INTERNET DRAFT J. Floroiu Date: 30 November 2001 FhG Fokus Expires: May 2002 Dynamic Security Associations Setup in Mobile IP 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 document proposes extensions to the Mobile IPv4 base protocol [RFC2002] enabling mobile nodes and mobility agents to dynamically setup security associations. Mobile IP is therefore employed as a supporting protocol for SA negotiation. The proposed mechanism is based on RSA cryptography [RSA78], entities acting as key distribution centers and Diffie-Hellman exchanges [DH76]. 1. Terminology Mobile Node (MN) Mobile IP mobile node Home Agent (HA) Mobile IP home agent Foreign Agent (FA) Mobile IP foreign agent Security Association (SA) Set of parameters describing a simplex secure "connection" between two peers RSA Rivest, Shamir and Adleman public key algorithm Floroiu [Page 1] INTERNET DRAFT 30 November 2001 Diffie-Hellman (DH) A protocol enabling two nodes to securely derive a shared secrets without having a pre-existent security relationship Certificate A data structure which associates an entity (identified for instance by its name) with a public key and some other possible extensions, signed by a trusted third party Network Access Identifier (NAI) A character string identifying the mobile nodes and mobility agents Internet Key Exchange Protocol (IKE) A protocol which negotiates and provides authenticated keying material for security associations in a protected manner 2. Introduction There are several potential methodologies of authenticating Mobile IP control messages, such as manually distributed shared secrets, IKE negotiated SAs, AAA key distribution, CA signed certificates [Jacobs01]. Manually distributed shared secrets have two main disadvantages. First, it does not scale well as the number of shared secrets experience a quadratic grow. Secondly, keys need to be pre-configured on all involved entities as there is also no support for dynamic keys configuration. AAA key distribution is based on the idea of having pre-distributed shared secrets between the interacting entities. This approach actually shifts the problem rather than addressing it. IKE provides flexibility and a very good level of security. Peers authenticate each other through shared secrets, public keys or certificates. In the first phase IKE sets up the ISAKMP SA which is used to secure the negotiation of further SAs. In aggressive mode this process requires three trips. The SA negotiation which takes place during phase two requires three more trips. A mobile node to negotiate SAs with FA and HA requires therefore three round trips to FA and three round trips to HA. This extensive control message exchange however negatively impacts on hand-over performance. Besides, a MN visiting a private addressing realm will not be able to communicate at the IP level with the HA unless a Mobile IP tunnel is created, which cannot be done prior to MN authentication. The proposed protocol does not seek to achieve a level of flexibility comparable to IKE, but to use Mobile IP as a SA negotiation supporting protocol which would satisfy the security needs of a mobile node. Floroiu [Page 2] INTERNET DRAFT 30 November 2001 The proposed solution is based on the use of RSA cryptography for initial authentication of peers and as a mean to secure further SA negotiation. The advantage of such an approach is that no additional control message exchange is necessary in order to set up a "main SA" to protect further exchanges, as IKE does (ISAKMP SA). 3. Assumptions and requirements In principle the design is based on the idea of using reverse tunneling [RFC2344], with the tunnel being segmented at the FA level. Also colocated care-of addresses are envisioned to be used. Such an architecture supports bridging private IP addressing realms (a situation which occurs when both home and foreign domain employ private addressing schemes). The following requirements have been considered as having particular importance for the design: 1) The SA setup must be accomplished in one round trip so that the hand-over performances wouldn't be affected too much (higher delays are however expected due to the cryptographic operations involved). 2) In real world environments, besides authenticating the Mobile IP control messages, a MN typically needs to set up an AH tunnel with the FA (or another administrative entity in the visited domain) and a MN an ESP encrypted tunnel with the HA. This would protect MN in visited domains against attacks based on IP and MAC address spoofing and the MN inter-domain traffic against passive eavesdropping. Therefore, the SAs set up between the mobility entities should address these needs as well. 3) MN and FA must not be forced or assumed to have any previous knowledge of each other. MN and FA should therefore rely on HA for the initial MN-FA SA setup. 4) The solution should be extensible to hierarchical Mobile IP architectures. Although the document do not explicitly deal with hierarchical architectures, support is provided for enabling MN to perform "local" SA setup with the FA. In an hierarchical architecture the HA and FA referred throughout the document would be the gateway FA and the gateway HA. The SA setup schemes within a hierarchy of FAs or HAs is beyond the scope of the current version of this document. 4. Key Distribution and Security Associations Setup For the authentication SAs MN negotiates all parameters except for the keys, which are provided (initially) by HA and (later on also) by FA. For the encryption SAs the keys are typically 3DES keys derived from the shared secrets obtained as result of DH exchanges. MN and FA need to set up an encryption SA in order to ensure security of further "local" MN-FA authentication SA negotiations which would take place without the assistance of HA. As soon as the MN-FA encryption SA expires, MN should register again via the HA. Floroiu [Page 3] INTERNET DRAFT 30 November 2001 HA and FA act as Key Distribution Centers for the authentication SAs. Only the MN-HA and MN-FA encryption SAs keys are adopted as result to DH key exchange. This breaks the symmetry of the MN-HA, FA-HA and MN-HA security relationships in the sense that MN and FA have to trust the HA and MN has to trust FA as soon as HA has authenticated the FA. This is assumed however to be acceptable since: 1) MN is part of the same administrative domain as the HA, with the HA being the entity which authenticates the MNs, therefore having some kind of authority over the MN; 2) MN is visiting a foreign domain to which it should present its credentials, with FA "representing" the local authority; 3) FA must rely on HA for authenticating the MN. Besides, the control message exchange gets dramatically lower. 4.1. Security associations The following security associations will be negotiated by the protocol. Different authentication SAs have been defined for Mobile IP and AH authentication. A MN-FA encryption SA was also defined. It aims at protecting the negotiation of the MN-FA AH SAs without assistance of HA. +-------------+--------------------+-------------------------+ | Name | Description | How is the key obtained | +-------------+--------------------+-------------------------+ | MH_MIP_AUTH | MN-HA MIP auth. SA | Key generated by HA | | MF_MIP_AUTH | MF-HA MIP auth. SA | Key generated by HA | | HF_MIP_AUTH | HF-HA MIP auth. SA | Key generated by HA | | | | | | MH_ESP_ENCR | MN-HA ESP encr. SA | DH Key exchange | | MH_AH_AUTH | MN-HA AH auth. SA | Key generated by HA | | | | | | MF_AH_AUTH | MN-FA AH auth. SA | Key generated by HA, FA | | MF_MIP_ENCR | MN-FA MIP encr. SA | DH Key exchange | +-------------+--------------------+-------------------------+ 5. Other considerations Each time a RSA extension is present, a NAI identifying the sender must also be present. NAI is used to retrieve the corresponding certificate. Floroiu [Page 4] INTERNET DRAFT 30 November 2001 RSA cryptographic operations should be used only if no SA matching the intended operation is present. There are several reasons for that: 1) to preserve the entropy of the RSA keys; 2) to save some time by performing shared secret based operations rather than RSA operations; 3) to save some space since the RSA cipher comes in chunks as large as the RSA key length. 6. Formats of the extensions All message extensions are in the form of vendor extensions [RFC3115]. Every extension has at most one variable long field so that the length of such a field can be easily deduced from the vendor extension length field. 6.1. SA Proposal Extension This extension carries a SA proposal containing the parameters to be negotiated between the peers. More proposals can be included by the initiator (MN). Currently SPI, the SA lifetime and the protocol are defined. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA lifetime | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type of the Key Extension is TBD. The Vendor-CVSE-Types (subtypes) are as follows: 3010 MH_MIP_AUTH proposal (PR_MH_MIP_AUTH/PR_HM_MIP_AUTH) 3011 MF_MIP_AUTH proposal (PR_MF_MIP_AUTH/PR_FM_MIP_AUTH) 3012 HF_MIP_AUTH proposal (PR_HF_MIP_AUTH/PR_FH_MIP_AUTH) 3020 MH_AH_AUTH proposal (PR_MH_AH_AUTH/PR_HM_AH_AUTH) 3021 MF_AH_AUTH proposal (PR_MF_AH_AUTH/PR_FM_AH_AUTH) 3030 MH_ESP_ENCR proposal (PR_MH_ESP_ENCR/PR_HM_ESP_ENCR) 3031 MF_MIP_ENCR proposal (PR_MF_MIP_ENCR/PR_FM_MIP_ENCR) The same CVSE code is used in both directions of the SA negotiation between two given entities. The content however reflect the proposal of the sending peer. In the PR_MH_MIP_AUTH in the request for instance MN proposes the SPI to be used by HA when authenticating Mobile IP registration reply messages along with the SA lifetime and protocol to be used. In the PR_HM_MIP_AUTH in the reply on the other hand HA proposes the SPI to be used by MN when authenticating Mobile IP registration requests along with the granted SA lifetime and protocol to be used. Floroiu [Page 5] INTERNET DRAFT 30 November 2001 Protocol is one of the following: 1 MD5/prefix+suffix authentication 2 HMAC MD5 authentication 3 HMAC SHA-1 authentication 65 3DES encryption 129 Diffie-Hellman key exchange 6.2. Key Extension The Key Extension contains the key associated with a certain SA. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key type | Key ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type of the Key Extension is TBD. The Vendor-CVSE-Types (subtypes) identify the particular SA type this key is related to. The following types have been defined: 3110 Shared secret for MH_MIP_AUTH (SS_MH_MIP_AUTH) 3111 Shared secret for MF_MIP_AUTH (SS_MF_MIP_AUTH) 3112 Shared secret for HF_MIP_AUTH (SS_HF_MIP_AUTH) 3120 Shared secret for MH_AH_AUTH (SS_MH_IPS_AUTH) 3121 Shared secret for MF_AH_AUTH (SS_MF_IPS_AUTH) 3130 DH public info. for MH_ESP_ENCR (DH_MH_ENCR_pub) 3131 DH public info. for MF_MIP_ENCR (DH_MF_ENCR_pub) SS_MH_ESP_ENCR is derived by combining DH_MH_ENCR_pub, DH_MH_ENCR_priv (produced by MN) and DH_HM_ENCR_pub, DH_HM_ENCR_priv (produced by HA). SS_MF_MIP_ENCR is derived by combining DH_MF_ENCR_pub, DH_MF_ENCR_priv (produced by MN) and DH_FM_ENCR_pub, DH_FM_ENCR_priv (produced by FA). Note that for DH keys DH_AB_XXX and DH_BA_XXX are different from each other, while for shared secrets SS_AB_XXX is the same as SS_BA_XXX. Key Type is one of the following: Authentication keys (for the MIP and AH authentication SAs): 1 MD5/prefix+suffix authentication (typical length 16 bytes) 2 HMAC MD5 (typical length 16 bytes) 3 HMAC SHA-1 (typical length 20 bytes) Diffie-Hellman public key (for constructing the shared keys to be used by MIP and ESP encryption SAs) 129 Diffie-Hellman Floroiu [Page 6] INTERNET DRAFT 30 November 2001 Key field is a variable length field specifying the key. The length of this filed is deduced from the total length of the extension contained in the Vendor Extension header. 6.3. Authentication Extension This extension carries an RSA authenticator. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authenticator field is a variable length field containing an encrypted digest computed over the payload. 6.4. Encrypted Payload Extension The Encrypted Payload Extension transports a sequence of SA Proposal and Key extensions in encrypted form. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameter Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encrypted Payload ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The SPI is used for identifying the appropriate SA. 7. The control message exchange The following diagram depicts a typical control message exchange. The MN aims at setting up an AH tunnel to FA and an ESP/AH tunnel to HA. The following notation have been used in order to indicate authentication and encryption: { Message } RSA_priv_Entity A digest of Message was encrypted with the RSA private key of the indicated Entity and appended to Message; { Message } SS_XXX When used in conjunction with Mobile IP registration messages denotes an Mobile IP prefix-suffix authenticator which is appended to Message; < Message > Key Message is encrypted using Key (which might be a RSA key or a 3DES key) and transferred as chiper. Floroiu [Page 7] INTERNET DRAFT 30 November 2001 M N F A H A | | | { RegReq -----------> NAI FA-NAI PR_MH_ESP_ENCR PR_MH_AH_AUTH PR_MH_MIP_AUTH PR_MF_AH_AUTH PR_MF_MIP_AUTH DH_MH_ENCR_pub } RSA_priv_MN F A H A | | { { RegReq -----------> NAI FA-NAI PR_MH_ESP_ENCR PR_MH_AH_AUTH PR_MH_MIP_AUTH PR_MF_AH_AUTH [1] PR_MF_MIP_AUTH [2] DH_MH_ENCR_pub } RSA_priv_MN PR_FH_MIP_AUTH PR_FM_MIP_AUTH [3] PR_FM_AH_AUTH [4] } RSA_priv_FA F A H A | | { { RegRpl <----------- NAI FA-NAI PR_HM_ESP_ENCR PR_HM_AH_AUTH PR_HM_MIP_AUTH PR_FM_MIP_AUTH [3] PR_FM_AH_AUTH [4] < SS_HM_AH_AUTH SS_HM_MIP_AUTH SS_MF_MIP_AUTH SS_MF_AH_AUTH > RSA_pub_MN DH_HM_ENCR_pub } RSA_priv_HA PR_HF_MIP_AUTH PR_MF_AH_AUTH [1] PR_MF_MIP_AUTH [2] < SS_HF_MIP_AUTH SS_MF_AH_AUTH SS_MF_MIP_AUTH > RSA_pub_FA } RSA_priv_HA Floroiu [Page 8] INTERNET DRAFT 30 November 2001 M N F A | | { RegRpl <----------- NAI FA-NAI PR_HM_ESP_ENCR PR_HM_AH_AUTH PR_HM_MIP_AUTH PR_FM_MIP_AUTH [3] PR_FM_AH_AUTH [4] < SS_HM_AH_AUTH SS_HM_MIP_AUTH SS_MF_MIP_AUTH SS_MF_AH_AUTH > RSA_pub_MN DH_HM_ENCR_pub } RSA_priv_HA A secondary objective would be fitting one control messages into one datagram, since fragmented control messages may introduce severe delays if fragments got lost. From the perspective of the message size, the main issue is related to the RSA plain text and cipher length: the cipher is as long as the RSA key and can accommodate a plain text almost as long as the RSA key. Therefore, in order to optimize the space usage, the plain text and the RSA key must be nearly the same size. Following this idea, and considering the size of the extensions transfered during a "normal" exchange, the SA proposal extensions in the reply messages could be encrypted along with the keys. It should be noted that even if there are multiple proposals for a given SA, the reply contains only the accepted proposal. If the same is done for the SA proposal extensions in the request packets, the SPI values won't appear in plaintext in the network which improves the security of the security material being negotiated. The exchange depicted below is based on this idea. M N F A H A | | | { RegReq -----------> NAI FA-NAI < PR_MH_ESP_ENCR PR_MH_AH_AUTH PR_MH_MIP_AUTH PR_MF_AH_AUTH PR_MF_MIP_AUTH > RSA_pub_HA DH_MH_ENCR_pub } RSA_priv_MN Floroiu [Page 9] INTERNET DRAFT 30 November 2001 F A H A | | { { RegReq -----------> NAI FA-NAI < PR_MH_ESP_ENCR PR_MH_AH_AUTH PR_MH_MIP_AUTH PR_MF_AH_AUTH [1] PR_MF_MIP_AUTH [2] > RSA_pub_HA DH_MH_ENCR_pub } RSA_priv_MN < PR_FH_MIP_AUTH PR_FM_MIP_AUTH [3] PR_FM_AH_AUTH [4] > RSA_pub_HA } RSA_priv_FA F A H A | | { { RegRpl <----------- NAI FA-NAI < PR_HM_ESP_ENCR PR_HM_AH_AUTH PR_HM_MIP_AUTH PR_FM_MIP_AUTH [3] PR_FM_AH_AUTH [4] SS_HM_AH_AUTH SS_HM_MIP_AUTH SS_MF_MIP_AUTH SS_MF_AH_AUTH > RSA_pub_MN DH_HM_ENCR_pub } RSA_priv_HA < PR_HF_MIP_AUTH PR_MF_AH_AUTH [1] PR_MF_MIP_AUTH [2] SS_HF_MIP_AUTH SS_MF_AH_AUTH SS_MF_MIP_AUTH > RSA_pub_FA } RSA_priv_HA Floroiu [Page 10] INTERNET DRAFT 30 November 2001 M N F A | | { RegRpl <----------- NAI FA-NAI < PR_HM_ESP_ENCR PR_HM_AH_AUTH PR_HM_MIP_AUTH PR_FM_MIP_AUTH [3] PR_FM_AH_AUTH [4] SS_HM_AH_AUTH SS_HM_MIP_AUTH SS_MF_MIP_AUTH SS_MF_AH_AUTH > RSA_pub_MN DH_HM_ENCR_pub } RSA_priv_HA 8. Addressing Mobile IP hierarchical architectures One of the requirements identified at the beginning of the draft states that support for Mobile IP hierarchical architectures should be provided. Although the current version of the document is far from exhausting this topic, the proposed protocol addresses the issue. Taking benefit from the SS_MF_MIP_AUTH distributed by HA during the initial (inter-domain) registration to both FA and MN, the latter two engage in further negotiations. Thus, FA and MN exchange Diffie-Hellman keys by mean of which the distribution of SS_FM_MIP_AUTH by FA to MN is secured. M N F A | | { RegReq -----------> NAI FA-NAI PR_MF_AH_AUTH PR_MF_MIP_ENCR DH_MF_ENCR_pub } SS_MF_MIP_AUTH(old - distributed by HA) { RegRpl <----------- NAI FA-NAI PR_FM_AH_AUTH PR_FM_MIP_AUTH < SS_FM_AH_AUTH SS_FM_MIP_AUTH(new - generated by FA) SS_FM_AH_AUTH(new - generated by FA) > SS_FM_MIP_ENCR DH_FM_ENCR_pub } SS_MF_MIP_AUTH(old - distributed by HA) Floroiu [Page 11] INTERNET DRAFT 30 November 2001 MN provides a DH public key (DH_MF_ENCR_pub), so that FA can derive SS_MF_MIP_ENCR based on this key and DH_FM_ENCR_priv - the private counterpart of DH_FM_ENCR_pub the FA will send in the reply. FA generates SS_FM_MIP_AUTH and SS_FM_AH_AUTH and encrypts them with SS_MF_MIP_ENCR. Upon receipt of the reply message, MN will be able based on DH_FM_ENCR_pub and DH_MF_ENCR_priv to derive the same SS_MF_MIP_ENCR which he will use then to retrieve SS_FM_MIP_AUTH and SS_FM_AH_AUTH. 9. Interaction with other key exchange protocols A mobile node may set up ESP/AH tunnels with correspondent nodes. Assuming the mobile node establishes an ESP tunnel back to its home agent as well, the traffic between the mobile node and such correspondent nodes needs therefore not be sent through the MN-HA ESP tunnel, since double encryption requires double processing resources and double the amount of control information per datagram. This must and can be adjusted using routing mechanisms such as policy routing and packet filtering. As soon as the mobile node acquires IP level connectivity to its home network it can use key exchange protocols such as IKE to negotiate SAs with correspondent nodes. The IKE exchange and the locally generated ESP traffic will be sent through the Mobile IP IPnIP tunnel rather than through MN-HA ESP tunnel. Without going into implementation details it is worth mentioning that today operating systems provide the necessary support to implement such routing schemes - a sample suite is mentiond in [Impl]. 10. Certificates considerations A PKI local to the home domain may be used in order to distribute certificates to mobile nodes. HA itself may act as a CA signing these certificates.. The HA - FA secure communication relies however on certificates issued by a "global" authority. A discussion on CRL check is beyond the scope of the current version of the present draft. The certificates themselves may be transported along with Mobile IP registration messages, since they are not vulnerable to man-in-the-middle attacks. However, in order not to end up by having fragmented control messages - which are at least that bad as large number of control messages - piggybacking certificates should be used only when no timely alternate way to retrieve the peer's certificate is available. Floroiu [Page 12] INTERNET DRAFT 30 November 2001 11. Security Considerations The protocol does not introduce additional security threats beyond those known so far for the case of Mobile IP. The protocol provides support for the MN to negotiate authentication SA with FA. This breaks attacks based on IP and MAC addresses spoofing in the visited domains. The protocol provides support for the MN to negotiate encryption SA with HA. This enables a MN to encrypt all its data traffic up to the home domain. The shared keys used for authentication are distributed in encrypted form by HA and FA following a clear trust model (see chapter 4). Moreover the SA proposals themselves may be encrypted as well. The encryption keys are established following a Diffie-Hellman exchange. PFS is therefore achieved for the MN-FA SA negotiations and for the MN-HA data traffic. 12. Conclusion The draft explores the opportunities of making Mobile IP a supporting protocol for SA negotiation which would satisfy the security needs of mobile nodes. Floroiu [Page 13] INTERNET DRAFT 30 November 2001 References [Jacobs01] Jacobs, S., Belgard, S., "Mobile IP Public Key Based Authentication", draft-jacobs-mobileip-pki-auth-03.txt, July 2001, work in progress [RFC2002] Perkins, C., editor, "IP mobility support", October 1996. [RFC2344] Montenegro, G., editor, "Reverse Tunneling for Mobile IP", May 1998. [RFC3115] Dommety, G., Leung, K., "Mobile IP Vendor/Organization-Specific Extensions", April 2001. [DH76] Diffie, W., Hellman, M. E., "New directions in cryptography", IEEE Transactions on Information Theory, IT-22(6):644-654, November 1976 [RSA78] Rivest, R.L., Shamir, A., Adleman, L., "A method for obtaining digital signatures and public-key cryptosystems", Communications of the ACM, 21(2):120-126, February 1978 [Impl] Linux Mobile IP/IPsec/routing suite: The Netfilter Project - http://netfilter.smaba.org iproute2 utility - ftp://ftp.inr.ac.ru/ip-routing FreeS/WAN - an implementation of IPSEC & IKE for Linux - http://www.freeswan.org Dynamics - an implementation of Mobile IP for Linux - http://www.cs.hut.fi/Research/Dynamics 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 14]