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.