Internet Engineering Task Force Francis Dupont INTERNET DRAFT ENST Bretagne Expires in August 2001 Maryline Laurent-Maknavicius INT Evry February 22, 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 [1] has many security requirements which are fulfilled by IPsec [2]. Unfortunately this solution 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 [3]. This document extends AAA for IPv6 network access proposal [4], mainly with DHCPv6 [5] because we believe it will be the auto-configuration method of choice. draft-dupont-mipv6-aaa-00.txt [Page 1] INTERNET-DRAFT AAA for mobile IPv6 February 2001 1. Introduction Experiments with secure mobile IPv6 show that in some circumstances performance of IKE [6] 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... The AAA for IPv6 network access document [4] already provides good integration of AAA into IPv6 auto-configuration methods but does not really describe how to apply it to the mobile node case. The purpose of this document is to fill this gap. This document assumes reasonable knowledge of mobile IPv6 [1], DHCPv6 [5], AAA [3] and IPsec [2]. 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 AAAL server with the identity (NAI) of the previous AAAL server and share an AAA security association with it (in order to protect the transfer against a rogue MN). draft-dupont-mipv6-aaa-00.txt [Page 2] INTERNET-DRAFT AAA for mobile IPv6 February 2001 3. Boot in visit case 3.1 Terminology 3.1.1 General terms Attendant: AAA entity which is the local AAA system entry point and the local address provider. Term from [4]. 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 payloads. 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 by a local entity which is assumed in this document to be the DHCP server. Dynamic Host Configuration Protocol (DHCP): IPv6 stateful auto-configuration protocol [5]. This document will use DHCP for DHCPv6 everywhere. DHCP agent: DHCP relay or server. DHCP relay: DHCP agent on the local link which forwards DHCP messages between the local link and off-link DHCP servers. DHCP relays are transparent. DHCP server: DHCP agent which provides address allocation and/or registration in its network. The DHCP server is the AAA attendant (ie. the entry point to the AAA service). Home address (H@): fixed address used by a mobile node. The home address belongs to the home network and is in general known by the mobile node even if the protocol described here supports home address allocation. draft-dupont-mipv6-aaa-00.txt [Page 3] INTERNET-DRAFT AAA for mobile IPv6 February 2001 Home agent (HA): router on the home network which forwards traffic for the home address to the mobile node. Mobile Node (MN): node using mobile IPv6 [1] mechanisms. Network Access Identifier (NAI): [6] 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, IKE and AAA over different forms. 3.1.2 Messages AMA (AA-MN-Answer): AAA message from the AAAH to the DHCP server. This is the final AAA message. AMR (AA-MN-Request): AAA message from the DHCP server to the AAAH. This is the first AAA message. DA (DHCP Advertise): second DHCP message sent by DHCP servers to the DHCP client. It carries local challenge issued by the DHCP server. DReq (DHCP Request): third DHCP message sent by the DHCP client to the DHCP server 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 DA. DRep (DHCP Reply): forth/last DHCP message sent by the DHCP server. We assume that in general the mobile node must wait for this message before sending a home registration (because this message contains the care-of address). DS (DHCP Solicit): first DHCP message sent by the DHCP client to DHCP agents in order to discover them. draft-dupont-mipv6-aaa-00.txt [Page 4] INTERNET-DRAFT AAA for mobile IPv6 February 2001 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. 3.1.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. 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. dhcp_key: MN issued keying material (algorithm, secret and lifetime for DHCP delayed authentication [7]) IPSEC_I: IPsec elements from initiator/MN. This should include HASH_I, SA, Ni, [KE], [IDci, IDcr] IKE-like payloads for the HA. IPSEC_R: IPsec elements from responder/HA. This should include HASH_R, SA, Nr, [KE], [IDci, IDcr] IKE-like payloads for the MN. The HASH_R must include the initiator nonce (Ni) as for IKE [6]. LC (Local Challenge): challenge issued by the DHCP server. 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 [4]) mobile node identity. This is used by the AAAL in order to find the AAAH and shall be available to the DHCP server as an unique DHCP client identifier. pub_key: public key of the AAAH. draft-dupont-mipv6-aaa-00.txt [Page 5] INTERNET-DRAFT AAA for mobile IPv6 February 2001 RPI (Replay Protection Indicator): time-stamp or nonce used between the MN and the AAAH in order to ensure replay protection. See [4] 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). 3.2 Motivations The MN provides some credentials to the DHCP server 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 DHCP server. 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 (ie. fake a IKE phase one) as it is proposed with Kerberos in KINK [8]. - build an IPsec SA pair (ie. 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 [4]) has too many problems: - mobile IPv6 needs a strong anti-replay mechanism (as explained in [1] section 13.1 the BU/BA sequence number provides only ordering). draft-dupont-mipv6-aaa-00.txt [Page 6] INTERNET-DRAFT AAA for mobile IPv6 February 2001 - if an AAA mechanism is used in place of IPsec in all circumstances, in some cases it will be a big waste in efficiency (ie. this is too drastic): the performance issue of IPsec/IKE is in SA establishment only. - usually the MN gets its care-of address(es) only at the end of the DHCP/AAA exchange, thus it cannot provide it/them at the beginning. 3.3 Security context This document makes many assumptions about security context, ie. 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 (ie. protected (by other tools) payloads are protected against entities that should not need to know what is in). - the DHCP server is in charge of providing a good local challenge which is the source of randomness for the MN credentials (CR). - DHCP security itself is not addressed by this document but the dhcp_key ensures delayed authentication [7]. - the MN has the proof of identity of AAAH using its public key for aaa_key encryption. - the dhcp_key secret proves a communication from the AAAH to the the DHCP server (ie. it can replace a reverse challenge). - as a result of KE (ie. Diffie-Hellman) payload exchange through IPSEC_*, 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: 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? draft-dupont-mipv6-aaa-00.txt [Page 7] INTERNET-DRAFT AAA for mobile IPv6 February 2001 3.4 Protocol overview The overall protocol is depicted below: DHCP DHCP MN relay server AAAL AAAH HA | | | | | | | | | | | | | DS | | | | | |--------|------->| | | | | DA | | | | |<-------|--------| | | | | | | | | | | | | | | | | DReq | | | | |--------|------->| | | | | | | AMR | | | | | |-------------------------->| A M R | | | | | |- - - >| AHR | | | | | |---------->| | | | | | | | | | | | AHA | | | | | A M A |<----------| | | | AMA |< - - -| | | | |<--------------------------| | | | DRep | | | | |<----------------| | | | | | | | | | | | | | | | | | | | | | | BU | | | | | |---------------------------------------------------------------->| | | | | | BA | |<----------------------------------------------------------------| | | | | | | | | | | | | Notation: [XX] = optional element (XX) {XX}xxx = protected element (XX) using the xxx_key keying material draft-dupont-mipv6-aaa-00.txt [Page 8] INTERNET-DRAFT AAA for mobile IPv6 February 2001 Content of messages: DS: standard DHCP Solicit DA: DHCP Advertise with LC (challenge issued by the DHCP server) DReq: DHCP 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 {dhcp_key}aaa {IPSEC_I}aaa IPsec elements for HA (IKE HASH_I, SA, Ni, [KE], [IDci, IDcr]) CR MN authenticator (signature of the AVP set) AMR: same content than DReq (translated from DHCP to AAA) AHR: [H@], IPSEC_I AHA: IPSEC_R (IKE HASH_R, SA, Nr, [KE], [IDci, IDcr]) AMA: AAA answer with: RC result code (validity of AMR CR) dhcp_key local DHCP secret RPI new replay protection indicator [H@] home address, if not in AMR [HA@] home agent address, if not in AMR {IPSEC_R}aaa DRep: DHCP Reply protected by the dhcp_key shared secret with: Co@ care-of address, allocated/registered by the DHCP server (then in an AAA opaque option) RPI copied from AMA [H@] copied from AMA [HA@] copied from AMA {IPSEC_R}aaa copied from AMA draft-dupont-mipv6-aaa-00.txt [Page 9] INTERNET-DRAFT AAA for mobile IPv6 February 2001 3.5 IPsec and IKE details 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. In [6] notations, secret materials are (unvalidated proposal): SKEYID = prf(Ni_b | Nr_b, g^xy) HASH_I = prf(SKEYID, IPSEC_I) HASH_R = prf(SKEYID, Ni_b | IPSEC_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 (ie. create in the larval state) a SA (ie. a SPI) for IPSEC_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. Acknowledgements The seminal work was done by AAA for IPv6 network access document [4]. 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), Jerome Marchand (IUP Vannes), Nicolas Prigent (IFSIC/Universite Rennes 1). draft-dupont-mipv6-aaa-00.txt [Page 10] INTERNET-DRAFT AAA for mobile IPv6 February 2001 6. References [1] D. Johnson, C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-13.tx, work in progress, November 2000. [2] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [3] S. Glass, T. Hiller, S. Jacobs, C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", RFC 2977, October 2000. [4] N. Asokan, P. Flykt, C. Perkins, T. Eklund, "AAA for IPv6 Network Access", draft-perkins-aaav6-02.txt, work in progress, January 2000. [5] J. Bound, M. Carney, C. Perkins, R. Droms, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-16.txt, work in progress, November 2000. [6] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [7] R. Droms, W. Arbaugh, "Authentication for DHCP Messages", draft-ietf-dhc-authentication-16.txt, work in progress, January 2001. [8] T. Kivinen, "Running IKE Phase 2 over Artificial Kerberos IKE SA", draft-ietf-kink-ike-over-kkmp-00.txt, work in progress, November 2000. draft-dupont-mipv6-aaa-00.txt [Page 11] INTERNET-DRAFT AAA for mobile IPv6 February 2001 7. Author's Address 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 Expire in 6 months (August 22, 2001)