INTERNET DRAFT J. Floroiu Date: November 2002 FhG Fokus Expires: May 2003 Security Framework for the Access Control of MIPv6 Mobile Nodes 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. Abstract This draft proposes a few alterations to the Internet Key Exchange protocol (IKE) aimed at shortening the security associations and key management signaling. The resulting "IKE-like" exchange can easily be embedded into AAA/Mobile IP signaling, resulting in reduced registration and handover latencies. At the same time the premises for a secure access control and data traffic framework for the mobile nodes are created. Introduction In order to operate in a secure environment (especially when radio links are concerned) mobile nodes require a number of security associations to be setup between themselves and other entities that assist them during the roaming. In most cases the setup of such security associations must take place before any other signaling could proceed, making it a time critical operation. The AAA infrastructures have gained wide acceptance as instruments for handling the authentication and manage the access control of mobile nodes to visited networks. IKE along with a number of related protocols has been largely adopted for setting up secure communication channels between hosts. Floroiu [Page 1] INTERNET DRAFT November 2002 There has been a lot of experimentation in the area of "user plane" integration between Mobile IP and IPsec enabling the setup of "mobile VPNs" or the authentication (and possibly encryption over the public Internet) of Mobile IP tunnels. This draft aims at achieving "control plane" integration between AAA/Mobile IP and IKE by reusing as much as possible from existing protocols. The proposed protocol is based on mechanisms defined in IKE and related protocols [1,2,3] (many notations have been adopted as well). 1. Terminology Mobile Node (MN) Mobile IP mobile node as defined in [4,5] Attendant (Att), AAAL (subsequently denoted as AAAF), AAAH As defined in [6] Authentication header (AH) As defined [7] Encryption header (ESP) As defined [8] Security association (SA) As defined in [9] 2. Assumptions Figure 1 depicts the signaling that takes place between a MN and the AAA infrastructure. The "router system" (as defined in [6]) has been assimilated to Att. The AAA request/answer exchange between AAAH and HA (not present in [6]) uses to setting up a security association between MN and HA (at a minimum Binding Updates need to be protected through AH). MN Att AAAF AAAH HA | | | | | |-- AAA Req -->| | | | | |-- AAA Req -->| | | | | |-- AAA Req -->| | | | | |-- AAA Req -->| | | | |<-- AAA Ans --| | | |<-- AAA Ans --| | |<-- AAA Ans --| |<-- AAA Ans --| AAA Req = AAA Request AAA Ans = AAA Answer Figure 1: AAA Request-Answer exchange Floroiu [Page 2] INTERNET DRAFT November 2002 The following assumptions have been made: - Each pair Att-AAAF, AAAF-AAAH, AAAH-HA share a long term secret key which enables the two entities authenticate the AAA message exchange. The way such keys are obtained is outside the scope of this draft, and any technique may be employed for this purpose: Diffie-Hellman certificates, message exchange over an apriori established TLS connection or IPsec channel, manual configuration; - MN and AAAH share a long term secret key which enables the two entities authenticate the AAA message exchange. For MNs such keys may be distributed on SIM cards, for instance. 3. Security requirements Roaming mobile nodes may visit foreign domains about which they have no previous knowledge, hence share no trust relationship with. Not only need mobile nodes be able to establish such a relationship, but they also need to protect themselves against possible attacks which may be mounted by potential attackers visiting the foreign link. The foreign domain on the other hand needs to learn the mobile node's identity from a trusted party and ensure that no other node can pose as an authentic one. Therefore, the following objectives must be met: - Elimination of potential attacks based on MAC and IP address spoofing, by enabling MN establish an AH tunnel with Att; - Protection of the data traffic over the MN-Att segment by mean of an ESP tunnel. Typically this segment is a wireless link (which makes it vulnerable to eavesdropping) and even layer II encryption is insufficient since all other MNs which are authorized to access the link, share the same layer II encryption key, regardless the domain they originate from; MN may derive a shared secret with AAAF in order to avoid contacting AAAH each time it moves to a new Att within the same visited domain, enabling AAAF act as a trusted third party for the MN as long as the current authentication session hasn't expired. The way the AAA control messages exchanged between MN and the new Att are authenticated, is AAA specific, and it can be assimilated neither to a ISAKMP SA nor to a AH SA. A shared secret deriving from the SKEYID_d key negotiated by MN and AAAF (during phase 1) may however be appropriate for this purpose. Relevant to the interaction with the home agent, MN must at least establish an AH connection since at a minimum it must be able to protect the BU. Additionally, MN may want to also ensure the confidentiality of its data traffic, in which case an ESP tunnel must also be negotiated. Establishing security relationships with correspondent nodes may be achieved in a similar way. However setting up route optimization may be considered less time critical, therefore a MN may use reverse tunneling via HA until a standard IKE exchange with the CN completes. This draft does not address this case in detail. Floroiu [Page 3] INTERNET DRAFT November 2002 To conclude the discussion, figure 2 indicates the SAs a MN needs to establish in order to ensure a secure framework for access control and data traffic. MN Attendant AAAF AAAH HA | | | | | |<-- AH/ESP -->| | | | |<------ Local Auth Key ------>| | | |<--------------------------- AH/ESP --------------------->| Figure 2: SA protecting the MN's access control and data traffic The three sets of SAs can be established by performing three instances of the exchange described in the next section. The payloads can be merged into one jumbo control message so that the overall propagation delay is one MN-HA round trip (if, however, fragmentation is avoided). 4. The protocol 4.1. Notations A{K}(M) Authentication of message M with symmetric key K. M is typically the preceding payload and therefore abbreviated by "..." KE Diffie-Hellman public key N Nonces SA Security association payload sa Security association "pre-proposal" specifiying the protocols to be negotiated during phase 2. It is transmitted unprotected (unencrypted) and consists of a sequence of proposal payloads indicating only the protocols (not the transforms), the SPI field may be set to 0 IDc Client identity 1, 2 When follows KE, N, SA or sa indicates that the corresponding parameter is relevant to ISAKMP phase 1, respectively 2 _i, _r When used as suffixes indicate that the parameter is produced by the initiator, respectively by the responder Floroiu [Page 4] INTERNET DRAFT November 2002 HDR ISAKMP header * When follows HDR indicates ISAKMP encryption [ ] Indicates optional fields 4.2. Message exchange The message exchange that takes place between peers, as depicted in figure 1, may be decomposed into a number of elementary exchanges like in figure 3, where I (initiator) is the MN, R (responder) is either Att, AAAF or HA and T (trusted third party) is AAAH. I R T | | | | --- Message_1 --> | --- Message_2 --> | | <-- Message_4 --- | <-- Message_3 --- | | | | Figure 3: Request/Answer exchange between I, R and T It was already assumed that I and T, as well as R and T share trust relationships that enable the two pairs authenticate the message exchange, typically by using pre-shared keys (SK_it and SK_rt, respectively). Message_X (X = 1..4) denote the control messages exchanged by I, R and T which are typically composed of a sequence of AVPs containing control information relevant to the AAA and Mobile IP protocols. The set of existing AVPs is extended with a number of AVPs that encapsulate control information relevant to the SA and key management (a set of IKE payloads). The exchange of these latter AVPs is depicted in figure 4, each newly introduced AVP being delimited with angle brackets. All other AVPs are omitted for simplicity, therefore Msg_X should be considered as being embedded into Message_X (X = 1..4). Msg_1: I->R , A{SK_it}(...) Msg_2: R->T , A{SK_it}(...), , A{SK_rt}(...) Msg_3: T->R , A{SK_it}(...), , A{SK_rt}(...) Msg_4: R->I , A{SK_it}(...), Msg_5: I->R Figure 4: The exchange Floroiu [Page 5] INTERNET DRAFT November 2002 The authentication of the messages corresponding to the IKE phase 1 is delegated to the AAA infrastructure and it is done in a way consistent with the AAA specification, for instance by appending an AVP containing a HMAC computed over the protected fields. Msg_1 contains the IKE header, the phase 1 SA proposal, initiator's nonce, public DH key and a phase 2 SA "pre-proposal". The phase 2 SA "pre-proposal" cannot be encrypted at this stage, the contained information is therefore limited to enumerating the protocols the MN wants to negotiate in phase 2. The message is packed into one AVP which is authenticated using the pre-shared key known to I and T. Msg_2 is built by appending to Msg_1 a new AVP containing the response of R. This latter AVP is authenticated using the pre-shared key known to R and T. At this moment R does not know yet whether the IKE message received from I is authentic or not, therefore the computations it performs must be reduced to a minimum. R does not need to generate a fresh public DH key, since the same key may be reused for a limited time or number of connections, and R does not compute yet the shared secret. However R needs to generate a coockie and a nonce N1_r. Msg_3 contains the same 2 AVPs as Msg_2, but T reverses them, so that both I and R can authenticate the message sent by the peer. As R receives Msg_3, the authenticity of the IKE message sent by I is proven, therefore R consumes it. Then R computes the SKEYID suite of shared keys and constructs the (authenticated and encrypted) phase 2 message. The SA2_r proposal is compiled according to the MN's sa2_i "pre-proposal". Similar to IKE, PFS may be afforded by providing a new DH public key. Peer identifiers ID_cr and ID_ci are needed in order to indicate the peer's IP addresses. This is particulary important because for the IPsec connection with Att, MN uses the care-of address as the source address, while in home agent's SPD the peer's source address is the MN's home address. If the home address and the care-of address are dynamically allocated, they are assumed to be available at the moment Msg_4 is sent. Finally, I responds with Msg_5 indicating the accepted AH/ESP SA proposals. Upon reception of Msg_5, R derives the shared keys, installs the SAs and sets up the AH/ESP tunnels. I may immediately proceed with sending AH/ESP traffic. As soon as the initial SAs are in place, throughout the AAA authentication session's lifetime, and while connected through the same Att, the phase 2 SAs may be renegotiated periodically directly between I and R using a message exchange like the one below: Floroiu [Page 6] INTERNET DRAFT November 2002 Msg_3: I->R HDR*, HASH, sa2_i Msg_4: R->I HDR*, HASH(2), SA2_r, N2_r, [KE2_r], ID_cr, ID_ci Msg_5: I->R HDR*, HASH(1), SA2_i, N2_i, [KE2_i] SKEYID_a and SKEYID_e negotiated during phase 1 are used to authenticate and encrypt the exchange, which follows the same pattern as in figure 4. When moving to a new Att, MN and the new Att use AAAF as a trust party and follow the exchange described in figure 4. 5. Security Considerations The protocol aims at enhancing the security of MNs visiting foreign domains and relies on the security properties and trust model of the IKE protocol and AAA infrastructure. References [1] Harkins, D. Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998 [2] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998 [3] Piper, D., "The Internet IP Security Domain Of Interpretation for ISAKMP", RFC 2407, November 1998 [4] Perkins, C., Editor, "IP Mobility Support for IPv4", RFC 3344, August 2002 [5] Johnson, D., Perkins, C. Arkko, J. "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-19.txt, work in progress [6] Perkins, C., Eklund, T., "AAA for IPv6 Network Access", draft-perkins-aaav6-06.txt, work in progress [7] Kent, S., Atkinson, R., "IP Authentication Header", RFC 2402, November 1998 [8] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)" RFC 2406, November 1998 [9] Kent, S., Atkinson, R., "Security Architecture for the Internet Protocol", RFC2401, November 1998 Floroiu [Page 7] INTERNET DRAFT November 2002 Author's Address Questions about this memo can also be directed to: John Floroiu FhG Fokus 31 Kaiserin-Augusta-Allee 10589 Berlin, Germany Phone: +49 (0)30 3463 7144 Email: floroiu@fokus.fhg.de Floroiu [Page 8]