idnits 2.17.1 draft-jung-mipshop-access-auth-00.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 824. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 801. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 814. ** 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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Receiving an AAA response from the AAA server, the NAR MUST notify the failure of the AAA request through an AAuthResp message to the MN. If the NAR receive an error message, the NAR SHOULD not create the authentication table of the MN and stop the access authentication procedure of the FNA message, and then SHOULD announce the result of failure to the MN. Otherwise, the NAR MUST calculate the MAC_NAR using the nonce from the HI message and AAK received from the AAA response, and create the authentication table of the MN. Receiving a FNA message from the MN, the NAR SHOULD extract the MAC_NAR in the FNA and compare this MAC_NAR with the MAC_NAR of the authentication table of the MN. After successful verification of the MAC_NAR, the NAR MUST send the AAuthResp including an access approval and a MAC_MN to the MN. In case of failure, the NAR SHOULD reject the access of the MN and send a response of failure. The NAR SHOULD delete the authentication table of the MN when the NAR send a FAck of FBU after another handoff of the MN. -- 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 26, 2006) is 6634 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) -- Looks like a reference, but probably isn't: 'Nonce' on line 222 -- Looks like a reference, but probably isn't: 'FBU' on line 395 ** Obsolete normative reference: RFC 4068 (ref. '2') (Obsoleted by RFC 5268) ** Obsolete normative reference: RFC 3775 (ref. '3') (Obsoleted by RFC 6275) == Outdated reference: A later version (-22) exists of draft-ietf-eap-keying-09 ** Downref: Normative reference to an Informational RFC: RFC 4285 (ref. '6') ** Obsolete normative reference: RFC 3546 (ref. '7') (Obsoleted by RFC 4366) ** Obsolete normative reference: RFC 2402 (ref. '8') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '9') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 3588 (ref. '11') (Obsoleted by RFC 6733) == Outdated reference: A later version (-04) exists of draft-vidya-mipshop-handover-keys-aaa-01 Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 9 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 26, 2006 Soongsil University 4 February 26, 2006 6 Access Authentication Protocol in FMIP6 7 draft-jung-mipshop-access-auth-00.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-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on February 26, 2006. 34 Abstract 36 This memo describes a secure authentication protocol between the MN 37 and NAR(New Access Router) in FMIP6. The main idea is that the MN 38 generates an authentication key for handoff, and delivers it to the 39 NAR through an existing secure channel via the AAA server during a 40 pre-authentication process. The NAR verifies the MN using the 41 delivered key when the MN attaches to itself. The main advantage of 42 this scheme over the full authentication procedure is to distribute 43 the heavy overhead of the AAA server such as key generation and 44 management to the MNs. The AAA server in this scheme just forwards 45 the key information to the NAR using an existing secure channel. 47 Table of Contents 49 1. Introduction................................................2 50 2. Terminology.................................................3 51 3. Protocol Overview...........................................3 52 4. Protocol Details............................................5 53 4.1. Predictive Access Authentication........................5 54 4.1.1. MN Behavior........................................8 55 4.1.2. AR Behavior........................................8 56 4.1.3. AAA Server Behavior................................9 57 4.2. Reactive Access Authentication..........................9 58 4.2.1. MN Behavior.......................................11 59 4.2.2. AR Behavior.......................................11 60 4.2.3. AAA Server Behavior...............................12 61 5. Message Formats............................................12 62 5.1. Access Authentication Request (AAuthReq)...............12 63 5.2. Access Authentication Response (AAuthResp).............13 64 5.3. Mobility Options.......................................15 65 6. Security Considerations.....................................17 66 7. IANA Considerations........................................17 67 8. References.................................................17 68 8.1. Normative References...................................17 69 8.2. Informative References.................................18 70 Author's Addresses............................................18 71 Intellectual Property Statement................................19 73 1. Introduction 75 MIPv6 WG[3] has designed an authentication protocol for secure MN-HA 76 communications[6], and Fast Mobile IPv6 [2] WG has been active in 77 designing an authentication protocol for securing MN-AR handoff 78 signaling messages[12]. But, since the authentication for handoff 79 signaling messages is limited to protect the BU messages, the NAR is 80 still vulnerable to the unauthorized network access by a spoofed MN 81 using the CoA or identifier of a valid MN. The NAR, therefore, need 82 to authorize the MN for network access. The authentication key for 83 this purpose should be separated from the key used by the PAR 84 (Previous Access Router). 86 This memo describes an authentication protocol using a new generated 87 key by the MN, which is to be delivered to the NAR via the AAA 88 server[10][11] through the existing secure channels between the MN 89 and the AAA server, and also between the AAA server and the NAR. It 90 is assumed that a secure channel exists between the AAA server and 91 the NAR using IPsec or TLS. In this scheme, the MN generates a new 92 authentication key and transfer it to the NAR after encrypting it 93 using the EMSK [4][5] that is derived from the master key of the AAA 94 server shared by MN through bootstrapping procedure[10][11]. The NAR 95 can authorize the network access of the MN after verifying it using 96 the delivered key. 98 This memo defines a set of new messages such as AAuthReq, AAuthResp, 99 and new mobility options that can be accommodated in the FMIP6 [2] 100 protocol messages and Mobility Header[3]. 102 2. Terminology 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC-2119 [1]. 108 New terminologies are defined in this memo. 110 Access Authentication Request (AAuthReq): 112 AAuthReq is a message to deliver the new authentication key(AAK) 113 generated by the MN to the AAA server. 115 Access Authentication Response (AAuthResp): 117 AAuthResp is a message to notify the MN of the success or failure 118 of the authentication key delivery. 120 Access Authentication Master Key (AAMK): 122 AAMK is a key derived from the EMSK shared by the MN and AAA 123 server, and is used for authentication of the MN. 125 Access Encryption Master Key (AEMK) 127 AEMK is a key derived from the EMSK to be used for encrypting the 128 AAK. 130 Access Authentication Key (AAK): 132 AAK is a key used for authentication after the MN attaches to the 133 NAR. The MN generates the AAK. 135 3. Protocol Overview 137 The operation of the MN-AR authentication protocol assumes that the 138 AAA-AR channels are secured by the IPsec[8][9] or TLS[7]. The data 139 for the MN-AR authentication can be delivered secure from the AAA 140 server to the AR. The MN also shares the EMSK with the AAA server 141 established during the bootstrapping process[4][5]. The AAMK and AEMK 142 are derived from the EMSK as follows. Those keys are used for secure 143 delivery of the AAK to the NAR 145 AAMK = H(EMSK_0_31, "Authentication Key") 147 AEMK = K1 | K2 149 K1 = H(EMSK_32_47, "Encryption Key" | 0x01) 151 K2 = H(EMSK_48_63, "Encryption Key" | 0x02) 153 where EMSK_X_Y : Octets X through Y inclusive of the EMSK 155 (AAMK, AEMK) 156 +----------------> AAA Server ----------------+ 157 | | 158 | | 159 | [E(AAK), AAK | 160 | MAC_AAA] | 161 | | 162 | V 163 Nonce 164 PAR ----------------------------------------> NAR 166 ^ ^ | 167 | | | 168 | [E(AAK), | | MAC_MN 169 | MAC_PAR, | | 170 | MAC_AAA, MAC_NAR | | 171 | Nonce] | | 172 | | V 173 Movement 174 MN ==============> MN 175 (AAMK, AEMK, AAK) 176 Figure 1 Protocol Overview. 178 Figure 1 shows the overview of the authentication protocol in FMIP6. 179 After the MN exchanges the RtSolPr and PrRtAdv messages before 180 handoff[2] to decide where it moves to, the MN generates the AAK, 181 encrypts it with the AEMK, and delivers it to the PAR encapsulated 182 in the AAuthReq message that also encloses the nonce, MAC_PAR and 183 MAC_AAA. 185 The PAR verifies the MAC_PAR, converts the encrypted AAK and MAC_AAA 186 into the AVP[10][11] format to deliver to the AAA server. The PAR 187 also transfers a nonce to the NAR. When receiving the message from 188 the PAR, the AAA server checks the MAC_AAA using the AAMK, and then 189 decrypts the AAK to deliver to the NAR using an existing secure 190 channel. 192 When attached to the NAR, the MN exchanges the MAC_NAR and the 193 MAC_MN for access authentication. The details of the corresponding 194 messages are shown in Section 4. 196 4. Protocol Details 198 4.1. Predictive Access Authentication 200 After deciding to whom to attach by exchanging RtSolPr and PrRtAdv, 201 the MN is supposed to go through the authentication procedure. Two 202 types of authentication procedure are possible for supporting fast 203 handoff. One is the predictive protocol, and the other is reactive 204 one. 206 Figure 2 shows the procedure of the predictive access 207 authentication. In this procedure, most of the handoff messages are 208 exchanged before physical switching of the MN. As soon as receiving 209 the AAA request, the AAA server sends a response with key 210 information to the NAR, not to the MN to reduce the handoff latency. 212 MN PAR NAR AAA Server 213 | RtSolPr | | | 214 |------------------>| | | 215 | PrRtAdv | | | 216 |<------------------| | | 217 |AAuthReq[E(AAK)...]| | | 218 |------------------>| AAA Request[E(AAK)...] | 219 | AAuthResp |-------------------|------------------>| 220 |<------------------| | | 221 | FBU[Nonce] | |AAA Response[AAK..]| 222 |------------------>| HI[Nonce] |<------------------| 223 | |------------------>| | 224 | | HAck | | 225 | |<------------------| | 226 | FBack | FBack | | 227 | <----------|---------> | | 228 | | | | 229 disconnect | | | 230 | | | | 231 connect | | | 232 |FNA[MN_ID,MAC_NAR] | | | 233 |-------------------|------------------>| | 234 | |AAuthResp[MAC_MN..]| | 235 |<------------------|-------------------| | 236 | | Network Access | | 237 |<==================|===================|=======> | 238 | | | | 239 Figure 2 Predictive Access Authentication. 241 The MN generates the AAK to be used for access authentication, and 242 encrypts it using the AEMK (E_AEMK(AAK)), and sends the message to 243 the PAR. The AAK is generated as follows. The value of Time-Stamp is 244 included to avoid generating a duplicated value. 246 AAK = H(Time_Stamp, MN_ID | NAR_ID | "Access Authentication Key") 248 The MN_ID and NAR_ID are the CoA of MN and the IP address of the 249 NAR, respectively. The MN generates the MAC_PAR using the AAK_PAR 250 shared by the PAR as follows. 252 MAC_PAR = H(MN_ID|NAR_ID|AAA_ID, E_AEMK(AAK)) XOR H(AAK_PAR) XOR 253 MAC_AAA 255 The MN also generates the MAC_AAA using AAMK as follows: 257 MAC_AAA = H(MN_ID|NAR_ID|AAA_ID, E_AEMK(AAK)) XOR H(AAMK) 259 where, the AAA_ID may be the IP address or the domain name of the 260 AAA server. 262 After filling up all the necessary data, the MN sends the AAuthReq 263 message to the PAR. 265 AAuthReq[MN_ID,NAR_ID,AAA_ID,E_AEMK(AAK),MAC_PAR,MAC_AAA] 267 After verifying the MAC_PAR using the AAK_PAR, the PAR encapsulates 268 the AAuthReq message removing the MAC_PAR into the AAA request 269 message in AAA AVP form, and sends it to the AAA server. The AAA 270 Request message is generated as follows. 272 AAA Request[MN_ID,NAR_ID,AAA_ID,E_AEMK(AAK),MAC_AAA] 274 The PAR sends an answer message AAuthResp to the MN to notify the 275 result of message verification. The AAA Server verifies the MAC_AAA 276 using the AAMK associated with the MN_ID, decrypts the message 277 E_AEMK(AAK), and then transports the AAK to the NAR. Receiving 278 AAuthResp, the MN sends a FBU message with a nonce to the PAR. The 279 PAR forwards the HI message added with the nonce to the NAR. The NAR 280 that has the AAK and nonce creates an authentication table that 281 consists of the MN_ID, AAK, nonce, and the MAC_NAR. 283 After successful handoff, the MN generates the MAC_NAR as follows 284 and sends the FNA including the MAC_NAR to the NAR. 286 MAC_NAR = H(AAK, Nonce|MN_ID|NAR_ID) 288 The NAR compares the MAC_NAR of the FNA message with the MAC_NAR of 289 the authentication table of the MN. If the verification is a 290 success, the NAR delivers an AAuthResp message including the MAC_MN 291 and the approval to the MN. 293 MAC_MN = H(Nonce|MN_ID|NAR_ID, AAK) 295 If the MN receives a fail or error message through the AAuthResp, MN 296 MUST initiate the access authentication procedure (See Section 4.2 297 Scenario). After exchanging the AAK between the MN and the NAR, the 298 NAR play a role of authenticator to authorize the network access of 299 the MN. 301 4.1.1. MN Behavior 303 The MN SHOULD share the EMSK with the AAA server through an EAP full 304 authentication, and derive the AAMK and AEMK from the EMSK. In order 305 to share an AAK with the NAR, the MN MUST create an AAuthReq with a 306 unique, random Message ID with the sequence number starting at 0. 307 The MN MUST use the same AAK during a whole access authentication 308 process. 310 When the MN receives the AAuthResp message of success, the MN SHOULD 311 send a FBU message including a nonce to the PAR. Otherwise, the MN 312 MUST send a new AAuthReq with a new message ID to the PAR. In case 313 of retransmission, the message ID SHOULD be the same, and the 314 sequence number MUST be incremented by 1. 316 If the MN does not receive an AAuthResp corresponding to the 317 AAuthReq from the PAR before handoff, the MN MUST send a new 318 AAuthReq message to the NAR (see Section 4.2 scenario). This 319 AAuthReq message MUST have a new message ID with a sequence number 320 incremented by 1. The original AAuthReq transported to the PAR 321 SHOULD be ignored. After receiving the AAuthResp of success and 322 verifying the MAC_MN, the MN can access network through the NAR. If 323 the MN fails to access authentication, the MN SHOULD execute a 324 re-authentication process (see Section 4.2 scenario). 326 4.1.2. AR Behavior 328 The channels between the AR and the AAA server are to be secured by 329 the IPsec or TLS. The PAR MUST verify the MAC_PAR in AAuthReq 330 message using the AAK_PAR shared with the MN. If the PAR fails to 331 verify the MAC_PAR, the PAR MUST send an AAuthResp of failure to the 332 MN and discard the received AAuthReq message. After a successful 333 verification of the MAC_PAR, the PAR MUST convert the data of 334 AAuthReq message (e.g. encrypted AAK, MN_ID, and MAC_AAA etc.) into 335 the AVP format, and deliver the AAA request to the AAA server. 337 After sending the AAA request, the PAR MUST notify the result of 338 MAC_PAR verification and the result of AAA Request procedure using 339 the AAuthResp message to the MN. Receiving the FBU message, the PAR 340 MUST forward the nonce in FBU using HI message to the NAR. If the 341 PAR already received the same AAuthReq from the MN but has not yet 342 send a response to the MN, the PAR SHOULD silently discard the 343 retransmitted request from the MN. 345 Receiving an AAA response from the AAA server, the NAR MUST notify 346 the failure of the AAA request through an AAuthResp message to the 347 MN. If the NAR receive an error message, the NAR SHOULD not create 348 the authentication table of the MN and stop the access 349 authentication procedure of the FNA message, and then SHOULD 350 announce the result of failure to the MN. Otherwise, the NAR MUST 351 calculate the MAC_NAR using the nonce from the HI message and AAK 352 received from the AAA response, and create the authentication table 353 of the MN. Receiving a FNA message from the MN, the NAR SHOULD 354 extract the MAC_NAR in the FNA and compare this MAC_NAR with the 355 MAC_NAR of the authentication table of the MN. After successful 356 verification of the MAC_NAR, the NAR MUST send the AAuthResp 357 including an access approval and a MAC_MN to the MN. In case of 358 failure, the NAR SHOULD reject the access of the MN and send a 359 response of failure. The NAR SHOULD delete the authentication table 360 of the MN when the NAR send a FAck of FBU after another handoff of 361 the MN. 363 4.1.3. AAA Server Behavior 365 The AAA server MUST share the EMSK with the MN through an EAP full 366 authentication, and derive the AAMK and AEMK from the EMSK. The AAA 367 server MUST verify the MAC_AAA in AAA request using the AAMK, and 368 decrypt the AAK using the AEMK, and then send the AAK through a 369 secure channel to the NAR. In case of error, the AAA server MUST 370 notify the result to the NAR. 372 4.2. Reactive Access Authentication 374 After creating the NCoA by exchanging the RtSolPr and PrRtAdv 375 messages, the MN begins the access authentication procedure. Figure 376 3 shows the procedure of the reactive access authentication. In this 377 scenario, access authentication messages are exchanged after sending 378 the FNA. The NAR sends the AAA request to the AAA server if only the 379 FBU procedure is successful. The NAR in reactive procedure cannot 380 verify the MN because the MN and the NAR do not have any security 381 associations. Therefore, the NAR sends the AAA request message to 382 the AAA server after receiving the FAck to resist against DoS 383 attacks. 385 MN PAR NAR AAA Server 386 | RtSolPr | | | 387 |------------------>| | | 388 | PrRtAdv | | | 389 |<------------------| | | 390 | | | | 391 disconnect | | | 392 | | | | 393 connect | | | 394 | | | | 395 | FNA[FBU] | | 396 |-------------------|------------------>| | 397 |AAuthReq[E(AAK),MAC_NAR,Nonce,MN_ID...]| | 398 |-------------------|------------------>| | 399 | | FBU | | 400 | |<------------------| | 401 | | FBack | | 402 | |------------------>|AAA Request[E(AAK)..]| 403 | | |-------------------->| 404 | | | AAA Response[AAK..] | 405 | |AAuthResp[MAC_MN..]|<--------------------| 406 |<------------------|-------------------| | 407 | | Network Access | 408 |<==================|===================|=======> 409 | | | 410 Figure 3 Reactive Access Authentication. 412 The way of generating the AAK is the same as Section 4.1. The MN 413 generates the MAC_NAR using the AAK shared by the NAR as follows. 415 MAC_NAR = H(MN_ID|NAR_ID|AAA_ID, E_AEMK(AAK)) XOR H(AAK) 417 The MN also generates the MAC_AAA using the AAMK as follows: 419 MAC_AAA = H(MN_ID|NAR_ID|AAA_ID|Nonce, E_AEMK(AAK)) XOR H(AAMK) 420 XOR MAC_NAR 422 After generating all the necessary data, the MN sends AAuthReq 423 message to the NAR. 425 AAuthReq[MN_ID,NAR_ID,AAA_ID,Nonce,E_AEMK(AAK),MAC_NAR,MAC_AAA] 427 The NAR processes the FBU and the AAuthReq message. The NAR creates 428 the authentication table of MN that consists of the MN_ID, nonce, 429 and the MAC_NAR. After receiving the FAck of FBU, the NAR converts 430 the data of AAuthReq message into the AVP format, and sends the AAA 431 Request to the AAA server. The AAA Request message is generated as 432 follows. 434 AAA Request[MN_ID,NAR_ID,AAA_ID,Nonce,E_AEMK(AAK),MAC_NAR, 435 MAC_AAA] 437 The AAA server verifies the MAC_AAA using the shared AAMK, decrypts 438 the AAK using the shared AEMK, and then sends the AAK to the NAR. 439 Receiving the AAK, the NAR verifies the MAC_NAR using the nonce in 440 the authentication table. After a successful verification, the NAR 441 sends the AAuthResp message with the MAC_MN to the MN to notify a 442 success. 444 MAC_NAR = H(AAK, Nonce|MN_ID|NAR_ID) 446 MAC_MN = H(Nonce|MN_ID|NAR_ID, AAK) 448 If the MN receives a message regarding the FBU failure or access 449 authentication failure, the MN initiates the access authentication 450 procedure. After receiving the AAuthResp of success and verifying 451 the MAC_MN, the MN can access network through the NAR. If the MN 452 fails access authentication, the MN MUST carry out re-authentication 453 process. 455 4.2.1. MN Behavior 457 The generation and retransmission of the AAuthReq message is the 458 same as Section 4.1.1. In case of the FBU failure, the MN MUST carry 459 out re-authentication procedure using the AAuthReq message. In the 460 reactive mode, the MN MUST include the nonce and MAC_NAR in the 461 AAuthReq message. If the MN receives the AAuthResp including access 462 failure or can not verify the MAC_MN, the MN MUST execute a re- 463 authentication procedure. 465 4.2.2. AR Behavior 467 Receiving the AAuthReq message, the NAR MUST converts the data of 468 AAuthReq message into the AVP format, create the authentication 469 table of the MN, and send the AAA Request to the AAA server if only 470 the NAR receives the successful FAck. The NAR discards the AAuthReq 471 message in case of failed FAck. If the NAR already received an 472 AAuthReq from the MN but has not yet send a response about the 473 AAuthReq to the MN, the NAR MUST silently discard the retransmitted 474 request from the MN. 476 After receiving the AAA Response from the AAA server, the result MUST 477 be notified by the NAR to the MN. If the NAR receive an error 478 message, the NAR MUST delete the authentication table of the MN and 479 stop the access authentication, and then SHOULD announce the result 480 of failure to the MN. Otherwise, the NAR MUST compare the MAC_NAR 481 in the authentication table of the MN and the calculated MAC_NAR 482 using the AAK receiving from the AAA response. After successful 483 verification of the MAC_NAR, the NAR MUST send an AAuthResp 484 including access approval and a MAC_MN to the MN. For a failure of 485 verification, the NAR MUST reject the access of the MN and response 486 the result of failure. The NAR MUST delete the authentication table 487 of the MN when the MN handoffs to another NAR. 489 4.2.3. AAA Server Behavior 491 The behavior of the AAA server is the same as Section 4.1.3. 493 5. Message Formats 495 This memo defines a set of new messages such as AAuthReq, AAuthResp, 496 and new mobility options to carry out access authentication for MN- 497 NAR. 499 5.1. Access Authentication Request (AAuthReq) 501 The AAuthReq MUST be sent from the MN to the AR for the access 502 authentication. The AAuthReq message MUST be sent to the PAR before 503 handoff. After handoff to the NAR, the MN MUST send the AAuthReq to 504 the NAR. The AAuthReq message uses the MH(Mobility Header) Type[3] 505 (to be assigned by IANA). 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Message Code | Length | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Message ID | Sequence Number | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | | 515 . . 516 . Mobility Options . 517 . . 518 | | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Figure 4 Access Authentication Request (AAuthReq) Message. 522 AAuthReq Fields 523 Message Code 524 8-bit field indicate the access authentication protocol, the 525 value of which is taken from the IANA. A value of '1' (to be 526 assigned by IANA) indicates the AAuthReq message. 528 Length 530 8-bit unsigned integer is the length of the AAuthReq message. 532 Message ID 534 16-bit random value used to uniquely match the AAuthReq and the 535 AAuthResp is set to a new value in case of re-authentication. 537 Sequence Number 539 16-bit unsigned integer used by the AR to be matched to a 540 sequence number of the AAuthResp message, and increased by one 541 for each AAuthReq. 543 Mobility Options 545 Variable-length field of such length that the complete 546 Mobility Header is an integer multiple of 8 octets. The 547 encoding and format of defined options are described in Section 548 5.3. 550 5.2. Access Authentication Response (AAuthResp) 552 The AAuthResp MUST be sent from the AR to the MN in responding to a 553 AAuthReq message. The AAuthResp message use the MH(Mobility Header) 554 Type[3] (to be assigned by IANA). 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Message Code | Length | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Message ID | Sequence Number | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Status Code |P|F| Reserved | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | | 566 . . 567 . Mobility Options . 568 . . 569 | | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Figure 5 Access Authentication Response (AAuthResp) Message. 573 AAuthResp Fields 575 Message Code 577 8-bit field indicates the access authentication protocol, the 578 value of which is taken from the IANA. A value of '200' (to be 579 assigned by IANA) indicates the AAuthResp message. 581 Length 583 8-bit unsigned integer is the length of the AAuthResp message. 585 Message ID 587 16-bit random value used to uniquely match the AAuthReq and the 588 AAuthResp. This value is copied from the corresponding 589 AAuthReq. In the predictive mode, the NAR set '0xFFFF' if F 590 flag is '1'. 592 Sequence Number 594 16-bit unsigned integer matched to the sequence number of the 595 AAuthReq message. In the predictive, the NAR set '0xFFFF' if F 596 flag is '1'. 598 Status Code 600 8-bit status code indicates the status of the AAuthReq. 602 0 : Success. 604 100 : MAC_PAR verification failed. 606 101 : MAC_AAA verification failed. 608 102 : MAC_NAR verification failed. 610 200 : MN_ID option required. 612 201 : NAR_ID option required. 614 202 : AAA_ID option required. 616 203 : Nonce option required. 618 300 : Adminisratively prohibited. 620 400 : Invalid AAuthReq message. 622 401 : Invalid FNA message. 624 P flag (Provisional response) 626 In predictive procedure, the PAR set '1' to the P flag in 627 responding to the AAuthReq. 629 F flag (Final response) 631 In predictive procedure, the NAR set '1' to the F flag in final 632 response to the AAuthReq. 634 Reserved 636 This field is unused. It MUST be initialized to zero by the 637 sender and MUST be ignored by the receiver. 639 Mobility Options 641 Variable-length field of such length that the complete Mobility 642 Header is an integer multiple of 8 octets. The encoding and 643 format of defined options are described in Section 5.3. 645 5.3. Mobility Options 647 The AAuthReq and AAuthResp messages SHOULD have various options as 648 follows. 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Option Code | Option Length | Option Data | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 655 . ... . 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Figure 6 Options Message. 659 MN_ID (Code number: to be assigned by IANA) 661 The MN_ID field contains an identifier of the MN that is a new 662 CoA. 664 NAR_ID (Code number: to be assigned by IANA) 666 The filed indicates the IP address of NAR. 668 AAA_ID (Code number: to be assigned by IANA) 670 This value may be present the IP address or the domain name of 671 the AAA server. 673 E_AEMK(AAK) (Code number: to be assigned by IANA) 675 The encrypted message of an AAK using the AEMK 677 Nonce (Code number: to be assigned by IANA) 679 The random value generated by MN. 681 MAC_PAR (Code number: to be assigned by IANA) 683 This field has the MAC(Message Authentication Code) using the 684 AAK_PAR to authenticate the MN at the PAR. 686 MAC_AAA (Code number: to be assigned by IANA) 688 The MAC_AAA is calculated by MN using AAMK for MN 689 authentication. 691 MAC_NAR (Code number: to be assigned by IANA) 693 The MAC_NAR is used for AAK exchange between the MN and the NAR 694 and MN authentication in the NAR. The value is generated by MN 695 using the AAK and nonce. 697 MAC_MN (Code number: to be assigned by IANA) 699 The MN verifies the exchange of the AAK and authenticates the 700 NAR using MAC_MN generated by NAR. 702 6. Security Considerations 704 The overall scheme of this memo is about to make a secure delivery 705 of an authentication key AAK from the MN to the NAR, in which no 706 secure channel does exist. The proposed scheme assumes a secure 707 channel between the AAA server and the AR protected by the IPsec or 708 TLS. The AAA server and the MN also share a secret EMSK populated 709 from the bootstrapping process. The AAK for access authentication, 710 therefore, can de delivered securely from the MN to the NAR 711 protected by those keys like the AAMK and AEMK which are derived 712 from the EMSK. 714 In the proposed scheme, since the MN generates the AAK without 715 regards to the ARs for each handoff, the key AAK satisfies the 716 property of PFS (Perfect Forward Secrecy). 718 The process of predictive access authentication has a resistance 719 against DoS attack by verifying the AAuthReq message with MAC_PAR. 720 The process of reactive access authentication is also secure against 721 DoS attack because the NAR issues the AAuthReq after verifying the 722 FBU from the MN. 724 7. IANA Considerations 726 The IANA will allocate the numbers to the AAuthReq, AAuthResp, and 727 mobility options (see Section 5). 729 8. References 731 8.1. Normative References 733 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 734 Levels", BCP 14, RFC 2119, March 1997. 736 [2] C Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 737 2005. 739 [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 740 IPv6", RFC 3775, June 2004. 742 [4] Aboba, B., "Extensible Authentication Protocol (EAP)", RFC 743 3748, June 2004. 745 [5] Aboba, B., "Extensible Authentication Protocol (EAP) Key 746 Management Framework", draft-ietf-eap-keying-09 (work in 747 progress), January 2006. 749 [6] Patel, A., "Authentication Protocol for Mobile IPv6", RFC 4285, 750 January 2006. 752 [7] Blake-Wilson, S., "Transport Layer Security (TLS) Extensions", 753 RFC 3546, June 2003. 755 [8] Kent, S. "IP Authentication Header", RFC 2402, November 1998. 757 [9] Kent, S. "IP Encapsulating Security Payload (ESP)", RFC 2406, 758 November 1998. 760 [10] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 761 Authentication Dial In User Service (RADIUS)", RFC 2865, June 762 2000. 764 [11] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, 765 "Diameter Base Protocol", RFC 3588, September 2003. 767 8.2. Informative References 769 [12] Narayanan, V., "Handover Keys Using AAA", draft-vidya-mipshop- 770 handover-keys-aaa-01 (work in progress), October 2005. 772 Author's Addresses 774 Souhwan Jung 775 Soongsil University 776 511, Sangdo-dong, Dongjak-ku 777 Seoul 156-743 778 KOREA 780 Phone: +82-2-820-0714 781 Email: souhwanj@ssu.ac.kr 783 Jaeduck Choi 784 Soongsil University 785 511, Sangdo-dong, Dongjak-ku 786 Seoul 156-743 787 KOREA 789 Phone: +82-2-824-1807 790 Email: cjduck@cns.ssu.ac.kr 792 Intellectual Property Statement 794 The IETF takes no position regarding the validity or scope of any 795 Intellectual Property Rights or other rights that might be claimed 796 to pertain to the implementation or use of the technology described 797 in this document or the extent to which any license under such 798 rights might or might not be available; nor does it represent that 799 it has made any independent effort to identify any such rights. 800 Information on the procedures with respect to rights in RFC 801 documents can be found in BCP 78 and BCP 79. 803 Copies of IPR disclosures made to the IETF Secretariat and any 804 assurances of licenses to be made available, or the result of an 805 attempt made to obtain a general license or permission for the use 806 of such proprietary rights by implementers or users of this 807 specification can be obtained from the IETF on-line IPR repository 808 at http://www.ietf.org/ipr. 810 The IETF invites any interested party to bring to its attention any 811 copyrights, patents or patent applications, or other proprietary 812 rights that may cover technology that may be required to implement 813 this standard. Please address the information to the IETF at 814 ietf-ipr@ietf.org. 816 Disclaimer of Validity 818 This document and the information contained herein are provided on 819 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 820 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 821 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 822 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 823 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 824 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 826 Copyright Statement 828 Copyright (C) The Internet Society (2006). 830 This document is subject to the rights, licenses and restrictions 831 contained in BCP 78, and except as set forth therein, the authors 832 retain all their rights. 834 Acknowledgment 836 Funding for the RFC Editor function is currently provided by the 837 Internet Society.