Network Working Group S. Frankel Internet Draft NIST Obsoletes: 2411 (if approved) S. Krishnan Intended Status: Informational Ericsson Expires: August 2009 March 6, 2009 IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap <draft-ietf-ipsecme-roadmap-01.txt> Status of this Memo Distribution of this memo is unlimited. This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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/1id-abstracts.html. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 6, 2009. Copyright and License Notice Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Frankel & Krishnan Expires August 2009 [Page 1]
Internet Draft IPsec/IKE Roadmap March 6, 2009 Abstract Over the past few years, the number of RFCs that define and use IPsec and IKE has greatly proliferated. This is complicated by the fact that these RFCs originate from numerous IETF working groups: the original IPsec WG, its various spin-offs, and other WGs that use IPsec and/or IKE to protect their protocols' traffic. This document is a snapshot of IPsec- and IKE-related RFCs. It includes a brief description of each RFC, along with background information explaining the motivation and context of IPsec's outgrowths and extensions. It obsoletes the previous IPsec Document Roadmap [RFC2411]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. IPsec/IKE Background Information . . . . . . . . . . . . . . . . 4 2.1. Interrelationship of IPsec/IKE Documents . . . . . . . . . 4 2.2. Versions of IPsec . . . . . . . . . . . . . . . . . . . . . 5 2.2.1. Differences between "old" IPsec (IPsec-v2) and "new" IPsec (IPsec-v3) . . . . . . . . . . . . . . . . 6 2.3. Versions of IKE . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1. Differences between IKEv1 and IKEv2 . . . . . . . . . 7 2.4. IPsec and IKE IANA Registries . . . . . . . . . . . . . . . 8 3. IPsec Documents . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Base Documents . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. "Old" IPsec . . . . . . . . . . . . . . . . . . . . . . 8 3.1.2. "New" IPsec . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. MIBs . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Additions to IPsec . . . . . . . . . . . . . . . . . . . . 11 3.5. General Considerations . . . . . . . . . . . . . . . . . . 12 4. IKE Documents . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Base Documents . . . . . . . . . . . . . . . . . . . . . . 13 4.1.1. IKEv1 . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.2. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Additions and Extensions . . . . . . . . . . . . . . . . . 14 4.2.1. Peer Authentication Methods . . . . . . . . . . . . . . 15 4.2.2. Certificate Contents and Management . . . . . . . . . . 15 4.2.3. Dead Peer Detection . . . . . . . . . . . . . . . . . . 16 4.2.4. Remote Access . . . . . . . . . . . . . . . . . . . . . 16 5. Cryptographic Algorithms and Suites . . . . . . . . . . . . . . 17 5.1. Algorithm Requirements . . . . . . . . . . . . . . . . . . 17 5.2. Encryption Algorithms . . . . . . . . . . . . . . . . . . . 18 5.3. Integrity-Protection (Authentication) Algorithms . . . . . 21 5.3.1. General Considerations . . . . . . . . . . . . . . . . 23 5.4. Combined Mode Algorithms . . . . . . . . . . . . . . . . . 23 5.4.1. General Considerations . . . . . . . . . . . . . . . . 25 Frankel & Krishnan Expires August 2009 [Page 2]
Internet Draft IPsec/IKE Roadmap March 6, 2009 5.5. Pseudo-Random Functions (PRFs) . . . . . . . . . . . . . . 25 5.6. Cryptographic Suites . . . . . . . . . . . . . . . . . . . 26 5.7. Diffie-Hellman Algorithms . . . . . . . . . . . . . . . . . 26 6. IPsec/IKE for Multicast . . . . . . . . . . . . . . . . . . . . 28 7. Outgrowths of IPsec/IKE . . . . . . . . . . . . . . . . . . . . 30 7.1. IPComp (Compression) . . . . . . . . . . . . . . . . . . . 31 7.2. IKEv2 Mobility and Multihoming (MobIKE) . . . . . . . . . . 31 7.3. Better-than-Nothing Security (Btns) . . . . . . . . . . . . 32 7.4. Kerberized Internet Negotiation of Keys (Kink) . . . . . . 32 7.5. IPsec Secure Remote Access (IPSRA) . . . . . . . . . . . . 33 7.6. IPsec Keying Information Resource Record (IPsecKEY) . . . . 33 8. Other Protocols that use IPsec/IKE . . . . . . . . . . . . . . . 33 8.1. Mobile IP (MIPv4 and MIPv6) . . . . . . . . . . . . . . . . 33 8.2. Open Shortest Path First (OSPF) . . . . . . . . . . . . . . 36 8.3. Host Identity Protocol (HIP) . . . . . . . . . . . . . . . 36 8.4. Extensible Authentication Protocol (EAP) Method Update (EMU) . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 8.5. Stream Control Transmission Protocol (SCTP) . . . . . . . . 37 8.6. Fibre Channel . . . . . . . . . . . . . . . . . . . . . . . 37 8.7. Robust Header Compression (ROHC) . . . . . . . . . . . . . 38 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 38 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 38 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 11.1. Normative References . . . . . . . . . . . . . . . . . . . 38 11.2. Informative References . . . . . . . . . . . . . . . . . . 38 Frankel & Krishnan Expires August 2009 [Page 3]
Internet Draft IPsec/IKE Roadmap March 6, 2009 1. Introduction IPsec is a suite of protocols that provides security to Internet communications at the IP layer. The most common current use of IPsec is to provide a Virtual Private Network (VPN), either between two locations (gateway-to-gateway) or between a remote user and an enterprise network (host-to-gateway); it can also provide end-to-end, or host-to-host, security. IPsec is also used by other Internet protocols (e.g. MIPv6) to protect some or all of their traffic. In addition to the base documents for IPsec and IKE, there are numerous RFCs that reference, extend, and in some cases alter the core specifications. This document is an attempt to list and briefly describe those RFCs, providing context and rationale where indicated. The title of each RFC is followed by a letter that indicates its category in the RFC series [RFC2026], as follows: o S: Standards Track (Proposed Standard, Draft Standard, or Standard) o E: Experimental o B: Best Current Practice o I: Informational For each RFC, the publication date is also given. The usage of terms in this document conforms to definitions in [RFC4949]. 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 [RFC2119]. 2. IPsec/IKE Background Information 2.1. Interrelationship of IPsec/IKE Documents The main documents describing the set of IPsec protocols are divided into seven groups. This is illustrated in Figure 1. There is a main Architecture document which broadly covers the general concepts, security requirements, definitions, and mechanisms defining IPsec technology. There are an ESP Protocol document and an AH Protocol document which cover the packet format and general issues regarding the respective protocols. The "Encryption Algorithm" document set, shown on the Frankel & Krishnan Expires August 2009 [Page 4]
Internet Draft IPsec/IKE Roadmap March 6, 2009 left, is the set of documents describing how various encryption algorithms are used for ESP. The "Combined Algorithm" document set, shown in the middle, is the set of documents describing how various combined mode algorithms are used to provide both encryption and integrity-protection for ESP. The "Integ-Protection Algorithm" document set, shown on the right, is the set of documents describing how various integrity-protection algorithms are used for both ESP and AH. The "IKE Documents", shown at the bottom, are the documents describing the IETF standards-track key management schemes. +--------------+ | Architecture | +--------------+ v v +<-<-<-<-<-<-<-<-+ +->->->->->->->->+ v v +----------+ +----------+ | ESP | | AH | | Protocol | | Protocol | +----------+ +----------+ v v v v v +->->->->->->->->+->->->->->->->->+ v v v v v v v v v v v v v v v +------------+ +-----------+ +----------------+ v v | +------------+ | +------------+ | +----------------+ v v | | Encryption | | | Combined | | |Integ-Protection| v v +-| Algorithm | +-| Algorithm | +-| Algorithm | v v +------------+ +------------+ +----------------+ v v v v v v v v v v v +>->->->-+->->->->->->->->->--<-<-<-<-<-<-<-<-<-+-<-<-<-<-+ ^ ^ +------------+ | IKE | | Protocol | +------------+ 2.2. Versions of IPsec Two versions of IPsec can currently be found in implementations. The "new" IPsec (referred to as IPsec-v3 in this document) obsoleted the "old" IPsec (referred to as IPsec-v2 in this document); however, IPsec-v2 is still commonly found in operational use. In this document, when the unqualified term IPsec is used, it pertains to Frankel & Krishnan Expires August 2009 [Page 5]
Internet Draft IPsec/IKE Roadmap March 6, 2009 both versions of IPsec. An earlier version of IPsec (defined in RFCs 1825-1829), obsoleted by IPsec-v2, is not covered in this document. 2.2.1. Differences between "old" IPsec (IPsec-v2) and "new" IPsec (IPsec-v3) IPsec-v3 incorporates "lessons learned" from implementation and operational experience with IPsec-v2 and its predecessor, IPsec-v1. Knowledge was gained about the barriers to IPsec deployment, the scenarios in which IPsec is most effective, and requirements that needed to be added to IPsec to facilitate its use in other protocols. In addition, the documentation for IPsec-v3 clarifies and expands details that were underspecified or ambiguous in IPsec-v2. Changes to the architecture document [RFC4301] include: o More detailed descriptions of IPsec processing, both unicast and multicast, and the interactions among the various IPsec databases o In IPsec-v2, an SA (Security Association) is uniquely identified by a combination of the SPI (Security Parameters Index), protocol (ESP or AH), and destination address. In IPsec-v3, a unicast SA is uniquely identified by the SPI and, optionally, by the protocol; a multicast SA is identified by a combination of the SPI and the destination address and, optionally, the source address. o More flexible SPD (Security Policy Database) selectors, including ranges of values and ICMP message types as selectors o Decorrelated (order-independent) SAD (Security Association Database) replaced the former ordered SAD o Added extended sequence numbers (ESNs) o Mandatory algorithms defined in standalone document o AH [RFC4302] is mandatory-to-implement (MUST) in IPsec-v2, optional (MAY) in IPsec-v3 Changes to ESP [RFC4303] include: o Added combined mode algorithms, necessitating changes to packet format and processing o NULL authentication, mandatory (MUST) in ESP-v2, is optional (MAY) in ESP-v3 Frankel & Krishnan Expires August 2009 [Page 6]
Internet Draft IPsec/IKE Roadmap March 6, 2009 2.3. Versions of IKE Two versions of IKE can currently be found in implementations. The "new" IKE (generally referred to as IKEv2) obsoleted the "old" IKE (generally referred to as IKEv1); however, IKEv1 is still commonly found in operational use. In this document, when the unqualified term IKE is used, it pertains to both versions of IKE. 2.3.1. Differences between IKEv1 and IKEv2 As with IPsec-v3, IKEv2 incorporates "lessons learned" from implementation and operational experience with IKEv1. Knowledge was gained about the barriers to IKE deployment, the scenarios in which IKE is most effective, and requirements that needed to be added to IKE to facilitate its use in other protocols as well as in general-purpose use. The documentation for IKEv2 replaces multiple, at time contradictory documents, with a single document; it also clarifies and expands details that were underspecified or ambiguous in IKEv1. Once an IKE negotiation is successfully completed, the peers have established two pairs of one-way (inbound and outbound) SAs. The first SA, the IKE SA, is used to protect IKE traffic. The second SA provides IPsec protection to data traffic between the peers and/or other devices for which the peers are authorized to negotiate. It is called the IPsec SA in IKEv1 and, in the IKEv2 RFCs, it is referred to variously as a CHILD_SA, a child SA, and an IPsec SA. This document uses the term "IPsec SA". Changes to IKE include: o Multiple alternate exchange types replaced by a single, shorter exchange o Streamlined negotiation format to avoid combinatorial bloat for multiple proposals o Protects responder from committing significant resources to the exchange until the initiator's existence and identity are confirmed o Reliable exchanges: Every request expects a response o Protection of IKE messages based on ESP, rather than a method unique to IKE o Add traffic selectors: distinct from peer IDs and more flexible Frankel & Krishnan Expires August 2009 [Page 7]
Internet Draft IPsec/IKE Roadmap March 6, 2009 o Support of EAP-based authentication methods and asymmetric authentication (i.e., initiator and responder can use different authentication methods) 2.4. IPsec and IKE IANA Registries Numerous IANA registries contain values that are used in IPsec, IKE and related protocols. They include: o IKE Attributes (http://www.iana.org/assignments/ipsec-registry): values used during IKEv1 Phase 1 exchanges, defined in [RFC2409] o "Magic Numbers" for ISAKMP Protocol (http://www.iana.org/assignments/isakmp-registry): values used during IKEv1 Phase 2 exchanges, defined in [RFC2407], [RFC2408] and numerous other cryptographic algorithm RFCs o IKEv2 Parameters (http://www.iana.org/assignments/ikev2-parameters): values used in IKEv2 exchanges, defined in [RFC4306] and numerous other cryptographic algorithm RFCs o Cryptographic Suites for IKEv1, IKEv2, and IPsec (http://www.iana.org/assignments/crypto-suites): names of cryptographic suites in [RFC4308] and [RFC4869] 3. IPsec Documents 3.1. Base Documents IPsec protections are provided by two extension headers: the Encapsulating Security Payload (ESP) Header and the Authentication Header (AH). There are 3 base documents: one that describes the IP security architecture, and one for each of the IPsec headers. 3.1.1. "Old" IPsec o RFC 2401, Security Architecture for the Internet Protocol (S, Nov. 1998) [RFC2401] specifies the the mechanisms, procedures and components required to provide security services at the IP layer. It also describes their interrelationship, and the general processing required to inject IPsec protections into the network architecture. The components include: Frankel & Krishnan Expires August 2009 [Page 8]
Internet Draft IPsec/IKE Roadmap March 6, 2009 - SA (Security Association): a one-way (inbound or outbound) agreement between two communicating peers that specifies the IPsec protections to be provided to their communications. This includes the specific security protections, cryptographic algorithms, and secret keys to be applied, as well as the specific types of traffic to be protected. - SPI (Security Parameters Index): a value that, together with the Destination Address and security protocol (AH or ESP), uniquely identifies a single SA - SAD (Security Association Database): each peer's SA repository. The RFC describes how this database functions (SA lookup, etc.) and the types of information it must contain to factilitate SA processing; it does not dictate the format or layout of the database. SAs can be established in either transport mode or tunnel mode (see below). - SPD (Security Policy Database): an ordered database that expresses the security protections to be afforded to different types and classes of traffic. The 3 general classes of traffic are: traffic to be discarded, traffic that is allowed without IPsec protection, and traffic that requires IPsec protection. The RFC describes general inbound and outbound IPsec processing; it also includes details on several special cases: packet fragments, ICMP messages, and multicast traffic. o RFC 2402, IP Authentication Header (S, Nov. 1998) [RFC2402] defines the Authentication Header (AH), which provides integrity protection; it also provides data origin authentication, access control, and, optionally, replay protection. A transport mode AH SA, used to protect peer-to-peer communications, protects upper-layer data, as well as those portions of the IP header that do not vary unpredictably during packet delivery. A tunnel mode AH SA can be used to protect gateway-to-gateway or host-to-gateway traffic; it can optionally be used for host-to-host traffic. This class of AH SA protects the inner (original) header and upper-layer data, as well as those portions of the outer (tunnel) header that do not vary unpredictably during packet delivery. Because portions of the IP header are not included in the AH calculations, AH processing is more complex than ESP processing. AH also does not work in the presence of Network Address Translation (NAT). Unlike IPsec-v3, IPsec-v2 classifies AH as mandatory-to-implement. o RFC 2406, IP Encapsulating Security Payload (ESP) (S, Nov. 1998) Frankel & Krishnan Expires August 2009 [Page 9]
Internet Draft IPsec/IKE Roadmap March 6, 2009 [RFC2406] defines the IP Encapsulating Security Payload (ESP), which provides confidentiality (encryption) and/or integrity protection; it also provides data origin authentication, access control, and, optionally, replay and/or traffic analysis protection. A transport mode ESP SA protects the upper-layer data, but not the IP header. A tunnel mode ESP SA protects the upper-layer data and the inner header, but not the outer header. 3.1.2. "New" IPsec o RFC 4301, Security Architecture for the Internet Protocol (S, Dec. 2005) [RFC4301] updates [RFC2401], including a more complete and detailed processing model. The most notable changes are detailed above in Section 2.2.1. IPsec-v3 processing incorporates an additional database: - PAD (Peer Authorization Database): contains information necessary to conduct peer authentication, providing a link between IPsec and the key management procotol (e.g. IKE) o RFC 4302, IP Authentication Header (S, Dec. 2005) [RFC4302] updates [RFC2402]. Unlike IPsec-v2, IPsec-v3 classifies AH as optional. o RFC 4303, IP Encapsulating Security Payload (ESP) (S, Dec. 2005) [RFC4303] updates [RFC2406]. The most notable changes are detailed above in Section 2.2.1. 3.2. Policy The IPsec Policy Working Group (ipsp) originally planned an RFC that would allow entities with no common Trust Anchor and no prior knowledge of each others' security policies to establish an IPsec-protected connection. The solutions that were proposed for gateway discovery and security policy negotiation proved to be overly complex and fragile, in the absence of prior knowledge or compatible configuration policies. o RFC 3586, IP Security Policy (IPSP) Requirements (S, Aug. 2003) [RFC3586] describes the functional requirements of a generalized IPsec policy framework, that could be used to discover, negotiate and manage IPsec policies. Frankel & Krishnan Expires August 2009 [Page 10]
Internet Draft IPsec/IKE Roadmap March 6, 2009 o RFC 3585, IPsec Configuration Policy Information Model (S, Aug. 2003) As stated in [RFC3585], "This document presents an object-oriented information model of IP Security (IPsec) policy designed to facilitate agreement about the content and semantics of IPsec policy, and enable derivations of task-specific representations of IPsec policy such as storage schema, distribution representations, and policy specification languages used to configure IPsec-enabled endpoints." This RFC has not been widely adopted. 3.3. MIBs Over the years, several MIB-related Internet Drafts were proposed for IPsec and IKE, but only one progressed to RFC status. o RFC 4807, IPsec Security Policy Database Configuration MIB (S, Mar. 2007) [RFC4807] defines a MIB module that can be used to configure the SPD of an IPsec device. This RFC has not been widely adopted. 3.4. Additions to IPsec o RFC 3947, Negotiation of NAT-Traversal in the IKE (S, Jan. 2005) [RFC3947] enables IKEv1 to detect whether there are any NATs between the negotiating peers, and whether both peers support NAT traversal. It also describes how IKEv1 can be used to negotiate the use of UDP encapsulation of ESP packets for the IPsec SA. For IKEv2, this capability is described in [RFC4306]. o RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) (S, Dec. 2005) The use of ESNs allows IPsec to use 64-bit sequence numbers for replay protection, but to send only 32 bits of the sequence number in the packet, enabling shorter packets and avoiding a re-design of the packet format. The larger sequence numbers allow an existing IPsec SA to be used for larger volumes of data. [RFC4304] describes an extension to IKEv1 to negotiate the use of ESNs for IPsec-v3 SAs. For IKEv2, this capability is described in [RFC4306]. o RFC 3948, UDP Encapsulation of IPsec ESP Packets (S, Jan. 2005) Frankel & Krishnan Expires August 2009 [Page 11]
Internet Draft IPsec/IKE Roadmap March 6, 2009 [RFC3948] defines how to encapsulate ESP packets in UDP packets to enable the traversal of NATs that discard packets with protocols other than UDP or TCP. This makes it possible for ESP packets to pass through the NAT device without requiring any change to the NAT device itself. The use of this solution is negotiated by IKE, as described in [RFC3947] for IKEv1 and [RFC4306] for IKEv2. o RFC 4891, Using IPsec to Secure IPv6-in-IPv4 Tunnels (I, May 2007) [RFC4891] describes how to use IKE and transport-mode IPsec to provide security protection to manually-configured IPv6-in-IPv4 tunnels. This document uses standard IKE and IPsec, without any new extensions. It does not apply to tunnels that are initiated in an automated manner (e.g., 6to4 tunnels [RFC3056]). o RFC 3884, Use of IPsec Transport Mode for Dynamic Routing (I, Sep. 2004) [RFC3884] describes the use of transport-mode IPsec to secure IP-in-IP tunnels, which constitute the links of a multi-hop, distributed virtual network (VN). This allows the traffic to be dynamically routed via the VN's trusted routers, rather than routing all traffic through a statically-routed IPsec tunnel. This RFC has not been widely adopted. o draft-ietf-ipsecme-traffic-visibility, Wrapped ESP for Traffic Visibility (S) ESP, as defined in [RFC4303], does not allow a network device to easily determine whether protected traffic that is passing through the device is encrypted, or only integrity-protected (referred to as ESP-NULL packets). This document extends ESP to provide explicit notification of integrity-protected packets, and extends IKEv2 to negotiate this capability between the IPsec peers. o draft-kivinen-ipsecme-esp-null-heuristics, Heuristics for Detecting ESP-NULL packets (I) This document offers an alternative approach to differentiating between ESP-encrypted and ESP-NULL packets, through packet inspection. This method does not require any change to IKEv2 or ESP. 3.5. General Considerations o RFC 3715, IPsec-Network Address Translation (NAT) Compatibility Requirements (I, Mar. 2004) Frankel & Krishnan Expires August 2009 [Page 12]
Internet Draft IPsec/IKE Roadmap March 6, 2009 [RFC3715] "describes known incompatibilities between NAT and IPsec, and describes the requirements for addressing them." This is a critical issue, since IPsec is frequently used to provide VPN access to the corporate network for telecommuters, and NATs are widely deployed in home gateways, hotels, and other access networks typically used for remote access. o RFC 5406, Guidelines for Specifying the Use of IPsec Version 2 (B, Feb. 2009) [RFC5406] offers guidance to protocol designers on how to ascertain whether IPsec is the appropriate security mechanism to provide an interoperable security solution for the protocol. If this is not the case, it advises against attempting to define a new security protocol; rather, it suggests using another standards-based security protocol. 4. IKE Documents 4.1. Base Documents 4.1.1. IKEv1 o RFC 2409, The Internet Key Exchange (IKE) (S, Nov. 1998) This document defines a key exchange protocol that can be used to negotiate authenticated keying material for SAs. This document implements a subset of the Oakley protocol in conjunction with ISAKMP to obtain authenticated keying material for use with ISAKMP, and for other security associations such as AH and ESP for the IETF IPsec DOI. While historically IKEv1 was created by combining two security protocols, ISAKMP and Oakley, in practice the combination (along with the IPsec DOI) has commonly been viewed as one protocol, IKEv1. The protocol's origins can be seen in the organization of the documents that define it. o RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP) (S, Nov. 1998) This document defines procedures and packet formats to establish, negotiate, modify and delete Security Associations (SAs). It is intended to support the negotiation of SAs for security protocols at all layers of the network stack. ISAKMP can work with many different key exchange protocols, each with different security properties. o RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP (S, Nov. 1998) Frankel & Krishnan Expires August 2009 [Page 13]
Internet Draft IPsec/IKE Roadmap March 6, 2009 Within ISAKMP, a Domain of Interpretation is used to group related protocols using ISAKMP to negotiate security associations. Security protocols sharing a DOI choose security protocol and cryptographic transforms from a common namespace and share key exchange protocol identifiers. This document defines the Internet IP Security DOI (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses ISAKMP to negotiate security associations. o RFC 2412, The OAKLEY Key Determination Protocol (I, Nov. 1998) [RFC2412] describes a key establishment protocol using which two authenticated parties can agree on secure and secret keying material. The Oakley protocol describes a series of key exchanges-- called "modes"-- and details the services provided by each (e.g. perfect forward secrecy for keys, identity protection, and authentication). 4.1.2. IKEv2 o RFC 4306, Internet Key Exchange (IKEv2) Protocol (S, Dec. 2005) This document describes version 2 of the Internet Key Exchange (IKE) protocol. It covers what was covered previously by separate documents: ISAKMP, IKE and DOI.It also addresses NAT traversal, legacy authentication and remote address acquisition. IKEv2 is not interoperable with IKEv1. o RFC 4718, IKEv2 Clarifications and Implementation Guidelines (I, Oct. 2006) [RFC4718] clarifies many areas of the IKEv2 specification that may be difficult to understand for developers who are not intimately familiar with the specification and its history. It does not introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The goal of this document is to encourage the development of interoperable implementations. o draft-ietf-ipsecme-ikev2bis, Internet Key Exchange Protocol: IKEv2 (S) This document combines the original IKEv2 RFC [RFC4306] with the Clarifications RFC [RFC4718], and resolves many implementation issues discovered by the community since the publication of these two documents. 4.2. Additions and Extensions Frankel & Krishnan Expires August 2009 [Page 14]
Internet Draft IPsec/IKE Roadmap March 6, 2009 4.2.1. Peer Authentication Methods o RFC 4478, Repeated Authentication in Internet Key Exchange (IKEv2) Protocol (E, Apr. 2006) [RFC4478] addresses a problem unique to remote access scenarios. How can the gateway (the IKE responder) force the remote user (the IKE initiator) to periodically re-authenticate, limiting the damage in the case where an unauthorized user gains physical access to the remote host? This document defines a new informational message that a responder can send to an initiator, notifying the initiator that the IPsec SA will be revoked unless the initiator re-authenticates. o RFC 4739, Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol (E, Nov. 2006) IKEv2 supports several mechanisms for authenticating the parties but each endpoint uses only one of these mechanisms to authenticate itself. [RFC4739] specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, using either different mechanisms or the same mechanism. This extension allows, for instance, performing certificate-based authentication of the client host followed by an EAP authentication of the user. This also allows for authentication by multiple administrative domains, if needed. o RFC 4754, IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA) (S, Jan. 2007) [RFC4754] describes how the Elliptic Curve Digital Signature Algorithm (ECDSA) may be used as the authentication method within the IKEv1 and IKEv2 protocols. ECDSA provides many benefits including computational efficiency, small signature sizes, and minimal bandwidth compared to other available digital signature methods like RSA and DSA. 4.2.2. Certificate Contents and Management (PKI4IPsec) o RFC 4809, Requirements for an IPsec Certificate Management Profile (I, Feb. 2007) [RFC4809] enumerates requirements for Public Key Certificate (PKC) lifecycle transactions between different VPN System and PKI System products in order to better enable large scale, PKI-enabled IPsec deployments with a common set of transactions. This document discusses requirements for both the IPsec and the PKI products. o RFC 4945, The Internet IP Security PKI Profile of IKEv1/ISAKMP, Frankel & Krishnan Expires August 2009 [Page 15]
Internet Draft IPsec/IKE Roadmap March 6, 2009 IKEv2, and PKIX (S, Aug. 2007) [RFC4945] defines a profile of the IKE and PKIX frameworks in order to provide an agreed-upon standard for using PKI technology in the context of IPsec. It also documents the contents of the relevant IKE payloads and further specifies their semantics. It also summarizes the current state of implementations and deployment and provides advice to avoid common interoperability issues. o RFC 4806, Online Certificate Status Protocol (OCSP) Extensions to IKEv2 (S, Feb. 2007) When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. [RFC4806] defines the "OCSP Content" extension to IKEv2. This document is applicable when OCSP is desired and security policy (e.g. firewall) prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. 4.2.3. Dead Peer Detection o RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers (I, Feb. 2004) When two peers communicate using IKE and IPsec, it is possible for the connectivity between the two peers to drop unexpectedly. But the SAs can still remain until their lifetimes expire, resulting in the packets getting tunneled into a "black hole". [RFC3706] describes an approach to detect peer liveliness without needing to send messages at regular intervals. This RFC defines an optional extension to IKEv1; dead peer detection (DPD) is an integral part of IKEv2. 4.2.4. Remote Access o draft-ietf-ipsecme-ikev2-resumption, IKEv2 Session Resumption (S) This document enables a remote client that has been disconnected from a gateway to re-establish SAs with the gateway in an expedited manner, without repeating the complete IKEv2 negotiation. This capability requires changes to IKEv2. o draft-ietf-ipsecme-ikev2-redirect, Re-direct Mechanism for IKEv2 (S) This document enables a gateway to securely re-direct VPN clients to Frankel & Krishnan Expires August 2009 [Page 16]
Internet Draft IPsec/IKE Roadmap March 6, 2009 another VPN gateway, either during or after the IKEv2 negotiation. Possible reasons include, but are not limited to, an overloaded gateway or a gateway that needs to shut down. This requires changes to IKEv2. o draft-ietf-ipsecme-ikev2-ipv6-config, IPv6 Configuration in IKEv2 (S) In IKEv2, a VPN gateway can assign an internal network address to a remote VPN client. This is accomplished through the use of configuration payloads. For an IPv6 client, the assignment of a single address is not sufficient to enable full-fledged IPv6 communications. This document proposes several solutions that might remove this limitation. 5. Cryptographic Algorithms and Suites Two basic requirements must be met for an algorithm to be used within IKE and/or IPsec: assignment of one or more IANA values and an RFC that describes how to use the algorithm within the relevant protocol, packet formats, special considerations, etc. For each RFC that describes a cryptographic algorithm, this document will classify its Requirements Level for each protocol, as either MUST, SHALL or MAY [RFC2119]; optional; not defined; or N/A (not applicable). Optional means that the algorithm meets the two basic requirements, but its use is not specifically recommended for that protocol. Not defined means that one of the basic requirements is not met: either there is no relevant IANA number for the algorithm, or there is no RFC specifying how it should be used within that specific protocol. N/A means that use of the algorithm is inappropriate in the context (e.g., NULL encryption for IKE, which always requires encryption; or combined mode algorithms, a new feature in IPsec-v3, for use with IPsec-v2). This document categorizes the requirements level of each algorithm for IKEv1, IKEv2, IPsec-v2 and IPsec-v3. If an algorithm is recommended for use within IKEv1 or IKEv2, it is used either to protect the IKE SA's traffic (encryption and integrity-protection algorithms) or to generate keying material (Diffie-Hellman or DH groups, Pseudo-Random Functions or PRFs). If an algorithm is recommended for use within IPsec, it is used to protect the IPsec/child SA's traffic, and IKE is capable of negotiating its use for that purpose. 5.1. Algorithm Requirements Specifying a core set of mandatory algorithms for each protocol Frankel & Krishnan Expires August 2009 [Page 17]
Internet Draft IPsec/IKE Roadmap March 6, 2009 facilitates interoperability. Defining those algorithms in an RFC separate from the base protocol RFC enhances algorithm agility. IPsec-v3 and IKEv2 each have an RFC that specifies their mandatory-to-implement (MUST), recommended (SHOULD), optional (MAY), and deprecated (SHOULD NOT) algorithms. For IPsec-v2, this is included in the base protocol RFC. That was originally the case for IKEv1, but IKEv1's algorithm requirements were updated in [RFC4109]. o RFC 4835, Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (S, Apr. 2007) [RFC4835] specifies the encryption and integrity-protection algorithms for IPsec (both versions). Combined mode algorithms are mentioned, but not assigned a requirement level. NOTE: Algorithms for IPsec-v2 were originally defined in [RFC2402] and [RFC2406]. [RFC4305] obsoleted those requirements, and was in turn obsoleted by [RFC4835]. Therefore, by inference [RFC4835] applies to IPsec-v2 as well as IPsec-v3. o RFC 4307, Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2) (S, Dec. 2005) [RFC4307] specifies the encryption and integrity-protection algorithms used by IKEv2 to protect its own traffic; the Diffie-Hellman (DH) groups used within IKEv2; and the pseudo-random functions used by IKEv2 to generate keys, nonces and other random values. It also specifies the encryption and integrity-protection algorithms that IKEv2 negotiates for use within IPsec. o RFC 4109, Algorithms for Internet Key Exchange version 1 (IKEv1) (S, May 2005) [RFC4109] updates IKEv1's algorithm specifications, which were originally defined in [RFC2409]. It specifies the encryption and integrity-protection algorithms used by IKEv1 to protect its own traffic; the Diffie-Hellman (DH) groups used within IKEv1; the hash and pseudo-random functions used by IKEv1 to generate keys, nonces and other random values; and the authentication methods and algorithms used by IKEv1 for peer authentication. 5.2. Encryption Algorithms The encryption algorithm RFCs describe how to use these algorithms to encrypt IKE and/or ESP traffic, providing confidentiality protection to the traffic. They describe any special constraints, requirements, Frankel & Krishnan Expires August 2009 [Page 18]
Internet Draft IPsec/IKE Roadmap March 6, 2009 or changes to packet format appropriate for the specific algorithm. In general, they do not describe the detailed algorithmic computations; the reference section of each RFC includes pointers to documents that define the inner workings of the algorithm. Some of the RFCs include sample test data, to enable implementors to compare their results with standardized output. When any encryption algorithm is used to provide confidentiality, the use of integrity(protection is strongly recommended. If the encryption algorithm is a stream cipher, omitting integrity-protection seriously compromises the security properties of the algorithm. DES, as described in [RFC2405], was originally a required algorithm for IKEv1 and ESP-v2. Since the use of DES is now deprecated, this roadmap does not include [RFC2405]. o RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec (S, Nov. 1998) [RFC2410] is a tongue-in-cheek description of the no-op encryption algorithm (i.e. using ESP without encryption). In order for IKE to negotiate the selection of the NULL encryption algorithm for use in an ESP SA, an identifying IANA number is needed. This number (the value 11 for ESP_NULL) is found on the IANA registries for both IKEv1 and IKEv2, but it is not mentioned in this RFC. Requirements levels for ESP-NULL: IKEv1 - N/A; IKEv2 - N/A; ESP-v2 - MUST [RFC4835]; ESP-v3 - MUST [RFC4835] NOTE: [RFC4307] lists ESP-NULL as MAY for ESP-v3, which conflicts with the MUST in [RFC4835]. o RFC 2451, The ESP CBC-Mode Cipher Algorithms (S, Nov. 1998) [RFC2451] describes how to use encryption algorithms in cipher block chaining (CBC) mode to encrypt IKE and ESP traffic. It specifically mentions Blowfish, CAST-128, Triple DES (3DES), IDEA and RC5, but it is applicable to any block cipher algorithm used in CBC mode. The algorithms mentioned in the RFC all have a 64-bit blocksize and a 64-bit random IV that is sent in the packet along with the encrypted data. Requirements levels for 3DES-CBC: IKEv1 - MUST [RFC4109]; IKEv2 - MUST- [RFC4307]; ESP-v2 - MUST [RFC4835]; ESP-v3 - MUST- [RFC4835] Requirements levels for other CBC algorithms (Blowfish, CAST, IDEA, RC5): IKEv1 - optional; IKEv2 - optional; ESP-v2 - optional; ESP-v3 - Frankel & Krishnan Expires August 2009 [Page 19]
Internet Draft IPsec/IKE Roadmap March 6, 2009 optional o RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec (S, Sep. 2003) [RFC3602] describes how to use AES in cipher block chaining (CBC) mode to encrypt IKE and ESP traffic. AES is the successor to DES. AES-CBC is a block-mode cipher with a 128-bit blocksize; a random IV that is sent in the packet along with the encrypted data; and keysizes of 128, 192 and 256 bits. 128-bit keys are MUST; the other sizes are MAY. [RFC3602] includes IANA values for use in IKEv1 and ESP-v2. A single IANA value is defined for AES-CBC, so IKE negotiations need to specify the keysize. Requirements levels for AES-CBC with 128-bit keys: IKEv1 - SHOULD [RFC4109]; IKEv2 - SHOULD+ [RFC4307]; ESP-v2 - MUST [RFC4835]; ESP-v3 - MUST [RFC4835] Requirements levels for AES-CBC with 192- or 256-bit keys: IKEv1 - optional; IKEv2 - optional; ESP-v2 - optional; ESP-v3 - optional o RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP) (S, Jan. 2004) [RFC3686] describes how to use AES in counter (CTR) mode to encrypt ESP traffic. AES-CTR is a stream cipher with a 32-bit random nonce (1/SA) and a 64-bit IV, both of which are sent in the packet along with the encrypted data. 128-bit keys are MUST; 192- and 256-byte keys are MAY. Reuse of the IV with the same key and nonce compromises the data's security; thus, AES-CTR should not be used with manual keying. AES-CTR can be pipelined and parallelized; it uses only the AES encryption operations for both encryption and decryption. Requirements levels for AES-CTR: IKEv1 - not defined (no IANA #); IKEv2 - optional or not defined (see NOTE); ESP-v2 - SHOULD [RFC4835]; ESP-v3 - SHOULD [RFC4835] NOTE: AES-CTR does not have an IANA number for IKEv1; since the same IANA numbers are used for IKEv2 and IPsec-v3, does [RFC3686] suffice to define the use of AES-CTR within IKEv2? o RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec (S, Dec. 2005) [RFC4312] describes how to use Camellia in cipher block chaining (CBC) mode to encrypt IKE and ESP traffic. Camellia-CBC is a block-mode cipher with a 128-bit blocksize; a random IV that is sent Frankel & Krishnan Expires August 2009 [Page 20]
Internet Draft IPsec/IKE Roadmap March 6, 2009 in the packet along with the encrypted data; and keysizes of 128, 192 and 256 bits. 128-bit keys are MUST; the other sizes are MAY. [RFC4312] includes IANA values for use in IKEv1 and IPsec-v2. A single IANA value is defined for Camellia-CBC, so IKEv1 negotiations need to specify the keysize. Requirements levels for Camellia-CBC: IKEv1 - optional; IKEv2 - not defined (no IANA #); ESP-v2 - optional; ESP-v3 - not defined (no IANA #) 5.3. Integrity-Protection (Authentication) Algorithms The integrity-protection algorithm RFCs describe how to use these algorithms to authenticate IKE and/or IPsec traffic, providing integrity protection to the traffic. This protection is provided by computing an Integrity Check Value (ICV), which is sent in the packet. The RFCs describe any special constraints, requirements, or changes to packet format appropriate for the specific algorithm. In general, they do not describe the detailed algorithmic computations; the reference section of each RFC includes pointers to documents that define the inner workings of the algorithm. Some of the RFCs include sample test data, to enable implementors to compare their results with standardized output. o RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH (S, Nov. 1998) [RFC2404] describes HMAC-SHA-1, an integrity-protection algorithm with a 512-bit blocksize, and a 160-bit key and Integrity Check Value (ICV). For use within IPsec, the ICV is truncated to 96 bits. This is currently the most commonly-used integrity-protection algorithm. Requirements levels for HMAC-SHA-1: IKEv1 - MUST [RFC4109]; IKEv2 - MUST [RFC4307]; IPsec-v2 - MUST [RFC4835]; IPsec-v3 - MUST [RFC4835] o RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec (S, Sep. 2003) [RFC3566] describes AES-XCBC-MAC, a variant of CBC-MAC which is secure for messages of varying lengths (unlike classic CBC-MAC). It is an integrity-protection algorithm with a 128-bit blocksize, and a 128-bit key and ICV. For use within IPsec, the ICV is truncated to 96 bits. [RFC3566] includes test data. Requirements levels for AES-XCBC-MAC: IKEv1 - SHOULD [RFC4109]; IKEv2 - optional; IPsec-v2 - SHOULD+ [RFC4835]; IPsec-v3 - SHOULD+ [RFC4835] Frankel & Krishnan Expires August 2009 [Page 21]
Internet Draft IPsec/IKE Roadmap March 6, 2009 o RFC 4868, Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec (S, May 2007) [RFC4868] describes a family of algorithms, successors to HMAC-SHA-1. HMAC-SHA-256 has a 512-bit blocksize, and a 256-bit key and ICV. HMAC-SHA-384 has a 1024-bit blocksize, and a 384-bit key and ICV. HMAC-SHA-512 has a 1024-bit blocksize, and a 512-bit key and ICV. For use within IKE and IPsec, the ICV is truncated to half its original size (128 bits, 192 bits, or 256 bits). Each of the three algorithms has its own IANA value, so IKE does not have to negotiate the keysize. Requirements levels for HMAC-SHA-256, HMAC-SHA-384, HMC-SHA-512: IKEv1 - optional; IKEv2 - optional; IPsec-v2 - optional; IPsec-v3 - optional o RFC 4543, The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH (S, May 2006) [RFC4543] is the variant of AES-GCM [RFC4106] that provides integrity-protection without encryption. It has two versions: an integrity-protection algorithm for use within AH-v3, and a combined-mode algorithm with null encryption for use within ESP-v3. It can use a key of 128-, 192-, or 256-bits; the ICV is always 128 bits, and is not truncated. AES-GMAC uses a nonce, consisting of a 64-bit IV and a 32-bit salt (1/SA). The salt value is generated by IKEv2 during the key generation process. Reuse of the salt value with the same key compromises the data's security; thus, AES-GMAC should not be used with manual keying. For use within AH-v3, each keysize has its own IANA value, so IKE does not have to negotiate the keysize. For use within ESP-v3, there is only one IANA value, so IKE negotiations must specify the keysize. Requirements levels for AES-GMAC: IKEv1 - N/A; IKEv2 - optional; IPsec-v2 - not defined (no IANA #); IPsec-v3 - optional o RFC 2403, The Use of HMAC-MD5-96 within ESP and AH (S, Nov. 1998) [RFC2403] describes HMAC-MD5, an integrity-protection algorithm with a 512-bit blocksize, and a 128-bit key and Integrity Check Value (ICV). For use within IPsec, the ICV is truncated to 96 bits. It was a required algorithm for IKEv1 and IPsec-v2. The use of plain MD5 is now deprecated, but [RFC4835] states: "Weaknesses have become apparent in MD5; however, these should not affect the use of MD5 with HMAC." Requirements levels for HMAC-MD5: IKEv1 - MAY [RFC4109]; IKEv2 - Frankel & Krishnan Expires August 2009 [Page 22]
Internet Draft IPsec/IKE Roadmap March 6, 2009 optional [RFC4307]; IPsec-v2 - MAY [RFC4835]; IPsec-v3 - MAY [RFC4835] o RFC 4494, The AES-CMAC-96 Algorithm and Its Use with IPsec (S, Jun. 2006) [RFC4494] describes AES-CMAC, another variant of CBC-MAC which is secure for messages of varying lengths. It is an integrity-protection algorithm with a 128-bit blocksize, and 128-bit key and ICV. For use within IPsec, the ICV is truncated to 96 bits. [RFC4494] includes test data. Requirements levels for AES-CMAC: IKEv1 - not defined (no IANA #); IKEv2 - optional; IPsec-v2 - not defined (no IANA #); IPsec-v3 - optional o RFC 2857, The Use of HMAC-RIPEMD-160-96 within ESP and AH (S, Jun. 2000) [RFC2857] describes HMAC-RIPEMD, an integrity-protection algorithm with a 512-bit blocksize, and a 160-bit key and ICV. For use within IPsec, the ICV is truncated to 96 bits. Requirements levels for HMAC-RIPEMD: IKEv1 - not defined (no IANA #); IKEv2 - not defined (no IANA #); IPsec-v2 - optional; IPsec-v3 - not defined (no IANA #) 5.3.1. General Considerations o RFC 4894, Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec (I, May 2007) In light of recent attacks on MD5 and SHA-1, [RFC4894] examines whether it is necessary to replace the hash functions currently used by IKE and IPsec for key generation, integrity-protection, digital signatures, or PKIX certificates. It concludes that the algorithms recommended for IKEv2 [RFC4307] and IPsec-v3 [RFC4305] are not currently susceptible to any known attacks. Nonetheless, it suggests that implementors add support for AES-XCBC-MAC-96 [RFC3566], AES-XCBC-PRF-128 [RFC4434] and HMAC-SHA-256, -384, and -512 [RFC4868] for future use. It also suggests that IKEv2 implementors add support for PKIX certificates signed with HMAC-SHA-256, -384, and -512. 5.4. Combined Mode Algorithms IKEv1 and ESP-v2 use separate algorithms to provide encryption and Frankel & Krishnan Expires August 2009 [Page 23]
Internet Draft IPsec/IKE Roadmap March 6, 2009 integrity-protection, and IKEv1 can negotiate different combinations of algorithms for different SAs. In ESP-v3, a new class of algorithms was introduced, in which a single algorithm can provide both encryption and integrity-protection. [RFC4306] describes how IKEv2 can negotiate combined mode algorithms to be used in ESP-v3 SAs. [RFC5282] adds that capability to IKEv2, enabling IKEv2 to negotiate and use combined mode algorithms for its own traffic. When properly designed, these algorithms can provide increased efficiency in both implementation and execution. o RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP) (S, Dec. 2005) [RFC4309] describes how to use AES in Counter with CBC-MAC (CCM) mode, a combined alorithm, to encrypt and integrity-protect ESP-v3 traffic. AES-CCM is a block-mode cipher with a 128-bit blocksize; a random IV that is sent in the packet along with the encrypted data; a 24-bit salt value (1/SA); keysizes of 128, 192 and 256 bits, and ICV sizes of 64, 96 and 128 bits. 128-bit keys are MUST; the other sizes are MAY. ICV sizes of 64 and 128 bit are MUST; 96 bits is MAY. The salt value is generated by IKEv2 during the key generation process. Reuse of the IV with the same key compromises the data's security; thus, AES-CCM should not be used with manual keying. [RFC4309] includes IANA values for use in ESP-v3. Each of the three ICV lengths has its own IANA value, but IKEv2 negotiations need to specify the keysize. [RFC4309] includes test data. [RFC4309] describes how IKEv2 can negotiate the use of AES-CCM to use in an ESP-v3 SA. [RFC5282] extends this to the use of AES-CCM to protect an IKEv2 SA. Requirements levels for AES-CCM: IKEv1 - N/A; IKEv2 - optional; ESP-v2 - N/A; ESP-v3 - optional [RFC4835] NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but combined-mode algorithms are not a feature of IPsec-v2. o RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) (S, Jun. 2005) [RFC4106] describes how to use AES in Galois/Counter (GCM) mode, a combined alorithm, to encrypt and integrity-protect ESP-v3 traffic. AES-GCM is a block-mode cipher with a 128-bit blocksize; a random IV that is sent in the packet along with the encrypted data; a 32-bit salt value (1/SA); keysizes of 128, 192 and 256 bits; and ICV sizes of 64, 96 and 128 bits. 128-bit keys are MUST; the other sizes are MAY. An ICV size of 128 bits is a MUST; 64 and 96 bits are MAY. The salt value is generated by IKEv2 during the key generation process. Reuse of the IV with the same key compromises the data's security; Frankel & Krishnan Expires August 2009 [Page 24]
Internet Draft IPsec/IKE Roadmap March 6, 2009 thus, AES-GCM should not be used with manual keying. [RFC4106] includes IANA values for use in ESP-v3. Each of the three ICV lengths has its own IANA value, but IKEv2 negotiations need to specify the keysize. [RFC4106] includes test data. [RFC4106] describes how IKEv2 can negotiate the use of AES-GCM to use in an ESP-v3 SA. [RFC5282] extends this to the use of AES-GCM to protect an IKEv2 SA. Requirements levels for AES-GCM: IKEv1 - N/A; IKEv2 - optional; ESP-v2 - N/A; ESP-v3 - optional [RFC4835] NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but combined-mode algorithms are not a feature of IPsec-v2. 5.4.1. General Considerations o RFC 5282, Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol (S, Aug. 2008) [RFC5282] extends [RFC4309] and [RFC4106] to enable the use of AES-CCM and AES-GCM to provide encryption and integrity-protection for IKEv2 messages. 5.5. Pseudo-Random Functions (PRFs) IKE uses pseudo-random functions (PRFs) to generate the secret keys that are used in IKE SAs and IPsec SAs. These PRFs are generally the same algorithms used for integrity-protection, but their output is not truncated, since all of the generated bits are generally needed for the keys. If the PRF's output is not long enough to supply the required number of bits of keying material, the PRF is applied iteratively until the requisite amount of keying material is generated. o RFC 4434, The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) (S, Feb. 2006) [RFC3566] defines AES-XCBC-MAC-96, which is used for integrity protection within IKE and IPsec. [RFC4434] enables the use of AES-XCBC-MAC as a PRF within IKE. The PRF differs from the integrity-protection algorithm in two ways: its 128-bit output is not truncated to 96 bits; and it accepts a variable-length key, which is modified (lengthened via padding or shortened through application of AES-XCBC) to a 128-bit key. [RFC4434] includes test data. Requirements levels for AES-XCBC-PRF: IKEv1 - SHOULD [RFC4109]; IKEv2 Frankel & Krishnan Expires August 2009 [Page 25]
Internet Draft IPsec/IKE Roadmap March 6, 2009 - SHOULD+ [RFC4307] o RFC 4615, The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE) (S, Aug. 2006) [RFC4615] extends [RFC4494] to enable the use of AES-CMAC as a PRF within IKEv2, in a manner analogous to that used by [RFC4434] for AES-XCBC. Requirements levels for AES-CMAC-PRF: IKEv1 - not defined (no IANA #); IKEv2 - optional 5.6. Cryptographic Suites o RFC 4308, Cryptographic Suites for IPsec (S, Dec. 2005) An IKE negotiation consists of multiple cryptographic attributes, both for the IKE SA and for the IPsec SA. The infinite number of possible combinations can pose a challenge to peers trying to find a common policy. To enhance interoperability, [RFC4308] defines two pre-defined suites, consisting of combinations of algorithms that comprise typical security policies. IKE/ESP suite "VPN-A" includes use of 3DES, HMAC-SHA-1, and 1024-bit MODP Diffie-Hellman (DH); IKE/ESP suite "VPN-B" includes AES-CBC, AES-XCBC-MAC, and 2048-bit MODP DH. These suites are intended to be named "single-button" choices in the administrative interface, but do not prevent the use of alternative combinations. o RFC 4869, Suite B Cryptographic Suites for IPsec (I, May 2007) [RFC4869] adds 4 pre-defined suites, based upon "Suite B" algorithms, to those specified in [RFC4308]. IKE/ESP-v3 suites "Suite-B-GCM-128" and "Suite-B-GCM-256" include use of AES-CBC, AES-GCM, HMAC-SHA-256 or HMAC-SHA-384, and 256-bit or 384-bit elliptic curve (EC) DH groups. IKE/AH-v3 suites "Suite-B-GMAC-128" and "Suite-B-GMAC-256" include use of AES-CBC, AES-GMAC, HMAC-SHA-256 or HMAC-SHA-384, and 256-bit or 384-bit EC DH groups. 5.7. Diffie-Hellman Algorithms IKE negotiations include a Diffie-Hellman exchange, which establishes a shared secret, to which both parties contributed. This value is used to generate keying material to protect both the IKE SA and the IPsec SA. Frankel & Krishnan Expires August 2009 [Page 26]
Internet Draft IPsec/IKE Roadmap March 6, 2009 IKEv1 [RFC2409] contains definitions of 2 DH MODP groups and 2 elliptic curve (EC) groups; IKEv2 [RFC4306] only references the MODP groups. The requirements levels of these groups are: Requirements levels for DH MODP group 1: IKEv1 - MAY [RFC4109]; IKEv2 - optional Requirements levels for DH MODP group 2: IKEv1 - MUST [RFC4109]; IKEv2 - MUST- [RFC4307] Requirements levels for EC groups 3-4: IKEv1 - MAY [RFC4109]; IKEv2 - not defined (no IANA #) o RFC 3526, More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) (S, May 2003) [RFC2409] and [RFC4306] define 2 MODP DH groups (groups 1 and 2) for use within IKE. [RFC3526] adds six more groups (groups 5 and 14-18). Group 14 is a 2048-bit group that is strongly recommended for use in IKE. Requirements levels for DH MODP group 14: IKEv1 - SHOULD [RFC4109]; IKEv2 - SHOULD+ [RFC4307] Requirements levels for DH MODP groups 5, 15-18: IKEv1 - optional [RFC4109]; IKEv2 - optional o RFC 4753, ECP Groups For IKE and IKEv2 (I, Jan. 2007) [RFC4753] defines 3 EC DH groups (groups 19-21) for use within IKE. The document includes test data. Requirements levels for DH EC groups 19-21: IKEv1 - optional [RFC4109]; IKEv2 - optional o RFC 5114, Additional Diffie-Hellman Groups for Use with IETF Standards (I, Jan. 2008) [RFC5114] defines 5 additional DH groups (MODP groups 22-24 and EC groups 25-26) for use in IKE. It also includes 3 EC DH groups (groups 19-21) that were previously defined in [RFC4753]. The IANA group numbers are specific to IKE, but the DH groups are intended for use in multiple IETF protocols, including TLS/SSL, S/MIME, and X.509 Certificates. Requirements levels for DH MODP groups 22-24, EC groups 25-26: IKEv1 - optional; IKEv2 - optional Frankel & Krishnan Expires August 2009 [Page 27]
Internet Draft IPsec/IKE Roadmap March 6, 2009 6. IPsec/IKE for Multicast [RFC4301] describes IPsec processing for unicast and multicast traffic. However, classical IPsec SAs provide point-to-point protection; the security afforded by IPsec's cryptographic algorithms is not applicable when the SA is one-to-many or many-to-many, the case for multicast. The Multicast Security (msec) Working Group has defined alternatives to IKE and extensions to IPsec for use with multicast traffic. Different multicast groups have differing characteristics and requirements: number of senders (one-to-many or many-to-many), number of members (few, moderate, very large), volatility of membership, real-time delivery, etc. Their security requirements vary as well. Each solution defined by msec applies to a subset of the infinite variety of possible multicast groups. o RFC 3740, The Multicast Group Security Architecture (I, Mar. 2004) [RFC3740] defines the multicast security architecture, which is used to provide security for packets exchanged by large multicast groups. It defines the components of the architectural framework; discusses Group Security Associations (GSAs), key management, data handling and security policies. Several existing protocols, including GDOI [RFC3547], GSAKMP [RFC4535] and MIKEY [RFC3830], satisfy the group key management requirements defined in this document. o RFC 5374, Multicast Extensions to the Security Architecture for the Internet Protocol (S, Nov. 2008) [RFC5374] extends the security architecture defined in [4301] to apply to multicast traffic. It defines a new class of SAs (GSAs - Group Security Associations) and additional databases used to apply IPsec protection to multicast traffic. It also describes revisions and additions to the processing algorithms in [RFC4301]. o RFC 3547, The Group Domain of Interpretation (S, Jul. 2003) GDOI [RFC3547] extends IKEv1 so that it can be used to establish SAs to protect multicast traffic. This document defines additional exchanges and payloads to be used for that purpose. o RFC 4046, Multicast Security (MSEC) Group Key Management Architecture (I, Apr. 2005) [RFC4046] sets out the general requirements and design principles for protocols that are used for multicast key management. It does not go into the specifics of an individual protocol that can be used for that purposel Frankel & Krishnan Expires August 2009 [Page 28]
Internet Draft IPsec/IKE Roadmap March 6, 2009 o RFC 4535, GSAKMP: Group Secure Association Key Management Protocol (S, Jun. 2006) [RFC4535] defines a protocol that can be used to generate, distribute and manage keys to be used for secure group communications. GSAKMP is also used to distribute and enforce group security policies. It can be used to facilitate many-to-many communications and distributed architectures. o RFC 4534, Group Security Policy Token v1 (S, Jun. 2006) [RFC4534] specifies the structure of the Group Security Policy Token, "a structure used to specify the security policy and configurable parameters for a cryptographic group, such as a secure multicast group." This token can be used within GSAKMP to define and enforce group polices such as secure access control. o RFC 3830, MIKEY: Multimedia Internet KEYing (S, Aug. 2004) MIKEY [RFC3830] is a key management protocol, an alternative to GDOI [RFC3547] and GSAKMP [RFC4535], that is well-suited for use in real-time, low-latency secure multimedia scenarios. o RFC 4738, MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY) (S, Nov. 2006) [RFC4738] adds an additional key distribution method to MIKEY: MIKEY-RSA-R, reverse-mode RSA. o RFC 5197, On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions (I, Jun. 2008) [RFC5197] provides in in-depth, integrated description of MIKEY modes and extensions. It also includes sample real-world use cases. o RFC 4563, The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY) (S, Jun. 2006) [RFC4563] defines a MIKEY extension that satisfies the need for frequent, efficient key update in the 3GPP environment. o RFC 4359, The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH) (S, Jan. 2006) [RFC4359] describes the use of the RSA digital signature algorithm to provide integrity-protection for multicast traffic within ESP and AH. The algorithms used for integrity-protection for unicast traffic Frankel & Krishnan Expires August 2009 [Page 29]
Internet Draft IPsec/IKE Roadmap March 6, 2009 (e.g., HMAC) are not suitable for this purpose when used with multicast traffic. o RFC 4650, HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY) (S, Sep. 2006) [RFC4650] "describes a lightweight point-to-point key management protocol variant for the multimedia Internet keying (MIKEY) project." o RFC 5410, Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0 (I, Jan. 2009) [RFC5410] describes one use of the General Extension Payload, defined as part of the base MIKEY [RFC3830] protocol. This document specifies a payload that can be used to transport keying material or management data that is defined in the Open Mobile Alliance's (OMA) Broadcast (BCAST) group's Service and Content protection specification. o RFC 4082, Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction (I, Jun. 2005) TESLA is a scheme that provides source authentication and integrity-protection to receivers of multicast traffic. Symmetric algorithms cannot generally be used for this purpose with multicast traffic; public-key algorithms, which can afford this protection, require considerably greater overhead. TESLA leverages time synchronization and delayed key disclosure to provide this protection via the more efficient symmetric key algorithms. It can be used in multicast groups with a very large number of receivers. o RFC 4442, Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA) (S, Mar. 2006) [RFC4442] describes MIKEY payloads that can be used to specify TESLA parameters, thus bootstrapping the use of TESLA within the Secure Real-time Transport Protocol (SRTP). o RFC 4383, The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP) (S, Feb. 2006) [RFC4383] describes the use of TESLA within SRTP to protect multicast and broadcast traffic. 7. Outgrowths of IPsec/IKE Frankel & Krishnan Expires August 2009 [Page 30]
Internet Draft IPsec/IKE Roadmap March 6, 2009 7.1. IPComp (Compression) o RFC 3173, IP Payload Compression Protocol (IPComp) (S, Sep. 2001) IPComp is a protocol that provides lossless compression for IP datagrams. IP payload compression is especially useful when IPsec based encryption is applied to IP datagrams. Encrypting the IP datagram causes the data to be random in nature, rendering compression at lower protocol layers ineffective. If IKE is used to negotiate compression in conjunction with IPsec, compression can be performed prior to encryption. [RFC3173] defines the payload compression protocol, the IPComp packet structure, the IPComp Association (IPCA), and several methods to negotiate the IPCA. o RFC 2394, IP Payload Compression Using DEFLATE (I, Dec. 1998) The IPComp protocol allows the compression of IP datagrams by supporting different compression algorithms. [RFC2394] defines the application of the DEFLATE algorithm as a compression method to IPComp. o RFC 2395, IP Payload Compression Using LZS (I, Dec. 1998) The IPComp protocol allows the compression of IP datagrams by supporting different compression algorithms. [RFC2395] defines the application of the LZS algorithm as a compression method to IPComp. 7.2. IKEv2 Mobility and Multihoming (MobIKE) o RFC 4621, Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol (I, Aug. 2006) [RFC4621] discusses the involved network entities and the relationship between IKEv2 signaling and information provided by other protocols. It also records design decisions for the MOBIKE protocol, background information, and records discussions within the working group. o RFC 4555, IKEv2 Mobility and Multihoming Protocol (MOBIKE) (S, Jun. 2006) IKEv2 assumes that an IKE SA is created implicitly between the IP address pair that is used during the protocol execution when establishing the IKEv2 SA. IPsec related documents had no provision to change this pair after an IKE SA was created. [RFC4555] defines extensions to IKEv2 that enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP Frankel & Krishnan Expires August 2009 [Page 31]
Internet Draft IPsec/IKE Roadmap March 6, 2009 addresses and/or where IP addresses of an IPsec host change over time. o RFC 5266, Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE) (B, Jun. 2008) [RFC5266] describes a solution using Mobile IPv4 (MIPv4) and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility to enterprise users when they roam into untrusted networks. 7.3. Better-than-Nothing Security (Btns) o draft-ietf-btns-connection-latching, IPsec Channels: Connection Latching This document specifies, abstractly, how to interface applications and transport protocols with IPsec so as to create channels by latching connections (packet flows) to certain IPsec Security Association (SA) parameters for the lifetime of the connections. Connection latching is layered on top of IPsec and does not modify the underlying IPsec architecture. o RFC 5386, Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec (S, Nov. 2008) [RFC5386] specifies how to use the Internet Key Exchange (IKE) protocols, such as IKEv1 and IKEv2, to setup unauthenticated security associations (SAs) for use with the IPsec Encapsulating Security Payload (ESP) and the IPsec Authentication Header (AH). This document does not require any changes to the bits on the wire, but specifies extensions to the Peer Authorization Database (PAD) and Security Policy Database (SPD). o RFC 5387, Problem and Applicability Statement for Better-Than-Nothing Security (BTNS) (I, Nov. 2008) [RFC5387] considers that the need to deploy authentication information and its associated identities is a significant obstacle to the use of IPsec. This document explains the rationale for extending the Internet network security protocol suite to enable use of IPsec security services without authentication. 7.4. Kerberized Internet Negotiation of Keys (Kink) o RFC 3129, Requirements for Kerberized Internet Negotiation of Keys (I, Jun. 2001) Frankel & Krishnan Expires August 2009 [Page 32]
Internet Draft IPsec/IKE Roadmap March 6, 2009 [RFC3129] considers that peer to peer authentication and keying mechanisms have inherent drawbacks such as computational complexity and difficulty in enforcing security policies. This document specifies the requirements for using basic features of Kerberos and uses them to its advantage to create a protocol which can establish and maintain IPsec security associations ([RFC2401]). o RFC 4430, Kerberized Internet Negotiation of Keys (KINK) (S, Mar. 2006) [RFC4430] defines a low-latency, computationally inexpensive, easily managed, and cryptographically sound protocol to establish and maintain security associations using the Kerberos authentication system. This document reuses the Quick Mode payloads of IKEv1 in order to foster substantial reuse of IKEv1 implementations. This RFC has not been widely adopted. 7.5. IPsec Secure Remote Access (IPSRA) o RFC 3457, Requirements for IPsec Remote Access Scenarios (I, Jan. 2003) [RFC3457] explores and enumerates the requirements of various IPsec remote access scenarios, without suggesting particular solutions for them. o RFC 3456, Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode (S, Jan. 2003) [RFC3456] explores the requirements for host configuration in IPsec tunnel mode, and describes how the Dynamic Host Configuration Protocol (DHCPv4) may be used for providing such configuration information. This RFC has not been widely adopted. 7.6. IPsec Keying Information Resource Record (IPsecKEY) o RFC 4025, A method for storing IPsec keying material in DNS (S, Feb. 2005) This document describes a method of storing IPsec keying material in DNS using a new type of resource record. This document describes how to store the public key of the target node in this resource record. This RFC has not been widely adopted. 8. Other Protocols that use IPsec/IKE 8.1. Mobile IP (MIPv4 and MIPv6) Frankel & Krishnan Expires August 2009 [Page 33]
Internet Draft IPsec/IKE Roadmap March 6, 2009 o RFC 4093, Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways (I, Aug. 2005) This document describes the issues with deploying Mobile IPv4 across virtual private networks (VPNs). IPsec is one of the VPN technologies covered by this document. It identifes and describes practical deployment scenarios for Mobile IPv4 running alongside IPsec in enterprise and operator environments. It also specifies a set of framework guidelines to evaluate proposed solutions for supporting multi-vendor seamless IPv4 mobility across IPsec-based VPN gateways. o RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways (S, Jun. 2008) This document describes a basic solution that uses Mobile IPv4 and IPsec to provide session mobility between enterprise intranets and external networks. The proposed solution minimizes changes to existing firewall/VPN/DMZ deployments and does not require any changes to IPsec or key exchange protocols. It also proposes a mechanism to minimize IPsec renegotiation when the mobile node moves. o RFC 3776, Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents (S, Jun. 2004) This document illustrates the use of IPsec in securing Mobile IPv6 traffic between mobile nodes and home agents. It specifies the required wire formats for the protected packets and illustrates examples of Security Policy Database and Security Association Database entries that can be used to protect Mobile IPv6 signaling messages. It also describes how to configure either manually keyed IPsec security associations or how to configure IKEv1 to establish the SAs automatically. o RFC 4877, Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture (S, Apr. 2007) This document updates [RFC3776] in order to work with the revised IPsec architecture [RFC4301]. Since the revised IPsec architecture expands the list of selectors to include the Mobility Header message type, it becomes much easier to differentiate between different mobility header messages. Since the ICMP message type and code are also newly added as selectors, this document uses them to protect Mobile Prefix Discovery messages. Finally, this document describes the use of IKEv2 in order to set up the SAs for Mobile IPv6. o draft-ietf-mip6-cn-ipsec, Using IPsec between Mobile and Correspondent IPv6 Nodes Frankel & Krishnan Expires August 2009 [Page 34]
Internet Draft IPsec/IKE Roadmap March 6, 2009 The Mobile IPv6 protocol contains a mode called "route optimization" (RO) mode that enables the mobile node to communicate with a corresponding node using the most direct path between them instead of passing through the home agent. It also defines a mechanism called the return routability procedure in order to secure the RO signaling. This document defines an alternative mechanism for Mobile IPv6 route optimization based on strong authentication and IPsec. It specifies which IPsec configurations can be useful in a Mobile IPv6 context and how they can validate Home Address Options and protect mobility signaling. It also provides detailed IKEv1 and IKEv2 configuration guidelines for common usage scenarios. o RFC 5213, Proxy Mobile IPv6 (S, Aug. 2008) This document describes a network-based mobility management protocol that is used to provide mobility services hosts without requiring their participation in any mobility-related signaling. It uses IPsec to protect the mobility signaling messages between the two network entities called the mobile access gateway (MAG) and the local mobility anchor (LMA). It also uses IKEv2 in order to set up the security associations between the MAG and the LMA. o RFC 5268, Mobile IPv6 Fast Handovers (S, Jun. 2008) When Mobile IPv6 is used for a handover, there is a period during which the Mobile Node is unable to send or receive packets because of link switching delay and IP protocol operations. This document specifies a protocol between the Previous Access Router (PAR) and the New Access Router (NAR) to improve handover latency due to Mobile IPv6 procedures. It uses IPsec ESP in transport mode with integrity protection for protecting the signaling messages between the PAR and the NAR. It also describes the SPD entries and the PAD entries when IKEv2 is used for setting up the required SAs. o RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management (S, Oct. 2008) This document describes extensions to Mobile IPv6 and IPv6 Neighbour Discovery to allow for local mobility handling in order to reduce the amount of signalling between the mobile node, its correspondent nodes, and its home agent. It also improves handover speed of Mobile IPv6. It uses IPsec for protecting the signaling between the mobile node and a local mobility management entity called the Mobility Anchor Point (MAP). The MAP also uses IPsec Peer Authorization Database (PAD) entries and configuration payloads described in [RFC4877] in order to allocate a Regional Care-of Address (RCoA) for mobile nodes. Frankel & Krishnan Expires August 2009 [Page 35]
Internet Draft IPsec/IKE Roadmap March 6, 2009 8.2. Open Shortest Path First (OSPF) o RFC 4552, Authentication/Confidentiality for OSPFv3 (S, Jun. 2006) OSPF is a link-state routing protocol that is designed to be run inside a single Autonomous System. OSPFv2 provided its own authentication mechanisms using the AuType and Authentication protocol header fields but OSPFv3 removed these fields and uses IPsec instead. This document describes how to use IPsec ESP and AH in order to protect OSPFv3 signaling between two routers. It also enumerates the IPsec capabilities the routers require in order to support this specification. Finally, it also describes the operation of OSPFv3 with IPsec over virtual links where the other endpoint is not known at configuration time. 8.3. Host Identity Protocol (HIP) o RFC 5201, Host Identity Protocol (E, Apr. 2008) This document specifies a protocol that allows consenting hosts to securely establish and maintain shared IP-layer state, allowing separation of the identifier and locator roles of IP addresses. This enables continuity of communications across IP address (locator) changes. It uses the HMAC-SHA-1-96 and the AES-CBC algorithms with IPsec ESP and AH for protecting its signaling messages. o RFC 5202, Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP) (E, Apr. 2008) The HIP base exchange specification [RFC5201] does not describe any transport formats or methods for for describing how ESP is used to protect user data to be used during the actual communication. This document specifies a set of HIP protocol extensions for creating a pair of ESP Security Associations (SAs) between the hosts during the base exchange. After the HIP association and required ESP SAs have been established between the hosts, the user data communication is protected using ESP. In addition, this document specifies how to use the ESP Security Parameter Index (SPI) is used to indicate the right host context(host identity) and methods to update an existing ESP Security Association. o RFC 5206, End-Host Mobility and Multihoming with the Host Identity (E, Apr. 2008) When a host uses HIP, the overlying protocol sublayers (e.g., transport layer sockets and Encapsulating Security Payload (ESP) Frankel & Krishnan Expires August 2009 [Page 36]
Internet Draft IPsec/IKE Roadmap March 6, 2009 Security Associations (SAs) are bound to representations of these host identities, and the IP addresses are only used for packet forwarding. This document defines a generalized LOCATOR parameter for use in HIP messages that allows a HIP host to notify a peer about alternate addresses at which it is reachable. It also specifies how a host can change its IP address and continue to send packets to its peers without necessarily rekeying. o RFC 5207, NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) (I, Apr. 2008) This document discusses the problems associated with HIP communication across network paths that include network address translators and firewalls. It analyzes the impact of NATs and firewalls on the HIP base exchange and the ESP data exchange. It discusses possible changes to HIP that attempt to improve NAT and firewall traversal and proposes a rendezvous point for letting HIP nodes behind a NAT be reachable. It also suggests mechanisms for NATs to be more aware of the HIP messages. 8.4. Extensible Authentication Protocol (EAP) Method Update (EMU) o RFC 5106, The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method (E, Feb. 2008) This document specifies an Extensible Authentication Protocol (EAP) method that is based on the Internet Key Exchange (IKEv2) protocol. EAP-IKEv2 provides mutual authentication and session key establishment between an EAP peer and an EAP server. It describes the full EAP-IKEv2 message exchange and the composition of the protocol messages. 8.5. Stream Control Transmission Protocol (SCTP) o RFC 3554, On the Use of Stream Control Transmission Protocol (SCTP) with IPsec (S, Jul. 2003) The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connection-less packet network such as IP. This document describes functional requirements for IPsec and IKE to be used in securing SCTP traffic. It adds support for SCTP in the form of a new ID type in IKE [RFC2409] and implementation choices in the IPsec processing to account for the multiple source and destination addresses associated with a single SCTP association. 8.6. Fibre Channel Frankel & Krishnan Expires August 2009 [Page 37]
Internet Draft IPsec/IKE Roadmap March 6, 2009 o RFC 4595, Use of IKEv2 in the Fibre Channel Security Association Management Protocol (I, Jul. 2006) Fibre Channel (FC) is a gigabit-speed network technology used for Storage Area Networking. The Fibre Channel Security Protocols standard (FC-SP) has adapted the IKEv2 protocol [RFC4306] to provide authentication of Fibre Channel entities and setup of security associations. Since IP is transported over Fibre Channel [RFC4338] and Fibre Channel/SCSI are transported over IP [RFC3643], [RFC3821] there is the potential for confusion when IKEv2 is used for both IP and FC traffic. This document specifies identifiers for IKEv2 over FC in a fashion that ensures that any mistaken usage of IKEv2/FC over IP or IKEv2/IP over FC will result in a negotiation failure due to the absence of an acceptable proposal. 8.7. Robust Header Compression (ROHC) o RFC 3095, RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed (S, July 2001) ROHC is a framework for header compression, intended to be used in resource-constrained environments. [RFC3095] applies this framework to four protocols, including ESP. o RFC 5225, RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP, and UDP-Lite (S, April 2008) [RFC5225] includes an ESP profile for use with ROHC version 2. 9. Security Considerations There are no security considerations relevant to this document. 10. IANA Considerations No actions are required from IANA as result of the publication of this document. 11. References 11.1. Normative References 11.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Frankel & Krishnan Expires August 2009 [Page 38]
Internet Draft IPsec/IKE Roadmap March 6, 2009 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [btns-1] Williams, N., "IPsec Channels: Connection Latching", draft-ietf-btns-connection-latching, Work in Progress. [ipsecme-1] Kaufman, C., P. Hoffman, Y. Nir and P. Eronen, "Internet Key Exchange Protocol: IKEv2", draft-ietf-ipsecme-ikev2bis, Work in Progress. [ipsecme-2] Eronen, P., J. Laganier and C. Madson, draft-ietf-ipsecme-ikev2-ipv6-config, IPv6 Configuration in IKEv2, Work in Progress. [ipsecme-3] Devarapalli, V and K. Weniger, draft-ietf-ipsecme-ikev2-redirect, Re-direct Mechanism for IKEv2, Work in Progress. [ipsecme-4] Sheffer, Y., H. Tschofenig, L. Dondeti and V. Narayanan, draft-ietf-ipsecme-ikev2-resumption, IKEv2 Session Resumption, Work in Progress. [ipsecme-5] Grewal, K. and G. Montenegro, draft-ietf-ipsecme-traffic-visibility, Wrapped ESP for Traffic Visibility, Work in Progress. [ipsecme-6] Kivinen, T. and D. McDonald, draft-kivinen-ipsecme-esp-null-heuristics, Heuristics for Detecting ESP-NULL packets, Work in Progress. [mip6-1] Dupont, F. and J-M. Combes, "Using IPsec between Mobile and Correspondent IPv6 Nodes", draft-ietf-mip6-cn-ipsec, Work in Progress. [RFC2394] Pereira, R., "IP Payload Compression Using DEFLATE", RFC 2394, December 1998. [RFC2395] Friend, R. and R. Monsour, "IP Payload Compression Using LZS", RFC 2395, December 1998. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998 (obsolete). [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998 (obsolete). [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998. Frankel & Krishnan Expires August 2009 [Page 39]
Internet Draft IPsec/IKE Roadmap March 6, 2009 [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP and AH", RFC 2404, November 1998. [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998 (obsolete). [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998 (obsolete). [RFC2408] Maughan, D. M. Schertler, M. Schneider and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998 (obsolete). [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998 (obsolete). [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and Its Use With IPsec", RFC 2410, November 1998. [RFC2411] Thayer, R., N. Doraswamy and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998. [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998. [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998. [RFC2857] Keromytis, A. and N. Provos, "The Use of HMAC-RIPEMD-160-96 within ESP and AH", RFC 2857, June 2000. [RFC3056] Carpenter, B., "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC3095] Bormann, C., Ed. et.al., "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [RFC3129] Thomas, M., "Requirements for Kerberized Internet Negotiation of Keys", RFC 3129, June 2001. [RFC3173] Shacham, A. B. Monsour, R. Pereira and M. Thomas, "IP Payload Compression Protocol (IPComp)", RFC 3173, Frankel & Krishnan Expires August 2009 [Page 40]
Internet Draft IPsec/IKE Roadmap March 6, 2009 September 2001. [RFC3456] Patel, B. B. Aboba, S. Kelly and V. Gupta, "Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode", RFC 3456, January 2003. [RFC3457] Kelly, S. and S. Ramamoorthi, "Requirements for IPsec Remote Access Scenarios", RFC 3457, January 2003. [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003. [RFC3547] Baugher, M. B. Weis, T. Hardjono and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003. [RFC3554] Bellovin, S. J. Ioannidis, A. Keromytis and R. Stewart, "On the Use of Stream Control Transmission Protocol (SCTP) with IPsec", RFC 3554, July 2003. [RFC3566] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec", RFC 3566, September 2003. [RFC3585] Jason, J. L. Rafalow, and E. Vyncke, "IPsec Configuration Policy Information Model", RFC 3585, August 2003. [RFC3586] Blaze, M. A. Keromytis, M. Richardson and L. Sanchez, "IP Security Policy (IPSP) Requirements", RFC 3586, August 2003. [RFC3602] Frankel, S. R. Glenn and S. Kelly, "The AES-CBC Cipher Algorithm and Its Use with IPsec", RFC 3602, September 2003. [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)", RFC 3686, January 2004. [RFC3706] Huang, G., S. Beaulieu and D. Rochefort, "A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers", RFC 3706, February 2004. [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004. [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004. Frankel & Krishnan Expires August 2009 [Page 41]
Internet Draft IPsec/IKE Roadmap March 6, 2009 [RFC3776] Arkko, J., V. Devarapalli and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004. [RFC3830] Arkko, J., E. Carrara, F. Lindholm, M. Naslund and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004. [RFC3884] Touch, J., L. Eggert and Y. Wang, "Use of IPsec Transport Mode for Dynamic Routing", RFC 3884, September 2004. [RFC3947] Kivinen, T., B. Swander, A. Huttunen and V. Volpe, "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005. [RFC3948] Huttunen, A., B. Swander, V. Volpe, L. DiBurro and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. [RFC4025] Richardson, M., "A method for storing IPsec keying material in DNS", RFC 4025, February 2005. [RFC4046] Baugher, M., R. Canetti, L. Dondeti and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005. [RFC4082] Perrig, A., D. Song, R. Canetti, J. D. Tygar and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005. [RFC4093] Adrandi, F., Ed. and H. Levkowetz, Ed., "Problem Statement: Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, August 2005. [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 4106, June 2005. [RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version 1 (IKEv1)", RFC 4109, May 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. Frankel & Krishnan Expires August 2009 [Page 42]
Internet Draft IPsec/IKE Roadmap March 6, 2009 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4304] Kent, S., "Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)", RFC 4304, December 2005. [RFC4305] Eastlake, D. 3rd, "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005 (obsolete). [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005. [RFC4308] Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308, December 2005. [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005. [RFC4312] Kato, A., S. Moriai and M. Kanda, "The Camellia Cipher Algorithm and Its Use with IPsec", RFC 4312, December 2005. [RFC4359] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006. [RFC4383] Baugher, M. and E. Carrara, "The Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Secure Real-time Transport Protocol (SRTP)", RFC 4383, February 2006. [RFC4430] Sakane, S., K. Kamada, M. Thomas, and J. Vilhuber, "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430, March 2006. [RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4434, February 2006. Frankel & Krishnan Expires August 2009 [Page 43]
Internet Draft IPsec/IKE Roadmap March 6, 2009 [RFC4442] Fries, S. and H. Tschofenig, "Bootstrapping Timed Efficient Stream Loss-Tolerant Authentication (TESLA)", RFC 4442, March 2006. [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange (IKEv2) Protocol", RFC 4478, April 2006. [RFC4494] Song, JH., R. Poovendran and J. Lee, "The AES-CMAC-96 Algorithm and Its Use with IPsec", RFC 4494, June 2006. [RFC4534] Colegrove, A. and H. Harney, "Group Security Policy Token v1", RFC 4534, June 2006. [RFC4535] Harney, H., U. Meth, A. Colegrove and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006. [RFC4543] McGrew, D. and J. Viega, "The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543, May 2006. [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006. [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", RFC 4555, June 2006. [RFC4563] Carrara, E., V. Lehtovirta and K. Norrman, "The Key ID Information Type for the General Extension Payload in Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006. [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel Security Association Management Protocol", RFC 4595, July 2006. [RFC4615] Song, J., R. Poovendran, J. Lee and T. Iwata, "The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)", RFC 4615, August 2006. [RFC4621] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, August 2006. [RFC4650] Euchner, M., "HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY)", RFC 4650, September 2006. Frankel & Krishnan Expires August 2009 [Page 44]
Internet Draft IPsec/IKE Roadmap March 6, 2009 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006. [RFC4738] Ignjatic, D., L. Dondeti, F. Audet and P. Lin, "MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, November 2006. [RFC4739] Eronen P. and J. Korhonen, "Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol", RFC 4739, November 2006. [RFC4753] Fu, D. and J. Solinas, "ECP Groups For IKE and IKEv2", RFC 4753, January 2007. [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)", RFC 4754, January 2007. [RFC4806] Myers, M. and H. Tschofenig, "Online Certificate Status Protocol (OCSP) Extensions to IKEv2", RFC 4806, February 2007. [RFC4807] Baer, M., R. Charlet, W. Hardaker, R. Story and C. Wang, "IPsec Security Policy Database Configuration MIB", RFC 4807, March 2007. [RFC4809] Bonatti, C., Ed., and S. Turner, Ed., "Requirements for an IPsec Certificate Management Profile", RFC 4809, February 2007. [RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007. [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. [RFC4869] Law, L. and J. Solinas, "Suite B Cryptographic Suites for IPsec", RFC 4869, May 2007. [RFC4877] Devarapalli, V. and R. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. [RFC4891] Graveman, R., M. Parthasarathy, P. Savola and H. Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", Frankel & Krishnan Expires August 2009 [Page 45]
Internet Draft IPsec/IKE Roadmap March 6, 2009 RFC 4891, May 2007. [RFC4894] Hoffman, P., "Use of Hash Algorithms in Internet Key Exchange (IKE) and IPsec", RFC 4894, May 2007. [RFC4945] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. [RFC5106] Tschofenig, H., D. Kroeselberg, A. Pashalidis, Y. Ohba and F. Bersani, "The Extensible Authentication Protocol-Internet Key Exchange Protocol version 2 (EAP-IKEv2) Method", RFC 5106, February 2008. [RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, January 2008. [RFC5197] Fries, S. and D. Ignjatic, "On the Applicability of Various Multimedia Internet KEYing (MIKEY) Modes and Extensions", RFC 5197, June 2008. [RFC5201] Moskowitz, R., P. Nikander, P. Jokela, Ed., and T. Henderson, "Host Identity Protocol", RFC 5201, April 2008. [RFC5202] Jokela, P., R. Moskowitz and P. Nikander, "Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008. [RFC5206] Nikander, P., T. Henderson, Ed., C. Vogt, and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity", RFC 5206, April 2008. [RFC5207] Stiemerling, M., J. Quittek and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP)", RFC 5207, April 2008. [RFC5213] Gundavelli, S., Ed., K. Leung, V. Devarapali, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5225] Pelletier, G. and K. Sandlund, "RObust Header Compression Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP, and UDP-Lite", RFC 5225, April 2008. [RFC5265] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across IPsec-Based VPN Gateways", RFC 5265, June 2008. Frankel & Krishnan Expires August 2009 [Page 46]
Internet Draft IPsec/IKE Roadmap March 6, 2009 [RFC5266] Devarapalli, V. and P. Eronen, "Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)", RFC 5266, June 2008. [RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008. [RFC5282] Black, D. and D. McGrew, " Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol", RFC 5282, August 2008. [RFC5380] Soliman, H., C. Castelluccia, K. ElMalki and L. Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, October 2008. [RFC5386] Williams, N. and M. Richardson, "Better-Than-Nothing-Security: An Unauthenticated Mode of IPsec", RFC 5386, November 2008. [RFC5374] Weis, B., G. Gross and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008. [RFC5387] Touch, J., D. Black and Y. Wang, "Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)", RFC 5387, November 2008. [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec Version 2", RFC 5406, February 2009. [RFC 5410] Jerichow, A., Ed., and L. Piron, "Multimedia Internet KEYing (MIKEY) General Extension Payload for Open Mobile Alliance BCAST 1.0", RFC 5410, January 2009. Frankel & Krishnan Expires August 2009 [Page 47]
Internet Draft IPsec/IKE Roadmap March 6, 2009 Authors' Addresses Sheila Frankel NIST Bldg. 223 Rm. B366 Gaithersburg, MD 20899 Phone: 1-301-975-3297 Email: sheila.frankel@nist.gov Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada Phone: 1-514-345-7900 x42871 Email: suresh.krishnan@ericsson.com Intellectual Property All IETF Documents and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement Frankel & Krishnan Expires August 2009 [Page 48]
Internet Draft IPsec/IKE Roadmap March 6, 2009 any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices, of the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Frankel & Krishnan Expires August 2009 [Page 49]
