diff options
Diffstat (limited to 'doc/rfc/rfc5419.txt')
| -rw-r--r-- | doc/rfc/rfc5419.txt | 1067 |
1 files changed, 1067 insertions, 0 deletions
diff --git a/doc/rfc/rfc5419.txt b/doc/rfc/rfc5419.txt new file mode 100644 index 0000000..a9f9f80 --- /dev/null +++ b/doc/rfc/rfc5419.txt @@ -0,0 +1,1067 @@ + + + + + + +Network Working Group B. Patil +Request for Comments: 5419 Nokia +Category: Informational G. Dommety + Cisco + January 2009 + + +Why the Authentication Data Suboption is Needed for Mobile IPv6 (MIPv6) + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (c) 2009 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents (http://trustee.ietf.org/ + license-info) in effect on the date of publication of this document. + Please review these documents carefully, as they describe your rights + and restrictions with respect to this document. + +Abstract + + Mobile IPv6 defines a set of signaling messages that enable the + mobile node (MN) to authenticate and perform registration with its + home agent (HA). These authentication signaling messages between the + mobile node and home agent are secured by an IPsec security + association (SA) that is established between the MN and HA. The MIP6 + working group has specified a mechanism to secure the Binding Update + (BU) and Binding Acknowledgement (BAck) messages using an + authentication option, similar to the authentication option in Mobile + IPv4, carried within the signaling messages that are exchanged + between the MN and HA to establish a binding. This document provides + the justifications as to why the authentication option mechanism is + needed for Mobile IPv6 deployment in certain environments. + + + + + + + + + + + +Patil & Dommety Informational [Page 1] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Conventions Used in This Document ...............................3 + 3. Background ......................................................3 + 4. Applicability Statement .........................................3 + 5. Justification for the Use of the Authentication Option ..........5 + 5.1. Motivation for Use of the Authentication Option in + CDMA2000 ...................................................5 + 5.2. Additional Arguments for the Use of the + Authentication Option ......................................6 + 6. Application of Mobile IPv6 in CDMA Networks .....................9 + 6.1. IPv4-Based Mobility Architecture in CDMA2000 Networks ......9 + 6.2. IPv6-Based Mobility Architecture in CDMA2000 Networks .....11 + 6.2.1. Overview of the Mobility Operation in + IPv6-Based CDMA2000 Networks .......................11 + 6.2.2. Authentication and Security Details ................12 + 7. Limitations of the Authentication Protocol Option ..............14 + 8. Security Considerations ........................................16 + 9. Conclusion .....................................................16 + 10. Acknowledgements ..............................................17 + 11. References ....................................................17 + 11.1. Normative References .....................................17 + 11.2. Informative References ...................................18 + +1. Introduction + + Mobile IPv6 relies on the IPsec Security Association between the + Mobile Node (MN) and the Home Agent (HA) for authentication of the MN + to its HA before a binding cache can be created at the HA. An + alternate mechanism that does not rely on the existence of the IPsec + SA between the MN and HA for authenticating the MN is needed in + certain deployment environments. Such an alternate mechanism is + outlined in [RFC4285]. This document is intended to capture for + archival purposes the reasoning behind the need for the + authentication protocol [RFC4285]. It should be noted that the + alternate solution does not imply that the IPsec-based solution will + be deprecated. It simply means that in certain deployment scenarios + there is a need for supporting MIPv6 without an IPsec SA between the + MN and HA. So the alternate solution is in addition to the IPsec- + based mechanism specified in the base RFCs, i.e., [RFC3775], + [RFC3776], and [RFC4877]. It has been noted that some of the + challenges of deploying MIPv6 in certain types of networks arose from + dependence on the Internet Key Exchange (IKE), which did not + integrate well with an Authentication, Authorization, and Accounting + (AAA) backend infrastructure. IKEv2 solves this problem. However, + at the time of discussion on the need for the authentication + + + + +Patil & Dommety Informational [Page 2] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + + protocol, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec + Architecture" [RFC4877] was still a work in progress and, as a + result, an alternative solution was needed. + + It should be noted that some of the arguments for justifying the + specification of the authentication protocol have been made redundant + as a result of the specification of Mobile IPv6 operation with IKEv2 + [RFC4877]. However, some of the arguments discussed in this document + are still applicable and justify usage of the authentication protocol + in certain deployment environments. + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +3. Background + + Mobile IPv6 signaling involves several messages. These include: + + o The Binding Update/Binding Acknowledgment between the mobile node + and the home agent. + + o The route optimization signaling messages, which include the + HoTI-HoT (Home Test Init/Home Test), CoTI-CoT (Care-of Test Init/ + Care-of Test), and BU-BAck messages between the MN and CN. HoTI + and HoT signaling messages are routed through the MN's HA. + + o Mobile prefix solicitation and advertisements between the MN and + HA. + + o Home agent discovery by MNs. + + The signaling messages between the MN and HA are secured using the + IPsec SA that is established between these entities. The exception + to this are the messages involved in the home agent discovery + process. [RFC4877] specifies the establishment of the IPsec SA using + IKEv2. + +4. Applicability Statement + + The authentication option specified in "Authentication Protocol for + MIPv6" [RFC4285] provides a solution for MIPv6 deployment in + environments in which an operator may not require IPsec-based + security for the signaling. The reasons for an operator choosing to + + + + + +Patil & Dommety Informational [Page 3] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + + deploy MIPv6 without mandating IPsec-based security for signaling + messages between the MN and HA could be many. Some of these are, for + example: + + 1. Operators deploying MIPv6 in cellular networks may consider IPsec + and IKEv2 as adding overhead to the limited bandwidth over the + air interface. The overhead here is in terms of the bytes that + IPsec and IKEv2 introduce to the signaling. + + 2. Operators may consider the number of messages between the MN and + HA that are required to establish the IPsec SA as too many. The + number of transactions chew into the capacity of limited + bandwidth air interfaces when MIPv6 is used in such environments. + It also adds additional latency to the establishment of the + binding. + + 3. In many deployments, authentication credentials already exist in + a AAA server. These credentials are used for authenticating a + user and authorizing network access. The same credentials and + security parameters cannot be reused for MIPv6 security as well, + if IKEv1 is used. + + 4. Dynamic assignment of home agents is needed in certain + deployments to minimize the latency of the backhaul. This is + done by allocating an HA in a visited network, for example. + Requiring IPsec SAs with home agents that are dynamically + assigned is an overhead, especially when the HA is in a visited + network. + + 5. In certain deployments, signaling messages between the MN and HA + may be over secure link layers. The lower layers provide + ciphering and security for the messages, and hence the need for + IPsec to do the same for MIPv6 messages does not exist. + + One example of networks that have such characteristics are Code + Division Multiple Access (CDMA) networks as defined in the 3GPP2 + [3GPP2 X.S0011-002-D] specification. Mobile WiMAX (Worldwide + Interoperability for Microwave Access), which is based on IEEE + 802.16e, also specifies in the network architecture the use of MIPv6, + with the default security for signaling being the authentication + protocol [RFC4285]. The WiMAX network architecture specifications + are available at [WiMAX-NWG]. + + + + + + + + + +Patil & Dommety Informational [Page 4] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + +5. Justification for the Use of the Authentication Option + + The following two sections provide the reasoning for why the + authentication option-based registration process for Mobile IPv6 is + needed. Section 5.1 provides key arguments for the use of the + authentication option. Section 5.2 provides further explanation and + additional motivations for the authentication option. + +5.1. Motivation for Use of the Authentication Option in CDMA2000 + Wireless Networks + + CDMA2000 networks deployed and operational today use Mobile IPv4 for + IP mobility. Operators have gained a significant amount of + operational experience in the process of deploying and operating + these networks. 3GPP2 has specified Mobile IPv6 operation in the + [3GPP2 X.S0011-002-D] specification. The following are the + deployment constraints that existing CDMA networks have to deal with + when deploying mobility service based on IPv6: + + o Operators intend to leverage the Mobile IPv4 deployment and + operational experience by ensuring that Mobile IPv6 has a similar + deployment and operating model. + + o Operators will have two parallel networks: one that offers IPv4 + mobility with MIPv4 and another providing IPv6 mobility using + MIPv6. + + o The same backend subscriber profile database, security keys, etc. + are intended to be used for both Mobile IPv4 and Mobile IPv6 + service. However, from a security standpoint, the reuse of the + same keys with multiple algorithms/protocols is a bad idea. + + o The same user-configuration information, i.e., the identity and + keys associated with a user, will be used for IP mobility service + in IPv4 and/or IPv6 networks. The only security association that + is preconfigured is a shared secret between the mobile node and + the home AAA server. This is in contrast with an earlier version + of the Mobile IPv6 model, which required an IPsec SA between the + MN and HA. At the time of this writing, the IKEv2-based solution + for establishing an IPsec SA [RFC4877] was not available. IKEv2 + does enable integration with a AAA backend. + + o At the time of specifying the authentication protocol, the Mobile + IPv6 specification did not support the dynamic assignment of home + agent and home address. However, work done in the MIP6 working + group on bootstrapping of Mobile IPv6 as specified in [RFC5026] + and "MIPv6-Bootstrapping for the Integrated Scenario" [BOOT] + addresses this deficiency. The mechanism defined in + + + +Patil & Dommety Informational [Page 5] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + + "Authentication Protocol for Mobile IPv6" [RFC4285] is capable of + handling authentication even in the case of dynamic assignments + (and is similar to what is used in current MIPv4 deployments). + + Consequently, MIPv6 as specified at the time the authentication + protocol was being specified, did not satisfy many of the deployment + requirements. "Authentication Protocol for MIPv6" [RFC4285] along + with "MN Identifier Option for MIPv6" [RFC4283] are enabling the + deployment of Mobile IPv6 in a manner that is similar to what is + deployed in CDMA2000 networks today. This authentication model is + very similar to the one adopted by the MIP4 WG. This is explained in + detail in [3GPP2 X.S0011-002-D]. + + The earlier MIPv6 deployment model, which requires an IPsec SA that + is either configured manually or established using IKE, does not have + synergy with the deployment models of 3GPP2 or WiMAX networks. This + issue has however been alleviated with the publication of RFC 4877, + which enables the establishment of an IPsec SA using IKEv2 and which + is also able to integrate with the backend AAA infrastructure that is + responsible for the authentication of the MN in 3GPP2 and WiMAX + networks. + +5.2. Additional Arguments for the Use of the Authentication Option + + The use of IPsec for performing Registration with a home agent is not + always an optimal solution. While it is true that IPsec is viewed as + an integral part of the IPv6 stack, it is still a considerable + overhead from a deployment perspective of using IPsec as the security + mechanism for the signaling messages between the MN and HA. This + statement is a result of experience gained from deployment of Mobile + IPv4. MIPv4 does not rely on IPsec for securing the Registration + signaling messages. + + Deployment of Mobile IPv6 on a large scale is possible only when the + protocol is flexible for being adapted to various scenarios. The + scenario being considered is the deployment in CDMA2000 networks or + WiMAX networks. CDMA2000 networks are currently deployed in many + countries today. WiMAX deployments in many countries began in 2008. + The packet data network architecture of CDMA2000 [3GPP2 + X.S0011-002-D] includes a MIPv4 foreign agent/home agent and a + RADIUS-based AAA infrastructure for Authentication, Authorization, + and Accounting purposes. The AAA infrastructure provides + authentication capability in the case of Mobile IPv4. + + Typically, the mobile node shares a security association with the + AAA-Home entity. This is the preferred mode of operation over having + a shared secret between the MN and HA because the AAA-Home entity + provides a central location for provisioning and administering the + + + +Patil & Dommety Informational [Page 6] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + + shared secrets for a large number of mobiles (millions). This mode + of operation also makes dynamic home address and dynamic home agent + assignment easier. A similar approach is needed for the deployment + of Mobile IPv6 in these networks. There is no practical mechanism to + use IPsec directly with the AAA infrastructure without the use of + IKEv2 or some other mechanism that enables the establishment of the + IPsec SA between the MN and HA. + + Mobile IPv6 as specified in [RFC3775] and [RFC3776] is based on a + very specific model for deployment. It anticipates the mobile node's + having a static home IPv6 address and a designated home agent. This + is not practical in most deployment scenarios being considered. An + IPsec SA is expected to be created via manual keying or established + dynamically via IKE or IKEv2. These assumptions do not necessarily + fit in very well for the deployment model envisioned in CDMA2000 or + WiMAX networks. These limitations have however been overcome as a + result of the bootstrapping specifications as per [RFC5026] and + "MIPv6-Bootstrapping for the Integrated Scenario" [BOOT]. + + CDMA2000 and WiMAX networks would prefer to allocate home addresses + to MNs on a dynamic basis. The advantage of doing so is the fact + that the HA can be assigned on a link that is close to the MN's point + of attachment. While route optimization negates the benefit of + having a home agent on a link close to the MN, it cannot always be + guaranteed that the MN and correspondent node (CN) will use or + support route optimization. There may also be instances where the + operator prefers to not allow route optimization for various reasons, + such as accounting aggregation or enforcing service contracts. In + such cases, an HA that is close to the MN's point of attachment + reduces the issues of latency, etc. of forward and reverse tunnelling + of packets between the MN and HA. + + CDMA2000 networks that are operational today have large numbers of + subscribers who are authenticated via the AAA infrastructure. + Deployment of Mobile IPv6 should leverage the existing AAA + infrastructure. The security model needed in these networks is an SA + between the MN and AAA-Home entity. This is the primary security + association that should be used for authenticating and authorizing + users to utilize MIPv6 service. This SA is then used for + establishing session keys between the MN and the dynamically assigned + HA for authenticating subsequent Binding Updates and Binding + Acknowledgements between them. Establishing an IPsec SA between the + MN and HA using AAA infrastructure was not specified for Mobile IPv6 + at the time the authentication protocol was being specified. RFC + 3776 explains how IKE is used for establishing the SA between the MN + and HA. [RFC4877] has been published subsequently and hence the + issue of establishing an IPsec SA dynamically between the MN and HA + no longer exists. CDMA2000 network operators would prefer to assign + + + +Patil & Dommety Informational [Page 7] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + + home addresses to the MN on a dynamic basis -- preferably using the + AAA infrastructure, which contains subscriber profile and capability + information. This was not possible prior to the specification of the + bootstrapping mechanism in [RFC5026]. + + A large subset of MNs in CDMA2000 networks do not have IKE + capability. As a result, the use of RFC 3776 for setting up the + MN-HA IPsec SA is not an option. It should also be noted that IKE + requires several transactions before it is able to establish the + IPsec SA. [RFC4877] specifies the establishment of an IPsec SA + between the MN and HA using IKEv2. It is possible that not all MNs + in a deployment will support IKEv2, and hence an alternative + mechanism provides the needed flexibility. + + CDMA2000 network operators are extremely conscious in terms of the + number of messages sent and received over the air interface for + signaling. The overhead associated with sending/receiving a large + number of signaling messages over the air interface has a direct + impact on the overall capacity and cost for the operator. + Optimization of the number of messages needed for using a service + like Mobile IPv6 is of great concern. As a result, the use of IKE + for Mobile IPv6 deployment is considered as being suboptimal in + certain network architectures and deployment scenarios from the + perspective of message overhead. + + Another downside of IKE for setting up the IPsec SA between the MN + and HA is that IKE does not integrate very well with the RADIUS-based + AAA backend. Since operators rely on the AAA infrastructure to + provision subscribers as well as define profiles, keys, etc. in the + AAA-Home, there is no getting away from the use of AAA in CDMA2000 + networks. IKEv2 does address this problem. However, from a timeline + perspective, the availability of IKEv2 specifications for "Mobile + IPv6 Operation with IKEv2 and the Revised IPsec Architecture" + [RFC4877] and its implementations did not meet the need of operators + that were relying on 3GPP2 specifications. With the specification of + IKEv2 and publication of RFC 4877, integration with AAA backends is + no longer an issue. + + In summary, the model of Mobile IPv6 deployment that mandated the + existence of an IPsec SA between the MN and HA, as specified in RFCs + 3775 and 3776, was too rigid and did not meet the requirements of + operators building networks based on the CDMA2000 [3GPP2 + X.S0011-002-D] specifications. To address this shortcoming, the + authentication protocol [RFC4285] was specified. + + + + + + + +Patil & Dommety Informational [Page 8] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + +6. Application of Mobile IPv6 in CDMA Networks + + Sections 6.1 and 6.2 describe the IPv4- and IPv6-based mobility + architectures in CDMA networks, respectively. For further details + associated with the description below, please refer to Section 5, + "MIP6 Operation", in the 3GPP2 specification [3GPP2 X.S0011-002-D]. + +6.1. IPv4-Based Mobility Architecture in CDMA2000 Networks + + The figure below shows a high level view of the key network elements + that play a role in providing IP mobility using Mobile IPv4. + + +--------------+ +----------------------+ + | +------+ | | +------+ | + | | | | | | | | + | |F-AAA | | | |H-AAAH| | + | | +-------------------+ | | + | +---+--+ | | +--+---+ | + | | | | | | + | | | | | | + +------+ | +---+--+ | | +--+---+ | + | | | | | | | | | | + | MN +- -|- -+ PDSN + -- -- -- -- - + HA | | + | | | | /FA | | | | | | + +------+ | +------+ | | +------+ | + | | | | + +--------------+ +----------------------+ + + Figure 1: CDMA2000 Packet Data Network Architecture with Mobile IPv4 + + The CDMA mobility architecture based on MIPv4 is explained below. In + this architecture, mobility is tightly integrated with the AAA + infrastructure. The Mobile Node is configured with an NAI (Network + Access Identifier) and an MN-AAA key. The MN-AAA key is a shared key + that is shared between the MN and the home AAA server. + + Below is the access link setup procedure: + + (1) Bring up the PPP on the MN/PDSN (access router link). PPP + authentication is skipped. Mobile IP authentication is + performed via the FA (Foreign Agent). + + (2) The PDSN (Packet Data Serving Node) sends a Mobile IP challenge + to the MN on the PPP link (RFC 3012). + + + + + + + +Patil & Dommety Informational [Page 9] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + + (3) The MN sends a MIP Registration Request (RRQ), which includes + the user's NAI, challenge, and MN-AAA extension that has a + challenge response, and an MN-HA extension, which is generated + based on the MN-HA key. + + (4) The PDSN extracts the MIP NAI, challenge, and the response to + the challenge, from the MIP MN-AAA extension, and sends an + Access Request to the F-AAA (challenge/response using MD5). + + (5) The F-AAA (Foreign AAA) may forward it to the H-AAA (Home AAA) + if needed (based on realm). + + (6) AAA authenticates the CHAP-challenge/response and returns + "success" if authentication succeeds. + + (7) The PDSN forwards the Registration Request (RRQ) to the HA. + + (8) The HA authenticates the RRQ (MHAE (Mobile-Home Authentication + Extension)). The HA may optionally authenticate with the AAA + infrastructure (just like the PDSN in #4). + + (9) If authentication is successful, the HA creates a binding and + sends a success Registration Reply (RRP) to the PDSN. + + (10) The PDSN creates a visitor entry and forwards the RRP to the MN. + + + + + + + + + + + + + + + + + + + + + + + + + + +Patil & Dommety Informational [Page 10] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + +6.2. IPv6-Based Mobility Architecture in CDMA2000 Networks + + Due to the need for co-existence with MIPv4, and having the same + operational model, the 3GPP2 standards body is adopting the following + mobility architecture for MIPv6. + + Access Domain Home Domain + +--------------+ +----------------------+ + | +------+ | | +------+ | + | | | | | | | | + | |F-AAA | | | |H-AAA | | + | | +-------------------+ | | + | +---+--+ | | +--+---+ | + | | | | | | + | | | | | | + +------+ | +---+--+ | | +--+---+ | + | | | | | | | | | | + | MN +- -|- -+ PDSN + -- -- -- -- - + HA | | + | | | | /AR | | | | | | + +------+ | +------+ | | +------+ | + | | | | + +--------------+ +----------------------+ + + Figure 2: CDMA2000 Packet Data Network Architecture with Mobile IPv6 + + The Mobile Node is configured with an NAI (Network Access Identifier) + and an MN-AAA key. The MN-AAA key is a shared key between the MN and + the home AAA server. + +6.2.1. Overview of the Mobility Operation in IPv6-Based CDMA2000 + Networks + + The following steps explain at a very generic level the operation of + IP mobility in CDMA2000 networks: + + (1) The MN performs link-layer establishment. This includes setting + up the PPP link. PPP-CHAP authentication is performed. This is + authenticated by the PDSN/AR (Access Router) by sending an + Access Request to the F-AAA (and to the H-AAA when/if needed). + Optionally, the MN acquires bootstrap information from the Home + Network (via the PDSN; the PDSN receives this information in + Access Accept). The bootstrap information includes home address + and home agent assignment. The MN uses stateless DHCPv6 + [RFC3736] to obtain the bootstrap information from the PDSN. + + + + + + + +Patil & Dommety Informational [Page 11] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + + (2) The MN begins to use the home address (HoA) that was assigned in + step 1. If no HoA was assigned at step 1, the MN generates + (auto-configures) an IPv6 global unicast address based on the + prefix information received at step 1. + + (3) The MN sends a Binding Update to the selected home agent. In + the BU, the MN includes the NAI option, timestamp option, and + MN-AAA auth option. + + (4) The HA extracts the NAI, authenticator, etc. from the BU and + sends an Access Request to the Home RADIUS server. + + (5) The Home RADIUS server authenticates and authorizes the user and + sends back a RADIUS Access Accept to the HA indicating + successful authentication and authorization. + + (6) The HA performs a replay check with the ID field in the received + BU. The HA also performs proxy Duplicate Address Detection + (DAD) on the MN's home address (global) using proxy Neighbor + Solicitation as specified in [RFC4861]. + + (7) Assuming that proxy DAD is successful, the HA sends back a + Binding Acknowledgment to the MN. In this BAck message, the HA + includes the MN-HA mobility option, NAI mobility option, and ID + mobility option. + +6.2.2. Authentication and Security Details + + Access Link Setup, Access Authentication, and Bootstrapping: + + (1) The MN brings up a PPP session. The PDSN triggers the MN to + perform CHAP authentication, as part of access authentication, + while bringing up the PPP link. + + (2) The MN is authenticated using the PPP-CHAP by the H-AAA (Home + AAA), via the F-AAA (Foreign AAA). + + (3) The H-AAA may optionally send the HoA and HA IP address to the + PDSN for bootstrapping the MN (skipping details). + + + + + + + + + + + + +Patil & Dommety Informational [Page 12] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + + Mobile IPv6 Authentication: + + The call flow for the initial authentication (the numbers in the + parentheses correspond to the explanation below): + + MN HA H-AAA + | BU to HA (4) | RADIUS Access-ReQ(5) + |------------------------------------>|------------------->|(6) + | (includes NAI option, MN-ID option, | | + | Mesg ID option, MN-AAA auth option) |RADIUS Access Accept|(7) + | + |<-------------------| + | | | + | HA/AAAH authenticates MN + | + | |(8) + | + | | + | + | BAck to MN (9) | + | + |<------------------------------------|--------------------| + | (including MN-ID option, | (10) + | Message ID option, | + | MN-HA auth options) | | + + Figure 3: Flow Diagram for Initial Authentication + + (4) The MN sends a Binding Update (BU) to the HA. The Binding + Update is authenticated using the MN-AAA option. The + authenticator in the MN-AAA option is calculated using the hash + of the BU and MN-AAA shared key. It uses the HMAC_SHA1 + algorithm. The Security Parameter Index (SPI) field in MN-AAA + is set to 3 (as per [RFC4285]). The BU also includes the NAI + and timestamp, among other details. The hash of the BU includes + the 'timestamp' option and thus provides proof of liveness to + prevent replay. + + (5) The HA, on receiving the BU, extracts the NAI, timestamp, and + authenticator from the MN-AAA option, and generates the hash of + the BU. The HA sends an Access Request to the AAA and puts this + information in 3GPP2-defined VSAs (Vendor Specific Attributes). + The NAI is inserted in the username option in the Access Request + message. The other attributes sent are: the timestamp option, + the hash of the BU (till SPI field of MN-AAA auth option), and + the authentication data from the MN-AAA auth option. + + + + + +Patil & Dommety Informational [Page 13] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + + (6) AAA (RADIUS server that interprets these attributes) + authenticates the MN based on the hash of the BU and the + authenticator. Proceed to step 7. + + (7) AAA calculates a session key based on the MN-AAA shared secret + and timestamp, and sends this to the HA in an Access Accept (in + a 3GPP2-defined VSA). + + (8) The HA creates a binding and a security association per + Authentication Protocol for MIPv6 [RFC4285]. The key for this + association is retrieved from the Access Accept and is referred + to as the session key. The HA associates a fixed SPI of 5 with + this SA, and is associated with the binding for the MN. (The + description of this step skips the details for timestamp + processing at the HA.) + + (9) The HA sends a Binding Acknowledgement (BAck) to the MN. The + BAck has the MN-HA authentication option, authenticated using + the session key. This option has the SPI set to 5. + + (10) On receiving a BAck, the MN calculates the session key (using + the same method as AAA) and associates it with an SPI value of + 5. + + The MN derives the session key and SA using the timestamp in the BU + that the MN sent and the MN-AAA shared key. The MN uses this key to + authenticate the MN-HA option in the Binding Ack. If authentication + is successful, the MN creates a security association with SPI=5. + This key is used to authenticate further BUs to the HA using the + MN-HA auth option. Once the binding lifetime expires and the binding + is deleted, the binding as well as the security association based on + the integrity key is removed at the MN and HA. + + Migration from MobileIPv4 to MobileIPv6 utilizes the same network + architecture and, specifically, the same AAA infrastructure. Thus, + it is natural to have similar signaling in MIPv6 as in MIPv4, + specifically the authentication with AAA infrastructure. + +7. Limitations of the Authentication Protocol Option + + While the authentication protocol as specified in [RFC4285] provides + Mobile IPv6 [RFC3775] deployments a certain degree of flexibility, it + does have a few disadvantages as well. These are: + + (1) The route optimization feature specified in RFC 3775 requires a + secure transport (IPsec/ESP (Encapsulating Security Payload) + mode) between the MN and HA. In cases where the authentication + protocol [RFC4285] is used as the means for securing the MIPv6 + + + +Patil & Dommety Informational [Page 14] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + + signaling between the MN and HA, route optimization should be + switched off unless the security of the signaling between the MN + and HA can be guaranteed via other means (such as link-layer + security in the case of 3GPP2 networks). + + (2) The MIPv6 protocol is responsible for the security of the + signaling messages as opposed to relying on IPsec for providing + the security. + + (3) In 3GPP2 networks, link-layer security mechanisms, ingress + filtering at the PDSN, and various network domain security + mechanisms largely ensure that reverse tunnelled packets + received by the HA do not have spoofed source addresses, and + that their contents have not been modified. This implies the HA + can determine the specific MN that sent the packet simply by + verifying the outer-source IP address matches the currently + registered care-of address. Authentication of payload packets + can be necessary for, e.g.: + + - Authenticating signaling messages other than BU/BAck + between the MN and HA, such as ICMPv6, MLD, and DHCPv6. + + - Enforcing access control to the network behind the HA. + + - Accounting or other flow-specific processing performed by + the HA. + + This means the authentication option is of limited + applicability in environments where the HA can receive + reverse-tunneled packets with spoofed source IP addresses + and/or modified contents. + + (4) As described in [RFC4285], the authentication option assumes + that the MN-AAA shared key and security association are created + by out-of-band mechanisms. These mechanisms are specific to + specific deployment environments. IKEv2, on the other hand, + supports a wide range of authentication mechanisms, such as + certificates and Extensible Authentication Protocol (EAP) + methods, and is independent of the access network technology + being used. However, it would be possible to specify a similar + authentication and key management protocol for the + authentication option in the future. + + (5) Sending the long-term user identity (NAI) in the clear raises + privacy concerns. These concerns are addressed by access + network and network domain security mechanisms in 3GPP2 + networks, but do limit the applicability in networks where + sniffing other users' traffic is possible. + + + +Patil & Dommety Informational [Page 15] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + + (6) RFC 4285 does not specify a mechanism for creating the MN-HA + shared key and SA from the MN-AAA SA (unlike similar Mobile IPv4 + mechanisms defined in [RFC3957]), and thus relies on deployment- + specific mechanisms not standardized in the IETF. + + (7) The authentication option does not support negotiation of + cryptographic algorithms. + + (8) The replay protection mechanisms in [RFC4285] rely on + timestamps, and thus require reasonably synchronized clocks (by + default, +/- 7 seconds). This assumes the MN implements, and is + configured to use, some mechanism for synchronizing its clock. + +8. Security Considerations + + When MIPv6 signaling messages use IPsec with ESP encapsulation, they + are accorded privacy on the links over which the messages traverse. + When MIPv6 signaling messages are secured using the authentication + protocol, such ciphering capability will have to be enabled by the + underlying link layers. It should be noted that the MIPv6 signaling + messages are susceptible to snooping/sniffing when the authentication + protocol [RFC4285] is used. Route optimization messages need to be + secured between the MN and HA and this is not possible with the + authentication protocol. However, route optimization is not + supported in the current specification of the authentication protocol + in [RFC4285]. + + Security issues with RFC 4285 are specifically: + + 1. Key length. This is being addressed in [AUTH-PRO]. + + 2. The keys used for securing the signaling between the MN and HA + are derived from a security association that exists between the + MN and AAA. The MIPv6 keys, which are bootstrapped from the MN- + AAA SA, are transient. Limiting the lifetime of the keys to + shorter periods should be recommended. + + 3. Location privacy is an issue in the absence of lower-layer + security in the case of shared links. + +9. Conclusion + + Mobile IPv6 was published as a Standards Track RFC [RFC3775] in 2004. + Deployment of this protocol on a large scale is in the interest of + the IETF and the working group, as well as that of many people who + have worked on this. A rigid model for deployment will cause the + protocol to be limited to an academic exercise only. It is extremely + critical that the working group consider the needs of the industry + + + +Patil & Dommety Informational [Page 16] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + + and the deployment scenarios, and address them accordingly. This + document captures the reasoning behind the need for the + authentication protocol, which has been published as RFC 4285. RFC + 4877 has alleviated some of the issues that have been of primary + concern and were motivators for the authentication protocol. + However, the IETF should consider the architectures of networks such + as 3GPP2 and WiMAX and their security models, and enable deployment + of Mobile IPv6 without requiring IPsec. + +10. Acknowledgements + + The authors would like to thank Alpesh Patel, AC Mahendra, Kuntal + Chowdhury, and Vijay Devarapalli for their input and discussions. + Jari Arkko has reviewed the ID and provided valuable feedback. + Thomas Narten has provided valuable reviews and made significant + improvements to the text in this document. In his role as the IETF + liaison to 3GPP2, Thomas Narten has ensured that the IETF understands + the 3GPP2 requirements. Pasi Eronen, in his role as the Security AD, + has reviewed and helped improve the document. Vidya Narayanan has + reviewed the document from a security directorate perspective and + provided input that has been incorporated. + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels", BCP 14, + RFC 2119, March 1997. + + [RFC3736] Droms, R., "Stateless Dynamic Host + Configuration Protocol (DHCP) Service for + IPv6", RFC 3736, April 2004. + + [RFC3775] Johnson, D., Perkins, C., and J. Arkko, + "Mobility Support in IPv6", RFC 3775, + June 2004. + + [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, + "Using IPsec to Protect Mobile IPv6 Signaling + Between Mobile Nodes and Home Agents", + RFC 3776, June 2004. + + [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., + and K. Chowdhury, "Mobile Node Identifier + Option for Mobile IPv6 (MIPv6)", RFC 4283, + November 2005. + + + + +Patil & Dommety Informational [Page 17] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + +11.2. Informative References + + [3GPP2 X.S0011-002-D] 3GPP2 X.S0011-002-D, "cdma2000 Wireless IP + Network Standard: Simple IP and Mobile IP + Access Services", http://www.3gpp2.org/ + Public_html/specs/ + X.S0011-002-D_v1.0_060301.pdf, February 2006. + + [AUTH-PRO] Patel, A., Leung, K., Khalil, M., Akhtar, H., + and K. Chowdhury, "Authentication Protocol for + Mobile IPv6", Work in Progress, July 2008. + + [BOOT] Chowdhury, K. and A. Yegin, "MIP6- + Bootstrapping for the Integrated Scenario", + Work in Progress, April 2008. + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. + Soliman, "Neighbor Discovery for IP version 6 + (IPv6)", RFC 4861, September 2007. + + [RFC3957] Perkins, C. and P. Calhoun, "Authentication, + Authorization, and Accounting (AAA) + Registration Keys for Mobile IPv4", RFC 3957, + March 2005. + + [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., + and K. Chowdhury, "Authentication Protocol for + Mobile IPv6", RFC 4285, January 2006. + + [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 + Operation with IKEv2 and the Revised IPsec + Architecture", RFC 4877, April 2007. + + [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, + "Mobile IPv6 Bootstrapping in Split Scenario", + RFC 5026, October 2007. + + [WiMAX-NWG] "WiMAX Network Architecture - WiMAX End-to-End + Network Systems Architecture", May 2008, <http + ://www.wimaxforum.org/documents/documents/ + WiMAX_Forum_Network_Architecture_Stage_2- + 3_Rel_1v1.2.zip>. + + + + + + + + + +Patil & Dommety Informational [Page 18] + +RFC 5419 Why Authdata Option for MIPv6 January 2009 + + +Authors' Addresses + + Basavaraj Patil + Nokia + 6021 Connection Drive + Irving, TX 75039 + USA + + EMail: basavaraj.patil@nokia.com + + + Gopal Dommety + Cisco + 170 West Tasman Drive + San Jose, CA 95134 + USA + + EMail: gdommety@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Patil & Dommety Informational [Page 19] + |