Internet Draft C. Madson Document: draft-ietf-ipsec-sonofike-rqts-00.txt Cisco Expires: September 2002 March 2002 Son-of-IKE Requirements 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 Various proposals have been made for updating the IKE protocol. This effort has been known as "Son of IKE (SOI)". One thing that is missing from the discussion is an evaluation of the scope of SOI, identifying which problems it should solve. Sections of this document discuss various scenarios that are considered important for SOI. Once this scoping is done, it becomes easier to specify the requirements of the protocol. This document also discusses protocol, policy and security requirements for SOI, along with recommendations for protocol improvement in such areas as modularity, extensibility, protocol convergence and simplicity, which are important regardless of the scope of SOI. Hain Expires - September 2002 [Page 1]
Son-of-IKE Requirements March 2002 Table of Contents 1. Overview.......................................................5 1.1 Changes from Previous Drafts...............................5 2. Conventions Used in This Document..............................6 3. Definitions....................................................6 4. Scenarios: Primary Domains of Usage............................6 4.1 Virtual Private Network Site-to-Site Tunnels...............7 4.1.1 Operational Characteristics..........................7 4.1.1.1 General Description...........................8 4.1.1.2 Dynamic Addressing............................8 4.1.1.3 NAT...........................................9 4.1.1.4 QoS...........................................9 4.1.2 Policy...............................................9 4.1.3 Security-Related Characteristics....................10 4.1.3.1 Authentication...............................10 4.1.3.2 Identity.....................................10 4.1.3.3 Identity Protection..........................10 4.2 Secure Remote Access......................................10 4.2.1 Operational Characteristics.........................11 4.2.1.1 General......................................11 4.2.1.2 Dynamic Addressing...........................12 4.2.1.3 NAT..........................................12 4.2.1.4 QoS..........................................12 4.2.2 Policy..............................................13 4.2.3 Security Characteristics............................13 4.2.3.1 Authentication...............................13 4.2.3.2 Identity.....................................14 4.2.3.3 Identity Protection..........................14 4.3 End-to-End Security.......................................14 4.3.1 Operational Characteristics.........................15 4.3.1.1 General Description..........................15 4.3.1.2 Dynamic Addressing...........................15 4.3.1.3 NAT..........................................15 4.3.1.4 QoS..........................................15 4.3.2 Policy..............................................16 4.3.3 Security Characteristics............................16 4.3.3.1 Authentication...............................16 4.3.3.2 Identity.....................................16 4.3.3.3 Identity Protection..........................16 4.4 IP Storage................................................17 4.4.1 Operational Characteristics.........................17 4.4.1.1 General Description..........................17 4.4.1.2 Dynamic Addressing...........................18 4.4.1.3 NAT..........................................18 4.4.1.4 QoS..........................................18 4.4.2 Policy..............................................18 4.4.3 Security Characteristics............................18 4.4.3.1 Authentication...............................18 Madson Expires - September 2002 [Page 2]
Son-of-IKE Requirements March 2002 4.4.3.2 Identity.....................................19 4.4.3.3 Identity Protection..........................19 4.5 PPVPN/MPLS................................................19 4.5.1 PE-to-PE IPsec......................................19 4.5.2 CE-to-CE IPsec......................................20 5. Other Problem Areas...........................................20 5.1 Mobile IP/Wireless........................................20 5.1.1 Fast Handoff........................................21 5.1.2 Securing Binding Updates............................21 5.2 Multiple and Changing Addresses: IPv6, SCTP and MobileIP (and NAT?).........................................................22 5.3 Delay-sensitive Applications..............................23 5.4 Other Users of IPsec......................................24 6. General Operational Requirements..............................24 6.1 Scalability...............................................24 6.2 Fast setup................................................25 6.3 One-phase vs. two-phase exchange..........................26 7. Protocol Requirements.........................................27 7.1 Protocol Interaction......................................27 7.2 Identity..................................................27 7.3 Interaction with NAT......................................27 7.4 General Protocol Design Criteria..........................28 7.4.1 Modularity..........................................28 7.4.2 Extensibility.......................................28 7.4.3 Protocol Convergence................................29 7.4.4 Simplicity..........................................30 8. Policy Requirements...........................................30 8.1 Provisioning and Management...............................30 8.1.1 Configuration.......................................30 8.1.2 Discovery...........................................31 8.2 Expanding the set of selectors............................31 8.3 SPD traffic flow descriptors and dynamic policy...........32 8.4 Retaining SAs in face of address changes..................33 8.5 Distribution of authentication information................34 8.6 Authorization.............................................34 8.7 Additional "per-connection" policy........................34 9. Security Requirements.........................................34 9.1 Key Agreement.............................................34 9.2 Key Generation............................................35 9.3 Authentication............................................35 9.4 Resistance to Denial-of-Service Attacks...................36 9.5 Resistance to Replay Attacks..............................37 9.6 Resistance to downgrade attacks...........................37 9.7 Implementation Recommendations............................37 9.8 Use of Negotiation Suites.................................37 9.9 Identity Hiding...........................................38 9.10 Plausible Deniability....................................38 9.11 Protection of Key Management Messages....................39 9.12 Support for PFS..........................................39 Madson Expires - September 2002 [Page 3]
Son-of-IKE Requirements March 2002 10. Security Considerations......................................39 11. Acknowledgements.............................................40 12. References...................................................40 13. Editor's Address.............................................41 Madson Expires - September 2002 [Page 4]
Son-of-IKE Requirements March 2002 1. Overview While there have been various proposals made over time of how to "improve" IKE, in order to address issues such as complexity, itÆs important to decide what are the important characteristics for the protocol, and then determine what changes need to be made in order to accomplish this. Another way of stating this is "what are the characteristics of an optimal protocol, and what does it take to get there?" It will be important to prioritize these characteristics, in order to help focus on making changes in areas that will have the biggest benefit. We first need to identify the "important" baseline scenarios that should be accommodated with a redesign of IKE. These scenarios should drive the definition of detailed requirements in various areas. However, in many cases the scenarios themselves cannot completely drive security requirements. There are also some general requirements that can be considered as requirements related to protocol design, both of which will be outlined later in the document. The WG needs to prioritize the sometimes conflicting requirements; subsequent revisions of this document should reflect this. The term "Son of IKE" (SOI) will be used to refer to the new protocol. Where appropriate, "IKE" will be used to refer to the original protocol. The term "IPsec tunnel" means an instance of an IPsec "connection", in this context it does not mean "tunnel mode IPsec". 1.1 Changes from Previous Drafts The primary differences between this draft and the previous draft are: . inclusion of security and policy requirements along with the protocol requirements . expanding the scenarios . restructuring the document to emphasize the scenarios, where more of the requirements are represented as a result of the scenarios . reducing the amount of "philosophical discussion" from the original draft (which was put there to influence initial WG thinking). Madson Expires - September 2002 [Page 5]
Son-of-IKE Requirements March 2002 2. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119[1]. 3. Definitions This section defines some terms relative to how they are used within this document. 1) Dynamic addressing: the network node does not have a fixed address, and the DNS entry is tied to the address and not the node. 2) Machine-level authentication: refers to some static authentication scheme, where the authentication material is readily available to both parties. Machine-level also refers to the fact that the device is authenticated, and not the user using the device, which is a function of a higher layer or separate protocol. 3) User-level authentication: refers to the fact that the user of the device is authenticated. This authentication may be "static" (simple presenting of user credentials) or "dynamic" (interactive exchange between user and authentication server/proxy, using legacy authentication mechanisms). 4. Scenarios: Primary Domains of Usage It is important for SOI to focus on some number of usage domains, and make sure that the domains' requirements have been met. The following sections describe several characteristics of each domain of usage that are noteworthy: . Operational Characteristics o General o Dynamic addressing o NAT o QoS . Policy . Security Characteristics o Authentication o Identity o Identity Protection Madson Expires - September 2002 [Page 6]
Son-of-IKE Requirements March 2002 The scenarios listed here are considered to be the major ones that should be addressed, although the list is not exhaustive and needs to be refined by the WG. For simplicity's sake, this section attempts to describe "idealized" scenario classes. However, the real world *will* have scenarios which are hybrids of one or more of the below classes. The next section will describes some problem areas that are orthogonal to the main classes; in some scenarios these classes would be used in conjunction with the above classes, but they are kept separate to reduce the complexity of the discussion. A combination of brackets <<< >>> and identing are used to highlight items that should be considered during protocol design. 4.1 Virtual Private Network Site-to-Site Tunnels VPN Site-to-Site Tunnels are between two devices acting as Security Gateways (SGWs). IPsec can either directly encapsulate the IP traffic that it will secure, or it can secure another tunneling protocol (e.g. IPinIP) running between the two SGWs, where that tunnel has already encapsulated the data. The SGWs may be responsible for securing a wide variety of traffic, including interactive (Telnet), file transfer and HTTP traffic. Customers are also increasingly deploying IP-based video conferencing and VoIP. This category can be broken down into two sub-categories: . The VPN itself is in the same general administrative domain as the transport network. . The VPN is in a separate administrative domain from the transport network. This can include a VPN that traverses transport networks in multiple domains. In both cases, the VPN itself is in a single administrative domain. 4.1.1 Operational Characteristics In the first sub-category, the VPN is in the same administrative domain as the transport network (to be referred to as "single administrative domain" in this document). One such example may be a campus network. Such a network may be a (near) full-mesh. Madson Expires - September 2002 [Page 7]
Son-of-IKE Requirements March 2002 In the second sub-category, the VPN is in a different administrative domain from the transport network (to be referred to as "multiple administrative domains" in this document). One such example may be one or more SPs interconnecting several locations of an enterprise, where the enterprise is managing the VPN. Depending upon its size and organizational topology, the VPN may operate as a (near) full-mesh, or it may operate with more limited interconnection (e.g. hub-and-spoke). 4.1.1.1 General Description The administrator may have requirements to encrypt some or all of the traffic that crosses the transport network, and may require that certain traffic be handled or otherwise protected different from other traffic (e.g. a department-wide video conference may need to be protected and/or handled in a different manner than normal file transfer/web traffic between systems in that same department). While a simple general model has the SGWs simply protecting subnet- to-subnet traffic, the greater the number of distinctive traffic classes identified, the greater the number of IPsec tunnels needed between the SGWs. Even the simple model can result in a lot of IPsec tunnels in the case where each SGW is fronting multiple non- contiguous subnets (such as in the case where the SGWs are on the customer premise boundaries). <<<This calls out a need for either a two-phased approach for SOI, or a single-phased approach that is sufficiently fast, where "fast" represents an optimal combination of "number of messages" and "computational expenditure". The cost of authentication must also be factored into the total cost; this will be different for different mechanisms, which results in a decision of scalability - - vs- processing overhead. In certain cases, it may be desirable to amortize the cost of the key management across multiple tunnels. In the case of a pair of SGWs fronting multiple non-contiguous subnets, a mechanism that allowed the negotiation of a list of phase 2 identities will help to alleviate the number of IPsec tunnels that must be created.>>> 4.1.1.2 Dynamic Addressing Madson Expires - September 2002 [Page 8]
Son-of-IKE Requirements March 2002 Within a single administrative domain network, the SGWs will almost always have permanent IP addresses assigned to them. Within a multiple administrative domain network, there may be a mixture of SGWs with static and dynamic IP addresses. 4.1.1.3 NAT Within a single administrative domain network, it is unlikely that NAT devices will be deployed between the SGWs. Within a multiple administrative domain network, the IPsec tunnel may be NAT'd between the SGWs. The traffic inside the IPsec tunnel may also be NAT'd by one of the SGWs. 4.1.1.4 QoS In many cases, there will be a need for separate handling of multimedia vs. standard file transfer/web/login traffic. Depending upon the characteristics of the traffic, this may call out a need for fast tunnel establishment ("fast" in this case is expanded to also mean low delay). Such traffic may also need to be separately protected (e.g. via stream ciphers instead of block ciphers). Depending on the location of the SGWs relative to the systems that do the QoS classification/marking, <<<extensions to the IPsec (now known as phase 2) parameters are needed in order to negotiate QoS characteristics for the various tunnels. QoS increases the probability of multiple tunnels between a pair of SGWs. Also, negotiation of IPsec tunnels needs to accommodate QoS information, predominantly in the set of selectors used to identify the contents of any particular IPsec tunnel.>>> 4.1.2 Policy The peers in this scenario are more likely to be relatively static (in terms of IP address, number of peers, and rate at which a new peer will get added or existing peer deleted). The number of peers is also likely to be lower by orders of magnitude than in the Remote Access case. Therefore configuring policy pertaining to SOI (authentication material as well as ciphers) can easily be statically configured on each peer. Another issue is policy that should apply to the resulting IPsec tunnel. In the site-to-site case, since peers are bound to be fairly static, configuring this IPsec policy (inside IP addresses, firewall Madson Expires - September 2002 [Page 9]
Son-of-IKE Requirements March 2002 features, QoS features, etc) can be manually configured on both ends, rather than pushed or pulled in some way. 4.1.3 Security-Related Characteristics 4.1.3.1 Authentication Machine-level only. 4.1.3.2 Identity If the SGWs do not have dynamic IP addresses, and there are no NAT boxes between the SGWs, IP addresses can be sufficient for phase 1 identities, although this is discouraged. <<<In the case of dynamic IP addresses and/or NAT boxes, IP addresses cannot be used as phase 1 identifiers. This also means that the authentication material cannot be chosen based upon the IP address in the packet.>>> 4.1.3.3 Identity Protection In a single administrative domain network, while identity protection is desirable, in many cases it is not a requirement. <<<In a multiple administrative domain network, identity protection of both IPsec endpoints is important.>>> 4.2 Secure Remote Access When the client is outside the protected network that it needs to access, it will have to interact with a Remote Access Server (RAS) in order to access that network. In many cases, this scenario is replacing a remote access scenario that uses dial-up access to reach a network. The client would dial up to the RAS and interact with the RAS to perform user-level authentication (e.g. userid/password, SecureID, etc.). If the authentication is successful, the RAS would permit access to that network, and it may also push down configuration information to the client. In this scenario, before the IPsec tunnel is constructed between the client and the RAS, the client must first authenticate itself (most likely using legacy authentication mechanisms). The IPsec connection Madson Expires - September 2002 [Page 10]
Son-of-IKE Requirements March 2002 will most likely operate in tunnel mode, and will most likely always be initiated by the client. The entity that supplies the RAS typically requires accounting of connections and resources consumed, in order to do capacity planning. 4.2.1 Operational Characteristics 4.2.1.1 General A RAS server in many cases is a remote access aggregation device, which is terminating large numbers of IPsec tunnels. In the case of a reboot of a RAS, the RAS will be forced to rapidly service a large number of requests to reestablish SOI and IPsec connections. [While this problem is also true in the Site-to-Site scenarios, the aggregation densities associated with RAS devices means that this issue tends to be more prevalent in this scenario.] <<<This means that the key management mechanism must be able to rapidly establish both the SOI and IPsec connections, without undue impact on CPU and memory overhead. ItÆs also desirable for each exchange to have as few messages as possible, to help alleviate the burst load on the RAS.>>> It is more common for a remote access client to initiate a single SOI connection and create a single IPsec tunnel with the RAS. However, if there is a need to uniquely handle separate data flows (e.g. video vs. ftp), a client may need to establish multiple IPsec tunnels with the RAS. In most cases, any user authentication should apply against the collection of IPsec tunnels, in other words, the user should not be forced to re-authenticate with every tunnel setup. [While on the one hand, this can be viewed as a local issue, in the case of certain legacy authentication mechanisms, having the client simply store the value and use it again for the next IPsec tunnel will not work.] <<<While this does not mandate user authentication to happen within the SOI exchange, itÆs strongly encouraged that the protocol directly or indirectly associate a single user authentication exchange with a group of IPsec tunnels between a client and an RAS.>>> In certain scenarios, a single RAS may be supporting traffic for different VPNs. In this case, the RAS will have a separate identity per domain. For any given SOI exchange, the RAS will need to select which identity it will use depending upon the identity supplied by the client. Basically, the RAS needs the clientÆs identity in order Madson Expires - September 2002 [Page 11]
Son-of-IKE Requirements March 2002 to decide how to interact with the client (e.g. negotiation parameters, RAS identity, etc.). <<<For example, this may mean that SOI will need to allow for the client to present its identity (or some "blob of bits" that the server can correctly map to an identity) early in the exchange.>>> 4.2.1.2 Dynamic Addressing The client will almost always have a dynamic IP address, while the RAS will have a fixed IP address. <<<The protocol design (e.g. state management) needs to consider rapid disconnection/reconnection events, where one client disconnects and gives up its (outside, or phase 1) IP address, and the next client grabs that same address.>>> 4.2.1.3 NAT There may be one or more NAT devices between the client and the RAS. If an internal address is assigned to the client, there should not be any need for the RAS to perform NAT translation on the traffic that is sent to/received from the IPsec tunnel. 4.2.1.4 QoS While the typical remote access case involves establishing a single IPsec tunnel between the client and the RAS, over time there will become a need for multiple IPsec tunnels between the client and the RAS, for separate handling of multimedia vs. standard file transfer/web/login traffic. Depending upon the characteristics of the traffic, this may call out a need for fast tunnel establishment ("fast" in this case is expanded to also mean low delay). Such traffic may also need to be separately protected (e.g. via stream ciphers instead of block ciphers). <<<Extensions to the IPsec (now known as phase 2) parameters are needed in order to negotiate QoS characteristics for the various tunnels. QoS increases the probability of multiple tunnels between a client and a RAS. Also, negotiation of IPsec tunnels needs to accommodate QoS information, predominantly in the set of selectors used to identify the contents of any particular IPsec tunnel.>>> Madson Expires - September 2002 [Page 12]
Son-of-IKE Requirements March 2002 4.2.2 Policy The remote access scenario generally involves downloading some 'per- connection' policy from the RAS to the client. In general, this information is associated with the bootstrapping of the client connections (set of IPsec tunnels), such as the internal IP address assigned to the client. There may be information associated with a single IPsec tunnel out of the set (e.g. information on QoS settings that the client could use for marking the traffic). Either the push or pull model of policy distribution may be needed, depending upon the scenario. <<<This means that there must be a way of securely pushing down this policy information before the IPsec tunnel is constructed.>>> 4.2.3 Security Characteristics 4.2.3.1 Authentication Remote access is one of the major scenarios that isn't solely based on mutual authentication. In some scenarios, machine-level authentication in the client-to- server direction may be sufficient (e.g. the authentication information supplied by the client is sufficient for the RAS to grant access to the protected network). In other cases, user-level authentication is also required. This is primarily supplied via legacy authentication mechanisms. User-level authentication could also be done via user credentials that can easily passed in IKE phase 1 (e.g. x.509 user certs). In the server-to-client direction, the client can use machine-level authentication to validate that it is communicating with a desired RAS. In other scenarios, such as an Internet Kiosk, machine-level authentication becomes meaningless; user-level authentication is needed for the client to gain access to the protected network. In this case, there is no equivalent server-to-client authentication. Other considerations in terms of user-level authentication: <<<The mechanism associated with such authentication should accommodate re-authentication based on the RAS or authentication server site security policy>>> (e.g. the local policy demands re- authentication every 8 hours or the connection is torn down). If out-of-band mechanisms are used for user-level authentication (ala Madson Expires - September 2002 [Page 13]
Son-of-IKE Requirements March 2002 PIC), then the mechanism must somehow come up with a means of supporting this requirement. There should be some means of supporting asymmetric authentication mechanisms for user-level authentication. Some consideration should be made as to whether or not to support such mechanisms as one of the base authentication mechanisms (e.g. what IKE would use for authentication within phase 1). A previous section discussed binding of the user-level authentication with possibly multiple simultaneous IPsec tunnels between the client and the RAS. <<<Out-of-band authentication mechanisms must also consider the location of the authentication server relative to the client and the RAS. In many scenarios, server tends to be "behind" the RAS device, in the domain that is being secured by the RAS, which may be problematic for bootstrapping the user authentication for the client-to-RAS connection.>>> 4.2.3.2 Identity The client's SOI identity comes from some authentication information supplied within the phase 1 exchange. Any identity supplied via out- of-band user-level authentication may be useful in conjunction with the connection, but it is not identity information as far as SOI is concerned. 4.2.3.3 Identity Protection In the case where the RAS is servicing multiple VPNs, the client may need to leak all or part of its identity early within the exchange, in order for the RAS to know how to act to the client (e.g. which policy and which server identity). Hiding the identity of the RAS may or may not be required. 4.3 End-to-End Security [The requirements associated with IP storage are spelled out in another section.] What this scenario attempts to describe is the characteristics associated with the common end-to-end scenarios. The primary Madson Expires - September 2002 [Page 14]
Son-of-IKE Requirements March 2002 definition of end-to-end here is that the traffic sourced by/destined to a pair of nodes is secured by those nodes. This scenario can be subdivided into at least two different scenarios, the first being the more classical case of "user-to- services", such as an IPsec connection securing an rlogin session between two workstations. The other class of scenario is associated with securing infrastructure traffic, such as a network management path between the management station and the router, or for router-to- router control traffic. 4.3.1 Operational Characteristics 4.3.1.1 General Description An IPsec "connection" is used to secure traffic between the two IP endpoints for that traffic. The granularity of the connection may be as fine as an individual socket, or as gross as all traffic between the two systems. If multiple connections exist, they can have the same or different protections. The IPsec connection can operate in either tunnel or transport mode. 4.3.1.2 Dynamic Addressing End systems may have static or dynamic addresses. 4.3.1.3 NAT The IPsec connection may undergo NAT translation. The traffic within the IPsec connection most likely will not be NAT'd. 4.3.1.4 QoS In the end-to-end model, what is the chance of needing different tunnels between a pair of end systems to support traffic with different QoS characteristics? For example, will a given system service both file transfer and multimedia traffic? If so, there would be a need for separate IPsec tunnels. Depending upon the characteristics of the traffic, this may call out a need for fast tunnel establishment ("fast" in this case is expanded to also mean low delay). Such traffic may also need to be separately protected (e.g. via stream ciphers instead of block ciphers). Madson Expires - September 2002 [Page 15]
Son-of-IKE Requirements March 2002 <<<Extensions to the IPsec (now known as phase 2) parameters are needed in order to negotiate QoS characteristics for the various tunnels. QoS may increase the probability of multiple tunnels between a pair of end systems. Also, negotiation of IPsec tunnels needs to accommodate QoS information, predominantly in the set of selectors used to identify the contents of any particular IPsec tunnel.>>> 4.3.2 Policy In general, the policy is a combination of static configuration and dynamic policy (e.g. "secure this FTP connection"). 4.3.3 Security Characteristics 4.3.3.1 Authentication In many cases, machine-level authentication is sufficient. In some cases, such as client-to-server connections, user-level authentication may also be necessary. User-level authentication via legacy mechanisms is currently outside the scope of IKE. However, it may be desirable to have such user authentication happen before IPsec connections could be established, similar to what happens in the remote access scenario. User-level authentication could also be done via user credentials that can easily passed in IKE phase 1 (e.g. x.509 user certs). 4.3.3.2 Identity Whether or not there are static IP addresses, in this scenario the identity is not normally tied to IP address, but to something like an fqdn or user-at-fqdn identifier. 4.3.3.3 Identity Protection <<<Hiding the identity of both parties in the exchange is desirable.>>> Madson Expires - September 2002 [Page 16]
Son-of-IKE Requirements March 2002 4.4 IP Storage The IPS working group is addressing the various issues associated with using storage protocols over IP. The primary protocols in question are iSCSI, iFCP and FCIP, along with support protocols SLPv2 and iSNS. [Abob01] does a very thorough job of describing the security scenarios and requirements for these protocols. While this section will attempt to highlight some of the key items, the reader is strongly encouraged to read the document. The documents within the IPS working group that describe requirements take precedence over anything described in this document. 4.4.1 Operational Characteristics 4.4.1.1 General Description iSCSI is a client-server protocol that runs over TCP and is used to access disk, tape and other devices. iSCSI sessions between a given Initiator (client) and Target (server) are run over one or more TCP connections between those entities. A single connection is used for both control and data, and is secured with its own IPsec tunnel. iFCP is a gateway-to-gateway protocol, which provides Fibre Channel fabric services to FC devices over a TCP/IP network. The primary objective is to allow interconnection and networking of existing FC devices at wire speeds over an IP network. An iFCP session runs over a single TCP connection, which is secured with its own IPsec tunnel. FCIP is a pure FC encapsulation protocol that transports FC frames. The primary objective is to allow interconnection of FC switches over TCP/IP networks. An FCIP session runs over one or more TCP connections, with each connection being secured with its own IPsec tunnel. Neither iFCP nor FCIP have any security services. iSCSI has a text- based authentication login mechanism that can provide mutual authentication, however, it has no means to support packet-by-packet security. iSNS provides for discovery and management of iSCSI and iFCP storage devices. An iSNS server keeps track of device attributes and monitors availability and reachability. iSCSI and iFCP clients can use iSNS for discovery (and possibly management). Connections between iSNS clients and servers must be secured via IPsec. Madson Expires - September 2002 [Page 17]
Son-of-IKE Requirements March 2002 SLPv2 provides for a way for iSCSI and FCIP to discover peer entities and management servers. SLPv2 may also be used to provide information on peer security configuration. It is strongly encouraged that this protocol be secured via IPsec. <<<[Abob01] discusses resource constraints, calling out the size for both code footprint and data as the most important criteria.>>> Entities may choose to terminate security associations in order to save memory, restarting them on an as-needed basis. 4.4.1.2 Dynamic Addressing iSCSI systems may use static or dynamic addressing. iFCP and FCIP systems will use static addresses. 4.4.1.3 NAT iSCSI connections may be NAT'd. iFCP and FCIP connections cannot be NAT'd. 4.4.1.4 QoS [Abob01] has no mention of QoS. 4.4.2 Policy Security policy may be statically configured on the devices. The devices can also choose to use iSNS or SLPv2 for discovery of nodes. 4.4.3 Security Characteristics 4.4.3.1 Authentication iSCSI has an in-band login authentication mechanism, which provides mutual authentication. This will provide user authentication, which can be associated with one or more connections. [Abob01] calls out using SRP for the specific authentication mechanism. Neither FCIP nor iFCP have any in-band security, so both protocols will rely on IKE for authentication. Mutual authentication is required. Madson Expires - September 2002 [Page 18]
Son-of-IKE Requirements March 2002 iSNS will use IKE authentication (e.g. machine-level only). Mutual authentication is required. SLPv2 will use IKE authentication. <<<However, the discussion in [Abob01] calls out requirements for an API, in order to provide a means of pushing authentication information to the application (e.g. "this peer was authenticated with this cert"), so the application can decide what types of transactions are allowed by this peer.>>> 4.4.3.2 Identity FCIP and iFCP must use IP addresses as identities for IKE authentication. The other protocols need to use identities other than IP addresses for authentication. 4.4.3.3 Identity Protection There is no requirement that the identities used by FCIP and iFCP be kept confidential. It is recommended that the other protocols use identity hiding. 4.5 PPVPN/MPLS A PE (Provider Edge) device can support one or more VPNs. If a PE supports multiple VPNs, it has internal logic (commonly known as VRF, or VPN routing and forwarding instance) that maintains data separation between VPNs. A CE (Customer Edge) device resides in one or more VPNs. What this means is that two or more PEs supply the transit network for a collection of CEs representing a customer network. There are various proposals in this general space, which will be outlined below. [Future versions of this draft should flesh out the scenarios in greater detail.] 4.5.1 PE-to-PE IPsec [Rose01] proposes a means of using IPsec to secure RFC2547 VPNs. The outer MPLS label of a VPN packet is replaced with an IPsec encapsulation, allowing the VPN packets to be carried over non-MPLS networks (this is to allow traversal over a mixed cloud of both MPLS Madson Expires - September 2002 [Page 19]
Son-of-IKE Requirements March 2002 and non-MPLS-aware routers, or where the transit network traverses multiple administrative domains). [Rose01] introduces the concept of using a new BGP attribute, "IPsec Extended Community", which will help indicate which traffic flows need protection. The encapsulation into MPLS and encapsulation by IPsec is viewed as an atomic operation. However, that may not be feasible in certain implementations. <<<it may make sense to expand the set of phase 2 identifiers to also support an MPLS/VPN identifier (so the entity doing the SPD check can be separated from the entity doing the encapsulation).>>> [Decl01] is another proposal for securing RFC2547 VPNs, however, it makes several special demands on the IPsec processing, including reserving part of the SPI for signaling special context. [Part of the stated goal here is to have "IKE negotiate SPI-pools, so that multiple SPIs point to the same SA".] This will most likely collide with other mechanisms that systems use to internally subdivide the SPI space, such as associating a range of SPIs with an instance of a crypto engine on a system with multiple crypto engines. The SPI allocation should be a local matter, and there shouldnÆt be any external meaning applied to the SPI values. [RFC2401 says basically the same thing.] 4.5.2 CE-to-CE IPsec In this scenario, the IPsec tunnels are set up between the CE devices. To a large extent, this scenario is the same as the site-to- site scenario; the fact that the cloud in between is an MPLS or other VPN is immaterial. 5. Other Problem Areas 5.1 Mobile IP/Wireless There are several facets to mobility, some which will be mentioned here. The issue of handling changing addresses will be discussed in another section. [A future version of this draft should try to identify and spell out the primary scenarios in more detail. But no doubt there are NATs somewhere in the picture ;-).] The general characteristics here include a desire for a small number of messages. Short messages are also desirable, but in some scenarios the # of messages is a much greater issue than the message size. Madson Expires - September 2002 [Page 20]
Son-of-IKE Requirements March 2002 5.1.1 Fast Handoff One area where IPsec may be used is in securing the access between the mobile node and the "wireless" (wireless here simply means "not wired", as opposed to any particular technology) access node (sometimes also known as "access router"), in lieu of a mechanism such as WEP. In some sense, the access node could be considered the equivalent of an RAS. The SEAMOBY working group is discussing issues associated with fast handoff between access nodes, which happens as the mobile node moves from one access node to another one. Depending upon the networking characteristics, in certain cases new connections can be established before existing ones terminate (make-before-break), while in others, the new connection cannot be done until after the existing ones terminate (break-before-make). [It is possible for the MN to acquire a new IP address during the handoff as well, and the handoff has to somehow also resolve the fact that the IP address of the access node is also changing.] One of the pieces to be handed-off would be IPsec context. The general sentiment is that setting up a new connection from scratch using either IKE or KINK has the problem of long latency and excessive signaling during handover [SEAM01]. [SEAM01] proposes a mechanism for transferring IPsec (but not IKE) state between access nodes. However, [SEAM02] claims that there are a lot of additional issues associated with context transfer, and the scenarios aren't as simple as claimed by the earlier document. Those authors present an alternative in [SEAM03]. It isn't clear from any of these documents what is considered an acceptable (total) delay for fast handoff, <<<but a mechanism that could rapidly establish connections with new systems could provide an alternative to the complexities associated with handing over security state between machines.>>> 5.1.2 Securing Binding Updates Since this is an issue under active discussion, this section does not attempt to fully reflect the consensus, if any. The initial philosophy was that Binding Updates - - notifications from the mobile node to the correspondent node that the mobile nodeÆs current address is changing -- would be secured using IPsec. While Madson Expires - September 2002 [Page 21]
Son-of-IKE Requirements March 2002 that is still a goal, the lack of a universal authentication and authorization infrastructure makes it a difficult one to achieve (although it would still be usable in smaller domains). The bulk of [Thom01] proposes a non-IPsec mechanism to work around the general problem. However, [Thom01] does state that even without a ubiquitous PKI, that at least some of the binding updates (e.g. between the home agent and the mobile node, which should already have exchanged certificates, or some such event, before the MN left itÆs home network) must be secured using IPsec. Ignoring the PKI issues associated with the above, it is assumed that the rate of binding update messages sent from a mobile node to its correspondent nodes is based upon the frequency of new IP address assignment (rate of movement of the mobile node, topology of the network that the MN is traveling through, etc.). Most likely fast setup will be desirable for this scenario. 5.2 Multiple and Changing Addresses: IPv6, SCTP and MobileIP (and NAT?) This section isnÆt discussing all of the associated requirements of the above protocols; it is focusing on the idea that there are multiple protocols which can support more than one address per endpoint and/or that have addresses that can (sometimes rapidly) change. IPv6 allows for multiple addresses per "interface"; the common one being in terms of scoped addresses: link-local, site-local, and global (with possibly more than once instance of any particular type). It is desirable that "connections" survive across renumbering (although it isn't clear whether that has been codified yet). In general, the frequency of renumbering should be low. SCTP allows for multiple IP addresses to be associated with an endpoint, where these addresses can be added/removed on the fly. The frequency of updates depends upon where/how SCTP is used. Mobile IP nodes may have to pick up different IP addresses while the node is moving (this is supposedly more common as the node enters a new administrative domain, or if the node is migrating from one media to another, e.g. 802.11 to cellular). The expectation is that any connections that the node had with its remote peer (e.g. CN) Madson Expires - September 2002 [Page 22]
Son-of-IKE Requirements March 2002 shouldn't terminate simply because of the use of a new IP address. [The connection to an access node is outside the scope of this section.] The frequency of renumbering is based upon the speed of travel and the topology of the mobile network(s) that the node is traveling through. NAT devices will force an address translation, and if the translation state in the NAT devices is allowed to age out, the next packet may force a different translation. While in (at least) most of these cases, address rollover can be accommodated by simply setting up new SOI/IPsec connections at the appropriate time, it does represent an expense. And if the frequency of change is high enough, the expense may be unacceptable. Apart from an I-D that discusses how to handle SCTP identifiers within SOI, and various and sundry NAT-related discussions, there hasn't been a lot of discussion in the IPsec WG about the general theme of <<<supporting multiple and/or changing addresses in the context of a single secure connection. While it may be too much to expect all of IPsec to handle changing addresses (e.g. changes to outside addresses), one possibility is to design SOI in such a way that a phase 1 could survive changes in addresses, but set up new phase 2 connections when addresses change. [How one would do this would obviously need further analysis.] The use of the two-phase approach here could help to alleviate the expense associated with setting up new connections in the face of renumbering. SOI should also accommodate sets of identifiers within a phase 2 exchange. This is needed for supporting SCTP. Also, the negotiation of a multi-entry phase 2 identifier can help to greatly reduce the number of IPsec tunnels between systems that need to secure multiple traffic flows in a similar manner.>>> 5.3 Delay-sensitive Applications Certain classes of traffic do not tolerate delay very well. Addressing the delay (or probably more the delay's jitter) associated with data flowing through an IPsec tunnel is outside the scope of this document, except to indicate that such delay-sensitive flows may need their own IPsec tunnels for QoS purposes, even if other IPsec Madson Expires - September 2002 [Page 23]
Son-of-IKE Requirements March 2002 tunnels exist between the two endpoints. These tunnels may also be secured differently, for example, using stream ciphers instead of block ciphers. There are also applications (e.g. VoIP) that are sensitive to the delay associated with connection setup, where setting up an IPsec tunnel is only one part of the total setup. KINK has a mechanism that attempts to address this issue. The IPsec WG should consider whether or not the SOI protocol should also consider this scenario. The overriding characteristic here would be for the protocol exchange to run as fast as possible, including performing the necessary authentication. [KINK also assumes that certain devices find it too expensive CPU-wise to run DH and RSA and play with certs.] In the case where the two nodes are running a single application (such as VoIP), it could be argued that the two-phase exchange is too expensive. However, if the nodes are running video in conjunction with voice, the cost of a phase 1 could be amortized over the two (or more) IPsec tunnels. 5.4 Other Users of IPsec The above list isnÆt intended to be an exhaustive one regarding every possible protocol that is considering using IPsec. The intent was to both call out primary scenarios, and identify other possible scenarios that have special requirements. One such example of "another user" is LMP, which is an optical link management protocol. [Rama01] describes the use of IPsec with LMP, but does not call out any special requirements. [One might assume that fast connection establishment would be a criterion for this protocol.] 6. General Operational Requirements 6.1 Scalability IPsec will be deployed in end systems, security gateways and RAS devices. Madson Expires - September 2002 [Page 24]
Son-of-IKE Requirements March 2002 The number of simultaneous SAs for an end system/client will be quite a bit smaller than the number of simultaneous SAs that need to be supported by an intermediate system SGW or RAS. While a low-end end system may need a lightweight mechanism in order to save precious memory/CPU/etc. for other functions, larger intermediate systems also need lightweight mechanism in order to sustain a reasonable number of connections. In other words, whatever the cost is for a single connection, that cost needs to be multiplied by several tens to thousands of times, depending upon the capacity of the intermediate system. This especially becomes important in the crash/restart scenario, where the intermediate system might get hit with a flurry of new negotiation requests from the remote IPsec peers. The expense of processing the new negotiation requests includes a cost based on number of messages and amount of processing. Costs associated with authentication also need to be accounted for in this calculation. At the same time that the system is processing a large number of new connect requests, it is also receiving traffic/control messages based on the IKE/IPsec SAs that had been in place prior to the crash. [The system should not use this traffic as hints to create new SAs, due to the DoS risk as discussed in a later section.] Besides the costs associated with connection setup, there are costs in terms of maintaining the connection. While connection maintenance has cost, it must be weighed against the cost of "no maintenance". One such example is the use of a dead peer detection mechanism; while it isnÆt cost-free, the operational costs associated with black- holing traffic will outweigh the costs of keeping the connection "alive". Costs associated with connection state are also important, whether in a low-end system with a small footprint or a large intermediate system supporting many connections. [Abob01] calls out a requirement for a small code and data footprint; the application may choose to terminate IPsec tunnels which arenÆt currently active, in order to save on resources. 6.2 Fast setup Madson Expires - September 2002 [Page 25]
Son-of-IKE Requirements March 2002 In many cases, fast setup is a desirable, but not critical goal. Its importance increases in the following scenarios: . RAS or SGW or other server terminating lots of connections . SGW crashing and restarting, requiring reestablishment of prior connections . Applications which are sensitive to delays in connection setup . Mobile nodes which frequently move o A sufficiently fast setup might be an alternative to complex IPsec context transfer for fast handoff scenarios. A definition of "fast"in this context means: . Optimal combination of "number of messages" and "computational expenditure". . Low delay where possible. For the scenarios that are delay sensitive, this means that the cost of the "other pieces" tied to the exchange, such as validation of authentication information (e.g. communicating with a PKI or Kerberos server or whatever), need to be kept in mind. 6.3 One-phase vs. two-phase exchange SOI will need to negotiate a protected tunnel for its own communication, as well as the IPSec protected tunnels. These tunnels may be negotiated simultaneously or sequentially, and the SOI tunnel may be either short term (for the duration of the IPSec tunnel negotiation) or long term. The decision on how this is handled affects: . Setup time, number of messages, delay o There is a requirement that a second IPSec tunnel between two peers be a less costly operation. . Separate tunnels between IPsec peers for different traffic flows . Non-contiguous addresses/subnets . QoS . Securing individual UDP sockets between L2TP LAC and LNS . Securing individual TCP sockets for IPS sessions . Flexibility o Negotiating the IPSec tunnel separately from the SOI tunnel may allow user authentication to be done under the protection of the SOI tunnel. . A long term SOI tunnel may ease sending notify messages, such as changing ID values, notifications of tunnel teardown, or keepalives. Without such a long term tunnel, the establishment of a short term tunnel may need to be very fast, or alternate mechanisms would need to be proposed. o Simplicity Madson Expires - September 2002 [Page 26]
Son-of-IKE Requirements March 2002 o Reducing the number of types of exchanges (e.g. Phase1/phase2 combined versus a separate phase 2) should be considered a benefit. An analysis is needed of what is appropriate to perform under the protection of a phase 1 exchange, besides rekeying events and error/notify messages. However, future additions of new phases to the protocol (ala phase 0, or phase 1.5, or "first phase 2") should be strongly discouraged. Shoehorning in new phases is the most difficult (if not impossible) thing to do cleanly, and it is difficult for any protocol design to accommodate such events in an extensible manner. Any issues associated with NAT traversal also need to be considered in the context of one vs. two phases. 7. Protocol Requirements 7.1 Protocol Interaction There needs to be an analysis of the types of protocols required in the SOI framework, and how they interact. For example, in the RAS scenario three protocols may be required in order to provide a useful solution: a legacy authentication protocol, a policy push protocol, and an IPsec negotiation protocol. Defining an order, and possible interactions between these protocols is necessary. Other scenarios will have similar predicaments. 7.2 Identity Identity cannot practically be based off of IP address, due to the prevalence of NAT devices in the network, and the use of dynamically- assigned IP addresses. <more detailed identity discussion to followà> 7.3 Interaction with NAT At some point in the future, NAT devices may disappear. Until that point, there is a need for SOI to interact with both IPsec-aware and non-IPsec aware NAT devices. Madson Expires - September 2002 [Page 27]
Son-of-IKE Requirements March 2002 Regardless of how addresses and identities, etc., may be handled in SOI, there is a known issue of NAT devices not handling fragments very well. 7.4 General Protocol Design Criteria Describing the scope of SOI is one of the primary goals of this document. To accomplish the goal, this document needs to (over time): . Identify key scenarios that need to be accommodated within the new design. . Describe what problem spaces SOI will (and won't) try to solve. No single protocol can solve the worldÆs problems. . Describe at a high level what needs to be done within the scope of the SOI protocol and what can be done via out-of-band mechanisms. [Any such mechanisms need to be defined in the same timeframe as SOI. Also, SOI must define the core requirements for the mechanism.] 7.4.1 Modularity It is also important to encourage the use of functional modularity within the protocol. Since in some scenarios the answer is to not mutate SOI to handle that problem set, there is a need for building blocks for others to use. Such well-defined functional components (where the definition includes what is required by the component and what the component will generate/perform) will allow other groups to pick up these components for their own use (e.g. picking up the components that meet their needs and use them in conjunction with components that they develop - - or borrow from elsewhere). Such functional modularity can also help in terms of understanding and evaluating the protocol. 7.4.2 Extensibility Another important protocol design goal is ease of extensibility. While it is important to maintain control over the scope of SOI, a protocol that is difficult to extend when necessary is effectively a dead protocol. SOI must be extensible to a practical degree. Extensibility has several facets to it: . Handling of new payloads, field values, exchanges, etc. o Mechanism to easily add such values. o Capability to flag these values in such a way that the receiver can understand how to process unrecognized values. Madson Expires - September 2002 [Page 28]
Son-of-IKE Requirements March 2002 o New values must be evaluated relative to ones currently existing. If the new values impact other parts of the existing protocol, this must be documented. . Mechanism for specifying variants that are very close to the base SOI protocol (e.g. what is currently provided via the ISAKMP DOI). Other active DOIs include o Group Domain of Interpretation (from MSEC) o MAPSEC DOI . Full hashing of SOI packets, in order to protect new values. . Analyze current fields to decide appropriate behavior for handling unrecognized values. SOI must spell out the behaviors. 7.4.3 Protocol Convergence Another important criteria for protocol design is the area of protocol convergence. It is important for a protocol to behave in a predictable manner, even in the face of retransmissions, lost packets, receipt of invalid packets or payloads, loss of communication between peers, the administrator reinitializing one or more security connections on one machine, etc. It is especially important that once an exchange starts, that the two SOI peers have a very similar view of the state of the connection between them. It is also important for the behaviors to be well understood, so that the implementers can make sure that they have implemented the protocol correctly. These needs can be addressed by various means: . Reasonably complete documentation of the protocol state machine o Analyze error conditions and document such analysis and document behaviors o Base protocol must specify all pieces needed to ensure convergence . Detecting and handling loss of communication with IKE peer . Fully spelled-out definition of rekeying behaviors (including error analysis) . "Guaranteed" notify/delete messages (this assumes continued communication between peers). . Documenting errors, especially if it results in a state change to the peer. Especially if it involves sending an error message to the peer. Documenting what the peer needs to do upon receipt of the error message. . Negotiation matching rules must be spelled out. . New (extension) specifications must perform and document analysis, including impact on existing protocol behaviors. When meditating on analyzing protocol convergence, it is recommended that [Spen01] be read. This document does a good job of describing Madson Expires - September 2002 [Page 29]
Son-of-IKE Requirements March 2002 some of the protocol issues associated with IKEv1; some of these items are still pertinent for SOI. An important scenario to be addressed in the analysis: state management needs to consider rapid disconnection/reconnection events, where one client disconnects and gives up its (outside, or phase 1) IP address, and the next client grabs that same address. 7.4.4 Simplicity Protocol simplicity is another goal. Besides getting rid of unnecessary fields/exchanges, etc., and keeping in mind the other protocol design goals above, simplicity can be addressed by other facets: . Ease of accomplishing a particular function (simple negotiation model as is seen in IKE may make it hard to successfully negotiate with a peer - - if successful connectivity is a goal -- without a fair amount of a-priori knowledge, because of the sheer number of possible combinations of what needs to be negotiated). o This can be alleviated by having fewer negotiable pieces/attributes o This can also be alleviated by creating and using so-called "negotiation suites", which represent well-known groupings of settings o This can also be alleviated by modifying the negotiation model to be something other than a "take it or leave it" proposition. 8. Policy Requirements 8.1 Provisioning and Management 8.1.1 Configuration In general, provisioning is viewed as æædefining a topology, generating a configuration, and distributing it to the network devicesÆÆ, and then æægenerating and distributing configuration updatesÆÆ. In the case of IPsec, this information includes security policy (criteria it will use to decide whether or not to communicate with a remote peer, and how that communication will be protected/authenticated/etc.). In order to support this in a heterogeneous environment, there is a need for: Madson Expires - September 2002 [Page 30]
Son-of-IKE Requirements March 2002 . A common distribution mechanism (which also addresses interacting with systems which have dynamically-assigned addresses). . A common representation model for configuration entities (understood by the devices performing the provisioning) and data (understood by the provisioned devices) . The model must also address the issues associated with changing addressing and dynamic policy instantiation associated with an application (for example, itÆs hard to secure an H.323 connection when it isnÆt possible to a-priori know the socket). These mechanisms are completely outside the scope of SOI. However, the distribution mechanism and representation model should be relatively lightweight in order to make it useful for smaller deployments. 8.1.2 Discovery To some people provisioning also represents dynamic mechanisms such as discovery. One such example is in the Provider-Provisioned VPN (PPVPN) space, which is working on dynamic mechanisms for discovery of VPN peers and signaling of which peers support which traffic. Two alternative proposals take slightly different approaches: . Using BGP extensions to communicate both peers and traffic flows supported. [Rose01] and [Decl01]. . Using DNS for discovering the VPN peers, and using signaling (as yet unspecified) between the peers to determine which peer supports what traffic [Luci01]. Mechanisms like the above are also outside the scope of SOI, but the IPSP WG should survey mechanisms that are being considered within other WGs while it considers the issue of policy discovery. [While it would be very beneficial for IPSP to develop a standardized discovery mechanism, such a mechanism wouldnÆt be required to be used in every scenario, for example, IPS has special mechanisms [Abob01] tailored for itÆs environment which should be used as appropriate.] 8.2 Expanding the set of selectors This section and the next one talk about the traffic flow descriptors (e.g. phase 2 IDs). To a large extent, the SPD is a form of a packet classifier. Unfortunately, what is negotiated via an IKE phase 2 exchange is a single instance of a traffic filter entry. Madson Expires - September 2002 [Page 31]
Son-of-IKE Requirements March 2002 This has multiple issues associated with it, but the biggest one is scaling. Even if there is a desire to secure multiple non-contiguous traffic flow descriptors between the same two IPsec endpoints using the same security characteristics, it is not possible to bind these all together; individual SAs must be negotiated for each flow descriptor. A pair of SGWs that are supporting a large number of traffic flows between them are forced to negotiate independent SAs. [While in certain cases separate SAs are desirable, there is no alternative with the current mechanisms.] The next section discusses a couple of alternative proposals for this issue. Adding to the list of possible selectors is also desirable. One such example is to include some QoS designators (e.g. Diff-Serve Code Point, etc.), so that separate IPsec tunnels could be created for separate QoS "levels". Another example is VPN tags. The PPVPN section had a discussion of using IPsec to encapsulate VPN-tagged packets so they could traverse a mixed cloud. [Rose01] talked about the VPN tagging and IPsec encapsulation as almost an atomic operation, but that won't be practical in certain deployments. Adding filtering on a VPN tag allows has two advantages: separation of tagging and IPsec, and requiring only a single SA bundle to be associated with the tag, instead of either separate SAs - - one per classical phase 2 ID filter, or attempting to negotiate and bind the various flows together with a single SA. 8.3 SPD traffic flow descriptors and dynamic policy There has also been a strong desire with some applications such as SCTP [Bell01], to support lists of traffic filters, where entries could be added to/removed from the list on the fly. In this model, the SA bundle instance may over time support different traffic flows. [SCTP also talks about changing phase 1 identifiers; that point will be covered in a later section.] This allows for a model where traffic flows that (should) have the same fate to share the same SA. Besides SCTP, there are other protocols that dynamically discover what needs to be secured via the protocol exchange itself. [RFC3193] discusses such a mechanism for L2TP, which requires the creation of new IPsec SAs in the case of "port floating". [Of course, in the case of address floating, both a new IKE and IPsec SA will probably be Madson Expires - September 2002 [Page 32]
Son-of-IKE Requirements March 2002 required, but thatÆs because the client is now talking to a different device.] Forcing each protocol that has "floating port" requirements to come up with their own mechanism to get around the fundamental constraint results in a lot of unnecessary complexity. [Sris01] introduces a general mechanism for constructing traffic filter lists, which also allows for individual filters to be added/removed from the list. Negative entries might also be useful in that they might help to reduce the size of the list (e.g. "secure everything between subnet A and subnet B except <foo>"). However, they would add to the complexity and should be approached with caution. Regardless of the mechanism used, there needs to be a determination of how to handle the case of "the responder is willing to accept only a subset of the initiatorÆs list". 8.4 Retaining SAs in face of address changes There are various scenarios where one end node may have its address change during operation. The most obvious one is MobileIP, where the rate of address change can be frequent. Another scenario is IPv6, where a node may have its global address renumbered at any time (at least thatÆs the philosophy). In the classical scenario, this tends to result in a rekeying of IKE and IPsec SAs between the mobile node and the systems it communicates with, even if nothing else has changed. Even worse, this renumbering can happen in the midst of a rekey, causing even more confusion. When the rate of address change is frequent enough, this rekey overhead can quickly become very expensive. While NAT can be considered another scenario in this class, it has the problem that the address change (NAT translation) goes on without the knowledge of the system that has its address translated. [Ignoring NAT discovery mechanisms being discussed for IKE.] Still, it would be highly desirable for any solution to address this as well. One possible idea has two (main) parts (meant for illustrative purposes only; no analysis has been done on this, not warranted for merchantability, etc., etc.): Madson Expires - September 2002 [Page 33]
Son-of-IKE Requirements March 2002 . SOI state management must keep connection state based on phase 1 identities, regardless of the IP addresses in use. . When a change to an IP address has been detected, it must be communicated to IPsec and/or SOI where appropriate. SOI as appropriate will notify the peer of the change. 8.5 Distribution of authentication information Another piece of the provisioning puzzle is making authentication information available in a scalable manner. [This was in a note somewhere, but I donÆt recall what the main point was supposed to be here.] 8.6 Authorization <text to be supplied laterà> 8.7 Additional "per-connection" policy This is more typical in the remote access scenarios, where the client needs additional information either during connection establishment or after it completes. This information can be grouped into two classes: . Applying to all IPsec tunnels for that connection o Inside address (assigned by RAS so it wonÆt have to NAT the traffic coming out of the tunnel). o Location of DHCP, etc. servers . Applying to specific IPsec tunnels for that connection: o QoS settings o Other? While there are various proposals, such as using MODECFG or DHCP to communicate this information, neither one of them is necessarily flexible enough. In order to subdivide the problem, the above mechanisms should be use to get the minimal initial information (e.g. inside address), and IPSP should consider another mechanism to communicate the other information from the server to the client. 9. Security Requirements 9.1 Key Agreement Madson Expires - September 2002 [Page 34]
Son-of-IKE Requirements March 2002 The fundamental premise of IKE was that it used Diffie-Hellman for key agreement, combined with a variant of the Station-to-Station protocol (by ???) for preventing man-in-the-middle attacks against the key agreement mechanism. This key, or "shared secret", would then be used in generating keying material to secure the IKE phase 1 and IPsec tunnels. The pluses of such a mechanism are that itÆs well understood and evaluated. The minus is that it is computationally expensive, making it an important issue in terms of defending against Denial of Service attacks. In some scenarios, it is also considered to be too expensive in general - - such a philosophy has resulted in the specification of KINK. Still, the current sentiment is that this represents the best mechanism for key agreement. 9.2 Key Generation The base protocol spec must spell out the core key generation requirements, including discussing such issues as "key strength", and requirements for the amount of entropy associated with various inputs. It should spell out in great detail the various issues associated with key expansion. The core requirements, along with the algorithm-specific requirements (e.g. a specification of an instance of a PRF), should be sufficient for someone unfamiliar with the protocols to perform an evaluation. 9.3 Authentication IKE allows for various authentication mechanisms. However, their specifications are incomplete (such as the one associated with the use of X.509 certificates). Another complaint has been that the specification is biased towards X.509 w/PKI and discourages the development/deployment/use of other mechanisms. The core draft should spell out the requirements for authentication as it affects SOI, such as how the authentication values do/donÆt fold into the key generation process. The core draft should also document one least common denominator authentication mechanism (the current sentiment is to use RSA key pairs and distribute the public key to the peer systems via an out- of-band mechanism). This core mechanism must be fully specified, including discussing distribution/verification of the authenticator value, how this value is used in the exchange, authentication validation rules, and other protocol support needed for this mechanism. Madson Expires - September 2002 [Page 35]
Son-of-IKE Requirements March 2002 Each other mechanism is in a separate draft, and must include a full specification of the protocol and handling requirements. For example, "if you want to do X.509 certificates, you must support these payloads, you must support these encoding formats, you must send these payloads at this point in the exchange, you must send certificate chains that look like this, you must be able to support certificate path discovery (or not), you must feed this blob into SKEYID generation this way, you must enforce certificate lifetimes and crls, the lifetime of a phase 1 SA cannot exceed the lifetime of the certificate that is used to authenticate the exchange (or notà), etcà.". [This previous list is an illustration, not a statement of requirements.]. The document should also spell out if the particular authentication mechanism implies a particular trust model. Ideally, the set of possible mechanisms should not be constrained to the ones that can fit into the number of messages within the normal SOI exchange. Over time, there has also been confusion with respect to user-vs- machine authentication via IKE. Over time, it seems that the general consensus has been that IKE provides machine authentication; part of it has to do with the wide variety of user authentication mechanisms, and whether or not they could be accommodated within IKE phase 1. If this model holds, there may be a need for user authentication as a part of SOI (and not just in the remote access scenario). At a minimum, the base draft should specify that SOI supplies machine- level authentication. Another area of consideration involves asymmetric authentication. For example, in a remote access scenario it might be desirable to have the server authenticate to the client using a certificate, while the client might authenticate to the server using a legacy authentication mechanism. 9.4 Resistance to Denial-of-Service Attacks While it is difficult to design a protocol that is completely secure from DoS attacks against it (even ignoring the attack that simply floods the media preventing the system from sending/receiving traffic), there are certain things that should be done to alleviate the vulnerability for DoS attacks. As a rule, the primary tenants of DoS resistance involve making the attacker do a certain amount of work before the system under attack has to do any real work. The system under attack should not be forced Madson Expires - September 2002 [Page 36]
Son-of-IKE Requirements March 2002 to keep much state, or to perform much processing, until it determines that the peer system is alive and can sustain a protocol exchange. There are various mechanisms proposed to address these issues; these include: . Stateless cookies: requested by the responder, this forces the requestor to sustain an exchange (the equivalent in IKE would be that the attacker would have to do more than simply spewing out a whole bunch of MM1 packets). o Should this be mandatory (a part of every exchange) or optional (on demand of the responder)? . No reliance on unauthenticated messages that would force a change in state. [Kryw01] discusses the scenario of relying on unauthenticated notify messages, such as "invalid spi", to decide to tear down existing SAs and force establishment of new ones. 9.5 Resistance to Replay Attacks The protocol must be resistant against replay attacks, without requiring that the node keep large amounts of state (which can be expensive both memory and processing-wise). IKE had various proposals for addressing the issue (mostly centered around message IDs), which may or may not be appropriate for SOI. 9.6 Resistance to downgrade attacks The protocol must resist against an attacker trying to downgrade the security of the exchange. IKE addressed this through including the proposals within the data that was hashed. 9.7 Implementation Recommendations [for lack of a better term]. There are certain design tradeoffs that can be made in an implementation, commonly to improve performance and/or to "improve" certain "behaviors". Some of these tradeoffs actually have security implications. While it is difficult to guess what any possible implementer might do, one of the outputs of a security analysis should be a list of the possible implications, and a set of implementation recommendations. 9.8 Use of Negotiation Suites Madson Expires - September 2002 [Page 37]
Son-of-IKE Requirements March 2002 This has been an idea that periodically floats to the surface. The general idea is that there are too many parameters (attributes) for negotiation. The number of various combinations is huge. Also, since anything can match with anything else, it is hard for folks to evaluate the security properties. [In fact, the original suggestion of suites came from the cryptographic community, in order to make the feat of analysis feasible.] While reducing the number of negotiable attributes can help a great deal here, the idea of negotiation suites can still be helpful in addressing the analysis issue. However, in its security requirements discussion, IPS [Abob01] is requiring that every single security mechanism must be able to be "turned off" independently. Such an operational requirement would be a counter-argument to the use of suites. 9.9 Identity Hiding In general, identity hiding of both peers is considered desirable. In practice, there may be scenarios where this isn't feasible. According to [Kauf01], "whoever admits identity second can be protected from active attacker". If the responder reveals his identity first, he can be vulnerable to what is known as a "polling attack", where the attacker is trolling for systems that will reveal their identities. However, if the initiator reveals his identity first, he can be vulnerable to being "tricked" into leaking his identity to a party that it otherwise would have no intention of doing so. Also, in certain scenarios, such as where a RAS supplied by a service provider is fronting several VPNs, it is necessary for the client to provide some sort of identifying information early enough in the exchange in order for the RAS to know which identity and which policy to use when interacting with that client. In many cases, this information does not need to be the client identity, but it should be something that the responder can use to select itÆs own identity/policy to use when communicating with the client. At a minimum, the protocol needs to protect against passive attackers when identity hiding is necessary. 9.10 Plausible Deniability [Kauf01] discusses this concept, where the data was never signed, but a third party may be able to prove that the conversation took place Madson Expires - September 2002 [Page 38]
Son-of-IKE Requirements March 2002 between the two parties. [How much of this is solved via identity hiding?] 9.11 Protection of Key Management Messages IKE had partial authentication protection for key management messages, in that it only hashed certain fields. The primary problem in the base protocol was that the Commit bit was not protected, which an attacker could exploit. The more serious problem is that there was no means of securing any new payloads/fields, regardless of their security criticality. While hashing fewer fields could be considered ææfasterÆÆ, the gain in hash speed was offset by the processing complexity. SOI MUST protect all fields in all messages via the hash. 9.12 Support for PFS There has been this long-running sentiment that PFS is a requirement for security protocols. Certain proposals in the IETF's Security Area in the past have been shot down because they didnÆt have this characteristic. The classical definition of PFS in the IETF is that both peers generate new D-H pairs and calculate a new shared secret. In IKE, there exists PFS for phase 1 (each new IKE exchange expects a new shared secret) and optionally for phase 2 (where each new phase 2 could also calculate a new shared secret to be combined with the phase 1 shared secret). One of the recent items for consideration in front of the working group is whether or not this definition of PFS could be changed for SOI. At the time being, this seems to have appeal, but no strong consensus. 10. Security Considerations This document describes both requirements and other design considerations that should be taken into account for developing a follow-on protocol to IKE. The primary goal of the considerations is to provide guidance for a protocol that is more easily understood/ evaluated in terms of security properties and behaviors. Madson Expires - September 2002 [Page 39]
Son-of-IKE Requirements March 2002 11. Acknowledgements Thanks to the various members of the IPsec WG whose comments over a long period of time have contributed to the thinking that resulted in this document. Thanks also to Brian Weis, Jan Vilhuber and Scott Fluhrer for the various discussions and making many helpful suggestions. 12. References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [Abob01] Aboba, et. al, "Securing IP Block Storage Protocols", draft- ietf-ips-security-09.txt, work in progress. [Bell01] Bellovin, et. al, "On the use of SCTP with IPsec", draft- ietf-ipsec-sctp-03.txt, work in progress. [Decl01] De Clercq, et. al, "BGP/IPsec VPN", draft-declercq-bgp- ipsec-vpn-01.txt, work in progress. [Kauf01] Kaufman, Charlie, "Engineering Trade-offs in Authentication Protocols", slides from IETF-53 presentation. [Kryw01] Krywaniuk, A. "Security Properties of the IPsec Protocol Suite", draft-ietf-ipsec-properties-01.txt, work in progress [Luci01] Luciani, et. al, "Using DNS for VPN Discovery", draft- luciani-ppvpn-vpn-discovery-01.txt [Rama01] Ramamoorthi and Zinin, "LMP Security Mechanism", draft- sankar-lmp-sec-00.txt, work in progress. [Rose01] Rosen, et. al, "Use of PE-PE IPsec in RFC2547 VPNs", draft- ietf-ppvpn-ipsec-2547-01.txt, work in progress. [SEAM01] Hamer and Kosinski, "IPSec Context Transfer", draft-hk- seamoby-ct-ipsec-00.txt, work in progress. [SEAM02] Gopal, Krishnamurthi and Sengodan, "Issues in IPSec Context Transfer", draft-gopal-seamoby-ipsecctxt-issues-00.txt, work in progress. [SEAM03] Gopal, et. al, "IPsec Context Transfer", draft-gopal- seamoby-ipsec-relocate-00.txt, work in progress Madson Expires - September 2002 [Page 40]
Son-of-IKE Requirements March 2002 [Spen01] Spencer and Redelmeier, "IKE Implementation Issues", draft- spencer-ipsec-ike-implementation-01.txt, work in progress [Sris01] Srisuresh and Vilhuber, "Policy Extensions to IKE", draft- srisuresh-ike-policy-extensions-00.txt, work in progress. [Thom01] Thomas, M., "Binding Updates Security", draft-thomas- mobileip-bu-sec-00.txt, work in progress 13. Editor's Address Cheryl Madson <cmadson@cisco.com> Cisco Systems, Inc. The IPsec working group can be contacted through the chairs: Barbara Fraser <byfraser@cisco.com> Cisco Systems, Inc. Ted T'so <tytso@mit.edu> Massachusetts Institute of Technology Madson Expires - September 2002 [Page 41]
