INTERNET-DRAFT Miyoung Kim Expires April 2003 Youngsong Mun Soongsil University Oct 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 steps for mobile node in the visited link may be reduced by delegating the role for generating 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. Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 1] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 The delegation model which enables that described above is also described 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 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 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 between 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 domains should be established to enable inter-domain roaming. To provide inter-domain authentication and authorization, the following entities for mobility and authentication/authorization support. - 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 visited domain. - H_AAA : AAA server in home domain. In general, there are 12 steps to complete the authentication for inter-domain roaming.[1] The embedding option to send a Binding Update and Binding Acknowledgement data 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 with 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 infra structure. +----------+ +----------+ | V_AAA | "AAA Network" | H_AAA | | Server |<----------------->| Server | +----------+ +----------+ ^ ^ | | | | | | v v +----------+ +----------+ | AAA | | Home | |Attendant | | Agent | +----------+ +----------+ ^ . . . v +----------+ <----> : Secure Channel | Mobile | <....> : Unsecure Channel | Node | +----------+ Figure 1. AAA Authentication Model The AAA network provides AAA servers with secure communication channels. The V_AAA and Attendant are the entities in the same administrative domain so they shares information on how to authenti- cate each other. The SAs based on pre-assigned authentication method are exist between H_AAA and NM's home agent. However, when the mobile node with its NAI belongs to the domain of H_AAA is entering into the foreign link with another domain, the attendant is not able to authenticate the mobile node since there's no security associations and secure shared key between them. To perform the normal Biding Registration Procedure[4], the authentication should be done prior to any mobility supporting procedures. The generation and distribution of session key can be performed by H_AAA or Home Agent [1]. 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- Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 3] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 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 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 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 delegation then it is neccessary for MN to know which AAA servers are used in delegation because if the MN moves into another link in the same domain with its current location, it will request the authentication to use that link to get a new session key managed by the AAA server which maintains also the delegation instance from previous location of MN. Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 4] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 2.2 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): 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): 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. BU(Binding Update): As defined in [4]. BA(Binding Acknowledgement): As defined in [4]. RC(AAA Result Code): indicates the result of authentication. It is composed with success(1)/fail(0) and cause code. 3. Message Sequence 3.1 General Flow The follwing figure shows what happens when MN is about to access the visited link. This represents the normal steps to distribute the secure shared key for MN and attendant. Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 5] 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 6] 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) - 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 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. 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. 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. 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. The parametes included in AHA message are Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 7] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 - RC result code(validity of m_AR). - sesstion_key the local secret between the MN and the attendant. - keying materials used in generation of session_key. - Nonce for replay protection. - Home address, if not in m_AR. - Home agent address, if not in m_AR. - Security parameters. - Authenticator of HA. 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 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 exampple. 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) Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 8] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 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 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 home agent. When the above case occurs, 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 intervals. 3.2.1 Delegation One 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 MN's current location. If MN sends the AReq message with delegation option, this message is relayed to the entity such as which H_AAA or Home Agent 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. It has If insufficient capablities, the the delegation request is ignored and the message is processed as specified in 3.1. When 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. 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. Miyoung Kim and Youngsong Mun. Expires 8 Apirl 2003 [Page 9] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 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 Home Agent has the right to manage the keying materials, the security context is transfered when Home Agent responds to AHR with AHA. The rest of processing is identical to the procedure described above. 3.2.2 Authentication Path There may exist more than one AAA servers in one domain for 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 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. Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 10] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 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_AR 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.3 Message Flow 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) - 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 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. If the delegation option exists in AHR then it should include the security context. The parametes included in AHA message are - RC result code(validity of m_AR). - sesstion_key the local secret between the MN and the attendant. - keying materials used in generation of session_key. - Nonce for replay protection. - Home address, if not in m_AR. Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 11] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 - Home agent address, if not in m_AR. - Security parameters. - Authenticator of HA. - Security Context for MN(if delegation option is used) 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 than the previous IPv6 packet. If delegation option is used, this message should contain the NAI of H_AAA. 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. MN Attendant V_AAA H_AAA HA | | | | | | AS | | | | |----------> | | | | | | | | | | AA | | | | |<--------------| | | | | | | | | | AReq | | | | |-------------->| m_AR | | | | |-------------------------->| | | | | | | | | | h_AA | | | | ARsp |<--------------------------| | | |<--------------| | | | | | | | | | BU | | | | |-------------------------------------------------------------->| | | | | | | | | | BA | |<--------------------------------------------------------------| | | | | | v v v v v Figure 4. Message Sequence for Authentication(Delegation) Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 12] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 2002 In the step 10 or 11, MN should save the Authentication Path with NAI of V_AAA and H_AAA from ARsp message. The step 5,6,7 and 8 is removed from the message sequence after delegation. The figure shows the message flow when delegation entry exists in V_AAA and it's lifetime is still vaild. By using the delegation, the round trips are reduced to 8 steps. When MN is roaming rapidly across the subnets within one domain, 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 The delegation model defined in this document does not create new security breaches for the IPv6 MN and the foreign and visited domain. On the contrary, it allows for an effective and efficient MN authentication and authorization when roaming across the subnet links in same domain as well as between different domains. 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. Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 13] INTERNET-DRAFT Localized Key Management for AAA in Mobile IPv6 Oct 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. 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 Miyoung Kim and Youngsong Mun. Expires Apirl 2003 [Page 14]