Difference between revisions of "RFC6071"
Line 19: | Line 19: | ||
includes a brief description of each RFC, along with background | includes a brief description of each RFC, along with background | ||
information explaining the motivation and context of IPsec's | information explaining the motivation and context of IPsec's | ||
− | outgrowths and extensions. It obsoletes RFC 2411, the previous "IP | + | outgrowths and extensions. It obsoletes [[RFC2411|RFC 2411]], the previous "IP |
Security Document Roadmap." | Security Document Roadmap." | ||
− | The obsoleted IPsec roadmap (RFC 2411) briefly described the | + | The obsoleted IPsec roadmap ([[RFC2411|RFC 2411]]) briefly described the |
interrelationship of the various classes of base IPsec documents. | interrelationship of the various classes of base IPsec documents. | ||
− | The major focus of RFC 2411 was to specify the recommended contents | + | The major focus of [[RFC2411|RFC 2411]] was to specify the recommended contents |
of documents specifying additional encryption and authentication | of documents specifying additional encryption and authentication | ||
algorithms. | algorithms. | ||
Line 38: | Line 38: | ||
Internet Engineering Steering Group (IESG). Not all documents | Internet Engineering Steering Group (IESG). Not all documents | ||
approved by the IESG are a candidate for any level of Internet | approved by the IESG are a candidate for any level of Internet | ||
− | Standard; see Section 2 of RFC 5741. | + | Standard; see Section 2 of [[RFC5741|RFC 5741]]. |
Information about the current status of this document, any errata, | Information about the current status of this document, any errata, | ||
Line 49: | Line 49: | ||
document authors. All rights reserved. | document authors. All rights reserved. | ||
− | This document is subject to BCP 78 and the IETF Trust's Legal | + | This document is subject to [[BCP78|BCP 78]] and the IETF Trust's Legal |
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | ||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | ||
Line 90: | Line 90: | ||
In addition to the base documents for IPsec and IKE, there are | In addition to the base documents for IPsec and IKE, there are | ||
numerous RFCs that reference, extend, and in some cases alter the | numerous RFCs that reference, extend, and in some cases alter the | ||
− | core specifications. This document obsoletes | + | core specifications. This document obsoletes [[RFC2411]]. It attempts |
to list and briefly describe those RFCs, providing context and | to list and briefly describe those RFCs, providing context and | ||
rationale where indicated. The title of each RFC is followed by a | rationale where indicated. The title of each RFC is followed by a | ||
− | letter that indicates its category in the RFC series | + | letter that indicates its category in the RFC series [[RFC2026]], as |
follows: | follows: | ||
Line 120: | Line 120: | ||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||
− | document are to be interpreted as described in | + | document are to be interpreted as described in [[RFC2119]]. |
== IPsec/IKE Background Information == | == IPsec/IKE Background Information == | ||
Line 202: | Line 202: | ||
expands details that were underspecified or ambiguous in IPsec-v2. | expands details that were underspecified or ambiguous in IPsec-v2. | ||
− | Changes to the architecture document | + | Changes to the architecture document [[RFC4301]] include: |
o More detailed descriptions of IPsec processing, both unicast and | o More detailed descriptions of IPsec processing, both unicast and | ||
Line 226: | Line 226: | ||
o Mandatory algorithms defined in standalone document | o Mandatory algorithms defined in standalone document | ||
− | o AH | + | o AH [[RFC4302]] is mandatory to implement (MUST) in IPsec-v2, |
optional (MAY) in IPsec-v3 | optional (MAY) in IPsec-v3 | ||
− | Changes to ESP | + | Changes to ESP [[RFC4303]] include: |
o Combined mode algorithms were added, necessitating changes to | o Combined mode algorithms were added, necessitating changes to | ||
Line 301: | Line 301: | ||
o IKE Attributes | o IKE Attributes | ||
(http://www.iana.org/assignments/ipsec-registry): values used | (http://www.iana.org/assignments/ipsec-registry): values used | ||
− | during IKEv1 Phase 1 exchanges, defined in | + | during IKEv1 Phase 1 exchanges, defined in [[RFC2409]]. |
o "Magic Numbers" for Internet Security Association and Key | o "Magic Numbers" for Internet Security Association and Key | ||
Management Protocol (ISAKMP) | Management Protocol (ISAKMP) | ||
(http://www.iana.org/assignments/isakmp-registry): values used | (http://www.iana.org/assignments/isakmp-registry): values used | ||
− | during IKEv1 Phase 2 exchanges, defined in | + | during IKEv1 Phase 2 exchanges, defined in [[RFC2407]], |
− | + | [[RFC2408]], and numerous other cryptographic algorithm RFCs. | |
o IKEv2 Parameters | o IKEv2 Parameters | ||
(http://www.iana.org/assignments/ikev2-parameters): values used | (http://www.iana.org/assignments/ikev2-parameters): values used | ||
− | in IKEv2 exchanges, defined in | + | in IKEv2 exchanges, defined in [[RFC5996]] and numerous other |
cryptographic algorithm RFCs. | cryptographic algorithm RFCs. | ||
o Cryptographic Suites for IKEv1, IKEv2, and IPsec | o Cryptographic Suites for IKEv1, IKEv2, and IPsec | ||
(http://www.iana.org/assignments/crypto-suites): names of | (http://www.iana.org/assignments/crypto-suites): names of | ||
− | cryptographic suites in | + | cryptographic suites in [[RFC4308]] and [[RFC4869]]. |
== IPsec Documents == | == IPsec Documents == | ||
Line 331: | Line 331: | ||
==== "Old" IPsec (IPsec-v2) ==== | ==== "Old" IPsec (IPsec-v2) ==== | ||
− | ===== RFC 2401, Security Architecture for the Internet Protocol ===== | + | ===== [[RFC2401|RFC 2401]], Security Architecture for the Internet Protocol ===== |
(S, November 1998) | (S, November 1998) | ||
− | + | [[RFC2401]] specifies the mechanisms, procedures, and components | |
required to provide security services at the IP layer. It also | required to provide security services at the IP layer. It also | ||
describes their interrelationship and the general processing required | describes their interrelationship and the general processing required | ||
Line 366: | Line 366: | ||
protection. | protection. | ||
− | RFC 2401 describes general inbound and outbound IPsec processing; it | + | [[RFC2401|RFC 2401]] describes general inbound and outbound IPsec processing; it |
also includes details on several special cases: packet fragments, | also includes details on several special cases: packet fragments, | ||
ICMP messages, and multicast traffic. | ICMP messages, and multicast traffic. | ||
− | ===== RFC 2402, IP Authentication Header (S, November 1998) ===== | + | ===== [[RFC2402|RFC 2402]], IP Authentication Header (S, November 1998) ===== |
− | + | [[RFC2402]] defines the Authentication Header (AH), which provides | |
integrity protection; it also provides data-origin authentication, | integrity protection; it also provides data-origin authentication, | ||
access control, and, optionally, replay protection. A transport mode | access control, and, optionally, replay protection. A transport mode | ||
Line 388: | Line 388: | ||
classifies AH as mandatory to implement. | classifies AH as mandatory to implement. | ||
− | ===== RFC 2406, IP Encapsulating Security Payload (ESP) ===== | + | ===== [[RFC2406|RFC 2406]], IP Encapsulating Security Payload (ESP) ===== |
(S, November 1998) | (S, November 1998) | ||
− | + | [[RFC2406]] defines the IP Encapsulating Security Payload (ESP), which | |
provides confidentiality (encryption) and/or integrity protection; it | provides confidentiality (encryption) and/or integrity protection; it | ||
also provides data-origin authentication, access control, and, | also provides data-origin authentication, access control, and, | ||
Line 401: | Line 401: | ||
==== "New" IPsec (IPsec-v3) ==== | ==== "New" IPsec (IPsec-v3) ==== | ||
− | ===== RFC 4301, Security Architecture for the Internet Protocol ===== | + | ===== [[RFC4301|RFC 4301]], Security Architecture for the Internet Protocol ===== |
(S, December 2005) | (S, December 2005) | ||
− | + | [[RFC4301]] obsoletes [[RFC2401]], and it includes a more complete and | |
detailed processing model. The most notable changes are detailed | detailed processing model. The most notable changes are detailed | ||
above in Section 2.2.1. IPsec-v3 processing incorporates an | above in Section 2.2.1. IPsec-v3 processing incorporates an | ||
Line 413: | Line 413: | ||
between IPsec and the key management protocol (e.g., IKE) | between IPsec and the key management protocol (e.g., IKE) | ||
− | ===== RFC 4302, IP Authentication Header (S, December 2005) ===== | + | ===== [[RFC4302|RFC 4302]], IP Authentication Header (S, December 2005) ===== |
− | + | [[RFC4302]] obsoletes [[RFC2402]]. Unlike IPsec-v2, IPsec-v3 classifies | |
AH as optional. | AH as optional. | ||
− | ===== RFC 4303, IP Encapsulating Security Payload (ESP) ===== | + | ===== [[RFC4303|RFC 4303]], IP Encapsulating Security Payload (ESP) ===== |
(S, December 2005) | (S, December 2005) | ||
− | + | [[RFC4303]] obsoletes [[RFC2406]]. The most notable changes are detailed | |
above in Section 2.2.1. | above in Section 2.2.1. | ||
Line 445: | Line 445: | ||
high-availability environment. | high-availability environment. | ||
− | ==== RFC 3947, Negotiation of NAT-Traversal in the IKE ==== | + | ==== [[RFC3947|RFC 3947]], Negotiation of NAT-Traversal in the IKE ==== |
(S, January 2005) | (S, January 2005) | ||
− | + | [[RFC3947]] defines an optional extension to IKEv1. It enables IKEv1 | |
to detect whether there are any NATs between the negotiating peers | to detect whether there are any NATs between the negotiating peers | ||
and whether both peers support NAT traversal. It also describes how | and whether both peers support NAT traversal. It also describes how | ||
IKEv1 can be used to negotiate the use of UDP encapsulation of ESP | 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 | packets for the IPsec SA. For IKEv2, this capability is described in | ||
− | + | [[RFC5996]]. | |
− | ==== RFC 3948, UDP Encapsulation of IPsec ESP Packets ==== | + | ==== [[RFC3948|RFC 3948]], UDP Encapsulation of IPsec ESP Packets ==== |
(S, January 2005) | (S, January 2005) | ||
− | + | [[RFC3948]] is an optional extension for IPsec-v2 and IPsec-v3. It | |
defines how to encapsulate ESP packets in UDP packets to enable the | defines how to encapsulate ESP packets in UDP packets to enable the | ||
traversal of NATs that discard packets with protocols other than UDP | traversal of NATs that discard packets with protocols other than UDP | ||
Line 464: | Line 464: | ||
NAT device without requiring any change to the NAT device itself. | NAT device without requiring any change to the NAT device itself. | ||
The use of this solution is negotiated by IKE, as described in | The use of this solution is negotiated by IKE, as described in | ||
− | + | [[RFC3947]] for IKEv1 and [[RFC5996]] for IKEv2. | |
− | ==== RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec ==== | + | ==== [[RFC4304|RFC 4304]], Extended Sequence Number (ESN) Addendum to IPsec ==== |
Domain of Interpretation (DOI) for Internet Security Association | Domain of Interpretation (DOI) for Internet Security Association | ||
and Key Management Protocol (ISAKMP) (S, December 2005) | and Key Management Protocol (ISAKMP) (S, December 2005) | ||
Line 474: | Line 474: | ||
the packet, enabling shorter packets and avoiding a redesign of the | the packet, enabling shorter packets and avoiding a redesign of the | ||
packet format. The larger sequence numbers allow an existing IPsec | packet format. The larger sequence numbers allow an existing IPsec | ||
− | SA to be used for larger volumes of data. | + | SA to be used for larger volumes of data. [[RFC4304]] describes an |
optional extension to IKEv1 that enables IKEv1 to negotiate the use | optional extension to IKEv1 that enables IKEv1 to negotiate the use | ||
of ESNs for IPsec SAs. For IKEv2, this capability is described in | of ESNs for IPsec SAs. For IKEv2, this capability is described in | ||
− | + | [[RFC5996]]. | |
− | ==== RFC 4322, Opportunistic Encryption using the Internet Key ==== | + | ==== [[RFC4322|RFC 4322]], Opportunistic Encryption using the Internet Key ==== |
Exchange (IKE) (I, December 2005) | Exchange (IKE) (I, December 2005) | ||
Opportunistic encryption allows a pair of end systems to use | Opportunistic encryption allows a pair of end systems to use | ||
− | encryption without any specific pre-arrangements. | + | encryption without any specific pre-arrangements. [[RFC4322]] |
specifies a mechanism that uses DNS to distribute the public keys of | specifies a mechanism that uses DNS to distribute the public keys of | ||
each system involved and uses DNS Security (DNSSEC) to secure the | each system involved and uses DNS Security (DNSSEC) to secure the | ||
Line 494: | Line 494: | ||
gateway. | gateway. | ||
− | ==== RFC 4891, Using IPsec to Secure IPv6-in-IPv4 Tunnels ==== | + | ==== [[RFC4891|RFC 4891]], Using IPsec to Secure IPv6-in-IPv4 Tunnels ==== |
(I, May 2007) | (I, May 2007) | ||
− | + | [[RFC4891]] describes how to use IKE and transport-mode IPsec to | |
provide security protection to manually configured IPv6-in-IPv4 | provide security protection to manually configured IPv6-in-IPv4 | ||
tunnels. This document uses standard IKE and IPsec, without any new | tunnels. This document uses standard IKE and IPsec, without any new | ||
extensions. It does not apply to tunnels that are initiated in an | extensions. It does not apply to tunnels that are initiated in an | ||
− | automated manner (e.g., 6to4 tunnels | + | automated manner (e.g., 6to4 tunnels [[RFC3056]]). |
− | ==== RFC 3884, Use of IPsec Transport Mode for Dynamic Routing ==== | + | ==== [[RFC3884|RFC 3884]], Use of IPsec Transport Mode for Dynamic Routing ==== |
(I, September 2004) | (I, September 2004) | ||
− | + | [[RFC3884]] describes the use of transport-mode IPsec to secure IP-in- | |
IP tunnels, which constitute the links of a multi-hop, distributed | IP tunnels, which constitute the links of a multi-hop, distributed | ||
virtual network (VN). This allows the traffic to be dynamically | virtual network (VN). This allows the traffic to be dynamically | ||
Line 513: | Line 513: | ||
widely adopted. | widely adopted. | ||
− | ==== RFC 5840, Wrapped Encapsulating Security Payload (ESP) for ==== | + | ==== [[RFC5840|RFC 5840]], Wrapped Encapsulating Security Payload (ESP) for ==== |
Traffic Visibility (S, April 2010) | Traffic Visibility (S, April 2010) | ||
− | ESP, as defined in | + | ESP, as defined in [[RFC4303]], does not allow a network device to |
easily determine whether protected traffic that is passing through | easily determine whether protected traffic that is passing through | ||
the device is encrypted or only integrity protected (referred to as | the device is encrypted or only integrity protected (referred to as | ||
− | ESP-NULL packets). | + | ESP-NULL packets). [[RFC5840]] extends ESPv3 to provide explicit |
notification of integrity-protected packets, and extends IKEv2 to | notification of integrity-protected packets, and extends IKEv2 to | ||
negotiate this capability between the IPsec peers. | negotiate this capability between the IPsec peers. | ||
− | ==== RFC 5879, Heuristics for Detecting ESP-NULL packets ==== | + | ==== [[RFC5879|RFC 5879]], Heuristics for Detecting ESP-NULL packets ==== |
(I, May 2010) | (I, May 2010) | ||
− | + | [[RFC5879]] offers an alternative approach to differentiating between | |
ESP-encrypted and ESP-NULL packets through packet inspection. This | ESP-encrypted and ESP-NULL packets through packet inspection. This | ||
method does not require any change to IKE or ESP; it can be used with | method does not require any change to IKE or ESP; it can be used with | ||
Line 533: | Line 533: | ||
=== General Considerations === | === General Considerations === | ||
− | ==== RFC 3715, IPsec-Network Address Translation (NAT) Compatibility ==== | + | ==== [[RFC3715|RFC 3715]], IPsec-Network Address Translation (NAT) Compatibility ==== |
Requirements (I, March 2004) | Requirements (I, March 2004) | ||
− | + | [[RFC3715]] "describes known incompatibilities between NAT and IPsec, | |
and describes the requirements for addressing them". This is a | and describes the requirements for addressing them". This is a | ||
critical issue, since IPsec is frequently used to provide VPN access | critical issue, since IPsec is frequently used to provide VPN access | ||
Line 543: | Line 543: | ||
typically used for remote access. | typically used for remote access. | ||
− | ==== RFC 5406, Guidelines for Specifying the Use of IPsec Version 2 ==== | + | ==== [[RFC5406|RFC 5406]], Guidelines for Specifying the Use of IPsec Version 2 ==== |
(B, February 2009) | (B, February 2009) | ||
− | + | [[RFC5406]] offers guidance to protocol designers on how to ascertain | |
whether IPsec is the appropriate security mechanism to provide an | whether IPsec is the appropriate security mechanism to provide an | ||
interoperable security solution for the protocol. If this is not the | interoperable security solution for the protocol. If this is not the | ||
Line 553: | Line 553: | ||
protocol. The details in this document apply only to IPsec-v2. | protocol. The details in this document apply only to IPsec-v2. | ||
− | ==== RFC 2521, ICMP Security Failures Messages (E, March 1999) ==== | + | ==== [[RFC2521|RFC 2521]], ICMP Security Failures Messages (E, March 1999) ==== |
− | + | [[RFC2521]] specifies an ICMP message for indicating failures related | |
to the use of IPsec protocols (AH and ESP). The specified ICMP | to the use of IPsec protocols (AH and ESP). The specified ICMP | ||
message defines several codes for handling common failure modes for | message defines several codes for handling common failure modes for | ||
Line 563: | Line 563: | ||
messages can be used to trigger automated session-key management or | messages can be used to trigger automated session-key management or | ||
to signal to an operator the need to manually reconfigure the SAs. | to signal to an operator the need to manually reconfigure the SAs. | ||
− | This RFC has not been widely adopted. Furthermore, | + | This RFC has not been widely adopted. Furthermore, [[RFC4301]] |
discusses the pros and cons of relying on unprotected ICMP messages. | discusses the pros and cons of relying on unprotected ICMP messages. | ||
− | ==== RFC 6027, IPsec Cluster Problem Statement (I, October 2010) ==== | + | ==== [[RFC6027|RFC 6027]], IPsec Cluster Problem Statement (I, October 2010) ==== |
− | + | [[RFC6027]] describes the problems of using IKE and IPsec in a high | |
availability environment, in which one or both of the peers are | availability environment, in which one or both of the peers are | ||
clusters of gateways. It details the numerous types of stateful | clusters of gateways. It details the numerous types of stateful | ||
Line 614: | Line 614: | ||
recommended. | recommended. | ||
− | ===== RFC 2409, The Internet Key Exchange (IKE) (S, November 1998) ===== | + | ===== [[RFC2409|RFC 2409]], The Internet Key Exchange (IKE) (S, November 1998) ===== |
This document defines a key exchange protocol that can be used to | This document defines a key exchange protocol that can be used to | ||
Line 628: | Line 628: | ||
documents that define it. | documents that define it. | ||
− | ===== RFC 2408, Internet Security Association and Key Management ===== | + | ===== [[RFC2408|RFC 2408]], Internet Security Association and Key Management ===== |
Protocol (ISAKMP) (S, November 1998) | Protocol (ISAKMP) (S, November 1998) | ||
Line 637: | Line 637: | ||
key exchange protocols, each with different security properties. | key exchange protocols, each with different security properties. | ||
− | ===== RFC 2407, The Internet IP Security Domain of Interpretation ===== | + | ===== [[RFC2407|RFC 2407]], The Internet IP Security Domain of Interpretation ===== |
for ISAKMP (S, November 1998) | for ISAKMP (S, November 1998) | ||
Line 648: | Line 648: | ||
ISAKMP to negotiate security associations. | ISAKMP to negotiate security associations. | ||
− | ===== RFC 2412, The OAKLEY Key Determination Protocol ===== | + | ===== [[RFC2412|RFC 2412]], The OAKLEY Key Determination Protocol ===== |
(I, November 1998) | (I, November 1998) | ||
− | + | [[RFC2412]] describes a key establishment protocol that two | |
authenticated parties can use to agree on secure and secret keying | authenticated parties can use to agree on secure and secret keying | ||
material. The Oakley protocol describes a series of key exchanges -- | material. The Oakley protocol describes a series of key exchanges -- | ||
Line 663: | Line 663: | ||
==== IKEv2 ==== | ==== IKEv2 ==== | ||
− | ===== RFC 4306, Internet Key Exchange (IKEv2) Protocol ===== | + | ===== [[RFC4306|RFC 4306]], Internet Key Exchange (IKEv2) Protocol ===== |
(S, December 2005) | (S, December 2005) | ||
Line 674: | Line 674: | ||
distribution is required for IPsec-v3, but alternatives to IKE may be | distribution is required for IPsec-v3, but alternatives to IKE may be | ||
used to satisfy that requirement. This document has been superseded | used to satisfy that requirement. This document has been superseded | ||
− | by | + | by [[RFC5996]]. |
− | ===== RFC 4718, IKEv2 Clarifications and Implementation Guidelines ===== | + | ===== [[RFC4718|RFC 4718]], IKEv2 Clarifications and Implementation Guidelines ===== |
(I, October 2006) | (I, October 2006) | ||
− | + | [[RFC4718]] clarifies many areas of the original IKEv2 specification | |
− | + | [[RFC4306]] that were seen as potentially difficult to understand for | |
developers who were not intimately familiar with the specification | developers who were not intimately familiar with the specification | ||
and its history. It does not introduce any changes to the protocol, | and its history. It does not introduce any changes to the protocol, | ||
Line 687: | Line 687: | ||
development of interoperable implementations. The clarifications in | development of interoperable implementations. The clarifications in | ||
this document have been included in the new version of the IKEv2 | this document have been included in the new version of the IKEv2 | ||
− | specification | + | specification [[RFC5996]]. |
− | ===== RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2) ===== | + | ===== [[RFC5996|RFC 5996]], Internet Key Exchange Protocol Version 2 (IKEv2) ===== |
(S, September 2010) | (S, September 2010) | ||
− | + | [[RFC5996]] combines the original IKEv2 RFC [[RFC4306]] with the | |
− | Clarifications RFC | + | Clarifications RFC [[RFC4718]], and resolves many implementation issues |
discovered by the community since the publication of these two | discovered by the community since the publication of these two | ||
documents. This document was developed by the IPsecME (IPsec | documents. This document was developed by the IPsecME (IPsec | ||
Line 705: | Line 705: | ||
==== Peer Authentication Methods ==== | ==== Peer Authentication Methods ==== | ||
− | ===== RFC 4478, Repeated Authentication in Internet Key Exchange ===== | + | ===== [[RFC4478|RFC 4478]], Repeated Authentication in Internet Key Exchange ===== |
(IKEv2) Protocol (E, April 2006) | (IKEv2) Protocol (E, April 2006) | ||
− | + | [[RFC4478]] addresses a problem unique to remote access scenarios. How | |
can the gateway (the IKE responder) force the remote user (the IKE | can the gateway (the IKE responder) force the remote user (the IKE | ||
initiator) to periodically reauthenticate, limiting the damage in the | initiator) to periodically reauthenticate, limiting the damage in the | ||
Line 718: | Line 718: | ||
only to IKEv2, not to IKEv1. | only to IKEv2, not to IKEv1. | ||
− | ===== RFC 4739, Multiple Authentication Exchanges in the Internet ===== | + | ===== [[RFC4739|RFC 4739]], Multiple Authentication Exchanges in the Internet ===== |
Key Exchange (IKEv2) Protocol (E, November 2006) | Key Exchange (IKEv2) Protocol (E, November 2006) | ||
IKEv2 supports several mechanisms for authenticating the parties but | IKEv2 supports several mechanisms for authenticating the parties but | ||
each endpoint uses only one of these mechanisms to authenticate | each endpoint uses only one of these mechanisms to authenticate | ||
− | itself. | + | itself. [[RFC4739]] specifies an extension to IKEv2 that allows the |
use of multiple authentication exchanges, using either different | use of multiple authentication exchanges, using either different | ||
mechanisms or the same mechanism. This extension allows, for | mechanisms or the same mechanism. This extension allows, for | ||
Line 731: | Line 731: | ||
This optional extension applies only to IKEv2, not to IKEv1. | This optional extension applies only to IKEv2, not to IKEv1. | ||
− | ===== RFC 4754, IKE and IKEv2 Authentication Using the Elliptic ===== | + | ===== [[RFC4754|RFC 4754]], IKE and IKEv2 Authentication Using the Elliptic ===== |
Curve Digital Signature Algorithm (ECDSA) (S, January 2007) | Curve Digital Signature Algorithm (ECDSA) (S, January 2007) | ||
− | + | [[RFC4754]] describes how the Elliptic Curve Digital Signature | |
Algorithm (ECDSA) may be used as the authentication method within the | Algorithm (ECDSA) may be used as the authentication method within the | ||
IKEv1 and IKEv2 protocols. ECDSA provides many benefits including | IKEv1 and IKEv2 protocols. ECDSA provides many benefits including | ||
Line 742: | Line 742: | ||
IKEv2. | IKEv2. | ||
− | ===== RFC 5998, An Extension for EAP-Only Authentication in IKEv2 ===== | + | ===== [[RFC5998|RFC 5998]], An Extension for EAP-Only Authentication in IKEv2 ===== |
(S, September 2010) | (S, September 2010) | ||
IKEv2 allows an initiator to use EAP for peer authentication, but | IKEv2 allows an initiator to use EAP for peer authentication, but | ||
requires the responder to authenticate through the use of a digital | requires the responder to authenticate through the use of a digital | ||
− | signature. | + | signature. [[RFC5998]] extends IKEv2 so that EAP methods that provide |
mutual authentication and key agreement can also be used to provide | mutual authentication and key agreement can also be used to provide | ||
peer authentication for the responder. This optional extension | peer authentication for the responder. This optional extension | ||
Line 759: | Line 759: | ||
procedures and interpretations to mitigate those problems. | procedures and interpretations to mitigate those problems. | ||
− | ===== RFC 4809, Requirements for an IPsec Certificate Management ===== | + | ===== [[RFC4809|RFC 4809]], Requirements for an IPsec Certificate Management ===== |
Profile (I, February 2007) | Profile (I, February 2007) | ||
− | + | [[RFC4809]] enumerates requirements for Public Key Certificate (PKC) | |
lifecycle transactions between different VPN System and PKI System | lifecycle transactions between different VPN System and PKI System | ||
products in order to better enable large scale, PKI-enabled IPsec | products in order to better enable large scale, PKI-enabled IPsec | ||
Line 770: | Line 770: | ||
These optional requirements apply to both IKEv1 and IKEv2. | These optional requirements apply to both IKEv1 and IKEv2. | ||
− | ===== RFC 4945, The Internet IP Security PKI Profile of ===== | + | ===== [[RFC4945|RFC 4945]], The Internet IP Security PKI Profile of ===== |
IKEv1/ISAKMP, IKEv2, and PKIX (S, August 2007) | IKEv1/ISAKMP, IKEv2, and PKIX (S, August 2007) | ||
− | + | [[RFC4945]] defines a profile of the IKE and Public Key Infrastructure | |
using X.509 (PKIX) frameworks in order to provide an agreed-upon | using X.509 (PKIX) frameworks in order to provide an agreed-upon | ||
standard for using PKI technology in the context of IPsec. It also | standard for using PKI technology in the context of IPsec. It also | ||
Line 782: | Line 782: | ||
both IKEv1 and IKEv2. | both IKEv1 and IKEv2. | ||
− | ===== RFC 4806, Online Certificate Status Protocol (OCSP) Extensions ===== | + | ===== [[RFC4806|RFC 4806]], Online Certificate Status Protocol (OCSP) Extensions ===== |
to IKEv2 (S, February 2007) | to IKEv2 (S, February 2007) | ||
When certificates are used with IKEv2, the communicating peers need a | When certificates are used with IKEv2, the communicating peers need a | ||
mechanism to determine the revocation status of the peer's | mechanism to determine the revocation status of the peer's | ||
− | certificate. OCSP is one such mechanism. | + | certificate. OCSP is one such mechanism. [[RFC4806]] defines the |
"OCSP Content" extension to IKEv2. This document is applicable when | "OCSP Content" extension to IKEv2. This document is applicable when | ||
OCSP is desired and security policy (e.g., firewall policy) prevents | OCSP is desired and security policy (e.g., firewall policy) prevents | ||
Line 796: | Line 796: | ||
==== Dead Peer Detection ==== | ==== Dead Peer Detection ==== | ||
− | ===== RFC 3706, A Traffic-Based Method of Detecting Dead Internet ===== | + | ===== [[RFC3706|RFC 3706]], A Traffic-Based Method of Detecting Dead Internet ===== |
Key Exchange (IKE) Peers (I, February 2004) | Key Exchange (IKE) Peers (I, February 2004) | ||
Line 802: | Line 802: | ||
the connectivity between the two peers to drop unexpectedly. But the | the connectivity between the two peers to drop unexpectedly. But the | ||
SAs can still remain until their lifetimes expire, resulting in the | SAs can still remain until their lifetimes expire, resulting in the | ||
− | packets getting tunneled into a "black hole". | + | packets getting tunneled into a "black hole". [[RFC3706]] describes an |
approach to detect peer liveliness without needing to send messages | approach to detect peer liveliness without needing to send messages | ||
at regular intervals. This RFC defines an optional extension to | at regular intervals. This RFC defines an optional extension to | ||
Line 825: | Line 825: | ||
configuration using IPsec configuration payloads. | configuration using IPsec configuration payloads. | ||
− | ===== RFC 4555, IKEv2 Mobility and Multihoming Protocol (MOBIKE) ===== | + | ===== [[RFC4555|RFC 4555]], IKEv2 Mobility and Multihoming Protocol (MOBIKE) ===== |
(S, June 2006) | (S, June 2006) | ||
Line 831: | Line 831: | ||
address pair that is used during the protocol execution when | address pair that is used during the protocol execution when | ||
establishing the IKEv2 SA. IPsec-related documents had no provision | establishing the IKEv2 SA. IPsec-related documents had no provision | ||
− | to change this pair after an IKE SA was created. | + | to change this pair after an IKE SA was created. [[RFC4555]] defines |
extensions to IKEv2 that enable an efficient management of IKE and | extensions to IKEv2 that enable an efficient management of IKE and | ||
IPsec Security Associations when a host possesses multiple IP | IPsec Security Associations when a host possesses multiple IP | ||
Line 837: | Line 837: | ||
time. | time. | ||
− | ===== RFC 4621, Design of the IKEv2 Mobility and Multihoming ===== | + | ===== [[RFC4621|RFC 4621]], Design of the IKEv2 Mobility and Multihoming ===== |
(MOBIKE) Protocol (I, August 2006) | (MOBIKE) Protocol (I, August 2006) | ||
− | + | [[RFC4621]] discusses the involved network entities and the | |
relationship between IKEv2 signaling and information provided by | relationship between IKEv2 signaling and information provided by | ||
other protocols. It also records design decisions for the MOBIKE | other protocols. It also records design decisions for the MOBIKE | ||
Line 846: | Line 846: | ||
working group. | working group. | ||
− | ===== RFC 5266, Secure Connectivity and Mobility Using Mobile IPv4 ===== | + | ===== [[RFC5266|RFC 5266]], Secure Connectivity and Mobility Using Mobile IPv4 ===== |
and IKEv2 Mobility and Multihoming (MOBIKE) (B, June 2008) | and IKEv2 Mobility and Multihoming (MOBIKE) (B, June 2008) | ||
− | + | [[RFC5266]] describes a solution using Mobile IPv4 (MIPv4) and mobility | |
extensions to IKEv2 (MOBIKE) to provide secure connectivity and | extensions to IKEv2 (MOBIKE) to provide secure connectivity and | ||
mobility to enterprise users when they roam into untrusted networks. | mobility to enterprise users when they roam into untrusted networks. | ||
− | ===== RFC 5723, Internet Key Exchange Protocol Version 2 (IKEv2) ===== | + | ===== [[RFC5723|RFC 5723]], Internet Key Exchange Protocol Version 2 (IKEv2) ===== |
Session Resumption (S, January 2010) | Session Resumption (S, January 2010) | ||
− | + | [[RFC5723]] enables a remote client that has been disconnected from a | |
gateway to re-establish SAs with the gateway in an expedited manner, | gateway to re-establish SAs with the gateway in an expedited manner, | ||
without repeating the complete IKEv2 negotiation. This capability | without repeating the complete IKEv2 negotiation. This capability | ||
Line 862: | Line 862: | ||
IKEv2, not to IKEv1. | IKEv2, not to IKEv1. | ||
− | ===== RFC 5685, Re-direct Mechanism for the Internet Key Exchange ===== | + | ===== [[RFC5685|RFC 5685]], Re-direct Mechanism for the Internet Key Exchange ===== |
Protocol Version 2 (IKEv2) (S, November 2009) | Protocol Version 2 (IKEv2) (S, November 2009) | ||
− | + | [[RFC5685]] enables a gateway to securely redirect VPN clients to | |
another VPN gateway, either during or after the IKEv2 negotiation. | another VPN gateway, either during or after the IKEv2 negotiation. | ||
Possible reasons include, but are not limited to, an overloaded | Possible reasons include, but are not limited to, an overloaded | ||
Line 872: | Line 872: | ||
IKEv1. | IKEv1. | ||
− | ===== RFC 5739, IPv6 Configuration in Internet Key Exchange Protocol ===== | + | ===== [[RFC5739|RFC 5739]], IPv6 Configuration in Internet Key Exchange Protocol ===== |
Version 2 (IKEv2) (E, February 2010) | Version 2 (IKEv2) (E, February 2010) | ||
Line 879: | Line 879: | ||
configuration payloads. For an IPv6 client, the assignment of a | configuration payloads. For an IPv6 client, the assignment of a | ||
single address is not sufficient to enable full-fledged IPv6 | single address is not sufficient to enable full-fledged IPv6 | ||
− | communications. | + | communications. [[RFC5739]] proposes several solutions that might |
remove this limitation. This optional extension applies only to | remove this limitation. This optional extension applies only to | ||
IKEv2, not to IKEv1. | IKEv2, not to IKEv1. | ||
Line 891: | Line 891: | ||
describes a cryptographic algorithm, this roadmap will classify its | describes a cryptographic algorithm, this roadmap will classify its | ||
requirement level for each protocol, as either MUST, SHOULD, or MAY | requirement level for each protocol, as either MUST, SHOULD, or MAY | ||
− | + | [[RFC2119]]; SHOULD+, SHOULD-, or MUST- [[RFC4835]]; optional; undefined; | |
or N/A (not applicable). A designation of "optional" means that the | or N/A (not applicable). A designation of "optional" means that the | ||
algorithm meets the two basic requirements, but its use is not | algorithm meets the two basic requirements, but its use is not | ||
Line 933: | Line 933: | ||
deprecated (SHOULD NOT) algorithms. For IPsec-v2, this is included | deprecated (SHOULD NOT) algorithms. For IPsec-v2, this is included | ||
in the base protocol RFC. That was originally the case for IKEv1, | in the base protocol RFC. That was originally the case for IKEv1, | ||
− | but IKEv1's algorithm requirements were updated in | + | but IKEv1's algorithm requirements were updated in [[RFC4109]]. |
− | ==== RFC 4835, Cryptographic Algorithm Implementation Requirements ==== | + | ==== [[RFC4835|RFC 4835]], Cryptographic Algorithm Implementation Requirements ==== |
for Encapsulating Security Payload (ESP) and Authentication | for Encapsulating Security Payload (ESP) and Authentication | ||
Header (AH) (S, April 2007) | Header (AH) (S, April 2007) | ||
− | + | [[RFC4835]] specifies the encryption and integrity-protection | |
algorithms for IPsec (both versions). Algorithms for IPsec-v2 were | algorithms for IPsec (both versions). Algorithms for IPsec-v2 were | ||
− | originally defined in | + | originally defined in [[RFC2402]] and [[RFC2406]]. [[RFC4305]] obsoleted |
− | those requirements, and was in turn obsoleted by | + | those requirements, and was in turn obsoleted by [[RFC4835]]. |
− | Therefore, | + | Therefore, [[RFC4835]] applies to IPsec-v2 as well as IPsec-v3. |
Combined mode algorithms are mentioned, but not assigned a | Combined mode algorithms are mentioned, but not assigned a | ||
requirement level. | requirement level. | ||
− | ==== RFC 4307, Cryptographic Algorithms for Use in the Internet Key ==== | + | ==== [[RFC4307|RFC 4307]], Cryptographic Algorithms for Use in the Internet Key ==== |
Exchange Version 2 (IKEv2) (S, December 2005) | Exchange Version 2 (IKEv2) (S, December 2005) | ||
− | + | [[RFC4307]] specifies the encryption and integrity-protection | |
algorithms used by IKEv2 to protect its own traffic, the Diffie- | algorithms used by IKEv2 to protect its own traffic, the Diffie- | ||
Hellman (DH) groups used within IKEv2, and the pseudorandom functions | Hellman (DH) groups used within IKEv2, and the pseudorandom functions | ||
used by IKEv2 to generate keys, nonces, and other random values. | used by IKEv2 to generate keys, nonces, and other random values. | ||
− | + | [[RFC4307]] contains conflicting requirements for IKEv2 encryption and | |
integrity-protection algorithms. Where there are contradictory | integrity-protection algorithms. Where there are contradictory | ||
requirements, this document takes its requirement levels from Section | requirements, this document takes its requirement levels from Section | ||
Line 962: | Line 962: | ||
Transform Type 2 Algorithms". | Transform Type 2 Algorithms". | ||
− | ==== RFC 4109, Algorithms for Internet Key Exchange version 1 (IKEv1) ==== | + | ==== [[RFC4109|RFC 4109]], Algorithms for Internet Key Exchange version 1 (IKEv1) ==== |
(S, May 2005) | (S, May 2005) | ||
− | + | [[RFC4109]] updates IKEv1's algorithm specifications, which were | |
− | originally defined in | + | originally defined in [[RFC2409]]. It specifies the encryption and |
integrity-protection algorithms used by IKEv1 to protect its own | integrity-protection algorithms used by IKEv1 to protect its own | ||
traffic; the Diffie-Hellman (DH) groups used within IKEv1; the hash | traffic; the Diffie-Hellman (DH) groups used within IKEv1; the hash | ||
Line 991: | Line 991: | ||
algorithm. | algorithm. | ||
− | DES, as described in | + | DES, as described in [[RFC2405]], was originally a required algorithm |
for IKEv1 and ESP-v2. Since the use of DES is now deprecated, this | for IKEv1 and ESP-v2. Since the use of DES is now deprecated, this | ||
− | roadmap does not include | + | roadmap does not include [[RFC2405]]. |
− | ==== RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec ==== | + | ==== [[RFC2410|RFC 2410]], The NULL Encryption Algorithm and Its Use With IPsec ==== |
(S, November 1998) | (S, November 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 | algorithm (i.e., using ESP without encryption). In order for IKE to | ||
negotiate the selection of the NULL encryption algorithm for use in | negotiate the selection of the NULL encryption algorithm for use in | ||
an ESP SA, an identifying IANA number is needed. This number (the | 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 | value 11 for ESP_NULL) is found on the IANA registries for both IKEv1 | ||
− | and IKEv2, but it is not mentioned in | + | and IKEv2, but it is not mentioned in [[RFC2410]]. |
Requirement levels for ESP-NULL: | Requirement levels for ESP-NULL: | ||
Line 1,009: | Line 1,009: | ||
IKEv1 - N/A | IKEv1 - N/A | ||
IKEv2 - N/A | IKEv2 - N/A | ||
− | ESP-v2 - MUST | + | ESP-v2 - MUST [[RFC4835]] |
− | ESP-v3 - MUST | + | ESP-v3 - MUST [[RFC4835]] |
− | NOTE: RFC 4307 erroneously classifies ESP-NULL as MAY for IKEv2; this | + | NOTE: [[RFC4307|RFC 4307]] erroneously classifies ESP-NULL as MAY for IKEv2; this |
− | has been corrected in an errata submission for RFC 4307. | + | has been corrected in an errata submission for [[RFC4307|RFC 4307]]. |
− | ==== RFC 2451, The ESP CBC-Mode Cipher Algorithms (S, November 1998) ==== | + | ==== [[RFC2451|RFC 2451]], The ESP CBC-Mode Cipher Algorithms (S, November 1998) ==== |
− | + | [[RFC2451]] describes how to use encryption algorithms in cipher-block- | |
chaining (CBC) mode to encrypt IKE and ESP traffic. It specifically | chaining (CBC) mode to encrypt IKE and ESP traffic. It specifically | ||
mentions Blowfish, CAST-128, Triple DES (3DES), International Data | mentions Blowfish, CAST-128, Triple DES (3DES), International Data | ||
Line 1,028: | Line 1,028: | ||
Requirement levels for 3DES-CBC: | Requirement levels for 3DES-CBC: | ||
− | IKEv1 - MUST | + | IKEv1 - MUST [[RFC4109]] |
− | IKEv2 - MUST- | + | IKEv2 - MUST- [[RFC4307]] |
− | ESP-v2 - MUST | + | ESP-v2 - MUST [[RFC4835]] |
− | ESP-v3 - MUST- | + | ESP-v3 - MUST- [[RFC4835]] |
Requirement levels for other CBC algorithms (Blowfish, CAST, IDEA, | Requirement levels for other CBC algorithms (Blowfish, CAST, IDEA, | ||
Line 1,041: | Line 1,041: | ||
ESP-v3 - optional | ESP-v3 - optional | ||
− | ==== RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec ==== | + | ==== [[RFC3602|RFC 3602]], The AES-CBC Cipher Algorithm and Its Use with IPsec ==== |
(S, September. 2003) | (S, September. 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. | 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 | 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 | that is sent in the packet along with the encrypted data, and | ||
keysizes of 128, 192 and 256 bits. If AES-CBC is implemented, | keysizes of 128, 192 and 256 bits. If AES-CBC is implemented, | ||
− | 128-bit keys are MUST; the other sizes are MAY. | + | 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 | 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. | defined for AES-CBC, so IKE negotiations need to specify the keysize. | ||
Line 1,055: | Line 1,055: | ||
Requirement levels for AES-CBC with 128-bit keys: | Requirement levels for AES-CBC with 128-bit keys: | ||
− | IKEv1 - SHOULD | + | IKEv1 - SHOULD [[RFC4109]] |
− | IKEv2 - SHOULD+ | + | IKEv2 - SHOULD+ [[RFC4307]] |
− | ESP-v2 - MUST | + | ESP-v2 - MUST [[RFC4835]] |
− | ESP-v3 - MUST | + | ESP-v3 - MUST [[RFC4835]] |
Requirement levels for AES-CBC with 192- or 256-bit keys: | Requirement levels for AES-CBC with 192- or 256-bit keys: | ||
Line 1,067: | Line 1,067: | ||
ESP-v3 - optional | ESP-v3 - optional | ||
− | ==== RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode ==== | + | ==== [[RFC3686|RFC 3686]], Using Advanced Encryption Standard (AES) Counter Mode ==== |
With IPsec Encapsulating Security Payload (ESP) | With IPsec Encapsulating Security Payload (ESP) | ||
(S, January 2004) | (S, January 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 | ESP traffic. AES-CTR is a stream cipher with a 32-bit random nonce | ||
(1/SA) and a 64-bit IV. If AES-CTR is implemented, 128-bit keys are | (1/SA) and a 64-bit IV. If AES-CTR is implemented, 128-bit keys are | ||
Line 1,083: | Line 1,083: | ||
IKEv1 - undefined (no IANA #) | IKEv1 - undefined (no IANA #) | ||
− | IKEv2 - optional | + | IKEv2 - optional [[RFC5930]] |
− | ESP-v2 - SHOULD | + | ESP-v2 - SHOULD [[RFC4835]] |
− | ESP-v3 - SHOULD | + | ESP-v3 - SHOULD [[RFC4835]] |
− | ==== RFC 5930, Using Advanced Encryption Standard Counter Mode (AES- ==== | + | ==== [[RFC5930|RFC 5930]], Using Advanced Encryption Standard Counter Mode (AES- ==== |
CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol | CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol | ||
(I, July 210). | (I, July 210). | ||
− | + | [[RFC5930]] extends [[RFC3686]] to enable the use of AES-CTR to provide | |
encryption and integrity protection for IKEv2 messages. | encryption and integrity protection for IKEv2 messages. | ||
− | ==== RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec ==== | + | ==== [[RFC4312|RFC 4312]], The Camellia Cipher Algorithm and Its Use with IPsec ==== |
(S, December 2005) | (S, December 2005) | ||
− | + | [[RFC4312]] describes how to use Camellia in cipher block chaining | |
(CBC) mode to encrypt IKE and ESP traffic. Camellia-CBC is a block- | (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 in the | mode cipher with a 128-bit blocksize, a random IV that is sent in the | ||
Line 1,103: | Line 1,103: | ||
256 bits. If Camellia-CBC is implemented, 128-bit keys are MUST; the | 256 bits. If Camellia-CBC is implemented, 128-bit keys are MUST; the | ||
− | other sizes are MAY. | + | 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 | and IPsec-v2. A single IANA value is defined for Camellia-CBC, so | ||
IKEv1 negotiations need to specify the keysize. | IKEv1 negotiations need to specify the keysize. | ||
− | ==== RFC 5529, Modes of Operation for Camellia for Use with IPsec ==== | + | ==== [[RFC5529|RFC 5529]], Modes of Operation for Camellia for Use with IPsec ==== |
(S, April 2009) | (S, April 2009) | ||
− | + | [[RFC5529]] describes the use of the Camellia block-cipher algorithm in | |
conjunction with several different modes of operation. It describes | conjunction with several different modes of operation. It describes | ||
the use of Camellia in cipher block chaining (CBC) mode and counter | the use of Camellia in cipher block chaining (CBC) mode and counter | ||
Line 1,121: | Line 1,121: | ||
description of block-mode encryption, provide enough detail to allow | description of block-mode encryption, provide enough detail to allow | ||
the use of Camellia-CBC algorithms within IKEv2. All three modes can | the use of Camellia-CBC algorithms within IKEv2. All three modes can | ||
− | use keys of length 128 bits, 192 bits, or 256 bits. | + | use keys of length 128 bits, 192 bits, or 256 bits. [[RFC5529]] |
includes IANA values for use in IKEv2 and IPsec-v3. A single IANA | includes IANA values for use in IKEv2 and IPsec-v3. A single IANA | ||
value is defined for each Camellia mode, so IKEv2 negotiations need | value is defined for each Camellia mode, so IKEv2 negotiations need | ||
Line 1,147: | Line 1,147: | ||
ESP-v3 - optional | ESP-v3 - optional | ||
− | ==== RFC 4196, The SEED Cipher Algorithm and Its Use with IPsec ==== | + | ==== [[RFC4196|RFC 4196]], The SEED Cipher Algorithm and Its Use with IPsec ==== |
(S, October 2005) | (S, October 2005) | ||
− | + | [[RFC4196]] describes how to use SEED in cipher block chaining (CBC) | |
mode to encrypt ESP traffic. It describes how to use IKEv1 to | mode to encrypt ESP traffic. It describes how to use IKEv1 to | ||
negotiate a SEED-ESP SA, but does not define the use of SEED to | negotiate a SEED-ESP SA, but does not define the use of SEED to | ||
protect IKEv1 traffic. SEED-CBC is a block-mode cipher with a | protect IKEv1 traffic. SEED-CBC is a block-mode cipher with a | ||
128-bit blocksize, a random IV that is sent in the packet along with | 128-bit blocksize, a random IV that is sent in the packet along with | ||
− | the encrypted data, and a keysize of 128 bits. | + | the encrypted data, and a keysize of 128 bits. [[RFC4196]] includes |
− | IANA values for use in IKEv1 and IPsec-v2. | + | IANA values for use in IKEv1 and IPsec-v2. [[RFC4196]] includes test |
data. | data. | ||
Line 1,196: | Line 1,196: | ||
used for IKEv2 SAs and for IPsec SAs. The non-truncated version is | used for IKEv2 SAs and for IPsec SAs. The non-truncated version is | ||
− | reserved for use by the Fibre Channel protocol | + | reserved for use by the Fibre Channel protocol [[RFC4595]]. For the |
other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC, and HMAC- | other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC, and HMAC- | ||
RIPEMD), only the truncated version can be used for both IKEv2 and | RIPEMD), only the truncated version can be used for both IKEv2 and | ||
IPsec-v3 SAs. | IPsec-v3 SAs. | ||
− | One other algorithm, AES-GMAC | + | One other algorithm, AES-GMAC [[RFC4543]], can also provide integrity |
protection. It has two versions: an integrity-protection algorithm | protection. It has two versions: an integrity-protection algorithm | ||
for use within AH-v3, and a combined mode algorithm with null | for use within AH-v3, and a combined mode algorithm with null | ||
− | encryption for use within ESP-v3. | + | encryption for use within ESP-v3. [[RFC4543]] is described in Section |
5.4, "Combined Mode Algorithms". | 5.4, "Combined Mode Algorithms". | ||
− | ==== RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH ==== | + | ==== [[RFC2404|RFC 2404]], The Use of HMAC-SHA-1-96 within ESP and AH ==== |
(S, November 1998) | (S, November 1998) | ||
− | + | [[RFC2404]] describes HMAC-SHA-1, an integrity-protection algorithm | |
with a 512-bit blocksize, and a 160-bit key and Integrity Check Value | 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 | (ICV). For use within IPsec, the ICV is truncated to 96 bits. This | ||
Line 1,217: | Line 1,217: | ||
Requirement levels for HMAC-SHA-1: | Requirement levels for HMAC-SHA-1: | ||
− | IKEv1 - MUST | + | IKEv1 - MUST [[RFC4109]] |
− | IKEv2 - MUST | + | IKEv2 - MUST [[RFC4307]] |
− | IPsec-v2 - MUST | + | IPsec-v2 - MUST [[RFC4835]] |
− | IPsec-v3 - MUST | + | IPsec-v3 - MUST [[RFC4835]] |
− | ==== RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec ==== | + | ==== [[RFC3566|RFC 3566]], The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec ==== |
(S, September 2003) | (S, September 2003) | ||
− | + | [[RFC3566]] describes AES-XCBC-MAC, a variant of CBC-MAC, which is | |
secure for messages of varying lengths (unlike classic CBC-MAC). It | secure for messages of varying lengths (unlike classic CBC-MAC). It | ||
is an integrity-protection algorithm with a 128-bit blocksize and a | 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 | 128-bit key and ICV. For use within IPsec, the ICV is truncated to | ||
− | 96 bits. | + | 96 bits. [[RFC3566]] includes test data. |
Requirement levels for AES-XCBC-MAC: | Requirement levels for AES-XCBC-MAC: | ||
Line 1,235: | Line 1,235: | ||
IKEv1 - undefined (no RFC) | IKEv1 - undefined (no RFC) | ||
IKEv2 - optional | IKEv2 - optional | ||
− | IPsec-v2 - SHOULD+ | + | IPsec-v2 - SHOULD+ [[RFC4835]] |
− | IPsec-v3 - SHOULD+ | + | IPsec-v3 - SHOULD+ [[RFC4835]] |
− | ==== RFC 4868, Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 ==== | + | ==== [[RFC4868|RFC 4868]], Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 ==== |
with IPsec (S, May 2007) | 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-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-384 has a 1024-bit blocksize and a 384-bit key and ICV. | ||
Line 1,258: | Line 1,258: | ||
IPsec-v3 - optional | IPsec-v3 - optional | ||
− | ==== RFC 2403, The Use of HMAC-MD5-96 within ESP and AH ==== | + | ==== [[RFC2403|RFC 2403]], The Use of HMAC-MD5-96 within ESP and AH ==== |
(S, November 1998) | (S, November 1998) | ||
− | + | [[RFC2403]] describes HMAC-MD5, an integrity-protection algorithm with | |
a 512-bit blocksize and a 128-bit key and Integrity Check Value | 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 | (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 | was a required algorithm for IKEv1 and IPsec-v2. The use of plain | ||
− | MD5 is now deprecated, but | + | MD5 is now deprecated, but [[RFC4835]] states: "Weaknesses have become |
apparent in MD5; however, these should not affect the use of MD5 with | apparent in MD5; however, these should not affect the use of MD5 with | ||
HMAC". | HMAC". | ||
Line 1,271: | Line 1,271: | ||
Requirement levels for HMAC-MD5: | Requirement levels for HMAC-MD5: | ||
− | IKEv1 - MAY | + | IKEv1 - MAY [[RFC4109]] |
− | IKEv2 - optional | + | IKEv2 - optional [[RFC4307]] |
− | IPsec-v2 - MAY | + | IPsec-v2 - MAY [[RFC4835]] |
− | IPsec-v3 - MAY | + | IPsec-v3 - MAY [[RFC4835]] |
− | ==== RFC 4494, The AES-CMAC-96 Algorithm and Its Use with IPsec ==== | + | ==== [[RFC4494|RFC 4494]], The AES-CMAC-96 Algorithm and Its Use with IPsec ==== |
(S, June 2006) | (S, June 2006) | ||
− | + | [[RFC4494]] describes AES-CMAC, another variant of CBC-MAC, which is | |
secure for messages of varying lengths. It is an integrity- | secure for messages of varying lengths. It is an integrity- | ||
protection algorithm with a 128-bit blocksize and 128-bit key and | protection algorithm with a 128-bit blocksize and 128-bit key and | ||
ICV. For use within IPsec, the ICV is truncated to 96 bits. | ICV. For use within IPsec, the ICV is truncated to 96 bits. | ||
− | + | [[RFC4494]] includes test data. | |
Requirement levels for AES-CMAC: | Requirement levels for AES-CMAC: | ||
Line 1,292: | Line 1,292: | ||
IPsec-v3 - optional | IPsec-v3 - optional | ||
− | ==== RFC 2857, The Use of HMAC-RIPEMD-160-96 within ESP and AH ==== | + | ==== [[RFC2857|RFC 2857]], The Use of HMAC-RIPEMD-160-96 within ESP and AH ==== |
(S, June 2000) | (S, June 2000) | ||
− | + | [[RFC2857]] describes HMAC-RIPEMD, an integrity-protection algorithm | |
with a 512-bit blocksize and a 160-bit key and ICV. For use within | with a 512-bit blocksize and a 160-bit key and ICV. For use within | ||
IPsec, the ICV is truncated to 96 bits. | IPsec, the ICV is truncated to 96 bits. | ||
Line 1,306: | Line 1,306: | ||
IPsec-v3 - optional (but no IANA #, so cannot be negotiated by IKE) | IPsec-v3 - optional (but no IANA #, so cannot be negotiated by IKE) | ||
− | ==== RFC 4894, Use of Hash Algorithms in Internet Key Exchange (IKE) ==== | + | ==== [[RFC4894|RFC 4894]], Use of Hash Algorithms in Internet Key Exchange (IKE) ==== |
and IPsec (I, May 2007) | and IPsec (I, May 2007) | ||
− | In light of recent attacks on MD5 and SHA-1, | + | In light of recent attacks on MD5 and SHA-1, [[RFC4894]] examines |
whether it is necessary to replace the hash functions currently used | whether it is necessary to replace the hash functions currently used | ||
by IKE and IPsec for key generation, integrity protection, digital | by IKE and IPsec for key generation, integrity protection, digital | ||
signatures, or PKIX certificates. It concludes that the algorithms | signatures, or PKIX certificates. It concludes that the algorithms | ||
− | recommended for IKEv2 | + | recommended for IKEv2 [[RFC4307]] and IPsec-v3 [[RFC4305]] are not |
currently susceptible to any known attacks. Nonetheless, it suggests | currently susceptible to any known attacks. Nonetheless, it suggests | ||
− | that implementors add support for AES-XCBC-MAC-96 | + | that implementors add support for AES-XCBC-MAC-96 [[RFC3566]], AES- |
− | XCBC-PRF-128 | + | XCBC-PRF-128 [[RFC4434]], and HMAC-SHA-256, -384, and -512 [[RFC4868]] |
for future use. It also suggests that IKEv2 implementors add support | for future use. It also suggests that IKEv2 implementors add support | ||
for PKIX certificates signed with SHA-256, -384, and -512. | for PKIX certificates signed with SHA-256, -384, and -512. | ||
Line 1,326: | Line 1,326: | ||
of algorithms for different SAs. In ESP-v3, a new class of | of algorithms for different SAs. In ESP-v3, a new class of | ||
algorithms was introduced, in which a single algorithm can provide | algorithms was introduced, in which a single algorithm can provide | ||
− | both encryption and integrity protection. | + | both encryption and integrity protection. [[RFC5996]] describes how |
IKEv2 can negotiate combined mode algorithms to be used in ESP-v3 | IKEv2 can negotiate combined mode algorithms to be used in ESP-v3 | ||
− | SAs. | + | SAs. [[RFC5282]] adds that capability to IKEv2, enabling IKEv2 to |
negotiate and use combined mode algorithms for its own traffic. When | negotiate and use combined mode algorithms for its own traffic. When | ||
properly designed, these algorithms can provide increased efficiency | properly designed, these algorithms can provide increased efficiency | ||
Line 1,340: | Line 1,340: | ||
added to the IKEv1 registry. | added to the IKEv1 registry. | ||
− | ==== RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode with ==== | + | ==== [[RFC4309|RFC 4309]], Using Advanced Encryption Standard (AES) CCM Mode with ==== |
IPsec Encapsulating Security Payload (ESP) (S, December 2005) | IPsec Encapsulating Security Payload (ESP) (S, December 2005) | ||
− | + | [[RFC4309]] describes how to use AES in counter with CBC-MAC (CCM) | |
mode, a combined algorithm, to encrypt and integrity protect ESP | mode, a combined algorithm, to encrypt and integrity protect ESP | ||
traffic. AES-CCM is a block-mode cipher with a 128-bit blocksize; a | traffic. AES-CCM is a block-mode cipher with a 128-bit blocksize; a | ||
Line 1,353: | Line 1,353: | ||
the key-generation process. Reuse of the IV with the same key | the key-generation process. Reuse of the IV with the same key | ||
compromises the data's security; thus, AES-CCM should not be used | compromises the data's security; thus, AES-CCM should not be used | ||
− | with manual keying. | + | with manual keying. [[RFC4309]] includes IANA values that IKE can use |
to negotiate ESP-v3 SAs. Each of the three ICV lengths has its own | to negotiate ESP-v3 SAs. Each of the three ICV lengths has its own | ||
IANA value, but IKE negotiations need to specify the keysize. | IANA value, but IKE negotiations need to specify the keysize. | ||
− | + | [[RFC4309]] includes test data. [[RFC4309]] describes how IKE can | |
− | negotiate the use of AES-CCM to use in an ESP SA. | + | negotiate the use of AES-CCM to use in an ESP SA. [[RFC5282]] extends |
this to the use of AES-CCM to protect an IKEv2 SA. | this to the use of AES-CCM to protect an IKEv2 SA. | ||
Line 1,365: | Line 1,365: | ||
IKEv2 - optional | IKEv2 - optional | ||
ESP-v2 - N/A | ESP-v2 - N/A | ||
− | ESP-v3 - optional | + | ESP-v3 - optional [[RFC4835]] |
NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but | NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but | ||
Line 1,372: | Line 1,372: | ||
Section 5.4), it is not part of the protocol. | Section 5.4), it is not part of the protocol. | ||
− | ==== RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec ==== | + | ==== [[RFC4106|RFC 4106]], The Use of Galois/Counter Mode (GCM) in IPsec ==== |
Encapsulating Security Payload (ESP) (S, June 2005) | Encapsulating Security Payload (ESP) (S, June 2005) | ||
− | + | [[RFC4106]] describes how to use AES in Galois/Counter (GCM) mode, a | |
combined algorithm, to encrypt and integrity protect ESP traffic. | combined algorithm, to encrypt and integrity protect ESP traffic. | ||
AES-GCM is a block-mode cipher with a 128-bit blocksize; a random IV | AES-GCM is a block-mode cipher with a 128-bit blocksize; a random IV | ||
Line 1,385: | Line 1,385: | ||
key-generation process. Reuse of the IV with the same key | key-generation process. Reuse of the IV with the same key | ||
compromises the data's security; thus, AES-GCM should not be used | compromises the data's security; thus, AES-GCM should not be used | ||
− | with manual keying. | + | with manual keying. [[RFC4106]] includes IANA values that IKE can use |
to negotiate ESP-v3 SAs. Each of the three ICV lengths has its own | to negotiate ESP-v3 SAs. Each of the three ICV lengths has its own | ||
IANA value, but IKE negotiations need to specify the keysize. | IANA value, but IKE negotiations need to specify the keysize. | ||
− | + | [[RFC4106]] includes test data. [[RFC4106]] describes how IKE can | |
− | negotiate the use of AES-GCM to use in an ESP SA. | + | negotiate the use of AES-GCM to use in an ESP SA. [[RFC5282]] extends |
this to the use of AES-GCM to protect an IKEv2 SA. | this to the use of AES-GCM to protect an IKEv2 SA. | ||
Line 1,398: | Line 1,398: | ||
IKEv2 - optional | IKEv2 - optional | ||
ESP-v2 - N/A | ESP-v2 - N/A | ||
− | ESP-v3 - optional | + | ESP-v3 - optional [[RFC4835]] |
NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but | NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but | ||
Line 1,405: | Line 1,405: | ||
Section 5.4), it is not part of the protocol. | Section 5.4), it is not part of the protocol. | ||
− | ==== RFC 4543, The Use of Galois Message Authentication Code (GMAC) ==== | + | ==== [[RFC4543|RFC 4543]], The Use of Galois Message Authentication Code (GMAC) ==== |
in IPsec ESP and AH (S, May 2006) | 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 without encryption. It has two versions: an integrity- | ||
protection algorithm for use within AH, and a combined mode algorithm | protection algorithm for use within AH, and a combined mode algorithm | ||
Line 1,435: | Line 1,435: | ||
Section 5.4), it is not part of the protocol. | Section 5.4), it is not part of the protocol. | ||
− | ==== RFC 5282, Using Authenticated Encryption Algorithms with the ==== | + | ==== [[RFC5282|RFC 5282]], Using Authenticated Encryption Algorithms with the ==== |
Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) | Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) | ||
Protocol (S, August 2008) | Protocol (S, August 2008) | ||
− | + | [[RFC5282]] extends [[RFC4309]] and [[RFC4106]] to enable the use of AES- | |
CCM and AES-GCM to provide encryption and integrity protection for | CCM and AES-GCM to provide encryption and integrity protection for | ||
IKEv2 messages. | IKEv2 messages. | ||
Line 1,459: | Line 1,459: | ||
protection to the IKE SA's traffic. | protection to the IKE SA's traffic. | ||
− | IKEv1's approach is more complicated. IKEv1 | + | IKEv1's approach is more complicated. IKEv1 [[RFC2409]] does not |
specify any PRF algorithms. For each IKEv1 SA, the peers agree on an | specify any PRF algorithms. For each IKEv1 SA, the peers agree on an | ||
unkeyed hash function (e.g., SHA-1). IKEv1 uses the HMAC version of | unkeyed hash function (e.g., SHA-1). IKEv1 uses the HMAC version of | ||
Line 1,468: | Line 1,468: | ||
Requirement levels for PRF-HMAC-SHA1: | Requirement levels for PRF-HMAC-SHA1: | ||
− | IKEv1 - MUST | + | IKEv1 - MUST [[RFC4109]] |
− | IKEv2 - MUST | + | IKEv2 - MUST [[RFC4307]] |
Requirement levels for PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF- | Requirement levels for PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF- | ||
HMAC-SHA-512: | HMAC-SHA-512: | ||
− | IKEv1 - optional | + | IKEv1 - optional [[RFC4868]] |
− | IKEv2 - optional | + | IKEv2 - optional [[RFC4868]] |
− | ==== RFC 4434, The AES-XCBC-PRF-128 Algorithm for the Internet Key ==== | + | ==== [[RFC4434|RFC 4434]], The AES-XCBC-PRF-128 Algorithm for the Internet Key ==== |
Exchange Protocol (IKE) (S, February 2006) | Exchange Protocol (IKE) (S, February 2006) | ||
− | + | [[RFC3566]] defines AES-XCBC-MAC-96, which is used for integrity | |
− | protection within IKE and IPsec. | + | protection within IKE and IPsec. [[RFC4434]] enables the use of AES- |
XCBC-MAC as a PRF within IKE. The PRF differs from the integrity- | XCBC-MAC as a PRF within IKE. The PRF differs from the integrity- | ||
Line 1,487: | Line 1,487: | ||
to 96 bits, and it accepts a variable-length key, which is modified | to 96 bits, and it accepts a variable-length key, which is modified | ||
(lengthened via padding or shortened through application of AES-XCBC) | (lengthened via padding or shortened through application of AES-XCBC) | ||
− | to a 128-bit key. | + | to a 128-bit key. [[RFC4434]] includes test data. |
Requirement levels for AES-XCBC-PRF: | Requirement levels for AES-XCBC-PRF: | ||
IKEv1 - undefined (no RFC) | IKEv1 - undefined (no RFC) | ||
− | IKEv2 - SHOULD+ | + | IKEv2 - SHOULD+ [[RFC4307]] |
− | NOTE: RFC 4109 erroneously classifies AES-XCBC-PRF as SHOULD for | + | NOTE: [[RFC4109|RFC 4109]] erroneously classifies AES-XCBC-PRF as SHOULD for |
− | IKEv1; this has been corrected in an errata submission for RFC 4109. | + | IKEv1; this has been corrected in an errata submission for [[RFC4109|RFC 4109]]. |
− | ==== RFC 4615, The Advanced Encryption Standard-Cipher-based Message ==== | + | ==== [[RFC4615|RFC 4615]], The Advanced Encryption Standard-Cipher-based Message ==== |
Authentication Code-Pseudorandom Function-128 (AES-CMAC-PRF-128) | Authentication Code-Pseudorandom Function-128 (AES-CMAC-PRF-128) | ||
Algorithm for the Internet Key Exchange Protocol (IKE) | Algorithm for the Internet Key Exchange Protocol (IKE) | ||
(S, August 2006) | (S, August 2006) | ||
− | + | [[RFC4615]] extends [[RFC4494]] to enable the use of AES-CMAC as a PRF | |
− | within IKEv2, in a manner analogous to that used by | + | within IKEv2, in a manner analogous to that used by [[RFC4434]] for |
AES-XCBC. | AES-XCBC. | ||
Line 1,513: | Line 1,513: | ||
=== Cryptographic Suites === | === Cryptographic Suites === | ||
− | ==== RFC 4308, Cryptographic Suites for IPsec (S, December 2005) ==== | + | ==== [[RFC4308|RFC 4308]], Cryptographic Suites for IPsec (S, December 2005) ==== |
An IKE negotiation consists of multiple cryptographic attributes, | An IKE negotiation consists of multiple cryptographic attributes, | ||
both for the IKE SA and for the IPsec SA. The number of possible | both for the IKE SA and for the IPsec SA. The number of possible | ||
combinations can pose a challenge to peers trying to find a common | combinations can pose a challenge to peers trying to find a common | ||
− | policy. To enhance interoperability, | + | policy. To enhance interoperability, [[RFC4308]] defines two pre- |
defined suites, consisting of combinations of algorithms that | defined suites, consisting of combinations of algorithms that | ||
comprise typical security policies. IKE/ESP suite "VPN-A" includes | comprise typical security policies. IKE/ESP suite "VPN-A" includes | ||
Line 1,527: | Line 1,527: | ||
not prevent the use of alternative combinations. | not prevent the use of alternative combinations. | ||
− | ==== RFC 4869, Suite B Cryptographic Suites for IPsec (I, May 2007) ==== | + | ==== [[RFC4869|RFC 4869]], Suite B Cryptographic Suites for IPsec (I, May 2007) ==== |
− | + | [[RFC4869]] adds four pre-defined suites, based upon the United States | |
National Security Agency's "Suite B" specifications, to those | National Security Agency's "Suite B" specifications, to those | ||
− | specified in | + | specified in [[RFC4308]]. IKE/ESP suites "Suite-B-GCM-128" and "Suite- |
B-GCM-256" include use of AES-CBC, AES-GCM, HMAC-SHA-256, or HMAC- | B-GCM-256" include use of AES-CBC, AES-GCM, HMAC-SHA-256, or HMAC- | ||
Line 1,537: | Line 1,537: | ||
IKE/AH suites "Suite-B-GMAC-128" and "Suite-B-GMAC-256" include use | IKE/AH 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 | of AES-CBC, AES-GMAC, HMAC-SHA-256, or HMAC-SHA-384, and 256-bit or | ||
− | 384-bit EC DH groups. While | + | 384-bit EC DH groups. While [[RFC4308]] does not specify a peer- |
− | authentication method, | + | authentication method, [[RFC4869]] mandates pre-shared key |
authentication for IKEv1; public key authentication using ECDSA is | authentication for IKEv1; public key authentication using ECDSA is | ||
recommended for IKEv1 and required for IKEv2. | recommended for IKEv1 and required for IKEv2. | ||
Line 1,549: | Line 1,549: | ||
IPsec SA. | IPsec SA. | ||
− | IKEv1 | + | IKEv1 [[RFC2409]] contains definitions of two DH MODP groups and two |
− | elliptic curve (EC) groups; IKEv2 | + | elliptic curve (EC) groups; IKEv2 [[RFC5996]] only references the MODP |
groups. The requirements levels of these groups are: | groups. The requirements levels of these groups are: | ||
Requirement levels for DH MODP group 1: | Requirement levels for DH MODP group 1: | ||
− | IKEv1 - MAY | + | IKEv1 - MAY [[RFC4109]] |
IKEv2 - optional | IKEv2 - optional | ||
Requirement levels for DH MODP group 2: | Requirement levels for DH MODP group 2: | ||
− | IKEv1 - MUST | + | IKEv1 - MUST [[RFC4109]] |
− | IKEv2 - MUST- | + | IKEv2 - MUST- [[RFC4307]] |
Requirement levels for EC groups 3-4: | Requirement levels for EC groups 3-4: | ||
− | IKEv1 - MAY | + | IKEv1 - MAY [[RFC4109]] |
IKEv2 - undefined (no IANA #) | IKEv2 - undefined (no IANA #) | ||
− | ==== RFC 3526, More Modular Exponential (MODP) Diffie-Hellman groups ==== | + | ==== [[RFC3526|RFC 3526]], More Modular Exponential (MODP) Diffie-Hellman groups ==== |
for Internet Key Exchange (IKE) (S, May 2003) | for Internet Key Exchange (IKE) (S, May 2003) | ||
− | + | [[RFC2409]] and [[RFC5996]] define two MODP DH groups (groups 1 and 2) | |
− | for use within IKE. | + | 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 | 14-18). Group 14 is a 2048-bit group that is strongly recommended | ||
for use in IKE. | for use in IKE. | ||
Line 1,578: | Line 1,578: | ||
Requirement levels for DH MODP group 14: | Requirement levels for DH MODP group 14: | ||
− | IKEv1 - SHOULD | + | IKEv1 - SHOULD [[RFC4109]] |
− | IKEv2 - SHOULD+ | + | IKEv2 - SHOULD+ [[RFC4307]] |
Requirement levels for DH MODP groups 5, 15-18: | Requirement levels for DH MODP groups 5, 15-18: | ||
− | IKEv1 - optional | + | IKEv1 - optional [[RFC4109]] |
IKEv2 - optional | IKEv2 - optional | ||
− | ==== RFC 4753, ECP Groups For IKE and IKEv2 (I, January 2007) ==== | + | ==== [[RFC4753|RFC 4753]], ECP Groups For IKE and IKEv2 (I, January 2007) ==== |
− | + | [[RFC4753]] defines three EC DH groups (groups 19-21) for use within | |
IKE. | IKE. | ||
Line 1,595: | Line 1,595: | ||
Requirement levels for DH EC groups 19-21: | Requirement levels for DH EC groups 19-21: | ||
− | IKEv1 - optional | + | IKEv1 - optional [[RFC4109]] |
IKEv2 - optional | IKEv2 - optional | ||
− | ==== RFC 5903, Elliptic Curve Groups modulo a Prime (ECP Groups) for ==== | + | ==== [[RFC5903|RFC 5903]], Elliptic Curve Groups modulo a Prime (ECP Groups) for ==== |
IKE and IKEv2 (I, June 2010) | IKE and IKEv2 (I, June 2010) | ||
− | + | [[RFC5903]] obsoletes [[RFC4753]], fixing an inconsistency in the DH | |
shared secret value. | shared secret value. | ||
− | ==== RFC 5114, Additional Diffie-Hellman Groups for Use with IETF ==== | + | ==== [[RFC5114|RFC 5114]], Additional Diffie-Hellman Groups for Use with IETF ==== |
Standards (I, January 2008) | Standards (I, January 2008) | ||
− | + | [[RFC5114]] defines five additional DH groups (MODP groups 22-24 and EC | |
groups 25-26) for use in IKE. It also includes three EC DH groups | groups 25-26) for use in IKE. It also includes three EC DH groups | ||
− | (groups 19-21) that were originally defined in | + | (groups 19-21) that were originally defined in [[RFC4753]]; however, |
− | the current specification for these groups is | + | the current specification for these groups is [[RFC5903]]. The IANA |
group numbers are specific to IKE, but the DH groups are intended for | group numbers are specific to IKE, but the DH groups are intended for | ||
use in multiple IETF protocols, including Transport Layer | use in multiple IETF protocols, including Transport Layer | ||
Line 1,623: | Line 1,623: | ||
== IPsec/IKE for Multicast == | == IPsec/IKE for Multicast == | ||
− | + | [[RFC4301]] describes IPsec processing for unicast and multicast | |
traffic. However, classical IPsec SAs provide point-to-point | traffic. However, classical IPsec SAs provide point-to-point | ||
protection; the security afforded by IPsec's cryptographic algorithms | protection; the security afforded by IPsec's cryptographic algorithms | ||
Line 1,637: | Line 1,637: | ||
a subset of the large variety of possible multicast groups. | a subset of the large variety of possible multicast groups. | ||
− | === RFC 3740, The Multicast Group Security Architecture === | + | === [[RFC3740|RFC 3740]], The Multicast Group Security Architecture === |
(I, March 2004) | (I, March 2004) | ||
− | + | [[RFC3740]] defines the multicast security architecture, which is used | |
to provide security for packets exchanged by large multicast groups. | to provide security for packets exchanged by large multicast groups. | ||
It defines the components of the architectural framework; discusses | It defines the components of the architectural framework; discusses | ||
Group Security Associations (GSAs), key management, data handling, | Group Security Associations (GSAs), key management, data handling, | ||
and security policies. Several existing protocols, including Group | and security policies. Several existing protocols, including Group | ||
− | DOI (GDOI) | + | DOI (GDOI) [[RFC3547]], Group Secure Association Key Management |
− | Protocol (GSAKMP) | + | Protocol (GSAKMP) [[RFC4535]], and Multimedia Internet KEYing (MIKEY) |
− | + | [[RFC3830]], satisfy the group key management requirements defined in | |
this document. Both the architecture and the components for | this document. Both the architecture and the components for | ||
Multicast Group Security differ from IPsec. | Multicast Group Security differ from IPsec. | ||
− | === RFC 5374, Multicast Extensions to the Security Architecture for === | + | === [[RFC5374|RFC 5374]], Multicast Extensions to the Security Architecture for === |
the Internet Protocol (S, November 2008) | the Internet Protocol (S, November 2008) | ||
− | + | [[RFC5374]] extends the security architecture defined in [[RFC4301]] to | |
apply to multicast traffic. It defines a new class of SAs (GSAs - | apply to multicast traffic. It defines a new class of SAs (GSAs - | ||
Group Security Associations) and additional databases used to apply | Group Security Associations) and additional databases used to apply | ||
IPsec protection to multicast traffic. It also describes revisions | IPsec protection to multicast traffic. It also describes revisions | ||
− | and additions to the processing algorithms in | + | and additions to the processing algorithms in [[RFC4301]]. |
− | === RFC 3547, The Group Domain of Interpretation (S, July 2003) === | + | === [[RFC3547|RFC 3547]], The Group Domain of Interpretation (S, July 2003) === |
− | GDOI | + | GDOI [[RFC3547]] extends IKEv1 so that it can be used to establish SAs |
to protect multicast traffic. This document defines additional | to protect multicast traffic. This document defines additional | ||
exchanges and payloads to be used for that purpose. | exchanges and payloads to be used for that purpose. | ||
− | === RFC 4046, Multicast Security (MSEC) Group Key Management === | + | === [[RFC4046|RFC 4046]], Multicast Security (MSEC) Group Key Management === |
Architecture (I, April 2005) | Architecture (I, April 2005) | ||
− | + | [[RFC4046]] sets out the general requirements and design principles for | |
protocols that are used for multicast key management. It does not go | protocols that are used for multicast key management. It does not go | ||
into the specifics of an individual protocol that can be used for | into the specifics of an individual protocol that can be used for | ||
that purpose. | that purpose. | ||
− | === RFC 4359, The Use of RSA/SHA-1 Signatures within Encapsulating === | + | === [[RFC4359|RFC 4359]], The Use of RSA/SHA-1 Signatures within Encapsulating === |
Security Payload (ESP) and Authentication Header (AH) | Security Payload (ESP) and Authentication Header (AH) | ||
(S, January 2006) | (S, January 2006) | ||
− | + | [[RFC4359]] describes the use of the RSA digital signature algorithm to | |
provide integrity protection for multicast traffic within ESP and AH. | provide integrity protection for multicast traffic within ESP and AH. | ||
The algorithms used for integrity protection for unicast traffic | The algorithms used for integrity protection for unicast traffic | ||
Line 1,704: | Line 1,704: | ||
configuration policies. | configuration policies. | ||
− | ==== RFC 3586, IP Security Policy (IPSP) Requirements ==== | + | ==== [[RFC3586|RFC 3586]], IP Security Policy (IPSP) Requirements ==== |
(S, August 2003) | (S, August 2003) | ||
− | + | [[RFC3586]] describes the functional requirements of a generalized | |
IPsec policy framework, that could be used to discover, negotiate, | IPsec policy framework, that could be used to discover, negotiate, | ||
and manage IPsec policies. | and manage IPsec policies. | ||
− | ==== RFC 3585, IPsec Configuration Policy Information Model ==== | + | ==== [[RFC3585|RFC 3585]], IPsec Configuration Policy Information Model ==== |
(S, August 2003) | (S, August 2003) | ||
− | As stated in | + | As stated in [[RFC3585]]: |
This document presents an object-oriented information model of IP | This document presents an object-oriented information model of IP | ||
Line 1,730: | Line 1,730: | ||
IPsec and IKE, but only one progressed to RFC status. | IPsec and IKE, but only one progressed to RFC status. | ||
− | ==== RFC 4807, IPsec Security Policy Database Configuration MIB ==== | + | ==== [[RFC4807|RFC 4807]], IPsec Security Policy Database Configuration MIB ==== |
(S, March 2007) | (S, March 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. | of an IPsec device. This RFC has not been widely adopted. | ||
Line 1,745: | Line 1,745: | ||
The IPComp protocol allows the compression of IP datagrams by | The IPComp protocol allows the compression of IP datagrams by | ||
supporting different compression algorithms. Three of these | supporting different compression algorithms. Three of these | ||
− | algorithms are: DEFLATE | + | algorithms are: DEFLATE [[RFC2394]], LZS [[RFC2395]], and the ITU-T V.44 |
− | Packet Method | + | Packet Method [[RFC3051]], which is based on the LZJH algorithm. |
− | ==== RFC 3173, IP Payload Compression Protocol (IPComp) ==== | + | ==== [[RFC3173|RFC 3173]], IP Payload Compression Protocol (IPComp) ==== |
(S, September 2001) | (S, September 2001) | ||
Line 1,756: | Line 1,756: | ||
lower protocol layers ineffective. If IKE is used to negotiate | lower protocol layers ineffective. If IKE is used to negotiate | ||
compression in conjunction with IPsec, compression can be performed | compression in conjunction with IPsec, compression can be performed | ||
− | prior to encryption. | + | prior to encryption. [[RFC3173]] defines the payload compression |
protocol, the IPComp packet structure, the IPComp Association (IPCA), | protocol, the IPComp packet structure, the IPComp Association (IPCA), | ||
and several methods to negotiate the IPCA. | and several methods to negotiate the IPCA. | ||
Line 1,775: | Line 1,775: | ||
application protocol, which performs its own peer authentication. | application protocol, which performs its own peer authentication. | ||
− | ==== RFC 5660, IPsec Channels: Connection Latching (S, October 2009) ==== | + | ==== [[RFC5660|RFC 5660]], IPsec Channels: Connection Latching (S, October 2009) ==== |
− | + | [[RFC5660]] specifies, abstractly, how to interface applications and | |
transport protocols with IPsec so as to create channels by latching | transport protocols with IPsec so as to create channels by latching | ||
connections (packet flows) to certain IPsec Security Association (SA) | connections (packet flows) to certain IPsec Security Association (SA) | ||
Line 1,784: | Line 1,784: | ||
architecture. | architecture. | ||
− | ==== RFC 5386, Better-Than-Nothing-Security: An Unauthenticated Mode ==== | + | ==== [[RFC5386|RFC 5386]], Better-Than-Nothing-Security: An Unauthenticated Mode ==== |
of IPsec (S, November 2008) | of IPsec (S, November 2008) | ||
− | + | [[RFC5386]] specifies how to use IKEv2 to set up unauthenticated | |
security associations (SAs) for use with the IPsec Encapsulating | security associations (SAs) for use with the IPsec Encapsulating | ||
Security Payload (ESP) and the IPsec Authentication Header (AH). | Security Payload (ESP) and the IPsec Authentication Header (AH). | ||
Line 1,794: | Line 1,794: | ||
Security Policy Database (SPD). | Security Policy Database (SPD). | ||
− | ==== RFC 5387, Problem and Applicability Statement for Better-Than- ==== | + | ==== [[RFC5387|RFC 5387]], Problem and Applicability Statement for Better-Than- ==== |
Nothing Security (BTNS) (I, November 2008) | Nothing Security (BTNS) (I, November 2008) | ||
− | + | [[RFC5387]] considers that the need to deploy authentication | |
information and its associated identities is a significant obstacle | information and its associated identities is a significant obstacle | ||
to the use of IPsec. This document explains the rationale for | to the use of IPsec. This document explains the rationale for | ||
Line 1,815: | Line 1,815: | ||
and not to IKEv2. | and not to IKEv2. | ||
− | ==== RFC 3129, Requirements for Kerberized Internet Negotiation of ==== | + | ==== [[RFC3129|RFC 3129]], Requirements for Kerberized Internet Negotiation of ==== |
Keys (I, June 2001) | Keys (I, June 2001) | ||
− | + | [[RFC3129]] considers that peer-to-peer authentication and keying | |
mechanisms have inherent drawbacks such as computational complexity | mechanisms have inherent drawbacks such as computational complexity | ||
and difficulty in enforcing security policies. This document | and difficulty in enforcing security policies. This document | ||
specifies the requirements for using basic features of Kerberos and | specifies the requirements for using basic features of Kerberos and | ||
uses them to its advantage to create a protocol that can establish | uses them to its advantage to create a protocol that can establish | ||
− | and maintain IPsec security associations ( | + | and maintain IPsec security associations ([[RFC2401]]). |
− | ==== RFC 4430, Kerberized Internet Negotiation of Keys (KINK) ==== | + | ==== [[RFC4430|RFC 4430]], Kerberized Internet Negotiation of Keys (KINK) ==== |
(S, March 2006) | (S, March 2006) | ||
− | + | [[RFC4430]] defines a low-latency, computationally inexpensive, easily | |
managed, and cryptographically sound protocol to establish and | managed, and cryptographically sound protocol to establish and | ||
maintain security associations using the Kerberos authentication | maintain security associations using the Kerberos authentication | ||
Line 1,849: | Line 1,849: | ||
EAP for user authentication. | EAP for user authentication. | ||
− | ==== RFC 3457, Requirements for IPsec Remote Access Scenarios ==== | + | ==== [[RFC3457|RFC 3457]], Requirements for IPsec Remote Access Scenarios ==== |
(I, January 2003) | (I, January 2003) | ||
− | + | [[RFC3457]] explores and enumerates the requirements of various IPsec | |
remote access scenarios, without suggesting particular solutions for | remote access scenarios, without suggesting particular solutions for | ||
them. | them. | ||
− | ==== RFC 3456, Dynamic Host Configuration Protocol (DHCPv4) ==== | + | ==== [[RFC3456|RFC 3456]], Dynamic Host Configuration Protocol (DHCPv4) ==== |
Configuration of IPsec Tunnel Mode (S, January 2003) | Configuration of IPsec Tunnel Mode (S, January 2003) | ||
− | + | [[RFC3456]] explores the requirements for host configuration in IPsec | |
tunnel mode, and describes how the Dynamic Host Configuration | tunnel mode, and describes how the Dynamic Host Configuration | ||
Protocol (DHCPv4) may be used for providing such configuration | Protocol (DHCPv4) may be used for providing such configuration | ||
Line 1,870: | Line 1,870: | ||
facilitate opportunistic IPsec in a new type of DNS resource record. | facilitate opportunistic IPsec in a new type of DNS resource record. | ||
− | ==== RFC 4025, A method for storing IPsec keying material in DNS ==== | + | ==== [[RFC4025|RFC 4025]], A method for storing IPsec keying material in DNS ==== |
(S, February 2005) | (S, February 2005) | ||
− | + | [[RFC4025]] describes a method of storing IPsec keying material in the | |
DNS using a new type of resource record. This document describes how | 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. | to store the public key of the target node in this resource record. | ||
Line 1,891: | Line 1,891: | ||
=== Mobile IP (MIPv4 and MIPv6) === | === Mobile IP (MIPv4 and MIPv6) === | ||
− | ==== RFC 4093, Problem Statement: Mobile IPv4 Traversal of Virtual ==== | + | ==== [[RFC4093|RFC 4093]], Problem Statement: Mobile IPv4 Traversal of Virtual ==== |
Private Network (VPN) Gateways (I, August 2005) | Private Network (VPN) Gateways (I, August 2005) | ||
− | + | [[RFC4093]] describes the issues with deploying Mobile IPv4 across | |
virtual private networks (VPNs). IPsec is one of the VPN | virtual private networks (VPNs). IPsec is one of the VPN | ||
technologies covered by this document. It identifies and describes | technologies covered by this document. It identifies and describes | ||
Line 1,903: | Line 1,903: | ||
gateways. | gateways. | ||
− | ==== RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways ==== | + | ==== [[RFC5265|RFC 5265]], Mobile IPv4 Traversal across IPsec-Based VPN Gateways ==== |
(S, June 2008) | (S, June 2008) | ||
− | + | [[RFC5265]] describes a basic solution that uses Mobile IPv4 and IPsec | |
to provide session mobility between enterprise intranets and external | to provide session mobility between enterprise intranets and external | ||
networks. The proposed solution minimizes changes to existing | networks. The proposed solution minimizes changes to existing | ||
Line 1,913: | Line 1,913: | ||
minimize IPsec renegotiation when the mobile node moves. | minimize IPsec renegotiation when the mobile node moves. | ||
− | ==== RFC 3776, Using IPsec to Protect Mobile IPv6 Signaling Between ==== | + | ==== [[RFC3776|RFC 3776]], Using IPsec to Protect Mobile IPv6 Signaling Between ==== |
Mobile Nodes and Home Agents (S, June 2004) | Mobile Nodes and Home Agents (S, June 2004) | ||
Line 1,928: | Line 1,928: | ||
IPv6 signaling messages. | IPv6 signaling messages. | ||
− | ==== RFC 4877, Mobile IPv6 Operation with IKEv2 and the Revised IPsec ==== | + | ==== [[RFC4877|RFC 4877]], Mobile IPv6 Operation with IKEv2 and the Revised IPsec ==== |
Architecture (S, April 2007) | Architecture (S, April 2007) | ||
− | This document updates | + | This document updates [[RFC3776]] in order to work with the revised |
− | IPsec architecture | + | IPsec architecture [[RFC4301]]. Since the revised IPsec architecture |
expands the list of selectors to include the Mobility Header message | expands the list of selectors to include the Mobility Header message | ||
type, it becomes much easier to differentiate between different | type, it becomes much easier to differentiate between different | ||
Line 1,942: | Line 1,942: | ||
order to set up the SAs for Mobile IPv6. | order to set up the SAs for Mobile IPv6. | ||
− | ==== RFC 5026, Mobile IPv6 Bootstrapping in Split Scenario ==== | + | ==== [[RFC5026|RFC 5026]], Mobile IPv6 Bootstrapping in Split Scenario ==== |
(S, October 2007) | (S, October 2007) | ||
− | + | [[RFC5026]] extends [[RFC4877]] to support dynamic discovery of home | |
agents and the home network prefix; for the latter purpose, it | agents and the home network prefix; for the latter purpose, it | ||
specifies a new IKEv2 configuration attribute and notification. It | specifies a new IKEv2 configuration attribute and notification. It | ||
Line 1,958: | Line 1,958: | ||
used for IKEv2 exchange. | used for IKEv2 exchange. | ||
− | ==== RFC 5213, Proxy Mobile IPv6 (S, August 2008) ==== | + | ==== [[RFC5213|RFC 5213]], Proxy Mobile IPv6 (S, August 2008) ==== |
− | + | [[RFC5213]] describes a network-based mobility management protocol that | |
is used to provide mobility services to hosts without requiring their | is used to provide mobility services to hosts without requiring their | ||
participation in any mobility-related signaling. It uses IPsec to | participation in any mobility-related signaling. It uses IPsec to | ||
Line 1,968: | Line 1,968: | ||
security associations between the MAG and the LMA. | security associations between the MAG and the LMA. | ||
− | ==== RFC 5568, Mobile IPv6 Fast Handovers (S, July 2009) ==== | + | ==== [[RFC5568|RFC 5568]], Mobile IPv6 Fast Handovers (S, July 2009) ==== |
When Mobile IPv6 is used for a handover, there is a period during | 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 | which the Mobile Node is unable to send or receive packets because of | ||
− | link switching delay and IP protocol operations. | + | link switching delay and IP protocol operations. [[RFC5568]] specifies |
a protocol between the Previous Access Router (PAR) and the New | a protocol between the Previous Access Router (PAR) and the New | ||
Access Router (NAR) to improve handover latency due to Mobile IPv6 | Access Router (NAR) to improve handover latency due to Mobile IPv6 | ||
Line 1,980: | Line 1,980: | ||
IKEv2 is used for setting up the required SAs. | IKEv2 is used for setting up the required SAs. | ||
− | ==== RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management ==== | + | ==== [[RFC5380|RFC 5380]], Hierarchical Mobile IPv6 (HMIPv6) Mobility Management ==== |
(S, October 2008) | (S, October 2008) | ||
− | + | [[RFC5380]] describes extensions to Mobile IPv6 and IPv6 Neighbor | |
Discovery to allow for local mobility handling in order to reduce the | Discovery to allow for local mobility handling in order to reduce the | ||
amount of signaling between the mobile node, its correspondent nodes, | amount of signaling between the mobile node, its correspondent nodes, | ||
Line 1,990: | Line 1,990: | ||
and a local mobility management entity called the Mobility Anchor | and a local mobility management entity called the Mobility Anchor | ||
Point (MAP). The MAP also uses IPsec Peer Authorization Database | Point (MAP). The MAP also uses IPsec Peer Authorization Database | ||
− | (PAD) entries and configuration payloads described in | + | (PAD) entries and configuration payloads described in [[RFC4877]] in |
order to allocate a Regional Care-of Address (RCoA) for mobile nodes. | order to allocate a Regional Care-of Address (RCoA) for mobile nodes. | ||
=== Open Shortest Path First (OSPF) === | === Open Shortest Path First (OSPF) === | ||
− | ==== RFC 4552, Authentication/Confidentiality for OSPFv3 ==== | + | ==== [[RFC4552|RFC 4552]], Authentication/Confidentiality for OSPFv3 ==== |
(S, June 2006) | (S, June 2006) | ||
Line 2,002: | Line 2,002: | ||
authentication mechanisms using the AuType and Authentication | authentication mechanisms using the AuType and Authentication | ||
protocol header fields but OSPFv3 removed these fields and uses IPsec | protocol header fields but OSPFv3 removed these fields and uses IPsec | ||
− | instead. | + | instead. [[RFC4552]] describes how to use IPsec ESP and AH in order to |
protect OSPFv3 signaling between two routers. It also enumerates the | protect OSPFv3 signaling between two routers. It also enumerates the | ||
IPsec capabilities the routers require in order to support this | IPsec capabilities the routers require in order to support this | ||
Line 2,015: | Line 2,015: | ||
=== Host Identity Protocol (HIP) === | === Host Identity Protocol (HIP) === | ||
− | ==== RFC 5201, Host Identity Protocol (E, April 2008) ==== | + | ==== [[RFC5201|RFC 5201]], Host Identity Protocol (E, April 2008) ==== |
IP addresses perform two distinct functions: host identifier and | IP addresses perform two distinct functions: host identifier and | ||
Line 2,027: | Line 2,027: | ||
protecting its signaling messages. | protecting its signaling messages. | ||
− | ==== RFC 5202, Using the Encapsulating Security Payload (ESP) ==== | + | ==== [[RFC5202|RFC 5202]], Using the Encapsulating Security Payload (ESP) ==== |
Transport Format with the Host Identity Protocol (HIP) | Transport Format with the Host Identity Protocol (HIP) | ||
(E, April 2008) | (E, April 2008) | ||
− | The HIP base exchange specification | + | The HIP base exchange specification [[RFC5201]] does not describe any |
transport formats or methods for describing how ESP is used to | transport formats or methods for describing how ESP is used to | ||
protect user data to be used during the actual communication. | protect user data to be used during the actual communication. | ||
− | + | [[RFC5202]] specifies a set of HIP extensions for creating a pair of | |
ESP Security Associations (SAs) between the hosts during the base | ESP Security Associations (SAs) between the hosts during the base | ||
exchange. After the HIP association and required ESP SAs have been | exchange. After the HIP association and required ESP SAs have been | ||
Line 2,043: | Line 2,043: | ||
Security Association. | Security Association. | ||
− | ==== RFC 5206, End-Host Mobility and Multihoming with the Host ==== | + | ==== [[RFC5206|RFC 5206]], End-Host Mobility and Multihoming with the Host ==== |
Identity (E, April 2008) | Identity (E, April 2008) | ||
Line 2,050: | Line 2,050: | ||
Security Associations (SAs) are bound to representations of these | Security Associations (SAs) are bound to representations of these | ||
host identities, and the IP addresses are only used for packet | host identities, and the IP addresses are only used for packet | ||
− | forwarding. | + | forwarding. [[RFC5206]] defines a generalized LOCATOR parameter for |
use in HIP messages that allows a HIP host to notify a peer about | 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 | alternate addresses at which it is reachable. It also specifies how | ||
Line 2,056: | Line 2,056: | ||
peers without necessarily rekeying. | peers without necessarily rekeying. | ||
− | ==== RFC 5207, NAT and Firewall Traversal Issues of Host Identity ==== | + | ==== [[RFC5207|RFC 5207]], NAT and Firewall Traversal Issues of Host Identity ==== |
Protocol (HIP) (I, April 2008) | Protocol (HIP) (I, April 2008) | ||
− | + | [[RFC5207]] discusses the problems associated with HIP communication | |
across network paths that include network address translators and | across network paths that include network address translators and | ||
firewalls. It analyzes the impact of NATs and firewalls on the HIP | firewalls. It analyzes the impact of NATs and firewalls on the HIP | ||
Line 2,070: | Line 2,070: | ||
=== Stream Control Transmission Protocol (SCTP) === | === Stream Control Transmission Protocol (SCTP) === | ||
− | ==== RFC 3554, On the Use of Stream Control Transmission Protocol ==== | + | ==== [[RFC3554|RFC 3554]], On the Use of Stream Control Transmission Protocol ==== |
(SCTP) with IPsec (S, July 2003) | (SCTP) with IPsec (S, July 2003) | ||
The Stream Control Transmission Protocol (SCTP) is a reliable | The Stream Control Transmission Protocol (SCTP) is a reliable | ||
transport protocol operating on top of a connection-less packet | transport protocol operating on top of a connection-less packet | ||
− | network such as IP. | + | network such as IP. [[RFC3554]] describes functional requirements for |
IPsec and IKE to be used in securing SCTP traffic. It adds support | 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 | + | for SCTP in the form of a new ID type in IKE [[RFC2409]] and |
implementation choices in the IPsec processing to account for the | implementation choices in the IPsec processing to account for the | ||
multiple source and destination addresses associated with a single | multiple source and destination addresses associated with a single | ||
Line 2,085: | Line 2,085: | ||
=== Robust Header Compression (ROHC) === | === Robust Header Compression (ROHC) === | ||
− | ==== RFC 3095, RObust Header Compression (ROHC): Framework and four ==== | + | ==== [[RFC3095|RFC 3095]], RObust Header Compression (ROHC): Framework and four ==== |
profiles: RTP, UDP, ESP, and uncompressed (S, July 2001) | profiles: RTP, UDP, ESP, and uncompressed (S, July 2001) | ||
ROHC is a framework for header compression, intended to be used in | ROHC is a framework for header compression, intended to be used in | ||
− | resource-constrained environments. | + | resource-constrained environments. [[RFC3095]] applies this framework |
to four protocols, including ESP. | to four protocols, including ESP. | ||
− | ==== RFC 5225, RObust Header Compression Version 2 (ROHCv2): Profiles ==== | + | ==== [[RFC5225|RFC 5225]], RObust Header Compression Version 2 (ROHCv2): Profiles ==== |
for RTP, UDP, IP, ESP, and UDP-Lite (S, April 2008) | for RTP, UDP, IP, ESP, and UDP-Lite (S, April 2008) | ||
− | + | [[RFC5225]] defines an updated ESP/IP profile for use with ROHC version | |
2. It analyzes the ESP header and classifies the fields into several | 2. It analyzes the ESP header and classifies the fields into several | ||
classes like static, well-known, irregular, etc., in order to | classes like static, well-known, irregular, etc., in order to | ||
efficiently compress the headers. | efficiently compress the headers. | ||
− | ==== RFC 5856, Integration of Robust Header Compression over IPsec ==== | + | ==== [[RFC5856|RFC 5856]], Integration of Robust Header Compression over IPsec ==== |
Security Associations (I, May 2010) | Security Associations (I, May 2010) | ||
− | + | [[RFC5856]] describes a mechanism to compress inner IP headers at the | |
ingress point of IPsec tunnels and to decompress them at the egress | ingress point of IPsec tunnels and to decompress them at the egress | ||
point. Since the Robust Header Compression (ROHC) specifications | point. Since the Robust Header Compression (ROHC) specifications | ||
Line 2,111: | Line 2,111: | ||
transport mode SAs. | transport mode SAs. | ||
− | ==== RFC 5857, IKEv2 Extensions to Support Robust Header Compression ==== | + | ==== [[RFC5857|RFC 5857]], IKEv2 Extensions to Support Robust Header Compression ==== |
over IPsec (S, May 2010) | over IPsec (S, May 2010) | ||
Line 2,117: | Line 2,117: | ||
decompressor ends. Since ROHC usually operates on a per-hop basis, | decompressor ends. Since ROHC usually operates on a per-hop basis, | ||
this configuration information is carried over link-layer protocols | this configuration information is carried over link-layer protocols | ||
− | such as PPP. Since | + | such as PPP. Since [[RFC5856]] operates over multiple hops, a |
− | different signaling mechanism is required. | + | different signaling mechanism is required. [[RFC5857]] describes how |
to use IKEv2 in order to dynamically communicate the configuration | to use IKEv2 in order to dynamically communicate the configuration | ||
parameters between the compressor and decompressor. | parameters between the compressor and decompressor. | ||
− | ==== RFC 5858, IPsec Extensions to Support Robust Header Compression ==== | + | ==== [[RFC5858|RFC 5858]], IPsec Extensions to Support Robust Header Compression ==== |
over IPsec (S, May 2010) | over IPsec (S, May 2010) | ||
− | + | [[RFC5856]] describes how to use ROHC with IPsec. This is not possible | |
− | without extensions to IPsec. | + | without extensions to IPsec. [[RFC5858]] describes the extensions |
needed to IPsec in order to support ROHC. Specifically, it describes | needed to IPsec in order to support ROHC. Specifically, it describes | ||
extensions needed to the IPsec SPD, SAD, and IPsec processing | extensions needed to the IPsec SPD, SAD, and IPsec processing | ||
Line 2,133: | Line 2,133: | ||
=== Border Gateway Protocol (BGP) === | === Border Gateway Protocol (BGP) === | ||
− | ==== RFC 5566, BGP IPsec Tunnel Encapsulation Attribute ==== | + | ==== [[RFC5566|RFC 5566]], BGP IPsec Tunnel Encapsulation Attribute ==== |
(S, June 2009) | (S, June 2009) | ||
− | + | [[RFC5566]] adds an additional BGP Encapsulation Subsequent Address | |
Family Identifier (SAFI), allowing the use of IPsec and, optionally, | Family Identifier (SAFI), allowing the use of IPsec and, optionally, | ||
IKE to protect BGP tunnels. It defines the use of AH and ESP in | IKE to protect BGP tunnels. It defines the use of AH and ESP in | ||
Line 2,168: | Line 2,168: | ||
=== Network Address Translators (NAT) === | === Network Address Translators (NAT) === | ||
− | ==== RFC 2709, Security Model with Tunnel-mode IPsec for NAT domains ==== | + | ==== [[RFC2709|RFC 2709]], Security Model with Tunnel-mode IPsec for NAT domains ==== |
(I, October 1999) | (I, October 1999) | ||
Line 2,174: | Line 2,174: | ||
communicate from disparate address realms, by modifying IP and | communicate from disparate address realms, by modifying IP and | ||
transport headers en route. This makes it difficult for applications | transport headers en route. This makes it difficult for applications | ||
− | to pursue end-to-end application-level security. | + | to pursue end-to-end application-level security. [[RFC2709]] describes |
a security model by which tunnel mode IPsec security can be | a security model by which tunnel mode IPsec security can be | ||
architected on NAT devices. It defines how NATs administer security | architected on NAT devices. It defines how NATs administer security | ||
Line 2,187: | Line 2,187: | ||
=== Session Initiation Protocol (SIP) === | === Session Initiation Protocol (SIP) === | ||
− | ==== RFC 3329, Security Mechanism Agreement for the Session ==== | + | ==== [[RFC3329|RFC 3329]], Security Mechanism Agreement for the Session ==== |
Initiation Protocol (SIP) (S, January 2003) | Initiation Protocol (SIP) (S, January 2003) | ||
− | + | [[RFC3329]] describes how a SIP client can select one of the various | |
available SIP security mechanisms. In particular, the method allows | available SIP security mechanisms. In particular, the method allows | ||
secure negotiation to prevent bidding down attacks. It also | secure negotiation to prevent bidding down attacks. It also | ||
Line 2,199: | Line 2,199: | ||
8.10. Explicit Packet Sensitivity Labels | 8.10. Explicit Packet Sensitivity Labels | ||
− | 8.10.1. RFC 5570, Common Architecture Label IPv6 Security Option | + | 8.10.1. [[RFC5570|RFC 5570]], Common Architecture Label IPv6 Security Option |
(CALIPSO) (I, July 2009) | (CALIPSO) (I, July 2009) | ||
− | + | [[RFC5570]] describes a mechanism used to encode explicit packet | |
Sensitivity Labels on IPv6 packets in Multi-Level Secure (MLS) | Sensitivity Labels on IPv6 packets in Multi-Level Secure (MLS) | ||
networks. The method is implemented using an IPv6 hop-by-hop option. | networks. The method is implemented using an IPv6 hop-by-hop option. | ||
Line 2,217: | Line 2,217: | ||
=== Extensible Authentication Protocol (EAP) === | === Extensible Authentication Protocol (EAP) === | ||
− | ==== RFC 5106, The Extensible Authentication Protocol-Internet Key ==== | + | ==== [[RFC5106|RFC 5106]], The Extensible Authentication Protocol-Internet Key ==== |
Exchange Protocol version 2 (EAP-IKEv2) Method | Exchange Protocol version 2 (EAP-IKEv2) Method | ||
(E, February 2008) | (E, February 2008) | ||
− | + | [[RFC5106]] specifies an Extensible Authentication Protocol (EAP) | |
method that is based on the Internet Key Exchange version 2 (IKEv2) | method that is based on the Internet Key Exchange version 2 (IKEv2) | ||
protocol. EAP-IKEv2 provides mutual authentication and session-key | protocol. EAP-IKEv2 provides mutual authentication and session-key | ||
Line 2,230: | Line 2,230: | ||
=== Fibre Channel === | === Fibre Channel === | ||
− | ==== RFC 4595, Use of IKEv2 in the Fibre Channel Security Association ==== | + | ==== [[RFC4595|RFC 4595]], Use of IKEv2 in the Fibre Channel Security Association ==== |
Management Protocol (I, July 2006) | Management Protocol (I, July 2006) | ||
Fibre Channel (FC) is a gigabit-speed network technology used for | Fibre Channel (FC) is a gigabit-speed network technology used for | ||
Storage Area Networking. The Fibre Channel Security Protocols (FC- | Storage Area Networking. The Fibre Channel Security Protocols (FC- | ||
− | SP) standard has adapted the IKEv2 protocol | + | SP) standard has adapted the IKEv2 protocol [[RFC4306]] to provide |
authentication of Fibre Channel entities and setup of security | authentication of Fibre Channel entities and setup of security | ||
associations. Since IP is transported over Fibre Channel and Fibre | associations. Since IP is transported over Fibre Channel and Fibre | ||
Channel is transported over IP, there is the potential for confusion | Channel is transported over IP, there is the potential for confusion | ||
− | when IKEv2 is used for both IP and FC traffic. | + | when IKEv2 is used for both IP and FC traffic. [[RFC4595]] specifies |
identifiers for IKEv2 over FC in a fashion that ensures that any | 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 | mistaken usage of IKEv2/FC over IP or IKEv2/IP over FC will result in | ||
Line 2,246: | Line 2,246: | ||
=== Wireless Security === | === Wireless Security === | ||
− | ==== RFC 4705, GigaBeam High-Speed Radio Link Encryption ==== | + | ==== [[RFC4705|RFC 4705]], GigaBeam High-Speed Radio Link Encryption ==== |
(I, October 2006) | (I, October 2006) | ||
− | + | [[RFC4705]] describes the encryption and key management used by | |
GigaBeam as part of the WiFiber(tm) family of radio-link products and | GigaBeam as part of the WiFiber(tm) family of radio-link products and | ||
is intended to serve as a guideline for similar wireless product | is intended to serve as a guideline for similar wireless product | ||
Line 2,301: | Line 2,301: | ||
1999. | 1999. | ||
− | + | [[RFC2119]] Bradner, S., "Key words for use in RFCs to Indicate | |
− | Requirement Levels", BCP 14, RFC 2119, March 1997. | + | Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997. |
− | + | [[RFC2026]] Bradner, S., "The Internet Standards Process -- Revision | |
− | 3", BCP 9, RFC 2026, October 1996. | + | 3", [[BCP9|BCP 9]], [[RFC2026|RFC 2026]], October 1996. |
− | + | [[RFC2394]] Pereira, R., "IP Payload Compression Using DEFLATE", RFC | |
2394, December 1998. | 2394, December 1998. | ||
− | + | [[RFC2395]] Friend, R. and R. Monsour, "IP Payload Compression Using | |
− | LZS", RFC 2395, December 1998. | + | LZS", [[RFC2395|RFC 2395]], December 1998. |
− | + | [[RFC2401]] Kent, S. and R. Atkinson, "Security Architecture for the | |
− | Internet Protocol", RFC 2401, November 1998. | + | Internet Protocol", [[RFC2401|RFC 2401]], November 1998. |
− | + | [[RFC2402]] Kent, S. and R. Atkinson, "IP Authentication Header", RFC | |
2402, November 1998. | 2402, November 1998. | ||
− | + | [[RFC2403]] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within | |
− | ESP and AH", RFC 2403, November 1998. | + | ESP and AH", [[RFC2403|RFC 2403]], November 1998. |
− | + | [[RFC2404]] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within | |
− | ESP and AH", RFC 2404, November 1998. | + | ESP and AH", [[RFC2404|RFC 2404]], November 1998. |
− | + | [[RFC2405]] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher | |
− | Algorithm With Explicit IV", RFC 2405, November 1998. | + | Algorithm With Explicit IV", [[RFC2405|RFC 2405]], November 1998. |
− | + | [[RFC2406]] Kent, S. and R. Atkinson, "IP Encapsulating Security | |
− | Payload (ESP)", RFC 2406, November 1998. | + | Payload (ESP)", [[RFC2406|RFC 2406]], November 1998. |
− | + | [[RFC2407]] Piper, D., "The Internet IP Security Domain of | |
− | Interpretation for ISAKMP", RFC 2407, November 1998. | + | Interpretation for ISAKMP", [[RFC2407|RFC 2407]], November 1998. |
− | + | [[RFC2408]] Maughan, D., Schertler, M., Schneider, M., and J. Turner, | |
"Internet Security Association and Key Management Protocol | "Internet Security Association and Key Management Protocol | ||
− | (ISAKMP)", RFC 2408, November 1998. | + | (ISAKMP)", [[RFC2408|RFC 2408]], November 1998. |
− | + | [[RFC2409]] Harkins, D. and D. Carrel, "The Internet Key Exchange | |
− | (IKE)", RFC 2409, November 1998. | + | (IKE)", [[RFC2409|RFC 2409]], November 1998. |
− | + | [[RFC2410]] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and | |
− | Its Use With IPsec", RFC 2410, November 1998. | + | Its Use With IPsec", [[RFC2410|RFC 2410]], November 1998. |
− | + | [[RFC2411]] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security | |
− | Document Roadmap", RFC 2411, November 1998. | + | Document Roadmap", [[RFC2411|RFC 2411]], November 1998. |
− | + | [[RFC2412]] Orman, H., "The OAKLEY Key Determination Protocol", RFC | |
2412, November 1998. | 2412, November 1998. | ||
− | + | [[RFC2451]] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher | |
− | Algorithms", RFC 2451, November 1998. | + | Algorithms", [[RFC2451|RFC 2451]], November 1998. |
− | + | [[RFC2521]] Karn, P. and W. Simpson, "ICMP Security Failures | |
− | Messages", RFC 2521, March 1999. | + | Messages", [[RFC2521|RFC 2521]], March 1999. |
− | + | [[RFC2709]] Srisuresh, P., "Security Model with Tunnel-mode IPsec for | |
− | NAT Domains", RFC 2709, October 1999. | + | NAT Domains", [[RFC2709|RFC 2709]], October 1999. |
− | + | [[RFC2857]] Keromytis, A. and N. Provos, "The Use of HMAC- | |
− | RIPEMD-160-96 within ESP and AH", RFC 2857, June 2000. | + | RIPEMD-160-96 within ESP and AH", [[RFC2857|RFC 2857]], June 2000. |
− | + | [[RFC3051]] Heath, J. and J. Border, "IP Payload Compression Using | |
− | ITU-T V.44 Packet Method", RFC 3051, January 2001. | + | ITU-T V.44 Packet Method", [[RFC3051|RFC 3051]], January 2001. |
− | + | [[RFC3056]] Carpenter, B. and K. Moore, "Connection of IPv6 Domains | |
− | via IPv4 Clouds", RFC 3056, February 2001. | + | via IPv4 Clouds", [[RFC3056|RFC 3056]], February 2001. |
− | + | [[RFC3095]] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., | |
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, | Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, | ||
K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., | K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., | ||
Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header | Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header | ||
Compression (ROHC): Framework and four profiles: RTP, UDP, | Compression (ROHC): Framework and four profiles: RTP, UDP, | ||
− | ESP, and uncompressed", RFC 3095, July 2001. | + | ESP, and uncompressed", [[RFC3095|RFC 3095]], July 2001. |
− | + | [[RFC3129]] Thomas, M., "Requirements for Kerberized Internet | |
− | Negotiation of Keys", RFC 3129, June 2001. | + | Negotiation of Keys", [[RFC3129|RFC 3129]], June 2001. |
− | + | [[RFC3173]] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP | |
− | Payload Compression Protocol (IPComp)", RFC 3173, | + | Payload Compression Protocol (IPComp)", [[RFC3173|RFC 3173]], |
September 2001. | September 2001. | ||
− | + | [[RFC3329]] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. | |
Haukka, "Security Mechanism Agreement for the Session | Haukka, "Security Mechanism Agreement for the Session | ||
− | Initiation Protocol (SIP)", RFC 3329, January 2003. | + | Initiation Protocol (SIP)", [[RFC3329|RFC 3329]], January 2003. |
− | + | [[RFC3456]] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic | |
Host Configuration Protocol (DHCPv4) Configuration of | Host Configuration Protocol (DHCPv4) Configuration of | ||
− | IPsec Tunnel Mode", RFC 3456, January 2003. | + | IPsec Tunnel Mode", [[RFC3456|RFC 3456]], January 2003. |
− | + | [[RFC3457]] Kelly, S. and S. Ramamoorthi, "Requirements for IPsec | |
− | Remote Access Scenarios", RFC 3457, January 2003. | + | Remote Access Scenarios", [[RFC3457|RFC 3457]], January 2003. |
− | + | [[RFC3526]] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) | |
Diffie-Hellman groups for Internet Key Exchange (IKE)", | Diffie-Hellman groups for Internet Key Exchange (IKE)", | ||
− | RFC 3526, May 2003. | + | [[RFC3526|RFC 3526]], May 2003. |
− | + | [[RFC3547]] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The | |
− | Group Domain of Interpretation", RFC 3547, July 2003. | + | Group Domain of Interpretation", [[RFC3547|RFC 3547]], July 2003. |
− | + | [[RFC3554]] Bellovin, S., Ioannidis, J., Keromytis, A., and R. | |
Stewart, "On the Use of Stream Control Transmission | Stewart, "On the Use of Stream Control Transmission | ||
− | Protocol (SCTP) with IPsec", RFC 3554, July 2003. | + | Protocol (SCTP) with IPsec", [[RFC3554|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. | + | and Its Use With IPsec", [[RFC3566|RFC 3566]], September 2003. |
− | + | [[RFC3585]] Jason, J., Rafalow, L., and E. Vyncke, "IPsec | |
− | Configuration Policy Information Model", RFC 3585, August | + | Configuration Policy Information Model", [[RFC3585|RFC 3585]], August |
2003. | 2003. | ||
− | + | [[RFC3586]] Blaze, M., Keromytis, A., Richardson, M., and L. Sanchez, | |
− | "IP Security Policy (IPSP) Requirements", RFC 3586, August | + | "IP Security Policy (IPSP) Requirements", [[RFC3586|RFC 3586]], August |
2003. | 2003. | ||
− | + | [[RFC3602]] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher | |
− | Algorithm and Its Use with IPsec", RFC 3602, September | + | Algorithm and Its Use with IPsec", [[RFC3602|RFC 3602]], September |
2003. | 2003. | ||
− | + | [[RFC3686]] Housley, R., "Using Advanced Encryption Standard (AES) | |
Counter Mode With IPsec Encapsulating Security Payload | Counter Mode With IPsec Encapsulating Security Payload | ||
− | (ESP)", RFC 3686, January 2004. | + | (ESP)", [[RFC3686|RFC 3686]], January 2004. |
− | + | [[RFC3706]] Huang, G., Beaulieu, S., and D. Rochefort, "A Traffic- | |
Based Method of Detecting Dead Internet Key Exchange (IKE) | Based Method of Detecting Dead Internet Key Exchange (IKE) | ||
− | Peers", RFC 3706, February 2004. | + | Peers", [[RFC3706|RFC 3706]], February 2004. |
− | + | [[RFC3715]] Aboba, B. and W. Dixon, "IPsec-Network Address Translation | |
− | (NAT) Compatibility Requirements", RFC 3715, March 2004. | + | (NAT) Compatibility Requirements", [[RFC3715|RFC 3715]], March 2004. |
− | + | [[RFC3740]] Hardjono, T. and B. Weis, "The Multicast Group Security | |
− | Architecture", RFC 3740, March 2004. | + | Architecture", [[RFC3740|RFC 3740]], March 2004. |
− | + | [[RFC3776]] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to | |
Protect Mobile IPv6 Signaling Between Mobile Nodes and | Protect Mobile IPv6 Signaling Between Mobile Nodes and | ||
− | Home Agents", RFC 3776, June 2004. | + | Home Agents", [[RFC3776|RFC 3776]], June 2004. |
− | + | [[RFC3830]] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. | |
− | Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, | + | Norrman, "MIKEY: Multimedia Internet KEYing", [[RFC3830|RFC 3830]], |
August 2004. | August 2004. | ||
− | + | [[RFC3884]] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec | |
− | Transport Mode for Dynamic Routing", RFC 3884, September | + | Transport Mode for Dynamic Routing", [[RFC3884|RFC 3884]], September |
2004. | 2004. | ||
− | + | [[RFC3947]] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, | |
− | "Negotiation of NAT-Traversal in the IKE", RFC 3947, | + | "Negotiation of NAT-Traversal in the IKE", [[RFC3947|RFC 3947]], |
January 2005. | January 2005. | ||
− | + | [[RFC3948]] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. | |
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC | Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC | ||
3948, January 2005. | 3948, January 2005. | ||
− | + | [[RFC4025]] Richardson, M., "A Method for Storing IPsec Keying | |
− | Material in DNS", RFC 4025, March 2005. | + | Material in DNS", [[RFC4025|RFC 4025]], March 2005. |
− | + | [[RFC4046]] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, | |
"Multicast Security (MSEC) Group Key Management | "Multicast Security (MSEC) Group Key Management | ||
− | Architecture", RFC 4046, April 2005. | + | Architecture", [[RFC4046|RFC 4046]], April 2005. |
− | + | [[RFC4093]] Adrangi, F., Ed., and H. Levkowetz, Ed., "Problem | |
Statement: Mobile IPv4 Traversal of Virtual Private | Statement: Mobile IPv4 Traversal of Virtual Private | ||
− | Network (VPN) Gateways", RFC 4093, August 2005. | + | Network (VPN) Gateways", [[RFC4093|RFC 4093]], August 2005. |
− | + | [[RFC4106]] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode | |
(GCM) in IPsec Encapsulating Security Payload (ESP)", RFC | (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC | ||
4106, June 2005. | 4106, June 2005. | ||
− | + | [[RFC4109]] Hoffman, P., "Algorithms for Internet Key Exchange version | |
− | 1 (IKEv1)", RFC 4109, May 2005. | + | 1 (IKEv1)", [[RFC4109|RFC 4109]], May 2005. |
− | + | [[RFC4196]] Lee, H., Yoon, J., Lee, S., and J. Lee, "The SEED Cipher | |
− | Algorithm and Its Use with IPsec", RFC 4196, October 2005. | + | Algorithm and Its Use with IPsec", [[RFC4196|RFC 4196]], October 2005. |
− | + | [[RFC4301]] Kent, S. and K. Seo, "Security Architecture for the | |
− | Internet Protocol", RFC 4301, December 2005. | + | Internet Protocol", [[RFC4301|RFC 4301]], December 2005. |
− | + | [[RFC4302]] Kent, S., "IP Authentication Header", [[RFC4302|RFC 4302]], December | |
2005. | 2005. | ||
− | + | [[RFC4303]] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC | |
4303, December 2005. | 4303, December 2005. | ||
− | + | [[RFC4304]] Kent, S., "Extended Sequence Number (ESN) Addendum to | |
IPsec Domain of Interpretation (DOI) for Internet Security | IPsec Domain of Interpretation (DOI) for Internet Security | ||
Association and Key Management Protocol (ISAKMP)", RFC | Association and Key Management Protocol (ISAKMP)", RFC | ||
4304, December 2005. | 4304, December 2005. | ||
− | + | [[RFC4305]] Eastlake 3rd, D., "Cryptographic Algorithm Implementation | |
Requirements for Encapsulating Security Payload (ESP) and | Requirements for Encapsulating Security Payload (ESP) and | ||
− | Authentication Header (AH)", RFC 4305, December 2005. | + | Authentication Header (AH)", [[RFC4305|RFC 4305]], December 2005. |
− | + | [[RFC4306]] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) | |
− | Protocol", RFC 4306, December 2005. | + | Protocol", [[RFC4306|RFC 4306]], December 2005. |
− | + | [[RFC4307]] Schiller, J., "Cryptographic Algorithms for Use in the | |
− | Internet Key Exchange Version 2 (IKEv2)", RFC 4307, | + | Internet Key Exchange Version 2 (IKEv2)", [[RFC4307|RFC 4307]], |
December 2005. | December 2005. | ||
− | + | [[RFC4308]] Hoffman, P., "Cryptographic Suites for IPsec", [[RFC4308|RFC 4308]], | |
December 2005. | December 2005. | ||
− | + | [[RFC4309]] Housley, R., "Using Advanced Encryption Standard (AES) CCM | |
Mode with IPsec Encapsulating Security Payload (ESP)", RFC | Mode with IPsec Encapsulating Security Payload (ESP)", RFC | ||
4309, December 2005. | 4309, December 2005. | ||
− | + | [[RFC4312]] Kato, A., Moriai, S., and M. Kanda, "The Camellia Cipher | |
− | Algorithm and Its Use With IPsec", RFC 4312, December | + | Algorithm and Its Use With IPsec", [[RFC4312|RFC 4312]], December |
2005. | 2005. | ||
− | + | [[RFC4322]] Richardson, M. and D. Redelmeier, "Opportunistic | |
Encryption using the Internet Key Exchange (IKE)", RFC | Encryption using the Internet Key Exchange (IKE)", RFC | ||
4322, December 2005. | 4322, December 2005. | ||
− | + | [[RFC4359]] Weis, B., "The Use of RSA/SHA-1 Signatures within | |
Encapsulating Security Payload (ESP) and Authentication | Encapsulating Security Payload (ESP) and Authentication | ||
− | Header (AH)", RFC 4359, January 2006. | + | Header (AH)", [[RFC4359|RFC 4359]], January 2006. |
− | + | [[RFC4430]] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, | |
"Kerberized Internet Negotiation of Keys (KINK)", RFC | "Kerberized Internet Negotiation of Keys (KINK)", RFC | ||
4430, March 2006. | 4430, March 2006. | ||
− | + | [[RFC4434]] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the | |
− | Internet Key Exchange Protocol (IKE)", RFC 4434, February | + | Internet Key Exchange Protocol (IKE)", [[RFC4434|RFC 4434]], February |
2006. | 2006. | ||
− | + | [[RFC4478]] Nir, Y., "Repeated Authentication in Internet Key Exchange | |
− | (IKEv2) Protocol", RFC 4478, April 2006. | + | (IKEv2) Protocol", [[RFC4478|RFC 4478]], April 2006. |
− | + | [[RFC4494]] Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96 | |
− | Algorithm and Its Use with IPsec", RFC 4494, June 2006. | + | Algorithm and Its Use with IPsec", [[RFC4494|RFC 4494]], June 2006. |
− | + | [[RFC4535]] Harney, H., Meth, U., Colegrove, A., and G. Gross, | |
"GSAKMP: Group Secure Association Key Management | "GSAKMP: Group Secure Association Key Management | ||
− | Protocol", RFC 4535, June 2006. | + | Protocol", [[RFC4535|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, | + | Authentication Code (GMAC) in IPsec ESP and AH", [[RFC4543|RFC 4543]], |
May 2006. | May 2006. | ||
− | + | [[RFC4552]] Gupta, M. and N. Melam, "Authentication/Confidentiality | |
− | for OSPFv3", RFC 4552, June 2006. | + | for OSPFv3", [[RFC4552|RFC 4552]], June 2006. |
− | + | [[RFC4555]] Eronen, P., "IKEv2 Mobility and Multihoming Protocol | |
− | (MOBIKE)", RFC 4555, June 2006. | + | (MOBIKE)", [[RFC4555|RFC 4555]], June 2006. |
− | + | [[RFC4595]] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel | |
− | Security Association Management Protocol", RFC 4595, July | + | Security Association Management Protocol", [[RFC4595|RFC 4595]], July |
2006. | 2006. | ||
− | + | [[RFC4615]] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The | |
Advanced Encryption Standard-Cipher-based Message | Advanced Encryption Standard-Cipher-based Message | ||
Authentication Code-Pseudo-Random Function-128 (AES-CMAC- | Authentication Code-Pseudo-Random Function-128 (AES-CMAC- | ||
PRF-128) Algorithm for the Internet Key Exchange Protocol | PRF-128) Algorithm for the Internet Key Exchange Protocol | ||
− | (IKE)", RFC 4615, August 2006. | + | (IKE)", [[RFC4615|RFC 4615]], August 2006. |
− | + | [[RFC4621]] Kivinen, T. and H. Tschofenig, "Design of the IKEv2 | |
− | Mobility and Multihoming (MOBIKE) Protocol", RFC 4621, | + | Mobility and Multihoming (MOBIKE) Protocol", [[RFC4621|RFC 4621]], |
August 2006. | August 2006. | ||
− | + | [[RFC4705]] Housley, R. and A. Corry, "GigaBeam High-Speed Radio Link | |
− | Encryption", RFC 4705, October 2006. | + | Encryption", [[RFC4705|RFC 4705]], October 2006. |
− | + | [[RFC4718]] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and | |
− | Implementation Guidelines", RFC 4718, October 2006. | + | Implementation Guidelines", [[RFC4718|RFC 4718]], October 2006. |
− | + | [[RFC4739]] Eronen, P. and J. Korhonen, "Multiple Authentication | |
Exchanges in the Internet Key Exchange (IKEv2) Protocol", | Exchanges in the Internet Key Exchange (IKEv2) Protocol", | ||
− | RFC 4739, November 2006. | + | [[RFC4739|RFC 4739]], November 2006. |
− | + | [[RFC4753]] Fu, D. and J. Solinas, "ECP Groups For IKE and IKEv2", RFC | |
4753, January 2007. | 4753, January 2007. | ||
− | + | [[RFC4754]] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using | |
the Elliptic Curve Digital Signature Algorithm (ECDSA)", | the Elliptic Curve Digital Signature Algorithm (ECDSA)", | ||
− | RFC 4754, January 2007. | + | [[RFC4754|RFC 4754]], January 2007. |
− | + | [[RFC4806]] Myers, M. and H. Tschofenig, "Online Certificate Status | |
− | Protocol (OCSP) Extensions to IKEv2", RFC 4806, February | + | Protocol (OCSP) Extensions to IKEv2", [[RFC4806|RFC 4806]], February |
2007. | 2007. | ||
− | + | [[RFC4807]] Baer, M., Charlet, R., Hardaker, W., Story, R., and C. | |
Wang, "IPsec Security Policy Database Configuration MIB", | Wang, "IPsec Security Policy Database Configuration MIB", | ||
− | RFC 4807, March 2007. | + | [[RFC4807|RFC 4807]], March 2007. |
− | + | [[RFC4809]] Bonatti, C., Ed., Turner, S., Ed., and G. Lebovitz, Ed., | |
"Requirements for an IPsec Certificate Management | "Requirements for an IPsec Certificate Management | ||
− | Profile", RFC 4809, February 2007. | + | Profile", [[RFC4809|RFC 4809]], February 2007. |
− | + | [[RFC4835]] Manral, V., "Cryptographic Algorithm Implementation | |
Requirements for Encapsulating Security Payload (ESP) and | Requirements for Encapsulating Security Payload (ESP) and | ||
− | Authentication Header (AH)", RFC 4835, April 2007. | + | Authentication Header (AH)", [[RFC4835|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. | + | SHA-384, and HMAC-SHA-512 with IPsec", [[RFC4868|RFC 4868]], May 2007. |
− | + | [[RFC4869]] Law, L. and J. Solinas, "Suite B Cryptographic Suites for | |
− | IPsec", RFC 4869, May 2007. | + | IPsec", [[RFC4869|RFC 4869]], May 2007. |
− | + | [[RFC4877]] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with | |
− | IKEv2 and the Revised IPsec Architecture", RFC 4877, April | + | IKEv2 and the Revised IPsec Architecture", [[RFC4877|RFC 4877]], April |
2007. | 2007. | ||
− | + | [[RFC4891]] Graveman, R., Parthasarathy, M., Savola, P., and H. | |
Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", | Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", | ||
− | RFC 4891, May 2007. | + | [[RFC4891|RFC 4891]], May 2007. |
− | + | [[RFC4894]] Hoffman, P., "Use of Hash Algorithms in Internet Key | |
− | Exchange (IKE) and IPsec", RFC 4894, May 2007. | + | Exchange (IKE) and IPsec", [[RFC4894|RFC 4894]], May 2007. |
− | + | [[RFC4945]] Korver, B., "The Internet IP Security PKI Profile of | |
− | IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007. | + | IKEv1/ISAKMP, IKEv2, and PKIX", [[RFC4945|RFC 4945]], August 2007. |
− | + | [[RFC5026]] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., | |
− | "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, | + | "Mobile IPv6 Bootstrapping in Split Scenario", [[RFC5026|RFC 5026]], |
October 2007. | October 2007. | ||
− | + | [[RFC5106]] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y., | |
and F. Bersani, "The Extensible Authentication Protocol- | and F. Bersani, "The Extensible Authentication Protocol- | ||
Internet Key Exchange Protocol version 2 (EAP-IKEv2) | Internet Key Exchange Protocol version 2 (EAP-IKEv2) | ||
− | Method", RFC 5106, February 2008. | + | Method", [[RFC5106|RFC 5106]], February 2008. |
− | + | [[RFC5114]] Lepinski, M. and S. Kent, "Additional Diffie-Hellman | |
− | Groups for Use with IETF Standards", RFC 5114, January | + | Groups for Use with IETF Standards", [[RFC5114|RFC 5114]], January |
2008. | 2008. | ||
− | + | [[RFC5201]] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T. | |
− | Henderson, "Host Identity Protocol", RFC 5201, April 2008. | + | Henderson, "Host Identity Protocol", [[RFC5201|RFC 5201]], April 2008. |
− | + | [[RFC5202]] Jokela, P., Moskowitz, R., and P. Nikander, "Using the | |
Encapsulating Security Payload (ESP) Transport Format with | Encapsulating Security Payload (ESP) Transport Format with | ||
− | the Host Identity Protocol (HIP)", RFC 5202, April 2008. | + | the Host Identity Protocol (HIP)", [[RFC5202|RFC 5202]], April 2008. |
− | + | [[RFC5206]] Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko, | |
"End-Host Mobility and Multihoming with the Host Identity | "End-Host Mobility and Multihoming with the Host Identity | ||
− | Protocol", RFC 5206, April 2008. | + | Protocol", [[RFC5206|RFC 5206]], April 2008. |
− | + | [[RFC5207]] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and | |
Firewall Traversal Issues of Host Identity Protocol (HIP) | Firewall Traversal Issues of Host Identity Protocol (HIP) | ||
− | Communication", RFC 5207, April 2008. | + | Communication", [[RFC5207|RFC 5207]], April 2008. |
− | + | [[RFC5213]] Gundavelli, S., Ed., Leung, K., Devarapalli, V., | |
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC | Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC | ||
5213, August 2008. | 5213, August 2008. | ||
− | + | [[RFC5225]] Pelletier, G. and K. Sandlund, "RObust Header Compression | |
Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and | Version 2 (ROHCv2): Profiles for RTP, UDP, IP, ESP and | ||
− | UDP-Lite", RFC 5225, April 2008. | + | UDP-Lite", [[RFC5225|RFC 5225]], April 2008. |
− | + | [[RFC5265]] Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across | |
− | IPsec-Based VPN Gateways", RFC 5265, June 2008. | + | IPsec-Based VPN Gateways", [[RFC5265|RFC 5265]], June 2008. |
− | + | [[RFC5266]] Devarapalli, V. and P. Eronen, "Secure Connectivity and | |
Mobility Using Mobile IPv4 and IKEv2 Mobility and | Mobility Using Mobile IPv4 and IKEv2 Mobility and | ||
− | Multihoming (MOBIKE)", BCP 136, RFC 5266, June 2008. | + | Multihoming (MOBIKE)", [[BCP136|BCP 136]], [[RFC5266|RFC 5266]], June 2008. |
− | + | [[RFC5282]] Black, D. and D. McGrew, "Using Authenticated Encryption | |
Algorithms with the Encrypted Payload of the Internet Key | Algorithms with the Encrypted Payload of the Internet Key | ||
− | Exchange version 2 (IKEv2) Protocol", RFC 5282, August | + | Exchange version 2 (IKEv2) Protocol", [[RFC5282|RFC 5282]], August |
2008. | 2008. | ||
− | + | [[RFC5380]] Soliman, H., Castelluccia, C., ElMalki, K., and L. | |
Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility | Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility | ||
− | Management", RFC 5380, October 2008. | + | Management", [[RFC5380|RFC 5380]], October 2008. |
− | + | [[RFC5386]] Williams, N. and M. Richardson, "Better-Than-Nothing | |
− | Security: An Unauthenticated Mode of IPsec", RFC 5386, | + | Security: An Unauthenticated Mode of IPsec", [[RFC5386|RFC 5386]], |
November 2008. | November 2008. | ||
− | + | [[RFC5374]] Weis, B., Gross, G., and D. Ignjatic, "Multicast | |
Extensions to the Security Architecture for the Internet | Extensions to the Security Architecture for the Internet | ||
− | Protocol", RFC 5374, November 2008. | + | Protocol", [[RFC5374|RFC 5374]], November 2008. |
− | + | [[RFC5387]] Touch, J., Black, D., and Y. Wang, "Problem and | |
Applicability Statement for Better-Than-Nothing Security | Applicability Statement for Better-Than-Nothing Security | ||
− | (BTNS)", RFC 5387, November 2008. | + | (BTNS)", [[RFC5387|RFC 5387]], November 2008. |
− | + | [[RFC5406]] Bellovin, S., "Guidelines for Specifying the Use of IPsec | |
− | Version 2", BCP 146, RFC 5406, February 2009. | + | Version 2", [[BCP146|BCP 146]], [[RFC5406|RFC 5406]], February 2009. |
− | + | [[RFC5529]] Kato, A., Kanda, M., and S. Kanno, "Modes of Operation for | |
− | Camellia for Use with IPsec", RFC 5529, April 2009. | + | Camellia for Use with IPsec", [[RFC5529|RFC 5529]], April 2009. |
− | + | [[RFC5566]] Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel | |
− | Encapsulation Attribute", RFC 5566, June 2009. | + | Encapsulation Attribute", [[RFC5566|RFC 5566]], June 2009. |
− | + | [[RFC5568]] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", [[RFC5568|RFC 5568]], | |
July 2009. | July 2009. | ||
− | + | [[RFC5570]] StJohns, M., Atkinson, R., and G. Thomas, "Common | |
Architecture Label IPv6 Security Option (CALIPSO)", RFC | Architecture Label IPv6 Security Option (CALIPSO)", RFC | ||
5570, July 2009. | 5570, July 2009. | ||
− | + | [[RFC5660]] Williams, N., "IPsec Channels: Connection Latching", RFC | |
5660, October 2009. | 5660, October 2009. | ||
− | + | [[RFC5685]] Devarapalli, V. and K. Weniger, "Redirect Mechanism for | |
the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC | the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC | ||
5685, November 2009. | 5685, November 2009. | ||
− | + | [[RFC5723]] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange | |
− | Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, | + | Protocol Version 2 (IKEv2) Session Resumption", [[RFC5723|RFC 5723]], |
January 2010. | January 2010. | ||
− | + | [[RFC5739]] Eronen, P., Laganier, J., and C. Madson, "IPv6 | |
Configuration in Internet Key Exchange Protocol Version 2 | Configuration in Internet Key Exchange Protocol Version 2 | ||
− | (IKEv2)", RFC 5739, February 2010. | + | (IKEv2)", [[RFC5739|RFC 5739]], February 2010. |
− | + | [[RFC5840]] Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped | |
Encapsulating Security Payload (ESP) for Traffic | Encapsulating Security Payload (ESP) for Traffic | ||
− | Visibility", RFC 5840, April 2010. | + | Visibility", [[RFC5840|RFC 5840]], April 2010. |
− | + | [[RFC5856]] Ertekin, E., Jasani, R., Christou, C., and C. Bormann, | |
"Integration of Robust Header Compression over IPsec | "Integration of Robust Header Compression over IPsec | ||
− | Security Associations", RFC 5856, May 2010. | + | Security Associations", [[RFC5856|RFC 5856]], May 2010. |
− | + | [[RFC5857]] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. | |
Bormann, "IKEv2 Extensions to Support Robust Header | Bormann, "IKEv2 Extensions to Support Robust Header | ||
− | Compression over IPsec", RFC 5857, May 2010. | + | Compression over IPsec", [[RFC5857|RFC 5857]], May 2010. |
− | + | [[RFC5858]] Ertekin, E., Christou, C., and C. Bormann, "IPsec | |
Extensions to Support Robust Header Compression over | Extensions to Support Robust Header Compression over | ||
− | IPsec", RFC 5858, May 2010. | + | IPsec", [[RFC5858|RFC 5858]], May 2010. |
− | + | [[RFC5879]] Kivinen, T. and D. McDonald, "Heuristics for Detecting | |
− | ESP-NULL Packets", RFC 5879, May 2010. | + | ESP-NULL Packets", [[RFC5879|RFC 5879]], May 2010. |
− | + | [[RFC5903]] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a | |
− | Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June | + | Prime (ECP Groups) for IKE and IKEv2", [[RFC5903|RFC 5903]], June |
2010. | 2010. | ||
− | + | [[RFC5930]] Shen, S., Mao, Y., and NSS. Murthy, "Using Advanced | |
Encryption Standard Counter Mode (AES-CTR) with the | Encryption Standard Counter Mode (AES-CTR) with the | ||
Internet Key Exchange version 02 (IKEv2) Protocol", RFC | Internet Key Exchange version 02 (IKEv2) Protocol", RFC | ||
5930, July 2010. | 5930, July 2010. | ||
− | + | [[RFC5996]] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, | |
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC | "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC | ||
5996, September 2010. | 5996, September 2010. | ||
− | + | [[RFC5998]] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension | |
− | for EAP-Only Authentication in IKEv2", RFC 5998, September | + | for EAP-Only Authentication in IKEv2", [[RFC5998|RFC 5998]], September |
2010. | 2010. | ||
− | + | [[RFC6027]] Nir, Y., "IPsec Cluster Problem Statement", [[RFC6027|RFC 6027]], | |
October 2010. | October 2010. | ||
Latest revision as of 02:46, 22 October 2020
Internet Engineering Task Force (IETF) S. Frankel Request for Comments: 6071 NIST Obsoletes: 2411 S. Krishnan Category: Informational Ericsson ISSN: 2070-1721 February 2011
IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap
Abstract
Over the past few years, the number of RFCs that define and use IPsec and Internet Key Exchange (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 RFC 2411, the previous "IP Security Document Roadmap."
The obsoleted IPsec roadmap (RFC 2411) briefly described the interrelationship of the various classes of base IPsec documents. The major focus of RFC 2411 was to specify the recommended contents of documents specifying additional encryption and authentication algorithms.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6071.
Copyright Notice
Copyright (c) 2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
2.2.1. Differences between "Old" IPsec (IPsec-v2) and
Contents
- 1 Introduction
- 2 IPsec/IKE Background Information
- 3 IPsec Documents
- 3.1 Base Documents
- 3.2 Additions to IPsec
- 3.2.1 RFC 3947, Negotiation of NAT-Traversal in the IKE
- 3.2.2 RFC 3948, UDP Encapsulation of IPsec ESP Packets
- 3.2.3 RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec
- 3.2.4 RFC 4322, Opportunistic Encryption using the Internet Key
- 3.2.5 RFC 4891, Using IPsec to Secure IPv6-in-IPv4 Tunnels
- 3.2.6 RFC 3884, Use of IPsec Transport Mode for Dynamic Routing
- 3.2.7 RFC 5840, Wrapped Encapsulating Security Payload (ESP) for
- 3.2.8 RFC 5879, Heuristics for Detecting ESP-NULL packets
- 3.3 General Considerations
- 4 IKE Documents
- 4.1 Base Documents
- 4.2 Additions and Extensions
- 4.2.1 Peer Authentication Methods
- 4.2.2 Certificate Contents and Management (PKI4IPsec)
- 4.2.3 Dead Peer Detection
- 4.2.4 Remote Access
- 4.2.4.1 RFC 4555, IKEv2 Mobility and Multihoming Protocol (MOBIKE)
- 4.2.4.2 RFC 4621, Design of the IKEv2 Mobility and Multihoming
- 4.2.4.3 RFC 5266, Secure Connectivity and Mobility Using Mobile IPv4
- 4.2.4.4 RFC 5723, Internet Key Exchange Protocol Version 2 (IKEv2)
- 4.2.4.5 RFC 5685, Re-direct Mechanism for the Internet Key Exchange
- 4.2.4.6 RFC 5739, IPv6 Configuration in Internet Key Exchange Protocol
- 5 Cryptographic Algorithms and Suites
- 5.1 Algorithm Requirements
- 5.2 Encryption Algorithms
- 5.2.1 RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec
- 5.2.2 RFC 2451, The ESP CBC-Mode Cipher Algorithms (S, November 1998)
- 5.2.3 RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec
- 5.2.4 RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode
- 5.2.5 RFC 5930, Using Advanced Encryption Standard Counter Mode (AES-
- 5.2.6 RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec
- 5.2.7 RFC 5529, Modes of Operation for Camellia for Use with IPsec
- 5.2.8 RFC 4196, The SEED Cipher Algorithm and Its Use with IPsec
- 5.3 Integrity-Protection (Authentication) Algorithms
- 5.3.1 RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH
- 5.3.2 RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec
- 5.3.3 RFC 4868, Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512
- 5.3.4 RFC 2403, The Use of HMAC-MD5-96 within ESP and AH
- 5.3.5 RFC 4494, The AES-CMAC-96 Algorithm and Its Use with IPsec
- 5.3.6 RFC 2857, The Use of HMAC-RIPEMD-160-96 within ESP and AH
- 5.3.7 RFC 4894, Use of Hash Algorithms in Internet Key Exchange (IKE)
- 5.4 Combined Mode Algorithms
- 5.5 Pseudo-Random Functions (PRFs)
- 5.6 Cryptographic Suites
- 5.7 Diffie-Hellman Algorithms
- 6 IPsec/IKE for Multicast
- 6.1 RFC 3740, The Multicast Group Security Architecture
- 6.2 RFC 5374, Multicast Extensions to the Security Architecture for
- 6.3 RFC 3547, The Group Domain of Interpretation (S, July 2003)
- 6.4 RFC 4046, Multicast Security (MSEC) Group Key Management
- 6.5 RFC 4359, The Use of RSA/SHA-1 Signatures within Encapsulating
- 7 Outgrowths of IPsec/IKE
- 8 Other Protocols That Use IPsec/IKE
- 8.1 Mobile IP (MIPv4 and MIPv6)
- 8.1.1 RFC 4093, Problem Statement: Mobile IPv4 Traversal of Virtual
- 8.1.2 RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways
- 8.1.3 RFC 3776, Using IPsec to Protect Mobile IPv6 Signaling Between
- 8.1.4 RFC 4877, Mobile IPv6 Operation with IKEv2 and the Revised IPsec
- 8.1.5 RFC 5026, Mobile IPv6 Bootstrapping in Split Scenario
- 8.1.6 RFC 5213, Proxy Mobile IPv6 (S, August 2008)
- 8.1.7 RFC 5568, Mobile IPv6 Fast Handovers (S, July 2009)
- 8.1.8 RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
- 8.2 Open Shortest Path First (OSPF)
- 8.3 Host Identity Protocol (HIP)
- 8.4 Stream Control Transmission Protocol (SCTP)
- 8.5 Robust Header Compression (ROHC)
- 8.5.1 RFC 3095, RObust Header Compression (ROHC): Framework and four
- 8.5.2 RFC 5225, RObust Header Compression Version 2 (ROHCv2): Profiles
- 8.5.3 RFC 5856, Integration of Robust Header Compression over IPsec
- 8.5.4 RFC 5857, IKEv2 Extensions to Support Robust Header Compression
- 8.5.5 RFC 5858, IPsec Extensions to Support Robust Header Compression
- 8.6 Border Gateway Protocol (BGP)
- 8.7 IPsec Benchmarking
- 8.8 Network Address Translators (NAT)
- 8.9 Session Initiation Protocol (SIP)
- 8.1 Mobile IP (MIPv4 and MIPv6)
- 9 Other Protocols That Adapt IKE for Non-IPsec Functionality
Introduction
IPsec (Internet Protocol Security) 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., Mobile IP version 6 (MIPv6)) to protect some or all of their traffic. IKE (Internet Key Exchange) is the key negotiation and management protocol that is most commonly used to provide dynamically negotiated and updated keying material for IPsec. IPsec and IKE can be used in conjunction with both IPv4 and IPv6.
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 obsoletes RFC2411. It attempts 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.
This document also categorizes the requirements level of each cryptographic algorithm for use with IKEv1, IKEv2, IPsec-v2, and IPsec-v3. These requirements are summarized in Appendix A. These levels are current as of February 2011; subsequent RFCs may result in altered requirement levels.
This document does not define requirement levels; it simply restates those found in the IKE and IPsec RFCs. If there is a conflict between this document and any other RFC, then the other RFC takes precedence.
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.
IPsec/IKE Background Information
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 that broadly covers the general concepts, security requirements, definitions, and mechanisms defining IPsec technology.
There are an Encapsulating Security Payload (ESP) Protocol document and an Authentication Header (AH) Protocol document that cover the packet format and general issues regarding the respective protocols. The "Encryption Algorithm" document set, shown on the 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 | +------------+
Figure 1. IPsec/IKE Document Interrelationships
Versions of IPsec
Two versions of IPsec can currently be found in implementations. The "new" IPsec (referred to as IPsec-v3 in this document; see Section 3.1.1 for the RFC descriptions) obsoleted the "old" IPsec (referred to as IPsec-v2 in this document; see Section 3.1.2 for the RFC descriptions); however, IPsec-v2 is still commonly found in operational use. In this document, when the unqualified term IPsec is used, it pertains to both versions of IPsec. An earlier version of IPsec (defined in RFCs 1825-1829), obsoleted by IPsec-v2, is not covered in this document.
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 the requirements that needed to be added to IPsec to facilitate its use with 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 the 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 Extended sequence numbers (ESNs) were added
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 Combined mode algorithms were added, necessitating changes to packet format and processing
o NULL authentication, mandatory (MUST) in ESP-v2, is optional (MAY) in ESP-v3
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.
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 the requirements that needed to be added to IKE to facilitate its use with other protocols as well as in general-purpose use. The documentation for IKEv2 replaces multiple, at times 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. Since IKE always negotiates pairs of SAs, the term "SA" is generally used to refer to a pair of SAs (e.g., an "IKE SA" or an "IPsec SA" is in reality a pair of one-way 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". To further complicate the terminology, since IKEv1 consists of two sequential negotiations, called phases, the IKE SA is also referred to as a Phase 1 SA and the IPsec SA is referred to as a Phase 2 SA.
Changes to IKE include:
o Replaced multiple alternate exchange types with a single, shorter exchange
o Streamlined negotiation format to avoid combinatorial bloat for multiple proposals
o Protect 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
o Support of EAP-based authentication methods and asymmetric authentication (i.e., initiator and responder can use different authentication methods)
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 Internet Security Association and Key Management Protocol (ISAKMP) (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 RFC5996 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.
IPsec Documents
Base Documents
IPsec protections are provided by two special headers: the Encapsulating Security Payload (ESP) Header and the Authentication Header (AH). In IPv4, these headers take the form of protocol headers; in IPv6, they are classified as extension headers. There are three base IPsec documents: one that describes the IP security architecture, and one for each of the IPsec headers.
"Old" IPsec (IPsec-v2)
RFC 2401, Security Architecture for the Internet Protocol
(S, November 1998)
RFC2401 specifies 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:
- 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 facilitate 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 three general classes of traffic are traffic to be discarded, traffic that is allowed without IPsec protection, and traffic that requires IPsec protection.
RFC 2401 describes general inbound and outbound IPsec processing; it also includes details on several special cases: packet fragments, ICMP messages, and multicast traffic.
RFC 2402, IP Authentication Header (S, November 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.
RFC 2406, IP Encapsulating Security Payload (ESP)
(S, November 1998)
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.
"New" IPsec (IPsec-v3)
RFC 4301, Security Architecture for the Internet Protocol
(S, December 2005)
RFC4301 obsoletes RFC2401, and it includes 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 protocol (e.g., IKE)
RFC 4302, IP Authentication Header (S, December 2005)
RFC4302 obsoletes RFC2402. Unlike IPsec-v2, IPsec-v3 classifies AH as optional.
RFC 4303, IP Encapsulating Security Payload (ESP)
(S, December 2005)
RFC4303 obsoletes RFC2406. The most notable changes are detailed above in Section 2.2.1.
Additions to IPsec
Once the IKEv1 and IPsec-v2 RFCs were finalized, several additions were defined in separate documents: negotiation of NAT traversal, extended sequence numbers, UDP encapsulation of ESP packets, opportunistic encryption, and IPsec-related ICMP messages. Additional uses of IPsec transport mode were also described: protection of manually configured IPv6-in-IPv4 tunnels and protection of IP-in-IP tunnels. These documents describe atypical uses of IPsec transport mode, but do not define any new IPsec features.
Once the original IPsec Working Group concluded, additional IPsec- related issues were handled by the IPsecME (IPsec Maintenance and Extensions) Working Group. One such problem is the capability of middleboxes to distinguish unencrypted ESP packets (ESP-NULL) from encrypted ones in a fast and accurate manner. Two solutions are described: a new protocol that requires changes to IKEv2 and IPsec-v3 and a heuristic method that imposes no new requirements. Another issue that was addressed is the problem of using IKE and IPsec in a high-availability environment.
RFC 3947, Negotiation of NAT-Traversal in the IKE
(S, January 2005)
RFC3947 defines an optional extension to IKEv1. It 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 RFC5996.
RFC 3948, UDP Encapsulation of IPsec ESP Packets
(S, January 2005)
RFC3948 is an optional extension for IPsec-v2 and IPsec-v3. It 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 RFC5996 for IKEv2.
RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec
Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) (S, December 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 redesign of the packet format. The larger sequence numbers allow an existing IPsec SA to be used for larger volumes of data. RFC4304 describes an optional extension to IKEv1 that enables IKEv1 to negotiate the use of ESNs for IPsec SAs. For IKEv2, this capability is described in RFC5996.
RFC 4322, Opportunistic Encryption using the Internet Key
Exchange (IKE) (I, December 2005)
Opportunistic encryption allows a pair of end systems to use encryption without any specific pre-arrangements. RFC4322 specifies a mechanism that uses DNS to distribute the public keys of each system involved and uses DNS Security (DNSSEC) to secure the mechanism against active attackers. It specifies the changes that are needed in existing IPsec and IKE implementations. The majority of the changes are needed in the IKE implementation and these changes relate to the handling of key acquisition requests, the lookup of public keys and TXT records, and the interactions with firewalls and other security facilities that may be co-resident on the same gateway.
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).
RFC 3884, Use of IPsec Transport Mode for Dynamic Routing
(I, September 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.
RFC 5840, Wrapped Encapsulating Security Payload (ESP) for
Traffic Visibility (S, April 2010)
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). RFC5840 extends ESPv3 to provide explicit notification of integrity-protected packets, and extends IKEv2 to negotiate this capability between the IPsec peers.
RFC 5879, Heuristics for Detecting ESP-NULL packets
(I, May 2010)
RFC5879 offers an alternative approach to differentiating between ESP-encrypted and ESP-NULL packets through packet inspection. This method does not require any change to IKE or ESP; it can be used with ESP-v2 or ESP-v3.
General Considerations
RFC 3715, IPsec-Network Address Translation (NAT) Compatibility
Requirements (I, March 2004)
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.
RFC 5406, Guidelines for Specifying the Use of IPsec Version 2
(B, February 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. The details in this document apply only to IPsec-v2.
RFC 2521, ICMP Security Failures Messages (E, March 1999)
RFC2521 specifies an ICMP message for indicating failures related to the use of IPsec protocols (AH and ESP). The specified ICMP message defines several codes for handling common failure modes for IPsec. The failures that are signaled by this message include invalid or expired SPIs, failure of authenticity or integrity checks on datagrams, decryption and decompression errors, etc. These messages can be used to trigger automated session-key management or to signal to an operator the need to manually reconfigure the SAs. This RFC has not been widely adopted. Furthermore, RFC4301 discusses the pros and cons of relying on unprotected ICMP messages.
RFC 6027, IPsec Cluster Problem Statement (I, October 2010)
RFC6027 describes the problems of using IKE and IPsec in a high availability environment, in which one or both of the peers are clusters of gateways. It details the numerous types of stateful
information shared by IKE and IPsec peers that would have to be available to other members of the cluster in order to provide high- availability, load sharing, and/or failover capabilities.
IKE Documents
Base Documents
IKEv1
IKE is the preferred key management protocol for IPsec. It is used for peer authentication; to negotiate, modify, and delete SAs; and to negotiate authenticated keying material for use within those SAs. The standard peer authentication methods used by IKEv1 (pre-shared secret keys and digital certificates) had several shortcomings related to use of IKEv1 to enable remote user authentication to a corporate VPN: it could not leverage the use of legacy authentication systems (e.g. RADIUS databases) to authenticate a remote user to a security gateway; and it could not be used to configure remote users with network addresses or other information needed in order to access the internal network. Automatic key distribution is required for IPsec-v2, but alternatives to IKE may be used to satisfy that requirement.
Several Internet Drafts were written to address these problems: two such documents include "Extended Authentication within IKE (XAUTH)" [IKE-XAUTH] (and its predecessor, "Extended Authentication within ISAKMP/Oakley (XAUTH)" [ISAKMP-XAUTH]) and "The ISAKMP Configuration Method" [IKE-MODE-CFG] (and its predecessor [ISAKMP-MODE-CFG]). These Internet Drafts did not progress to RFC status due to security flaws and other problems related to these solutions. However, many current IKEv1 implementations incorporate aspects of these solutions to facilitate remote user access to corporate VPNs. These solutions were not standardized, and different implementations implemented different versions. Thus, there is no assurance that the implementations adhere fully to the suggested solutions or that one implementation can interoperate with others that claim to incorporate the same features. Furthermore, these solutions have known security issues. All of those problems and security issues have been solved in IKEv2; thus, use of these non-standardized IKEv1 solutions is not recommended.
RFC 2409, The Internet Key Exchange (IKE) (S, November 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.
RFC 2408, Internet Security Association and Key Management
Protocol (ISAKMP) (S, November 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.
RFC 2407, The Internet IP Security Domain of Interpretation
for ISAKMP (S, November 1998)
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.
RFC 2412, The OAKLEY Key Determination Protocol
(I, November 1998)
RFC2412 describes a key establishment protocol that two authenticated parties can use to 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). This document provides additional theory and background to explain some of the design decisions and security features of IKE and ISAKMP; it does not include details necessary for the implementation of IKEv1.
IKEv2
RFC 4306, Internet Key Exchange (IKEv2) Protocol
(S, December 2005)
This document contains the original description of version 2 of the Internet Key Exchange (IKE) protocol. It covers what was previously covered by separate documents: ISAKMP, IKE, and DOI. It also
addresses NAT traversal, legacy authentication, and remote address acquisition. IKEv2 is not interoperable with IKEv1. Automatic key distribution is required for IPsec-v3, but alternatives to IKE may be used to satisfy that requirement. This document has been superseded by RFC5996.
RFC 4718, IKEv2 Clarifications and Implementation Guidelines
(I, October 2006)
RFC4718 clarifies many areas of the original IKEv2 specification RFC4306 that were seen as potentially difficult to understand for developers who were 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 was to encourage the development of interoperable implementations. The clarifications in this document have been included in the new version of the IKEv2 specification RFC5996.
RFC 5996, Internet Key Exchange Protocol Version 2 (IKEv2)
(S, September 2010)
RFC5996 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. This document was developed by the IPsecME (IPsec Maintenance and Extensions) Working Group, after the conclusion of the original IPsec Working Group. Automatic key distribution is required for IPsec-v3, but alternatives to IKE may be used to satisfy that requirement.
Additions and Extensions
Peer Authentication Methods
RFC 4478, Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol (E, April 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 reauthenticate, limiting the damage in the case where an unauthorized user gains physical access to the remote host? This document defines a new status notification, that a responder can send to an initiator, which notifies the initiator that the IPsec SA will be revoked unless the initiator reauthenticates within a specified period of time. This optional extension applies only to IKEv2, not to IKEv1.
RFC 4739, Multiple Authentication Exchanges in the Internet
Key Exchange (IKEv2) Protocol (E, November 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. This optional extension applies only to IKEv2, not to IKEv1.
RFC 4754, IKE and IKEv2 Authentication Using the Elliptic
Curve Digital Signature Algorithm (ECDSA) (S, January 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. This optional extension applies to both IKEv1 and IKEv2.
RFC 5998, An Extension for EAP-Only Authentication in IKEv2
(S, September 2010)
IKEv2 allows an initiator to use EAP for peer authentication, but requires the responder to authenticate through the use of a digital signature. RFC5998 extends IKEv2 so that EAP methods that provide mutual authentication and key agreement can also be used to provide peer authentication for the responder. This optional extension applies only to IKEv2, not to IKEv1.
Certificate Contents and Management (PKI4IPsec)
The format, contents, and interpretation of Public Key Certificates (PKCs) proved to be a source of interoperability problems within IKE and IPsec. PKI4IPsec was an attempt to set in place some common procedures and interpretations to mitigate those problems.
RFC 4809, Requirements for an IPsec Certificate Management
Profile (I, February 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. These optional requirements apply to both IKEv1 and IKEv2.
RFC 4945, The Internet IP Security PKI Profile of
IKEv1/ISAKMP, IKEv2, and PKIX (S, August 2007)
RFC4945 defines a profile of the IKE and Public Key Infrastructure using X.509 (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. In addition, it summarizes the current state of implementations and deployment and provides advice to avoid common interoperability issues. This optional extension applies to both IKEv1 and IKEv2.
RFC 4806, Online Certificate Status Protocol (OCSP) Extensions
to IKEv2 (S, February 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 policy) prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. This optional extension applies only to IKEv2, not to IKEv1.
Dead Peer Detection
RFC 3706, A Traffic-Based Method of Detecting Dead Internet
Key Exchange (IKE) Peers (I, February 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, which refers to this feature as a "liveness check" or "liveness test".
Remote Access
The IKEv2 Mobility and Multihoming (MOBIKE) protocol enables two additional capabilities for IPsec VPN users: 1) moving from one address to another without re-establishing existing SAs and 2) using
multiple interfaces simultaneously. These solutions are limited to IPsec VPNs; they are not intended to provide more general mobility or multihoming capabilities.
The IPsecME Working Group identified some missing components needed for more extensive IKEv2 and IPsec-v3 support for remote access clients. These include efficient client resumption of a previously established session with a VPN gateway, efficient client redirection to an alternate VPN gateway, and support for IPv6 client configuration using IPsec configuration payloads.
RFC 4555, IKEv2 Mobility and Multihoming Protocol (MOBIKE)
(S, June 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 addresses and/or where IP addresses of an IPsec host change over time.
RFC 4621, Design of the IKEv2 Mobility and Multihoming
(MOBIKE) Protocol (I, August 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.
RFC 5266, Secure Connectivity and Mobility Using Mobile IPv4
and IKEv2 Mobility and Multihoming (MOBIKE) (B, June 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.
RFC 5723, Internet Key Exchange Protocol Version 2 (IKEv2)
Session Resumption (S, January 2010)
RFC5723 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. This optional extension applies only to IKEv2, not to IKEv1.
RFC 5685, Re-direct Mechanism for the Internet Key Exchange
Protocol Version 2 (IKEv2) (S, November 2009)
RFC5685 enables a gateway to securely redirect VPN clients to 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. This optional extension applies only to IKEv2, not to IKEv1.
RFC 5739, IPv6 Configuration in Internet Key Exchange Protocol
Version 2 (IKEv2) (E, February 2010)
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. RFC5739 proposes several solutions that might remove this limitation. This optional extension applies only to IKEv2, not to IKEv1.
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 roadmap will classify its requirement level for each protocol, as either MUST, SHOULD, or MAY RFC2119; SHOULD+, SHOULD-, or MUST- RFC4835; optional; undefined; or N/A (not applicable). A designation of "optional" means that the algorithm meets the two basic requirements, but its use is not specifically recommended for that protocol. "Undefined" 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 requirement 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, Pseudorandom 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. These requirements
are summarized in Table 1 (Appendix A). These levels are current as of February 2011; subsequent RFCs may result in altered requirement levels. For algorithms, this could mean the introduction of new algorithms or upgrading or downgrading the requirement levels of current algorithms.
The IANA registries for IKEv1 and IKEv2 include IANA values for various cryptographic algorithms. IKE uses these values to negotiate IPsec SAs that will provide protection using those algorithms. If a specific algorithm lacks a value for IKEv1 and/or IKEv2, that algorithm's use is classified as "undefined" (no IANA #) within IPsec-v2 and/or IPsec-v3.
Algorithm Requirements
Specifying a core set of mandatory algorithms for each protocol 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.
RFC 4835, Cryptographic Algorithm Implementation Requirements
for Encapsulating Security Payload (ESP) and Authentication Header (AH) (S, April 2007)
RFC4835 specifies the encryption and integrity-protection algorithms for IPsec (both versions). Algorithms for IPsec-v2 were originally defined in RFC2402 and RFC2406. RFC4305 obsoleted those requirements, and was in turn obsoleted by RFC4835. Therefore, RFC4835 applies to IPsec-v2 as well as IPsec-v3. Combined mode algorithms are mentioned, but not assigned a requirement level.
RFC 4307, Cryptographic Algorithms for Use in the Internet Key
Exchange Version 2 (IKEv2) (S, December 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 pseudorandom functions used by IKEv2 to generate keys, nonces, and other random values. RFC4307 contains conflicting requirements for IKEv2 encryption and integrity-protection algorithms. Where there are contradictory requirements, this document takes its requirement levels from Section
3.1.1, "Encrypted Payload Algorithms", rather than from Section 3.1.3, "IKEv2 Transform Type 1 Algorithms", or Section 3.1.4, "IKEv2 Transform Type 2 Algorithms".
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 pseudorandom functions used by IKEv1 to generate keys, nonces and other random values; and the authentication methods and algorithms used by IKEv1 for peer authentication.
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, 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.
RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec
(S, November 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 RFC2410.
Requirement levels for ESP-NULL:
IKEv1 - N/A IKEv2 - N/A ESP-v2 - MUST RFC4835 ESP-v3 - MUST RFC4835
NOTE: RFC 4307 erroneously classifies ESP-NULL as MAY for IKEv2; this has been corrected in an errata submission for RFC 4307.
RFC 2451, The ESP CBC-Mode Cipher Algorithms (S, November 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), International Data Encryption Algorithm (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 Initialization Vector (IV) that is sent in the packet along with the encrypted data.
Requirement levels for 3DES-CBC:
IKEv1 - MUST RFC4109 IKEv2 - MUST- RFC4307 ESP-v2 - MUST RFC4835 ESP-v3 - MUST- RFC4835
Requirement levels for other CBC algorithms (Blowfish, CAST, IDEA, RC5):
IKEv1 - optional IKEv2 - optional ESP-v2 - optional ESP-v3 - optional
RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec
(S, September. 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. If AES-CBC is implemented, 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.
Requirement levels for AES-CBC with 128-bit keys:
IKEv1 - SHOULD RFC4109 IKEv2 - SHOULD+ RFC4307 ESP-v2 - MUST RFC4835 ESP-v3 - MUST RFC4835
Requirement levels for AES-CBC with 192- or 256-bit keys:
IKEv1 - optional IKEv2 - optional ESP-v2 - optional ESP-v3 - optional
RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode
With IPsec Encapsulating Security Payload (ESP) (S, January 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. If AES-CTR is implemented, 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.
Requirement levels for AES-CTR:
IKEv1 - undefined (no IANA #) IKEv2 - optional RFC5930 ESP-v2 - SHOULD RFC4835 ESP-v3 - SHOULD RFC4835
RFC 5930, Using Advanced Encryption Standard Counter Mode (AES-
CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol (I, July 210).
RFC5930 extends RFC3686 to enable the use of AES-CTR to provide encryption and integrity protection for IKEv2 messages.
RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec
(S, December 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 in the packet along with the encrypted data, and keysizes of 128, 192, and
256 bits. If Camellia-CBC is implemented, 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.
RFC 5529, Modes of Operation for Camellia for Use with IPsec
(S, April 2009)
RFC5529 describes the use of the Camellia block-cipher algorithm in conjunction with several different modes of operation. It describes the use of Camellia in cipher block chaining (CBC) mode and counter (CTR) mode as an encryption algorithm within ESP. It also describes the use of Camellia in Counter with CBC-MAC (CCM) mode as a combined mode algorithm in ESP. This document defines how to use IKEv2 to generate keying material for a Camellia ESP SA; it does not define how to use Camellia within IKEv2 to protect an IKEv2 SA's traffic. However, this RFC, in conjunction with IKEv2's generalized description of block-mode encryption, provide enough detail to allow the use of Camellia-CBC algorithms within IKEv2. All three modes can use keys of length 128 bits, 192 bits, or 256 bits. RFC5529 includes IANA values for use in IKEv2 and IPsec-v3. A single IANA value is defined for each Camellia mode, so IKEv2 negotiations need to specify the keysize.
Requirement levels for Camellia-CBC:
IKEv1 - optional IKEv2 - optional ESP-v2 - optional ESP-v3 - optional
Requirement levels for Camellia-CTR:
IKEv1 - undefined (no IANA #) IKEv2 - undefined (no RFC) ESP-v2 - optional (but no IANA #, so cannot be negotiated by IKE) ESP-v3 - optional
Requirement levels for Camellia-CCM:
IKEv1 - N/A IKEv2 - undefined (no RFC) ESP-v2 - N/A ESP-v3 - optional
RFC 4196, The SEED Cipher Algorithm and Its Use with IPsec
(S, October 2005)
RFC4196 describes how to use SEED in cipher block chaining (CBC) mode to encrypt ESP traffic. It describes how to use IKEv1 to negotiate a SEED-ESP SA, but does not define the use of SEED to protect IKEv1 traffic. SEED-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 a keysize of 128 bits. RFC4196 includes IANA values for use in IKEv1 and IPsec-v2. RFC4196 includes test data.
Requirement levels for SEED-CBC:
IKEv1 - undefined (no IANA #) IKEv2 - undefined (no IANA #) ESP-v2 - optional ESP-v3 - optional (but no IANA #, so cannot be negotiated by IKE)
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.
Some of these algorithms generate a fixed-length ICV, which is truncated when it is included in an IPsec-protected packet. For example, standard HMAC-SHA-1 (Hashed Message Authentication Code) generates a 160-bit ICV, which is truncated to 96 bits when it is used to provide integrity protection to an ESP or AH packet. The individual RFC descriptions mention those algorithms that are truncated. When these algorithms are used to protect IKEv2 SAs, they are also truncated. For IKEv1, HMAC-SHA-1 and HMAC-MD5 are negotiated by requesting the hash algorithms SHA-1 and MD5, respectively; these algorithms are not truncated when used to protect an IKEv1 SA. For HMAC-SHA-1 and HMAC-MD5, the IKEv2 IANA registry contains values for both the truncated version and the standard non- truncated version; thus, IKEv2 has the capability to negotiate either version of the algorithm. However, only the truncated version is used for IKEv2 SAs and for IPsec SAs. The non-truncated version is
reserved for use by the Fibre Channel protocol RFC4595. For the other algorithms (AES-XCBC, HMAC-SHA-256/384/512, AES-CMAC, and HMAC- RIPEMD), only the truncated version can be used for both IKEv2 and IPsec-v3 SAs.
One other algorithm, AES-GMAC RFC4543, can also provide integrity protection. 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. RFC4543 is described in Section 5.4, "Combined Mode Algorithms".
RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH
(S, November 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.
Requirement levels for HMAC-SHA-1:
IKEv1 - MUST RFC4109 IKEv2 - MUST RFC4307 IPsec-v2 - MUST RFC4835 IPsec-v3 - MUST RFC4835
RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec
(S, September 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.
Requirement levels for AES-XCBC-MAC:
IKEv1 - undefined (no RFC) IKEv2 - optional IPsec-v2 - SHOULD+ RFC4835 IPsec-v3 - SHOULD+ RFC4835
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.
Requirement levels for HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512:
IKEv1 - optional IKEv2 - optional IPsec-v2 - optional IPsec-v3 - optional
RFC 2403, The Use of HMAC-MD5-96 within ESP and AH
(S, November 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".
Requirement levels for HMAC-MD5:
IKEv1 - MAY RFC4109 IKEv2 - optional RFC4307 IPsec-v2 - MAY RFC4835 IPsec-v3 - MAY RFC4835
RFC 4494, The AES-CMAC-96 Algorithm and Its Use with IPsec
(S, June 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.
Requirement levels for AES-CMAC:
IKEv1 - undefined (no IANA #) IKEv2 - optional IPsec-v2 - optional (but no IANA #, so cannot be negotiated by IKE) IPsec-v3 - optional
RFC 2857, The Use of HMAC-RIPEMD-160-96 within ESP and AH
(S, June 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.
Requirement levels for HMAC-RIPEMD:
IKEv1 - undefined (no IANA #) IKEv2 - undefined (no IANA #) IPsec-v2 - optional IPsec-v3 - optional (but no IANA #, so cannot be negotiated by IKE)
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 SHA-256, -384, and -512.
Combined Mode Algorithms
IKEv1 and ESP-v2 use separate algorithms to provide encryption and 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. RFC5996 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.
Although ESP-v2 did not originally include combined mode algorithms, some IKEv1 implementations have added the capability to negotiate combined mode algorithms for use in IPsec SAs; these implementations do not include the capability to use combined mode algorithms to protect IKE SAs. IANA numbers for combined mode algorithms have been added to the IKEv1 registry.
RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode with
IPsec Encapsulating Security Payload (ESP) (S, December 2005)
RFC4309 describes how to use AES in counter with CBC-MAC (CCM) mode, a combined algorithm, to encrypt and integrity protect ESP 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. If AES-CCM is implemented, 128-bit keys are MUST; the other sizes are MAY. ICV sizes of 64 and 128 bits are MUST; 96 bits is MAY. The salt value is generated by IKE 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 that IKE can use to negotiate ESP-v3 SAs. Each of the three ICV lengths has its own IANA value, but IKE negotiations need to specify the keysize. RFC4309 includes test data. RFC4309 describes how IKE can negotiate the use of AES-CCM to use in an ESP SA. RFC5282 extends this to the use of AES-CCM to protect an IKEv2 SA.
Requirement 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. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol.
RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec
Encapsulating Security Payload (ESP) (S, June 2005)
RFC4106 describes how to use AES in Galois/Counter (GCM) mode, a combined algorithm, to encrypt and integrity protect ESP 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. If AES-GCM is implemented, 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 IKE during the key-generation process. Reuse of the IV with the same key compromises the data's security; thus, AES-GCM should not be used with manual keying. RFC4106 includes IANA values that IKE can use to negotiate ESP-v3 SAs. Each of the three ICV lengths has its own IANA value, but IKE negotiations need to specify the keysize.
RFC4106 includes test data. RFC4106 describes how IKE can negotiate the use of AES-GCM to use in an ESP SA. RFC5282 extends this to the use of AES-GCM to protect an IKEv2 SA.
Requirement 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. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol.
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, and a combined mode algorithm with null encryption for use within ESP. 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 IKE 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, each keysize has its own IANA value, so IKE does not have to negotiate the keysize. For use within ESP, there is only one IANA value, so IKE negotiations must specify the keysize. AES-GMAC cannot be used by IKE to protect its own SAs, since IKE traffic requires encryption.
Requirement levels for AES-GMAC:
IKEv1 - N/A IKEv2 - N/A IPsec-v2 - N/A IPsec-v3 - optional
NOTE: The IPsec-v2 IANA registry includes values for AES-GMAC, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol.
RFC 5282, Using Authenticated Encryption Algorithms with the
Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol (S, August 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.
Pseudo-Random Functions (PRFs)
IKE uses pseudorandom 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.
For each IKEv2 SA, the peers negotiate both a PRF algorithm and an integrity-protection algorithm; the former is used to generate keying material and other values, and the latter is used to provide protection to the IKE SA's traffic.
IKEv1's approach is more complicated. IKEv1 RFC2409 does not specify any PRF algorithms. For each IKEv1 SA, the peers agree on an unkeyed hash function (e.g., SHA-1). IKEv1 uses the HMAC version of this function to generate keying material and to provide integrity protection for the IKE SA. Therefore, PRFs that are not HMACs cannot currently be used in IKEv1.
Requirement levels for PRF-HMAC-SHA1:
IKEv1 - MUST RFC4109 IKEv2 - MUST RFC4307
Requirement levels for PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and PRF- HMAC-SHA-512:
IKEv1 - optional RFC4868 IKEv2 - optional RFC4868
RFC 4434, The AES-XCBC-PRF-128 Algorithm for the Internet Key
Exchange Protocol (IKE) (S, February 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.
Requirement levels for AES-XCBC-PRF:
IKEv1 - undefined (no RFC) IKEv2 - SHOULD+ RFC4307
NOTE: RFC 4109 erroneously classifies AES-XCBC-PRF as SHOULD for IKEv1; this has been corrected in an errata submission for RFC 4109.
RFC 4615, The Advanced Encryption Standard-Cipher-based Message
Authentication Code-Pseudorandom Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE) (S, August 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.
Requirement levels for AES-CMAC-PRF:
IKEv1 - undefined (no IANA #) IKEv2 - optional
Cryptographic Suites
RFC 4308, Cryptographic Suites for IPsec (S, December 2005)
An IKE negotiation consists of multiple cryptographic attributes, both for the IKE SA and for the IPsec SA. The 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 modular exponentiation group (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.
RFC 4869, Suite B Cryptographic Suites for IPsec (I, May 2007)
RFC4869 adds four pre-defined suites, based upon the United States National Security Agency's "Suite B" specifications, to those specified in RFC4308. IKE/ESP 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 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. While RFC4308 does not specify a peer- authentication method, RFC4869 mandates pre-shared key authentication for IKEv1; public key authentication using ECDSA is recommended for IKEv1 and required for IKEv2.
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.
IKEv1 RFC2409 contains definitions of two DH MODP groups and two elliptic curve (EC) groups; IKEv2 RFC5996 only references the MODP groups. The requirements levels of these groups are:
Requirement levels for DH MODP group 1:
IKEv1 - MAY RFC4109 IKEv2 - optional
Requirement levels for DH MODP group 2:
IKEv1 - MUST RFC4109 IKEv2 - MUST- RFC4307
Requirement levels for EC groups 3-4:
IKEv1 - MAY RFC4109 IKEv2 - undefined (no IANA #)
RFC 3526, More Modular Exponential (MODP) Diffie-Hellman groups
for Internet Key Exchange (IKE) (S, May 2003)
RFC2409 and RFC5996 define two 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.
Requirement levels for DH MODP group 14:
IKEv1 - SHOULD RFC4109 IKEv2 - SHOULD+ RFC4307
Requirement levels for DH MODP groups 5, 15-18:
IKEv1 - optional RFC4109 IKEv2 - optional
RFC 4753, ECP Groups For IKE and IKEv2 (I, January 2007)
RFC4753 defines three EC DH groups (groups 19-21) for use within IKE.
The document includes test data.
Requirement levels for DH EC groups 19-21:
IKEv1 - optional RFC4109 IKEv2 - optional
RFC 5903, Elliptic Curve Groups modulo a Prime (ECP Groups) for
IKE and IKEv2 (I, June 2010)
RFC5903 obsoletes RFC4753, fixing an inconsistency in the DH shared secret value.
RFC 5114, Additional Diffie-Hellman Groups for Use with IETF
Standards (I, January 2008)
RFC5114 defines five additional DH groups (MODP groups 22-24 and EC groups 25-26) for use in IKE. It also includes three EC DH groups (groups 19-21) that were originally defined in RFC4753; however, the current specification for these groups is RFC5903. The IANA group numbers are specific to IKE, but the DH groups are intended for use in multiple IETF protocols, including Transport Layer Security/Secure Socket Layer (TLS/SSL), Secure/Multipurpose Internet Mail Extensions (S/MIME), and X.509 Certificates.
Requirement levels for DH MODP groups 22-24, EC groups 25-26:
IKEv1 - optional IKEv2 - optional
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 large variety of possible multicast groups.
RFC 3740, The Multicast Group Security Architecture
(I, March 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 Group DOI (GDOI) RFC3547, Group Secure Association Key Management Protocol (GSAKMP) RFC4535, and Multimedia Internet KEYing (MIKEY) RFC3830, satisfy the group key management requirements defined in this document. Both the architecture and the components for Multicast Group Security differ from IPsec.
RFC 5374, Multicast Extensions to the Security Architecture for
the Internet Protocol (S, November 2008)
RFC5374 extends the security architecture defined in RFC4301 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.
RFC 3547, The Group Domain of Interpretation (S, July 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.
RFC 4046, Multicast Security (MSEC) Group Key Management
Architecture (I, April 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 purpose.
RFC 4359, The Use of RSA/SHA-1 Signatures within Encapsulating
Security Payload (ESP) and Authentication Header (AH) (S, January 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 (e.g., HMAC) are not suitable for this purpose when used with multicast traffic.
Outgrowths of IPsec/IKE
Operational experience with IPsec revealed additional capabilities that could make IPsec more useful in real-world scenarios. These include support for IPsec policy mechanisms, IPsec MIBs, payload compression (IPComp), extensions to facilitate additional peer authentication methods (Better-Than-Nothing Security (BTNS), Kerberized Internet Negotiation of Keys (KINK), and IPSECKEY), and additional capabilities for VPN clients (IPSRA).
IPsec Policy
The IPsec Policy (ipsp) Working Group originally planned an RFC that would allow entities with no common Trust Anchor and no prior knowledge of each other's 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.
RFC 3586, IP Security Policy (IPSP) Requirements
(S, August 2003)
RFC3586 describes the functional requirements of a generalized IPsec policy framework, that could be used to discover, negotiate, and manage IPsec policies.
RFC 3585, IPsec Configuration Policy Information Model
(S, August 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.
IPsec MIBs
Over the years, several MIB-related Internet Drafts were proposed for IPsec and IKE, but only one progressed to RFC status.
RFC 4807, IPsec Security Policy Database Configuration MIB
(S, March 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.
IPComp (Compression)
The IP Payload Compression Protocol (IPComp) is a protocol that provides lossless compression for IP datagrams. Although IKE can be used to negotiate the use of IPComp in conjunction with IPsec, IPComp can also be used when IPsec is not applied.
The IPComp protocol allows the compression of IP datagrams by supporting different compression algorithms. Three of these algorithms are: DEFLATE RFC2394, LZS RFC2395, and the ITU-T V.44 Packet Method RFC3051, which is based on the LZJH algorithm.
RFC 3173, IP Payload Compression Protocol (IPComp)
(S, September 2001)
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.
Better-Than-Nothing Security (BTNS)
One of the major obstacles to widespread implementation of IPsec is the lack of pre-existing credentials that can be used for peer authentication. Better-Than-Nothing Security (BTNS) is an attempt to sidestep this problem by allowing IKE to negotiate unauthenticated (anonymous) IPsec SAs, using credentials such as self-signed certificates or "bare" public keys (public keys that are not connected to a public key certificate) for peer authentication. This ensures that subsequent traffic protected by the SA is conducted with
the same peer, and protects the communications from passive attack. These SAs can then be cryptographically bound to a higher-level application protocol, which performs its own peer authentication.
RFC 5660, IPsec Channels: Connection Latching (S, October 2009)
RFC5660 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.
RFC 5386, Better-Than-Nothing-Security: An Unauthenticated Mode
of IPsec (S, November 2008)
RFC5386 specifies how to use IKEv2 to set up 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).
RFC 5387, Problem and Applicability Statement for Better-Than-
Nothing Security (BTNS) (I, November 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.
Kerberized Internet Negotiation of Keys (KINK)
Kerberized Internet Negotiation of Keys (KINK) is an attempt to provide an alternative to IKE for IPsec peer authentication. It uses Kerberos, instead of IKE, to establish IPsec SAs. For enterprises that already deploy the Kerberos centralized key management system, IPsec can then be implemented without the need for additional peer credentials. Some vendors have implemented proprietary extensions for using Kerberos in IKEv1, as an alternative to the use of KINK. These extensions, as well as the KINK protocol, apply only to IKEv1, and not to IKEv2.
RFC 3129, Requirements for Kerberized Internet Negotiation of
Keys (I, June 2001)
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 that can establish and maintain IPsec security associations (RFC2401).
RFC 4430, Kerberized Internet Negotiation of Keys (KINK)
(S, March 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.
IPsec Secure Remote Access (IPSRA)
IPsec Secure Remote Access (IPSRA) was an attempt to extend IPsec protection to "road warriors", allowing IKE to authenticate not only the user's device but also the user, without changing IKEv1. The working group defined generic requirements of different IPsec remote access scenarios. An attempt was made to define an IKE-like protocol that would use legacy authentication mechanisms to create a temporary or short-lived user credential that could be used for peer authentication within IKE. This protocol proved to be more cumbersome than standard Public Key protocols, and was abandoned. This led to the development of IKEv2, which incorporates the use of EAP for user authentication.
RFC 3457, Requirements for IPsec Remote Access Scenarios
(I, January 2003)
RFC3457 explores and enumerates the requirements of various IPsec remote access scenarios, without suggesting particular solutions for them.
RFC 3456, Dynamic Host Configuration Protocol (DHCPv4)
Configuration of IPsec Tunnel Mode (S, January 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.
IPsec Keying Information Resource Record (IPSECKEY)
The IPsec Keying Information Resource Record (IPSECKEY) enables the storage of public keys and other information that can be used to facilitate opportunistic IPsec in a new type of DNS resource record.
RFC 4025, A method for storing IPsec keying material in DNS
(S, February 2005)
RFC4025 describes a method of storing IPsec keying material in the 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.
Other Protocols That Use IPsec/IKE
IPsec and IKE were designed to provide IP-layer security protection to other Internet protocols' traffic as well as generic communications. Since IPsec is a general-purpose protocol, in some cases, its features do not provide the granularity or distinctive features required by another protocol; in some cases, its overhead or prerequisites do not match another protocol's requirements. However, a number of other protocols do use IKE and/or IPsec to protect some or all of their communications.
Mobile IP (MIPv4 and MIPv6)
RFC 4093, Problem Statement: Mobile IPv4 Traversal of Virtual
Private Network (VPN) Gateways (I, August 2005)
RFC4093 describes the issues with deploying Mobile IPv4 across virtual private networks (VPNs). IPsec is one of the VPN technologies covered by this document. It identifies 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.
RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways
(S, June 2008)
RFC5265 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.
RFC 3776, Using IPsec to Protect Mobile IPv6 Signaling Between
Mobile Nodes and Home Agents (S, June 2004)
This document specifies 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 IKEv1 to establish the SAs automatically. Mobile IPv6 requires considering the home address destination option and Routing Header in IPsec processing. Also, IPsec and IKE security association addresses can be updated by Mobile IPv6 signaling messages.
RFC 4877, Mobile IPv6 Operation with IKEv2 and the Revised IPsec
Architecture (S, April 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. This document also specifies the use of IKEv2 configuration payloads for dynamic home address configuration. Finally, this document describes the use of IKEv2 in order to set up the SAs for Mobile IPv6.
RFC 5026, Mobile IPv6 Bootstrapping in Split Scenario
(S, October 2007)
RFC5026 extends RFC4877 to support dynamic discovery of home agents and the home network prefix; for the latter purpose, it specifies a new IKEv2 configuration attribute and notification. It describes how a Mobile IPv6 node can obtain the address of its home agent, its home address, and create IPsec security associations with its home agent using DNS lookups and security credentials preconfigured on the Mobile Node. It defines how a mobile node (MN) can request its home address and home prefixes through the Configuration Payload in the IKE_AUTH exchange and what attributes need to be present in the CFG_REQUEST messages in order to do this. It also specifies how the home agent can authorize the credentials used for IKEv2 exchange.
RFC 5213, Proxy Mobile IPv6 (S, August 2008)
RFC5213 describes a network-based mobility management protocol that is used to provide mobility services to 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.
RFC 5568, Mobile IPv6 Fast Handovers (S, July 2009)
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. RFC5568 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.
RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
(S, October 2008)
RFC5380 describes extensions to Mobile IPv6 and IPv6 Neighbor Discovery to allow for local mobility handling in order to reduce the amount of signaling 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.
Open Shortest Path First (OSPF)
RFC 4552, Authentication/Confidentiality for OSPFv3
(S, June 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. RFC4552 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. Since OSPFv3 exchanges multicast packets as well as unicast ones, the use of IKE within OSPFv3 is not appropriate. Therefore, this document mandates the use of manual keys.
Host Identity Protocol (HIP)
RFC 5201, Host Identity Protocol (E, April 2008)
IP addresses perform two distinct functions: host identifier and locator. 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 public key identifiers from a new Host Identity (HI) namespace for peer authentication. It uses the HMAC-SHA-1-96 and the AES-CBC algorithms with IPsec ESP and AH for protecting its signaling messages.
RFC 5202, Using the Encapsulating Security Payload (ESP)
Transport Format with the Host Identity Protocol (HIP) (E, April 2008)
The HIP base exchange specification RFC5201 does not describe any transport formats or methods for describing how ESP is used to protect user data to be used during the actual communication. RFC5202 specifies a set of HIP 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 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.
RFC 5206, End-Host Mobility and Multihoming with the Host
Identity (E, April 2008)
When a host uses HIP, the overlying protocol sublayers (e.g., transport layer sockets) and Encapsulating Security Payload (ESP) Security Associations (SAs) are bound to representations of these host identities, and the IP addresses are only used for packet forwarding. RFC5206 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.
RFC 5207, NAT and Firewall Traversal Issues of Host Identity
Protocol (HIP) (I, April 2008)
RFC5207 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.
Stream Control Transmission Protocol (SCTP)
RFC 3554, On the Use of Stream Control Transmission Protocol
(SCTP) with IPsec (S, July 2003)
The Stream Control Transmission Protocol (SCTP) is a reliable transport protocol operating on top of a connection-less packet network such as IP. RFC3554 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. This document applies only to IKEv1 and IPsec-v2; it does not apply to IKEv2 AND IPsec-v3.
Robust Header Compression (ROHC)
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.
RFC 5225, RObust Header Compression Version 2 (ROHCv2): Profiles
for RTP, UDP, IP, ESP, and UDP-Lite (S, April 2008)
RFC5225 defines an updated ESP/IP profile for use with ROHC version 2. It analyzes the ESP header and classifies the fields into several classes like static, well-known, irregular, etc., in order to efficiently compress the headers.
RFC 5856, Integration of Robust Header Compression over IPsec
Security Associations (I, May 2010)
RFC5856 describes a mechanism to compress inner IP headers at the ingress point of IPsec tunnels and to decompress them at the egress point. Since the Robust Header Compression (ROHC) specifications only describe operations on a per-hop basis, this document also specifies extensions to enable ROHC over multiple hops. This document applies only to tunnel mode SAs and does not support transport mode SAs.
RFC 5857, IKEv2 Extensions to Support Robust Header Compression
over IPsec (S, May 2010)
ROHC requires initial configuration at the compressor and decompressor ends. Since ROHC usually operates on a per-hop basis, this configuration information is carried over link-layer protocols such as PPP. Since RFC5856 operates over multiple hops, a different signaling mechanism is required. RFC5857 describes how to use IKEv2 in order to dynamically communicate the configuration parameters between the compressor and decompressor.
RFC 5858, IPsec Extensions to Support Robust Header Compression
over IPsec (S, May 2010)
RFC5856 describes how to use ROHC with IPsec. This is not possible without extensions to IPsec. RFC5858 describes the extensions needed to IPsec in order to support ROHC. Specifically, it describes extensions needed to the IPsec SPD, SAD, and IPsec processing including ICV computation and integrity verification.
Border Gateway Protocol (BGP)
RFC 5566, BGP IPsec Tunnel Encapsulation Attribute
(S, June 2009)
RFC5566 adds an additional BGP Encapsulation Subsequent Address Family Identifier (SAFI), allowing the use of IPsec and, optionally, IKE to protect BGP tunnels. It defines the use of AH and ESP in tunnel mode and the use of AH and ESP in transport mode to protect IP in IP and MPLS-in-IP tunnels. It also defines how public key fingerprints (hashes) are distributed via BGP and used later to authenticate IKEv2 exchange between the tunnel endpoints.
IPsec Benchmarking
The Benchmarking Methodology WG in the IETF is working on documents that relate to benchmarking IPsec [BMWG-1] [BMWG-2].
Methodology for Benchmarking IPsec Devices (Work in Progress)
[BMWG-1] defines a set of tests that can be used to measure and report the performance characteristics of IPsec devices. It extends the methodology defined for benchmarking network interconnecting devices to include IPsec gateways and adds further tests that can be used to measure IPsec performance of end-hosts. The document focuses on establishing a performance testing methodology for IPsec devices that support manual keying and IKEv1, but does not cover IKEv2.
Terminology for Benchmarking IPsec Devices (Work in Progress)
[BMWG-2] defines the standardized performance testing terminology for IPsec devices that support manual keying and IKEv1. It also describes the benchmark tests that would be used to test the performance of the IPsec devices.
Network Address Translators (NAT)
RFC 2709, Security Model with Tunnel-mode IPsec for NAT domains
(I, October 1999)
NAT devices provide transparent routing to end-hosts trying to communicate from disparate address realms, by modifying IP and transport headers en route. This makes it difficult for applications to pursue end-to-end application-level security. RFC2709 describes a security model by which tunnel mode IPsec security can be architected on NAT devices. It defines how NATs administer security policies and SA attributes based on private realm addressing. It also specifies how to operate IKE in such scenarios by specifying an IKE-ALG (Application Level Gateway) that translates policies from private realm addressing into public addressing. Although the model presented here uses terminology from IKEv1, it can be deployed within IKEv1, IKEv2, IPsec-v2, and IPsec-v3. This security model has not been widely adopted
Session Initiation Protocol (SIP)
RFC 3329, Security Mechanism Agreement for the Session
Initiation Protocol (SIP) (S, January 2003)
RFC3329 describes how a SIP client can select one of the various available SIP security mechanisms. In particular, the method allows secure negotiation to prevent bidding down attacks. It also describes a security mechanism called ipsec-3gpp and its associated parameters (algorithms, protocols, mode, SPIs and ports) as they are used in the 3GPP IP Multimedia Subsystem.
8.10. Explicit Packet Sensitivity Labels
8.10.1. RFC 5570, Common Architecture Label IPv6 Security Option
(CALIPSO) (I, July 2009)
RFC5570 describes a mechanism used to encode explicit packet Sensitivity Labels on IPv6 packets in Multi-Level Secure (MLS) networks. The method is implemented using an IPv6 hop-by-hop option. This document uses the IPsec Authentication Header (AH) in order to detect any malicious modification of the Sensitivity Label in a packet.
Other Protocols That Adapt IKE for Non-IPsec Functionality
Some protocols protect their traffic through mechanisms other than IPsec, but use IKEv2 as a basis for their key negotiation and key management functionality.
Extensible Authentication Protocol (EAP)
RFC 5106, The Extensible Authentication Protocol-Internet Key
Exchange Protocol version 2 (EAP-IKEv2) Method (E, February 2008)
RFC5106 specifies an Extensible Authentication Protocol (EAP) method that is based on the Internet Key Exchange version 2 (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.
Fibre Channel
RFC 4595, Use of IKEv2 in the Fibre Channel Security Association
Management Protocol (I, July 2006)
Fibre Channel (FC) is a gigabit-speed network technology used for Storage Area Networking. The Fibre Channel Security Protocols (FC- SP) standard 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 and Fibre Channel is transported over IP, there is the potential for confusion when IKEv2 is used for both IP and FC traffic. RFC4595 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.
Wireless Security
RFC 4705, GigaBeam High-Speed Radio Link Encryption
(I, October 2006)
RFC4705 describes the encryption and key management used by GigaBeam as part of the WiFiber(tm) family of radio-link products and is intended to serve as a guideline for similar wireless product development efforts to include comparable capabilities. It specifies the algorithms that are used to provide confidentiality and integrity protection of both subscriber and management traffic. It also specifies a custom security protocol that runs between two Gigabeam Radio Control Modules (RCMs).
10. Acknowledgements
The authors would like to thank Yaron Sheffer, Paul Hoffman, Yoav Nir, Rajeshwar Singh Jenwar, Alfred Hoenes, Al Morton, Gabriel Montenegro, Sean Turner, Julien Laganier, Grey Daley, Scott Moonen, Richard Graveman, Tero Kivinen, Pasi Eronen, Ran Atkinson, David Black, and Tim Polk for reviewing this document and suggesting changes.
11. Security Considerations
This RFC serves as a review of other documents and introduces no new security considerations itself; however, please see each of the individual documents described herein for security considerations related to each protocol.
12. References
12.1. Informative References
[BMWG-1] Kaeo, M. and T. Van Herck, "Methodology for Benchmarking
IPsec Devices", Work in Progress, July 2009.
[BMWG-2] Kaeo, M., Van Herck T., and M. Bustos, "Terminology for
Benchmarking IPsec Devices", Work in Progress, July 2009.
[IKE-MODE-CFG]
Dukes, D. and R. Pereira, "The ISAKMP Configuration Method", Work in Progress, September 2001.
[IKE-XAUTH]
Beaulieu, S. and R. Pereira, "Extended Authentication within IKE (XAUTH)", Work in Progress, October 2001.
[ISAKMP-MODE-CFG]
Pereira, R., Anand, S., and B. Patel, "The ISAKKMP Configuration Method", Work in Progress, August 1999.
[ISAKMP-XAUTH]
Pereira, R. and S. Beaulieu, "Extended Authentication within ISAKMP/Oakley (XAUTH)", Work in Progress, December 1999.
RFC2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC2026 Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
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.
RFC2402 Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
RFC2403 Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, November 1998.
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.
RFC2407 Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
RFC2408 Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998.
RFC2409 Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
RFC2410 Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998.
RFC2411 Thayer, R., Doraswamy, N., 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.
RFC2521 Karn, P. and W. Simpson, "ICMP Security Failures
Messages", RFC 2521, March 1999.
RFC2709 Srisuresh, P., "Security Model with Tunnel-mode IPsec for
NAT Domains", RFC 2709, October 1999.
RFC2857 Keromytis, A. and N. Provos, "The Use of HMAC-
RIPEMD-160-96 within ESP and AH", RFC 2857, June 2000.
RFC3051 Heath, J. and J. Border, "IP Payload Compression Using
ITU-T V.44 Packet Method", RFC 3051, January 2001.
RFC3056 Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
RFC3095 Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "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., Monsour, B., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 3173, September 2001.
RFC3329 Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T.
Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003.
RFC3456 Patel, B., Aboba, B., Kelly, S., 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., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
RFC3554 Bellovin, S., Ioannidis, J., Keromytis, A., 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., Rafalow, L., and E. Vyncke, "IPsec
Configuration Policy Information Model", RFC 3585, August 2003.
RFC3586 Blaze, M., Keromytis, A., Richardson, M., and L. Sanchez,
"IP Security Policy (IPSP) Requirements", RFC 3586, August 2003.
RFC3602 Frankel, S., Glenn, R., 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., Beaulieu, S., 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.
RFC3776 Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
RFC3830 Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
RFC3884 Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
Transport Mode for Dynamic Routing", RFC 3884, September 2004.
RFC3947 Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005.
RFC3948 Huttunen, A., Swander, B., Volpe, V., DiBurro, L., 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, March 2005.
RFC4046 Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, April 2005.
RFC4093 Adrangi, 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.
RFC4196 Lee, H., Yoon, J., Lee, S., and J. Lee, "The SEED Cipher
Algorithm and Its Use with IPsec", RFC 4196, October 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.
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 3rd, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4305, December 2005.
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., Moriai, S., and M. Kanda, "The Camellia Cipher
Algorithm and Its Use With IPsec", RFC 4312, December 2005.
RFC4322 Richardson, M. and D. Redelmeier, "Opportunistic
Encryption using the Internet Key Exchange (IKE)", RFC 4322, 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.
RFC4430 Sakane, S., Kamada, K., Thomas, M., 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.
RFC4478 Nir, Y., "Repeated Authentication in Internet Key Exchange
(IKEv2) Protocol", RFC 4478, April 2006.
RFC4494 Song, JH., Poovendran, R., and J. Lee, "The AES-CMAC-96
Algorithm and Its Use with IPsec", RFC 4494, June 2006.
RFC4535 Harney, H., Meth, U., Colegrove, A., 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.
RFC4595 Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel
Security Association Management Protocol", RFC 4595, July 2006.
RFC4615 Song, J., Poovendran, R., Lee, J., 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.
RFC4705 Housley, R. and A. Corry, "GigaBeam High-Speed Radio Link
Encryption", RFC 4705, October 2006.
RFC4718 Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 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., Charlet, R., Hardaker, W., Story, R., and C.
Wang, "IPsec Security Policy Database Configuration MIB", RFC 4807, March 2007.
RFC4809 Bonatti, C., Ed., Turner, S., Ed., and G. Lebovitz, 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 F. Dupont, "Mobile IPv6 Operation with
IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
RFC4891 Graveman, R., Parthasarathy, M., Savola, P., and H.
Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", 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.
RFC5026 Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed.,
"Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, October 2007.
RFC5106 Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, Y.,
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.
RFC5201 Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
Henderson, "Host Identity Protocol", RFC 5201, April 2008.
RFC5202 Jokela, P., Moskowitz, R., and P. Nikander, "Using the
Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)", RFC 5202, April 2008.
RFC5206 Nikander, P., Henderson, T., Ed., Vogt, C., and J. Arkko,
"End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008.
RFC5207 Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, April 2008.
RFC5213 Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., 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.
RFC5266 Devarapalli, V. and P. Eronen, "Secure Connectivity and
Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE)", BCP 136, RFC 5266, 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., Castelluccia, C., ElMalki, K., 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., Gross, G., and D. Ignjatic, "Multicast
Extensions to the Security Architecture for the Internet Protocol", RFC 5374, November 2008.
RFC5387 Touch, J., Black, D., 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", BCP 146, RFC 5406, February 2009.
RFC5529 Kato, A., Kanda, M., and S. Kanno, "Modes of Operation for
Camellia for Use with IPsec", RFC 5529, April 2009.
RFC5566 Berger, L., White, R., and E. Rosen, "BGP IPsec Tunnel
Encapsulation Attribute", RFC 5566, June 2009.
RFC5568 Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568,
July 2009.
RFC5570 StJohns, M., Atkinson, R., and G. Thomas, "Common
Architecture Label IPv6 Security Option (CALIPSO)", RFC 5570, July 2009.
RFC5660 Williams, N., "IPsec Channels: Connection Latching", RFC
5660, October 2009.
RFC5685 Devarapalli, V. and K. Weniger, "Redirect Mechanism for
the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5685, November 2009.
RFC5723 Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, January 2010.
RFC5739 Eronen, P., Laganier, J., and C. Madson, "IPv6
Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5739, February 2010.
RFC5840 Grewal, K., Montenegro, G., and M. Bhatia, "Wrapped
Encapsulating Security Payload (ESP) for Traffic Visibility", RFC 5840, April 2010.
RFC5856 Ertekin, E., Jasani, R., Christou, C., and C. Bormann,
"Integration of Robust Header Compression over IPsec Security Associations", RFC 5856, May 2010.
RFC5857 Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C.
Bormann, "IKEv2 Extensions to Support Robust Header Compression over IPsec", RFC 5857, May 2010.
RFC5858 Ertekin, E., Christou, C., and C. Bormann, "IPsec
Extensions to Support Robust Header Compression over IPsec", RFC 5858, May 2010.
RFC5879 Kivinen, T. and D. McDonald, "Heuristics for Detecting
ESP-NULL Packets", RFC 5879, May 2010.
RFC5903 Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
Prime (ECP Groups) for IKE and IKEv2", RFC 5903, June 2010.
RFC5930 Shen, S., Mao, Y., and NSS. Murthy, "Using Advanced
Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol", RFC 5930, July 2010.
RFC5996 Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
RFC5998 Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension
for EAP-Only Authentication in IKEv2", RFC 5998, September 2010.
RFC6027 Nir, Y., "IPsec Cluster Problem Statement", RFC 6027,
October 2010.
Appendix A. Summary of Algorithm Requirement Levels
Table 1: Algorithm Requirement Levels
+--------------------------+----------------------------------------+ | ALGORITHM | REQUIREMENT LEVEL | | | IKEv1 IKEv2 IPsec-v2 IPsec-v3 | +--------------------------+----------------------------------------+ |Encryption Algorithms: | |--------------------- | | ESP-NULL | N/A N/A MUST MUST | | | | | 3DES-CBC | MUST MUST- MUST MUST- | | | | | Blowfish/CAST/IDEA/RC5 | optional optional optional optional | | | | | AES-CBC 128-bit key | SHOULD SHOULD+ MUST MUST | | | | | AES-CBC 192/256-bit key | optional optional optional optional | | | | | AES-CTR | undefined optional SHOULD SHOULD | | | | | Camellia-CBC | optional optional optional optional | | | | | Camellia-CTR | undefined undefined undefined optional | | | | | SEED-CBC | undefined undefined optional undefined| | | | |Integrity-Protection Algorithms: | |------------------------------ | | HMAC-SHA-1 | MUST MUST MUST MUST | | | | | AES-XCBC-MAC | undefined optional SHOULD+ SHOULD+ | | | | | HMAC-SHA-256/384/512 | optional optional optional optional | | | | | AES-GMAC | N/A N/A undefined optional | | | | | HMAC-MD5 | MAY optional MAY MAY | | | | | AES-CMAC | undefined optional undefined optional | | | | | HMAC-RIPEMD | undefined undefined optional undefined| +--------------------------+----------------------------------------+
Table 1: Algorithm Requirement Levels (continued)
+--------------------------+----------------------------------------+ | ALGORITHM | REQUIREMENT LEVEL | | | IKEv1 IKEv2 IPsec-v2 IPsec-v3 | +--------------------------+----------------------------------------+ |Combined Mode Algorithms: | |------------------------ | | AES-CCM | N/A optional N/A optional | | | | | AES-GCM | N/A optional N/A optional | | | | | AES-GMAC | N/A N/A undefined optional | | | | | Camellia-CCM | N/A undefined N/A optional | | | | |Pseudorandom Functions: | |----------------------- | | PRF-HMAC-SHA1 | MUST MUST | | | | | PRF-HMAC-SHA-256/384/512 | optional optional | | | | | AES-XCBC-PRF | undefined SHOULD+ | | | | | AES-CMAC-PRF | undefined optional | | | | |Diffie-Hellman Algorithms: | |------------------------- | | DH MODP grp 1 | MAY optional | | | | | DH MODP grp 2 | MUST MUST- | | | | | DH MODP grp 5 | optional optional | | | | | DH MODP grp 14 | SHOULD SHOULD+ | | | | | DH MODP grp 15-18 | optional optional | | | | | DH MODP grp 22-24 | optional optional | | | | | DH EC grp 3-4 | MAY undefined | | | | | DH EC grp 19-21 | optional optional | | | | | DH EC grp 25-26 | optional optional | +--------------------------+----------------------------------------+
Authors' Addresses
Sheila Frankel NIST Bldg. 223 Rm. B366 Gaithersburg, MD 20899
Phone: 1-301-975-3297 EMail: [email protected]
Suresh Krishnan Ericsson 8400 Decarie Blvd. Town of Mount Royal, QC Canada
Phone: 1-514-345-7900 x42871 EMail: [email protected]