Network Working Group A. Patel Internet-Draft K. Leung Expires:
December 31, 2004May 2, 2005 Cisco Systems M. Khalil H. Akhtar K. Chowdhury Nortel Networks July 2,November 2004 Authentication Protocol for Mobile IPv6 draft-ietf-mip6-auth-protocol-00.txtdraft-ietf-mip6-auth-protocol-01.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 31, 2004.May 2, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document defines new mobility options to enable authentication between mobility entities. These options can be used in addition to or in lieu ofIPsec to authenticate mobility messagesis specified as defined inthe basesole means of securing all signaling messages between the Mobile Node and Home agent for Mobile IPv6. A flexible model for security between the mobile node and home agent is required from the perspective of deployment of the Mobile IPv6 specification.protocol. One instance of such deployment need comes from networks that are built on 3GPP2 standards. This document proposes an alternate method for securing the signaling messages that are responsible for performing Registration of a mobile node at a home agent. Table of Contents 1. Motivation .Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. General Terms .Operational flow . . . . . . . . . . . . . . . . . . . . . . . 6 5. Operational flowMobility message authentication option . . . . . . . . . . . . 7 5.1 MN-HA authentication mobility option . . . . . . . . . . . 7 6. Mobility message authentication option8 5.1.1 Processing Considerations . . . . . . . . . . . . 8 6.1 MN-HA. . 9 5.2 MN-AAA authentication mobility option . . . . . . . . . . .9 6.2 MN-AAA authentication mobility option . .5.2.1 Processing Considerations . . . . . . . . 9 6.2.1 Processing considerations. . . . . . 10 5.3 Authentication Failure Detection at the MN . . . . . . . . 10 7.6. Mobility message identification option . . . . . . . . . . . . 11 7.1 Processing considerations6.1 Timestamp option . . . . . . . . . . . . . . . . . . . . . 12 7.1.1 Home Agent7. Security Considerations . . . . . . . . . . . . . . 12 7.1.2 Mobile Node Considerations. . . . . 14 8. IANA Considerations . . . . . . . . . 12 7.1.3 AAA server Considerations. . . . . . . . . . . . 15 9. Acknowledgements . . . 13 8. Security Considerations. . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations. 16 10. Normative References . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 11. Normative ReferencesA. Authentication using CHAP . . . . . . . . . . . . . . . . . . 18 A.1 Processing considerations . . . 16 Authors' Addresses. . . . . . . . . . . . . 18 A.2 Mapping BU to Radius Attributes . . . . . . . . . 16. . . . 18 A.3 Processing of Radius response . . . . . . . . . . . . . . 18 B. Rationale for message identification option . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . 1821 1. MotivationIntroduction The base specification ofMobile IPv6 specification [RFC3775] mandates IPsec support between MNspecifies the signaling messages, Binding Update (BU) and HA for authentication. Also, return routability messages passing viaBinding Acknowledegment (BA), between the HA (HoT/HoTi)Mobile node and mobile prefix discovery messages mustHome agent to be protected using IPsec. While IPsec (ESP) may offer strong protection (depending onsecured by the algorithms used), use ofIPsec may not be required/feasible in all cases whereSA that is established between these two entities. This security model for Mobile IPv6 may be used. For small handheld devices,does not fit in very well for deployment scenarios which: 1. rely on the use of IPsec may be too taxing on battery and processor performance. Also depending ona AAA infrastructure for authenticating the modelsubscriber 2. require dynamic assignment of home agent deployment (HA deployed by enterprise/service provider), MN may have to VPN back into the enterprise (which may impose dual IPsec requirement on MN). Moreover, IPsec/IKE based Mobile IPv6 over public wireless carrier's networks may pose serious capacityand scalability challenge. The multiple round trips to perform ISAKMP/IKE to establish IPsec SA may be too taxinghome addresses 3. have constraints on the wireless link, not to mention increase in setup latency during initial access and during handoffs. The usenumber of manual IPsec SAmessages involved in these large public network deployments suffer from scalability issue and involve provisioning nightmare. Also, having an authentication mechanism tied to the Mobile's home IP address does not permit the mobility entity to derive or acquire a dynamic home address based on the configured prefix. If the MN's home address is dynamically configured based onsetting up a fixed prefix or acquired during network access authentication (PPP, 802.1x etc.), IPsec will most likelysecurity association using protocols like IKEv1 4. include mobile nodes that do not work as the IPsec SAs are tied to the address.support IKEv1 The mechanism described in this draftconclusion drawn thereby is not tied with mobility entities home IP address and thereforethe need for a solution that does not mandate SA relationship withnecessarily require an IP address. Another important motivationIPsec SA for this proposed mechanism is to allowsecuring the MN to registersignaling messages that deal with the Registration process of a Home Agent onmobile node with a dynamically discovered Home Link.home agent. This sort of Dynamic Home Link assignments will allow the operators to leverage the true benefit of dynamic Home Agent assignment. For example the operator may assigndocument proposes a Home Link or Home Agentsolution for securing the user that is closest to the subnet of attachment ofBinding update and Binding acknowledgment messages between the user. There may be various other reasons for opportunisticMobile node and Home Agent assignment. The mechanisms described in the draft allows the MNagent using an authentication option which is included in these messages. Such a mechanism enables IPv6 mobility in hosts without having to registerestablish an IPsec SA with any Home Agent in theits home network as long as the MN user shares security associationagent. A mobile node can implement Mobile IPv6 without having to integrate it with an entitythe IPsec module, in which case the home networkBinding update and Binding Acknowldegement messages (between MN-HA) are secured with the authentication option. It should be noted that it does not imply that the availability of such asa AAA server.solution deprecates the use of IPsec for securing Mobile IPv6 signaling between MNs and HAs. Home agents however have to implement and support registrations from mobile nodes that are secured via IPsec as well as with the authentication option. 2. Overview This document presents a lightweight mechanism to authenticate the MN at the HA or at the Home AAA based on a shared security association between the MN and the respective authenticating entity. This document introduces new mobility options to aid in authentication of the MN to the HA or AAA server. The confidentiality protection of theReturn Routability messages and authentication/integrity protection of Mobile Prefix Discovery (MPD) and Return Routability (Home KeyGen token) messagesis outside the scope of this document. 3. Terminology The keywords "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. 4. General Terms MN Mobile Node HA Home Agent SA Security Association IPsec IP Security protocol ESP Encapsulating security protocol BU Binding Update BA Binding Acknowledgement SPI Security Parameter Index MH Mobility Header HAAA Home Authentication Authorization Accounting server CHAP CHallenge Authentication Protocol HoA Home Address AVP Attribute Value Pair AAA Authentication Authorization Accounting NAI Network Address Identifier 5.Operational flow MN HA/HAAA | BU to HA | (a) |---------------------------------------------------->||----------------------------------------------------->| | (HoA option, NAI[optional],MN-ID option [optional], | | Message ID option, auth option)option [optional], authentication option)| | | | | | HA/HAAA authenticates MN | | | | | BA to MN | (b) |<----------------------------------------------------||<-----------------------------------------------------| | (HoA(RH-2 option, NAI[optional],MN-ID option [optional], | | Message ID option,option [optional], auth option) | | | | |MN mayMAY use NAI option as defined in [NAI][MN_Ident] to identify itself to the HAwhile authenticating with the HA. TheHA or AAA infrastructure. MN SHOULDMAY use NAIMessage Identifier option [NAI] while authenticating with the AAA infrastructure. 6.as defined in Section 6 for replay protection. 5. Mobility message authentication option This section defines the message authentication mobility option that may be used to secure Binding Update and Binding Acknowledgement messages. This extension can be used along with IPsec or preferably as an alternate mechanism to authenticate binding updateBinding Update and binding acknowledgementBinding Acknowledgement messages in absence of IPsec. This document also defines subtype numbers, which identify the mode of authentication and the peer entity to authenticate the message. Two subtype numbers are specified in this document. It is expected that other subtypes will be defined by other documents in the future. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option LengthOnly one instance of an authentication option of a particular subtype can be present in the message. One message may contain multiple instances of authentication options with different subtype values. When a Binding Update or Binding Acknowledgement is received without an authentication option and the entity receiving it is configured to use authentication option or has the security association for authentication option, the entity should silently discard the received message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Option Type | SubtypeOption Length | SPISubtype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type: AUTH-OPTION-TYPE to be defined by IANA. An 8-bit identifier of the type mobility option. Option Length: 8-bit unsigned integer, representing the length in octets of the sub-type, SPI and authenticator, not including the Option TypeSub-type, Security Parameter Index (SPI) and Option LengthAuthenticator fields. Subtype: A number assigned to identify the entity and/or mechanism to be used to authenticate the message. SPI: Used to identify the particular security association to use to authenticate the message. Authenticator: This field has the information to authenticate the relevant mobility entity. This protects the message beginning at the Mobility Header upto and including the SPI field. Alignment requirements : MUST be aligned on an 8-octet boundary. 6.1The alignment requirement for this option is 4n + 1 octets. 5.1 MN-HA authentication mobility option The format of the MN-HA authentication mobility option is as defined in section 6.Section 5. This option uses the subtype value of 1. The MN-HA authentication mobility option is used to authenticate the binding updateBinding Update and binding acknowledgementBinding Acknowledgement messages based on the shared security association between the MN and the HA. This must be the last option in a message with mobility header.header if it is the only authentication option in the message. It must occur before the MN-AAA authentication option if both options are present in the message. The authenticator is calculated on the message starting from the mobility header till (including) the SPI value of this option. Authenticator = First (96,HMAC_SHA1(MN-HA Shared key, Mobility Data)) Mobility Data = care-of address | home address | MHMobility Header(MH) Data MH Data is the content of the Mobility Header till (including) the SPI field of this extension. The first 96 bits from the MAC result are used as the Authenticator field. 126.96.36.199 Processing Considerations MN MUST include this option in a BU if it shares a security association with the HA. HA MUST include this option in the BA if IPsec is not used and it has a security association with the MN. MN or HA receiving this option MUST verify the authenticator in the option. If authentication fails, HA MUST discard the BU and send BA with Status Code MIPV6-AUTH-FAIL, if the HA has a SA with the MN. 5.2 MN-AAA authentication mobility option The format of the MN-AAA authentication mobility option is as defined in section 6.Section 5. This option uses the subtype value of 2. The MN-AAA authentication mobility option is used to authenticate the binding update and binding acknowledgement messagesBinding Update message based on the shared security association between MN and HAAA. This must be the last option in a message with mobility header. The authenticatorHome Authentication, Authorization and Accounting (AAA) server. It is calculated onnot used in Binding Acknowledgement message. This must be the last option in a message starting from thewith mobility header tillheader. If both Mobile-Home and Mobile-AAA authentication mobility options are present, the SPI value of this option.Mobile-Home Authentication Extension MUST appear prior to the Mobile-AAA Authentication extension. The corresponding response MUST include the Mobile-Home Authentication Extension, and MUST NOT include the Mobile-AAA Authentication Extension. The MN SHOULDMAY use NAI option [NAI][MN_Ident] to enable the Home Agent to make use of available AAA infrastructure which requires NAI. The MN MUST use either CHAP_SPI or HMAC_CHAP_SPI as defined in [3012bis] to indicate CHAP style authentication.authenticator is calculated on the message starting from the mobility header till (including) the SPI value of this option. The authenticator shall be calculated as follows: Authenticator = First (96, HMAC_SHA1 (MN-AAAhash_fn(MN-AAA Shared key, MAC_Mobility Data))).Data) hash_fn() is decided by the value of SPI field in the authentication option. The SPI field in the MN-AAA authentication option also defines how the mobility options in BU are mapped to AAA attributes for authentication. SPI = CHAP_SPI: hash_fn() is MD5. When CHAP_SPI is used, the BU is authenticated via AAA using Challenge Handshake Authentication Protocol (CHAP) authentication. Specifics of how CHAP authentication is done using RADIUS ([RFC2865]) is described in Appendix A. MAC_Mobility Data = MD5 (care-ofMD5(care-of address | home address | MH Data). SPI = HMAC_CHAP_SPI: MAC_Mobility Data = HMAC_MD5 (care-of address | home address |Data) MH Data). 6.2.1Data is the content of the Mobility Header till (including) the SPI field of this extension. 5.2.1 Processing considerationsConsiderations The MN-AAA authentication mobility option MUST be verified by the AAA infrastructure that has the shared secret with the MN. The HA relays the authenticating information to the HAAA.home AAA. The HA relies on the HAAAhome AAA to admit or reject the home registration requestBinding Update from the MN. 188.8.131.52.2.1.1 Home Agent Considerations Upon receiving a BU from the MNMN, the HA SHALL extract the MN-AAA authenticator and the SPI from the MN-AAA authentication mobility option and extract the NAI from the NAI option [NAI].[MN_Ident]. The HA SHALL include the extracted MN-AAA authenticator, SPI and the NAI in AAA specific AVPsAttribute-Value Pairs (AVPs) while initiating the authentication procedure via AAA infrastructure. 7.Specifics of how authentication is done using RADIUS ([RFC2865]) when CHAP_SPI is used, are described in Appendix A. 5.3 Authentication Failure Detection at the MN In case of authentication failure, the HA MUST send a Binding Acknowledgement with error code MIPV6-AUTH-FAIL to the MN, if an SA to be used between MN and HA for authentication exists. This MAY need administrative intervention to resolve the cause of the authentication failure. Upon receiving a Binding Acknowledgement with error code MIPV6-AUTH-FAIL, the MN SHOULD stop sending new Binding Updates to the responding HA. 6. Mobility message identification option The Mobility message identification option isMAY be used to prevent replay protection. The Identification field carries timestamp for replay protection. Thisin a Binding Update/Binding Acknowledgement messages when authenticated using the mobility authentication option can be usedas described in binding update and binding acknowledgement messages.Section 5. The default method for this purposeIdentification option is used to let the timestamp method; some other methods may be utilized as well. If the MN uses 'timestamp' ashome agent verify that a measure against replay protection, it SHOULD insert the current time of day. When the destination node receives theBinding Update, it will make sure that the 'timestamp' (as includedUpdate has been freshly generated by the sender)mobile node, not replayed by an attacker from some previous Binding Update. The identification option when included is close enough to its own time of the day. A default value of 500 milliseconds MAY beused as a reasonable offset (the time difference between the sender andby the receiver).MN for matching BA with BU. The low-order 32 bits ofsubtype field in the identification option represents fractional seconds,specifies the reststyle of the bits SHOULD be generated from a good sourcereplay protection used. This document specifies timestamps as one style of randomness. For the identification field to be valid, the 'timestamp' containedreplay protection, as described in theSection 6.1. The Identification fieldin a new Binding Update MUST not be close enough (as determined by the system implementers) and greater thanthe HA's and/or HAAA's time of day clock.same as in an immediately preceding Binding Update. The style of replay protection in effect between a mobile node and the HA and/or the HAAAis part of the mobilemobility security association. A mobile node and the HA and/or the HAAAMUST agree on which method of replay protection will be used. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type: IDENT-OPTION-TYPE to be defined by IANA. An 8-bit identifier ofIf the type mobility option.policy at HA mandates replay protection using this option (as opposed to the sequence number in Mobility Header in Binding Update) and the Binding Update from MN does not include this option, HA discards the BU and sets the Status Code in BA to MIPV6-MESG-ID-REQD. When mobility message identification option is used along with authentication option, the MN SHOULD set the Sequence Number in the mobility header in Binding Update to 0 and SHOULD ignore the Sequence Number in Mobility Header in BA. Appendix B provides details regarding why message identification option MAY be used when using the authentication option. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | Subtype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type: MESG-ID-OPTION-TYPE to be defined by IANA. An 8-bit identifier of the type mobility option. Option Length: 8-bit unsigned integer, representing the length in octets of the Subtype and Identification field. Subtype: 8-bit unsigned integer indicating the style of replay protection in use. Identification: The Identification field carries timestampSubtype specific data for replay protection. Alignment requirements : MUST be aligned on an 8-octet boundary. 7.1 Processing considerations The Identification field is used to let the HA and/or the HAAA verify that a Binding Update message has been generated recently by the MN, and it isThis option does not replayed by an attacker from some older registrations. 7.1.1 Home Agent Considerations The HA processes thishave any specific alignment requirements. 6.1 Timestamp option only when MN-HA authenticationThe format of the timestamp mobility option is usedas defined in Section 6. This option uses the BU. In this case: After successful authenticationsubtype value of Binding Update, the Home Agent must verify that the1. The Identification field falls within thecarries timestamp for replay protection window. If Identification field is not within this window but the authenticationprotection. The basic principle of timestamp replay protection is that the BU succeeds, HA MUST sendnode generating a Binding Acknowledgement with error code "TBD by IANA" MIPV6-ID-MISMATCH. In this case, HA must includemessage inserts the correct identification field incurrent time of day, and the Binding Acknowledgement message. MN-HA Timestamp: Ifnode receiving the message checks that this timestamp based replay checkis successful and the authentication succeeds,sufficiently close to its own time of day. Unless specified differently in the HA MUST includesecurity association between the received Identificationnodes, a default value in the corresponding fieldof 7 seconds MAY be used to limit the Mobility message identification option in the BA. 7.1.2 Mobile Node Considerations The MN MUST processtime difference. This value SHOULD be greater than 3 seconds. Obviously the Mobility message identification option. MN-HA Timestamp and MN-AAA Timestamp:two nodes must have adequately synchronized time-of-day clocks. The MNmobile node MUST set the Identification field to a 64-bit value in the Mobility message identification option informatted as specified by the BU message according to its own clock. IfNetwork Time Protocol [RFC1305]. The low-order 32 bits of the MN receivesNTP format represent fractional seconds, and those bits which are not available from a Binding Acknowledgement withtime source SHOULD be generated from a good source of randomness. Note, however, that when using timestamps, the code MIPV6-ID-MISMATCH, MN must adjust its timestamp and send subsequent64-bit Identification used in a Binding Update usingfrom the updated value. 7.1.3 AAA server Considerations The HAAA processes this option only when MN-AAA authentication mobility option ismobile node MUST be greater than that used in the BU. In this case:any previous Binding Update. After successful authentication of MN's credentials contained inBinding Update (either locally at the AVPs,HA or when a success indication is received from the HomeAAA serverserver), the home agent MUST verify thatcheck the Identification field falls withinfor validity. In order to be valid, the timestamp contained in the replay protection window. IfIdentification field is not within this window, HAAAMUST rejectbe close enough to the authenticationhome agent's time of day clock and authorization request. Upon receivingthe reject messagetimestamp MUST be greater than all previously accepted timestamps for the requesting mobile node. If the timestamp is valid, the home agent copies the entire Identification field into the Identification field in the BA it returns to the mobile node. If the timestamp is not valid, the home agent copies only the low-order 32 bits into the BA, and supplies the high-order 32 bits from HAAA server,its own time of day. If the timestamp field is not valid but the authentication of the BU succeeds, HA MUST send a Binding Acknowledgement with error code "TBD by IANA"MIPV6-ID-MISMATCH. In this case,HA must include the correct identification field indoes not create a binding cache entry if the Mobility message identification option intimestamp check fails. If the MN receives a Binding Acknowledgement message. MN-AAA Timestamp: If timestamp based replay check is successful andwith the code MIPV6-ID-MISMATCH, the MN MUST authenticate the BA by processing the MN-HA authentication mobility option. If authentication and authorizationsucceeds, the HAAAMN MUST adjust its timestamp and send subsequent Binding Update using the updated value. Upon receiving a BA that does not include any updatedcontain the MIPV6-ID-MISMATCH error code, the MN MUST compare the Identification value in the accept message. In this case, the HA copiesBA to the Identification value from the BU intoit sent in the corresponding fieldBU. If the values match, the MN proceeds to process the MN-HA authenticator in the BA. If the replay check fails but authentication succeeds, in the reject messagevalues do not match, the HAAA MUST includeMN silently discards the latest timestamp according to it's own clock. 8.BA. 7. Security Considerations This document proposes new authentication options to authenticate the control message between MN, HA and/or HAAAhome AAA (as an alternative to IPsec). The new options provide for authentication of Binding Update and Binding Acknowledgement messages 9. IANA Considerations The option types AUTH-OPTION-TYPE, IDENT-OPTION-TYPE, as defined in section 6 and 7 respectively are new mobility options.messages. The MIPV6-ID-MISMATCH error code also needs to be defined. IANA should record values for these new mobilityMN-AAA authentication options and the new error code. 10.provides for authentication with AAA infrastructure. It can be used to generate a per session key between MN and HA for subsequent authentication of BU/BA between MN and HA via the MN-HA authentication option. This memo also introduces an optional replay protection mechanism Section 6, to prevent replay attacks. The sequence number field in the Binding Update is not used if this mechanism is used. This memo defines the timestamp option to be used for message identification. 8. IANA Considerations IANA services are required for this document. The values for new mobility options and error codes must be assigned from the Mobile IPv6 [RFC3775] numbering space. The values for Mobility Option types AUTH-OPTION-TYPE and MESG-ID-OPTION-TYPE, as defined in Section 5 and Section 6 need to be assigned. The suggested values are 8 for the AUTH-OPTION-TYPE and 9 for the MESG-ID-OPTION-TYPE Mobility Option. The values for Status Codes MIPV6-ID-MISMATCH, MIPv6-AUTH-FAIL and MIPV6-MESG-ID-REQD as defined in Section 6.1, Section 6 and Section 5.3 also need to be assigned. The suggested values are 144 for MIPV6-ID-MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for MIPV6-AUTH-FAIL. IANA should record values for these new Mobility Options and the new Status Codes. A new section for enumerating algorithms identified by specific SPIs within the range 0-255 is to be added to http://www.isi.edu/in-notes/iana/assignments/mobility-parameters The value 0 should not be assigned. The value 2 is suggested for CHAP_SPI as defined in section Section 5.2. The value 3 is suggested for HMAC_SHA1. The value 5 is reserved for use by 3GPP2. 9. Acknowledgements TBD. 11The authors would like to thank Basavaraj Patil, Charlie Perkins and Vijay Devarapalli for their suggestions and comments on the draft. The authors would like to acknowledge the fact that a similar authentication method was considered in base protocol [RFC3775] at one time. 10 Normative References [3012bis] Perkins et. al., C., "Mobile IPv4 Challenge/Response Extensions (revised)", draft-ietf-mip4-rfc3012bis-01 (work in progress), April 2004. [NAI][MN_Ident] Patel et. al., A., "Network Access"MN Identifier Option for Mobile IPv6", draft-ietf-mipv6-nai-option-00.txtdraft-ietf-mip6-mn-ident-option-01.txt (work in progress), FebruaryDecember 2004. [RFC2486] Aboba, B.[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [RFC2865] Rigney, C., Willens, S., Rubens, A. and M. Beadles, "The Network Access Identifier",W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 2486, January 1999.3344, August 2002. [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. Authors' Addresses Alpesh Patel Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-853-9580 EMail: firstname.lastname@example.org Kent Leung Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 US Phone: +1 408-526-5030 EMail: email@example.com Mohamed Khalil Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US Phone: +1 972-685-0574 EMail: firstname.lastname@example.org Haseeb Akhtar Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US Phone: +1 972-684-4732 EMail: email@example.com Kuntal Chowdhury Nortel Networks 2221 Lakeside Blvd. Richardson, TX 75082 US Phone: +1 972 685 7788 EMail: firstname.lastname@example.org Appendix A. Authentication using CHAP A.1 Processing considerations The HA acts as a Radius client in accordance with ([RFC2865]) when MN-AAA mobility option is received in a BU. On receipt of the BU from the MN, and if SPI in the MN-AAA mobility option is set to CHAP-SPI, the HA shall create a Radius Access-Request message to authenticate the BU. If the SPI in the MN-AAA Authentication Extension is set to CHAP-SPI, the HA shall use MD5 when computing the CHAP challenge. A.2 Mapping BU to Radius Attributes The home agent maps the mobility options to the Radius attributes as follows: User-Name(1): obtained from NAI mobility option in BU. Chap-Password(3): CHAP Ident field: High-order byte of the identification field in the Identification mobility option String field: Authenticator field from the MN-AAA Authentication option Chap-Challenge(60): MD5(care-of address | home address | Mobility header till (including) SPI field in MN-AAA mobility option), followed by the Identification field in the identification mobility option. NAS-IP-Address: NAS-IPv6-Address: Address of the HA. HA uses the v4/v6 address or both if available. A.3 Processing of Radius response If the authentication succeeds, the Home Radius server sends a Radius Access-Accept message to the HA. HA proceeds to process the BU message and sends a BA with appropriate code. If the authentication fails, the Home Radius server sends a Radius Access-Reject message to the HA. If Access-Reject is received from AAA, HA drops the BU. HA does not send a BA to the MN in response to this BU. An existing binding cache entry from a previous successful Binding Update MUST not be modified due to this authentication failure. Appendix B. Rationale for message identification option Mobile IPv6 [RFC3775] defines a Sequence Number in the mobility header to prevent replay attacks. There are two aspects that stand out in regards to using the Sequence Number to prevent replay attacks. Firstly, the specification states that HA should accept a BU with a Sequence Number greater than the Sequence Number from previous Binding Update. This implicitly assumes that the HA has some information regarding the Sequence Number from previous BU (even when the binding cache entry is not present). Secondly, the specification states that if the HA has no binding cache entry for the indicated home address, it MUST accept any Sequence Number value in a received Binding Update from this mobile node. With the mechanism defined in this draft, it is possible for the MN to register with a different home agent during each mobility session. Thus, it is unreasonable to expect each HA in the network to maintain state about the MN. Also, if the HA does not cache information regarding sequence number, as per the second point above, a replayed BU can cause a Home Agent to create a binding cache entry for the MN. Thus, when authentication option is used, Sequence Number does not provide protection against replay attack. One solution to this problem would be for the HA to reject the first BU and assign a starting sequence number for the session and force the MN to send a fresh BU with the suggested sequence number. While this would work in most cases, it would require an additional round trip and this extra signalling and latency is not acceptable in certain deployments (3GPP2). Also, this rejection and using sequence number as a nonce in rejection is a new behavior that is not specified in [RFC3775]. Thus, this specification uses the message identification option to prevent replay attacks. Specifically, timestamps are used for message identification to prevent replay attacks as described in Section 6.1. It is important to note that as per Mobile IPv6 [RFC3775] this problem with sequence number exists. Since the base specification mandates the use of IPsec (and naturally that goes with IKE in most cases), the real replay protection is provided by IPsec/IKE. In case of BU/BA between MN and CN, the liveness proof is provided by the use of nonces which the CN generates. Intellectual Property Statement 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 email@example.com. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.