INTERNET DRAFT Pete McCann Category: Tom Hiller Title: draft-mccann-transform-00.txt Date: June 1999 Lucent Technologies IP Transform Policy Distribution using Mobile IP/DIAMETER draft-mccann-transform-00.txt Status of this Memo This document is an Internet Draft and is in full compliance 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. Internet Drafts 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 The deployment of Mobile IP in a wide area network presents several challenges, not the least of which is how to provide subscribers with secure access to remote private networks. This draft outlines mechanisms whereby the home and visited network may negotiate the use of IP transforms, such as IP Security ESP and AH protocols, on the Mobile IP redirection tunnels. These mechanisms allow for the secure distribution of both keys and policies through a DIAMETER AAA infrastructure, obviating the need for other forms of key distribution or policy negotiation. The mechanisms are extensible to other kinds of IP transforms, such as IP Compression. 1. Introduction With the coming third generation of cellular infrastructure, variously termed IMT-2000 or UMTS, Mobile IP could have a critical role to play in the data network offerings of wireless carriers. McCann and Hiller Expires 12/99 1 INTERNET DRAFT IP Transform Policy Distribution June 1999 However, several obstacles to this goal remain, including the support of secure access to remote private networks. One way to accomplish this goal is with so-called "voluntary tunneling," where the foreign network plays no role in providing the remote access, but instead gives only direct access to the public Internet and relies on the mobile nodes to implement their own security protocols end-to-end with the private network. This solution is attractive because it requires no extra effort on the part of foreign networks and supports any access method supported by the home network. This leaves open the problem of provisioning and maintaining security associations between the mobile nodes and the home networks. Protocols such as IKE [Harkins98] are one possibility, but several problems with these approaches exist. First, they require some independent means of securely establishing the identity of the participants, such as a public key infrastructure or pre- arranged security keys. They also introduce several additional messages at registration time, increasing latency. Voluntary tunneling also involves overhead on the last-hop (potentially low-bandwidth) link, and, for the case of some small wireless devices used in public cellular networks, may require more processing power than is feasible. Additionally, not all hosts may implement IP Security in the near future, and so such a solution poses timing issues for wireless carriers desiring to offer private network access. These considerations lead to an architecture where traffic is secured using link-layer mechanisms from mobile node to foreign agent, and via IP Security mechanisms from foreign agent to home agent. Provisioning and maintaining the security associations between home and foreign agent require new information to be exchanged during the Mobile IP registration process. This draft outlines an approach that supports dynamic distribution of security policies (or, more generally, IP-layer transforms) and keys, allowing security associations to be dynamically established with the Mobile IP registration process. This solution applies in the context of a likely DIAMETER-based AAA framework that supports global roaming and dynamic configuration of home agents and home addresses for Mobile IP [Calhoun98d, Hiller99]. The network of AAA brokers necessary for authentication of roaming users offers a web of trust that can be used to distribute entire security associations, obviating the need for a parallel public key infrastructure or other key distribution mechanism. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [Bradner97]. 1.1 Terminology McCann and Hiller Expires 12/99 2 INTERNET DRAFT IP Transform Policy Distribution June 1999 Mobile Node (MN) As in Mobile IP [Perkins96]. Home Agent (HA) As in Mobile IP [Perkins96]. A home agent is link-layer reachable from the home network. Foreign Agent (FA) As in Mobile IP [Perkins96]. A foreign agent is link-layer reachable from a MN, when the MN is present on its foreign network. Correspondent Node (CN) As in Mobile IP [Perkins96]. Authentication, Authorization, and Accounting (AAA) Server A server implementing a protocol such as DIAMETER [Calhoun98c] and which can distribute information which is cryptographically protected on either a hop-by-hop or end-to-end basis. Security Parameters Index (SPI) A 32-bit number that forms part of the index to find an SA. Security Association (SA) Information such as shared keys and algorithm specifications that indicate what protection is to be applied to traffic between two hosts on the Internet. SAs are kept in a database that can be indexed by SPI and other information. 2. Assumptions In this section we review assumptions about private networks, the placement of mobility agents, and the authentication services provided by the AAA infrastructure as it will typically apply to wireless cellular uses of Mobile IP and AAA [Hiller99]. Justification for each assumption is given. 2.1 Placement of Mobility Agents In what follows, we assume that mobility agents are placed at the boundaries of administrative domains - that is, the FA is at the boundary of some firewall protecting the wireless carrier network, and the HA is at the boundary of the home, private network. Each is associated with a AAA server for use during the registration process. Each mobility agent straddles the administrative boundary, meaning it has at least one IP address on the "outside" of the boundary and is link-layer reachable from the "inside" of the boundary. Each agent may have a separate internal IP address for the internal interface, but link-layer reachability to the MN (if McCann and Hiller Expires 12/99 3 INTERNET DRAFT IP Transform Policy Distribution June 1999 the agent is an FA) or home network (if the agent is an HA) will suffice for correct operation. 2.2 AAA Infrastructure We assume the existence of an overall AAA infrastructure which can be used to distribute cryptographic keys. Each valid MN possesses an NAI which can be used to find a home AAA server, possibly via some broker servers that implement a large-scale roaming agreement. As described in the Mobile IP DIAMETER Extensions [Calhoun98d], the home AAA server is affiliated with the HA, such that the HA trusts the AAA server to provide it with authentic instructions for tunnel setup from the MN. The MN also has a shared secret with the home AAA server which is used during the registration process to authenticate the registration request and to encode secret information, such as session keys, for the MN. The home AAA server can similarly encode information for the FA on a hop-by-hop basis, using the shared secret it has with its first-hop broker. Additional mechanisms [Calhoun98e] may be in place to provide end- to-end security from the home AAA to the foreign AAA using public key cryptography. Calhoun & Perkins [Calhoun98d] assume that the cryptographic shared secrets so distributed will be used only for authenticating further registration messages. However, DIAMETER messages can also play a role in IP Security protection of user data by transporting keys, SPIs, and a set of security attributes for use in creating a security association. This draft presents specific extensions in which this information may be carried. 3. Distribution of Transform Associations RFC2401 states "The default automated key management protocol selected for use with IPsec is IKE [MSST97, Orm97, HC98] under the IPsec domain of interpretation [Pip98]. Other automated SA management protocols MAY be employed" [Kent98a]. This draft proposes that AAA act as an "other automated protocol for key management". This approach is ultimately possible due to the AAA infrastructure that will already in place, along with existing business relationships that inherently establish trust between various network domains. 3.1 Keys and SPIs Keys and SPIs are created by the home AAA server, and are distributed via DIAMETER messages to the FA, protected on a hop-by- hop basis. Keys and SPIs may be distributed to the MN in the Mobile IP Registration Reply, protected by the secret shared between the MN and home AAA. McCann and Hiller Expires 12/99 4 INTERNET DRAFT IP Transform Policy Distribution June 1999 3.2 Security Profile In addition to Keys and SPIs, the parties must agree on what transformations will be applied to IP packets and in what order they should be applied. In what follows we extend the Mobile IP Registration Request, Reply, and corresponding DIAMETER messages with transform policy specifications. This allows the MN and FA to request policies, and for the home AAA server to select policies and return them to the MN, FA, and HA. This allows for protocols such as AH and ESP to be specified and used for each leg (MN-FA, FA-HA, and MN-HA) of the Mobile IP traffic path. 3.3 Registration Registration proceeds as in [Calhoun98d], where the foreign agent converts the Mobile IP Registration Request into a DIAMETER AA- Mobile-Node-Request. The MN includes in the request any desired security policies for the MN-FA or MN-HA legs, and the FA adds Security Profile extensions that indicates the security profiles the FA is able to support. This request is then forwarded, possibly via a proxy, to a home DIAMETER server. The response to the FA Challenge is verified, and if successful the DIAMETER server determines what security profiles the user is eligible or required to use on each leg. The home DIAMETER server then creates keys and selects SPIs. It then sends out a Home-Agent-MIP-Request to the HA, which includes the MN _ HA and FA _ HA keys, plus the security profile suitably encrypted so that only the HA can read them. The HA then may assign a home address to the MN, if one was not assigned already, and return it in a Home-Agent-MIP-Answer to the home DIAMETER server. If registration was successful, the home DIAMETER server returns a AA-Mobile-Node-Reply to the original DIAMETER server which relays it on to the original FA. This message contains the MN - FA, FA _ HA, and HA - FA keys and SPIs, encrypted on hop- by-hop basis so that the FA can decode them. It also contains the MN - FA and MN - HA keys in the enclosed Registration Reply, encrypted with the MN's original shared secret so that only the MN can decode them. The FA extracts the key, SPI, and security profile. The FA then returns a Mobile IP Registration Reply to the MN. The mobile does not receive the HA and FA related keys, SPIs, or security profile. If no special security services are required on the MN-FA or MN-HA legs, this allows for a mode of operation where the MN is completely unaware of the policy distribution, but where IP security is used between the FA and HA. As discussed in the introduction, this mode of operation may be suitable for many wireless deployment scenarios. McCann and Hiller Expires 12/99 5 INTERNET DRAFT IP Transform Policy Distribution June 1999 3.4 Security Association Control Assuming the home DIAMETER server selected appropriate policies, the given keys, SPIs, and security attributes are used to populate the security association databases of the MN, FA, and HA. Subsequent communications will then use these security associations. Typically, IPsec will be used for this purpose. The lifetime of each SA will be distributed along with the policy specifications. Refreshment of an SA may be accomplished via another Mobile IP/DIAMETER exchange or by means outside the scope of this document. 4.0 DIAMETER Transform Policy Extension As stated above, we assume that DIAMETER extensions describing the security policy may be included in the AA-Mobile-Node-Request and AA-Mobile-Node-Reply. It can also be included in the Home-Agent- MIP-Request and Home-Agent-MIP-Answer. In the request, the FA includes one or more extensions to indicate acceptable security policies. In the reply, the HA includes exactly one extension for each leg (FA-HA, HA-FA, MN-FA, FA-MN) to indicate which policy is acceptable for each leg. The FA and HA will then populate their security policy databases with the indicated policies, keys, and SPIs. Some of the fields in this extension are borrowed from previous work [Vakil98], although we also distribute keys and do not specify the use of ISAKMP. The policies described here are designed to be used directly by IP Security. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | Reserved |P|T|V|E|H|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proposal Number | Transform Order | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Spec | Protocol | Encap Mode | Anti-Replay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transform | Authentication Method | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA-Life-Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA-Life-Kbs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Data... McCann and Hiller Expires 12/99 6 INTERNET DRAFT IP Transform Policy Distribution June 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AVP Code TBD - DIAMETER Transform Policy Extension AVP Length 32 plus the length of the Key, if any. AVP Flags The 'M' bit MUST be set. The 'H' and 'E' MAY be set depending upon the security model used. The 'V', 'T' and the 'P' bits MUST NOT be set. Proposal Number A unique number given to the sequence of transforms of which this transform is a member. This allows the FA to include a number of different proposals for transformation sequences in its request. Transform Order The place for this transform in the sequence given by the Proposal Number. For example, if the FA wanted to make proposal number 2 be an IPcomp transform followed by an ESP transform, it would include two Policy Extensions, each with Proposal Number set to 2, and one extension (specifying the IPcomp transform) with Transform Order 0, and the other (specifying the ESP transform) with Transform Order set to 1. Tunnel Spec Specifies to which tunnel(s) the given policy parameters apply. 1 - HA to FA 2 - FA to HA 3 _ MN to FA 4 _ FA to MN 5 _ MN to HA 6 _ HA to MN Protocol Specifies what security protocol is to be used. 1 - Authentication Header (AH) McCann and Hiller Expires 12/99 7 INTERNET DRAFT IP Transform Policy Distribution June 1999 2 - Encapsulation Security Payload Header (ESP) 4 - IP Compression (IPCOMP) Encap Mode Specifies the encapsulation mode for the given protocol. 1 - Tunnel-Mode 2 - Transport-Mode Anti-Replay Specifies whether Anti-Reply protection is used with the given protocol. 1 - Anti-Replay-Enabled 2 - Anti-Replay-Disabled Transform Specifies the desired transform to use with the given protocol. 0 - NULL (ESP Only) 1 - DES (ESP and AH) 2 - 3DES (ESP Only) 3 - DES_IV64 (ESP Only) 4 - RC5 (ESP Only) 5 - IDEA (ESP Only) 6 - CAST (ESP Only) 7 - Blowfish (ESP Only) 8 - 3IDEA (ESP Only) 9 - DES_IV32 (ESP Only) 10 - ARCFOUR (ESP Only) 11 - MD5 (AH Only) 12 - SHA-1 (AH Only) 14 - LZS (IPCOMP Only) 15 - V.42bis (IPCOMP Only) 16 - DEFLATE (IPCOMP Only) Authentication Method Specifies the desired authentication algorithm for the given protocol. 1 - HMAC-MD5 (ESP and AH) 2 - HMAC-SHA-1 (ESP and AH) 3 - DES-MAC (ESP and AH) 10 - KPDK (AH Only - MUST be used with MD5 as transform only) SA-Life-Seconds McCann and Hiller Expires 12/99 8 INTERNET DRAFT IP Transform Policy Distribution June 1999 Specifies the number of seconds before the security association will expire. SA-Life-Kbs Specifies the number of kilobytes that can be transmitted before the security association will expire. SPI The Security Parameter Index or Compression Parameter Index to be used for this transform. Key Data The secret key or any other data appropriate to the given transform, to be used for the life of the security or other association. 5. Mobile IP Registration Request and Reply Extensions The extensions defined by Zao and Condell [Zao97] allow for communicating which paths must be protected by IP Security mechanisms. However, these fields specify only which tunnels will be protected, and they rely on subsequent negotiation ala ISAKMP [Maughan98] to establish keys and algorithms. Here we assume that the protocols and algorithms used for protection, along with SPIs and secret keys, can be expressed by adding new extensions to the Registration Reply. These may also be used in a Registration Request if the MN has a preference for specific protocols and algorithms. The final extension specifies the treatment of Mobile IP reverse tunnels [Montenegro98]. 5.1 Mobile IP Transform Policy Extension The Mobile IP Transform Policy Extension should be inserted by the HA in Registration Replies, and may be included by MNs in a Registration Request. It should not be modified by the FA. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Proposal No | Trans Order | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Spec | Protocol | Encap Mode | Anti-Replay | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Transform | Authentication Method | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ McCann and Hiller Expires 12/99 9 INTERNET DRAFT IP Transform Policy Distribution June 1999 | SA-Life-Seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SA-Life-Kbs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD - Mobile IP Transform Policy Extension Length 24 plus the length of the Key, if any. Proposal Number A unique number given to the sequence of transforms of which this transform is a member. This allows the FA to include a number of different proposals for transformation sequences in its request. Transform Order The place for this transform in the sequence given by the Proposal Number. For example, if the FA wanted to make proposal number 2 be an IPcomp transform followed by an ESP transform, it would include two Policy Extensions, each with Proposal Number set to 2, and one extension (specifying the IPcomp transform) with Transform Order 0, and the other (specifying the ESP transform) with Transform Order set to 1. Tunnel Spec Specifies to which tunnel(s) the given policy parameters apply. 1 - HA to FA (Not applicable for most situations) 2 - FA to HA (Not applicable for most situations) 3 _ MN to FA 4 _ FA to MN 5 _ MN to HA 6 _ HA to MN Protocol Specifies what security protocol is to be used. McCann and Hiller Expires 12/99 10 INTERNET DRAFT IP Transform Policy Distribution June 1999 1 - Authentication Header (AH) 2 - Encapsulation Security Payload Header (ESP) 4 - IP Compression (IPCOMP) Encap Mode Specifies the encapsulation mode for the given protocol. 1 - Tunnel-Mode 2 - Transport-Mode Anti-Replay Specifies whether Anti-Reply protection is used with the given protocol. 1 - Anti-Replay-Enabled 2 - Anti-Replay-Disabled Transform Specifies the desired transform to use with the given protocol. 0 - NULL (ESP Only) 1 - DES (ESP and AH) 2 - 3DES (ESP Only) 3 - DES_IV64 (ESP Only) 4 - RC5 (ESP Only) 5 - IDEA (ESP Only) 6 - CAST (ESP Only) 7 - Blowfish (ESP Only) 8 - 3IDEA (ESP Only) 9 - DES_IV32 (ESP Only) 10 - ARCFOUR (ESP Only) 11 - MD5 (AH Only) 12 - SHA-1 (AH Only) 14 - LZS (IPCOMP Only) 15 - V.42bis (IPCOMP Only) 16 - DEFLATE (IPCOMP Only) Authentication Method Specifies the desired authentication algorithm for the given protocol. 1 - HMAC-MD5 (ESP and AH) 2 - HMAC-SHA-1 (ESP and AH) 3 - DES-MAC (ESP and AH) 10 - KPDK (AH Only - MUST be used with MD5 as transform only) McCann and Hiller Expires 12/99 11 INTERNET DRAFT IP Transform Policy Distribution June 1999 SA-Life-Seconds Specifies the number of seconds before the security association will expire. SA-Life-Kbs Specifies the number of kilobytes that can be transmitted before the security association will expire. SPI The Security Parameter Index or Compression Parameter Index to be used for this transform. Key Data The secret key or any other data appropriate to the given transform, to be used for the life of the security or other association. This field should be protected by the MN shared secret. 5.2 Mobile IP Reverse Tunnel Policy Extension This extension is used to specify how the FA should treat packets that arrive from the mobile node. It tells whether reverse tunnels are required and if so what delivery styles are available. In the case of Encapsulated Delivery, this extension describes what to do with Direct Delivered packets. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reverse Tunnel Policy | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type [TBD] - Reverse Tunnel Policy Length 2 Reverse Tunnel Policy 0 - No, reverse tunneling is not required. 1 - Yes, reverse tunneling with Direct Delivery style is required. All traffic will be tunneled to the HA. 2 - Yes, reverse tunneling with Encapsulated Delivery McCann and Hiller Expires 12/99 12 INTERNET DRAFT IP Transform Policy Distribution June 1999 style is required and Direct Delivery packets should be silently dropped by the FA. 3 - Yes, reverse tunneling is required, but Encapsulated Delivery mode may be negotiated. Encapsulated packets will be tunneled to the HA and Direct Delivered packets will be routed directly to the CN. 4 - Like (3), but with a private MN address. The FA must use NAT to propagate Direct Delivery packets. 6. Tunnel Formats and Applicability In this section we discuss the protection of user traffic. We give justification for the use of IP Security on each leg of Mobile IP, revisiting some of the same arguments given by Zao and Condell[Zao97], and we raise some new issues having to do with the use of private addresses by mobile nodes. In particular, we are concerned with the fact that each mobility agent must have enough information to properly identify a particular packet as belonging to a particular mobile node, as well as what security association should be used to decrypt or authenticate the packet. In what follows, we use the notation S, D, trans, payload to denote a packet with the source field set to S, the destination field set to D, an IP Transformation header (AH, ESP, IPcomp, or other) generated from an association between S and D, and a payload. If the header includes AH, then the authentication covers S, D, and the payload data. If the header includes ESP, then the payload is encrypted according to the SA. 6.1 FA - HA In the absence of end-to-end protection of traffic between the MN and HA, protection applied between the FA and HA may be the next best thing. This technique has the advantage that it adds zero overhead to the link between the FA and MN, which might be slow and which may be protected itself by link-layer authentication and encryption. As was noted in [Zao97], IP Security headers such as AH [Kent98a] and ESP [Kent98b] can be added directly to the tunnels between the FA and HA. Also, IP Compression could be used between the MN and FA. This leads to packets of the form: FA, HA, trans, encapsulation(MN, CN, payload) HA, FA, trans, encapsulation(CN, MN, payload) Because all SPIs were generated by the home AAA server, which should generate values unique to the HA, the FA may use the tuple (HA, SPI) McCann and Hiller Expires 12/99 13 INTERNET DRAFT IP Transform Policy Distribution June 1999 to distinguish to which SA and MN a given packet belongs. Also, the HA may simply use the SPI to distinguish the SA and MN. Note that if IP Security or some SPI-based transform is not used on this tunnel, and if the HA supports multiple, distinct private networks, the encapsulation must be GRE and a Tunnel Identifier [Calhoun98a] must be used to distinguish the traffic, because MNs may have overlapping private addresses. Otherwise, normal IP-in-IP tunnels may be used and the FA can distinguish traffic based on the tuple (HA, MN) which will be unique if the HA supports only one private network. 6.2 MN - FA When using a shared medium, or if the link-layer authentication and privacy mechanisms are deemed insufficient, it may be desirable to protect traffic between the MN and FA. If the FA is owned by a wireless carrier, it may wish to authenticate each packet from the MN even if the traffic itself is not protected for privacy, in order to rule out service-stealing attacks by malicious MNs. Similarly, IP Compression may be used if link-layer compression is deemed insufficient. Unfortunately, when using a non-collocated care-of address, normally the only way to transform such traffic is to use the Encapsulated Delivery style, which is only used when reverse tunnels [Montenegro98] have been negotiated. If such protection is desired, we propose using the FA as one would use any other security gateway; i.e., use IP Security headers in tunnel mode. This leads to packets of the form: MN, FA, trans, (MN, CN, payload) In the case where Encapsulated Delivery is negotiated, and the MN wants the flexibility to deliver some traffic directly rather than through a reverse tunnel, we must additionally encapsulate the non- direct traffic, as in: MN, FA, trans, (MN, FA, encapsulation(MN, CN, payload)) Traffic in the forward direction can always be protected by: FA, MN, trans, (CN, MN, payload) Note that because the MN address may be private, the FA must rely on the link-layer address of the MN to distinguish which SA is used to protect the traffic. Also, direct delivery of packets, for instance direct access to servers on the public Internet, may require the FA to implement some form of NAT [Srisuresh98] if the MN addresses are private. McCann and Hiller Expires 12/99 14 INTERNET DRAFT IP Transform Policy Distribution June 1999 6.3 MN - HA To provide protection against malicious FAs, the security association between the MN and HA may be used. Truly end-to-end protection would be a security association between MN and CN, but setting up such associations might be costly and unnecessary if all CNs are in the private network protected by the HA. As noted in [Zao97], protection between the MN and HA requires the insertion of an extra header. This amounts to treating the HA simply as a security gateway, and sending encapsulated packets to it via the Mobile IP redirection tunnel. Packets from the MN could be formatted as: MN, HA, trans, (MN, CN, payload) The HA should receive the packet, use its SA with the MN to decapsulate it, and finally forward the packet on to the CN. In the forward direction, we have: HA, MN, trans, (CN, MN, payload) The MN can use its SA with the HA to decapsulate the packet and then handle it normally. 7. Security This contribution outlines a new mechanism for distributing IP Security Associations to HAs, FAs, and MNs. The policy AVPs in this draft are secured as with other informational elements in the DIAMETER protocols via pre-existing security associations between AAA servers. Depending on the policies selected, different security requirements are achieved. For example, some configurations of policies allow the FA plain-text access to messages, and security between MN and CN is outside the scope of this document. However, the use of IP security on only the leg from FA to HA may be acceptable to many users if there is a sufficient degree of trust in the FA, if the home network behind the HA is trusted, and if the first-hop link is protected by other means. References [Bradner97] S. Bradner, "Key words for use in RFCs to Indicate Requirement Level", RFC 2119, March 1997. McCann and Hiller Expires 12/99 15 INTERNET DRAFT IP Transform Policy Distribution June 1999 [Calhoun98a] Calhoun, Montenegro, Perkins, "Tunnel Establishment Protocol", draft-ietf-mobileip-calhoun-tep-01.txt, March 1998. Work In Progress. [Calhoun98b] Calhoun, Montenegro, Perkins, "Mobile IP Regionalized Tunnel Management", draft-ietf-mobileip-reg-tunnel-00.txt, November 1998. Work In Progress. [Calhoun98c] Calhoun, Rubens, "DIAMETER Base Protocol", draft- calhoun-diameter-04.txt, July 1998. Work In Progress. [Calhoun98d] Calhoun, Perkins, "DIAMETER Mobile IP Extensions", draft-calhoun-diameter-mobileip-01.txt, November 1998. Work In Progress. [Calhoun98e] Calhoun, Bulley, "DIAMETER Proxy Server Extensions", draft-calhoun-diameter-proxy-01.txt, August 1998. Work In Progress. [Harkins98] Harkins, Carrel, "The Internet Key Exchange", RFC 2409, November 1998. [Hiller99] "3G Wireless Data Provider Architecture Using Mobile IP and AAA" draft-hiller-3Gwireless-00.txt, March 1999. Work in Progress. [Kent98a] Kent, Atkinson, "Security Architecture for the Internet Protocol", RFC2401, November 1998. [Kent98b] Kent, Atkinson, "IP Authentication Header", RFC 2402, November 1998. [Kent98c] Kent, Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [Maughan98] Maughan, Schertler, Schneider, Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [Montenegro98] Montenegro, "Reverse Tunnels for Mobile IP", RFC 2344, May 1998. [Perkins96] C. Perkins, Editor, "IP Mobility Support", RFC 2002, October 1996. [Simpson94] Simpson, Editor, "The Point-to-Point Protocol (PPP)", RFC 1661, July 1994. [Srisuresh98] Srisuresh, Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", draft-ietf-nat-terminology- 01.txt, October 1998. Work In Progress. McCann and Hiller Expires 12/99 16 INTERNET DRAFT IP Transform Policy Distribution June 1999 [Vakil98] Vakil, Calhoun, "DIAMETER IP Security Policy Extensions", draft-calhoun-diameter-ipsec-policy-00.txt, March 1998. Work In Progress. [Zao97] Zao, Condell, "Use of IPSec in Mobile IP", draft-ietf- mobileip-ipsec-use-00.txt, November 1997. Work In Progress. Addresses Questions about this memo can be directed to: Peter J. McCann Lucent Technologies Rm 2Z-305 263 Shuman Blvd Naperville, IL 60566 USA email: mccap@lucent.com phone: +1 630 713 9359 fax: +1 630 713 4982 Tom Hiller Lucent Technologies Rm 2F-218 263 Shuman Blvd Naperville, IL 60566 USA email: tom.hiller@lucent.com phone: +1 630 979 7673 fax: +1 630 224 5811 McCann and Hiller Expires 12/99 17