idnits 2.17.1 draft-ietf-mip6-rfc4285bis-02.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 799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 817. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 823. 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 242: '... The Mobile Node MUST include the MN-N...' RFC 2119 keyword, line 246: '... Mobile Node MAY use Message Identif...' RFC 2119 keyword, line 274: '... option MUST be present before the M...' RFC 2119 keyword, line 275: '... the HA MUST discard the message)....' RFC 2119 keyword, line 340: '... 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 (December 4, 2007) is 5985 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 337, but not defined == Missing Reference: '0-255' is mentioned on line 337, but not defined == Unused Reference: 'RFC4306' is defined on line 664, 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 (~~), 5 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 Expires: June 6, 2008 Cisco Systems 5 M. Khalil 6 H. Akhtar 7 Nortel Networks 8 K. Chowdhury 9 Starent Networks 10 December 4, 2007 12 Authentication Protocol for Mobile IPv6 13 draft-ietf-mip6-rfc4285bis-02.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 June 6, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 IPsec is specified as the means of securing signaling messages 47 between the Mobile Node and Home Agent for Mobile IPv6. Mobile IPv6 48 signalling messages that are secured include the Binding Updates and 49 Acknowledgement messages used for managing the bindings between a 50 Mobile Node and its Home Agent. This document proposes an alternate 51 method for securing Mobile IPv6 signaling messages between a Mobile 52 Nodes and Home Agents. The alternate method defined here consists of 53 a Mobile IPv6 specific authentication option that can be added to 54 Mobile IPv6 signalling messages. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 3 60 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3.1. General Terms . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Operational flow . . . . . . . . . . . . . . . . . . . . . . . 7 64 5. Mobility message authentication option . . . . . . . . . . . . 8 65 5.1. MN-HA authentication mobility option . . . . . . . . . . . 10 66 5.1.1. Processing Considerations . . . . . . . . . . . . . . 11 67 5.2. MN-AAA authentication mobility option . . . . . . . . . . 11 68 5.2.1. Processing Considerations . . . . . . . . . . . . . . 12 69 5.3. Authentication Failure Detection at the Mobile Node . . . 12 70 6. Mobility message replay protection option . . . . . . . . . . 13 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 77 Appendix A. Rationale for mobility message replay protection 78 option . . . . . . . . . . . . . . . . . . . . . . . 20 79 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 21 80 B.1. Key length change . . . . . . . . . . . . . . . . . . . . 21 81 B.2. Changed IKEv2 draft number to RFC . . . . . . . . . . . . 21 82 B.3. Text removed in applicability statement . . . . . . . . . 21 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 84 Intellectual Property and Copyright Statements . . . . . . . . . . 24 86 1. Introduction 88 The base Mobile IPv6 (MIPv6) specification [RFC3775] specifies the 89 signaling messages, Binding Update (BU) and Binding Acknowledgement 90 (BA), between the Mobile Node (MN) and Home agent (HA) to be secured 91 by the IPsec Security Associations (IPsec SAs) that are established 92 between these two entities. 94 This document proposes a solution for securing the Binding Update and 95 Binding Acknowledgment messages between the Mobile Node and Home 96 agent using an authentication option which is included in these 97 messages. Such a mechanism enables IPv6 mobility in a host without 98 having to establish an IPsec SA with its Home Agent. A Mobile Node 99 can implement Mobile IPv6 without having to integrate it with the 100 IPsec module, in which case the Binding Update and Binding 101 Acknowldegement messages (between MN and HA) are secured with the 102 authentication option. 104 The authentication mechanism proposed here is similar to the 105 authentication mechanism used in Mobile IPv4 [RFC3344]. 107 1.1. Applicability Statement 109 The authentication option specified in Section 5 is applicable in 110 certain types of networks that have the following characteristics: 112 - Networks in which the authentication of the MN for network access 113 is done by an authentication server in the home network via the home 114 agent. The security association is established by the network 115 operator (provisioning methods) between the MN and a backend 116 authentication server (eg. home AAA server). MIPv6 as per RFC3775/ 117 3776 relies on the IPsec SA between the MN and an HA. In cases where 118 the assignment of the HA is dynamic and the only static or long term 119 SA is between the MN and a backend authentication server, the 120 authentication option is desirable. 122 - In certain deployment environments, the Mobile Node needs dynamic 123 assignment of a home agent and home address. The assignment of such 124 can be on a per session basis or on a per MN power-up basis. In such 125 scenarios, the MN relies on an identity such as an NAI [RFC4283], and 126 a security association with a AAA server to obtain such bootstrapping 127 information. The security association is created via an out-of-band 128 mechanism or by non Mobile IPv6 signaling. The out-of-band mechanism 129 can be specific to the deployment environment of a network operator. 130 In cdma2000 network deployments this information can be obtained at 131 the time of network access authentication via [3GPP2] specific 132 extensions to PPP or DHCPv6 on the access link and by AAA extensions 133 in the core. It should be noted that the out-of-band mechanism if 134 not within the scope of the authentication option Section 5 and hence 135 not described therein. 137 - Network deployments in which not all Mobile Nodes and home agents 138 have Internet Key Exchange verion 2 (IKEv2) implementations and 139 support for the integration of IKEv2 with backend AAA 140 infrastructures. IKEv2 as a technology has yet to reach maturity 141 status and widespread implementations needed for commercial 142 deployments on a large scale. 144 - Networks which expressly rely on the backend AAA infrastructure as 145 the primary means for identifying and authentication/authorizing a 146 mobile user for MIPv6 service. 148 - Networks in which the establishment of the security association 149 between the mobile node and the authentication server (home AAA 150 server) is established using an out-of-band mechanism and not by any 151 key exchange protocol. Such networks will also rely on out-of-band 152 mechanisms to renew the security association (between MN and home AAA 153 server) when needed. 155 - Networks which are bandwidth constrained (such as cellular wireless 156 networks) and there exists a strong desire to minimize the number of 157 signaling messages sent over such interfaces. MIPv6 signaling which 158 relies on IKE as the primary means for setting up an SA between the 159 MN and HA requires more signaling messages compared with the use of 160 an authentication option carried in the BU/BA messages. 162 One such example of networks that have such characteristics are cdma 163 networks as defined in [3GPP2]. 165 2. Overview 167 This document presents a lightweight mechanism to authenticate the 168 Mobile Node at the Home Agent or at the Authentication, Authorization 169 and Accounting (AAA) server in Home network (HAAA) based on a shared- 170 key based mobility security association between the Mobile Node and 171 the respective authenticating entity. This shared-key based mobility 172 security association (shared-key based mobility SA) may be statically 173 provisioned or dynamically created. The term "mobility security 174 association" referred to in this document is understood to be a 175 "shared-key based Mobile IPv6 authentication" security association. 177 This document introduces new mobility options to aid in 178 authentication of the Mobile Node to the Home Agent or home AAA 179 server. The confidentiality protection of Return Routability 180 messages and authentication/integrity protection of Mobile Prefix 181 Discovery (MPD) is not provided when these options are used for 182 authentication of the Mobile Node to the Home Agent. Thus, unless 183 the network can guarantee such protection (for instance, like in 184 3GPP2 networks), Route Optimization and Mobile Prefix Discovery 185 should not be used when using the authentication option. 187 3. Terminology 189 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119. 193 3.1. General Terms 195 First (size, input) 197 Some formulas in this specification use a functional form "First 198 (size, input)" to indicate truncation of the "input" data so that 199 only the first "size" bits remain to be used. 201 Shared-key based Mobility Security Association 203 Security relation between Mobile Node and its Home Agent, used to 204 authenticate the Mobile Node for mobility service. The shared-key 205 based mobility security association between Mobile Node and Home 206 Agent consists of a mobility SPI, a shared-key, an authentication 207 algorithm and the replay protection mechanism in use. 209 Mobility Security Pamater Index (SPI) 211 A number in the range [0-4294967296] used to index into the 212 shared-key based mobility security associations. The SPI value 213 can be same or different from MN to HA and from HA to MN in 214 relation to MN-HA authentication mobility option. Value range 215 [0-255] is reserved. 217 4. Operational flow 219 The figure below describes the sequence of messages sent and received 220 between the MN and HA in the registration process. Binding Update 221 (BU) and Binding Acknowledgement (BA) messages are used in the 222 registration process. 224 MN HA/HAAA 225 | BU to HA | 226 (a) |----------------------------------------------------->| 227 | (including MN-NAI Mobility Option, | 228 | Message ID option [optional], authentication option)| 229 | | 230 | | 231 | HA/HAAA authenticates MN 232 | | 233 | | 234 | BA to MN | 235 (b) |<-----------------------------------------------------| 236 | (including MN-NAI Mobility Option, | 237 | Message ID option [optional], authentication option)| 238 | | 240 Figure 1: Home Registration with Authentication Protocol 242 The Mobile Node MUST include the MN-NAI Mobility Option, as defined 243 in [RFC4283] to identify itself while authenticating with the Home 244 Agent. 246 Mobile Node MAY use Message Identifier option as defined in Section 6 247 for additional replay protection. 249 The authentication option described in Section 5 may be used by the 250 mobile node to transfer authentication data when the mobile node and 251 the home agent are utilizing a mobility SPI (a number in the range 252 [0-4294967296] used to index into the shared-key based mobility 253 security associations). 255 5. Mobility message authentication option 257 This section defines a message authentication mobility option that 258 may be used to secure Binding Update and Binding Acknowledgement 259 messages. This option can be used along with IPsec or preferably as 260 an alternate mechanism to authenticate Binding Update and Binding 261 Acknowledgement messages in the absence of IPsec. 263 This document also defines subtype numbers, which identify the mode 264 of authentication and the peer entity to authenticate the message. 265 Two subtype numbers are specified in this document. Other subtypes 266 may be defined for use in the future. 268 Only one instance of an authentication option of a particular subtype 269 can be present in the message. One message may contain multiple 270 instances of authentication options with different subtype values. 271 If both Mobile Node to Home Agent (MN-HA) and Mobile Node to 272 Authentication Authorization Accounting server (MN-AAA) 273 authentication mobility options are present, the MN-HA authentication 274 option MUST be present before the MN-AAA authentication option (else, 275 the HA MUST discard the message). 277 When a Binding Update or Binding Acknowledgement is received without 278 an authentication option and the entity receiving it is configured to 279 use authentication option or has the shared-key based mobility 280 security association for authentication option, the entity should 281 silently discard the received message. 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Option Type | Option Length | Subtype | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Mobility SPI | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Authentication Data .... 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Figure 2 295 Option Type: 297 AUTH-OPTION-TYPE to be defined by IANA. An 8-bit identifier of 298 the type mobility option. 300 Option Length: 302 8-bit unsigned integer, representing the length in octets of 303 the Sub-type, mobility SPI and Authentication Data fields. 305 Subtype: 307 A number assigned to identify the entity and/or mechanism to be 308 used to authenticate the message. 310 Mobility SPI: 312 Mobility Security Parameter Index 314 Authentication Data: 316 This field has the information to authenticate the relevant 317 mobility entity. This protects the message beginning at the 318 Mobility Header upto and including the mobility SPI field. 320 Alignment requirements : 322 The alignment requirement for this option is 4n + 1. 324 5.1. MN-HA authentication mobility option 326 The format of the MN-HA authentication mobility option is as defined 327 in Figure 2. This option uses the subtype value of 1. The MN-HA 328 authentication mobility option is used to authenticate the Binding 329 Update and Binding Acknowledgement messages based on the shared-key 330 based security association between the Mobile Node and the Home 331 Agent. 333 The shared-key based mobility security association between Mobile 334 Node and Home Agent used within this specification consists of a 335 mobility SPI, a key, an authentication algorithm and the replay 336 protection mechanism in use. The mobility SPI is a number in range 337 [0-4294967296], where the range [0-255] is reserved. In particular, 338 the SPI selects the authentication algorithm and shared key used in 339 computing the Authenticator. In order to ensure interoperability, an 340 implementation MUST be able to associate any SPI value with any 341 authentication algorithm. In addition, all implementations MUST 342 implement the default authentication algorithm, HMAC_SHA1. Other 343 algorithms are allowed but are not specified in this document. The 344 shared-key consists of an arbitrary value and is 20 octets in length. 346 The replay protection mechanism may use the sequence number as 347 specified in [RFC3775] or the Timestamp option as defined in 348 Section 6. If the Timestamp option is used for replay protection as 349 defined in Section 6, the mobility security association includes a 350 "close enough" field to account for clock drift. A default value of 351 7 seconds SHOULD be used. This value SHOULD be greater than 3 352 seconds. 354 The MN-HA authentication mobility option MUST be the last option in a 355 message with mobility header if it is the only authentication option 356 in the message. 358 The authentication data is calculated on the message starting from 359 the mobility header upto and including the mobility SPI value of this 360 option. 362 Authentication Data = First (96, HMAC_SHA1(MN-HA Shared key, Mobility 363 Data)) 365 Mobility Data = care-of address | home address | Mobility Header(MH) 366 Data 368 MH Data is the content of the Mobility Header upto and including the 369 mobility SPI field of the Mobility message authentication option. 370 The Checksum field in Mobility Header MUST be set to 0 to calculate 371 the Mobility Data. 373 5.1.1. Processing Considerations 375 The assumption is that Mobile Node has a shared-key based security 376 association with the Home Agent. The Mobile Node MUST include this 377 option in a BU if it has a shared-key based mobility security 378 association with the Home Agent. The Home Agent MUST include this 379 option in the BA if it received this option in the corresponding BU 380 and Home Agent has a shared-key based mobility security association 381 with the Mobile Node. 383 The Mobile Node or Home Agent receiving this option MUST verify the 384 authentication data in the option. If authentication fails, the Home 385 Agent MUST send BA with Status Code MIPV6-AUTH-FAIL. If the Home 386 Agent does not have shared-key based mobility SA, Home Agent MUST 387 discard the BU. The Home Agent MAY log such events. 389 5.2. MN-AAA authentication mobility option 391 The format of the MN-AAA authentication mobility option is as defined 392 in Figure 2. This option uses the subtype value of 2. The MN-AAA 393 authentication mobility option is used to authenticate the Binding 394 Update message based on the shared mobility security association 395 between Mobile Node and AAA server in Home network (HAAA). It is not 396 used in Binding Acknowledgement messages. The corresponding Binding 397 Acknowledgement messages must be authenticated using the MN-HA 398 authentication option Section 5.1. 400 This must be the last option in a message with mobility header. The 401 corresponding response MUST include the MN-HA Authentication option, 402 and MUST NOT include the MN-AAA Authentication option. 404 The Mobile Node MAY use Mobile Node Identifier option [RFC4283] to 405 enable the Home Agent to make use of available AAA infrastructure. 407 The authentication data is calculated on the message starting from 408 the mobility header upto and including the mobility SPI value of this 409 option. 411 The authentication data shall be calculated as follows: 413 Authentication data = hash_fn(MN-AAA Shared key, MAC_Mobility Data) 415 hash_fn() is decided by the value of mobility SPI field in the 416 authentication option. 418 SPI = HMAC_SHA1_SPI: 420 If mobility SPI has the well-known value HMAC_SHA1_SPI, then 421 hash_fn() is HMAC_SHA1. When HMAC_SHA1_SPI is used, the BU is 422 authenticated by AAA using HMAC_SHA1 authentication. In that case, 423 MAC_Mobility Data is calculated as follows: 425 MAC_Mobility Data = SHA1(care-of address | home address | MH Data) 427 MH Data is the content of the Mobility Header upto and including the 428 mobility SPI field of this option. 430 5.2.1. Processing Considerations 432 The use of the MN-AAA authentication option assumes that AAA entities 433 at the home site communicate with the HA via an authenticated 434 channel. Specifically, a BU with the MN-AAA authentication option is 435 authenticated via a home AAA server. The specific details of the 436 interaction between the HA and the AAA server is beyond the scope of 437 this document. 439 When the Home Agent receives a Binding Update with the MN-AAA 440 authentication option, the Binding Update is authenticated by an 441 entity external to the Home Agent, typically a AAA server. 443 5.3. Authentication Failure Detection at the Mobile Node 445 In case of authentication failure, the Home Agent MUST send a Binding 446 Acknowledgement with status code MIPV6-AUTH-FAIL to the Mobile Node, 447 if a shared-key based mobility security association to be used 448 between Mobile Node and Home Agent for authentication exists. If 449 there is no shared-key based mobility security association, HA MUST 450 silently discard the Binding Update. HA may log the message for 451 administrative action. 453 Upon receiving a Binding Acknowledgement with status code MIPV6-AUTH- 454 FAIL, the Mobile Node SHOULD stop sending new Binding Updates to the 455 Home Agent. 457 6. Mobility message replay protection option 459 The Mobility message replay protection option MAY be used in Binding 460 Update/Binding Acknowledgement messages when authenticated using the 461 mobility message authentication option as described in Section 5. 463 The mobility message replay protection option is used to let the Home 464 Agent verify that a Binding Update has been freshly generated by the 465 Mobile Node and not replayed by an attacker from some previous 466 Binding Update. This is especially useful for cases where the Home 467 Agent does not maintain stateful information about the Mobile Node 468 after the binding cache entry has been removed. The Home Agent does 469 the replay protection check after the Binding Update has been 470 authenticated. The mobility message replay protection option when 471 included is used by the Mobile Node for matching BA with BU. 473 If this mode of replay protection is used, it needs to be part of the 474 shared-key based mobility security association. 476 If the policy at Home Agent mandates replay protection using this 477 option (as opposed to the sequence number in Mobility Header in 478 Binding Update) and the Binding Update from Mobile Node does not 479 include this option, Home Agent discards the BU and sets the Status 480 Code in BA to MIPV6-MESG-ID-REQD. 482 When the Home Agent receives the mobility message replay protection 483 option in Binding Update, it MUST include the mobility message replay 484 protection option in Binding Acknowledgement. Appendix A provides 485 details regarding why the mobility message replay protection option 486 MAY be used when using the authentication option. 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Option Type | Option Length | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Timestamp ... | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Timestamp | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 Figure 3 500 Option Type: 502 MESG-ID-OPTION-TYPE to be defined by IANA. An 8-bit identifier 503 of the type mobility option. 505 Option Length: 507 8-bit unsigned integer, representing the length in octets of 508 the Timestamp field. 510 Timestamp: 512 This field carries the 64 bit timestamp. 514 Alignment requirements : 516 The alignment requirement for this option is 8n + 2. 518 The basic principle of timestamp replay protection is that the node 519 generating a message inserts the current time of day, and the node 520 receiving the message checks that this timestamp is sufficiently 521 close to its own time of day. Unless specified differently in the 522 shared-key based mobility security association between the nodes, a 523 default value of 7 seconds MAY be used to limit the time difference. 524 This value SHOULD be greater than 3 seconds. The two nodes must have 525 adequately synchronized time-of-day clocks. 527 The Mobile Node MUST set the Timestamp field to a 64-bit value 528 formatted as specified by the Network Time Protocol [RFC1305]. The 529 low-order 32 bits of the NTP format represent fractional seconds, and 530 those bits which are not available from a time source SHOULD be 531 generated from a good source of randomness. Note, however, that when 532 using timestamps, the 64-bit Timestamp used in a Binding Update from 533 the Mobile Node MUST be greater than that used in any previous 534 successful Binding Update. 536 After successful authentication of Binding Update (either locally at 537 the Home Agent or when a success indication is received from the AAA 538 server), the Home Agent MUST check the Timestamp field for validity. 539 In order to be valid, the timestamp contained in the Timestamp field 540 MUST be close enough to the Home Agent's time of day clock and the 541 timestamp MUST be greater than all previously accepted timestamps for 542 the requesting Mobile Node. 544 If the timestamp is valid, the Home Agent copies the entire Timestamp 545 field into the Timestamp field in the BA it returns to the Mobile 546 Node. If the timestamp is not valid, the Home Agent copies only the 547 low-order 32 bits into the BA, and supplies the high-order 32 bits 548 from its own time of day. 550 If the timestamp field is not valid but the authentication of the BU 551 succeeds, Home Agent MUST send a Binding Acknowledgement with status 552 code MIPV6-ID-MISMATCH. The Home Agent does not create a binding 553 cache entry if the timestamp check fails. 555 If the Mobile Node receives a Binding Acknowledgement with the code 556 MIPV6-ID-MISMATCH, the Mobile Node MUST authenticate the BA by 557 processing the MN-HA authentication mobility option. 559 If authentication succeeds, the Mobile Node MUST adjust its timestamp 560 and send subsequent Binding Update using the updated value. 562 Upon receiving a BA that does not contain the MIPV6-ID-MISMATCH 563 status code, the Mobile Node MUST compare the Timestamp value in the 564 BA to the Timestamp value it sent in the corresponding BU. If the 565 values match, the Mobile Node proceeds to process the MN-HA 566 authentication data in the BA. If the values do not match, the 567 Mobile Node silently discards the BA. 569 7. Security Considerations 571 This document proposes new authentication options to authenticate the 572 control message between Mobile Node, Home Agent and/or home AAA (as 573 an alternative to IPsec). The new options provide for authentication 574 of Binding Update and Binding Acknowledgement messages. The MN-AAA 575 authentication options provides for authentication with AAA 576 infrastructure. 578 This specification also introduces an optional replay protection 579 mechanism in Section 6, to prevent replay attacks. The sequence 580 number field in the Binding Update is not used if this mechanism is 581 used. This memo defines the timestamp option to be used for mobility 582 message replay protection. 584 8. IANA Considerations 586 IANA services are required for this specification. The values for 587 new mobility options and status codes must be assigned from the 588 Mobile IPv6 [RFC3775] numbering space. 590 The values for Mobility Option types AUTH-OPTION-TYPE and MESG-ID- 591 OPTION-TYPE, as defined in Section 5 and Section 6 need to be 592 assigned. The suggested values are 8 for the AUTH-OPTION-TYPE and 9 593 for the MESG-ID-OPTION-TYPE Mobility Option. 595 The values for status codes MIPV6-ID-MISMATCH, MIPv6-AUTH-FAIL and 596 MIPV6-MESG-ID-REQD as defined in Section 6, Section 6 and Section 5.3 597 also need to be assigned. The suggested values are 144 for MIPV6-ID- 598 MISMATCH 145 for MIPV6-MESG-ID-REQD and 146 for MIPV6-AUTH-FAIL. 600 IANA should record values for these new Mobility Options and the new 601 Status Codes. 603 A new section for enumerating algorithms identified by specific 604 mobility SPIs within the range 0-255 is to be added to 606 http://www.isi.edu/in-notes/iana/assignments/mobility-parameters 608 The currently defined values are as follows: 610 The value 0 should not be assigned. 612 The value 3 is suggested for HMAC_SHA1_SPI as defined in Section 5.2. 614 The value 5 is reserved for use by 3GPP2. 616 New values for this namespace can be allocated using IETF Consensus. 617 [RFC2434]. 619 In addition, IANA needs to create a new namespace for the subtype 620 field of the MN-HA and MN-AAA authentication mobility options under 622 http://www.isi.edu/in-notes/iana/assignments/mobility-parameters 624 The currently allocated values are as follows: 626 1 MN-HA authentication mobility option Section 5.1 628 2 MN-AAA authentication mobility option Section 5.2 630 New values for this namespace can be allocated using IETF Consensus. 631 [RFC2434]. 633 9. Acknowledgements 635 The authors would like to thank Basavaraj Patil, Charlie Perkins 636 Vijay Devarapalli, Jari Arkko and Gopal Dommety for their thorough 637 review and suggestions on the document. The authors would like to 638 acknowledge the fact that a similar authentication method was 639 considered in base protocol [RFC3775] at one time. Many thanks to 640 Hannes Tschofenig and Jouni Korhonen for their detailed review and 641 comments. 643 10. References 645 10.1. Normative References 647 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 648 Specification, Implementation", RFC 1305, March 1992. 650 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 651 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 652 October 1998. 654 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 655 August 2002. 657 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 658 in IPv6", RFC 3775, June 2004. 660 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 661 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 662 (MIPv6)", RFC 4283, November 2005. 664 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 665 RFC 4306, December 2005. 667 10.2. Informative References 669 [3GPP2] "cdma2000 Wireless IP Network Standard", 3GPP2 X.S0011-D, 670 September 2005. 672 [whyauth] Patil et. al., B., "Why Authentication Data suboption is 673 needed for MIPv6", 674 draft-ietf-mip6-whyauthdataoption-04.txt (work in 675 progress), August 2007. 677 Appendix A. Rationale for mobility message replay protection option 679 Mobile IPv6 [RFC3775] defines a Sequence Number in the mobility 680 header to prevent replay attacks. There are two aspects that stand 681 out in regards to using the Sequence Number to prevent replay 682 attacks. 684 Firstly, the specification states that Home Agent should accept a BU 685 with a Sequence Number greater than the Sequence Number from previous 686 Binding Update. This implicitly assumes that the Home Agent has some 687 information regarding the Sequence Number from previous BU (even when 688 the binding cache entry is not present). Secondly, the specification 689 states that if the Home Agent has no binding cache entry for the 690 indicated home address, it MUST accept any Sequence Number value in a 691 received Binding Update from this Mobile Node. 693 With the mechanism defined in this draft, it is possible for the 694 Mobile Node to register with a different Home Agent during each 695 mobility session. Thus, it is unreasonable to expect each Home Agent 696 in the network to maintain state about the Mobile Node. Also, if the 697 Home Agent does not cache information regarding sequence number, as 698 per the second point above, a replayed BU can cause a Home Agent to 699 create a binding cache entry for the Mobile Node. Thus, when 700 authentication option is used, Sequence Number does not provide 701 protection against replay attack. 703 One solution to this problem (when Home Agent does not save state 704 information for every Mobile Node) would be for the Home Agent to 705 reject the first BU and assign a (randomly generated) starting 706 sequence number for the session and force the Mobile Node to send a 707 fresh BU with the suggested sequence number. While this would work 708 in most cases, it would require an additional round trip and this 709 extra signalling and latency is not acceptable in certain deployments 710 [3GPP2]. Also, this rejection and using sequence number as a nonce 711 in rejection is a new behavior that is not specified in [RFC3775]. 713 Thus, this specification uses the mobility message replay protection 714 option to prevent replay attacks. Specifically, timestamps are used 715 to prevent replay attacks as described in Section 6. 717 It is important to note that as per Mobile IPv6 [RFC3775] this 718 problem with sequence number exists. Since the base specification 719 mandates the use of IPsec (and naturally that goes with IKE in most 720 cases), the real replay protection is provided by IPsec/IKE. In case 721 of BU/BA between Mobile Node and CN, the liveness proof is provided 722 by the use of nonces which the CN generates. 724 Appendix B. Change Log 726 B.1. Key length change 728 Changed the key length to 20 octets from 16 octets in section 729 Section 5.1 731 B.2. Changed IKEv2 draft number to RFC 733 In the reference section. 735 B.3. Text removed in applicability statement 737 Removed IKEv2 related text in section Section 1.1 739 Authors' Addresses 741 Alpesh Patel 742 Cisco Systems 743 170 W. Tasman Drive 744 San Jose, CA 95134 745 US 747 Phone: +1 919-392-5626 748 Email: alpesh@cisco.com 750 Kent Leung 751 Cisco Systems 752 170 W. Tasman Drive 753 San Jose, CA 95134 754 US 756 Phone: +1 408-526-5030 757 Email: kleung@cisco.com 759 Mohamed Khalil 760 Nortel Networks 761 2221 Lakeside Blvd. 762 Richardson, TX 75082 763 US 765 Phone: +1 972-685-0574 766 Email: mkhalil@nortel.com 768 Haseeb Akhtar 769 Nortel Networks 770 2221 Lakeside Blvd. 771 Richardson, TX 75082 772 US 774 Phone: +1 972-684-4732 775 Email: haseebak@nortel.com 776 Kuntal Chowdhury 777 Starent Networks 778 30 International Place 779 Tewksbury, MA 01876 780 US 782 Phone: +1 214-547-7307 783 Email: kchowdhury@starentnetworks.com 785 Full Copyright Statement 787 Copyright (C) The IETF Trust (2007). 789 This document is subject to the rights, licenses and restrictions 790 contained in BCP 78, and except as set forth therein, the authors 791 retain all their rights. 793 This document and the information contained herein are provided on an 794 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 795 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 796 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 797 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 798 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 799 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 801 Intellectual Property 803 The IETF takes no position regarding the validity or scope of any 804 Intellectual Property Rights or other rights that might be claimed to 805 pertain to the implementation or use of the technology described in 806 this document or the extent to which any license under such rights 807 might or might not be available; nor does it represent that it has 808 made any independent effort to identify any such rights. Information 809 on the procedures with respect to rights in RFC documents can be 810 found in BCP 78 and BCP 79. 812 Copies of IPR disclosures made to the IETF Secretariat and any 813 assurances of licenses to be made available, or the result of an 814 attempt made to obtain a general license or permission for the use of 815 such proprietary rights by implementers or users of this 816 specification can be obtained from the IETF on-line IPR repository at 817 http://www.ietf.org/ipr. 819 The IETF invites any interested party to bring to its attention any 820 copyrights, patents or patent applications, or other proprietary 821 rights that may cover technology that may be required to implement 822 this standard. Please address the information to the IETF at 823 ietf-ipr@ietf.org. 825 Acknowledgment 827 Funding for the RFC Editor function is provided by the IETF 828 Administrative Support Activity (IASA).