|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
RFCs & Drafts related to
IPSEC working group
|
|
|
|
|
|
|
|
|
##
##
##
## IPSECwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: May 13, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
##
##
##
## IPSECwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
##
##
##
## IPSECwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
Excerpts from an IESG message on 29 April 2005:
|
|
|
|
The IP Security Protocol (ipsec) WG in the Security Area has concluded.
...
There are a few remaining active documents. They deal with the addition of
elliptic curve cryptography (ECC) to IKE and IKEv2. This item was
abandoned by the WG several years ago, and for good reasons, there is renewed
interest. Very few participants are involved in these documents. Therefore, these
documents will progress as individual standards-track documents.
|
|
|
|
|
|
|
|
##
##
##
## IPSECwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC2104
02/1997
(11 p.)
[html]
[pdf(2)] |
H. Krawczyk
M. Bellare
R. Canetti |
|
HMAC: Keyed-Hashing for Message Authentication |
|
This document describes HMAC, a mechanism for message authentication
using cryptographic hash functions. HMAC can be used with any
iterative cryptographic hash function, e.g., MD5, SHA-1, in
combination with a secret shared key. The cryptographic strength of
HMAC depends on the properties of the underlying hash function.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2403
11/1998
(7 p.)
[html]
[pdf(2)] |
C. Madson
R. Glenn |
|
The Use of HMAC-MD5-96 within ESP and AH |
|
This memo describes the use of the HMAC algorithm [RFC-2104] in
conjunction with the MD5 algorithm [RFC-1321] as an authentication
mechanism within IPsec Encapsulating Security Payload
(ESP) and IPsec Authentication Header (AH). HMAC with MD5
provides data origin authentication and integrity protection.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC2410
11/1998
(6 p.)
[html]
[pdf(2)] |
R. Glenn
S. Kent |
|
The NULL Encryption Algorithm and its Use with IPsec |
|
This memo defines the NULL encryption algorithm and its use with the
IPsec Encapsulating Security Payload (ESP). NULL does nothing to
alter plaintext data. In fact, NULL, by itself, does nothing. NULL
provides the means for ESP to provide authentication and integrity
without confidentiality.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC2411
11/1998
(11 p.)
[html]
[pdf(2)] |
R. Thayer
N. Doraswamy
R. Glenn |
|
IP Security Document Roadmap |
|
The IPsec protocol suite is used to provide privacy and
authentication services at the IP layer. Several documents are used
to describe this protocol suite. The interrelationship and
organization of the various documents covering the IPsec protocol are
discussed here. An explanation of what to find in which document,
and what to include in new Encryption Algorithm and Authentication
Algorithm documents are described.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2412
11/1998
(55 p.)
[html]
[pdf(2)] |
H. Orman |
|
The OAKLEY Key Determination Protocol |
This document describes a protocol, named OAKLEY, by which two
authenticated parties can agree on secure and secret keying material.
The basic mechanism is the Diffie-Hellman key exchange algorithm.
The OAKLEY protocol supports Perfect Forward Secrecy, compatibility
with the ISAKMP protocol for managing security associations, user-
defined abstract group structures for use with the Diffie-Hellman
algorithm, key updates, and incorporation of keys distributed via
out-of-band mechanisms.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2451
11/1998
(14 p.)
[html]
[pdf(2)] |
R. Pereira
R. Adams |
|
The ESP CBC-Mode Cipher Algorithms |
|
This document describes how to use CBC-mode cipher algorithms with
the IPSec ESP (Encapsulating Security Payload) Protocol. It not only
clearly states how to use certain cipher algorithms, but also how to
use all CBC-mode cipher algorithms.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2857
06/2000
(7 p.)
[html]
[pdf(2)] |
A. Keromytis
N. Provos |
|
The Use of HMAC-RIPEMD-160-96 within ESP and AH |
|
This memo describes the use of the HMAC algorithm [RFC 2104] in
conjunction with the RIPEMD-160 algorithm as an
authentication mechanism within IPsec Encapsulating
Security Payload (ESP) and IPsec Authentication Header
(AH). HMAC with RIPEMD-160 provides data origin authentication and
integrity protection.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3456
01/2003
(18 p.)
[html]
[pdf(2)] |
B. Patel
B. Aboba
S. Kelly
V. Gupta |
|
Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode |
|
This memo explores the requirements for host configuration in IPsec
tunnel mode, and describes how the Dynamic Host Configuration
Protocol (DHCPv4) may be leveraged for configuration. In many remote
access scenarios, a mechanism for making the remote host appear to be
present on the local corporate network is quite useful. This may be
accomplished by assigning the host a "virtual" address from the
corporate network, and then tunneling traffic via IPsec from the
host's ISP-assigned address to the corporate security gateway. In
IPv4, DHCP provides for such remote host configuration.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3566
09/2003
(11 p.)
[html]
[pdf(2)] |
S. Frankel
H. Herbert |
|
The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec |
|
A Message Authentication Code (MAC) is a key-dependent one way hash
function. One popular way to construct a MAC algorithm is to use a
block cipher in conjunction with the Cipher-Block-Chaining (CBC) mode
of operation. The classic CBC-MAC algorithm, while secure for
messages of a pre-selected fixed length, has been shown to be
insecure across messages of varying lengths such as the type found in
typical IP datagrams. This memo specifies the use of AES in CBC mode
with a set of extensions to overcome this limitation. This new
algorithm is named AES-XCBC-MAC-96.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3602
09/2003
(15 p.)
[html]
[pdf(2)] |
S. Frankel
R. Glenn
S. Kelly |
|
The AES-CBC Cipher Algorithm and Its Use with IPsec |
|
This document describes the use of the Advanced Encryption Standard
(AES) Cipher Algorithm in Cipher Block Chaining (CBC) Mode, with an
explicit Initialization Vector (IV), as a confidentiality mechanism
within the context of the IPsec Encapsulating Security Payload (ESP).
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3706
02/2004
(13 p.)
[html]
[pdf(2)] |
G. Huang
S. Beaulieu
D. Rochefort |
|
A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers |
|
This document describes the method detecting a dead Internet Key
Exchange (IKE) peer that is presently in use by a number of vendors.
The method, called Dead Peer Detection (DPD) uses IPSec traffic
patterns to minimize the number of IKE messages that are needed to
confirm liveness. DPD, like other keepalive mechanisms, is needed to
determine when to perform IKE peer failover, and to reclaim lost
resources.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3715
03/2004
(18 p.)
[html]
[pdf(2)] |
B. Aboba
W. Dixon |
|
IPsec-Network Address Translation (NAT) Compatibility Requirements |
|
This document describes known incompatibilities between Network
Address Translation (NAT) and IPsec, and describes the requirements
for addressing them. Perhaps the most common use of IPsec is in
providing virtual private networking capabilities. One very popular
use of Virtual Private Networks (VPNs) is to provide telecommuter
access to the corporate Intranet. Today, NATs are widely deployed in
home gateways, as well as in other locations likely to be used by
telecommuters, such as hotels. The result is that IPsec-NAT
incompatibilities have become a major barrier in the deployment of
IPsec in one of its principal uses.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3884
09/2004
(25 p.)
[html]
[pdf(2)] |
J. Touch
L. Eggert
Y. Wang |
|
Use of IPsec Transport Mode for Dynamic Routing |
|
IPsec can secure the links of a multihop network to protect
communication between trusted components, e.g., for a secure virtual
network (VN), overlay, or virtual private network (VPN). Virtual
links established by IPsec tunnel mode can conflict with routing and
forwarding inside VNs because IP routing depends on references to
interfaces and next-hop IP addresses. The IPsec tunnel mode
specification is ambiguous on this issue, so even compliant
implementations cannot be trusted to avoid conflicts. An alternative
to tunnel mode uses non-IPsec IPIP encapsulation together with IPsec
transport mode, which we call IIPtran. IPIP encapsulation occurs as
a separate initial step, as the result of a forwarding lookup of the
VN packet. IPsec transport mode processes the resulting (tunneled) IP
packet with an SA determined through a security association database
(SAD) match on the tunnel header. IIPtran supports dynamic routing
inside the VN without changes to the current IPsec architecture.
IIPtran demonstrates how to configure any compliant IPsec
implementation to avoid the aforementioned conflicts. IIPtran is
also compared to several alternative mechanisms for VN routing and
their respective impact on IPsec, routing, policy enforcement, and
interactions with the Internet Key Exchange (IKE).
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3947
01/2005
(16 p.)
[html]
[pdf(2)] |
T. Kivinen
B. Swander
A. Huttunen
V. Volpe |
|
Negotiation of NAT-Traversal in the IKE |
|
This document describes how to detect one or more network address
translation devices (NATs) between IPsec hosts, and how to negotiate
the use of UDP encapsulation of IPsec packets through NAT boxes in
Internet Key Exchange (IKE).
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3948
01/2005
(15 p.)
[html]
[pdf(2)] |
A. Huttunen
B. Swander
V. Volpe
L. DiBurro
M. Stenberg |
|
UDP Encapsulation of IPsec ESP Packets |
|
This protocol specification defines methods to encapsulate and
decapsulate IP Encapsulating Security Payload (ESP) packets inside
UDP packets for traversing Network Address Translators. ESP
encapsulation, as defined in this document, can be used in both IPv4
and IPv6 scenarios. Whenever negotiated, encapsulation is used with
Internet Key Exchange (IKE).
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4106
06/2005
(11 p.)
[html]
[pdf(2)] |
J. Viega
D. McGrew |
|
The Use of Galois/Counter Mode (GCM)
in IPsec Encapsulating Security Payload (ESP) |
|
This memo describes the use of the Advanced Encryption Standard (AES)
in Galois/Counter Mode (GCM) as an IPsec Encapsulating Security
Payload (ESP) mechanism to provide confidentiality and data origin
authentication. This method can be efficiently implemented in
hardware for speeds of 10 gigabits per second and above, and is also
well-suited to software implementations.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4109
05/2005
(5 p.)
[html]
[pdf(2)] |
P. Hoffman |
|
Algorithms for Internet Key Exchange version 1 (IKEv1) |
|
The required and suggested algorithms in the original Internet Key
Exchange version 1 (IKEv1) specification do not reflect the current
reality of the IPsec market requirements. The original specification
allows weak security and suggests algorithms that are thinly
implemented. This document updates RFC 2409, the original
specification, and is intended for all IKEv1 implementations deployed
today.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4196
10/2005
(12 p.)
[html]
[pdf(2)] |
H.J. Lee
J.H. Yoon
S.L. Lee
J.I. Lee |
|
The SEED Cipher Algorithm and Its Use with IPsec |
|
This document describes the use of the SEED block cipher algorithm in
the Cipher Block Chaining Mode, with an explicit IV, as a
confidentiality mechanism within the context of the IPsec
Encapsulating Security Payload (ESP).
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4302
12/2005
(34 p.)
[html]
[pdf(2)] |
S. Kent |
|
IP Authentication Header |
|
This document describes an updated version of the IP Authentication
Header (AH), which is designed to provide authentication services in
IPv4 and IPv6. This document obsoletes RFC 2402
(November 1998).
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4303
12/2005
(44 p.)
[html]
[pdf(2)] |
S. Kent |
|
IP Encapsulating Security Payload (ESP) |
|
This document describes an updated version of the Encapsulating
Security Payload (ESP) protocol, which is designed to provide a mix
of security services in IPv4 and IPv6. ESP is used to provide
confidentiality, data origin authentication, connectionless
integrity, an anti-replay service (a form of partial sequence
integrity), and limited traffic flow confidentiality.
This document obsoletes RFC 2406 (November 1998).
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4306
12/2005
(99 p.)
[html]
[pdf(2)] |
C. Kaufman |
|
Internet Key Exchange (IKEv2) Protocol |
This document describes version 2 of the Internet Key Exchange (IKE)
protocol. IKE is a component of IPsec used for performing mutual
authentication and establishing and maintaining security associations
(SAs).
This version of the IKE specification combines the contents of what
were previously separate documents, including Internet Security
Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC
2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network
Address Translation (NAT) Traversal, Legacy authentication, and
remote address acquisition.
Version 2 of IKE does not interoperate with version 1, but it has
enough of the header format in common that both versions can
unambiguously run over the same UDP port.
This document obsoletes RFCs 2407, 2408 and 2409
(November 1998).
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4307
12/2005
(6 p.)
[html]
[pdf(2)] |
J. Schiller |
|
Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2) |
|
The IPsec series of protocols makes use of various cryptographic
algorithms in order to provide security services. The Internet Key
Exchange (IKE (RFC 2409) and IKEv2) provide a mechanism to negotiate
which algorithms should be used in any given association. However,
to ensure interoperability between disparate implementations, it is
necessary to specify a set of mandatory-to-implement algorithms to
ensure that there is at least one algorithm that all implementations
will have available. This document defines the current set of
algorithms that are mandatory to implement as part of IKEv2, as well
as algorithms that should be implemented because they may be promoted
to mandatory at some future time.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4308
12/2005
(7 p.)
[html]
[pdf(2)] |
P. Hoffman |
|
Cryptographic Suites for IPsec |
|
The IPsec, Internet Key Exchange (IKE), and IKEv2 protocols rely on
security algorithms to provide privacy and authentication between the
initiator and responder. There are many such algorithms available,
and two IPsec systems cannot interoperate unless they are using the
same algorithms. This document specifies optional suites of
algorithms and attributes that can be used to simplify the
administration of IPsec when used in manual keying mode, with IKEv1
or with IKEv2.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4312
12/2005
(8 p.)
[html]
[pdf(2)] |
A. Kato
S. Moriai
M. Kanda |
|
The Camellia Cipher Algorithm and Its Use With IPsec |
|
This document describes the use of the Camellia block cipher
algorithm in Cipher Block Chaining Mode, with an explicit
Initialization Vector, as a confidentiality mechanism within the
context of the IPsec Encapsulating Security Payload (ESP).
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4322
12/2005
(44 p.)
[html]
[pdf(2)] |
M. Richardson
D.H. Redelmeier |
|
Opportunistic Encryption using the Internet Key Exchange (IKE) |
This document describes opportunistic encryption (OE) as designed and
implemented by the Linux FreeS/WAN project. OE uses the Internet Key
Exchange (IKE) and IPsec protocols. The objective is to allow
encryption for secure communication without any pre-arrangement
specific to the pair of systems involved. DNS is used to distribute
the public keys of each system involved. This is resistant to
passive attacks. The use of DNS Security (DNSSEC) secures this
system against active attackers as well.
As a result, the administrative overhead is reduced from the square
of the number of systems to a linear dependence, and it becomes
possible to make secure communication the default even when the
partner is not known in advance.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4718
10/2006
(58 p.)
[html]
[pdf(2)] |
P. Eronen
P. Hoffman |
|
IKEv2 Clarifications and Implementation Guidelines |
|
This document clarifies many areas of the IKEv2 specification. It
does not to introduce any changes to the protocol, but rather
provides descriptions that are less prone to ambiguous
interpretations. The purpose of this document is to encourage the
development of interoperable implementations.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4739
11/2006
(11 p.)
[html]
[pdf(2)] |
P. Eronen
J. Korhonen |
|
Multiple Authentication Exchanges
in the Internet Key Exchange (IKEv2) Protocol |
|
The Internet Key Exchange (IKEv2) protocol supports several
mechanisms for authenticating the parties, including signatures with
public-key certificates, shared secrets, and Extensible
Authentication Protocol (EAP) methods. Currently, each endpoint uses
only one of these mechanisms to authenticate itself. This document
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. When backend authentication servers
are used, they can belong to different administrative domains, such
as the network access provider and the service provider.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4753
01/2007
(16 p.)
[html]
[pdf(2)] |
D. Fu
J. Solinas |
|
ECP Groups for IKE and IKEv2 |
|
This document describes new Elliptic Curve Cryptography (ECC) groups
for use in the Internet Key Exchange (IKE) and Internet Key Exchange
version 2 (IKEv2) protocols in addition to previously defined groups.
Specifically, the new curve groups are based on modular arithmetic
rather than binary arithmetic. These new groups are defined to align
IKE and IKEv2 with other ECC implementations and standards,
particularly NIST standards. In addition, the curves defined here
can provide more efficient implementation than previously defined ECC
groups.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4754
01/2007
(15 p.)
[html]
[pdf(2)] |
D. Fu
J. Solinas |
|
IKE and IKEv2 Authentication Using
the Elliptic Curve Digital Signature Algorithm (ECDSA) |
|
This document describes how the Elliptic Curve Digital Signature
Algorithm (ECDSA) may be used as the authentication method within the
Internet Key Exchange (IKE) and Internet Key Exchange version 2
(IKEv2) protocols. ECDSA may provide benefits including
computational efficiency, small signature sizes, and minimal
bandwidth compared to other available digital signature methods.
This document adds ECDSA capability to IKE and IKEv2 without
introducing any changes to existing IKE operation.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4835
04/2007
(11 p.)
[html]
[pdf(2)] |
V. Manral |
|
Cryptographic Algorithm Implementation Requirements for
Encapsulating Security Payload (ESP) and Authentication Header (AH) |
|
The IPsec series of protocols makes use of various cryptographic
algorithms in order to provide security services. The Encapsulating
Security Payload (ESP) and the Authentication Header (AH) provide two
mechanisms for protecting data being sent over an IPsec Security
Association (SA). To ensure interoperability between disparate
implementations, it is necessary to specify a set of mandatory-to-implement
algorithms to ensure that there is at least one algorithm
that all implementations will have available. This document defines
the current set of mandatory-to-implement algorithms for ESP and AH
as well as specifying algorithms that should be implemented because
they may be promoted to mandatory at some future time.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4868
05/2007
(21 p.)
[html]
[pdf(2)] |
S. Kelly
S. Frankel |
|
Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec |
|
This specification describes the use of Hashed Message Authentication
Mode (HMAC) in conjunction with the SHA-256, SHA-384, and SHA-512
algorithms in IPsec. These algorithms may be used as the basis for
data origin authentication and integrity verification mechanisms for
the Authentication Header (AH), Encapsulating Security Payload (ESP),
Internet Key Exchange Protocol (IKE), and IKEv2 protocols, and also
as Pseudo-Random Functions (PRFs) for IKE and IKEv2. Truncated
output lengths are specified for the authentication-related variants,
with the corresponding algorithms designated as HMAC-SHA-256-128,
HMAC-SHA-384-192, and HMAC-SHA-512-256. The PRF variants are not
truncated, and are called PRF-HMAC-SHA-256, PRF-HMAC-SHA-384, and
PRF-HMAC-SHA-512.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
