idnits 2.17.1 draft-jung-mipshop-secure-efficient-handover-01.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, updated by RFC 4748 on line 638. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 622. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 628. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 25, 2008) is 5904 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) == Outdated reference: A later version (-07) exists of draft-ietf-mipshop-fmipv6-rfc4068bis-05 ** Obsolete normative reference: RFC 3775 (ref. '3') (Obsoleted by RFC 6275) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MIPSHOP Working Group Souhwan Jung 2 Internet Draft Jaeduck Choi 3 Expires: August 25, 2008 Soongsil University 4 February 25, 2008 6 A Secure and Efficient Handover Authentication in FMIP6 7 draft-jung-mipshop-secure-efficient-handover-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 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 August 25, 2008. 35 Abstract 37 This document describes a secure and efficient handover 38 authentication (SEHA) protocol in FMIP6. The main idea is using the 39 Diffie-Hellman (DH) algorithm to enhance security aspects, and is 40 modifying the DH key exchange to reduce computational cost at the 41 Mobile Node (MN) by delegating exponential operation to the Access 42 Router (AR). The MN and NAR establish the handover key HK_NAR through 43 the PAR instead of the AAA server at any convenient time while the MN 44 belongs to the NAR domain. The HK_NAR is used for handover 45 authentication when the MN moves from the NAR to the next NAR. The 46 main advantage of this document is more secure and suitable to a 47 light-weight mobile terminal than the existing handover 48 authentication scheme using SEND. 50 Table of Contents 52 1. Introduction..................................................3 53 2. Terminology...................................................3 54 3. Protocol Overview.............................................4 55 4. Protocol Details..............................................6 56 4.1. MN Behavior..............................................8 57 4.2. PAR Behavior.............................................9 58 4.3. NAR Behavior.............................................9 59 5. Message Formats..............................................10 60 5.1. Handover Authentication Request (HAReq).................10 61 5.2. Handover Authentication Response (HAResp)...............11 62 5.3. Options.................................................12 63 6. Security Considerations......................................13 64 7. IANA Considerations..........................................14 65 8. References...................................................14 66 8.1. Normative References....................................14 67 Author's Addresses..............................................15 68 Intellectual Property Statement.................................15 69 Disclaimer of Validity..........................................16 70 Copyright Statement.............................................16 71 Acknowledgment..................................................16 73 1. Introduction 75 In the mobile IP networks [2],[3], the handover authentication should 76 be provided to protect signaling messages against security 77 vulnerabilities such as the Denial of Service (DoS) attack or the 78 intercept attack by packet redirection. Also, it should require less 79 computing power to be suitable for a light-weight mobile terminal. 81 The distributing handover key scheme using SEND [4] provides good 82 security features without resorting to the AAA server. However, there 83 are potential problems such as a Sybil attack (forging identities) 84 and DoS attack due to using self-generated private/public key pairs. 85 The Secure Neighbor Discovery (SEND) [5] based on Cryptographically 86 Generated Addresses (CGA) [6] is weak against the Sybil attack, in 87 which the attacker uses several invented addresses so that a 88 legitimate node can believe many other nodes to be around. This Sybil 89 attack also causes the AR to be vulnerable to the DoS attack. For 90 example, if the AR receives a number of forged requests, it should 91 perform many verification and encryption operations based on public 92 key algorithm to distribute handover keys. Also, this scheme requires 93 computational overhead at the MN such as RSA signature and decryption 94 for distributing a symmetric FMIPv6 handover key. 96 This document describes a secure and efficient handover 97 authentication (SEHA) based on a light-weight DH key exchange without 98 the AAA server. The MN and the NAR (AR_i+1) establish the handover 99 key HK_NAR (HK_i+1) through the PAR (AR_i) after exchanging both the 100 RtSolPr and PrRtAdv messages while the MN belongs to the NAR domain. 101 The SEHA also supports a robust security feature against DoS attack 102 than the existing handover authentication scheme using SEND. Also, it 103 requires less computation at the MN by delegating the DH half-key 104 generation to the AR. 106 This document defines two messages HAResq and HAResp, and new options 107 to carry out handover authentication. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC-2119 [1]. 115 New terminologies are defined in this memo. 117 Handover Authentication Request (HAReq): 118 HAReq is a message to deliver parameters for the handover 119 authentication to the AR. 121 Handover Authentication Response (HAResp): 122 HAResp is a message to deliver parameters for the handover 123 authentication to the MN, and notify the MN of the success or 124 failure of the handover authentication. 126 HK_i : 127 Handover key between the MN and AR_i for securing FBU message 129 3. Protocol Overview 131 In our scheme, there are two assumptions. First, the MN and AAA 132 server perform an initial full EAP authentication [7][8] during a 133 bootstrapping resulting that a master key is established between 134 them. Hence, the MN and AR share a Handover Key (HK) that is derived 135 from the master key. The second assumption is that a secure channel 136 exists among the ARs using the TLS or IPSec to protect handover 137 authentication messages among them. 139 The basic idea of our scheme is using the DH key exchange to enhance 140 security aspects, and is modifying the DH algorithm to reduce 141 computational cost at the MN by delegating exponential operation to 142 the AR. This feature is more secure and suitable to a light-weight 143 mobile terminal than the existing schemes. The other idea is that the 144 MN and the NAR (AR_i+1) establish the handover key HK_NAR (HK_i+1) 145 through the PAR (AR_i) instead of the AAA server after exchanging 146 both RtSolPr and PrRtAdv messages with the NAR while the MN belongs 147 to the NAR domain. In other words, the MN establishes the new 148 Security Association (SA) between the MN and the NAR using the old SA 149 between the MN and the PAR. The HK_NAR (HK_i+1) is used for handover 150 authentication when the MN moves from the NAR (AR_i+1) to the next 151 NAR (AR_i+2). 153 Figure 1 shows the sequential steps of a proposed SEHA scheme in 154 FMIPv6. The AAA server takes part only in the bootstrapping 155 authentication procedure. The MN and the AR_1 share the key HK_1 156 after the bootstrapping authentication. When the MN moves from the 157 AR_1 to the AR_2, the MN protects the FBU message using the HK_1. The 158 MN in the AR_2 domain may exchange the HK_2 with the AR_2 to protect 159 the FBU message for the next handover. This key exchange procedure is 160 achieved among the AR_1, AR_2, and MN without the AAA server. The 161 AR_1 authenticates the MN using the Message Authentication Code (MAC) 162 with the HK_1. If the validation is successful, the MN and AR_2 163 generate a new handover key HK_2 using the DH key exchange. The MN 164 and AR_2 SHOULD cache the HK_2 during their lifetime. The HK_2 is 165 used for handover authentication when the MN moves from the AR_2 to 166 the next AR (AR_3). The MN repeats the same procedure whenever it 167 handovers. 169 Step 1 170 - Bootstrapping authentication 171 Step 2 172 - FBU procedure protected by HK_1 when MN moves from AR_1 to AR_2 173 Step 3 174 - Handover from AR_1 to AR_2 175 Step 4 176 - Authentication procedure between AR_1 and MN using HK_1 177 - Key exchange (HK_2) based on DH key exchange 178 Step 5 179 - FBU procedure protected by HK_2 when MN moves from AR_2 to AR_3 180 Step 6 181 - Handover from AR_2 to AR_3 182 _ +-----+ 183 +--------------------->| AAA | 184 | +-----+ 185 | 186 |1 187 | 188 | 189 |HK_1 HK_2 HK_i HK_i+1 190 +------+ 4 +------+ +------+ +------+ 191 | AR_1 |<------| AR_2 | ... | AR_i | |AR_i+1| 192 +------+ +------+ +------+ +------+ 193 | ^ | ^ 194 | | | | 195 | |2 |4 |5 196 | | | | 197 | | | | 198 V V V V 199 +------+ 3 +------+ 6 +------+ 200 | MN |------>| MN |----->| MN | 201 +------+ +------+ +------+ 202 HK_1 HK_1, HK_2 HK_2, HK_3 204 Figure 1 Protocol Overview. 206 4. Protocol Details 208 Figure 2 shows the protocol of the handover authentication. In Figure 209 2, the MN SHOULD generate and store a random number r and value g^r 210 after a bootstrapping authentication. 212 The MN with the HK_PAR (HK_i) moves from the PAR (AR_i) to the NAR 213 (AR_i+1) at the time T_1. Note that the MN currently belongs to the 214 NAR domain. The MN and the NAR MUST exchange a handover key HK_i+1 to 215 protect the FBU message for the next handover after exchanging both 216 RtSolPr and PrRtAdv messages with the NAR when the MN belongs to the 217 NAR domain as shown in the following figure. 219 MN NAR (AR_i+1) PAR (AR_i) 220 | | | 221 r,g^r, HK_i | |HK_i 222 | | | 223 --- T_1 : MN handovers to NAR | | 224 | | | 225 | RtSolPr | | 226 |---------------------------->| | 227 | PrRtAdv | | 228 |<----------------------------| | 229 | | | 230 x| HAReq (M_1, r+x, g^r) | | 231 |---------------------------->| |(g^(r+x) 232 | |g^y | /g^r) 233 | | HAReq (M_1, r+x, g^r, g^y | =g^x 234 | |--------------------------->| 235 | | | 236 | | HAResp (M_2, g^x) | 237 | HAResp (M_2, M_3, g^x, g^y) |<---------------------------| 238 |<----------------------------| | 239 | | | 240 HK_i+1 = g^(xy) HK_i+1 = g^(xy) 242 Figure 2 Procedure of Handover Authentication. 244 The MN generates a new random value x and computes the message M_1. 245 And then, the MN sends the HAReq message to the NAR. The HAReq 246 message contains following values. 248 M_1=H(HK_i, ID_MN||ID_PAR||ID_NAR||r+x||g^r) 249 HAReq [M_1, ID_MN, ID_PAR, ID_NAR, r+x, g^r] 251 Upon receiving the messages, the NAR generates a random number y and 252 computes its DH public key g^y. The NAR forwards the receiving 253 messages with the g^y to the PAR, which means that the integrity of 254 g^y is guaranteed by the PAR establishing the security association 255 with the MN. The HAReq message contains following values. 257 HAReq [M_1, ID_MN, ID_PAR, ID_NAR, r+x, g^r, g^y] 259 The PAR caching the MN's HK_i verifies the message M_1. If the 260 validation is successful, the PAR computes a value g^(r+x), and then 261 extracts the value g^x by computing g^(r+x)/g^r. The PAR computes the 262 M_2, and then replies with the HAResp message to the NAR. The PAR 263 also notifies the success of authentication to the NAR. The HAResp 264 message contains following values. 266 M_2=H(HK_i, ID_MN||ID_PAR||ID_NAR||g^(r+x)||g^x||g^y) 267 HAResp ["Success", M_2, ID_MN, ID_PAR, ID_NAR, g^x] 269 If the NAR receives the messages including the failure notification 270 from the PAR, the NAR notifies the MN of the failure of the handover 271 authentication. Otherwise, the NAR computes the new handover 272 authentication key HK_i+1=(g^x)^y= g^(xy) using the private key y and 273 the received value g^x from the PAR. The NAR computes M_3, and sends 274 the message HAResp to the MN. Note that the NAR SHOULD cache the 275 HK_i+1 and ID_MN for securing FBU procedure when the MN will move 276 from the NAR (AR_i+1) to the next NAR (AR_i+2). The HAResp message 277 contains following values. 279 M_3=H(g^(xy), M_2||ID_MN||ID_PAR||ID_NAR) 280 HAResp ["Success", M_2, M_3, ID_MN, ID_PAR, ID_NAR, g^x, g^y] 282 The MN computes the g^(r+x) by computing (g^r)x(g^x), and then 283 verifies the M_2. If a success, the MN computes the new handover 284 authentication key HK_i+1=(g^y)^x=g^(yx) using the private key x and 285 the public key g^y, and then verifies the M_3. If the MN fails to 286 verify the M_2 or M_3, the authentication fails. In the future, the 287 MN MUST perform securing FBU using the HK_i+1 when it moves from the 288 NAR (AR_i+1) to the next NAR (AR_i+2). 290 - Securing FBU procedure : FBU, H(HK_i+1, FBU) 292 4.1. MN Behavior 294 The MN MUST share the HK_1 with the AR_1 after initial bootstrapping 295 authentication. Also, the MN SHOULD store a random value r and value 296 g^r, and compute the exponent operation g^x by computing g^(r+x)/g^r 297 to reduce computational overhead. 299 The MN MUST use the HK_PAR (HK_i) for protecting the FBU message when 300 the MN handovers to the NAR (AR_i+1). After moving to the NAR, the MN 301 MUST initiate a HAReq message to exchange the HK_NAR (HK_i+1) with 302 the NAR. The authentication procedure MUST be performed after 303 receiving the PrRtAdv message from the NAR while the MN belongs to 304 the NAR domain. 306 If the MN receives the HAResp message including the success 307 notification from the NAR, the MN MUST generate the HK_i+1 and cache 308 it for next handover authentication. In the future, the MN MUST use 309 HK_i+1 for securing FBU between the MN and NAR when the MN moves from 310 the NAR (AR_i+1) to the next NAR (AR_i+2). 312 The MN that belongs to the NAR (AR_i+1) domain MUST store the HK_PAR 313 (HK_i) until the MN and AR_i+1 exchange the HK_NAR (HK_i+1). Also, 314 the MN SHOULD cache HK_i for its life time. If the MN comes back to 315 the PAR domain, the MN SHOULD reuse its HK_i. 317 4.2. PAR Behavior 319 The channels among the ARs SHOULD be established by the IPsec or TLS. 320 Upon receiving a HAReq message from the NAR (AR_i+1), the PAR (AR_i) 321 MUST verify the value M_1 in the HAReq message using the HK_i shared 322 with the MN. If the PAR fails to verify the M_1, the PAR MUST send a 323 HAResp message including the failure of authentication to the NAR, 324 and ignore the received HAReq message. Otherwise, the PAR MUST 325 compute a g^x by computing g^(r+x)/g^r. And then the PAR MUST 326 generate the message M_2. The PAR MUST send the HAResp message with 327 the result of M_1 verification to the NAR. 329 The PAR SHOULD store the HK_PAR (HK_i) until the MN request handover 330 authentication. Also, the PAR SHOULD cache HK_i for its life time. If 331 the MN returns to the PAR domain, the PAR SHOULD reuse the MN's HK_i. 333 4.3. NAR Behavior 335 Upon receiving the message HAReq from the MN, the NAR MUST generate a 336 random number y and a value g^y. Also, the NAR MUST forward the 337 received message HAReq with the value g^y to the PAR, and create 338 cache table including the MN_ID, NAR_ID, PAR_ID, y, and g^y. 340 The NAR MUST compute the new handover authentication key HK_i+1 using 341 its DH private key y in cache table and the received value g^x from 342 the PAR, when the NAR receives the message HAResp including the 343 success notification. Also, the NAR MUST compute the message M_3 to 344 confirm the handover key HK_i+1 with the MN. The NAR MUST send the 345 message HAResp including the life time of the HK_i+1 to the MN. If 346 the NAR receives the failure of authentication from the PAR, the NAR 347 MUST delete the MN's cache table except the DH parameters y and g^y 348 that are not used for generating handover key. The NAR SHOULD reuse 349 the stored value y and g^y without computing new DH public keys. 351 The NAR MUST verify a FBU message using the HK_i+1 when the MN moves 352 from the NAR (AR_i+1) to the next NAR (AR_i+2). 354 5. Message Formats 356 This document defines two messages HAReq and HAResp, and new options 357 to carry out handover authentication. 359 5.1. Handover Authentication Request (HAReq) 361 The HAReq MUST be sent from the MN to the AR for the handover 362 authentication. Receiving the HAReq message from the MN, the AR MUST 363 forward it to another AR. The HAReq message SHOULD use Options to 364 deliver extra variables for authentication (to be assigned by IANA). 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Message Code | Length | Reserved | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | | 372 . . 373 . Options . 374 . . 375 | | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 Figure 3 Handover Authentication Request (HAReq) Message. 379 HAReq Fields 381 Message Code 383 8-bit field indicate the handover authentication protocol, the 384 value of which is taken from the IANA. A value of '1' (to be 385 assigned by IANA) indicates the HAReq message. 387 Length 389 8-bit field is the length of the HAReq message. 391 Reserved 393 16-bit field reserved for future use. This field is unused. It 394 MUST be initialized to zero by the sender and MUST be ignored by 395 the receiver. 397 Options 399 Options field includes extra variables for handover 400 authentication. 402 5.2. Handover Authentication Response (HAResp) 404 The HAResp MUST be sent to the AR and MN in responding to a HAReq 405 message. 407 0 1 2 3 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Message Code | Length | Result Code | Reserved | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | | 413 . . 414 . Options . 415 . . 416 | | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 4 Handover Authentication Response (HAResp) Message. 420 HAResp Fields 422 Message Code 424 8-bit field indicates the handover authentication protocol, the 425 value of which is taken from the IANA. A value of '2' (to be 426 assigned by IANA) indicates the HAResp message. 428 Length 430 8-bit field is the length of the HAResp message. 432 Result Code 434 8-bit field indicates the result of authentication. A value of 435 '200' (to be assigned by IANA) indicates the "Success", and 436 '400' (to be assigned by IANA) indicates the "Fail" 438 Reserved 440 16-bit field reserved for future use. This field is unused. It 441 MUST be initialized to zero by the sender and MUST be ignored by 442 the receiver. 444 Options 446 Options field includes extra variables for handover 447 authentication. 449 5.3. Options 451 The HAReq and HAResp messages SHOULD accommodate various options as 452 follows. 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Option Code | Option Length | Option Data | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 459 . ... . 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 Figure 5 Option Message. 463 Option Fields 465 Option Code 467 8-bit field indicates extra variables as follows. 469 M_1 (Code number: to be assigned by IANA) 471 M_2 (Code number: to be assigned by IANA) 473 M_3 (Code number: to be assigned by IANA) 475 ID_MN (Code number: to be assigned by IANA) 477 ID_PAR (Code number: to be assigned by IANA) 479 ID_NAR (Code number: to be assigned by IANA) 480 Random_1 (Code number: to be assigned by IANA) 482 : This value is r+x. 484 Random_2 (Code number: to be assigned by IANA) 486 : This value is g^r 488 DH_MN (Code number: to be assigned by IANA) 490 : This value is g^x. 492 DH_AR (Code number: to be assigned by IANA) 494 : This value is g^y. 496 HK_LifeTime (Code number: to be assigned by IANA) 498 Option Length 500 8-bit field is the length of the Options field. 502 6. Security Considerations 504 The proposed scheme assumes that there are secure channels among ARs 505 and no secure channel between the MN and the AR. Therefore, 506 communications between the ARs are secure against the MITM (Man-in- 507 the-Middle) attack. When communicating with the AR, the MN secures 508 the messages using the MAC with the HK shared with the AR. This can 509 also protect the MN and the AR against MITM attack. 511 The DoS attack for exhausting resource has become a major security 512 threat. The DoS attack considered on our scheme is the CPU exhaustion 513 attack such as exponent operation when an attacker sends a number of 514 fake requests to the AR. In the proposed scheme, by reusing unused DH 515 public keys, ARs protect themselves against malicious attackers who 516 will try to exhaust their computing power. The AR_i+1 requires two 517 exponent operations per handover procedure: a DH public value g^y and 518 handover key (g^x)^y. Upon receiving the fake requests, the AR_i+1 519 will generate DH public keys and forward the fake requests with the 520 DH public keys to the AR_i. However, the AR_i may fail to verify the 521 fake requests due to unknown HK_i, and then it notifies the failure 522 of authentication to the AR_i+1. For the resistance against DoS 523 attack, if the AR_i+1 receives the failure of authentication from the 524 AR_i, the AR_i+1 should keep the generated DH public key (g^y) to be 525 reused for the next request. The SEHA can also protect the nodes 526 against replay attack by using a random number and caching the MN's 527 ID and HK_i. 529 The SEHA scheme provides the PFS, but does not provide the PBS in 530 case of exposed HK_i. The PFS and PBS mean that even if a handover 531 key HK_i is compromised by some reasons, it never reveals all the 532 previous and next handover keys. We use the DH key agreement protocol 533 to provide the PFS and PBS. In case of the PFS, if the HK_i is 534 exposed by some attacks, an attacker gives no clues to guess the 535 previous handover key. The reason is that the MN and AR generate the 536 handover key HK_i using new DH private key x_i and y_i whenever the 537 MN performs the handover authentication. If, however, the HK_i is 538 exposed by some reasons, the SEHA does not provide the PBS since 539 then. Note that the HK stored at the MN has the same security 540 strength as the master handover key or private key used in the 541 existing schemes. 543 The SEHA scheme is robust to the ping-pong problem. If the MN quickly 544 changes its position between the ARs, there may be the ping-pong 545 problem. When the MN frequently moves between the AR_i and AR_i+1, 546 the handover key HK_i and HK_i+1 should be changed according to its 547 movement area. The SEHA scheme securely caches the MN's HK at the MN 548 and the AR. Hence, the MN can securely reuse the HK without 549 disclosing it and performing redundant handover authentication 550 procedure. 552 7. IANA Considerations 554 The IANA will allocate the numbers to the HAReq, HAResp, and options. 556 8. References 558 8.1. Normative References 560 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 561 Levels", BCP 14, RFC 2119, March 1997. 563 [2] C Koodli, R., "Mobile Ipv6 Fast Handovers", draft-ietf-mipshop- 564 fmipv6-rfc4068bis-05, February 2008. 566 [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 567 IPv6", RFC 3775, June 2004. 569 [4] Kempf, J. and Koodli, R, "Distributing a Symmetric FMIPv6 570 Handover Key using SEND", draft-ietf-mipshop-handover-key-03, 571 November 2007. 573 [5] Arkko, J., Kempf, J., Zill, B., and Nikander, P., "Secure 574 Neighbor Discovery (SEND)", RFC 3971, March 2005. 576 [6] Aura, T., "Cryptographically Generated Addresses", RFC 3972, 577 March 2005. 579 [7] Aboba, B., "Extensible Authentication Protocol (EAP)", RFC 3748, 580 June 2004. 582 [8] Aboba, B., "Extensible Authentication Protocol (EAP) Key 583 Management Framework", draft-ietf-eap-keying-22 (work in 584 progress), October 2006. 586 Author's Addresses 588 Souhwan Jung 589 Soongsil University 590 511, Sangdo-dong, Dongjak-gu 591 Seoul 156-743 592 KOREA 594 Phone: +82-2-820-0714 595 Email: souhwanj@ssu.ac.kr 597 Jaeduck Choi 598 Soongsil University 599 511, Sangdo-dong, Dongjak-gu 600 Seoul 156-743 601 KOREA 603 Phone: +82-2-824-1807 604 Email: cjduck@cns.ssu.ac.kr 606 Intellectual Property Statement 608 The IETF takes no position regarding the validity or scope of any 609 Intellectual Property Rights or other rights that might be claimed to 610 pertain to the implementation or use of the technology described in 611 this document or the extent to which any license under such rights 612 might or might not be available; nor does it represent that it has 613 made any independent effort to identify any such rights. Information 614 on the procedures with respect to rights in RFC documents can be 615 found in BCP 78 and BCP 79. 617 Copies of IPR disclosures made to the IETF Secretariat and any 618 assurances of licenses to be made available, or the result of an 619 attempt made to obtain a general license or permission for the use of 620 such proprietary rights by implementers or users of this 621 specification can be obtained from the IETF on-line IPR repository at 622 http://www.ietf.org/ipr. 624 The IETF invites any interested party to bring to its attention any 625 copyrights, patents or patent applications, or other proprietary 626 rights that may cover technology that may be required to implement 627 this standard. Please address the information to the IETF at 628 ietf-ipr@ietf.org. 630 Disclaimer of Validity 632 This document and the information contained herein are provided on an 633 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 634 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 635 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 636 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 637 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 638 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 640 Copyright Statement 642 Copyright (C) The IETF Trust (2008). 644 This document is subject to the rights, licenses and restrictions 645 contained in BCP 78, and except as set forth therein, the authors 646 retain all their rights. 648 Acknowledgment 650 Funding for the RFC Editor function is currently provided by the 651 Internet Society.