INTERNET-DRAFT Miyoung Kim Expires May 2003 Youngsong Mun Soongsil University Jaehoon Nah Seungwon Sohn ETRI Nov 2002 Localized Key Management for AAA in Mobile IPv6 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 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 [RFC 2119]. Abstract This document describes a way to distribute secure key for optimizing AAA authentication procedure while a mobile node is away from it's home. The AAA infrastrucrue is used as an underlying framework which enables a Mobile-IPv6 node to get an global authentication by identifying it with an unique identifier NAI. The Diameter messages are exchanged to transfer information of mobile node between home and foreign AAA servers. The steps to complete an authentication procedure for mobile node in the visited link may be reduced by delegating the role for generating Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 1] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 and synchronizing keys to AAA server in the visited domain. The implications to existing entities supporting mobility such as attendant, AAA server in home and visited domain are discussed. The delegation is introduced and the related security issues are pointed out. 1. Introduction This document specifies the way of authentication procedure which should be performed when a mobile node is accessing a network in the visited link. When a mobile node moves from a domain to another in away from home, if the framework such as AAA to provide the robust authentication in a secure way does not exist then an access to the resources in visited link will not be allowed in which results a mobile node fail on keeping on-going sessions. The Mobile IP draft-18 dose not specify a way how to authenticate a mobile node roaming across the different domains. For example, in a 802.11 wireless network [5], when a node tries to get an access to AP(Access Point) it should get the right to use the resources of that network with prior to any mobility supporting operations. If this process fails, the mobile node is not allowed to use that link so that on-going transport sessions will be dropped. To get a continueos mobility service, the contract and authentication method between the different domains should be established to enable inter-domain roaming. In order to provide inter-domain authentication and authorization, the following entities for mobility and authentication/authorization are defined. - Mobile Node: As defined in mobile ip working group. - Home Agent: As defined in mobile ip working group. - Attendant: An entry point of visited network.(e.g. AP in 802.11) - V_AAA: AAA server in the visited domain. - H_AAA: AAA server in the home domain. In general, there are 12 steps to complete the authentication for inter-domain roaming.[3] The embedding option to send a Binding Update and Binding Acknowledgement within AAA messages exchanged between AAA servers is proposed but it is exposed to an attacker since the mobility information(BU/BA) is used before SAs between mobile node and attendant are established. When a mobile node is moving rapidly on the subnets in the same domain, this document describes a way to enable a mobile node to resume the on-going sessions with minimized delay by simplifying the authentication procedure. Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 2] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 2. Model and Entities The following figure shows the model used in communication to distribute the session key between mobile node and attendant thorugh the AAA(Diameter[2]) infra structure. +----------+ +----------+ | V_AAA | "AAA Network" | H_AAA | | Server |<----------------->| Server | +----------+ +----------+ ^ ^ | | | | | | v v +----------+ +----------+ | AAA | | Home | |Attendant | | Agent | +----------+ +----------+ ^ . . . v +----------+ <----> : Secure Channel | Mobile | <....> : Insecure Channel | Node | +----------+ Figure 1. AAA Authentication Model The AAA network provides AAA servers with the secure communication channels. The V_AAA and Attendant are the entities in the same administrative domain so they share information on how to authenti- cate each other. The SAs based on pre-assigned authentication method exist between H_AAA and MN's home agent.[4] However, when the mobile node with its NAI which belongs to the domain of H_AAA is entering into the foreign link in another domain, the attendant is unable to authenticate the mobile node since there's no security associations and information to generate the shared security key between them. To perform the normal Biding Registration Procedure[4], the authenti- cation should be done prior to any mobility supporting procedures. The creation and distribution of the session key can be performed by H_AAA or Home Agent [1]. The Diameter protocol[2] is used to encapsulate the authentication request messages from the MN and deliver it to the AAA entity in the destination domain which is able to identify the MN. Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 3] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 2.1 Terminologies Attendant: AAA entity which is the local AAA system entry point and the local address provider/registry. In 802.11 wireless network [5]. AP can play a role for this. Term from [3]. AAA client: Attendant. It acts as a proxy to process the authenti- cation request/reply from(to) mobile node. In the perspecive of AAA infra-structure, the attendant can be a client sending a authentication request in behalf of mobile node. AAA server in home domain(H_AAA): AAA server of home network. The home agent and mobile node have the same domain identifier with its AAA server. It is assumed that the contract for global roaming across the different domains is established between AAA servers. AAA server in visited domain(V_AAA): AAA server of visited network AVP(Attribute Value Pair): The payload data to send the authenti- cation request/answer within the AAA messages to the entity associated with SA. Binding: home address/care-of address association for a mobile node on a mobility aware IPv6 node. MN(Mobile Node): an IPv6 mobile node distigushed with its NAI or home address. NAI(Network Authentication Identifier): An identifier to represent where the entity belongs. The entities in a domain also have the same domain identifier in its NAI. The way to represent it is described in [6]. CoA(Care-of Address): Temporary address used by MN during in the visited link. SA(Security Association): The security materials and algorithms to calculate the secure shared key between peers. HA(Home Agent): Home agent of MN which has the same doamin identifer with its AAA server. HoA(Home Address): A fixed address of MN allocated in its home link. The home address belongs to the home network and is in general well known by the mobile node even if the protocol described here supports home address allocation. Delegation Option: An option to delegate the role of generating and distributing the session key used between attendant and mobile node to an AAA server in the visited domain. Delegation Entry List: The instances of the table which indicate the MN's home agent or AAA server has delegated the key management roles to the AAA server in the visited domain. Only when the H_AAA/Home Agent and V_AAA have the same SA context, the the delegation entry is created as a response to Authentication Request. This entry has information on which MN is managed by V_AAA and how long it is vaild(lifetime), etc. Authentication Path: There may exist several AAA servers in one domain for administrative policy or redundancy. If delegation option is used and the delegation entry has created as the result of the delegation then it is neccessary for MN to know which AAA servers are used in delegation because if the MN Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 4] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 moves to another link without going outside the range of the current domain, it will request the authentication to attendant to use the new link and to get a new session key managed by the AAA server which is keeping the delegation instance created when the MN is in the previous location. Security Context: A set of information on how to process the authentication securely. It contains the algorithms to be used in creation of the session key and the security-related functions (e.g. hash, random generator, etc). Thus it represents the capabilities of the AAA/mobility Nodes. 2.2 Key Distribution In order to secure the messages between mobility entities(MN and HA) against the eavesdropping from unauthenticated node, there SHOULD be some security keys such as: - The key between the MN and the Attendant to protect the messages on the acess link. To provide the confidentiality and integrity for the access link, the all processes for mutual authentication between the MN and Attendant SHOULD be completed before sending any data over the link. If the MN is able to access the visited link without authentication, an attacker tries to deceive the attendant into becoming the victim of an illusion so that it can make the DoS attack for the MN and the Home Agent. Similary, if the MN dosen't authenticate the Attendant(e.g. Access Router or AP), an attacker can personate the attendant as if it is a legitimated node. (BTS attack). To authenticate each other, the MN and Attendant SHOULD ask for help to AAA servers and MN's Home Agent since there are authentication mechanism(SAs or pre-associated longterm keys) to the MN and Attendant. - The key between the MN and it's Home Agent to authenticate the binding registration(e.g. BU, BA). The AAA servers can take a role to compute and distribute these keys in behalf of the MN's Home Agent. The two methods are proposed[7]. (Key distribution based on Random Numner and Diffie Hellman) In Random Number approach, the home AAA server generates a random number for each required security key and it derives the security key from the random number and keying materials accoring to the SAs with the MN.[8] After derivation of the key, it sends the key to the attendant and the keying materials to the MN. Then the MN also generates the security key based on the SAs with the home AAA server. In this method, it is assumed that the SAs and the longterm key between the MN and its home AAA server MUST exist. As another approach the Diffie Hellman mechanism is used for distiributing the security key.[7] Diffie Hellman allows two nodes to establish a shared secret key in secure manner. The DH public values Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 5] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 for the two nodes must be authenticated using the AAA infrastructure and particularly the security association between the MN and its home AAA server and the security association between the V_AAA and H_AAA. This method provides the local AAA server with the authentication to the MN with DH public value, but the security key is unable to dereived since the the AAA server has no idea of the DH secret values. In this document, the Random Number method is used for generating the required session key. The Diffie-Hellman public values can be used to authenticate the MN but the detailed operation to the way of gaining the authentication for MN is not represented here. 2.3 Messages The messages related on authentication are as below (The definition of some messages are borrowed from[1].) AS(Attendant Solicitation): first message between the attendant and the mobile node. It is sent by the mobile node and its purpose is to discover or to select an attendant. At the point of time the MN knows its mobility it send this message to the attendant. AA(Attendant Advertisement): second message between the attendant and the mobile node. It is sent by the attendant and carries a local challenge issued or transmitted by the attendant. The local challenge is used for authenticating the messages between mobile node and attendant until the SA is established. AReq(Authentication Request): third message between the attendant and the mobile node. It is sent by the mobile node in order to ask for the allocation or the registration of local/care-of address. This message is loosely authenticated by the local challenge repeated from the AA. ARsp(Authentication Response): forth/last message between the attendant and the mobile node. It is sent by the attendant. We assume that in general the mobile node must wait for this message before sending a home registration (because this message validates the care-of address). m_AR(Authentication Request from MN): AAA message from the attendant to the AAAH. This is the first AAA message.(AAA message contains under score in the message name) The contents of this messages are mapped from the MN request, AReq. The attendant plays a role of mapping the contents of AReq/m_AR and ARsp/h_AA. h_AA(Authentication Answer from HA): AAA message from the AAAH to the attendant. This is the final AAA message.(AAA message contains under score in message name). It contains the session key and keying materials to distribute to attendant and mobile node. AHR(Authentication Home Agent Request): second AAA message from the AAAH to the HA. The contents of it is identical to m_AR. AHA(Authentication Home Agent Answer): third AAA message from the HA to the AAAH. It is mapped into h_AA. ASK(Security Key from AAA): When the 'Delegation' is used, the session key generated by local AAA server(V_AAA) should be sent to MN's Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 6] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 Home Agent to authenticate the binding registration messages. This messages is for carrying the created session key and additional information about the MN. BU(Binding Update): As defined in [4]. BA(Binding Acknowledgement): As defined in [4]. RC(AAA Result Code): indicates the result of authentication. It consists of the operation status(success(1)/fail(0)) and the cause code. 2.4 New Commands and AVPs The Diameter[2] protocol is flexible to extend with the new commands and parameters(AVP: Attribute Value Pair). In this section, we describe the commands and AVPs newly defined to form the Diameter messages from the request/response messages exchanged between MN and attendant. 2.4.1 New Commands This document introduces four new Command Codes: - m_AR: AA-Authentication-Request-from-MN (Code: Not specified, Abbrevation: MAR) - h_AA: AA-Authentication-Answer-from-H_AAA (Code: Not specified, Abbrevation: HAA) - AHR: AA-Authentication-Request-to-HA (Code: Not specified, Abbrevation: AHR) - ARA: AA-Authentication-Answer-from-HA (Code: Not specified, Abbrevation: ARA) - ASK: Security-Key-from-AAA (Code: Not specified, Abbrevation: ASK) The code value is not specified in this document since the Command Code should be assigned by the WG or IANA to avoid conflicting with existing code.(the abbrevation name is changable whenever the same name exists) 2.4.2 New AVPs The general format for Diameter AVP is defined like as [2]: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M P r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 7] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 Various AVPs are defined by Diameter WG as the standard parameters exchanged between Diameter peers.[2] In the message format, the length of the 'Data' field is variable and any type of data can be encoded into that field. We also define the 'Option' to carry the multiple parameters within an AVP. The options with the similar meaning are groupped into the same AVP. One or more options can exist in 'Data' field with distinct Option code and value. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V M P r r r r r| AVP Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code | Option Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Value .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Option Code: Code value assigned to each 'Options'(0-127) - Option Length: The length of 'Option Value' (Byte or Octet) - Option Value: The contents of the 'Option' To form and represent the Diameter message parameters by referecing the non-Diameter message sent by the MN, the new AVPs are defined as bellow. Group 1. Address AVP(Assigned Code1) It specifies the options related on address processing. - Care-of-Address-Option: MN's Care-of-Address.(Code = 0x00) The value is IPv6 Unicast Address of the MN. - Home-Address-Option: MN's Home Address. (Code = 0x01) This option can be used when the MN dosen't know information of its home address (bootstrapping on the visited link or home network renumberring) The value is IPv6 Unicast Address of the MN. - Home-Agent-Address-Option: MN's Home Agent Address.(Code = 0x02) This option is used when the MN dosen't know information of its home Agent Address as a result of the network renumbering or agent role change. The value is IPv6 Unicast Address of the MN's Home Agent. Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 8] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 Group 2. Security AVP(Assigned Code2) It specifies the options related on security processing. - Authenticator-Option: The hashed value to sign the contents of the message payload.(Code = 0x00) The MN and Home Agent can generate the authenticator to guarantee the integrity of the message. The value is 128-bit hash value. - Session-Key-Option: A secure key shared between the MN and Attendant(Code = 0x01). The MN's home agent generates and distributes the secure session key as a result of 'authenti- cation request' from the MN. If the 'Delegation-Option' is used and the local AAA server(V_AAA) has the delegation list entity for the MN then it takes a role of generating and distributing the session key in behalf of the MN's HA or H_AAA. - Key-Materials-Option: The materials referenced in generating the session key.(Code = 0x02) Only the peers associated with SAs can create the session key from this materials. - Nonce-Option: A random value for replay protection. (Code = 0x03) - Security-Parameter-Option: The additional security parameters. (Code = 0x04). This is undefined in this document now. - Security-Context-Option: Information on security-related capabilities for home agent or H_AAA.(Code = 0x04) The AAA(Diameter) servers on the home and visited domain has the security capabilities for their nodes. When the delegation option is used to delegate the role of generating and distributing the session key, the H_AAA gathers the set of information about SAs and keying materials established with the MN and sends it to the V_AAA. Receiving the security context, the V_AAA compares the context with its security capabilities. If it has the super-set of capabilities as to the security context sent from the delegating entity(H_AAA or HA) then it accepts the 'Delegation' and creates the delegation list entry for MN which makes the V_AAA be ready for generating and distributing the session key for MN. If the comparison fails then the delegation option is ignored.(In case of this happens, no delegation entity is created) - Random-Number-Option: A random number generated by the MN's Home Agent for each required session key. Group 3. Authentication-Path AVP(Assigned Code3) It specifies the options related on authentication path. - NAI-Option: NAI of the AAA(Diameter) servers while processing the authentication. (Code = 0x00) The V_AAA server has the delegation list entity for the MN when the delegation option is processed successfuly. Considering the situation of multiple AAA servers exists in a domain, we should provide a way for MN to select the exact AAA server which contains the delegation entity for MN. When returing for the authentication request, the H_AAA and V_AAA specifies their NAI into the return message and it delivered to the MN. The MN extracts the path information from it for future uses. Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 9] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 Group 4. Action AVP(Assigned Code4) It specifies the options for actions requested from the MN and HA. - Delegation-Option: To delegate the H_AAA's role to V_AAA(authenti cation, creation and distribution of the session key) (Code = 0x00) It requires the security context transmission from H_AAA to V_AAA. The value is True(1) or False(0). - Delegation-Lifetime-Option: Specifies the aliveness of the dele- gation list entry. (Code = 0x01) This value is set by delegating eneity(H_AAA or home agent)(Default life time = 300sec). If it expires the delegation list entry is removed from V_AAA. The value is timetick for timeout. - Dynamic-Home-Agent-Discovery-Option: Request the action to dynamic home agent address discovery(Code = 0x02). If the MN lost the information of the home agent when the MN is powered-up in the visited link or the network prefix has changed for renumbering which may causes the HA role switchig then H_AAA should perform the action to find the HA for MN. The action of home agent discovery is performed as described in [4]. The value is the IPv6 Unicast address of a new home agent. - Result-Code-Option: The status of message processing.(Code = 0x03) It indicates the result of requested actions. The values are Success(1), Fail(>1). In case of operation fails, the code values are: NAI_ROAMING_INVALID(2): The NAI value is not valid. DELEGATION_NOT_ACCEPTED(3): The delegation request has failed. 3. Message Sequence 3.1 General Flow All steps for message exchage is divided into two categories.(Authenti cation and Binding Registration) When the first time the MN enters into the visited link, the normal IP packets excepting for Authentication messages should be blocked (pending or discarding). The local router may perform the 'Neigbor Discovery' operation [6]. If the MN is in the visited domain but the authentication is not started or in progress, the attendant should block the messages. The follwing figure shows what happens when MN is about to access the visited link. This represents the normal steps to distribute the shared secure key for MN and attendant. Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 10] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 MN Attendant V_AAA H_AAA HA | | | | | | AS | | | | |----------> | | | | | | | | | | AA | | | | |<--------------| | | | | | | | | | AReq | | | | |-------------->| m_AR | | | | |-------------------------->| m_AR | | | | |----- >| AHR | | | | |---------->| | | | | | | | | | AHA | | | | h_AA |<----------| | | h_AA |<------| | | ARsp |<--------------------------| | | |<--------------| | | | | | | | | | BU | | | | |-------------------------------------------------------------->| | | | | | | | | | BA | |<--------------------------------------------------------------| | | | | | v v v v v Figure 2. Message Sequence for Authentication(General Case) Step 1. Message: Attendant Solicitation(AS) Send to: IPv6 multicast address Parameters(AVPs): None Pre-condition: None Behavior: MN tries to find the attendant(entry point of visited link) by sending this message at the time when MN knows it has moved. If there is no reply from attendant, this message is issued periodically until it finds out the attendant. Step 2. Message: Attendant Advertisement(AA) Send to: MN's address(Care-of) Pre-condition: None Behavior: If AS message received from MN, replies to MN with local challenge used to authenticate the AReq message in Step 3. The local challenge is likely to be a random number or cookie. Step 3. Message: Authentication Request(AReq) Send to: discovered attendant address Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 11] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 Pre-condition: None Behavior: MN sends AReq to request the attendant to perform the AAA protocol operations to get a session key. The parameters included in this message are - LC(local challenge): received from AA - NAI(MN identity) - Nonce - Home address of MN - Home agent address on MN - Authenticator(signature of the parameter set) Step 4. Message: Authentication Request for MN(m_AR) Send to: Local AAA server in the visited domain(V_AAA) Pre-condition: The communication channel between attandant and V_AAA is secure with some key meterials for protection of AAA message. Behavior: Same content as the previous IPv6 packet (translated to AAA message). The attendant extracts the payload data from AReq and constructs a new m_AR message with parameter set(AVPs) from the payload. - Authentication-Path AVP NAI-Option - Address AVP Care-of-Address-Option Home-Address-Option Home-Agent-Address-Option - Security AVP Authenticator-Option Nonce-Option Security-Parameter-Option Step 5. Message: Authentication Request for MN(m_AR) Send to: H_AAA Pre-condition: The communication channel between AAA servers is protected by AAA infra-structure. Behavior: Same content as the previous IPv6 packet(translated to AAA message). V_AAA finds where the message sent by referencing the parameter NAI which identifies the domain address and validate the it based on the global roaming contracts or SAs with H_AAA server. If the NAI is not valid(wrong NAI or unallowed roaming request) then the V_AAA send the h_AA messages with the Result-Code-Option NAI_ROAMING_INVALID in Action-AVP. Step 6. Message: Authentication Request to Home Agent(AHR) Send to: Home Agent of MN Pre-condition: None Behavior: H_AAA determines which home agent is a destination of this message from the paramater(Home Agent Address) in m_AR. Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 12] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 It send AHR to the home agent with some security parameters, authenticator and home address of MN. If m_AR dose not include the home agent address, H_AAA can perform the DHAAD(Dynamic Home Agent Address Discovery)[4]. Step 7. Message: Authentication Answer from Home Agent(AHA) Send to: H_AAA Pre-condition: The communication channel between Home Agent and H_AAA is secure with some key meterials for protection of AAA messages. Behavior: HA authenticates the AHA message using the authenticator and security parameters. If it's successful, HA accepts the the message and then generates a session key using the security materials received from mobile node and attendant. HA saves the session key into its secure storage(e.g. memory or local storage) The parametes included in AHA message are: - Address AVP Home-Address-Option(if not in m_AR) Home-Aagent-Address-Option(if not in m_AR) - Security AVP Authenticator-Option Session-Key-Option Nonce-Option Key-Materials-Opton Random-Number-Option - Action AVP Result-Code-Option Step 8. Message: Authentication Answer(h_AA). Send to: V_AAA Pre-condition: H_AAA maintains the request transaction until it responds with h_AA to V_AAA. Behavior: Same content as the previous IPv6 packet(translated to AAA message). Step 9. Message: Authentication Answer(h_AA) Send to: Attendant Pre-condition: None Behavior: Same content as the previous IPv6 packet. Step 10. Message: Authentication Response(ARsp) Send to: MN's address(Care-of) Pre-condition: None Behavior: The attendant extracts the session_key from previous message and saves it into local storage protected by a secure manner. It reconstructs ARsp message with the parameters Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 13] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 received from h_AA excepting session_key. Step 11. Message: Binding Update(BU) Send to: MN's home agent Pre-condition: SAs exist between mobile node and it's home agent. Behavior: MN authenticates the ARsp message using the authenti- cator. MN extracts the keying materials from the message and calculates the session_key with the materials based on pre- established SAs with it's home agent. MN saves the session_key into the local storage or memory. It may also save the home and home agent address if it has not information on these addresses due to the bootstrapping of the device within the visited network for example. MN send binding update message to register its location[4]. The session_key is used to protect the traffic between mobile node and attendant.(Since the attendant is likey to be an AP in 802.11 wireless network[5], all traffics from MN are transmitted throught out the AP) Step 12. Message: Binding Acknowledgement(BA) Pre-condition: None Behavior: HA perfroms the binding registration procedure as described in mobile IP[4]. 3.2 Optimized Flow - Delegation Under the condition of moving rapidely from the area to another within a business domain(the area governed by a ISP or Network Provider), the flow of messages described in Section 3.1 is inadequate for this situation since the message overhead is also increased in proportional to the MN's movement. In this section, we represent what is needed to optimize the flow of messages and how to accomplish it. 3.2.1 Background From the perspectives of ISP or Network Provider, success or fail of the business depends on the range of coverage and the contents it provides. The broadband wireless coverage is relativley shorter than wired. So, Cellular network consists of many cells which conqures the small range of coverages by the base station centered in the cell. The network designer should pay attention to make the cells bind well. The Wireless LAN(WiFi - 802.11b/a) has a preference for broadband services because it has the strength of the air-link speed. It also has an access point in an area which may exist in the same or different subnets. From this point of view, the subnets of an ISP consists of more than one APs binded tightly with its neighbors. Miyoung Kim and Youngsong Mun. Expires 8 Apirl 2003 [Page 14] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 When MN is changing its location rapidely moving across the subnets within the same administrative domain, one may guess that MN is more closer to V_AAA than the H_AAA and it's home agent. If the MN's subnet prefix is changed by its movement then it sends the binding update message to its home agent. If the MN changes it location(subnet prefix) frequently but stays long in the same domain, it is ineffective that MN gets a session_key and registers its current location according to 12 steps described in 3.1 because this happens very often within a breif time interval. If an AAA entity in the visited domain is capable of processing the authentication requests from the MN on behalf of the entities in MN's home domain, the procedure to complete 'binding update' takes 8 steps including the authentication. The security context(SA context) is a collection of the capabilities of SA between the MN and HA as described before. If the AAA entity has the same context with SA(between MN and HA) and HA or H_AAA can transfer the shadow of the SA to requesting AAA entity, the all processes of authentication is under the control of that entity until the timer value set by HA or H_AAA in context transmission is expired. 3.2.2 Delegation An option is defined to delegate the V_AAA to manage the keying materials and SAs context for MN. This option is sent by MN when requesting authentication with AReq message. When MN enters the visited link in different domain, the 12 steps described in 3.1 are performed to get a session_key and registers the MN's current location. If MN sends the AReq message with delegation option, this message is relayed to the entity such as H_AAA or Home Agent which plays the role of generating and distritbuting session key and keying materials. If H_AAA has the right to manage the keying materials, the security context used to authenticate and generate session_key for MN is transfered when H_AAA responds to the m_AR with h_AA. Then V_AAA will receive the h_AA message with security context. V_AAA compares its capablities with security context(SAs, algorithms, hash functions, etc.). If it has capabilities specified in the security context then V_AAA create an entry into the delegateion entry list to accept and process delegation request. If it has insufficient capablities, the the delegation request is ignored and the message is processed as specified in 3.1. If MN moves to another visited link in the same domain with MN's previous location and the delegation request option is set, V_AAA determines whether the MN is registered in delegation entry list. Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 15] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 If the entry exists then V_AAA authenticates the MN and generates the session_key according to the security context. After the delegation procedure is completed, V_AAA responds to m_AR with h_AA which contains session_key, keying materials and some security parameters. The delegation entry is maintained by V_AAA untile the lifetime is expired.(the lifetime is specified by H_AAA, default value is 300sec) If the lifetime expires the delegation entry is removed from the delegation list. The lifetime may be refreshed by a request from H_AAA(optional). When the home agent has the right to manage the keying materials, the security context is transfered when the home agent responds to AHR with AHA. The rest of processing is identical to the procedure described above. 3.2.3 Authentication Path There may exist one or more AAA servers in a domain for the purpose of redundancy or administrative policy. +-----------------------+ +-----------------------+ | +--------+ +--------+ | | +--------+ +--------+ | | | V_AAA1 | | V_AAA2 | | | | H_AAA1 | | H_AAA2 | | | +--------+ +--------+ | AAA Network | +--------+ +--------+ | | +--------+ |<------------->| +--------+ | | ..... | V_AAAn | | | ..... | H_AAAn | | | +--------+ | | +--------+ | +-----------------------+ +-----------------------+ ^ ^ | | | | v v +------------+ +------------+ | Attendant | | Home Agent | +------------+ +------------+ ^ | | v +------------+ |Mobile Node | +------------+ Figure 3. AAA Authentcaion Model with Multiple AAA Servers Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 16] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 By delegation, V_AAA has an entry with security context for MN. But this entry information is not distribute to all AAA servers in the visited domain because it is difficult to manage the AAA servers with consistency for refreshment and deletion of the entry. To disthinguish and select the exact V_AAA which is used in the first request for the delegation, the 'Authentication Path' is defined. The authentication path consists of the NAI of H_AAA and V_AAA which is returned by H_AAA and V_AAA. If the delegation option is set, when H_AAA returns the h_AA after processing the AHA, it returns h_AA with it's NAI. When V_AAA returns h_AA the NAI of V_AAA is also added into h_AA. MN receives the ARsp from attentant which contains the authentication path(NAI of V_AAA and H_AAA) and saves it into local storage or memory. In the next movement to another link in the same domain, MN uses this information to specify the AAA server which maintains the delegation entry for MN. 3.2.4 Message Flow - Changed from 3.1 The step 3,7,8 and 9 is modified to process delegation option. (The first entering into a different domain) Step 3. Message: Authentication Request(AReq) Send to: discovered attendant address Pre-condition: None Behavior: MN sends AReq to request the attendant to perform the AAA protocol operations to get a session key. The parameters included in this message are - LC(local challenge): received from AA - NAI(MN identity) - Nonce - Home address of MN - Home agent address on MN - Authenticator(signature of the parameter set) - Delegation Option(True or False) Step 7. Message: Authentication Answer from Home Agent(AHA) Send to: H_AAA Pre-condition: The communication channel between Home Agent and H_AAA is secure with some key meterials for protection of AAA messages. Behavior: HA authenticates the AHA message using the authenticator. If it's successful, Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 17] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 HA accepts the the message and then generates a session key using the security materials received from mobile node and attendant. If the delegation option exists in AHR then it should include the security context used in generating the session_key. The session key and it's keying materials are computed as below: session_key = prf(N_m | N_h, m_HoA, m_CoA, h_R) key_material = {Nonces(N_a, N_h), SPI, HASH,..} where, m_HoA is the home address of MN and m_CoA the Care-of address and h_R is the random number generated by MN's Home Agent for each required session key. The parametes included in AHA message are: - Address AVP Home-Address-Option(if not in m_AR) Home-Agent-Address-Option(if not in m_AR) - Security AVP Nonce-Option Security-Parameter-Option Security-Context-Option(if delegation option is used) Session-Key-Option Key-Materials-Option Random-Number-Option - Action AVP Result-Code-Option Step 8. Message: Authentication Answer(h_AA) Send to: V_AAA Pre-condition: H_AAA maintains the request transaction until it responds with h_AA to V_AAA. Behavior: When the delegation option is used,V_AAA compares its capabilities with the security context received from HA or H_AAA to determine whether it creates an delegation entry or not. If it has sufficient capabilities then it make an entry for MN into delegation list. h_AAA has the same content as the previous IPv6 packet. If delegation option is used, this message should contain the NAI of H_AAA. - Authentication-Path AVP NAI-Option(If delegation option is used) - Address AVP Home-Address-Option(if not in m_AR) Home-Agent-Address-Option(if not in m_AR) - Security AVP Security-Parameter-Option Security-Context-Option(if delegation option is used) Session-Key-Option Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 18] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 Key-Materials-Option Random-Number-Option - Action AVP Result-Code-Option Step 9. Message: Authentication Answer(h_AA) Send to: Attendant Pre-condition: None Behavior: Same content as the previous IPv6 packet. If delegation option is used, this message should contain the NAI of V_AAA. Upon receiving this message, the attendant takes the session key from the Session-Key-Option and saves it into its memory or local storage.(which is protected from being exposed to external nodes) - Authentication-Path AVP NAI-Option(If delegation option in used) - Address AVP Home-Address-Option(if not in m_AR) Home-Agent-Address-Option(if not in m_AR) - Security AVP Security-Parameter-Option Session-Key-Option Key-Materials-Option Random-Number-Option - Action AVP Result-Code-Option In the step 10 or 11, MN should save the Authentication Path with NAI of V_AAA and H_AAA from ARsp message. Taking the keying materials(Key-Materials-Option) and random number (Random-Number-Option), the MN computes the session key using the computation algorithm based on the pre-established SAs. 3.2.5 Message Flow - Delegation for Session Key The V_AAA has a delegation entry for the MN after finished the request from MN which had a Delegation-Option if it was successful. The V_AAA can take two steps for processing the request with the delegation option. First, it checks whether the NAI or CoA of the MN is belong to the delegation list in V_AAA.(It means that the delegation is already processed through this V_AAA server and the lifetime of it is not expired yet.) Second, if the delegation entry for MN has found in V_AAA, it generates the session key between the MN and Attendant that allows the MN to use the network resources(e.g. wireless link) in the visited domain or area(Attendant) and delivers it to the MN when returning the h_AA message by adding the options for the session Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 19] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 key.(Session-Key-Option, Key-Materials-Option) We dipicts the delegation processing after the delegation list entry for MN has created in V_AAA.(It means that the MN has entered the visited domain and moves across one or more subnets which belongs the same domain) The procedure for the authentication request from MN is performed as the following sequence : MN Attendant V_AAA H_AAA HA | | | | | | AS | | | | |----------> | | | | | | | | | | AA | | | | |<--------------| | | | | | | | | | AReq | | | | |-------------->| m_AR | | | | |-------------------------->| | | | | | | | | | h_AA | h_AA | | | ARsp |<--------------------------|------>| ASK | |<--------------| | |---------->| | | | | | | BU | | | | |-------------------------------------------------------------->| | | | | | | | | | BA | |<--------------------------------------------------------------| | | | | | v v v v v Figure 4. Message Sequence for Authentication(Delegation) Step 1. Message: Attendant Solicitation(AS) Send to: IPv6 multicast address. Parameters(AVPs) : None Pre-condition: None Behavior: MN tries to find the attendant(entry point of visited link) by sending this message at the time when MN knows it has moved. If there is no reply from attendant, this message is issued periodically until it finds out the attendant. Step 2. Message: Attendant Advertisement(AA) Send to: MN's address(Care-of) Pre-condition: None Behavior: If AS message received from MN, replies to MN with local Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 20] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 challenge used to authenticate the AReq message in Step 3. The local challenge is likely to be a random number or cookie. Step 3. Message: Authentication Request(AReq) Send to: discovered attendant address Pre-condition: None Behavior: MN sends AReq to request the attendant to perform the AAA protocol operations to get a session key. The parameters included in this message are - LC(local challenge): received from AA - NAI for MN and AAA servers(for Authentication Path) - Nonce - Home address of MN - Home agent address on MN - Authenticator(signature of the parameter set) - Delegation Option(True or False) Step 4. Message: Authentication Request for MN(m_AR) Send to: Local AAA server in visited domain(V_AAA) Pre-condition: The communication channel between attandant and V_AAA is secure with some key meterials for protection of AAA message. Behavior: Same content as the previous IPv6 packet (translated to AAA message). The attendant extracts the payload data from AReq and constructs a new m_AR message with parameter set(AVPs) from the payload. When the V_AAA receives this message, it validates the NAI of the MN to decide if the requests will be allowed or not. If it is not valid(wrong NAI or unallowd roaming request) then the V_AAA SHOULD send the h_AA to attendant with Result-Code-Option(NAI-ROAMING-INVALIDE) of the Action-AVP. In successful, if it contains the Action AVP with Delegation-Option then the V_AAA looks up the delegation entriy if an entry for MN exists or not. The parameters for m_AR are: - Authentication-Path AVP NAI-Option - Address AVP Care-of-Address-Option Home-Address-Option Home-Agent-Address-Option - Security AVP Authenticator-Option Nonce-Option Security-Parameter-Option - Action AVP Delegation-Option If the entry exists and the lifetime is still alive then the V_AAA can compute the session_key and its keying materials as follow: Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 21] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 session_key = prf(N_m | N_a, m_HoA, m_CoA, a_R) key_material = {Nonces(N_a, N_m), SPI, HASH,..} where, N_a is a nonce value generated by the V_AAA in bahalf of the MN's Home Agent or H_AAA server. m_HoA and m_CoA are the Home Address and Care-of Address of the MN as descibed before. the a_R is a random number generated by V_AAA for each required session key. All parameters except for the random number and nonce are referenced from the Security Context in the delegation list entry for MN. Step 5. Message: Authentication Answer(h_AA) Send to: Attendant Pre-condition: None Behavior: V_AAA generates and delivers the session key and keying materials to Attendant. Result-Code-Option indicates the result of authentication request. - Security AVP Authenticator-Option Session-Key-Option Key-Materials-Option Nonce-Option Random-Number-Option - Action AVP Result-Code-Option In this step, it must send the clone of the session_key to the MN's H_AAA or HA. In case of this flow, the ASK message is used to carry the session key and additional information about the MN. - Security AVP Session-Key Option - Address AVP Home-Address-Option Home-Agent-Address-Option The session key forwarded to MN's home agent is used to authenticate the consequence binding registration messages from the MN. Step 6. Message: Authentication Response(ARsp) Sent to: MN's CoA Pre-condition: None Behavior: When the attendant recieves this message, it should extracts the session_key with MN and stores it into it's local storage area to authenticate the session between the MN and the attendant. Notice that it should not send the session_key itself to the MN before the session is protected by it. The attendant converts the AAA(Diameter) message into the message Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 22] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 known to the MN and Attendant(e.g. EAP) - Nonce(wihch generated by V_AAA for replay protection) - Keying Materials. - Random Number. - Authenticator Step 7. Message: Binding Update(BU) Send to: MN's home agent Pre-condition: SAs exist between mobile node and it's home agent. Behavior: It takes the same actions as Step 11 described in the Section 3.1(General Flow). Step 8. Message: Binding Acknowledgement(BA) Pre-condition: None Behavior: HA perfroms the binding registration procedure as described in mobile IP[4]. If we compare to general flow, the step 5,6,7 and 8 is removed from the message sequence after the delegation. By using the delegation, the round trips are reduced to 8 steps. When MN is roaming rapidly across the subnets within a domain, the MN tries to get a session key to access the communication resource of the visited link. The delegation model is appropriate in this case when taking account of the locality of MN's movement. If MN moves into another domain, the 12 steps specified in 3.1 is performed. If delegation request fails, the 12 steps specified in 3.1 is also performed. 4. Security Considerations Two methods the authentication and distribution of the security key are proposed[7][8]. It uses the methods based on the random number and Diffie Hellman mechanism. In this document, we applies the Random Number mechanism to dereive the security key from V_AAA. The AAA infra structure(Diameter) is used to distribute the security key with secure manner. To optimize the message exchange steps and to provides the continuity of the mobility service, we introduces the 'Delegation Model' which enables the MN to establish the session key with its Home Agent and the attendant in the visited link. Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 23] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 The delegation model defined in this document does not create new security breaches for the IPv6 MN and AAA entities in home and visited domain. On the contrary, it allows for an effective and efficient authentication and authorization to the MN when roaming across the subnet links in the same domain as well as between different domains. As the rocality of MN's movement grows, this method is effective to used when the MN is moving rapidly across the links in a same AAA domain. 5. Acknowledgments All the RFC's, ID's, freely available 802.11 standards, and web-sites. 6. References [1] F. Dupont, J. Bournelle " AAA for Mobile IPv6", draft-dupont-mipv6-aaa-01.txt, Internet Draft, IETF, Nov, 2001. [2] Pat R. Calhoun, Erik Guttman, Jari Arkko, "Diamet Base Protocol", draft-ietf-aaa-diameter-12.txt, Internet Draft, IETF, July,2002. [3] Pat R. Calhoun, Tony Johansson, Charles E. Perkins, "Diameter Mobile IPv4 Application", draft-ietf-aaa-diameter-mobileip-11.txt,Internet Draft, IETF, June, 2002. [4] Davied B. Johnson, Charles E. Perkins, Jari Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-18.txt, Internet Draft, IETF, June, 2002. [5] IEEE, "Part 11: Wireless LAN Medium Access Control(MAC) and Physical Layer(PHY) Specifications", 1999. [6] P.Calhoun, C.Perkins, "Mobile IP Network Access Identifier Extension for IPv4", RFC 2794, IETF, March, 2000. [7] Franck Le, Basavaraj Patil, Charles E. Perkins "Diameter Mobile IPv6 Application", draft-le-aaa-diameter-mobileipv6-01.txt, Internet Draft, IETF, November, 2001. [8] Pat R. Calhoun, Charles E. Perkins, "Diameter Mobile IPv4 Application" Internet draft, Internet Engineer Task Force, November 2001. Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 24] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 7. Author's Address Miyoung Kim, Ph.D Student Department of Computing, Soongsil University, #1-1 SangDo-5 Dong, DongJak-Gu, Seoul, 156-743 Korea Phone: +82-2-812-0689 Fax: +82-2-822-2236 E-mail: mizero31@sunny.soongsil.ac.kr Youngsong Mun, Professor Department of Computing, Soongsil University, #1-1 SangDo-5 Dong, DongJak-Gu, Seoul, 156-743 Korea Phone: +82-2-820-0676 Fax: +82-2-822-2236 E-mail: mun@computing.ssu.ac.kr Jaehoon Nah Network Security Department, ETRI #161 Gajeong-Dong Yuseong-Gu Daejeon, seoul, 305-350 KOREA Phone: +82-42-860-6749 Fax: +82-42-860-5611 E-mail: jhnah@etri.re.kr Seungwon Sohn Network Security Department, ETRI #161 Gajeong-Dong Yuseong-Gu Daejeon, seoul, 305-350 KOREA Phone: +82-42-860-5072 Fax: +82-42-860-5611 E-mail: swsohn@etri.re.kr Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 25]