idnits 2.17.00 (12 Aug 2021) /tmp/idnits13627/draft-haddad-mipshop-fmipv6-auth-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 437. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 444. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 450. ** 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. 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 21, 2006) is 5714 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) -- No information found for draft-haddad-mipshop-optisend- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'OptiSEND' -- Possible downref: Normative reference to a draft: ref. 'RFC4068' Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIPSHOP Working Group W. Haddad 3 Internet-Draft S. Krishnan 4 Expires: March 25, 2007 Ericsson Research 5 September 21, 2006 7 Authenticating FMIPv6 Handovers 8 draft-haddad-mipshop-fmipv6-auth-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on March 25, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document specifies a scheme to secure the handover signaling in 42 FMIPv6 using one way hash chains. The values generated in a one way 43 hash chain will be used one at a time during each handoff to 44 authenticate the signaling messages. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Conventions used in this document . . . . . . . . . . . . . . 4 50 3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 6 52 5. New Options . . . . . . . . . . . . . . . . . . . . . . . . . 9 53 5.1. Hash Handoff Option (HHO) . . . . . . . . . . . . . . . . 9 54 5.2. Hash Extension Option (HEO) . . . . . . . . . . . . . . . 9 55 5.3. Handoff Vector Option (HVO) . . . . . . . . . . . . . . . 10 56 5.4. Handoff Option (HO) . . . . . . . . . . . . . . . . . . . 11 57 5.5. Hash Chain Option (HCO) . . . . . . . . . . . . . . . . . 11 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 61 Intellectual Property and Copyright Statements . . . . . . . . . . 15 63 1. Introduction 65 FMIPv6 protocol (described in [RFC4068]) specifies a fast handoff 66 procedure for IPv6 mobile nodes, which is based on tunneling data 67 packets between the mobile node's previous and new access routers 68 (ARs). The FMIPv6 protocol specification does not provide a method 69 to establish a handoff key to secure the FMIPv6 signaling messages 70 between the MN and the AR. Current proposed schemes require 71 generation of a handoff key at each handover in order to secure the 72 handoff signaling. 74 This draft suggests a mechanism based on the one-way hash chain 75 technique to authenticate the handoff signaling messages without the 76 burden of generating one "handoff key" by using public keys, per 77 handoff procedure. Values generated in a OWHC will be used one at a 78 time during each handoff to authenticate the signaling messages. 80 2. Conventions used in this document 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 3. Glossary 88 One Way Hash Chain (OWHC) 90 A one way chain (Vo...Vn) is a collection of values such that each 91 value Vi (except the last value Vn) is a one-way function of the 92 next value Vi+1. In particular, we have Vi = H(Vi+1), for i 93 belonging to [0,n[. For clarity purpose and to avoid confusion, 94 we'll use in the rest of this document the notation V[i] instead 95 of Vi, which means V[i+1] points to Vi+1... 97 Fast Binding Update (FBU) 99 A message from the MN instructing its PAR to redirect its traffic 100 towards the nAR. 102 Previous Access Router (pAR) 104 The MN's default router prior to its handover. 106 New Access Router (nAR) 108 The MN's default router subsequent to its handover. 110 Fast Binding Acknowledgment (FBA) 112 A message from the pAR in response to an FBU. 114 4. Protocol Operation 116 In order to avoid using heavy cryptographic operations and redundant 117 signaling messages to generate a handoff key each time the MN 118 switches to a new AR, the MN should be able to use simpler mechanisms 119 such as OWHC technique in order to authenticate the FBU message sent 120 to its pAR. On the other side, the network access infrastructure 121 should also provide the MN enough assurance that the FBA message is 122 coming from the same AR, which received the FBU message. 124 Furthermore, it is important to mention that a fast growing class of 125 mobile devices tend to have very limited battery and processing 126 power. Thus the available energy must be meticulously controlled and 127 consumed, i.e., not to be wasted on exchanging unnecessary redundant 128 signaling messages nor on computing unnecessary RSA signatures. 129 Consequently, care should be taken to rely whenever possible on low 130 processing power operations and to minimize the amount of signaling 131 messages sent from the MN. 133 The suggested protocol allows an FMIPv6 enabled MN to generate a OWHC 134 (e.g., 20 values) prior to triggering the first fast handoff 135 procedure (i.e., sending an FBU message following the receipt of a 136 PrRtAdv message from its AR). The length of each value of the OWHC 137 SHOULD be equal to 128 bits and SHOULD be used together with another 138 parameter to generate each nCoA interface identifier (IID). 140 In order to minimize using expensive processing power operations, the 141 MN SHOULD use the SEND procedure only at the beginning, i.e., when 142 switching for the first time to another AR. In this case, the MN 143 sends a RtSol message signed with CGA to its current AR, prior to 144 triggering a fast handoff procedure. The RtSol message SHOULD carry 145 the tip of the MN's OWHC in a new option called the "hash handoff" 146 option (HHO). 148 Upon receiving a RtSol message carrying an HHO, the AR SHOULD reply 149 by sending confidentially a 64-bit unique parameter called "Handoff 150 Vector" (HV). For this purpose, the AR MUST encrypt the HV with the 151 MN's CGA public key and inserts it in a unicast RtAdv message before 152 sending it to the MN. The AR SHOULD also store the sender's current 153 IPv6 address, the associated OWHC value and the corresponding HV in 154 its mobile cache entries (MCE) for a limited lifetime. 156 Note that an additional optimization would mainly target the use of 157 CGA technology and would consist on using the Optimized SEND protocol 158 (described in [OptiSEND]). 160 In order to respect the MN's privacy, the HV will be used to hide any 161 correlation between the MN's nCoA and the previous CoA (pCoA). This 162 is achieved by using a simple computation involving the HV and the 163 MN's CoAs. 164 In addition, upon receiving a valid FBU message from the MN, the AR 165 SHOULD hash the current HV value then forward the first 64-bit value 166 of the resulting hash, i.e., new HV, to the MN's nAR. The new HV 167 (nHV) is inserted in a new option carried by the Handoff Initiate 168 (HI) message. Note that we assume that all links between ARs are 169 secure and the network access infrastructure can be trusted. 171 When the MN performs a fast handoff procedure (other than the first 172 one), it starts by autoconfiguring a new CoA. For this purpose, it 173 has to compute the nCoA IID. This is done in the following way: 175 nCoA (IID) = First [64, OWHC(NV)) XOR First(64, nHV)] 177 The rule to generate the nHV is the following: 179 nHV = First[64, SHA1((n-1)HV)] 181 Where: 183 - OWHC(NV) is the next 128-bit undisclosed value from the MN's OWHC. 184 - First(x,y) is a function which extracts the first "x" bits from 185 "y". 186 - nHV is the new HV value received by the MN's nAR and (n-1) is the 187 previous value used by the MN's pAR to check the validity of the FBU 188 message. 190 After generating the nCoA's IID, the MN generates another 64-bit 191 value from XORing the remaining 64-bit of the OWHC(NV) with nHV. The 192 resulting value is called "Hash Extension" (HE) value and is sent in 193 a new option carried by the FBU message. The last step is to 194 authenticate the FBU message with the 128-bit OWHC(NV) and insert the 195 result in the BAD. 197 Procedures to exchange FBU/FBA messages between the MN and ARs are 198 described in the following: 200 Upon receiving an FBU message, the AR (i.e., the pAR which has 201 generated the HV) checks its MCE for an entry containing the MN's 202 pCoA. If the MN's pCoA is found, then the pAR decodes the nCoA IID 203 by using its nHV then it decodes the HE value and concatenates the 204 result with the nCoA's IID. The next step consists on hashing the 205 concatenation of the two decoded values and comparing the first 128 206 bits of the resulting hash to the 128-bit OWHC disclosed value stored 207 in the MN's corresponding entry. 208 If the two values are equal, then the pAR proceeds to check the 209 authenticity of the BU message and sends an FBA message to the MN. 211 The FBA message MUST be authenticated with the same key, i.e., 212 OWHC(NV), in order for the MN to check if the FBA message has been 213 sent by the same entity which has received the MN's corresponding HV 214 and the FBU message. 215 Note that the 128-bit OWHC value SHOULD be forwarded by the pAR to 216 the nAR in the HI message. For this purpose, a new option called 217 "Hash Chain" Option (HCO) is defined to carry the OWHC value in the 218 HI message. 220 When the nAR gets an HI message carrying an HV, it SHOULD store it 221 together with the MN's nCoA in its cache memory for future use. As 222 mentioned earlier, after using SEND protocol with the first AR, any 223 subsequent AR visited by the MN MUST NOT use the same HV value used 224 by the previous one. The same requirement applies also to the MN, 225 which has to hash again its current HV value before using it to 226 compute the nCoA IID. 228 5. New Options 230 This proposal defines 5 new options described in the following: 232 5.1. Hash Handoff Option (HHO) 234 This option is used to carry a 128-bit value, which is the tip of the 235 MN's OWHC. The HHO is carried by the RtSol message sent by the MN to 236 its current AR. 238 The format of the option is the following: 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Option Type | 16 | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | | 246 | | 247 | Vi | 248 | | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 Option Type 252 254 Option Length 255 16 257 Option Data 258 This contains the value at the tip of the hash chain. 260 5.2. Hash Extension Option (HEO) 262 This option is used to carry the 64-bit value, which is generated 263 from XORing the leftmost 64 bits extracted from the 128-bit OWHC(NV) 264 with the first 64 bits resulting from hashing HV (or re-hashing). 265 The HEO is carried by the FBU message sent by the MN to the pAR. 267 The format of the option is the following: 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Option Type | 8 | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | HE | 275 | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Option Type 279 281 Option Length 282 8 284 Option Data 285 Contains the 64-bit HE, which is used by the MN to provide the pAR 286 the ability to discover the entire OWHC(NV), i.e., the new shared 287 secret, in order to check the authenticity of the FBU message and to 288 authenticate the FBA message. 290 5.3. Handoff Vector Option (HVO) 292 This option is carried by the RtAdv message sent by the AR after 293 receiving a RtSol message carrying an HHO. The HVO is used to carry 294 the 64-bit handoff vector. 296 The format of the option is the following: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Option Type | 8 | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | HV | 304 | | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Option Type 308 310 Option Length 311 8. 313 Option Data 314 Contains the 64-bit HV, which is the used by the MN to prevent 315 correlation between its different CoAs generated from the same OWHC, 316 and by the AR to decode the MN's CoA(s) and the HE value prior to 317 hashing the combination and checking the validity of the FBU message. 318 Note that the HV value is hashed by the MN at each handoff and by 319 each nAR before storing it in the corresponding MCE. 321 5.4. Handoff Option (HO) 323 This option is carried by the HI message sent by the pAR to the nAR 324 upon receiving a valid FBU message. The HO carries the 64-bit HV in 325 order to allow the nAR to check the validity of the FBU message sent 326 by the MN to its nAR. 328 The format of the option is the following: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Option Type | 8 | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | HV | 336 | | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Option Type 340 342 Option Length 343 8. 345 Option Data 346 Contains the 64-bit HV. 348 5.5. Hash Chain Option (HCO) 350 This option is carried by the HI message sent by the pAR to the nAR 351 upon receiving a valid FBU message. The HCO carries the 128-bit OWHC 352 value computed by the MN's pAR from data received in the FBU message 353 sent by the MN. 355 The format of the option is the following: 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Option Type | 16 | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | | 363 | HC | 364 | | 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 Option Type 369 371 Option Length 372 16 374 Option Data 375 Contains the last disclosed 128-bit value from the MN's OWHC. 377 6. Security Considerations 379 This document specifies a simple scheme to secure the handover 380 signaling using one way hash chains. The values generated in a one 381 way hash chain will be used one at a time during each handover to 382 secure the fast mobility signaling. 383 The suggested proposal relies also on the assumption that a trust 384 relationship between the MN and the network access infrastructure 385 exists in order to guarantee that the HV parameter won't be forwarded 386 to a malicious node at a particular time. 388 The suggested proposal fulfills the requirements dictated by low 389 processing and battery power mobile devices regarding the number of 390 signaling messages sent by the mobile node and the use of RSA 391 signatures, without creating nor amplifying new and/or existing 392 threats. 394 7. References 396 [OptiSEND] 397 Haddad, W., Krishnan, S., and J. Choi, "Secure Neighbor 398 Discovery (SEND) Optimization and Adaptation for Mobility: 399 The OptiSEND protocol", Internet 400 Draft, draft-haddad-mipshop-optisend- 01.txt, June 2006. 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", RFC 2119, March 1997. 405 [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", Internet 406 Draft, draft-ietf-mipshop-fmipv6-rev-00.txt, April 2006. 408 Authors' Addresses 410 Wassim Haddad 411 Ericsson Research 412 Torshamnsgatan 23 413 SE-164 80 Stockholm 414 Sweden 416 Phone: +46 8 4044079 417 Email: Wassim.Haddad@ericsson.com 419 Suresh Krishnan 420 Ericsson Research 421 8400 Decarie Blvd. 422 Town of Mount Royal, QC 423 Canada 425 Phone: +1 514 3457900 426 Email: Suresh.Krishnan@ericsson.com 428 Intellectual Property Statement 430 The IETF takes no position regarding the validity or scope of any 431 Intellectual Property Rights or other rights that might be claimed to 432 pertain to the implementation or use of the technology described in 433 this document or the extent to which any license under such rights 434 might or might not be available; nor does it represent that it has 435 made any independent effort to identify any such rights. Information 436 on the procedures with respect to rights in RFC documents can be 437 found in BCP 78 and BCP 79. 439 Copies of IPR disclosures made to the IETF Secretariat and any 440 assurances of licenses to be made available, or the result of an 441 attempt made to obtain a general license or permission for the use of 442 such proprietary rights by implementers or users of this 443 specification can be obtained from the IETF on-line IPR repository at 444 http://www.ietf.org/ipr. 446 The IETF invites any interested party to bring to its attention any 447 copyrights, patents or patent applications, or other proprietary 448 rights that may cover technology that may be required to implement 449 this standard. Please address the information to the IETF at 450 ietf-ipr@ietf.org. 452 Disclaimer of Validity 454 This document and the information contained herein are provided on an 455 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 456 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 457 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 458 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 459 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 460 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 462 Copyright Statement 464 Copyright (C) The Internet Society (2006). This document is subject 465 to the rights, licenses and restrictions contained in BCP 78, and 466 except as set forth therein, the authors retain all their rights. 468 Acknowledgment 470 Funding for the RFC Editor function is currently provided by the 471 Internet Society.