sharpetronics/strongswan
1
0
Fork 0
mirror of https://github.com/strongswan/strongswan.git synced 2025-10-03 00:00:24 -04:00
Code Issues Projects Releases Wiki Activity

doc: Removed the standards directory

Browse Source 
This collection of Internet standards and drafts hadn't been
updated for a long time and the documents are readily available
on the Internet anyway. The strongSwan documentation page

  https://docs.strongswan.org/docs/5.9/features/ietf.html

specifies which standards are currently supported.
This commit is contained in:
Andreas Steffen 2022-07-12 10:20:30 +02:00
parent 2b474073d9
commit 110e8e6608
19 changed files with 0 additions and 50398 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

505
doc/standards/draft-sheffer-ikev2-gtc-00.txt
View File

@ -1,505 +0,0 @@
Network Working Group Y. Sheffer
Internet-Draft Check Point
Intended status: Informational July 6, 2008
Expires: January 7, 2009
Using EAP-GTC for Simple User Authentication in IKEv2
draft-sheffer-ikev2-gtc-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2009.
Abstract
Despite many years of effort, simple username-password authentication
is still prevalent. In many cases a password is the only credential
available to the end user. IKEv2 uses EAP as a sub-protocol for user
authentication. This provides a well-specified and extensible
architecture. To this day EAP does not provide a simple password-
based authentication method. The only existing password
authentication methods either require the peer to know the password
in advance (EAP-MD5), or are needlessly complex when used within
IKEv2 (e.g. PEAP). This document codifies the common practice of
using EAP-GTC for this type of authentication, with the goal of
achieving maximum interoperability. The various security issues are
extensively analyzed.
Sheffer Expires January 7, 2009 [Page 1]
Internet-Draft EAP-GTC in IKEv2 July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Alternatives to EAP-GTC in IKEv2 . . . . . . . . . . . . . . . 4
3.1. Non-password credentials . . . . . . . . . . . . . . . . . 4
3.2. Using the IKE preshared secret . . . . . . . . . . . . . . 4
3.3. EAP-MD5 , EAP-MSCHAPv2 and mutual authentication
schemes . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Using EAP-GTC in IKE: Details . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6.1. Key generation and MITM protection . . . . . . . . . . . . 6
6.2. Protection of credentials between the IKE gateway and
the AAA server . . . . . . . . . . . . . . . . . . . . . . 6
6.3. Server authentication . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 8
A.1. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Sheffer Expires January 7, 2009 [Page 2]
Internet-Draft EAP-GTC in IKEv2 July 2008
1. Introduction
"Oh dear! It's possible that we have added EAP to IKE to support a
case that EAP can't support." -- C. Kaufman.
Despite many years of effort, simple username-password authentication
is still prevalent. In many cases a password is the only credential
available to the end user.
IKEv2 [RFC4306] uses the Extensible Authentication Protocol (EAP) as
a sub-protocol for user authentication. This provides a well-
specified and extensible architecture and enables useful capabilities
like SIM authentication. Unfortunately, for a number of reasons EAP
still does not provide a simple password-based authentication method.
The only existing password authentication methods either require the
peer to know the password in advance (EAP-MD5), or are needlessly
complex when used within IKEv2 (e.g. PEAP).
Technically, the IKE preshared secret authentication mode can be used
for password authentication. In fact even the IKEv2 RFC winks at
this practice. But this use jeopardizes the protocol's security and
should clearly be avoided (more details below).
EAP is used in IKEv2 at a stage when the remote access gateway has
already been authenticated. At this point the user has a high enough
level of trust to send his or her password to the gateway. Such an
exchange is enabled by the EAP Generic Token Card (GTC) method, which
is a simple text transport between the two EAP peers. To quote
[RFC3748]:
The EAP GTC method is intended for use with the Token Cards
supporting challenge/response authentication and MUST NOT be used
to provide support for cleartext passwords in the absence of a
protected tunnel with server authentication.
IKEv2 does indeed provide "a protected tunnel with server
authentication". The current document updates [RFC3748] by making an
exception and allowing the use of GTC to carry secret credentials, in
this specific situation. Section 6 further elaborates on the
security properties of this solution.
Other protocols provide a similar protected tunnel, for example TLS-
EAP, described in [I-D.nir-tls-eap]. These protocols however are out
of scope for this document.
Sheffer Expires January 7, 2009 [Page 3]
Internet-Draft EAP-GTC in IKEv2 July 2008
2. Terminology
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].
3. Alternatives to EAP-GTC in IKEv2
This section presents a few of the alternatives to EAP-GTC, and
explains why they are either insecure or impractical given today's
common identity management infrastructure.
3.1. Non-password credentials
Certificate-based authentication, especially when combined with
hardware protection (e.g. a hardware token), can be deployed in a
more secure manner than the form of password authentication which we
discuss. However, due to a host of issues to do with cost,
inconvenience and reliability this solution has not gained wide
market acceptance over the last 10 years.
3.2. Using the IKE preshared secret
Sec. 2.15 of RFC 4306 points out that the generation of the IKE
preshared secret from a weak password is insecure. Such use is
vulnerable to off line password guessing by an active attacker. All
the attacker needs to do is respond correctly to the first IKE_INIT
message, and then record the third IKE message. This is then
followed by a dictionary attack to obtain the password.
3.3. EAP-MD5 , EAP-MSCHAPv2 and mutual authentication schemes
Challenge-response schemes, like EAP-MD5 and EAP-MSCHAPv2, have a
clear security advantage over sending the plaintext password to the
gateway. Password-based mutual authentication schemes like SRP have
a further advantage in that the gateway's authentication is much
stronger than when using certificates alone, since the AAA server
proves its knowledge of a per-client credential, and the gateway
proves that it has been authorized by the AAA server for that
particular client.
Unfortunately all of these methods also suffer from a major drawback:
the gateway must have a priori access to the plaintext password.
While many RADIUS servers may indeed have such access, other very
common deployments do not provide it. One typical example is when
the gateway directly accesses an LDAP directory (or a Microsoft
Active Directory) to authenticate the user. The usual way to do that
Sheffer Expires January 7, 2009 [Page 4]
Internet-Draft EAP-GTC in IKEv2 July 2008
is by issuing an LDAP Bind operation into the directory, using the
just-received plaintext password. Often in this case it is the IKE
gateway that terminates the EAP protocol, and it needs a way to
obtain the raw password.
An additional issue with mutual authentication schemes is their heavy
IP encumbrance, which has resulted in a scarcity of standards using
them and a low rate of market adoption.
4. Using EAP-GTC in IKE: Details
EAP-GTC is specified in [RFC3748], Sec. 5.6. This section is non-
normative, and is merely an interpretation of this specification in
the context of IKEv2.
Simple authentication requires a non secret identity ("user name")
and a secret credential ("password"). Both of these are arbitrary
Unicode strings, although implementations may impose length
constraints.
In the case of EAP-GTC, the user name is conveyed in the IKE IDi
payload. According to [RFC4718], Sec. 3.4, the user name can be
encoded in one of two ways: as a simple user name, in which case the
ID_KEY_ID identification type is used; or as a combination user name
plus realm, in which case the format is a NAI [RFC4282] and the
identification type is ID_RFC822_ADDR. In either case, the user name
is a Unicode string encoded as UTF-8. Using the EAP Identity payload
is redundant, and if it is used, it should be identical to the IDi
payload.
EAP-GTC consists of a simple 2-message exchange. The contents of the
Type-Data field in the Request should not be interpreted in any way,
and should be displayed to the user. This field contains a Unicode
string, encoded as UTF-8.
The password is sent in the EAP Response. The Type-Data field of the
Response is also a Unicode string encoded as UTF-8. Note that none
of the IDi payload, the EAP Request or the EAP Response is null-
terminated.
If either or both the user name and the password are non-ASCII, they
should be normalized by the IKE client before the IKE/EAP message is
constructed. The normalization method is SASLprep, [RFC4013].
Sheffer Expires January 7, 2009 [Page 5]
Internet-Draft EAP-GTC in IKEv2 July 2008
5. IANA Considerations
This document does not require any action by IANA.
6. Security Considerations
6.1. Key generation and MITM protection
Modern EAP methods generate a key shared between the two protocol
peers. GTC does not (and cannot) generate such a key. RFC 4306
mandates that:
EAP methods that do not establish a shared key SHOULD NOT be used,
as they are subject to a number of man-in-the-middle attacks
[EAPMITM] if these EAP methods are used in other protocols that do
not use a server-authenticated tunnel.
However GTC must never be used in such a situation, since the client
would be sending its credentials openly to an unauthenticated server.
When using GTC with IKEv2, the implementation (or local
administrators) MUST ensure that the same credentials are never used
in such a manner.
6.2. Protection of credentials between the IKE gateway and the AAA
server
In the proposed solution, the raw credentials are sent from the IKE
gateway to a AAA server, typically a RADIUS server. These
credentials and the associated messaging MUST be strongly protected.
Some of the existing options include:
o An IPsec tunnel between the gateway and the AAA server.
o RADIUS over TCP with TLS, [I-D.winter-radsec].
o RADIUS over UDP with DTLS, [I-D.dekok-radext-dtls] (expired).
The legacy RADIUS security mechanism (Sec. 5.2 of [RFC2865]) is
considered weak and SHOULD NOT be used when better alternatives are
available.
6.3. Server authentication
The client may only send its cleartext credentials after it has
positively authenticated the server. This authentication is
specified, albeit rather vaguely, in [RFC4306] and is out of scope of
the current document. Unauthenticated (BTNS) derivatives of IKE MUST
NOT be used with EAP-GTC.
Sheffer Expires January 7, 2009 [Page 6]
Internet-Draft EAP-GTC in IKEv2 July 2008
7. Acknowledgments
I would like to thank Yoav Nir and Charlie Kaufman for their helpful
comments.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
and Passwords", RFC 4013, February 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
8.2. Informative References
[EAPMITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
in Tunneled Authentication Protocols", November 2002,
<http://eprint.iacr.org/2002/163>.
[I-D.dekok-radext-dtls]
DeKok, A., "DTLS as a Transport Layer for RADIUS",
draft-dekok-radext-dtls-00 (work in progress),
February 2007.
[I-D.nir-tls-eap]
Nir, Y., Tschofenig, H., and P. Gutmann, "TLS using EAP
Authentication", draft-nir-tls-eap-03 (work in progress),
April 2008.
[I-D.winter-radsec]
Winter, S., McCauley, M., and S. Venaas, "RadSec Version 2
- A Secure and Reliable Transport for the RADIUS
Protocol", draft-winter-radsec-01 (work in progress),
February 2008.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
Sheffer Expires January 7, 2009 [Page 7]
Internet-Draft EAP-GTC in IKEv2 July 2008
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
Implementation Guidelines", RFC 4718, October 2006.
Appendix A. Change Log
A.1. -00
Initial version.
Author's Address
Yaron Sheffer
Check Point Software Technologies Ltd.
5 Hasolelim St.
Tel Aviv 67897
Israel
Email: yaronf@checkpoint.com
Sheffer Expires January 7, 2009 [Page 8]
Internet-Draft EAP-GTC in IKEv2 July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Sheffer Expires January 7, 2009 [Page 9]

1401
doc/standards/draft-sheffer-ipsec-failover-03.txt
View File

File diff suppressed because it is too large Load Diff

732
doc/standards/rfc1994.txt
View File

@ -1,732 +0,0 @@
Network Working Group W. Simpson
Request for Comments: 1994 DayDreamer
Obsoletes: 1334 August 1996
Category: Standards Track
PPP Challenge Handshake Authentication Protocol (CHAP)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
PPP also defines an extensible Link Control Protocol, which allows
negotiation of an Authentication Protocol for authenticating its peer
before allowing Network Layer protocols to transmit over the link.
This document defines a method for Authentication using PPP, which
uses a random Challenge, with a cryptographically hashed Response
which depends upon the Challenge and a secret key.
Table of Contents
1. Introduction .......................................... 1
1.1 Specification of Requirements ................... 1
1.2 Terminology ..................................... 2
2. Challenge-Handshake Authentication Protocol ........... 2
2.1 Advantages ...................................... 3
2.2 Disadvantages ................................... 3
2.3 Design Requirements ............................. 4
3. Configuration Option Format ........................... 5
4. Packet Format ......................................... 6
4.1 Challenge and Response .......................... 7
4.2 Success and Failure ............................. 9
SECURITY CONSIDERATIONS ...................................... 10
ACKNOWLEDGEMENTS ............................................. 11
REFERENCES ................................................... 12
CONTACTS ..................................................... 12
Simpson [Page i]
RFC 1994 PPP CHAP August 1996
1. Introduction
In order to establish communications over a point-to-point link, each
end of the PPP link must first send LCP packets to configure the data
link during Link Establishment phase. After the link has been
established, PPP provides for an optional Authentication phase before
proceeding to the Network-Layer Protocol phase.
By default, authentication is not mandatory. If authentication of
the link is desired, an implementation MUST specify the
Authentication-Protocol Configuration Option during Link
Establishment phase.
These authentication protocols are intended for use primarily by
hosts and routers that connect to a PPP network server via switched
circuits or dial-up lines, but might be applied to dedicated links as
well. The server can use the identification of the connecting host
or router in the selection of options for network layer negotiations.
This document defines a PPP authentication protocol. The Link
Establishment and Authentication phases, and the Authentication-
Protocol Configuration Option, are defined in The Point-to-Point
Protocol (PPP) [1].
1.1. Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
MUST This word, or the adjective "required", means that the
definition is an absolute requirement of the specification.
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
SHOULD This word, or the adjective "recommended", means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications must be
understood and carefully weighed before choosing a
different course.
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST be
prepared to interoperate with another implementation which
does include the option.
Simpson [Page 1]
RFC 1994 PPP CHAP August 1996
1.2. Terminology
This document frequently uses the following terms:
authenticator
The end of the link requiring the authentication. The
authenticator specifies the authentication protocol to be
used in the Configure-Request during Link Establishment
phase.
peer The other end of the point-to-point link; the end which is
being authenticated by the authenticator.
silently discard
This means the implementation discards the packet without
further processing. The implementation SHOULD provide the
capability of logging the error, including the contents of
the silently discarded packet, and SHOULD record the event
in a statistics counter.
2. Challenge-Handshake Authentication Protocol
The Challenge-Handshake Authentication Protocol (CHAP) is used to
periodically verify the identity of the peer using a 3-way handshake.
This is done upon initial link establishment, and MAY be repeated
anytime after the link has been established.
1. After the Link Establishment phase is complete, the
authenticator sends a "challenge" message to the peer.
2. The peer responds with a value calculated using a "one-way
hash" function.
3. The authenticator checks the response against its own
calculation of the expected hash value. If the values match,
the authentication is acknowledged; otherwise the connection
SHOULD be terminated.
4. At random intervals, the authenticator sends a new challenge to
the peer, and repeats steps 1 to 3.
Simpson [Page 2]
RFC 1994 PPP CHAP August 1996
2.1. Advantages
CHAP provides protection against playback attack by the peer through
the use of an incrementally changing identifier and a variable
challenge value. The use of repeated challenges is intended to limit
the time of exposure to any single attack. The authenticator is in
control of the frequency and timing of the challenges.
This authentication method depends upon a "secret" known only to the
authenticator and that peer. The secret is not sent over the link.
Although the authentication is only one-way, by negotiating CHAP in
both directions the same secret set may easily be used for mutual
authentication.
Since CHAP may be used to authenticate many different systems, name
fields may be used as an index to locate the proper secret in a large
table of secrets. This also makes it possible to support more than
one name/secret pair per system, and to change the secret in use at
any time during the session.
2.2. Disadvantages
CHAP requires that the secret be available in plaintext form.
Irreversably encrypted password databases commonly available cannot
be used.
It is not as useful for large installations, since every possible
secret is maintained at both ends of the link.
Implementation Note: To avoid sending the secret over other links
in the network, it is recommended that the challenge and response
values be examined at a central server, rather than each network
access server. Otherwise, the secret SHOULD be sent to such
servers in a reversably encrypted form. Either case requires a
trusted relationship, which is outside the scope of this
specification.
Simpson [Page 3]
RFC 1994 PPP CHAP August 1996
2.3. Design Requirements
The CHAP algorithm requires that the length of the secret MUST be at
least 1 octet. The secret SHOULD be at least as large and
unguessable as a well-chosen password. It is preferred that the
secret be at least the length of the hash value for the hashing
algorithm chosen (16 octets for MD5). This is to ensure a
sufficiently large range for the secret to provide protection against
exhaustive search attacks.
The one-way hash algorithm is chosen such that it is computationally
infeasible to determine the secret from the known challenge and
response values.
Each challenge value SHOULD be unique, since repetition of a
challenge value in conjunction with the same secret would permit an
attacker to reply with a previously intercepted response. Since it
is expected that the same secret MAY be used to authenticate with
servers in disparate geographic regions, the challenge SHOULD exhibit
global and temporal uniqueness.
Each challenge value SHOULD also be unpredictable, least an attacker
trick a peer into responding to a predicted future challenge, and
then use the response to masquerade as that peer to an authenticator.
Although protocols such as CHAP are incapable of protecting against
realtime active wiretapping attacks, generation of unique
unpredictable challenges can protect against a wide range of active
attacks.
A discussion of sources of uniqueness and probability of divergence
is included in the Magic-Number Configuration Option [1].
Simpson [Page 4]
RFC 1994 PPP CHAP August 1996
3. Configuration Option Format
A summary of the Authentication-Protocol Configuration Option format
to negotiate the Challenge-Handshake Authentication Protocol is shown
below. The fields are transmitted from left to right.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm |
+-+-+-+-+-+-+-+-+
Type
3
Length
5
Authentication-Protocol
c223 (hex) for Challenge-Handshake Authentication Protocol.
Algorithm
The Algorithm field is one octet and indicates the authentication
method to be used. Up-to-date values are specified in the most
recent "Assigned Numbers" [2]. One value is required to be
implemented:
5 CHAP with MD5 [3]
Simpson [Page 5]
RFC 1994 PPP CHAP August 1996
4. Packet Format
Exactly one Challenge-Handshake Authentication Protocol packet is
encapsulated in the Information field of a PPP Data Link Layer frame
where the protocol field indicates type hex c223 (Challenge-Handshake
Authentication Protocol). A summary of the CHAP packet format is
shown below. The fields are transmitted from left to right.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Code
The Code field is one octet and identifies the type of CHAP
packet. CHAP Codes are assigned as follows:
1 Challenge
2 Response
3 Success
4 Failure
Identifier
The Identifier field is one octet and aids in matching challenges,
responses and replies.
Length
The Length field is two octets and indicates the length of the
CHAP packet including the Code, Identifier, Length and Data
fields. Octets outside the range of the Length field should be
treated as Data Link Layer padding and should be ignored on
reception.
Data
The Data field is zero or more octets. The format of the Data
field is determined by the Code field.
Simpson [Page 6]
RFC 1994 PPP CHAP August 1996
4.1. Challenge and Response
Description
The Challenge packet is used to begin the Challenge-Handshake
Authentication Protocol. The authenticator MUST transmit a CHAP
packet with the Code field set to 1 (Challenge). Additional
Challenge packets MUST be sent until a valid Response packet is
received, or an optional retry counter expires.
A Challenge packet MAY also be transmitted at any time during the
Network-Layer Protocol phase to ensure that the connection has not
been altered.
The peer SHOULD expect Challenge packets during the Authentication
phase and the Network-Layer Protocol phase. Whenever a Challenge
packet is received, the peer MUST transmit a CHAP packet with the
Code field set to 2 (Response).
Whenever a Response packet is received, the authenticator compares
the Response Value with its own calculation of the expected value.
Based on this comparison, the authenticator MUST send a Success or
Failure packet (described below).
Implementation Notes: Because the Success might be lost, the
authenticator MUST allow repeated Response packets during the
Network-Layer Protocol phase after completing the
Authentication phase. To prevent discovery of alternative
Names and Secrets, any Response packets received having the
current Challenge Identifier MUST return the same reply Code
previously returned for that specific Challenge (the message
portion MAY be different). Any Response packets received
during any other phase MUST be silently discarded.
When the Failure is lost, and the authenticator terminates the
link, the LCP Terminate-Request and Terminate-Ack provide an
alternative indication that authentication failed.
Simpson [Page 7]
RFC 1994 PPP CHAP August 1996
A summary of the Challenge and Response packet format is shown below.
The fields are transmitted from left to right.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value-Size | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
1 for Challenge;
2 for Response.
Identifier
The Identifier field is one octet. The Identifier field MUST be
changed each time a Challenge is sent.
The Response Identifier MUST be copied from the Identifier field
of the Challenge which caused the Response.
Value-Size
This field is one octet and indicates the length of the Value
field.
Value
The Value field is one or more octets. The most significant octet
is transmitted first.
The Challenge Value is a variable stream of octets. The
importance of the uniqueness of the Challenge Value and its
relationship to the secret is described above. The Challenge
Value MUST be changed each time a Challenge is sent. The length
of the Challenge Value depends upon the method used to generate
the octets, and is independent of the hash algorithm used.
The Response Value is the one-way hash calculated over a stream of
octets consisting of the Identifier, followed by (concatenated
with) the "secret", followed by (concatenated with) the Challenge
Value. The length of the Response Value depends upon the hash
algorithm used (16 octets for MD5).
Simpson [Page 8]
RFC 1994 PPP CHAP August 1996
Name
The Name field is one or more octets representing the
identification of the system transmitting the packet. There are
no limitations on the content of this field. For example, it MAY
contain ASCII character strings or globally unique identifiers in
ASN.1 syntax. The Name should not be NUL or CR/LF terminated.
The size is determined from the Length field.
4.2. Success and Failure
Description
If the Value received in a Response is equal to the expected
value, then the implementation MUST transmit a CHAP packet with
the Code field set to 3 (Success).
If the Value received in a Response is not equal to the expected
value, then the implementation MUST transmit a CHAP packet with
the Code field set to 4 (Failure), and SHOULD take action to
terminate the link.
A summary of the Success and Failure packet format is shown below.
The fields are transmitted from left to right.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
3 for Success;
4 for Failure.
Identifier
The Identifier field is one octet and aids in matching requests
and replies. The Identifier field MUST be copied from the
Identifier field of the Response which caused this reply.
Simpson [Page 9]
RFC 1994 PPP CHAP August 1996
Message
The Message field is zero or more octets, and its contents are
implementation dependent. It is intended to be human readable,
and MUST NOT affect operation of the protocol. It is recommended
that the message contain displayable ASCII characters 32 through
126 decimal. Mechanisms for extension to other character sets are
the topic of future research. The size is determined from the
Length field.
Security Considerations
Security issues are the primary topic of this RFC.
The interaction of the authentication protocols within PPP are highly
implementation dependent. This is indicated by the use of SHOULD
throughout the document.
For example, upon failure of authentication, some implementations do
not terminate the link. Instead, the implementation limits the kind
of traffic in the Network-Layer Protocols to a filtered subset, which
in turn allows the user opportunity to update secrets or send mail to
the network administrator indicating a problem.
There is no provision for re-tries of failed authentication.
However, the LCP state machine can renegotiate the authentication
protocol at any time, thus allowing a new attempt. It is recommended
that any counters used for authentication failure not be reset until
after successful authentication, or subsequent termination of the
failed link.
There is no requirement that authentication be full duplex or that
the same protocol be used in both directions. It is perfectly
acceptable for different protocols to be used in each direction.
This will, of course, depend on the specific protocols negotiated.
The secret SHOULD NOT be the same in both directions. This allows an
attacker to replay the peer's challenge, accept the computed
response, and use that response to authenticate.
In practice, within or associated with each PPP server, there is a
database which associates "user" names with authentication
information ("secrets"). It is not anticipated that a particular
named user would be authenticated by multiple methods. This would
make the user vulnerable to attacks which negotiate the least secure
method from among a set (such as PAP rather than CHAP). If the same
Simpson [Page 10]
RFC 1994 PPP CHAP August 1996
secret was used, PAP would reveal the secret to be used later with
CHAP.
Instead, for each user name there should be an indication of exactly
one method used to authenticate that user name. If a user needs to
make use of different authentication methods under different
circumstances, then distinct user names SHOULD be employed, each of
which identifies exactly one authentication method.
Passwords and other secrets should be stored at the respective ends
such that access to them is as limited as possible. Ideally, the
secrets should only be accessible to the process requiring access in
order to perform the authentication.
The secrets should be distributed with a mechanism that limits the
number of entities that handle (and thus gain knowledge of) the
secret. Ideally, no unauthorized person should ever gain knowledge
of the secrets. Such a mechanism is outside the scope of this
specification.
Acknowledgements
David Kaufman, Frank Heinrich, and Karl Auerbach used a challenge
handshake at SDC when designing one of the protocols for a "secure"
network in the mid-1970s. Tom Bearson built a prototype Sytek
product ("Poloneous"?) on the challenge-response notion in the 1982-
83 timeframe. Another variant is documented in the various IBM SNA
manuals. Yet another variant was implemented by Karl Auerbach in the
Telebit NetBlazer circa 1991.
Kim Toms and Barney Wolff provided useful critiques of earlier
versions of this document.
Special thanks to Dave Balenson, Steve Crocker, James Galvin, and
Steve Kent, for their extensive explanations and suggestions. Now,
if only we could get them to agree with each other.
Simpson [Page 11]
RFC 1994 PPP CHAP August 1996
References
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, DayDreamer, July 1994.
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, USC/Information Sciences Institute, October 1994.
[3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
MIT Laboratory for Computer Science and RSA Data Security,
Inc., RFC 1321, April 1992.
Contacts
Comments should be submitted to the ietf-ppp@merit.edu mailing list.
This document was reviewed by the Point-to-Point Protocol Working
Group of the Internet Engineering Task Force (IETF). The working
group can be contacted via the current chair:
Karl Fox
Ascend Communications
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
karl@MorningStar.com
karl@Ascend.com
Questions about this memo can also be directed to:
William Allen Simpson
DayDreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)
Simpson [Page 12]

4259
doc/standards/rfc2865.txt
View File

File diff suppressed because it is too large Load Diff

2579
doc/standards/rfc3579.txt
View File

File diff suppressed because it is too large Load Diff

3755
doc/standards/rfc3748.txt
View File

File diff suppressed because it is too large Load Diff

5155
doc/standards/rfc4186.txt
View File

File diff suppressed because it is too large Load Diff

4427
doc/standards/rfc4187.txt
View File

File diff suppressed because it is too large Load Diff

5659
doc/standards/rfc4301.txt
View File

File diff suppressed because it is too large Load Diff

5547
doc/standards/rfc4306.txt
View File

File diff suppressed because it is too large Load Diff

339
doc/standards/rfc4307.txt
View File

@ -1,339 +0,0 @@
Network Working Group J. Schiller
Request for Comments: 4307 Massachusetts Institute of Technology
Category: Standards Track December 2005
Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
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.
1. Introduction
The Internet Key Exchange protocol provides for the negotiation of
cryptographic algorithms between both endpoints of a cryptographic
association. Different implementations of IPsec and IKE may provide
different algorithms. However, the IETF desires that all
implementations should have some way to interoperate. In particular,
this requires that IKE define a set of mandatory-to-implement
algorithms because IKE itself uses such algorithms as part of its own
negotiations. This requires that some set of algorithms be specified
as "mandatory-to-implement" for IKE.
Schiller Standards Track [Page 1]
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
The nature of cryptography is that new algorithms surface
continuously and existing algorithms are continuously attacked. An
algorithm believed to be strong today may be demonstrated to be weak
tomorrow. Given this, the choice of mandatory-to-implement algorithm
should be conservative so as to minimize the likelihood of it being
compromised quickly. Thought should also be given to performance
considerations as many uses of IPsec will be in environments where
performance is a concern.
Finally, we need to recognize that the mandatory-to-implement
algorithm(s) may need to change over time to adapt to the changing
world. For this reason, the selection of mandatory-to-implement
algorithms was removed from the main IKEv2 specification and placed
in this document. As the choice of algorithm changes, only this
document should need to be updated.
Ideally, the mandatory-to-implement algorithm of tomorrow should
already be available in most implementations of IPsec by the time it
is made mandatory. To facilitate this, we will attempt to identify
those algorithms (that are known today) in this document. There is
no guarantee that the algorithms we believe today may be mandatory in
the future will in fact become so. All algorithms known today are
subject to cryptographic attack and may be broken in the future.
2. Requirements Terminology
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and
"MAY" that appear in this document are to be interpreted as described
in [RFC2119].
We define some additional terms here:
SHOULD+ This term means the same as SHOULD. However, it is likely
that an algorithm marked as SHOULD+ will be promoted at
some future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, an algorithm
marked as SHOULD- may be deprecated to a MAY in a future
version of this document.
MUST- This term means the same as MUST. However, we expect at
some point that this algorithm will no longer be a MUST in
a future document. Although its status will be determined
at a later time, it is reasonable to expect that if a
future revision of a document alters the status of a MUST-
algorithm, it will remain at least a SHOULD or a SHOULD-.
Schiller Standards Track [Page 2]
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
3. Algorithm Selection
3.1. IKEv2 Algorithm Selection
3.1.1. Encrypted Payload Algorithms
The IKEv2 Encrypted Payload requires both a confidentiality algorithm
and an integrity algorithm. For confidentiality, implementations
MUST- implement 3DES-CBC and SHOULD+ implement AES-128-CBC. For
integrity, HMAC-SHA1 MUST be implemented.
3.1.2. Diffie-Hellman Groups
There are several Modular Exponential (MODP) groups that are defined
for use in IKEv2. They are defined in both the [IKEv2] base document
and in the MODP extensions document. They are identified by group
number. Any groups not listed here are considered as "MAY be
implemented".
Group Number Bit Length Status Defined
2 1024 MODP Group MUST- [RFC2409]
14 2048 MODP Group SHOULD+ [RFC3526]
3.1.3. IKEv2 Transform Type 1 Algorithms
IKEv2 defines several possible algorithms for Transfer Type 1
(encryption). These are defined below with their implementation
status.
Name Number Defined In Status
RESERVED 0
ENCR_3DES 3 [RFC2451] MUST-
ENCR_NULL 11 [RFC2410] MAY
ENCR_AES_CBC 12 [AES-CBC] SHOULD+
ENCR_AES_CTR 13 [AES-CTR] SHOULD
3.1.4. IKEv2 Transform Type 2 Algorithms
Transfer Type 2 Algorithms are pseudo-random functions used to
generate random values when needed.
Name Number Defined In Status
RESERVED 0
PRF_HMAC_MD5 1 [RFC2104] MAY
PRF_HMAC_SHA1 2 [RFC2104] MUST
PRF_AES128_CBC 4 [AESPRF] SHOULD+
Schiller Standards Track [Page 3]
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
3.1.5. IKEv2 Transform Type 3 Algorithms
Transfer Type 3 Algorithms are Integrity algorithms used to protect
data against tampering.
Name Number Defined In Status
NONE 0
AUTH_HMAC_MD5_96 1 [RFC2403] MAY
AUTH_HMAC_SHA1_96 2 [RFC2404] MUST
AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+
4. Security Considerations
The security of cryptographic-based systems depends on both the
strength of the cryptographic algorithms chosen and the strength of
the keys used with those algorithms. The security also depends on
the engineering of the protocol used by the system to ensure that
there are no non-cryptographic ways to bypass the security of the
overall system.
This document concerns itself with the selection of cryptographic
algorithms for the use of IKEv2, specifically with the selection of
"mandatory-to-implement" algorithms. The algorithms identified in
this document as "MUST implement" or "SHOULD implement" are not known
to be broken at the current time, and cryptographic research so far
leads us to believe that they will likely remain secure into the
foreseeable future. However, this isn't necessarily forever. We
would therefore expect that new revisions of this document will be
issued from time to time that reflect the current best practice in
this area.
5. Normative References
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, December 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential
(MODP) Diffie-Hellman groups for Internet Key Exchange
(IKE)", RFC 3526, May 2003.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
Schiller Standards Track [Page 4]
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm
and Its Use With IPsec", RFC 2410, November 1998.
[AES-CBC] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
Cipher Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[AES-CTR] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, January 2004.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[AESPRF] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
Internet Key Exchange Protocol (IKE)", RFC 3664, January
2004.
[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.
[AES-MAC] Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96
Algorithm and Its Use With IPsec", RFC 3566, September
2003.
Author's Address
Jeffrey I. Schiller
Massachusetts Institute of Technology
Room W92-190
77 Massachusetts Avenue
Cambridge, MA 02139-4307
USA
Phone: +1 (617) 253-0161
EMail: jis@mit.edu
Schiller Standards Track [Page 5]
RFC 4307 IKEv2 Cryptographic Algorithms December 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schiller Standards Track [Page 6]

283
doc/standards/rfc4478.txt
View File

@ -1,283 +0,0 @@
Network Working Group Y. Nir
Request for Comments: 4478 Check Point
Category: Experimental April 2006
Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document extends the Internet Key Exchange (IKEv2) Protocol
document [IKEv2]. With some IPsec peers, particularly in the remote
access scenario, it is desirable to repeat the mutual authentication
periodically. The purpose of this is to limit the time that security
associations (SAs) can be used by a third party who has gained
control of the IPsec peer. This document describes a mechanism to
perform this function.
1. Introduction
In several cases, such as the remote access scenario, policy dictates
that the mutual authentication needs to be repeated periodically.
Repeated authentication can usually be achieved by simply repeating
the Initial exchange by whichever side has a stricter policy.
However, in the remote access scenario it is usually up to a human
user to supply the authentication credentials, and often Extensible
Authentication Protocol (EAP) is used for authentication, which makes
it unreasonable or impossible for the remote access gateway to
initiate the IKEv2 exchange.
This document describes a new notification that the original
Responder can send to the original Initiator with the number of
seconds before the authentication needs to be repeated. The
Initiator SHOULD repeat the Initial exchange before that time is
expired. If the Initiator fails to do so, the Responder may close
all Security Associations.
Nir Experimental [Page 1]
RFC 4478 Repeated Authentication in IKEv2 April 2006
Repeated authentication is not the same as IKE SA rekeying, and need
not be tied to it. The key words "MUST", "MUST NOT", "SHOULD",
"SHOULD NOT", and "MAY" in this document are to be interpreted as
described in [RFC2119].
2. Authentication Lifetime
The Responder in an IKEv2 negotiation MAY be configured to limit the
time that an IKE SA and the associated IPsec SAs may be used before
the peer is required to repeat the authentication, through a new
Initial Exchange.
The Responder MUST send this information to the Initiator in an
AUTH_LIFETIME notification either in the last message of an IKE_AUTH
exchange, or in an INFORMATIONAL request, which may be sent at any
time.
When sent as part of the IKE SA setup, the AUTH_LIFETIME notification
is used as follows:
Initiator Responder
------------------------------- -----------------------------
HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERT,] [CERTREQ,]
[IDr,] AUTH, SAi2, TSi, TSr} -->
<-- HDR, SK {IDr, [CERT,] AUTH,
SAr2, TSi, TSr,
N(AUTH_LIFETIME)}
The separate Informational exchange is formed as follows:
<-- HDR, SK {N(AUTH_LIFETIME)}
HDR SK {} -->
The AUTH_LIFETIME notification is described in Section 3.
The original Responder that sends the AUTH_LIFETIME notification
SHOULD send a DELETE notification soon after the end of the lifetime
period, unless the IKE SA is deleted before the lifetime period
elapses. If the IKE SA is rekeyed, then the time limit applies to
the new SA.
An Initiator that received an AUTH_LIFETIME notification SHOULD
repeat the Initial exchange within the time indicated in the
notification. The time is measured from the time that the original
Initiator receives the notification.
Nir Experimental [Page 2]
RFC 4478 Repeated Authentication in IKEv2 April 2006
A special case is where the notification is sent in an Informational
exchange, and the lifetime is zero. In that case, the original
responder SHOULD allow a reasonable time for the repeated
authentication to occur.
The AUTH_LIFETIME notification MUST be protected and MAY be sent by
the original Responder at any time. If the policy changes, the
original Responder MAY send it again in a new Informational.
The new Initial exchange is not altered. The initiator SHOULD delete
the old IKE SA within a reasonable time of the new Auth exchange.
3. AUTH_LIFETIME Notification
The AUTH_LIFETIME message is a notification payload formatted as
follows:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Protocol ID ! SPI Size ! Notify Message Type !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Lifetime !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o Payload Length is 12.
o Protocol ID (1 octet) MUST be 0.
o SPI size is 0 (SPI is in message header).
o Notify Message type is 16403 by IANA.
o Lifetime is the amount of time (in seconds) left before the
peer should repeat the Initial exchange. A zero value
signifies that the Initial exchange should begin immediately.
It is usually not reasonable to set this value to less than 300
(5 minutes) since that is too cumbersome for a user.
It is also usually not reasonable to set this value to more
than 86400 (1 day) as that would negate the security benefit of
repeating the authentication.
4. Interoperability with Non-Supporting IKEv2 Implementations
IKEv2 implementations that do not support the AUTH_LIFETIME
notification will ignore it and will not repeat the authentication.
In that case the original Responder will send a Delete notification
for the IKE SA in an Informational exchange. Such implementations
may be configured manually to repeat the authentication periodically.
Nir Experimental [Page 3]
RFC 4478 Repeated Authentication in IKEv2 April 2006
Non-supporting Responders are not a problem because they will simply
not send these notifications. In that case, there is no requirement
that the original Initiator re-authenticate.
5. Security Considerations
The AUTH_LIFETIME notification sent by the Responder does not
override any security policy on the Initiator. In particular, the
Initiator may have a different policy regarding re-authentication,
requiring more frequent re-authentication. Such an Initiator can
repeat the authentication earlier then is required by the
notification.
An Initiator MAY set reasonable limits on the amount of time in the
AUTH_LIFETIME notification. For example, an authentication lifetime
of less than 300 seconds from SA initiation may be considered
unreasonable.
6. IANA Considerations
The IANA has assigned a notification payload type for the
AUTH_LIFETIME notifications from the IKEv2 Notify Message Types
registry.
7. Normative References
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Author's Address
Yoav Nir
Check Point Software Technologies
EMail: ynir@checkpoint.com
Nir Experimental [Page 4]
RFC 4478 Repeated Authentication in IKEv2 April 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Nir Experimental [Page 5]

787
doc/standards/rfc4543.txt
View File

@ -1,787 +0,0 @@
Network Working Group D. McGrew
Request for Comments: 4543 Cisco Systems, Inc.
Category: Standards Track J. Viega
McAfee, Inc.
May 2006
The Use of Galois Message Authentication Code (GMAC) in
IPsec ESP and AH
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo describes the use of the Advanced Encryption Standard (AES)
Galois Message Authentication Code (GMAC) as a mechanism to provide
data origin authentication, but not confidentiality, within the IPsec
Encapsulating Security Payload (ESP) and Authentication Header (AH).
GMAC is based on the Galois/Counter Mode (GCM) of operation, and can
be efficiently implemented in hardware for speeds of 10 gigabits per
second and above, and is also well-suited to software
implementations.
McGrew & Viega Standards Track [Page 1]
RFC 4543 GMAC in IPsec ESP and AH May 2006
Table of Contents
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. AES-GMAC ........................................................3
3. The Use of AES-GMAC in ESP ......................................3
3.1. Initialization Vector ......................................4
3.2. Nonce Format ...............................................4
3.3. AAD Construction ...........................................5
3.4. Integrity Check Value (ICV) ................................6
3.5. Differences with AES-GCM-ESP ...............................6
3.6. Packet Expansion ...........................................7
4. The Use of AES-GMAC in AH .......................................7
5. IKE Conventions .................................................8
5.1. Phase 1 Identifier .........................................8
5.2. Phase 2 Identifier .........................................8
5.3. Key Length Attribute .......................................9
5.4. Keying Material and Salt Values ............................9
6. Test Vectors ....................................................9
7. Security Considerations ........................................10
8. Design Rationale ...............................................11
9. IANA Considerations ............................................11
10. Acknowledgements ..............................................11
11. References ....................................................12
11.1. Normative References .....................................12
11.2. Informative References ...................................12
1. Introduction
This document describes the use of AES-GMAC mode (AES-GMAC) as a
mechanism for data origin authentication in ESP [RFC4303] and AH
[RFC4302]. We refer to these methods as ENCR_NULL_AUTH_AES_GMAC and
AUTH_AES_GMAC, respectively. ENCR_NULL_AUTH_AES_GMAC is a companion
to the AES Galois/Counter Mode ESP [RFC4106], which provides
authentication as well as confidentiality. ENCR_NULL_AUTH_AES_GMAC
is intended for cases in which confidentiality is not desired. Like
GCM, GMAC is efficient and secure, and is amenable to high-speed
implementations in hardware. ENCR_NULL_AUTH_AES_GMAC and
AUTH_AES_GMAC are designed so that the incremental cost of
implementation, given an implementation is AES-GCM-ESP, is small.
This document does not cover implementation details of GCM or GMAC.
Those details can be found in [GCM], along with test vectors.
McGrew & Viega Standards Track [Page 2]
RFC 4543 GMAC in IPsec ESP and AH May 2006
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. AES-GMAC
GMAC is a block cipher mode of operation providing data origin
authentication. It is defined in terms of the GCM authenticated
encryption operation as follows. The GCM authenticated encryption
operation has four inputs: a secret key, an initialization vector
(IV), a plaintext, and an input for additional authenticated data
(AAD). It has two outputs, a ciphertext whose length is identical to
the plaintext and an authentication tag. GMAC is the special case of
GCM in which the plaintext has a length of zero. The (zero-length)
ciphertext output is ignored, of course, so that the only output of
the function is the Authentication Tag. In the following, we
describe how the GMAC IV and AAD are formed from the ESP and AH
fields, and how the ESP and AH packets are formed from the
Authentication Tag.
Below we refer to the AES-GMAC IV input as a nonce, in order to
distinguish it from the IV fields in the packets. The same nonce and
key combination MUST NOT be used more than once, since reusing a
nonce/key combination destroys the security guarantees of AES-GMAC.
Because of this restriction, it can be difficult to use this mode
securely when using statically configured keys. For the sake of good
security, implementations MUST use an automated key management
system, such as the Internet Key Exchange (IKE) (either version two
[RFC4306] or version one [RFC2409]), to ensure that this requirement
is met.
3. The Use of AES-GMAC in ESP
The AES-GMAC algorithm for ESP is defined as an ESP "combined mode"
algorithm (see Section 3.2.3 of [RFC4303]), rather than an ESP
integrity algorithm. It is called ENCR_NULL_AUTH_AES_GMAC to
highlight the fact that it performs no encryption and provides no
confidentiality.
Rationale: ESP makes no provision for integrity transforms to
place an initialization vector within the Payload field; only
encryption transforms are expected to use IVs. Defining GMAC as
an encryption transform avoids this issue, and allows GMAC to
benefit from the same pipelining as does GCM.
McGrew & Viega Standards Track [Page 3]
RFC 4543 GMAC in IPsec ESP and AH May 2006
Like all ESP combined modes, it is registered in IKEv2 as an
encryption transform, or "Type 1" transform. It MUST NOT be used in
conjunction with any other ESP encryption transform (within a
particular ESP encapsulation). If confidentiality is desired, then
GCM ESP [RFC4106] SHOULD be used instead.
3.1. Initialization Vector
With ENCR_NULL_AUTH_AES_GMAC, an explicit Initialization Vector (IV)
is included in the ESP Payload, at the outset of that field. The IV
MUST be eight octets long. For a given key, the IV MUST NOT repeat.
The most natural way to meet this requirement is to set the IV using
a counter, but implementations are free to set the IV field in any
way that guarantees uniqueness, such as a linear feedback shift
register (LFSR). Note that the sender can use any IV generation
method that meets the uniqueness requirement without coordinating
with the receiver.
3.2. Nonce Format
The nonce passed to the AES-GMAC authentication algorithm has the
following layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Salt |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Nonce Format
The components of the nonce are as follows:
Salt
The salt field is a four-octet value that is assigned at the
beginning of the security association, and then remains constant
for the life of the security association. The salt SHOULD be
unpredictable (i.e., chosen at random) before it is selected, but
need not be secret. We describe how to set the salt for a
Security Association established via the Internet Key Exchange in
Section 5.4.
Initialization Vector
The IV field is described in Section 3.1.
McGrew & Viega Standards Track [Page 4]
RFC 4543 GMAC in IPsec ESP and AH May 2006
3.3. AAD Construction
Data integrity and data origin authentication are provided for the
SPI, (Extended) Sequence Number, Authenticated Payload, Padding, Pad
Length, and Next Header fields. This is done by including those
fields in the AES-GMAC Additional Authenticated Data (AAD) field.
Two formats of the AAD are defined: one for 32-bit sequence numbers,
and one for 64-bit extended sequence numbers. The format with 32-bit
sequence numbers is shown in Figure 2, and the format with 64-bit
extended sequence numbers is shown in Figure 3.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authenticated Payload (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (0-255 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: AAD Format with 32-bit Sequence Number
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit Extended Sequence Number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Authenticated Payload (variable) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (0-255 bytes) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Pad Length | Next Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: AAD Format with 64-bit Extended Sequence Number
McGrew & Viega Standards Track [Page 5]
RFC 4543 GMAC in IPsec ESP and AH May 2006
The use of 32-bit sequence numbers vs. 64-bit extended sequence
numbers is determined by the security association (SA) management
protocol that is used to create the SA. For IKEv2 [RFC4306] this is
negotiated via Transform Type 5, and the default for ESP is to use
64-bit extended sequence numbers in the absence of negotiation (e.g.,
see Section 2.2.1 of [RFC4303]).
3.4. Integrity Check Value (ICV)
The ICV consists solely of the AES-GMAC Authentication Tag. The
Authentication Tag MUST NOT be truncated, so the length of the ICV is
16 octets.
3.5. Differences with AES-GCM-ESP
In this section, we highlight the differences between this
specification and AES-GCM-ESP [RFC4106]. The essential difference is
that in this document, the AAD consists of the SPI, Sequence Number,
and ESP Payload, and the AES-GCM plaintext is zero-length, while in
AES-GCM-ESP, the AAD consists only of the SPI and Sequence Number,
and the AES-GCM plaintext consists of the ESP Payload. These
differences are illustrated in Figure 4. This figure shows the case
in which the Extended Sequence Number option is not used. When that
option is exercised, the Sequence Number field in the figure would be
replaced with the Extended Sequence Number.
Importantly, ENCR_NULL_AUTH_AES_GMAC is *not* equivalent to AES-GCM-
ESP with encryption "turned off". However, the ICV computations
performed in both cases are similar because of the structure of the
GHASH function [GCM].
McGrew & Viega Standards Track [Page 6]
RFC 4543 GMAC in IPsec ESP and AH May 2006
+-> +-----------------------+ <-+
AES-GCM-ESP | | SPI | |
AAD -------+ +-----------------------+ |
| | Sequence Number | |
+-> +-----------------------+ |
| Authentication | |
| IV | |
+->+-> +-----------------------+ +
AES-GCM-ESP | | | |
Plaintext -+ ~ ESP Payload ~ |
| | | |
| +-----------+-----+-----+ |
| | Padding | PL | NH | |
+----> +-----------+-----+-----+ <-+
|
ENCR_NULL_AUTH_AES_GMAC AAD --+
Figure 4: Differences between ENCR_NULL_AUTH_AES_GMAC and AES-GCM-ESP
3.6. Packet Expansion
The IV adds an additional eight octets to the packet and the ICV adds
an additional 16 octets. These are the only sources of packet
expansion, other than the 10-13 bytes taken up by the ESP SPI,
Sequence Number, Padding, Pad Length, and Next Header fields (if the
minimal amount of padding is used).
4. The Use of AES-GMAC in AH
In AUTH_AES_GMAC, the AH Authentication Data field consists of the IV
and the Authentication Tag, as shown in Figure 5. Unlike the usual
AH case, the Authentication Data field contains both an input to the
authentication algorithm (the IV) and the output of the
authentication algorithm (the tag). No padding is required in the
Authentication Data field, because its length is a multiple of 64
bits.
McGrew & Viega Standards Track [Page 7]
RFC 4543 GMAC in IPsec ESP and AH May 2006
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector (IV) |
| (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Integrity Check Value (ICV) (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The AUTH_AES_GMAC Authentication Data Format
The IV is as described in Section 3.1. The Integrity Check Value
(ICV) is as described in Section 3.4.
The GMAC Nonce input is formed as described in Section 3.2. The GMAC
AAD input consists of the authenticated data as defined in Section
3.1 of [RFC4302]. These values are provided as to that algorithm,
along with the secret key, and the resulting authentication tag given
as output is used to form the ICV.
5. IKE Conventions
This section describes the conventions used to generate keying
material and salt values for use with ENCR_NULL_AUTH_AES_GMAC and
AUTH_AES_GMAC using the Internet Key Exchange (IKE) versions one
[RFC2409] and two [RFC4306].
5.1. Phase 1 Identifier
This document does not specify the conventions for using AES-GMAC for
IKE Phase 1 negotiations. For AES-GMAC to be used in this manner, a
separate specification would be needed, and an Encryption Algorithm
Identifier would need to be assigned. Implementations SHOULD use an
IKE Phase 1 cipher that is at least as strong as AES-GMAC. The use
of AES-CBC [RFC3602] with the same AES key size as used by
ENCR_NULL_AUTH_AES_GMAC or AUTH_AES_GMAC is RECOMMENDED.
5.2. Phase 2 Identifier
For IKE Phase 2 negotiations, IANA has assigned identifiers as
described in Section 9.
McGrew & Viega Standards Track [Page 8]
RFC 4543 GMAC in IPsec ESP and AH May 2006
5.3. Key Length Attribute
AES-GMAC can be used with any of the three AES key lengths. The way
that the key length is indicated is different for AH and ESP.
For AH, each key length has its own separate integrity transform
identifier and algorithm name (Section 9). The IKE Key Length
attribute MUST NOT be used with these identifiers. This transform
MUST NOT be used with ESP.
For ESP, there is a single encryption transform identifier (which
represents the combined transform) (Section 9). The IKE Key Length
attribute MUST be used with each use of this identifier to indicate
the key length. The Key Length attribute MUST have a value of 128,
192, or 256.
5.4. Keying Material and Salt Values
IKE makes use of a pseudo-random function (PRF) to derive keying
material. The PRF is used iteratively to derive keying material of
arbitrary size, called KEYMAT. Keying material is extracted from the
output string without regard to boundaries.
The size of the KEYMAT for the ENCR_NULL_AUTH_AES_GMAC and
AUTH_AES_GMAC MUST be four octets longer than is needed for the
associated AES key. The keying material is used as follows:
ENCR_NULL_AUTH_AES_GMAC with a 128-bit key and AUTH_AES_128_GMAC
The KEYMAT requested for each AES-GMAC key is 20 octets. The
first 16 octets are the 128-bit AES key, and the remaining four
octets are used as the salt value in the nonce.
ENCR_NULL_AUTH_AES_GMAC with a 192-bit key and AUTH_AES_192_GMAC
The KEYMAT requested for each AES-GMAC key is 28 octets. The
first 24 octets are the 192-bit AES key, and the remaining four
octets are used as the salt value in the nonce.
ENCR_NULL_AUTH_AES_GMAC with a 256-bit key and AUTH_AES_256_GMAC
The KEYMAT requested for each AES-GMAC key is 36 octets. The
first 32 octets are the 256-bit AES key, and the remaining four
octets are used as the salt value in the nonce.
6. Test Vectors
Appendix B of [GCM] provides test vectors that will assist
implementers with AES-GMAC.
McGrew & Viega Standards Track [Page 9]
RFC 4543 GMAC in IPsec ESP and AH May 2006
7. Security Considerations
Since the authentication coverage is different between AES-GCM-ESP
and this specification (see Figure 4), it is worth pointing out that
both specifications are secure. In ENCR_NULL_AUTH_AES_GMAC, the IV
is not included in either the plaintext or the additional
authenticated data. This does not adversely affect security, because
the IV field only provides an input to the GMAC IV, which is not
required to be authenticated (see [GCM]). In AUTH_AES_GMAC, the IV
is included in the additional authenticated data. This fact has no
adverse effect on security; it follows from the property that GMAC is
secure even against attacks in which the adversary can manipulate
both the IV and the message. Even an adversary with these powerful
capabilities cannot forge an authentication tag for any message
(other than one that was submitted to the chosen-message oracle).
Since such an adversary could easily choose messages that contain the
IVs with which they correspond, there are no security problems with
the inclusion of the IV in the AAD.
GMAC is provably secure against adversaries that can adaptively
choose plaintexts, ICVs and the AAD field, under standard
cryptographic assumptions (roughly, that the output of the underlying
cipher under a randomly chosen key is indistinguishable from a
randomly selected output). Essentially, this means that, if used
within its intended parameters, a break of GMAC implies a break of
the underlying block cipher. The proof of security is available in
[GCMP].
The most important security consideration is that the IV never
repeats for a given key. In part, this is handled by disallowing the
use of AES-GMAC when using statically configured keys, as discussed
in Section 2.
When IKE is used to establish fresh keys between two peer entities,
separate keys are established for the two traffic flows. If a
different mechanism is used to establish fresh keys, one that
establishes only a single key to protect packets, then there is a
high probability that the peers will select the same IV values for
some packets. Thus, to avoid counter block collisions, ESP or AH
implementations that permit use of the same key for protecting
packets with the same peer MUST ensure that the two peers assign
different salt values to the security association (SA).
The other consideration is that, as with any block cipher mode of
operation, the security of all data protected under a given security
association decreases slightly with each message.
McGrew & Viega Standards Track [Page 10]
RFC 4543 GMAC in IPsec ESP and AH May 2006
To protect against this problem, implementations MUST generate a
fresh key before processing 2^64 blocks of data with a given key.
Note that it is impossible to reach this limit when using 32-bit
Sequence Numbers.
Note that, for each message, GMAC calls the block cipher only once.
8. Design Rationale
This specification was designed to be as similar to AES-GCM-ESP
[RFC4106] as possible. We re-use the design and implementation
experience from that specification. We include all three AES key
sizes since AES-GCM-ESP supports all of those sizes, and the larger
key sizes provide future users with more high-security options.
9. IANA Considerations
IANA has assigned the following IKEv2 parameters. For the use of AES
GMAC in AH, the following integrity (type 3) transform identifiers
have been assigned:
"9" for AUTH_AES_128_GMAC
"10" for AUTH_AES_192_GMAC
"11" for AUTH_AES_256_GMAC
For the use of AES-GMAC in ESP, the following encryption (type 1)
transform identifier has been assigned:
"21" for ENCR_NULL_AUTH_AES_GMAC
10. Acknowledgements
Our discussions with Fabio Maino and David Black significantly
improved this specification, and Tero Kivinen provided us with useful
comments. Steve Kent provided guidance on ESP interactions. This
work is closely modeled after AES-GCM, which itself is closely
modeled after Russ Housley's AES-CCM transform [RFC4309].
Additionally, the GCM mode of operation was originally conceived as
an improvement to the CWC mode [CWC] in which Doug Whiting and Yoshi
Kohno participated. We express our thanks to Fabio, David, Tero,
Steve, Russ, Doug, and Yoshi.
McGrew & Viega Standards Track [Page 11]
RFC 4543 GMAC in IPsec ESP and AH May 2006
11. References
11.1. Normative References
[GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of
Operation (GCM)", Submission to NIST. http://
csrc.nist.gov/CryptoToolkit/modes/proposedmodes/gcm/
gcm-spec.pdf, January 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC Cipher
Algorithm and Its Use with IPsec", RFC 3602, September
2003.
11.2. Informative References
[CWC] Kohno, T., Viega, J., and D. Whiting, "CWC: A high-
performance conventional authenticated encryption mode",
Fast Software Encryption.
http://eprint.iacr.org/2003/106.pdf, February 2004.
[GCMP] McGrew, D. and J. Viega, "The Security and Performance of
the Galois/Counter Mode (GCM)", Proceedings of INDOCRYPT
'04, http://eprint.iacr.org/2004/193, December 2004.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
4106, June 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
4306, December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", RFC
4309, December 2005.
McGrew & Viega Standards Track [Page 12]
RFC 4543 GMAC in IPsec ESP and AH May 2006
Authors' Addresses
David A. McGrew
Cisco Systems, Inc.
510 McCarthy Blvd.
Milpitas, CA 95035
US
Phone: (408) 525 8651
EMail: mcgrew@cisco.com
URI: http://www.mindspring.com/~dmcgrew/dam.htm
John Viega
McAfee, Inc.
1145 Herndon Parkway, Suite 500
Herndon, VA 20170
EMail: viega@list.org
McGrew & Viega Standards Track [Page 13]
RFC 4543 GMAC in IPsec ESP and AH May 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
McGrew & Viega Standards Track [Page 14]

1851
doc/standards/rfc4555.txt
View File

File diff suppressed because it is too large Load Diff

3251
doc/standards/rfc4718.txt
View File

File diff suppressed because it is too large Load Diff

619
doc/standards/rfc4739.txt
View File

@ -1,619 +0,0 @@
Network Working Group P. Eronen
Request for Comments: 4739 Nokia
Category: Experimental J. Korhonen
TeliaSonera
November 2006
Multiple Authentication Exchanges
in the Internet Key Exchange (IKEv2) Protocol
Status of This Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Abstract
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.
Eronen & Korhonen Experimental [Page 1]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
Table of Contents
1. Introduction ....................................................3
1.1. Usage Scenarios ............................................4
1.2. Terminology ................................................5
2. Solution ........................................................5
2.1. Solution Overview ..........................................5
2.2. Example 1: Multiple EAP Authentications ....................6
2.3. Example 2: Mixed EAP and Certificate Authentications .......7
2.4. Example 3: Multiple Initiator Certificates .................8
2.5. Example 4: Multiple Responder Certificates .................8
3. Payload Formats .................................................9
3.1. MULTIPLE_AUTH_SUPPORTED Notify Payload .....................9
3.2. ANOTHER_AUTH_FOLLOWS Notify Payload ........................9
4. IANA Considerations .............................................9
5. Security Considerations .........................................9
6. Acknowledgments ................................................10
7. References .....................................................10
7.1. Normative References ......................................10
7.2. Informative References ....................................10
Eronen & Korhonen Experimental [Page 2]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
1. Introduction
IKEv2 [IKEv2] supports several mechanisms for parties involved in the
IKE_SA (IKE security association). These include 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. However, there are scenarios where making the
authorization decision in IKEv2 (whether to allow access or not)
requires using several of these methods.
For instance, it may be necessary to authenticate both the host
(machine) requesting access, and the user currently using the host.
These two authentications would use two separate sets of credentials
(such as certificates and associated private keys) and might even use
different authentication mechanisms.
To take another example, when an operator is hosting a Virtual
Private Network (VPN) gateway service for a third party, it may be
necessary to authenticate the client to both the operator (for
billing purposes) and the third party's Authentication,
Authorization, and Accounting (AAA) server (for authorizing access to
the third party's internal network).
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.
Each authentication exchange requiring communication with backend AAA
servers may be directed to different backend AAA servers, located
even in different administrative domains. However, details of the
communication between the IKEv2 gateway and the backend
authentication servers are beyond the scope of this document. In
particular, this document does not specify any changes to existing
AAA protocols, and it does not require the use of any particular AAA
protocol.
In case of several EAP authentications, it is important to notice
that they are not a "sequence" (as described in Section 2.1 of
[EAP]), but separate independent EAP conversations, which are usually
also terminated in different EAP servers. Multiple authentication
methods within a single EAP conversation are still prohibited as
described in Section 2.1 of [EAP]. Using multiple independent EAP
conversations is similar to the separate Network Access Provider
(NAP) and Internet Service Provider (ISP) authentication exchanges
Eronen & Korhonen Experimental [Page 3]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
planned for [PANA]. The discovery of the appropriate EAP server for
each EAP authentication conversation is based on AAA routing.
1.1. Usage Scenarios
Figure 1 shows an example architecture of an operator-hosted VPN
scenario that could benefit from a two-phase authentication within
the IKEv2 exchange. First, the client authenticates towards the
Network Access Provider (NAP) and gets access to the NAP-hosted VPN
gateway. The first-phase authentication involves the backend AAA
server of the NAP. After the first authentication, the client
initiates the second authentication round that also involves the
Third Party's backend AAA server. If both authentications succeed,
the required IPsec tunnels are set up and the client can access
protected networks behind the Third Party.
Client *Network Access Provider*
+---------+ +---------+ +-----+
| | | NAP's | | NAP |
|Protected| IPsec SAs | Tunnel | AAA Protocol | AAA |
|Endpoint |<------------------>|Endpoint |<------------>|Serv/|
| | | | |Proxy|
+---------+ +---------+ +-----+
^ ^
IPsec or / AAA |
Leased Line / Protocol |
/ |
v |
+---------+ *Third Party* v
|3rd Party| +-----+
Protected | Tunnel | | 3rd |
Subnet <----|Endpoint | |Party|
| | | AAA |
+---------+ +-----+
Figure 1: Two-phase authentication used to gain access to
the Third Party network via Network Access Provider. AAA
traffic goes through NAP's AAA server.
The NAP's AAA server can be used to proxy the AAA traffic to the
Third Party's backend AAA server. Alternatively, the AAA traffic
from the NAP's tunnel endpoint could go directly to the Third Party's
backend AAA servers. However, this is more or less an AAA routing
issue.
Eronen & Korhonen Experimental [Page 4]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
1.2. Terminology
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 [KEYWORDS].
The terms and abbreviations "authenticator", "backend authentication
server", "EAP server", and "peer" in this document are to be
interpreted as described in [EAP].
When messages containing IKEv2 payloads are described, optional
payloads are shown in brackets (for instance, "[FOO]"), and a plus
sign indicates that a payload can be repeated one or more times (for
instance, "FOO+").
2. Solution
2.1. Solution Overview
The peers announce support for this IKEv2 extension by including a
MULTIPLE_AUTH_SUPPORTED notification in the IKE_SA_INIT response
(responder) and the first IKE_AUTH request (initiator).
If both peers support this extension, either of them can announce
that it wishes to have a second authentication by including an
ANOTHER_AUTH_FOLLOWS notification in any IKE_AUTH message that
contains an AUTH payload. This indicates that the peer sending the
ANOTHER_AUTH_FOLLOWS wishes to authenticate another set of
credentials to the other peer. The next IKE_AUTH message sent by
this peer will contain a second identity payload (IDi or IDr) and
starts another authentication exchange. The IKE_AUTH phase is
considered successful only if all the individual authentication
exchanges complete successfully.
It is assumed that both peers know what credentials they want to
present; there is no negotiation about, for instance, what type of
authentication is to be done. As in IKEv2, EAP-based authentication
is always requested by the initiator (by omitting the AUTH payload).
The AUTH payloads are calculated as specified in [IKEv2] Sections
2.15 and 2.16, where IDi' refers to the latest IDi payload sent by
the initiator, and IDr' refers to the latest IDr payload sent by the
responder. If EAP methods that do not generate shared keys are used,
it is possible that several AUTH payloads with identical contents are
sent. When such EAP methods are used, the purpose of the AUTH
payload is simply to delimit the authentication exchanges, and ensure
that the IKE_SA_INIT request/response messages were not modified.
Eronen & Korhonen Experimental [Page 5]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
2.2. Example 1: Multiple EAP Authentications
This example shows certificate-based authentication of the responder
followed by an EAP authentication exchange (messages 1-10). When the
first EAP exchange is ending (the initiator is sending its AUTH
payload), the initiator announces that it wishes to have a second
authentication exchange by including an ANOTHER_AUTH_FOLLOWS
notification (message 9).
After this, a second authentication exchange begins. The initiator
sends a new IDi payload but no AUTH payload (message 11), indicating
that EAP will be used. After that, another EAP authentication
exchange follows (messages 12-18).
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERTREQ+], [IDr],
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH,
EAP(Request) }
5. HDR, SK { EAP(Response) } -->
<-- 6. HDR, SK { EAP(Request) }
7. HDR, SK { EAP(Response) } -->
<-- 8. HDR, SK { EAP(Success) }
9. HDR, SK { AUTH,
N(ANOTHER_AUTH_FOLLOWS) } -->
<-- 10. HDR, SK { AUTH }
11. HDR, SK { IDi } -->
<-- 12. HDR, SK { EAP(Request) }
13. HDR, SK { EAP(Response) } -->
<-- 14. HDR, SK { EAP(Request) }
15. HDR, SK { EAP(Response) } -->
<-- 16. HDR, SK { EAP(Success) }
17. HDR, SK { AUTH } -->
<-- 18. HDR, SK { AUTH, SA, TSi, TSr }
Example 1: Certificate-based authentication of the
responder, followed by two EAP authentication exchanges.
Eronen & Korhonen Experimental [Page 6]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
2.3. Example 2: Mixed EAP and Certificate Authentications
Another example is shown below: here both the initiator and the
responder are first authenticated using certificates (or shared
secrets); this is followed by an EAP authentication exchange.
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED),
N(ANOTHER_AUTH_FOLLOWS) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH }
5. HDR, SK { IDi } -->
<-- 6. HDR, SK { EAP(Request) }
7. HDR, SK { EAP(Response) } -->
<-- 8. HDR, SK { EAP(Request) }
9. HDR, SK { EAP(Response) } -->
<-- 10. HDR, SK { EAP(Success) }
11. HDR, SK { AUTH } -->
<-- 12. HDR, SK { AUTH, SA, TSi, TSr }
Example 2: Certificate-based (or shared-secret-based)
authentication of the initiator and the responder,
followed by an EAP authentication exchange.
Eronen & Korhonen Experimental [Page 7]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
2.4. Example 3: Multiple Initiator Certificates
This example shows yet another possibility: the initiator has two
different certificates (and associated private keys), and
authenticates both of them to the responder.
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED),
N(ANOTHER_AUTH_FOLLOWS) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH }
5. HDR, SK { IDi, [CERT+], AUTH } -->
<-- 6. HDR, SK { SA, TSi, TSr }
Example 3: Two certificate-based authentications of the
initiator, and one certificate-based authentication
of the responder.
2.5. Example 4: Multiple Responder Certificates
This example shows yet another possibility: the responder has two
different certificates (and associated private keys), and
authenticates both of them to the initiator.
Initiator Responder
----------- -----------
1. HDR, SA, KE, Ni -->
<-- 2. HDR, SA, KE, Nr, [CERTREQ],
N(MULTIPLE_AUTH_SUPPORTED)
3. HDR, SK { IDi, [CERT+], [CERTREQ+], [IDr], AUTH,
SA, TSi, TSr, N(MULTIPLE_AUTH_SUPPORTED) } -->
<-- 4. HDR, SK { IDr, [CERT+], AUTH,
N(ANOTHER_AUTH_FOLLOWS) }
5. HDR, SK { } -->
<-- 6. HDR, SK { IDr, [CERT+], AUTH,
SA, TSi, TSr }
Example 4: Two certificate-based authentications of the
responder, and one certificate-based authentication
of the initiator.
Eronen & Korhonen Experimental [Page 8]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
3. Payload Formats
3.1. MULTIPLE_AUTH_SUPPORTED Notify Payload
The MULTIPLE_AUTH_SUPPORTED notification is included in the
IKE_SA_INIT response or the first IKE_AUTH request to indicate that
the peer supports this specification. The Notify Message Type is
MULTIPLE_AUTH_SUPPORTED (16404). The Protocol ID and SPI Size fields
MUST be set to zero, and there is no data associated with this Notify
type.
3.2. ANOTHER_AUTH_FOLLOWS Notify Payload
The ANOTHER_AUTH_FOLLOWS notification payload is included in an
IKE_AUTH message containing an AUTH payload to indicate that the peer
wants to continue with another authentication exchange. The Notify
Message Type is ANOTHER_AUTH_FOLLOWS (16405). The Protocol ID and
SPI Size fields MUST be set to zero, and there is no data associated
with this Notify type.
4. IANA Considerations
This document defines two new IKEv2 notifications,
MULTIPLE_AUTH_SUPPORTED and ANOTHER_AUTH_FOLLOWS, whose values are
allocated from the "IKEv2 Notify Message Types" namespace defined in
[IKEv2].
This document does not define any new namespaces to be managed by
IANA.
5. Security Considerations
Security considerations for IKEv2 are discussed in [IKEv2]. The
reader is encouraged to pay special attention to considerations
relating to the use of EAP methods that do not generate shared keys.
However, the use of multiple authentication exchanges results in at
least one new security consideration.
In normal IKEv2, the responder authenticates the initiator before
revealing its identity (except when EAP is used). When multiple
authentication exchanges are used to authenticate the initiator, the
responder has to reveal its identity before all of the initiator
authentication exchanges have been completed.
Eronen & Korhonen Experimental [Page 9]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
6. Acknowledgments
The authors would like to thank Bernard Aboba, Jari Arkko, Spencer
Dawkins, Lakshminath Dondeti, Henry Haverinen, Russ Housley, Mika
Joutsenvirta, Charlie Kaufman, Tero Kivinen, Yoav Nir, Magnus
Nystrom, Mohan Parthasarathy, and Juha Savolainen for their valuable
comments.
7. References
7.1. Normative References
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
7.2. Informative References
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[PANA] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C.
Wang, "Protocol for Carrying Authentication for Network
Access (PANA) Requirements", RFC 4058, May 2005.
Authors' Addresses
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Jouni Korhonen
TeliaSonera
P.O. Box 970
FIN-00051 Sonera
Finland
EMail: jouni.korhonen@teliasonera.com
Eronen & Korhonen Experimental [Page 10]
RFC 4739 Multiple Auth. Exchanges in IKEv2 November 2006
Full Copyright Statement
Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eronen & Korhonen Experimental [Page 11]

619
doc/standards/rfc4806.txt
View File

@ -1,619 +0,0 @@
Network Working Group M. Myers
Request for Comments: 4806 TraceRoute Security LLC
Category: Standards Track H. Tschofenig
Siemens Networks GmbH & Co KG
February 2007
Online Certificate Status Protocol (OCSP) Extensions to IKEv2
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Abstract
While the Internet Key Exchange Protocol version 2 (IKEv2) supports
public key based authentication, the corresponding use of in-band
Certificate Revocation Lists (CRL) is problematic due to unbounded
CRL size. The size of an Online Certificate Status Protocol (OCSP)
response is however well-bounded and small. This document defines
the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSP
Content" identifies zero or more trusted OCSP responders and is a
request for inclusion of an OCSP response in the IKEv2 handshake. A
cooperative recipient of such a request responds with a CERT payload
containing the appropriate OCSP response. This content is
recognizable via the same "OCSP Content" identifier.
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. This document applies when
OCSP is desired and security policy prevents one of the IKEv2 peers
from accessing the relevant OCSP responder directly. Firewalls are
often deployed in a manner that prevents such access by IKEv2 peers
outside of an enterprise network.
Myers & Tschofenig Standards Track [Page 1]
RFC 4806 OCSP Extensions to IKEv2 February 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4
3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 5
4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 5
4.1. Request for OCSP Support . . . . . . . . . . . . . . . . . 5
4.2. Response to OCSP Support . . . . . . . . . . . . . . . . . 6
5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 6
5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2]
supports a range of authentication mechanisms, including the use of
public key based authentication. Confirmation of certificate
reliability is essential in order to achieve the security assurances
public key cryptography provides. One fundamental element of such
confirmation is reference to certificate revocation status (see
[RFC3280] for additional detail).
The traditional means of determining certificate revocation status is
through the use of Certificate Revocation Lists (CRLs). IKEv2 allows
CRLs to be exchanged in-band via the CERT payload.
However, CRLs can grow unbounded in size. Many real-world examples
exist to demonstrate the impracticality of including a multi-megabyte
file in an IKE exchange. This constraint is particularly acute in
bandwidth-limited environments (e.g., mobile communications). The
net effect is exclusion of in-band CRLs in favor of out-of-band (OOB)
acquisition of these data, should they even be used at all.
Reliance on OOB methods can be further complicated if access to
revocation data requires use of IPsec (and therefore IKE) to
establish secure and authorized access to the CRLs of an IKE
participant. Such network access deadlock further contributes to a
reduced reliance on the status of certificate revocations in favor of
blind trust.
Myers & Tschofenig Standards Track [Page 2]
RFC 4806 OCSP Extensions to IKEv2 February 2007
OCSP [RFC2560] offers a useful alternative. The size of an OCSP
response is bounded and small and therefore suitable for in-band
IKEv2 signaling of a certificate's revocation status.
This document defines an extension to IKEv2 that enables the use of
OCSP for in-band signaling of certificate revocation status. A new
content encoding is defined for use in the CERTREQ and CERT payloads.
A CERTREQ payload with "OCSP Content" identifies zero or more trusted
OCSP responders and is a request for inclusion of an OCSP response in
the IKEv2 handshake. A cooperative recipient of such a request
responds with a CERT payload containing the appropriate OCSP
response. This content is recognizable via the same "OCSP Content"
identifier.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
This document defines the following terms:
OCSP request:
An OCSP request refers to the CERTREQ payload that contains a new
content encoding, referred to as OCSP Content, that conforms to
the definition and behavior specified in Section 3.1.
OCSP response:
An OCSP response refers to the CERT payload that contains a new
content encoding, referred to as OCSP Content, that conforms to
the definition and behavior specified in Section 3.2.
OCSP responder:
The term OCSP responder refers to the entity that accepts requests
from an OCSP client and returns responses as defined in [RFC2560].
Note that the OCSP responder does not refer to the party that
sends the CERT message.
Myers & Tschofenig Standards Track [Page 3]
RFC 4806 OCSP Extensions to IKEv2 February 2007
3. Extension Definition
With reference to Section 3.6 of [IKEv2], the values for the Cert
Encoding field of the CERT payload are extended as follows (see also
the IANA Considerations section of this document):
Certificate Encoding Value
-------------------- -----
OCSP Content 14
3.1. OCSP Request
A value of OCSP Content (14) in the Cert Encoding field of a CERTREQ
Payload indicates the presence of zero or more OCSP responder
certificate hashes in the Certificate Authority field of the CERTREQ
payload. Section 2.2 of [RFC2560] defines responses, which belong to
one of the following three groups:
(a) the CA who issued the certificate
(b) a Trusted Responder whose public key is trusted by the requester
(c) a CA Designated Responder (Authorized Responder) who holds a
specially marked certificate issued directly by the CA,
indicating that the responder may issue OCSP responses for that
CA
In case of (a), the use of hashes in the CERTREQ message is not
needed since the OCSP response is signed by the CA who issued the
certificate. In case of (c), the OCSP response is signed by the CA
Designated Responder whereby the sender of the CERTREQ message does
not know the public key in advance. The presence of OCSP Content in
a CERTREQ message will identify one or more OCSP responders trusted
by the sender in case of (b).
The presence of OCSP Content (14) in a CERTREQ message:
1. identifies zero or more OCSP responders trusted by the sender;
2. notifies the recipient of sender's support for the OCSP extension
to IKEv2; and
3. notifies the recipient of sender's desire to receive OCSP
confirmation in a subsequent CERT payload.
Myers & Tschofenig Standards Track [Page 4]
RFC 4806 OCSP Extensions to IKEv2 February 2007
3.2. OCSP Response
A value of OCSP Content (14) in the Cert Encoding field of a CERT
Payload indicates the presence of an OCSP response in the Certificate
Data field of the CERT payload.
Correlation between an OCSP response CERT payload and a corresponding
CERT payload carrying a certificate can be achieved by matching the
OCSP response CertID field to the certificate. See [RFC2560] for the
definition of OCSP response content.
4. Extension Requirements
4.1. Request for OCSP Support
Section 3.7 of [IKEv2] allows for the concatenation of trust anchor
hashes as the Certification Authority value of a single CERTREQ
message. There is no means however to indicate which among those
hashes, if present, relates to the certificate of a trusted OCSP
responder.
Therefore, an OCSP request, as defined in Section 3.1 above, is
transmitted separate from any other CERTREQ payloads in an IKEv2
exchange.
Where it is useful to identify more than one trusted OCSP responder,
each such identification SHALL be concatenated in a manner identical
to the method documented in Section 3.7 of [IKEv2] regarding the
assembly of multiple trust anchor hashes.
The Certification Authority value in an OCSP request CERTREQ SHALL be
computed and produced in a manner identical to that of trust anchor
hashes as documented in Section 3.7 of [IKEv2].
Upon receipt of an OCSP response CERT payload corresponding to a
prior OCSP request CERTREQ, the CERTREQ sender SHALL incorporate the
OCSP response into path validation logic defined by [RFC3280].
Note that the lack of an OCSP response CERT payload after sending an
OCSP request CERT payload might be an indication that this OCSP
extension is not supported. As a result, it is recommended that
nodes be configured to require a response only if it is known that
all peers do in fact support this extension. Otherwise, it is
recommended that the nodes be configured to try OCSP and, if there is
no response, attempt to determine certificate revocation status by
some other means.
Myers & Tschofenig Standards Track [Page 5]
RFC 4806 OCSP Extensions to IKEv2 February 2007
4.2. Response to OCSP Support
Upon receipt of an OCSP request CERTREQ payload, the recipient SHOULD
acquire the related OCSP-based assertion and produce and transmit an
OCSP response CERT payload corresponding to the certificate needed to
verify its signature on IKEv2 payloads.
An OCSP response CERT payload is transmitted separate from any other
CERT payload in an IKEv2 exchange.
The means by which an OCSP response may be acquired for production of
an OCSP response CERT payload is out of scope of this document.
The Certificate Data field of an OCSP response CERT payload SHALL
contain a DER-encoded OCSPResponse structure as defined in [RFC2560].
5. Examples and Discussion
This section shows the standard IKEv2 message examples with both
peers, the initiator and the responder, using public key based
authentication, CERTREQ and CERT payloads. The first instance
corresponds to Section 1.2 of [IKEv2], the illustrations of which are
reproduced below for reference.
5.1. Peer to Peer
Application of the IKEv2 extensions defined in this document to the
peer-to-peer exchange defined in Section 1.2 of [IKEv2] is as
follows. Messages are numbered for ease of reference.
Initiator Responder
----------- -----------
(1) HDR, SAi1, KEi, Ni -->
(2) <-- HDR, SAr1, KEr, Nr,
CERTREQ(OCSP Request)
(3) HDR, SK {IDi, CERT(certificate),-->
CERT(OCSP Response),
CERTREQ(OCSP Request),
[IDr,] AUTH, SAi2, TSi, TSr}
(4) <-- HDR, SK {IDr,
CERT(certificate),
CERT(OCSP Response),
AUTH, SAr2, TSi, TSr}
OCSP Extensions to Baseline IKEv2
Myers & Tschofenig Standards Track [Page 6]
RFC 4806 OCSP Extensions to IKEv2 February 2007
In (2), Responder sends an OCSP request CERTREQ payload identifying
zero or more OCSP responders trusted by the Responder. In response,
Initiator sends in (3) both a CERT payload carrying its certificate
and an OCSP response CERT payload covering that certificate. In (3),
Initiator also requests an OCSP response via the OCSP request CERTREQ
payload. In (4), the Responder returns its certificate and a
separate OCSP response CERT payload covering that certificate.
It is important to note that in this scenario, the Responder in (2)
does not yet possess the Initiator's certificate and therefore cannot
form an OCSP request as defined in [RFC2560]. To bypass this
problem, hashes are used as defined in Section 4.1. In such
instances, OCSP Requests are simply index values into these data.
Thus, it is easily inferred that OCSP responses can be produced in
the absence of a corresponding request (provided that OCSP nonces are
not used, see Section 6).
It is also important in extending IKEv2 toward OCSP in this scenario
that the Initiator has certain knowledge that the Responder is
capable of and willing to participate in the extension. Yet the
Responder will only trust one or more OCSP responder signatures.
These factors motivate the definition of OCSP responder hash
extension.
5.2. Extended Authentication Protocol (EAP)
Another scenario of pressing interest is the use of EAP to
accommodate multiple end users seeking enterprise access to an IPsec
gateway. Note that OCSP is used for the certificate status check of
the server side IKEv2 certificate and not for certificates that may
be used within EAP methods (either by the EAP peer or the EAP
server). As with the preceding section, the following illustration
is extracted from [IKEv2]. In the event of a conflict between this
document and [IKEv2] regarding these illustrations, [IKEv2] SHALL
dominate.
Myers & Tschofenig Standards Track [Page 7]
RFC 4806 OCSP Extensions to IKEv2 February 2007
Initiator Responder
----------- -----------
(1) HDR, SAi1, KEi, Ni -->
(2) <-- HDR, SAr1, KEr, Nr
(3) HDR, SK {IDi, -->
CERTREQ(OCSP Request),
[IDr,] AUTH, SAi2, TSi, TSr}
(4) <-- HDR, SK {IDr,
CERT(certificate),
CERT(OCSP Response),
AUTH, EAP}
(5) HDR, SK {EAP} -->
(6) <-- HDR, SK {EAP (success)}
(7) HDR, SK {AUTH} -->
(8) <-- HDR, SK {AUTH, SAr2, TSi,
TSr }
OCSP Extensions to EAP in IKEv2
In the EAP scenario, messages (5) through (8) are not relevant to
this document.
6. Security Considerations
For the reasons noted above, an OCSP request, as defined in Section
3.1, is used in place of an OCSP request syntax to trigger production
and transmission of an OCSP response. OCSP, as defined in [RFC2560],
may contain a nonce request extension to improve security against
replay attacks (see Section 4.4.1 of [RFC2560] for further details).
The OCSP request defined by this document cannot accommodate nonces.
[RFC2560] deals with this aspect by allowing pre-produced responses.
[RFC2560] points to this replay vulnerability and indicates: "The use
of precomputed responses allows replay attacks in which an old (good)
response is replayed prior to its expiration date but after the
certificate has been revoked. Deployments of OCSP should carefully
evaluate the benefit of precomputed responses against the probability
of a replay attack and the costs associated with its successful
execution." Nodes SHOULD make the required freshness of an OCSP
response configurable.
Myers & Tschofenig Standards Track [Page 8]
RFC 4806 OCSP Extensions to IKEv2 February 2007
7. IANA Considerations
This document defines one new field type for use in the IKEv2 Cert
Encoding field of the Certificate Payload format. Official
assignment of the "OCSP Content" extension to the Cert Encoding table
of Section 3.6 of [IKEv2] has been acquired from IANA.
Certificate Encoding Value
-------------------- -----
OCSP Content 14
8. Acknowledgements
The authors would like to thank Russ Housley for his support.
Additionally, we would like to thank Pasi Eronen, Nicolas Williams,
Liqiang (Larry) Zhu, Lakshminath Dondeti, and Paul Hoffman for their
review. Pasi gave us invaluable last-call comments. We would also
like to thank Tom Taylor for his Gen-ART review. Jari Arkko gave us
IESG review comments.
9. Normative References
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
Myers & Tschofenig Standards Track [Page 9]
RFC 4806 OCSP Extensions to IKEv2 February 2007
Authors' Addresses
Michael Myers
TraceRoute Security LLC
EMail: mmyers@fastq.com
Hannes Tschofenig
Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Myers & Tschofenig Standards Track [Page 10]
RFC 4806 OCSP Extensions to IKEv2 February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Myers & Tschofenig Standards Track [Page 11]

7731
doc/standards/rfc5996.txt
View File

File diff suppressed because it is too large Load Diff

899
doc/standards/rfc5998.txt
View File

@ -1,899 +0,0 @@
Internet Engineering Task Force (IETF) P. Eronen
Request for Comments: 5998 Independent
Updates: 5996 H. Tschofenig
Category: Standards Track Nokia Siemens Networks
ISSN: 2070-1721 Y. Sheffer
Independent
September 2010
An Extension for EAP-Only Authentication in IKEv2
Abstract
IKEv2 specifies that Extensible Authentication Protocol (EAP)
authentication must be used together with responder authentication
based on public key signatures. This is necessary with old EAP
methods that provide only unilateral authentication using, e.g., one-
time passwords or token cards.
This document specifies how EAP methods that provide mutual
authentication and key agreement can be used to provide extensible
responder authentication for IKEv2 based on methods other than public
key signatures.
Status of This Memo
This is an Internet Standards Track document.
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). Further information on
Internet Standards is available in 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/rfc5998.
Eronen, et al. Standards Track [Page 1]
RFC 5998 Extension for EAP in IKEv2 September 2010
Copyright Notice
Copyright (c) 2010 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.
1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748],
is an authentication framework that supports multiple authentication
mechanisms. Today, EAP has been implemented at end hosts and routers
that connect via switched circuits or dial-up lines using PPP
[RFC1661], IEEE 802 wired switches [IEEE8021X], and IEEE 802.11
wireless access points [IEEE80211i].
One of the advantages of the EAP architecture is its flexibility.
EAP is used to select a specific authentication mechanism, typically
after the authenticator requests more information in order to
determine the specific authentication method to be used. Rather than
requiring the authenticator (e.g., wireless LAN access point) to be
updated to support each new authentication method, EAP permits the
use of a backend authentication server that may implement some or all
authentication methods.
Eronen, et al. Standards Track [Page 2]
RFC 5998 Extension for EAP in IKEv2 September 2010
IKEv2 ([RFC4306] and [RFC5996]) is a component of IPsec used for
performing mutual authentication and establishing and maintaining
Security Associations (SAs) for IPsec ESP and Authentication Header
(AH). In addition to supporting authentication using public key
signatures and shared secrets, IKEv2 also supports EAP
authentication.
IKEv2 provides EAP authentication since it was recognized that public
key signatures and shared secrets are not flexible enough to meet the
requirements of many deployment scenarios. By using EAP, IKEv2 can
leverage existing authentication infrastructure and credential
databases, since EAP allows users to choose a method suitable for
existing credentials, and also makes separation of the IKEv2
responder (VPN gateway) from the EAP authentication endpoint (backend
Authentication, Authorization, and Accounting (AAA) server) easier.
Some older EAP methods are designed for unilateral authentication
only (that is, EAP peer to EAP server). These methods are used in
conjunction with IKEv2 public-key-based authentication of the
responder to the initiator. It is expected that this approach is
especially useful for "road warrior" VPN gateways that use, for
instance, one-time passwords or token cards to authenticate the
clients.
However, most newer EAP methods, such as those typically used with
IEEE 802.11i wireless LANs, provide mutual authentication and key
agreement. Currently, IKEv2 specifies that these EAP methods must
also be used together with responder authentication based on public
key signatures.
In order for the public key signature authentication of the gateway
to be effective, a deployment of Public Key Infrastructure (PKI) is
required, which has to include management of trust anchors on all
supplicants. In many environments, this is not realistic, and the
security of the gateway public key is the same as the security of a
self-signed certificate. Mutually authenticating EAP methods alone
can provide a sufficient level of security in many circumstances, and
in fact, in some deployments, IEEE 802.11i uses EAP without any PKI
for authenticating the Wireless Local Area Network (WLAN) access
points.
This document specifies how EAP methods that offer mutual
authentication and key agreement can be used to provide responder
authentication in IKEv2 completely based on EAP.
Eronen, et al. Standards Track [Page 3]
RFC 5998 Extension for EAP in IKEv2 September 2010
1.1. Terminology
All notation in this protocol extension is taken from [RFC4306].
Numbered messages refer to the IKEv2 message sequence when using EAP.
Thus:
o Message 1 is the request message of IKE_SA_INIT.
o Message 2 is the response message of IKE_SA_INIT.
o Message 3 is the first request of IKE_AUTH.
o Message 4 is the first response of IKE_AUTH.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Scenarios
In this section, we describe two scenarios for extensible
authentication within IKEv2. These scenarios are intended to be
illustrative examples rather than specifying how things should be
done.
Figure 1 shows a configuration where the EAP and the IKEv2 endpoints
are co-located. Authenticating the IKEv2 responder using both EAP
and public key signatures is redundant. Offering EAP-based
authentication has the advantage that multiple different
authentication and key exchange protocols are available with EAP with
different security properties (such as strong password-based
protocols, protocols offering user identity confidentiality, and many
more).
+------+-----+ +------------+
O | IKEv2 | | IKEv2 |
/|\ | Initiator |<---////////////////////--->| Responder |
/ \ +------------+ IKEv2 +------------+
User | EAP Peer | Exchange | EAP Server |
+------------+ +------------+
Figure 1: EAP and IKEv2 Endpoints Are Co-Located
Figure 2 shows a typical corporate network access scenario. The
initiator (client) interacts with the responder (VPN gateway) in the
corporate network. The EAP exchange within IKE runs between the
Eronen, et al. Standards Track [Page 4]
RFC 5998 Extension for EAP in IKEv2 September 2010
client and the home AAA server. As a result of a successful EAP
authentication protocol run, session keys are established and sent
from the AAA server to the VPN gateway, and then used to authenticate
the IKEv2 SA with AUTH payloads.
The protocol used between the VPN gateway and AAA server could be,
for instance, Diameter [RFC4072] or RADIUS [RFC3579]. See Section 6
for related security considerations.
+-------------------------------+
| Corporate network |
| |
+-----------+ +--------+ |
| IKEv2 | AAA | Home | |
IKEv2 +////----->+ Responder +<---------->+ AAA | |
Exchange / | (VPN GW) | (RADIUS/ | Server | |
/ +-----------+ Diameter) +--------+ |
/ | carrying EAP |
| | |
| +-------------------------------+
v
+------+-----+
o | IKEv2 |
/|\ | Initiator |
/ \ | VPN client |
User +------------+
Figure 2: Corporate Network Access
3. Solution
IKEv2 specifies that when the EAP method establishes a shared secret
key, that key is used by both the initiator and responder to generate
an AUTH payload (thus authenticating the IKEv2 SA set up by messages
1 and 2).
When used together with public key responder authentication, the
responder is, in effect, authenticated using two different methods:
the public key signature AUTH payload in message 4, and the EAP-based
AUTH payload later.
If the initiator does not wish to use public-key-based responder
authentication, it includes an EAP_ONLY_AUTHENTICATION notification
payload (16417) in message 3. The Protocol ID and Security Parameter
Index (SPI) size fields are set to zero, and there is no additional
data associated with this notification.
Eronen, et al. Standards Track [Page 5]
RFC 5998 Extension for EAP in IKEv2 September 2010
If the responder supports this notification and chooses to use it, it
omits the public-key-based AUTH payload and CERT payloads from
message 4.
If the responder does not support the EAP_ONLY_AUTHENTICATION
notification or does not wish to use it, it ignores the notification
payload, and includes the AUTH payload in message 4. In this case,
the initiator MUST verify that payload and any associated
certificates, as per [RFC4306].
When receiving message 4, the initiator MUST verify that the proposed
EAP method is allowed by this specification, and MUST abort the
protocol immediately otherwise.
Both the initiator and responder MUST verify that the EAP method
actually used provided mutual authentication and established a shared
secret key. The AUTH payloads sent after EAP Success MUST use the
EAP-generated key, and MUST NOT use SK_pi or SK_pr (see Section 2.15
of [RFC5996]).
Eronen, et al. Standards Track [Page 6]
RFC 5998 Extension for EAP in IKEv2 September 2010
An IKEv2 message exchange with this modification is shown below:
Initiator Responder
----------- -----------
HDR, SAi1, KEi, Ni,
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)] -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ],
[N(NAT_DETECTION_SOURCE_IP),
N(NAT_DETECTION_DESTINATION_IP)]
HDR, SK { IDi, [IDr], SAi2, TSi, TSr,
N(EAP_ONLY_AUTHENTICATION),
[CP(CFG_REQUEST)] } -->
<-- HDR, SK { IDr, EAP(Request) }
HDR, SK { EAP(Response) } -->
<-- HDR, SK { EAP(Request) }
HDR, SK { EAP(Response) } -->
<-- HDR, SK { EAP(Success) }
HDR, SK { AUTH } -->
<-- HDR, SK { AUTH, SAr2, TSi, TSr,
[CP(CFG_REPLY] }
Note: all notation in the above protocol sequence and elsewhere in
this specification is as defined in [RFC4306], and see in particular
Sec. 1.2 of [RFC4306] for payload types.
The NAT detection and Configuration payloads are shown for
informative purposes only; they do not change how EAP authentication
works.
An IKE SA that was set up with this extension can be resumed using
the mechanism described in [RFC5723]. However, session resumption
does not change the authentication method. Therefore, during the
IKE_AUTH exchange of the resumed session, this extension MUST NOT be
sent by the initiator.
Eronen, et al. Standards Track [Page 7]
RFC 5998 Extension for EAP in IKEv2 September 2010
4. Safe EAP Methods
EAP methods to be used with this extension MUST have the following
properties:
1. The method provides mutual authentication of the peers.
2. The method is key-generating.
3. The method is resistant to dictionary attacks.
The authors believe that the following EAP methods are secure when
used with the current extension. The list is not inclusive, and
there are likely other safe methods that have not been listed here.
+-------------------------------+-------------------+---------------+
| Method Name | Allows Channel | Reference |
| | Binding? | |
+-------------------------------+-------------------+---------------+
| EAP-SIM | No | [RFC4186] |
| EAP-AKA | Yes | [RFC4187] |
| EAP-AKA' | Yes | [RFC5448] |
| EAP-GPSK | Yes | [RFC5433] |
| EAP-pwd | No | [RFC5931] |
| EAP-EKE | Yes | [EMU-EAP-EKE] |
| EAP-PAX | Yes | [RFC4746] |
| EAP-SAKE | No | [RFC4763] |
| EAP-SRP | No | [EAP-SRP] |
| EAP-POTP (mutual | Yes | [RFC4793] |
| authentication variant) | | |
| EAP-TLS | No | [RFC5216] |
| EAP-FAST | No | [RFC4851] |
| EAP-TTLS | No | [RFC5281] |
+-------------------------------+-------------------+---------------+
The "Allows channel binding?" column denotes protocols where
protected identity information may be sent between the EAP endpoints.
This third, optional property of the method provides protection
against certain types of attacks (see Section 6.2 for an
explanation), and therefore in some scenarios, methods that allow for
channel binding are to be preferred. It is noted that at the time of
writing, even when such capabilities are provided, they are not fully
specified in an interoperable manner. In particular, no RFC
specifies what identities should be sent under the protection of the
channel binding mechanism, or what policy is to be used to correlate
identities at the different layers.
Eronen, et al. Standards Track [Page 8]
RFC 5998 Extension for EAP in IKEv2 September 2010
5. IANA Considerations
This document defines a new IKEv2 Notification Payload type,
EAP_ONLY_AUTHENTICATION, described in Section 3. This payload has
been assigned the type number 16417 from the "Status Types" range.
6. Security Considerations
Security considerations applicable to all EAP methods are discussed
in [RFC3748]. The EAP Key Management Framework [RFC5247] deals with
issues that arise when EAP is used as a part of a larger system.
6.1. Authentication of IKEv2 SA
It is important to note that the IKEv2 SA is not authenticated by
just running an EAP conversation: the crucial step is the AUTH
payload based on the EAP-generated key. Thus, EAP methods that do
not provide mutual authentication or establish a shared secret key
MUST NOT be used with the modifications presented in this document.
6.2. Authentication with Separated IKEv2 Responder / EAP Server
As described in Section 2, the EAP conversation can terminate either
at the IKEv2 responder or at a backend AAA server.
If the EAP method is terminated at the IKEv2 responder, then no key
transport via the AAA infrastructure is required. Pre-shared secret
and public-key-based authentication offered by IKEv2 is then replaced
by a wider range of authentication and key exchange methods.
However, typically EAP will be used with a backend AAA server. See
[RFC5247] for a more complete discussion of the related security
issues; here we provide only a short summary.
When a backend server is used, there are actually two authentication
exchanges: the EAP method between the client and the AAA server, and
another authentication between the AAA server and IKEv2 gateway. The
AAA server authenticates the client using the selected EAP method,
and they establish a session key. The AAA server then sends this key
to the IKEv2 gateway over a connection authenticated using, e.g.,
IPsec or Transport Layer Security (TLS).
Some EAP methods do not have any concept of pass-through
authenticator (e.g., Network Access Server (NAS) or IKEv2 gateway)
identity, and these two authentications remain quite independent of
each other. That is, after the client has verified the AUTH payload
sent by the IKEv2 gateway, it knows that it is talking to SOME
gateway trusted by the home AAA server, but not which one. The
Eronen, et al. Standards Track [Page 9]
RFC 5998 Extension for EAP in IKEv2 September 2010
situation is somewhat similar if a single cryptographic hardware
accelerator, containing a single private key, would be shared between
multiple IKEv2 gateways (perhaps in some kind of cluster
configuration). In particular, if one of the gateways is
compromised, it can impersonate any of the other gateways towards the
user (until the compromise is discovered and access rights revoked).
In some environments it is not desirable to trust the IKEv2 gateways
this much (also known as the "Lying NAS Problem"). EAP methods that
provide what is called "connection binding" or "channel binding"
transport some identity or identities of the gateway (or WLAN access
point / NAS) inside the EAP method. Then the AAA server can check
that it is indeed sending the key to the gateway expected by the
client. A potential solution is described in [EAP-SERVICE], see also
[EMU-AAAPAY].
In some deployment configurations, AAA proxies may be present between
the IKEv2 gateway and the backend AAA server. These AAA proxies MUST
be trusted for secure operation, and therefore SHOULD be avoided when
possible; see Section 2.3.4 of [RFC4072] and Section 4.3.7 of
[RFC3579] for more discussion.
6.3. Protection of EAP Payloads
Although the EAP payloads are encrypted and integrity protected with
SK_e/SK_a, this does not provide any protection against active
attackers. Until the AUTH payload has been received and verified, a
man-in-the-middle can change the KEi/KEr payloads and eavesdrop or
modify the EAP payloads.
In IEEE 802.11i wireless LANs, the EAP payloads are neither encrypted
nor integrity protected (by the link layer), so EAP methods are
typically designed to take that into account.
In particular, EAP methods that are vulnerable to dictionary attacks
when used in WLANs are still vulnerable (to active attackers) when
run inside IKEv2.
The rules in Section 4 are designed to avoid this potential
vulnerability.
Eronen, et al. Standards Track [Page 10]
RFC 5998 Extension for EAP in IKEv2 September 2010
6.4. Identities and Authenticated Identities
When using this protocol, each of the peers sends two identity
values:
1. An identity contained in the IKE ID payload.
2. An identity transferred within the specific EAP method's
messages.
(IKEv2 omits the EAP Identity request/response pair, see Section 3.16
of [RFC5996].) The first identity value can be used by the recipient
to route AAA messages and/or to select authentication and EAP types.
But it is only the second identity that is directly authenticated by
the EAP method. The reader is referred to Section 2.16 of [RFC5996]
regarding the need to base IPsec policy decisions on the
authenticated identity. In the context of the extension described
here, this guidance on IPsec policy applies both to the
authentication of the client by the gateway and vice versa.
6.5. User Identity Confidentiality
IKEv2 provides confidentiality for the initiator identity against
passive eavesdroppers, but not against active attackers. The
initiator announces its identity first (in message 3), before the
responder has been authenticated. The usage of EAP in IKEv2 does not
change this situation, since the ID payload in message 3 is used
instead of the EAP Identity Request/Response exchange. This is
somewhat unfortunate since when EAP is used with public key
authentication of the responder, it would be possible to provide
active user identity confidentiality for the initiator.
IKEv2 protects the responder's identity even against active attacks.
This property cannot be provided when using EAP. If public key
responder authentication is used in addition to EAP, the responder
reveals its identity before authenticating the initiator. If only
EAP is used (as proposed in this document), the situation depends on
the EAP method used (in some EAP methods, the server reveals its
identity first).
Hence, if active user identity confidentiality for the responder is
required then EAP methods that offer this functionality have to be
used (see [RFC3748], Section 7.3).
Eronen, et al. Standards Track [Page 11]
RFC 5998 Extension for EAP in IKEv2 September 2010
7. Acknowledgments
This document borrows some text from [RFC3748], [RFC4306], and
[RFC4072]. We would also like to thank Hugo Krawczyk for interesting
discussions about this topic, Dan Harkins, and David Harrington for
their comments.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
Protocol Version 2 (IKEv2) Session Resumption",
RFC 5723, January 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
8.2. Informative References
[EAP-SERVICE] Arkko, J. and P. Eronen, "Authenticated Service
Information for the Extensible Authentication Protocol
(EAP)", Work in Progress, October 2005.
[EAP-SRP] Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-
SHA1 Authentication Protocol", Work in Progress,
July 2001.
[EMU-AAAPAY] Clancy, C., Lior, A., Zorn, G., and K. Hoeper, "EAP
Method Support for Transporting AAA Payloads", Work
in Progress, May 2010.
[EMU-EAP-EKE] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer,
"An EAP Authentication Method Based on the EKE
Protocol", Work in Progress, August 2010.
Eronen, et al. Standards Track [Page 12]
RFC 5998 Extension for EAP in IKEv2 September 2010
[IEEE80211i] Institute of Electrical and Electronics Engineers,
"IEEE Standard for Information technology -
Telecommunications and information exchange between
systems - Local and metropolitan area networks -
Specific requirements - Part 11: Wireless Medium
Access Control (MAC) and Physical Layer (PHY)
specifications: Amendment 6: Medium Access Control
(MAC) Security Enhancements", IEEE Standard 802.11i-
2004, July 2004.
[IEEE8021X] Institute of Electrical and Electronics Engineers,
"Local and Metropolitan Area Networks: Port-Based
Network Access Control", IEEE Standard 802.1X-2001,
2001.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
Authentication Dial In User Service) Support For
Extensible Authentication Protocol (EAP)", RFC 3579,
September 2003.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter
Extensible Authentication Protocol (EAP) Application",
RFC 4072, August 2005.
[RFC4186] Haverinen, H. and J. Salowey, "Extensible
Authentication Protocol Method for Global System for
Mobile Communications (GSM) Subscriber Identity
Modules (EAP-SIM)", RFC 4186, January 2006.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and
Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication
Protocol (EAP) Password Authenticated Exchange",
RFC 4746, November 2006.
[RFC4763] Vanderveen, M. and H. Soliman, "Extensible
Authentication Protocol Method for Shared-secret
Authentication and Key Establishment (EAP-SAKE)",
RFC 4763, November 2006.
[RFC4793] Nystroem, M., "The EAP Protected One-Time Password
Protocol (EAP-POTP)", RFC 4793, February 2007.
Eronen, et al. Standards Track [Page 13]
RFC 5998 Extension for EAP in IKEv2 September 2010
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou,
"The Flexible Authentication via Secure Tunneling
Extensible Authentication Protocol Method (EAP-FAST)",
RFC 4851, May 2007.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, March 2008.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management
Framework", RFC 5247, August 2008.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible
Authentication Protocol Tunneled Transport Layer
Security Authenticated Protocol Version 0 (EAP-
TTLSv0)", RFC 5281, August 2008.
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible
Authentication Protocol - Generalized Pre-Shared Key
(EAP-GPSK) Method", RFC 5433, February 2009.
[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
Extensible Authentication Protocol Method for 3rd
Generation Authentication and Key Agreement (EAP-
AKA')", RFC 5448, May 2009.
[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication
Protocol (EAP) Authentication Using Only A Password",
RFC 5931, August 2010.
Eronen, et al. Standards Track [Page 14]
RFC 5998 Extension for EAP in IKEv2 September 2010
Appendix A. Alternative Approaches
In this section, we list alternatives that have been considered
during the work on this document. We concluded that the solution
presented in Section 3 seems to fit better into IKEv2.
A.1. Ignore AUTH Payload at the Initiator
With this approach, the initiator simply ignores the AUTH payload in
message 4 (but obviously must check the second AUTH payload later!).
The main advantage of this approach is that no protocol modifications
are required and no signature verification is required. A
significant disadvantage is that the EAP method to be used cannot be
selected to take this behavior into account.
The initiator could signal to the responder (using a notification
payload) that it did not verify the first AUTH payload.
A.2. Unauthenticated Public Keys in AUTH Payload (Message 4)
Another solution approach suggests the use of unauthenticated public
keys in the public key signature AUTH payload (for message 4).
That is, the initiator verifies the signature in the AUTH payload,
but does not verify that the public key indeed belongs to the
intended party (using certificates) -- since it doesn't have a PKI
that would allow this. This could be used with X.509 certificates
(the initiator ignores all other fields of the certificate except the
public key), or "Raw RSA Key" CERT payloads.
This approach has the advantage that initiators that wish to perform
certificate-based responder authentication (in addition to EAP) may
do so, without requiring the responder to handle these cases
separately. A disadvantage here, again, is that the EAP method
selection cannot take into account the incomplete validation of the
responder's certificate.
If using RSA, the overhead of signature verification is quite small,
compared to the g^xy calculation required by the Diffie-Hellman
exchange.
A.3. Using EAP Derived Session Keys for IKEv2
It has been proposed that when using an EAP method that provides
mutual authentication and key agreement, the IKEv2 Diffie-Hellman
exchange could also be omitted. This would mean that the session
keys for IPsec SAs established later would rely only on EAP-provided
keys.
Eronen, et al. Standards Track [Page 15]
RFC 5998 Extension for EAP in IKEv2 September 2010
It seems the only benefit of this approach is saving some computation
time (g^xy calculation). This approach requires designing a
completely new protocol (which would not resemble IKEv2 anymore); we
do not believe that it should be considered. Nevertheless, we
include it for completeness.
Authors' Addresses
Pasi Eronen
Independent
EMail: pe@iki.fi
Hannes Tschofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Yaron Sheffer
Independent
EMail: yaronf.ietf@gmail.com
Eronen, et al. Standards Track [Page 16]