RFC 4004
Diameter Mobile IPv4 Application
9. Key Distribution AVPs
The Mobile-IP protocol defines a set of mobility security associations shared between the mobile node, foreign agent, and home agent. These three mobility security associations (MN-HA, MN-FA, and FA-HA) are dynamically created by the AAAH and have previously been described in sections 3.4 and 8. AAA servers supporting the Diameter Mobile IP Application MUST implement the key distribution AVPs defined in this document. The names of the key distribution AVPs indicate the two entities sharing the mobility security association. The first named entity in the AVP name will use the mobility security association to create authentication extensions using the given SPI and key. The second named entity in the AVP name will use the mobility security association to verify the authentication extensions of received Mobile IP messages. For instance, the MIP-MN-to-HA-MSA AVP contains the MN-HA nonce, which the mobile node will use to derive the MN-HA Key, and the MIP-HA-to-MN-MSA AVP contains the MN-HA key for the home agent. Note that mobility security associations are unidirectional; however, this application delivers only one key that is shared between both unidirectional security associations that exist between two peers. The security considerations of using the same key in each direction are given in section 13. The SPIs are, however, unique to each unidirectional security association and are chosen by the peer that will receive the Mobile IP messages authenticated with that security association. The following table describes the Diameter AVPs defined in the Mobile IP application and their AVP Code values, types, and possible flag values.
+--------------------------+
| AVP Flag Rules |
|----+-----+----+-----|----+
AVP Section | | |SHLD| MUST|MAY |
Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr|
-----------------------------------------|----+-----+----+-----|----|
MIP-FA-to-HA-SPI 318 9.11 Unsigned32 | M | P | | V | Y |
MIP-FA-to-MN-SPI 319 9.10 Unsigned32 | M | P | | V | Y |
MIP-HA-to-FA-SPI 323 9.14 Unsigned32 | M | P | | V | Y |
MIP-MN-to-FA-MSA 325 9.5 Grouped | M | P | | V | Y |
MIP-FA-to-MN-MSA 326 9.1 Grouped | M | P | | V | Y |
MIP-FA-to-HA-MSA 328 9.2 Grouped | M | P | | V | Y |
MIP-HA-to-FA-MSA 329 9.3 Grouped | M | P | | V | Y |
MIP-MN-to-HA-MSA 331 9.6 Grouped | M | P | | V | Y |
MIP-HA-to-MN-MSA 332 9.4 Grouped | M | P | | V | Y |
MIP-Nonce 335 9.12 OctetString| M | P | | V | Y |
MIP-Session-Key 343 9.7 OctetString| M | P | | V | Y |
MIP-Algorithm- 345 9.8 Enumerated | M | P | | V | Y |
Type
MIP-Replay-Mode 346 9.9 Enumerated | M | P | | V | Y |
MIP-MSA-Lifetime 367 9.13 Unsigned32 | M | P | | V | Y |
9.1. MIP-FA-to-MN-MSA AVP
The MIP-FA-to-MN-MSA AVP (AVP Code 326) is of type Grouped and
contains the FA-MN session key. This AVP is conveyed to the FA in an
AMA message. The MN allocates the MIP-FA-to-MN-SPI. The FA creates
an FA-MN authentication extension by using the session key and
algorithm, and the MN verifies that extension by using the same
session key and algorithm. The data field of this AVP has the
following ABNF grammar:
MIP-FA-to-MN-MSA ::= < AVP Header: 326 >
{ MIP-FA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
9.2. MIP-FA-to-HA-MSA AVP
The MIP-FA-to-HA-MSA AVP (AVP Code 328) is of type Grouped and
contains the FA-HA session key. This AVP is conveyed to the FA in an
AMA message. The HA allocates the MIP-FA-to-HA-SPI. The FA creates
the FA-HA authentication extension by using the session key and
algorithm, and the HA verifies that extension by using the same key
and algorithm. The AVP's data field has the following ABNF grammar:
MIP-FA-to-HA-MSA ::= < AVP Header: 328 >
{ MIP-FA-to-HA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
9.3. MIP-HA-to-FA-MSA AVP
The MIP-HA-to-FA-MSA AVP (AVP Code 329) is of type Grouped and
contains the Home Agent's session key, which it shares with the
foreign agent. This AVP is conveyed to the HA in an HAR message.
The FA allocates the MIP-HA-to-FA-SPI. The HA creates the HA-FA
authentication extension by using the session key and algorithm, and
the FA verifies that extension by using the same session key and
algorithm. The AVP's data field has the following ABNF grammar:
MIP-HA-to-FA-MSA ::= < AVP Header: 329 >
{ MIP-HA-to-FA-SPI }
{ MIP-Algorithm-Type }
{ MIP-Session-Key }
* [ AVP ]
9.4. MIP-HA-to-MN-MSA AVP
The MIP-HA-to-MN-MSA AVP (AVP Code 332) is of type Grouped, and
contains the HA-MN session key. This AVP is conveyed to the HA in an
HAR for FA COA Mobile IPv4 and in an AMA for collocated COA Mobile
IPv4. The MN allocates the MIP-HA-to-MN-SPI. The HA creates the
HA-MN authentication extension by using the session key and
algorithm, and the MN verifies that extension by using the same key
and algorithm. The AVP's field has the following ABNF grammar:
MIP-HA-to-MN-MSA ::= < AVP Header: 332 >
{ MIP-HA-to-MN-SPI }
{ MIP-Algorithm-Type }
{ MIP-Replay-Mode }
{ MIP-Session-Key }
* [ AVP ]
9.5. MIP-MN-to-FA-MSA AVP
The MIP-MN-to-FA-MSA AVP (AVP Code 325) is of type Grouped, and
contains the MN-FA session nonce, which the mobile node uses to
derive the MN-FA session key. This AVP is conveyed to the HA in an
HAR message. The FA allocates the MIP-MN-to-FA-SPI. The MN creates
the MN-FA authentication extension by using the session key and
algorithm, and the FA verifies that extension using the same key and
algorithm.
The home agent uses this AVP in the construction of the Mobile IP "Generalized MN-FA Key Generation Nonce Reply" extension [MIPKEYS]. MIP-MN-to-FA-MSA ::= < AVP Header: 325 > { MIP-MN-FA-SPI } { MIP-Algorithm-Type } { MIP-nonce } * [ AVP ]9.6. MIP-MN-to-HA-MSA AVP
The MIP-MN-to-HA-MSA AVP (AVP Code 331) is of type Grouped and contains the MN-HA session nonce, which the mobile node uses to derive the MN-HA session key. This AVP is conveyed to the HA in an HAR message for FA COA Mobile IPv4 and in an AMR for collocated Mobile IPv4. The HA allocates the MIP-MN-to-HA-SPI. The MN creates the MN-FA authentication extension using the session key and algorithm, and the HA verifies that extension using the same session key and algorithm. The Home Agent uses this AVP in the construction of the Mobile IP "Generalized MN-HA Key Generation Nonce Reply" extension [MIPKEYS]. MIP-MN-to-HA-MSA ::= < AVP Header: 331 > { MIP-MN-HA-SPI } { MIP-Algorithm-Type } { MIP-Replay-Mode } { MIP-nonce } * [ AVP ]9.7. MIP-Session-Key AVP
The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and contains the Session Key for the associated Mobile IPv4 authentication extension. The HAAA selects the session key.9.8. MIP-Algorithm-Type AVP
The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated and contains the Algorithm identifier for the associated Mobile IPv4 authentication extension. The HAAA selects the algorithm type. The following values are currently defined: 2 HMAC-SHA-1 [HMAC]
9.9. MIP-Replay-Mode AVP
The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and contains the replay mode the Home Agent for authenticating the mobile node. The HAAA selects the replay mode. The following values are supported (see [MOBILEIP] for more information): 1 None 2 Timestamps 3 Nonces9.10. MIP-FA-to-MN-SPI AVP
The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and it contains the Security Parameter Index the FA that and MN use to refer to the FA-MN mobility security association. The MN allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP].9.11. MIP-FA-to-HA-SPI AVP
The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32 and contains the Security Parameter Index the FA and HA use to refer to the FA-HA mobility security association. The HA allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP].9.12. MIP-Nonce AVP
The MIP-Nonce AVP (AVP Code 335) is of type OctetString and contains the nonce sent to the mobile node for the associated authentication extension. The mobile node follows the procedures in [MIPKEYS] to generate the session key used to authenticate Mobile IPv4 registration messages. The HAAA selects the nonce.9.13. MIP-MSA-Lifetime AVP
The MIP-MSA-Lifetime AVP (AVP Code 367) is of type Unsigned32 and represents the period of time (in seconds) for which the session key or nonce is valid. The associated session key or nonce, as the case may be, MUST NOT be used if the lifetime has expired; if the session key or nonce lifetime expires while the session to which it applies is still active, either the session key or nonce MUST be changed or the association Mobile IPv4 session MUST be terminated.
9.14. MIP-HA-to-FA-SPI AVP
The MIP-HA-to-FA-SPI AVP (AVP Code 323) is of type Unsigned32 and contains the Security Parameter Index the HA and FA use to refer to the HA-FA mobility security association. The FA allocates the SPI, and it MUST NOT have a value between zero (0) and 255, which is the reserved namespace defined in [MOBILEIP].10. Accounting AVPs
10.1. Accounting-Input-Octets AVP
The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64, and contains the number of octets in IP packets received from the user. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.10.2. Accounting-Output-Octets AVP
The Accounting-Output-Octets AVP (AVP Code 364) is of type Unsigned64 and contains the number of octets in IP packets sent to the user. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.10.3. Acct-Session-Time AVP
The Acct-Time AVP (AVP Code 46) is of type Unsigned32 and indicates the length of the current session in seconds. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.10.4. Accounting-Input-Packets AVP
The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64 and contains the number of IP packets received from the user. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.10.5. Accounting-Output-Packets AVP
The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64 and contains the number of IP packets sent to the user. This AVP MUST be included in all Accounting-Request messages and MAY be present in the corresponding Accounting-Answer messages as well.
10.6. Event-Timestamp AVP
The Event-Timestamp (AVP Code 55) is of type Time and MAY be included in an Accounting-Request message to record the time at which this event occurred on the mobility agent, in seconds since January 1, 1970, 00:00 UTC.11. AVP Occurrence Tables
The following tables present the AVPs defined in this document and their occurrences in Diameter messages. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. The table uses the following symbols: 0 The AVP MUST NOT be present in the message. 0+ Zero or more instances of the AVP MAY be present in the message. 0 - 1 Zero or one instance of the AVP MAY be present in the message. 1 One instance of the AVP MUST be present in the message.11.1. Mobile IP Command AVP Table
The table in this section is limited to the Command Codes defined in this specification. +-----------------------+ | Command-Code | |-----+-----+-----+-----+ Attribute Name | AMR | AMA | HAR | HAA | ------------------------------|-----+-----+-----+-----+ Authorization-Lifetime | 0-1 | 0-1 | 1 | 0 | Auth-Application-Id | 1 | 1 | 1 | 1 | Auth-Session-State | 0-1 | 0-1 | 1 | 0 | Acct-Multi-Session-Id | 0-1 | 0-1 | 0 | 0-1 | Destination-Host | 0-1 | 0 | 0-1 | 0 | Destination-Realm | 1 | 0 | 1 | 0 | Error-Message | 0 | 0-1 | 0 | 0-1 | Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 | MIP-Candidate-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 | MIP-Home-Agent-Host | 0-1 | 0 | 0-1 | 0 | MIP-Originating-Foreign-AAA | 0-1 | 0 | 0-1 | 0 | MIP-FA-Challenge | 0-1 | 0 | 0 | 0 | MIP-FA-to-MN-MSA | 0 | 0-1 | 0 | 0 | MIP-FA-to-HA-MSA | 0 | 0-1 | 0 | 0 | MIP-HA-to-FA-MSA | 0 | 0 | 0-1 | 0 | MIP-HA-to-MN-MSA | 0 | 0-1 | 0-1 | 0 |
MIP-MN-to-FA-MSA | 0 | 0 | 0-1 | 0 |
MIP-MN-to-HA-MSA | 0 | 0-1 | 0-1 | 0 |
MIP-FA-to-HA-SPI | 0 | 0 | 0 | 0-1 |
MIP-HA-to-FA-SPI | 0 | 0 | 0 | 0-1 |
MIP-FA-to-MN-SPI | 0 | 0 | 0 | 0-1 |
MIP-MN-to-FA-SPI | 0 | 0 | 0 | 0-1 |
MIP-HA-to-MN-SPI | 0 | 0 | 0 | 0-1 |
MIP-MN-to-HA-SPI | 0 | 0 | 0 | 0-1 |
MIP-Feature-Vector | 0-1 | 0-1 | 1 | 0 |
MIP-Filter-Rule | 0 | 0+ | 0+ | 0 |
MIP-Home-Agent-Address | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-MSA-Lifetime | 0 | 0-1 | 0-1 | 0 |
MIP-MN-AAA-Auth | 1 | 0 | 0 | 0 |
MIP-Mobile-Node-Address | 0-1 | 0-1 | 0-1 | 0-1 |
MIP-Reg-Reply | 0 | 0-1 | 0 | 0-1 |
MIP-Reg-Request | 1 | 0 | 1 | 0 |
Origin-Host | 1 | 1 | 1 | 1 |
Origin-Realm | 1 | 1 | 1 | 1 |
Origin-State-Id | 0-1 | 0-1 | 0-1 | 0-1 |
Proxy-Info | 0+ | 0+ | 0+ | 0+ |
Redirect-Host | 0 | 0+ | 0 | 0+ |
Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 |
Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 |
Result-Code | 0 | 1 | 0 | 1 |
Re-Auth-Request-Type | 0 | 0-1 | 0 | 0 |
Route-Record | 0+ | 0 | 0+ | 0 |
Session-Id | 1 | 1 | 1 | 1 |
User-Name | 1 | 0-1 | 1 | 0-1 |
------------------------------|-----+-----+-----+-----|
11.2. Accounting AVP Table
The table in this section is used to represent which AVPs defined in this document are to be present in the Accounting messages, as defined in [DIAMBASE]. +-------------+ | Command-Code| |------+------+ Attribute Name | ACR | ACA | -------------------------------------|------+------+ Accounting-Input-Octets | 1 | 0-1 | Accounting-Input-Packets | 1 | 0-1 | Accounting-Output-Octets | 1 | 0-1 | Accounting-Output-Packets | 1 | 0-1 | Acct-Multi-Session-Id | 1 | 0-1 | Acct-Session-Time | 1 | 0-1 | MIP-Feature-Vector | 1 | 0-1 | MIP-Home-Agent-Address | 1 | 0-1 | MIP-Mobile-Node-Address | 1 | 0-1 | Event-Timestamp | 0-1 | 0 | -------------------------------------|------+------+12. IANA Considerations
This section contains the namespaces that have either been created in this specification or had their values assigned to existing namespaces managed by IANA.12.1. Command Codes
This specification assigns the values 260 and 262 from the Command Code namespace defined in [DIAMBASE]. See section 5 for the assignment of the namespace in this specification.12.2. AVP Codes
This specification assigns the values 318 - 348 and 363 - 367 from the AVP Code namespace defined in [DIAMBASE]. See sections 7, 9, and 10 for the assignment of the namespace in this specification.12.3. Result-Code AVP Values
This specification assigns the values 4005 - 4008 and 5024 - 5025 from the Result-Code AVP (AVP Code 268) value namespace defined in [DIAMBASE]. See section 6 for the assignment of the namespace in this specification.
12.4. MIP-Feature-Vector AVP Values
There are 32 bits in the MIP-Feature-Vector AVP (AVP Code 337) that are available for assignment. This document assigns bits 1 - 9, as listed in section 7.5. The remaining bits should only be assigned via Standards Action [IANA].12.5. MIP-Algorithm-Type AVP Values
As defined in section 9.8, the MIP-Algorithm-Type AVP (AVP Code 345) defines the value 2. All remaining values, except zero, are available for assignment via Designated Expert [IANA].12.6. MIP-Replay-Mode AVP Values
As defined in section 9.9, the MIP-Replay-Mode AVP (AVP Code 346) defines the values 1 - 3. All remaining values, except zero, are available for assignment via Designated Expert [IANA].12.7. Application Identifier
This specification uses the value two (2) to the Application Identifier namespace defined in [DIAMBASE]. See section 4 for more information.13. Security Considerations
This specification describes a Mobile IPv4 Diameter Application for authenticating and authorizing a Mobile IPv4 mobile node. The authentication algorithm used is dependent on the transforms used within the Mobile IPv4 protocol, and [MIPCHAL]. This specification, in conjunction with [MIPKEYS], also defines a method by which the home Diameter server can create and distribute session keys and nonces for use in authenticating and integrity-protecting Mobile IPv4 registration messages [MOBILEIP]. The key distribution is asymmetric, as communication with the mobile node occurs via the Mobile IPv4 protocol [MIPKEYS, MOBILEIP], where as communication to the Home Agent and Foreign Agent occurs via the Diameter protocol. Where untrusted Diameter agents are present, end-to-end security MUST be used. The end-to-end security takes the form of TLS or IPSec security associations between the AAAH and the FA and between the AAAH and the HA. These connections will be authenticated with the use of public keys and certificates; however, the identities that appear in the certificates must be authorized and bound to a particular Mobile IPv4 Diameter session before the AAAH can safely begin distribution of keys.
Note that the direct connections are established as a result of Diameter redirect messages. For example, in Figure 3, the FA gets a redirect response containing the Redirect-Host AVP of the AAAH. This is the identity that should be matched against the certificate presented by the AAAH when the secure connection is established. In this case, the network of Diameter proxies and redirect agents is trusted with the task of returning the correct AAAH identity to the FA. The AAAH must also make an authorization decision when the FA establishes the connection. If the AAAH and the redirect server are one and the same, then the AAAH may have observed and noted the original AMR message that contained the identity of the FA and so may authorize the establishment of a TLS or IPSec connection from the same entity. Otherwise, the AAAH would need to maintain a list of all authorized visited domains (roaming partners) and authorize TLS or IPSec connections based on this list. Note that establishment of the connection is only the first step, and the AAAH has another opportunity to deny service upon receipt of the AMR message itself. At this step, the AAAH can check the internal AVPs of the AMR to ensure that the FA is valid; for example, it can check that the Mobile IP COA is equal to the IP address used as the endpoint of the TLS or IPSec connection. However, such a policy would prevent the FA from using different interfaces for AAA and Mobile IP tunnel packets and may not be desirable in every deployment situation. A similar set of considerations applies to the connection between AAAH and HA when those entities are in different administrative domains. However, here the roles are reversed because it is the AAAH that contacts the HA via the HAR. The identity of the candidate HA is given to the AAAH in the AMR, and the AAAH should expect to receive the same identity in the public key certificates during TLS or IPSec negotiation. The HA may authorize individual connections by acting as its own redirect server, or it may maintain a list of trusted roaming partners. This application creates and distributes a single session key for each pair of MSAs between two entities; e.g., the same session key is used for the MN-HA MSA and the HA-MN MSA. This is safe to do from a security perspective, as the session keys are only used with keyed hash functions to generate authenticator values that protect the integrity of each Mobile IP control message. Mobile IP messages have built-in replay protection with the use of timestamps or nonces [MOBILEIP], and, due to the nature of the protocol, requests are always different bitwise from responses, at least in the message type code. This avoids problems that might arise in other situations
where an attacker could mount a replay or reflection attack if the same key were used (for example) to encrypt otherwise unprotected traffic on more than one connection leg in the network. Nonces are sent to the mobile node, which are used to generate the session keys via the HMAC-SHA-1 one-way function. Because the nonces and authentication extensions may be observed by anyone with access to a clear-text copy of the Registration Reply, the pre-shared key between the mobile node and the home Diameter server would be vulnerable to an offline dictionary attack if it did not contain enough entropy. To prevent this, the pre-shared key between the mobile node and the home Diameter server SHOULD be a randomly chosen quantity of at least 96 bits. Because the session key is determined by the long-term secret and the nonce, the nonce SHOULD be temporally and globally unique; if the nonce were to repeat, then so would the session key. To prevent this, a nonce is strongly recommended to be a random [RANDOM] value of at least 128 bits. The long-term secret between the MN and AAAH MUST be refreshed periodically, to guard against recovery of the long-term secret due to nonce reuse or other factors. This is accomplished by using out-of-band mechanisms, which are not specified in this document. Note that it is not recommended to set the MIP-MSA-Lifetime AVP value to zero, as keeping session keys for a long time (no refresh) increases the level of vulnerability.14. References
14.1. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [DIAMBASE] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [MOBILEIP] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[MIPCHAL] Perkins, C. and P. Calhoun, "Mobile IPv4 Challenge/Response Extensions", RFC 3012, November 2000. [NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999. [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [MIPKEYS] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IP", RFC 3957, March 2005. [AAANAI] Johansson, F. and T. Johansson, "Mobile IPv4 Extension for Carrying Network Access Identifiers", RFC 3846, June 2004. [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [TLS] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.14.2. Informative References
[MIPREQ] Glass, S., Hiller, T., Jacobs, S., and C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000. [CDMA2000] Hiller, T., Walsh, P., Chen, X., Munson, M., Dommety, G., Sivalingham, S., Lim, B., McCann, P., Shiino, H., Hirschman, B., Manning, S., Hsu, R., Koo, H., Lipford, M., Calhoun, P., Lo, C., Jaques, E., Campbell, E., Xu, Y., Baba, S., Ayaki, T., Seki, T., and A. Hameed, "CDMA2000 Wireless Data Requirements for AAA", RFC 3141, June 2001. [EVALROAM] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999. [MIPNAI] Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, March 2000.
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.15. Acknowledgements
The authors would like to thank Nenad Trifunovic, Haseeb Akhtar, and Pankaj Patel for their participation in the pre-IETF Document Reading Party; Erik Guttman for his very useful proposed text; and to Fredrik Johansson, Martin Julien, and Bob Kopacz for their very useful contributed text. The authors would also like to thank the participants of 3GPP2's TSG-X working group for their valuable feedback, and the following people for their contribution in the development of the protocol: Kevin Purser, Thomas Panagiotis, Mark Eklund, Paul Funk, Michael Chen, Henry Haverinen, and Johan Johansson. General redirect server text due to Pasi Eronen was borrowed from Diameter-EAP. Pat Calhoun would like to thank Sun Microsystems, as most of the effort put into this document was done while he was in their employ.Authors' Addresses
Questions about this memo can be directed to: Pat Calhoun Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA Phone: +1 408-853-5269 EMail: pcalhoun@cisco.com Tony Johansson Bytemobile, Inc. 2029 Stierlin Court Mountain View, CA 94043 Phone: +1 650-641-7817 Fax: +1 650-641-7701 EMail: tony.johansson@bytemobile.com
Charles E. Perkins Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Phone: +1 650-625-2986 Fax: +1 650-625-2502 EMail: Charles.Perkins@nokia.com Tom Hiller Lucent Technologies 1960 Lucent Lane Naperville, IL 60566 USA Phone: +1 630-979-7673 EMail: tomhiller@lucent.com Peter J. McCann Lucent Technologies 1960 Lucent Lane Naperville, IL 60563 USA Phone: +1 630-713-9359 Fax: +1 630-713-1921 EMail: mccap@lucent.com
Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.