MIPSHOP Working Group Souhwan Jung Internet Draft Jaeduck Choi Expires: August 26, 2006 Soongsil University February 26, 2006 Access Authentication Protocol in FMIP6 draft-jung-mipshop-access-auth-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on February 26, 2006. Abstract This memo describes a secure authentication protocol between the MN and NAR(New Access Router) in FMIP6. The main idea is that the MN generates an authentication key for handoff, and delivers it to the NAR through an existing secure channel via the AAA server during a pre-authentication process. The NAR verifies the MN using the delivered key when the MN attaches to itself. The main advantage of this scheme over the full authentication procedure is to distribute the heavy overhead of the AAA server such as key generation and management to the MNs. The AAA server in this scheme just forwards the key information to the NAR using an existing secure channel. Jung, et al. Expires August 26, 2006 [Page 1] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 Table of Contents 1. Introduction................................................2 2. Terminology.................................................3 3. Protocol Overview...........................................3 4. Protocol Details............................................5 4.1. Predictive Access Authentication........................5 4.1.1. MN Behavior........................................8 4.1.2. AR Behavior........................................8 4.1.3. AAA Server Behavior................................9 4.2. Reactive Access Authentication..........................9 4.2.1. MN Behavior.......................................11 4.2.2. AR Behavior.......................................11 4.2.3. AAA Server Behavior...............................12 5. Message Formats............................................12 5.1. Access Authentication Request (AAuthReq)...............12 5.2. Access Authentication Response (AAuthResp).............13 5.3. Mobility Options.......................................15 6. Security Considerations.....................................17 7. IANA Considerations........................................17 8. References.................................................17 8.1. Normative References...................................17 8.2. Informative References.................................18 Author's Addresses............................................18 Intellectual Property Statement................................19 1. Introduction MIPv6 WG[3] has designed an authentication protocol for secure MN-HA communications[6], and Fast Mobile IPv6 [2] WG has been active in designing an authentication protocol for securing MN-AR handoff signaling messages[12]. But, since the authentication for handoff signaling messages is limited to protect the BU messages, the NAR is still vulnerable to the unauthorized network access by a spoofed MN using the CoA or identifier of a valid MN. The NAR, therefore, need to authorize the MN for network access. The authentication key for this purpose should be separated from the key used by the PAR (Previous Access Router). This memo describes an authentication protocol using a new generated key by the MN, which is to be delivered to the NAR via the AAA server[10][11] through the existing secure channels between the MN and the AAA server, and also between the AAA server and the NAR. It is assumed that a secure channel exists between the AAA server and the NAR using IPsec or TLS. In this scheme, the MN generates a new authentication key and transfer it to the NAR after encrypting it using the EMSK [4][5] that is derived from the master key of the AAA Jung, et al. Expires August 26, 2006 [Page 2] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 server shared by MN through bootstrapping procedure[10][11]. The NAR can authorize the network access of the MN after verifying it using the delivered key. This memo defines a set of new messages such as AAuthReq, AAuthResp, and new mobility options that can be accommodated in the FMIP6 [2] protocol messages and Mobility Header[3]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. New terminologies are defined in this memo. Access Authentication Request (AAuthReq): AAuthReq is a message to deliver the new authentication key(AAK) generated by the MN to the AAA server. Access Authentication Response (AAuthResp): AAuthResp is a message to notify the MN of the success or failure of the authentication key delivery. Access Authentication Master Key (AAMK): AAMK is a key derived from the EMSK shared by the MN and AAA server, and is used for authentication of the MN. Access Encryption Master Key (AEMK) AEMK is a key derived from the EMSK to be used for encrypting the AAK. Access Authentication Key (AAK): AAK is a key used for authentication after the MN attaches to the NAR. The MN generates the AAK. 3. Protocol Overview The operation of the MN-AR authentication protocol assumes that the AAA-AR channels are secured by the IPsec[8][9] or TLS[7]. The data for the MN-AR authentication can be delivered secure from the AAA server to the AR. The MN also shares the EMSK with the AAA server Jung, et al. Expires August 26, 2006 [Page 3] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 established during the bootstrapping process[4][5]. The AAMK and AEMK are derived from the EMSK as follows. Those keys are used for secure delivery of the AAK to the NAR AAMK = H(EMSK_0_31, "Authentication Key") AEMK = K1 | K2 K1 = H(EMSK_32_47, "Encryption Key" | 0x01) K2 = H(EMSK_48_63, "Encryption Key" | 0x02) where EMSK_X_Y : Octets X through Y inclusive of the EMSK (AAMK, AEMK) +----------------> AAA Server ----------------+ | | | | | [E(AAK), AAK | | MAC_AAA] | | | | V Nonce PAR ----------------------------------------> NAR ^ ^ | | | | | [E(AAK), | | MAC_MN | MAC_PAR, | | | MAC_AAA, MAC_NAR | | | Nonce] | | | | V Movement MN ==============> MN (AAMK, AEMK, AAK) Figure 1 Protocol Overview. Figure 1 shows the overview of the authentication protocol in FMIP6. After the MN exchanges the RtSolPr and PrRtAdv messages before handoff[2] to decide where it moves to, the MN generates the AAK, encrypts it with the AEMK, and delivers it to the PAR encapsulated in the AAuthReq message that also encloses the nonce, MAC_PAR and MAC_AAA. Jung, et al. Expires August 26, 2006 [Page 4] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 The PAR verifies the MAC_PAR, converts the encrypted AAK and MAC_AAA into the AVP[10][11] format to deliver to the AAA server. The PAR also transfers a nonce to the NAR. When receiving the message from the PAR, the AAA server checks the MAC_AAA using the AAMK, and then decrypts the AAK to deliver to the NAR using an existing secure channel. When attached to the NAR, the MN exchanges the MAC_NAR and the MAC_MN for access authentication. The details of the corresponding messages are shown in Section 4. 4. Protocol Details 4.1. Predictive Access Authentication After deciding to whom to attach by exchanging RtSolPr and PrRtAdv, the MN is supposed to go through the authentication procedure. Two types of authentication procedure are possible for supporting fast handoff. One is the predictive protocol, and the other is reactive one. Figure 2 shows the procedure of the predictive access authentication. In this procedure, most of the handoff messages are exchanged before physical switching of the MN. As soon as receiving the AAA request, the AAA server sends a response with key information to the NAR, not to the MN to reduce the handoff latency. Jung, et al. Expires August 26, 2006 [Page 5] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 MN PAR NAR AAA Server | RtSolPr | | | |------------------>| | | | PrRtAdv | | | |<------------------| | | |AAuthReq[E(AAK)...]| | | |------------------>| AAA Request[E(AAK)...] | | AAuthResp |-------------------|------------------>| |<------------------| | | | FBU[Nonce] | |AAA Response[AAK..]| |------------------>| HI[Nonce] |<------------------| | |------------------>| | | | HAck | | | |<------------------| | | FBack | FBack | | | <----------|---------> | | | | | | disconnect | | | | | | | connect | | | |FNA[MN_ID,MAC_NAR] | | | |-------------------|------------------>| | | |AAuthResp[MAC_MN..]| | |<------------------|-------------------| | | | Network Access | | |<==================|===================|=======> | | | | | Figure 2 Predictive Access Authentication. The MN generates the AAK to be used for access authentication, and encrypts it using the AEMK (E_AEMK(AAK)), and sends the message to the PAR. The AAK is generated as follows. The value of Time-Stamp is included to avoid generating a duplicated value. AAK = H(Time_Stamp, MN_ID | NAR_ID | "Access Authentication Key") The MN_ID and NAR_ID are the CoA of MN and the IP address of the NAR, respectively. The MN generates the MAC_PAR using the AAK_PAR shared by the PAR as follows. MAC_PAR = H(MN_ID|NAR_ID|AAA_ID, E_AEMK(AAK)) XOR H(AAK_PAR) XOR MAC_AAA The MN also generates the MAC_AAA using AAMK as follows: Jung, et al. Expires August 26, 2006 [Page 6] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 MAC_AAA = H(MN_ID|NAR_ID|AAA_ID, E_AEMK(AAK)) XOR H(AAMK) where, the AAA_ID may be the IP address or the domain name of the AAA server. After filling up all the necessary data, the MN sends the AAuthReq message to the PAR. AAuthReq[MN_ID,NAR_ID,AAA_ID,E_AEMK(AAK),MAC_PAR,MAC_AAA] After verifying the MAC_PAR using the AAK_PAR, the PAR encapsulates the AAuthReq message removing the MAC_PAR into the AAA request message in AAA AVP form, and sends it to the AAA server. The AAA Request message is generated as follows. AAA Request[MN_ID,NAR_ID,AAA_ID,E_AEMK(AAK),MAC_AAA] The PAR sends an answer message AAuthResp to the MN to notify the result of message verification. The AAA Server verifies the MAC_AAA using the AAMK associated with the MN_ID, decrypts the message E_AEMK(AAK), and then transports the AAK to the NAR. Receiving AAuthResp, the MN sends a FBU message with a nonce to the PAR. The PAR forwards the HI message added with the nonce to the NAR. The NAR that has the AAK and nonce creates an authentication table that consists of the MN_ID, AAK, nonce, and the MAC_NAR. After successful handoff, the MN generates the MAC_NAR as follows and sends the FNA including the MAC_NAR to the NAR. MAC_NAR = H(AAK, Nonce|MN_ID|NAR_ID) The NAR compares the MAC_NAR of the FNA message with the MAC_NAR of the authentication table of the MN. If the verification is a success, the NAR delivers an AAuthResp message including the MAC_MN and the approval to the MN. MAC_MN = H(Nonce|MN_ID|NAR_ID, AAK) If the MN receives a fail or error message through the AAuthResp, MN MUST initiate the access authentication procedure (See Section 4.2 Scenario). After exchanging the AAK between the MN and the NAR, the NAR play a role of authenticator to authorize the network access of the MN. Jung, et al. Expires August 26, 2006 [Page 7] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 4.1.1. MN Behavior The MN SHOULD share the EMSK with the AAA server through an EAP full authentication, and derive the AAMK and AEMK from the EMSK. In order to share an AAK with the NAR, the MN MUST create an AAuthReq with a unique, random Message ID with the sequence number starting at 0. The MN MUST use the same AAK during a whole access authentication process. When the MN receives the AAuthResp message of success, the MN SHOULD send a FBU message including a nonce to the PAR. Otherwise, the MN MUST send a new AAuthReq with a new message ID to the PAR. In case of retransmission, the message ID SHOULD be the same, and the sequence number MUST be incremented by 1. If the MN does not receive an AAuthResp corresponding to the AAuthReq from the PAR before handoff, the MN MUST send a new AAuthReq message to the NAR (see Section 4.2 scenario). This AAuthReq message MUST have a new message ID with a sequence number incremented by 1. The original AAuthReq transported to the PAR SHOULD be ignored. After receiving the AAuthResp of success and verifying the MAC_MN, the MN can access network through the NAR. If the MN fails to access authentication, the MN SHOULD execute a re-authentication process (see Section 4.2 scenario). 4.1.2. AR Behavior The channels between the AR and the AAA server are to be secured by the IPsec or TLS. The PAR MUST verify the MAC_PAR in AAuthReq message using the AAK_PAR shared with the MN. If the PAR fails to verify the MAC_PAR, the PAR MUST send an AAuthResp of failure to the MN and discard the received AAuthReq message. After a successful verification of the MAC_PAR, the PAR MUST convert the data of AAuthReq message (e.g. encrypted AAK, MN_ID, and MAC_AAA etc.) into the AVP format, and deliver the AAA request to the AAA server. After sending the AAA request, the PAR MUST notify the result of MAC_PAR verification and the result of AAA Request procedure using the AAuthResp message to the MN. Receiving the FBU message, the PAR MUST forward the nonce in FBU using HI message to the NAR. If the PAR already received the same AAuthReq from the MN but has not yet send a response to the MN, the PAR SHOULD silently discard the retransmitted request from the MN. 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 Jung, et al. Expires August 26, 2006 [Page 8] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 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. 4.1.3. AAA Server Behavior The AAA server MUST share the EMSK with the MN through an EAP full authentication, and derive the AAMK and AEMK from the EMSK. The AAA server MUST verify the MAC_AAA in AAA request using the AAMK, and decrypt the AAK using the AEMK, and then send the AAK through a secure channel to the NAR. In case of error, the AAA server MUST notify the result to the NAR. 4.2. Reactive Access Authentication After creating the NCoA by exchanging the RtSolPr and PrRtAdv messages, the MN begins the access authentication procedure. Figure 3 shows the procedure of the reactive access authentication. In this scenario, access authentication messages are exchanged after sending the FNA. The NAR sends the AAA request to the AAA server if only the FBU procedure is successful. The NAR in reactive procedure cannot verify the MN because the MN and the NAR do not have any security associations. Therefore, the NAR sends the AAA request message to the AAA server after receiving the FAck to resist against DoS attacks. Jung, et al. Expires August 26, 2006 [Page 9] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 MN PAR NAR AAA Server | RtSolPr | | | |------------------>| | | | PrRtAdv | | | |<------------------| | | | | | | disconnect | | | | | | | connect | | | | | | | | FNA[FBU] | | |-------------------|------------------>| | |AAuthReq[E(AAK),MAC_NAR,Nonce,MN_ID...]| | |-------------------|------------------>| | | | FBU | | | |<------------------| | | | FBack | | | |------------------>|AAA Request[E(AAK)..]| | | |-------------------->| | | | AAA Response[AAK..] | | |AAuthResp[MAC_MN..]|<--------------------| |<------------------|-------------------| | | | Network Access | |<==================|===================|=======> | | | Figure 3 Reactive Access Authentication. The way of generating the AAK is the same as Section 4.1. The MN generates the MAC_NAR using the AAK shared by the NAR as follows. MAC_NAR = H(MN_ID|NAR_ID|AAA_ID, E_AEMK(AAK)) XOR H(AAK) The MN also generates the MAC_AAA using the AAMK as follows: MAC_AAA = H(MN_ID|NAR_ID|AAA_ID|Nonce, E_AEMK(AAK)) XOR H(AAMK) XOR MAC_NAR After generating all the necessary data, the MN sends AAuthReq message to the NAR. AAuthReq[MN_ID,NAR_ID,AAA_ID,Nonce,E_AEMK(AAK),MAC_NAR,MAC_AAA] The NAR processes the FBU and the AAuthReq message. The NAR creates the authentication table of MN that consists of the MN_ID, nonce, and the MAC_NAR. After receiving the FAck of FBU, the NAR converts Jung, et al. Expires August 26, 2006 [Page 10] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 the data of AAuthReq message into the AVP format, and sends the AAA Request to the AAA server. The AAA Request message is generated as follows. AAA Request[MN_ID,NAR_ID,AAA_ID,Nonce,E_AEMK(AAK),MAC_NAR, MAC_AAA] The AAA server verifies the MAC_AAA using the shared AAMK, decrypts the AAK using the shared AEMK, and then sends the AAK to the NAR. Receiving the AAK, the NAR verifies the MAC_NAR using the nonce in the authentication table. After a successful verification, the NAR sends the AAuthResp message with the MAC_MN to the MN to notify a success. MAC_NAR = H(AAK, Nonce|MN_ID|NAR_ID) MAC_MN = H(Nonce|MN_ID|NAR_ID, AAK) If the MN receives a message regarding the FBU failure or access authentication failure, the MN initiates the access authentication procedure. After receiving the AAuthResp of success and verifying the MAC_MN, the MN can access network through the NAR. If the MN fails access authentication, the MN MUST carry out re-authentication process. 4.2.1. MN Behavior The generation and retransmission of the AAuthReq message is the same as Section 4.1.1. In case of the FBU failure, the MN MUST carry out re-authentication procedure using the AAuthReq message. In the reactive mode, the MN MUST include the nonce and MAC_NAR in the AAuthReq message. If the MN receives the AAuthResp including access failure or can not verify the MAC_MN, the MN MUST execute a re- authentication procedure. 4.2.2. AR Behavior Receiving the AAuthReq message, the NAR MUST converts the data of AAuthReq message into the AVP format, create the authentication table of the MN, and send the AAA Request to the AAA server if only the NAR receives the successful FAck. The NAR discards the AAuthReq message in case of failed FAck. If the NAR already received an AAuthReq from the MN but has not yet send a response about the AAuthReq to the MN, the NAR MUST silently discard the retransmitted request from the MN. After receiving the AAA Response from the AAA server, the result MUST Jung, et al. Expires August 26, 2006 [Page 11] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 be notified by the NAR to the MN. If the NAR receive an error message, the NAR MUST delete the authentication table of the MN and stop the access authentication, and then SHOULD announce the result of failure to the MN. Otherwise, the NAR MUST compare the MAC_NAR in the authentication table of the MN and the calculated MAC_NAR using the AAK receiving from the AAA response. After successful verification of the MAC_NAR, the NAR MUST send an AAuthResp including access approval and a MAC_MN to the MN. For a failure of verification, the NAR MUST reject the access of the MN and response the result of failure. The NAR MUST delete the authentication table of the MN when the MN handoffs to another NAR. 4.2.3. AAA Server Behavior The behavior of the AAA server is the same as Section 4.1.3. 5. Message Formats This memo defines a set of new messages such as AAuthReq, AAuthResp, and new mobility options to carry out access authentication for MN- NAR. 5.1. Access Authentication Request (AAuthReq) The AAuthReq MUST be sent from the MN to the AR for the access authentication. The AAuthReq message MUST be sent to the PAR before handoff. After handoff to the NAR, the MN MUST send the AAuthReq to the NAR. The AAuthReq message uses the MH(Mobility Header) Type[3] (to be assigned by IANA). 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Code | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Access Authentication Request (AAuthReq) Message. AAuthReq Fields Jung, et al. Expires August 26, 2006 [Page 12] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 Message Code 8-bit field indicate the access authentication protocol, the value of which is taken from the IANA. A value of '1' (to be assigned by IANA) indicates the AAuthReq message. Length 8-bit unsigned integer is the length of the AAuthReq message. Message ID 16-bit random value used to uniquely match the AAuthReq and the AAuthResp is set to a new value in case of re-authentication. Sequence Number 16-bit unsigned integer used by the AR to be matched to a sequence number of the AAuthResp message, and increased by one for each AAuthReq. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets. The encoding and format of defined options are described in Section 5.3. 5.2. Access Authentication Response (AAuthResp) The AAuthResp MUST be sent from the AR to the MN in responding to a AAuthReq message. The AAuthResp message use the MH(Mobility Header) Type[3] (to be assigned by IANA). Jung, et al. Expires August 26, 2006 [Page 13] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Code | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status Code |P|F| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 Access Authentication Response (AAuthResp) Message. AAuthResp Fields Message Code 8-bit field indicates the access authentication protocol, the value of which is taken from the IANA. A value of '200' (to be assigned by IANA) indicates the AAuthResp message. Length 8-bit unsigned integer is the length of the AAuthResp message. Message ID 16-bit random value used to uniquely match the AAuthReq and the AAuthResp. This value is copied from the corresponding AAuthReq. In the predictive mode, the NAR set '0xFFFF' if F flag is '1'. Sequence Number 16-bit unsigned integer matched to the sequence number of the AAuthReq message. In the predictive, the NAR set '0xFFFF' if F flag is '1'. Status Code 8-bit status code indicates the status of the AAuthReq. Jung, et al. Expires August 26, 2006 [Page 14] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 0 : Success. 100 : MAC_PAR verification failed. 101 : MAC_AAA verification failed. 102 : MAC_NAR verification failed. 200 : MN_ID option required. 201 : NAR_ID option required. 202 : AAA_ID option required. 203 : Nonce option required. 300 : Adminisratively prohibited. 400 : Invalid AAuthReq message. 401 : Invalid FNA message. P flag (Provisional response) In predictive procedure, the PAR set '1' to the P flag in responding to the AAuthReq. F flag (Final response) In predictive procedure, the NAR set '1' to the F flag in final response to the AAuthReq. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Mobility Options Variable-length field of such length that the complete Mobility Header is an integer multiple of 8 octets. The encoding and format of defined options are described in Section 5.3. 5.3. Mobility Options The AAuthReq and AAuthResp messages SHOULD have various options as follows. Jung, et al. Expires August 26, 2006 [Page 15] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code | Option Length | Option Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . ... . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 Options Message. MN_ID (Code number: to be assigned by IANA) The MN_ID field contains an identifier of the MN that is a new CoA. NAR_ID (Code number: to be assigned by IANA) The filed indicates the IP address of NAR. AAA_ID (Code number: to be assigned by IANA) This value may be present the IP address or the domain name of the AAA server. E_AEMK(AAK) (Code number: to be assigned by IANA) The encrypted message of an AAK using the AEMK Nonce (Code number: to be assigned by IANA) The random value generated by MN. MAC_PAR (Code number: to be assigned by IANA) This field has the MAC(Message Authentication Code) using the AAK_PAR to authenticate the MN at the PAR. MAC_AAA (Code number: to be assigned by IANA) The MAC_AAA is calculated by MN using AAMK for MN authentication. MAC_NAR (Code number: to be assigned by IANA) The MAC_NAR is used for AAK exchange between the MN and the NAR and MN authentication in the NAR. The value is generated by MN using the AAK and nonce. Jung, et al. Expires August 26, 2006 [Page 16] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 MAC_MN (Code number: to be assigned by IANA) The MN verifies the exchange of the AAK and authenticates the NAR using MAC_MN generated by NAR. 6. Security Considerations The overall scheme of this memo is about to make a secure delivery of an authentication key AAK from the MN to the NAR, in which no secure channel does exist. The proposed scheme assumes a secure channel between the AAA server and the AR protected by the IPsec or TLS. The AAA server and the MN also share a secret EMSK populated from the bootstrapping process. The AAK for access authentication, therefore, can de delivered securely from the MN to the NAR protected by those keys like the AAMK and AEMK which are derived from the EMSK. In the proposed scheme, since the MN generates the AAK without regards to the ARs for each handoff, the key AAK satisfies the property of PFS (Perfect Forward Secrecy). The process of predictive access authentication has a resistance against DoS attack by verifying the AAuthReq message with MAC_PAR. The process of reactive access authentication is also secure against DoS attack because the NAR issues the AAuthReq after verifying the FBU from the MN. 7. IANA Considerations The IANA will allocate the numbers to the AAuthReq, AAuthResp, and mobility options (see Section 5). 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] C Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [4] Aboba, B., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. Jung, et al. Expires August 26, 2006 [Page 17] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 [5] Aboba, B., "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-09 (work in progress), January 2006. [6] Patel, A., "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006. [7] Blake-Wilson, S., "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [8] Kent, S. "IP Authentication Header", RFC 2402, November 1998. [9] Kent, S. "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [10] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [11] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 8.2. Informative References [12] Narayanan, V., "Handover Keys Using AAA", draft-vidya-mipshop- handover-keys-aaa-01 (work in progress), October 2005. Author's Addresses Souhwan Jung Soongsil University 511, Sangdo-dong, Dongjak-ku Seoul 156-743 KOREA Phone: +82-2-820-0714 Email: souhwanj@ssu.ac.kr Jaeduck Choi Soongsil University 511, Sangdo-dong, Dongjak-ku Seoul 156-743 KOREA Phone: +82-2-824-1807 Email: cjduck@cns.ssu.ac.kr Jung, et al. Expires August 26, 2006 [Page 18] Internet-Draft Access Authentication Protocol in FMIP6 February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jung, et al. Expires August 26, 2006 [Page 19]