Internet Engineering Task Force Francis Dupont INTERNET DRAFT ENST Bretagne Expires in May 2002 Maryline Laurent-Maknavicius INT Evry Julien Bournelle INT Evry November 20, 2001 AAA for mobile IPv6 Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC 2026. This document is an Internet-Draft. 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. Distribution of this memo is unlimited. Abstract IPv6 mobility [5] has many security requirements which can be roughly divided into security of signaling with common correspondent nodes [6] and security between the mobile node and its home agent. If IPsec [1] is not so usable in the first case it remains the solution of choice in the second. Unfortunately IPsec does not allow reasonable performance in some common situations. One of the main problems is the lack of integration with a modern network access service security like the one provided by AAA [7]. draft-dupont-mipv6-aaa-01.txt [Page 1] INTERNET-DRAFT AAA for mobile IPv6 November 2001 This document describes a solution that allows the AAA infrastructure to authenticate/authorize an IPv6 mobile node, and to create credentials for securing subsequent AAA exchanges. The original idea is that the mobile node is allowed to dynamically establish a security association pair with its home agent during AAA exchanges using the AAA system as a trusted third party. For simplification purpose, it is assumed that Mobile IPv6 security between the mobile node and the home agent is based on IPsec. Note that the described solution is still valid for any other similar security mechanisms selected for Mobile IPv6. Table of Contents 1 Introduction .................................... Page 2 2 Short movement case ............................. Page 3 3 Boot in visit case .............................. Page 3 3.1 Schema ........................................ Page 3 3.2 Terminology ................................... Page 4 3.2.1 General terms ............................... Page 4 3.2.2 Messages .................................... Page 5 3.2.3 Payloads .................................... Page 5 3.3 Motivations ................................... Page 7 3.4 Security context .............................. Page 8 3.5 Protocol overview ............................. Page 9 3.6 IPsec and ISAKMP/IKE detailed example ......... Page 10 4 Security Considerations ......................... Page 11 5 Acknowledgments ................................. Page 11 6 Normative References ............................ Page 11 7 Informative References .......................... Page 12 8 Authors' Addresses .............................. Page 12 1. Introduction Experiments with secure mobile IPv6 show that in some circumstances performance of IKE [2] exchanges followed by mobile IPv6 signaling (binding update and acknowledge) is not reasonable, so some combinations with AAA were proposed. Access to a new foreign network by a mobile node can be (and should be!) optimized in two cases: - when the new network is closed to the previous one (short movements) - when the mobile node boots in a foreign network (boot in visit) The last case can be unbearable because a common mobile node should get a care-of address then do a main mode IKE exchange followed by a quick mode IKE exchange before sending a home registration: at least 13 packets between local and home networks and at least 5 round trip times without taking into account cryptography function computing... draft-dupont-mipv6-aaa-01.txt [Page 2] INTERNET-DRAFT AAA for mobile IPv6 November 2001 This document defines the information to be exchanged between the mobile node and the AAA attendant, but the mechanism to convey this information is considered outside the scope of this document. This document only assumes such a mechanism exists with the following properties: - the mechanism has two phases (solicit/advertise then request/ reply) - the advertisement message contains a local challenge - the protocol can carry AAA payloads. For simplification purpose, it is assumed this protocol is the IPv6 address allocation or registration one but in fact only its network access control aspects are used. This document assumes reasonable knowledge of mobile IPv6 [5], DHCPv6 [9], AAA [7] and IPsec [1]. 2. Short movement case In the short movement case the previous AAAL is likely to be far closer to the new AAAL than the AAAH, so the transfer of the authentication credentials from the previous AAAL is a suitable option. Consequently, the mobile node should provide the new attendant/ AAAL server with the identity (NAI) of the previous attendant/AAAL server and share an AAA security association with it (in order to protect the transfer against a rogue MN). 3. Boot in visit case 3.1 Schema +--------+ "AAA network" +--------+ | AAAL |<------------------->| AAAH | | server | | server | +--------+ +--------+ ^ ^ | | | | v v +-----------+ +---------+ | AAA | | Home | | Attendant | | Agent | +-----------+ +---------+ ^ | | v +--------+ | Mobile | | Node | +--------+ draft-dupont-mipv6-aaa-01.txt [Page 3] INTERNET-DRAFT AAA for mobile IPv6 November 2001 3.2 Terminology 3.2.1 General terms Attendant: AAA entity which is the local AAA system entry point and the local address provider/registry. Term from [8]. AAA client: attendant. AAA home server (AAAH): AAA server of the home network. AAA local server (AAAL): AAA server of the local network. AVP (Attribute Value Pair): AAA (element of) payload. Binding: home address/care-of address association for a mobile node on a mobility aware IPv6 node. Care-of address (Co@): temporary address used by a mobile node. The care-of address is allocated or registered by a local entity which is assumed for simplicity in this document to be the same than the attendant. Home address (H@): fixed address used by a mobile node. 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. Home agent (HA): router on the home network which forwards traffic at the destination of the home address to the mobile node. Mobile Node (MN): node using mobile IPv6 [5] mechanisms. Network Access Identifier (NAI): [2] mobile user identifier which is compatible with user_FQDN identities of IKE. We assume NAI can be used to identify any entity involved here even if some of them are nodes and not users. Security Association (SA): a security connection which affords security services to some traffic between peers. This notion is shared between IPsec, ISAKMP [4] and AAA over different forms. draft-dupont-mipv6-aaa-01.txt [Page 4] INTERNET-DRAFT AAA for mobile IPv6 November 2001 3.2.2 Messages (in alphabetical order) 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. AHA (AA-HA-Answer): third AAA message from the HA to the AAAH. AHR (AA-HA-Request): second AAA message from the AAAH to the HA. AMA (AA-MN-Answer): AAA message from the AAAH to the attendant. This is the final AAA message. AMR (AA-MN-Request): AAA message from the attendant to the AAAH. This is the first AAA message. AReq (Attendant 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(es). This message is loosely authenticated by the local challenge repeated from the AA. ARep (Attendant Reply): 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). AS (Attendant Solicit): 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. 3.2.3 Payloads aaa_key: MN issued keying material (algorithm, secret and lifetime for encryption). BA (binding acknowledge): mobile IPv6 message which gives the result of a binding update reception. BU (binding update): mobile IPv6 message which creates or updates a binding. Home registrations are a special case of BUs and they must be acknowledged. draft-dupont-mipv6-aaa-01.txt [Page 5] INTERNET-DRAFT AAA for mobile IPv6 November 2001 attendant_key: MN issued keying material for the security exchange between the attendant and the MN. (For instance for DHCP delayed authentication [3] it should include algorithm, secret and lifetime) CR (MN Credential): AAA credential which is used by the AAAH to authenticate the MN. The CR is bound to the AMR content, we suggest using something like a RSA signature. SecuParam_I: Security Association establishment elements from initiator/MN. In the ISAKMP/IKE example, this should include HASH_I, SA, Ni, KE, [IDci, IDcr] ISAKMP-like payloads for the HA. SecuParam_R: Security Association establishment elements from responder/HA. In the ISAKMP/IKE example, this should include HASH_R, SA, Nr, KE, [IDci, IDcr] ISAKMP-like payloads for the MN. The HASH_R must include the initiator nonce (Ni) as for IKE [2]. LC (Local Challenge): challenge issued by the attendant. It provides a local liveliness proof of the MN, loose local authentication and a randomness source for AAA authentication. NAI (MN NAI): (called ID in [8]) mobile node identity. This is used by the AAAL in order to find the AAAH. (The attendant may use it as an unique client identifier too). pub_key: public key of the AAAH. RPI (Replay Protection Indicator): time-stamp or nonce used between the MN and the AAAH in order to ensure replay protection. See [8] section 3.3 for more details. H@ (Home Address): MN home address, this will be in AHR/AHA and either in AMR (if the MN knows it) or AMA (if the AAAH allocates it). HA@ (Home Agent Address): HA address, this will be in AHR/AHA and either in AMR (if the MN knows it) or AMA (if the AAAH provides it). The home agent discovery mechanism should not be used from the MN because AAAH allocation is more flexible and faster. RC (Result Code): AAA result code (in AAA answers). draft-dupont-mipv6-aaa-01.txt [Page 6] INTERNET-DRAFT AAA for mobile IPv6 November 2001 3.3 Motivations The MN provides some credentials to the attendant which gives them to the AAAL which forwards them to the AAAH. The AAAH checks them and sends back the result to the AAAL and then the attendant. The basic idea is to use this exchange in order to send information to the HA. In increasing "aggressiveness" order the possibilities are: - send a pre-shared key (poor option for security) or public key (hard to make secure) or certificates (but they can be already stored in the home network or agent). - build an ISAKMP security association (i.e. fake a IKE phase one) as it is proposed with Kerberos in KINK [10]. - build an IPsec SA pair (i.e. fake a IKE phase two) in order to protect the BU/BA exchange. This is realized by the protocol described in this document. - piggy-back the BU/BA exchange in AAA. The last idea (from [8] and [11]) has too many problems: - mobile IPv6 needs a strong anti-replay mechanism (as explained in [5] section 13.1 the BU/BA sequence number provides only ordering). - if an AAA mechanism is used in place of IPsec in all circumstances, in some cases it will be a big waste in efficiency (i.e. this is too drastic): the performance issue of IPsec/IKE is in SA establishment only. - the MN may get its care-of address(es) only at the end of the attendant/AAA exchange, thus it cannot provide it/them at the beginning. - from a security point of view, to have a secret key between *only* the MN and the HA is far better than to ensure security by AAA servers. It can be reused in order to protect the tunnel between the MN and the HA by ESP too. draft-dupont-mipv6-aaa-01.txt [Page 7] INTERNET-DRAFT AAA for mobile IPv6 November 2001 3.4 Security context This document makes many assumptions about security context, i.e. security services that should be available so used. Here is a list of those assumptions with their consequences: - AAA connections are supposed to be protected (i.e. protected (by other tools) payloads are protected against entities that should not need to know what is in). - the attendant is in charge of providing a good local challenge which is the source of randomness for the MN credentials (CR). - the security of the protocol used between the mobile node and the attendant is not addressed by this document but the attendant_key ensures delayed authentication as defined for DHCP [3] for instance. - the MN has the proof of identity of AAAH using its public key for aaa_key encryption. - the attendant_key secret proves a communication from the AAAH to the attendant (i.e. it can replace a reverse challenge). - as a result of KE (i.e. Diffie-Hellman) payload exchange through SecuParam_*, the AAAH server does not know the shared secret between MN and HA. So KEs are not really optional in this first release of the protocol in the IKE/ISAKMP example: the fake phase 2 is with PFS. - there is no proof of MN liveliness as the one ensured by the IKE phase 2 third message. This does not seem to be a problem? This document does not strongly defined the layout of SecuParam_* payloads. As an example, this document describes an ISAKMP-like layout but some others are possible as discussed for KINK [10] and (a better source of ideas which has exactly the same problem in a very similar context) for HIP [12]. draft-dupont-mipv6-aaa-01.txt [Page 8] INTERNET-DRAFT AAA for mobile IPv6 November 2001 3.5 Protocol overview The overall protocol is depicted below: MN attendant AAAL AAAH HA | | | | | | AS | | | | |----------> | | | | | | | | | | AA | | | | |<--------------| | | | | | | | | | AReq | | | | |-------------->| AMR | | | | |-------------------------->| AMR | | | | |----- >| AHR | | | | |---------->| | | | | | | | | | AHA | | | | AMA |<----------| | | AMA |<------| | | ARep |<--------------------------| | | |<--------------| | | | | | | | | | BU | | | | |-------------------------------------------------------------->| | | | | | | | | | BA | |<--------------------------------------------------------------| | | | | | Notation: [XX] = optional element (XX) {XX}xxx = protected element (XX) using the xxx_key keying material Content of messages: AS: Attendant Solicit (likely a multicast IPv6 packet) AA: Attendant Advertisement with LC (challenge issued or transmitted by the attendant) draft-dupont-mipv6-aaa-01.txt [Page 9] INTERNET-DRAFT AAA for mobile IPv6 November 2001 AReq: Attendant Request with: LC (local challenge) NAI (MN identity) (then in an AAA opaque option) RPI AAA replay protection indicator [H@] home address (will be allocated by AAAH if none) [HA@] home agent address (will be allocated by AAAH if none) {aaa_key}pub keying material for protection of AAA messages {attendant_key}aaa {SecuParam_I}aaa Security Association establishment elements for HA CR MN authenticator (signature of the AVP set) AMR: same content than the previous IPv6 packet (translated to AAA) AHR: [H@], SecuParam_I AHA: SecuParam_R AMA: AAA answer with: RC result code (validity of AMR CR) attendant_key local secret between the MN and the attendant RPI new replay protection indicator [H@] home address, if not in AMR [HA@] home agent address, if not in AMR {SecuParam_R}aaa copied from AHA ARep: Attendant Reply protected by the attendant_key shared secret with: [Co@] care-of address, allocated/registered by the attendant (then in an AAA opaque option) RPI copied from AMA [H@] copied from AMA [HA@] copied from AMA {SecuParam_R}aaa copied from AMA 3.6 IPsec and ISAKMP/IKE detailed example This section provides the detailed layout of SecuParam_* with the associated keying material as an example. There is no real phase 1 so the phase 1 like parameters must be agreed before. SA payloads must negotiate AH SAs with replay protection as required by mobile IPv6. The identity payloads provide in fact only the IPv6 protocol to protect (there is an open issue about this for mobile IPv6): port is not relevant and address identities for H@ and HA@ can be assumed. HIP [12] should be considered as a good example of how to specialize IKE mechanisms to this kind of context (i.e. when HIP will be well known it should be used as the basis of this section). draft-dupont-mipv6-aaa-01.txt [Page 10] INTERNET-DRAFT AAA for mobile IPv6 November 2001 In [2] notations, secret materials are (unvalidated proposal): SKEYID = prf(Ni_b | Nr_b, g^xy) HASH_R = prf(SKEYID, Ni_b | SecuParam_R) KEYMAT = prf(SKEYID, g^xy | protocol | SPI | Ni_b | Nr_b) If the H@ and the HA@ are known by the MN it can reserve (i.e. create in the larval state) a SA (i.e. a SPI) for SecuParam_I. This is harder when one or both are not known but this protocol deals with the booting case... 4. Security Considerations This protocol provides as aggressive as possible integration of AAA into secure mobile IPv6 in the "boot in visit case" without too many infringements to security... Obviously a deep security review is needed: we request comments! 5. Acknowledgments The seminal work was done by AAA for IPv6 network access document [8]. The lack of a concrete proposal for mobile IPv6 in this document was the reason to develop this protocol. We would like to thank Olivier Charles (France Telecom R&D) for his continuous encouragements. The following persons listed in the alphabetical order have taken part into this document: Julien Bournelle (INT Evry), Francis Dupont (ENST Bretagne), Maryline Laurent-Maknavicius (INT Evry). 6. Normative References [1] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [2] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [3] R. Droms, W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [4] D. Maughan, M. Schertler, M. Schneider, J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. draft-dupont-mipv6-aaa-01.txt [Page 11] INTERNET-DRAFT AAA for mobile IPv6 November 2001 7. Informative References [5] D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-14.txt, work in progress, July 2001. [6] A. Mankin & all, "Threat Models introduced by Mobile IPv6 and Requirements for Security in Mobile IPv6", draft-ietf-mobileip-mipv6-scrty-reqts-02.txt, work in progress, November 2001. [7] S. Glass, T. Hiller, S. Jacobs, C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000. [8] P. Flykt, C. Perkins, T. Eklund, "AAA for IPv6 Network Access", draft-perkins-aaav6-04.txt, work in progress, July 2001. [9] J. Bound, M. Carney, C. Perkins, R. Droms, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-20.txt, work in progress, October 2001. [10] T. Kivinen, "Kerberized Internet Negotiation of Keys (KINK)", draft-ietf-kink-kink-01.txt , work in progress, July 2001. [11] S. Faccin, F. Le, B. Patil, C. Perkins, "Diameter Mobile IPv6 Application", draft-le-aaa-diameter-mobileipv6-00.txt, work in progress, July 2001. [12] R. Moskowitz, "Host Identity Payload And Protocol", draft-moskowitz-hip-04.txt, work in progress, July 2001. 8. Authors' Addresses Francis Dupont ENST Bretagne Campus de Rennes 2, rue de la Chataigneraie BP 78 35512 Cesson-Sevigne Cedex FRANCE Fax: +33 2 99 12 70 30 EMail: Francis.Dupont@enst-bretagne.fr Maryline Laurent-Maknavicius INT Evry 9, rue Charles Fourier 91011 Evry Cedex FRANCE Fax: +33 1 60 76 47 11 EMail: Maryline.Maknavicius@int-evry.fr draft-dupont-mipv6-aaa-01.txt [Page 12] INTERNET-DRAFT AAA for mobile IPv6 November 2001 Julien Bournelle INT Evry 9, rue Charles Fourier 91011 Evry Cedex FRANCE Fax: +33 1 60 76 47 11 EMail: Julien.Bournelle@int-evry.fr Expire in 6 months (May 21, 2002)