idnits 2.17.1 draft-ietf-mip6-auth-protocol-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 776. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 782. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 236: '... The Mobile Node MUST use the Mobile N...' RFC 2119 keyword, line 243: '... Mobile Node MAY use Message Identif...' RFC 2119 keyword, line 271: '...on (else, the HA MUST discard the mess...' RFC 2119 keyword, line 341: '...lue of 7 seconds SHOULD be used. This...' RFC 2119 keyword, line 342: '... SHOULD be greater than 3 seconds....' (29 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 19, 2005) is 6787 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '0-4294967296' is mentioned on line 334, but not defined == Missing Reference: '0-255' is mentioned on line 334, but not defined ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Patel 2 Internet-Draft K. Leung 3 Expires: March 23, 2006 Cisco Systems 4 M. Khalil 5 H. Akhtar 6 Nortel Networks 7 K. Chowdhury 8 Starent Networks 9 September 19, 2005 11 Authentication Protocol for Mobile IPv6 12 draft-ietf-mip6-auth-protocol-07.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on March 23, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 IPsec is specified as the means of securing signaling messages 46 between the Mobile Node and Home agent for Mobile IPv6 (MIPv6). 47 MIPv6 signalling messages that are secured include the Binding 48 Updates and Acknowledgement messages used for managing the bindings 49 between a Mobile Node and its Home Agent. This document proposes an 50 alternate method for securing MIPv6 signaling messages between a 51 Mobile Nodes and Home Agents. The alternate method defined here 52 conists of a MIPv6-specific authentication option that can be added 53 to MIPv6 signalling messages. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 3 59 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Operational flow . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. Mobility message authentication option . . . . . . . . . . . . 8 64 5.1. MN-HA authentication mobility option . . . . . . . . . . . 10 65 5.1.1. Processing Considerations . . . . . . . . . . . . . . 10 66 5.2. MN-AAA authentication mobility option . . . . . . . . . . 11 67 5.2.1. Processing Considerations . . . . . . . . . . . . . . 12 68 5.3. Authentication Failure Detection at the Mobile Node . . . 12 69 6. Mobility message replay protection option . . . . . . . . . . 13 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 75 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 76 Appendix A. Rationale for mobility message replay protection 77 option . . . . . . . . . . . . . . . . . . . . . . . 20 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 79 Intellectual Property and Copyright Statements . . . . . . . . . . 23 81 1. Introduction 83 The base Mobile IPv6 specification [RFC3775] specifies the signaling 84 messages, Binding Update (BU) and Binding Acknowledgement (BA), 85 between the Mobile Node and Home agent to be secured by the IPsec 86 Security Associations (IPsec SAs) that are established between these 87 two entities. 89 This document proposes a solution for securing the Binding Update and 90 Binding Acknowledgment messages between the Mobile Node and Home 91 agent using an authentication option which is included in these 92 messages. Such a mechanism enables IPv6 mobility in a host without 93 having to establish an IPsec SA with its Home Agent. A Mobile Node 94 can implement Mobile IPv6 without having to integrate it with the 95 IPsec module, in which case the Binding Update and Binding 96 Acknowldegement messages (between MN-HA) are secured with the 97 authentication option. 99 The authentication mechanism proposed here is similar to the 100 authentication mechanism used in Mobile IPv4 [RFC3344]. 102 1.1. Applicability Statement 104 The authentication option specified in Section 5 is applicable in 105 certain types of networks that have the following characteristics: 107 - Networks in which the authentication of the MN for network access 108 is done by an authentication server in the home network via the home 109 agent. The security association is established by the network 110 operator (provisioning methods) between the MN and a backend 111 authentication server (eg. AAA home server). MIP6 as per RFC3775/ 112 3776 relies on the IPsec SA between the MN and an HA. In cases where 113 the assignment of the HA is dynamic and the only static or long term 114 SA is between the MN and a backend authentication server, the 115 authentication option is desirable. 117 - In certain deployment environments, the mobile node needs dynamic 118 assignment of a home agent and home address. The assignment of such 119 can be on a per session basis or on a per MN power-up basis. In such 120 scenarios, the MN relies on an identity such as an NAI [MN_Ident], 121 and a security association with a AAA server to obtain such 122 bootstrapping information. The security association is created via 123 an out-of-band mechanism or by non Mobile IPv6 signaling. The out- 124 of-band mechanism can be specific to the deployment environment of a 125 network operator. In cdma network deployments this information can 126 be obtained at the time of network access authentication via [3GPP2] 127 specific extensions to PPP or DHCPv6 on the access link and by AAA 128 extensions in the core. It should be noted that the out-of-band 129 mechanism if not within the scope of the authentication option 130 Section 5 and hence not described therein. 132 - Network deployments in which not all mobile nodes and home agents 133 have IKEv2 implementations and support for the integration of IKEv2 134 with backend AAA infrastructures. IKEv2 as a technology has yet to 135 reach maturity status and widespread implementations needed for 136 commercial deployments on a large scale. At the time of this writing 137 [IKEv2-REF] is yet to be published as an RFC. Hence from a practical 138 perspective that operators face, IKEv2 is not yet capable of 139 addressing the immediate need for MIP6 deployment. 141 - Networks which expressly rely on the backend AAA infrastructure as 142 the primary means for identifying and authentication/authorizing a 143 mobile user for MIP6 service. 145 - Networks in which the establishment of the security association 146 between the mobile node and the authentication server (AAA Home) is 147 established using an out-of-band mechanism and not by any key 148 exchange protocol. Such networks will also rely on out-of-band 149 mechanisms to renew the security association (between MN and AAA 150 Home) when needed. 152 - Networks which are bandwidth constrained (such as cellular wireless 153 networks) and there exists a strong desire to minimize the number of 154 signaling messages sent over such interfaces. MIP6 signaling which 155 relies on IKE as the primary means for setting up an SA between the 156 MN and HA requires more signaling messages compared with the use of 157 an authentication option carried in the BU/BAck messages. 159 One such example of networks that have such characteristics are cdma 160 networks as defined in [3GPP2]. 162 2. Overview 164 This document presents a lightweight mechanism to authenticate the 165 Mobile Node at the Home Agent or at the Authentication, Authorization 166 and Accounting (AAA) server in Home network (AAAH) based on a shared- 167 key based mobility security association between the Mobile Node and 168 the respective authenticating entity. This shared-key based mobility 169 security association (shared-key based mobility SA) may be statically 170 provisioned or dynamically created. The term "mobility security 171 association" referred to in this document is understood to be a 172 "shared-key based Mobile IPv6 authentication" security association. 174 This document introduces new mobility options to aid in 175 authentication of the Mobile Node to the Home Agent or AAAH server. 176 The confidentiality protection of Return Routability messages and 177 authentication/integrity protection of Mobile Prefix Discovery (MPD) 178 is not provided when these options are used for authentication of the 179 Mobile Node to the Home Agent. Thus, unless the network can 180 guarantee such protection (for instance, like in 3gpp2 networks), 181 Route Optimization and Mobile Prefix Discovery should not be used 182 when using the authentication option. 184 3. Terminology 186 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in RFC 2119. 190 3.1. General Terms 192 First (size, input) 194 Some formulas in this specification use a functional form "First 195 (size, input)" to indicate truncation of the "input" data so that 196 only the first "size" bits remain to be used. 198 Shared-key based Mobility Security Association 200 Security relation between Mobile Node and its Home Agent, used to 201 authenticate the Mobile Node for mobility service. The shared-key 202 based mobility security association between Mobile Node and Home 203 Agent consists of a mobility SPI, a shared-key, an authentication 204 algorithm and the replay protection mechanism in use. 206 Mobility SPI 208 A number in the range [0-4294967296] used to index into the 209 shared-key based mobility security associations. 211 4. Operational flow 213 The figure below describes the sequence of messages sent and received 214 between the MN and HA in the registration process. Binding Update 215 (BU) and Binding Acknowledgement (BA) messages are used in the 216 registration process. 218 MN HA/AAAH 219 | BU to HA | 220 (a) |----------------------------------------------------->| 221 | (including MN-ID option, | 222 | Message ID option [optional], authentication option)| 223 | | 224 | | 225 | HA/AAAH authenticates MN 226 | | 227 | | 228 | BA to MN | 229 (b) |<-----------------------------------------------------| 230 | (including MN-ID option, | 231 | Message ID option [optional], authentication option)| 232 | | 234 Figure 1: Home Registration with Authentication Protocol 236 The Mobile Node MUST use the Mobile Node Identifier Option, 237 specifically the MN-NAI mobility option as defined in [MN_Ident] to 238 identify itself while authenticating with the Home Agent. The mobile 239 node uses the Mobile Node Identifier option as defined in [MN_Ident] 240 to identify itself as may be required for use with some existing AAA 241 infrastructure designs. 243 Mobile Node MAY use Message Identifier option as defined in Section 6 244 for additional replay protection. 246 The authentication option described in Section 5 may be used by the 247 mobile node to transfer authentication data when the mobile node and 248 the home agent are utilizing a mobility SPI (a number in the range 249 [0-4294967296] used to index into the shared-key based mobility 250 security associations). to index between multiple mobility security 251 associations. 253 5. Mobility message authentication option 255 This section defines a message authentication mobility option that 256 may be used to secure Binding Update and Binding Acknowledgement 257 messages. This option can be used along with IPsec or preferably as 258 an alternate mechanism to authenticate Binding Update and Binding 259 Acknowledgement messages in the absence of IPsec. 261 This document also defines subtype numbers, which identify the mode 262 of authentication and the peer entity to authenticate the message. 263 Two subtype numbers are specified in this document. Other subtypes 264 may be defined for use in the future. 266 Only one instance of an authentication option of a particular subtype 267 can be present in the message. One message may contain multiple 268 instances of authentication options with different subtype values. 269 If both MN-HA and MN-AAA authentication options are present, MN-HA 270 authentication option must be present before the MN-AAA 271 authentication option (else, the HA MUST discard the message). 273 When a Binding Update or Binding Acknowledgement is received without 274 an authentication option and the entity receiving it is configured to 275 use authentication option or has the shared-key based mobility 276 security association for authentication option, the entity should 277 silently discard the received message. 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Option Type | Option Length | Subtype | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | Mobility SPI | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Authentication Data .... 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 Figure 2 291 Option Type: 293 AUTH-OPTION-TYPE to be defined by IANA. An 8-bit identifier of 294 the type mobility option. 296 Option Length: 298 8-bit unsigned integer, representing the length in octets of 299 the Sub-type, mobility Security Parameter Index (SPI) and 300 Authentication Data fields. 302 Subtype: 304 A number assigned to identify the entity and/or mechanism to be 305 used to authenticate the message. 307 Mobility SPI: 309 Mobility Security Parameter Index 311 Authentication Data: 313 This field has the information to authenticate the relevant 314 mobility entity. This protects the message beginning at the 315 Mobility Header upto and including the mobility SPI field. 317 Alignment requirements : 319 The alignment requirement for this option is 4n + 1. 321 5.1. MN-HA authentication mobility option 323 The format of the MN-HA authentication mobility option is as defined 324 in Figure 2. This option uses the subtype value of 1. The MN-HA 325 authentication mobility option is used to authenticate the Binding 326 Update and Binding Acknowledgement messages based on the shared-key 327 based security association between the Mobile Node and the Home 328 Agent. 330 The shared-key based mobility security association between Mobile 331 Node and Home Agent used within this specification consists of a 332 mobility SPI, a key, an authentication algorithm and the replay 333 protection mechanism in use. The mobility SPI is a number in range 334 [0-4294967296], where the range [0-255] is reserved. The key 335 consists of an arbitrary value and is 16 octets in length. The 336 authentication algorithm is HMAC_SHA1. The replay protection 337 mechanism may use the Sequence number as specified in [RFC3775] or 338 the option as defined in Section 6. If the Timestamp option is used 339 for replay protection as defined in Section 6, the mobility security 340 association includes a "close enough" field to account for clock 341 drift. A default value of 7 seconds SHOULD be used. This value 342 SHOULD be greater than 3 seconds. 344 This MUST be the last option in a message with mobility header if it 345 is the only authentication option in the message. 347 The authentication data is calculated on the message starting from 348 the mobility header upto and including the mobility SPI value of this 349 option. 351 Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility 352 Data)) 354 Mobility Data = care-of address | home address | Mobility Header(MH) 355 Data 357 MH Data is the content of the Mobility Header upto and including the 358 mobility SPI field of this option. The Checksum field in Mobility 359 Header MUST be set to 0 to calculate the Mobility Data. 361 The first 96 bits from the MAC result are used as the Authentication 362 Data field. 364 5.1.1. Processing Considerations 366 The assumption is that Mobile Node has a shared-key based security 367 association with the Home Agent. The Mobile Node MUST include this 368 option in a BU if it has a shared-key based mobility security 369 association with the Home Agent. The Home Agent MUST include this 370 option in the BA if it received this option in the corresponding BU 371 and Home Agent has a shared-key based mobility security association 372 with the Mobile Node. 374 The Mobile Node or Home Agent receiving this option MUST verify the 375 authentication data in the option. If authentication fails, the Home 376 Agent MUST send BA with Status Code MIPV6-AUTH-FAIL. If the Home 377 Agent does not have shared-key based mobility SA, Home Agent MUST 378 discard the BU. The Home Agent MAY log such events. 380 5.2. MN-AAA authentication mobility option 382 The format of the MN-AAA authentication mobility option is as defined 383 in Figure 2. This option uses the subtype value of 2. The MN-AAA 384 authentication mobility option is used to authenticate the Binding 385 Update message based on the shared mobility security association 386 between Mobile Node and AAA server in Home network (AAAH). It is not 387 used in Binding Acknowledgement messages. The corresponding Binding 388 Acknowledgement messages must be authenticated using the MN-HA 389 authentication option Section 5.1. 391 This must be the last option in a message with mobility header. The 392 corresponding response MUST include the Mobile-Home Authentication 393 option, and MUST NOT include the Mobile-AAA Authentication option. 395 The Mobile Node MAY use Mobile Node Identifier option [MN_Ident] to 396 enable the Home Agent to make use of available AAA infrastructure. 398 The authentication data is calculated on the message starting from 399 the mobility header upto and including the mobility SPI value of this 400 option. 402 The authentication data shall be calculated as follows: 404 Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data) 406 hash_fn() is decided by the value of mobility SPI field in the 407 authentication option. 409 SPI = HMAC_SHA1_SPI: 411 If mobility SPI has the well-known value HMAC_SHA1_SPI, then 412 hash_fn() is HMAC_SHA1. When HMAC_SHA1_SPI is used, the BU is 413 authenticated by AAA using HMAC_SHA1 authentication. In that case, 414 MAC_Mobility Data is calculated as follows: 416 MAC_Mobility Data = SHA1(care-of address | home address | MH Data) 417 MH Data is the content of the Mobility Header upto and including the 418 mobility SPI field of this option. 420 5.2.1. Processing Considerations 422 The use of the MN-AAA authentication option assumes that AAA entities 423 at the home site communicate with the HA via an authenticated 424 channel. Specifically, a BU with the MN-AAA authentication option is 425 authenticated via a home AAA server. The specific details of the 426 interaction between the HA and the AAA server is beyond the scope of 427 this document. 429 When the Home Agent receives a Binding Update with the Mobile-AAA 430 authentication option, the Binding Update is authenticated by an 431 entity external to the Home Agent, typically a AAA server. 433 5.3. Authentication Failure Detection at the Mobile Node 435 In case of authentication failure, the Home Agent MUST send a Binding 436 Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node, 437 if a shared-key based mobility security association to be used 438 between Mobile Node and Home Agent for authentication exists. If 439 there is no shared-key based mobility security association, HA drops 440 the Binding Update. HA may log the message for administrative 441 action. 443 Upon receiving a Binding Acknowledgement with status code MIPV6-AUTH- 444 FAIL, the Mobile Node SHOULD stop sending new Binding Updates to the 445 Home Agent. 447 6. Mobility message replay protection option 449 The Mobility message replay protection option MAY be used in Binding 450 Update/Binding Acknowledgement messages when authenticated using the 451 mobility message authentication option as described in Section 5. 453 The mobility message replay protection option is used to let the Home 454 Agent verify that a Binding Update has been freshly generated by the 455 Mobile Node and not replayed by an attacker from some previous 456 Binding Update. This is especially useful for cases where the Home 457 Agent does not maintain stateful information about the Mobile Node 458 after the binding entry has been removed. The Home Agent does the 459 replay protection check after the Binding Update has been 460 authenticated. The mobility message replay protection option when 461 included is used by the Mobile Node for matching BA with BU. 463 If this mode of replay protection is used, it needs to be part of the 464 shared-key based mobility security association. 466 If the policy at Home Agent mandates replay protection using this 467 option (as opposed to the sequence number in Mobility Header in 468 Binding Update) and the Binding Update from Mobile Node does not 469 include this option, Home Agent discards the BU and sets the Status 470 Code in BA to MIPV6-MESG-ID-REQD. 472 When the Home Agent receives the mobility message replay protection 473 option in Binding Update, it MUST include the mobility message replay 474 protection option in Binding Acknowledgement. Appendix A provides 475 details regarding why the mobility message replay protection option 476 MAY be used when using the authentication option. 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Option Type | Option Length | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Timestamp ... | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Timestamp | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Figure 3 489 Option Type: 491 MESG-ID-OPTION-TYPE to be defined by IANA. An 8-bit identifier 492 of the type mobility option. 494 Option Length: 496 8-bit unsigned integer, representing the length in octets of 497 the Timestamp field. 499 Timestamp: 501 This field carries the 64 bit timestamp. 503 Alignment requirements : 505 The alignment requirement for this option is 8n + 2. 507 The basic principle of timestamp replay protection is that the node 508 generating a message inserts the current time of day, and the node 509 receiving the message checks that this timestamp is sufficiently 510 close to its own time of day. Unless specified differently in the 511 shared-key based mobility security association between the nodes, a 512 default value of 7 seconds MAY be used to limit the time difference. 513 This value SHOULD be greater than 3 seconds. The two nodes must have 514 adequately synchronized time-of-day clocks. 516 The Mobile Node MUST set the Timestamp field to a 64-bit value 517 formatted as specified by the Network Time Protocol [RFC1305]. The 518 low-order 32 bits of the NTP format represent fractional seconds, and 519 those bits which are not available from a time source SHOULD be 520 generated from a good source of randomness. Note, however, that when 521 using timestamps, the 64-bit Timestamp used in a Binding Update from 522 the Mobile Node MUST be greater than that used in any previous 523 successful Binding Update. 525 After successful authentication of Binding Update (either locally at 526 the Home Agent or when a success indication is received from the AAA 527 server), the Home Agent MUST check the Timestamp field for validity. 528 In order to be valid, the timestamp contained in the Timestamp field 529 MUST be close enough to the Home Agent's time of day clock and the 530 timestamp MUST be greater than all previously accepted timestamps for 531 the requesting Mobile Node. 533 If the timestamp is valid, the Home Agent copies the entire Timestamp 534 field into the Timestamp field in the BA it returns to the Mobile 535 Node. If the timestamp is not valid, the Home Agent copies only the 536 low-order 32 bits into the BA, and supplies the high-order 32 bits 537 from its own time of day. 539 If the timestamp field is not valid but the authentication of the BU 540 succeeds, Home Agent MUST send a Binding Acknowledgement with status 541 code MIPV6-ID-MISMATCH. The Home Agent does not create a binding 542 cache entry if the timestamp check fails. 544 If the Mobile Node receives a Binding Acknowledgement with the code 545 MIPV6-ID-MISMATCH, the Mobile Node MUST authenticate the BA by 546 processing the MN-HA authentication mobility option. 548 If authentication succeeds, the Mobile Node MUST adjust its timestamp 549 and send subsequent Binding Update using the updated value. 551 Upon receiving a BA that does not contain the MIPV6-ID-MISMATCH 552 status code, the Mobile Node MUST compare the Timestamp value in the 553 BA to the Timestamp value it sent in the corresponding BU. If the 554 values match, the Mobile Node proceeds to process the MN-HA 555 authentication data in the BA. If the values do not match, the 556 Mobile Node silently discards the BA. 558 7. Security Considerations 560 This document proposes new authentication options to authenticate the 561 control message between Mobile Node, Home Agent and/or home AAA (as 562 an alternative to IPsec). The new options provide for authentication 563 of Binding Update and Binding Acknowledgement messages. The MN-AAA 564 authentication options provides for authentication with AAA 565 infrastructure. 567 This specification also introduces an optional replay protection 568 mechanism in Section 6, to prevent replay attacks. The sequence 569 number field in the Binding Update is not used if this mechanism is 570 used. This memo defines the timestamp option to be used for mobility 571 message replay protection. 573 8. IANA Considerations 575 IANA services are required for this specification. The values for 576 new mobility options and status codes must be assigned from the 577 Mobile IPv6 [RFC3775] numbering space. 579 The values for Mobility Option types AUTH-OPTION-TYPE and MESG-ID- 580 OPTION-TYPE, as defined in Section 5 and Section 6 need to be 581 assigned. The suggested values are 8 for the AUTH-OPTION-TYPE and 9 582 for the MESG-ID-OPTION-TYPE Mobility Option. 584 The values for status codes MIPV6-ID-MISMATCH, MIPv6-AUTH-FAIL and 585 MIPV6-MESG-ID-REQD as defined in Section 6, Section 6 and Section 5.3 586 also need to be assigned. The suggested values are 144 for MIPV6-ID- 587 MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for MIPV6-AUTH-FAIL. 589 IANA should record values for these new Mobility Options and the new 590 Status Codes. 592 A new section for enumerating algorithms identified by specific 593 mobility SPIs within the range 0-255 is to be added to 595 http://www.isi.edu/in-notes/iana/assignments/mobility-parameters 597 The currently defined values are as follows: 599 The value 0 should not be assigned. 601 The value 3 is suggested for HMAC_SHA1_SPI as defined in Section 5.2. 603 The value 5 is reserved for use by 3GPP2. 605 New values for this namespace can be allocated using IETF Consensus. 606 [RFC2434]. 608 In addition, IANA needs to create a new namespace for the subtype 609 field of the MN-HA and MN-AAA authentication mobility options under 611 http://www.isi.edu/in-notes/iana/assignments/mobility-parameters 613 The currently allocated values are as follows: 615 1 MN-HA authentication mobility option Section 5.1 617 2 MN-AAA authentication mobility option Section 5.2 619 New values for this namespace can be allocated using IETF Consensus. 620 [RFC2434]. 622 9. Acknowledgements 624 The authors would like to thank Basavaraj Patil, Charlie Perkins 625 Vijay Devarapalli, Jari Arkko and Gopal Dommety for their thorough 626 review and suggestions on the document. The authors would like to 627 acknowledge the fact that a similar authentication method was 628 considered in base protocol [RFC3775] at one time. 630 10. References 632 10.1. Normative References 634 [MN_Ident] 635 Patel et. al., A., "Mobile Node Identifier Option for 636 Mobile IPv6", draft-ietf-mip6-mn-ident-option-03.txt (work 637 in progress), December 2004. 639 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 640 Specification, Implementation", RFC 1305, March 1992. 642 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 643 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 644 October 1998. 646 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 647 August 2002. 649 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 650 in IPv6", RFC 3775, June 2004. 652 10.2. Informative References 654 [3GPP2] "cdma2000 Wireless IP Network Standard", 3GPP2 X.S0011-D, 655 September 2005. 657 [IKEv2-REF] 658 Kaufman, et. al, C., "Internet Key Exchange (IKEv2) 659 Protocol", draft-ietf-ipsec-ikev2-17.txt (work in 660 progress). 662 [whyauth] Patil et. al., B., "Why Authentication Data suboption is 663 needed for MIP6", 664 draft-patil-mip6-whyauthdataoption-01.txt (work in 665 progress), September 2005. 667 Appendix A. Rationale for mobility message replay protection option 669 Mobile IPv6 [RFC3775] defines a Sequence Number in the mobility 670 header to prevent replay attacks. There are two aspects that stand 671 out in regards to using the Sequence Number to prevent replay 672 attacks. 674 Firstly, the specification states that Home Agent should accept a BU 675 with a Sequence Number greater than the Sequence Number from previous 676 Binding Update. This implicitly assumes that the Home Agent has some 677 information regarding the Sequence Number from previous BU (even when 678 the binding cache entry is not present). Secondly, the specification 679 states that if the Home Agent has no binding cache entry for the 680 indicated home address, it MUST accept any Sequence Number value in a 681 received Binding Update from this Mobile Node. 683 With the mechanism defined in this draft, it is possible for the 684 Mobile Node to register with a different Home Agent during each 685 mobility session. Thus, it is unreasonable to expect each Home Agent 686 in the network to maintain state about the Mobile Node. Also, if the 687 Home Agent does not cache information regarding sequence number, as 688 per the second point above, a replayed BU can cause a Home Agent to 689 create a binding cache entry for the Mobile Node. Thus, when 690 authentication option is used, Sequence Number does not provide 691 protection against replay attack. 693 One solution to this problem (when Home Agent does not save state 694 information for every Mobile Node) would be for the Home Agent to 695 reject the first BU and assign a (randomly generated) starting 696 sequence number for the session and force the Mobile Node to send a 697 fresh BU with the suggested sequence number. While this would work 698 in most cases, it would require an additional round trip and this 699 extra signalling and latency is not acceptable in certain deployments 700 [3GPP2]. Also, this rejection and using sequence number as a nonce 701 in rejection is a new behavior that is not specified in [RFC3775]. 703 Thus, this specification uses the mobility message replay protection 704 option to prevent replay attacks. Specifically, timestamps are used 705 to prevent replay attacks as described in Section 6. 707 It is important to note that as per Mobile IPv6 [RFC3775] this 708 problem with sequence number exists. Since the base specification 709 mandates the use of IPsec (and naturally that goes with IKE in most 710 cases), the real replay protection is provided by IPsec/IKE. In case 711 of BU/BA between Mobile Node and CN, the liveness proof is provided 712 by the use of nonces which the CN generates. 714 Authors' Addresses 716 Alpesh Patel 717 Cisco Systems 718 170 W. Tasman Drive 719 San Jose, CA 95134 720 US 722 Phone: +1 408-853-9580 723 Email: alpesh@cisco.com 725 Kent Leung 726 Cisco Systems 727 170 W. Tasman Drive 728 San Jose, CA 95134 729 US 731 Phone: +1 408-526-5030 732 Email: kleung@cisco.com 734 Mohamed Khalil 735 Nortel Networks 736 2221 Lakeside Blvd. 737 Richardson, TX 75082 738 US 740 Phone: +1 972-685-0574 741 Email: mkhalil@nortel.com 743 Haseeb Akhtar 744 Nortel Networks 745 2221 Lakeside Blvd. 746 Richardson, TX 75082 747 US 749 Phone: +1 972-684-4732 750 Email: haseebak@nortel.com 751 Kuntal Chowdhury 752 Starent Networks 753 30 International Place 754 Tewksbury, MA 01876 755 US 757 Phone: +1 214 550 1416 758 Email: kchowdury@starentnetworks.com 760 Intellectual Property Statement 762 The IETF takes no position regarding the validity or scope of any 763 Intellectual Property Rights or other rights that might be claimed to 764 pertain to the implementation or use of the technology described in 765 this document or the extent to which any license under such rights 766 might or might not be available; nor does it represent that it has 767 made any independent effort to identify any such rights. Information 768 on the procedures with respect to rights in RFC documents can be 769 found in BCP 78 and BCP 79. 771 Copies of IPR disclosures made to the IETF Secretariat and any 772 assurances of licenses to be made available, or the result of an 773 attempt made to obtain a general license or permission for the use of 774 such proprietary rights by implementers or users of this 775 specification can be obtained from the IETF on-line IPR repository at 776 http://www.ietf.org/ipr. 778 The IETF invites any interested party to bring to its attention any 779 copyrights, patents or patent applications, or other proprietary 780 rights that may cover technology that may be required to implement 781 this standard. Please address the information to the IETF at 782 ietf-ipr@ietf.org. 784 Disclaimer of Validity 786 This document and the information contained herein are provided on an 787 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 788 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 789 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 790 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 791 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 792 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 794 Copyright Statement 796 Copyright (C) The Internet Society (2005). This document is subject 797 to the rights, licenses and restrictions contained in BCP 78, and 798 except as set forth therein, the authors retain all their rights. 800 Acknowledgment 802 Funding for the RFC Editor function is currently provided by the 803 Internet Society.