idnits 2.17.1 draft-ietf-mip6-rfc4285bis-03.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 813. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 819. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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 238: '... The Mobile Node MUST include the MN-N...' RFC 2119 keyword, line 242: '... Mobile Node MAY use Message Identif...' RFC 2119 keyword, line 270: '... option MUST be present before the M...' RFC 2119 keyword, line 271: '... the HA MUST discard the message)....' RFC 2119 keyword, line 336: '... implementation MUST be able to assoc...' (32 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 14, 2008) is 5737 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0-4294967296' is mentioned on line 333, but not defined == Missing Reference: '0-255' is mentioned on line 333, but not defined == Unused Reference: 'RFC4306' is defined on line 660, but no explicit reference was found in the text ** 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) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Patel 3 Internet-Draft K. Leung 4 Intended status: Informational Cisco Systems 5 Expires: January 15, 2009 M. Khalil 6 H. Akhtar 7 Nortel Networks 8 K. Chowdhury 9 Starent Networks 10 July 14, 2008 12 Authentication Protocol for Mobile IPv6 13 draft-ietf-mip6-rfc4285bis-03.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 15, 2009. 40 Abstract 42 IPsec is specified as the means of securing signaling messages 43 between the Mobile Node and Home Agent for Mobile IPv6. Mobile IPv6 44 signalling messages that are secured include the Binding Updates and 45 Acknowledgement messages used for managing the bindings between a 46 Mobile Node and its Home Agent. This document proposes an alternate 47 method for securing Mobile IPv6 signaling messages between a Mobile 48 Nodes and Home Agents. The alternate method defined here consists of 49 a Mobile IPv6 specific authentication option that can be added to 50 Mobile IPv6 signalling messages. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 3 56 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Operational flow . . . . . . . . . . . . . . . . . . . . . . . 7 60 5. Mobility message authentication option . . . . . . . . . . . . 8 61 5.1. MN-HA authentication mobility option . . . . . . . . . . . 10 62 5.1.1. Processing Considerations . . . . . . . . . . . . . . 11 63 5.2. MN-AAA authentication mobility option . . . . . . . . . . 11 64 5.2.1. Processing Considerations . . . . . . . . . . . . . . 12 65 5.3. Authentication Failure Detection at the Mobile Node . . . 12 66 6. Mobility message replay protection option . . . . . . . . . . 13 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 73 Appendix A. Rationale for mobility message replay protection 74 option . . . . . . . . . . . . . . . . . . . . . . . 20 75 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 21 76 B.1. Key length change . . . . . . . . . . . . . . . . . . . . 21 77 B.2. Changed IKEv2 draft number to RFC . . . . . . . . . . . . 21 78 B.3. Text removed in applicability statement . . . . . . . . . 21 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 80 Intellectual Property and Copyright Statements . . . . . . . . . . 24 82 1. Introduction 84 The base Mobile IPv6 (MIPv6) specification [RFC3775] specifies the 85 signaling messages, Binding Update (BU) and Binding Acknowledgement 86 (BA), between the Mobile Node (MN) and Home agent (HA) to be secured 87 by the IPsec Security Associations (IPsec SAs) that are established 88 between these two entities. 90 This document proposes a solution for securing the Binding Update and 91 Binding Acknowledgment messages between the Mobile Node and Home 92 agent using an authentication option which is included in these 93 messages. Such a mechanism enables IPv6 mobility in a host without 94 having to establish an IPsec SA with its Home Agent. A Mobile Node 95 can implement Mobile IPv6 without having to integrate it with the 96 IPsec module, in which case the Binding Update and Binding 97 Acknowldegement messages (between MN and HA) are secured with the 98 authentication option. 100 The authentication mechanism proposed here is similar to the 101 authentication mechanism used in Mobile IPv4 [RFC3344]. 103 1.1. Applicability Statement 105 The authentication option specified in Section 5 is applicable in 106 certain types of networks that have the following characteristics: 108 - Networks in which the authentication of the MN for network access 109 is done by an authentication server in the home network via the home 110 agent. The security association is established by the network 111 operator (provisioning methods) between the MN and a backend 112 authentication server (eg. home AAA server). MIPv6 as per RFC3775/ 113 3776 relies on the IPsec SA between the MN and an HA. In cases where 114 the assignment of the HA is dynamic and the only static or long term 115 SA is between the MN and a backend authentication server, the 116 authentication option is desirable. 118 - In certain deployment environments, the Mobile Node needs dynamic 119 assignment of a home agent and home address. The assignment of such 120 can be on a per session basis or on a per MN power-up basis. In such 121 scenarios, the MN relies on an identity such as an NAI [RFC4283], and 122 a security association with a AAA server to obtain such bootstrapping 123 information. The security association is created via an out-of-band 124 mechanism or by non Mobile IPv6 signaling. The out-of-band mechanism 125 can be specific to the deployment environment of a network operator. 126 In cdma2000 network deployments this information can be obtained at 127 the time of network access authentication via [3GPP2] specific 128 extensions to PPP or DHCPv6 on the access link and by AAA extensions 129 in the core. It should be noted that the out-of-band mechanism if 130 not within the scope of the authentication option Section 5 and hence 131 not described therein. 133 - Network deployments in which not all Mobile Nodes and home agents 134 have Internet Key Exchange verion 2 (IKEv2) implementations and 135 support for the integration of IKEv2 with backend AAA 136 infrastructures. IKEv2 as a technology has yet to reach maturity 137 status and widespread implementations needed for commercial 138 deployments on a large scale. 140 - Networks which expressly rely on the backend AAA infrastructure as 141 the primary means for identifying and authentication/authorizing a 142 mobile user for MIPv6 service. 144 - Networks in which the establishment of the security association 145 between the mobile node and the authentication server (home AAA 146 server) is established using an out-of-band mechanism and not by any 147 key exchange protocol. Such networks will also rely on out-of-band 148 mechanisms to renew the security association (between MN and home AAA 149 server) when needed. 151 - Networks which are bandwidth constrained (such as cellular wireless 152 networks) and there exists a strong desire to minimize the number of 153 signaling messages sent over such interfaces. MIPv6 signaling which 154 relies on IKE as the primary means for setting up an SA between the 155 MN and HA requires more signaling messages compared with the use of 156 an authentication option carried in the BU/BA messages. 158 One such example of networks that have such characteristics are cdma 159 networks as defined in [3GPP2]. 161 2. Overview 163 This document presents a lightweight mechanism to authenticate the 164 Mobile Node at the Home Agent or at the Authentication, Authorization 165 and Accounting (AAA) server in Home network (HAAA) based on a shared- 166 key based mobility security association between the Mobile Node and 167 the respective authenticating entity. This shared-key based mobility 168 security association (shared-key based mobility SA) may be statically 169 provisioned or dynamically created. The term "mobility security 170 association" referred to in this document is understood to be a 171 "shared-key based Mobile IPv6 authentication" security association. 173 This document introduces new mobility options to aid in 174 authentication of the Mobile Node to the Home Agent or home AAA 175 server. The confidentiality protection of Return Routability 176 messages and authentication/integrity protection of Mobile Prefix 177 Discovery (MPD) is not provided when these options are used for 178 authentication of the Mobile Node to the Home Agent. Thus, unless 179 the network can guarantee such protection (for instance, like in 180 3GPP2 networks), Route Optimization and Mobile Prefix Discovery 181 should not be used when using the authentication option. 183 3. Terminology 185 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in RFC 2119. 189 3.1. General Terms 191 First (size, input) 193 Some formulas in this specification use a functional form "First 194 (size, input)" to indicate truncation of the "input" data so that 195 only the first "size" bits remain to be used. 197 Shared-key based Mobility Security Association 199 Security relation between Mobile Node and its Home Agent, used to 200 authenticate the Mobile Node for mobility service. The shared-key 201 based mobility security association between Mobile Node and Home 202 Agent consists of a mobility SPI, a shared-key, an authentication 203 algorithm and the replay protection mechanism in use. 205 Mobility Security Pamater Index (SPI) 207 A number in the range [0-4294967296] used to index into the 208 shared-key based mobility security associations. The SPI value 209 can be same or different from MN to HA and from HA to MN in 210 relation to MN-HA authentication mobility option. Value range 211 [0-255] is reserved. 213 4. Operational flow 215 The figure below describes the sequence of messages sent and received 216 between the MN and HA in the registration process. Binding Update 217 (BU) and Binding Acknowledgement (BA) messages are used in the 218 registration process. 220 MN HA/HAAA 221 | BU to HA | 222 (a) |----------------------------------------------------->| 223 | (including MN-NAI Mobility Option, | 224 | Message ID option [optional], authentication option)| 225 | | 226 | | 227 | HA/HAAA authenticates MN 228 | | 229 | | 230 | BA to MN | 231 (b) |<-----------------------------------------------------| 232 | (including MN-NAI Mobility Option, | 233 | Message ID option [optional], authentication option)| 234 | | 236 Figure 1: Home Registration with Authentication Protocol 238 The Mobile Node MUST include the MN-NAI Mobility Option, as defined 239 in [RFC4283] to identify itself while authenticating with the Home 240 Agent. 242 Mobile Node MAY use Message Identifier option as defined in Section 6 243 for additional replay protection. 245 The authentication option described in Section 5 may be used by the 246 mobile node to transfer authentication data when the mobile node and 247 the home agent are utilizing a mobility SPI (a number in the range 248 [0-4294967296] used to index into the shared-key based mobility 249 security associations). 251 5. Mobility message authentication option 253 This section defines a message authentication mobility option that 254 may be used to secure Binding Update and Binding Acknowledgement 255 messages. This option can be used along with IPsec or preferably as 256 an alternate mechanism to authenticate Binding Update and Binding 257 Acknowledgement messages in the absence of IPsec. 259 This document also defines subtype numbers, which identify the mode 260 of authentication and the peer entity to authenticate the message. 261 Two subtype numbers are specified in this document. Other subtypes 262 may be defined for use in the future. 264 Only one instance of an authentication option of a particular subtype 265 can be present in the message. One message may contain multiple 266 instances of authentication options with different subtype values. 267 If both Mobile Node to Home Agent (MN-HA) and Mobile Node to 268 Authentication Authorization Accounting server (MN-AAA) 269 authentication mobility options are present, the MN-HA authentication 270 option MUST be present before the MN-AAA authentication option (else, 271 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 SPI and Authentication Data fields. 301 Subtype: 303 A number assigned to identify the entity and/or mechanism to be 304 used to authenticate the message. 306 Mobility SPI: 308 Mobility Security Parameter Index 310 Authentication Data: 312 This field has the information to authenticate the relevant 313 mobility entity. This protects the message beginning at the 314 Mobility Header upto and including the mobility SPI field. 316 Alignment requirements : 318 The alignment requirement for this option is 4n + 1. 320 5.1. MN-HA authentication mobility option 322 The format of the MN-HA authentication mobility option is as defined 323 in Figure 2. This option uses the subtype value of 1. The MN-HA 324 authentication mobility option is used to authenticate the Binding 325 Update and Binding Acknowledgement messages based on the shared-key 326 based security association between the Mobile Node and the Home 327 Agent. 329 The shared-key based mobility security association between Mobile 330 Node and Home Agent used within this specification consists of a 331 mobility SPI, a key, an authentication algorithm and the replay 332 protection mechanism in use. The mobility SPI is a number in range 333 [0-4294967296], where the range [0-255] is reserved. In particular, 334 the SPI selects the authentication algorithm and shared key used in 335 computing the Authenticator. In order to ensure interoperability, an 336 implementation MUST be able to associate any SPI value with any 337 authentication algorithm. In addition, all implementations MUST 338 implement the default authentication algorithm, HMAC_SHA1. Other 339 algorithms are allowed but are not specified in this document. The 340 shared-key consists of an arbitrary value and is 20 octets in length. 342 The replay protection mechanism may use the sequence number as 343 specified in [RFC3775] or the Timestamp option as defined in 344 Section 6. If the Timestamp option is used for replay protection as 345 defined in Section 6, the mobility security association includes a 346 "close enough" field to account for clock drift. A default value of 347 7 seconds SHOULD be used. This value SHOULD be greater than 3 348 seconds. 350 The MN-HA authentication mobility option MUST be the last option in a 351 message with mobility header if it is the only authentication option 352 in the message. 354 The authentication data is calculated on the message starting from 355 the mobility header upto and including the mobility SPI value of this 356 option. 358 Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility 359 Data)) 361 Mobility Data = care-of address | home address | Mobility Header(MH) 362 Data 364 MH Data is the content of the Mobility Header upto and including the 365 mobility SPI field of the Mobility message authentication option. 366 The Checksum field in Mobility Header MUST be set to 0 to calculate 367 the Mobility Data. 369 5.1.1. Processing Considerations 371 The assumption is that Mobile Node has a shared-key based security 372 association with the Home Agent. The Mobile Node MUST include this 373 option in a BU if it has a shared-key based mobility security 374 association with the Home Agent. The Home Agent MUST include this 375 option in the BA if it received this option in the corresponding BU 376 and Home Agent has a shared-key based mobility security association 377 with the Mobile Node. 379 The Mobile Node or Home Agent receiving this option MUST verify the 380 authentication data in the option. If authentication fails, the Home 381 Agent MUST send BA with Status Code MIPV6-AUTH-FAIL. If the Home 382 Agent does not have shared-key based mobility SA, Home Agent MUST 383 discard the BU. The Home Agent MAY log such events. 385 5.2. MN-AAA authentication mobility option 387 The format of the MN-AAA authentication mobility option is as defined 388 in Figure 2. This option uses the subtype value of 2. The MN-AAA 389 authentication mobility option is used to authenticate the Binding 390 Update message based on the shared mobility security association 391 between Mobile Node and AAA server in Home network (HAAA). It is not 392 used in Binding Acknowledgement messages. The corresponding Binding 393 Acknowledgement messages must be authenticated using the MN-HA 394 authentication option Section 5.1. 396 This must be the last option in a message with mobility header. The 397 corresponding response MUST include the MN-HA Authentication option, 398 and MUST NOT include the MN-AAA Authentication option. 400 The Mobile Node MAY use Mobile Node Identifier option [RFC4283] to 401 enable the Home Agent to make use of available AAA infrastructure. 403 The authentication data is calculated on the message starting from 404 the mobility header upto and including the mobility SPI value of this 405 option. 407 The authentication data shall be calculated as follows: 409 Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data) 411 hash_fn() is decided by the value of mobility SPI field in the 412 authentication option. 414 SPI = HMAC_SHA1_SPI: 416 If mobility SPI has the well-known value HMAC_SHA1_SPI, then 417 hash_fn() is HMAC_SHA1. When HMAC_SHA1_SPI is used, the BU is 418 authenticated by AAA using HMAC_SHA1 authentication. In that case, 419 MAC_Mobility Data is calculated as follows: 421 MAC_Mobility Data = SHA1(care-of address | home address | MH Data) 423 MH Data is the content of the Mobility Header upto and including the 424 mobility SPI field of this option. 426 5.2.1. Processing Considerations 428 The use of the MN-AAA authentication option assumes that AAA entities 429 at the home site communicate with the HA via an authenticated 430 channel. Specifically, a BU with the MN-AAA authentication option is 431 authenticated via a home AAA server. The specific details of the 432 interaction between the HA and the AAA server is beyond the scope of 433 this document. 435 When the Home Agent receives a Binding Update with the MN-AAA 436 authentication option, the Binding Update is authenticated by an 437 entity external to the Home Agent, typically a AAA server. 439 5.3. Authentication Failure Detection at the Mobile Node 441 In case of authentication failure, the Home Agent MUST send a Binding 442 Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node, 443 if a shared-key based mobility security association to be used 444 between Mobile Node and Home Agent for authentication exists. If 445 there is no shared-key based mobility security association, HA MUST 446 silently discard the Binding Update. HA may log the message for 447 administrative action. 449 Upon receiving a Binding Acknowledgement with status code MIPV6-AUTH- 450 FAIL, the Mobile Node SHOULD stop sending new Binding Updates to the 451 Home Agent. 453 6. Mobility message replay protection option 455 The Mobility message replay protection option MAY be used in Binding 456 Update/Binding Acknowledgement messages when authenticated using the 457 mobility message authentication option as described in Section 5. 459 The mobility message replay protection option is used to let the Home 460 Agent verify that a Binding Update has been freshly generated by the 461 Mobile Node and not replayed by an attacker from some previous 462 Binding Update. This is especially useful for cases where the Home 463 Agent does not maintain stateful information about the Mobile Node 464 after the binding cache entry has been removed. The Home Agent does 465 the replay protection check after the Binding Update has been 466 authenticated. The mobility message replay protection option when 467 included is used by the Mobile Node for matching BA with BU. 469 If this mode of replay protection is used, it needs to be part of the 470 shared-key based mobility security association. 472 If the policy at Home Agent mandates replay protection using this 473 option (as opposed to the sequence number in Mobility Header in 474 Binding Update) and the Binding Update from Mobile Node does not 475 include this option, Home Agent discards the BU and sets the Status 476 Code in BA to MIPV6-MESG-ID-REQD. 478 When the Home Agent receives the mobility message replay protection 479 option in Binding Update, it MUST include the mobility message replay 480 protection option in Binding Acknowledgement. Appendix A provides 481 details regarding why the mobility message replay protection option 482 MAY be used when using the authentication option. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Option Type | Option Length | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Timestamp ... | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Timestamp | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Figure 3 496 Option Type: 498 MESG-ID-OPTION-TYPE to be defined by IANA. An 8-bit identifier 499 of the type mobility option. 501 Option Length: 503 8-bit unsigned integer, representing the length in octets of 504 the Timestamp field. 506 Timestamp: 508 This field carries the 64 bit timestamp. 510 Alignment requirements : 512 The alignment requirement for this option is 8n + 2. 514 The basic principle of timestamp replay protection is that the node 515 generating a message inserts the current time of day, and the node 516 receiving the message checks that this timestamp is sufficiently 517 close to its own time of day. Unless specified differently in the 518 shared-key based mobility security association between the nodes, a 519 default value of 7 seconds MAY be used to limit the time difference. 520 This value SHOULD be greater than 3 seconds. The two nodes must have 521 adequately synchronized time-of-day clocks. 523 The Mobile Node MUST set the Timestamp field to a 64-bit value 524 formatted as specified by the Network Time Protocol [RFC1305]. The 525 low-order 32 bits of the NTP format represent fractional seconds, and 526 those bits which are not available from a time source SHOULD be 527 generated from a good source of randomness. Note, however, that when 528 using timestamps, the 64-bit Timestamp used in a Binding Update from 529 the Mobile Node MUST be greater than that used in any previous 530 successful Binding Update. 532 After successful authentication of Binding Update (either locally at 533 the Home Agent or when a success indication is received from the AAA 534 server), the Home Agent MUST check the Timestamp field for validity. 535 In order to be valid, the timestamp contained in the Timestamp field 536 MUST be close enough to the Home Agent's time of day clock and the 537 timestamp MUST be greater than all previously accepted timestamps for 538 the requesting Mobile Node. 540 If the timestamp is valid, the Home Agent copies the entire Timestamp 541 field into the Timestamp field in the BA it returns to the Mobile 542 Node. If the timestamp is not valid, the Home Agent copies only the 543 low-order 32 bits into the BA, and supplies the high-order 32 bits 544 from its own time of day. 546 If the timestamp field is not valid but the authentication of the BU 547 succeeds, Home Agent MUST send a Binding Acknowledgement with status 548 code MIPV6-ID-MISMATCH. The Home Agent does not create a binding 549 cache entry if the timestamp check fails. 551 If the Mobile Node receives a Binding Acknowledgement with the code 552 MIPV6-ID-MISMATCH, the Mobile Node MUST authenticate the BA by 553 processing the MN-HA authentication mobility option. 555 If authentication succeeds, the Mobile Node MUST adjust its timestamp 556 and send subsequent Binding Update using the updated value. 558 Upon receiving a BA that does not contain the MIPV6-ID-MISMATCH 559 status code, the Mobile Node MUST compare the Timestamp value in the 560 BA to the Timestamp value it sent in the corresponding BU. If the 561 values match, the Mobile Node proceeds to process the MN-HA 562 authentication data in the BA. If the values do not match, the 563 Mobile Node silently discards the BA. 565 7. Security Considerations 567 This document proposes new authentication options to authenticate the 568 control message between Mobile Node, Home Agent and/or home AAA (as 569 an alternative to IPsec). The new options provide for authentication 570 of Binding Update and Binding Acknowledgement messages. The MN-AAA 571 authentication options provides for authentication with AAA 572 infrastructure. 574 This specification also introduces an optional replay protection 575 mechanism in Section 6, to prevent replay attacks. The sequence 576 number field in the Binding Update is not used if this mechanism is 577 used. This memo defines the timestamp option to be used for mobility 578 message replay protection. 580 8. IANA Considerations 582 IANA services are required for this specification. The values for 583 new mobility options and status codes must be assigned from the 584 Mobile IPv6 [RFC3775] numbering space. 586 The values for Mobility Option types AUTH-OPTION-TYPE and MESG-ID- 587 OPTION-TYPE, as defined in Section 5 and Section 6 need to be 588 assigned. The suggested values are 8 for the AUTH-OPTION-TYPE and 9 589 for the MESG-ID-OPTION-TYPE Mobility Option. 591 The values for status codes MIPV6-ID-MISMATCH, MIPv6-AUTH-FAIL and 592 MIPV6-MESG-ID-REQD as defined in Section 6, Section 6 and Section 5.3 593 also need to be assigned. The suggested values are 144 for MIPV6-ID- 594 MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for MIPV6-AUTH-FAIL. 596 IANA should record values for these new Mobility Options and the new 597 Status Codes. 599 A new section for enumerating algorithms identified by specific 600 mobility SPIs within the range 0-255 is to be added to 602 http://www.isi.edu/in-notes/iana/assignments/mobility-parameters 604 The currently defined values are as follows: 606 The value 0 should not be assigned. 608 The value 3 is suggested for HMAC_SHA1_SPI as defined in Section 5.2. 610 The value 5 is reserved for use by 3GPP2. 612 New values for this namespace can be allocated using IETF Consensus. 613 [RFC2434]. 615 In addition, IANA needs to create a new namespace for the subtype 616 field of the MN-HA and MN-AAA authentication mobility options under 618 http://www.isi.edu/in-notes/iana/assignments/mobility-parameters 620 The currently allocated values are as follows: 622 1 MN-HA authentication mobility option Section 5.1 624 2 MN-AAA authentication mobility option Section 5.2 626 New values for this namespace can be allocated using IETF Consensus. 627 [RFC2434]. 629 9. Acknowledgements 631 The authors would like to thank Basavaraj Patil, Charlie Perkins 632 Vijay Devarapalli, Jari Arkko and Gopal Dommety for their thorough 633 review and suggestions on the document. The authors would like to 634 acknowledge the fact that a similar authentication method was 635 considered in base protocol [RFC3775] at one time. Many thanks to 636 Hannes Tschofenig and Jouni Korhonen for their detailed review and 637 comments. 639 10. References 641 10.1. Normative References 643 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 644 Specification, Implementation", RFC 1305, March 1992. 646 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 647 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 648 October 1998. 650 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 651 August 2002. 653 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 654 in IPv6", RFC 3775, June 2004. 656 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 657 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 658 (MIPv6)", RFC 4283, November 2005. 660 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 661 RFC 4306, December 2005. 663 10.2. Informative References 665 [3GPP2] "cdma2000 Wireless IP Network Standard", 3GPP2 X.S0011-D, 666 September 2005. 668 [whyauth] Patil et. al., B., "Why Authentication Data suboption is 669 needed for MIPv6", 670 draft-ietf-mip6-whyauthdataoption-06.txt (work in 671 progress), July 2008. 673 Appendix A. Rationale for mobility message replay protection option 675 Mobile IPv6 [RFC3775] defines a Sequence Number in the mobility 676 header to prevent replay attacks. There are two aspects that stand 677 out in regards to using the Sequence Number to prevent replay 678 attacks. 680 Firstly, the specification states that Home Agent should accept a BU 681 with a Sequence Number greater than the Sequence Number from previous 682 Binding Update. This implicitly assumes that the Home Agent has some 683 information regarding the Sequence Number from previous BU (even when 684 the binding cache entry is not present). Secondly, the specification 685 states that if the Home Agent has no binding cache entry for the 686 indicated home address, it MUST accept any Sequence Number value in a 687 received Binding Update from this Mobile Node. 689 With the mechanism defined in this draft, it is possible for the 690 Mobile Node to register with a different Home Agent during each 691 mobility session. Thus, it is unreasonable to expect each Home Agent 692 in the network to maintain state about the Mobile Node. Also, if the 693 Home Agent does not cache information regarding sequence number, as 694 per the second point above, a replayed BU can cause a Home Agent to 695 create a binding cache entry for the Mobile Node. Thus, when 696 authentication option is used, Sequence Number does not provide 697 protection against replay attack. 699 One solution to this problem (when Home Agent does not save state 700 information for every Mobile Node) would be for the Home Agent to 701 reject the first BU and assign a (randomly generated) starting 702 sequence number for the session and force the Mobile Node to send a 703 fresh BU with the suggested sequence number. While this would work 704 in most cases, it would require an additional round trip and this 705 extra signalling and latency is not acceptable in certain deployments 706 [3GPP2]. Also, this rejection and using sequence number as a nonce 707 in rejection is a new behavior that is not specified in [RFC3775]. 709 Thus, this specification uses the mobility message replay protection 710 option to prevent replay attacks. Specifically, timestamps are used 711 to prevent replay attacks as described in Section 6. 713 It is important to note that as per Mobile IPv6 [RFC3775] this 714 problem with sequence number exists. Since the base specification 715 mandates the use of IPsec (and naturally that goes with IKE in most 716 cases), the real replay protection is provided by IPsec/IKE. In case 717 of BU/BA between Mobile Node and CN, the liveness proof is provided 718 by the use of nonces which the CN generates. 720 Appendix B. Change Log 722 B.1. Key length change 724 Changed the key length to 20 octets from 16 octets in section 725 Section 5.1 727 B.2. Changed IKEv2 draft number to RFC 729 In the reference section. 731 B.3. Text removed in applicability statement 733 Removed IKEv2 related text in section Section 1.1 735 Authors' Addresses 737 Alpesh Patel 738 Cisco Systems 739 170 W. Tasman Drive 740 San Jose, CA 95134 741 US 743 Phone: +1 919-392-5626 744 Email: alpesh@cisco.com 746 Kent Leung 747 Cisco Systems 748 170 W. Tasman Drive 749 San Jose, CA 95134 750 US 752 Phone: +1 408-526-5030 753 Email: kleung@cisco.com 755 Mohamed Khalil 756 Nortel Networks 757 2221 Lakeside Blvd. 758 Richardson, TX 75082 759 US 761 Phone: +1 972-685-0574 762 Email: mkhalil@nortel.com 764 Haseeb Akhtar 765 Nortel Networks 766 2221 Lakeside Blvd. 767 Richardson, TX 75082 768 US 770 Phone: +1 972-684-4732 771 Email: haseebak@nortel.com 772 Kuntal Chowdhury 773 Starent Networks 774 30 International Place 775 Tewksbury, MA 01876 776 US 778 Phone: +1 214-547-7307 779 Email: kchowdhury@starentnetworks.com 781 Full Copyright Statement 783 Copyright (C) The IETF Trust (2008). 785 This document is subject to the rights, licenses and restrictions 786 contained in BCP 78, and except as set forth therein, the authors 787 retain all their rights. 789 This document and the information contained herein are provided on an 790 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 791 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 792 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 793 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 794 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 795 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 797 Intellectual Property 799 The IETF takes no position regarding the validity or scope of any 800 Intellectual Property Rights or other rights that might be claimed to 801 pertain to the implementation or use of the technology described in 802 this document or the extent to which any license under such rights 803 might or might not be available; nor does it represent that it has 804 made any independent effort to identify any such rights. Information 805 on the procedures with respect to rights in RFC documents can be 806 found in BCP 78 and BCP 79. 808 Copies of IPR disclosures made to the IETF Secretariat and any 809 assurances of licenses to be made available, or the result of an 810 attempt made to obtain a general license or permission for the use of 811 such proprietary rights by implementers or users of this 812 specification can be obtained from the IETF on-line IPR repository at 813 http://www.ietf.org/ipr. 815 The IETF invites any interested party to bring to its attention any 816 copyrights, patents or patent applications, or other proprietary 817 rights that may cover technology that may be required to implement 818 this standard. Please address the information to the IETF at 819 ietf-ipr@ietf.org.