+++ /dev/null
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-
+++ /dev/null
-
-
-
-Network Working Group Y. Sheffer
-Internet-Draft Check Point
-Intended status: Experimental H. Tschofenig
-Expires: September 20, 2008 Nokia Siemens Networks
- L. Dondeti
- V. Narayanan
- QUALCOMM, Inc.
- March 19, 2008
-
-
- IPsec Gateway Failover Protocol
- draft-sheffer-ipsec-failover-03.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 September 20, 2008.
-
-Abstract
-
- The Internet Key Exchange version 2 (IKEv2) protocol has
- computational and communication overhead with respect to the number
- of round-trips required and cryptographic operations involved. In
- remote access situations, the Extensible Authentication Protocol is
- used for authentication, which adds several more round trips and
- therefore latency.
-
- To re-establish security associations (SA) upon a failure recovery
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 1]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
- condition is time consuming, especially when an IPsec peer, such as a
- VPN gateway, needs to re-establish a large number of SAs with various
- end points. A high number of concurrent sessions might cause
- additional problems for an IPsec peer during SA re-establishment.
-
- In many failure cases it would be useful to provide an efficient way
- to resume an interrupted IKE/IPsec session. This document proposes
- an extension to IKEv2 that allows a client to re-establish an IKE SA
- with a gateway in a highly efficient manner, utilizing a previously
- established IKE SA.
-
- A client can reconnect to a gateway from which it was disconnected,
- or alternatively migrate to another gateway that is associated with
- the previous one. The proposed approach conveys IKEv2 state
- information, in the form of an encrypted ticket, to a VPN client that
- is later presented to the VPN gateway for re-authentication. The
- encrypted ticket can only be decrypted by the VPN gateway in order to
- restore state for faster session setup.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 2]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
- 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 6
- 3.1. Recovering from a Remote Access Gateway Failover . . . . . 6
- 3.2. Recovering from an Application Server Failover . . . . . . 8
- 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 9
- 4.1. Requesting a Ticket . . . . . . . . . . . . . . . . . . . 9
- 4.2. Presenting a Ticket . . . . . . . . . . . . . . . . . . . 10
- 4.2.1. Protection of the IKE_SESSION_RESUME Exchange . . . . 12
- 4.2.2. Presenting a Ticket: The DoS Case . . . . . . . . . . 12
- 4.2.3. Requesting a ticket during resumption . . . . . . . . 13
- 4.3. IKE Notifications . . . . . . . . . . . . . . . . . . . . 13
- 4.4. TICKET_OPAQUE Notify Payload . . . . . . . . . . . . . . . 14
- 4.5. TICKET_GATEWAY_LIST Notify Payload . . . . . . . . . . . . 14
- 4.6. Processing Guidelines for IKE SA Establishment . . . . . . 15
- 5. The IKE Ticket . . . . . . . . . . . . . . . . . . . . . . . . 16
- 5.1. Ticket Contents . . . . . . . . . . . . . . . . . . . . . 16
- 5.2. Ticket Format . . . . . . . . . . . . . . . . . . . . . . 17
- 5.3. Ticket Identity and Lifecycle . . . . . . . . . . . . . . 17
- 5.4. Exchange of Ticket-Protecting Keys . . . . . . . . . . . . 18
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
- 7.1. Stolen Tickets . . . . . . . . . . . . . . . . . . . . . . 18
- 7.2. Forged Tickets . . . . . . . . . . . . . . . . . . . . . . 19
- 7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 19
- 7.4. Ticket Protection Key Management . . . . . . . . . . . . . 19
- 7.5. Ticket Lifetime . . . . . . . . . . . . . . . . . . . . . 19
- 7.6. Alternate Ticket Formats and Distribution Schemes . . . . 20
- 7.7. Identity Privacy, Anonymity, and Unlinkability . . . . . . 20
- 7.8. Replay Protection in the IKE_SESSION_RESUME Exchange . . . 20
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
- Appendix A. Related Work . . . . . . . . . . . . . . . . . . . . 22
- Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 22
- B.1. -03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
- B.2. -02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
- B.3. -01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
- B.4. -00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
- Intellectual Property and Copyright Statements . . . . . . . . . . 25
-
-
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 3]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
-1. Introduction
-
- The Internet Key Exchange version 2 (IKEv2) protocol has
- computational and communication overhead with respect to the number
- of round-trips required and cryptographic operations involved. In
- particular the Extensible Authentication Protocol is used for
- authentication in remote access cases, which increases latency.
-
- To re-establish security associations (SA) upon a failure recovery
- condition is time-consuming, especially when an IPsec peer, such as a
- VPN gateway, needs to re-establish a large number of SAs with various
- end points. A high number of concurrent sessions might cause
- additional problems for an IPsec peer.
-
- In many failure cases it would be useful to provide an efficient way
- to resume an interrupted IKE/IPsec session. This document proposes
- an extension to IKEv2 that allows a client to re-establish an IKE SA
- with a gateway in a highly efficient manner, utilizing a previously
- established IKE SA.
-
- A client can reconnect to a gateway from which it was disconnected,
- or alternatively migrate to another gateway that is associated with
- the previous one. This document proposes to maintain IKEv2 state in
- a "ticket", an opaque data structure created and used by a server and
- stored by a client, which the client cannot understand or tamper
- with. The IKEv2 protocol is extended to allow a client to request
- and present a ticket. When two gateways mutually trust each other,
- one can accept a ticket generated by the other.
-
- This approach is similar to the one taken by TLS session resumption
- [RFC4507] with the required adaptations for IKEv2, e.g., to
- accommodate the two-phase protocol structure. We have borrowed
- heavily from that specification.
-
-1.1. Goals
-
- The high-level goal of this extension is to provide an IPsec failover
- solution, according to the requirements defined in
- [I-D.vidya-ipsec-failover-ps].
-
- Specifically, the proposed extension should allow IPsec sessions to
- be recovered from failures in remote access scenarios, in a more
- efficient manner than the basic IKE solution. This efficiency is
- primarily on the gateway side, since the gateway might have to deal
- with many thousands of concurrent requests. We should enable the
- following cases:
-
-
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 4]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
- o Failover from one gateway to another, where the two gateways do
- not share state but do have mutual trust. For example, the
- gateways may be operated by the same provider and share the same
- keying materials to access an encrypted ticket.
- o Recovery from an intermittent connectivity, where clients
- reconnect into the same gateway. In this case, the gateway would
- typically have detected the clients' absence and removed the state
- associated with them.
- o Recovery from a gateway restart, where clients reconnect into the
- same gateway.
-
- The proposed solution should additionally meet the following goals:
-
- o Using only symmetric cryptography to minimize CPU consumption.
- o Allowing a gateway to push state to clients.
- o Providing cryptographic agility.
- o Having no negative impact on IKEv2 security features.
-
-1.2. Non-Goals
-
- The following are non-goals of this solution:
- o Providing load balancing among gateways.
- o Specifying how a client detects the need for a failover.
-
-
-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].
-
- This document uses terminology defined in [RFC4301], [RFC4306], and
- [RFC4555]. In addition, this document uses the following terms:
-
- Secure domain: A secure domain comprises a set of gateways that are
- able to resume an IKEv2 session that may have been established by
- any other gateway within the domain. All gateways in the secure
- domain are expected to share some secrets, so that they can
- generate an IKEv2 ticket, verify the validity of the ticket and
- extract the IKEv2 policy and session key material from the ticket.
- IKEv2 ticket: An IKEv2 ticket is a data structure that contains all
- the necessary information that allows any gateway within the same
- secure domain as the gateway that created the ticket to verify the
- validity of the ticket and extract IKEv2 policy and session keys
- to re-establish an IKEv2 session.
-
-
-
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 5]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
- Stateless failover: When the IKEv2 session state is stored at the
- client, the IKEv2 responder is "stateless" until the client
- restores the SA with one of the gateways within the secure domain;
- thus, we refer to SA resumption with SA storage at the client as
- stateless session resumption.
- Stateful failover: When the infrastructure maintains IKEv2 session
- state, we refer to the process of IKEv2 SA re-establishment as
- stateful session resumption.
-
-
-3. Usage Scenarios
-
- This specification envisions two usage scenarios for efficient IKEv2
- and IPsec SA session re-establishment.
-
- The first is similar to the use case specified in Section 1.1.3 of
- the IKEv2 specification [RFC4306], where the IPsec tunnel mode is
- used to establish a secure channel between a remote access client and
- a gateway; the traffic flow may be between the client and entities
- beyond the gateway.
-
- The second use case focuses on the usage of transport (or tunnel)
- mode to secure the communicate between two end points (e.g., two
- servers). The two endpoints have a client-server relationship with
- respect to a protocol that runs using the protections afforded by the
- IPsec SA.
-
-3.1. Recovering from a Remote Access Gateway Failover
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 6]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
- (a)
-
- +-+-+-+-+-+ +-+-+-+-+-+
- ! ! IKEv2/IKEv2-EAP ! ! Protected
- ! Remote !<------------------------>! Remote ! Subnet
- ! Access ! ! Access !<--- and/or
- ! Client !<------------------------>! Gateway ! Internet
- ! ! IPsec tunnel ! !
- +-+-+-+-+-+ +-+-+-+-+-+
-
-
- (b)
-
- +-+-+-+-+-+ +-+-+-+-+-+
- ! ! IKE_SESSION_RESUME ! !
- ! Remote !<------------------------>! New/Old !
- ! Access ! ! Gateway !
- ! Client !<------------------------>! !
- ! ! IPsec tunnel ! !
- +-+-+-+-+-+ +-+-+-+-+-+
-
-
-
- Figure 1: Remote Access Gateway Failure
-
- In this scenario, an end-host (an entity with a host implementation
- of IPsec [RFC4301] ) establishes a tunnel mode IPsec SA with a
- gateway in a remote network using IKEv2. The end-host in this
- scenario is sometimes referred to as a remote access client. When
- the remote gateway fails, all the clients associated with the gateway
- either need to re-establish IKEv2 sessions with another gateway
- within the same secure domain of the original gateway, or with the
- original gateway if the server is back online soon.
-
- The clients may choose to establish IPsec SAs using a full IKEv2
- exchange or the IKE_SESSION_RESUME exchange (shown in Figure 1).
-
- In this scenario, the client needs to get an IP address from the
- remote network so that traffic can be encapsulated by the remote
- access gateway before reaching the client. In the initial exchange,
- the gateway may acquire IP addresses from the address pool of a local
- DHCP server. The new gateway that a client gets associated may not
- receive addresses from the same address pool. Thus, the session
- resumption protocol needs to support the assignment of a new IP
- address.
-
- The protocol defined in this document supports the re-allocation of
- an IP address to the client, if this capability is provided by the
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 7]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
- network. For example, if routing tables are modified so that traffic
- is rerouted through the new gateway. This capability is implicit in
- the use of the IKE Config mechanism, which allows the client to
- present its existing IP address and receive the same address back, if
- allowed by the gateway.
-
- The protocol defined here supports both stateful and stateless
- scenarios. In other words, tickets can be stored wholly on the
- client, or the ticket can be stored on the gateway (or in a database
- shared between multiple gateways), with the client only presenting a
- handle that identifies a particular ticket. In fact these scenarios
- are transparent to the protocols, with the only change being the non-
- mandatory ticket format.
-
-3.2. Recovering from an Application Server Failover
-
-
- (a)
-
- +-+-+-+-+-+ +-+-+-+-+-+
- ! App. ! IKEv2/IKEv2-EAP ! App. !
- ! Client !<------------------------>! Server !
- ! & ! ! & !
- ! IPsec !<------------------------>! IPsec !
- ! host ! IPsec transport/ ! host !
- +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+
-
-
- (b)
-
- +-+-+-+-+-+ +-+-+-+-+-+
- ! App. ! IKE_SESSION_RESUME ! New !
- ! Client !<------------------------>! Server !
- ! & ! ! & !
- ! IPsec !<------------------------>! IPsec !
- ! host ! IPsec transport/ ! host !
- +-+-+-+-+-+ tunnel mode SA +-+-+-+-+-+
-
-
- Figure 2: Application Server Failover
-
- The second usage scenario is as follows: two entities with IPsec host
- implementations establish an IPsec transport or tunnel mode SA
- between themselves; this is similar to the model described in Section
- 1.1.2. of [RFC4306]. At the application level, one of the entities
- is always the client and the other is a server. From that view
- point, the IKEv2 exchange is always initiated by the client. This
- allows the Initiator (the client) to authenticate itself using EAP,
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 8]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
- as long as the Responder (or the application server) allows it.
-
- If the application server fails, the client may find other servers
- within the same secure domain for service continuity. It may use a
- full IKEv2 exchange or the IKE_SESSION_RESUME exchange to re-
- establish the IPsec SAs for secure communication required by the
- application layer signaling.
-
- The client-server relationship at the application layer ensures that
- one of the entities in this usage scenario is unambiguously always
- the Initiator and the other the Responder. This role determination
- also allows the Initiator to request an address in the Responder's
- network using the Configuration Payload mechanism of the IKEv2
- protocol. If the client has thus received an address during the
- initial IKEv2 exchange, when it associates with a new server upon
- failure of the original server, it needs to request an address,
- specifying its assigned address. The server may allow the client to
- use the original address or if it is not permitted to use that
- address, assign a new address.
-
-
-4. Protocol Details
-
- This section provides protocol details and contains the normative
- parts. This document defines two protocol exchanges, namely
- requesting a ticket and presenting a ticket. Section 4.1 describes
- the procedure to request a ticket and Section 4.2 illustrates how to
- present a ticket.
-
-4.1. Requesting a Ticket
-
- A client MAY request a ticket in the following exchanges:
-
- o In an IKE_AUTH exchange, as shown in the example message exchange
- in Figure 3 below.
- o In a CREATE_CHILD_SA exchange, when an IKE SA is rekeyed.
- o In an Informational exchange, if the gateway previously replied
- with an N(TICKET_ACK) instead of providing a ticket.
- o In an Informational exchange, when the ticket lifetime is about to
- expire.
- o In an IKE_SESSION_RESUME exchange, see Section 4.2.3.
-
- Normally, a client requests a ticket in the third message of an IKEv2
- exchange (the first of IKE_AUTH). Figure 3 shows the message
- exchange for this typical case.
-
-
-
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 9]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
- Initiator Responder
- ----------- -----------
- HDR, SAi1, KEi, Ni -->
-
- <-- HDR, SAr1, KEr, Nr, [CERTREQ]
-
- HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
- AUTH, SAi2, TSi, TSr, N(TICKET_REQUEST)} -->
-
- Figure 3: Example Message Exchange for Requesting a Ticket
-
- The notification payloads are described in Section 4.3. The above is
- an example, and IKEv2 allows a number of variants on these messages.
- A complete description of IKEv2 can be found in [RFC4718].
-
- When an IKEv2 responder receives a request for a ticket using the
- N(TICKET_REQUEST) payload it MUST perform one of the following
- operations if it supports the extension defined in this document:
- o it creates a ticket and returns it with the N(TICKET_OPAQUE)
- payload in a subsequent message towards the IKEv2 initiator. This
- is shown in Figure 4.
- o it returns an N(TICKET_NACK) payload, if it refuses to grant a
- ticket for some reason.
- o it returns an N(TICKET_ACK), if it cannot grant a ticket
- immediately, e.g., due to packet size limitations. In this case
- the client MAY request a ticket later using an Informational
- exchange, at any time during the lifetime of the IKE SA.
-
- Provided the IKEv2 exchange was successful, the IKEv2 initiator can
- accept the requested ticket. The ticket may be used later with an
- IKEv2 responder which supports this extension. Figure 4 shows how
- the initiator receives the ticket.
-
-
-
- Initiator Responder
- ----------- -----------
- <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi,
- TSr, N(TICKET_OPAQUE) [,N(TICKET_GATEWAY_LIST)]}
-
-
- Figure 4: Receiving a Ticket
-
-4.2. Presenting a Ticket
-
- Following a communication failure, a client re-initiates an IKE
- exchange to the same gateway or to a different one, and includes a
- ticket in the first message. A client MAY initiate a regular (non-
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 10]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
- ticket-based) IKEv2 exchange even if it is in possession of a valid
- ticket. A client MUST NOT present a ticket after the ticket's
- lifetime has expired.
-
- It is up to the client's local policy to decide when the
- communication with the IKEv2 responder is seen as interrupted and a
- new exchange needs to be initiated and the session resumption
- procedure to be initiated.
-
- Tickets are intended for one-time use: a client MUST NOT reuse a
- ticket, either with the same or with a different gateway. A gateway
- SHOULD reject a reused ticket. Note however that a gateway can elect
- not to retain a list of already-used tickets. Potential replay
- attacks on such gateways are mitigated by the cookie mechanism
- described in Section 4.2.2.
-
- This document specifies a new IKEv2 exchange type called
- IKE_SESSION_RESUME whose value is TBA by IANA. This exchange is
- somewhat similar to the IKE_AUTH exchange, and results in the
- creation of a Child SA. The client SHOULD NOT use this exchange type
- unless it knows that the gateway supports it, either through
- configuration, by out-of-band means or by using the Gateway List
- provision.
-
-
-
- Initiator Responder
- ----------- -----------
- HDR, Ni, N(TICKET_OPAQUE), [N+,]
- SK {IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->
-
- The exchange type in HDR is set to 'IKE_SESSION_RESUME'.
-
- See Section 4.2.1 for details on computing the protected (SK)
- payload.
-
- When the IKEv2 responder receives a ticket using the N(TICKET_OPAQUE)
- payload it MUST perform one of the following steps if it supports the
- extension defined in this document:
- o If it is willing to accept the ticket, it responds as shown in
- Figure 5.
- o It responds with an unprotected N(TICKET_NACK) notification, if it
- rejects the ticket for any reason. In that case, the initiator
- should re-initiate a regular IKE exchange. One such case is when
- the responder receives a ticket for an IKE SA that has previously
- been terminated on the responder itself, which may indicate
- inconsistent state between the IKEv2 initiator and the responder.
- However, a responder is not required to maintain the state for
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 11]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
- terminated sessions.
- o When the responder receives a ticket for an IKE SA that is still
- active and if the responder accepts it, then the old SAs SHOULD be
- silently deleted without sending a DELETE informational exchange.
-
-
-
- Initiator Responder
- ----------- -----------
- <-- HDR, SK {IDr, Nr, SAr2, [TSi, TSr],
- [CP(CFG_REPLY)]}
-
- Figure 5: IKEv2 Responder accepts the ticket
-
- Again, the exchange type in HDR is set to 'IKE_SESSION_RESUME'.
-
- The SK payload is protected using the cryptographic parameters
- derived from the ticket, see Section 4.2.1 below.
-
- At this point a new IKE SA is created by both parties, see
- Section 4.6. This is followed by normal derivation of a child SA,
- per Sec. 2.17 of [RFC4306].
-
-4.2.1. Protection of the IKE_SESSION_RESUME Exchange
-
- The two messages of this exchange are protected by a "subset" IKE SA.
- The key material is derived from the ticket, as follows:
-
-
- {SK_d2 | SK_ai | SK_ar | SK_ei | SK_er} = prf+(SK_d_old, Ni)
-
- where SK_d_old is the SK_d value of the original IKE SA, as retrieved
- from the ticket. Ni guarantees freshness of the key material. SK_d2
- is used later to derive the new IKE SA, see Section 4.6.
-
- See [RFC4306] for the notation. "prf" is determined from the SA value
- in the ticket.
-
-4.2.2. Presenting a Ticket: The DoS Case
-
- When receiving the first message of the IKE_SESSION_RESUME exchange,
- the gateway may decide that it is under a denial-of-service attack.
- In such a case, the gateway SHOULD defer the establishment of session
- state until it has verified the identity of the client. We use a
- variation of the IKEv2 Cookie mechanism, where the cookie is
- protected.
-
- In the two messages that follow, the gateway responds that it is
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 12]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
- unwilling to resume the session until the client is verified, and the
- client resubmits its first message, this time with the cookie:
-
-
-
- Initiator Responder
- ----------- -----------
- <-- HDR, SK{N(COOKIE)}
-HDR, Ni, N(TICKET_OPAQUE), [N+,]
- SK {N(COOKIE), IDi, [IDr,] SAi2, TSi, TSr [, CP(CFG_REQUEST)]} -->
-
- Assuming the cookie is correct, the gateway now replies normally.
-
- This now becomes a 4-message exchange. The entire exchange is
- protected as defined in Section 4.2.1.
-
- See Sec. 2.6 and Sec. 3.10.1 of [RFC4306] for more guidance regarding
- the usage and syntax of the cookie. Note that the cookie is
- completely independent of the IKEv2 ticket.
-
-4.2.3. Requesting a ticket during resumption
-
- When resuming a session, a client will typically request a new ticket
- immediately, so it is able to resume the session again in the case of
- a second failure. Therefore, the N(TICKET_REQUEST), N(TICKET_OPAQUE)
- and N(TICKET_GATEWAY_LIST) notifications may be piggybacked as
- protected payloads to the IKE_SESSION_RESUME exchange.
-
- The returned ticket (if any) will correspond to the IKE SA created
- per the rules described in Section 4.6.
-
-4.3. IKE Notifications
-
- This document defines a number of notifications. The notification
- numbers are TBA by IANA.
-
- +---------------------+--------+-----------------+
- | Notification Name | Number | Data |
- +---------------------+--------+-----------------+
- | TICKET_OPAQUE | TBA1 | See Section 4.4 |
- | TICKET_REQUEST | TBA2 | None |
- | TICKET_ACK | TBA3 | None |
- | TICKET_NACK | TBA4 | None |
- | TICKET_GATEWAY_LIST | TBA5 | See Section 4.5 |
- +---------------------+--------+-----------------+
-
-
-
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 13]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
-4.4. TICKET_OPAQUE Notify Payload
-
- The data for the TICKET_OPAQUE Notify payload consists of the Notify
- message header, a lifetime field and the ticket itself. The four
- octet lifetime field contains the number of seconds until the ticket
- expires as an unsigned integer. Section 5.2 describes a possible
- ticket format, and Section 5.3 offers further guidelines regarding
- the ticket's lifetime.
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Next Payload !C! Reserved ! Payload Length !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Protocol ID ! SPI Size = 0 ! Notify Message Type !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Lifetime !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ Ticket ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Figure 6: TICKET_OPAQUE Notify Payload
-
-4.5. TICKET_GATEWAY_LIST Notify Payload
-
- The TICKET_GATEWAY_LIST Notify payload contains the Notify payload
- header followed by a sequence of one or more gateway identifiers,
- each of the format depicted in Figure 8.
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Next Payload !C! Reserved ! Payload Length !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Protocol ID ! SPI Size = 0 ! Notify Message Type !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ Gateway Identifier List ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Figure 7: TICKET_GATEWAY_LIST Notify Payload
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 14]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! ID Type ! Reserved ! Length !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ Identification Data ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Figure 8: Gateway Identifier for One Gateway
-
- ID Type:
-
- The ID Type contains a restricted set of the IKEv2 ID payloads
- (see [RFC4306], Section 3.5). Allowed ID types are: ID_IPV4_ADDR,
- ID_IPV6_ADDR, ID_FQDN and the various reserved values.
-
- Reserved:
-
- This field must be sent as 0 and must be ignored when received.
-
- Length:
-
- The length field indicates the total size of the Identification
- data.
-
- Identification Data:
-
- The Identification Data field is of variable length and depends on
- the ID type. The length is not necessarily a multiple of 4.
-
-4.6. Processing Guidelines for IKE SA Establishment
-
- When a ticket is presented, the gateway parses the ticket to retrieve
- the state of the old IKE SA, and the client retrieves this state from
- its local store. Both peers now create state for the new IKE SA as
- follows:
-
- o The SA value (transforms etc.) is taken directly from the ticket.
- o The sequence numbers are reset to 0.
- o The IDi value is obtained from the ticket.
- o The IDr value is obtained from the new exchange. The gateway MAY
- make policy decisions based on the IDr value encoded in the
- ticket.
-
-
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 15]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
- o The SPI values are created anew, similarly to a regular IKE
- exchange. SPI values from the ticket SHOULD NOT be reused. This
- restriction is to avoid problems caused by collisions with other
- SPI values used already by the initiator/responder. The SPI value
- should only be reused if collision avoidance can be ensured
- through other means.
-
- The cryptographic material is refreshed based on the ticket and the
- nonce values, Ni, and Nr, from the current exchange. A new SKEYSEED
- value is derived as follows:
-
-
- SKEYSEED = prf(SK_d2, Ni | Nr)
-
- where SK_d2 was computed earlier (Section 4.2.1).
-
- The keys are derived as follows, unchanged from IKEv2:
-
-
- {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} =
- prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)
-
- where SPIi, SPIr are the SPI values created in the new IKE exchange.
-
- See [RFC4306] for the notation. "prf" is determined from the SA value
- in the ticket.
-
-
-5. The IKE Ticket
-
- This section lists the required contents of the ticket, and
- recommends a non-normative format. This is followed by a discussion
- of the ticket's lifecycle.
-
-5.1. Ticket Contents
-
- The ticket MUST encode at least the following state from an IKE SA.
- These values MUST be encrypted and authenticated.
-
- o IDi, IDr.
- o SPIi, SPIr.
- o SAr (the accepted proposal).
- o SK_d.
-
- In addition, the ticket MUST encode a protected ticket expiration
- value.
-
-
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 16]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
-5.2. Ticket Format
-
- This document does not specify a mandatory-to-implement or a
- mandatory-to-use ticket format. The following format is RECOMMENDED,
- if interoperability between gateways is desired.
-
-
- struct {
- [authenticated] struct {
- octet format_version; // 1 for this version of the protocol
- octet reserved[3]; // sent as 0, ignored by receiver.
- octet key_id[8]; // arbitrary byte string
- opaque IV[0..255]; // actual length (possibly 0) depends
- // on the encryption algorithm
-
- [encrypted] struct {
- opaque IDi, IDr; // the full payloads
- octet SPIi[8], SPIr[8];
- opaque SA; // the full SAr payload
- octet SK_d[0..255]; // actual length depends on SA value
- int32 expiration; // an absolute time value, seconds
- // since Jan. 1, 1970
- } ikev2_state;
- } protected_part;
- opaque MAC[0..255]; // the length (possibly 0) depends
- // on the integrity algorithm
- } ticket;
-
- Note that the key defined by "key_id" determines the encryption and
- authentication algorithms used for this ticket. Those algorithms are
- unrelated to the transforms defined by the SA payload.
-
- The reader is referred to a recent draft
- [I-D.rescorla-stateless-tokens] that recommends a similar (but not
- identical) ticket format, and discusses related security
- considerations in depth.
-
-5.3. Ticket Identity and Lifecycle
-
- Each ticket is associated with a single IKE SA. In particular, when
- an IKE SA is deleted, the client MUST delete its stored ticket.
-
- A ticket is therefore associated with the tuple (IDi, IDr). The
- client MAY however use a ticket to approach other gateways that are
- willing to accept it. How a client discovers such gateways is
- outside the scope of this document.
-
- The lifetime of the ticket carried in the N(TICKET_OPAQUE)
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 17]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
- notification should be the minimum of the IKE SA lifetime (per the
- gateway's local policy) and its re-authentication time, according to
- [RFC4478]. Even if neither of these are enforced by the gateway, a
- finite lifetime MUST be specified for the ticket.
-
-5.4. Exchange of Ticket-Protecting Keys
-
- This document does not define an interoperable mechanism for the
- generation and distribution of the keys that protect IKE keys. Such
- a mechanism can be developed, based on the GDOI group key exchange
- protocol [RFC3547]. There is on-going work to enable the generation
- of non-IPsec keys by means of GDOI, e.g. to provide RSVP router
- groups with a single key [I-D.weis-gdoi-for-rsvp]. This work can be
- generalized for our purposes. We note that there are no significant
- performance requirements on such a protocol, as key rollover can be
- at a daily or even more leisurely rate.
-
-
-6. IANA Considerations
-
- This document requires a number of IKEv2 notification status types in
- Section 4.3, to be registered by IANA. The corresponding registry
- was established by IANA.
-
- The document defines a new IKEv2 exchange in Section 4.2. The
- corresponding registry was established by IANA.
-
-
-7. Security Considerations
-
- This section addresses security issues related to the usage of a
- ticket.
-
-7.1. Stolen Tickets
-
- An eavesdropper or man-in-the-middle may try to obtain a ticket and
- use it to establish a session with the IKEv2 responder. This can
- happen in different ways: by eavesdropping on the initial
- communication and copying the ticket when it is granted and before it
- is used, or by listening in on a client's use of the ticket to resume
- a session. However, since the ticket's contents is encrypted and the
- attacker does not know the corresponding secret key (specifically,
- SK_d), a stolen ticket cannot be used by an attacker to resume a
- session. An IKEv2 responder MUST use strong encryption and integrity
- protection of the ticket to prevent an attacker from obtaining the
- ticket's contents, e.g., by using a brute force attack.
-
-
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 18]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
-7.2. Forged Tickets
-
- A malicious user could forge or alter a ticket in order to resume a
- session, to extend its lifetime, to impersonate as another user, or
- to gain additional privileges. This attack is not possible if the
- ticket is protected using a strong integrity protection algorithm.
-
-7.3. Denial of Service Attacks
-
- The key_id field defined in the recommended ticket format helps the
- server efficiently reject tickets that it did not issue. However, an
- adversary could generate and send a large number of tickets to a
- gateway for verification. To minimize the possibility of such denial
- of service, ticket verification should be lightweight (e.g., using
- efficient symmetric key cryptographic algorithms).
-
-7.4. Ticket Protection Key Management
-
- A full description of the management of the keys used to protect the
- ticket is beyond the scope of this document. A list of RECOMMENDED
- practices is given below.
- o The keys should be generated securely following the randomness
- recommendations in [RFC4086].
- o The keys and cryptographic protection algorithms should be at
- least 128 bits in strength.
- o The keys should not be used for any other purpose than generating
- and verifying tickets.
- o The keys should be changed regularly.
- o The keys should be changed if the ticket format or cryptographic
- protection algorithms change.
-
-7.5. Ticket Lifetime
-
- An IKEv2 responder controls the lifetime of a ticket, based on the
- operational and security requirements of the environment in which it
- is deployed. The responder provides information about the ticket
- lifetime to the IKEv2 initiator, allowing it to manage its tickets.
-
- An IKEv2 client may present a ticket in its possession to a gateway,
- even if the IKE SA associated with this ticket had previously been
- terminated by another gateway (the gateway that originally provided
- the ticket). Where such usage is against the local security policy,
- an Invalid Ticket List (ITL) may be used, see
- [I-D.rescorla-stateless-tokens]. Management of such lists is outside
- the scope of the current document. Note that a policy that requires
- tickets to have shorter lifetimes (e.g., 1 hour) significantly
- mitigates this risk.
-
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 19]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
-7.6. Alternate Ticket Formats and Distribution Schemes
-
- If the ticket format or distribution scheme defined in this document
- is not used, then great care must be taken in analyzing the security
- of the solution. In particular, if confidential information, such as
- a secret key, is transferred to the client, it MUST be done using
- secure communication to prevent attackers from obtaining or modifying
- the key. Also, the ticket MUST have its integrity and
- confidentiality protected with strong cryptographic techniques to
- prevent a breach in the security of the system.
-
-7.7. Identity Privacy, Anonymity, and Unlinkability
-
- This document mandates that the content of the ticket MUST be
- encrypted in order to avoid leakage of information, such as the
- identities of an IKEv2 initiator and a responder. Thus, it prevents
- the disclosure of potentially sensitive information carried within
- the ticket.
-
- When an IKEv2 initiator presents the ticket as part of the
- IKE_SESSION_RESUME exchange, confidentiality is not provided for the
- exchange. Although the ticket itself is encrypted there might still
- be a possibility for an on-path adversary to observe multiple
- exchange handshakes where the same ticket is used and therefore to
- conclude that they belong to the same communication end points.
- Administrators that use the ticket mechanism described in this
- document should be aware that unlinkability may not be provided by
- this mechanism. Note, however, that IKEv2 does not provide active
- user identity confidentiality for the IKEv2 initiator either.
-
-7.8. Replay Protection in the IKE_SESSION_RESUME Exchange
-
- A major design goal of this protocol extension has been the two-
- message exchange for session resumption. There is a tradeoff between
- this abbreviated exchange and replay protection. It is RECOMMENDED
- that the gateway should cache tickets, and reject replayed ones.
- However some gateways may not do that in order to reduce state size.
- In addition, an adversary may replay a ticket last presented to
- gateway A, into gateway B. Our cookie-based mechanism (Section 4.2.2)
- mitigates both scenarios by ensuring that the client presenting the
- ticket is indeed its "owner": the client can be required by the
- gateway to prove that it knows the ticket's secret, before any state
- is committed on the gateway. Note that this is a stronger guarantee
- than the regular IKE cookie mechanism, which only proves IP return
- routability of the client. This is enabled by including the cookie
- in the protected portion of the message.
-
- For performance reasons, the cookie mechanism is optional, and
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 20]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
- invoked by the gateway only when it suspects that it is the subject
- of a denial-of-service attack.
-
- In any case, a ticket replayed by an adversary only causes partial
- IKE state to be created on the gateway. The IKE exchange cannot be
- completed and an IKE SA cannot be created unless the client knows the
- ticket's secret values.
-
-
-8. Acknowledgements
-
- We would like to thank Paul Hoffman, Pasi Eronen, Florian Tegeler,
- Yoav Nir and Tero Kivinen for their many helpful comments.
-
-
-9. References
-
-9.1. Normative References
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
- RFC 4306, December 2005.
-
-9.2. Informative References
-
- [I-D.friedman-ike-short-term-certs]
- Friedman, A., "Short-Term Certificates",
- draft-friedman-ike-short-term-certs-02 (work in progress),
- June 2007.
-
- [I-D.rescorla-stateless-tokens]
- Rescorla, E., "How to Implement Secure (Mostly) Stateless
- Tokens", draft-rescorla-stateless-tokens-01 (work in
- progress), March 2007.
-
- [I-D.vidya-ipsec-failover-ps]
- Narayanan, V., "IPsec Gateway Failover and Redundancy -
- Problem Statement and Goals",
- draft-vidya-ipsec-failover-ps-02 (work in progress),
- December 2007.
-
- [I-D.weis-gdoi-for-rsvp]
- Weis, B., "Group Domain of Interpretation (GDOI) support
- for RSVP", draft-weis-gdoi-for-rsvp-01 (work in progress),
- February 2008.
-
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 21]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
- [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
- Group Domain of Interpretation", RFC 3547, July 2003.
-
- [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
- Requirements for Security", BCP 106, RFC 4086, June 2005.
-
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
- Internet Protocol", RFC 4301, December 2005.
-
- [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange
- (IKEv2) Protocol", RFC 4478, April 2006.
-
- [RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
- "Transport Layer Security (TLS) Session Resumption without
- Server-Side State", RFC 4507, May 2006.
-
- [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
- (MOBIKE)", RFC 4555, June 2006.
-
- [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
- Implementation Guidelines", RFC 4718, October 2006.
-
-
-Appendix A. Related Work
-
- [I-D.friedman-ike-short-term-certs] is on-going work that discusses
- the use of short-term certificates for client re-authentication. It
- is similar to the ticket approach described in this document in that
- they both require enhancements to IKEv2 to allow information request,
- e.g., for a certificate or a ticket. However, the changes required
- by the former are fewer since an obtained certificate is valid for
- any IKE responder that is able to verify them. On the other hand,
- short-term certificates, while eliminating the usability issues of
- user re-authentication, do not reduce the amount of effort performed
- by the gateway in failover situations.
-
-
-Appendix B. Change Log
-
-B.1. -03
-
- Removed counter mechanism. Added an optional anti-DoS mechanism,
- based on IKEv2 cookies (removed previous discussion of cookies).
- Clarified that gateways may support reallocation of same IP address,
- if provided by network. Proposed a solution outline to the problem
- of key exchange for the keys that protect tickets. Added fields to
- the ticket to enable interoperability. Removed incorrect MOBIKE
- notification.
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 22]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
-B.2. -02
-
- Clarifications on generation of SPI values, on the ticket's lifetime
- and on the integrity protection of the anti-replay counter.
- Eliminated redundant SPIs from the notification payloads.
-
-B.3. -01
-
- Editorial review. Removed 24-hour limitation on ticket lifetime,
- lifetime is up to local policy.
-
-B.4. -00
-
- Initial version. This draft is a selective merge of
- draft-sheffer-ike-session-resumption-00 and
- draft-dondeti-ipsec-failover-sol-00.
-
-
-Authors' Addresses
-
- Yaron Sheffer
- Check Point Software Technologies Ltd.
- 5 Hasolelim St.
- Tel Aviv 67897
- Israel
-
- Email: yaronf@checkpoint.com
-
-
- Hannes Tschofenig
- Nokia Siemens Networks
- Otto-Hahn-Ring 6
- Munich, Bavaria 81739
- Germany
-
- Email: Hannes.Tschofenig@nsn.com
- URI: http://www.tschofenig.priv.at
-
-
- Lakshminath Dondeti
- QUALCOMM, Inc.
- 5775 Morehouse Dr
- San Diego, CA
- USA
-
- Phone: +1 858-845-1267
- Email: ldondeti@qualcomm.com
-
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 23]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 2008
-
-
- Vidya Narayanan
- QUALCOMM, Inc.
- 5775 Morehouse Dr
- San Diego, CA
- USA
-
- Phone: +1 858-845-2483
- Email: vidyan@qualcomm.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Sheffer, et al. Expires September 20, 2008 [Page 24]
-\f
-Internet-Draft IPsec Gateway Failover Protocol March 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, et al. Expires September 20, 2008 [Page 25]
-\f
-
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-
+++ /dev/null
-
-
-
-
-
-
-Network Working Group C. Rigney
-Request for Comments: 2865 S. Willens
-Obsoletes: 2138 Livingston
-Category: Standards Track A. Rubens
- Merit
- W. Simpson
- Daydreamer
- June 2000
-
-
- Remote Authentication Dial In User Service (RADIUS)
-
-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 (2000). All Rights Reserved.
-
-IESG Note:
-
- This protocol is widely implemented and used. Experience has shown
- that it can suffer degraded performance and lost data when used in
- large scale systems, in part because it does not include provisions
- for congestion control. Readers of this document may find it
- beneficial to track the progress of the IETF's AAA working group,
- which may develop a successor protocol that better addresses the
- scaling and congestion control issues.
-
-Abstract
-
- This document describes a protocol for carrying authentication,
- authorization, and configuration information between a Network Access
- Server which desires to authenticate its links and a shared
- Authentication Server.
-
-Implementation Note
-
- This memo documents the RADIUS protocol. The early deployment of
- RADIUS was done using UDP port number 1645, which conflicts with the
- "datametrics" service. The officially assigned port number for
- RADIUS is 1812.
-
-
-
-
-Rigney, et al. Standards Track [Page 1]
-\f
-RFC 2865 RADIUS June 2000
-
-
-Table of Contents
-
- 1. Introduction .......................................... 3
- 1.1 Specification of Requirements ................... 4
- 1.2 Terminology ..................................... 5
- 2. Operation ............................................. 5
- 2.1 Challenge/Response .............................. 7
- 2.2 Interoperation with PAP and CHAP ................ 8
- 2.3 Proxy ........................................... 8
- 2.4 Why UDP? ........................................ 11
- 2.5 Retransmission Hints ............................ 12
- 2.6 Keep-Alives Considered Harmful .................. 13
- 3. Packet Format ......................................... 13
- 4. Packet Types .......................................... 17
- 4.1 Access-Request .................................. 17
- 4.2 Access-Accept ................................... 18
- 4.3 Access-Reject ................................... 20
- 4.4 Access-Challenge ................................ 21
- 5. Attributes ............................................ 22
- 5.1 User-Name ....................................... 26
- 5.2 User-Password ................................... 27
- 5.3 CHAP-Password ................................... 28
- 5.4 NAS-IP-Address .................................. 29
- 5.5 NAS-Port ........................................ 30
- 5.6 Service-Type .................................... 31
- 5.7 Framed-Protocol ................................. 33
- 5.8 Framed-IP-Address ............................... 34
- 5.9 Framed-IP-Netmask ............................... 34
- 5.10 Framed-Routing .................................. 35
- 5.11 Filter-Id ....................................... 36
- 5.12 Framed-MTU ...................................... 37
- 5.13 Framed-Compression .............................. 37
- 5.14 Login-IP-Host ................................... 38
- 5.15 Login-Service ................................... 39
- 5.16 Login-TCP-Port .................................. 40
- 5.17 (unassigned) .................................... 41
- 5.18 Reply-Message ................................... 41
- 5.19 Callback-Number ................................. 42
- 5.20 Callback-Id ..................................... 42
- 5.21 (unassigned) .................................... 43
- 5.22 Framed-Route .................................... 43
- 5.23 Framed-IPX-Network .............................. 44
- 5.24 State ........................................... 45
- 5.25 Class ........................................... 46
- 5.26 Vendor-Specific ................................. 47
- 5.27 Session-Timeout ................................. 48
- 5.28 Idle-Timeout .................................... 49
- 5.29 Termination-Action .............................. 49
-
-
-
-Rigney, et al. Standards Track [Page 2]
-\f
-RFC 2865 RADIUS June 2000
-
-
- 5.30 Called-Station-Id ............................... 50
- 5.31 Calling-Station-Id .............................. 51
- 5.32 NAS-Identifier .................................. 52
- 5.33 Proxy-State ..................................... 53
- 5.34 Login-LAT-Service ............................... 54
- 5.35 Login-LAT-Node .................................. 55
- 5.36 Login-LAT-Group ................................. 56
- 5.37 Framed-AppleTalk-Link ........................... 57
- 5.38 Framed-AppleTalk-Network ........................ 58
- 5.39 Framed-AppleTalk-Zone ........................... 58
- 5.40 CHAP-Challenge .................................. 59
- 5.41 NAS-Port-Type ................................... 60
- 5.42 Port-Limit ...................................... 61
- 5.43 Login-LAT-Port .................................. 62
- 5.44 Table of Attributes ............................. 63
- 6. IANA Considerations ................................... 64
- 6.1 Definition of Terms ............................. 64
- 6.2 Recommended Registration Policies ............... 65
- 7. Examples .............................................. 66
- 7.1 User Telnet to Specified Host ................... 66
- 7.2 Framed User Authenticating with CHAP ............ 67
- 7.3 User with Challenge-Response card ............... 68
- 8. Security Considerations ............................... 71
- 9. Change Log ............................................ 71
- 10. References ............................................ 73
- 11. Acknowledgements ...................................... 74
- 12. Chair's Address ....................................... 74
- 13. Authors' Addresses .................................... 75
- 14. Full Copyright Statement .............................. 76
-
-1. Introduction
-
- This document obsoletes RFC 2138 [1]. A summary of the changes
- between this document and RFC 2138 is available in the "Change Log"
- appendix.
-
- Managing dispersed serial line and modem pools for large numbers of
- users can create the need for significant administrative support.
- Since modem pools are by definition a link to the outside world, they
- require careful attention to security, authorization and accounting.
- This can be best achieved by managing a single "database" of users,
- which allows for authentication (verifying user name and password) as
- well as configuration information detailing the type of service to
- deliver to the user (for example, SLIP, PPP, telnet, rlogin).
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 3]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Key features of RADIUS are:
-
- Client/Server Model
-
- A Network Access Server (NAS) operates as a client of RADIUS. The
- client is responsible for passing user information to designated
- RADIUS servers, and then acting on the response which is returned.
-
- RADIUS servers are responsible for receiving user connection
- requests, authenticating the user, and then returning all
- configuration information necessary for the client to deliver
- service to the user.
-
- A RADIUS server can act as a proxy client to other RADIUS servers
- or other kinds of authentication servers.
-
- Network Security
-
- Transactions between the client and RADIUS server are
- authenticated through the use of a shared secret, which is never
- sent over the network. In addition, any user passwords are sent
- encrypted between the client and RADIUS server, to eliminate the
- possibility that someone snooping on an unsecure network could
- determine a user's password.
-
- Flexible Authentication Mechanisms
-
- The RADIUS server can support a variety of methods to authenticate
- a user. When it is provided with the user name and original
- password given by the user, it can support PPP PAP or CHAP, UNIX
- login, and other authentication mechanisms.
-
- Extensible Protocol
-
- All transactions are comprised of variable length Attribute-
- Length-Value 3-tuples. New attribute values can be added without
- disturbing existing implementations of the protocol.
-
-1.1. Specification of Requirements
-
- 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 BCP 14 [2]. These key
- words mean the same thing whether capitalized or not.
-
- An implementation is not compliant if it fails to satisfy one or more
- of the must or must not requirements for the protocols it implements.
- An implementation that satisfies all the must, must not, should and
-
-
-
-Rigney, et al. Standards Track [Page 4]
-\f
-RFC 2865 RADIUS June 2000
-
-
- should not requirements for its protocols is said to be
- "unconditionally compliant"; one that satisfies all the must and must
- not requirements but not all the should or should not requirements
- for its protocols is said to be "conditionally compliant".
-
- A NAS that does not implement a given service MUST NOT implement the
- RADIUS attributes for that service. For example, a NAS that is
- unable to offer ARAP service MUST NOT implement the RADIUS attributes
- for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an
- unavailable service as an access-reject instead.
-
-1.2. Terminology
-
- This document frequently uses the following terms:
-
- service The NAS provides a service to the dial-in user, such as PPP
- or Telnet.
-
- session Each service provided by the NAS to a dial-in user
- constitutes a session, with the beginning of the session
- defined as the point where service is first provided and
- the end of the session defined as the point where service
- is ended. A user may have multiple sessions in parallel or
- series if the NAS supports that.
-
- 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. Operation
-
- When a client is configured to use RADIUS, any user of the client
- presents authentication information to the client. This might be
- with a customizable login prompt, where the user is expected to enter
- their username and password. Alternatively, the user might use a
- link framing protocol such as the Point-to-Point Protocol (PPP),
- which has authentication packets which carry this information.
-
- Once the client has obtained such information, it may choose to
- authenticate using RADIUS. To do so, the client creates an "Access-
- Request" containing such Attributes as the user's name, the user's
- password, the ID of the client and the Port ID which the user is
- accessing. When a password is present, it is hidden using a method
- based on the RSA Message Digest Algorithm MD5 [3].
-
-
-
-
-Rigney, et al. Standards Track [Page 5]
-\f
-RFC 2865 RADIUS June 2000
-
-
- The Access-Request is submitted to the RADIUS server via the network.
- If no response is returned within a length of time, the request is
- re-sent a number of times. The client can also forward requests to
- an alternate server or servers in the event that the primary server
- is down or unreachable. An alternate server can be used either after
- a number of tries to the primary server fail, or in a round-robin
- fashion. Retry and fallback algorithms are the topic of current
- research and are not specified in detail in this document.
-
- Once the RADIUS server receives the request, it validates the sending
- client. A request from a client for which the RADIUS server does not
- have a shared secret MUST be silently discarded. If the client is
- valid, the RADIUS server consults a database of users to find the
- user whose name matches the request. The user entry in the database
- contains a list of requirements which must be met to allow access for
- the user. This always includes verification of the password, but can
- also specify the client(s) or port(s) to which the user is allowed
- access.
-
- The RADIUS server MAY make requests of other servers in order to
- satisfy the request, in which case it acts as a client.
-
- If any Proxy-State attributes were present in the Access-Request,
- they MUST be copied unmodified and in order into the response packet.
- Other Attributes can be placed before, after, or even between the
- Proxy-State attributes.
-
- If any condition is not met, the RADIUS server sends an "Access-
- Reject" response indicating that this user request is invalid. If
- desired, the server MAY include a text message in the Access-Reject
- which MAY be displayed by the client to the user. No other
- Attributes (except Proxy-State) are permitted in an Access-Reject.
-
- If all conditions are met and the RADIUS server wishes to issue a
- challenge to which the user must respond, the RADIUS server sends an
- "Access-Challenge" response. It MAY include a text message to be
- displayed by the client to the user prompting for a response to the
- challenge, and MAY include a State attribute.
-
- If the client receives an Access-Challenge and supports
- challenge/response it MAY display the text message, if any, to the
- user, and then prompt the user for a response. The client then re-
- submits its original Access-Request with a new request ID, with the
- User-Password Attribute replaced by the response (encrypted), and
- including the State Attribute from the Access-Challenge, if any.
- Only 0 or 1 instances of the State Attribute SHOULD be
-
-
-
-
-
-Rigney, et al. Standards Track [Page 6]
-\f
-RFC 2865 RADIUS June 2000
-
-
- present in a request. The server can respond to this new Access-
- Request with either an Access-Accept, an Access-Reject, or another
- Access-Challenge.
-
- If all conditions are met, the list of configuration values for the
- user are placed into an "Access-Accept" response. These values
- include the type of service (for example: SLIP, PPP, Login User) and
- all necessary values to deliver the desired service. For SLIP and
- PPP, this may include values such as IP address, subnet mask, MTU,
- desired compression, and desired packet filter identifiers. For
- character mode users, this may include values such as desired
- protocol and host.
-
-2.1. Challenge/Response
-
- In challenge/response authentication, the user is given an
- unpredictable number and challenged to encrypt it and give back the
- result. Authorized users are equipped with special devices such as
- smart cards or software that facilitate calculation of the correct
- response with ease. Unauthorized users, lacking the appropriate
- device or software and lacking knowledge of the secret key necessary
- to emulate such a device or software, can only guess at the response.
-
- The Access-Challenge packet typically contains a Reply-Message
- including a challenge to be displayed to the user, such as a numeric
- value unlikely ever to be repeated. Typically this is obtained from
- an external server that knows what type of authenticator is in the
- possession of the authorized user and can therefore choose a random
- or non-repeating pseudorandom number of an appropriate radix and
- length.
-
- The user then enters the challenge into his device (or software) and
- it calculates a response, which the user enters into the client which
- forwards it to the RADIUS server via a second Access-Request. If the
- response matches the expected response the RADIUS server replies with
- an Access-Accept, otherwise an Access-Reject.
-
- Example: The NAS sends an Access-Request packet to the RADIUS Server
- with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
- just be a fixed string like "challenge" or ignored). The server
- sends back an Access-Challenge packet with State and a Reply-Message
- along the lines of "Challenge 12345678, enter your response at the
- prompt" which the NAS displays. The NAS prompts for the response and
- sends a NEW Access-Request to the server (with a new ID) with NAS-
- Identifier, NAS-Port, User-Name, User-Password (the response just
- entered by the user, encrypted), and the same State Attribute that
-
-
-
-
-
-Rigney, et al. Standards Track [Page 7]
-\f
-RFC 2865 RADIUS June 2000
-
-
- came with the Access-Challenge. The server then sends back either an
- Access-Accept or Access-Reject based on whether the response matches
- the required value, or it can even send another Access-Challenge.
-
-2.2. Interoperation with PAP and CHAP
-
- For PAP, the NAS takes the PAP ID and password and sends them in an
- Access-Request packet as the User-Name and User-Password. The NAS MAY
- include the Attributes Service-Type = Framed-User and Framed-Protocol
- = PPP as a hint to the RADIUS server that PPP service is expected.
-
- For CHAP, the NAS generates a random challenge (preferably 16 octets)
- and sends it to the user, who returns a CHAP response along with a
- CHAP ID and CHAP username. The NAS then sends an Access-Request
- packet to the RADIUS server with the CHAP username as the User-Name
- and with the CHAP ID and CHAP response as the CHAP-Password
- (Attribute 3). The random challenge can either be included in the
- CHAP-Challenge attribute or, if it is 16 octets long, it can be
- placed in the Request Authenticator field of the Access-Request
- packet. The NAS MAY include the Attributes Service-Type = Framed-
- User and Framed-Protocol = PPP as a hint to the RADIUS server that
- PPP service is expected.
-
- The RADIUS server looks up a password based on the User-Name,
- encrypts the challenge using MD5 on the CHAP ID octet, that password,
- and the CHAP challenge (from the CHAP-Challenge attribute if present,
- otherwise from the Request Authenticator), and compares that result
- to the CHAP-Password. If they match, the server sends back an
- Access-Accept, otherwise it sends back an Access-Reject.
-
- If the RADIUS server is unable to perform the requested
- authentication it MUST return an Access-Reject. For example, CHAP
- requires that the user's password be available in cleartext to the
- server so that it can encrypt the CHAP challenge and compare that to
- the CHAP response. If the password is not available in cleartext to
- the RADIUS server then the server MUST send an Access-Reject to the
- client.
-
-2.3. Proxy
-
- With proxy RADIUS, one RADIUS server receives an authentication (or
- accounting) request from a RADIUS client (such as a NAS), forwards
- the request to a remote RADIUS server, receives the reply from the
- remote server, and sends that reply to the client, possibly with
- changes to reflect local administrative policy. A common use for
- proxy RADIUS is roaming. Roaming permits two or more administrative
- entities to allow each other's users to dial in to either entity's
- network for service.
-
-
-
-Rigney, et al. Standards Track [Page 8]
-\f
-RFC 2865 RADIUS June 2000
-
-
- The NAS sends its RADIUS access-request to the "forwarding server"
- which forwards it to the "remote server". The remote server sends a
- response (Access-Accept, Access-Reject, or Access-Challenge) back to
- the forwarding server, which sends it back to the NAS. The User-Name
- attribute MAY contain a Network Access Identifier [8] for RADIUS
- Proxy operations. The choice of which server receives the forwarded
- request SHOULD be based on the authentication "realm". The
- authentication realm MAY be the realm part of a Network Access
- Identifier (a "named realm"). Alternatively, the choice of which
- server receives the forwarded request MAY be based on whatever other
- criteria the forwarding server is configured to use, such as Called-
- Station-Id (a "numbered realm").
-
- A RADIUS server can function as both a forwarding server and a remote
- server, serving as a forwarding server for some realms and a remote
- server for other realms. One forwarding server can act as a
- forwarder for any number of remote servers. A remote server can have
- any number of servers forwarding to it and can provide authentication
- for any number of realms. One forwarding server can forward to
- another forwarding server to create a chain of proxies, although care
- must be taken to avoid introducing loops.
-
- The following scenario illustrates a proxy RADIUS communication
- between a NAS and the forwarding and remote RADIUS servers:
-
- 1. A NAS sends its access-request to the forwarding server.
-
- 2. The forwarding server forwards the access-request to the remote
- server.
-
- 3. The remote server sends an access-accept, access-reject or
- access-challenge back to the forwarding server. For this example,
- an access-accept is sent.
-
- 4. The forwarding server sends the access-accept to the NAS.
-
- The forwarding server MUST treat any Proxy-State attributes already
- in the packet as opaque data. Its operation MUST NOT depend on the
- content of Proxy-State attributes added by previous servers.
-
- If there are any Proxy-State attributes in the request received from
- the client, the forwarding server MUST include those Proxy-State
- attributes in its reply to the client. The forwarding server MAY
- include the Proxy-State attributes in the access-request when it
- forwards the request, or MAY omit them in the forwarded request. If
- the forwarding server omits the Proxy-State attributes in the
- forwarded access-request, it MUST attach them to the response before
- sending it to the client.
-
-
-
-Rigney, et al. Standards Track [Page 9]
-\f
-RFC 2865 RADIUS June 2000
-
-
- We now examine each step in more detail.
-
- 1. A NAS sends its access-request to the forwarding server. The
- forwarding server decrypts the User-Password, if present, using
- the shared secret it knows for the NAS. If a CHAP-Password
- attribute is present in the packet and no CHAP-Challenge attribute
- is present, the forwarding server MUST leave the Request-
- Authenticator untouched or copy it to a CHAP-Challenge attribute.
-
- '' The forwarding server MAY add one Proxy-State attribute to the
- packet. (It MUST NOT add more than one.) If it adds a Proxy-
- State, the Proxy-State MUST appear after any other Proxy-States in
- the packet. The forwarding server MUST NOT modify any other
- Proxy-States that were in the packet (it may choose not to forward
- them, but it MUST NOT change their contents). The forwarding
- server MUST NOT change the order of any attributes of the same
- type, including Proxy-State.
-
- 2. The forwarding server encrypts the User-Password, if present,
- using the secret it shares with the remote server, sets the
- Identifier as needed, and forwards the access-request to the
- remote server.
-
- 3. The remote server (if the final destination) verifies the user
- using User-Password, CHAP-Password, or such method as future
- extensions may dictate, and returns an access-accept, access-
- reject or access-challenge back to the forwarding server. For
- this example, an access-accept is sent. The remote server MUST
- copy all Proxy-State attributes (and only the Proxy-State
- attributes) in order from the access-request to the response
- packet, without modifying them.
-
- 4. The forwarding server verifies the Response Authenticator using
- the secret it shares with the remote server, and silently discards
- the packet if it fails verification. If the packet passes
- verification, the forwarding server removes the last Proxy-State
- (if it attached one), signs the Response Authenticator using the
- secret it shares with the NAS, restores the Identifier to match
- the one in the original request by the NAS, and sends the access-
- accept to the NAS.
-
- A forwarding server MAY need to modify attributes to enforce local
- policy. Such policy is outside the scope of this document, with the
- following restrictions. A forwarding server MUST not modify existing
- Proxy-State, State, or Class attributes present in the packet.
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 10]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Implementers of forwarding servers should consider carefully which
- values it is willing to accept for Service-Type. Careful
- consideration must be given to the effects of passing along Service-
- Types of NAS-Prompt or Administrative in a proxied Access-Accept, and
- implementers may wish to provide mechanisms to block those or other
- service types, or other attributes. Such mechanisms are outside the
- scope of this document.
-
-2.4. Why UDP?
-
- A frequently asked question is why RADIUS uses UDP instead of TCP as
- a transport protocol. UDP was chosen for strictly technical reasons.
-
- There are a number of issues which must be understood. RADIUS is a
- transaction based protocol which has several interesting
- characteristics:
-
- 1. If the request to a primary Authentication server fails, a
- secondary server must be queried.
-
- To meet this requirement, a copy of the request must be kept above
- the transport layer to allow for alternate transmission. This
- means that retransmission timers are still required.
-
- 2. The timing requirements of this particular protocol are
- significantly different than TCP provides.
-
- At one extreme, RADIUS does not require a "responsive" detection
- of lost data. The user is willing to wait several seconds for the
- authentication to complete. The generally aggressive TCP
- retransmission (based on average round trip time) is not required,
- nor is the acknowledgement overhead of TCP.
-
- At the other extreme, the user is not willing to wait several
- minutes for authentication. Therefore the reliable delivery of
- TCP data two minutes later is not useful. The faster use of an
- alternate server allows the user to gain access before giving up.
-
- 3. The stateless nature of this protocol simplifies the use of UDP.
-
- Clients and servers come and go. Systems are rebooted, or are
- power cycled independently. Generally this does not cause a
- problem and with creative timeouts and detection of lost TCP
- connections, code can be written to handle anomalous events. UDP
- however completely eliminates any of this special handling. Each
- client and server can open their UDP transport just once and leave
- it open through all types of failure events on the network.
-
-
-
-
-Rigney, et al. Standards Track [Page 11]
-\f
-RFC 2865 RADIUS June 2000
-
-
- 4. UDP simplifies the server implementation.
-
- In the earliest implementations of RADIUS, the server was single
- threaded. This means that a single request was received,
- processed, and returned. This was found to be unmanageable in
- environments where the back-end security mechanism took real time
- (1 or more seconds). The server request queue would fill and in
- environments where hundreds of people were being authenticated
- every minute, the request turn-around time increased to longer
- than users were willing to wait (this was especially severe when a
- specific lookup in a database or over DNS took 30 or more
- seconds). The obvious solution was to make the server multi-
- threaded. Achieving this was simple with UDP. Separate processes
- were spawned to serve each request and these processes could
- respond directly to the client NAS with a simple UDP packet to the
- original transport of the client.
-
- It's not all a panacea. As noted, using UDP requires one thing which
- is built into TCP: with UDP we must artificially manage
- retransmission timers to the same server, although they don't require
- the same attention to timing provided by TCP. This one penalty is a
- small price to pay for the advantages of UDP in this protocol.
-
- Without TCP we would still probably be using tin cans connected by
- string. But for this particular protocol, UDP is a better choice.
-
-2.5. Retransmission Hints
-
- If the RADIUS server and alternate RADIUS server share the same
- shared secret, it is OK to retransmit the packet to the alternate
- RADIUS server with the same ID and Request Authenticator, because the
- content of the attributes haven't changed. If you want to use a new
- Request Authenticator when sending to the alternate server, you may.
-
- If you change the contents of the User-Password attribute (or any
- other attribute), you need a new Request Authenticator and therefore
- a new ID.
-
- If the NAS is retransmitting a RADIUS request to the same server as
- before, and the attributes haven't changed, you MUST use the same
- Request Authenticator, ID, and source port. If any attributes have
- changed, you MUST use a new Request Authenticator and ID.
-
- A NAS MAY use the same ID across all servers, or MAY keep track of
- IDs separately for each server, it is up to the implementer. If a
- NAS needs more than 256 IDs for outstanding requests, it MAY use
-
-
-
-
-
-Rigney, et al. Standards Track [Page 12]
-\f
-RFC 2865 RADIUS June 2000
-
-
- additional source ports to send requests from, and keep track of IDs
- for each source port. This allows up to 16 million or so outstanding
- requests at one time to a single server.
-
-2.6. Keep-Alives Considered Harmful
-
- Some implementers have adopted the practice of sending test RADIUS
- requests to see if a server is alive. This practice is strongly
- discouraged, since it adds to load and harms scalability without
- providing any additional useful information. Since a RADIUS request
- is contained in a single datagram, in the time it would take you to
- send a ping you could just send the RADIUS request, and getting a
- reply tells you that the RADIUS server is up. If you do not have a
- RADIUS request to send, it does not matter if the server is up or
- not, because you are not using it.
-
- If you want to monitor your RADIUS server, use SNMP. That's what
- SNMP is for.
-
-3. Packet Format
-
- Exactly one RADIUS packet is encapsulated in the UDP Data field [4],
- where the UDP Destination Port field indicates 1812 (decimal).
-
- When a reply is generated, the source and destination ports are
- reversed.
-
- This memo documents the RADIUS protocol. The early deployment of
- RADIUS was done using UDP port number 1645, which conflicts with the
- "datametrics" service. The officially assigned port number for
- RADIUS is 1812.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 13]
-\f
-RFC 2865 RADIUS June 2000
-
-
- A summary of the RADIUS data format is shown below. The fields are
- transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Code
-
- The Code field is one octet, and identifies the type of RADIUS
- packet. When a packet is received with an invalid Code field, it
- is silently discarded.
-
- RADIUS Codes (decimal) are assigned as follows:
-
- 1 Access-Request
- 2 Access-Accept
- 3 Access-Reject
- 4 Accounting-Request
- 5 Accounting-Response
- 11 Access-Challenge
- 12 Status-Server (experimental)
- 13 Status-Client (experimental)
- 255 Reserved
-
- Codes 4 and 5 are covered in the RADIUS Accounting document [5].
- Codes 12 and 13 are reserved for possible use, but are not further
- mentioned here.
-
- Identifier
-
- The Identifier field is one octet, and aids in matching requests
- and replies. The RADIUS server can detect a duplicate request if
- it has the same client source IP address and source UDP port and
- Identifier within a short span of time.
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 14]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Length
-
- The Length field is two octets. It indicates the length of the
- packet including the Code, Identifier, Length, Authenticator and
- Attribute fields. Octets outside the range of the Length field
- MUST be treated as padding and ignored on reception. If the
- packet is shorter than the Length field indicates, it MUST be
- silently discarded. The minimum length is 20 and maximum length
- is 4096.
-
- Authenticator
-
- The Authenticator field is sixteen (16) octets. The most
- significant octet is transmitted first. This value is used to
- authenticate the reply from the RADIUS server, and is used in the
- password hiding algorithm.
-
- Request Authenticator
-
- In Access-Request Packets, the Authenticator value is a 16
- octet random number, called the Request Authenticator. The
- value SHOULD be unpredictable and unique over the lifetime of a
- secret (the password shared between the client and the RADIUS
- server), since repetition of a request 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 Request Authenticator field
- SHOULD exhibit global and temporal uniqueness.
-
- The Request Authenticator value in an Access-Request packet
- SHOULD also be unpredictable, lest an attacker trick a server
- into responding to a predicted future request, and then use the
- response to masquerade as that server to a future Access-
- Request.
-
- Although protocols such as RADIUS are incapable of protecting
- against theft of an authenticated session via realtime active
- wiretapping attacks, generation of unique unpredictable
- requests can protect against a wide range of active attacks
- against authentication.
-
- The NAS and RADIUS server share a secret. That shared secret
- followed by the Request Authenticator is put through a one-way
- MD5 hash to create a 16 octet digest value which is xored with
- the password entered by the user, and the xored result placed
-
-
-
-
-
-Rigney, et al. Standards Track [Page 15]
-\f
-RFC 2865 RADIUS June 2000
-
-
- in the User-Password attribute in the Access-Request packet.
- See the entry for User-Password in the section on Attributes
- for a more detailed description.
-
- Response Authenticator
-
- The value of the Authenticator field in Access-Accept, Access-
- Reject, and Access-Challenge packets is called the Response
- Authenticator, and contains a one-way MD5 hash calculated over
- a stream of octets consisting of: the RADIUS packet, beginning
- with the Code field, including the Identifier, the Length, the
- Request Authenticator field from the Access-Request packet, and
- the response Attributes, followed by the shared secret. That
- is, ResponseAuth =
- MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
- denotes concatenation.
-
- Administrative Note
-
- The secret (password shared between the client and the RADIUS
- server) SHOULD be at least as large and unguessable as a well-
- chosen password. It is preferred that the secret be at least 16
- octets. This is to ensure a sufficiently large range for the
- secret to provide protection against exhaustive search attacks.
- The secret MUST NOT be empty (length 0) since this would allow
- packets to be trivially forged.
-
- A RADIUS server MUST use the source IP address of the RADIUS UDP
- packet to decide which shared secret to use, so that RADIUS
- requests can be proxied.
-
- When using a forwarding proxy, the proxy must be able to alter the
- packet as it passes through in each direction - when the proxy
- forwards the request, the proxy MAY add a Proxy-State Attribute,
- and when the proxy forwards a response, it MUST remove its Proxy-
- State Attribute if it added one. Proxy-State is always added or
- removed after any other Proxy-States, but no other assumptions
- regarding its location within the list of attributes can be made.
- Since Access-Accept and Access-Reject replies are authenticated on
- the entire packet contents, the stripping of the Proxy-State
- attribute invalidates the signature in the packet - so the proxy
- has to re-sign it.
-
- Further details of RADIUS proxy implementation are outside the
- scope of this document.
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 16]
-\f
-RFC 2865 RADIUS June 2000
-
-
-4. Packet Types
-
- The RADIUS Packet type is determined by the Code field in the first
- octet of the Packet.
-
-4.1. Access-Request
-
- Description
-
- Access-Request packets are sent to a RADIUS server, and convey
- information used to determine whether a user is allowed access to
- a specific NAS, and any special services requested for that user.
- An implementation wishing to authenticate a user MUST transmit a
- RADIUS packet with the Code field set to 1 (Access-Request).
-
- Upon receipt of an Access-Request from a valid client, an
- appropriate reply MUST be transmitted.
-
- An Access-Request SHOULD contain a User-Name attribute. It MUST
- contain either a NAS-IP-Address attribute or a NAS-Identifier
- attribute (or both).
-
- An Access-Request MUST contain either a User-Password or a CHAP-
- Password or a State. An Access-Request MUST NOT contain both a
- User-Password and a CHAP-Password. If future extensions allow
- other kinds of authentication information to be conveyed, the
- attribute for that can be used in an Access-Request instead of
- User-Password or CHAP-Password.
-
- An Access-Request SHOULD contain a NAS-Port or NAS-Port-Type
- attribute or both unless the type of access being requested does
- not involve a port or the NAS does not distinguish among its
- ports.
-
- An Access-Request MAY contain additional attributes as a hint to
- the server, but the server is not required to honor the hint.
-
- When a User-Password is present, it is hidden using a method based
- on the RSA Message Digest Algorithm MD5 [3].
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 17]
-\f
-RFC 2865 RADIUS June 2000
-
-
- A summary of the Access-Request packet format is shown below. The
- fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Request Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Code
-
- 1 for Access-Request.
-
- Identifier
-
- The Identifier field MUST be changed whenever the content of the
- Attributes field changes, and whenever a valid reply has been
- received for a previous request. For retransmissions, the
- Identifier MUST remain unchanged.
-
- Request Authenticator
-
- The Request Authenticator value MUST be changed each time a new
- Identifier is used.
-
- Attributes
-
- The Attribute field is variable in length, and contains the list
- of Attributes that are required for the type of service, as well
- as any desired optional Attributes.
-
-4.2. Access-Accept
-
- Description
-
- Access-Accept packets are sent by the RADIUS server, and provide
- specific configuration information necessary to begin delivery of
- service to the user. If all Attribute values received in an
- Access-Request are acceptable then the RADIUS implementation MUST
- transmit a packet with the Code field set to 2 (Access-Accept).
-
-
-
-
-Rigney, et al. Standards Track [Page 18]
-\f
-RFC 2865 RADIUS June 2000
-
-
- On reception of an Access-Accept, the Identifier field is matched
- with a pending Access-Request. The Response Authenticator field
- MUST contain the correct response for the pending Access-Request.
- Invalid packets are silently discarded.
-
- A summary of the Access-Accept packet format is shown below. The
- fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Response Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Code
-
- 2 for Access-Accept.
-
- Identifier
-
- The Identifier field is a copy of the Identifier field of the
- Access-Request which caused this Access-Accept.
-
- Response Authenticator
-
- The Response Authenticator value is calculated from the Access-
- Request value, as described earlier.
-
- Attributes
-
- The Attribute field is variable in length, and contains a list of
- zero or more Attributes.
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 19]
-\f
-RFC 2865 RADIUS June 2000
-
-
-4.3. Access-Reject
-
- Description
-
- If any value of the received Attributes is not acceptable, then
- the RADIUS server MUST transmit a packet with the Code field set
- to 3 (Access-Reject). It MAY include one or more Reply-Message
- Attributes with a text message which the NAS MAY display to the
- user.
-
- A summary of the Access-Reject packet format is shown below. The
- fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Response Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Code
-
- 3 for Access-Reject.
-
- Identifier
-
- The Identifier field is a copy of the Identifier field of the
- Access-Request which caused this Access-Reject.
-
- Response Authenticator
-
- The Response Authenticator value is calculated from the Access-
- Request value, as described earlier.
-
- Attributes
-
- The Attribute field is variable in length, and contains a list of
- zero or more Attributes.
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 20]
-\f
-RFC 2865 RADIUS June 2000
-
-
-4.4. Access-Challenge
-
- Description
-
- If the RADIUS server desires to send the user a challenge
- requiring a response, then the RADIUS server MUST respond to the
- Access-Request by transmitting a packet with the Code field set to
- 11 (Access-Challenge).
-
- The Attributes field MAY have one or more Reply-Message
- Attributes, and MAY have a single State Attribute, or none.
- Vendor-Specific, Idle-Timeout, Session-Timeout and Proxy-State
- attributes MAY also be included. No other Attributes defined in
- this document are permitted in an Access-Challenge.
-
- On receipt of an Access-Challenge, the Identifier field is matched
- with a pending Access-Request. Additionally, the Response
- Authenticator field MUST contain the correct response for the
- pending Access-Request. Invalid packets are silently discarded.
-
- If the NAS does not support challenge/response, it MUST treat an
- Access-Challenge as though it had received an Access-Reject
- instead.
-
- If the NAS supports challenge/response, receipt of a valid
- Access-Challenge indicates that a new Access-Request SHOULD be
- sent. The NAS MAY display the text message, if any, to the user,
- and then prompt the user for a response. It then sends its
- original Access-Request with a new request ID and Request
- Authenticator, with the User-Password Attribute replaced by the
- user's response (encrypted), and including the State Attribute
- from the Access-Challenge, if any. Only 0 or 1 instances of the
- State Attribute can be present in an Access-Request.
-
- A NAS which supports PAP MAY forward the Reply-Message to the
- dialing client and accept a PAP response which it can use as
- though the user had entered the response. If the NAS cannot do
- so, it MUST treat the Access-Challenge as though it had received
- an Access-Reject instead.
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 21]
-\f
-RFC 2865 RADIUS June 2000
-
-
- A summary of the Access-Challenge packet format is shown below. The
- fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Response Authenticator |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attributes ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Code
-
- 11 for Access-Challenge.
-
- Identifier
-
- The Identifier field is a copy of the Identifier field of the
- Access-Request which caused this Access-Challenge.
-
- Response Authenticator
-
- The Response Authenticator value is calculated from the Access-
- Request value, as described earlier.
-
- Attributes
-
- The Attributes field is variable in length, and contains a list of
- zero or more Attributes.
-
-5. Attributes
-
- RADIUS Attributes carry the specific authentication, authorization,
- information and configuration details for the request and reply.
-
- The end of the list of Attributes is indicated by the Length of the
- RADIUS packet.
-
- Some Attributes MAY be included more than once. The effect of this
- is Attribute specific, and is specified in each Attribute
- description. A summary table is provided at the end of the
- "Attributes" section.
-
-
-
-
-Rigney, et al. Standards Track [Page 22]
-\f
-RFC 2865 RADIUS June 2000
-
-
- If multiple Attributes with the same Type are present, the order of
- Attributes with the same Type MUST be preserved by any proxies. The
- order of Attributes of different Types is not required to be
- preserved. A RADIUS server or client MUST NOT have any dependencies
- on the order of attributes of different types. A RADIUS server or
- client MUST NOT require attributes of the same type to be contiguous.
-
- Where an Attribute's description limits which kinds of packet it can
- be contained in, this applies only to the packet types defined in
- this document, namely Access-Request, Access-Accept, Access-Reject
- and Access-Challenge (Codes 1, 2, 3, and 11). Other documents
- defining other packet types may also use Attributes described here.
- To determine which Attributes are allowed in Accounting-Request and
- Accounting-Response packets (Codes 4 and 5) refer to the RADIUS
- Accounting document [5].
-
- Likewise where packet types defined here state that only certain
- Attributes are permissible in them, future memos defining new
- Attributes should indicate which packet types the new Attributes may
- be present in.
-
- A summary of the Attribute format is shown below. The fields are
- transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | Value ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- The Type field is one octet. Up-to-date values of the RADIUS Type
- field are specified in the most recent "Assigned Numbers" RFC [6].
- Values 192-223 are reserved for experimental use, values 224-240
- are reserved for implementation-specific use, and values 241-255
- are reserved and should not be used.
-
- A RADIUS server MAY ignore Attributes with an unknown Type.
-
- A RADIUS client MAY ignore Attributes with an unknown Type.
-
-
-
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 23]
-\f
-RFC 2865 RADIUS June 2000
-
-
- This specification concerns the following values:
-
- 1 User-Name
- 2 User-Password
- 3 CHAP-Password
- 4 NAS-IP-Address
- 5 NAS-Port
- 6 Service-Type
- 7 Framed-Protocol
- 8 Framed-IP-Address
- 9 Framed-IP-Netmask
- 10 Framed-Routing
- 11 Filter-Id
- 12 Framed-MTU
- 13 Framed-Compression
- 14 Login-IP-Host
- 15 Login-Service
- 16 Login-TCP-Port
- 17 (unassigned)
- 18 Reply-Message
- 19 Callback-Number
- 20 Callback-Id
- 21 (unassigned)
- 22 Framed-Route
- 23 Framed-IPX-Network
- 24 State
- 25 Class
- 26 Vendor-Specific
- 27 Session-Timeout
- 28 Idle-Timeout
- 29 Termination-Action
- 30 Called-Station-Id
- 31 Calling-Station-Id
- 32 NAS-Identifier
- 33 Proxy-State
- 34 Login-LAT-Service
- 35 Login-LAT-Node
- 36 Login-LAT-Group
- 37 Framed-AppleTalk-Link
- 38 Framed-AppleTalk-Network
- 39 Framed-AppleTalk-Zone
- 40-59 (reserved for accounting)
- 60 CHAP-Challenge
- 61 NAS-Port-Type
- 62 Port-Limit
- 63 Login-LAT-Port
-
-
-
-
-
-Rigney, et al. Standards Track [Page 24]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Length
-
- The Length field is one octet, and indicates the length of this
- Attribute including the Type, Length and Value fields. If an
- Attribute is received in an Access-Request but with an invalid
- Length, an Access-Reject SHOULD be transmitted. If an Attribute
- is received in an Access-Accept, Access-Reject or Access-Challenge
- packet with an invalid length, the packet MUST either be treated
- as an Access-Reject or else silently discarded.
-
- Value
-
- The Value field is zero or more octets and contains information
- specific to the Attribute. The format and length of the Value
- field is determined by the Type and Length fields.
-
- Note that none of the types in RADIUS terminate with a NUL (hex
- 00). In particular, types "text" and "string" in RADIUS do not
- terminate with a NUL (hex 00). The Attribute has a length field
- and does not use a terminator. Text contains UTF-8 encoded 10646
- [7] characters and String contains 8-bit binary data. Servers and
- servers and clients MUST be able to deal with embedded nulls.
- RADIUS implementers using C are cautioned not to use strcpy() when
- handling strings.
-
- The format of the value field is one of five data types. Note
- that type "text" is a subset of type "string".
-
- text 1-253 octets containing UTF-8 encoded 10646 [7]
- characters. Text of length zero (0) MUST NOT be sent;
- omit the entire attribute instead.
-
- string 1-253 octets containing binary data (values 0 through
- 255 decimal, inclusive). Strings of length zero (0)
- MUST NOT be sent; omit the entire attribute instead.
-
- address 32 bit value, most significant octet first.
-
- integer 32 bit unsigned value, most significant octet first.
-
- time 32 bit unsigned value, most significant octet first --
- seconds since 00:00:00 UTC, January 1, 1970. The
- standard Attributes do not use this data type but it is
- presented here for possible use in future attributes.
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 25]
-\f
-RFC 2865 RADIUS June 2000
-
-
-5.1. User-Name
-
- Description
-
- This Attribute indicates the name of the user to be authenticated.
- It MUST be sent in Access-Request packets if available.
-
- It MAY be sent in an Access-Accept packet, in which case the
- client SHOULD use the name returned in the Access-Accept packet in
- all Accounting-Request packets for this session. If the Access-
- Accept includes Service-Type = Rlogin and the User-Name attribute,
- a NAS MAY use the returned User-Name when performing the Rlogin
- function.
-
- A summary of the User-Name Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 1 for User-Name.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets. The NAS may limit the
- maximum length of the User-Name but the ability to handle at least
- 63 octets is recommended.
-
- The format of the username MAY be one of several forms:
-
- text Consisting only of UTF-8 encoded 10646 [7] characters.
-
- network access identifier
- A Network Access Identifier as described in RFC 2486
- [8].
-
- distinguished name
- A name in ASN.1 form used in Public Key authentication
- systems.
-
-
-
-Rigney, et al. Standards Track [Page 26]
-\f
-RFC 2865 RADIUS June 2000
-
-
-5.2. User-Password
-
- Description
-
- This Attribute indicates the password of the user to be
- authenticated, or the user's input following an Access-Challenge.
- It is only used in Access-Request packets.
-
- On transmission, the password is hidden. The password is first
- padded at the end with nulls to a multiple of 16 octets. A one-
- way MD5 hash is calculated over a stream of octets consisting of
- the shared secret followed by the Request Authenticator. This
- value is XORed with the first 16 octet segment of the password and
- placed in the first 16 octets of the String field of the User-
- Password Attribute.
-
- If the password is longer than 16 characters, a second one-way MD5
- hash is calculated over a stream of octets consisting of the
- shared secret followed by the result of the first xor. That hash
- is XORed with the second 16 octet segment of the password and
- placed in the second 16 octets of the String field of the User-
- Password Attribute.
-
- If necessary, this operation is repeated, with each xor result
- being used along with the shared secret to generate the next hash
- to xor the next segment of the password, to no more than 128
- characters.
-
- The method is taken from the book "Network Security" by Kaufman,
- Perlman and Speciner [9] pages 109-110. A more precise
- explanation of the method follows:
-
- Call the shared secret S and the pseudo-random 128-bit Request
- Authenticator RA. Break the password into 16-octet chunks p1, p2,
- etc. with the last one padded at the end with nulls to a 16-octet
- boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need
- intermediate values b1, b2, etc.
-
- b1 = MD5(S + RA) c(1) = p1 xor b1
- b2 = MD5(S + c(1)) c(2) = p2 xor b2
- . .
- . .
- . .
- bi = MD5(S + c(i-1)) c(i) = pi xor bi
-
- The String will contain c(1)+c(2)+...+c(i) where + denotes
- concatenation.
-
-
-
-
-Rigney, et al. Standards Track [Page 27]
-\f
-RFC 2865 RADIUS June 2000
-
-
- On receipt, the process is reversed to yield the original
- password.
-
- A summary of the User-Password Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 2 for User-Password.
-
- Length
-
- At least 18 and no larger than 130.
-
- String
-
- The String field is between 16 and 128 octets long, inclusive.
-
-5.3. CHAP-Password
-
- Description
-
- This Attribute indicates the response value provided by a PPP
- Challenge-Handshake Authentication Protocol (CHAP) user in
- response to the challenge. It is only used in Access-Request
- packets.
-
- The CHAP challenge value is found in the CHAP-Challenge Attribute
- (60) if present in the packet, otherwise in the Request
- Authenticator field.
-
- A summary of the CHAP-Password Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | CHAP Ident | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 28]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Type
-
- 3 for CHAP-Password.
-
- Length
-
- 19
-
- CHAP Ident
-
- This field is one octet, and contains the CHAP Identifier from the
- user's CHAP Response.
-
- String
-
- The String field is 16 octets, and contains the CHAP Response from
- the user.
-
-5.4. NAS-IP-Address
-
- Description
-
- This Attribute indicates the identifying IP Address of the NAS
- which is requesting authentication of the user, and SHOULD be
- unique to the NAS within the scope of the RADIUS server. NAS-IP-
- Address is only used in Access-Request packets. Either NAS-IP-
- Address or NAS-Identifier MUST be present in an Access-Request
- packet.
-
- Note that NAS-IP-Address MUST NOT be used to select the shared
- secret used to authenticate the request. The source IP address of
- the Access-Request packet MUST be used to select the shared
- secret.
-
- A summary of the NAS-IP-Address Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Address
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Address (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 4 for NAS-IP-Address.
-
-
-
-Rigney, et al. Standards Track [Page 29]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Length
-
- 6
-
- Address
-
- The Address field is four octets.
-
-5.5. NAS-Port
-
- Description
-
- This Attribute indicates the physical port number of the NAS which
- is authenticating the user. It is only used in Access-Request
- packets. Note that this is using "port" in its sense of a
- physical connection on the NAS, not in the sense of a TCP or UDP
- port number. Either NAS-Port or NAS-Port-Type (61) or both SHOULD
- be present in an Access-Request packet, if the NAS differentiates
- among its ports.
-
- A summary of the NAS-Port Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 5 for NAS-Port.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
-
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 30]
-\f
-RFC 2865 RADIUS June 2000
-
-
-5.6. Service-Type
-
- Description
-
- This Attribute indicates the type of service the user has
- requested, or the type of service to be provided. It MAY be used
- in both Access-Request and Access-Accept packets. A NAS is not
- required to implement all of these service types, and MUST treat
- unknown or unsupported Service-Types as though an Access-Reject
- had been received instead.
-
- A summary of the Service-Type Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 6 for Service-Type.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 1 Login
- 2 Framed
- 3 Callback Login
- 4 Callback Framed
- 5 Outbound
- 6 Administrative
- 7 NAS Prompt
- 8 Authenticate Only
- 9 Callback NAS Prompt
- 10 Call Check
- 11 Callback Administrative
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 31]
-\f
-RFC 2865 RADIUS June 2000
-
-
- The service types are defined as follows when used in an Access-
- Accept. When used in an Access-Request, they MAY be considered to
- be a hint to the RADIUS server that the NAS has reason to believe
- the user would prefer the kind of service indicated, but the
- server is not required to honor the hint.
-
- Login The user should be connected to a host.
-
- Framed A Framed Protocol should be started for the
- User, such as PPP or SLIP.
-
- Callback Login The user should be disconnected and called
- back, then connected to a host.
-
- Callback Framed The user should be disconnected and called
- back, then a Framed Protocol should be started
- for the User, such as PPP or SLIP.
-
- Outbound The user should be granted access to outgoing
- devices.
-
- Administrative The user should be granted access to the
- administrative interface to the NAS from which
- privileged commands can be executed.
-
- NAS Prompt The user should be provided a command prompt
- on the NAS from which non-privileged commands
- can be executed.
-
- Authenticate Only Only Authentication is requested, and no
- authorization information needs to be returned
- in the Access-Accept (typically used by proxy
- servers rather than the NAS itself).
-
- Callback NAS Prompt The user should be disconnected and called
- back, then provided a command prompt on the
- NAS from which non-privileged commands can be
- executed.
-
- Call Check Used by the NAS in an Access-Request packet to
- indicate that a call is being received and
- that the RADIUS server should send back an
- Access-Accept to answer the call, or an
- Access-Reject to not accept the call,
- typically based on the Called-Station-Id or
- Calling-Station-Id attributes. It is
-
-
-
-
-
-Rigney, et al. Standards Track [Page 32]
-\f
-RFC 2865 RADIUS June 2000
-
-
- recommended that such Access-Requests use the
- value of Calling-Station-Id as the value of
- the User-Name.
-
- Callback Administrative
- The user should be disconnected and called
- back, then granted access to the
- administrative interface to the NAS from which
- privileged commands can be executed.
-
-5.7. Framed-Protocol
-
- Description
-
- This Attribute indicates the framing to be used for framed access.
- It MAY be used in both Access-Request and Access-Accept packets.
-
- A summary of the Framed-Protocol Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 7 for Framed-Protocol.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 1 PPP
- 2 SLIP
- 3 AppleTalk Remote Access Protocol (ARAP)
- 4 Gandalf proprietary SingleLink/MultiLink protocol
- 5 Xylogics proprietary IPX/SLIP
- 6 X.75 Synchronous
-
-
-
-
-
-Rigney, et al. Standards Track [Page 33]
-\f
-RFC 2865 RADIUS June 2000
-
-
-5.8. Framed-IP-Address
-
- Description
-
- This Attribute indicates the address to be configured for the
- user. It MAY be used in Access-Accept packets. It MAY be used in
- an Access-Request packet as a hint by the NAS to the server that
- it would prefer that address, but the server is not required to
- honor the hint.
-
- A summary of the Framed-IP-Address Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Address
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Address (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 8 for Framed-IP-Address.
-
- Length
-
- 6
-
- Address
-
- The Address field is four octets. The value 0xFFFFFFFF indicates
- that the NAS Should allow the user to select an address (e.g.
- Negotiated). The value 0xFFFFFFFE indicates that the NAS should
- select an address for the user (e.g. Assigned from a pool of
- addresses kept by the NAS). Other valid values indicate that the
- NAS should use that value as the user's IP address.
-
-5.9. Framed-IP-Netmask
-
- Description
-
- This Attribute indicates the IP netmask to be configured for the
- user when the user is a router to a network. It MAY be used in
- Access-Accept packets. It MAY be used in an Access-Request packet
- as a hint by the NAS to the server that it would prefer that
- netmask, but the server is not required to honor the hint.
-
-
-
-
-Rigney, et al. Standards Track [Page 34]
-\f
-RFC 2865 RADIUS June 2000
-
-
- A summary of the Framed-IP-Netmask Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Address
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Address (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 9 for Framed-IP-Netmask.
-
- Length
-
- 6
-
- Address
-
- The Address field is four octets specifying the IP netmask of the
- user.
-
-5.10. Framed-Routing
-
- Description
-
- This Attribute indicates the routing method for the user, when the
- user is a router to a network. It is only used in Access-Accept
- packets.
-
- A summary of the Framed-Routing Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 10 for Framed-Routing.
-
-
-
-
-
-Rigney, et al. Standards Track [Page 35]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 0 None
- 1 Send routing packets
- 2 Listen for routing packets
- 3 Send and Listen
-
-5.11. Filter-Id
-
- Description
-
- This Attribute indicates the name of the filter list for this
- user. Zero or more Filter-Id attributes MAY be sent in an
- Access-Accept packet.
-
- Identifying a filter list by name allows the filter to be used on
- different NASes without regard to filter-list implementation
- details.
-
- A summary of the Filter-Id Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | Text ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 11 for Filter-Id.
-
- Length
-
- >= 3
-
- Text
-
- The Text field is one 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 UTF-8 encoded 10646 [7] characters.
-
-
-
-Rigney, et al. Standards Track [Page 36]
-\f
-RFC 2865 RADIUS June 2000
-
-
-5.12. Framed-MTU
-
- Description
-
- This Attribute indicates the Maximum Transmission Unit to be
- configured for the user, when it is not negotiated by some other
- means (such as PPP). It MAY be used in Access-Accept packets. It
- MAY be used in an Access-Request packet as a hint by the NAS to
- the server that it would prefer that value, but the server is not
- required to honor the hint.
-
- A summary of the Framed-MTU Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 12 for Framed-MTU.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets. Despite the size of the field,
- values range from 64 to 65535.
-
-5.13. Framed-Compression
-
- Description
-
- This Attribute indicates a compression protocol to be used for the
- link. It MAY be used in Access-Accept packets. It MAY be used in
- an Access-Request packet as a hint to the server that the NAS
- would prefer to use that compression, but the server is not
- required to honor the hint.
-
- More than one compression protocol Attribute MAY be sent. It is
- the responsibility of the NAS to apply the proper compression
- protocol to appropriate link traffic.
-
-
-
-Rigney, et al. Standards Track [Page 37]
-\f
-RFC 2865 RADIUS June 2000
-
-
- A summary of the Framed-Compression Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 13 for Framed-Compression.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 0 None
- 1 VJ TCP/IP header compression [10]
- 2 IPX header compression
- 3 Stac-LZS compression
-
-5.14. Login-IP-Host
-
- Description
-
- This Attribute indicates the system with which to connect the user,
- when the Login-Service Attribute is included. It MAY be used in
- Access-Accept packets. It MAY be used in an Access-Request packet as
- a hint to the server that the NAS would prefer to use that host, but
- the server is not required to honor the hint.
-
- A summary of the Login-IP-Host Attribute format is shown below. The
- fields are transmitted from left to right.
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 38]
-\f
-RFC 2865 RADIUS June 2000
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Address
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Address (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 14 for Login-IP-Host.
-
- Length
-
- 6
-
- Address
-
- The Address field is four octets. The value 0xFFFFFFFF indicates
- that the NAS SHOULD allow the user to select an address. The
- value 0 indicates that the NAS SHOULD select a host to connect the
- user to. Other values indicate the address the NAS SHOULD connect
- the user to.
-
-5.15. Login-Service
-
- Description
-
- This Attribute indicates the service to use to connect the user to
- the login host. It is only used in Access-Accept packets.
-
- A summary of the Login-Service Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 15 for Login-Service.
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 39]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 0 Telnet
- 1 Rlogin
- 2 TCP Clear
- 3 PortMaster (proprietary)
- 4 LAT
- 5 X25-PAD
- 6 X25-T3POS
- 8 TCP Clear Quiet (suppresses any NAS-generated connect string)
-
-5.16. Login-TCP-Port
-
- Description
-
- This Attribute indicates the TCP port with which the user is to be
- connected, when the Login-Service Attribute is also present. It
- is only used in Access-Accept packets.
-
- A summary of the Login-TCP-Port Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 16 for Login-TCP-Port.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets. Despite the size of the field,
- values range from 0 to 65535.
-
-
-
-Rigney, et al. Standards Track [Page 40]
-\f
-RFC 2865 RADIUS June 2000
-
-
-5.17. (unassigned)
-
- Description
-
- ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED.
-
-5.18. Reply-Message
-
- Description
-
- This Attribute indicates text which MAY be displayed to the user.
-
- When used in an Access-Accept, it is the success message.
-
- When used in an Access-Reject, it is the failure message. It MAY
- indicate a dialog message to prompt the user before another
- Access-Request attempt.
-
- When used in an Access-Challenge, it MAY indicate a dialog message
- to prompt the user for a response.
-
- Multiple Reply-Message's MAY be included and if any are displayed,
- they MUST be displayed in the same order as they appear in the
- packet.
-
- A summary of the Reply-Message Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | Text ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 18 for Reply-Message.
-
- Length
-
- >= 3
-
- Text
-
- The Text field is one 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 UTF-8 encoded 10646 [7] characters.
-
-
-
-Rigney, et al. Standards Track [Page 41]
-\f
-RFC 2865 RADIUS June 2000
-
-
-5.19. Callback-Number
-
- Description
-
- This Attribute indicates a dialing string to be used for callback.
- It MAY be used in Access-Accept packets. It MAY be used in an
- Access-Request packet as a hint to the server that a Callback
- service is desired, but the server is not required to honor the
- hint.
-
- A summary of the Callback-Number Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 19 for Callback-Number.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.20. Callback-Id
-
- Description
-
- This Attribute indicates the name of a place to be called, to be
- interpreted by the NAS. It MAY be used in Access-Accept packets.
-
-
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 42]
-\f
-RFC 2865 RADIUS June 2000
-
-
- A summary of the Callback-Id Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 20 for Callback-Id.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.21. (unassigned)
-
- Description
-
- ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED.
-
-5.22. Framed-Route
-
- Description
-
- This Attribute provides routing information to be configured for
- the user on the NAS. It is used in the Access-Accept packet and
- can appear multiple times.
-
- A summary of the Framed-Route Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | Text ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
-
-Rigney, et al. Standards Track [Page 43]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Type
-
- 22 for Framed-Route.
-
- Length
-
- >= 3
-
- Text
-
- The Text field is one 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 UTF-8 encoded 10646 [7] characters.
-
- For IP routes, it SHOULD contain a destination prefix in dotted
- quad form optionally followed by a slash and a decimal length
- specifier stating how many high order bits of the prefix to use.
- That is followed by a space, a gateway address in dotted quad
- form, a space, and one or more metrics separated by spaces. For
- example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length
- specifier may be omitted, in which case it defaults to 8 bits for
- class A prefixes, 16 bits for class B prefixes, and 24 bits for
- class C prefixes. For example, "192.168.1.0 192.168.1.1 1".
-
- Whenever the gateway address is specified as "0.0.0.0" the IP
- address of the user SHOULD be used as the gateway address.
-
-5.23. Framed-IPX-Network
-
- Description
-
- This Attribute indicates the IPX Network number to be configured
- for the user. It is used in Access-Accept packets.
-
- A summary of the Framed-IPX-Network Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 44]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Type
-
- 23 for Framed-IPX-Network.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets. The value 0xFFFFFFFE indicates
- that the NAS should select an IPX network for the user (e.g.
- assigned from a pool of one or more IPX networks kept by the NAS).
- Other values should be used as the IPX network for the link to the
- user.
-
-5.24. State
-
- Description
-
- This Attribute is available to be sent by the server to the client
- in an Access-Challenge and MUST be sent unmodified from the client
- to the server in the new Access-Request reply to that challenge,
- if any.
-
- This Attribute is available to be sent by the server to the client
- in an Access-Accept that also includes a Termination-Action
- Attribute with the value of RADIUS-Request. If the NAS performs
- the Termination-Action by sending a new Access-Request upon
- termination of the current session, it MUST include the State
- attribute unchanged in that Access-Request.
-
- In either usage, the client MUST NOT interpret the attribute
- locally. A packet must have only zero or one State Attribute.
- Usage of the State Attribute is implementation dependent.
-
- A summary of the State Attribute format is shown below. The fields
- are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 24 for State.
-
-
-
-Rigney, et al. Standards Track [Page 45]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.25. Class
-
- Description
-
- This Attribute is available to be sent by the server to the client
- in an Access-Accept and SHOULD be sent unmodified by the client to
- the accounting server as part of the Accounting-Request packet if
- accounting is supported. The client MUST NOT interpret the
- attribute locally.
-
- A summary of the Class Attribute format is shown below. The fields
- are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 25 for Class.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-
-
-Rigney, et al. Standards Track [Page 46]
-\f
-RFC 2865 RADIUS June 2000
-
-
-5.26. Vendor-Specific
-
- Description
-
- This Attribute is available to allow vendors to support their own
- extended Attributes not suitable for general usage. It MUST not
- affect the operation of the RADIUS protocol.
-
- Servers not equipped to interpret the vendor-specific information
- sent by a client MUST ignore it (although it may be reported).
- Clients which do not receive desired vendor-specific information
- SHOULD make an attempt to operate without it, although they may do
- so (and report they are doing so) in a degraded mode.
-
- A summary of the Vendor-Specific Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Vendor-Id
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Vendor-Id (cont) | String...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 26 for Vendor-Specific.
-
- Length
-
- >= 7
-
- Vendor-Id
-
- The high-order octet is 0 and the low-order 3 octets are the SMI
- Network Management Private Enterprise Code of the Vendor in
- network byte order, as defined in the "Assigned Numbers" RFC [6].
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-
-
-
-Rigney, et al. Standards Track [Page 47]
-\f
-RFC 2865 RADIUS June 2000
-
-
- It SHOULD be encoded as a sequence of vendor type / vendor length
- / value fields, as follows. The Attribute-Specific field is
- dependent on the vendor's definition of that attribute. An
- example encoding of the Vendor-Specific attribute using this
- method follows:
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Vendor-Id
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Vendor-Id (cont) | Vendor type | Vendor length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Attribute-Specific...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Multiple subattributes MAY be encoded within a single Vendor-
- Specific attribute, although they do not have to be.
-
-5.27. Session-Timeout
-
- Description
-
- This Attribute sets the maximum number of seconds of service to be
- provided to the user before termination of the session or prompt.
- This Attribute is available to be sent by the server to the client
- in an Access-Accept or Access-Challenge.
-
- A summary of the Session-Timeout Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 27 for Session-Timeout.
-
- Length
-
- 6
-
-
-
-
-
-Rigney, et al. Standards Track [Page 48]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Value
-
- The field is 4 octets, containing a 32-bit unsigned integer with
- the maximum number of seconds this user should be allowed to
- remain connected by the NAS.
-
-5.28. Idle-Timeout
-
- Description
-
- This Attribute sets the maximum number of consecutive seconds of
- idle connection allowed to the user before termination of the
- session or prompt. This Attribute is available to be sent by the
- server to the client in an Access-Accept or Access-Challenge.
-
- A summary of the Idle-Timeout Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 28 for Idle-Timeout.
-
- Length
-
- 6
-
- Value
-
- The field is 4 octets, containing a 32-bit unsigned integer with
- the maximum number of consecutive seconds of idle time this user
- should be permitted before being disconnected by the NAS.
-
-5.29. Termination-Action
-
- Description
-
- This Attribute indicates what action the NAS should take when the
- specified service is completed. It is only used in Access-Accept
- packets.
-
-
-
-
-Rigney, et al. Standards Track [Page 49]
-\f
-RFC 2865 RADIUS June 2000
-
-
- A summary of the Termination-Action Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 29 for Termination-Action.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets.
-
- 0 Default
- 1 RADIUS-Request
-
- If the Value is set to RADIUS-Request, upon termination of the
- specified service the NAS MAY send a new Access-Request to the
- RADIUS server, including the State attribute if any.
-
-5.30. Called-Station-Id
-
- Description
-
- This Attribute allows the NAS to send in the Access-Request packet
- the phone number that the user called, using Dialed Number
- Identification (DNIS) or similar technology. Note that this may
- be different from the phone number the call comes in on. It is
- only used in Access-Request packets.
-
- A summary of the Called-Station-Id Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
-
-Rigney, et al. Standards Track [Page 50]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Type
-
- 30 for Called-Station-Id.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets, containing the phone
- number that the user's call came in on.
-
- The actual format of the information is site or application
- specific. UTF-8 encoded 10646 [7] characters are recommended, but
- a robust implementation SHOULD support the field as
- undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.31. Calling-Station-Id
-
- Description
-
- This Attribute allows the NAS to send in the Access-Request packet
- the phone number that the call came from, using Automatic Number
- Identification (ANI) or similar technology. It is only used in
- Access-Request packets.
-
- A summary of the Calling-Station-Id Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 31 for Calling-Station-Id.
-
- Length
-
- >= 3
-
-
-
-
-
-Rigney, et al. Standards Track [Page 51]
-\f
-RFC 2865 RADIUS June 2000
-
-
- String
-
- The String field is one or more octets, containing the phone
- number that the user placed the call from.
-
- The actual format of the information is site or application
- specific. UTF-8 encoded 10646 [7] characters are recommended, but
- a robust implementation SHOULD support the field as
- undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.32. NAS-Identifier
-
- Description
-
- This Attribute contains a string identifying the NAS originating
- the Access-Request. It is only used in Access-Request packets.
- Either NAS-IP-Address or NAS-Identifier MUST be present in an
- Access-Request packet.
-
- Note that NAS-Identifier MUST NOT be used to select the shared
- secret used to authenticate the request. The source IP address of
- the Access-Request packet MUST be used to select the shared
- secret.
-
- A summary of the NAS-Identifier Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 32 for NAS-Identifier.
-
- Length
-
- >= 3
-
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 52]
-\f
-RFC 2865 RADIUS June 2000
-
-
- String
-
- The String field is one or more octets, and should be unique to
- the NAS within the scope of the RADIUS server. For example, a
- fully qualified domain name would be suitable as a NAS-Identifier.
-
- The actual format of the information is site or application
- specific, and a robust implementation SHOULD support the field as
- undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.33. Proxy-State
-
- Description
-
- This Attribute is available to be sent by a proxy server to
- another server when forwarding an Access-Request and MUST be
- returned unmodified in the Access-Accept, Access-Reject or
- Access-Challenge. When the proxy server receives the response to
- its request, it MUST remove its own Proxy-State (the last Proxy-
- State in the packet) before forwarding the response to the NAS.
-
- If a Proxy-State Attribute is added to a packet when forwarding
- the packet, the Proxy-State Attribute MUST be added after any
- existing Proxy-State attributes.
-
- The content of any Proxy-State other than the one added by the
- current server should be treated as opaque octets and MUST NOT
- affect operation of the protocol.
-
- Usage of the Proxy-State Attribute is implementation dependent. A
- description of its function is outside the scope of this
- specification.
-
- A summary of the Proxy-State Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 33 for Proxy-State.
-
-
-
-Rigney, et al. Standards Track [Page 53]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets. The actual format of the
- information is site or application specific, and a robust
- implementation SHOULD support the field as undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.34. Login-LAT-Service
-
- Description
-
- This Attribute indicates the system with which the user is to be
- connected by LAT. It MAY be used in Access-Accept packets, but
- only when LAT is specified as the Login-Service. It MAY be used
- in an Access-Request packet as a hint to the server, but the
- server is not required to honor the hint.
-
- Administrators use the service attribute when dealing with
- clustered systems, such as a VAX or Alpha cluster. In such an
- environment several different time sharing hosts share the same
- resources (disks, printers, etc.), and administrators often
- configure each to offer access (service) to each of the shared
- resources. In this case, each host in the cluster advertises its
- services through LAT broadcasts.
-
- Sophisticated users often know which service providers (machines)
- are faster and tend to use a node name when initiating a LAT
- connection. Alternately, some administrators want particular
- users to use certain machines as a primitive form of load
- balancing (although LAT knows how to do load balancing itself).
-
- A summary of the Login-LAT-Service Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 54]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Type
-
- 34 for Login-LAT-Service.
-
- Length
-
- >= 3
-
- String
-
- The String field is one or more octets, and contains the identity
- of the LAT service to use. The LAT Architecture allows this
- string to contain $ (dollar), - (hyphen), . (period), _
- (underscore), numerics, upper and lower case alphabetics, and the
- ISO Latin-1 character set extension [11]. All LAT string
- comparisons are case insensitive.
-
-5.35. Login-LAT-Node
-
- Description
-
- This Attribute indicates the Node with which the user is to be
- automatically connected by LAT. It MAY be used in Access-Accept
- packets, but only when LAT is specified as the Login-Service. It
- MAY be used in an Access-Request packet as a hint to the server,
- but the server is not required to honor the hint.
-
- A summary of the Login-LAT-Node Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 35 for Login-LAT-Node.
-
- Length
-
- >= 3
-
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 55]
-\f
-RFC 2865 RADIUS June 2000
-
-
- String
-
- The String field is one or more octets, and contains the identity
- of the LAT Node to connect the user to. The LAT Architecture
- allows this string to contain $ (dollar), - (hyphen), . (period),
- _ (underscore), numerics, upper and lower case alphabetics, and
- the ISO Latin-1 character set extension. All LAT string
- comparisons are case insensitive.
-
-5.36. Login-LAT-Group
-
- Description
-
- This Attribute contains a string identifying the LAT group codes
- which this user is authorized to use. It MAY be used in Access-
- Accept packets, but only when LAT is specified as the Login-
- Service. It MAY be used in an Access-Request packet as a hint to
- the server, but the server is not required to honor the hint.
-
- LAT supports 256 different group codes, which LAT uses as a form
- of access rights. LAT encodes the group codes as a 256 bit
- bitmap.
-
- Administrators can assign one or more of the group code bits at
- the LAT service provider; it will only accept LAT connections that
- have these group codes set in the bit map. The administrators
- assign a bitmap of authorized group codes to each user; LAT gets
- these from the operating system, and uses these in its requests to
- the service providers.
-
- A summary of the Login-LAT-Group Attribute format is shown below.
- The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 36 for Login-LAT-Group.
-
- Length
-
- 34
-
-
-
-
-
-Rigney, et al. Standards Track [Page 56]
-\f
-RFC 2865 RADIUS June 2000
-
-
- String
-
- The String field is a 32 octet bit map, most significant octet
- first. A robust implementation SHOULD support the field as
- undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.37. Framed-AppleTalk-Link
-
- Description
-
- This Attribute indicates the AppleTalk network number which should
- be used for the serial link to the user, which is another
- AppleTalk router. It is only used in Access-Accept packets. It
- is never used when the user is not another router.
-
- A summary of the Framed-AppleTalk-Link Attribute format is shown
- below. The fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 37 for Framed-AppleTalk-Link.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets. Despite the size of the field,
- values range from 0 to 65535. The special value of 0 indicates
- that this is an unnumbered serial link. A value of 1-65535 means
- that the serial line between the NAS and the user should be
- assigned that value as an AppleTalk network number.
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 57]
-\f
-RFC 2865 RADIUS June 2000
-
-
-5.38. Framed-AppleTalk-Network
-
- Description
-
- This Attribute indicates the AppleTalk Network number which the
- NAS should probe to allocate an AppleTalk node for the user. It
- is only used in Access-Accept packets. It is never used when the
- user is another router. Multiple instances of this Attribute
- indicate that the NAS may probe using any of the network numbers
- specified.
-
- A summary of the Framed-AppleTalk-Network Attribute format is shown
- below. The fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 38 for Framed-AppleTalk-Network.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets. Despite the size of the field,
- values range from 0 to 65535. The special value 0 indicates that
- the NAS should assign a network for the user, using its default
- cable range. A value between 1 and 65535 (inclusive) indicates
- the AppleTalk Network the NAS should probe to find an address for
- the user.
-
-5.39. Framed-AppleTalk-Zone
-
- Description
-
- This Attribute indicates the AppleTalk Default Zone to be used for
- this user. It is only used in Access-Accept packets. Multiple
- instances of this attribute in the same packet are not allowed.
-
-
-
-
-
-Rigney, et al. Standards Track [Page 58]
-\f
-RFC 2865 RADIUS June 2000
-
-
- A summary of the Framed-AppleTalk-Zone Attribute format is shown
- below. The fields are transmitted from left to right.
-
- 0 1 2
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 39 for Framed-AppleTalk-Zone.
-
- Length
-
- >= 3
-
- String
-
- The name of the Default AppleTalk Zone to be used for this user.
- A robust implementation SHOULD support the field as
- undistinguished octets.
-
- The codification of the range of allowed usage of this field is
- outside the scope of this specification.
-
-5.40. CHAP-Challenge
-
- Description
-
- This Attribute contains the CHAP Challenge sent by the NAS to a
- PPP Challenge-Handshake Authentication Protocol (CHAP) user. It
- is only used in Access-Request packets.
-
- If the CHAP challenge value is 16 octets long it MAY be placed in
- the Request Authenticator field instead of using this attribute.
-
- A summary of the CHAP-Challenge Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 59]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Type
-
- 60 for CHAP-Challenge.
-
- Length
-
- >= 7
-
- String
-
- The String field contains the CHAP Challenge.
-
-5.41. NAS-Port-Type
-
- Description
-
- This Attribute indicates the type of the physical port of the NAS
- which is authenticating the user. It can be used instead of or in
- addition to the NAS-Port (5) attribute. It is only used in
- Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or
- both SHOULD be present in an Access-Request packet, if the NAS
- differentiates among its ports.
-
- A summary of the NAS-Port-Type Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 61 for NAS-Port-Type.
-
- Length
-
- 6
-
- Value
-
- The Value field is four octets. "Virtual" refers to a connection
- to the NAS via some transport protocol, instead of through a
- physical port. For example, if a user telnetted into a NAS to
-
-
-
-
-Rigney, et al. Standards Track [Page 60]
-\f
-RFC 2865 RADIUS June 2000
-
-
- authenticate himself as an Outbound-User, the Access-Request might
- include NAS-Port-Type = Virtual as a hint to the RADIUS server
- that the user was not on a physical port.
-
- 0 Async
- 1 Sync
- 2 ISDN Sync
- 3 ISDN Async V.120
- 4 ISDN Async V.110
- 5 Virtual
- 6 PIAFS
- 7 HDLC Clear Channel
- 8 X.25
- 9 X.75
- 10 G.3 Fax
- 11 SDSL - Symmetric DSL
- 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase
- Modulation
- 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone
- 14 IDSL - ISDN Digital Subscriber Line
- 15 Ethernet
- 16 xDSL - Digital Subscriber Line of unknown type
- 17 Cable
- 18 Wireless - Other
- 19 Wireless - IEEE 802.11
-
- PIAFS is a form of wireless ISDN commonly used in Japan, and
- stands for PHS (Personal Handyphone System) Internet Access Forum
- Standard (PIAFS).
-
-5.42. Port-Limit
-
- Description
-
- This Attribute sets the maximum number of ports to be provided to
- the user by the NAS. This Attribute MAY be sent by the server to
- the client in an Access-Accept packet. It is intended for use in
- conjunction with Multilink PPP [12] or similar uses. It MAY also
- be sent by the NAS to the server as a hint that that many ports
- are desired for use, but the server is not required to honor the
- hint.
-
- A summary of the Port-Limit Attribute format is shown below. The
- fields are transmitted from left to right.
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 61]
-\f
-RFC 2865 RADIUS June 2000
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Value (cont) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 62 for Port-Limit.
-
- Length
-
- 6
-
- Value
-
- The field is 4 octets, containing a 32-bit unsigned integer with
- the maximum number of ports this user should be allowed to connect
- to on the NAS.
-
-5.43. Login-LAT-Port
-
- Description
-
- This Attribute indicates the Port with which the user is to be
- connected by LAT. It MAY be used in Access-Accept packets, but
- only when LAT is specified as the Login-Service. It MAY be used
- in an Access-Request packet as a hint to the server, but the
- server is not required to honor the hint.
-
- A summary of the Login-LAT-Port Attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
- | Type | Length | String ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Type
-
- 63 for Login-LAT-Port.
-
- Length
-
- >= 3
-
-
-
-Rigney, et al. Standards Track [Page 62]
-\f
-RFC 2865 RADIUS June 2000
-
-
- String
-
- The String field is one or more octets, and contains the identity
- of the LAT port to use. The LAT Architecture allows this string
- to contain $ (dollar), - (hyphen), . (period), _ (underscore),
- numerics, upper and lower case alphabetics, and the ISO Latin-1
- character set extension. All LAT string comparisons are case
- insensitive.
-
-5.44. Table of Attributes
-
- The following table provides a guide to which attributes may be found
- in which kinds of packets, and in what quantity.
-
- Request Accept Reject Challenge # Attribute
- 0-1 0-1 0 0 1 User-Name
- 0-1 0 0 0 2 User-Password [Note 1]
- 0-1 0 0 0 3 CHAP-Password [Note 1]
- 0-1 0 0 0 4 NAS-IP-Address [Note 2]
- 0-1 0 0 0 5 NAS-Port
- 0-1 0-1 0 0 6 Service-Type
- 0-1 0-1 0 0 7 Framed-Protocol
- 0-1 0-1 0 0 8 Framed-IP-Address
- 0-1 0-1 0 0 9 Framed-IP-Netmask
- 0 0-1 0 0 10 Framed-Routing
- 0 0+ 0 0 11 Filter-Id
- 0-1 0-1 0 0 12 Framed-MTU
- 0+ 0+ 0 0 13 Framed-Compression
- 0+ 0+ 0 0 14 Login-IP-Host
- 0 0-1 0 0 15 Login-Service
- 0 0-1 0 0 16 Login-TCP-Port
- 0 0+ 0+ 0+ 18 Reply-Message
- 0-1 0-1 0 0 19 Callback-Number
- 0 0-1 0 0 20 Callback-Id
- 0 0+ 0 0 22 Framed-Route
- 0 0-1 0 0 23 Framed-IPX-Network
- 0-1 0-1 0 0-1 24 State [Note 1]
- 0 0+ 0 0 25 Class
- 0+ 0+ 0 0+ 26 Vendor-Specific
- 0 0-1 0 0-1 27 Session-Timeout
- 0 0-1 0 0-1 28 Idle-Timeout
- 0 0-1 0 0 29 Termination-Action
- 0-1 0 0 0 30 Called-Station-Id
- 0-1 0 0 0 31 Calling-Station-Id
- 0-1 0 0 0 32 NAS-Identifier [Note 2]
- 0+ 0+ 0+ 0+ 33 Proxy-State
- 0-1 0-1 0 0 34 Login-LAT-Service
- 0-1 0-1 0 0 35 Login-LAT-Node
-
-
-
-Rigney, et al. Standards Track [Page 63]
-\f
-RFC 2865 RADIUS June 2000
-
-
- 0-1 0-1 0 0 36 Login-LAT-Group
- 0 0-1 0 0 37 Framed-AppleTalk-Link
- 0 0+ 0 0 38 Framed-AppleTalk-Network
- 0 0-1 0 0 39 Framed-AppleTalk-Zone
- 0-1 0 0 0 60 CHAP-Challenge
- 0-1 0 0 0 61 NAS-Port-Type
- 0-1 0-1 0 0 62 Port-Limit
- 0-1 0-1 0 0 63 Login-LAT-Port
- Request Accept Reject Challenge # Attribute
-
- [Note 1] An Access-Request MUST contain either a User-Password or a
- CHAP-Password or State. An Access-Request MUST NOT contain both a
- User-Password and a CHAP-Password. If future extensions allow other
- kinds of authentication information to be conveyed, the attribute for
- that can be used in an Access-Request instead of User-Password or
- CHAP-Password.
-
- [Note 2] An Access-Request MUST contain either a NAS-IP-Address or a
- NAS-Identifier (or both).
-
- The following table defines the meaning of the above table entries.
-
-0 This attribute MUST NOT be present in packet.
-0+ Zero or more instances of this attribute MAY be present in packet.
-0-1 Zero or one instance of this attribute MAY be present in packet.
-1 Exactly one instance of this attribute MUST be present in packet.
-
-6. IANA Considerations
-
- This section provides guidance to the Internet Assigned Numbers
- Authority (IANA) regarding registration of values related to the
- RADIUS protocol, in accordance with BCP 26 [13].
-
- There are three name spaces in RADIUS that require registration:
- Packet Type Codes, Attribute Types, and Attribute Values (for certain
- Attributes).
-
- RADIUS is not intended as a general-purpose Network Access Server
- (NAS) management protocol, and allocations should not be made for
- purposes unrelated to Authentication, Authorization or Accounting.
-
-6.1. Definition of Terms
-
- The following terms are used here with the meanings defined in
- BCP 26: "name space", "assigned value", "registration".
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 64]
-\f
-RFC 2865 RADIUS June 2000
-
-
- The following policies are used here with the meanings defined in
- BCP 26: "Private Use", "First Come First Served", "Expert Review",
- "Specification Required", "IETF Consensus", "Standards Action".
-
-6.2. Recommended Registration Policies
-
- For registration requests where a Designated Expert should be
- consulted, the IESG Area Director for Operations should appoint the
- Designated Expert.
-
- For registration requests requiring Expert Review, the ietf-radius
- mailing list should be consulted.
-
- Packet Type Codes have a range from 1 to 254, of which 1-5,11-13 have
- been allocated. Because a new Packet Type has considerable impact on
- interoperability, a new Packet Type Code requires Standards Action,
- and should be allocated starting at 14.
-
- Attribute Types have a range from 1 to 255, and are the scarcest
- resource in RADIUS, thus must be allocated with care. Attributes
- 1-53,55,60-88,90-91 have been allocated, with 17 and 21 available for
- re-use. Attributes 17, 21, 54, 56-59, 89, 92-191 may be allocated
- following Expert Review, with Specification Required. Release of
- blocks of Attribute Types (more than 3 at a time for a given purpose)
- should require IETF Consensus. It is recommended that attributes 17
- and 21 be used only after all others are exhausted.
-
- Note that RADIUS defines a mechanism for Vendor-Specific extensions
- (Attribute 26) and the use of that should be encouraged instead of
- allocation of global attribute types, for functions specific only to
- one vendor's implementation of RADIUS, where no interoperability is
- deemed useful.
-
- As stated in the "Attributes" section above:
-
- "[Attribute Type] Values 192-223 are reserved for experimental
- use, values 224-240 are reserved for implementation-specific use,
- and values 241-255 are reserved and should not be used."
-
- Therefore Attribute values 192-240 are considered Private Use, and
- values 241-255 require Standards Action.
-
- Certain attributes (for example, NAS-Port-Type) in RADIUS define a
- list of values to correspond with various meanings. There can be 4
- billion (2^32) values for each attribute. Adding additional values to
- the list can be done on a First Come, First Served basis by the IANA.
-
-
-
-
-
-Rigney, et al. Standards Track [Page 65]
-\f
-RFC 2865 RADIUS June 2000
-
-
-7. Examples
-
- A few examples are presented to illustrate the flow of packets and
- use of typical attributes. These examples are not intended to be
- exhaustive, many others are possible. Hexadecimal dumps of the
- example packets are given in network byte order, using the shared
- secret "xyzzy5461".
-
-7.1. User Telnet to Specified Host
-
- The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
- RADIUS Server for a user named nemo logging in on port 3 with
- password "arctangent".
-
- The Request Authenticator is a 16 octet random number generated by
- the NAS.
-
- The User-Password is 16 octets of password padded at end with nulls,
- XORed with MD5(shared secret|Request Authenticator).
-
- 01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb
- 98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d
- 93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8
- 01 10 05 06 00 00 00 03
-
- 1 Code = Access-Request (1)
- 1 ID = 0
- 2 Length = 56
- 16 Request Authenticator
-
- Attributes:
- 6 User-Name = "nemo"
- 18 User-Password
- 6 NAS-IP-Address = 192.168.1.16
- 6 NAS-Port = 3
-
- The RADIUS server authenticates nemo, and sends an Access-Accept UDP
- packet to the NAS telling it to telnet nemo to host 192.168.1.3.
-
- The Response Authenticator is a 16-octet MD5 checksum of the code
- (2), id (0), Length (38), the Request Authenticator from above, the
- attributes in this reply, and the shared secret.
-
-
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 66]
-\f
-RFC 2865 RADIUS June 2000
-
-
- 02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf
- 9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00
- 0e 06 c0 a8 01 03
-
- 1 Code = Access-Accept (2)
- 1 ID = 0 (same as in Access-Request)
- 2 Length = 38
- 16 Response Authenticator
-
- Attributes:
- 6 Service-Type (6) = Login (1)
- 6 Login-Service (15) = Telnet (0)
- 6 Login-IP-Host (14) = 192.168.1.3
-
-7.2. Framed User Authenticating with CHAP
-
- The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
- RADIUS Server for a user named flopsy logging in on port 20 with PPP,
- authenticating using CHAP. The NAS sends along the Service-Type and
- Framed-Protocol attributes as a hint to the RADIUS server that this
- user is looking for PPP, although the NAS is not required to do so.
-
- The Request Authenticator is a 16 octet random number generated by
- the NAS, and is also used as the CHAP Challenge.
-
- The CHAP-Password consists of a 1 octet CHAP ID, in this case 22,
- followed by the 16 octet CHAP response.
-
- 01 01 00 47 2a ee 86 f0 8d 0d 55 96 9c a5 97 8e
- 0d 33 67 a2 01 08 66 6c 6f 70 73 79 03 13 16 e9
- 75 57 c3 16 18 58 95 f2 93 ff 63 44 07 72 75 04
- 06 c0 a8 01 10 05 06 00 00 00 14 06 06 00 00 00
- 02 07 06 00 00 00 01
-
- 1 Code = 1 (Access-Request)
- 1 ID = 1
- 2 Length = 71
- 16 Request Authenticator
-
- Attributes:
- 8 User-Name (1) = "flopsy"
- 19 CHAP-Password (3)
- 6 NAS-IP-Address (4) = 192.168.1.16
- 6 NAS-Port (5) = 20
- 6 Service-Type (6) = Framed (2)
- 6 Framed-Protocol (7) = PPP (1)
-
-
-
-
-
-Rigney, et al. Standards Track [Page 67]
-\f
-RFC 2865 RADIUS June 2000
-
-
- The RADIUS server authenticates flopsy, and sends an Access-Accept
- UDP packet to the NAS telling it to start PPP service and assign an
- address for the user out of its dynamic address pool.
-
- The Response Authenticator is a 16-octet MD5 checksum of the code
- (2), id (1), Length (56), the Request Authenticator from above, the
- attributes in this reply, and the shared secret.
-
- 02 01 00 38 15 ef bc 7d ab 26 cf a3 dc 34 d9 c0
- 3c 86 01 a4 06 06 00 00 00 02 07 06 00 00 00 01
- 08 06 ff ff ff fe 0a 06 00 00 00 02 0d 06 00 00
- 00 01 0c 06 00 00 05 dc
-
- 1 Code = Access-Accept (2)
- 1 ID = 1 (same as in Access-Request)
- 2 Length = 56
- 16 Response Authenticator
-
- Attributes:
- 6 Service-Type (6) = Framed (2)
- 6 Framed-Protocol (7) = PPP (1)
- 6 Framed-IP-Address (8) = 255.255.255.254
- 6 Framed-Routing (10) = None (0)
- 6 Framed-Compression (13) = VJ TCP/IP Header Compression (1)
- 6 Framed-MTU (12) = 1500
-
-7.3. User with Challenge-Response card
-
- The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
- RADIUS Server for a user named mopsy logging in on port 7. The user
- enters the dummy password "challenge" in this example. The challenge
- and response generated by the smart card for this example are
- "32769430" and "99101462".
-
- The Request Authenticator is a 16 octet random number generated by
- the NAS.
-
- The User-Password is 16 octets of password, in this case "challenge",
- padded at the end with nulls, XORed with MD5(shared secret|Request
- Authenticator).
-
- 01 02 00 39 f3 a4 7a 1f 6a 6d 76 71 0b 94 7a b9
- 30 41 a0 39 01 07 6d 6f 70 73 79 02 12 33 65 75
- 73 77 82 89 b5 70 88 5e 15 08 48 25 c5 04 06 c0
- a8 01 10 05 06 00 00 00 07
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 68]
-\f
-RFC 2865 RADIUS June 2000
-
-
- 1 Code = Access-Request (1)
- 1 ID = 2
- 2 Length = 57
- 16 Request Authenticator
-
- Attributes:
- 7 User-Name (1) = "mopsy"
- 18 User-Password (2)
- 6 NAS-IP-Address (4) = 192.168.1.16
- 6 NAS-Port (5) = 7
-
- The RADIUS server decides to challenge mopsy, sending back a
- challenge string and looking for a response. The RADIUS server
- therefore and sends an Access-Challenge UDP packet to the NAS.
-
- The Response Authenticator is a 16-octet MD5 checksum of the code
- (11), id (2), length (78), the Request Authenticator from above, the
- attributes in this reply, and the shared secret.
-
- The Reply-Message is "Challenge 32769430. Enter response at prompt."
-
- The State is a magic cookie to be returned along with user's
- response; in this example 8 octets of data (33 32 37 36 39 34 33 30
- in hex).
-
- 0b 02 00 4e 36 f3 c8 76 4a e8 c7 11 57 40 3c 0c
- 71 ff 9c 45 12 30 43 68 61 6c 6c 65 6e 67 65 20
- 33 32 37 36 39 34 33 30 2e 20 20 45 6e 74 65 72
- 20 72 65 73 70 6f 6e 73 65 20 61 74 20 70 72 6f
- 6d 70 74 2e 18 0a 33 32 37 36 39 34 33 30
-
- 1 Code = Access-Challenge (11)
- 1 ID = 2 (same as in Access-Request)
- 2 Length = 78
- 16 Response Authenticator
-
- Attributes:
- 48 Reply-Message (18)
- 10 State (24)
-
- The user enters his response, and the NAS send a new Access-Request
- with that response, and includes the State Attribute.
-
- The Request Authenticator is a new 16 octet random number.
-
- The User-Password is 16 octets of the user's response, in this case
- "99101462", padded at the end with nulls, XORed with MD5(shared
- secret|Request Authenticator).
-
-
-
-Rigney, et al. Standards Track [Page 69]
-\f
-RFC 2865 RADIUS June 2000
-
-
- The state is the magic cookie from the Access-Challenge packet,
- unchanged.
-
- 01 03 00 43 b1 22 55 6d 42 8a 13 d0 d6 25 38 07
- c4 57 ec f0 01 07 6d 6f 70 73 79 02 12 69 2c 1f
- 20 5f c0 81 b9 19 b9 51 95 f5 61 a5 81 04 06 c0
- a8 01 10 05 06 00 00 00 07 18 10 33 32 37 36 39
- 34 33 30
-
- 1 Code = Access-Request (1)
- 1 ID = 3 (Note that this changes.)
- 2 Length = 67
- 16 Request Authenticator
-
- Attributes:
- 7 User-Name = "mopsy"
- 18 User-Password
- 6 NAS-IP-Address (4) = 192.168.1.16
- 6 NAS-Port (5) = 7
- 10 State (24)
-
- The Response was incorrect (for the sake of example), so the RADIUS
- server tells the NAS to reject the login attempt.
-
- The Response Authenticator is a 16 octet MD5 checksum of the code
- (3), id (3), length(20), the Request Authenticator from above, the
- attributes in this reply (in this case, none), and the shared secret.
-
- 03 03 00 14 a4 2f 4f ca 45 91 6c 4e 09 c8 34 0f
- 9e 74 6a a0
-
- 1 Code = Access-Reject (3)
- 1 ID = 3 (same as in Access-Request)
- 2 Length = 20
- 16 Response Authenticator
-
- Attributes:
- (none, although a Reply-Message could be sent)
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 70]
-\f
-RFC 2865 RADIUS June 2000
-
-
-8. Security Considerations
-
- Security issues are the primary topic of this document.
-
- In practice, within or associated with each RADIUS 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. Instead, for each named user 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. It is possible to achieve this with SNMP Security
- Protocols [14], but such a mechanism is outside the scope of this
- specification.
-
- Other distribution methods are currently undergoing research and
- experimentation. The SNMP Security document [14] also has an
- excellent overview of threats to network protocols.
-
- The User-Password hiding mechanism described in Section 5.2 has not
- been subjected to significant amounts of cryptanalysis in the
- published literature. Some in the IETF community are concerned that
- this method might not provide sufficient confidentiality protection
- [15] to passwords transmitted using RADIUS. Users should evaluate
- their threat environment and consider whether additional security
- mechanisms should be employed.
-
-9. Change Log
-
- The following changes have been made from RFC 2138:
-
- Strings should use UTF-8 instead of US-ASCII and should be handled as
- 8-bit data.
-
- Integers and dates are now defined as 32 bit unsigned values.
-
-
-
-Rigney, et al. Standards Track [Page 71]
-\f
-RFC 2865 RADIUS June 2000
-
-
- Updated list of attributes that can be included in Access-Challenge
- to be consistent with the table of attributes.
-
- User-Name mentions Network Access Identifiers.
-
- User-Name may now be sent in Access-Accept for use with accounting
- and Rlogin.
-
- Values added for Service-Type, Login-Service, Framed-Protocol,
- Framed-Compression, and NAS-Port-Type.
-
- NAS-Port can now use all 32 bits.
-
- Examples now include hexadecimal displays of the packets.
-
- Source UDP port must be used in conjunction with the Request
- Identifier when identifying duplicates.
-
- Multiple subattributes may be allowed in a Vendor-Specific attribute.
-
- An Access-Request is now required to contain either a NAS-IP-Address
- or NAS-Identifier (or may contain both).
-
- Added notes under "Operations" with more information on proxy,
- retransmissions, and keep-alives.
-
- If multiple Attributes with the same Type are present, the order of
- Attributes with the same Type MUST be preserved by any proxies.
-
- Clarified Proxy-State.
-
- Clarified that Attributes must not depend on position within the
- packet, as long as Attributes of the same type are kept in order.
-
- Added IANA Considerations section.
-
- Updated section on "Proxy" under "Operations".
-
- Framed-MTU can now be sent in Access-Request as a hint.
-
- Updated Security Considerations.
-
- Text strings identified as a subset of string, to clarify use of
- UTF-8.
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 72]
-\f
-RFC 2865 RADIUS June 2000
-
-
-10. References
-
- [1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
- Authentication Dial In User Service (RADIUS)", RFC 2138, April
- 1997.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", BCP 14, RFC 2119, March, 1997.
-
- [3] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm",
- RFC 1321, April 1992.
-
- [4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
- 1980.
-
- [5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
-
- [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
- 1700, October 1994.
-
- [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
- 2279, January 1998.
-
- [8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
- 2486, January 1999.
-
- [9] Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
- Private Communications in a Public World", Prentice Hall, March
- 1995, ISBN 0-13-061466-1.
-
- [10] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
- links", RFC 1144, February 1990.
-
- [11] ISO 8859. International Standard -- Information Processing --
- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
- Alphabet No. 1, ISO 8859-1:1987.
-
- [12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
- Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August
- 1996.
-
- [13] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
- Considerations Section in RFCs", BCP 26, RFC 2434, October
- 1998.
-
- [14] Galvin, J., McCloghrie, K. and J. Davin, "SNMP Security
- Protocols", RFC 1352, July 1992.
-
-
-
-
-Rigney, et al. Standards Track [Page 73]
-\f
-RFC 2865 RADIUS June 2000
-
-
- [15] Dobbertin, H., "The Status of MD5 After a Recent Attack",
- CryptoBytes Vol.2 No.2, Summer 1996.
-
-11. Acknowledgements
-
- RADIUS was originally developed by Steve Willens of Livingston
- Enterprises for their PortMaster series of Network Access Servers.
-
-12. Chair's Address
-
- The working group can be contacted via the current chair:
-
- Carl Rigney
- Livingston Enterprises
- 4464 Willow Road
- Pleasanton, California 94588
-
- Phone: +1 925 737 2100
- EMail: cdr@telemancy.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 74]
-\f
-RFC 2865 RADIUS June 2000
-
-
-13. Authors' Addresses
-
- Questions about this memo can also be directed to:
-
- Carl Rigney
- Livingston Enterprises
- 4464 Willow Road
- Pleasanton, California 94588
-
- Phone: +1 925 737 2100
- EMail: cdr@telemancy.com
-
-
- Allan C. Rubens
- Merit Network, Inc.
- 4251 Plymouth Road
- Ann Arbor, Michigan 48105-2785
-
- EMail: acr@merit.edu
-
-
- William Allen Simpson
- Daydreamer
- Computer Systems Consulting Services
- 1384 Fontaine
- Madison Heights, Michigan 48071
-
- EMail: wsimpson@greendragon.com
-
-
- Steve Willens
- Livingston Enterprises
- 4464 Willow Road
- Pleasanton, California 94588
-
- EMail: steve@livingston.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 75]
-\f
-RFC 2865 RADIUS June 2000
-
-
-14. Full Copyright Statement
-
- Copyright (C) The Internet Society (2000). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Rigney, et al. Standards Track [Page 76]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group B. Aboba
-Request for Comments: 3579 Microsoft
-Updates: 2869 P. Calhoun
-Category: Informational Airespace
- September 2003
-
-
- RADIUS (Remote Authentication Dial In User Service)
- Support For Extensible Authentication Protocol (EAP)
-
-Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
-Abstract
-
- This document defines Remote Authentication Dial In User Service
- (RADIUS) support for the Extensible Authentication Protocol (EAP), an
- authentication framework which supports multiple authentication
- mechanisms. In the proposed scheme, the Network Access Server (NAS)
- forwards EAP packets to and from the RADIUS server, encapsulated
- within EAP-Message attributes. This has the advantage of allowing
- the NAS to support any EAP authentication method, without the need
- for method-specific code, which resides on the RADIUS server. While
- EAP was originally developed for use with PPP, it is now also in use
- with IEEE 802.
-
- This document updates RFC 2869.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 1]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
- 1.1. Specification of Requirements. . . . . . . . . . . . . . 3
- 1.2. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3
- 2. RADIUS Support for EAP . . . . . . . . . . . . . . . . . . . . 4
- 2.1. Protocol Overview. . . . . . . . . . . . . . . . . . . . 5
- 2.2. Invalid Packets. . . . . . . . . . . . . . . . . . . . . 9
- 2.3. Retransmission . . . . . . . . . . . . . . . . . . . . . 10
- 2.4. Fragmentation. . . . . . . . . . . . . . . . . . . . . . 10
- 2.5. Alternative uses . . . . . . . . . . . . . . . . . . . . 11
- 2.6. Usage Guidelines . . . . . . . . . . . . . . . . . . . . 11
- 3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 14
- 3.1. EAP-Message. . . . . . . . . . . . . . . . . . . . . . . 15
- 3.2. Message-Authenticator. . . . . . . . . . . . . . . . . . 16
- 3.3. Table of Attributes. . . . . . . . . . . . . . . . . . . 18
- 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
- 4.1. Security Requirements. . . . . . . . . . . . . . . . . . 19
- 4.2. Security Protocol. . . . . . . . . . . . . . . . . . . . 20
- 4.3. Security Issues. . . . . . . . . . . . . . . . . . . . . 22
- 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 30
- 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
- 6.1. Normative References . . . . . . . . . . . . . . . . . . 30
- 6.2. Informative References . . . . . . . . . . . . . . . . . 32
- Appendix A - Examples. . . . . . . . . . . . . . . . . . . . . . . 34
- Appendix B - Change Log. . . . . . . . . . . . . . . . . . . . . . 43
- Intellectual Property Statement. . . . . . . . . . . . . . . . . . 44
- Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 44
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 46
-
-1. Introduction
-
- The Remote Authentication Dial In User Service (RADIUS) is an
- authentication, authorization and accounting protocol used to control
- network access. RADIUS authentication and authorization is specified
- in [RFC2865], and RADIUS accounting is specified in [RFC2866]; RADIUS
- over IPv6 is specified in [RFC3162].
-
- The Extensible Authentication Protocol (EAP), defined in [RFC2284],
- is an authentication framework which supports multiple authentication
- mechanisms. EAP may be used on dedicated links, switched circuits,
- and wired as well as wireless links.
-
- To date, EAP has been implemented with hosts and routers that connect
- via switched circuits or dial-up lines using PPP [RFC1661]. It has
- also been implemented with bridges supporting [IEEE802]. EAP
- encapsulation on IEEE 802 wired media is described in [IEEE8021X].
-
-
-
-Aboba & Calhoun Informational [Page 2]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- RADIUS attributes are comprised of variable length Type-Length-Value
- 3-tuples. New attribute values can be added without disturbing
- existing implementations of the protocol. This specification
- describes RADIUS attributes supporting the Extensible Authentication
- Protocol (EAP): EAP-Message and Message-Authenticator. These
- attributes now have extensive field experience. The purpose of this
- document is to provide clarification and resolve interoperability
- issues.
-
- As noted in [RFC2865], a Network Access Server (NAS) that does not
- implement a given service MUST NOT implement the RADIUS attributes
- for that service. This implies that a NAS that is unable to offer
- EAP service MUST NOT implement the RADIUS attributes for EAP. A NAS
- MUST treat a RADIUS Access-Accept requesting an unavailable service
- as an Access-Reject instead.
-
-1.1. Specification of Requirements
-
- In this document, several words are used to signify the requirements
- of the specification. These words are often capitalized. 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].
-
-1.2. Terminology
-
- This document frequently uses the following terms:
-
- authenticator
- The end of the link requiring the authentication. Also
- known as the Network Access Server (NAS) or RADIUS client.
- Within IEEE 802.1X terminology, the term Authenticator is
- used.
-
- peer The other end of the point-to-point link (PPP),
- point-to-point LAN segment (IEEE 802.1X) or wireless link,
- which is being authenticated by the authenticator. In IEEE
- 802.1X, this end is known as the Supplicant.
-
- authentication server
- An authentication server is an entity that provides an
- authentication service to an authenticator (NAS). This
- service verifies from the credentials provided by the peer,
- the claim of identity made by the peer; it also may provide
- credentials allowing the peer to verify the identity of the
- authentication server. Within this document it is assumed
- that the NAS operates as a pass-through, forwarding EAP
- packets between the RADIUS server and the EAP peer.
-
-
-
-Aboba & Calhoun Informational [Page 3]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- Therefore the RADIUS server operates as an authentication
- server.
-
- 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.
-
- displayable message
- This is interpreted to be a human readable string of
- characters, and MUST NOT affect operation of the protocol.
- The message encoding MUST follow the UTF-8 transformation
- format [RFC2279].
-
- Network Access Server (NAS)
- The device providing access to the network. Also known as
- the Authenticator (IEEE 802.1X or EAP terminology) or
- RADIUS client.
-
- service The NAS provides a service to the user, such as IEEE 802 or
- PPP.
-
- session Each service provided by the NAS to a peer constitutes a
- session, with the beginning of the session defined as the
- point where service is first provided and the end of the
- session defined as the point where service is ended. A
- peer may have multiple sessions in parallel or series if
- the NAS supports that, with each session generating a
- separate start and stop accounting record.
-
-2. RADIUS Support for EAP
-
- The Extensible Authentication Protocol (EAP), described in [RFC2284],
- provides a standard mechanism for support of additional
- authentication methods without the NAS to be upgraded to support each
- new method. Through the use of EAP, support for a number of
- authentication schemes may be added, including smart cards, Kerberos
- [RFC1510], Public Key [RFC2716], One Time Passwords [RFC2284], and
- others.
-
- One of the advantages of the EAP architecture is its flexibility.
- EAP is used to select a specific authentication mechanism. Rather
- than requiring the NAS to be updated to support each new
- authentication method, EAP permits the use of an authentication
- server implementing authentication methods, with the NAS acting as a
- pass-through for some or all methods and peers.
-
-
-
-Aboba & Calhoun Informational [Page 4]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- A NAS MAY authenticate local peers while at the same time acting as a
- pass-through for non-local peers and authentication methods it does
- not implement locally. A NAS implementing this specification is not
- required to use RADIUS to authenticate every peer. However, once the
- NAS begins acting as a pass-through for a particular session, it can
- no longer perform local authentication for that session.
-
- In order to support EAP within RADIUS, two new attributes,
- EAP-Message and Message-Authenticator, are introduced in this
- document. This section describes how these new attributes may be
- used for providing EAP support within RADIUS.
-
-2.1. Protocol Overview
-
- In RADIUS/EAP, RADIUS is used to shuttle RADIUS-encapsulated EAP
- Packets between the NAS and an authentication server.
-
- The authenticating peer and the NAS begin the EAP conversation by
- negotiating use of EAP. Once EAP has been negotiated, the NAS SHOULD
- send an initial EAP-Request message to the authenticating peer. This
- will typically be an EAP-Request/Identity, although it could be an
- EAP-Request for an authentication method (Types 4 and greater). A
- NAS MAY be configured to initiate with a default authentication
- method. This is useful in cases where the identity is determined by
- another means (such as Called-Station-Id, Calling-Station-Id and/or
- Originating-Line-Info); where a single authentication method is
- required, which includes its own identity exchange; where identity
- hiding is desired, so that the identity is not requested until after
- a protected channel has been set up.
-
- The peer replies with an EAP-Response. The NAS MAY determine from
- the Response that it should proceed with local authentication.
- Alternatively, the NAS MAY act as a pass-through, encapsulating the
- EAP-Response within EAP-Message attribute(s) sent to the RADIUS
- server within a RADIUS Access-Request packet. If the NAS sends an
- EAP-Request/Identity message as the initial packet, the peer responds
- with an EAP-Response/Identity. The NAS may determine that the peer
- is local and proceed with local authentication. If no match is found
- against the list of local users, the NAS encapsulates the
- EAP-Response/Identity message within an EAP-Message attribute,
- enclosed within an Access-Request packet.
-
- On receiving a valid Access-Request packet containing EAP-Message
- attribute(s), a RADIUS server compliant with this specification and
- wishing to authenticate with EAP MUST respond with an
- Access-Challenge packet containing EAP-Message attribute(s). If the
- RADIUS server does not support EAP or does not wish to authenticate
- with EAP, it MUST respond with an Access-Reject.
-
-
-
-Aboba & Calhoun Informational [Page 5]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- EAP-Message attribute(s) encapsulate a single EAP packet which the
- NAS decapsulates and passes on to the authenticating peer. The peer
- then responds with an EAP-Response packet, which the NAS encapsulates
- within an Access-Request containing EAP-Message attribute(s). EAP is
- a 'lock step' protocol, so that other than the initial Request, a new
- Request cannot be sent prior to receiving a valid Response.
-
- The conversation continues until either a RADIUS Access-Reject or
- Access-Accept packet is received from the RADIUS server. Reception
- of a RADIUS Access-Reject packet MUST result in the NAS denying
- access to the authenticating peer. A RADIUS Access-Accept packet
- successfully ends the authentication phase. The NAS MUST NOT
- "manufacture" a Success or Failure packet as the result of a timeout.
- After a suitable number of timeouts have elapsed, the NAS SHOULD
- instead end the EAP conversation.
-
- Using RADIUS, the NAS can act as a pass-through for an EAP
- conversation between the peer and authentication server, without
- needing to implement the EAP method used between them. Where the NAS
- initiates the conversation by sending an EAP-Request for an
- authentication method, it may not be required that the NAS fully
- implement the EAP method reflected in the initial EAP-Request.
- Depending on the initial method, it may be sufficient for the NAS to
- be configured with the initial packet to be sent to the peer, and for
- the NAS to act as a pass-through for subsequent messages. Note that
- since the NAS only encapsulates the EAP-Response in its initial
- Access-Request, the initial EAP-Request within the authentication
- method is not available to the RADIUS server. For the RADIUS server
- to be able to continue the conversation, either the initial
- EAP-Request is vestigial, so that the RADIUS server need not be aware
- of it, or the relevant information from the initial EAP-Request (such
- as a nonce) is reflected in the initial EAP-Response, so that the
- RADIUS server can obtain it without having received the initial
- EAP-Request.
-
- Where the initial EAP-Request sent by the NAS is for an
- authentication Type (4 or greater), the peer MAY respond with a Nak
- indicating that it would prefer another authentication method that is
- not implemented locally. In this case, the NAS SHOULD send
- Access-Request encapsulating the received EAP-Response/Nak. This
- provides the RADIUS server with a hint about the authentication
- method(s) preferred by the peer, although it does not provide
- information on the Type of the original Request. It also provides
- the server with the Identifier used in the initial EAP-Request, so
- that Identifier conflicts can be avoided.
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 6]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- In order to evaluate whether the alternatives preferred by the
- authenticating peer are allowed, the RADIUS server will typically
- respond with an Access-Challenge containing EAP-Message attribute(s)
- encapsulating an EAP-Request/Identity (Type 1). This allows the
- RADIUS server to determine the peer identity, so as to be able to
- retrieve the associated authentication policy. Alternatively, an
- EAP-Request for an authentication method (Type 4 or greater) could be
- sent. Since the RADIUS server may not be aware of the Type of the
- initial EAP-Request, it is possible for the RADIUS server to choose
- an unacceptable method, and for the peer to respond with another Nak.
-
- In order to permit non-EAP aware RADIUS proxies to forward the
- Access-Request packet, if the NAS initially sends an
- EAP-Request/Identity message to the peer, the NAS MUST copy the
- contents of the Type-Data field of the EAP-Response/Identity received
- from the peer into the User-Name attribute and MUST include the
- Type-Data field of the EAP-Response/Identity in the User-Name
- attribute in every subsequent Access-Request. Since RADIUS proxies
- are assumed to act as a pass-through, they cannot be expected to
- parse an EAP-Response/Identity encapsulated within EAP-Message
- attribute(s). If the NAS initially sends an EAP-Request for an
- authentication method, and the peer identity cannot be determined
- from the EAP-Response, then the User-Name attribute SHOULD be
- determined by another means. As noted in [RFC2865] Section 5.6, it
- is recommended that Access-Requests use the value of the
- Calling-Station-Id as the value of the User-Name attribute.
-
- Having the NAS send the initial EAP-Request packet has a number of
- advantages:
-
- [1] It saves a round trip between the NAS and RADIUS server.
-
- [2] An Access-Request is only sent to the RADIUS server if the
- authenticating peer sends an EAP-Response, confirming that it
- supports EAP. In situations where peers may be EAP unaware,
- initiating a RADIUS Access-Request on a "carrier sense" or
- "media up" indication may result in many authentication
- exchanges that cannot complete successfully. For example, on
- wired networks [IEEE8021X] Supplicants typically do not initiate
- the 802.1X conversation with an EAPOL-Start. Therefore an IEEE
- 802.1X-enabled bridge may not be able to determine whether the
- peer supports EAP until it receives a Response to the initial
- EAP-Request.
-
- [3] It allows some peers to be authenticated locally.
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 7]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- Although having the NAS send the initial EAP-Request packet has
- substantial advantages, this technique cannot be universally
- employed. There are circumstances in which the peer identity is
- already known (such as when authentication and accounting is handled
- based on Called-Station-Id, Calling-Station-Id and/or
- Originating-Line-Info), but where the appropriate EAP method may vary
- based on that identity.
-
- Rather than sending an initial EAP-Request packet to the
- authenticating peer, on detecting the presence of the peer, the NAS
- MAY send an Access-Request packet to the RADIUS server containing an
- EAP-Message attribute signifying EAP-Start. The RADIUS server will
- typically respond with an Access-Challenge containing EAP-Message
- attribute(s) encapsulating an EAP-Request/Identity (Type 1).
- However, an EAP-Request for an authentication method (Type 4 or
- greater) can also be sent by the server.
-
- EAP-Start is indicated by sending an EAP-Message attribute with a
- length of 2 (no data). The Calling-Station-Id SHOULD be included in
- the User-Name attribute. This may result in a RADIUS Access-Request
- being sent by the NAS to the RADIUS server without first confirming
- that the peer supports EAP. Since this technique can result in a
- large number of uncompleted RADIUS conversations, in situations where
- EAP unaware peers are common, or where peer support for EAP cannot be
- determined on initial contact (e.g. [IEEE8021X] Supplicants not
- initiating the conversation with an EAPOL-Start) it SHOULD NOT be
- employed by default.
-
- For proxied RADIUS requests, there are two methods of processing. If
- the domain is determined based on the Calling-Station-Id,
- Called-Station-Id and/or Originating-Line-Info, the RADIUS server may
- proxy the initial RADIUS Access-Request/EAP-Start. If the realm is
- determined based on the peer identity, the local RADIUS server MUST
- respond with a RADIUS Access-Challenge including an EAP-Message
- attribute encapsulating an EAP-Request/Identity packet. The response
- from the authenticating peer SHOULD be proxied to the final
- authentication server.
-
- If an Access-Request is sent to a RADIUS server which does not
- support the EAP-Message attribute, then an Access-Reject MUST be sent
- in response. On receiving an Access-Reject, the NAS MUST deny access
- to the authenticating peer.
-
-
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 8]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
-2.2. Invalid Packets
-
- While acting as a pass-through, the NAS MUST validate the EAP header
- fields (Code, Identifier, Length) prior to forwarding an EAP packet
- to or from the RADIUS server. On receiving an EAP packet from the
- peer, the NAS checks the Code (2) and Length fields, and matches the
- Identifier value against the current Identifier, supplied by the
- RADIUS server in the most recently validated EAP-Request. On
- receiving an EAP packet from the RADIUS server (encapsulated within
- an Access-Challenge), the NAS checks the Code (1) and Length fields,
- then updates the current Identifier value. Pending EAP Responses
- that do not match the current Identifier value are silently discarded
- by the NAS.
-
- Since EAP method fields (Type, Type-Data) are typically not validated
- by a NAS operating as a pass-through, despite these checks it is
- possible for a NAS to forward an invalid EAP packet to or from the
- RADIUS server. A RADIUS server receiving EAP-Message attribute(s) it
- does not understand SHOULD make the determination of whether the
- error is fatal or non-fatal based on the EAP Type. A RADIUS server
- determining that a fatal error has occurred MUST send an
- Access-Reject containing an EAP-Message attribute encapsulating
- EAP-Failure.
-
- A RADIUS server determining that a non-fatal error has occurred MAY
- send an Access-Challenge to the NAS including EAP-Message
- attribute(s) as well as an Error-Cause attribute [RFC3576] with value
- 202 (decimal), "Invalid EAP Packet (Ignored)". The Access-Challenge
- SHOULD encapsulate within EAP-Message attribute(s) the most recently
- sent EAP-Request packet (including the same Identifier value). On
- receiving such an Access-Challenge, a NAS implementing previous
- versions of this specification will decapsulate the EAP-Request and
- send it to the peer, which will retransmit the EAP-Response.
-
- A NAS compliant with this specification, on receiving an
- Access-Challenge with an Error-Cause attribute of value 202 (decimal)
- SHOULD discard the EAP-Response packet most recently transmitted to
- the RADIUS server and check whether additional EAP-Response packets
- have been received matching the current Identifier value. If so, a
- new EAP-Response packet, if available, MUST be sent to the RADIUS
- server within an Access-Request, and the EAP-Message attribute(s)
- included within the Access-Challenge are silently discarded. If no
- EAP-Response packet is available, then the EAP-Request encapsulated
- within the Access-Challenge is sent to the peer, and the
- retransmission timer is reset.
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 9]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- In order to provide protection against Denial of Service (DoS)
- attacks, it is advisable for the NAS to allocate a finite buffer for
- EAP packets received from the peer, and to discard packets according
- to an appropriate policy once that buffer has been exceeded. Also,
- the RADIUS server is advised to permit only a modest number of
- invalid EAP packets within a single session, prior to terminating the
- session with an Access-Reject. By default a value of 5 invalid EAP
- packets is recommended.
-
-2.3. Retransmission
-
- As noted in [RFC2284], if an EAP packet is lost in transit between
- the authenticating peer and the NAS (or vice versa), the NAS will
- retransmit.
-
- It may be necessary to adjust retransmission strategies and
- authentication timeouts in certain cases. For example, when a token
- card is used additional time may be required to allow the user to
- find the card and enter the token. Since the NAS will typically not
- have knowledge of the required parameters, these need to be provided
- by the RADIUS server. This can be accomplished by inclusion of
- Session-Timeout attribute within the Access-Challenge packet.
-
- If Session-Timeout is present in an Access-Challenge packet that also
- contains an EAP-Message, the value of the Session-Timeout is used to
- set the EAP retransmission timer for that EAP Request, and that
- Request alone. Once the EAP-Request has been sent, the NAS sets the
- retransmission timer, and if it expires without having received an
- EAP-Response corresponding to the Request, then the EAP-Request is
- retransmitted.
-
-2.4. Fragmentation
-
- Using the EAP-Message attribute, it is possible for the RADIUS server
- to encapsulate an EAP packet that is larger than the MTU on the link
- between the NAS and the peer. Since it is not possible for the
- RADIUS server to use MTU discovery to ascertain the link MTU, the
- Framed-MTU attribute may be included in an Access-Request packet
- containing an EAP-Message attribute so as to provide the RADIUS
- server with this information. A RADIUS server having received a
- Framed-MTU attribute in an Access-Request packet MUST NOT send any
- subsequent packet in this EAP conversation containing EAP-Message
- attributes whose values, when concatenated, exceed the length
- specified by the Framed-MTU value, taking the link type (specified by
- the NAS-Port-Type attribute) into account. For example, as noted in
- [RFC3580] Section 3.10, for a NAS-Port-Type value of IEEE 802.11, the
-
-
-
-
-
-Aboba & Calhoun Informational [Page 10]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- RADIUS server may send an EAP packet as large as Framed-MTU minus
- four (4) octets, taking into account the additional overhead for the
- IEEE 802.1X Version (1), Type (1) and Body Length (2) fields.
-
-2.5. Alternative Uses
-
- Currently the conversation between security servers and the RADIUS
- server is often proprietary because of lack of standardization. In
- order to increase standardization and provide interoperability
- between RADIUS vendors and security vendors, it is recommended that
- RADIUS- encapsulated EAP be used for this conversation.
-
- This has the advantage of allowing the RADIUS server to support EAP
- without the need for authentication-specific code within the RADIUS
- server. Authentication-specific code can then reside on a security
- server instead.
-
- In the case where RADIUS-encapsulated EAP is used in a conversation
- between a RADIUS server and a security server, the security server
- will typically return an Access-Accept message without inclusion of
- the expected attributes currently returned in an Access-Accept. This
- means that the RADIUS server MUST add these attributes prior to
- sending an Access-Accept message to the NAS.
-
-2.6. Usage Guidelines
-
-2.6.1. Identifier Space
-
- In EAP, each session has its own unique Identifier space. RADIUS
- server implementations MUST be able to distinguish between EAP
- packets with the same Identifier existing within distinct sessions,
- originating on the same NAS. For this purpose, sessions can be
- distinguished based on NAS and session identification attributes.
- NAS identification attributes include NAS-Identifier,
- NAS-IPv6-Address and NAS-IPv4-Address. Session identification
- attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port-Id,
- Called-Station-Id, Calling-Station-Id and Originating-Line-Info.
-
-2.6.2. Role Reversal
-
- Since EAP is a peer-to-peer protocol, an independent and simultaneous
- authentication may take place in the reverse direction. Both peers
- may act as authenticators and authenticatees at the same time.
-
- However, role reversal is not supported by this specification. A
- RADIUS server MUST respond to an Access-Request encapsulating an
- EAP-Request with an Access-Reject. In order to avoid retransmissions
-
-
-
-
-Aboba & Calhoun Informational [Page 11]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- by the peer, the Access-Reject SHOULD include an EAP-Response/Nak
- packet indicating no preferred method, encapsulated within
- EAP-Message attribute(s).
-
-2.6.3. Conflicting Messages
-
- The NAS MUST make its access control decision based solely on the
- RADIUS Packet Type (Access-Accept/Access-Reject). The access control
- decision MUST NOT be based on the contents of the EAP packet
- encapsulated in one or more EAP-Message attributes, if present.
-
- Access-Accept packets SHOULD have only one EAP-Message attribute in
- them, containing EAP Success; similarly, Access-Reject packets SHOULD
- have only one EAP-Message attribute in them, containing EAP Failure.
-
- Where the encapsulated EAP packet does not match the result implied
- by the RADIUS Packet Type, the combination is likely to cause
- confusion, because the NAS and peer will arrive at different
- conclusions as to the outcome of the authentication.
-
- For example, if the NAS receives an Access-Reject with an
- encapsulated EAP Success, it will not grant access to the peer.
- However, on receiving the EAP Success, the peer will be lead to
- believe that it authenticated successfully.
-
- If the NAS receives an Access-Accept with an encapsulated EAP
- Failure, it will grant access to the peer. However, on receiving an
- EAP Failure, the peer will be lead to believe that it failed
- authentication. If no EAP-Message attribute is included within an
- Access-Accept or Access-Reject, then the peer may not be informed as
- to the outcome of the authentication, while the NAS will take action
- to allow or deny access.
-
- As described in [RFC2284], the EAP Success and Failure packets are
- not acknowledged, and these packets terminate the EAP conversation.
- As a result, if these packets are encapsulated within an
- Access-Challenge, no response will be received, and therefore the NAS
- will send no further Access-Requests to the RADIUS server for the
- session. As a result, the RADIUS server will not indicate to the NAS
- whether to allow or deny access, while the peer will be informed as
- to the outcome of the authentication.
-
-
-
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 12]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- To avoid these conflicts, the following combinations SHOULD NOT be
- sent by a RADIUS server:
-
- Access-Accept/EAP-Message/EAP Failure
- Access-Accept/no EAP-Message attribute
- Access-Accept/EAP-Start
- Access-Reject/EAP-Message/EAP Success
- Access-Reject/no EAP-Message attribute
- Access-Reject/EAP-Start
- Access-Challenge/EAP-Message/EAP Success
- Access-Challenge/EAP-Message/EAP Failure
- Access-Challenge/no EAP-Message attribute
- Access-Challenge/EAP-Start
-
- Since the responsibility for avoiding conflicts lies with the RADIUS
- server, the NAS MUST NOT "manufacture" EAP packets in order to
- correct contradictory messages that it receives. This behavior,
- originally mandated within [IEEE8021X], will be deprecated in the
- future.
-
-2.6.4. Priority
-
- A RADIUS Access-Accept or Access-Reject packet may contain EAP-
- Message attribute(s). In order to ensure the correct processing of
- RADIUS packets, the NAS MUST first process the attributes, including
- the EAP-Message attribute(s), prior to processing the Accept/Reject
- indication.
-
-2.6.5. Displayable Messages
-
- The Reply-Message attribute, defined in [RFC2865], Section 5.18,
- indicates text which may be displayed to the peer. This is similar
- in concept to EAP Notification, defined in [RFC2284]. When sending a
- displayable message to a NAS during an EAP conversation, the RADIUS
- server MUST encapsulate displayable messages within
- EAP-Message/EAP-Request/Notification attribute(s). Reply-Message
- attribute(s) MUST NOT be included in any RADIUS message containing an
- EAP-Message attribute. An EAP-Message/EAP-Request/Notification
- SHOULD NOT be included within an Access-Accept or Access-Reject
- packet.
-
- In some existing implementations, a NAS receiving Reply-Message
- attribute(s) copies the Text field(s) into the Type-Data field of an
- EAP-Request/Notification packet, fills in the Identifier field, and
- sends this to the peer. However, several issues arise from this:
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 13]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- [1] Unexpected Responses. On receiving an EAP-Request/Notification,
- the peer will send an EAP-Response/Notification, and the NAS
- will pass this on to the RADIUS server, encapsulated within
- EAP-Message attribute(s). However, the RADIUS server may not be
- expecting an Access-Request containing an
- EAP-Message/EAP-Response/Notification attribute.
-
- For example, consider what happens when a Reply-Message is
- included within an Access-Accept or Access-Reject packet with no
- EAP-Message attribute(s) present. If the value of the
- Reply-Message attribute is copied into the Type-Data of an
- EAP-Request/Notification and sent to the peer, this will result
- in an Access-Request containing an
- EAP-Message/EAP-Response/Notification attribute being sent by
- the NAS to the RADIUS server. Since an Access-Accept or
- Access-Reject packet terminates the RADIUS conversation, such an
- Access-Request would not be expected, and could be interpreted
- as the start of another conversation.
-
- [2] Identifier conflicts. While the EAP-Request/Notification is an
- EAP packet containing an Identifier field, the Reply-Message
- attribute does not contain an Identifier field. As a result, a
- NAS receiving a Reply-Message attribute and wishing to translate
- this to an EAP-Request/Notification will need to choose an
- Identifier value. It is possible that the chosen Identifier
- value will conflict with a value chosen by the RADIUS server for
- another packet within the EAP conversation, potentially causing
- confusion between a new packet and a retransmission.
-
- To avoid these problems, a NAS receiving a Reply-Message attribute
- from the RADIUS server SHOULD silently discard the attribute, rather
- than attempting to translate it to an EAP Notification Request.
-
-3. Attributes
-
- The NAS-Port or NAS-Port-Id attributes SHOULD be included by the NAS
- in Access-Request packets, and either NAS-Identifier, NAS-IP-Address
- or NAS-IPv6-Address attributes MUST be included. In order to permit
- forwarding of the Access-Reply by EAP-unaware proxies, if a User-Name
- attribute was included in an Access-Request, the RADIUS server MUST
- include the User-Name attribute in subsequent Access-Accept packets.
- Without the User-Name attribute, accounting and billing becomes
- difficult to manage. The User-Name attribute within the Access-
- Accept packet need not be the same as the User-Name attribute in the
- Access-Request.
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 14]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
-3.1. EAP-Message
-
- Description
-
- This attribute encapsulates EAP [RFC2284] packets so as to allow
- the NAS to authenticate peers via EAP without having to understand
- the EAP method it is passing through.
-
- The NAS places EAP messages received from the authenticating peer
- into one or more EAP-Message attributes and forwards them to the
- RADIUS server within an Access-Request message. If multiple
- EAP-Message attributes are contained within an Access-Request or
- Access-Challenge packet, they MUST be in order and they MUST be
- consecutive attributes in the Access-Request or Access-Challenge
- packet. The RADIUS server can return EAP-Message attributes in
- Access-Challenge, Access-Accept and Access-Reject packets.
-
- When RADIUS is used to enable EAP authentication, Access-Request,
- Access-Challenge, Access-Accept, and Access-Reject packets SHOULD
- contain one or more EAP-Message attributes. Where more than one
- EAP-Message attribute is included, it is assumed that the
- attributes are to be concatenated to form a single EAP packet.
-
- Multiple EAP packets MUST NOT be encoded within EAP-Message
- attributes contained within a single Access-Challenge,
- Access-Accept, Access-Reject or Access-Request packet.
-
- It is expected that EAP will be used to implement a variety of
- authentication methods, including methods involving strong
- cryptography. In order to prevent attackers from subverting EAP
- by attacking RADIUS/EAP, (for example, by modifying EAP Success or
- EAP Failure packets) it is necessary that RADIUS provide
- per-packet authentication and integrity protection.
-
- Therefore the Message-Authenticator attribute MUST be used to
- protect all Access-Request, Access-Challenge, Access-Accept, and
- Access-Reject packets containing an EAP-Message attribute.
-
- Access-Request packets including EAP-Message attribute(s) without
- a Message-Authenticator attribute SHOULD be silently discarded by
- the RADIUS server. A RADIUS server supporting the EAP-Message
- attribute MUST calculate the correct value of the
- Message-Authenticator and MUST silently discard the packet if it
- does not match the value sent. A RADIUS server not supporting the
- EAP-Message attribute MUST return an Access-Reject if it receives
- an Access-Request containing an EAP-Message attribute.
-
-
-
-
-
-Aboba & Calhoun Informational [Page 15]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- Access-Challenge, Access-Accept, or Access-Reject packets
- including EAP-Message attribute(s) without a Message-Authenticator
- attribute SHOULD be silently discarded by the NAS. A NAS
- supporting the EAP-Message attribute MUST calculate the correct
- value of the Message-Authenticator and MUST silently discard the
- packet if it does not match the value sent.
-
- A summary of the EAP-Message attribute format is shown below. The
- fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | String...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 79 for EAP-Message
-
- Length
-
- >= 3
-
- String
-
- The String field contains an EAP packet, as defined in [RFC2284].
- If multiple EAP-Message attributes are present in a packet their
- values should be concatenated; this allows EAP packets longer than
- 253 octets to be transported by RADIUS.
-
-3.2. Message-Authenticator
-
- Description
-
- This attribute MAY be used to authenticate and integrity-protect
- Access-Requests in order to prevent spoofing. It MAY be used in
- any Access-Request. It MUST be used in any Access-Request,
- Access-Accept, Access-Reject or Access-Challenge that includes an
- EAP-Message attribute.
-
- A RADIUS server receiving an Access-Request with a
- Message-Authenticator attribute present MUST calculate the correct
- value of the Message-Authenticator and silently discard the packet
- if it does not match the value sent.
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 16]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- A RADIUS client receiving an Access-Accept, Access-Reject or
- Access-Challenge with a Message-Authenticator attribute present
- MUST calculate the correct value of the Message-Authenticator and
- silently discard the packet if it does not match the value sent.
-
- This attribute is not required in Access-Requests which include
- the User-Password attribute, but is useful for preventing attacks
- on other types of authentication. This attribute is intended to
- thwart attempts by an attacker to setup a "rogue" NAS, and perform
- online dictionary attacks against the RADIUS server. It does not
- afford protection against "offline" attacks where the attacker
- intercepts packets containing (for example) CHAP challenge and
- response, and performs a dictionary attack against those packets
- offline.
-
- A summary of the Message-Authenticator attribute format is shown
- below. The fields are transmitted from left to right.
-
- 0 1 2
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | String...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 80 for Message-Authenticator
-
- Length
-
- 18
-
- String
-
- When present in an Access-Request packet, Message-Authenticator is
- an HMAC-MD5 [RFC2104] hash of the entire Access-Request packet,
- including Type, ID, Length and Authenticator, using the shared
- secret as the key, as follows.
-
- Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
- Request Authenticator, Attributes)
-
- When the message integrity check is calculated the signature
- string should be considered to be sixteen octets of zero.
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 17]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- For Access-Challenge, Access-Accept, and Access-Reject packets,
- the Message-Authenticator is calculated as follows, using the
- Request-Authenticator from the Access-Request this packet is in
- reply to:
-
- Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
- Request Authenticator, Attributes)
-
- When the message integrity check is calculated the signature
- string should be considered to be sixteen octets of zero. The
- shared secret is used as the key for the HMAC-MD5 message
- integrity check. The Message-Authenticator is calculated and
- inserted in the packet before the Response Authenticator is
- calculated.
-
-3.3. Table of Attributes
-
- The following table provides a guide to which attributes may be found
- in packets including EAP-Message attribute(s), and in what quantity.
- The EAP-Message and Message-Authenticator attributes specified in
- this document MUST NOT be present in an Accounting-Request. If a
- table entry is omitted, the values found in [RFC2548], [RFC2865],
- [RFC2868], [RFC2869] and [RFC3162] should be assumed.
-
-Request Accept Reject Challenge # Attribute
-0-1 0-1 0 0 1 User-Name
-0 0 0 0 2 User-Password [Note 1]
-0 0 0 0 3 CHAP-Password [Note 1]
-0 0 0 0 18 Reply-Message
-0 0 0 0 60 CHAP-Challenge
-0 0 0 0 70 ARAP-Password [Note 1]
-0 0 0 0 75 Password-Retry
-1+ 1+ 1+ 1+ 79 EAP-Message [Note 1]
-1 1 1 1 80 Message-Authenticator [Note 1]
-0-1 0 0 0 94 Originating-Line-Info [Note 3]
-0 0 0-1 0-1 101 Error-Cause [Note 2]
-Request Accept Reject Challenge # Attribute
-
- [Note 1] An Access-Request that contains either a User-Password or
- CHAP-Password or ARAP-Password or one or more EAP-Message attributes
- MUST NOT contain more than one type of those four attributes. If it
- does not contain any of those four attributes, it SHOULD contain a
- Message-Authenticator. If any packet type contains an EAP-Message
- attribute it MUST also contain a Message-Authenticator. A RADIUS
- server receiving an Access-Request not containing any of those four
- attributes and also not containing a Message-Authenticator attribute
- SHOULD silently discard it.
-
-
-
-
-Aboba & Calhoun Informational [Page 18]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- [Note 2] The Error-Cause attribute is defined in [RFC3576].
-
- [Note 3] The Originating-Line-Info attribute is defined in [NASREQ].
-
- The following table defines the meaning of the above table entries.
-
- 0 This attribute MUST NOT be present.
- 0+ Zero or more instances of this attribute MAY be present.
- 0-1 Zero or one instance of this attribute MAY be present.
- 1 Exactly one instance of this attribute MUST be present.
- 1+ One or more of these attributes MUST be present.
-
-4. Security Considerations
-
-4.1. Security Requirements
-
- RADIUS/EAP is used in order to provide authentication and
- authorization for network access. As a result, both the RADIUS and
- EAP portions of the conversation are potential targets of an attack.
- Threats are discussed in [RFC2607], [RFC2865], and [RFC3162].
- Examples include:
-
- [1] An adversary may attempt to acquire confidential data and
- identities by snooping RADIUS packets.
-
- [2] An adversary may attempt to modify packets containing RADIUS
- messages.
-
- [3] An adversary may attempt to inject packets into a RADIUS
- conversation.
-
- [4] An adversary may launch a dictionary attack against the RADIUS
- shared secret.
-
- [5] An adversary may launch a known plaintext attack, hoping to
- recover the key stream corresponding to a Request Authenticator.
-
- [6] An adversary may attempt to replay a RADIUS exchange.
-
- [7] An adversary may attempt to disrupt the EAP negotiation, in
- order to weaken the authentication, or gain access to peer
- passwords.
-
- [8] An authenticated NAS may attempt to forge NAS or session
- identification attributes,
-
- [9] A rogue (unauthenticated) NAS may attempt to impersonate a
- legitimate NAS.
-
-
-
-Aboba & Calhoun Informational [Page 19]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- [10] An attacker may attempt to act as a man-in-the-middle.
-
- To address these threats, it is necessary to support confidentiality,
- data origin authentication, integrity, and replay protection on a
- per-packet basis. Bi-directional authentication between the RADIUS
- client and server also needs to be provided. There is no requirement
- that the identities of RADIUS clients and servers be kept
- confidential (e.g., from a passive eavesdropper).
-
-4.2. Security Protocol
-
- To address the security vulnerabilities of RADIUS/EAP,
- implementations of this specification SHOULD support IPsec [RFC2401]
- along with IKE [RFC2409] for key management. IPsec ESP [RFC2406]
- with non-null transform SHOULD be supported, and IPsec ESP with a
- non-null encryption transform and authentication support SHOULD be
- used to provide per-packet confidentiality, authentication, integrity
- and replay protection. IKE SHOULD be used for key management.
-
- Within RADIUS [RFC2865], a shared secret is used for hiding of
- attributes such as User-Password, as well as in computation of the
- Response Authenticator. In RADIUS accounting [RFC2866], the shared
- secret is used in computation of both the Request Authenticator and
- the Response Authenticator.
-
- Since in RADIUS a shared secret is used to provide confidentiality as
- well as integrity protection and authentication, only use of IPsec
- ESP with a non-null transform can provide security services
- sufficient to substitute for RADIUS application-layer security.
- Therefore, where IPSEC AH or ESP null is used, it will typically
- still be necessary to configure a RADIUS shared secret.
-
- Where RADIUS is run over IPsec ESP with a non-null transform, the
- secret shared between the NAS and the RADIUS server MAY NOT be
- configured. In this case, a shared secret of zero length MUST be
- assumed. However, a RADIUS server that cannot know whether incoming
- traffic is IPsec-protected MUST be configured with a non-null RADIUS
- shared secret.
-
- When IPsec ESP is used with RADIUS, per-packet authentication,
- integrity and replay protection MUST be used. 3DES-CBC MUST be
- supported as an encryption transform and AES-CBC SHOULD be supported.
- AES-CBC SHOULD be offered as a preferred encryption transform if
- supported. HMAC-SHA1-96 MUST be supported as an authentication
- transform. DES-CBC SHOULD NOT be used as the encryption transform.
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 20]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- A typical IPsec policy for an IPsec-capable RADIUS client is
- "Initiate IPsec, from me to any destination port UDP 1812". This
- causes an IPsec SA to be set up by the RADIUS client prior to sending
- RADIUS traffic. If some RADIUS servers contacted by the client do
- not support IPsec, then a more granular policy will be required:
- "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination
- port UDP 1812".
-
- For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept
- IPsec, from any to me, destination port 1812". This causes the
- RADIUS server to accept (but not require) use of IPsec. It may not
- be appropriate to require IPsec for all RADIUS clients connecting to
- an IPsec-enabled RADIUS server, since some RADIUS clients may not
- support IPsec.
-
- Where IPsec is used for security, and no RADIUS shared secret is
- configured, it is important that the RADIUS client and server perform
- an authorization check. Before enabling a host to act as a RADIUS
- client, the RADIUS server SHOULD check whether the host is authorized
- to provide network access. Similarly, before enabling a host to act
- as a RADIUS server, the RADIUS client SHOULD check whether the host
- is authorized for that role.
-
- RADIUS servers can be configured with the IP addresses (for IKE
- Aggressive Mode with pre-shared keys) or FQDNs (for certificate
- authentication) of RADIUS clients. Alternatively, if a separate
- Certification Authority (CA) exists for RADIUS clients, then the
- RADIUS server can configure this CA as a trust anchor [RFC3280] for
- use with IPsec.
-
- Similarly, RADIUS clients can be configured with the IP addresses
- (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for
- certificate authentication) of RADIUS servers. Alternatively, if a
- separate CA exists for RADIUS servers, then the RADIUS client can
- configure this CA as a trust anchor for use with IPsec.
-
- Since unlike SSL/TLS, IKE does not permit certificate policies to be
- set on a per-port basis, certificate policies need to apply to all
- uses of IPsec on RADIUS clients and servers. In IPsec deployments
- supporting only certificate authentication, a management station
- initiating an IPsec-protected telnet session to the RADIUS server
- would need to obtain a certificate chaining to the RADIUS client CA.
- Issuing such a certificate might not be appropriate if the management
- station was not authorized as a RADIUS client.
-
- Where RADIUS clients may obtain their IP address dynamically (such as
- an Access Point supporting DHCP), IKE Main Mode with pre-shared keys
- [RFC2409] SHOULD NOT be used, since this requires use of a group
-
-
-
-Aboba & Calhoun Informational [Page 21]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- pre-shared key; instead, Aggressive Mode SHOULD be used. IKEv2, a
- work in progress, may address this issue in the future. Where RADIUS
- client addresses are statically assigned, either Aggressive Mode or
- Main Mode MAY be used. With certificate authentication, Main Mode
- SHOULD be used.
-
- Care needs to be taken with IKE Phase 1 Identity Payload selection in
- order to enable mapping of identities to pre-shared keys even with
- Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity
- Payloads are used and addresses are dynamically assigned, mapping of
- identities to keys is not possible, so that group pre-shared keys are
- still a practical necessity. As a result, the ID_FQDN identity
- payload SHOULD be employed in situations where Aggressive mode is
- utilized along with pre-shared keys and IP addresses are dynamically
- assigned. This approach also has other advantages, since it allows
- the RADIUS server and client to configure themselves based on the
- fully qualified domain name of their peers.
-
- Note that with IPsec, security services are negotiated at the
- granularity of an IPsec SA, so that RADIUS exchanges requiring a set
- of security services different from those negotiated with existing
- IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs
- are also advisable where quality of service considerations dictate
- different handling RADIUS conversations. Attempting to apply
- different quality of service to connections handled by the same IPsec
- SA can result in reordering, and falling outside the replay window.
- For a discussion of the issues, see [RFC2983].
-
-4.3. Security Issues
-
- This section provides more detail on the vulnerabilities identified
- in Section 4.1., and how they may be mitigated. Vulnerabilities
- include:
-
- Privacy issues
- Spoofing and hijacking
- Dictionary attacks
- Known plaintext attacks
- Replay attacks
- Negotiation attacks
- Impersonation
- Man in the middle attacks
- Separation of authenticator and authentication server
- Multiple databases
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 22]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
-4.3.1. Privacy Issues
-
- Since RADIUS messages may contain the User-Name attribute as well as
- NAS-IP-Address or NAS-Identifier attributes, an attacker snooping on
- RADIUS traffic may be able to determine the geographic location of
- peers in real time. In wireless networks, it is often assumed that
- RADIUS traffic is physically secure, since it typically travels over
- the wired network and that this limits the release of location
- information.
-
- However, it is possible for an authenticated attacker to spoof ARP
- packets [RFC826] so as to cause diversion of RADIUS traffic onto the
- wireless network. In this way an attacker may obtain RADIUS packets
- from which it can glean peer location information, or which it can
- subject to a known plaintext or offline dictionary attack. To
- address these vulnerabilities, implementations of this specification
- SHOULD use IPsec ESP with non-null transform and per-packet
- encryption, authentication, integrity and replay protection to
- protect both RADIUS authentication [RFC2865] and accounting [RFC2866]
- traffic, as described in Section 4.2.
-
-4.3.2. Spoofing and Hijacking
-
- Access-Request packets with a User-Password attribute establish the
- identity of both the user and the NAS sending the Access-Request,
- because of the way the shared secret between the NAS and RADIUS
- server is used. Access-Request packets with CHAP-Password or
- EAP-Message attributes do not have a User-Password attribute. As a
- result, the Message-Authenticator attribute SHOULD be used in
- Access-Request packets that do not have a User-Password attribute, in
- order to establish the identity of the NAS sending the request.
-
- An attacker may attempt to inject packets into the conversation
- between the NAS and the RADIUS server, or between the RADIUS server
- and the security server. RADIUS [RFC2865] does not support
- encryption other than attribute hiding. As described in [RFC2865],
- only Access-Reply and Access-Challenge packets are integrity
- protected. Moreover, the per-packet authentication and integrity
- protection mechanism described in [RFC2865] has known weaknesses
- [MD5Attack], making it a tempting target for attackers looking to
- subvert RADIUS/EAP.
-
- To provide stronger security, the Message-Authenticator attribute
- MUST be used in all RADIUS packets containing an EAP-Message
- attribute. Implementations of this specification SHOULD use IPsec
- ESP with non-null transform and per-packet encryption,
- authentication, integrity and replay protection, as described in
- Section 4.2.
-
-
-
-Aboba & Calhoun Informational [Page 23]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
-4.3.3. Dictionary Attacks
-
- The RADIUS shared secret is vulnerable to offline dictionary attack,
- based on capture of the Response Authenticator or
- Message-Authenticator attribute. In order to decrease the level of
- vulnerability, [RFC2865] recommends:
-
- The secret (password shared between the client and the RADIUS
- server) SHOULD be at least as large and unguessable as a
- well-chosen password. It is preferred that the secret be at least
- 16 octets.
-
- The risk of an offline dictionary attack can be further reduced by
- employing IPsec ESP with non-null transform in order to encrypt the
- RADIUS conversation, as described in Section 4.2.
-
-4.3.4. Known Plaintext Attacks
-
- Since EAP [RFC2284] does not support PAP, the RADIUS User-Password
- attribute is not used to carry hidden user passwords within
- RADIUS/EAP conversations. The User-Password hiding mechanism,
- defined in [RFC2865] utilizes MD5, defined in [RFC1321], in order to
- generate a key stream based on the RADIUS shared secret and the
- Request Authenticator. Where PAP is in use, it is possible to
- collect key streams corresponding to a given Request Authenticator
- value, by capturing RADIUS conversations corresponding to a PAP
- authentication attempt, using a known password. Since the
- User-Password is known, the key stream corresponding to a given
- Request Authenticator can be determined and stored.
-
- Since the key stream may have been determined previously from a known
- plaintext attack, if the Request Authenticator repeats, attributes
- encrypted using the RADIUS attribute hiding mechanism should be
- considered compromised. In addition to the User-Password attribute,
- which is not used with EAP, this includes attributes such as
- Tunnel-Password [RFC2868, section 3.5] and MS-MPPE-Send-Key and
- MS-MPPE-Recv-Key attributes [RFC2548, section 2.4], which include a
- Salt field as part of the hiding algorithm.
-
- To avoid this, [RFC2865], Section 3 advises:
-
- Since it is expected that the same secret MAY be used to
- authenticate with servers in disparate geographic regions, the
- Request Authenticator field SHOULD exhibit global and temporal
- uniqueness.
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 24]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- Where the Request Authenticator repeats, the Salt field defined in
- [RFC2548], Section 2.4 does not provide protection against
- compromise. This is because MD5 [RFC1321], rather than HMAC-MD5
- [RFC2104], is used to generate the key stream, which is calculated
- from the 128-bit RADIUS shared secret (S), the 128-bit Request
- Authenticator (R), and the Salt field (A), using the formula b(1) =
- MD5(S + R + A). Since the Salt field is placed at the end, if the
- Request Authenticator were to repeat on a network where PAP is in
- use, then the salted keystream could be calculated from the
- User-Password keystream by continuing the MD5 calculation based on
- the Salt field (A), which is sent in the clear.
-
- Even though EAP does not support PAP authentication, a security
- vulnerability can still exist where the same RADIUS shared secret is
- used for hiding User-Password as well as other attributes. This can
- occur, for example, if the same RADIUS proxy handles authentication
- requests for both EAP and PAP.
-
- The threat can be mitigated by protecting RADIUS with IPsec ESP with
- non-null transform, as described in Section 4.2. Where RADIUS shared
- secrets are configured, the RADIUS shared secret used by a NAS
- supporting EAP MUST NOT be reused by a NAS utilizing the
- User-Password attribute, since improper shared secret hygiene could
- lead to compromise of hidden attributes.
-
-4.3.5. Replay Attacks
-
- The RADIUS protocol provides only limited support for replay
- protection. RADIUS Access-Requests include liveness via the 128-bit
- Request Authenticator. However, the Request Authenticator is not a
- replay counter. Since RADIUS servers may not maintain a cache of
- previous Request Authenticators, the Request Authenticator does not
- provide replay protection.
-
- RADIUS accounting [RFC2866] does not support replay protection at the
- protocol level. Due to the need to support failover between RADIUS
- accounting servers, protocol-based replay protection is not
- sufficient to prevent duplicate accounting records. However, once
- accepted by the accounting server, duplicate accounting records can
- be detected by use of the the Acct-Session-Id [RFC2866, section 5.5]
- and Event-Timestamp [RFC2869, section 5.3] attributes.
-
- Unlike RADIUS authentication, RADIUS accounting does not use the
- Request Authenticator as a nonce. Instead, the Request Authenticator
- contains an MD5 hash calculated over the Code, Identifier, Length,
- and request attributes of the Accounting Request packet, plus the
- shared secret. The Response Authenticator also contains an MD5 hash
- calculated over the Code, Identifier and Length, the Request
-
-
-
-Aboba & Calhoun Informational [Page 25]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- Authenticator field from the Accounting-Request packet being replied
- to, the response attributes and the shared secret.
-
- Since the Accounting Response Authenticator depends in part on the
- Accounting Request Authenticator, it is not possible to replay an
- Accounting-Response unless the Request Authenticator repeats. While
- it is possible to utilize EAP methods such as EAP TLS [RFC2716] which
- include liveness checks on both sides, not all EAP messages will
- include liveness so that this provides incomplete protection.
-
- Strong replay protection for RADIUS authentication and accounting can
- be provided by enabling IPsec replay protection with RADIUS, as
- described in Section 4.2.
-
-4.3.6. Negotiation Attacks
-
- In a negotiation attack a rogue NAS, tunnel server, RADIUS proxy or
- RADIUS server attempts to cause the authenticating peer to choose a
- less secure authentication method. For example, a session that would
- normally be authenticated with EAP would instead be authenticated via
- CHAP or PAP; alternatively, a connection that would normally be
- authenticated via a more secure EAP method such as EAP-TLS [RFC2716]
- might be made to occur via a less secure EAP method, such as
- MD5-Challenge. The threat posed by rogue devices, once thought to be
- remote, has gained currency given compromises of telephone company
- switching systems, such as those described in [Masters].
-
- Protection against negotiation attacks requires the elimination of
- downward negotiations. The RADIUS exchange may be further protected
- by use of IPsec, as described in Section 4.2. Alternatively, where
- IPsec is not used, the vulnerability can be mitigated via
- implementation of per-connection policy on the part of the
- authenticating peer, and per-peer policy on the part of the RADIUS
- server. For the authenticating peer, authentication policy should be
- set on a per-connection basis. Per-connection policy allows an
- authenticating peer to negotiate a strong EAP method when connecting
- to one service, while negotiating a weaker EAP method for another
- service.
-
- With per-connection policy, an authenticating peer will only attempt
- to negotiate EAP for a session in which EAP support is expected. As
- a result, there is a presumption that an authenticating peer
- selecting EAP requires that level of security. If it cannot be
- provided, it is likely that there is some kind of misconfiguration,
- or even that the authenticating peer is contacting the wrong server.
- Should the NAS not be able to negotiate EAP, or should the
- EAP-Request sent by the NAS be of a different EAP type than what is
- expected, the authenticating peer MUST disconnect. An authenticating
-
-
-
-Aboba & Calhoun Informational [Page 26]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- peer expecting EAP to be negotiated for a session MUST NOT negotiate
- a weaker method, such as CHAP or PAP. In wireless networks, the
- service advertisement itself may be spoof-able, so that an attacker
- could fool the peer into negotiating an authentication method
- suitable for a less secure network.
-
- For a NAS, it may not be possible to determine whether a peer is
- required to authenticate with EAP until the peer's identity is known.
- For example, for shared-uses NASes it is possible for one reseller to
- implement EAP while another does not. Alternatively, some peer might
- be authenticated locally by the NAS while other peers are
- authenticated via RADIUS. In such cases, if any peers of the NAS
- MUST do EAP, then the NAS MUST attempt to negotiate EAP for every
- session. This avoids forcing a peer to support more than one
- authentication type, which could weaken security.
-
- If CHAP is negotiated, the NAS will pass the User-Name and
- CHAP-Password attributes to the RADIUS server in an Access-Request
- packet. If the peer is not required to use EAP, then the RADIUS
- server will respond with an Access-Accept or Access-Reject packet as
- appropriate. However, if CHAP has been negotiated but EAP is
- required, the RADIUS server MUST respond with an Access-Reject,
- rather than an Access-Challenge/EAP-Message/EAP-Request packet. The
- authenticating peer MUST refuse to renegotiate authentication, even
- if the renegotiation is from CHAP to EAP.
-
- If EAP is negotiated but is not supported by the RADIUS proxy or
- server, then the server or proxy MUST respond with an Access-Reject.
- In these cases, a PPP NAS MUST send an LCP-Terminate and disconnect
- the peer. This is the correct behavior since the authenticating peer
- is expecting EAP to be negotiated, and that expectation cannot be
- fulfilled. An EAP-capable authenticating peer MUST refuse to
- renegotiate the authentication protocol if EAP had initially been
- negotiated. Note that problems with a non-EAP capable RADIUS proxy
- could prove difficult to diagnose, since a peer connecting from one
- location (with an EAP-capable proxy) might be able to successfully
- authenticate via EAP, while the same peer connecting at another
- location (and encountering an EAP-incapable proxy) might be
- consistently disconnected.
-
-4.3.7. Impersonation
-
- [RFC2865] Section 3 states:
-
- A RADIUS server MUST use the source IP address of the RADIUS UDP
- packet to decide which shared secret to use, so that RADIUS
- requests can be proxied.
-
-
-
-
-Aboba & Calhoun Informational [Page 27]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
- NAS-IPv6-Address attributes may not match the source address. Since
- the NAS-Identifier attribute need not contain an FQDN, this attribute
- also may not correspond to the source address, even indirectly, with
- or without a proxy present.
-
- As a result, the authenticity check performed by a RADIUS server or
- proxy does not verify the correctness of NAS identification
- attributes. This makes it possible for a rogue NAS to forge
- NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier attributes within
- a RADIUS Access-Request in order to impersonate another NAS. It is
- also possible for a rogue NAS to forge session identification
- attributes such as Called-Station-Id, Calling-Station-Id, and
- Originating-Line-Info.
-
- This could fool the RADIUS server into subsequently sending
- Disconnect or CoA-Request messages [RFC3576] containing forged
- session identification attributes to a NAS targeted by an attacker.
-
- To address these vulnerabilities RADIUS proxies SHOULD check whether
- NAS identification attributes (NAS-IP-Address, NAS-IPv6-Address,
- NAS-Identifier) match the source address of packets originating from
- the NAS. Where a match is not found, an Access-Reject SHOULD be
- sent, and an error SHOULD be logged.
-
- However, such a check may not always be possible. Since the
- NAS-Identifier attribute need not correspond to an FQDN, it may not
- be resolvable to an IP address to be matched against the source
- address. Also, where a NAT exists between the RADIUS client and
- proxy, checking the NAS-IP-Address or NAS-IPv6-Address attributes may
- not be feasible.
-
- To allow verification of NAS and session identification parameters,
- EAP methods can support the secure exchange of these parameters
- between the EAP peer and EAP server. NAS identification attributes
- include NAS-IP-Address, NAS-IPv6-Address and Called-Station-Id;
- session identification attributes include User-Name and
- Calling-Station-Id. The secure exchange of these parameters between
- the EAP peer and server enables the RADIUS server to check whether
- the attributes provided by the NAS match those provided by the peer;
- similarly, the peer can check the parameters provided by the NAS
- against those provided by the EAP server. This enables detection of
- a rogue NAS.
-
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 28]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
-4.3.8. Man in the Middle Attacks
-
- RADIUS only provides security on a hop-by-hop basis, even where IPsec
- is used. As a result, an attacker gaining control of a RADIUS proxy
- could attempt to modify EAP packets in transit. To protect against
- this, EAP methods SHOULD incorporate their own per-packet integrity
- protection and authentication mechanisms.
-
-4.3.9. Separation of Authenticator and Authentication Server
-
- As noted in [RFC2716], it is possible for the EAP peer and
- authenticator to mutually authenticate, and derive a Master Session
- Key (MSK) for a ciphersuite used to protect subsequent data traffic.
- This does not present an issue on the peer, since the peer and EAP
- client reside on the same machine; all that is required is for the
- EAP client module to derive and pass a Transient Session Key (TSK) to
- the ciphersuite module.
-
- The situation is more complex when EAP is used with RADIUS, since the
- authenticator and authentication server may not reside on the same
- host.
-
- In the case where the authenticator and authentication server reside
- on different machines, there are several implications for security.
- First, mutual authentication will occur between the peer and the
- authentication server, not between the peer and the authenticator.
- This means that it is not possible for the peer to validate the
- identity of the NAS or tunnel server that it is speaking to, using
- EAP alone.
-
- As described in Section 4.2, when RADIUS/EAP is used to encapsulate
- EAP packets, IPsec SHOULD be used to provide per-packet
- authentication, integrity, replay protection and confidentiality.
- The Message-Authenticator attribute is also required in RADIUS
- Access-Requests containing an EAP-Message attribute sent from the NAS
- or tunnel server to the RADIUS server. Since the
- Message-Authenticator attribute involves an HMAC-MD5 message
- integrity check, it is possible for the RADIUS server to verify the
- integrity of the Access-Request as well as the NAS or tunnel server's
- identity, even where IPsec is not used. Similarly, Access-Challenge
- packets containing an EAP-Message attribute sent from the RADIUS
- server to the NAS are also authenticated and integrity protected
- using an HMAC-MD5 message integrity check, enabling the NAS or tunnel
- server to determine the integrity of the packet and verify the
- identity of the RADIUS server, even where IPsec is not used.
- Moreover, EAP packets sent using methods that contain their own
- integrity protection cannot be successfully modified by a rogue NAS
- or tunnel server.
-
-
-
-Aboba & Calhoun Informational [Page 29]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- The second issue that arises where the authenticator and
- authentication server reside on separate hosts is that the EAP Master
- Session Key (MSK) negotiated between the peer and authentication
- server will need to be transmitted to the authenticator. Therefore a
- mechanism needs to be provided to transmit the MSK from the
- authentication server to the NAS or tunnel server that needs it. The
- specification of the key transport and wrapping mechanism is outside
- the scope of this document. However, it is expected that the
- wrapping mechanism will provide confidentiality, integrity and replay
- protection, and data origin authentication.
-
-4.3.10. Multiple Databases
-
- In many cases a security server will be deployed along with a RADIUS
- server in order to provide EAP services. Unless the security server
- also functions as a RADIUS server, two separate user databases will
- exist, each containing information about the security requirements
- for the user. This represents a weakness, since security may be
- compromised by a successful attack on either of the servers, or their
- databases. With multiple user databases, adding a new user may
- require multiple operations, increasing the chances for error. The
- problems are further magnified in the case where user information is
- also being kept in an LDAP server. In this case, three stores of
- user information may exist.
-
- In order to address these threats, consolidation of databases is
- recommended. This can be achieved by having both the RADIUS server
- and security server store information in the same database; by having
- the security server provide a full RADIUS implementation; or by
- consolidating both the security server and the RADIUS server onto
- the same machine.
-
-5. IANA Considerations
-
- This specification does not create any new registries, or define any
- new RADIUS attributes or values.
-
-6. References
-
-6.1. Normative References
-
- [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
- 1321, April 1992.
-
- [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
- Keyed-Hashing for Message Authentication", RFC 2104,
- February 1997.
-
-
-
-
-Aboba & Calhoun Informational [Page 30]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", RFC 2279, January 1998.
-
- [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
- Authentication Protocol (EAP)", RFC 2284, March 1998.
-
- [RFC2401] Atkinson, R. and S. Kent, "Security Architecture for
- the Internet Protocol", RFC 2401, November 1998.
-
- [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
- Payload (ESP)", RFC 2406, November 1998.
-
- [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
- (IKE)", RFC 2409, November 1998.
-
- [RFC2486] Aboba, B. and M. Beadles, "The Network Access
- Identifier", RFC 2486, January 1999.
-
- [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
- "Remote Authentication Dial In User Service (RADIUS)",
- RFC 2865, June 2000.
-
- [RFC2988] Paxson, V. and M. Allman, "Computing TCP's
- Retransmission Timer", RFC 2988, November 2000.
-
- [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IP6",
- RFC 3162, August 2001.
-
- [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.
-
- [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B.
- Aboba, "Dynamic Authorization Extensions to Remote
- Authentication Dial In User Service (RADIUS)", RFC
- 3576, July 2003.
-
-
-
-
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 31]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
-6.2. Informative References
-
- [RFC826] Plummer, D., "An Ethernet Address Resolution
- Protocol", STD 37, RFC 826, November 1982.
-
- [RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network
- Authentication Service (V5)", RFC 1510, September
- 1993.
-
- [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD
- 51, RFC 1661, July 1994.
-
- [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS
- Attributes", RFC 2548, March 1999.
-
- [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and
- Policy Implementation in Roaming", RFC 2607, June
- 1999.
-
- [RFC2716] Aboba, B. and D. Simon,"PPP EAP TLS Authentication
- Protocol", RFC 2716, October 1999.
-
- [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
-
- [RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
- Modifications for Tunnel Protocol Support", RFC 2867,
- June 2000.
-
- [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J.,
- Holdrege, M. and I. Goyret, "RADIUS Attributes for
- Tunnel Protocol Support", RFC 2868, June 2000.
-
- [RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS
- Extensions", RFC 2869, June 2000.
-
- [RFC2983] Black, D. "Differentiated Services and Tunnels", RFC
- 2983, October 2000.
-
- [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J.
- Roese, "IEEE 802.1X Remote Authentication Dial In User
- Service (RADIUS) Usage Guidelines", RFC 3580,
- September 2003.
-
- [IEEE802] IEEE Standards for Local and Metropolitan Area
- Networks: Overview and Architecture, ANSI/IEEE Std
- 802, 1990.
-
-
-
-
-
-Aboba & Calhoun Informational [Page 32]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- [IEEE8021X] IEEE Standards for Local and Metropolitan Area
- Networks: Port based Network Access Control, IEEE Std
- 802.1X-2001, June 2001.
-
- [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent
- Attack", CryptoBytes Vol.2 No.2, Summer 1996.
-
- [Masters] Slatalla, M. and J. Quittner, "Masters of Deception."
- HarperCollins, New York, 1995.
-
- [NASREQ] Calhoun, P., et al., "Diameter Network Access Server
- Application", Work in Progress.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 33]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
-Appendix A - Examples
-
- The examples below illustrate conversations between an authenticating
- peer, NAS, and RADIUS server. The OTP and EAP-TLS protocols are used
- only for illustrative purposes; other authentication protocols could
- also have been used, although they might show somewhat different
- behavior.
-
- Where the NAS sends an EAP-Request/Identity as the initial packet,
- the exchange appears as follows:
-
-Authenticating peer NAS RADIUS server
-------------------- --- -------------
- <- EAP-Request/
- Identity
-EAP-Response/
-Identity (MyID) ->
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- (MyID) ->
- <- RADIUS
- Access-Challenge/
- EAP-Message/EAP-Request
- OTP/OTP Challenge
- <- EAP-Request/
- OTP/OTP Challenge
-EAP-Response/
-OTP, OTPpw ->
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- OTP, OTPpw ->
- <- RADIUS
- Access-Accept/
- EAP-Message/EAP-Success
- (other attributes)
- <- EAP-Success
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 34]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- In the case where the NAS initiates with an EAP-Request for EAP TLS
- [RFC2716], and the identity is determined based on the contents of
- the client certificate, the exchange will appear as follows:
-
-Authenticating peer NAS RADIUS server
-------------------- --- -------------
- <- EAP-Request/
- EAP-Type=EAP-TLS
- (TLS Start, S bit set)
-EAP-Response/
-EAP-Type=EAP-TLS
-(TLS client_hello)->
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- EAP-Type=EAP-TLS->
- <-RADIUS Access-Challenge/
- EAP-Message/
- EAP-Request/
- EAP-Type=EAP-TLS
- <- EAP-Request/
- EAP-Type=EAP-TLS
- (TLS server_hello,
- TLS certificate,
- [TLS server_key_exchange,]
- [TLS certificate_request,]
- TLS server_hello_done)
-EAP-Response/
-EAP-Type=EAP-TLS
-(TLS certificate,
-TLS client_key_exchange,
-[TLS certificate_verify,]
-TLS change_cipher_spec,
-TLS finished)->
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- EAP-Type=EAP-TLS->
- <-RADIUS Access-Challenge/
- EAP-Message/
- EAP-Request/
- EAP-Type=EAP-TLS
- <- EAP-Request/
- EAP-Type=EAP-TLS
- (TLS change_cipher_spec,
- TLS finished)
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 35]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
-EAP-Response/
-EAP-Type=EAP-TLS ->
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- EAP-Type=EAP-TLS->
- <-RADIUS Access-Accept/
- EAP-Message/EAP-Success
- (other attributes)
- <- EAP-Success
-
- In the case where the NAS first sends an EAP-Start packet to the
- RADIUS server, the conversation would appear as follows:
-
-Authenticating peer NAS RADIUS server
-------------------- --- -------------
- RADIUS Access-Request/
- EAP-Message/Start ->
- <- RADIUS
- Access-Challenge/
- EAP-Message/EAP-Request/
- Identity
- <- EAP-Request/
- Identity
-EAP-Response/
-Identity (MyID) ->
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- Identity (MyID) ->
- <- RADIUS
- Access-Challenge/
- EAP-Message/EAP-Request/
- OTP/OTP Challenge
- <- EAP-Request/
- OTP/OTP Challenge
-EAP-Response/
-OTP, OTPpw ->
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- OTP, OTPpw ->
- <- RADIUS
- Access-Accept/
- EAP-Message/EAP-Success
- (other attributes)
- <- EAP-Success
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 36]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- In the case where the NAS initiates with an EAP-Request for EAP TLS
- [RFC2716], but the peer responds with a Nak, indicating that it would
- prefer another method not implemented locally on the NAS, the
- exchange will appear as follows:
-
-Authenticating peer NAS RADIUS server
-------------------- --- -------------
- <- EAP-Request/
- EAP-Type=EAP-TLS
- (TLS Start, S bit set)
-EAP-Response/
-EAP-Type=Nak
-(Alternative(s))->
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- Nak ->
- <- RADIUS
- Access-Challenge/
- EAP-Message/EAP-Request/
- Identity
- <- EAP-Request/
- Identity
-EAP-Response/
-Identity (MyID) ->
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- (MyID) ->
- <- RADIUS
- Access-Challenge/
- EAP-Message/EAP-Request
- OTP/OTP Challenge
- <- EAP-Request/
- OTP/OTP Challenge
-EAP-Response/
-OTP, OTPpw ->
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- OTP, OTPpw ->
- <- RADIUS
- Access-Accept/
- EAP-Message/EAP-Success
- (other attributes)
- <- EAP-Success
-
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 37]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- In the case where the authenticating peer attempts to authenticate
- the NAS, the conversation would appear as follows:
-
-Authenticating peer NAS RADIUS Server
-------------------- --- -------------
-EAP-Request/
-Challenge, MD5 ->
- RADIUS Access-Request/
- EAP-Message/EAP-Request/
- Challenge, MD5 ->
- <- RADIUS
- Access-Reject/
- EAP-Message/
- EAP-Response/
- Nak (no alternative)
-
- <- EAP-Response/Nak
- (no alternative)
-EAP-Failure ->
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 38]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- In the case where an invalid EAP Response is inserted by an attacker,
- the conversation would appear as follows:
-
-Authenticating peer NAS RADIUS server
-------------------- --- -------------
- <- EAP-Request/
- EAP-Type=Foo
-EAP-Response/
-EAP-Type=Foo ->
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- EAP-Type=Foo ->
- <- RADIUS
- Access-Challenge/
- EAP-Message/EAP-Request/
- EAP-Type=Foo
- <- EAP-Request/
- EAP-Type=Foo
-Attacker spoof:
-EAP-Response/
-EAP-Type=Bar ->
-
-Good guy:
-EAP-Response/
-EAP-Type=Foo ->
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- EAP-Type=Bar ->
-
- <- RADIUS
- Access-Challenge/
- EAP-Message/EAP-Request/
- EAP-Type=Foo,
- Error-Cause="Invalid EAP
- Packet (Ignored)"
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- EAP-Type=Foo ->
- <- Access-Accept/
- EAP-Message/Success
- <- EAP Success
-
-
-
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 39]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- In the case where the client fails EAP authentication, and an error
- message is sent prior to disconnection, the conversation would appear
- as follows:
-
-Authenticating peer NAS RADIUS server
-------------------- --- -------------
- RADIUS Access-Request/
- EAP-Message/Start ->
- <- RADIUS
- Access-Challenge/
- EAP-Message/EAP-Response/
- Identity
- <- EAP-Request/
- Identity
-EAP-Response/
-Identity (MyID) ->
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- (MyID) ->
- <- RADIUS
- Access-Challenge/
- EAP-Message/EAP-Request
- OTP/OTP Challenge
- <- EAP-Request/
- OTP/OTP Challenge
-EAP-Response/
-OTP, OTPpw ->
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- OTP, OTPpw ->
- <- RADIUS
- Access-Challenge/
- EAP-Message/EAP-Request/
- Notification
- <- EAP-Request/
- Notification
-
-EAP-Response/
-Notification ->
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- Notification ->
- <- RADIUS
- Access-Reject/
- EAP-Message/EAP-Failure
- <- EAP-Failure
- (client disconnected)
-
-
-
-
-Aboba & Calhoun Informational [Page 40]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- In the case that the RADIUS server or proxy does not support EAP-
- Message, but no error message is sent, the conversation would appear
- as follows:
-
-Authenticating peer NAS RADIUS server
-------------------- --- -------------
- RADIUS Access-Request/
- EAP-Message/Start ->
- <- RADIUS
- Access-Reject
- (User Disconnected)
-
-In the case where the local RADIUS server does support EAP-Message, but
-the remote RADIUS server does not, the conversation would appear as
-follows:
-
-Authenticating peer NAS RADIUS server
-------------------- --- -------------
- RADIUS Access-Request/
- EAP-Message/Start ->
- <- RADIUS
- Access-Challenge/
- EAP-Message/
- EAP-Response/
- Identity
- <- EAP-Request/
- Identity
-
-EAP-Response/
-Identity
-(MyID) ->
- RADIUS Access-Request/
- EAP-Message/EAP-Response/
- (MyID) ->
- <- RADIUS
- Access-Reject
- (proxied from remote
- RADIUS server)
- (User Disconnected)
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 41]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- In the case where PPP is the link and the authenticating peer does
- not support EAP, but where EAP is required for that user, the
- conversation would appear as follows:
-
-Authenticating peer NAS RADIUS server
-------------------- --- -------------
- <- PPP LCP Request-EAP
- auth
-PPP LCP NAK-EAP
-auth ->
- <- PPP LCP Request-CHAP
- auth
-PPP LCP ACK-CHAP
-auth ->
- <- PPP CHAP Challenge
-PPP CHAP Response ->
- RADIUS Access-Request/
- User-Name,
- CHAP-Password ->
- <- RADIUS
- Access-Reject
- <- PPP LCP Terminate
- (User Disconnected)
-
-In the case where PPP is the link, the NAS does not support EAP, but
-where EAP is required for that user, the conversation would appear as
-follows:
-
-Authenticating peer NAS RADIUS server
-------------------- --- -------------
- <- PPP LCP Request-CHAP
- auth
-
-PP LCP ACK-CHAP
-auth ->
- <- PPP CHAP Challenge
-PPP CHAP Response ->
- RADIUS Access-Request/
- User-Name,
- CHAP-Password ->
-
- <- RADIUS
- Access-Reject
- <- PPP LCP Terminate
- (User Disconnected)
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 42]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
-Appendix B - Change Log
-
- The following changes have been made from RFC 2869:
-
- A NAS may simultaneously support both local authentication and
- pass-through; once the NAS enters pass-through mode within a session,
- it cannot revert back to local authentication. Also EAP is
- explicitly described as a 'lock step' protocol. (Section 2).
-
- The NAS may initiate with an EAP-Request for an authentication Type.
- If the Request is NAK'd, the NAS should send an initial
- Access-Request with an EAP-Message attribute containing an
- EAP-Response/Nak.
-
- The RADIUS server may treat an invalid EAP Response as a non-fatal
- error (Section 2.2)
-
- For use with RADIUS/EAP, the Password-Retry (Section 2.3) and
- Reply-Message (2.6.5) attributes are deprecated.
-
- Each EAP session has a unique Identifier space (Section 2.6.1).
-
- Role reversal is not supported (Section 2.6.2).
-
- Message combinations (e.g. Access-Accept/EAP-Failure) that conflict
- are discouraged (Section 2.6.3).
-
- Only a single EAP packet may be encapsulated within a RADIUS message
- (Section 3.1).
-
- An Access-Request lacking explicit authentication as well as a
- Message- Authenticator attribute SHOULD be silently discarded
- (Section 3.3).
-
- The Originating-Line-Info attribute is supported (Section 3.3).
-
- IPsec ESP with non-null transform SHOULD be used and the usage model
- is described in detail (Section 4.2).
-
- Additional discussion of security vulnerabilities (Section 4.1) and
- potential fixes (Section 4.3).
-
- Separated normative (Section 6.1) and informative (Section 6.2)
- references.
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 43]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
- Added additional examples (Appendix A): a NAS initiating with an
- EAP-Request for an authentication Type; attempted role reversal.
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- intellectual property 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; neither does it represent that it
- has made any effort to identify any such rights. Information on the
- IETF's procedures with respect to rights in standards-track and
- standards-related documentation can be found in BCP-11. Copies of
- claims of rights made available for publication 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 implementors or users of this specification can
- be obtained from the IETF Secretariat.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights which may cover technology that may be required to practice
- this standard. Please address the information to the IETF Executive
- Director.
-
-Acknowledgments
-
- Thanks to Dave Dawson and Karl Fox of Ascend, Glen Zorn of Cisco
- Systems, Jari Arkko of Ericsson and Ashwin Palekar, Tim Moore and
- Narendra Gidwani of Microsoft for useful discussions of this problem
- space. The authors would also like to acknowledge Tony Jeffree,
- Chair of IEEE 802.1 for his assistance in resolving RADIUS/EAP issues
- in IEEE 802.1X-2001.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 44]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
-Authors' Addresses
-
- Bernard Aboba
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
-
- Phone: +1 425 706 6605
- Fax: +1 425 936 7329
- EMail: bernarda@microsoft.com
-
-
- Pat R. Calhoun
- Airespace
- 110 Nortech Parkway
- San Jose, California, 95134
- USA
-
- Phone: +1 408 635 2023
- Fax: +1 408 635 2020
- EMail: pcalhoun@airespace.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 45]
-\f
-RFC 3579 RADIUS & EAP September 2003
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2003). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assignees.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS 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.
-
-Acknowledgement
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba & Calhoun Informational [Page 46]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group B. Aboba
-Request for Comments: 3748 Microsoft
-Obsoletes: 2284 L. Blunk
-Category: Standards Track Merit Network, Inc
- J. Vollbrecht
- Vollbrecht Consulting LLC
- J. Carlson
- Sun
- H. Levkowetz, Ed.
- ipUnplugged
- June 2004
-
-
- Extensible Authentication Protocol (EAP)
-
-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 (2004).
-
-Abstract
-
- This document defines the Extensible Authentication Protocol (EAP),
- an authentication framework which supports multiple authentication
- methods. EAP typically runs directly over data link layers such as
- Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP
- provides its own support for duplicate elimination and
- retransmission, but is reliant on lower layer ordering guarantees.
- Fragmentation is not supported within EAP itself; however, individual
- EAP methods may support this.
-
- This document obsoletes RFC 2284. A summary of the changes between
- this document and RFC 2284 is available in Appendix A.
-
-
-
-
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 1]
-\f
-RFC 3748 EAP June 2004
-
-
-Table of Contents
-
- 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1. Specification of Requirements . . . . . . . . . . . . . 4
- 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . 6
- 2. Extensible Authentication Protocol (EAP). . . . . . . . . . . 7
- 2.1. Support for Sequences . . . . . . . . . . . . . . . . . 9
- 2.2. EAP Multiplexing Model. . . . . . . . . . . . . . . . . 10
- 2.3. Pass-Through Behavior . . . . . . . . . . . . . . . . . 12
- 2.4. Peer-to-Peer Operation. . . . . . . . . . . . . . . . . 14
- 3. Lower Layer Behavior. . . . . . . . . . . . . . . . . . . . . 15
- 3.1. Lower Layer Requirements. . . . . . . . . . . . . . . . 15
- 3.2. EAP Usage Within PPP. . . . . . . . . . . . . . . . . . 18
- 3.2.1. PPP Configuration Option Format. . . . . . . . . 18
- 3.3. EAP Usage Within IEEE 802 . . . . . . . . . . . . . . . 19
- 3.4. Lower Layer Indications . . . . . . . . . . . . . . . . 19
- 4. EAP Packet Format . . . . . . . . . . . . . . . . . . . . . . 20
- 4.1. Request and Response. . . . . . . . . . . . . . . . . . 21
- 4.2. Success and Failure . . . . . . . . . . . . . . . . . . 23
- 4.3. Retransmission Behavior . . . . . . . . . . . . . . . . 26
- 5. Initial EAP Request/Response Types. . . . . . . . . . . . . . 27
- 5.1. Identity. . . . . . . . . . . . . . . . . . . . . . . . 28
- 5.2. Notification. . . . . . . . . . . . . . . . . . . . . . 29
- 5.3. Nak . . . . . . . . . . . . . . . . . . . . . . . . . . 31
- 5.3.1. Legacy Nak . . . . . . . . . . . . . . . . . . . 31
- 5.3.2. Expanded Nak . . . . . . . . . . . . . . . . . . 32
- 5.4. MD5-Challenge . . . . . . . . . . . . . . . . . . . . . 35
- 5.5. One-Time Password (OTP) . . . . . . . . . . . . . . . . 36
- 5.6. Generic Token Card (GTC). . . . . . . . . . . . . . . . 37
- 5.7. Expanded Types. . . . . . . . . . . . . . . . . . . . . 38
- 5.8. Experimental. . . . . . . . . . . . . . . . . . . . . . 40
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
- 6.1. Packet Codes. . . . . . . . . . . . . . . . . . . . . . 41
- 6.2. Method Types. . . . . . . . . . . . . . . . . . . . . . 41
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42
- 7.1. Threat Model. . . . . . . . . . . . . . . . . . . . . . 42
- 7.2. Security Claims . . . . . . . . . . . . . . . . . . . . 43
- 7.2.1. Security Claims Terminology for EAP Methods. . . 44
- 7.3. Identity Protection . . . . . . . . . . . . . . . . . . 46
- 7.4. Man-in-the-Middle Attacks . . . . . . . . . . . . . . . 47
- 7.5. Packet Modification Attacks . . . . . . . . . . . . . . 48
- 7.6. Dictionary Attacks. . . . . . . . . . . . . . . . . . . 49
- 7.7. Connection to an Untrusted Network. . . . . . . . . . . 49
- 7.8. Negotiation Attacks . . . . . . . . . . . . . . . . . . 50
- 7.9. Implementation Idiosyncrasies . . . . . . . . . . . . . 50
- 7.10. Key Derivation. . . . . . . . . . . . . . . . . . . . . 51
- 7.11. Weak Ciphersuites . . . . . . . . . . . . . . . . . . . 53
-
-
-
-Aboba, et al. Standards Track [Page 2]
-\f
-RFC 3748 EAP June 2004
-
-
- 7.12. Link Layer. . . . . . . . . . . . . . . . . . . . . . . 53
- 7.13. Separation of Authenticator and Backend Authentication
- Server. . . . . . . . . . . . . . . . . . . . . . . . . 54
- 7.14. Cleartext Passwords . . . . . . . . . . . . . . . . . . 55
- 7.15. Channel Binding . . . . . . . . . . . . . . . . . . . . 55
- 7.16. Protected Result Indications. . . . . . . . . . . . . . 56
- 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 58
- 9. References. . . . . . . . . . . . . . . . . . . . . . . . . . 59
- 9.1. Normative References. . . . . . . . . . . . . . . . . . 59
- 9.2. Informative References. . . . . . . . . . . . . . . . . 60
- Appendix A. Changes from RFC 2284. . . . . . . . . . . . . . . . . 64
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
- Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 67
-
-1. Introduction
-
- This document defines the Extensible Authentication Protocol (EAP),
- an authentication framework which supports multiple authentication
- methods. EAP typically runs directly over data link layers such as
- Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP
- provides its own support for duplicate elimination and
- retransmission, but is reliant on lower layer ordering guarantees.
- Fragmentation is not supported within EAP itself; however, individual
- EAP methods may support this.
-
- EAP may be used on dedicated links, as well as switched circuits, and
- wired as well as wireless links. To date, EAP has been implemented
- with hosts and routers that connect via switched circuits or dial-up
- lines using PPP [RFC1661]. It has also been implemented with
- switches and access points using IEEE 802 [IEEE-802]. EAP
- encapsulation on IEEE 802 wired media is described in [IEEE-802.1X],
- and encapsulation on IEEE wireless LANs in [IEEE-802.11i].
-
- 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 to be updated to support each new
- authentication method, EAP permits the use of a backend
- authentication server, which may implement some or all authentication
- methods, with the authenticator acting as a pass-through for some or
- all methods and peers.
-
- Within this document, authenticator requirements apply regardless of
- whether the authenticator is operating as a pass-through or not.
- Where the requirement is meant to apply to either the authenticator
- or backend authentication server, depending on where the EAP
- authentication is terminated, the term "EAP server" will be used.
-
-
-
-Aboba, et al. Standards Track [Page 3]
-\f
-RFC 3748 EAP June 2004
-
-
-1.1. Specification of Requirements
-
- In this document, several words are used to signify the requirements
- of the specification. 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].
-
-1.2. Terminology
-
- This document frequently uses the following terms:
-
- authenticator
- The end of the link initiating EAP authentication. The term
- authenticator is used in [IEEE-802.1X], and has the same meaning
- in this document.
-
- peer
- The end of the link that responds to the authenticator. In
- [IEEE-802.1X], this end is known as the Supplicant.
-
- Supplicant
- The end of the link that responds to the authenticator in [IEEE-
- 802.1X]. In this document, this end of the link is called the
- peer.
-
- backend authentication server
- A backend authentication server is an entity that provides an
- authentication service to an authenticator. When used, this
- server typically executes EAP methods for the authenticator. This
- terminology is also used in [IEEE-802.1X].
-
- AAA
- Authentication, Authorization, and Accounting. AAA protocols with
- EAP support include RADIUS [RFC3579] and Diameter [DIAM-EAP]. In
- this document, the terms "AAA server" and "backend authentication
- server" are used interchangeably.
-
- Displayable Message
- This is interpreted to be a human readable string of characters.
- The message encoding MUST follow the UTF-8 transformation format
- [RFC2279].
-
-
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 4]
-\f
-RFC 3748 EAP June 2004
-
-
- EAP server
- The entity that terminates the EAP authentication method with the
- peer. In the case where no backend authentication server is used,
- the EAP server is part of the authenticator. In the case where
- the authenticator operates in pass-through mode, the EAP server is
- located on the backend authentication server.
-
- Silently Discard
- This means the implementation discards the packet without further
- processing. The implementation SHOULD provide the capability of
- logging the event, including the contents of the silently
- discarded packet, and SHOULD record the event in a statistics
- counter.
-
- Successful Authentication
- In the context of this document, "successful authentication" is an
- exchange of EAP messages, as a result of which the authenticator
- decides to allow access by the peer, and the peer decides to use
- this access. The authenticator's decision typically involves both
- authentication and authorization aspects; the peer may
- successfully authenticate to the authenticator, but access may be
- denied by the authenticator due to policy reasons.
-
- Message Integrity Check (MIC)
- A keyed hash function used for authentication and integrity
- protection of data. This is usually called a Message
- Authentication Code (MAC), but IEEE 802 specifications (and this
- document) use the acronym MIC to avoid confusion with Medium
- Access Control.
-
- Cryptographic Separation
- Two keys (x and y) are "cryptographically separate" if an
- adversary that knows all messages exchanged in the protocol cannot
- compute x from y or y from x without "breaking" some cryptographic
- assumption. In particular, this definition allows that the
- adversary has the knowledge of all nonces sent in cleartext, as
- well as all predictable counter values used in the protocol.
- Breaking a cryptographic assumption would typically require
- inverting a one-way function or predicting the outcome of a
- cryptographic pseudo-random number generator without knowledge of
- the secret state. In other words, if the keys are
- cryptographically separate, there is no shortcut to compute x from
- y or y from x, but the work an adversary must do to perform this
- computation is equivalent to performing an exhaustive search for
- the secret state value.
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 5]
-\f
-RFC 3748 EAP June 2004
-
-
- Master Session Key (MSK)
- Keying material that is derived between the EAP peer and server
- and exported by the EAP method. The MSK is at least 64 octets in
- length. In existing implementations, a AAA server acting as an
- EAP server transports the MSK to the authenticator.
-
- Extended Master Session Key (EMSK)
- Additional keying material derived between the EAP client and
- server that is exported by the EAP method. The EMSK is at least
- 64 octets in length. The EMSK is not shared with the
- authenticator or any other third party. The EMSK is reserved for
- future uses that are not defined yet.
-
- Result indications
- A method provides result indications if after the method's last
- message is sent and received:
-
- 1) The peer is aware of whether it has authenticated the server,
- as well as whether the server has authenticated it.
-
- 2) The server is aware of whether it has authenticated the peer,
- as well as whether the peer has authenticated it.
-
- In the case where successful authentication is sufficient to
- authorize access, then the peer and authenticator will also know if
- the other party is willing to provide or accept access. This may not
- always be the case. An authenticated peer may be denied access due
- to lack of authorization (e.g., session limit) or other reasons.
- Since the EAP exchange is run between the peer and the server, other
- nodes (such as AAA proxies) may also affect the authorization
- decision. This is discussed in more detail in Section 7.16.
-
-1.3. Applicability
-
- EAP was designed for use in network access authentication, where IP
- layer connectivity may not be available. Use of EAP for other
- purposes, such as bulk data transport, is NOT RECOMMENDED.
-
- Since EAP does not require IP connectivity, it provides just enough
- support for the reliable transport of authentication protocols, and
- no more.
-
- EAP is a lock-step protocol which only supports a single packet in
- flight. As a result, EAP cannot efficiently transport bulk data,
- unlike transport protocols such as TCP [RFC793] or SCTP [RFC2960].
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 6]
-\f
-RFC 3748 EAP June 2004
-
-
- While EAP provides support for retransmission, it assumes ordering
- guarantees provided by the lower layer, so out of order reception is
- not supported.
-
- Since EAP does not support fragmentation and reassembly, EAP
- authentication methods generating payloads larger than the minimum
- EAP MTU need to provide fragmentation support.
-
- While authentication methods such as EAP-TLS [RFC2716] provide
- support for fragmentation and reassembly, the EAP methods defined in
- this document do not. As a result, if the EAP packet size exceeds
- the EAP MTU of the link, these methods will encounter difficulties.
-
- EAP authentication is initiated by the server (authenticator),
- whereas many authentication protocols are initiated by the client
- (peer). As a result, it may be necessary for an authentication
- algorithm to add one or two additional messages (at most one
- roundtrip) in order to run over EAP.
-
- Where certificate-based authentication is supported, the number of
- additional roundtrips may be much larger due to fragmentation of
- certificate chains. In general, a fragmented EAP packet will require
- as many round-trips to send as there are fragments. For example, a
- certificate chain 14960 octets in size would require ten round-trips
- to send with a 1496 octet EAP MTU.
-
- Where EAP runs over a lower layer in which significant packet loss is
- experienced, or where the connection between the authenticator and
- authentication server experiences significant packet loss, EAP
- methods requiring many round-trips can experience difficulties. In
- these situations, use of EAP methods with fewer roundtrips is
- advisable.
-
-2. Extensible Authentication Protocol (EAP)
-
- The EAP authentication exchange proceeds as follows:
-
- [1] The authenticator sends a Request to authenticate the peer. The
- Request has a Type field to indicate what is being requested.
- Examples of Request Types include Identity, MD5-challenge, etc.
- The MD5-challenge Type corresponds closely to the CHAP
- authentication protocol [RFC1994]. Typically, the authenticator
- will send an initial Identity Request; however, an initial
- Identity Request is not required, and MAY be bypassed. For
- example, the identity may not be required where it is determined
- by the port to which the peer has connected (leased lines,
-
-
-
-
-
-Aboba, et al. Standards Track [Page 7]
-\f
-RFC 3748 EAP June 2004
-
-
- dedicated switch or dial-up ports), or where the identity is
- obtained in another fashion (via calling station identity or MAC
- address, in the Name field of the MD5-Challenge Response, etc.).
-
- [2] The peer sends a Response packet in reply to a valid Request. As
- with the Request packet, the Response packet contains a Type
- field, which corresponds to the Type field of the Request.
-
- [3] The authenticator sends an additional Request packet, and the
- peer replies with a Response. The sequence of Requests and
- Responses continues as long as needed. EAP is a 'lock step'
- protocol, so that other than the initial Request, a new Request
- cannot be sent prior to receiving a valid Response. The
- authenticator is responsible for retransmitting requests as
- described in Section 4.1. After a suitable number of
- retransmissions, the authenticator SHOULD end the EAP
- conversation. The authenticator MUST NOT send a Success or
- Failure packet when retransmitting or when it fails to get a
- response from the peer.
-
- [4] The conversation continues until the authenticator cannot
- authenticate the peer (unacceptable Responses to one or more
- Requests), in which case the authenticator implementation MUST
- transmit an EAP Failure (Code 4). Alternatively, the
- authentication conversation can continue until the authenticator
- determines that successful authentication has occurred, in which
- case the authenticator MUST transmit an EAP Success (Code 3).
-
- Advantages:
-
- o The EAP protocol can support multiple authentication mechanisms
- without having to pre-negotiate a particular one.
-
- o Network Access Server (NAS) devices (e.g., a switch or access
- point) do not have to understand each authentication method and
- MAY act as a pass-through agent for a backend authentication
- server. Support for pass-through is optional. An authenticator
- MAY authenticate local peers, while at the same time acting as a
- pass-through for non-local peers and authentication methods it
- does not implement locally.
-
- o Separation of the authenticator from the backend authentication
- server simplifies credentials management and policy decision
- making.
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 8]
-\f
-RFC 3748 EAP June 2004
-
-
- Disadvantages:
-
- o For use in PPP, EAP requires the addition of a new authentication
- Type to PPP LCP and thus PPP implementations will need to be
- modified to use it. It also strays from the previous PPP
- authentication model of negotiating a specific authentication
- mechanism during LCP. Similarly, switch or access point
- implementations need to support [IEEE-802.1X] in order to use EAP.
-
- o Where the authenticator is separate from the backend
- authentication server, this complicates the security analysis and,
- if needed, key distribution.
-
-2.1. Support for Sequences
-
- An EAP conversation MAY utilize a sequence of methods. A common
- example of this is an Identity request followed by a single EAP
- authentication method such as an MD5-Challenge. However, the peer
- and authenticator MUST utilize only one authentication method (Type 4
- or greater) within an EAP conversation, after which the authenticator
- MUST send a Success or Failure packet.
-
- Once a peer has sent a Response of the same Type as the initial
- Request, an authenticator MUST NOT send a Request of a different Type
- prior to completion of the final round of a given method (with the
- exception of a Notification-Request) and MUST NOT send a Request for
- an additional method of any Type after completion of the initial
- authentication method; a peer receiving such Requests MUST treat them
- as invalid, and silently discard them. As a result, Identity Requery
- is not supported.
-
- A peer MUST NOT send a Nak (legacy or expanded) in reply to a Request
- after an initial non-Nak Response has been sent. Since spoofed EAP
- Request packets may be sent by an attacker, an authenticator
- receiving an unexpected Nak SHOULD discard it and log the event.
-
- Multiple authentication methods within an EAP conversation are not
- supported due to their vulnerability to man-in-the-middle attacks
- (see Section 7.4) and incompatibility with existing implementations.
-
- Where a single EAP authentication method is utilized, but other
- methods are run within it (a "tunneled" method), the prohibition
- against multiple authentication methods does not apply. Such
- "tunneled" methods appear as a single authentication method to EAP.
- Backward compatibility can be provided, since a peer not supporting a
- "tunneled" method can reply to the initial EAP-Request with a Nak
-
-
-
-
-
-Aboba, et al. Standards Track [Page 9]
-\f
-RFC 3748 EAP June 2004
-
-
- (legacy or expanded). To address security vulnerabilities,
- "tunneled" methods MUST support protection against man-in-the-middle
- attacks.
-
-2.2. EAP Multiplexing Model
-
- Conceptually, EAP implementations consist of the following
- components:
-
- [a] Lower layer. The lower layer is responsible for transmitting and
- receiving EAP frames between the peer and authenticator. EAP has
- been run over a variety of lower layers including PPP, wired IEEE
- 802 LANs [IEEE-802.1X], IEEE 802.11 wireless LANs [IEEE-802.11],
- UDP (L2TP [RFC2661] and IKEv2 [IKEv2]), and TCP [PIC]. Lower
- layer behavior is discussed in Section 3.
-
- [b] EAP layer. The EAP layer receives and transmits EAP packets via
- the lower layer, implements duplicate detection and
- retransmission, and delivers and receives EAP messages to and
- from the EAP peer and authenticator layers.
-
- [c] EAP peer and authenticator layers. Based on the Code field, the
- EAP layer demultiplexes incoming EAP packets to the EAP peer and
- authenticator layers. Typically, an EAP implementation on a
- given host will support either peer or authenticator
- functionality, but it is possible for a host to act as both an
- EAP peer and authenticator. In such an implementation both EAP
- peer and authenticator layers will be present.
-
- [d] EAP method layers. EAP methods implement the authentication
- algorithms and receive and transmit EAP messages via the EAP peer
- and authenticator layers. Since fragmentation support is not
- provided by EAP itself, this is the responsibility of EAP
- methods, which are discussed in Section 5.
-
- The EAP multiplexing model is illustrated in Figure 1 below. Note
- that there is no requirement that an implementation conform to this
- model, as long as the on-the-wire behavior is consistent with it.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 10]
-\f
-RFC 3748 EAP June 2004
-
-
- +-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
- | | | | | |
- | EAP method| EAP method| | EAP method| EAP method|
- | Type = X | Type = Y | | Type = X | Type = Y |
- | V | | | ^ | |
- +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
- | ! | | ! |
- | EAP ! Peer layer | | EAP ! Auth. layer |
- | ! | | ! |
- +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
- | ! | | ! |
- | EAP ! layer | | EAP ! layer |
- | ! | | ! |
- +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
- | ! | | ! |
- | Lower ! layer | | Lower ! layer |
- | ! | | ! |
- +-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
- ! !
- ! Peer ! Authenticator
- +------------>-------------+
-
- Figure 1: EAP Multiplexing Model
-
- Within EAP, the Code field functions much like a protocol number in
- IP. It is assumed that the EAP layer demultiplexes incoming EAP
- packets according to the Code field. Received EAP packets with
- Code=1 (Request), 3 (Success), and 4 (Failure) are delivered by the
- EAP layer to the EAP peer layer, if implemented. EAP packets with
- Code=2 (Response) are delivered to the EAP authenticator layer, if
- implemented.
-
- Within EAP, the Type field functions much like a port number in UDP
- or TCP. It is assumed that the EAP peer and authenticator layers
- demultiplex incoming EAP packets according to their Type, and deliver
- them only to the EAP method corresponding to that Type. An EAP
- method implementation on a host may register to receive packets from
- the peer or authenticator layers, or both, depending on which role(s)
- it supports.
-
- Since EAP authentication methods may wish to access the Identity,
- implementations SHOULD make the Identity Request and Response
- accessible to authentication methods (Types 4 or greater), in
- addition to the Identity method. The Identity Type is discussed in
- Section 5.1.
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 11]
-\f
-RFC 3748 EAP June 2004
-
-
- A Notification Response is only used as confirmation that the peer
- received the Notification Request, not that it has processed it, or
- displayed the message to the user. It cannot be assumed that the
- contents of the Notification Request or Response are available to
- another method. The Notification Type is discussed in Section 5.2.
-
- Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes
- of method negotiation. Peers respond to an initial EAP Request for
- an unacceptable Type with a Nak Response (Type 3) or Expanded Nak
- Response (Type 254). It cannot be assumed that the contents of the
- Nak Response(s) are available to another method. The Nak Type(s) are
- discussed in Section 5.3.
-
- EAP packets with Codes of Success or Failure do not include a Type
- field, and are not delivered to an EAP method. Success and Failure
- are discussed in Section 4.2.
-
- Given these considerations, the Success, Failure, Nak Response(s),
- and Notification Request/Response messages MUST NOT be used to carry
- data destined for delivery to other EAP methods.
-
-2.3. Pass-Through Behavior
-
- When operating as a "pass-through authenticator", an authenticator
- performs checks on the Code, Identifier, and Length fields as
- described in Section 4.1. It forwards EAP packets received from the
- peer and destined to its authenticator layer to the backend
- authentication server; packets received from the backend
- authentication server destined to the peer are forwarded to it.
-
- A host receiving an EAP packet may only do one of three things with
- it: act on it, drop it, or forward it. The forwarding decision is
- typically based only on examination of the Code, Identifier, and
- Length fields. A pass-through authenticator implementation MUST be
- capable of forwarding EAP packets received from the peer with Code=2
- (Response) to the backend authentication server. It also MUST be
- capable of receiving EAP packets from the backend authentication
- server and forwarding EAP packets of Code=1 (Request), Code=3
- (Success), and Code=4 (Failure) to the peer.
-
- Unless the authenticator implements one or more authentication
- methods locally which support the authenticator role, the EAP method
- layer header fields (Type, Type-Data) are not examined as part of the
- forwarding decision. Where the authenticator supports local
- authentication methods, it MAY examine the Type field to determine
- whether to act on the packet itself or forward it. Compliant pass-
- through authenticator implementations MUST by default forward EAP
- packets of any Type.
-
-
-
-Aboba, et al. Standards Track [Page 12]
-\f
-RFC 3748 EAP June 2004
-
-
- EAP packets received with Code=1 (Request), Code=3 (Success), and
- Code=4 (Failure) are demultiplexed by the EAP layer and delivered to
- the peer layer. Therefore, unless a host implements an EAP peer
- layer, these packets will be silently discarded. Similarly, EAP
- packets received with Code=2 (Response) are demultiplexed by the EAP
- layer and delivered to the authenticator layer. Therefore, unless a
- host implements an EAP authenticator layer, these packets will be
- silently discarded. The behavior of a "pass-through peer" is
- undefined within this specification, and is unsupported by AAA
- protocols such as RADIUS [RFC3579] and Diameter [DIAM-EAP].
-
- The forwarding model is illustrated in Figure 2.
-
- Peer Pass-through Authenticator Authentication
- Server
-
- +-+-+-+-+-+-+ +-+-+-+-+-+-+
- | | | |
- |EAP method | |EAP method |
- | V | | ^ |
- +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
- | ! | |EAP | EAP | | | ! |
- | ! | |Peer | Auth.| EAP Auth. | | ! |
- |EAP ! peer| | | +-----------+ | |EAP !Auth.|
- | ! | | | ! | ! | | ! |
- +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
- | ! | | ! | ! | | ! |
- |EAP !layer| | EAP !layer| EAP !layer | |EAP !layer|
- | ! | | ! | ! | | ! |
- +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
- | ! | | ! | ! | | ! |
- |Lower!layer| | Lower!layer| AAA ! /IP | | AAA ! /IP |
- | ! | | ! | ! | | ! |
- +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
- ! ! ! !
- ! ! ! !
- +-------->--------+ +--------->-------+
-
-
- Figure 2: Pass-through Authenticator
-
- For sessions in which the authenticator acts as a pass-through, it
- MUST determine the outcome of the authentication solely based on the
- Accept/Reject indication sent by the backend authentication server;
- the outcome MUST NOT be determined by the contents of an EAP packet
- sent along with the Accept/Reject indication, or the absence of such
- an encapsulated EAP packet.
-
-
-
-
-Aboba, et al. Standards Track [Page 13]
-\f
-RFC 3748 EAP June 2004
-
-
-2.4. Peer-to-Peer Operation
-
- Since EAP is a peer-to-peer protocol, an independent and simultaneous
- authentication may take place in the reverse direction (depending on
- the capabilities of the lower layer). Both ends of the link may act
- as authenticators and peers at the same time. In this case, it is
- necessary for both ends to implement EAP authenticator and peer
- layers. In addition, the EAP method implementations on both peers
- must support both authenticator and peer functionality.
-
- Although EAP supports peer-to-peer operation, some EAP
- implementations, methods, AAA protocols, and link layers may not
- support this. Some EAP methods may support asymmetric
- authentication, with one type of credential being required for the
- peer and another type for the authenticator. Hosts supporting peer-
- to-peer operation with such a method would need to be provisioned
- with both types of credentials.
-
- For example, EAP-TLS [RFC2716] is a client-server protocol in which
- distinct certificate profiles are typically utilized for the client
- and server. This implies that a host supporting peer-to-peer
- authentication with EAP-TLS would need to implement both the EAP peer
- and authenticator layers, support both peer and authenticator roles
- in the EAP-TLS implementation, and provision certificates appropriate
- for each role.
-
- AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP [DIAM-
- EAP] only support "pass-through authenticator" operation. As noted
- in [RFC3579] Section 2.6.2, a RADIUS server responds to an Access-
- Request encapsulating an EAP-Request, Success, or Failure packet with
- an Access-Reject. There is therefore no support for "pass-through
- peer" operation.
-
- Even where a method is used which supports mutual authentication and
- result indications, several considerations may dictate that two EAP
- authentications (one in each direction) are required. These include:
-
- [1] Support for bi-directional session key derivation in the lower
- layer. Lower layers such as IEEE 802.11 may only support uni-
- directional derivation and transport of transient session keys.
- For example, the group-key handshake defined in [IEEE-802.11i] is
- uni-directional, since in IEEE 802.11 infrastructure mode, only
- the Access Point (AP) sends multicast/broadcast traffic. In IEEE
- 802.11 ad hoc mode, where either peer may send
- multicast/broadcast traffic, two uni-directional group-key
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 14]
-\f
-RFC 3748 EAP June 2004
-
-
- exchanges are required. Due to limitations of the design, this
- also implies the need for unicast key derivations and EAP method
- exchanges to occur in each direction.
-
- [2] Support for tie-breaking in the lower layer. Lower layers such
- as IEEE 802.11 ad hoc do not support "tie breaking" wherein two
- hosts initiating authentication with each other will only go
- forward with a single authentication. This implies that even if
- 802.11 were to support a bi-directional group-key handshake, then
- two authentications, one in each direction, might still occur.
-
- [3] Peer policy satisfaction. EAP methods may support result
- indications, enabling the peer to indicate to the EAP server
- within the method that it successfully authenticated the EAP
- server, as well as for the server to indicate that it has
- authenticated the peer. However, a pass-through authenticator
- will not be aware that the peer has accepted the credentials
- offered by the EAP server, unless this information is provided to
- the authenticator via the AAA protocol. The authenticator SHOULD
- interpret the receipt of a key attribute within an Accept packet
- as an indication that the peer has successfully authenticated the
- server.
-
- However, it is possible that the EAP peer's access policy was not
- satisfied during the initial EAP exchange, even though mutual
- authentication occurred. For example, the EAP authenticator may not
- have demonstrated authorization to act in both peer and authenticator
- roles. As a result, the peer may require an additional
- authentication in the reverse direction, even if the peer provided an
- indication that the EAP server had successfully authenticated to it.
-
-3. Lower Layer Behavior
-
-3.1. Lower Layer Requirements
-
- EAP makes the following assumptions about lower layers:
-
- [1] Unreliable transport. In EAP, the authenticator retransmits
- Requests that have not yet received Responses so that EAP does
- not assume that lower layers are reliable. Since EAP defines its
- own retransmission behavior, it is possible (though undesirable)
- for retransmission to occur both in the lower layer and the EAP
- layer when EAP is run over a reliable lower layer.
-
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 15]
-\f
-RFC 3748 EAP June 2004
-
-
- Note that EAP Success and Failure packets are not retransmitted.
- Without a reliable lower layer, and with a non-negligible error rate,
- these packets can be lost, resulting in timeouts. It is therefore
- desirable for implementations to improve their resilience to loss of
- EAP Success or Failure packets, as described in Section 4.2.
-
- [2] Lower layer error detection. While EAP does not assume that the
- lower layer is reliable, it does rely on lower layer error
- detection (e.g., CRC, Checksum, MIC, etc.). EAP methods may not
- include a MIC, or if they do, it may not be computed over all the
- fields in the EAP packet, such as the Code, Identifier, Length,
- or Type fields. As a result, without lower layer error
- detection, undetected errors could creep into the EAP layer or
- EAP method layer header fields, resulting in authentication
- failures.
-
- For example, EAP TLS [RFC2716], which computes its MIC over the
- Type-Data field only, regards MIC validation failures as a fatal
- error. Without lower layer error detection, this method, and
- others like it, will not perform reliably.
-
- [3] Lower layer security. EAP does not require lower layers to
- provide security services such as per-packet confidentiality,
- authentication, integrity, and replay protection. However, where
- these security services are available, EAP methods supporting Key
- Derivation (see Section 7.2.1) can be used to provide dynamic
- keying material. This makes it possible to bind the EAP
- authentication to subsequent data and protect against data
- modification, spoofing, or replay. See Section 7.1 for details.
-
- [4] Minimum MTU. EAP is capable of functioning on lower layers that
- provide an EAP MTU size of 1020 octets or greater.
-
- EAP does not support path MTU discovery, and fragmentation and
- reassembly is not supported by EAP, nor by the methods defined in
- this specification: Identity (1), Notification (2), Nak Response
- (3), MD5-Challenge (4), One Time Password (5), Generic Token Card
- (6), and expanded Nak Response (254) Types.
-
- Typically, the EAP peer obtains information on the EAP MTU from
- the lower layers and sets the EAP frame size to an appropriate
- value. Where the authenticator operates in pass-through mode,
- the authentication server does not have a direct way of
- determining the EAP MTU, and therefore relies on the
- authenticator to provide it with this information, such as via
- the Framed-MTU attribute, as described in [RFC3579], Section 2.4.
-
-
-
-
-
-Aboba, et al. Standards Track [Page 16]
-\f
-RFC 3748 EAP June 2004
-
-
- While methods such as EAP-TLS [RFC2716] support fragmentation and
- reassembly, EAP methods originally designed for use within PPP
- where a 1500 octet MTU is guaranteed for control frames (see
- [RFC1661], Section 6.1) may lack fragmentation and reassembly
- features.
-
- EAP methods can assume a minimum EAP MTU of 1020 octets in the
- absence of other information. EAP methods SHOULD include support
- for fragmentation and reassembly if their payloads can be larger
- than this minimum EAP MTU.
-
- EAP is a lock-step protocol, which implies a certain inefficiency
- when handling fragmentation and reassembly. Therefore, if the
- lower layer supports fragmentation and reassembly (such as where
- EAP is transported over IP), it may be preferable for
- fragmentation and reassembly to occur in the lower layer rather
- than in EAP. This can be accomplished by providing an
- artificially large EAP MTU to EAP, causing fragmentation and
- reassembly to be handled within the lower layer.
-
- [5] Possible duplication. Where the lower layer is reliable, it will
- provide the EAP layer with a non-duplicated stream of packets.
- However, while it is desirable that lower layers provide for
- non-duplication, this is not a requirement. The Identifier field
- provides both the peer and authenticator with the ability to
- detect duplicates.
-
- [6] Ordering guarantees. EAP does not require the Identifier to be
- monotonically increasing, and so is reliant on lower layer
- ordering guarantees for correct operation. EAP was originally
- defined to run on PPP, and [RFC1661] Section 1 has an ordering
- requirement:
-
- "The Point-to-Point Protocol is designed for simple links
- which transport packets between two peers. These links
- provide full-duplex simultaneous bi-directional operation,
- and are assumed to deliver packets in order."
-
- Lower layer transports for EAP MUST preserve ordering between a
- source and destination at a given priority level (the ordering
- guarantee provided by [IEEE-802]).
-
- Reordering, if it occurs, will typically result in an EAP
- authentication failure, causing EAP authentication to be re-run.
- In an environment in which reordering is likely, it is therefore
- expected that EAP authentication failures will be common. It is
- RECOMMENDED that EAP only be run over lower layers that provide
- ordering guarantees; running EAP over raw IP or UDP transport is
-
-
-
-Aboba, et al. Standards Track [Page 17]
-\f
-RFC 3748 EAP June 2004
-
-
- NOT RECOMMENDED. Encapsulation of EAP within RADIUS [RFC3579]
- satisfies ordering requirements, since RADIUS is a "lockstep"
- protocol that delivers packets in order.
-
-3.2. EAP Usage Within PPP
-
- In order to establish communications over a point-to-point link, each
- end of the PPP link first sends LCP packets to configure the data
- link during the 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 the Link
- Establishment phase.
-
- If the identity of the peer has been established in the
- Authentication phase, the server can use that identity in the
- selection of options for the following network layer negotiations.
-
- When implemented within PPP, EAP does not select a specific
- authentication mechanism at the PPP Link Control Phase, but rather
- postpones this until the Authentication Phase. This allows the
- authenticator to request more information before determining the
- specific authentication mechanism. This also permits the use of a
- "backend" server which actually implements the various mechanisms
- while the PPP authenticator merely passes through the authentication
- exchange. The PPP Link Establishment and Authentication phases, and
- the Authentication Protocol Configuration Option, are defined in The
- Point-to-Point Protocol (PPP) [RFC1661].
-
-3.2.1. PPP Configuration Option Format
-
- A summary of the PPP Authentication Protocol Configuration Option
- format to negotiate EAP follows. The fields are transmitted from
- left to right.
-
- Exactly one EAP packet is encapsulated in the Information field of a
- PPP Data Link Layer frame where the protocol field indicates type hex
- C227 (PPP EAP).
-
-
-
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 18]
-\f
-RFC 3748 EAP June 2004
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Authentication Protocol |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 3
-
- Length
-
- 4
-
- Authentication Protocol
-
- C227 (Hex) for Extensible Authentication Protocol (EAP)
-
-3.3. EAP Usage Within IEEE 802
-
- The encapsulation of EAP over IEEE 802 is defined in [IEEE-802.1X].
- The IEEE 802 encapsulation of EAP does not involve PPP, and IEEE
- 802.1X does not include support for link or network layer
- negotiations. As a result, within IEEE 802.1X, it is not possible to
- negotiate non-EAP authentication mechanisms, such as PAP or CHAP
- [RFC1994].
-
-3.4. Lower Layer Indications
-
- The reliability and security of lower layer indications is dependent
- on the lower layer. Since EAP is media independent, the presence or
- absence of lower layer security is not taken into account in the
- processing of EAP messages.
-
- To improve reliability, if a peer receives a lower layer success
- indication as defined in Section 7.2, it MAY conclude that a Success
- packet has been lost, and behave as if it had actually received a
- Success packet. This includes choosing to ignore the Success in some
- circumstances as described in Section 4.2.
-
- A discussion of some reliability and security issues with lower layer
- indications in PPP, IEEE 802 wired networks, and IEEE 802.11 wireless
- LANs can be found in the Security Considerations, Section 7.12.
-
- After EAP authentication is complete, the peer will typically
- transmit and receive data via the authenticator. It is desirable to
- provide assurance that the entities transmitting data are the same
- ones that successfully completed EAP authentication. To accomplish
-
-
-
-Aboba, et al. Standards Track [Page 19]
-\f
-RFC 3748 EAP June 2004
-
-
- this, it is necessary for the lower layer to provide per-packet
- integrity, authentication and replay protection, and to bind these
- per-packet services to the keys derived during EAP authentication.
- Otherwise, it is possible for subsequent data traffic to be modified,
- spoofed, or replayed.
-
- Where keying material for the lower layer ciphersuite is itself
- provided by EAP, ciphersuite negotiation and key activation are
- controlled by the lower layer. In PPP, ciphersuites are negotiated
- within ECP so that it is not possible to use keys derived from EAP
- authentication until the completion of ECP. Therefore, an initial
- EAP exchange cannot be protected by a PPP ciphersuite, although EAP
- re-authentication can be protected.
-
- In IEEE 802 media, initial key activation also typically occurs after
- completion of EAP authentication. Therefore an initial EAP exchange
- typically cannot be protected by the lower layer ciphersuite,
- although an EAP re-authentication or pre-authentication exchange can
- be protected.
-
-4. EAP Packet Format
-
- A summary of the EAP packet format is shown below. The fields are
- transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Data ...
- +-+-+-+-+
-
- Code
-
- The Code field is one octet and identifies the Type of EAP packet.
- EAP Codes are assigned as follows:
-
- 1 Request
- 2 Response
- 3 Success
- 4 Failure
-
- Since EAP only defines Codes 1-4, EAP packets with other codes
- MUST be silently discarded by both authenticators and peers.
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 20]
-\f
-RFC 3748 EAP June 2004
-
-
- Identifier
-
- The Identifier field is one octet and aids in matching Responses
- with Requests.
-
- Length
-
- The Length field is two octets and indicates the length, in
- octets, of the EAP 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 MUST be ignored
- upon reception. A message with the Length field set to a value
- larger than the number of received octets MUST be silently
- discarded.
-
- Data
-
- The Data field is zero or more octets. The format of the Data
- field is determined by the Code field.
-
-4.1. Request and Response
-
- Description
-
- The Request packet (Code field set to 1) is sent by the
- authenticator to the peer. Each Request has a Type field which
- serves to indicate what is being requested. Additional Request
- packets MUST be sent until a valid Response packet is received, an
- optional retry counter expires, or a lower layer failure
- indication is received.
-
- Retransmitted Requests MUST be sent with the same Identifier value
- in order to distinguish them from new Requests. The content of
- the data field is dependent on the Request Type. The peer MUST
- send a Response packet in reply to a valid Request packet.
- Responses MUST only be sent in reply to a valid Request and never
- be retransmitted on a timer.
-
- If a peer receives a valid duplicate Request for which it has
- already sent a Response, it MUST resend its original Response
- without reprocessing the Request. Requests MUST be processed in
- the order that they are received, and MUST be processed to their
- completion before inspecting the next Request.
-
- A summary of the Request and Response packet format follows. The
- fields are transmitted from left to right.
-
-
-
-
-
-Aboba, et al. Standards Track [Page 21]
-\f
-RFC 3748 EAP June 2004
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Type-Data ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Code
-
- 1 for Request
- 2 for Response
-
- Identifier
-
- The Identifier field is one octet. The Identifier field MUST be
- the same if a Request packet is retransmitted due to a timeout
- while waiting for a Response. Any new (non-retransmission)
- Requests MUST modify the Identifier field.
-
- The Identifier field of the Response MUST match that of the
- currently outstanding Request. An authenticator receiving a
- Response whose Identifier value does not match that of the
- currently outstanding Request MUST silently discard the Response.
-
- In order to avoid confusion between new Requests and
- retransmissions, the Identifier value chosen for each new Request
- need only be different from the previous Request, but need not be
- unique within the conversation. One way to achieve this is to
- start the Identifier at an initial value and increment it for each
- new Request. Initializing the first Identifier with a random
- number rather than starting from zero is recommended, since it
- makes sequence attacks somewhat more difficult.
-
- Since the Identifier space is unique to each session,
- authenticators are not restricted to only 256 simultaneous
- authentication conversations. Similarly, with re-authentication,
- an EAP conversation might continue over a long period of time, and
- is not limited to only 256 roundtrips.
-
- Implementation Note: The authenticator is responsible for
- retransmitting Request messages. If the Request message is obtained
- from elsewhere (such as from a backend authentication server), then
- the authenticator will need to save a copy of the Request in order to
- accomplish this. The peer is responsible for detecting and handling
- duplicate Request messages before processing them in any way,
- including passing them on to an outside party. The authenticator is
- also responsible for discarding Response messages with a non-matching
-
-
-
-Aboba, et al. Standards Track [Page 22]
-\f
-RFC 3748 EAP June 2004
-
-
- Identifier value before acting on them in any way, including passing
- them on to the backend authentication server for verification. Since
- the authenticator can retransmit before receiving a Response from the
- peer, the authenticator can receive multiple Responses, each with a
- matching Identifier. Until a new Request is received by the
- authenticator, the Identifier value is not updated, so that the
- authenticator forwards Responses to the backend authentication
- server, one at a time.
-
- Length
-
- The Length field is two octets and indicates the length of the EAP
- packet including the Code, Identifier, Length, Type, and Type-Data
- fields. Octets outside the range of the Length field should be
- treated as Data Link Layer padding and MUST be ignored upon
- reception. A message with the Length field set to a value larger
- than the number of received octets MUST be silently discarded.
-
- Type
-
- The Type field is one octet. This field indicates the Type of
- Request or Response. A single Type MUST be specified for each EAP
- Request or Response. An initial specification of Types follows in
- Section 5 of this document.
-
- The Type field of a Response MUST either match that of the
- Request, or correspond to a legacy or Expanded Nak (see Section
- 5.3) indicating that a Request Type is unacceptable to the peer.
- A peer MUST NOT send a Nak (legacy or expanded) in response to a
- Request, after an initial non-Nak Response has been sent. An EAP
- server receiving a Response not meeting these requirements MUST
- silently discard it.
-
- Type-Data
-
- The Type-Data field varies with the Type of Request and the
- associated Response.
-
-4.2. Success and Failure
-
- The Success packet is sent by the authenticator to the peer after
- completion of an EAP authentication method (Type 4 or greater) to
- indicate that the peer has authenticated successfully to the
- authenticator. The authenticator MUST transmit an EAP packet with
- the Code field set to 3 (Success). If the authenticator cannot
- authenticate the peer (unacceptable Responses to one or more
- Requests), then after unsuccessful completion of the EAP method in
- progress, the implementation MUST transmit an EAP packet with the
-
-
-
-Aboba, et al. Standards Track [Page 23]
-\f
-RFC 3748 EAP June 2004
-
-
- Code field set to 4 (Failure). An authenticator MAY wish to issue
- multiple Requests before sending a Failure response in order to allow
- for human typing mistakes. Success and Failure packets MUST NOT
- contain additional data.
-
- Success and Failure packets MUST NOT be sent by an EAP authenticator
- if the specification of the given method does not explicitly permit
- the method to finish at that point. A peer EAP implementation
- receiving a Success or Failure packet where sending one is not
- explicitly permitted MUST silently discard it. By default, an EAP
- peer MUST silently discard a "canned" Success packet (a Success
- packet sent immediately upon connection). This ensures that a rogue
- authenticator will not be able to bypass mutual authentication by
- sending a Success packet prior to conclusion of the EAP method
- conversation.
-
- Implementation Note: Because the Success and Failure packets are not
- acknowledged, they are not retransmitted by the authenticator, and
- may be potentially lost. A peer MUST allow for this circumstance as
- described in this note. See also Section 3.4 for guidance on the
- processing of lower layer success and failure indications.
-
- As described in Section 2.1, only a single EAP authentication method
- is allowed within an EAP conversation. EAP methods may implement
- result indications. After the authenticator sends a failure result
- indication to the peer, regardless of the response from the peer, it
- MUST subsequently send a Failure packet. After the authenticator
- sends a success result indication to the peer and receives a success
- result indication from the peer, it MUST subsequently send a Success
- packet.
-
- On the peer, once the method completes unsuccessfully (that is,
- either the authenticator sends a failure result indication, or the
- peer decides that it does not want to continue the conversation,
- possibly after sending a failure result indication), the peer MUST
- terminate the conversation and indicate failure to the lower layer.
- The peer MUST silently discard Success packets and MAY silently
- discard Failure packets. As a result, loss of a Failure packet need
- not result in a timeout.
-
- On the peer, after success result indications have been exchanged by
- both sides, a Failure packet MUST be silently discarded. The peer
- MAY, in the event that an EAP Success is not received, conclude that
- the EAP Success packet was lost and that authentication concluded
- successfully.
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 24]
-\f
-RFC 3748 EAP June 2004
-
-
- If the authenticator has not sent a result indication, and the peer
- is willing to continue the conversation, the peer waits for a Success
- or Failure packet once the method completes, and MUST NOT silently
- discard either of them. In the event that neither a Success nor
- Failure packet is received, the peer SHOULD terminate the
- conversation to avoid lengthy timeouts in case the lost packet was an
- EAP Failure.
-
- If the peer attempts to authenticate to the authenticator and fails
- to do so, the authenticator MUST send a Failure packet and MUST NOT
- grant access by sending a Success packet. However, an authenticator
- MAY omit having the peer authenticate to it in situations where
- limited access is offered (e.g., guest access). In this case, the
- authenticator MUST send a Success packet.
-
- Where the peer authenticates successfully to the authenticator, but
- the authenticator does not send a result indication, the
- authenticator MAY deny access by sending a Failure packet where the
- peer is not currently authorized for network access.
-
- A summary of the Success and Failure packet format is shown below.
- The fields are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Code
-
- 3 for Success
- 4 for Failure
-
- Identifier
-
- The Identifier field is one octet and aids in matching replies to
- Responses. The Identifier field MUST match the Identifier field
- of the Response packet that it is sent in response to.
-
- Length
-
- 4
-
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 25]
-\f
-RFC 3748 EAP June 2004
-
-
-4.3. Retransmission Behavior
-
- Because the authentication process will often involve user input,
- some care must be taken when deciding upon retransmission strategies
- and authentication timeouts. By default, where EAP is run over an
- unreliable lower layer, the EAP retransmission timer SHOULD be
- dynamically estimated. A maximum of 3-5 retransmissions is
- suggested.
-
- When run over a reliable lower layer (e.g., EAP over ISAKMP/TCP, as
- within [PIC]), the authenticator retransmission timer SHOULD be set
- to an infinite value, so that retransmissions do not occur at the EAP
- layer. The peer may still maintain a timeout value so as to avoid
- waiting indefinitely for a Request.
-
- Where the authentication process requires user input, the measured
- round trip times may be determined by user responsiveness rather than
- network characteristics, so that dynamic RTO estimation may not be
- helpful. Instead, the retransmission timer SHOULD be set so as to
- provide sufficient time for the user to respond, with longer timeouts
- required in certain cases, such as where Token Cards (see Section
- 5.6) are involved.
-
- In order to provide the EAP authenticator with guidance as to the
- appropriate timeout value, a hint can be communicated to the
- authenticator by the backend authentication server (such as via the
- RADIUS Session-Timeout attribute).
-
- In order to dynamically estimate the EAP retransmission timer, the
- algorithms for the estimation of SRTT, RTTVAR, and RTO described in
- [RFC2988] are RECOMMENDED, including use of Karn's algorithm, with
- the following potential modifications:
-
- [a] In order to avoid synchronization behaviors that can occur with
- fixed timers among distributed systems, the retransmission timer
- is calculated with a jitter by using the RTO value and randomly
- adding a value drawn between -RTOmin/2 and RTOmin/2. Alternative
- calculations to create jitter MAY be used. These MUST be
- pseudo-random. For a discussion of pseudo-random number
- generation, see [RFC1750].
-
- [b] When EAP is transported over a single link (as opposed to over
- the Internet), smaller values of RTOinitial, RTOmin, and RTOmax
- MAY be used. Recommended values are RTOinitial=1 second,
- RTOmin=200ms, and RTOmax=20 seconds.
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 26]
-\f
-RFC 3748 EAP June 2004
-
-
- [c] When EAP is transported over a single link (as opposed to over
- the Internet), estimates MAY be done on a per-authenticator
- basis, rather than a per-session basis. This enables the
- retransmission estimate to make the most use of information on
- link-layer behavior.
-
- [d] An EAP implementation MAY clear SRTT and RTTVAR after backing off
- the timer multiple times, as it is likely that the current SRTT
- and RTTVAR are bogus in this situation. Once SRTT and RTTVAR are
- cleared, they should be initialized with the next RTT sample
- taken as described in [RFC2988] equation 2.2.
-
-5. Initial EAP Request/Response Types
-
- This section defines the initial set of EAP Types used in Request/
- Response exchanges. More Types may be defined in future documents.
- The Type field is one octet and identifies the structure of an EAP
- Request or Response packet. The first 3 Types are considered special
- case Types.
-
- The remaining Types define authentication exchanges. Nak (Type 3) or
- Expanded Nak (Type 254) are valid only for Response packets, they
- MUST NOT be sent in a Request.
-
- All EAP implementations MUST support Types 1-4, which are defined in
- this document, and SHOULD support Type 254. Implementations MAY
- support other Types defined here or in future RFCs.
-
- 1 Identity
- 2 Notification
- 3 Nak (Response only)
- 4 MD5-Challenge
- 5 One Time Password (OTP)
- 6 Generic Token Card (GTC)
- 254 Expanded Types
- 255 Experimental use
-
- EAP methods MAY support authentication based on shared secrets. If
- the shared secret is a passphrase entered by the user,
- implementations MAY support entering passphrases with non-ASCII
- characters. In this case, the input should be processed using an
- appropriate stringprep [RFC3454] profile, and encoded in octets using
- UTF-8 encoding [RFC2279]. A preliminary version of a possible
- stringprep profile is described in [SASLPREP].
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 27]
-\f
-RFC 3748 EAP June 2004
-
-
-5.1. Identity
-
- Description
-
- The Identity Type is used to query the identity of the peer.
- Generally, the authenticator will issue this as the initial
- Request. An optional displayable message MAY be included to
- prompt the peer in the case where there is an expectation of
- interaction with a user. A Response of Type 1 (Identity) SHOULD
- be sent in Response to a Request with a Type of 1 (Identity).
-
- Some EAP implementations piggy-back various options into the
- Identity Request after a NUL-character. By default, an EAP
- implementation SHOULD NOT assume that an Identity Request or
- Response can be larger than 1020 octets.
-
- It is RECOMMENDED that the Identity Response be used primarily for
- routing purposes and selecting which EAP method to use. EAP
- Methods SHOULD include a method-specific mechanism for obtaining
- the identity, so that they do not have to rely on the Identity
- Response. Identity Requests and Responses are sent in cleartext,
- so an attacker may snoop on the identity, or even modify or spoof
- identity exchanges. To address these threats, it is preferable
- for an EAP method to include an identity exchange that supports
- per-packet authentication, integrity and replay protection, and
- confidentiality. The Identity Response may not be the appropriate
- identity for the method; it may have been truncated or obfuscated
- so as to provide privacy, or it may have been decorated for
- routing purposes. Where the peer is configured to only accept
- authentication methods supporting protected identity exchanges,
- the peer MAY provide an abbreviated Identity Response (such as
- omitting the peer-name portion of the NAI [RFC2486]). For further
- discussion of identity protection, see Section 7.3.
-
- Implementation Note: The peer MAY obtain the Identity via user input.
- It is suggested that the authenticator retry the Identity Request in
- the case of an invalid Identity or authentication failure to allow
- for potential typos on the part of the user. It is suggested that
- the Identity Request be retried a minimum of 3 times before
- terminating the authentication. The Notification Request MAY be used
- to indicate an invalid authentication attempt prior to transmitting a
- new Identity Request (optionally, the failure MAY be indicated within
- the message of the new Identity Request itself).
-
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 28]
-\f
-RFC 3748 EAP June 2004
-
-
- Type
-
- 1
-
- Type-Data
-
- This field MAY contain a displayable message in the Request,
- containing UTF-8 encoded ISO 10646 characters [RFC2279]. Where
- the Request contains a null, only the portion of the field prior
- to the null is displayed. If the Identity is unknown, the
- Identity Response field should be zero bytes in length. The
- Identity Response field MUST NOT be null terminated. In all
- cases, the length of the Type-Data field is derived from the
- Length field of the Request/Response packet.
-
- Security Claims (see Section 7.2):
-
- Auth. mechanism: None
- Ciphersuite negotiation: No
- Mutual authentication: No
- Integrity protection: No
- Replay protection: No
- Confidentiality: No
- Key derivation: No
- Key strength: N/A
- Dictionary attack prot.: N/A
- Fast reconnect: No
- Crypt. binding: N/A
- Session independence: N/A
- Fragmentation: No
- Channel binding: No
-
-5.2. Notification
-
- Description
-
- The Notification Type is optionally used to convey a displayable
- message from the authenticator to the peer. An authenticator MAY
- send a Notification Request to the peer at any time when there is
- no outstanding Request, prior to completion of an EAP
- authentication method. The peer MUST respond to a Notification
- Request with a Notification Response unless the EAP authentication
- method specification prohibits the use of Notification messages.
- In any case, a Nak Response MUST NOT be sent in response to a
- Notification Request. Note that the default maximum length of a
- Notification Request is 1020 octets. By default, this leaves at
- most 1015 octets for the human readable message.
-
-
-
-
-Aboba, et al. Standards Track [Page 29]
-\f
-RFC 3748 EAP June 2004
-
-
- An EAP method MAY indicate within its specification that
- Notification messages must not be sent during that method. In
- this case, the peer MUST silently discard Notification Requests
- from the point where an initial Request for that Type is answered
- with a Response of the same Type.
-
- The peer SHOULD display this message to the user or log it if it
- cannot be displayed. The Notification Type is intended to provide
- an acknowledged notification of some imperative nature, but it is
- not an error indication, and therefore does not change the state
- of the peer. Examples include a password with an expiration time
- that is about to expire, an OTP sequence integer which is nearing
- 0, an authentication failure warning, etc. In most circumstances,
- Notification should not be required.
-
- Type
-
- 2
-
- Type-Data
-
- The Type-Data field in the Request contains a displayable message
- greater than zero octets in length, containing UTF-8 encoded ISO
- 10646 characters [RFC2279]. The length of the message is
- determined by the Length field of the Request packet. The message
- MUST NOT be null terminated. A Response MUST be sent in reply to
- the Request with a Type field of 2 (Notification). The Type-Data
- field of the Response is zero octets in length. The Response
- should be sent immediately (independent of how the message is
- displayed or logged).
-
- Security Claims (see Section 7.2):
-
- Auth. mechanism: None
- Ciphersuite negotiation: No
- Mutual authentication: No
- Integrity protection: No
- Replay protection: No
- Confidentiality: No
- Key derivation: No
- Key strength: N/A
- Dictionary attack prot.: N/A
- Fast reconnect: No
- Crypt. binding: N/A
- Session independence: N/A
- Fragmentation: No
- Channel binding: No
-
-
-
-
-Aboba, et al. Standards Track [Page 30]
-\f
-RFC 3748 EAP June 2004
-
-
-5.3. Nak
-
-5.3.1. Legacy Nak
-
- Description
-
- The legacy Nak Type is valid only in Response messages. It is
- sent in reply to a Request where the desired authentication Type
- is unacceptable. Authentication Types are numbered 4 and above.
- The Response contains one or more authentication Types desired by
- the Peer. Type zero (0) is used to indicate that the sender has
- no viable alternatives, and therefore the authenticator SHOULD NOT
- send another Request after receiving a Nak Response containing a
- zero value.
-
- Since the legacy Nak Type is valid only in Responses and has very
- limited functionality, it MUST NOT be used as a general purpose
- error indication, such as for communication of error messages, or
- negotiation of parameters specific to a particular EAP method.
-
- Code
-
- 2 for Response.
-
- Identifier
-
- The Identifier field is one octet and aids in matching Responses
- with Requests. The Identifier field of a legacy Nak Response MUST
- match the Identifier field of the Request packet that it is sent
- in response to.
-
- Length
-
- >=6
-
- Type
-
- 3
-
- Type-Data
-
- Where a peer receives a Request for an unacceptable authentication
- Type (4-253,255), or a peer lacking support for Expanded Types
- receives a Request for Type 254, a Nak Response (Type 3) MUST be
- sent. The Type-Data field of the Nak Response (Type 3) MUST
- contain one or more octets indicating the desired authentication
- Type(s), one octet per Type, or the value zero (0) to indicate no
- proposed alternative. A peer supporting Expanded Types that
-
-
-
-Aboba, et al. Standards Track [Page 31]
-\f
-RFC 3748 EAP June 2004
-
-
- receives a Request for an unacceptable authentication Type (4-253,
- 255) MAY include the value 254 in the Nak Response (Type 3) to
- indicate the desire for an Expanded authentication Type. If the
- authenticator can accommodate this preference, it will respond
- with an Expanded Type Request (Type 254).
-
- Security Claims (see Section 7.2):
-
- Auth. mechanism: None
- Ciphersuite negotiation: No
- Mutual authentication: No
- Integrity protection: No
- Replay protection: No
- Confidentiality: No
- Key derivation: No
- Key strength: N/A
- Dictionary attack prot.: N/A
- Fast reconnect: No
- Crypt. binding: N/A
- Session independence: N/A
- Fragmentation: No
- Channel binding: No
-
-
-5.3.2. Expanded Nak
-
- Description
-
- The Expanded Nak Type is valid only in Response messages. It MUST
- be sent only in reply to a Request of Type 254 (Expanded Type)
- where the authentication Type is unacceptable. The Expanded Nak
- Type uses the Expanded Type format itself, and the Response
- contains one or more authentication Types desired by the peer, all
- in Expanded Type format. Type zero (0) is used to indicate that
- the sender has no viable alternatives. The general format of the
- Expanded Type is described in Section 5.7.
-
- Since the Expanded Nak Type is valid only in Responses and has
- very limited functionality, it MUST NOT be used as a general
- purpose error indication, such as for communication of error
- messages, or negotiation of parameters specific to a particular
- EAP method.
-
- Code
-
- 2 for Response.
-
-
-
-
-
-Aboba, et al. Standards Track [Page 32]
-\f
-RFC 3748 EAP June 2004
-
-
- Identifier
-
- The Identifier field is one octet and aids in matching Responses
- with Requests. The Identifier field of an Expanded Nak Response
- MUST match the Identifier field of the Request packet that it is
- sent in response to.
-
- Length
-
- >=20
-
- Type
-
- 254
-
- Vendor-Id
-
- 0 (IETF)
-
- Vendor-Type
-
- 3 (Nak)
-
- Vendor-Data
-
- The Expanded Nak Type is only sent when the Request contains an
- Expanded Type (254) as defined in Section 5.7. The Vendor-Data
- field of the Nak Response MUST contain one or more authentication
- Types (4 or greater), all in expanded format, 8 octets per Type,
- or the value zero (0), also in Expanded Type format, to indicate
- no proposed alternative. The desired authentication Types may
- include a mixture of Vendor-Specific and IETF Types. For example,
- an Expanded Nak Response indicating a preference for OTP (Type 5),
- and an MIT (Vendor-Id=20) Expanded Type of 6 would appear as
- follows:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 33]
-\f
-RFC 3748 EAP June 2004
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 2 | Identifier | Length=28 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type=254 | 0 (IETF) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 3 (Nak) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type=254 | 0 (IETF) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 5 (OTP) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type=254 | 20 (MIT) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 6 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- An Expanded Nak Response indicating a no desired alternative would
- appear as follows:
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 2 | Identifier | Length=20 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type=254 | 0 (IETF) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 3 (Nak) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type=254 | 0 (IETF) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 0 (No alternative) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Security Claims (see Section 7.2):
-
- Auth. mechanism: None
- Ciphersuite negotiation: No
- Mutual authentication: No
- Integrity protection: No
- Replay protection: No
- Confidentiality: No
- Key derivation: No
- Key strength: N/A
- Dictionary attack prot.: N/A
- Fast reconnect: No
- Crypt. binding: N/A
-
-
-
-Aboba, et al. Standards Track [Page 34]
-\f
-RFC 3748 EAP June 2004
-
-
- Session independence: N/A
- Fragmentation: No
- Channel binding: No
-
-
-5.4. MD5-Challenge
-
- Description
-
- The MD5-Challenge Type is analogous to the PPP CHAP protocol
- [RFC1994] (with MD5 as the specified algorithm). The Request
- contains a "challenge" message to the peer. A Response MUST be
- sent in reply to the Request. The Response MAY be either of Type
- 4 (MD5-Challenge), Nak (Type 3), or Expanded Nak (Type 254). The
- Nak reply indicates the peer's desired authentication Type(s).
- EAP peer and EAP server implementations MUST support the MD5-
- Challenge mechanism. An authenticator that supports only pass-
- through MUST allow communication with a backend authentication
- server that is capable of supporting MD5-Challenge, although the
- EAP authenticator implementation need not support MD5-Challenge
- itself. However, if the EAP authenticator can be configured to
- authenticate peers locally (e.g., not operate in pass-through),
- then the requirement for support of the MD5-Challenge mechanism
- applies.
-
- Note that the use of the Identifier field in the MD5-Challenge
- Type is different from that described in [RFC1994]. EAP allows
- for retransmission of MD5-Challenge Request packets, while
- [RFC1994] states that both the Identifier and Challenge fields
- MUST change each time a Challenge (the CHAP equivalent of the
- MD5-Challenge Request packet) is sent.
-
- Note: [RFC1994] treats the shared secret as an octet string, and
- does not specify how it is entered into the system (or if it is
- handled by the user at all). EAP MD5-Challenge implementations
- MAY support entering passphrases with non-ASCII characters. See
- Section 5 for instructions how the input should be processed and
- encoded into octets.
-
- Type
-
- 4
-
- Type-Data
-
- The contents of the Type-Data field is summarized below. For
- reference on the use of these fields, see the PPP Challenge
- Handshake Authentication Protocol [RFC1994].
-
-
-
-Aboba, et al. Standards Track [Page 35]
-\f
-RFC 3748 EAP June 2004
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Value-Size | Value ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Name ...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Security Claims (see Section 7.2):
-
- Auth. mechanism: Password or pre-shared key.
- Ciphersuite negotiation: No
- Mutual authentication: No
- Integrity protection: No
- Replay protection: No
- Confidentiality: No
- Key derivation: No
- Key strength: N/A
- Dictionary attack prot.: No
- Fast reconnect: No
- Crypt. binding: N/A
- Session independence: N/A
- Fragmentation: No
- Channel binding: No
-
-5.5. One-Time Password (OTP)
-
- Description
-
- The One-Time Password system is defined in "A One-Time Password
- System" [RFC2289] and "OTP Extended Responses" [RFC2243]. The
- Request contains an OTP challenge in the format described in
- [RFC2289]. A Response MUST be sent in reply to the Request. The
- Response MUST be of Type 5 (OTP), Nak (Type 3), or Expanded Nak
- (Type 254). The Nak Response indicates the peer's desired
- authentication Type(s). The EAP OTP method is intended for use
- with the One-Time Password system only, and MUST NOT be used to
- provide support for cleartext passwords.
-
- Type
-
- 5
-
-
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 36]
-\f
-RFC 3748 EAP June 2004
-
-
- Type-Data
-
- The Type-Data field contains the OTP "challenge" as a displayable
- message in the Request. In the Response, this field is used for
- the 6 words from the OTP dictionary [RFC2289]. The messages MUST
- NOT be null terminated. The length of the field is derived from
- the Length field of the Request/Reply packet.
-
- Note: [RFC2289] does not specify how the secret pass-phrase is
- entered by the user, or how the pass-phrase is converted into
- octets. EAP OTP implementations MAY support entering passphrases
- with non-ASCII characters. See Section 5 for instructions on how
- the input should be processed and encoded into octets.
-
- Security Claims (see Section 7.2):
-
- Auth. mechanism: One-Time Password
- Ciphersuite negotiation: No
- Mutual authentication: No
- Integrity protection: No
- Replay protection: Yes
- Confidentiality: No
- Key derivation: No
- Key strength: N/A
- Dictionary attack prot.: No
- Fast reconnect: No
- Crypt. binding: N/A
- Session independence: N/A
- Fragmentation: No
- Channel binding: No
-
-
-5.6. Generic Token Card (GTC)
-
- Description
-
- The Generic Token Card Type is defined for use with various Token
- Card implementations which require user input. The Request
- contains a displayable message and the Response contains the Token
- Card information necessary for authentication. Typically, this
- would be information read by a user from the Token card device and
- entered as ASCII text. A Response MUST be sent in reply to the
- Request. The Response MUST be of Type 6 (GTC), Nak (Type 3), or
- Expanded Nak (Type 254). The Nak Response indicates the peer's
- desired authentication Type(s). The EAP GTC method is intended
- for use with the Token Cards supporting challenge/response
-
-
-
-
-
-Aboba, et al. Standards Track [Page 37]
-\f
-RFC 3748 EAP June 2004
-
-
- authentication and MUST NOT be used to provide support for
- cleartext passwords in the absence of a protected tunnel with
- server authentication.
-
- Type
-
- 6
-
- Type-Data
-
- The Type-Data field in the Request contains a displayable message
- greater than zero octets in length. The length of the message is
- determined by the Length field of the Request packet. The message
- MUST NOT be null terminated. A Response MUST be sent in reply to
- the Request with a Type field of 6 (Generic Token Card). The
- Response contains data from the Token Card required for
- authentication. The length of the data is determined by the
- Length field of the Response packet.
-
- EAP GTC implementations MAY support entering a response with non-
- ASCII characters. See Section 5 for instructions how the input
- should be processed and encoded into octets.
-
- Security Claims (see Section 7.2):
-
- Auth. mechanism: Hardware token.
- Ciphersuite negotiation: No
- Mutual authentication: No
- Integrity protection: No
- Replay protection: No
- Confidentiality: No
- Key derivation: No
- Key strength: N/A
- Dictionary attack prot.: No
- Fast reconnect: No
- Crypt. binding: N/A
- Session independence: N/A
- Fragmentation: No
- Channel binding: No
-
-
-5.7. Expanded Types
-
- Description
-
- Since many of the existing uses of EAP are vendor-specific, the
- Expanded method Type is available to allow vendors to support
- their own Expanded Types not suitable for general usage.
-
-
-
-Aboba, et al. Standards Track [Page 38]
-\f
-RFC 3748 EAP June 2004
-
-
- The Expanded Type is also used to expand the global Method Type
- space beyond the original 255 values. A Vendor-Id of 0 maps the
- original 255 possible Types onto a space of 2^32-1 possible Types.
- (Type 0 is only used in a Nak Response to indicate no acceptable
- alternative).
-
- An implementation that supports the Expanded attribute MUST treat
- EAP Types that are less than 256 equivalently, whether they appear
- as a single octet or as the 32-bit Vendor-Type within an Expanded
- Type where Vendor-Id is 0. Peers not equipped to interpret the
- Expanded Type MUST send a Nak as described in Section 5.3.1, and
- negotiate a more suitable authentication method.
-
- A summary of the Expanded Type format is shown below. The fields
- are transmitted from left to right.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Vendor-Id |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Vendor-Type |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Vendor data...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Type
-
- 254 for Expanded Type
-
- Vendor-Id
-
- The Vendor-Id is 3 octets and represents the SMI Network
- Management Private Enterprise Code of the Vendor in network byte
- order, as allocated by IANA. A Vendor-Id of zero is reserved for
- use by the IETF in providing an expanded global EAP Type space.
-
- Vendor-Type
-
- The Vendor-Type field is four octets and represents the vendor-
- specific method Type.
-
- If the Vendor-Id is zero, the Vendor-Type field is an extension
- and superset of the existing namespace for EAP Types. The first
- 256 Types are reserved for compatibility with single-octet EAP
- Types that have already been assigned or may be assigned in the
- future. Thus, EAP Types from 0 through 255 are semantically
- identical, whether they appear as single octet EAP Types or as
-
-
-
-Aboba, et al. Standards Track [Page 39]
-\f
-RFC 3748 EAP June 2004
-
-
- Vendor-Types when Vendor-Id is zero. There is one exception to
- this rule: Expanded Nak and Legacy Nak packets share the same
- Type, but must be treated differently because they have a
- different format.
-
- Vendor-Data
-
- The Vendor-Data field is defined by the vendor. Where a Vendor-Id
- of zero is present, the Vendor-Data field will be used for
- transporting the contents of EAP methods of Types defined by the
- IETF.
-
-5.8. Experimental
-
- Description
-
- The Experimental Type has no fixed format or content. It is
- intended for use when experimenting with new EAP Types. This Type
- is intended for experimental and testing purposes. No guarantee
- is made for interoperability between peers using this Type, as
- outlined in [RFC3692].
-
- Type
-
- 255
-
- Type-Data
-
- Undefined
-
-6. IANA Considerations
-
- This section provides guidance to the Internet Assigned Numbers
- Authority (IANA) regarding registration of values related to the EAP
- protocol, in accordance with BCP 26, [RFC2434].
-
- There are two name spaces in EAP that require registration: Packet
- Codes and method Types.
-
- EAP is not intended as a general-purpose protocol, and allocations
- SHOULD NOT be made for purposes unrelated to authentication.
-
- The following terms are used here with the meanings defined in BCP
- 26: "name space", "assigned value", "registration".
-
- The following policies are used here with the meanings defined in BCP
- 26: "Private Use", "First Come First Served", "Expert Review",
- "Specification Required", "IETF Consensus", "Standards Action".
-
-
-
-Aboba, et al. Standards Track [Page 40]
-\f
-RFC 3748 EAP June 2004
-
-
- For registration requests where a Designated Expert should be
- consulted, the responsible IESG area director should appoint the
- Designated Expert. The intention is that any allocation will be
- accompanied by a published RFC. But in order to allow for the
- allocation of values prior to the RFC being approved for publication,
- the Designated Expert can approve allocations once it seems clear
- that an RFC will be published. The Designated expert will post a
- request to the EAP WG mailing list (or a successor designated by the
- Area Director) for comment and review, including an Internet-Draft.
- Before a period of 30 days has passed, the Designated Expert will
- either approve or deny the registration request and publish a notice
- of the decision to the EAP WG mailing list or its successor, as well
- as informing IANA. A denial notice must be justified by an
- explanation, and in the cases where it is possible, concrete
- suggestions on how the request can be modified so as to become
- acceptable should be provided.
-
-6.1. Packet Codes
-
- Packet Codes have a range from 1 to 255, of which 1-4 have been
- allocated. Because a new Packet Code has considerable impact on
- interoperability, a new Packet Code requires Standards Action, and
- should be allocated starting at 5.
-
-6.2. Method Types
-
- The original EAP method Type space has a range from 1 to 255, and is
- the scarcest resource in EAP, and thus must be allocated with care.
- Method Types 1-45 have been allocated, with 20 available for re-use.
- Method Types 20 and 46-191 may be allocated on the advice of a
- Designated Expert, with Specification Required.
-
- Allocation of blocks of method Types (more than one for a given
- purpose) should require IETF Consensus. EAP Type Values 192-253 are
- reserved and allocation requires Standards Action.
-
- Method Type 254 is allocated for the Expanded Type. Where the
- Vendor-Id field is non-zero, the Expanded Type is used for functions
- specific only to one vendor's implementation of EAP, where no
- interoperability is deemed useful. When used with a Vendor-Id of
- zero, method Type 254 can also be used to provide for an expanded
- IETF method Type space. Method Type values 256-4294967295 may be
- allocated after Type values 1-191 have been allocated, on the advice
- of a Designated Expert, with Specification Required.
-
- Method Type 255 is allocated for Experimental use, such as testing of
- new EAP methods before a permanent Type is allocated.
-
-
-
-
-Aboba, et al. Standards Track [Page 41]
-\f
-RFC 3748 EAP June 2004
-
-
-7. Security Considerations
-
- This section defines a generic threat model as well as the EAP method
- security claims mitigating those threats.
-
- It is expected that the generic threat model and corresponding
- security claims will used to define EAP method requirements for use
- in specific environments. An example of such a requirements analysis
- is provided in [IEEE-802.11i-req]. A security claims section is
- required in EAP method specifications, so that EAP methods can be
- evaluated against the requirements.
-
-7.1. Threat Model
-
- EAP was developed for use with PPP [RFC1661] and was later adapted
- for use in wired IEEE 802 networks [IEEE-802] in [IEEE-802.1X].
- Subsequently, EAP has been proposed for use on wireless LAN networks
- and over the Internet. In all these situations, it is possible for
- an attacker to gain access to links over which EAP packets are
- transmitted. For example, attacks on telephone infrastructure are
- documented in [DECEPTION].
-
- An attacker with access to the link may carry out a number of
- attacks, including:
-
- [1] An attacker may try to discover user identities by snooping
- authentication traffic.
-
- [2] An attacker may try to modify or spoof EAP packets.
-
- [3] An attacker may launch denial of service attacks by spoofing
- lower layer indications or Success/Failure packets, by replaying
- EAP packets, or by generating packets with overlapping
- Identifiers.
-
- [4] An attacker may attempt to recover the pass-phrase by mounting
- an offline dictionary attack.
-
- [5] An attacker may attempt to convince the peer to connect to an
- untrusted network by mounting a man-in-the-middle attack.
-
- [6] An attacker may attempt to disrupt the EAP negotiation in order
- cause a weak authentication method to be selected.
-
- [7] An attacker may attempt to recover keys by taking advantage of
- weak key derivation techniques used within EAP methods.
-
-
-
-
-
-Aboba, et al. Standards Track [Page 42]
-\f
-RFC 3748 EAP June 2004
-
-
- [8] An attacker may attempt to take advantage of weak ciphersuites
- subsequently used after the EAP conversation is complete.
-
- [9] An attacker may attempt to perform downgrading attacks on lower
- layer ciphersuite negotiation in order to ensure that a weaker
- ciphersuite is used subsequently to EAP authentication.
-
- [10] An attacker acting as an authenticator may provide incorrect
- information to the EAP peer and/or server via out-of-band
- mechanisms (such as via a AAA or lower layer protocol). This
- includes impersonating another authenticator, or providing
- inconsistent information to the peer and EAP server.
-
- Depending on the lower layer, these attacks may be carried out
- without requiring physical proximity. Where EAP is used over
- wireless networks, EAP packets may be forwarded by authenticators
- (e.g., pre-authentication) so that the attacker need not be within
- the coverage area of an authenticator in order to carry out an attack
- on it or its peers. Where EAP is used over the Internet, attacks may
- be carried out at an even greater distance.
-
-7.2. Security Claims
-
- In order to clearly articulate the security provided by an EAP
- method, EAP method specifications MUST include a Security Claims
- section, including the following declarations:
-
- [a] Mechanism. This is a statement of the authentication technology:
- certificates, pre-shared keys, passwords, token cards, etc.
-
- [b] Security claims. This is a statement of the claimed security
- properties of the method, using terms defined in Section 7.2.1:
- mutual authentication, integrity protection, replay protection,
- confidentiality, key derivation, dictionary attack resistance,
- fast reconnect, cryptographic binding. The Security Claims
- section of an EAP method specification SHOULD provide
- justification for the claims that are made. This can be
- accomplished by including a proof in an Appendix, or including a
- reference to a proof.
-
- [c] Key strength. If the method derives keys, then the effective key
- strength MUST be estimated. This estimate is meant for potential
- users of the method to determine if the keys produced are strong
- enough for the intended application.
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 43]
-\f
-RFC 3748 EAP June 2004
-
-
- The effective key strength SHOULD be stated as a number of bits,
- defined as follows: If the effective key strength is N bits, the
- best currently known methods to recover the key (with non-
- negligible probability) require, on average, an effort comparable
- to 2^(N-1) operations of a typical block cipher. The statement
- SHOULD be accompanied by a short rationale, explaining how this
- number was derived. This explanation SHOULD include the
- parameters required to achieve the stated key strength based on
- current knowledge of the algorithms.
-
- (Note: Although it is difficult to define what "comparable
- effort" and "typical block cipher" exactly mean, reasonable
- approximations are sufficient here. Refer to e.g. [SILVERMAN]
- for more discussion.)
-
- The key strength depends on the methods used to derive the keys.
- For instance, if keys are derived from a shared secret (such as a
- password or a long-term secret), and possibly some public
- information such as nonces, the effective key strength is limited
- by the strength of the long-term secret (assuming that the
- derivation procedure is computationally simple). To take another
- example, when using public key algorithms, the strength of the
- symmetric key depends on the strength of the public keys used.
-
- [d] Description of key hierarchy. EAP methods deriving keys MUST
- either provide a reference to a key hierarchy specification, or
- describe how Master Session Keys (MSKs) and Extended Master
- Session Keys (EMSKs) are to be derived.
-
- [e] Indication of vulnerabilities. In addition to the security
- claims that are made, the specification MUST indicate which of
- the security claims detailed in Section 7.2.1 are NOT being made.
-
-7.2.1. Security Claims Terminology for EAP Methods
-
- These terms are used to describe the security properties of EAP
- methods:
-
- Protected ciphersuite negotiation
- This refers to the ability of an EAP method to negotiate the
- ciphersuite used to protect the EAP conversation, as well as to
- integrity protect the negotiation. It does not refer to the
- ability to negotiate the ciphersuite used to protect data.
-
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 44]
-\f
-RFC 3748 EAP June 2004
-
-
- Mutual authentication
- This refers to an EAP method in which, within an interlocked
- exchange, the authenticator authenticates the peer and the peer
- authenticates the authenticator. Two independent one-way methods,
- running in opposite directions do not provide mutual
- authentication as defined here.
-
- Integrity protection
- This refers to providing data origin authentication and protection
- against unauthorized modification of information for EAP packets
- (including EAP Requests and Responses). When making this claim, a
- method specification MUST describe the EAP packets and fields
- within the EAP packet that are protected.
-
- Replay protection
- This refers to protection against replay of an EAP method or its
- messages, including success and failure result indications.
-
- Confidentiality
- This refers to encryption of EAP messages, including EAP Requests
- and Responses, and success and failure result indications. A
- method making this claim MUST support identity protection (see
- Section 7.3).
-
- Key derivation
- This refers to the ability of the EAP method to derive exportable
- keying material, such as the Master Session Key (MSK), and
- Extended Master Session Key (EMSK). The MSK is used only for
- further key derivation, not directly for protection of the EAP
- conversation or subsequent data. Use of the EMSK is reserved.
-
- Key strength
- If the effective key strength is N bits, the best currently known
- methods to recover the key (with non-negligible probability)
- require, on average, an effort comparable to 2^(N-1) operations of
- a typical block cipher.
-
- Dictionary attack resistance
- Where password authentication is used, passwords are commonly
- selected from a small set (as compared to a set of N-bit keys),
- which raises a concern about dictionary attacks. A method may be
- said to provide protection against dictionary attacks if, when it
- uses a password as a secret, the method does not allow an offline
- attack that has a work factor based on the number of passwords in
- an attacker's dictionary.
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 45]
-\f
-RFC 3748 EAP June 2004
-
-
- Fast reconnect
- The ability, in the case where a security association has been
- previously established, to create a new or refreshed security
- association more efficiently or in a smaller number of round-
- trips.
-
- Cryptographic binding
- The demonstration of the EAP peer to the EAP server that a single
- entity has acted as the EAP peer for all methods executed within a
- tunnel method. Binding MAY also imply that the EAP server
- demonstrates to the peer that a single entity has acted as the EAP
- server for all methods executed within a tunnel method. If
- executed correctly, binding serves to mitigate man-in-the-middle
- vulnerabilities.
-
- Session independence
- The demonstration that passive attacks (such as capture of the EAP
- conversation) or active attacks (including compromise of the MSK
- or EMSK) does not enable compromise of subsequent or prior MSKs or
- EMSKs.
-
- Fragmentation
- This refers to whether an EAP method supports fragmentation and
- reassembly. As noted in Section 3.1, EAP methods should support
- fragmentation and reassembly if EAP packets can exceed the minimum
- MTU of 1020 octets.
-
- Channel binding
- The communication within an EAP method of integrity-protected
- channel properties such as endpoint identifiers which can be
- compared to values communicated via out of band mechanisms (such
- as via a AAA or lower layer protocol).
-
- Note: This list of security claims is not exhaustive. Additional
- properties, such as additional denial-of-service protection, may be
- relevant as well.
-
-7.3. Identity Protection
-
- An Identity exchange is optional within the EAP conversation.
- Therefore, it is possible to omit the Identity exchange entirely, or
- to use a method-specific identity exchange once a protected channel
- has been established.
-
- However, where roaming is supported as described in [RFC2607], it may
- be necessary to locate the appropriate backend authentication server
- before the authentication conversation can proceed. The realm
- portion of the Network Access Identifier (NAI) [RFC2486] is typically
-
-
-
-Aboba, et al. Standards Track [Page 46]
-\f
-RFC 3748 EAP June 2004
-
-
- included within the EAP-Response/Identity in order to enable the
- authentication exchange to be routed to the appropriate backend
- authentication server. Therefore, while the peer-name portion of the
- NAI may be omitted in the EAP-Response/Identity where proxies or
- relays are present, the realm portion may be required.
-
- It is possible for the identity in the identity response to be
- different from the identity authenticated by the EAP method. This
- may be intentional in the case of identity privacy. An EAP method
- SHOULD use the authenticated identity when making access control
- decisions.
-
-7.4. Man-in-the-Middle Attacks
-
- Where EAP is tunneled within another protocol that omits peer
- authentication, there exists a potential vulnerability to a man-in-
- the-middle attack. For details, see [BINDING] and [MITM].
-
- As noted in Section 2.1, EAP does not permit untunneled sequences of
- authentication methods. Were a sequence of EAP authentication
- methods to be permitted, the peer might not have proof that a single
- entity has acted as the authenticator for all EAP methods within the
- sequence. For example, an authenticator might terminate one EAP
- method, then forward the next method in the sequence to another party
- without the peer's knowledge or consent. Similarly, the
- authenticator might not have proof that a single entity has acted as
- the peer for all EAP methods within the sequence.
-
- Tunneling EAP within another protocol enables an attack by a rogue
- EAP authenticator tunneling EAP to a legitimate server. Where the
- tunneling protocol is used for key establishment but does not require
- peer authentication, an attacker convincing a legitimate peer to
- connect to it will be able to tunnel EAP packets to a legitimate
- server, successfully authenticating and obtaining the key. This
- allows the attacker to successfully establish itself as a man-in-
- the-middle, gaining access to the network, as well as the ability to
- decrypt data traffic between the legitimate peer and server.
-
- This attack may be mitigated by the following measures:
-
- [a] Requiring mutual authentication within EAP tunneling mechanisms.
-
- [b] Requiring cryptographic binding between the EAP tunneling
- protocol and the tunneled EAP methods. Where cryptographic
- binding is supported, a mechanism is also needed to protect
- against downgrade attacks that would bypass it. For further
- details on cryptographic binding, see [BINDING].
-
-
-
-
-Aboba, et al. Standards Track [Page 47]
-\f
-RFC 3748 EAP June 2004
-
-
- [c] Limiting the EAP methods authorized for use without protection,
- based on peer and authenticator policy.
-
- [d] Avoiding the use of tunnels when a single, strong method is
- available.
-
-7.5. Packet Modification Attacks
-
- While EAP methods may support per-packet data origin authentication,
- integrity, and replay protection, support is not provided within the
- EAP layer.
-
- Since the Identifier is only a single octet, it is easy to guess,
- allowing an attacker to successfully inject or replay EAP packets.
- An attacker may also modify EAP headers (Code, Identifier, Length,
- Type) within EAP packets where the header is unprotected. This could
- cause packets to be inappropriately discarded or misinterpreted.
-
- To protect EAP packets against modification, spoofing, or replay,
- methods supporting protected ciphersuite negotiation, mutual
- authentication, and key derivation, as well as integrity and replay
- protection, are recommended. See Section 7.2.1 for definitions of
- these security claims.
-
- Method-specific MICs may be used to provide protection. If a per-
- packet MIC is employed within an EAP method, then peers,
- authentication servers, and authenticators not operating in pass-
- through mode MUST validate the MIC. MIC validation failures SHOULD
- be logged. Whether a MIC validation failure is considered a fatal
- error or not is determined by the EAP method specification.
-
- It is RECOMMENDED that methods providing integrity protection of EAP
- packets include coverage of all the EAP header fields, including the
- Code, Identifier, Length, Type, and Type-Data fields.
-
- Since EAP messages of Types Identity, Notification, and Nak do not
- include their own MIC, it may be desirable for the EAP method MIC to
- cover information contained within these messages, as well as the
- header of each EAP message.
-
- To provide protection, EAP also may be encapsulated within a
- protected channel created by protocols such as ISAKMP [RFC2408], as
- is done in [IKEv2] or within TLS [RFC2246]. However, as noted in
- Section 7.4, EAP tunneling may result in a man-in-the-middle
- vulnerability.
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 48]
-\f
-RFC 3748 EAP June 2004
-
-
- Existing EAP methods define message integrity checks (MICs) that
- cover more than one EAP packet. For example, EAP-TLS [RFC2716]
- defines a MIC over a TLS record that could be split into multiple
- fragments; within the FINISHED message, the MIC is computed over
- previous messages. Where the MIC covers more than one EAP packet, a
- MIC validation failure is typically considered a fatal error.
-
- Within EAP-TLS [RFC2716], a MIC validation failure is treated as a
- fatal error, since that is what is specified in TLS [RFC2246].
- However, it is also possible to develop EAP methods that support
- per-packet MICs, and respond to verification failures by silently
- discarding the offending packet.
-
- In this document, descriptions of EAP message handling assume that
- per-packet MIC validation, where it occurs, is effectively performed
- as though it occurs before sending any responses or changing the
- state of the host which received the packet.
-
-7.6. Dictionary Attacks
-
- Password authentication algorithms such as EAP-MD5, MS-CHAPv1
- [RFC2433], and Kerberos V [RFC1510] are known to be vulnerable to
- dictionary attacks. MS-CHAPv1 vulnerabilities are documented in
- [PPTPv1]; MS-CHAPv2 vulnerabilities are documented in [PPTPv2];
- Kerberos vulnerabilities are described in [KRBATTACK], [KRBLIM], and
- [KERB4WEAK].
-
- In order to protect against dictionary attacks, authentication
- methods resistant to dictionary attacks (as defined in Section 7.2.1)
- are recommended.
-
- If an authentication algorithm is used that is known to be vulnerable
- to dictionary attacks, then the conversation may be tunneled within a
- protected channel in order to provide additional protection.
- However, as noted in Section 7.4, EAP tunneling may result in a man-
- in-the-middle vulnerability, and therefore dictionary attack
- resistant methods are preferred.
-
-7.7. Connection to an Untrusted Network
-
- With EAP methods supporting one-way authentication, such as EAP-MD5,
- the peer does not authenticate the authenticator, making the peer
- vulnerable to attack by a rogue authenticator. Methods supporting
- mutual authentication (as defined in Section 7.2.1) address this
- vulnerability.
-
- In EAP there is no requirement that authentication be full duplex or
- that the same protocol be used in both directions. It is perfectly
-
-
-
-Aboba, et al. Standards Track [Page 49]
-\f
-RFC 3748 EAP June 2004
-
-
- acceptable for different protocols to be used in each direction.
- This will, of course, depend on the specific protocols negotiated.
- However, in general, completing a single unitary mutual
- authentication is preferable to two one-way authentications, one in
- each direction. This is because separate authentications that are
- not bound cryptographically so as to demonstrate they are part of the
- same session are subject to man-in-the-middle attacks, as discussed
- in Section 7.4.
-
-7.8. Negotiation Attacks
-
- In a negotiation attack, the attacker attempts to convince the peer
- and authenticator to negotiate a less secure EAP method. EAP does
- not provide protection for Nak Response packets, although it is
- possible for a method to include coverage of Nak Responses within a
- method-specific MIC.
-
- Within or associated with each authenticator, it is not anticipated
- that a particular named peer will support a choice of methods. This
- would make the peer vulnerable to attacks that negotiate the least
- secure method from among a set. Instead, for each named peer, there
- SHOULD be an indication of exactly one method used to authenticate
- that peer name. If a peer needs to make use of different
- authentication methods under different circumstances, then distinct
- identities SHOULD be employed, each of which identifies exactly one
- authentication method.
-
-7.9. Implementation Idiosyncrasies
-
- The interaction of EAP with lower layers such as PPP and IEEE 802 are
- highly implementation dependent.
-
- For example, upon failure of authentication, some PPP implementations
- do not terminate the link, instead limiting traffic in Network-Layer
- Protocols to a filtered subset, which in turn allows the peer the
- opportunity to update secrets or send mail to the network
- administrator indicating a problem. Similarly, while an
- authentication failure will result in denied access to the controlled
- port in [IEEE-802.1X], limited traffic may be permitted on the
- uncontrolled port.
-
- In EAP there is no provision for retries of failed authentication.
- However, in PPP the LCP state machine can renegotiate the
- authentication protocol at any time, thus allowing a new attempt.
- Similarly, in IEEE 802.1X the Supplicant or Authenticator can re-
- authenticate at any time. It is recommended that any counters used
- for authentication failure not be reset until after successful
- authentication, or subsequent termination of the failed link.
-
-
-
-Aboba, et al. Standards Track [Page 50]
-\f
-RFC 3748 EAP June 2004
-
-
-7.10. Key Derivation
-
- It is possible for the peer and EAP server to mutually authenticate
- and derive keys. In order to provide keying material for use in a
- subsequently negotiated ciphersuite, an EAP method supporting key
- derivation MUST export a Master Session Key (MSK) of at least 64
- octets, and an Extended Master Session Key (EMSK) of at least 64
- octets. EAP Methods deriving keys MUST provide for mutual
- authentication between the EAP peer and the EAP Server.
-
- The MSK and EMSK MUST NOT be used directly to protect data; however,
- they are of sufficient size to enable derivation of a AAA-Key
- subsequently used to derive Transient Session Keys (TSKs) for use
- with the selected ciphersuite. Each ciphersuite is responsible for
- specifying how to derive the TSKs from the AAA-Key.
-
- The AAA-Key is derived from the keying material exported by the EAP
- method (MSK and EMSK). This derivation occurs on the AAA server. In
- many existing protocols that use EAP, the AAA-Key and MSK are
- equivalent, but more complicated mechanisms are possible (see
- [KEYFRAME] for details).
-
- EAP methods SHOULD ensure the freshness of the MSK and EMSK, even in
- cases where one party may not have a high quality random number
- generator. A RECOMMENDED method is for each party to provide a nonce
- of at least 128 bits, used in the derivation of the MSK and EMSK.
-
- EAP methods export the MSK and EMSK, but not Transient Session Keys
- so as to allow EAP methods to be ciphersuite and media independent.
- Keying material exported by EAP methods MUST be independent of the
- ciphersuite negotiated to protect data.
-
- Depending on the lower layer, EAP methods may run before or after
- ciphersuite negotiation, so that the selected ciphersuite may not be
- known to the EAP method. By providing keying material usable with
- any ciphersuite, EAP methods can used with a wide range of
- ciphersuites and media.
-
- In order to preserve algorithm independence, EAP methods deriving
- keys SHOULD support (and document) the protected negotiation of the
- ciphersuite used to protect the EAP conversation between the peer and
- server. This is distinct from the ciphersuite negotiated between the
- peer and authenticator, used to protect data.
-
- The strength of Transient Session Keys (TSKs) used to protect data is
- ultimately dependent on the strength of keys generated by the EAP
- method. If an EAP method cannot produce keying material of
- sufficient strength, then the TSKs may be subject to a brute force
-
-
-
-Aboba, et al. Standards Track [Page 51]
-\f
-RFC 3748 EAP June 2004
-
-
- attack. In order to enable deployments requiring strong keys, EAP
- methods supporting key derivation SHOULD be capable of generating an
- MSK and EMSK, each with an effective key strength of at least 128
- bits.
-
- Methods supporting key derivation MUST demonstrate cryptographic
- separation between the MSK and EMSK branches of the EAP key
- hierarchy. Without violating a fundamental cryptographic assumption
- (such as the non-invertibility of a one-way function), an attacker
- recovering the MSK or EMSK MUST NOT be able to recover the other
- quantity with a level of effort less than brute force.
-
- Non-overlapping substrings of the MSK MUST be cryptographically
- separate from each other, as defined in Section 7.2.1. That is,
- knowledge of one substring MUST NOT help in recovering some other
- substring without breaking some hard cryptographic assumption. This
- is required because some existing ciphersuites form TSKs by simply
- splitting the AAA-Key to pieces of appropriate length. Likewise,
- non-overlapping substrings of the EMSK MUST be cryptographically
- separate from each other, and from substrings of the MSK.
-
- The EMSK is reserved for future use and MUST remain on the EAP peer
- and EAP server where it is derived; it MUST NOT be transported to, or
- shared with, additional parties, or used to derive any other keys.
- (This restriction will be relaxed in a future document that specifies
- how the EMSK can be used.)
-
- Since EAP does not provide for explicit key lifetime negotiation, EAP
- peers, authenticators, and authentication servers MUST be prepared
- for situations in which one of the parties discards the key state,
- which remains valid on another party.
-
- This specification does not provide detailed guidance on how EAP
- methods derive the MSK and EMSK, how the AAA-Key is derived from the
- MSK and/or EMSK, or how the TSKs are derived from the AAA-Key.
-
- The development and validation of key derivation algorithms is
- difficult, and as a result, EAP methods SHOULD re-use well
- established and analyzed mechanisms for key derivation (such as those
- specified in IKE [RFC2409] or TLS [RFC2246]), rather than inventing
- new ones. EAP methods SHOULD also utilize well established and
- analyzed mechanisms for MSK and EMSK derivation. Further details on
- EAP Key Derivation are provided within [KEYFRAME].
-
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 52]
-\f
-RFC 3748 EAP June 2004
-
-
-7.11. Weak Ciphersuites
-
- If after the initial EAP authentication, data packets are sent
- without per-packet authentication, integrity, and replay protection,
- an attacker with access to the media can inject packets, "flip bits"
- within existing packets, replay packets, or even hijack the session
- completely. Without per-packet confidentiality, it is possible to
- snoop data packets.
-
- To protect against data modification, spoofing, or snooping, it is
- recommended that EAP methods supporting mutual authentication and key
- derivation (as defined by Section 7.2.1) be used, along with lower
- layers providing per-packet confidentiality, authentication,
- integrity, and replay protection.
-
- Additionally, if the lower layer performs ciphersuite negotiation, it
- should be understood that EAP does not provide by itself integrity
- protection of that negotiation. Therefore, in order to avoid
- downgrading attacks which would lead to weaker ciphersuites being
- used, clients implementing lower layer ciphersuite negotiation SHOULD
- protect against negotiation downgrading.
-
- This can be done by enabling users to configure which ciphersuites
- are acceptable as a matter of security policy, or the ciphersuite
- negotiation MAY be authenticated using keying material derived from
- the EAP authentication and a MIC algorithm agreed upon in advance by
- lower-layer peers.
-
-7.12. Link Layer
-
- There are reliability and security issues with link layer indications
- in PPP, IEEE 802 LANs, and IEEE 802.11 wireless LANs:
-
- [a] PPP. In PPP, link layer indications such as LCP-Terminate (a
- link failure indication) and NCP (a link success indication) are
- not authenticated or integrity protected. They can therefore be
- spoofed by an attacker with access to the link.
-
- [b] IEEE 802. IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames are
- not authenticated or integrity protected. They can therefore be
- spoofed by an attacker with access to the link.
-
- [c] IEEE 802.11. In IEEE 802.11, link layer indications include
- Disassociate and Deauthenticate frames (link failure
- indications), and the first message of the 4-way handshake (link
- success indication). These messages are not authenticated or
- integrity protected, and although they are not forwardable, they
- are spoofable by an attacker within range.
-
-
-
-Aboba, et al. Standards Track [Page 53]
-\f
-RFC 3748 EAP June 2004
-
-
- In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 3
- unicast data frames, and are therefore forwardable. This implies
- that while EAPOL-Start and EAPOL-Logoff messages may be authenticated
- and integrity protected, they can be spoofed by an authenticated
- attacker far from the target when "pre-authentication" is enabled.
-
- In IEEE 802.11, a "link down" indication is an unreliable indication
- of link failure, since wireless signal strength can come and go and
- may be influenced by radio frequency interference generated by an
- attacker. To avoid unnecessary resets, it is advisable to damp these
- indications, rather than passing them directly to the EAP. Since EAP
- supports retransmission, it is robust against transient connectivity
- losses.
-
-7.13. Separation of Authenticator and Backend Authentication Server
-
- It is possible for the EAP peer and EAP server to mutually
- authenticate and derive a AAA-Key for a ciphersuite used to protect
- subsequent data traffic. This does not present an issue on the peer,
- since the peer and EAP client reside on the same machine; all that is
- required is for the client to derive the AAA-Key from the MSK and
- EMSK exported by the EAP method, and to subsequently pass a Transient
- Session Key (TSK) to the ciphersuite module.
-
- However, in the case where the authenticator and authentication
- server reside on different machines, there are several implications
- for security.
-
- [a] Authentication will occur between the peer and the authentication
- server, not between the peer and the authenticator. This means
- that it is not possible for the peer to validate the identity of
- the authenticator that it is speaking to, using EAP alone.
-
- [b] As discussed in [RFC3579], the authenticator is dependent on the
- AAA protocol in order to know the outcome of an authentication
- conversation, and does not look at the encapsulated EAP packet
- (if one is present) to determine the outcome. In practice, this
- implies that the AAA protocol spoken between the authenticator
- and authentication server MUST support per-packet authentication,
- integrity, and replay protection.
-
- [c] After completion of the EAP conversation, where lower layer
- security services such as per-packet confidentiality,
- authentication, integrity, and replay protection will be enabled,
- a secure association protocol SHOULD be run between the peer and
- authenticator in order to provide mutual authentication between
-
-
-
-
-
-Aboba, et al. Standards Track [Page 54]
-\f
-RFC 3748 EAP June 2004
-
-
- the peer and authenticator, guarantee liveness of transient
- session keys, provide protected ciphersuite and capabilities
- negotiation for subsequent data, and synchronize key usage.
-
- [d] A AAA-Key derived from the MSK and/or EMSK negotiated between the
- peer and authentication server MAY be transmitted to the
- authenticator. Therefore, a mechanism needs to be provided to
- transmit the AAA-Key from the authentication server to the
- authenticator that needs it. The specification of the AAA-key
- derivation, transport, and wrapping mechanisms is outside the
- scope of this document. Further details on AAA-Key Derivation
- are provided within [KEYFRAME].
-
-7.14. Cleartext Passwords
-
- This specification does not define a mechanism for cleartext password
- authentication. The omission is intentional. Use of cleartext
- passwords would allow the password to be captured by an attacker with
- access to a link over which EAP packets are transmitted.
-
- Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
- provide confidentiality, EAP packets may be subsequently encapsulated
- for transport over the Internet where they may be captured by an
- attacker.
-
- As a result, cleartext passwords cannot be securely used within EAP,
- except where encapsulated within a protected tunnel with server
- authentication. Some of the same risks apply to EAP methods without
- dictionary attack resistance, as defined in Section 7.2.1. For
- details, see Section 7.6.
-
-7.15. Channel Binding
-
- It is possible for a compromised or poorly implemented EAP
- authenticator to communicate incorrect information to the EAP peer
- and/or server. This may enable an authenticator to impersonate
- another authenticator or communicate incorrect information via out-
- of-band mechanisms (such as via a AAA or lower layer protocol).
-
- Where EAP is used in pass-through mode, the EAP peer typically does
- not verify the identity of the pass-through authenticator, it only
- verifies that the pass-through authenticator is trusted by the EAP
- server. This creates a potential security vulnerability.
-
- Section 4.3.7 of [RFC3579] describes how an EAP pass-through
- authenticator acting as a AAA client can be detected if it attempts
- to impersonate another authenticator (such by sending incorrect NAS-
- Identifier [RFC2865], NAS-IP-Address [RFC2865] or NAS-IPv6-Address
-
-
-
-Aboba, et al. Standards Track [Page 55]
-\f
-RFC 3748 EAP June 2004
-
-
- [RFC3162] attributes via the AAA protocol). However, it is possible
- for a pass-through authenticator acting as a AAA client to provide
- correct information to the AAA server while communicating misleading
- information to the EAP peer via a lower layer protocol.
-
- For example, it is possible for a compromised authenticator to
- utilize another authenticator's Called-Station-Id or NAS-Identifier
- in communicating with the EAP peer via a lower layer protocol, or for
- a pass-through authenticator acting as a AAA client to provide an
- incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA
- server via the AAA protocol.
-
- In order to address this vulnerability, EAP methods may support a
- protected exchange of channel properties such as endpoint
- identifiers, including (but not limited to): Called-Station-Id
- [RFC2865][RFC3580], Calling-Station-Id [RFC2865][RFC3580], NAS-
- Identifier [RFC2865], NAS-IP-Address [RFC2865], and NAS-IPv6-Address
- [RFC3162].
-
- Using such a protected exchange, it is possible to match the channel
- properties provided by the authenticator via out-of-band mechanisms
- against those exchanged within the EAP method. Where discrepancies
- are found, these SHOULD be logged; additional actions MAY also be
- taken, such as denying access.
-
-7.16. Protected Result Indications
-
- Within EAP, Success and Failure packets are neither acknowledged nor
- integrity protected. Result indications improve resilience to loss
- of Success and Failure packets when EAP is run over lower layers
- which do not support retransmission or synchronization of the
- authentication state. In media such as IEEE 802.11, which provides
- for retransmission, as well as synchronization of authentication
- state via the 4-way handshake defined in [IEEE-802.11i], additional
- resilience is typically of marginal benefit.
-
- Depending on the method and circumstances, result indications can be
- spoofable by an attacker. A method is said to provide protected
- result indications if it supports result indications, as well as the
- "integrity protection" and "replay protection" claims. A method
- supporting protected result indications MUST indicate which result
- indications are protected, and which are not.
-
- Protected result indications are not required to protect against
- rogue authenticators. Within a mutually authenticating method,
- requiring that the server authenticate to the peer before the peer
- will accept a Success packet prevents an attacker from acting as a
- rogue authenticator.
-
-
-
-Aboba, et al. Standards Track [Page 56]
-\f
-RFC 3748 EAP June 2004
-
-
- However, it is possible for an attacker to forge a Success packet
- after the server has authenticated to the peer, but before the peer
- has authenticated to the server. If the peer were to accept the
- forged Success packet and attempt to access the network when it had
- not yet successfully authenticated to the server, a denial of service
- attack could be mounted against the peer. After such an attack, if
- the lower layer supports failure indications, the authenticator can
- synchronize state with the peer by providing a lower layer failure
- indication. See Section 7.12 for details.
-
- If a server were to authenticate the peer and send a Success packet
- prior to determining whether the peer has authenticated the
- authenticator, an idle timeout can occur if the authenticator is not
- authenticated by the peer. Where supported by the lower layer, an
- authenticator sensing the absence of the peer can free resources.
-
- In a method supporting result indications, a peer that has
- authenticated the server does not consider the authentication
- successful until it receives an indication that the server
- successfully authenticated it. Similarly, a server that has
- successfully authenticated the peer does not consider the
- authentication successful until it receives an indication that the
- peer has authenticated the server.
-
- In order to avoid synchronization problems, prior to sending a
- success result indication, it is desirable for the sender to verify
- that sufficient authorization exists for granting access, though, as
- discussed below, this is not always possible.
-
- While result indications may enable synchronization of the
- authentication result between the peer and server, this does not
- guarantee that the peer and authenticator will be synchronized in
- terms of their authorization or that timeouts will not occur. For
- example, the EAP server may not be aware of an authorization decision
- made by a AAA proxy; the AAA server may check authorization only
- after authentication has completed successfully, to discover that
- authorization cannot be granted, or the AAA server may grant access
- but the authenticator may be unable to provide it due to a temporary
- lack of resources. In these situations, synchronization may only be
- achieved via lower layer result indications.
-
- Success indications may be explicit or implicit. For example, where
- a method supports error messages, an implicit success indication may
- be defined as the reception of a specific message without a preceding
- error message. Failures are typically indicated explicitly. As
- described in Section 4.2, a peer silently discards a Failure packet
- received at a point where the method does not explicitly permit this
-
-
-
-
-Aboba, et al. Standards Track [Page 57]
-\f
-RFC 3748 EAP June 2004
-
-
- to be sent. For example, a method providing its own error messages
- might require the peer to receive an error message prior to accepting
- a Failure packet.
-
- Per-packet authentication, integrity, and replay protection of result
- indications protects against spoofing. Since protected result
- indications require use of a key for per-packet authentication and
- integrity protection, methods supporting protected result indications
- MUST also support the "key derivation", "mutual authentication",
- "integrity protection", and "replay protection" claims.
-
- Protected result indications address some denial-of-service
- vulnerabilities due to spoofing of Success and Failure packets,
- though not all. EAP methods can typically provide protected result
- indications only in some circumstances. For example, errors can
- occur prior to key derivation, and so it may not be possible to
- protect all failure indications. It is also possible that result
- indications may not be supported in both directions or that
- synchronization may not be achieved in all modes of operation.
-
- For example, within EAP-TLS [RFC2716], in the client authentication
- handshake, the server authenticates the peer, but does not receive a
- protected indication of whether the peer has authenticated it. In
- contrast, the peer authenticates the server and is aware of whether
- the server has authenticated it. In the session resumption
- handshake, the peer authenticates the server, but does not receive a
- protected indication of whether the server has authenticated it. In
- this mode, the server authenticates the peer and is aware of whether
- the peer has authenticated it.
-
-8. Acknowledgements
-
- This protocol derives much of its inspiration from Dave Carrel's AHA
- document, as well as the PPP CHAP protocol [RFC1994]. Valuable
- feedback was provided by Yoshihiro Ohba of Toshiba America Research,
- Jari Arkko of Ericsson, Sachin Seth of Microsoft, Glen Zorn of Cisco
- Systems, Jesse Walker of Intel, Bill Arbaugh, Nick Petroni and Bryan
- Payne of the University of Maryland, Steve Bellovin of AT&T Research,
- Paul Funk of Funk Software, Pasi Eronen of Nokia, Joseph Salowey of
- Cisco, Paul Congdon of HP, and members of the EAP working group.
-
- The use of Security Claims sections for EAP methods, as required by
- Section 7.2 and specified for each EAP method described in this
- document, was inspired by Glen Zorn through [EAP-EVAL].
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 58]
-\f
-RFC 3748 EAP June 2004
-
-
-9. References
-
-9.1. Normative References
-
- [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)",
- STD 51, RFC 1661, July 1994.
-
- [RFC1994] Simpson, W., "PPP Challenge Handshake
- Authentication Protocol (CHAP)", RFC 1994, August
- 1996.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to
- Indicate Requirement Levels", BCP 14, RFC 2119,
- March 1997.
-
- [RFC2243] Metz, C., "OTP Extended Responses", RFC 2243,
- November 1997.
-
- [RFC2279] Yergeau, F., "UTF-8, a transformation format of
- ISO 10646", RFC 2279, January 1998.
-
- [RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A
- One-Time Password System", RFC 2289, February
- 1998.
-
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
- Writing an IANA Considerations Section in RFCs",
- BCP 26, RFC 2434, October 1998.
-
- [RFC2988] Paxson, V. and M. Allman, "Computing TCP's
- Retransmission Timer", RFC 2988, November 2000.
-
- [IEEE-802] Institute of Electrical and Electronics Engineers,
- "Local and Metropolitan Area Networks: Overview
- and Architecture", IEEE Standard 802, 1990.
-
- [IEEE-802.1X] Institute of Electrical and Electronics Engineers,
- "Local and Metropolitan Area Networks: Port-Based
- Network Access Control", IEEE Standard 802.1X,
- September 2001.
-
-
-
-
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 59]
-\f
-RFC 3748 EAP June 2004
-
-
-9.2. Informative References
-
- [RFC793] Postel, J., "Transmission Control Protocol", STD
- 7, RFC 793, September 1981.
-
- [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
- Authentication Service (V5)", RFC 1510, September
- 1993.
-
- [RFC1750] Eastlake, D., Crocker, S. and J. Schiller,
- "Randomness Recommendations for Security", RFC
- 1750, December 1994.
-
- [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P.,
- Freier, A. and P. Kocher, "The TLS Protocol
- Version 1.0", RFC 2246, January 1999.
-
- [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible
- Authentication Protocol (EAP)", RFC 2284, March
- 1998.
-
- [RFC2486] Aboba, B. and M. Beadles, "The Network Access
- Identifier", RFC 2486, January 1999.
-
- [RFC2408] Maughan, D., Schneider, M. and M. Schertler,
- "Internet Security Association and Key Management
- Protocol (ISAKMP)", RFC 2408, November 1998.
-
- [RFC2409] Harkins, D. and D. Carrel, "The Internet Key
- Exchange (IKE)", RFC 2409, November 1998.
-
- [RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP
- Extensions", RFC 2433, October 1998.
-
- [RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and
- Policy Implementation in Roaming", RFC 2607, June
- 1999.
-
- [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G.,
- Zorn, G. and B. Palter, "Layer Two Tunneling
- Protocol "L2TP"", RFC 2661, August 1999.
-
- [RFC2716] Aboba, B. and D. Simon, "PPP EAP TLS
- Authentication Protocol", RFC 2716, October 1999.
-
- [RFC2865] Rigney, C., Willens, S., Rubens, A. and W.
- Simpson, "Remote Authentication Dial In User
- Service (RADIUS)", RFC 2865, June 2000.
-
-
-
-Aboba, et al. Standards Track [Page 60]
-\f
-RFC 3748 EAP June 2004
-
-
- [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
- Schwarzbauer, H., Taylor, T., Rytina, I., Kalla,
- M., Zhang, L. and V. Paxson, "Stream Control
- Transmission Protocol", RFC 2960, October 2000.
-
- [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and
- IPv6", RFC 3162, August 2001.
-
- [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
- Internationalized Strings ("stringprep")", RFC
- 3454, December 2002.
-
- [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote
- Authentication Dial In User Service) Support For
- Extensible Authentication Protocol (EAP)", RFC
- 3579, September 2003.
-
- [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J.
- Roese, "IEEE 802.1X Remote Authentication Dial In
- User Service (RADIUS) Usage Guidelines", RFC 3580,
- September 2003.
-
- [RFC3692] Narten, T., "Assigning Experimental and Testing
- Numbers Considered Useful", BCP 82, RFC 3692,
- January 2004.
-
- [DECEPTION] Slatalla, M. and J. Quittner, "Masters of
- Deception", Harper-Collins, New York, 1995.
-
- [KRBATTACK] Wu, T., "A Real-World Analysis of Kerberos
- Password Security", Proceedings of the 1999 ISOC
- Network and Distributed System Security Symposium,
- http://www.isoc.org/isoc/conferences/ndss/99/
- proceedings/papers/wu.pdf.
-
- [KRBLIM] Bellovin, S. and M. Merrit, "Limitations of the
- Kerberos authentication system", Proceedings of
- the 1991 Winter USENIX Conference, pp. 253-267,
- 1991.
-
- [KERB4WEAK] Dole, B., Lodin, S. and E. Spafford, "Misplaced
- trust: Kerberos 4 session keys", Proceedings of
- the Internet Society Network and Distributed
- System Security Symposium, pp. 60-70, March 1997.
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 61]
-\f
-RFC 3748 EAP June 2004
-
-
- [PIC] Aboba, B., Krawczyk, H. and Y. Sheffer, "PIC, A
- Pre-IKE Credential Provisioning Protocol", Work in
- Progress, October 2002.
-
- [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2)
- Protocol", Work in Progress, January 2004.
-
- [PPTPv1] Schneier, B. and Mudge, "Cryptanalysis of
- Microsoft's Point-to- Point Tunneling Protocol",
- Proceedings of the 5th ACM Conference on
- Communications and Computer Security, ACM Press,
- November 1998.
-
- [IEEE-802.11] Institute of Electrical and Electronics Engineers,
- "Wireless LAN Medium Access Control (MAC) and
- Physical Layer (PHY) Specifications", IEEE
- Standard 802.11, 1999.
-
- [SILVERMAN] Silverman, Robert D., "A Cost-Based Security
- Analysis of Symmetric and Asymmetric Key Lengths",
- RSA Laboratories Bulletin 13, April 2000 (Revised
- November 2001),
- http://www.rsasecurity.com/rsalabs/bulletins/
- bulletin13.html.
-
- [KEYFRAME] Aboba, B., "EAP Key Management Framework", Work in
- Progress, October 2003.
-
- [SASLPREP] Zeilenga, K., "SASLprep: Stringprep profile for
- user names and passwords", Work in Progress, March
- 2004.
-
- [IEEE-802.11i] Institute of Electrical and Electronics Engineers,
- "Unapproved Draft Supplement to Standard for
- Telecommunications and Information Exchange
- Between Systems - LAN/MAN Specific Requirements -
- Part 11: Wireless LAN Medium Access Control (MAC)
- and Physical Layer (PHY) Specifications:
- Specification for Enhanced Security", IEEE Draft
- 802.11i (work in progress), 2003.
-
- [DIAM-EAP] Eronen, P., Hiller, T. and G. Zorn, "Diameter
- Extensible Authentication Protocol (EAP)
- Application", Work in Progress, February 2004.
-
- [EAP-EVAL] Zorn, G., "Specifying Security Claims for EAP
- Authentication Types", Work in Progress, October
- 2002.
-
-
-
-Aboba, et al. Standards Track [Page 62]
-\f
-RFC 3748 EAP June 2004
-
-
- [BINDING] Puthenkulam, J., "The Compound Authentication
- Binding Problem", Work in Progress, October 2003.
-
- [MITM] Asokan, N., Niemi, V. and K. Nyberg, "Man-in-the-
- Middle in Tunneled Authentication Protocols", IACR
- ePrint Archive Report 2002/163, October 2002,
- <http://eprint.iacr.org/2002/163>.
-
- [IEEE-802.11i-req] Stanley, D., "EAP Method Requirements for Wireless
- LANs", Work in Progress, February 2004.
-
- [PPTPv2] Schneier, B. and Mudge, "Cryptanalysis of
- Microsoft's PPTP Authentication Extensions (MS-
- CHAPv2)", CQRE 99, Springer-Verlag, 1999, pp.
- 192-203.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 63]
-\f
-RFC 3748 EAP June 2004
-
-
-Appendix A. Changes from RFC 2284
-
- This section lists the major changes between [RFC2284] and this
- document. Minor changes, including style, grammar, spelling, and
- editorial changes are not mentioned here.
-
- o The Terminology section (Section 1.2) has been expanded, defining
- more concepts and giving more exact definitions.
-
- o The concepts of Mutual Authentication, Key Derivation, and Result
- Indications are introduced and discussed throughout the document
- where appropriate.
-
- o In Section 2, it is explicitly specified that more than one
- exchange of Request and Response packets may occur as part of the
- EAP authentication exchange. How this may be used and how it may
- not be used is specified in detail in Section 2.1.
-
- o Also in Section 2, some requirements have been made explicit for
- the authenticator when acting in pass-through mode.
-
- o An EAP multiplexing model (Section 2.2) has been added to
- illustrate a typical implementation of EAP. There is no
- requirement that an implementation conform to this model, as long
- as the on-the-wire behavior is consistent with it.
-
- o As EAP is now in use with a variety of lower layers, not just PPP
- for which it was first designed, Section 3 on lower layer behavior
- has been added.
-
- o In the description of the EAP Request and Response interaction
- (Section 4.1), both the behavior on receiving duplicate requests,
- and when packets should be silently discarded has been more
- exactly specified. The implementation notes in this section have
- been substantially expanded.
-
- o In Section 4.2, it has been clarified that Success and Failure
- packets must not contain additional data, and the implementation
- note has been expanded. A subsection giving requirements on
- processing of success and failure packets has been added.
-
- o Section 5 on EAP Request/Response Types lists two new Type values:
- the Expanded Type (Section 5.7), which is used to expand the Type
- value number space, and the Experimental Type. In the Expanded
- Type number space, the new Expanded Nak (Section 5.3.2) Type has
- been added. Clarifications have been made in the description of
- most of the existing Types. Security claims summaries have been
- added for authentication methods.
-
-
-
-Aboba, et al. Standards Track [Page 64]
-\f
-RFC 3748 EAP June 2004
-
-
- o In Sections 5, 5.1, and 5.2, a requirement has been added such
- that fields with displayable messages should contain UTF-8 encoded
- ISO 10646 characters.
-
- o It is now required in Section 5.1 that if the Type-Data field of
- an Identity Request contains a NUL-character, only the part before
- the null is displayed. RFC 2284 prohibits the null termination of
- the Type-Data field of Identity messages. This rule has been
- relaxed for Identity Request messages and the Identity Request
- Type-Data field may now be null terminated.
-
- o In Section 5.5, support for OTP Extended Responses [RFC2243] has
- been added to EAP OTP.
-
- o An IANA Considerations section (Section 6) has been added, giving
- registration policies for the numbering spaces defined for EAP.
-
- o The Security Considerations (Section 7) have been greatly
- expanded, giving a much more comprehensive coverage of possible
- threats and other security considerations.
-
- o In Section 7.5, text has been added on method-specific behavior,
- providing guidance on how EAP method-specific integrity checks
- should be processed. Where possible, it is desirable for a
- method-specific MIC to be computed over the entire EAP packet,
- including the EAP layer header (Code, Identifier, Length) and EAP
- method layer header (Type, Type-Data).
-
- o In Section 7.14 the security risks involved in use of cleartext
- passwords with EAP are described.
-
- o In Section 7.15 text has been added relating to detection of rogue
- NAS behavior.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 65]
-\f
-RFC 3748 EAP June 2004
-
-
-Authors' Addresses
-
- Bernard Aboba
- Microsoft Corporation
- One Microsoft Way
- Redmond, WA 98052
- USA
-
- Phone: +1 425 706 6605
- Fax: +1 425 936 6605
- EMail: bernarda@microsoft.com
-
- Larry J. Blunk
- Merit Network, Inc
- 4251 Plymouth Rd., Suite 2000
- Ann Arbor, MI 48105-2785
- USA
-
- Phone: +1 734-647-9563
- Fax: +1 734-647-3185
- EMail: ljb@merit.edu
-
- John R. Vollbrecht
- Vollbrecht Consulting LLC
- 9682 Alice Hill Drive
- Dexter, MI 48130
- USA
-
- EMail: jrv@umich.edu
-
- James Carlson
- Sun Microsystems, Inc
- 1 Network Drive
- Burlington, MA 01803-2757
- USA
-
- Phone: +1 781 442 2084
- Fax: +1 781 442 1677
- EMail: james.d.carlson@sun.com
-
- Henrik Levkowetz
- ipUnplugged AB
- Arenavagen 33
- Stockholm S-121 28
- SWEDEN
-
- Phone: +46 708 32 16 08
- EMail: henrik@levkowetz.com
-
-
-
-Aboba, et al. Standards Track [Page 66]
-\f
-RFC 3748 EAP June 2004
-
-
-Full Copyright Statement
-
- Copyright (C) The Internet Society (2004). 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.
-
-
-
-
-
-
-
-
-
-Aboba, et al. Standards Track [Page 67]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group H. Haverinen, Ed.
-Request for Comments: 4186 Nokia
-Category: Informational J. Salowey, Ed.
- Cisco Systems
- January 2006
-
-
- Extensible Authentication Protocol Method for
- Global System for Mobile Communications (GSM)
- Subscriber Identity Modules (EAP-SIM)
-
-Status of This Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-IESG Note
-
- The EAP-SIM protocol was developed by 3GPP. The documentation of
- EAP-SIM is provided as information to the Internet community. While
- the EAP WG has verified that EAP-SIM is compatible with EAP, as
- defined in RFC 3748, no other review has been done, including
- validation of the security claims. The IETF has also not reviewed
- the security of the cryptographic algorithms.
-
-Abstract
-
- This document specifies an Extensible Authentication Protocol (EAP)
- mechanism for authentication and session key distribution using the
- Global System for Mobile Communications (GSM) Subscriber Identity
- Module (SIM). GSM is a second generation mobile network standard.
- The EAP-SIM mechanism specifies enhancements to GSM authentication
- and key agreement whereby multiple authentication triplets can be
- combined to create authentication responses and session keys of
- greater strength than the individual GSM triplets. The mechanism
- also includes network authentication, user anonymity support, result
- indications, and a fast re-authentication procedure.
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 1]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-Table of Contents
-
- 1. Introduction ....................................................4
- 2. Terms ...........................................................5
- 3. Overview ........................................................8
- 4. Operation ......................................................10
- 4.1. Version Negotiation .......................................10
- 4.2. Identity Management .......................................11
- 4.2.1. Format, Generation and Usage of Peer Identities ....11
- 4.2.2. Communicating the Peer Identity to the Server ......17
- 4.2.3. Choice of Identity for the EAP-Response/Identity ...19
- 4.2.4. Server Operation in the Beginning of
- EAP-SIM Exchange ...................................19
- 4.2.5. Processing of EAP-Request/SIM/Start by the Peer ....20
- 4.2.6. Attacks Against Identity Privacy ...................21
- 4.2.7. Processing of AT_IDENTITY by the Server ............22
- 4.3. Message Sequence Examples (Informative) ...................23
- 4.3.1. Full Authentication ................................24
- 4.3.2. Fast Re-authentication .............................25
- 4.3.3. Fall Back to Full Authentication ...................26
- 4.3.4. Requesting the Permanent Identity 1 ................27
- 4.3.5. Requesting the Permanent Identity 2 ................28
- 4.3.6. Three EAP-SIM/Start Roundtrips .....................28
- 5. Fast Re-Authentication .........................................30
- 5.1. General ...................................................30
- 5.2. Comparison to UMTS AKA ....................................31
- 5.3. Fast Re-authentication Identity ...........................31
- 5.4. Fast Re-authentication Procedure ..........................33
- 5.5. Fast Re-authentication Procedure when Counter Is
- Too Small .................................................36
- 6. EAP-SIM Notifications ..........................................37
- 6.1. General ...................................................37
- 6.2. Result Indications ........................................39
- 6.3. Error Cases ...............................................40
- 6.3.1. Peer Operation .....................................40
- 6.3.2. Server Operation ...................................41
- 6.3.3. EAP-Failure ........................................42
- 6.3.4. EAP-Success ........................................42
- 7. Key Generation .................................................43
- 8. Message Format and Protocol Extensibility ......................45
- 8.1. Message Format ............................................45
- 8.2. Protocol Extensibility ....................................47
- 9. Messages .......................................................48
- 9.1. EAP-Request/SIM/Start .....................................48
- 9.2. EAP-Response/SIM/Start ....................................49
- 9.3. EAP-Request/SIM/Challenge .................................49
- 9.4. EAP-Response/SIM/Challenge ................................50
- 9.5. EAP-Request/SIM/Re-authentication .........................51
-
-
-
-Haverinen & Salowey Informational [Page 2]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- 9.6. EAP-Response/SIM/Re-authentication ........................51
- 9.7. EAP-Response/SIM/Client-Error .............................52
- 9.8. EAP-Request/SIM/Notification ..............................52
- 9.9. EAP-Response/SIM/Notification .............................53
- 10. Attributes ....................................................53
- 10.1. Table of Attributes ......................................53
- 10.2. AT_VERSION_LIST ..........................................54
- 10.3. AT_SELECTED_VERSION ......................................55
- 10.4. AT_NONCE_MT ..............................................55
- 10.5. AT_PERMANENT_ID_REQ ......................................56
- 10.6. AT_ANY_ID_REQ ............................................56
- 10.7. AT_FULLAUTH_ID_REQ .......................................57
- 10.8. AT_IDENTITY ..............................................57
- 10.9. AT_RAND ..................................................58
- 10.10. AT_NEXT_PSEUDONYM .......................................59
- 10.11. AT_NEXT_REAUTH_ID .......................................59
- 10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING .....................60
- 10.13. AT_RESULT_IND ...........................................62
- 10.14. AT_MAC ..................................................62
- 10.15. AT_COUNTER ..............................................63
- 10.16. AT_COUNTER_TOO_SMALL ....................................63
- 10.17. AT_NONCE_S ..............................................64
- 10.18. AT_NOTIFICATION .........................................64
- 10.19. AT_CLIENT_ERROR_CODE ....................................65
- 11. IANA Considerations ...........................................66
- 12. Security Considerations .......................................66
- 12.1. A3 and A8 Algorithms .....................................66
- 12.2. Identity Protection ......................................66
- 12.3. Mutual Authentication and Triplet Exposure ...............67
- 12.4. Flooding the Authentication Centre .......................69
- 12.5. Key Derivation ...........................................69
- 12.6. Cryptographic Separation of Keys and Session
- Independence .............................................70
- 12.7. Dictionary Attacks .......................................71
- 12.8. Credentials Re-use .......................................71
- 12.9. Integrity and Replay Protection, and Confidentiality .....72
- 12.10. Negotiation Attacks .....................................73
- 12.11. Protected Result Indications ............................73
- 12.12. Man-in-the-Middle Attacks ...............................74
- 12.13. Generating Random Numbers ...............................74
- 13. Security Claims ...............................................74
- 14. Acknowledgements and Contributions ............................75
- 14.1. Contributors .............................................75
- 14.2. Acknowledgements .........................................75
- 14.2.1. Contributors' Addresses ...........................77
- 15. References ....................................................78
- 15.1. Normative References .....................................78
- 15.2. Informative References ...................................79
-
-
-
-Haverinen & Salowey Informational [Page 3]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- Appendix A. Test Vectors .........................................81
- A.1. EAP-Request/Identity .....................................81
- A.2. EAP-Response/Identity ....................................81
- A.3. EAP-Request/SIM/Start ....................................82
- A.4. EAP-Response/SIM/Start ...................................82
- A.5. EAP-Request/SIM/Challenge ................................83
- A.6. EAP-Response/SIM/Challenge ...............................86
- A.7. EAP-Success ..............................................86
- A.8. Fast Re-authentication ...................................86
- A.9. EAP-Request/SIM/Re-authentication ........................87
- A.10. EAP-Response/SIM/Re-authentication ......................89
- Appendix B. Pseudo-Random Number Generator .......................90
-
-1. Introduction
-
- This document specifies an Extensible Authentication Protocol (EAP)
- [RFC3748] mechanism for authentication and session key distribution
- using the Global System for Mobile Communications (GSM) Subscriber
- Identity Module (SIM).
-
- GSM is a second generation mobile network standard. Second
- generation mobile networks and third generation mobile networks use
- different authentication and key agreement mechanisms. EAP-AKA
- [EAP-AKA] specifies an EAP method that is based on the Authentication
- and Key Agreement (AKA) mechanism used in 3rd generation mobile
- networks.
-
- GSM authentication is based on a challenge-response mechanism. The
- A3/A8 authentication and key derivation algorithms that run on the
- SIM can be given a 128-bit random number (RAND) as a challenge. The
- SIM runs operator-specific algorithms, which take the RAND and a
- secret key Ki (stored on the SIM) as input, and produce a 32-bit
- response (SRES) and a 64-bit long key Kc as output. The Kc key is
- originally intended to be used as an encryption key over the air
- interface, but in this protocol, it is used for deriving keying
- material and is not directly used. Hence, the secrecy of Kc is
- critical to the security of this protocol. For more information
- about GSM authentication, see [GSM-03.20]. See Section 12.1 for more
- discussion about the GSM algorithms used in EAP-SIM.
-
- The lack of mutual authentication is a weakness in GSM
- authentication. The derived 64-bit cipher key (Kc) is not strong
- enough for data networks in which stronger and longer keys are
- required. Hence, in EAP-SIM, several RAND challenges are used for
- generating several 64-bit Kc keys, which are combined to constitute
- stronger keying material. In EAP-SIM, the client issues a random
- number NONCE_MT to the network in order to contribute to key
- derivation, and to prevent replays of EAP-SIM requests from previous
-
-
-
-Haverinen & Salowey Informational [Page 4]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- exchanges. The NONCE_MT can be conceived as the client's challenge
- to the network. EAP-SIM also extends the combined RAND challenges
- and other messages with a message authentication code in order to
- provide message integrity protection along with mutual
- authentication.
-
- EAP-SIM specifies optional support for protecting the privacy of
- subscriber identity using the same concept as the GSM, which uses
- pseudonyms/temporary identifiers. It also specifies an optional fast
- re-authentication procedure.
-
- The security of EAP-SIM builds on underlying GSM mechanisms. The
- security properties of EAP-SIM are documented in Section 11 of this
- document. Implementers and users of EAP-SIM are advised to carefully
- study the security considerations in Section 11 in order to determine
- whether the security properties are sufficient for the environment in
- question, especially as the secrecy of Kc keys is essential to the
- security of EAP-SIM. In brief, EAP-SIM is in no sense weaker than
- the GSM mechanisms. In some cases EAP-SIM provides better security
- properties than the underlying GSM mechanisms, particularly if the
- SIM credentials are only used for EAP-SIM and are not re-used from
- GSM/GPRS. Many of the security features of EAP-SIM rely upon the
- secrecy of the Kc values in the SIM triplets, so protecting these
- values is key to the security of the EAP-SIM protocol.
-
- The 3rd Generation Partnership Project (3GPP) has specified an
- enhanced Authentication and Key Agreement (AKA) architecture for the
- Universal Mobile Telecommunications System (UMTS). The 3rd
- generation AKA mechanism includes mutual authentication, replay
- protection, and derivation of longer session keys. EAP-AKA [EAP-AKA]
- specifies an EAP method that is based on the 3rd generation AKA.
- EAP-AKA, which is a more secure protocol, may be used instead of
- EAP-SIM, if 3rd generation identity modules and 3G network
- infrastructures are available.
-
-2. Terms
-
- 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].
-
- The terms and abbreviations "authenticator", "backend authentication
- server", "EAP server", "peer", "Silently Discard", "Master Session
- Key (MSK)", and "Extended Master Session Key (EMSK)" in this document
- are to be interpreted as described in [RFC3748].
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 5]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- This document frequently uses the following terms and abbreviations:
-
- AAA protocol
-
- Authentication, Authorization, and Accounting protocol
-
- AuC
-
- Authentication Centre. The GSM network element that provides
- the authentication triplets for authenticating
- the subscriber.
-
- Authentication vector
-
- GSM triplets can be alternatively called authentication
- vectors.
-
- EAP
-
- Extensible Authentication Protocol
-
- Fast re-authentication
-
- An EAP-SIM authentication exchange that is based on keys
- derived upon a preceding full authentication exchange.
- The GSM authentication and key exchange algorithms are not
- used in the fast re-authentication procedure.
-
- Fast Re-authentication Identity
-
- A fast re-authentication identity of the peer, including an NAI
- realm portion in environments where a realm is used. Used on
- fast re-authentication only.
-
- Fast Re-authentication Username
-
- The username portion of fast re-authentication identity,
- i.e., not including any realm portions.
-
- Full authentication
-
- An EAP-SIM authentication exchange based on the GSM
- authentication and key agreement algorithms.
-
- GSM
-
- Global System for Mobile communications.
-
-
-
-
-Haverinen & Salowey Informational [Page 6]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- GSM Triplet
-
- The tuple formed by the three GSM authentication values RAND,
- Kc, and SRES.
-
- IMSI
-
- International Mobile Subscriber Identifier, used in GSM to
- identify subscribers.
-
- MAC
-
- Message Authentication Code
-
- NAI
-
- Network Access Identifier
-
- Nonce
-
- A value that is used at most once or that is never repeated
- within the same cryptographic context. In general, a nonce can
- be predictable (e.g., a counter) or unpredictable (e.g., a
- random value). Since some cryptographic properties may depend
- on the randomness of the nonce, attention should be paid to
- whether a nonce is required to be random or not. In this
- document, the term nonce is only used to denote random nonces,
- and it is not used to denote counters.
-
- Permanent Identity
-
- The permanent identity of the peer, including an NAI realm
- portion in environments where a realm is used. The permanent
- identity is usually based on the IMSI. Used on full
- authentication only.
-
- Permanent Username
-
- The username portion of permanent identity, i.e., not including
- any realm portions.
-
- Pseudonym Identity
-
- A pseudonym identity of the peer, including an NAI realm
- portion in environments where a realm is used. Used on
- full authentication only.
-
-
-
-
-
-Haverinen & Salowey Informational [Page 7]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- Pseudonym Username
-
- The username portion of pseudonym identity, i.e., not including
- any realm portions.
-
- SIM
-
- Subscriber Identity Module. The SIM is traditionally a smart
- card distributed by a GSM operator.
-
-3. Overview
-
- Figure 1 shows an overview of the EAP-SIM full authentication
- procedure, wherein optional protected success indications are not
- used. The authenticator typically communicates with an EAP server
- that is located on a backend authentication server using an AAA
- protocol. The authenticator shown in the figure is often simply
- relaying EAP messages to and from the EAP server, but these backend
- AAA communications are not shown.
-
- Peer Authenticator
- | EAP-Request/Identity |
- |<---------------------------------------------------------|
- | |
- | EAP-Response/Identity |
- |--------------------------------------------------------->|
- | |
- | EAP-Request/SIM/Start (AT_VERSION_LIST) |
- |<---------------------------------------------------------|
- | |
- | EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)|
- |--------------------------------------------------------->|
- | |
- | EAP-Request/SIM/Challenge (AT_RAND, AT_MAC) |
- |<---------------------------------------------------------|
- +-------------------------------------+ |
- | Peer runs GSM algorithms, verifies | |
- | AT_MAC and derives session keys | |
- +-------------------------------------+ |
- | EAP-Response/SIM/Challenge (AT_MAC) |
- |--------------------------------------------------------->|
- | |
- | EAP-Success |
- |<---------------------------------------------------------|
- | |
-
- Figure 1: EAP-SIM full authentication procedure
-
-
-
-
-Haverinen & Salowey Informational [Page 8]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- The first EAP Request issued by the authenticator is
- EAP-Request/Identity. On full authentication, the peer's response
- includes either the user's International Mobile Subscriber Identity
- (IMSI) or a temporary identity (pseudonym) if identity privacy is in
- effect, as specified in Section 4.2.
-
- Following the peer's EAP-Response/Identity packet, the peer receives
- EAP Requests of Type 18 (SIM) from the EAP server and sends the
- corresponding EAP Responses. The EAP packets that are of the Type
- SIM also have a Subtype field. On full authentication, the first
- EAP-Request/SIM packet is of the Subtype 10 (Start). EAP-SIM packets
- encapsulate parameters in attributes, encoded in a Type, Length,
- Value format. The packet format and the use of attributes are
- specified in Section 8.
-
- The EAP-Request/SIM/Start packet contains the list of EAP-SIM
- versions supported by the EAP server in the AT_VERSION_LIST
- attribute. This packet may also include attributes for requesting
- the subscriber identity, as specified in Section 4.2.
-
- The peer responds to a EAP-Request/SIM/Start with the
- EAP-Response/SIM/Start packet, which includes the AT_NONCE_MT
- attribute that contains a random number NONCE_MT, chosen by the peer,
- and the AT_SELECTED_VERSION attribute that contains the version
- number selected by the peer. The version negotiation is protected by
- including the version list and the selected version in the
- calculation of keying material (Section 7).
-
- After receiving the EAP Response/SIM/Start, the EAP server obtains n
- GSM triplets for use in authenticating the subscriber, where n = 2 or
- n = 3. From the triplets, the EAP server derives the keying
- material, as specified in Section 7. The triplets may be obtained by
- contacting an Authentication Centre (AuC) on the GSM network; per GSM
- specifications, between 1 and 5 triplets may be obtained at a time.
- Triplets may be stored in the EAP server for use at a later time, but
- triplets MUST NOT be re-used, except in some error cases that are
- specified in Section 10.9.
-
- The next EAP Request the EAP Server issues is of the type SIM and
- subtype Challenge (11). It contains the RAND challenges and a
- message authentication code attribute AT_MAC to cover the challenges.
- The AT_MAC attribute is a general message authentication code
- attribute that is used in many EAP-SIM messages.
-
- On receipt of the EAP-Request/SIM/Challenge message, the peer runs
- the GSM authentication algorithm and calculates a copy of the message
- authentication code. The peer then verifies that the calculated MAC
- equals the received MAC. If the MAC's do not match, then the peer
-
-
-
-Haverinen & Salowey Informational [Page 9]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- sends the EAP-Response/SIM/Client-Error packet and the authentication
- exchange terminates.
-
- Since the RANDs given to a peer are accompanied by the message
- authentication code AT_MAC, and since the peer's NONCE_MT value
- contributes to AT_MAC, the peer is able to verify that the EAP-SIM
- message is fresh (i.e., not a replay) and that the sender possesses
- valid GSM triplets for the subscriber.
-
- If all checks out, the peer responds with the
- EAP-Response/SIM/Challenge, containing the AT_MAC attribute that
- covers the peer's SRES response values (Section 9.4). The EAP server
- verifies that the MAC is correct. Because protected success
- indications are not used in this example, the EAP server sends the
- EAP-Success packet, indicating that the authentication was
- successful. (Protected success indications are discussed in
- Section 6.2.) The EAP server may also include derived keying
- material in the message it sends to the authenticator. The peer has
- derived the same keying material, so the authenticator does not
- forward the keying material to the peer along with EAP-Success.
-
- EAP-SIM also includes a separate fast re-authentication procedure
- that does not make use of the A3/A8 algorithms or the GSM
- infrastructure. Fast re-authentication is based on keys derived on
- full authentication. If the peer has maintained state information
- for fast re-authentication and wants to use fast re-authentication,
- then the peer indicates this by using a specific fast
- re-authentication identity instead of the permanent identity or a
- pseudonym identity. The fast re-authentication procedure is
- described in Section 5.
-
-4. Operation
-
-4.1. Version Negotiation
-
- EAP-SIM includes version negotiation so as to allow future
- developments in the protocol. The version negotiation is performed
- on full authentication and it uses two attributes, AT_VERSION_LIST,
- which the server always includes in EAP-Request/SIM/Start, and
- AT_SELECTED_VERSION, which the peer includes in
- EAP-Response/SIM/Start on full authentication.
-
- AT_VERSION_LIST includes the EAP-SIM versions supported by the
- server. If AT_VERSION_LIST does not include a version that is
- implemented by the peer and allowed in the peer's security policy,
- then the peer MUST send the EAP-Response/SIM/Client-Error packet
- (Section 9.7) to the server with the error code "unsupported
- version". If a suitable version is included, then the peer includes
-
-
-
-Haverinen & Salowey Informational [Page 10]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- the AT_SELECTED_VERSION attribute, containing the selected version in
- the EAP-Response/SIM/Start packet. The peer MUST only indicate a
- version that is included in the AT_VERSION_LIST. If several versions
- are acceptable, then the peer SHOULD choose the version that occurs
- first in the version list.
-
- The version number list of AT_VERSION_LIST and the selected version
- of AT_SELECTED_VERSION are included in the key derivation procedure
- (Section 7). If an attacker modifies either one of these attributes,
- then the peer and the server derive different keying material.
- Because K_aut keys are different, the server and peer calculate
- different AT_MAC values. Hence, the peer detects that AT_MAC,
- included in EAP-Request/SIM/Challenge, is incorrect and sends the
- EAP-Response/SIM/Client-Error packet. The authentication procedure
- terminates.
-
-4.2. Identity Management
-
-4.2.1. Format, Generation and Usage of Peer Identities
-
-4.2.1.1. General
-
- In the beginning of EAP authentication, the Authenticator or the EAP
- server usually issues the EAP-Request/Identity packet to the peer.
- The peer responds with the EAP-Response/Identity, which contains the
- user's identity. The formats of these packets are specified in
- [RFC3748].
-
- GSM subscribers are identified with the International Mobile
- Subscriber Identity (IMSI) [GSM-03.03]. The IMSI is a string of not
- more than 15 digits. It is composed of a three digit Mobile Country
- Code (MCC), a two or three digit Mobile Network Code (MNC), and a
- Mobile Subscriber Identification Number (MSIN) of no more than 10
- digits. MCC and MNC uniquely identify the GSM operator and help
- identify the AuC from which the authentication vectors need to be
- retrieved for this subscriber.
-
- Internet AAA protocols identify users with the Network Access
- Identifier (NAI) [RFC4282]. When used in a roaming environment, the
- NAI is composed of a username and a realm, separated with "@"
- (username@realm). The username portion identifies the subscriber
- within the realm.
-
- This section specifies the peer identity format used in EAP-SIM. In
- this document, the term "identity" or "peer identity" refers to the
- whole identity string that is used to identify the peer. The peer
-
-
-
-
-
-Haverinen & Salowey Informational [Page 11]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- identity may include a realm portion. "Username" refers to the
- portion of the peer identity that identifies the user, i.e., the
- username does not include the realm portion.
-
-4.2.1.2. Identity Privacy Support
-
- EAP-SIM includes optional identity privacy (anonymity) support that
- can be used to hide the cleartext permanent identity and thereby make
- the subscriber's EAP exchanges untraceable to eavesdroppers. Because
- the permanent identity never changes, revealing it would help
- observers to track the user. The permanent identity is usually based
- on the IMSI, which may further help the tracking, because the same
- identifier may be used in other contexts as well. Identity privacy
- is based on temporary identities, or pseudonyms, which are equivalent
- to but separate from the Temporary Mobile Subscriber Identities
- (TMSI) that are used on cellular networks. Please see Section 12.2
- for security considerations regarding identity privacy.
-
-4.2.1.3. Username Types in EAP-SIM identities
-
- There are three types of usernames in EAP-SIM peer identities:
-
- (1) Permanent usernames. For example,
- 1123456789098765@myoperator.com might be a valid permanent identity.
- In this example, 1123456789098765 is the permanent username.
-
- (2) Pseudonym usernames. For example, 3s7ah6n9q@myoperator.com might
- be a valid pseudonym identity. In this example, 3s7ah6n9q is the
- pseudonym username.
-
- (3) Fast re-authentication usernames. For example,
- 53953754@myoperator.com might be a valid fast re-authentication
- identity. In this case, 53953754 is the fast re-authentication
- username. Unlike permanent usernames and pseudonym usernames, fast
- re-authentication usernames are one-time identifiers, which are not
- re-used across EAP exchanges.
-
- The first two types of identities are used only on full
- authentication and the last one only on fast re-authentication. When
- the optional identity privacy support is not used, the non-pseudonym
- permanent identity is used on full authentication. The fast
- re-authentication exchange is specified in Section 5.
-
-4.2.1.4. Username Decoration
-
- In some environments, the peer may need to decorate the identity by
- prepending or appending the username with a string, in order to
- indicate supplementary AAA routing information in addition to the NAI
-
-
-
-Haverinen & Salowey Informational [Page 12]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- realm. (The usage of an NAI realm portion is not considered
- decoration.) Username decoration is out of the scope of this
- document. However, it should be noted that username decoration might
- prevent the server from recognizing a valid username. Hence,
- although the peer MAY use username decoration in the identities that
- the peer includes in EAP-Response/Identity, and although the EAP
- server MAY accept a decorated peer username in this message, the peer
- or the EAP server MUST NOT decorate any other peer identities that
- are used in various EAP-SIM attributes. Only the identity used in
- the EAP-Response/Identity may be decorated.
-
-4.2.1.5. NAI Realm Portion
-
- The peer MAY include a realm portion in the peer identity, as per the
- NAI format. The use of a realm portion is not mandatory.
-
- If a realm is used, the realm MAY be chosen by the subscriber's home
- operator and it MAY be a configurable parameter in the EAP-SIM peer
- implementation. In this case, the peer is typically configured with
- the NAI realm of the home operator. Operators MAY reserve a specific
- realm name for EAP-SIM users. This convention makes it easy to
- recognize that the NAI identifies a GSM subscriber. Such a reserved
- NAI realm may be a useful hint as to the first authentication method
- to use during method negotiation. When the peer is using a pseudonym
- username instead of the permanent username, the peer selects the
- realm name portion similarly as it select the realm portion when
- using the permanent username.
-
- If no configured realm name is available, the peer MAY derive the
- realm name from the MCC and MNC portions of the IMSI. A RECOMMENDED
- way to derive the realm from the IMSI using the realm 3gppnetwork.org
- is specified in [3GPP-TS-23.003].
-
- Some old implementations derive the realm name from the IMSI by
- concatenating "mnc", the MNC digits of IMSI, ".mcc", the MCC digits
- of IMSI, and ".owlan.org". For example, if the IMSI is
- 123456789098765, and the MNC is three digits long, then the derived
- realm name is "mnc456.mcc123.owlan.org". As there are no DNS servers
- running at owlan.org, these realm names can only be used with
- manually configured AAA routing. New implementations SHOULD use the
- mechanism specified in [3GPP-TS-23.003] instead of owlan.org.
-
- The IMSI is a string of digits without any explicit structure, so the
- peer may not be able to determine the length of the MNC portion. If
- the peer is not able to determine whether the MNC is two or three
- digits long, the peer MAY use a 3-digit MNC. If the correct length
- of the MNC is two, then the MNC used in the realm name includes the
- first digit of the MSIN. Hence, when configuring AAA networks for
-
-
-
-Haverinen & Salowey Informational [Page 13]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- operators that have 2-digit MNCs, the network SHOULD also be prepared
- for realm names with incorrect, 3-digit MNCs.
-
-4.2.1.6. Format of the Permanent Username
-
- The non-pseudonym permanent username SHOULD be derived from the IMSI.
- In this case, the permanent username MUST be of the format "1" |
- IMSI, where the character "|" denotes concatenation. In other words,
- the first character of the username is the digit one (ASCII value 31
- hexadecimal), followed by the IMSI. The IMSI is encoded as an ASCII
- string that consists of not more than 15 decimal digits (ASCII values
- between 30 and 39 hexadecimal), one character per IMSI digit, in the
- order specified in [GSM-03.03]. For example, a permanent username
- derived from the IMSI 295023820005424 would be encoded as the ASCII
- string "1295023820005424" (byte values in hexadecimal notation: 31 32
- 39 35 30 32 33 38 32 30 30 30 35 34 32 34).
-
- The EAP server MAY use the leading "1" as a hint to try EAP-SIM as
- the first authentication method during method negotiation, rather
- than, for example EAP/AKA. The EAP-SIM server MAY propose EAP-SIM,
- even if the leading character was not "1".
-
- Alternatively, an implementation MAY choose a permanent username that
- is not based on the IMSI. In this case, the selection of the
- username, its format, and its processing is out of the scope of this
- document. In this case, the peer implementation MUST NOT prepend any
- leading characters to the username.
-
-4.2.1.7. Generating Pseudonyms and Fast Re-authentication Identities by
- the Server
-
- Pseudonym usernames and fast re-authentication identities are
- generated by the EAP server. The EAP server produces pseudonym
- usernames and fast re-authentication identities in an
- implementation-dependent manner. Only the EAP server needs to be
- able to map the pseudonym username to the permanent identity, or to
- recognize a fast re-authentication identity.
-
- EAP-SIM includes no provisions to ensure that the same EAP server
- that generated a pseudonym username will be used on the
- authentication exchange when the pseudonym username is used. It is
- recommended that the EAP servers implement some centralized mechanism
- to allow all EAP servers of the home operator to map pseudonyms
- generated by other severs to the permanent identity. If no such
- mechanism is available, then the EAP server failing to understand a
- pseudonym issued by another server can request the that peer send the
- permanent identity.
-
-
-
-
-Haverinen & Salowey Informational [Page 14]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- When issuing a fast re-authentication identity, the EAP server may
- include a realm name in the identity to make the fast
- re-authentication request be forwarded to the same EAP server.
-
- When generating fast re-authentication identities, the server SHOULD
- choose a fresh, new fast re-authentication identity that is different
- from the previous ones that were used after the same full
- authentication exchange. A full authentication exchange and the
- associated fast re-authentication exchanges are referred to here as
- the same "full authentication context". The fast re-authentication
- identity SHOULD include a random component. This random component
- works as a full authentication context identifier. A
- context-specific fast re-authentication identity can help the server
- to detect whether its fast re-authentication state information
- matches that of its peer (in other words, whether the state
- information is from the same full authentication exchange). The
- random component also makes the fast re-authentication identities
- unpredictable, so an attacker cannot initiate a fast
- re-authentication exchange to get the server's EAP-Request/SIM/
- Re-authentication packet.
-
- Transmitting pseudonyms and fast re-authentication identities from
- the server to the peer is discussed in Section 4.2.1.8. The
- pseudonym is transmitted as a username, without an NAI realm, and the
- fast re-authentication identity is transmitted as a complete NAI,
- including a realm portion if a realm is required. The realm is
- included in the fast re-authentication identity to allow the server
- to include a server-specific realm.
-
- Regardless of the construction method, the pseudonym username MUST
- conform to the grammar specified for the username portion of an NAI.
- The fast re-authentication identity also MUST conform to the NAI
- grammar. The EAP servers that the subscribers of an operator can use
- MUST ensure that the pseudonym usernames and the username portions
- used in fast re-authentication identities they generate are unique.
-
- In any case, it is necessary that permanent usernames, pseudonym
- usernames, and fast re-authentication usernames are separate and
- recognizable from each other. It is also desirable that EAP-SIM and
- EAP-AKA [EAP-AKA] usernames be distinguishable from each other as an
- aid for the server on which method to offer.
-
- In general, it is the task of the EAP server and the policies of its
- administrator to ensure sufficient separation of the usernames.
- Pseudonym usernames and fast re-authentication usernames are both
- produced and used by the EAP server. The EAP server MUST compose
- pseudonym usernames and fast re-authentication usernames so that it
- can determine if an NAI username is an EAP-SIM pseudonym username or
-
-
-
-Haverinen & Salowey Informational [Page 15]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- an EAP-SIM fast re-authentication username. For instance, when the
- usernames have been derived from the IMSI, the server could use
- different leading characters in the pseudonym usernames and fast
- re-authentication usernames (e.g., the pseudonym could begin with a
- leading "3" character). When mapping a fast re-authentication
- identity to a permanent identity, the server SHOULD only examine the
- username portion of the fast re-authentication identity and ignore
- the realm portion of the identity.
-
- Because the peer may fail to save a pseudonym username sent in an
- EAP-Request/SIM/Challenge, for example due to malfunction, the EAP
- server SHOULD maintain at least the most recently used pseudonym
- username in addition to the most recently issued pseudonym username.
- If the authentication exchange is not completed successfully, then
- the server SHOULD NOT overwrite the pseudonym username that was
- issued during the most recent successful authentication exchange.
-
-4.2.1.8. Transmitting Pseudonyms and Fast Re-authentication Identities
- to the Peer
-
- The server transmits pseudonym usernames and fast re-authentication
- identities to the peer in cipher, using the AT_ENCR_DATA attribute.
-
- The EAP-Request/SIM/Challenge message MAY include an encrypted
- pseudonym username and/or an encrypted fast re-authentication
- identity in the value field of the AT_ENCR_DATA attribute. Because
- identity privacy support and fast re-authentication are optional
- implementations, the peer MAY ignore the AT_ENCR_DATA attribute and
- always use the permanent identity. On fast re-authentication
- (discussed in Section 5), the server MAY include a new, encrypted
- fast re-authentication identity in the
- EAP-Request/SIM/Re-authentication message.
-
- On receipt of the EAP-Request/SIM/Challenge, the peer MAY decrypt the
- encrypted data in AT_ENCR_DATA. If the authentication exchange is
- successful, and the encrypted data includes a pseudonym username,
- then the peer may use the obtained pseudonym username on the next
- full authentication. If a fast re-authentication identity is
- included, then the peer MAY save it together with other fast
- re-authentication state information, as discussed in Section 5, for
- the next fast re-authentication. If the authentication exchange does
- not complete successfully, the peer MUST ignore the received
- pseudonym username and the fast re-authentication identity.
-
- If the peer does not receive a new pseudonym username in the
- EAP-Request/SIM/Challenge message, the peer MAY use an old pseudonym
- username instead of the permanent username on the next full
- authentication. The username portions of fast re-authentication
-
-
-
-Haverinen & Salowey Informational [Page 16]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- identities are one-time usernames, which the peer MUST NOT re-use.
- When the peer uses a fast re-authentication identity in an EAP
- exchange, the peer MUST discard the fast re-authentication identity
- and not re-use it in another EAP authentication exchange, even if the
- authentication exchange was not completed.
-
-4.2.1.9. Usage of the Pseudonym by the Peer
-
- When the optional identity privacy support is used on full
- authentication, the peer MAY use a pseudonym username received as
- part of a previous full authentication sequence as the username
- portion of the NAI. The peer MUST NOT modify the pseudonym username
- received in AT_NEXT_PSEUDONYM. However, as discussed above, the peer
- MAY need to decorate the username in some environments by appending
- or prepending the username with a string that indicates supplementary
- AAA routing information.
-
- When using a pseudonym username in an environment where a realm
- portion is used, the peer concatenates the received pseudonym
- username with the "@" character and an NAI realm portion. The
- selection of the NAI realm is discussed above. The peer can select
- the realm portion similarly, regardless of whether it uses the
- permanent username or a pseudonym username.
-
-4.2.1.10. Usage of the Fast Re-authentication Identity by the Peer
-
- On fast re-authentication, the peer uses the fast re-authentication
- identity that was received as part of the previous authentication
- sequence. A new re-authentication identity may be delivered as part
- of both full authentication and fast re-authentication. The peer
- MUST NOT modify the username part of the fast re-authentication
- identity received in AT_NEXT_REAUTH_ID, except in cases when username
- decoration is required. Even in these cases, the "root" fast
- re-authentication username must not be modified, but it may be
- appended or prepended with another string.
-
-4.2.2. Communicating the Peer Identity to the Server
-
-4.2.2.1. General
-
- The peer identity MAY be communicated to the server with the
- EAP-Response/Identity message. This message MAY contain the
- permanent identity, a pseudonym identity, or a fast re-authentication
- identity. If the peer uses the permanent identity or a pseudonym
- identity, which the server is able to map to the permanent identity,
- then the authentication proceeds as discussed in the overview of
- Section 3. If the peer uses a fast re-authentication identity, and
- if the fast re-authentication identity matches with a valid fast
-
-
-
-Haverinen & Salowey Informational [Page 17]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- re-authentication identity maintained by the server, and if the
- server agrees to use fast re-authentication, then a fast
- re-authentication exchange is performed, as described in Section 5.
-
- The peer identity can also be transmitted from the peer to the server
- using EAP-SIM messages instead of the EAP-Response/Identity. In this
- case, the server includes an identity-requesting attribute
- (AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the
- EAP-Request/SIM/Start message, and the peer includes the AT_IDENTITY
- attribute, which contains the peer's identity, in the
- EAP-Response/SIM/Start message. The AT_ANY_ID_REQ attribute is a
- general identity-requesting attribute, which the server uses if it
- does not specify which kind of an identity the peer should return in
- AT_IDENTITY. The server uses the AT_FULLAUTH_ID_REQ attribute to
- request either the permanent identity or a pseudonym identity. The
- server uses the AT_PERMANENT_ID_REQ attribute to request that the
- peer send its permanent identity.
-
- The identity format in the AT_IDENTITY attribute is the same as in
- the EAP-Response/Identity packet (except that identity decoration is
- not allowed). The AT_IDENTITY attribute contains a permanent
- identity, a pseudonym identity, or a fast re-authentication identity.
-
- Please note that the EAP-SIM peer and the EAP-SIM server only process
- the AT_IDENTITY attribute; entities that only pass through EAP
- packets do not process this attribute. Hence, the authenticator and
- other intermediate AAA elements (such as possible AAA proxy servers)
- will continue to refer to the peer with the original identity from
- the EAP-Response/Identity packet unless the identity authenticated in
- the AT_IDENTITY attribute is communicated to them in another way
- within the AAA protocol.
-
-4.2.2.2. Relying on EAP-Response/Identity Discouraged
-
- The EAP-Response/Identity packet is not method-specific, so in many
- implementations it may be handled by an EAP Framework. This
- introduces an additional layer of processing between the EAP peer and
- EAP server. The extra layer of processing may cache identity
- responses or add decorations to the identity. A modification of the
- identity response will cause the EAP peer and EAP server to use
- different identities in the key derivation, which will cause the
- protocol to fail.
-
- For this reason, it is RECOMMENDED that the EAP peer and server use
- the method-specific identity attributes in EAP-SIM, and the server is
- strongly discouraged from relying upon the EAP-Response/Identity.
-
-
-
-
-
-Haverinen & Salowey Informational [Page 18]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- In particular, if the EAP server receives a decorated identity in
- EAP-Response/Identity, then the EAP server MUST use the
- identity-requesting attributes to request that the peer send an
- unmodified and undecorated copy of the identity in AT_IDENTITY.
-
-4.2.3. Choice of Identity for the EAP-Response/Identity
-
- If EAP-SIM peer is started upon receiving an EAP-Request/Identity
- message, then the peer MAY use an EAP-SIM identity in the EAP-
- Response/Identity packet. In this case, the peer performs the
- following steps.
-
- If the peer has maintained fast re-authentication state information
- and wants to use fast re-authentication, then the peer transmits the
- fast re-authentication identity in EAP-Response/Identity.
-
- Else, if the peer has a pseudonym username available, then the peer
- transmits the pseudonym identity in EAP-Response/Identity.
-
- In other cases, the peer transmits the permanent identity in
- EAP-Response/Identity.
-
-4.2.4. Server Operation in the Beginning of EAP-SIM Exchange
-
- As discussed in Section 4.2.2.2, the server SHOULD NOT rely on an
- identity string received in EAP-Response/Identity. Therefore, the
- RECOMMENDED way to start an EAP-SIM exchange is to ignore any
- received identity strings. The server SHOULD begin the EAP-SIM
- exchange by issuing the EAP-Request/SIM/Start packet with an
- identity-requesting attribute to indicate that the server wants the
- peer to include an identity in the AT_IDENTITY attribute of the EAP-
- Response/SIM/Start message. Three methods to request an identity
- from the peer are discussed below.
-
- If the server chooses not to ignore the contents of EAP-
- Response/Identity, then the server may have already received an EAP-
- SIM identity in this packet. However, if the EAP server has not
- received any EAP-SIM peer identity (permanent identity, pseudonym
- identity, or fast re-authentication identity) from the peer when
- sending the first EAP-SIM request, or if the EAP server has received
- an EAP-Response/Identity packet but the contents do not appear to be
- a valid permanent identity, pseudonym identity or a re-authentication
- identity, then the server MUST request an identity from the peer
- using one of the methods below.
-
- The server sends the EAP-Request/SIM/Start message with the
- AT_PERMANENT_ID_REQ attribute to indicate that the server wants the
- peer to include the permanent identity in the AT_IDENTITY attribute
-
-
-
-Haverinen & Salowey Informational [Page 19]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- of the EAP-Response/SIM/Start message. This is done in the following
- cases:
-
- o The server does not support fast re-authentication or identity
- privacy.
-
- o The server decided to process a received identity, and the server
- recognizes the received identity as a pseudonym identity but the
- server is not able to map the pseudonym identity to a permanent
- identity.
-
- The server issues the EAP-Request/SIM/Start packet with the
- AT_FULLAUTH_ID_REQ attribute to indicate that the server wants the
- peer to include a full authentication identity (pseudonym identity or
- permanent identity) in the AT_IDENTITY attribute of the
- EAP-Response/SIM/Start message. This is done in the following cases:
-
- o The server does not support fast re-authentication and the server
- supports identity privacy.
-
- o The server decided to process a received identity, and the server
- recognizes the received identity as a re-authentication identity
- but the server is not able to map the re-authentication identity
- to a permanent identity.
-
- The server issues the EAP-Request/SIM/Start packet with the
- AT_ANY_ID_REQ attribute to indicate that the server wants the peer to
- include an identity in the AT_IDENTITY attribute of the
- EAP-Response/SIM/Start message, and the server does not indicate any
- preferred type for the identity. This is done in other cases, such
- as when the server ignores a received EAP-Response/Identity, the
- server does not have any identity, or the server does not recognize
- the format of a received identity.
-
-4.2.5. Processing of EAP-Request/SIM/Start by the Peer
-
- Upon receipt of an EAP-Request/SIM/Start message, the peer MUST
- perform the following steps.
-
- If the EAP-Request/SIM/Start does not include an identity request
- attribute, then the peer responds with EAP-Response/SIM/Start without
- AT_IDENTITY. The peer includes the AT_SELECTED_VERSION and
- AT_NONCE_MT attributes, because the exchange is a full authentication
- exchange.
-
- If the EAP-Request/SIM/Start includes AT_PERMANENT_ID_REQ, and if the
- peer does not have a pseudonym available, then the peer MUST respond
- with EAP-Response/SIM/Start and include the permanent identity in
-
-
-
-Haverinen & Salowey Informational [Page 20]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- AT_IDENTITY. If the peer has a pseudonym available, then the peer
- MAY refuse to send the permanent identity; hence, in this case the
- peer MUST either respond with EAP-Response/SIM/Start and include the
- permanent identity in AT_IDENTITY or respond with EAP-Response/SIM/
- Client-Error packet with the code "unable to process packet".
-
- If the EAP-Request/SIM/Start includes AT_FULL_AUTH_ID_REQ, and if the
- peer has a pseudonym available, then the peer SHOULD respond with
- EAP-Response/SIM/Start and include the pseudonym identity in
- AT_IDENTITY. If the peer does not have a pseudonym when it receives
- this message, then the peer MUST respond with EAP-Response/SIM/Start
- and include the permanent identity in AT_IDENTITY. The Peer MUST NOT
- use a re-authentication identity in the AT_IDENTITY attribute.
-
- If the EAP-Request/SIM/Start includes AT_ANY_ID_REQ, and if the peer
- has maintained fast re-authentication state information and the peer
- wants to use fast re-authentication, then the peer responds with
- EAP-Response/SIM/Start and includes the fast re-authentication
- identity in AT_IDENTITY. Else, if the peer has a pseudonym identity
- available, then the peer responds with EAP-Response/SIM/Start and
- includes the pseudonym identity in AT_IDENTITY. Else, the peer
- responds with EAP-Response/SIM/Start and includes the permanent
- identity in AT_IDENTITY.
-
- An EAP-SIM exchange may include several EAP/SIM/Start rounds. The
- server may issue a second EAP-Request/SIM/Start if it was not able to
- recognize the identity that the peer used in the previous AT_IDENTITY
- attribute. At most, three EAP/SIM/Start rounds can be used, so the
- peer MUST NOT respond to more than three EAP-Request/SIM/Start
- messages within an EAP exchange. The peer MUST verify that the
- sequence of EAP-Request/SIM/Start packets that the peer receives
- comply with the sequencing rules defined in this document. That is,
- AT_ANY_ID_REQ can only be used in the first EAP-Request/SIM/Start; in
- other words, AT_ANY_ID_REQ MUST NOT be used in the second or third
- EAP-Request/SIM/Start. AT_FULLAUTH_ID_REQ MUST NOT be used if the
- previous EAP-Request/SIM/Start included AT_PERMANENT_ID_REQ. The
- peer operation, in cases when it receives an unexpected attribute or
- an unexpected message, is specified in Section 6.3.1.
-
-4.2.6. Attacks Against Identity Privacy
-
- The section above specifies two possible ways the peer can operate
- upon receipt of AT_PERMANENT_ID_REQ. This is because a received
- AT_PERMANENT_ID_REQ does not necessarily originate from the valid
- network, but an active attacker may transmit an EAP-Request/SIM/
- Start packet with an AT_PERMANENT_ID_REQ attribute to the peer, in an
- effort to find out the true identity of the user. If the peer does
- not want to reveal its permanent identity, then the peer sends the
-
-
-
-Haverinen & Salowey Informational [Page 21]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- EAP-Response/SIM/Client-Error packet with the error code "unable to
- process packet", and the authentication exchange terminates.
-
- Basically, there are two different policies that the peer can employ
- with regard to AT_PERMANENT_ID_REQ. A "conservative" peer assumes
- that the network is able to maintain pseudonyms robustly. Therefore,
- if a conservative peer has a pseudonym username, the peer responds
- with EAP-Response/SIM/Client-Error to the EAP packet with
- AT_PERMANENT_ID_REQ, because the peer believes that the valid network
- is able to map the pseudonym identity to the peer's permanent
- identity. (Alternatively, the conservative peer may accept
- AT_PERMANENT_ID_REQ in certain circumstances, for example, if the
- pseudonym was received a long time ago.) The benefit of this policy
- is that it protects the peer against active attacks on anonymity. On
- the other hand, a "liberal" peer always accepts the
- AT_PERMANENT_ID_REQ and responds with the permanent identity. The
- benefit of this policy is that it works even if the valid network
- sometimes loses pseudonyms and is not able to map them to the
- permanent identity.
-
-4.2.7. Processing of AT_IDENTITY by the Server
-
- When the server receives an EAP-Response/SIM/Start message with the
- AT_IDENTITY (in response to the server's identity requesting
- attribute), the server MUST operate as follows.
-
- If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does
- not contain a valid permanent identity, then the server sends
- EAP-Request/SIM/Notification with AT_NOTIFICATION code "General
- failure" (16384), and the EAP exchange terminates. If the server
- recognizes the permanent identity and is able to continue, then the
- server proceeds with full authentication by sending EAP-Request/SIM/
- Challenge.
-
- If the server used AT_FULLAUTH_ID_REQ, and if AT_IDENTITY contains a
- valid permanent identity or a pseudonym identity that the server can
- map to a valid permanent identity, then the server proceeds with full
- authentication by sending EAP-Request/SIM/Challenge. If AT_IDENTITY
- contains a pseudonym identity that the server is not able to map to a
- valid permanent identity, or an identity that the server is not able
- to recognize or classify, then the server sends EAP-Request/SIM/Start
- with AT_PERMANENT_ID_REQ.
-
- If the server used AT_ANY_ID_REQ, and if the AT_IDENTITY contains a
- valid permanent identity or a pseudonym identity that the server can
- map to a valid permanent identity, then the server proceeds with full
- authentication by sending EAP-Request/SIM/Challenge.
-
-
-
-
-Haverinen & Salowey Informational [Page 22]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid
- fast re-authentication identity and the server agrees on using
- re-authentication, then the server proceeds with fast
- re-authentication by sending EAP-Request/SIM/Re-authentication
- (Section 5).
-
- If the server used AT_ANY_ID_REQ, and if the peer sent an
- EAP-Response/SIM/Start with only AT_IDENTITY (indicating
- re-authentication), but the server is not able to map the identity to
- a permanent identity, then the server sends EAP-Request/SIM/Start
- with AT_FULLAUTH_ID_REQ.
-
- If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid
- fast re-authentication identity that the server is able to map to a
- permanent identity, and if the server does not want to use fast
- re-authentication, then the server sends EAP-Request/SIM/Start
- without any identity requesting attributes.
-
- If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an
- identity that the server recognizes as a pseudonym identity but the
- server is not able to map the pseudonym identity to a permanent
- identity, then the server sends EAP-Request/SIM/Start with
- AT_PERMANENT_ID_REQ.
-
- If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an
- identity that the server is not able to recognize or classify, then
- the server sends EAP-Request/SIM/Start with AT_FULLAUTH_ID_REQ.
-
-4.3. Message Sequence Examples (Informative)
-
- This section contains non-normative message sequence examples to
- illustrate how the peer identity can be communicated to the server.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 23]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-4.3.1. Full Authentication
-
- This case for full authentication is illustrated below in Figure 2.
- In this case, AT_IDENTITY contains either the permanent identity or a
- pseudonym identity. The same sequence is also used in case the
- server uses the AT_FULLAUTH_ID_REQ in EAP-Request/SIM/Start.
-
- Peer Authenticator
- | |
- | +------------------------------+
- | | Server does not have a |
- | | Subscriber identity available|
- | | When starting EAP-SIM |
- | +------------------------------+
- | |
- | EAP-Request/SIM/Start |
- | (AT_ANY_ID_REQ, AT_VERSION_LIST) |
- |<------------------------------------------------------|
- | |
- | |
- | EAP-Response/SIM/Start |
- | (AT_IDENTITY, AT_NONCE_MT, |
- | AT_SELECTED_VERSION) |
- |------------------------------------------------------>|
- | |
-
- Figure 2: Requesting any identity, full authentication
-
- If the peer uses its full authentication identity and the AT_IDENTITY
- attribute contains a valid permanent identity or a valid pseudonym
- identity that the EAP server is able to map to the permanent
- identity, then the full authentication sequence proceeds as usual
- with the EAP Server issuing the EAP-Request/SIM/Challenge message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 24]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-4.3.2. Fast Re-authentication
-
- The case when the server uses the AT_ANY_ID_REQ and the peer wants to
- perform fast re-authentication is illustrated below in Figure 3.
-
- Peer Authenticator
- | |
- | +------------------------------+
- | | Server does not have a |
- | | Subscriber identity available|
- | | When starting EAP-SIM |
- | +------------------------------+
- | |
- | EAP-Request/SIM/Start |
- | (AT_ANY_ID_REQ, AT_VERSION_LIST) |
- |<------------------------------------------------------|
- | |
- | |
- | EAP-Response/SIM/Start |
- | (AT_IDENTITY containing a fast re-auth. identity) |
- |------------------------------------------------------>|
- | |
-
- Figure 3: Requesting any identity, fast re-authentication
-
- On fast re-authentication, if the AT_IDENTITY attribute contains a
- valid fast re-authentication identity and the server agrees on using
- fast re-authentication, then the server proceeds with the fast
- re-authentication sequence and issues the EAP-Request/SIM/
- Re-authentication packet, as specified in Section 5.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 25]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-4.3.3. Fall Back to Full Authentication
-
- Figure 4 illustrates cases in which the server does not recognize the
- fast re-authentication identity the peer used in AT_IDENTITY, and
- issues a second EAP-Request/SIM/Start message.
-
- Peer Authenticator
- | |
- | +------------------------------+
- | | Server does not have a |
- | | Subscriber identity available|
- | | When starting EAP-SIM |
- | +------------------------------+
- | |
- | EAP-Request/SIM/Start |
- | (AT_ANY_ID_REQ, AT_VERSION_LIST) |
- |<------------------------------------------------------|
- | |
- | |
- | EAP-Response/SIM/Start |
- | (AT_IDENTITY containing a fast re-auth. identity) |
- |------------------------------------------------------>|
- | |
- | +------------------------------+
- | | Server does not recognize |
- | | The fast re-auth. |
- | | Identity |
- | +------------------------------+
- | |
- | EAP-Request/SIM/Start |
- | (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) |
- |<------------------------------------------------------|
- | |
- | |
- | EAP-Response/SIM/Start |
- | (AT_IDENTITY with a full-auth. identity, AT_NONCE_MT, |
- | AT_SELECTED_VERSION) |
- |------------------------------------------------------>|
- | |
-
- Figure 4: Fall back to full authentication
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 26]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-4.3.4. Requesting the Permanent Identity 1
-
- Figure 5 illustrates the case in which the EAP server fails to map
- the pseudonym identity included in the EAP-Response/Identity packet
- to a valid permanent identity.
-
- Peer Authenticator
- | |
- | EAP-Request/Identity |
- |<------------------------------------------------------|
- | |
- | EAP-Response/Identity |
- | (Includes a pseudonym) |
- |------------------------------------------------------>|
- | |
- | +------------------------------+
- | | Server fails to map the |
- | | Pseudonym to a permanent id. |
- | +------------------------------+
- | EAP-Request/SIM/Start |
- | (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) |
- |<------------------------------------------------------|
- | |
- | EAP-Response/SIM/Start |
- | (AT_IDENTITY with permanent identity, AT_NONCE_MT, |
- | AT_SELECTED_VERSION) |
- |------------------------------------------------------>|
- | |
-
- Figure 5: Requesting the permanent identity
-
- If the server recognizes the permanent identity, then the
- authentication sequence proceeds as usual with the EAP Server issuing
- the EAP-Request/SIM/Challenge message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 27]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-4.3.5. Requesting the Permanent Identity 2
-
- Figure 6 illustrates the case in which the EAP server fails to map
- the pseudonym included in the AT_IDENTITY attribute to a valid
- permanent identity.
-
- Peer Authenticator
- | |
- | +------------------------------+
- | | Server does not have a |
- | | Subscriber identity available|
- | | When starting EAP-SIM |
- | +------------------------------+
- | EAP-Request/SIM/Start |
- | (AT_ANY_ID_REQ, AT_VERSION_LIST) |
- |<------------------------------------------------------|
- | |
- |EAP-Response/SIM/Start |
- |(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, |
- | AT_SELECTED_VERSION) |
- |------------------------------------------------------>|
- | +-------------------------------+
- | | Server fails to map the |
- | | Pseudonym in AT_IDENTITY |
- | | to a valid permanent identity |
- | +-------------------------------+
- | |
- | EAP-Request/SIM/Start |
- | (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) |
- |<------------------------------------------------------|
- | |
- | EAP-Response/SIM/Start |
- | (AT_IDENTITY with permanent identity, |
- | AT_NONCE_MT, AT_SELECTED_VERSION) |
- |------------------------------------------------------>|
- | |
-
- Figure 6: Requesting a permanent identity (two EAP-SIM Start rounds)
-
-4.3.6. Three EAP-SIM/Start Roundtrips
-
- In the worst case, there are three EAP/SIM/Start round trips before
- the server obtains an acceptable identity. This case is illustrated
- in Figure 7.
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 28]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- Peer Authenticator
- | |
- | +------------------------------+
- | | Server does not have a |
- | | Subscriber identity available|
- | | When starting EAP-SIM |
- | +------------------------------+
- | EAP-Request/SIM/Start |
- | (Includes AT_ANY_ID_REQ, AT_VERSION_LIST) |
- |<------------------------------------------------------|
- | |
- | EAP-Response/SIM/Start |
- | (AT_IDENTITY with fast re-auth. identity) |
- |------------------------------------------------------>|
- | |
- | +------------------------------+
- | | Server does not accept |
- | | The fast re-auth. |
- | | Identity |
- | +------------------------------+
- | EAP-Request/SIM/Start |
- | (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) |
- |<------------------------------------------------------|
- | |
- : :
- : :
- : :
- : :
- |EAP-Response/SIM/Start |
- |(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, |
- | AT_SELECTED_VERSION) |
- |------------------------------------------------------>|
- | |
- | +-------------------------------+
- | | Server fails to map the |
- | | Pseudonym in AT_IDENTITY |
- | | to a valid permanent identity |
- | +-------------------------------+
- | EAP-Request/SIM/Start |
- | (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) |
- |<------------------------------------------------------|
- | |
- | EAP-Response/SIM/Start |
- | (AT_IDENTITY with permanent identity, AT_NONCE_MT, |
- | AT_SELECTED_VERSION) |
- |------------------------------------------------------>|
- | |
- Figure 7: Three EAP-SIM Start rounds
-
-
-
-Haverinen & Salowey Informational [Page 29]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- After the last EAP-Response/SIM/Start message, the full
- authentication sequence proceeds as usual. If the EAP Server
- recognizes the permanent identity and is able to proceed, the server
- issues the EAP-Request/SIM/Challenge message.
-
-5. Fast Re-Authentication
-
-5.1. General
-
- In some environments, EAP authentication may be performed frequently.
- Because the EAP-SIM full authentication procedure makes use of the
- GSM SIM A3/A8 algorithms, and therefore requires 2 or 3 fresh
- triplets from the Authentication Centre, the full authentication
- procedure is not very well suited for frequent use. Therefore,
- EAP-SIM includes a more inexpensive fast re-authentication procedure
- that does not make use of the SIM A3/A8 algorithms and does not need
- new triplets from the Authentication Centre. Re-authentication can
- be performed in fewer roundtrips than the full authentication.
-
- Fast re-authentication is optional to implement for both the EAP-SIM
- server and peer. On each EAP authentication, either one of the
- entities may also fall back on full authentication if it does not
- want to use fast re-authentication.
-
- Fast re-authentication is based on the keys derived on the preceding
- full authentication. The same K_aut and K_encr keys that were used
- in full authentication are used to protect EAP-SIM packets and
- attributes, and the original Master Key from full authentication is
- used to generate a fresh Master Session Key, as specified in Section
- 7.
-
- The fast re-authentication exchange makes use of an unsigned 16-bit
- counter, included in the AT_COUNTER attribute. The counter has three
- goals: 1) it can be used to limit the number of successive
- reauthentication exchanges without full authentication 2) it
- contributes to the keying material, and 3) it protects the peer and
- the server from replays. On full authentication, both the server and
- the peer initialize the counter to one. The counter value of at
- least one is used on the first fast re-authentication. On subsequent
- fast re-authentications, the counter MUST be greater than on any of
- the previous re-authentications. For example, on the second fast
- re-authentication, the counter value is two or greater. The
- AT_COUNTER attribute is encrypted.
-
- Both the peer and the EAP server maintain a copy of the counter. The
- EAP server sends its counter value to the peer in the fast
- re-authentication request. The peer MUST verify that its counter
- value is less than or equal to the value sent by the EAP server.
-
-
-
-Haverinen & Salowey Informational [Page 30]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- The server includes an encrypted server random nonce (AT_NONCE_S) in
- the fast re-authentication request. The AT_MAC attribute in the
- peer's response is calculated over NONCE_S to provide a
- challenge/response authentication scheme. The NONCE_S also
- contributes to the new Master Session Key.
-
- Both the peer and the server SHOULD have an upper limit for the
- number of subsequent fast re-authentications allowed before a full
- authentication needs to be performed. Because a 16-bit counter is
- used in fast re-authentication, the theoretical maximum number of
- re-authentications is reached when the counter value reaches FFFF
- hexadecimal.
-
- In order to use fast re-authentication, the peer and the EAP server
- need to store the following values: Master Key, latest counter value
- and the next fast re-authentication identity. K_aut, K_encr may
- either be stored or derived again from MK. The server may also need
- to store the permanent identity of the user.
-
-5.2. Comparison to UMTS AKA
-
- When analyzing the fast re-authentication exchange, it may be helpful
- to compare it with the UMTS Authentication and Key Agreement (AKA)
- exchange, which it resembles closely. The counter corresponds to the
- UMTS AKA sequence number, NONCE_S corresponds to RAND, AT_MAC in
- EAP-Request/SIM/Re-authentication corresponds to AUTN, the AT_MAC in
- EAP-Response/SIM/Re-authentication corresponds to RES,
- AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the counter
- corresponds to the usage of the Anonymity Key. Also, the key
- generation on fast re-authentication, with regard to random or fresh
- material, is similar to UMTS AKA -- the server generates the NONCE_S
- and counter values, and the peer only verifies that the counter value
- is fresh.
-
- It should also be noted that encrypting the AT_NONCE_S, AT_COUNTER,
- or AT_COUNTER_TOO_SMALL attributes is not important to the security
- of the fast re-authentication exchange.
-
-5.3. Fast Re-authentication Identity
-
- The fast re-authentication procedure makes use of separate
- re-authentication user identities. Pseudonyms and the permanent
- identity are reserved for full authentication only. If a
- re-authentication identity is lost and the network does not recognize
- it, the EAP server can fall back on full authentication.
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 31]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- If the EAP server supports fast re-authentication, it MAY include the
- skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of
- EAP-Request/SIM/Challenge message (Section 9.3). This attribute
- contains a new fast re-authentication identity for the next fast
- re-authentication. The attribute also works as a capability flag
- that, indicating that the server supports fast re-authentication, and
- that the server wants to continue using fast re-authentication within
- the current context. The peer MAY ignore this attribute, in which
- case it MUST use full authentication next time. If the peer wants to
- use re-authentication, it uses this fast re-authentication identity
- on next authentication. Even if the peer has a fast
- re-authentication identity, the peer MAY discard the fast
- re-authentication identity and use a pseudonym or the permanent
- identity instead, in which case full authentication MUST be
- performed. If the EAP server does not include the AT_NEXT_REAUTH_ID
- in the encrypted data of EAP-Request/SIM/Challenge or
- EAP-Request/SIM/ Re-authentication, then the peer MUST discard its
- current fast re-authentication state information and perform a full
- authentication next time.
-
- In environments where a realm portion is needed in the peer identity,
- the fast re-authentication identity received in AT_NEXT_REAUTH_ID
- MUST contain both a username portion and a realm portion, as per the
- NAI format. The EAP Server can choose an appropriate realm part in
- order to have the AAA infrastructure route subsequent fast
- re-authentication related requests to the same AAA server. For
- example, the realm part MAY include a portion that is specific to the
- AAA server. Hence, it is sufficient to store the context required
- for fast re-authentication in the AAA server that performed the full
- authentication.
-
- The peer MAY use the fast re-authentication identity in the
- EAP-Response/Identity packet or, in response to the server's
- AT_ANY_ID_REQ attribute, the peer MAY use the fast re-authentication
- identity in the AT_IDENTITY attribute of the EAP-Response/SIM/Start
- packet.
-
- The peer MUST NOT modify the username portion of the fast
- re-authentication identity, but the peer MAY modify the realm portion
- or replace it with another realm portion. The peer might need to
- modify the realm in order to influence the AAA routing, for example,
- to make sure that the correct server is reached. It should be noted
- that sharing the same fast re-authentication key among several
- servers may have security risks, so changing the realm portion of the
- NAI in order to change the EAP server is not desirable.
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 32]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- Even if the peer uses a fast re-authentication identity, the server
- may want to fall back on full authentication, for example because the
- server does not recognize the fast re-authentication identity or does
- not want to use fast re-authentication. In this case, the server
- starts the full authentication procedure by issuing an
- EAP-Request/SIM/Start packet. This packet always starts a full
- authentication sequence if it does not include the AT_ANY_ID_REQ
- attribute. If the server was not able to recover the peer's identity
- from the fast re-authentication identity, the server includes either
- the AT_FULLAUTH_ID_REQ or the AT_PERMANENT_ID_REQ attribute in this
- EAP request.
-
-5.4. Fast Re-authentication Procedure
-
- Figure 8 illustrates the fast re-authentication procedure. In this
- example, the optional protected success indication is not used.
- Encrypted attributes are denoted with '*'. The peer uses its
- re-authentication identity in the EAP-Response/Identity packet. As
- discussed above, an alternative way to communicate the
- re-authentication identity to the server is for the peer to use the
- AT_IDENTITY attribute in the EAP-Response/SIM/Start message. This
- latter case is not illustrated in the figure below, and it is only
- possible when the server requests that the peer send its identity by
- including the AT_ANY_ID_REQ attribute in the EAP-Request/SIM/Start
- packet.
-
- If the server recognizes the identity as a valid fast
- re-authentication identity, and if the server agrees to use fast
- re-authentication, then the server sends the EAP-Request/SIM/
- Re-authentication packet to the peer. This packet MUST include the
- encrypted AT_COUNTER attribute, with a fresh counter value, the
- encrypted AT_NONCE_S attribute that contains a random number chosen
- by the server, the AT_ENCR_DATA and the AT_IV attributes used for
- encryption, and the AT_MAC attribute that contains a message
- authentication code over the packet. The packet MAY also include an
- encrypted AT_NEXT_REAUTH_ID attribute that contains the next fast
- re-authentication identity.
-
- Fast re-authentication identities are one-time identities. If the
- peer does not receive a new fast re-authentication identity, it MUST
- use either the permanent identity or a pseudonym identity on the next
- authentication to initiate full authentication.
-
- The peer verifies that AT_MAC is correct, and that the counter value
- is fresh (greater than any previously used value). The peer MAY save
- the next fast re-authentication identity from the encrypted
- AT_NEXT_REAUTH_ID for next time. If all checks are successful, the
- peer responds with the EAP-Response/SIM/Re-authentication packet,
-
-
-
-Haverinen & Salowey Informational [Page 33]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- including the AT_COUNTER attribute with the same counter value and
- AT_MAC attribute.
-
- The server verifies the AT_MAC attribute and also verifies that the
- counter value is the same that it used in the EAP-Request/SIM/
- Re-authentication packet. If these checks are successful, the
- re-authentication has succeeded and the server sends the EAP-Success
- packet to the peer.
-
- If protected success indications (Section 6.2) were used, the
- EAP-Success packet would be preceded by an EAP-SIM notification
- round.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 34]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- Peer Authenticator
- | |
- | EAP-Request/Identity |
- |<------------------------------------------------------|
- | |
- | EAP-Response/Identity |
- | (Includes a fast re-authentication identity) |
- |------------------------------------------------------>|
- | |
- | +--------------------------------+
- | | Server recognizes the identity |
- | | and agrees to use fast |
- | | re-authentication |
- | +--------------------------------+
- | |
- : :
- : :
- : :
- : :
- | EAP-Request/SIM/Re-authentication |
- | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, |
- | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) |
- |<------------------------------------------------------|
- | |
- +-----------------------------------------------+ |
- | Peer verifies AT_MAC and the freshness of | |
- | the counter. Peer MAY store the new fast re- | |
- | authentication identity for next re-auth. | |
- +-----------------------------------------------+ |
- | |
- | EAP-Response/SIM/Re-authentication |
- | (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, |
- | AT_MAC) |
- |------------------------------------------------------>|
- | +--------------------------------+
- | | Server verifies AT_MAC and |
- | | the counter |
- | +--------------------------------+
- | |
- | EAP-Success |
- |<------------------------------------------------------|
- | |
-
- Figure 8: Fast Re-authentication
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 35]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-5.5. Fast Re-authentication Procedure when Counter Is Too Small
-
- If the peer does not accept the counter value of EAP-Request/SIM/
- Re-authentication, it indicates the counter synchronization problem
- by including the encrypted AT_COUNTER_TOO_SMALL in EAP-Response/SIM/
- Re-authentication. The server responds with EAP-Request/SIM/Start to
- initiate a normal full authentication procedure. This is illustrated
- in Figure 9. Encrypted attributes are denoted with '*'.
-
- Peer Authenticator
- | EAP-Request/SIM/Start |
- | (AT_ANY_ID_REQ, AT_VERSION_LIST) |
- |<------------------------------------------------------|
- | |
- | EAP-Response/SIM/Start |
- | (AT_IDENTITY) |
- | (Includes a fast re-authentication identity) |
- |------------------------------------------------------>|
- | |
- | EAP-Request/SIM/Re-authentication |
- | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, |
- | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) |
- |<------------------------------------------------------|
- +-----------------------------------------------+ |
- | AT_MAC is valid but the counter is not fresh. | |
- +-----------------------------------------------+ |
- | |
- | EAP-Response/SIM/Re-authentication |
- | (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL, |
- | *AT_COUNTER, AT_MAC) |
- |------------------------------------------------------>|
- | +----------------------------------------------+
- | | Server verifies AT_MAC but detects |
- | | That peer has included AT_COUNTER_TOO_SMALL |
- | +----------------------------------------------+
- | |
- | EAP-Request/SIM/Start |
- | (AT_VERSION_LIST) |
- |<------------------------------------------------------|
- +---------------------------------------------------------------+
- | Normal full authentication follows. |
- +---------------------------------------------------------------+
- | |
-
- Figure 9: Fast Re-authentication, counter is not fresh
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 36]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- In the figure above, the first three messages are similar to the
- basic fast re-authentication case. When the peer detects that the
- counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL
- attribute in EAP-Response/SIM/Re-authentication. This attribute
- doesn't contain any data, but it is a request for the server to
- initiate full authentication. In this case, the peer MUST ignore the
- contents of the server's AT_NEXT_REAUTH_ID attribute.
-
- On receipt of AT_COUNTER_TOO_SMALL, the server verifies AT_MAC and
- verifies that AT_COUNTER contains the same counter value as in the
- EAP-Request/SIM/Re-authentication packet. If not, the server
- terminates the authentication exchange by sending the
- EAP-Request/SIM/Notification with AT_NOTIFICATION code "General
- failure" (16384). If all checks on the packet are successful, the
- server transmits a new EAP-Request/SIM/Start packet and the full
- authentication procedure is performed as usual. Since the server
- already knows the subscriber identity, it MUST NOT include
- AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_PERMANENT_ID_REQ in the
- EAP-Request/SIM/Start.
-
- It should be noted that in this case, peer identity is only
- transmitted in the AT_IDENTITY attribute at the beginning of the
- whole EAP exchange. The fast re-authentication identity used in this
- AT_IDENTITY attribute will be used in key derivation (see Section 7).
-
-6. EAP-SIM Notifications
-
-6.1. General
-
- EAP-SIM does not prohibit the use of the EAP Notifications as
- specified in [RFC3748]. EAP Notifications can be used at any time in
- the EAP-SIM exchange. It should be noted that EAP-SIM does not
- protect EAP Notifications. EAP-SIM also specifies method-specific
- EAP-SIM notifications that are protected in some cases.
-
- The EAP server can use EAP-SIM notifications to convey notifications
- and result indications (Section 6.2) to the peer.
-
- The server MUST use notifications in cases discussed in
- Section 6.3.2. When the EAP server issues an
- EAP-Request/SIM/Notification packet to the peer, the peer MUST
- process the notification packet. The peer MAY show a notification
- message to the user and the peer MUST respond to the EAP server with
- an EAP-Response/SIM/Notification packet, even if the peer did not
- recognize the notification code.
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 37]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- An EAP-SIM full authentication exchange or a fast re-authentication
- exchange MUST NOT include more than one EAP-SIM notification round.
-
- The notification code is a 16-bit number. The most significant bit
- is called the Success bit (S bit). The S bit specifies whether the
- notification implies failure. The code values with the S bit set to
- zero (code values 0...32767) are used on unsuccessful cases. The
- receipt of a notification code from this range implies a failed EAP
- exchange, so the peer can use the notification as a failure
- indication. After receiving the EAP-Response/SIM/Notification for
- these notification codes, the server MUST send the EAP-Failure
- packet.
-
- The receipt of a notification code with the S bit set to one (values
- 32768...65536) does not imply failure. Notification code "Success"
- (32768) has been reserved as a general notification code to indicate
- successful authentication.
-
- The second most significant bit of the notification code is called
- the Phase bit (P bit). It specifies at which phase of the EAP-SIM
- exchange the notification can be used. If the P bit is set to zero,
- the notification can only be used after a successful
- EAP/SIM/Challenge round in full authentication or a successful
- EAP/SIM/Re-authentication round in reauthentication. A
- re-authentication round is considered successful only if the peer has
- successfully verified AT_MAC and AT_COUNTER attributes, and does not
- include the AT_COUNTER_TOO_SMALL attribute in
- EAP-Response/SIM/Re-authentication.
-
- If the P bit is set to one, the notification can only by used before
- the EAP/SIM/Challenge round in full authentication, or before the
- EAP/SIM/Re-authentication round in reauthentication. These
- notifications can only be used to indicate various failure cases. In
- other words, if the P bit is set to one, then the S bit MUST be set
- to zero.
-
- Section 9.8 and Section 9.9 specify what other attributes must be
- included in the notification packets.
-
- Some of the notification codes are authorization related and, hence,
- are not usually considered part of the responsibility of an EAP
- method. However, they are included as part of EAP-SIM because there
- are currently no other ways to convey this information to the user in
- a localizable way, and the information is potentially useful for the
- user. An EAP-SIM server implementation may decide never to send
- these EAP-SIM notifications.
-
-
-
-
-
-Haverinen & Salowey Informational [Page 38]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-6.2. Result Indications
-
- As discussed in Section 6.3, the server and the peer use explicit
- error messages in all error cases. If the server detects an error
- after successful authentication, the server uses an EAP-SIM
- notification to indicate failure to the peer. In this case, the
- result indication is integrity and replay protected.
-
- By sending an EAP-Response/SIM/Challenge packet or an
- EAP-Response/SIM/Re-authentication packet (without
- AT_COUNTER_TOO_SMALL), the peer indicates that it has successfully
- authenticated the server and that the peer's local policy accepts the
- EAP exchange. In other words, these packets are implicit success
- indications from the peer to the server.
-
- EAP-SIM also supports optional protected success indications from the
- server to the peer. If the EAP server wants to use protected success
- indications, it includes the AT_RESULT_IND attribute in the
- EAP-Request/SIM/Challenge or the EAP-Request/SIM/Re-authentication
- packet. This attribute indicates that the EAP server would like to
- use result indications in both successful and unsuccessful cases. If
- the peer also wants this, the peer includes AT_RESULT_IND in
- EAP-Response/SIM/Challenge or EAP-Response/SIM/Re-authentication.
- The peer MUST NOT include AT_RESULT_IND if it did not receive
- AT_RESULT_IND from the server. If both the peer and the server used
- AT_RESULT_IND, then the EAP exchange is not complete yet, but an
- EAP-SIM notification round will follow. The following EAP-SIM
- notification may indicate either failure or success.
-
- Success indications with the AT_NOTIFICATION code "Success" (32768)
- can only be used if both the server and the peer indicate they want
- to use them with AT_RESULT_IND. If the server did not include
- AT_RESULT_IND in the EAP-Request/SIM/Challenge or
- EAP-Request/SIM/Re-authentication packet, or if the peer did not
- include AT_RESULT_IND in the corresponding response packet, then the
- server MUST NOT use protected success indications.
-
- Because the server uses the AT_NOTIFICATION code "Success" (32768) to
- indicate that the EAP exchange has completed successfully, the EAP
- exchange cannot fail when the server processes the EAP-SIM response
- to this notification. Hence, the server MUST ignore the contents of
- the EAP-SIM response it receives from the
- EAP-Request/SIM/Notification with this code. Regardless of the
- contents of the EAP-SIM response, the server MUST send EAP-Success as
- the next packet.
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 39]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-6.3. Error Cases
-
- This section specifies the operation of the peer and the server in
- error cases. The subsections below require the EAP-SIM peer and
- server to send an error packet (EAP-Response/SIM/Client-Error from
- the peer or EAP-Request/SIM/Notification from the server) in error
- cases. However, implementations SHOULD NOT rely upon the correct
- error reporting behavior of the peer, authenticator, or the server.
- It is possible for error and other messages to be lost in transit or
- for a malicious participant to attempt to consume resources by not
- issuing error messages. Both the peer and the EAP server SHOULD have
- a mechanism to clean up state, even if an error message or
- EAP-Success is not received after a timeout period.
-
-6.3.1. Peer Operation
-
- In general, if an EAP-SIM peer detects an error in a received EAP-SIM
- packet, the EAP-SIM implementation responds with the
- EAP-Response/SIM/Client-Error packet. In response to the
- EAP-Response/SIM/Client-Error, the EAP server MUST issue the
- EAP-Failure packet and the authentication exchange terminates.
-
- By default, the peer uses the client error code 0, "unable to process
- packet". This error code is used in the following cases:
-
- o EAP exchange is not acceptable according to the peer's local
- policy.
-
- o the peer is not able to parse the EAP request, i.e., the EAP
- request is malformed.
-
- o the peer encountered a malformed attribute.
-
- o wrong attribute types or duplicate attributes have been included
- in the EAP request.
-
- o a mandatory attribute is missing.
-
- o unrecognized, non-skippable attribute.
-
- o unrecognized or unexpected EAP-SIM Subtype in the EAP request.
-
- o A RAND challenge repeated in AT_RAND.
-
- o invalid AT_MAC. The peer SHOULD log this event.
-
- o invalid pad bytes in AT_PADDING.
-
-
-
-
-Haverinen & Salowey Informational [Page 40]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- o the peer does not want to process AT_PERMANENT_ID_REQ.
-
- Separate error codes have been defined for the following error cases
- in Section 10.19:
-
- As specified in Section 4.1, when processing the AT_VERSION_LIST
- attribute, which lists the EAP-SIM versions supported by the server,
- if the attribute does not include a version that is implemented by
- the peer and allowed in the peer's security policy, then the peer
- MUST send the EAP-Response/SIM/Client-Error packet with the error
- code "unsupported version".
-
- If the number of RAND challenges is smaller than what is required by
- peer's local policy when processing the AT_RAND attribute, the peer
- MUST send the EAP-Response/SIM/Client-Error packet with the error
- code "insufficient number of challenges".
-
- If the peer believes that the RAND challenges included in AT_RAND are
- not fresh e.g., because it is capable of remembering some previously
- used RANDs, the peer MUST send the EAP-Response/SIM/Client-Error
- packet with the error code "RANDs are not fresh".
-
-6.3.2. Server Operation
-
- If an EAP-SIM server detects an error in a received EAP-SIM response,
- the server MUST issue the EAP-Request/SIM/Notification packet with an
- AT_NOTIFICATION code that implies failure. By default, the server
- uses one of the general failure codes ("General failure after
- authentication" (0), or "General failure" (16384)). The choice
- between these two codes depends on the phase of the EAP-SIM exchange,
- see Section 6. When the server issues an EAP-
- Request/SIM/Notification that implies failure, the error cases
- include the following:
-
- o the server is not able to parse the peer's EAP response
-
- o the server encounters a malformed attribute, a non-recognized
- non-skippable attribute, or a duplicate attribute
-
- o a mandatory attribute is missing or an invalid attribute was
- included
-
- o unrecognized or unexpected EAP-SIM Subtype in the EAP Response
-
- o invalid AT_MAC. The server SHOULD log this event.
-
- o invalid AT_COUNTER
-
-
-
-
-Haverinen & Salowey Informational [Page 41]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-6.3.3. EAP-Failure
-
- The EAP-SIM server sends EAP-Failure in two cases:
-
- 1) In response to an EAP-Response/SIM/Client-Error packet the server
- has received from the peer, or
-
- 2) Following an EAP-SIM notification round, when the AT_NOTIFICATION
- code implies failure.
-
- The EAP-SIM server MUST NOT send EAP-Failure in cases other than
- these two. However, it should be noted that even though the EAP-SIM
- server would not send an EAP-Failure, an authorization decision that
- happens outside EAP-SIM, such as in the AAA server or in an
- intermediate AAA proxy, may result in a failed exchange.
-
- The peer MUST accept the EAP-Failure packet in case 1) and case 2),
- above. The peer SHOULD silently discard the EAP-Failure packet in
- other cases.
-
-6.3.4. EAP-Success
-
- On full authentication, the server can only send EAP-Success after
- the EAP/SIM/Challenge round. The peer MUST silently discard any
- EAP-Success packets if they are received before the peer has
- successfully authenticated the server and sent the
- EAP-Response/SIM/Challenge packet.
-
- If the peer did not indicate that it wants to use protected success
- indications with AT_RESULT_IND (as discussed in Section 6.2) on full
- authentication, then the peer MUST accept EAP-Success after a
- successful EAP/SIM/Challenge round.
-
- If the peer indicated that it wants to use protected success
- indications with AT_RESULT_IND (as discussed in Section 6.2), then
- the peer MUST NOT accept EAP-Success after a successful
- EAP/SIM/Challenge round. In this case, the peer MUST only accept
- EAP-Success after receiving an EAP-SIM Notification with the
- AT_NOTIFICATION code "Success" (32768).
-
- On fast re-authentication, EAP-Success can only be sent after the
- EAP/SIM/Re-authentication round. The peer MUST silently discard any
- EAP-Success packets if they are received before the peer has
- successfully authenticated the server and sent the
- EAP-Response/SIM/Re-authentication packet.
-
- If the peer did not indicate that it wants to use protected success
- indications with AT_RESULT_IND (as discussed in Section 6.2) on fast
-
-
-
-Haverinen & Salowey Informational [Page 42]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- re-authentication, then the peer MUST accept EAP-Success after a
- successful EAP/SIM/Re-authentication round.
-
- If the peer indicated that it wants to use protected success
- indications with AT_RESULT_IND (as discussed in Section 6.2), then
- the peer MUST NOT accept EAP-Success after a successful EAP/SIM/Re-
- authentication round. In this case, the peer MUST only accept
- EAP-Success after receiving an EAP-SIM Notification with the
- AT_NOTIFICATION code "Success" (32768).
-
- If the peer receives an EAP-SIM notification (Section 6) that
- indicates failure, then the peer MUST no longer accept the
- EAP-Success packet, even if the server authentication was
- successfully completed.
-
-7. Key Generation
-
- This section specifies how keying material is generated.
-
- On EAP-SIM full authentication, a Master Key (MK) is derived from the
- underlying GSM authentication values (Kc keys), the NONCE_MT, and
- other relevant context as follows.
-
- MK = SHA1(Identity|n*Kc| NONCE_MT| Version List| Selected Version)
-
- In the formula above, the "|" character denotes concatenation.
- "Identity" denotes the peer identity string without any terminating
- null characters. It is the identity from the last AT_IDENTITY
- attribute sent by the peer in this exchange, or, if AT_IDENTITY was
- not used, it is the identity from the EAP-Response/Identity packet.
- The identity string is included as-is, without any changes. As
- discussed in Section 4.2.2.2, relying on EAP-Response/Identity for
- conveying the EAP-SIM peer identity is discouraged, and the server
- SHOULD use the EAP-SIM method-specific identity attributes.
-
- The notation n*Kc in the formula above denotes the n Kc values
- concatenated. The Kc keys are used in the same order as the RAND
- challenges in AT_RAND attribute. NONCE_MT denotes the NONCE_MT value
- (not the AT_NONCE_MT attribute, but only the nonce value). The
- Version List includes the 2-byte-supported version numbers from
- AT_VERSION_LIST, in the same order as in the attribute. The Selected
- Version is the 2-byte selected version from AT_SELECTED_VERSION.
- Network byte order is used, just as in the attributes. The hash
- function SHA-1 is specified in [SHA-1]. If several EAP/SIM/Start
- roundtrips are used in an EAP-SIM exchange, then the NONCE_MT,
- Version List and Selected version from the last EAP/SIM/Start round
- are used, and the previous EAP/SIM/Start rounds are ignored.
-
-
-
-
-Haverinen & Salowey Informational [Page 43]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- The Master Key is fed into a Pseudo-Random number Function (PRF)
- which generates separate Transient EAP Keys (TEKs) for protecting
- EAP-SIM packets, as well as a Master Session Key (MSK) for link layer
- security, and an Extended Master Session Key (EMSK) for other
- purposes. On fast re-authentication, the same TEKs MUST be used for
- protecting EAP packets, but a new MSK and a new EMSK MUST be derived
- from the original MK and from new values exchanged in the fast
- re-authentication.
-
- EAP-SIM requires two TEKs for its own purposes; the authentication
- key K_aut is to be used with the AT_MAC attribute, and the encryption
- key K_encr is to be used with the AT_ENCR_DATA attribute. The same
- K_aut and K_encr keys are used in full authentication and subsequent
- fast re-authentications.
-
- Key derivation is based on the random number generation specified in
- NIST Federal Information Processing Standards (FIPS) Publication
- 186-2 [PRF]. The pseudo-random number generator is specified in the
- change notice 1 (2001 October 5) of [PRF] (Algorithm 1). As
- specified in the change notice (page 74), when Algorithm 1 is used as
- a general-purpose pseudo-random number generator, the "mod q" term in
- step 3.3 is omitted. The function G used in the algorithm is
- constructed via the Secure Hash Standard, as specified in Appendix
- 3.3 of the standard. It should be noted that the function G is very
- similar to SHA-1, but the message padding is different. Please refer
- to [PRF] for full details. For convenience, the random number
- algorithm with the correct modification is cited in Appendix B.
-
- 160-bit XKEY and XVAL values are used, so b = 160. On each full
- authentication, the Master Key is used as the initial secret seed-key
- XKEY. The optional user input values (XSEED_j) in step 3.1 are set
- to zero.
-
- On full authentication, the resulting 320-bit random numbers (x_0,
- x_1, ..., x_m-1) are concatenated and partitioned into suitable-sized
- chunks and used as keys in the following order: K_encr (128 bits),
- K_aut (128 bits), Master Session Key (64 bytes), Extended Master
- Session Key (64 bytes).
-
- On fast re-authentication, the same pseudo-random number generator
- can be used to generate a new Master Session Key and a new Extended
- Master Session Key. The seed value XKEY' is calculated as follows:
-
- XKEY' = SHA1(Identity|counter|NONCE_S| MK)
-
- In the formula above, the Identity denotes the fast re-authentication
- identity, without any terminating null characters, from the
- AT_IDENTITY attribute of the EAP-Response/SIM/Start packet, or, if
-
-
-
-Haverinen & Salowey Informational [Page 44]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- EAP-Response/SIM/Start was not used on fast re-authentication, it
- denotes the identity string from the EAP-Response/Identity packet.
- The counter denotes the counter value from the AT_COUNTER attribute
- used in the EAP-Response/SIM/Re-authentication packet. The counter
- is used in network byte order. NONCE_S denotes the 16-byte NONCE_S
- value from the AT_NONCE_S attribute used in the
- EAP-Request/SIM/Re-authentication packet. The MK is the Master Key
- derived on the preceding full authentication.
-
- On fast re-authentication, the pseudo-random number generator is run
- with the new seed value XKEY', and the resulting 320-bit random
- numbers (x_0, x_1, ..., x_m-1) are concatenated and partitioned into
- two 64-byte chunks and used as the new 64-byte Master Session Key and
- the new 64-byte Extended Master Session Key. Note that because
- K_encr and K_aut are not derived on fast re-authentication, the
- Master Session Key and the Extended Master Session key are obtained
- from the beginning of the key stream (x_0, x_1, ...).
-
- The first 32 bytes of the MSK can be used as the Pairwise Master Key
- (PMK) for IEEE 802.11i.
-
- When the RADIUS attributes specified in [RFC2548] are used to
- transport keying material, then the first 32 bytes of the MSK
- correspond to MS-MPPE-RECV-KEY and the second 32 bytes to
- MS-MPPE-SEND-KEY. In this case, only 64 bytes of keying material
- (the MSK) are used.
-
- When generating the initial Master Key, the hash function is used as
- a mixing function to combine several session keys (Kc's) generated by
- the GSM authentication procedure and the random number NONCE_MT into
- a single session key. There are several reasons for this. The
- current GSM session keys are, at most, 64 bits, so two or more of
- them are needed to generate a longer key. By using a one-way
- function to combine the keys, we are assured that, even if an
- attacker managed to learn one of the EAP-SIM session keys, it
- wouldn't help him in learning the original GSM Kc's. In addition,
- since we include the random number NONCE_MT in the calculation, the
- peer is able to verify that the EAP-SIM packets it receives from the
- network are fresh and not replays (also see Section 11).
-
-8. Message Format and Protocol Extensibility
-
-8.1. Message Format
-
- As specified in [RFC3748], EAP packets begin with the Code,
- Identifiers, Length, and Type fields, which are followed by EAP-
- method-specific Type-Data. The Code field in the EAP header is set
- to 1 for EAP requests, and to 2 for EAP Responses. The usage of the
-
-
-
-Haverinen & Salowey Informational [Page 45]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- Length and Identifier fields in the EAP header are also specified in
- [RFC3748]. In EAP-SIM, the Type field is set to 18.
-
- In EAP-SIM, the Type-Data begins with an EAP-SIM header that consists
- of a 1-octet Subtype field and a 2-octet reserved field. The Subtype
- values used in EAP-SIM are defined in the IANA considerations section
- of the EAP-AKA specification [EAP-AKA]. The formats of the EAP
- header and the EAP-SIM header are shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Subtype | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The rest of the Type-Data that immediately follows the EAP-SIM header
- consists of attributes that are encoded in Type, Length, Value
- format. The figure below shows the generic format of an attribute.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Length | Value...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
- Attribute Type
-
- Indicates the particular type of attribute. The attribute type
- values are listed in the IANA considerations section of the
- EAP-AKA specification [EAP-AKA].
-
- Length
-
- Indicates the length of this attribute in multiples of four
- bytes. The maximum length of an attribute is 1024 bytes. The
- length includes the Attribute Type and Length bytes.
-
- Value
-
- The particular data associated with this attribute. This field
- is always included and it may be two or more bytes in length.
- The type and length fields determine the format and length
- of the value field.
-
-
-
-
-
-Haverinen & Salowey Informational [Page 46]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- Attributes numbered within the range 0 through 127 are called
- non-skippable attributes. When an EAP-SIM peer encounters a
- non-skippable attribute that the peer does not recognize, the peer
- MUST send the EAP-Response/SIM/Client-Error packet, which terminates
- the authentication exchange. If an EAP-SIM server encounters a
- non-skippable attribute that the server does not recognize, then the
- server sends the EAP-Request/SIM/Notification packet with an
- AT_NOTIFICATION code, which implies general failure ("General failure
- after authentication" (0), or "General failure" (16384), depending on
- the phase of the exchange), which terminates the authentication
- exchange.
-
- Attributes within the range of 128 through 255 are called skippable
- attributes. When a skippable attribute is encountered and is not
- recognized, it is ignored. The rest of the attributes and message
- data MUST still be processed. The Length field of the attribute is
- used to skip the attribute value in searching for the next attribute.
-
- Unless otherwise specified, the order of the attributes in an EAP-SIM
- message is insignificant and an EAP-SIM implementation should not
- assume a certain order to be used.
-
- Attributes can be encapsulated within other attributes. In other
- words, the value field of an attribute type can be specified to
- contain other attributes.
-
-8.2. Protocol Extensibility
-
- EAP-SIM can be extended by specifying new attribute types. If
- skippable attributes are used, it is possible to extend the protocol
- without breaking old implementations.
-
- However, any new attributes added to the EAP-Request/SIM/Start or
- EAP-Response/SIM/Start packets would not be integrity-protected.
- Therefore, these messages MUST NOT be extended in the current version
- of EAP-SIM. If the list of supported EAP-SIM versions in the
- AT_VERSION_LIST does not include versions other than 1, then the
- server MUST NOT include attributes other than those specified in this
- document in the EAP-Request/SIM/Start message. Note that future
- versions of this protocol might specify new attributes for
- EAP-Request/SIM/Start and still support version 1 of the protocol.
- In this case, the server might send an EAP-Request/SIM/Start message
- that includes new attributes and indicates support for protocol
- version 1 and other versions in the AT_VERSION_LIST attribute. If
- the peer selects version 1, then the peer MUST ignore any other
- attributes included in EAP-Request/SIM/Start, other than those
- specified in this document. If the selected EAP-SIM version in
- peer's AT_SELECTED_VERSION is 1, then the peer MUST NOT include other
-
-
-
-Haverinen & Salowey Informational [Page 47]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- attributes aside from those specified in this document in the
- EAP-Response/SIM/Start message.
-
- When specifying new attributes, it should be noted that EAP-SIM does
- not support message fragmentation. Hence, the sizes of the new
- extensions MUST be limited so that the maximum transfer unit (MTU) of
- the underlying lower layer is not exceeded. According to [RFC3748],
- lower layers must provide an EAP MTU of 1020 bytes or greater, so any
- extensions to EAP-SIM SHOULD NOT exceed the EAP MTU of 1020 bytes.
-
- Because EAP-SIM supports version negotiation, new versions of the
- protocol can also be specified by using a new version number.
-
-9. Messages
-
- This section specifies the messages used in EAP-SIM. It specifies
- when a message may be transmitted or accepted, which attributes are
- allowed in a message, which attributes are required in a message, and
- other message-specific details. The general message format is
- specified in Section 8.1.
-
-9.1. EAP-Request/SIM/Start
-
- In full authentication the first SIM-specific EAP Request is
- EAP-Request/SIM/Start. The EAP/SIM/Start roundtrip is used for two
- purposes. In full authentication this packet is used to request the
- peer to send the AT_NONCE_MT attribute to the server. In addition,
- as specified in Section 4.2, the Start round trip may be used by the
- server for obtaining the peer identity. As discussed in Section 4.2,
- several Start rounds may be required to obtain a valid peer identity.
-
- The server MUST always include the AT_VERSION_LIST attribute.
-
- The server MAY include one of the following identity-requesting
- attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or
- AT_ANY_ID_REQ. These three attributes are mutually exclusive, so the
- server MUST NOT include more than one of the attributes.
-
- If the server has received a response from the peer, it MUST NOT
- issue a new EAP-Request/SIM/Start packet if it has previously issued
- an EAP-Request/SIM/Start message either without any identity
- requesting attributes or with the AT_PERMANENT_ID_REQ attribute.
-
- If the server has received a response from the peer, it MUST NOT
- issue a new EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ or
- AT_FULLAUTH_ID_REQ attributes if it has previously issued an
- EAP-Request/SIM/Start message with the AT_FULLAUTH_ID_REQ attribute.
-
-
-
-
-Haverinen & Salowey Informational [Page 48]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- If the server has received a response from the peer, it MUST NOT
- issue a new EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ
- attribute if the server has previously issued an
- EAP-Request/SIM/Start message with the AT_ANY_ID_REQ attribute.
-
- This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.
-
-9.2. EAP-Response/SIM/Start
-
- The peer sends EAP-Response/SIM/Start in response to a valid
- EAP-Request/SIM/Start from the server.
-
- If and only if the server's EAP-Request/SIM/Start includes one of the
- identity-requesting attributes, then the peer MUST include the
- AT_IDENTITY attribute. The usage of AT_IDENTITY is defined in
- Section 4.2.
-
- The AT_NONCE_MT attribute MUST NOT be included if the AT_IDENTITY
- with a fast re-authentication identity is present for fast
- re-authentication. AT_NONCE_MT MUST be included in all other cases
- (full authentication).
-
- The AT_SELECTED_VERSION attribute MUST NOT be included if the
- AT_IDENTITY attribute with a fast re-authentication identity is
- present for fast re-authentication. In all other cases,
- AT_SELECTED_VERSION MUST be included (full authentication). This
- attribute is used in version negotiation, as specified in
- Section 4.1.
-
- This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.
-
-9.3. EAP-Request/SIM/Challenge
-
- The server sends the EAP-Request/SIM/Challenge after receiving a
- valid EAP-Response/SIM/Start that contains AT_NONCE_MT and
- AT_SELECTED_VERSION, and after successfully obtaining the subscriber
- identity.
-
- The AT_RAND attribute MUST be included.
-
- The AT_RESULT_IND attribute MAY be included. The usage of this
- attribute is discussed in Section 6.2.
-
- The AT_MAC attribute MUST be included. For
- EAP-Request/SIM/Challenge, the MAC code is calculated over the
- following data:
-
- EAP packet| NONCE_MT
-
-
-
-Haverinen & Salowey Informational [Page 49]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- The EAP packet is represented as specified in Section 8.1. It is
- followed by the 16-byte NONCE_MT value from the peer's AT_NONCE_MT
- attribute.
-
- The EAP-Request/SIM/Challenge packet MAY include encrypted attributes
- for identity privacy and for communicating the next fast
- re-authentication identity. In this case, the AT_IV and AT_ENCR_DATA
- attributes are included (Section 10.12).
-
- The plaintext of the AT_ENCR_DATA value field consists of nested
- attributes. The nested attributes MAY include AT_PADDING (as
- specified in Section 10.12). If the server supports identity privacy
- and wants to communicate a pseudonym to the peer for the next full
- authentication, then the nested encrypted attributes include the
- AT_NEXT_PSEUDONYM attribute. If the server supports
- re-authentication and wants to communicate a fast re-authentication
- identity to the peer, then the nested encrypted attributes include
- the AT_NEXT_REAUTH_ID attribute.
-
- When processing this message, the peer MUST process AT_RAND before
- processing other attributes. Only if AT_RAND is verified to be
- valid, the peer derives keys and verifies AT_MAC. The operation in
- case an error occurs is specified in Section 6.3.1.
-
-9.4. EAP-Response/SIM/Challenge
-
- The peer sends EAP-Response/SIM/Challenge in response to a valid
- EAP-Request/SIM/Challenge.
-
- Sending this packet indicates that the peer has successfully
- authenticated the server and that the EAP exchange will be accepted
- by the peer's local policy. Hence, if these conditions are not met,
- then the peer MUST NOT send EAP-Response/SIM/Challenge, but the peer
- MUST send EAP-Response/SIM/Client-Error.
-
- The AT_MAC attribute MUST be included. For EAP-
- Response/SIM/Challenge, the MAC code is calculated over the following
- data:
-
- EAP packet| n*SRES
-
- The EAP packet is represented as specified in Section 8.1. The EAP
- packet bytes are immediately followed by the two or three SRES values
- concatenated, denoted above with the notation n*SRES. The SRES
- values are used in the same order as the corresponding RAND
- challenges in the server's AT_RAND attribute.
-
-
-
-
-
-Haverinen & Salowey Informational [Page 50]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- The AT_RESULT_IND attribute MAY be included if it was included in
- EAP-Request/SIM/Challenge. The usage of this attribute is discussed
- in Section 6.2.
-
- Later versions of this protocol MAY make use of the AT_ENCR_DATA and
- AT_IV attributes in this message to include encrypted (skippable)
- attributes. The EAP server MUST process EAP-Response/SIM/Challenge
- messages that include these attributes even if the server did not
- implement these optional attributes.
-
-9.5. EAP-Request/SIM/Re-authentication
-
- The server sends the EAP-Request/SIM/Re-authentication message if it
- wants to use fast re-authentication, and if it has received a valid
- fast re-authentication identity in EAP-Response/Identity or
- EAP-Response/SIM/Start.
-
- AT_MAC MUST be included. No message-specific data is included in the
- MAC calculation. See Section 10.14.
-
- The AT_RESULT_IND attribute MAY be included. The usage of this
- attribute is discussed in Section 6.2.
-
- The AT_IV and AT_ENCR_DATA attributes MUST be included. The
- plaintext consists of the following nested encrypted attributes,
- which MUST be included: AT_COUNTER and AT_NONCE_S. In addition, the
- nested encrypted attributes MAY include the following attributes:
- AT_NEXT_REAUTH_ID and AT_PADDING.
-
-9.6. EAP-Response/SIM/Re-authentication
-
- The client sends the EAP-Response/SIM/Re-authentication packet in
- response to a valid EAP-Request/SIM/Re-authentication.
-
- The AT_MAC attribute MUST be included. For
- EAP-Response/SIM/Re-authentication, the MAC code is calculated over
- the following data:
-
- EAP packet| NONCE_S
-
- The EAP packet is represented as specified in Section 8.1. It is
- followed by the 16-byte NONCE_S value from the server's AT_NONCE_S
- attribute.
-
- The AT_IV and AT_ENCR_DATA attributes MUST be included. The nested
- encrypted attributes MUST include the AT_COUNTER attribute. The
- AT_COUNTER_TOO_SMALL attribute MAY be included in the nested
-
-
-
-
-Haverinen & Salowey Informational [Page 51]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- encrypted attributes, and it is included in cases specified in
- Section 5. The AT_PADDING attribute MAY be included.
-
- The AT_RESULT_IND attribute MAY be included if it was included in
- EAP-Request/SIM/Re-authentication. The usage of this attribute is
- discussed in Section 6.2.
-
- Sending this packet without AT_COUNTER_TOO_SMALL indicates that the
- peer has successfully authenticated the server and that the EAP
- exchange will be accepted by the peer's local policy. Hence, if
- these conditions are not met, then the peer MUST NOT send
- EAP-Response/SIM/Re-authentication, but the peer MUST send
- EAP-Response/SIM/Client-Error.
-
-9.7. EAP-Response/SIM/Client-Error
-
- The peer sends EAP-Response/SIM/Client-Error in error cases, as
- specified in Section 6.3.1.
-
- The AT_CLIENT_ERROR_CODE attribute MUST be included.
-
- The AT_MAC, AT_IV, or AT_ENCR_DATA attributes MUST NOT be used with
- this packet.
-
-9.8. EAP-Request/SIM/Notification
-
- The usage of this message is specified in Section 6. The
- AT_NOTIFICATION attribute MUST be included.
-
- The AT_MAC attribute MUST be included if the P bit of the
- notification code in AT_NOTIFICATION is set to zero, and MUST NOT be
- included in cases when the P bit is set to one. The P bit is
- discussed in Section 6.
-
- No message-specific data is included in the MAC calculation. See
- Section 10.14.
-
- If EAP-Request/SIM/Notification is used on a fast re-authentication
- exchange, and if the P bit in AT_NOTIFICATION is set to zero, then
- AT_COUNTER is used for replay protection. In this case, the
- AT_ENCR_DATA and AT_IV attributes MUST be included, and the
- encapsulated plaintext attributes MUST include the AT_COUNTER
- attribute. The counter value included in AT_COUNTER MUST be the same
- as in the EAP-Request/SIM/Re-authentication packet on the same fast
- re-authentication exchange.
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 52]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-9.9. EAP-Response/SIM/Notification
-
- The usage of this message is specified in Section 6. This packet is
- an acknowledgement of EAP-Request/SIM/Notification.
-
- The AT_MAC attribute MUST be included in cases when the P bit of the
- notification code in AT_NOTIFICATION of EAP-Request/SIM/Notification
- is set to zero, and MUST NOT be included in cases when the P bit is
- set to one. The P bit is discussed in Section 6.
-
- No message-specific data is included in the MAC calculation, see
- Section 10.14.
-
- If EAP-Request/SIM/Notification is used on a fast re-authentication
- exchange, and if the P bit in AT_NOTIFICATION is set to zero, then
- AT_COUNTER is used for replay protection. In this case, the
- AT_ENCR_DATA and AT_IV attributes MUST be included, and the
- encapsulated plaintext attributes MUST include the AT_COUNTER
- attribute. The counter value included in AT_COUNTER MUST be the same
- as in the EAP-Request/SIM/Re-authentication packet on the same fast
- re-authentication exchange.
-
-10. Attributes
-
- This section specifies the format of message attributes. The
- attribute type numbers are specified in the IANA considerations
- section of the EAP-AKA specification [EAP-AKA].
-
-10.1. Table of Attributes
-
- The following table provides a guide to which attributes may be found
- in which kinds of messages, and in what quantity. Messages are
- denoted with numbers in parentheses as follows: (1)
- EAP-Request/SIM/Start, (2) EAP-Response/SIM/Start, (3)
- EAP-Request/SIM/Challenge, (4) EAP-Response/SIM/Challenge, (5)
- EAP-Request/SIM/Notification, (6) EAP-Response/SIM/Notification, (7)
- EAP-Response/SIM/Client-Error, (8) EAP-Request/SIM/Re-authentication,
- and (9) EAP-Response/SIM/Re-authentication. The column denoted with
- "Encr" indicates whether the attribute is a nested attribute that
- MUST be included within AT_ENCR_DATA, and the column denoted with
- "Skip" indicates whether the attribute is a skippable attribute.
-
- "0" indicates that the attribute MUST NOT be included in the message,
- "1" indicates that the attribute MUST be included in the message,
- "0-1" indicates that the attribute is sometimes included in the
- message, and "0*" indicates that the attribute is not included in the
- message in cases specified in this document, but MAY be included in
- future versions of the protocol.
-
-
-
-Haverinen & Salowey Informational [Page 53]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) Encr Skip
- AT_VERSION_LIST 1 0 0 0 0 0 0 0 0 N N
- AT_SELECTED_VERSION 0 0-1 0 0 0 0 0 0 0 N N
- AT_NONCE_MT 0 0-1 0 0 0 0 0 0 0 N N
- AT_PERMANENT_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N
- AT_ANY_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N
- AT_FULLAUTH_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N
- AT_IDENTITY 0 0-1 0 0 0 0 0 0 0 N N
- AT_RAND 0 0 1 0 0 0 0 0 0 N N
- AT_NEXT_PSEUDONYM 0 0 0-1 0 0 0 0 0 0 Y Y
- AT_NEXT_REAUTH_ID 0 0 0-1 0 0 0 0 0-1 0 Y Y
- AT_IV 0 0 0-1 0* 0-1 0-1 0 1 1 N Y
- AT_ENCR_DATA 0 0 0-1 0* 0-1 0-1 0 1 1 N Y
- AT_PADDING 0 0 0-1 0* 0-1 0-1 0 0-1 0-1 Y N
- AT_RESULT_IND 0 0 0-1 0-1 0 0 0 0-1 0-1 N Y
- AT_MAC 0 0 1 1 0-1 0-1 0 1 1 N N
- AT_COUNTER 0 0 0 0 0-1 0-1 0 1 1 Y N
- AT_COUNTER_TOO_SMALL 0 0 0 0 0 0 0 0 0-1 Y N
- AT_NONCE_S 0 0 0 0 0 0 0 1 0 Y N
- AT_NOTIFICATION 0 0 0 0 1 0 0 0 0 N N
- AT_CLIENT_ERROR_CODE 0 0 0 0 0 0 1 0 0 N N
-
- It should be noted that attributes AT_PERMANENT_ID_REQ,
- AT_ANY_ID_REQ, and AT_FULLAUTH_ID_REQ are mutually exclusive; only
- one of them can be included at the same time. If one of the
- attributes AT_IV and AT_ENCR_DATA is included, then both of the
- attributes MUST be included.
-
-10.2. AT_VERSION_LIST
-
- The format of the AT_VERSION_LIST attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_VERSION_L..| Length | Actual Version List Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Supported Version 1 | Supported Version 2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- . .
- . .
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Supported Version N | Padding |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- This attribute is used in version negotiation, as specified in
- Section 4.1. The attribute contains the version numbers supported by
- the EAP-SIM server. The server MUST only include versions that it
-
-
-
-Haverinen & Salowey Informational [Page 54]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- implements and that are allowed in its security policy. The server
- SHOULD list the versions in the order of preference, with the most
- preferred versions listed first. At least one version number MUST be
- included. The version number for the protocol described in this
- document is one (0001 hexadecimal).
-
- The value field of this attribute begins with 2-byte Actual Version
- List Length, which specifies the length of the Version List in bytes,
- not including the Actual Version List Length attribute length. This
- field is followed by the list of the versions supported by the
- server, which each have a length of 2 bytes. For example, if there
- is only one supported version, then the Actual Version List Length is
- 2. Because the length of the attribute must be a multiple of 4
- bytes, the sender pads the value field with zero bytes when
- necessary.
-
-10.3. AT_SELECTED_VERSION
-
- The format of the AT_SELECTED_VERSION attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_SELECTED...| Length = 1 | Selected Version |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- This attribute is used in version negotiation, as specified in
- Section 4.1. The value field of this attribute contains a two-byte
- version number, which indicates the EAP-SIM version that the peer
- wants to use.
-
-10.4. AT_NONCE_MT
-
- The format of the AT_NONCE_MT attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |AT_NONCE_MT | Length = 5 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | NONCE_MT |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 55]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- The value field of the NONCE_MT attribute contains two reserved bytes
- followed by a random number freshly generated by the peer (16 bytes
- long) for this EAP-SIM authentication exchange. The random number is
- used as a seed value for the new keying material. The reserved bytes
- are set to zero upon sending and ignored upon reception.
-
- The peer MUST NOT re-use the NONCE_MT value from a previous EAP-SIM
- authentication exchange. If an EAP-SIM exchange includes several
- EAP/SIM/Start rounds, then the peer SHOULD use the same NONCE_MT
- value in all EAP-Response/SIM/Start packets. The peer SHOULD use a
- good source of randomness to generate NONCE_MT. Please see [RFC4086]
- for more information about generating random numbers for security
- applications.
-
-10.5. AT_PERMANENT_ID_REQ
-
- The format of the AT_PERMANENT_ID_REQ attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |AT_PERM..._REQ | Length = 1 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The use of the AT_PERMANENT_ID_REQ is defined in Section 4.2. The
- value field contains only two reserved bytes, which are set to zero
- on sending and ignored on reception.
-
-10.6. AT_ANY_ID_REQ
-
- The format of the AT_ANY_ID_REQ attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |AT_ANY_ID_REQ | Length = 1 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The use of the AT_ANY_ID_REQ is defined in Section 4.2. The value
- field contains only two reserved bytes, which are set to zero on
- sending and ignored on reception.
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 56]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-10.7. AT_FULLAUTH_ID_REQ
-
- The format of the AT_FULLAUTH_ID_REQ attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |AT_FULLAUTH_...| Length = 1 | Reserved |
- +---------------+---------------+-------------------------------+
-
- The use of the AT_FULLAUTH_ID_REQ is defined in Section 4.2. The
- value field contains only two reserved bytes, which are set to zero
- on sending and ignored on reception.
-
-10.8. AT_IDENTITY
-
- The format of the AT_IDENTITY attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_IDENTITY | Length | Actual Identity Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- . Identity (optional) .
- . .
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The use of the AT_IDENTITY is defined in Section 4.2. The value
- field of this attribute begins with a 2-byte actual identity length,
- which specifies the length of the identity in bytes. This field is
- followed by the subscriber identity of the indicated actual length.
- The identity is the permanent identity, a pseudonym identity, or a
- fast re-authentication identity. The identity format is specified in
- Section 4.2.1. The same identity format is used in the AT_IDENTITY
- attribute and the EAP-Response/Identity packet, with the exception
- that the peer MUST NOT decorate the identity it includes in
- AT_IDENTITY. The identity does not include any terminating null
- characters. Because the length of the attribute must be a multiple
- of 4 bytes, the sender pads the identity with zero bytes when
- necessary.
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 57]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-10.9. AT_RAND
-
- The format of the AT_RAND attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_RAND | Length | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- . n*RAND .
- . .
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of this attribute contains two reserved bytes
- followed by n GSM RANDs, each 16 bytes long. The value of n can be
- determined by the attribute length. The reserved bytes are set to
- zero upon sending and ignored upon reception.
-
- The number of RAND challenges (n) MUST be two or three. The peer
- MUST verify that the number of RAND challenges is sufficient
- according to the peer's policy. The server MUST use different RAND
- values. In other words, a RAND value can only be included once in
- AT_RAND. When processing the AT_RAND attribute, the peer MUST check
- that the RANDs are different.
-
- The EAP server MUST obtain fresh RANDs for each EAP-SIM full
- authentication exchange. More specifically, the server MUST consider
- RANDs it included in AT_RAND to be consumed if the server receives an
- EAP-Response/SIM/Challenge packet with a valid AT_MAC, or an
- EAP-Response/SIM/Client-Error with the code "insufficient number of
- challenges" or "RANDs are not fresh". However, in other cases (if
- the server does not receive a response to its
- EAP-Request/SIM/Challenge packet, or if the server receives a
- response other than the cases listed above), the server does not need
- to consider the RANDs to be consumed, and the server MAY re-use the
- RANDs in the AT_RAND attribute of the next full authentication
- attempt.
-
-
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 58]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-10.10. AT_NEXT_PSEUDONYM
-
- The format of the AT_NEXT_PSEUDONYM attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_NEXT_PSEU..| Length | Actual Pseudonym Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- . Next Pseudonym .
- . .
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of this attribute begins with the 2-byte actual
- pseudonym length, which specifies the length of the following
- pseudonym in bytes. This field is followed by a pseudonym username
- that the peer can use in the next authentication. The username MUST
- NOT include any realm portion. The username does not include any
- terminating null characters. Because the length of the attribute
- must be a multiple of 4 bytes, the sender pads the pseudonym with
- zero bytes when necessary. The username encoding MUST follow the
- UTF-8 transformation format [RFC3629]. This attribute MUST always be
- encrypted by encapsulating it within the AT_ENCR_DATA attribute.
-
-10.11. AT_NEXT_REAUTH_ID
-
- The format of the AT_NEXT_REAUTH_ID attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_NEXT_REAU..| Length | Actual Re-Auth Identity Length|
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- . Next Fast Re-authentication Username .
- . .
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of this attribute begins with the 2-byte actual
- re-authentication identity length which specifies the length of the
- following fast re-authentication identity in bytes. This field is
- followed by a fast re-authentication identity that the peer can use
- in the next fast re-authentication, as described in Section 5. In
- environments where a realm portion is required, the fast
- re-authentication identity includes both a username portion and a
-
-
-
-Haverinen & Salowey Informational [Page 59]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- realm name portion. The fast re-authentication identity does not
- include any terminating null characters. Because the length of the
- attribute must be a multiple of 4 bytes, the sender pads the fast
- re-authentication identity with zero bytes when necessary. The
- identity encoding MUST follow the UTF-8 transformation format
- [RFC3629]. This attribute MUST always be encrypted by encapsulating
- it within the AT_ENCR_DATA attribute.
-
-10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING
-
- AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted
- information between the EAP-SIM peer and server.
-
- The value field of AT_IV contains two reserved bytes followed by a
- 16-byte initialization vector required by the AT_ENCR_DATA attribute.
- The reserved bytes are set to zero when sending and ignored on
- reception. The AT_IV attribute MUST be included if and only if the
- AT_ENCR_DATA is included. Section 6.3 specifies the operation if a
- packet that does not meet this condition is encountered.
-
- The sender of the AT_IV attribute chooses the initialization vector
- at random. The sender MUST NOT re-use the initialization vector
- value from previous EAP-SIM packets. The sender SHOULD use a good
- source of randomness to generate the initialization vector. Please
- see [RFC4086] for more information about generating random numbers
- for security applications. The format of AT_IV is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_IV | Length = 5 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Initialization Vector |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of the AT_ENCR_DATA attribute consists of two
- reserved bytes followed by cipher text bytes encrypted using the
- Advanced Encryption Standard (AES) [AES] with a 128-bit key in the
- Cipher Block Chaining (CBC) mode of operation using the
- initialization vector from the AT_IV attribute. The reserved bytes
- are set to zero when sending and ignored on reception. Please see
- [CBC] for a description of the CBC mode. The format of the
- AT_ENCR_DATA attribute is shown below.
-
-
-
-
-
-Haverinen & Salowey Informational [Page 60]
-\f
-RFC 4186 EAP-SIM Authentication January 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_ENCR_DATA | Length | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- . Encrypted Data .
- . .
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The derivation of the encryption key (K_encr) is specified in Section
- 7.
-
- The plaintext consists of nested EAP-SIM attributes.
-
- The encryption algorithm requires the length of the plaintext to be a
- multiple of 16 bytes. The sender may need to include the AT_PADDING
- attribute as the last attribute within AT_ENCR_DATA. The AT_PADDING
- attribute is not included if the total length of other nested
- attributes within the AT_ENCR_DATA attribute is a multiple of 16
- bytes. As usual, the Length of the Padding attribute includes the
- Attribute Type and Attribute Length fields. The length of the
- Padding attribute is 4, 8, or 12 bytes. It is chosen so that the
- length of the value field of the AT_ENCR_DATA attribute becomes a
- multiple of 16 bytes. The actual pad bytes in the value field are
- set to zero (00 hexadecimal) on sending. The recipient of the
- message MUST verify that the pad bytes are set to zero. If this
- verification fails on the peer, then it MUST send the
- EAP-Response/SIM/Client-Error packet with the error code "unable to
- process packet" to terminate the authentication exchange. If this
- verification fails on the server, then the server sends the peer the
- EAP-Request/SIM/Notification packet with an AT_NOTIFICATION code that
- implies failure to terminate the authentication exchange. The format
- of the AT_PADDING attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_PADDING | Length | Padding... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 61]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-10.13. AT_RESULT_IND
-
- The format of the AT_RESULT_IND attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_RESULT_...| Length = 1 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of this attribute consists of two reserved bytes,
- which are set to zero upon sending and ignored upon reception. This
- attribute is always sent unencrypted, so it MUST NOT be encapsulated
- within the AT_ENCR_DATA attribute.
-
-10.14. AT_MAC
-
- The AT_MAC attribute is used for EAP-SIM message authentication.
- Section 8 specifies in which messages AT_MAC MUST be included.
-
- The value field of the AT_MAC attribute contains two reserved bytes
- followed by a keyed message authentication code (MAC). The MAC is
- calculated over the whole EAP packet and concatenated with optional
- message-specific data, with the exception that the value field of the
- MAC attribute is set to zero when calculating the MAC. The EAP
- packet includes the EAP header that begins with the Code field, the
- EAP-SIM header that begins with the Subtype field, and all the
- attributes, as specified in Section 8.1. The reserved bytes in
- AT_MAC are set to zero when sending and ignored on reception. The
- contents of the message-specific data that may be included in the MAC
- calculation are specified separately for each EAP-SIM message in
- Section 9.
-
- The format of the AT_MAC attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_MAC | Length = 5 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | MAC |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 62]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- The MAC algorithm is an HMAC-SHA1-128 [RFC2104] keyed hash value.
- (The HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value
- by truncating the output to the first 16 bytes. Hence, the length of
- the MAC is 16 bytes. The derivation of the authentication key
- (K_aut) used in the calculation of the MAC is specified in Section 7.
-
- When the AT_MAC attribute is included in an EAP-SIM message, the
- recipient MUST process the AT_MAC attribute before looking at any
- other attributes, except when processing EAP-Request/SIM/Challenge.
- The processing of EAP-Request/SIM/Challenge is specified in Section
- 9.3. If the message authentication code is invalid, then the
- recipient MUST ignore all other attributes in the message and operate
- as specified in Section 6.3.
-
-10.15. AT_COUNTER
-
- The format of the AT_COUNTER attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_COUNTER | Length = 1 | Counter |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of the AT_COUNTER attribute consists of a 16-bit
- unsigned integer counter value, represented in network byte order.
- This attribute MUST always be encrypted by encapsulating it within
- the AT_ENCR_DATA attribute.
-
-10.16. AT_COUNTER_TOO_SMALL
-
- The format of the AT_COUNTER_TOO_SMALL attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_COUNTER...| Length = 1 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of this attribute consists of two reserved bytes,
- which are set to zero upon sending and ignored upon reception. This
- attribute MUST always be encrypted by encapsulating it within the
- AT_ENCR_DATA attribute.
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 63]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-10.17. AT_NONCE_S
-
- The format of the AT_NONCE_S attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_NONCE_S | Length = 5 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | |
- | NONCE_S |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of the AT_NONCE_S attribute contains two reserved
- bytes followed by a random number freshly generated by the server (16
- bytes) for this EAP-SIM fast re-authentication. The random number is
- used as a challenge for the peer and also as a seed value for the new
- keying material. The reserved bytes are set to zero upon sending and
- ignored upon reception. This attribute MUST always be encrypted by
- encapsulating it within the AT_ENCR_DATA attribute.
-
- The server MUST NOT re-use the NONCE_S value from any previous
- EAP-SIM fast re-authentication exchange. The server SHOULD use a
- good source of randomness to generate NONCE_S. Please see [RFC4086]
- for more information about generating random numbers for security
- applications.
-
-10.18. AT_NOTIFICATION
-
- The format of the AT_NOTIFICATION attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |AT_NOTIFICATION| Length = 1 |S|P| Notification Code |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of this attribute contains a two-byte notification
- code. The first and second bit (S and P) of the notification code
- are interpreted as described in Section 6.
-
- The notification code values listed below have been reserved. The
- descriptions below illustrate the semantics of the notifications.
-
-
-
-
-
-Haverinen & Salowey Informational [Page 64]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- The peer implementation MAY use different wordings when presenting
- the notifications to the user. The "requested service" depends on
- the environment where EAP-SIM is applied.
-
- 0 - General failure after authentication. (Implies failure, used
- after successful authentication.)
-
- 16384 - General failure. (Implies failure, used before
- authentication.)
-
- 32768 - Success. User has been successfully authenticated. (Does
- not imply failure, used after successful authentication). The usage
- of this code is discussed in Section 6.2.
-
- 1026 - User has been temporarily denied access to the requested
- service. (Implies failure, used after successful authentication.)
-
- 1031 - User has not subscribed to the requested service. (Implies
- failure, used after successful authentication.)
-
-10.19. AT_CLIENT_ERROR_CODE
-
- The format of the AT_CLIENT_ERROR_CODE attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |AT_CLIENT_ERR..| Length = 1 | Client Error Code |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of this attribute contains a two-byte client error
- code. The following error code values have been reserved.
-
-
- 0 "unable to process packet": a general error code
-
- 1 "unsupported version": the peer does not support any of
- the versions listed in AT_VERSION_LIST
-
- 2 "insufficient number of challenges": the peer's policy
- requires more triplets than the server included in AT_RAND
-
- 3 "RANDs are not fresh": the peer believes that the RAND
- challenges included in AT_RAND were not fresh
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 65]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-11. IANA Considerations
-
- IANA has assigned the EAP type number 18 for this protocol.
-
- EAP-SIM shares most of the protocol design, such as attributes and
- message Subtypes, with EAP-AKA [EAP-AKA]. EAP-SIM protocol numbers
- should be administered in the same IANA registry as EAP-AKA. The
- initial values are listed in [EAP-AKA] for both protocols, so this
- document does not require any new registries or parameter allocation.
- As a common registry is used for EAP-SIM and EAP-AKA, the protocol
- number allocation policy for both protocols is specified in
- [EAP-AKA].
-
-12. Security Considerations
-
- The EAP specification [RFC3748] describes the security
- vulnerabilities of EAP, which does not include its own security
- mechanisms. This section discusses the claimed security properties
- of EAP-SIM, as well as vulnerabilities and security recommendations.
-
-12.1. A3 and A8 Algorithms
-
- The GSM A3 and A8 algorithms are used in EAP-SIM. [GSM-03.20]
- specifies the general GSM authentication procedure and the external
- interface (inputs and outputs) of the A3 and A8 algorithms. The
- operation of these functions falls completely within the domain of an
- individual operator, and therefore, the functions are specified by
- each operator rather than being fully standardised. The GSM-MILENAGE
- algorithm, specified publicly in [3GPP-TS-55.205], is an example
- algorithm set for A3 and A8 algorithms.
-
- The security of the A3 and A8 algorithms is important to the security
- of EAP-SIM. Some A3/A8 algorithms have been compromised; see [GSM-
- Cloning] for discussion about the security of COMP-128 version 1.
- Note that several revised versions of the COMP-128 A3/A8 algorithm
- have been devised after the publication of these weaknesses and that
- the publicly specified GSM-MILENAGE algorithm is not vulnerable to
- any known attacks.
-
-12.2. Identity Protection
-
- EAP-SIM includes optional identity privacy support that protects the
- privacy of the subscriber identity against passive eavesdropping.
- This document only specifies a mechanism to deliver pseudonyms from
- the server to the peer as part of an EAP-SIM exchange. Hence, a peer
- that has not yet performed any EAP-SIM exchanges does not typically
- have a pseudonym available. If the peer does not have a pseudonym
- available, then the privacy mechanism cannot be used, but the
-
-
-
-Haverinen & Salowey Informational [Page 66]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- permanent identity will have to be sent in the clear. The terminal
- SHOULD store the pseudonym in a non-volatile memory so that it can be
- maintained across reboots. An active attacker that impersonates the
- network may use the AT_PERMANENT_ID_REQ attribute to attempt to learn
- the subscriber's permanent identity. However, as discussed in
- Section 4.2.2, the terminal can refuse to send the cleartext
- permanent identity if it believes that the network should be able to
- recognize the pseudonym.
-
- If the peer and server cannot guarantee that the pseudonym will be
- maintained reliably, and identity privacy is required, then
- additional protection from an external security mechanism (such as
- Protected Extensible Authentication Protocol (PEAP) [PEAP]) may be
- used. If an external security mechanism is in use, the identity
- privacy features of EAP-SIM may not be useful. The security
- considerations of using an external security mechanism with EAP-SIM
- are beyond the scope of this document.
-
-12.3. Mutual Authentication and Triplet Exposure
-
- EAP-SIM provides mutual authentication. The peer believes that the
- network is authentic because the network can calculate a correct
- AT_MAC value in the EAP-Request/SIM/Challenge packet. To calculate
- AT_MAC it is sufficient to know the RAND and Kc values from the GSM
- triplets (RAND, SRES, Kc) used in the authentication. Because the
- network selects the RAND challenges and the triplets, an attacker
- that knows n (2 or 3) GSM triplets for the subscriber is able to
- impersonate a valid network to the peer. (Some peers MAY employ an
- implementation-specific counter-measure against impersonating a valid
- network by re-using a previously used RAND; see below.) In other
- words, the security of EAP-SIM is based on the secrecy of Kc keys,
- which are considered secret intermediate results in the EAP-SIM
- cryptographic calculations.
-
- Given physical access to the SIM card, it is easy to obtain any
- number of GSM triplets.
-
- Another way to obtain triplets is to mount an attack on the peer
- platform via a virus or other malicious piece of software. The peer
- SHOULD be protected against triplet querying attacks by malicious
- software. Care should be taken not to expose Kc keys to attackers
- when they are stored or handled by the peer, or transmitted between
- subsystems of the peer. Steps should be taken to limit the
- transport, storage, and handling of these values outside a protected
- environment within the peer. However, the virus protection of the
- peer and the security capabilities of the peer's operating system are
- outside the scope of this document.
-
-
-
-
-Haverinen & Salowey Informational [Page 67]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- The EAP-SIM server typically obtains the triplets from the Home
- Location Register (HLR). An attacker might try to obtain triplets by
- attacking against the network used between the EAP-SIM server and the
- HLR. Care should be taken not to expose Kc keys to attackers when
- they are stored or handled by the EAP-SIM server, or transmitted
- between the EAP server and the HLR. Steps should be taken to limit
- the transport, storage, and handling of these values outside a
- protected environment. However, the protection of the communications
- between the EAP-SIM server and the HLR is outside the scope of this
- document.
-
- If the same SIM credentials are also used for GSM traffic, the
- triplets could be revealed in the GSM network; see Section 12.8.
-
- In GSM, the network is allowed to re-use the RAND challenge in
- consecutive authentication exchanges. This is not allowed in
- EAP-SIM. The EAP-SIM server is mandated to use fresh triplets (RAND
- challenges) in consecutive authentication exchanges, as specified in
- Section 3. EAP-SIM does not mandate any means for the peer to check
- if the RANDs are fresh, so the security of the scheme leans on the
- secrecy of the triplets. However, the peer MAY employ
- implementation-specific mechanisms to remember some of the previously
- used RANDs, and the peer MAY check the freshness of the server's
- RANDs. The operation in cases when the peer detects that the RANDs
- are not fresh is specified in Section 6.3.1.
-
- Preventing the re-use of authentication vectors has been taken into
- account in the design of the UMTS Authentication and Key Agreement
- (AKA), which is used in EAP-AKA [EAP-AKA]. In cases when the triplet
- re-use properties of EAP-SIM are not considered sufficient, it is
- advised to use EAP-AKA.
-
- Note that EAP-SIM mutual authentication is done with the EAP server.
- In general, EAP methods do not authenticate the identity or services
- provided by the EAP authenticator (if distinct from the EAP server)
- unless they provide the so-called channel bindings property. The
- vulnerabilities related to this have been discussed in [RFC3748],
- [EAP-Keying], [Service-Identity].
-
- EAP-SIM does not provide the channel bindings property, so it only
- authenticates the EAP server. However, ongoing work such as
- [Service-Identity] may provide such support as an extension to
- popular EAP methods such as EAP-TLS, EAP-SIM, or EAP-AKA.
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 68]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-12.4. Flooding the Authentication Centre
-
- The EAP-SIM server typically obtains authentication vectors from the
- Authentication Centre (AuC). EAP-SIM introduces a new usage for the
- AuC. The protocols between the EAP-SIM server and the AuC are out of
- the scope of this document. However, it should be noted that a
- malicious EAP-SIM peer may generate a lot of protocol requests to
- mount a denial of service attack. The EAP-SIM server implementation
- SHOULD take this into account and SHOULD take steps to limit the
- traffic that it generates towards the AuC, preventing the attacker
- from flooding the AuC and from extending the denial of service attack
- from EAP-SIM to other users of the AuC.
-
-12.5. Key Derivation
-
- EAP-SIM supports key derivation. The key hierarchy is specified in
- Section 7. EAP-SIM combines several GSM triplets in order to
- generate stronger keying material and stronger AT_MAC values. The
- actual strength of the resulting keys depends, among other things, on
- operator-specific parameters including authentication algorithms, the
- strength of the Ki key, and the quality of the RAND challenges. For
- example, some SIM cards generate Kc keys with 10 bits set to zero.
- Such restrictions may prevent the concatenation technique from
- yielding strong session keys. Because the strength of the Ki key is
- 128 bits, the ultimate strength of any derived secret key material is
- never more than 128 bits.
-
- It should also be noted that a security policy that allows n=2 to be
- used may compromise the security of a future policy that requires
- three triplets, because adversaries may be able to exploit the
- messages exchanged when the weaker policy is applied.
-
- There is no known way to obtain complete GSM triplets by mounting an
- attack against EAP-SIM. A passive eavesdropper can learn n*RAND and
- AT_MAC and may be able to link this information to the subscriber
- identity. An active attacker that impersonates a GSM subscriber can
- easily obtain n*RAND and AT_MAC values from the EAP server for any
- given subscriber identity. However, calculating the Kc and SRES
- values from AT_MAC would require the attacker to reverse the keyed
- message authentication code function HMAC-SHA1-128.
-
- As EAP-SIM does not expose any values calculated from an individual
- GSM Kc keys, it is not possible to mount a brute force attack on only
- one of the Kc keys in EAP-SIM. Therefore, when considering brute
- force attacks on the values exposed in EAP-SIM, the effective length
- of EAP-SIM session keys is not compromised by the fact that they are
-
-
-
-
-
-Haverinen & Salowey Informational [Page 69]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- combined from several shorter keys, i.e., the effective length of 128
- bits may be achieved. For additional considerations, see Section
- 12.8.
-
-12.6. Cryptographic Separation of Keys and Session Independence
-
- The EAP Transient Keys used to protect EAP-SIM packets (K_encr,
- K_aut), the Master Session Key, and the Extended Master Session Key
- are cryptographically separate in EAP-SIM. An attacker cannot derive
- any non-trivial information about any of these keys based on the
- other keys. An attacker also cannot calculate the pre-shared secret
- (Ki) from the GSM Kc keys, from EAP-SIM K_encr, from EAP-SIM K_aut,
- from the Master Session Key, or from the Extended Master Session Key.
-
- Each EAP-SIM exchange generates fresh keying material, and the keying
- material exported from the method upon separate EAP-SIM exchanges is
- cryptographically separate. The EAP-SIM peer contributes to the
- keying material with the NONCE_MT parameter, which must be chosen
- freshly for each full authentication exchange. The EAP server is
- mandated to choose the RAND challenges freshly for each full
- authentication exchange. If either the server or the peer chooses
- its random value (NONCE_MT or RAND challenges) freshly, even if the
- other entity re-used its value from a previous exchange, then the EAP
- Transient Keys, the Master Session Key, and the Extended Master
- Session Key will be different and cryptographically separate from the
- corresponding values derived upon the previous full authentication
- exchange.
-
- On fast re-authentication, freshness of the Master Session Key and
- the Extended Master Session Key is provided with a counter
- (AT_COUNTER). The same EAP Transient Keys (K_encr, K_aut) that were
- used in the full authentication exchange are used to protect the EAP
- negotiation. However, replay and integrity protection across all the
- fast re-authentication exchanges that use the same EAP Transient Keys
- is provided with AT_COUNTER.
-
- [RFC3748] defines session independence as the "demonstration that
- passive attacks (such as capture of the EAP conversation) or active
- attacks (including compromise of the MSK or EMSK) do not enable
- compromise of subsequent or prior MSKs or EMSKs". Because the MSKs
- and EMSKs are separate between EAP exchanges, EAP-SIM supports this
- security claim.
-
- It should be noted that [Patel-2003], which predates [RFC3748], uses
- a slightly different meaning for session independence. The EAP-SIM
- protocol does not allow the peer to ensure that different Kc key
- values would be used in different exchanges. Only the server is able
- to ensure that fresh RANDs, and therefore, fresh Kc keys are used.
-
-
-
-Haverinen & Salowey Informational [Page 70]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- Hence, the peer cannot guarantee EAP-SIM sessions to be independent
- with regard to the internal Kc values. However, in EAP-SIM, the Kc
- keys are considered to be secret intermediate results, which are not
- exported outside the method. See Section 12.3 for more information
- about RAND re-use.
-
-12.7. Dictionary Attacks
-
- Because EAP-SIM is not a password protocol, it is not vulnerable to
- dictionary attacks. (The pre-shared symmetric secret stored on the
- SIM card is not a passphrase, nor is it derived from a passphrase.)
-
-12.8. Credentials Re-use
-
- EAP-SIM cannot prevent attacks over the GSM or GPRS radio networks.
- If the same SIM credentials are also used in GSM or GPRS, it is
- possible to mount attacks over the cellular interface.
-
- A passive attacker can eavesdrop GSM or GPRS traffic and obtain RAND,
- SRES pairs. He can then use a brute force attack or other
- cryptanalysis techniques to obtain the 64-bit Kc keys used to encrypt
- the GSM or GPRS data. This makes it possible to attack each 64-bit
- key separately.
-
- An active attacker can mount a "rogue GSM/GPRS base station attack",
- replaying previously seen RAND challenges to obtain SRES values. He
- can then use a brute force attack to obtain the Kc keys. If
- successful, the attacker can impersonate a valid network or decrypt
- previously seen traffic, because EAP-SIM does not provide perfect
- forward secrecy (PFS).
-
- Due to several weaknesses in the GSM encryption algorithms, the
- effective key strength of the Kc keys is much less than the expected
- 64 bits (no more than 40 bits if the A5/1 GSM encryption algorithm is
- used; as documented in [Barkan-2003], an active attacker can force
- the peer to use the weaker A5/2 algorithm that can be broken in less
- than a second).
-
- Because the A5 encryption algorithm is not used in EAP-SIM, and
- because EAP-SIM does not expose any values calculated from individual
- Kc keys, it should be noted that these attacks are not possible if
- the SIM credentials used in EAP-SIM are not shared in GSM/GPRS.
-
- At the time this document was written, the 3rd Generation Partnership
- Project (3GPP) has started to work on fixes to these A5
- vulnerabilities. One of the solution proposals discussed in 3GPP is
- integrity-protected A5 version negotiation, which would require the
- base station to prove knowledge of the Kc key before the terminal
-
-
-
-Haverinen & Salowey Informational [Page 71]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- sends any values calculated from the Kc to the network. Another
- proposal is so-called special RANDs, where some bits of the RAND
- challenge would be used for cryptographic separation by indicating
- the allowed use of the triplet, such as the allowed A5 algorithm in
- GSM or the fact that the triplet is intended for EAP-SIM. This is
- currently a work in progress, and the mechanisms have not been
- selected yet.
-
-12.9. Integrity and Replay Protection, and Confidentiality
-
- AT_MAC, AT_IV, AT_ENCR_DATA, and AT_COUNTER attributes are used to
- provide integrity, replay and confidentiality protection for EAP-SIM
- requests and responses. Integrity protection with AT_MAC includes
- the EAP header. These attributes cannot be used during the
- EAP/SIM/Start roundtrip. However, the protocol values (user identity
- string, NONCE_MT, and version negotiation parameters) are
- (implicitly) protected by later EAP-SIM messages by including them in
- key derivation.
-
- Integrity protection (AT_MAC) is based on a keyed message
- authentication code. Confidentiality (AT_ENCR_DATA and AT_IV) is
- based on a block cipher.
-
- Confidentiality protection is applied only to a part of the protocol
- fields. The table of attributes in Section 10.1 summarizes which
- fields are confidentiality-protected. It should be noted that the
- error and notification code attributes AT_CLIENT_ERROR_CODE and
- AT_NOTIFICATION are not confidential, but they are transmitted in the
- clear. Identity protection is discussed in Section 12.2.
-
- On full authentication, replay protection of the EAP exchange is
- provided by the RAND values from the underlying GSM authentication
- scheme and the use of the NONCE_MT value. Protection against replays
- of EAP-SIM messages is also based on the fact that messages that can
- include AT_MAC can only be sent once with a certain EAP-SIM Subtype,
- and on the fact that a different K_aut key will be used for
- calculating AT_MAC in each full authentication exchange.
-
- On fast re-authentication, a counter included in AT_COUNTER and a
- server random nonce is used to provide replay protection. The
- AT_COUNTER attribute is also included in EAP-SIM notifications if it
- is used after successful authentication in order to provide replay
- protection between re-authentication exchanges.
-
- Because EAP-SIM is not a tunneling method, EAP-Request/Notification,
- EAP-Response/Notification, EAP-Success, or EAP-Failure packets are
- not confidential, integrity-protected, or replay-protected in
- EAP-SIM. On physically insecure networks, this may enable an
-
-
-
-Haverinen & Salowey Informational [Page 72]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- attacker to send false notifications to the peer and to mount denial
- of service attacks by spoofing these packets. As discussed in
- Section 6.3, the peer will only accept EAP-Success after the peer
- successfully authenticates the server. Hence, the attacker cannot
- force the peer to believe successful mutual authentication has
- occurred until the peer successfully authenticates the server or
- after the peer fails to authenticate the server.
-
- The security considerations of EAP-SIM result indications are covered
- in Section 12.11
-
- An eavesdropper will see the EAP-Request/Notification,
- EAP-Response/Notification, EAP-Success, and EAP-Failure packets sent
- in the clear. With EAP-SIM, confidential information MUST NOT be
- transmitted in EAP Notification packets.
-
-12.10. Negotiation Attacks
-
- EAP-SIM does not protect the EAP-Response/Nak packet. Because
- EAP-SIM does not protect the EAP method negotiation, EAP method
- downgrading attacks may be possible, especially if the user uses the
- same identity with EAP-SIM and other EAP methods.
-
- EAP-SIM includes a version negotiation procedure. In EAP-SIM the
- keying material derivation includes the version list and selected
- version to ensure that the protocol cannot be downgraded and that the
- peer and server use the same version of EAP-SIM.
-
- EAP-SIM does not support ciphersuite negotiation.
-
-12.11. Protected Result Indications
-
- EAP-SIM supports optional protected success indications and
- acknowledged failure indications. If a failure occurs after
- successful authentication, then the EAP-SIM failure indication is
- integrity- and replay-protected.
-
- Even if an EAP-Failure packet is lost when using EAP-SIM over an
- unreliable medium, then the EAP-SIM failure indications will help
- ensure that the peer and EAP server will know the other party's
- authentication decision. If protected success indications are used,
- then the loss of Success packet will also be addressed by the
- acknowledged, integrity- and replay-protected EAP-SIM success
- indication. If the optional success indications are not used, then
- the peer may end up believing that the server succeeded
- authentication, when it actually failed. Since access will not be
-
-
-
-
-
-Haverinen & Salowey Informational [Page 73]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- granted in this case, protected result indications are not needed
- unless the client is not able to realize it does not have access for
- an extended period of time.
-
-12.12. Man-in-the-Middle Attacks
-
- In order to avoid man-in-the-middle attacks and session hijacking,
- user data SHOULD be integrity-protected on physically insecure
- networks. The EAP-SIM Master Session Key, or keys derived from it,
- MAY be used as the integrity protection keys, or, if an external
- security mechanism such as PEAP is used, then the link integrity
- protection keys MAY be derived by the external security mechanism.
-
- There are man-in-the-middle attacks associated with the use of any
- EAP method within a tunneled protocol. For instance, an early
- version of PEAP [PEAP-02] was vulnerable to this attack. This
- specification does not address these attacks. If EAP-SIM is used
- with a tunneling protocol, there should be cryptographic binding
- provided between the protocol and EAP-SIM to prevent
- man-in-the-middle attacks through rogue authenticators being able to
- setup one-way authenticated tunnels. For example, newer versions of
- PEAP include such cryptographic binding. The EAP-SIM Master Session
- Key MAY be used to provide the cryptographic binding. However, the
- mechanism by which the binding is provided depends on the tunneling
- protocol and is beyond the scope of this document.
-
-12.13. Generating Random Numbers
-
- An EAP-SIM implementation SHOULD use a good source of randomness to
- generate the random numbers required in the protocol. Please see
- [RFC4086] for more information on generating random numbers for
- security applications.
-
-13. Security Claims
-
- This section provides the security claims required by [RFC3748].
-
- Auth. mechanism: EAP-SIM is based on the GSM SIM mechanism, which is
- a challenge/response authentication and key agreement mechanism based
- on a symmetric 128-bit pre-shared secret. EAP-SIM also makes use of
- a peer challenge to provide mutual authentication.
-
- Ciphersuite negotiation: No
-
- Mutual authentication: Yes (Section 12.3)
-
- Integrity protection: Yes (Section 12.9)
-
-
-
-
-Haverinen & Salowey Informational [Page 74]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- Replay protection: Yes (Section 12.9)
-
- Confidentiality: Yes, except method-specific success and failure
- indications (Section 12.2, Section 12.9)
-
- Key derivation: Yes
-
- Key strength: EAP-SIM supports key derivation with 128-bit effective
- key strength (Section 12.5). However, as discussed in Section 11, if
- the same credentials are used in GSM/GPRS and in EAP-SIM, then the
- key strength may be reduced considerably, basically to the same level
- as in GSM, by mounting attacks over GSM/GPRS. For example an active
- attack using a false GSM/GPRS base station reduces the effective key
- strength to almost zero.
-
- Description of key hierarchy: Please see Section 7.
-
- Dictionary attack protection: N/A (Section 12.7)
-
- Fast reconnect: Yes
-
- Cryptographic binding: N/A
-
- Session independence: Yes (Section 12.6)
-
- Fragmentation: No
-
- Channel binding: No
-
- Indication of vulnerabilities: Vulnerabilities are discussed in
- Section 12.
-
-14. Acknowledgements and Contributions
-
-14.1. Contributors
-
- In addition to the editors, Nora Dabbous, Jose Puthenkulam, and
- Prasanna Satarasinghe were significant contributors to this document.
-
- Pasi Eronen and Jukka-Pekka Honkanen contributed Appendix A.
-
-14.2. Acknowledgements
-
- Juha Ala-Laurila, N. Asokan, Jan-Erik Ekberg, Patrik Flykt,
- Jukka-Pekka Honkanen, Antti Kuikka, Jukka Latva, Lassi Lehtinen, Jyri
- Rinnemaa, Timo Takamaki, and Raimo Vuonnala contributed many original
- ideas and concepts to this protocol.
-
-
-
-
-Haverinen & Salowey Informational [Page 75]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- N. Asokan, Pasi Eronen, and Jukka-Pekka Honkanen contributed and
- helped in innumerable ways during the development of the protocol.
-
- Valtteri Niemi and Kaisa Nyberg contributed substantially to the
- design of the key derivation and the fast re-authentication
- procedure, and have also provided their cryptographic expertise in
- many discussions related to this protocol.
-
- Simon Blake-Wilson provided very helpful comments on key derivation
- and version negotiation.
-
- Thanks to Greg Rose for his very valuable comments to an early
- version of this specification [S3-020125], and for reviewing and
- providing very useful comments on version 12.
-
- Thanks to Bernard Aboba, Vladimir Alperovich, Florent Bersani,
- Jacques Caron, Gopal Dommety, Augustin Farrugia, Mark Grayson, Max de
- Groot, Prakash Iyer, Nishi Kant, Victor Lortz, Jouni Malinen, Sarvar
- Patel, Tom Porcher, Michael Richardson, Stefan Schroeder, Uma
- Shankar, Jesse Walker, and Thomas Wieland for their contributions and
- critiques. Special thanks to Max for proposing improvements to the
- MAC calculation.
-
- Thanks to Glen Zorn for reviewing this document and for providing
- very useful comments on the protocol.
-
- Thanks to Sarvar Patel for his review of the protocol [Patel-2003].
-
- Thanks to Bernard Aboba for reviewing this document for RFC 3748
- compliance.
-
- The identity privacy support is based on the identity privacy support
- of [EAP-SRP]. The attribute format is based on the extension format
- of Mobile IPv4 [RFC3344].
-
- This protocol has been partly developed in parallel with EAP-AKA
- [EAP-AKA], and hence this specification incorporates many ideas from
- Jari Arkko.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 76]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-14.2.1. Contributors' Addresses
-
- Nora Dabbous
- Gemplus
- 34 rue Guynemer
- 92447 Issy les Moulineaux
- France
-
- Phone: +33 1 4648 2000
- EMail: nora.dabbous@gemplus.com
-
-
- Jose Puthenkulam
- Intel Corporation
- 2111 NE 25th Avenue, JF2-58
- Hillsboro, OR 97124
- USA
-
- Phone: +1 503 264 6121
- EMail: jose.p.puthenkulam@intel.com
-
-
- Prasanna Satarasinghe
- Transat Technologies
- 180 State Street, Suite 240
- Southlake, TX 76092
- USA
-
- Phone: + 1 817 4814412
- EMail: prasannas@transat-tech.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 77]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-15. References
-
-15.1. Normative References
-
- [GSM-03.20] European Telecommunications Standards Institute,
- "GSM Technical Specification GSM 03.20 (ETS 300
- 534): "Digital cellular telecommunication system
- (Phase 2); Security related network functions"",
- August 1997.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to
- Indicate Requirement Levels", BCP 14, RFC 2119,
- March 1997.
-
- [GSM-03.03] European Telecommunications Standards Institute,
- "GSM Technical Specification GSM 03.03 (ETS 300
- 523): "Digital cellular telecommunication system
- (Phase 2); Numbering, addressing and
- identification"", April 1997.
-
- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
- Keyed-Hashing for Message Authentication", RFC
- 2104, February 1997.
-
- [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen,
- "The Network Access Identifier", RFC 4282,
- December 2005.
-
- [AES] National Institute of Standards and Technology,
- "Federal Information Processing Standards (FIPS)
- Publication 197, "Advanced Encryption Standard
- (AES)"", November 2001.
- http://csrc.nist.gov/publications/fips/fips197/
- fips-197.pdf
-
- [CBC] National Institute of Standards and Technology,
- "NIST Special Publication 800-38A, "Recommendation
- for Block Cipher Modes of Operation - Methods and
- Techniques"", December 2001.
- http://csrc.nist.gov/publications/nistpubs/
- 800-38a/sp800-38a.pdf
-
- [SHA-1] National Institute of Standards and Technology,
- U.S. Department of Commerce, "Federal Information
- Processing Standard (FIPS) Publication 180-1,
- "Secure Hash Standard"", April 1995.
-
-
-
-
-
-Haverinen & Salowey Informational [Page 78]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- [PRF] National Institute of Standards and Technology,
- "Federal Information Processing Standards (FIPS)
- Publication 186-2 (with change notice); Digital
- Signature Standard (DSS)", January 2000.
- Available on-line at:
- http://csrc.nist.gov/publications/
- fips/fips186-2/fips186-2-change1.pdf
-
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of
- ISO 10646", STD 63, RFC 3629, November 2003.
-
- [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J.,
- and H. Levkowetz, "Extensible Authentication
- Protocol (EAP)", RFC 3748, June 2004.
-
- [EAP-AKA] Arkko, J. and H. Haverinen, "Extensible
- Authentication Protocol Method for 3rd Generation
- Authentication and Key Agreement (EAP-AKA)", RFC
- 4187, January 2006.
-
-15.2. Informative References
-
- [3GPP-TS-23.003] 3rd Generation Partnership Project, "3GPP
- Technical Specification 3GPP TS 23.003 V6.8.0:
- "3rd Generation Parnership Project; Technical
- Specification Group Core Network; Numbering,
- addressing and identification (Release 6)"",
- December 2005.
-
- [3GPP-TS-55.205] 3rd Generation Partnership Project, "3GPP
- Technical Specification 3GPP TS 55.205 V 6.0.0:
- "3rd Generation Partnership Project; Technical
- Specification Group Services and System Aspects;
- Specification of the GSM-MILENAGE Algorithms: An
- example algorithm set for the GSM Authentication
- and Key Generation functions A3 and A8 (Release
- 6)"", December 2002.
-
- [PEAP] Palekar, A., Simon, D., Zorn, G., Salowey, J.,
- Zhou, H., and S. Josefsson, "Protected EAP
- Protocol (PEAP) Version 2", Work in Progress,
- October 2004.
-
- [PEAP-02] Anderson, H., Josefsson, S., Zorn, G., Simon, D.,
- and A. Palekar, "Protected EAP Protocol (PEAP)",
- Work in Progress, February 2002.
-
-
-
-
-
-Haverinen & Salowey Informational [Page 79]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- [EAP-Keying] Aboba, B., Simon, D., Arkko, J., Eronen, P., and
- H. Levkowetz, "Extensible Authentication Protocol
- (EAP) Key Management Framework", Work in Progress,
- October 2005.
-
- [Service-Identity] Arkko, J. and P. Eronen, "Authenticated Service
- Information for the Extensible Authentication
- Protocol (EAP)", Work in Progress, October 2004.
-
- [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
- "Randomness Requirements for Security", BCP 106,
- RFC 4086, June 2005.
-
- [S3-020125] Qualcomm, "Comments on draft EAP/SIM, 3rd
- Generation Partnership Project document 3GPP TSG
- SA WG3 Security S3#22, S3-020125", February 2002.
-
- [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC
- 3344, August 2002.
-
- [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS
- Attributes ", RFC 2548, March 1999.
-
- [EAP-SRP] Carlson, J., Aboba, B., and H. Haverinen, "EAP
- SRP-SHA1 Authentication Protocol", Work in
- Progress, July 2001.
-
- [GSM-Cloning] Wagner, D., "GSM Cloning". Web page about
- COMP-128 version 1 vulnerabilities, available at
- http://www.isaac.cs.berkeley.edu/isaac/gsm.html
-
- [Barkan-2003] Barkan, E., Biham, E., and N. Keller, "Instant
- Ciphertext-Only Cryptanalysis of GSM Encrypted
- Communications". available on-line at
- http://cryptome.org/gsm-crack-bbk.pdf
-
- [Patel-2003] Patel, S., "Analysis of EAP-SIM Session Key
- Agreement". Posted to the EAP mailing list 29
- May,2003. http://
- mail.frascone.com/pipermail/public/eap/2003-May/
- 001267.html
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 80]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-Appendix A. Test Vectors
-
- Test vectors for the NIST FIPS 186-2 pseudo-random number generator
- [PRF] are available at the following URL:
- http://csrc.nist.gov/encryption/dss/Examples-1024bit.pdf
-
- The following examples show the contents of EAP-SIM packets on full
- authentication and fast re-authentication.
-
-A.1. EAP-Request/Identity
-
- The first packet is a plain Identity Request:
-
- 01 ; Code: Request
- 00 ; Identifier: 0
- 00 05 ; Length: 5 octets
- 01 ; Type: Identity
-
-A.2. EAP-Response/Identity
-
- The client's identity is "1244070100000001@eapsim.foo", so it
- responds with the following packet:
-
- 02 ; Code: Response
- 00 ; Identifier: 0
- 00 20 ; Length: 32 octets
- 01 ; Type: Identity
- 31 32 34 34 ; "1244070100000001@eapsim.foo"
- 30 37 30 31
- 30 30 30 30
- 30 30 30 31
- 40 65 61 70
- 73 69 6d 2e
- 66 6f 6f
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 81]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-A.3. EAP-Request/SIM/Start
-
- The server's first packet looks like this:
-
- 01 ; Code: Request
- 01 ; Identifier: 1
- 00 10 ; Length: 16 octets
- 12 ; Type: EAP-SIM
- 0a ; EAP-SIM subtype: Start
- 00 00 ; (reserved)
- 0f ; Attribute type: AT_VERSION_LIST
- 02 ; Attribute length: 8 octets (2*4)
- 00 02 ; Actual version list length: 2 octets
- 00 01 ; Version: 1
- 00 00 ; (attribute padding)
-
-A.4. EAP-Response/SIM/Start
-
- The client selects a nonce and responds with the following packet:
-
- 02 ; Code: Response
- 01 ; Identifier: 1
- 00 20 ; Length: 32 octets
- 12 ; Type: EAP-SIM
- 0a ; EAP-SIM subtype: Start
- 00 00 ; (reserved)
- 07 ; Attribute type: AT_NONCE_MT
- 05 ; Attribute length: 20 octets (5*4)
- 00 00 ; (reserved)
- 01 23 45 67 ; NONCE_MT value
- 89 ab cd ef
- fe dc ba 98
- 76 54 32 10
- 10 ; Attribute type: AT_SELECTED_VERSION
- 01 ; Attribute length: 4 octets (1*4)
- 00 01 ; Version: 1
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 82]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-A.5. EAP-Request/SIM/Challenge
-
- Next, the server selects three authentication triplets
-
- (RAND1,SRES1,Kc1) = (10111213 14151617 18191a1b 1c1d1e1f,
- d1d2d3d4,
- a0a1a2a3 a4a5a6a7)
- (RAND2,SRES2,Kc2) = (20212223 24252627 28292a2b 2c2d2e2f,
- e1e2e3e4,
- b0b1b2b3 b4b5b6b7)
- (RAND3,SRES3,Kc3) = (30313233 34353637 38393a3b 3c3d3e3f,
- f1f2f3f4,
- c0c1c2c3 c4c5c6c7)
-
- Next, the MK is calculated as specified in Section 7*.
-
- MK = e576d5ca 332e9930 018bf1ba ee2763c7 95b3c712
-
- And the other keys are derived using the PRNG:
-
- K_encr = 536e5ebc 4465582a a6a8ec99 86ebb620
- K_aut = 25af1942 efcbf4bc 72b39434 21f2a974
- MSK = 39d45aea f4e30601 983e972b 6cfd46d1
- c3637733 65690d09 cd44976b 525f47d3
- a60a985e 955c53b0 90b2e4b7 3719196a
- 40254296 8fd14a88 8f46b9a7 886e4488
- EMSK = 5949eab0 fff69d52 315c6c63 4fd14a7f
- 0d52023d 56f79698 fa6596ab eed4f93f
- bb48eb53 4d985414 ceed0d9a 8ed33c38
- 7c9dfdab 92ffbdf2 40fcecf6 5a2c93b9
-
- Next, the server selects a pseudonym and a fast re-authentication
- identity (in this case, "w8w49PexCazWJ&xCIARmxuMKht5S1sxR
- DqXSEFBEg3DcZP9cIxTe5J4OyIwNGVzxeJOU1G" and
- "Y24fNSrz8BP274jOJaF17WfxI8YO7QX0
- 0pMXk9XMMVOw7broaNhTczuFq53aEpOkk3L0dm@eapsim.foo", respectively).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 83]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- The following plaintext will be encrypted and stored in the
- AT_ENCR_DATA attribute:
-
- 84 ; Attribute type: AT_NEXT_PSEUDONYM
- 13 ; Attribute length: 76 octets (19*4)
- 00 46 ; Actual pseudonym length: 70 octets
- 77 38 77 34 39 50 65 78 43 61 7a 57 4a 26 78 43
- 49 41 52 6d 78 75 4d 4b 68 74 35 53 31 73 78 52
- 44 71 58 53 45 46 42 45 67 33 44 63 5a 50 39 63
- 49 78 54 65 35 4a 34 4f 79 49 77 4e 47 56 7a 78
- 65 4a 4f 55 31 47
- 00 00 ; (attribute padding)
- 85 ; Attribute type: AT_NEXT_REAUTH_ID
- 16 ; Attribute length: 88 octets (22*4)
- 00 51 ; Actual re-auth identity length: 81 octets
- 59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f
- 4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30
- 30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f
- 61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b
- 6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f
- 6f
- 00 00 00 ; (attribute padding)
- 06 ; Attribute type: AT_PADDING
- 03 ; Attribute length: 12 octets (3*4)
- 00 00 00 00
- 00 00 00 00
- 00 00
-
- The EAP packet looks like this:
-
- 01 ; Code: Request
- 02 ; Identifier: 2
- 01 18 ; Length: 280 octets
- 12 ; Type: EAP-SIM
- 0b ; EAP-SIM subtype: Challenge
- 00 00 ; (reserved)
- 01 ; Attribute type: AT_RAND
- 0d ; Attribute length: 52 octets (13*4)
- 00 00 ; (reserved)
- 10 11 12 13 ; first RAND
- 14 15 16 17
- 18 19 1a 1b
- 1c 1d 1e 1f
- 20 21 22 23 ; second RAND
- 24 25 26 27
- 28 29 2a 2b
- 2c 2d 2e 2f
-
-
-
-
-Haverinen & Salowey Informational [Page 84]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- 30 31 32 33 ; third RAND
- 34 35 36 37
- 38 39 3a 3b
- 3c 3d 3e 3f
- 81 ; Attribute type: AT_IV
- 05 ; Attribute length: 20 octets (5*4)
- 00 00 ; (reserved)
- 9e 18 b0 c2 ; IV value
- 9a 65 22 63
- c0 6e fb 54
- dd 00 a8 95
- 82 ; Attribute type: AT_ENCR_DATA
- 2d ; Attribute length: 180 octets (45*4)
- 00 00 ; (reserved)
- 55 f2 93 9b bd b1 b1 9e a1 b4 7f c0 b3 e0 be 4c
- ab 2c f7 37 2d 98 e3 02 3c 6b b9 24 15 72 3d 58
- ba d6 6c e0 84 e1 01 b6 0f 53 58 35 4b d4 21 82
- 78 ae a7 bf 2c ba ce 33 10 6a ed dc 62 5b 0c 1d
- 5a a6 7a 41 73 9a e5 b5 79 50 97 3f c7 ff 83 01
- 07 3c 6f 95 31 50 fc 30 3e a1 52 d1 e1 0a 2d 1f
- 4f 52 26 da a1 ee 90 05 47 22 52 bd b3 b7 1d 6f
- 0c 3a 34 90 31 6c 46 92 98 71 bd 45 cd fd bc a6
- 11 2f 07 f8 be 71 79 90 d2 5f 6d d7 f2 b7 b3 20
- bf 4d 5a 99 2e 88 03 31 d7 29 94 5a ec 75 ae 5d
- 43 c8 ed a5 fe 62 33 fc ac 49 4e e6 7a 0d 50 4d
- 0b ; Attribute type: AT_MAC
- 05 ; Attribute length: 20 octets (5*4)
- 00 00 ; (reserved)
- fe f3 24 ac ; MAC value
- 39 62 b5 9f
- 3b d7 82 53
- ae 4d cb 6a
-
- The MAC is calculated over the EAP packet above (with MAC value set
- to zero), followed by the NONCE_MT value (a total of 296 bytes).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 85]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-A.6. EAP-Response/SIM/Challenge
-
- The client's response looks like this:
-
- 02 ; Code: Response
- 02 ; Identifier: 2
- 00 1c ; Length: 28 octets
- 12 ; Type: EAP-SIM
- 0b ; EAP-SIM subtype: Challenge
- 00 00 ; (reserved)
- 0b ; Attribute type: AT_MAC
- 05 ; Attribute length: 20 octets (5*4)
- 00 00 ; (reserved)
- f5 6d 64 33 ; MAC value
- e6 8e d2 97
- 6a c1 19 37
- fc 3d 11 54
-
- The MAC is calculated over the EAP packet above (with MAC value set
- to zero), followed by the SRES values (a total of 40 bytes).
-
-A.7. EAP-Success
-
- The last packet is an EAP-Success:
-
- 03 ; Code: Success
- 02 ; Identifier: 2
- 00 04 ; Length: 4 octets
-
-A.8. Fast Re-authentication
-
- When performing fast re-authentication, the EAP-Request/Identity
- packet is the same as usual. The EAP-Response/Identity contains the
- fast re-authentication identity (from AT_ENCR_DATA attribute above):
-
- 02 ; Code: Response
- 00 ; Identifier: 0
- 00 56 ; Length: 86 octets
- 01 ; Type: Identity
- 59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f
- 4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30
- 30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f
- 61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b
- 6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f
- 6f
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 86]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-A.9. EAP-Request/SIM/Re-authentication
-
- The server recognizes the reauthentication identity, so it will
- respond with EAP-Request/SIM/Re-authentication. It retrieves the
- associated counter value, generates a nonce, and picks a new
- reauthentication identity (in this case,
- "uta0M0iyIsMwWp5TTdSdnOLvg2XDVf21OYt1vnfiMcs5dnIDHOIFVavIRzMR
- yzW6vFzdHW@eapsim.foo").
-
- The following plaintext will be encrypted and stored in the
- AT_ENCR_DATA attribute. Note that AT_PADDING is not used because the
- length of the plaintext is a multiple of 16 bytes.
-
- 13 ; Attribute type: AT_COUNTER
- 01 ; Attribute length: 4 octets (1*4)
- 00 01 ; Counter value
- 15 ; Attribute type: AT_NONCE_S
- 05 ; Attribute length: 20 octets (5*4)
- 00 00 ; (reserved)
- 01 23 45 67 ; NONCE_S value
- 89 ab cd ef
- fe dc ba 98
- 76 54 32 10
- 85 ; Attribute type: AT_NEXT_REAUTH_ID
- 16 ; Attribute length: 88 octets (22*4)
- 00 51 ; Actual re-auth identity length: 81 octets
- 75 74 61 30 4d 30 69 79 49 73 4d 77 57 70 35 54
- 54 64 53 64 6e 4f 4c 76 67 32 58 44 56 66 32 31
- 4f 59 74 31 76 6e 66 69 4d 63 73 35 64 6e 49 44
- 48 4f 49 46 56 61 76 49 52 7a 4d 52 79 7a 57 36
- 76 46 7a 64 48 57 40 65 61 70 73 69 6d 2e 66 6f
- 6f
- 00 00 00 ; (attribute padding)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 87]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- The EAP packet looks like this:
-
- 01 ; Code: Request
- 01 ; Identifier: 1
- 00 a4 ; Length: 164 octets
- 12 ; Type: EAP-SIM
- 0d ; EAP-SIM subtype: Re-authentication
- 00 00 ; (reserved)
- 81 ; Attribute type: AT_IV
- 05 ; Attribute length: 20 octets (5*4)
- 00 00 ; (reserved)
- d5 85 ac 77 ; IV value
- 86 b9 03 36
- 65 7c 77 b4
- 65 75 b9 c4
- 82 ; Attribute type: AT_ENCR_DATA
- 1d ; Attribute length: 116 octets (29*4)
- 00 00 ; (reserved)
- 68 62 91 a9 d2 ab c5 8c aa 32 94 b6 e8 5b 44 84
- 6c 44 e5 dc b2 de 8b 9e 80 d6 9d 49 85 8a 5d b8
- 4c dc 1c 9b c9 5c 01 b9 6b 6e ca 31 34 74 ae a6
- d3 14 16 e1 9d aa 9d f7 0f 05 00 88 41 ca 80 14
- 96 4d 3b 30 a4 9b cf 43 e4 d3 f1 8e 86 29 5a 4a
- 2b 38 d9 6c 97 05 c2 bb b0 5c 4a ac e9 7d 5e af
- f5 64 04 6c 8b d3 0b c3 9b e5 e1 7a ce 2b 10 a6
- 0b ; Attribute type: AT_MAC
- 05 ; Attribute length: 20 octets (5*4)
- 00 00 ; (reserved)
- 48 3a 17 99 ; MAC value
- b8 3d 7c d3
- d0 a1 e4 01
- d9 ee 47 70
-
- The MAC is calculated over the EAP packet above (with MAC value set
- to zero; a total of 164 bytes).
-
- Finally, the server derives new keys. The XKEY' is calculated as
- described in Section 7*:
-
- XKEY' = 863dc120 32e08343 c1a2308d b48377f6 801f58d4
-
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 88]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- The new MSK and EMSK are derived using the PRNG (note that K_encr and
- K_aut stay the same).
-
- MSK = 6263f614 973895e1 335f7e30 cff028ee
- 2176f519 002c9abe 732fe0ef 00cf167c
- 756d9e4c ed6d5ed6 40eb3fe3 8565ca07
- 6e7fb8a8 17cfe8d9 adbce441 d47c4f5e
- EMSK = 3d8ff786 3a630b2b 06e2cf20 9684c13f
- 6b82f992 f2b06f1b 54bf51ef 237f2a40
- 1ef5e0d7 e098a34c 533eaebf 34578854
- b7721526 20a777f0 e0340884 a294fb73
-
-A.10. EAP-Response/SIM/Re-authentication
-
- The client's response includes the counter as well. The following
- plaintext will be encrypted and stored in the AT_ENCR_DATA attribute:
-
- 13 ; Attribute type: AT_COUNTER
- 01 ; Attribute length: 4 octets (1*4)
- 00 01 ; Counter value
- 06 ; Attribute type: AT_PADDING
- 03 ; Attribute length: 12 octets (3*4)
- 00 00 00 00
- 00 00 00 00
- 00 00
-
- The EAP packet looks like this:
-
- 02 ; Code: Response
- 01 ; Identifier: 1
- 00 44 ; Length: 68 octets
- 12 ; Type: EAP-SIM
- 0d ; EAP-SIM subtype: Re-authentication
- 00 00 ; (reserved)
- 81 ; Attribute type: AT_IV
- 05 ; Attribute length: 20 octets (5*4)
- 00 00 ; (reserved)
- cd f7 ff a6 ; IV value
- 5d e0 4c 02
- 6b 56 c8 6b
- 76 b1 02 ea
- 82 ; Attribute type: AT_ENCR_DATA
- 05 ; Attribute length: 20 octets (5*4)
- 00 00 ; (reserved)
- b6 ed d3 82
- 79 e2 a1 42
- 3c 1a fc 5c
- 45 5c 7d 56
-
-
-
-Haverinen & Salowey Informational [Page 89]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
- 0b ; Attribute type: AT_MAC
- 05 ; Attribute length: 20 octets (5*4)
- 00 00 ; (reserved)
- fa f7 6b 71 ; MAC value
- fb e2 d2 55
- b9 6a 35 66
- c9 15 c6 17
-
- The MAC is calculated over the EAP packet above (with MAC value set
- to zero), followed by the NONCE_S value (a total of 84 bytes).
-
- The next packet will be EAP-Success:
-
- 03 ; Code: Success
- 01 ; Identifier: 1
- 00 04 ; Length: 4 octets
-
-Appendix B. Pseudo-Random Number Generator
-
- The "|" character denotes concatenation, and "^" denotes
- exponentiation.
-
- Step 1: Choose a new, secret value for the seed-key, XKEY
-
- Step 2: In hexadecimal notation let
- t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0
- This is the initial value for H0|H1|H2|H3|H4
- in the FIPS SHS [SHA-1]
-
- Step 3: For j = 0 to m - 1 do
- 3.1 XSEED_j = 0 /* no optional user input */
- 3.2 For i = 0 to 1 do
- a. XVAL = (XKEY + XSEED_j) mod 2^b
- b. w_i = G(t, XVAL)
- c. XKEY = (1 + XKEY + w_i) mod 2^b
- 3.3 x_j = w_0|w_1
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 90]
-\f
-RFC 4186 EAP-SIM Authentication January 2006
-
-
-Authors' Addresses
-
- Henry Haverinen (editor)
- Nokia Enterprise Solutions
- P.O. Box 12
- FIN-40101 Jyvaskyla
- Finland
-
- EMail: henry.haverinen@nokia.com
-
-
- Joseph Salowey (editor)
- Cisco Systems
- 2901 Third Avenue
- Seattle, WA 98121
- USA
-
- Phone: +1 206 256 3380
- EMail: jsalowey@cisco.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 91]
-\f
-RFC 4186 EAP-SIM Authentication January 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).
-
-
-
-
-
-
-
-Haverinen & Salowey Informational [Page 92]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group J. Arkko
-Request for Comments: 4187 Ericsson
-Category: Informational H. Haverinen
- Nokia
- January 2006
-
-
- Extensible Authentication Protocol Method for 3rd Generation
- Authentication and Key Agreement (EAP-AKA)
-
-Status of This Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-IESG Note
-
- The EAP-AKA protocol was developed by 3GPP. The documentation of
- EAP-AKA is provided as information to the Internet community. While
- the EAP WG has verified that EAP-AKA is compatible with EAP as
- defined in RFC 3748, no other review has been done, including
- validation of the security claims. The IETF has also not reviewed
- the security of the underlying UMTS AKA algorithms.
-
-Abstract
-
- This document specifies an Extensible Authentication Protocol (EAP)
- mechanism for authentication and session key distribution that uses
- the Authentication and Key Agreement (AKA) mechanism. AKA is used in
- the 3rd generation mobile networks Universal Mobile
- Telecommunications System (UMTS) and CDMA2000. AKA is based on
- symmetric keys, and typically runs in a Subscriber Identity Module,
- which is a UMTS Subscriber Identity Module, USIM, or a (Removable)
- User Identity Module, (R)UIM, similar to a smart card.
-
- EAP-AKA includes optional identity privacy support, optional result
- indications, and an optional fast re-authentication procedure.
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 1]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-Table of Contents
-
- 1. Introduction and Motivation .....................................4
- 2. Terms and Conventions Used in This Document .....................5
- 3. Protocol Overview ...............................................9
- 4. Operation ......................................................15
- 4.1. Identity Management .......................................15
- 4.1.1. Format, Generation, and Usage of Peer Identities ...15
- 4.1.2. Communicating the Peer Identity to the Server ......21
- 4.1.3. Choice of Identity for the EAP-Response/Identity ...23
- 4.1.4. Server Operation in the Beginning of
- EAP-AKA Exchange ...................................23
- 4.1.5. Processing of EAP-Request/AKA-Identity by
- the Peer ...........................................24
- 4.1.6. Attacks against Identity Privacy ...................25
- 4.1.7. Processing of AT_IDENTITY by the Server ............26
- 4.2. Message Sequence Examples (Informative) ...................27
- 4.2.1. Usage of AT_ANY_ID_REQ .............................27
- 4.2.2. Fall Back on Full Authentication ...................28
- 4.2.3. Requesting the Permanent Identity 1 ................29
- 4.2.4. Requesting the Permanent Identity 2 ................30
- 4.2.5. Three EAP/AKA-Identity Round Trips .................30
- 5. Fast Re-Authentication .........................................32
- 5.1. General ...................................................32
- 5.2. Comparison to AKA .........................................33
- 5.3. Fast Re-Authentication Identity ...........................33
- 5.4. Fast Re-Authentication Procedure ..........................35
- 5.5. Fast Re-Authentication Procedure when Counter is
- Too Small .................................................37
- 6. EAP-AKA Notifications ..........................................38
- 6.1. General ...................................................38
- 6.2. Result Indications ........................................39
- 6.3. Error Cases ...............................................40
- 6.3.1. Peer Operation .....................................41
- 6.3.2. Server Operation ...................................41
- 6.3.3. EAP-Failure ........................................42
- 6.3.4. EAP-Success ........................................42
- 7. Key Generation .................................................43
- 8. Message Format and Protocol Extensibility ......................45
- 8.1. Message Format ............................................45
- 8.2. Protocol Extensibility ....................................47
- 9. Messages .......................................................48
- 9.1. EAP-Request/AKA-Identity ..................................48
- 9.2. EAP-Response/AKA-Identity .................................48
- 9.3. EAP-Request/AKA-Challenge .................................49
- 9.4. EAP-Response/AKA-Challenge ................................49
- 9.5. EAP-Response/AKA-Authentication-Reject ....................50
- 9.6. EAP-Response/AKA-Synchronization-Failure ..................50
-
-
-
-Arkko & Haverinen Informational [Page 2]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- 9.7. EAP-Request/AKA-Reauthentication ..........................50
- 9.8. EAP-Response/AKA-Reauthentication .........................51
- 9.9. EAP-Response/AKA-Client-Error .............................52
- 9.10. EAP-Request/AKA-Notification .............................52
- 9.11. EAP-Response/AKA-Notification ............................52
- 10. Attributes ....................................................53
- 10.1. Table of Attributes ......................................53
- 10.2. AT_PERMANENT_ID_REQ ......................................54
- 10.3. AT_ANY_ID_REQ ............................................54
- 10.4. AT_FULLAUTH_ID_REQ .......................................54
- 10.5. AT_IDENTITY ..............................................55
- 10.6. AT_RAND ..................................................55
- 10.7. AT_AUTN ..................................................56
- 10.8. AT_RES ...................................................56
- 10.9. AT_AUTS ..................................................57
- 10.10. AT_NEXT_PSEUDONYM .......................................57
- 10.11. AT_NEXT_REAUTH_ID .......................................58
- 10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING .....................58
- 10.13. AT_CHECKCODE ............................................60
- 10.14. AT_RESULT_IND ...........................................62
- 10.15. AT_MAC ..................................................63
- 10.16. AT_COUNTER ..............................................64
- 10.17. AT_COUNTER_TOO_SMALL ....................................64
- 10.18. AT_NONCE_S ..............................................65
- 10.19. AT_NOTIFICATION .........................................65
- 10.20. AT_CLIENT_ERROR_CODE ....................................66
- 11. IANA and Protocol Numbering Considerations ....................66
- 12. Security Considerations .......................................68
- 12.1. Identity Protection ......................................69
- 12.2. Mutual Authentication ....................................69
- 12.3. Flooding the Authentication Centre .......................69
- 12.4. Key Derivation ...........................................70
- 12.5. Brute-Force and Dictionary Attacks .......................70
- 12.6. Protection, Replay Protection, and Confidentiality .......70
- 12.7. Negotiation Attacks ......................................71
- 12.8. Protected Result Indications .............................72
- 12.9. Man-in-the-Middle Attacks ................................72
- 12.10. Generating Random Numbers ...............................73
- 13. Security Claims ...............................................73
- 14. Acknowledgements and Contributions ............................74
- 15. References ....................................................74
- 15.1. Normative References .....................................74
- 15.2. Informative References ...................................76
- Appendix A. Pseudo-Random Number Generator .......................77
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 3]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-1. Introduction and Motivation
-
- This document specifies an Extensible Authentication Protocol (EAP)
- mechanism for authentication and session key distribution that uses
- the 3rd generation Authentication and Key Agreement mechanism,
- specified for Universal Mobile Telecommunications System (UMTS) in
- [TS33.102] and for CDMA2000 in [S.S0055-A]. UMTS and CDMA2000 are
- global 3rd generation mobile network standards that use the same AKA
- mechanism.
-
- 2nd generation mobile networks and 3rd generation mobile networks use
- different authentication and key agreement mechanisms. The Global
- System for Mobile communications (GSM) is a 2nd generation mobile
- network standard, and EAP-SIM [EAP-SIM] specifies an EAP mechanism
- that is based on the GSM authentication and key agreement primitives.
-
- AKA is based on challenge-response mechanisms and symmetric
- cryptography. AKA typically runs in a UMTS Subscriber Identity
- Module (USIM) or a CDMA2000 (Removable) User Identity Module
- ((R)UIM). In this document, both modules are referred to as identity
- modules. Compared to the 2nd generation mechanisms such as GSM AKA,
- the 3rd generation AKA provides substantially longer key lengths and
- mutual authentication.
-
- The introduction of AKA inside EAP allows several new applications.
- These include the following:
-
- o The use of the AKA also as a secure PPP authentication method in
- devices that already contain an identity module.
- o The use of the 3rd generation mobile network authentication
- infrastructure in the context of wireless LANs
- o Relying on AKA and the existing infrastructure in a seamless way
- with any other technology that can use EAP.
-
- AKA works in the following manner:
-
- o The identity module and the home environment have agreed on a
- secret key beforehand. (The "home environment" refers to the home
- operator's authentication network infrastructure.)
- o The actual authentication process starts by having the home
- environment produce an authentication vector, based on the secret
- key and a sequence number. The authentication vector contains a
- random part RAND, an authenticator part AUTN used for
- authenticating the network to the identity module, an expected
- result part XRES, a 128-bit session key for integrity check IK,
- and a 128-bit session key for encryption CK.
-
-
-
-
-
-Arkko & Haverinen Informational [Page 4]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- o The RAND and the AUTN are delivered to the identity module.
- o The identity module verifies the AUTN, again based on the secret
- key and the sequence number. If this process is successful (the
- AUTN is valid and the sequence number used to generate AUTN is
- within the correct range), the identity module produces an
- authentication result RES and sends it to the home environment.
- o The home environment verifies the correct result from the identity
- module. If the result is correct, IK and CK can be used to
- protect further communications between the identity module and the
- home environment.
-
- When verifying AUTN, the identity module may detect that the sequence
- number the network uses is not within the correct range. In this
- case, the identity module calculates a sequence number
- synchronization parameter AUTS and sends it to the network. AKA
- authentication may then be retried with a new authentication vector
- generated using the synchronized sequence number.
-
- For a specification of the AKA mechanisms and how the cryptographic
- values AUTN, RES, IK, CK and AUTS are calculated, see [TS33.102] for
- UMTS and [S.S0055-A] for CDMA2000.
-
- In EAP-AKA, the EAP server node obtains the authentication vectors,
- compares RES and XRES, and uses CK and IK in key derivation.
-
- In the 3rd generation mobile networks, AKA is used for both radio
- network authentication and IP multimedia service authentication
- purposes. Different user identities and formats are used for these;
- the radio network uses the International Mobile Subscriber Identifier
- (IMSI), whereas the IP multimedia service uses the Network Access
- Identifier (NAI) [RFC4282].
-
-2. Terms and 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].
-
- The terms and abbreviations "authenticator", "backend authentication
- server", "EAP server", "peer", "Silently Discard", "Master Session
- Key (MSK)", and "Extended Master Session Key (EMSK)" in this document
- are to be interpreted as described in [RFC3748].
-
- This document frequently uses the following terms and abbreviations.
- The AKA parameters are specified in detail in [TS33.102] for UMTS and
- [S.S0055-A] for CDMA2000.
-
-
-
-
-
-Arkko & Haverinen Informational [Page 5]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- AAA protocol
-
- Authentication, Authorization and Accounting protocol
-
- AKA
-
- Authentication and Key Agreement
-
- AuC
-
- Authentication Centre. The mobile network element that can
- authenticate subscribers in the mobile networks.
-
- AUTN
-
- AKA parameter. AUTN is an authentication value generated by
- the AuC, which, together with the RAND, authenticates the
- server to the peer, 128 bits.
-
- AUTS
-
- AKA parameter. A value generated by the peer upon
- experiencing a synchronization failure, 112 bits.
-
- EAP
-
- Extensible Authentication Protocol [RFC3748]
-
- Fast Re-Authentication
-
- An EAP-AKA authentication exchange that is based on keys
- derived upon a preceding full authentication exchange. The
- 3rd Generation AKA is not used in the fast re-authentication
- procedure.
-
- Fast Re-Authentication Identity
-
- A fast re-authentication identity of the peer, including an
- NAI realm portion in environments where a realm is used.
- Used on re-authentication only.
-
- Fast Re-Authentication Username
-
- The username portion of fast re-authentication identity,
- i.e., not including any realm portions.
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 6]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- Full Authentication
-
- An EAP-AKA authentication exchange that is based on the
- 3rd Generation AKA procedure.
-
- GSM
-
- Global System for Mobile communications.
-
- NAI
-
- Network Access Identifier [RFC4282]
-
- Identity Module
-
- Identity module is used in this document to refer to the
- part of the mobile device that contains authentication and
- key agreement primitives. The identity module may be an
- integral part of the mobile device or it may be an application
- on a smart card distributed by a mobile operator. USIM and
- (R)UIM are identity modules.
-
- Nonce
-
- A value that is used at most once or that is never repeated
- within the same cryptographic context. In general, a nonce can
- be predictable (e.g., a counter) or unpredictable (e.g., a
- random value). Because some cryptographic properties may
- depend on the randomness of the nonce, attention should be paid
- to whether a nonce is required to be random or not. In this
- document, the term nonce is only used to denote random nonces,
- and it is not used to denote counters.
-
- Permanent Identity
-
- The permanent identity of the peer, including an NAI realm
- portion in environments where a realm is used. The permanent
- identity is usually based on the IMSI. Used on full
- authentication only.
-
- Permanent Username
-
- The username portion of permanent identity, i.e., not including
- any realm portions.
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 7]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- Pseudonym Identity
-
- A pseudonym identity of the peer, including an NAI realm
- portion in environments where a realm is used. Used on full
- authentication only.
-
- Pseudonym Username
-
- The username portion of pseudonym identity, i.e., not including
- any realm portions.
-
- RAND
-
- An AKA parameter. Random number generated by the AuC,
- 128 bits.
-
- RES
-
- Authentication result from the peer, which, together with
- the RAND, authenticates the peer to the server,
- 128 bits.
-
- (R)UIM
-
- CDMA2000 (Removable) User Identity Module. (R)UIM is an
- application that is resident on devices such as smart cards,
- which may be fixed in the terminal or distributed by CDMA2000
- operators (when removable).
-
- SQN
-
- An AKA parameter. Sequence number used in the authentication
- process, 48 bits.
-
- SIM
-
- Subscriber Identity Module. The SIM is traditionally a smart
- card distributed by a GSM operator.
-
- SRES
-
- The authentication result parameter in GSM, corresponds to
- the RES parameter in 3G AKA, 32 bits.
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 8]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- UAK
-
- UIM Authentication Key, used in CDMA2000 AKA. Both the
- identity module and the network can optionally generate the UAK
- during the AKA computation in CDMA2000. UAK is not used in
- this version of EAP-AKA.
-
- UIM
-
- Please see (R)UIM.
-
- USIM
-
- UMTS Subscriber Identity Module. USIM is an application that
- is resident on devices such as smart cards distributed by UMTS
- operators.
-
-3. Protocol Overview
-
- Figure 1 shows the basic, successful full authentication exchange in
- EAP-AKA, when optional result indications are not used. The
- authenticator typically communicates with an EAP server that is
- located on a backend authentication server using an AAA protocol.
- The authenticator shown in the figure is often simply relaying EAP
- messages to and from the EAP server, but these backend AAA
- communications are not shown. At the minimum, EAP-AKA uses two
- roundtrips to authenticate and authorize the peer and generate
- session keys. As in other EAP schemes, an identity request/response
- message pair is usually exchanged first. On full authentication, the
- peer's identity response includes either the user's International
- Mobile Subscriber Identity (IMSI), or a temporary identity
- (pseudonym) if identity privacy is in effect, as specified in
- Section 4.1. (As specified in [RFC3748], the initial identity
- request is not required, and MAY be bypassed in cases where the
- network can presume the identity, such as when using leased lines,
- dedicated dial-ups, etc. Please see Section 4.1.2 for specification
- of how to obtain the identity via EAP AKA messages.)
-
- After obtaining the subscriber identity, the EAP server obtains an
- authentication vector (RAND, AUTN, RES, CK, IK) for use in
- authenticating the subscriber. From the vector, the EAP server
- derives the keying material, as specified in Section 6.4. The vector
- may be obtained by contacting an Authentication Centre (AuC) on the
- mobile network; for example, per UMTS specifications, several vectors
- may be obtained at a time. Vectors may be stored in the EAP server
- for use at a later time, but they may not be reused.
-
-
-
-
-
-Arkko & Haverinen Informational [Page 9]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- In CDMA2000, the vector may include a sixth value called the User
- Identity Module Authentication Key (UAK). This key is not used in
- EAP-AKA.
-
- Next, the EAP server starts the actual AKA protocol by sending an
- EAP-Request/AKA-Challenge message. EAP-AKA packets encapsulate
- parameters in attributes, encoded in a Type, Length, Value format.
- The packet format and the use of attributes are specified in
- Section 8. The EAP-Request/AKA-Challenge message contains a RAND
- random number (AT_RAND), a network authentication token (AT_AUTN),
- and a message authentication code (AT_MAC). The EAP-Request/
- AKA-Challenge message MAY optionally contain encrypted data, which is
- used for identity privacy and fast re-authentication support, as
- described in Section 4.1. The AT_MAC attribute contains a message
- authentication code covering the EAP packet. The encrypted data is
- not shown in the figures of this section.
-
- The peer runs the AKA algorithm (typically using an identity module)
- and verifies the AUTN. If this is successful, the peer is talking to
- a legitimate EAP server and proceeds to send the EAP-Response/
- AKA-Challenge. This message contains a result parameter that allows
- the EAP server, in turn, to authenticate the peer, and the AT_MAC
- attribute to integrity protect the EAP message.
-
- The EAP server verifies that the RES and the MAC in the EAP-Response/
- AKA-Challenge packet are correct. Because protected success
- indications are not used in this example, the EAP server sends the
- EAP-Success packet, indicating that the authentication was
- successful. (Protected success indications are discussed in
- Section 6.2.) The EAP server may also include derived keying
- material in the message it sends to the authenticator. The peer has
- derived the same keying material, so the authenticator does not
- forward the keying material to the peer along with EAP-Success.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 10]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- Peer Authenticator
- | EAP-Request/Identity |
- |<------------------------------------------------------|
- | |
- | EAP-Response/Identity |
- | (Includes user's NAI) |
- |------------------------------------------------------>|
- | +------------------------------+
- | | Server runs AKA algorithms, |
- | | generates RAND and AUTN. |
- | +------------------------------+
- | EAP-Request/AKA-Challenge |
- | (AT_RAND, AT_AUTN, AT_MAC) |
- |<------------------------------------------------------|
- +-------------------------------------+ |
- | Peer runs AKA algorithms, | |
- | verifies AUTN and MAC, derives RES | |
- | and session key | |
- +-------------------------------------+ |
- | EAP-Response/AKA-Challenge |
- | (AT_RES, AT_MAC) |
- |------------------------------------------------------>|
- | +--------------------------------+
- | | Server checks the given RES, |
- | | and MAC and finds them correct.|
- | +--------------------------------+
- | EAP-Success |
- |<------------------------------------------------------|
-
- Figure 1: EAP-AKA full authentication procedure
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 11]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- Figure 2 shows how the EAP server rejects the Peer due to a failed
- authentication.
-
- Peer Authenticator
- | EAP-Request/Identity |
- |<------------------------------------------------------|
- | |
- | EAP-Response/Identity |
- | (Includes user's NAI) |
- |------------------------------------------------------>|
- | +------------------------------+
- | | Server runs AKA algorithms, |
- | | generates RAND and AUTN. |
- | +------------------------------+
- | EAP-Request/AKA-Challenge |
- | (AT_RAND, AT_AUTN, AT_MAC) |
- |<------------------------------------------------------|
- +-------------------------------------+ |
- | Peer runs AKA algorithms, | |
- | possibly verifies AUTN, and sends an| |
- | invalid response | |
- +-------------------------------------+ |
- | EAP-Response/AKA-Challenge |
- | (AT_RES, AT_MAC) |
- |------------------------------------------------------>|
- | +------------------------------------------+
- | | Server checks the given RES and the MAC, |
- | | and finds one of them incorrect. |
- | +------------------------------------------+
- | EAP-Request/AKA-Notification |
- |<------------------------------------------------------|
- | EAP-Response/AKA-Notification |
- |------------------------------------------------------>|
- | EAP-Failure |
- |<------------------------------------------------------|
-
- Figure 2: Peer authentication fails
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 12]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- Figure 3 shows the peer rejecting the AUTN of the EAP server.
-
- The peer sends an explicit error message (EAP-Response/
- AKA-Authentication-Reject) to the EAP server, as usual in AKA when
- AUTN is incorrect. This allows the EAP server to produce the same
- error statistics that AKA generally produces in UMTS or CDMA2000.
-
- Peer Authenticator
- | EAP-Request/Identity |
- |<------------------------------------------------------|
- | EAP-Response/Identity |
- | (Includes user's NAI) |
- |------------------------------------------------------>|
- | +------------------------------+
- | | Server runs AKA algorithms, |
- | | generates RAND and a bad AUTN|
- | +------------------------------+
- | EAP-Request/AKA-Challenge |
- | (AT_RAND, AT_AUTN, AT_MAC) |
- |<------------------------------------------------------|
- +-------------------------------------+ |
- | Peer runs AKA algorithms | |
- | and discovers AUTN that can not be | |
- | verified | |
- +-------------------------------------+ |
- | EAP-Response/AKA-Authentication-Reject |
- |------------------------------------------------------>|
- | EAP-Failure |
- |<------------------------------------------------------|
-
- Figure 3: Network authentication fails
-
- The AKA uses shared secrets between the Peer and the Peer's home
- operator, together with a sequence number, to actually perform an
- authentication. In certain circumstances, shown in Figure 4, it is
- possible for the sequence numbers to get out of sequence.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 13]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- Peer Authenticator
- | EAP-Request/Identity |
- |<------------------------------------------------------|
- | EAP-Response/Identity |
- | (Includes user's NAI) |
- |------------------------------------------------------>|
- | +------------------------------+
- | | Server runs AKA algorithms, |
- | | generates RAND and AUTN. |
- | +------------------------------+
- | EAP-Request/AKA-Challenge |
- | (AT_RAND, AT_AUTN, AT_MAC) |
- |<------------------------------------------------------|
- +-------------------------------------+ |
- | Peer runs AKA algorithms | |
- | and discovers AUTN that contains an | |
- | inappropriate sequence number | |
- +-------------------------------------+ |
- | EAP-Response/AKA-Synchronization-Failure |
- | (AT_AUTS) |
- |------------------------------------------------------>|
- | +---------------------------+
- | | Perform resynchronization |
- | | Using AUTS and |
- | | the sent RAND |
- | +---------------------------+
- | |
-
- Figure 4: Sequence number synchronization
-
- After the resynchronization process has taken place in the server and
- AAA side, the process continues by the server side sending a new
- EAP-Request/AKA-Challenge message.
-
- In addition to the full authentication scenarios described above,
- EAP-AKA includes a fast re-authentication procedure, which is
- specified in Section 5. Fast re-authentication is based on keys
- derived on full authentication. If the peer has maintained state
- information for re-authentication and wants to use fast
- re-authentication, then the peer indicates this by using a specific
- fast re-authentication identity instead of the permanent identity or
- a pseudonym identity.
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 14]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-4. Operation
-
-4.1. Identity Management
-
-4.1.1. Format, Generation, and Usage of Peer Identities
-
-4.1.1.1. General
-
- In the beginning of EAP authentication, the Authenticator or the EAP
- server usually issues the EAP-Request/Identity packet to the peer.
- The peer responds with EAP-Response/Identity, which contains the
- user's identity. The formats of these packets are specified in
- [RFC3748].
-
- Subscribers of mobile networks are identified with the International
- Mobile Subscriber Identity (IMSI) [TS23.003]. The IMSI is a string
- of not more than 15 digits. It is composed of a Mobile Country Code
- (MCC) of 3 digits, a Mobile Network Code (MNC) of 2 or 3 digits, and
- a Mobile Subscriber Identification Number (MSIN) of not more than 10
- digits. MCC and MNC uniquely identify the GSM operator and help
- identify the AuC from which the authentication vectors need to be
- retrieved for this subscriber.
-
- Internet AAA protocols identify users with the Network Access
- Identifier (NAI) [RFC4282]. When used in a roaming environment, the
- NAI is composed of a username and a realm, separated with "@"
- (username@realm). The username portion identifies the subscriber
- within the realm.
-
- This section specifies the peer identity format used in EAP-AKA. In
- this document, the term identity or peer identity refers to the whole
- identity string that is used to identify the peer. The peer identity
- may include a realm portion. "Username" refers to the portion of the
- peer identity that identifies the user, i.e., the username does not
- include the realm portion.
-
-4.1.1.2. Identity Privacy Support
-
- EAP-AKA includes optional identity privacy (anonymity) support that
- can be used to hide the cleartext permanent identity and thereby make
- the subscriber's EAP exchanges untraceable to eavesdroppers. Because
- the permanent identity never changes, revealing it would help
- observers to track the user. The permanent identity is usually based
- on the IMSI, which may further help the tracking, because the same
- identifier may be used in other contexts as well. Identity privacy
- is based on temporary identities, or pseudonyms, which are equivalent
-
-
-
-
-
-Arkko & Haverinen Informational [Page 15]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- to but separate from the Temporary Mobile Subscriber Identities
- (TMSI) that are used on cellular networks. Please see Section 12.1
- for security considerations regarding identity privacy.
-
-4.1.1.3. Username Types in EAP-AKA Identities
-
- There are three types of usernames in EAP-AKA peer identities:
-
- (1) Permanent usernames. For example,
- 0123456789098765@myoperator.com might be a valid permanent identity.
- In this example, 0123456789098765 is the permanent username.
-
- (2) Pseudonym usernames. For example, 2s7ah6n9q@myoperator.com might
- be a valid pseudonym identity. In this example, 2s7ah6n9q is the
- pseudonym username.
-
- (3) Fast re-authentication usernames. For example,
- 43953754@myoperator.com might be a valid fast re-authentication
- identity. In this case, 43953754 is the fast re-authentication
- username. Unlike permanent usernames and pseudonym usernames, fast
- re-authentication usernames are one-time identifiers, which are not
- re-used across EAP exchanges.
-
- The first two types of identities are used only on full
- authentication, and the last type only on fast re-authentication.
- When the optional identity privacy support is not used, the
- non-pseudonym permanent identity is used on full authentication. The
- fast re-authentication exchange is specified in Section 5.
-
-4.1.1.4. Username Decoration
-
- In some environments, the peer may need to decorate the identity by
- prepending or appending the username with a string, in order to
- indicate supplementary AAA routing information in addition to the NAI
- realm. (The usage of an NAI realm portion is not considered to be
- decoration.) Username decoration is out of the scope of this
- document. However, it should be noted that username decoration might
- prevent the server from recognizing a valid username. Hence,
- although the peer MAY use username decoration in the identities that
- the peer includes in EAP-Response/Identity, and although the EAP
- server MAY accept a decorated peer username in this message, the peer
- or the EAP server MUST NOT decorate any other peer identities that
- are used in various EAP-AKA attributes. Only the identity used in
- EAP-Response/Identity may be decorated.
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 16]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-4.1.1.5. NAI Realm Portion
-
- The peer MAY include a realm portion in the peer identity, as per the
- NAI format. The use of a realm portion is not mandatory.
-
- If a realm is used, the realm MAY be chosen by the subscriber's home
- operator and it MAY be a configurable parameter in the EAP-AKA peer
- implementation. In this case, the peer is typically configured with
- the NAI realm of the home operator. Operators MAY reserve a specific
- realm name for EAP-AKA users. This convention makes it easy to
- recognize that the NAI identifies an AKA subscriber. Such a reserved
- NAI realm may be useful as a hint of the first authentication method
- to use during method negotiation. When the peer is using a pseudonym
- username instead of the permanent username, the peer selects the
- realm name portion similarly to how it selects the realm portion when
- using the permanent username.
-
- If no configured realm name is available, the peer MAY derive the
- realm name from the MCC and MNC portions of the IMSI. A RECOMMENDED
- way to derive the realm from the IMSI, using the realm
- 3gppnetwork.org, will be specified in [TS23.003].
-
- Some old implementations derive the realm name from the IMSI by
- concatenating "mnc", the MNC digits of IMSI, ".mcc", the MCC digits
- of IMSI, and ".owlan.org". For example, if the IMSI is
- 123456789098765, and the MNC is three digits long, then the derived
- realm name is "mnc456.mcc123.owlan.org". As there are no DNS servers
- running at owlan.org, these realm names can only be used with
- manually configured AAA routing. New implementations SHOULD use the
- mechanism specified in [TS23.003] instead of owlan.org.
-
- The IMSI is a string of digits without any explicit structure, so the
- peer may not be able to determine the length of the MNC portion. If
- the peer is not able to determine whether the MNC is two or three
- digits long, the peer MAY use a 3-digit MNC. If the correct length
- of the MNC is two, then the MNC used in the realm name includes the
- first digit of MSIN. Hence, when configuring AAA networks for
- operators that have 2-digit MNC's, the network SHOULD also be
- prepared for realm names with incorrect 3-digit MNC's.
-
-4.1.1.6. Format of the Permanent Username
-
- The non-pseudonym permanent username SHOULD be derived from the IMSI.
- In this case, the permanent username MUST be of the format "0" |
- IMSI, where the character "|" denotes concatenation. In other words,
- the first character of the username is the digit zero (ASCII value 30
- hexadecimal), followed by the IMSI. The IMSI is an ASCII string that
- consists of not more than 15 decimal digits (ASCII values between 30
-
-
-
-Arkko & Haverinen Informational [Page 17]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- and 39 hexadecimal), one character per IMSI digit, in the order as
- specified in [TS23.003]. For example, a permanent username derived
- from the IMSI 295023820005424 would be encoded as the ASCII string
- "0295023820005424" (byte values in hexadecimal notation: 30 32 39 35
- 30 32 33 38 32 30 30 30 35 34 32 34)
-
- The EAP server MAY use the leading "0" as a hint to try EAP-AKA as
- the first authentication method during method negotiation, rather
- than using, for example, EAP-SIM. The EAP-AKA server MAY propose
- EAP-AKA even if the leading character was not "0".
-
- Alternatively, an implementation MAY choose a permanent username that
- is not based on the IMSI. In this case the selection of the
- username, its format, and its processing is out of the scope of this
- document. In this case, the peer implementation MUST NOT prepend any
- leading characters to the username.
-
-4.1.1.7. Generating Pseudonyms and Fast Re-Authentication Identities by
- the Server
-
- Pseudonym usernames and fast re-authentication identities are
- generated by the EAP server. The EAP server produces pseudonym
- usernames and fast re-authentication identities in an
- implementation-dependent manner. Only the EAP server needs to be
- able to map the pseudonym username to the permanent identity, or to
- recognize a fast re-authentication identity.
-
- EAP-AKA includes no provisions to ensure that the same EAP server
- that generated a pseudonym username will be used on the
- authentication exchange when the pseudonym username is used. It is
- recommended that the EAP servers implement some centralized mechanism
- to allow all EAP servers of the home operator to map pseudonyms
- generated by other severs to the permanent identity. If no such
- mechanism is available, then the EAP server, failing to understand a
- pseudonym issued by another server, can request the peer to send the
- permanent identity.
-
- When issuing a fast re-authentication identity, the EAP server may
- include a realm name in the identity that will cause the fast
- re-authentication request to be forwarded to the same EAP server.
-
- When generating fast re-authentication identities, the server SHOULD
- choose a fresh, new fast re-authentication identity that is different
- from the previous ones that were used after the same full
- authentication exchange. A full authentication exchange and the
- associated fast re-authentication exchanges are referred to here as
- the same "full authentication context". The fast re-authentication
- identity SHOULD include a random component. The random component
-
-
-
-Arkko & Haverinen Informational [Page 18]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- works as a full authentication context identifier. A context-
- specific fast re-authentication identity can help the server to
- detect whether its fast re-authentication state information matches
- the peer's fast re-authentication state information (in other words,
- whether the state information is from the same full authentication
- exchange). The random component also makes the fast re-
- authentication identities unpredictable, so an attacker cannot
- initiate a fast re-authentication exchange to get the server's
- EAP-Request/AKA-Reauthentication packet.
-
- Transmitting pseudonyms and fast re-authentication identities from
- the server to the peer is discussed in Section 4.1.1.8. The
- pseudonym is transmitted as a username, without an NAI realm, and the
- fast re-authentication identity is transmitted as a complete NAI,
- including a realm portion if a realm is required. The realm is
- included in the fast re-authentication identity in order to allow the
- server to include a server-specific realm.
-
- Regardless of construction method, the pseudonym username MUST
- conform to the grammar specified for the username portion of an NAI.
- Also, the fast re-authentication identity MUST conform to the NAI
- grammar. The EAP servers that the subscribers of an operator can use
- MUST ensure that the pseudonym usernames and the username portions
- used in fast re-authentication identities that they generate are
- unique.
-
- In any case, it is necessary that permanent usernames, pseudonym
- usernames, and fast re-authentication usernames are separate and
- recognizable from each other. It is also desirable that EAP-SIM and
- EAP-AKA usernames be recognizable from each other as an aid to the
- server when deciding which method to offer.
-
- In general, it is the task of the EAP server and the policies of its
- administrator to ensure sufficient separation of the usernames.
- Pseudonym usernames and fast re-authentication usernames are both
- produced and used by the EAP server. The EAP server MUST compose
- pseudonym usernames and fast re-authentication usernames so that it
- can recognize if an NAI username is an EAP-AKA pseudonym username or
- an EAP-AKA fast re-authentication username. For instance, when the
- usernames have been derived from the IMSI, the server could use
- different leading characters in the pseudonym usernames and fast
- re-authentication usernames (e.g., the pseudonym could begin with a
- leading "2" character). When mapping a fast re-authentication
- identity to a permanent identity, the server SHOULD only examine the
- username portion of the fast re-authentication identity and ignore
- the realm portion of the identity.
-
-
-
-
-
-Arkko & Haverinen Informational [Page 19]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- Because the peer may fail to save a pseudonym username that was sent
- in an EAP-Request/AKA-Challenge (for example, due to malfunction),
- the EAP server SHOULD maintain, at least, the most recently used
- pseudonym username in addition to the most recently issued pseudonym
- username. If the authentication exchange is not completed
- successfully, then the server SHOULD NOT overwrite the pseudonym
- username that was issued during the most recent successful
- authentication exchange.
-
-4.1.1.8. Transmitting Pseudonyms and Fast Re-Authentication Identities
- to the Peer
-
- The server transmits pseudonym usernames and fast re-authentication
- identities to the peer in cipher, using the AT_ENCR_DATA attribute.
-
- The EAP-Request/AKA-Challenge message MAY include an encrypted
- pseudonym username and/or an encrypted fast re-authentication
- identity in the value field of the AT_ENCR_DATA attribute. Because
- identity privacy support and fast re-authentication are optional to
- implement, the peer MAY ignore the AT_ENCR_DATA attribute and always
- use the permanent identity. On fast re-authentication (discussed in
- Section 5), the server MAY include a new, encrypted fast re-
- authentication identity in the EAP-Request/AKA-Reauthentication
- message.
-
- On receipt of the EAP-Request/AKA-Challenge, the peer MAY decrypt the
- encrypted data in AT_ENCR_DATA; and if a pseudonym username is
- included, the peer may use the obtained pseudonym username on the
- next full authentication. If a fast re-authentication identity is
- included, then the peer MAY save it together with other fast re-
- authentication state information, as discussed in Section 5, for the
- next fast re-authentication.
-
- If the peer does not receive a new pseudonym username in the
- EAP-Request/AKA-Challenge message, the peer MAY use an old pseudonym
- username instead of the permanent username on next full
- authentication. The username portions of fast re-authentication
- identities are one-time usernames, which the peer MUST NOT re-use.
- When the peer uses a fast re-authentication identity in an EAP
- exchange, the peer MUST discard the fast re-authentication identity
- and not re-use it in another EAP authentication exchange, even if the
- authentication exchange was not completed.
-
-4.1.1.9. Usage of the Pseudonym by the Peer
-
- When the optional identity privacy support is used on full
- authentication, the peer MAY use a pseudonym username received as
- part of a previous full authentication sequence as the username
-
-
-
-Arkko & Haverinen Informational [Page 20]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- portion of the NAI. The peer MUST NOT modify the pseudonym username
- received in AT_NEXT_PSEUDONYM. However, as discussed above, the peer
- MAY need to decorate the username in some environments by appending
- or prepending the username with a string that indicates supplementary
- AAA routing information.
-
- When using a pseudonym username in an environment where a realm
- portion is used, the peer concatenates the received pseudonym
- username with the "@" character and an NAI realm portion. The
- selection of the NAI realm is discussed above. The peer can select
- the realm portion similarly, regardless of whether it uses the
- permanent username or a pseudonym username.
-
-4.1.1.10. Usage of the Fast Re-Authentication Identity by the Peer
-
- On fast re-authentication, the peer uses the fast re-authentication
- identity received as part of the previous authentication sequence. A
- new fast re-authentication identity may be delivered as part of both
- full authentication and fast re-authentication. The peer MUST NOT
- modify the username part of the fast re-authentication identity
- received in AT_NEXT_REAUTH_ID, except in cases when username
- decoration is required. Even in these cases, the "root" fast
- re-authentication username must not be modified, but it may be
- appended or prepended with another string.
-
-4.1.2. Communicating the Peer Identity to the Server
-
-4.1.2.1. General
-
- The peer identity MAY be communicated to the server with the
- EAP-Response/Identity message. This message MAY contain the
- permanent identity, a pseudonym identity, or a fast re-authentication
- identity. If the peer uses the permanent identity or a pseudonym
- identity, which the server is able to map to the permanent identity,
- then the authentication proceeds as discussed in the overview of
- Section 3. If the peer uses a fast re-authentication identity, and
- if the fast re-authentication identity matches with a valid fast
- re-authentication identity maintained by the server, then a fast
- re-authentication exchange is performed, as described in Section 5.
-
- The peer identity can also be transmitted from the peer to the server
- using EAP-AKA messages instead of EAP-Response/Identity. In this
- case, the server includes an identity requesting attribute
- (AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the
- EAP-Request/AKA-Identity message; and the peer includes the
- AT_IDENTITY attribute, which contains the peer's identity, in the
- EAP-Response/AKA-Identity message. The AT_ANY_ID_REQ attribute is a
- general identity requesting attribute, which the server uses if it
-
-
-
-Arkko & Haverinen Informational [Page 21]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- does not specify which kind of an identity the peer should return in
- AT_IDENTITY. The server uses the AT_FULLAUTH_ID_REQ attribute to
- request either the permanent identity or a pseudonym identity. The
- server uses the AT_PERMANENT_ID_REQ attribute to request that the
- peer send its permanent identity. The EAP-Request/AKA-Challenge,
- EAP-Response/AKA-Challenge, or the packets used on fast re-
- authentication may optionally include the AT_CHECKCODE attribute,
- which enables the protocol peers to ensure the integrity of the
- AKA-Identity packets. AT_CHECKCODE is specified in Section 10.13.
-
- The identity format in the AT_IDENTITY attribute is the same as in
- the EAP-Response/Identity packet (except that identity decoration is
- not allowed). The AT_IDENTITY attribute contains a permanent
- identity, a pseudonym identity, or a fast re-authentication identity.
-
- Please note that only the EAP-AKA peer and the EAP-AKA server process
- the AT_IDENTITY attribute and entities that pass through; EAP packets
- do not process this attribute. Hence, the authenticator and other
- intermediate AAA elements (such as possible AAA proxy servers) will
- continue to refer to the peer with the original identity from the
- EAP-Response/Identity packet unless the identity authenticated in the
- AT_IDENTITY attribute is communicated to them in another way within
- the AAA protocol.
-
-4.1.2.2. Relying on EAP-Response/Identity Discouraged
-
- The EAP-Response/Identity packet is not method specific; therefore,
- in many implementations it may be handled by an EAP Framework. This
- introduces an additional layer of processing between the EAP peer and
- EAP server. The extra layer of processing may cache identity
- responses or add decorations to the identity. A modification of the
- identity response will cause the EAP peer and EAP server to use
- different identities in the key derivation, which will cause the
- protocol to fail.
-
- For this reason, it is RECOMMENDED that the EAP peer and server use
- the method-specific identity attributes in EAP-AKA, and the server is
- strongly discouraged from relying upon the EAP-Response/Identity.
-
- In particular, if the EAP server receives a decorated identity in
- EAP-Response/Identity, then the EAP server MUST use the
- identity-requesting attributes to request the peer to send an
- unmodified and undecorated copy of the identity in AT_IDENTITY.
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 22]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-4.1.3. Choice of Identity for the EAP-Response/Identity
-
- If EAP-AKA peer is started upon receiving an EAP-Request/Identity
- message, then the peer MAY use an EAP-AKA identity in the EAP-
- Response/Identity packet. In this case, the peer performs the
- following steps.
-
- If the peer has maintained fast re-authentication state information
- and if the peer wants to use fast re-authentication, then the peer
- transmits the fast re-authentication identity in
- EAP-Response/Identity.
-
- Else, if the peer has a pseudonym username available, then the peer
- transmits the pseudonym identity in EAP-Response/Identity.
-
- In other cases, the peer transmits the permanent identity in
- EAP-Response/Identity.
-
-4.1.4. Server Operation in the Beginning of EAP-AKA Exchange
-
- As discussed in Section 4.1.2.2, the server SHOULD NOT rely on an
- identity string received in EAP-Response/Identity. Therefore, the
- RECOMMENDED way to start an EAP-AKA exchange is to ignore any
- received identity strings. The server SHOULD begin the EAP-AKA
- exchange by issuing the EAP-Request/AKA-Identity packet with an
- identity-requesting attribute to indicate that the server wants the
- peer to include an identity in the AT_IDENTITY attribute of the EAP-
- Response/AKA-Identity message. Three methods to request an identity
- from the peer are discussed below.
-
- If the server chooses to not ignore the contents of
- EAP-Response/Identity, then the server may already receive an EAP-AKA
- identity in this packet. However, if the EAP server has not received
- any EAP-AKA peer identity (permanent identity, pseudonym identity, or
- fast re-authentication identity) from the peer when sending the first
- EAP-AKA request, or if the EAP server has received an
- EAP-Response/Identity packet but the contents do not appear to be a
- valid permanent identity, pseudonym identity, or a re-authentication
- identity, then the server MUST request an identity from the peer
- using one of the methods below.
-
- The server sends the EAP-Request/AKA-Identity message with the
- AT_PERMANENT_ID_REQ attribute to indicate that the server wants the
- peer to include the permanent identity in the AT_IDENTITY attribute
- of the EAP-Response/AKA-Identity message. This is done in the
- following cases:
-
-
-
-
-
-Arkko & Haverinen Informational [Page 23]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- o The server does not support fast re-authentication or identity
- privacy.
- o The server decided to process a received identity, and the server
- recognizes the received identity as a pseudonym identity, but the
- server is not able to map the pseudonym identity to a permanent
- identity.
-
- The server issues the EAP-Request/AKA-Identity packet with the
- AT_FULLAUTH_ID_REQ attribute to indicate that the server wants the
- peer to include a full authentication identity (pseudonym identity or
- permanent identity) in the AT_IDENTITY attribute of the
- EAP-Response/AKA-Identity message. This is done in the following
- cases:
-
- o The server does not support fast re-authentication and the server
- supports identity privacy
- o The server decided to process a received identity, and the server
- recognizes the received identity as a re-authentication identity
- but the server is not able to map the re-authentication identity
- to a permanent identity
-
- The server issues the EAP-Request/AKA-Identity packet with the
- AT_ANY_ID_REQ attribute to indicate that the server wants the peer to
- include an identity in the AT_IDENTITY attribute of the
- EAP-Response/AKA-Identity message, and the server does not indicate
- any preferred type for the identity. This is done in other cases,
- such as when the server ignores a received EAP-Response/Identity,
- when the server does not have any identity, or when the server does
- not recognize the format of a received identity.
-
-4.1.5. Processing of EAP-Request/AKA-Identity by the Peer
-
- Upon receipt of an EAP-Request/AKA-Identity message, the peer MUST
- perform the following steps.
-
- If the EAP-Request/AKA-Identity includes AT_PERMANENT_ID_REQ, and if
- the peer does not have a pseudonym available, then the peer MUST
- respond with EAP-Response/AKA-Identity and include the permanent
- identity in AT_IDENTITY. If the peer has a pseudonym available, then
- the peer MAY refuse to send the permanent identity; hence, in this
- case the peer MUST either respond with EAP-Response/AKA-Identity and
- include the permanent identity in AT_IDENTITY or respond with
- EAP-Response/AKA-Client-Error packet with code "unable to process
- packet".
-
- If the EAP-Request/AKA-Identity includes AT_FULL_AUTH_ID_REQ, and if
- the peer has a pseudonym available, then the peer SHOULD respond with
- EAP-Response/AKA-Identity and include the pseudonym identity in
-
-
-
-Arkko & Haverinen Informational [Page 24]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- AT_IDENTITY. If the peer does not have a pseudonym when it receives
- this message, then the peer MUST respond with EAP-Response/
- AKA-Identity and include the permanent identity in AT_IDENTITY. The
- Peer MUST NOT use a fast re-authentication identity in the
- AT_IDENTITY attribute.
-
- If the EAP-Request/AKA-Identity includes AT_ANY_ID_REQ, and if the
- peer has maintained fast re-authentication state information and
- wants to use fast re-authentication, then the peer responds with
- EAP-Response/AKA-Identity and includes the fast re-authentication
- identity in AT_IDENTITY. Else, if the peer has a pseudonym identity
- available, then the peer responds with EAP-Response/AKA-Identity and
- includes the pseudonym identity in AT_IDENTITY. Else, the peer
- responds with EAP-Response/AKA-Identity and includes the permanent
- identity in AT_IDENTITY.
-
- An EAP-AKA exchange may include several EAP/AKA-Identity rounds. The
- server may issue a second EAP-Request/AKA-Identity, if it was not
- able to recognize the identity the peer used in the previous
- AT_IDENTITY attribute. At most three EAP/AKA-Identity rounds can be
- used, so the peer MUST NOT respond to more than three
- EAP-Request/AKA-Identity messages within an EAP exchange. The peer
- MUST verify that the sequence of EAP-Request/AKA-Identity packets the
- peer receives comply with the sequencing rules defined in this
- document. That is, AT_ANY_ID_REQ can only be used in the first
- EAP-Request/AKA-Identity; in other words, AT_ANY_ID_REQ MUST NOT be
- used in the second or third EAP-Request/AKA-Identity.
- AT_FULLAUTH_ID_REQ MUST NOT be used if the previous
- EAP-Request/AKA-Identity included AT_PERMANENT_ID_REQ. The peer
- operation, in cases when it receives an unexpected attribute or an
- unexpected message, is specified in Section 6.3.1.
-
-4.1.6. Attacks against Identity Privacy
-
- The section above specifies two possible ways the peer can operate
- upon receipt of AT_PERMANENT_ID_REQ because a received
- AT_PERMANENT_ID_REQ does not necessarily originate from the valid
- network. However, an active attacker may transmit an
- EAP-Request/AKA-Identity packet with an AT_PERMANENT_ID_REQ attribute
- to the peer, in an effort to find out the true identity of the user.
- If the peer does not want to reveal its permanent identity, then the
- peer sends the EAP-Response/AKA-Client-Error packet with the error
- code "unable to process packet", and the authentication exchange
- terminates.
-
- Basically, there are two different policies that the peer can employ
- with regard to AT_PERMANENT_ID_REQ. A "conservative" peer assumes
- that the network is able to maintain pseudonyms robustly. Therefore,
-
-
-
-Arkko & Haverinen Informational [Page 25]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- if a conservative peer has a pseudonym username, the peer responds
- with EAP-Response/AKA-Client-Error to the EAP packet with
- AT_PERMANENT_ID_REQ, because the peer believes that the valid network
- is able to map the pseudonym identity to the peer's permanent
- identity. (Alternatively, the conservative peer may accept
- AT_PERMANENT_ID_REQ in certain circumstances, for example if the
- pseudonym was received a long time ago.) The benefit of this policy
- is that it protects the peer against active attacks on anonymity. On
- the other hand, a "liberal" peer always accepts the
- AT_PERMANENT_ID_REQ and responds with the permanent identity. The
- benefit of this policy is that it works even if the valid network
- sometimes loses pseudonyms and is not able to map them to the
- permanent identity.
-
-4.1.7. Processing of AT_IDENTITY by the Server
-
- When the server receives an EAP-Response/AKA-Identity message with
- the AT_IDENTITY (in response to the server's identity requesting
- attribute), the server MUST operate as follows.
-
- If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does
- not contain a valid permanent identity, then the server sends an
- EAP-Request/AKA-Notification packet with AT_NOTIFICATION code
- "General failure" (16384) to terminate the EAP exchange. If the
- server recognizes the permanent identity and is able to continue,
- then the server proceeds with full authentication by sending
- EAP-Request/AKA-Challenge.
-
- If the server used AT_FULLAUTH_ID_REQ, and if AT_IDENTITY contains a
- valid permanent identity or a pseudonym identity that the server can
- map to a valid permanent identity, then the server proceeds with full
- authentication by sending EAP-Request/AKA-Challenge. If AT_IDENTITY
- contains a pseudonym identity that the server is not able to map to a
- valid permanent identity, or an identity that the server is not able
- to recognize or classify, then the server sends EAP-Request/
- AKA-Identity with AT_PERMANENT_ID_REQ.
-
- If the server used AT_ANY_ID_REQ, and if the AT_IDENTITY contains a
- valid permanent identity or a pseudonym identity that the server can
- map to a valid permanent identity, then the server proceeds with full
- authentication by sending EAP-Request/ AKA-Challenge.
-
- If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid
- fast re-authentication identity and the server agrees on using
- re-authentication, then the server proceeds with fast
- re-authentication by sending EAP-Request/AKA-Reauthentication
- (Section 5).
-
-
-
-
-Arkko & Haverinen Informational [Page 26]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- If the server used AT_ANY_ID_REQ, and if the peer sent an EAP-
- Response/AKA-Identity with AT_IDENTITY that contains an identity that
- the server recognizes as a fast re-authentication identity, but the
- server is not able to map the identity to a permanent identity, then
- the server sends EAP-Request/AKA-Identity with AT_FULLAUTH_ID_REQ.
-
- If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid
- fast re-authentication identity, which the server is able to map to a
- permanent identity, and if the server does not want to use fast
- re-authentication, then the server proceeds with full authentication
- by sending EAP-Request/AKA-Challenge.
-
- If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an
- identity that the server recognizes as a pseudonym identity but the
- server is not able to map the pseudonym identity to a permanent
- identity, then the server sends EAP-Request/AKA-Identity with
- AT_PERMANENT_ID_REQ.
-
- If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an
- identity that the server is not able to recognize or classify, then
- the server sends EAP-Request/AKA-Identity with AT_FULLAUTH_ID_REQ.
-
-4.2. Message Sequence Examples (Informative)
-
- This section contains non-normative message sequence examples to
- illustrate how the peer identity can be communicated to the server.
-
-4.2.1. Usage of AT_ANY_ID_REQ
-
- Obtaining the peer identity with EAP-AKA attributes is illustrated in
- Figure 5 below.
-
- Peer Authenticator
- | |
- | +------------------------------+
- | | Server does not have any |
- | | Subscriber identity available|
- | | When starting EAP-AKA |
- | +------------------------------+
- | EAP-Request/AKA-Identity |
- | (AT_ANY_ID_REQ) |
- |<------------------------------------------------------|
- | |
- | EAP-Response/AKA-Identity |
- | (AT_IDENTITY) |
- |------------------------------------------------------>|
- | |
- Figure 5: Usage of AT_ANY_ID_REQ
-
-
-
-Arkko & Haverinen Informational [Page 27]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-4.2.2. Fall Back on Full Authentication
-
- Figure 6 illustrates the case when the server does not recognize the
- fast re-authentication identity the peer used in AT_IDENTITY.
-
- Peer Authenticator
- | |
- | +------------------------------+
- | | Server does not have any |
- | | Subscriber identity available|
- | | When starting EAP-AKA |
- | +------------------------------+
- | EAP-Request/AKA-Identity |
- | (AT_ANY_ID_REQ) |
- |<------------------------------------------------------|
- | |
- | EAP-Response/AKA-Identity |
- | (AT_IDENTITY containing a fast re-auth. identity) |
- |------------------------------------------------------>|
- | +------------------------------+
- | | Server does not recognize |
- | | The fast re-auth. |
- | | Identity |
- | +------------------------------+
- | EAP-Request/AKA-Identity |
- | (AT_FULLAUTH_ID_REQ) |
- |<------------------------------------------------------|
- | EAP-Response/AKA-Identity |
- | (AT_IDENTITY with a full-auth. Identity) |
- |------------------------------------------------------>|
- | |
-
- Figure 6: Fall back on full authentication
-
- If the server recognizes the fast re-authentication identity, but
- still wants to fall back on full authentication, the server may issue
- the EAP-Request/AKA-Challenge packet. In this case, the full
- authentication procedure proceeds as usual.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 28]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-4.2.3. Requesting the Permanent Identity 1
-
- Figure 7 illustrates the case when the EAP server fails to decode a
- pseudonym identity included in the EAP-Response/Identity packet.
-
- Peer Authenticator
- | EAP-Request/Identity |
- |<------------------------------------------------------|
- | EAP-Response/Identity |
- | (Includes a pseudonym) |
- |------------------------------------------------------>|
- | +------------------------------+
- | | Server fails to decode the |
- | | Pseudonym. |
- | +------------------------------+
- | EAP-Request/AKA-Identity |
- | (AT_PERMANENT_ID_REQ) |
- |<------------------------------------------------------|
- | |
- | EAP-Response/AKA-Identity |
- | (AT_IDENTITY with permanent identity) |
- |------------------------------------------------------>|
- | |
-
- Figure 7: Requesting the permanent identity 1
-
- If the server recognizes the permanent identity, then the
- authentication sequence proceeds as usual with the EAP Server issuing
- the EAP-Request/AKA-Challenge message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 29]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-4.2.4. Requesting the Permanent Identity 2
-
- Figure 8 illustrates the case when the EAP server fails to decode the
- pseudonym included in the AT_IDENTITY attribute.
-
- Peer Authenticator
- | |
- | +------------------------------+
- | | Server does not have any |
- | | Subscriber identity available|
- | | When starting EAP-AKA |
- | +------------------------------+
- | EAP-Request/AKA-Identity |
- | (AT_ANY_ID_REQ) |
- |<------------------------------------------------------|
- | |
- |EAP-Response/AKA-Identity |
- |(AT_IDENTITY with a pseudonym identity) |
- |------------------------------------------------------>|
- | +------------------------------+
- | | Server fails to decode the |
- | | Pseudonym in AT_IDENTITY |
- | +------------------------------+
- | EAP-Request/AKA-Identity |
- | (AT_PERMANENT_ID_REQ) |
- |<------------------------------------------------------|
- | EAP-Response/AKA-Identity |
- | (AT_IDENTITY with permanent identity) |
- |------------------------------------------------------>|
- | |
-
- Figure 8: Requesting the permanent identity 2
-
-4.2.5. Three EAP/AKA-Identity Round Trips
-
- Figure 9 illustrates the case with three EAP/AKA-Identity round
- trips.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 30]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- Peer Authenticator
- | |
- | +------------------------------+
- | | Server does not have any |
- | | Subscriber identity available|
- | | When starting EAP-AKA |
- | +------------------------------+
- | EAP-Request/AKA-Identity |
- | (AT_ANY_ID_REQ) |
- |<------------------------------------------------------|
- | |
- | EAP-Response/AKA-Identity |
- | (AT_IDENTITY with fast re-auth. identity) |
- |------------------------------------------------------>|
- | +------------------------------+
- | | Server does not accept |
- | | The fast re-authentication |
- | | Identity |
- | +------------------------------+
- | |
- : :
- : :
-
-
- : :
- : :
- | EAP-Request/AKA-Identity |
- | (AT_FULLAUTH_ID_REQ) |
- |<------------------------------------------------------|
- |EAP-Response/AKA-Identity |
- |(AT_IDENTITY with a pseudonym identity) |
- |------------------------------------------------------>|
- | +------------------------------+
- | | Server fails to decode the |
- | | Pseudonym in AT_IDENTITY |
- | +------------------------------+
- | EAP-Request/AKA-Identity |
- | (AT_PERMANENT_ID_REQ) |
- |<------------------------------------------------------|
- | EAP-Response/AKA-Identity |
- | (AT_IDENTITY with permanent identity) |
- |------------------------------------------------------>|
- | |
-
- Figure 9: Three EAP-AKA Start rounds
-
- After the last EAP-Response/AKA-Identity message, the full
- authentication sequence proceeds as usual.
-
-
-
-Arkko & Haverinen Informational [Page 31]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-5. Fast Re-Authentication
-
-5.1. General
-
- In some environments, EAP authentication may be performed frequently.
- Because the EAP-AKA full authentication procedure uses the AKA
- algorithms, and therefore requires fresh authentication vectors from
- the Authentication Centre, the full authentication procedure may
- result in many network operations when used very frequently.
- Therefore, EAP-AKA includes a more inexpensive fast re-authentication
- procedure that does not make use of the AKA algorithms and does not
- need new vectors from the Authentication Centre.
-
- Fast re-authentication is optional to implement for both the EAP-AKA
- server and peer. On each EAP authentication, either one of the
- entities may fall back on full authentication if is does not want to
- use fast re-authentication.
-
- Fast re-authentication is based on the keys derived on the preceding
- full authentication. The same K_aut and K_encr keys used in full
- authentication are used to protect EAP-AKA packets and attributes,
- and the original Master Key from full authentication is used to
- generate a fresh Master Session Key, as specified in Section 7.
-
- The fast re-authentication exchange makes use of an unsigned 16-bit
- counter, included in the AT_COUNTER attribute. The counter has three
- goals: 1) it can be used to limit the number of successive
- reauthentication exchanges without full-authentication 2) it
- contributes to the keying material, and 3) it protects the peer and
- the server from replays. On full authentication, both the server and
- the peer initialize the counter to one. The counter value of at
- least one is used on the first fast re-authentication. On subsequent
- fast re-authentications, the counter MUST be greater than on any of
- the previous fast re-authentications. For example, on the second
- fast re-authentication, counter value is two or greater, etc. The
- AT_COUNTER attribute is encrypted.
-
- Both the peer and the EAP server maintain a copy of the counter. The
- EAP server sends its counter value to the peer in the fast
- re-authentication request. The peer MUST verify that its counter
- value is less than or equal to the value sent by the EAP server.
-
- The server includes an encrypted server random nonce (AT_NONCE_S) in
- the fast re-authentication request. The AT_MAC attribute in the
- peer's response is calculated over NONCE_S to provide a
- challenge/response authentication scheme. The NONCE_S also
- contributes to the new Master Session Key.
-
-
-
-
-Arkko & Haverinen Informational [Page 32]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- Both the peer and the server SHOULD have an upper limit for the
- number of subsequent fast re-authentications allowed before a full
- authentication needs to be performed. Because a 16-bit counter is
- used in fast re-authentication, the theoretical maximum number of
- re-authentications is reached when the counter value reaches FFFF
- hexadecimal. In order to use fast re-authentication, the peer and
- the EAP server need to store the following values: Master Key, latest
- counter value and the next fast re-authentication identity. K_aut
- and K_encr may either be stored or derived again from MK. The server
- may also need to store the permanent identity of the user.
-
-5.2. Comparison to AKA
-
- When analyzing the fast re-authentication exchange, it may be helpful
- to compare it with the 3rd generation Authentication and Key
- Agreement (AKA) exchange used on full authentication. The counter
- corresponds to the AKA sequence number, NONCE_S corresponds to RAND,
- the AT_MAC in EAP-Request/AKA-Reauthentication corresponds to AUTN,
- the AT_MAC in EAP-Response/AKA-Reauthentication corresponds to RES,
- AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the counter
- corresponds to the usage of the Anonymity Key. Also, the key
- generation on fast re-authentication, with regard to random or fresh
- material, is similar to AKA -- the server generates the NONCE_S and
- counter values, and the peer only verifies that the counter value is
- fresh.
-
- It should also be noted that encrypting the AT_NONCE_S, AT_COUNTER,
- or AT_COUNTER_TOO_SMALL attributes is not important to the security
- of the fast re-authentication exchange.
-
-5.3. Fast Re-Authentication Identity
-
- The fast re-authentication procedure makes use of separate
- re-authentication user identities. Pseudonyms and the permanent
- identity are reserved for full authentication only. If a fast
- re-authentication identity is lost and the network does not recognize
- it, the EAP server can fall back on full authentication. If the EAP
- server supports fast re-authentication, it MAY include the skippable
- AT_NEXT_REAUTH_ID attribute in the encrypted data of EAP- Request/-
- AKA-Challenge message. This attribute contains a new
- re-authentication identity for the next fast re-authentication. The
- attribute also works as a capability flag that indicates that the
- server supports fast re-authentication and that the server wants to
- continue using fast re-authentication within the current context.
- The peer MAY ignore this attribute, in which case it will use full
- authentication next time. If the peer wants to use fast
- re-authentication, it uses this fast re-authentication identity on
- next authentication. Even if the peer has a fast re-authentication
-
-
-
-Arkko & Haverinen Informational [Page 33]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- identity, the peer MAY discard the re-authentication identity and use
- a pseudonym or the permanent identity instead, in which case full
- authentication MUST be performed. If the EAP server does not include
- the AT_NEXT_REAUTH_ID in the encrypted data of
- EAP-Request/AKA-Challenge or EAP-Request/AKA-Reauthentication, then
- the peer MUST discard its current fast re-authentication state
- information and perform a full authentication next time.
-
- In environments where a realm portion is needed in the peer identity,
- the fast re-authentication identity received in AT_NEXT_REAUTH_ID
- MUST contain both a username portion and a realm portion, as per the
- NAI format. The EAP Server can choose an appropriate realm part in
- order to have the AAA infrastructure route subsequent fast
- re-authentication-related requests to the same AAA server. For
- example, the realm part MAY include a portion that is specific to the
- AAA server. Hence, it is sufficient to store the context required
- for fast re-authentication in the AAA server that performed the full
- authentication.
-
- The peer MAY use the fast re-authentication identity in the
- EAP-Response/Identity packet or, in response to the server's
- AT_ANY_ID_REQ attribute, the peer MAY use the fast re-authentication
- identity in the AT_IDENTITY attribute of the EAP-Response/
- AKA-Identity packet.
-
- The peer MUST NOT modify the username portion of the fast
- re-authentication identity, but the peer MAY modify the realm portion
- or replace it with another realm portion. The peer might need to
- modify the realm in order to influence the AAA routing, for example,
- to make sure that the correct server is reached. It should be noted
- that sharing the same fast re-authentication key among several
- servers may have security risks, so changing the realm portion of the
- NAI in order to change the EAP server is not desirable.
-
- Even if the peer uses a fast re-authentication identity, the server
- may want to fall back on full authentication, for example, because
- the server does not recognize the fast re-authentication identity or
- does not want to use fast re-authentication. If the server was able
- to decode the fast re-authentication identity to the permanent
- identity, the server issues the EAP-Request/AKA-Challenge packet to
- initiate full authentication. If the server was not able to recover
- the peer's identity from the fast re-authentication identity, the
- server starts the full authentication procedure by issuing an
- EAP-Request/AKA-Identity packet. This packet always starts a full
- authentication sequence if it does not include the AT_ANY_ID_REQ
- attribute.
-
-
-
-
-
-Arkko & Haverinen Informational [Page 34]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-5.4. Fast Re-Authentication Procedure
-
- Figure 10 illustrates the fast re-authentication procedure. In this
- example, the optional protected success indication is not used.
- Encrypted attributes are denoted with '*'. The peer uses its fast
- re-authentication identity in the EAP-Response/Identity packet. As
- discussed above, an alternative way to communicate the fast
- re-authentication identity to the server is for the peer to use the
- AT_IDENTITY attribute in the EAP-Response/AKA-Identity message. This
- latter case is not illustrated in the figure below, and it is only
- possible when the server requests that the peer send its identity by
- including the AT_ANY_ID_REQ attribute in the EAP-Request/AKA-Identity
- packet.
-
- If the server recognizes the identity as a valid fast
- re-authentication identity, and if the server agrees to use fast
- re-authentication, then the server sends the EAP- Request/AKA-
- Reauthentication packet to the peer. This packet MUST include the
- encrypted AT_COUNTER attribute, with a fresh counter value, the
- encrypted AT_NONCE_S attribute that contains a random number chosen
- by the server, the AT_ENCR_DATA and the AT_IV attributes used for
- encryption, and the AT_MAC attribute that contains a message
- authentication code over the packet. The packet MAY also include an
- encrypted AT_NEXT_REAUTH_ID attribute that contains the next fast
- re-authentication identity.
-
- Fast re-authentication identities are one-time identities. If the
- peer does not receive a new fast re-authentication identity, it MUST
- use either the permanent identity or a pseudonym identity on the next
- authentication to initiate full authentication.
-
- The peer verifies that AT_MAC is correct and that the counter value
- is fresh (greater than any previously used value). The peer MAY save
- the next fast re-authentication identity from the encrypted
- AT_NEXT_REAUTH_ID for next time. If all checks are successful, the
- peer responds with the EAP-Response/AKA-Reauthentication packet,
- including the AT_COUNTER attribute with the same counter value and
- the AT_MAC attribute.
-
- The server verifies the AT_MAC attribute and also verifies that the
- counter value is the same that it used in the
- EAP-Request/AKA-Reauthentication packet. If these checks are
- successful, the fast re-authentication has succeeded and the server
- sends the EAP-Success packet to the peer.
-
- If protected success indications (Section 6.2) were used, the
- EAP-Success packet would be preceded by an EAP-AKA notification
- round.
-
-
-
-Arkko & Haverinen Informational [Page 35]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- Peer Authenticator
- | |
- | EAP-Request/Identity |
- |<------------------------------------------------------|
- | |
- | EAP-Response/Identity |
- | (Includes a fast re-authentication identity) |
- |------------------------------------------------------>|
- | +--------------------------------+
- | | Server recognizes the identity |
- | | and agrees on using fast |
- | | re-authentication |
- | +--------------------------------+
- | EAP-Request/AKA-Reauthentication |
- | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, |
- | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) |
- |<------------------------------------------------------|
- | |
- : :
- : :
-
-
- : :
- : :
- | |
- +-----------------------------------------------+ |
- | Peer verifies AT_MAC and the freshness of | |
- | the counter. Peer MAY store the new re- | |
- | authentication identity for next re-auth. | |
- +-----------------------------------------------+ |
- | |
- | EAP-Response/AKA-Reauthentication |
- | (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, |
- | AT_MAC) |
- |------------------------------------------------------>|
- | +--------------------------------+
- | | Server verifies AT_MAC and |
- | | the counter |
- | +--------------------------------+
- | EAP-Success |
- |<------------------------------------------------------|
- | |
-
- Figure 10: Reauthentication
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 36]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-5.5. Fast Re-Authentication Procedure when Counter is Too Small
-
- If the peer does not accept the counter value of EAP-Request/
- AKA-Reauthentication, it indicates the counter synchronization
- problem by including the encrypted AT_COUNTER_TOO_SMALL in
- EAP-Response/AKA-Reauthentication. The server responds with
- EAP-Request/AKA-Challenge to initiate a normal full authentication
- procedure. This is illustrated in Figure 11. Encrypted attributes
- are denoted with '*'.
-
- Peer Authenticator
- | EAP-Request/AKA-Identity |
- | (AT_ANY_ID_REQ) |
- |<------------------------------------------------------|
- | |
- | EAP-Response/AKA-Identity |
- | (AT_IDENTITY) |
- | (Includes a fast re-authentication identity) |
- |------------------------------------------------------>|
- | |
- | EAP-Request/AKA-Reauthentication |
- | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, |
- | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) |
- |<------------------------------------------------------|
- +-----------------------------------------------+ |
- | AT_MAC is valid but the counter is not fresh. | |
- +-----------------------------------------------+ |
- | EAP-Response/AKA-Reauthentication |
- | (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL, |
- | *AT_COUNTER, AT_MAC) |
- |------------------------------------------------------>|
- | +----------------------------------------------+
- | | Server verifies AT_MAC but detects |
- | | That peer has included AT_COUNTER_TOO_SMALL|
- | +----------------------------------------------+
- | EAP-Request/AKA-Challenge |
- |<------------------------------------------------------|
- +---------------------------------------------------------------+
- | Normal full authentication follows. |
- +---------------------------------------------------------------+
- | |
-
- Figure 11: Fast re-authentication counter too small
-
- In the figure above, the first three messages are similar to the
- basic fast re-authentication case. When the peer detects that the
- counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL
- attribute in EAP-Response/AKA-Reauthentication. This attribute
-
-
-
-Arkko & Haverinen Informational [Page 37]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- doesn't contain any data but it is a request for the server to
- initiate full authentication. In this case, the peer MUST ignore the
- contents of the server's AT_NEXT_REAUTH_ID attribute.
-
- On receipt of AT_COUNTER_TOO_SMALL, the server verifies AT_MAC and
- verifies that AT_COUNTER contains the same counter value as in the
- EAP-Request/AKA-Reauthentication packet. If not, the server
- terminates the authentication exchange by sending the
- EAP-Request/AKA-Notification packet with AT_NOTIFICATION code
- "General failure" (16384). If all checks on the packet are
- successful, the server transmits an EAP-Request/AKA-Challenge packet
- and the full authentication procedure is performed as usual. Because
- the server already knows the subscriber identity, it MUST NOT use the
- EAP-Request/AKA-Identity packet to request the identity.
-
- It should be noted that in this case, peer identity is only
- transmitted in the AT_IDENTITY attribute at the beginning of the
- whole EAP exchange. The fast re-authentication identity used in this
- AT_IDENTITY attribute will be used in key derivation (see Section 7).
-
-6. EAP-AKA Notifications
-
-6.1. General
-
- EAP-AKA does not prohibit the use of the EAP Notifications as
- specified in [RFC3748]. EAP Notifications can be used at any time in
- the EAP-AKA exchange. It should be noted that EAP-AKA does not
- protect EAP Notifications. EAP-AKA also specifies method-specific
- EAP-AKA notifications, which are protected in some cases.
-
- The EAP server can use EAP-AKA notifications to convey notifications
- and result indications (Section 6.2) to the peer.
-
- The server MUST use notifications in cases discussed in
- Section 6.3.2. When the EAP server issues an
- EAP-Request/AKA-Notification packet to the peer, the peer MUST
- process the notification packet. The peer MAY show a notification
- message to the user and the peer MUST respond to the EAP server with
- an EAP-Response/AKA-Notification packet, even if the peer did not
- recognize the notification code.
-
- An EAP-AKA full authentication exchange or a fast re-authentication
- exchange MUST NOT include more than one EAP-AKA notification round.
-
- The notification code is a 16-bit number. The most significant bit
- is called the Success bit (S bit). The S bit specifies whether the
- notification implies failure. The code values with the S bit set to
- zero (code values 0...32767) are used on unsuccessful cases. The
-
-
-
-Arkko & Haverinen Informational [Page 38]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- receipt of a notification code from this range implies failed EAP
- exchange, so the peer can use the notification as a failure
- indication. After receiving the EAP-Response/AKA-Notification for
- these notification codes, the server MUST send the EAP-Failure
- packet.
-
- The receipt of a notification code with the S bit set to one (values
- 32768...65536) does not imply failure. Notification code "Success"
- (32768) has been reserved as a general notification code to indicate
- successful authentication.
-
- The second most significant bit of the notification code is called
- the Phase bit (P bit). It specifies at which phase of the EAP-AKA
- exchange the notification can be used. If the P bit is set to zero,
- the notification can only be used after a successful EAP/AKA-
- Challenge round in full authentication or a successful EAP/AKA-
- Reauthentication round in re-authentication. A re-authentication
- round is considered successful only if the peer has successfully
- verified AT_MAC and AT_COUNTER attributes, and does not include the
- AT_COUNTER_TOO_SMALL attribute in EAP-Response/AKA-Reauthentication.
-
- If the P bit is set to one, the notification can only by used before
- the EAP/AKA-Challenge round in full authentication or before the
- EAP/AKA-Reauthentication round in reauthentication. These
- notifications can only be used to indicate various failure cases. In
- other words, if the P bit is set to one, then the S bit MUST be set
- to zero.
-
- Section 9.10 and Section 9.11 specify what other attributes must be
- included in the notification packets.
-
- Some of the notification codes are authorization related and hence
- not usually considered as part of the responsibility of an EAP
- method. However, they are included as part of EAP-AKA because there
- are currently no other ways to convey this information to the user in
- a localizable way, and the information is potentially useful for the
- user. An EAP-AKA server implementation may decide never to send
- these EAP-AKA notifications.
-
-6.2. Result Indications
-
- As discussed in Section 6.3, the server and the peer use explicit
- error messages in all error cases. If the server detects an error
- after successful authentication, the server uses an EAP-AKA
- notification to indicate failure to the peer. In this case, the
- result indication is integrity and replay protected.
-
-
-
-
-
-Arkko & Haverinen Informational [Page 39]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- By sending an EAP-Response/AKA-Challenge packet or an
- EAP-Response/AKA-Reauthentication packet (without
- AT_COUNTER_TOO_SMALL), the peer indicates that it has successfully
- authenticated the server and that the peer's local policy accepts the
- EAP exchange. In other words, these packets are implicit success
- indications from the peer to the server.
-
- EAP-AKA also supports optional protected success indications from the
- server to the peer. If the EAP server wants to use protected success
- indications, it includes the AT_RESULT_IND attribute in the
- EAP-Request/AKA-Challenge or the EAP-Request/AKA-Reauthentication
- packet. This attribute indicates that the EAP server would like to
- use result indications in both successful and unsuccessful cases. If
- the peer also wants this, the peer includes AT_RESULT_IND in
- EAP-Response/AKA-Challenge or EAP-Response/AKA-Reauthentication. The
- peer MUST NOT include AT_RESULT_IND if it did not receive
- AT_RESULT_IND from the server. If both the peer and the server used
- AT_RESULT_IND, then the EAP exchange is not complete yet, but an
- EAP-AKA notification round will follow. The following EAP-AKA
- notification may indicate either failure or success.
-
- Success indications with the AT_NOTIFICATION code "Success" (32768)
- can only be used if both the server and the peer indicate they want
- to use them with AT_RESULT_IND. If the server did not include
- AT_RESULT_IND in the EAP-Request/AKA-Challenge or
- EAP-Request/AKA-Reauthentication packet, or if the peer did not
- include AT_RESULT_IND in the corresponding response packet, then the
- server MUST NOT use protected success indications.
-
- Because the server uses the AT_NOTIFICATION code "Success" (32768) to
- indicate that the EAP exchange has completed successfully, the EAP
- exchange cannot fail when the server processes the EAP-AKA response
- to this notification. Hence, the server MUST ignore the contents of
- the EAP-AKA response it receives to the EAP-Request/AKA-Notification
- with this code. Regardless of the contents of the EAP-AKA response,
- the server MUST send EAP-Success as the next packet.
-
-6.3. Error Cases
-
- This section specifies the operation of the peer and the server in
- error cases. The subsections below require the EAP-AKA peer and
- server to send an error packet (EAP-Response/AKA-Client-Error,
- EAP-Response/AKA-Authentication-Reject or
- EAP-Response/AKA-Synchronization-Failure from the peer and
- EAP-Request/AKA-Notification from the server) in error cases.
- However, implementations SHOULD NOT rely upon the correct error
- reporting behavior of the peer, authenticator, or server. It is
- possible for error messages and other messages to be lost in transit,
-
-
-
-Arkko & Haverinen Informational [Page 40]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- or for a malicious participant to attempt to consume resources by not
- issuing error messages. Both the peer and the EAP server SHOULD have
- a mechanism to clean up state even if an error message or EAP-Success
- is not received after a timeout period.
-
-6.3.1. Peer Operation
-
- Two special error messages have been specified for error cases that
- are related to the processing of the AKA AUTN parameter, as described
- in Section 3: (1) if the peer does not accept AUTN, the peer responds
- with EAP-Response/AKA-Authentication-Reject (Section 9.5), and the
- server issues EAP-Failure, and (2) if the peer detects that the
- sequence number in AUTN is not correct, the peer responds with
- EAP-Response/AKA-Synchronization-Failure (Section 9.6), and the
- server proceeds with a new EAP-Request/AKA-Challenge.
-
- In other error cases, when an EAP-AKA peer detects an error in a
- received EAP-AKA packet, the EAP-AKA peer responds with the
- EAP-Response/AKA-Client-Error packet. In response to the
- EAP-Response/AKA-Client-Error, the EAP server MUST issue the
- EAP-Failure packet, and the authentication exchange terminates.
-
- By default, the peer uses the client error code 0, "unable to process
- packet". This error code is used in the following cases:
-
- o EAP exchange is not acceptable according to the peer's local
- policy.
- o The peer is not able to parse the EAP request, i.e., the EAP
- request is malformed.
- o The peer encountered a malformed attribute.
- o Wrong attribute types or duplicate attributes have been included
- in the EAP request.
- o A mandatory attribute is missing.
- o Unrecognized non-skippable attribute.
- o Unrecognized or unexpected EAP-AKA Subtype in the EAP request.
- o Invalid AT_MAC. The peer SHOULD log this event.
- o Invalid AT_CHECKCODE. The peer SHOULD log this event.
- o Invalid pad bytes in AT_PADDING.
- o The peer does not want to process AT_PERMANENT_ID_REQ.
-
-6.3.2. Server Operation
-
- If an EAP-AKA server detects an error in a received EAP-AKA response,
- the server MUST issue the EAP-Request/AKA-Notification packet with an
- AT_NOTIFICATION code that implies failure. By default, the server
- uses one of the general failure codes ("General failure after
- authentication" (0) or "General failure" (16384)). The choice
-
-
-
-
-Arkko & Haverinen Informational [Page 41]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- between these two codes depends on the phase of the EAP-AKA exchange,
- see Section 6. The error cases when the server issues an
- EAP-Request/AKA-Notification that implies failure include the
- following:
-
- o The server is not able to parse the peer's EAP response.
- o The server encounters a malformed attribute, a non-recognized
- non-skippable attribute, or a duplicate attribute.
- o A mandatory attribute is missing or an invalid attribute was
- included.
- o Unrecognized or unexpected EAP-AKA Subtype in the EAP Response.
- o Invalid AT_MAC. The server SHOULD log this event.
- o Invalid AT_CHECKCODE. The server SHOULD log this event.
- o Invalid AT_COUNTER.
-
-6.3.3. EAP-Failure
-
- The EAP-AKA server sends EAP-Failure in three cases:
-
- 1. In response to an EAP-Response/AKA-Client-Error packet the server
- has received from the peer, or
-
- 2. In response to an EAP-Response/AKA-Authentication-Reject packet
- the server has received from the peer, or
-
- 3. Following an EAP-AKA notification round, when the AT_NOTIFICATION
- code implies failure.
-
- The EAP-AKA server MUST NOT send EAP-Failure in other cases than
- these three. However, it should be noted that even though the
- EAP-AKA server would not send an EAP-Failure, an authorization
- decision that happens outside EAP-AKA, such as in the AAA server or
- in an intermediate AAA proxy, may result in a failed exchange.
-
- The peer MUST accept the EAP-Failure packet in case 1), case 2), and
- case 3) above. The peer SHOULD silently discard the EAP-Failure
- packet in other cases.
-
-6.3.4. EAP-Success
-
- On full authentication, the server can only send EAP-Success after
- the EAP/AKA-Challenge round. The peer MUST silently discard any
- EAP-Success packets if they are received before the peer has
- successfully authenticated the server and sent the
- EAP-Response/AKA-Challenge packet.
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 42]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- If the peer did not indicate that it wants to use protected success
- indications with AT_RESULT_IND (as discussed in Section 6.2) on full
- authentication, then the peer MUST accept EAP-Success after a
- successful EAP/AKA-Challenge round.
-
- If the peer indicated that it wants to use protected success
- indications with AT_RESULT_IND (as discussed in Section 6.2), then
- the peer MUST NOT accept EAP-Success after a successful EAP/
- AKA-Challenge round. In this case, the peer MUST only accept
- EAP-Success after receiving an EAP-AKA Notification with the
- AT_NOTIFICATION code "Success" (32768).
-
- On fast re-authentication, EAP-Success can only be sent after the
- EAP/AKA-Reauthentication round. The peer MUST silently discard any
- EAP-Success packets if they are received before the peer has
- successfully authenticated the server and sent the
- EAP-Response/AKA-Reauthentication packet.
-
- If the peer did not indicate that it wants to use protected success
- indications with AT_RESULT_IND (as discussed in Section 6.2) on fast
- re-authentication, then the peer MUST accept EAP-Success after a
- successful EAP/AKA-Reauthentication round.
-
- If the peer indicated that it wants to use protected success
- indications with AT_RESULT_IND (as discussed in Section 6.2), then
- the peer MUST NOT accept EAP-Success after a successful EAP/AKA-
- Reauthentication round. In this case, the peer MUST only accept
- EAP-Success after receiving an EAP-AKA Notification with the
- AT_NOTIFICATION code "Success" (32768).
-
- If the peer receives an EAP-AKA notification (Section 6) that
- indicates failure, then the peer MUST no longer accept the
- EAP-Success packet, even if the server authentication was
- successfully completed.
-
-7. Key Generation
-
- This section specifies how keying material is generated.
-
- On EAP-AKA full authentication, a Master Key (MK) is derived from the
- underlying AKA values (CK and IK keys), and the identity, as follows.
-
- MK = SHA1(Identity|IK|CK)
-
- In the formula above, the "|" character denotes concatenation.
- Identity denotes the peer identity string without any terminating
- null characters. It is the identity from the last AT_IDENTITY
- attribute sent by the peer in this exchange, or, if AT_IDENTITY was
-
-
-
-Arkko & Haverinen Informational [Page 43]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- not used, the identity from the EAP-Response/Identity packet. The
- identity string is included as-is, without any changes. As discussed
- in Section 4.1.2.2, relying on EAP-Response/Identity for conveying
- the EAP-AKA peer identity is discouraged, and the server SHOULD use
- the EAP-AKA method-specific identity attributes. The hash function
- SHA-1 is specified in [SHA-1].
-
- The Master Key is fed into a Pseudo-Random number Function (PRF),
- which generates separate Transient EAP Keys (TEKs) for protecting
- EAP-AKA packets, as well as a Master Session Key (MSK) for link layer
- security and an Extended Master Session Key (EMSK) for other
- purposes. On fast re-authentication, the same TEKs MUST be used for
- protecting EAP packets, but a new MSK and a new EMSK MUST be derived
- from the original MK and from new values exchanged in the fast
- re-authentication.
-
- EAP-AKA requires two TEKs for its own purposes: the authentication
- key K_aut, to be used with the AT_MAC attribute, and the encryption
- key K_encr, to be used with the AT_ENCR_DATA attribute. The same
- K_aut and K_encr keys are used in full authentication and subsequent
- fast re-authentications.
-
- Key derivation is based on the random number generation specified in
- NIST Federal Information Processing Standards (FIPS) Publication
- 186-2 [PRF]. The pseudo-random number generator is specified in the
- change notice 1 (2001 October 5) of [PRF] (Algorithm 1). As
- specified in the change notice (page 74), when Algorithm 1 is used as
- a general-purpose pseudo-random number generator, the "mod q" term in
- step 3.3 is omitted. The function G used in the algorithm is
- constructed via Secure Hash Standard as specified in Appendix 3.3 of
- the standard. It should be noted that the function G is very similar
- to SHA-1, but the message padding is different. Please refer to
- [PRF] for full details. For convenience, the random number algorithm
- with the correct modification is cited in Annex A.
-
- 160-bit XKEY and XVAL values are used, so b = 160. On each full
- authentication, the Master Key is used as the initial secret seed-key
- XKEY. The optional user input values (XSEED_j) in step 3.1 are set
- to zero.
-
- On full authentication, the resulting 320-bit random numbers x_0,
- x_1, ..., x_m-1 are concatenated and partitioned into suitable-sized
- chunks and used as keys in the following order: K_encr (128 bits),
- K_aut (128 bits), Master Session Key (64 bytes), Extended Master
- Session Key (64 bytes).
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 44]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- On fast re-authentication, the same pseudo-random number generator
- can be used to generate a new Master Session Key and a new Extended
- Master Session Key. The seed value XKEY' is calculated as follows:
-
- XKEY' = SHA1(Identity|counter|NONCE_S| MK)
-
- In the formula above, the Identity denotes the fast re-authentication
- identity, without any terminating null characters, from the
- AT_IDENTITY attribute of the EAP-Response/AKA-Identity packet, or, if
- EAP-Response/AKA-Identity was not used on fast re-authentication, it
- denotes the identity string from the EAP-Response/Identity packet.
- The counter denotes the counter value from the AT_COUNTER attribute
- used in the EAP-Response/AKA-Reauthentication packet. The counter is
- used in network byte order. NONCE_S denotes the 16-byte random
- NONCE_S value from the AT_NONCE_S attribute used in the
- EAP-Request/AKA-Reauthentication packet. The MK is the Master Key
- derived on the preceding full authentication.
-
- On fast re-authentication, the pseudo-random number generator is run
- with the new seed value XKEY', and the resulting 320-bit random
- numbers x_0, x_1, ..., x_m-1 are concatenated and partitioned into
- 64-byte chunks and used as the new 64-byte Master Session Key and the
- new 64-byte Extended Master Session Key. Note that because K_encr
- and K_aut are not derived on fast re-authentication, the Master
- Session Key and the Extended Master Session key are obtained from the
- beginning of the key stream x_0, x_1, ....
-
- The first 32 bytes of the MSK can be used as the Pairwise Master Key
- (PMK) for IEEE 802.11i.
-
- When the RADIUS attributes specified in [RFC2548] are used to
- transport keying material, then the first 32 bytes of the MSK
- correspond to MS-MPPE-RECV-KEY and the second 32 bytes to
- MS-MPPE-SEND-KEY. In this case, only 64 bytes of keying material
- (the MSK) are used.
-
-8. Message Format and Protocol Extensibility
-
-8.1. Message Format
-
- As specified in [RFC3748], EAP packets begin with the Code,
- Identifiers, Length, and Type fields, which are followed by
- EAP-method-specific Type-Data. The Code field in the EAP header is
- set to 1 for EAP requests, and to 2 for EAP Responses. The usage of
- the Length and Identifier fields in the EAP header is also specified
- in [RFC3748]. In EAP-AKA, the Type field is set to 23.
-
-
-
-
-
-Arkko & Haverinen Informational [Page 45]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- In EAP-AKA, the Type-Data begins with an EAP-AKA header that consists
- of a 1-octet Subtype field, and a 2-octet reserved field. The
- Subtype values used in EAP-AKA are defined in Section 11. The
- formats of the EAP header and the EAP-AKA header are shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Subtype | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The rest of the Type-Data, immediately following the EAP-AKA header,
- consists of attributes that are encoded in Type, Length, Value
- format. The figure below shows the generic format of an attribute.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |Attribute Type | Length | Value...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Attribute Type
-
- Indicates the particular type of attribute. The attribute type
- values are listed in Section 11.
-
- Length
-
- Indicates the length of this attribute in multiples of 4 bytes.
- The maximum length of an attribute is 1024 bytes. The length
- includes the Attribute Type and Length bytes.
-
- Value
-
- The particular data associated with this attribute. This field
- is always included and it is two or more bytes in length. The
- type and length fields determine the format and length of the
- value field.
-
- Attributes numbered within the range 0 through 127 are called
- non-skippable attributes. When an EAP-AKA peer encounters a
- non-skippable attribute type that the peer does not recognize, the
- peer MUST send the EAP-Response/AKA-Client-Error packet, and the
- authentication exchange terminates. If an EAP-AKA server encounters
- a non-skippable attribute that the server does not recognize, then
- the server sends EAP-Request/AKA-Notification packet with an
-
-
-
-Arkko & Haverinen Informational [Page 46]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- AT_NOTIFICATION code that implies general failure ("General failure
- after authentication" (0), or "General failure" (16384), depending on
- the phase of the exchange), and the authentication exchange
- terminates.
-
- When an attribute numbered in the range 128 through 255 is
- encountered but not recognized, that particular attribute is ignored,
- but the rest of the attributes and message data MUST still be
- processed. The Length field of the attribute is used to skip the
- attribute value when searching for the next attribute. These
- attributes are called skippable attributes.
-
- Unless otherwise specified, the order of the attributes in an EAP-AKA
- message is insignificant, and an EAP-AKA implementation should not
- assume a certain order will be used.
-
- Attributes can be encapsulated within other attributes. In other
- words, the value field of an attribute type can be specified to
- contain other attributes.
-
-8.2. Protocol Extensibility
-
- EAP-AKA can be extended by specifying new attribute types. If
- skippable attributes are used, it is possible to extend the protocol
- without breaking old implementations. As specified in Section 10.13,
- if new attributes are specified for EAP-Request/AKA-Identity or
- EAP-Response/AKA-Identity, then the AT_CHECKCODE MUST be used to
- integrity protect the new attributes.
-
- When specifying new attributes, it should be noted that EAP-AKA does
- not support message fragmentation. Hence, the sizes of the new
- extensions MUST be limited so that the maximum transfer unit (MTU) of
- the underlying lower layer is not exceeded. According to [RFC3748],
- lower layers must provide an EAP MTU of 1020 bytes or greater, so any
- extensions to EAP-AKA SHOULD NOT exceed the EAP MTU of 1020 bytes.
-
- EAP-AKA packets do not include a version field. However, should
- there be a reason to revise this protocol in the future, new
- non-skippable or skippable attributes could be specified in order to
- implement revised EAP-AKA versions in a backward-compatible manner.
- It is possible to introduce version negotiation in the
- EAP-Request/AKA-Identity and EAP-Response/AKA-Identity messages by
- specifying new skippable attributes.
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 47]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-9. Messages
-
- This section specifies the messages used in EAP-AKA. It specifies
- when a message may be transmitted or accepted, which attributes are
- allowed in a message, which attributes are required in a message, and
- other message-specific details. Message format is specified in
- Section 8.1.
-
-9.1. EAP-Request/AKA-Identity
-
- The EAP/AKA-Identity roundtrip MAY be used for obtaining the peer
- identity from the server. As discussed in Section 4.1, several
- AKA-Identity rounds may be required in order to obtain a valid peer
- identity.
-
- The server MUST include one of the following identity requesting
- attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, AT_ANY_ID_REQ.
- These three attributes are mutually exclusive, so the server MUST NOT
- include more than one of the attributes.
-
- If the server has previously issued an EAP-Request/AKA-Identity
- message with the AT_PERMANENT_ID_REQ attribute, and if the server has
- received a response from the peer, then the server MUST NOT issue a
- new EAP-Request/AKA-Identity packet.
-
- If the server has previously issued an EAP-Request/AKA-Identity
- message with the AT_FULLAUTH_ID_REQ attribute, and if the server has
- received a response from the peer, then the server MUST NOT issue a
- new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ or
- AT_FULLAUTH_ID_REQ attributes.
-
- If the server has previously issued an EAP-Request/AKA-Identity
- message with the AT_ANY_ID_REQ attribute, and if the server has
- received a response from the peer, then the server MUST NOT issue a
- new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ.
-
- This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.
-
-9.2. EAP-Response/AKA-Identity
-
- The peer sends EAP-Response/AKA-Identity in response to a valid
- EAP-Request/AKA-Identity from the server.
-
- The peer MUST include the AT_IDENTITY attribute. The usage of
- AT_IDENTITY is defined in Section 4.1.
-
- This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.
-
-
-
-
-Arkko & Haverinen Informational [Page 48]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-9.3. EAP-Request/AKA-Challenge
-
- The server sends the EAP-Request/AKA-Challenge on full authentication
- after successfully obtaining the subscriber identity.
-
- The AT_RAND attribute MUST be included.
-
- AT_MAC MUST be included. In EAP-Request/AKA-Challenge, there is no
- message-specific data covered by the MAC, see Section 10.15.
-
- The AT_RESULT_IND attribute MAY be included. The usage of this
- attribute is discussed in Section 6.2.
-
- The AT_CHECKCODE attribute MAY be included, and in certain cases
- specified in Section 10.13, it MUST be included.
-
- The EAP-Request/AKA-Challenge packet MAY include encrypted attributes
- for identity privacy and for communicating the next re-authentication
- identity. In this case, the AT_IV and AT_ENCR_DATA attributes are
- included (Section 10.12).
-
- The plaintext of the AT_ENCR_DATA value field consists of nested
- attributes. The nested attributes MAY include AT_PADDING (as
- specified in Section 10.12). If the server supports identity privacy
- and wants to communicate a pseudonym to the peer for the next full
- authentication, then the nested encrypted attributes include the
- AT_NEXT_PSEUDONYM attribute. If the server supports
- re-authentication and wants to communicate a fast re-authentication
- identity to the peer, then the nested encrypted attributes include
- the AT_NEXT_REAUTH_ID attribute. Later versions of this protocol MAY
- specify additional attributes to be included within the encrypted
- data.
-
- When processing this message, the peer MUST process AT_RAND and
- AT_AUTN before processing other attributes. Only if these attributes
- are verified to be valid, the peer derives keys and verifies AT_MAC.
- The operation in case an error occurs is specified in Section 6.3.1.
-
-9.4. EAP-Response/AKA-Challenge
-
- The peer sends EAP-Response/AKA-Challenge in response to a valid
- EAP-Request/AKA-Challenge.
-
- Sending this packet indicates that the peer has successfully
- authenticated the server and that the EAP exchange will be accepted
- by the peer's local policy. Hence, if these conditions are not met,
- then the peer MUST NOT send EAP-Response/AKA-Challenge, but the peer
- MUST send EAP-Response/AKA-Client-Error.
-
-
-
-Arkko & Haverinen Informational [Page 49]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- The AT_MAC attribute MUST be included. In
- EAP-Response/AKA-Challenge, there is no message-specific data covered
- by the MAC, see Section 10.15.
-
- The AT_RES attribute MUST be included.
-
- The AT_CHECKCODE attribute MAY be included, and in certain cases
- specified in Section 10.13, it MUST be included.
-
- The AT_RESULT_IND attribute MAY be included, if it was included in
- EAP-Request/AKA-Challenge. The usage of this attribute is discussed
- in Section 6.2.
-
- Later versions of this protocol MAY make use of the AT_ENCR_DATA and
- AT_IV attributes in this message to include encrypted (skippable)
- attributes. The EAP server MUST process EAP-Response/AKA-Challenge
- messages that include these attributes even if the server did not
- implement these optional attributes.
-
-9.5. EAP-Response/AKA-Authentication-Reject
-
- The peer sends the EAP-Response/AKA-Authentication-Reject packet if
- it does not accept the AUTN parameter. This version of the protocol
- does not specify any attributes for this message. Future versions of
- the protocol MAY specify attributes for this message.
-
- The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in
- this message.
-
-9.6. EAP-Response/AKA-Synchronization-Failure
-
- The peer sends the EAP-Response/AKA-Synchronization-Failure, when the
- sequence number in the AUTN parameter is incorrect.
-
- The peer MUST include the AT_AUTS attribute. Future versions of the
- protocol MAY specify other additional attributes for this message.
-
- The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in
- this message.
-
-9.7. EAP-Request/AKA-Reauthentication
-
- The server sends the EAP-Request/AKA-Reauthentication message if it
- wants to use fast re-authentication, and if it has received a valid
- fast re-authentication identity in EAP-Response/Identity or
- EAP-Response/AKA-Identity.
-
-
-
-
-
-Arkko & Haverinen Informational [Page 50]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- The AT_MAC attribute MUST be included. No message-specific data is
- included in the MAC calculation, see Section 10.15.
-
- The AT_RESULT_IND attribute MAY be included. The usage of this
- attribute is discussed in Section 6.2.
-
- The AT_CHECKCODE attribute MAY be included, and in certain cases
- specified in Section 10.13, it MUST be included.
-
- The AT_IV and AT_ENCR_DATA attributes MUST be included. The
- plaintext consists of the following nested encrypted attributes,
- which MUST be included: AT_COUNTER and AT_NONCE_S. In addition, the
- nested encrypted attributes MAY include the following attributes:
- AT_NEXT_REAUTH_ID and AT_PADDING.
-
-9.8. EAP-Response/AKA-Reauthentication
-
- The client sends the EAP-Response/AKA-Reauthentication packet in
- response to a valid EAP-Request/AKA-Reauthentication.
-
- The AT_MAC attribute MUST be included. For
- EAP-Response/AKA-Reauthentication, the MAC code is calculated over
- the following data: EAP packet| NONCE_S. The EAP packet is
- represented as specified in Section 8.1. It is followed by the
- 16-byte NONCE_S value from the server's AT_NONCE_S attribute.
-
- The AT_CHECKCODE attribute MAY be included, and in certain cases
- specified in Section 10.13, it MUST be included.
-
- The AT_IV and AT_ENCR_DATA attributes MUST be included. The nested
- encrypted attributes MUST include the AT_COUNTER attribute. The
- AT_COUNTER_TOO_SMALL attribute MAY be included in the nested
- encrypted attributes, and it is included in cases specified in
- Section 5. The AT_PADDING attribute MAY be included.
-
- The AT_RESULT_IND attribute MAY be included, if it was included in
- EAP-Request/AKA-Reauthentication. The usage of this attribute is
- discussed in Section 6.2.
-
- Sending this packet without AT_COUNTER_TOO_SMALL indicates that the
- peer has successfully authenticated the server and that the EAP
- exchange will be accepted by the peer's local policy. Hence, if
- these conditions are not met, then the peer MUST NOT send
- EAP-Response/AKA-Reauthentication, but the peer MUST send
- EAP-Response/ AKA-Client-Error.
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 51]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-9.9. EAP-Response/AKA-Client-Error
-
- The peer sends EAP-Response/AKA-Client-Error in error cases, as
- specified in Section 6.3.1.
-
- The AT_CLIENT_ERROR_CODE attribute MUST be included. The AT_MAC,
- AT_IV, or AT_ENCR_DATA attributes MUST NOT be used with this packet.
-
-9.10. EAP-Request/AKA-Notification
-
- The usage of this message is specified in Section 6.
-
- The AT_NOTIFICATION attribute MUST be included.
-
- The AT_MAC attribute MUST be included if the P bit of the
- AT_NOTIFICATION code is set to zero, and MUST NOT be included if the
- P bit is set to one. The P bit is discussed in Section 6.
-
- No message-specific data is included in the MAC calculation. See
- Section 10.15.
-
- If EAP-Request/AKA-Notification is used on a fast re-authentication
- exchange, and if the P bit in AT_NOTIFICATION is set to zero, then
- AT_COUNTER is used for replay protection. In this case, the
- AT_ENCR_DATA and AT_IV attributes MUST be included, and the
- encapsulated plaintext attributes MUST include the AT_COUNTER
- attribute. The counter value included in AT_COUNTER MUST be the same
- as in the EAP-Request/AKA-Reauthentication packet on the same fast
- re-authentication exchange.
-
-9.11. EAP-Response/AKA-Notification
-
- The usage of this message is specified in Section 6. This packet is
- an acknowledgement of EAP-Request/AKA-Notification.
-
- The AT_MAC attribute MUST be included in cases when the P bit of the
- notification code in AT_NOTIFICATION of EAP-Request/AKA-Notification
- is set to zero, and MUST NOT be included in cases when the P bit is
- set to one. The P bit is discussed in Section 6.
-
- If EAP-Request/AKA-Notification is used on a fast re-authentication
- exchange, and if the P bit in AT_NOTIFICATION is set to zero, then
- AT_COUNTER is used for replay protection. In this case, the
- AT_ENCR_DATA and AT_IV attributes MUST be included, and the
- encapsulated plaintext attributes MUST include the AT_COUNTER
- attribute. The counter value included in AT_COUNTER MUST be the same
- as in the EAP-Request/AKA-Reauthentication packet on the same fast
- re-authentication exchange.
-
-
-
-Arkko & Haverinen Informational [Page 52]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-10. Attributes
-
- This section specifies the format of message attributes. The
- attribute type numbers are specified in Section 11.
-
-10.1. Table of Attributes
-
- The following table provides a guide to which attributes may be found
- in which kinds of messages, and in what quantity. Messages are
- denoted with numbers in parentheses as follows: (1) EAP-Request/
- AKA-Identity, (2) EAP-Response/AKA-Identity, (3) EAP-Request/
- AKA-Challenge, (4) EAP-Response/AKA-Challenge, (5) EAP-Request/
- AKA-Notification, (6) EAP-Response/AKA-Notification, (7) EAP-
- Response/AKA-Client-Error (8) EAP-Request/AKA-Reauthentication, (9)
- EAP-Response/AKA-Reauthentication, (10) EAP-Response/AKA-
- Authentication-Reject, and (11) EAP-Response/AKA-Synchronization-
- Failure. The column denoted with "E" indicates whether the attribute
- is a nested attribute that MUST be included within AT_ENCR_DATA.
-
- "0" indicates that the attribute MUST NOT be included in the message,
- "1" indicates that the attribute MUST be included in the message,
- "0-1" indicates that the attribute is sometimes included in the
- message, and "0*" indicates that the attribute is not included in the
- message in cases specified in this document, but MAY be included in
- the future versions of the protocol.
-
- Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) (10)(11) E
- AT_PERMANENT_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N
- AT_ANY_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N
- AT_FULLAUTH_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N
- AT_IDENTITY 0 0-1 0 0 0 0 0 0 0 0 0 N
- AT_RAND 0 0 1 0 0 0 0 0 0 0 0 N
- AT_AUTN 0 0 1 0 0 0 0 0 0 0 0 N
- AT_RES 0 0 0 1 0 0 0 0 0 0 0 N
- AT_AUTS 0 0 0 0 0 0 0 0 0 0 1 N
- AT_NEXT_PSEUDONYM 0 0 0-1 0 0 0 0 0 0 0 0 Y
- AT_NEXT_REAUTH_ID 0 0 0-1 0 0 0 0 0-1 0 0 0 Y
- AT_IV 0 0 0-1 0* 0-1 0-1 0 1 1 0 0 N
- AT_ENCR_DATA 0 0 0-1 0* 0-1 0-1 0 1 1 0 0 N
- AT_PADDING 0 0 0-1 0* 0-1 0-1 0 0-1 0-1 0 0 Y
- AT_CHECKCODE 0 0 0-1 0-1 0 0 0 0-1 0-1 0 0 N
- AT_RESULT_IND 0 0 0-1 0-1 0 0 0 0-1 0-1 0 0 N
- AT_MAC 0 0 1 1 0-1 0-1 0 1 1 0 0 N
- AT_COUNTER 0 0 0 0 0-1 0-1 0 1 1 0 0 Y
- AT_COUNTER_TOO_SMALL 0 0 0 0 0 0 0 0 0-1 0 0 Y
- AT_NONCE_S 0 0 0 0 0 0 0 1 0 0 0 Y
- AT_NOTIFICATION 0 0 0 0 1 0 0 0 0 0 0 N
- AT_CLIENT_ERROR_CODE 0 0 0 0 0 0 1 0 0 0 0 N
-
-
-
-Arkko & Haverinen Informational [Page 53]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- It should be noted that attributes AT_PERMANENT_ID_REQ,
- AT_ANY_ID_REQ, and AT_FULLAUTH_ID_REQ are mutually exclusive, so that
- only one of them can be included at the same time. If one of the
- attributes AT_IV or AT_ENCR_DATA is included, then both of the
- attributes MUST be included.
-
-10.2. AT_PERMANENT_ID_REQ
-
- The format of the AT_PERMANENT_ID_REQ attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |AT_PERM..._REQ | Length = 1 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The use of the AT_PERMANENT_ID_REQ is defined in Section 4.1. The
- value field only contains two reserved bytes, which are set to zero
- on sending and ignored on reception.
-
-10.3. AT_ANY_ID_REQ
-
- The format of the AT_ANY_ID_REQ attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |AT_ANY_ID_REQ | Length = 1 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The use of the AT_ANY_ID_REQ is defined in Section 4.1. The value
- field only contains two reserved bytes, which are set to zero on
- sending and ignored on reception.
-
-10.4. AT_FULLAUTH_ID_REQ
-
- The format of the AT_FULLAUTH_ID_REQ attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |AT_FULLAUTH_...| Length = 1 | Reserved |
- +---------------+---------------+-------------------------------+
-
- The use of the AT_FULLAUTH_ID_REQ is defined in Section 4.1. The
- value field only contains two reserved bytes, which are set to zero
- on sending and ignored on reception.
-
-
-
-
-Arkko & Haverinen Informational [Page 54]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-10.5. AT_IDENTITY
-
- The format of the AT_IDENTITY attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_IDENTITY | Length | Actual Identity Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- . Identity .
- . .
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The use of the AT_IDENTITY is defined in Section 4.1. The value
- field of this attribute begins with 2-byte actual identity length,
- which specifies the length of the identity in bytes. This field is
- followed by the subscriber identity of the indicated actual length.
- The identity is the permanent identity, a pseudonym identity or a
- fast re-authentication identity. The identity format is specified in
- Section 4.1.1. The same identity format is used in the AT_IDENTITY
- attribute and the EAP-Response/Identity packet, with the exception
- that the peer MUST NOT decorate the identity it includes in
- AT_IDENTITY. The identity does not include any terminating null
- characters. Because the length of the attribute must be a multiple
- of 4 bytes, the sender pads the identity with zero bytes when
- necessary.
-
-10.6. AT_RAND
-
- The format of the AT_RAND attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_RAND | Length = 5 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | RAND |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of this attribute contains two reserved bytes
- followed by the AKA RAND parameter, 16 bytes (128 bits). The
- reserved bytes are set to zero when sending and ignored on reception.
-
-
-
-
-Arkko & Haverinen Informational [Page 55]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-10.7. AT_AUTN
-
- The format of the AT_AUTN attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_AUTN | Length = 5 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | AUTN |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of this attribute contains two reserved bytes
- followed by the AKA AUTN parameter, 16 bytes (128 bits). The
- reserved bytes are set to zero when sending and ignored on reception.
-
-10.8. AT_RES
-
- The format of the AT_RES attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_RES | Length | RES Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
- | |
- | RES |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of this attribute begins with the 2-byte RES Length,
- which identifies the exact length of the RES in bits. The RES length
- is followed by the AKA RES parameter. According to [TS33.105], the
- length of the AKA RES can vary between 32 and 128 bits. Because the
- length of the AT_RES attribute must be a multiple of 4 bytes, the
- sender pads the RES with zero bits where necessary.
-
-
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 56]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-10.9. AT_AUTS
-
- The format of the AT_AUTS attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
- | AT_AUTS | Length = 4 | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
- | |
- | AUTS |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of this attribute contains the AKA AUTS parameter,
- 112 bits (14 bytes).
-
-10.10. AT_NEXT_PSEUDONYM
-
- The format of the AT_NEXT_PSEUDONYM attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_NEXT_PSEU..| Length | Actual Pseudonym Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- . Next Pseudonym .
- . .
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of this attribute begins with a 2-byte actual
- pseudonym length, which specifies the length of the following
- pseudonym in bytes. This field is followed by a pseudonym username
- that the peer can use in the next authentication. The username MUST
- NOT include any realm portion. The username does not include any
- terminating null characters. Because the length of the attribute
- must be a multiple of 4 bytes, the sender pads the pseudonym with
- zero bytes when necessary. The username encoding MUST follow the
- UTF-8 transformation format [RFC3629]. This attribute MUST always be
- encrypted by encapsulating it within the AT_ENCR_DATA attribute.
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 57]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-10.11. AT_NEXT_REAUTH_ID
-
- The format of the AT_NEXT_REAUTH_ID attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_NEXT_REAU..| Length | Actual Re-Auth Identity Length|
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- . Next Fast Re-Authentication Username .
- . .
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of this attribute begins with a 2-byte actual
- re-authentication identity length which specifies the length of the
- following fast re-authentication identity in bytes. This field is
- followed by a fast re-authentication identity that the peer can use
- in the next fast re-authentication, as described in Section 5. In
- environments where a realm portion is required, the fast
- re-authentication identity includes both a username portion and a
- realm name portion. The fast re-authentication identity does not
- include any terminating null characters. Because the length of the
- attribute must be a multiple of 4 bytes, the sender pads the fast
- re-authentication identity with zero bytes when necessary. The
- identity encoding MUST follow the UTF-8 transformation format
- [RFC3629]. This attribute MUST always be encrypted by encapsulating
- it within the AT_ENCR_DATA attribute.
-
-10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING
-
- AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted
- information between the EAP-AKA peer and server.
-
- The value field of AT_IV contains two reserved bytes followed by a
- 16-byte initialization vector required by the AT_ENCR_DATA attribute.
- The reserved bytes are set to zero when sending and ignored on
- reception. The AT_IV attribute MUST be included if and only if the
- AT_ENCR_DATA is included. Section 6.3 specifies the operation if a
- packet that does not meet this condition is encountered.
-
- The sender of the AT_IV attribute chooses the initialization vector
- at random. The sender MUST NOT reuse the initialization vector value
- from previous EAP-AKA packets. The sender SHOULD use a good source
- of randomness to generate the initialization vector. Please see
- [RFC4086] for more information about generating random numbers for
- security applications. The format of AT_IV is shown below.
-
-
-
-Arkko & Haverinen Informational [Page 58]
-\f
-RFC 4187 EAP-AKA Authentication January 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_IV | Length = 5 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Initialization Vector |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of the AT_ENCR_DATA attribute consists of two
- reserved bytes followed by cipher text bytes. The cipher text bytes
- are encrypted using the Advanced Encryption Standard (AES) [AES] with
- a 128-bit key in the Cipher Block Chaining (CBC) mode of operation,
- which uses the initialization vector from the AT_IV attribute. The
- reserved bytes are set to zero when sending and ignored on reception.
- Please see [CBC] for a description of the CBC mode. The format of
- the AT_ENCR_DATA attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_ENCR_DATA | Length | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- . Encrypted Data .
- . .
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The derivation of the encryption key (K_encr) is specified in
- Section 7.
-
- The plaintext consists of nested EAP-AKA attributes.
-
- The encryption algorithm requires the length of the plaintext to be a
- multiple of 16 bytes. The sender may need to include the AT_PADDING
- attribute as the last attribute within AT_ENCR_DATA. The AT_PADDING
- attribute is not included if the total length of other nested
- attributes within the AT_ENCR_DATA attribute is a multiple of 16
- bytes. As usual, the Length of the Padding attribute includes the
- Attribute Type and Attribute Length fields. The length of the
- Padding attribute is 4, 8, or 12 bytes. It is chosen so that the
- length of the value field of the AT_ENCR_DATA attribute becomes a
- multiple of 16 bytes. The actual pad bytes in the value field are
- set to zero (00 hexadecimal) on sending. The recipient of the
- message MUST verify that the pad bytes are set to zero. If this
-
-
-
-Arkko & Haverinen Informational [Page 59]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- verification fails on the peer, then it MUST send the
- EAP-Response/AKA-Client-Error packet with the error code "unable to
- process packet" to terminate the authentication exchange. If this
- verification fails on the server, then the server sends the
- EAP-Response/AKA-Notification packet with an AT_NOTIFICATION code
- that implies failure to terminate the authentication exchange. The
- format of the AT_PADDING attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_PADDING | Length | Padding... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-10.13. AT_CHECKCODE
-
- The AT_MAC attribute is not used in the very first EAP-AKA messages
- during the AKA-Identity round, because keying material has not been
- derived yet. The peer and the server may exchange one or more pairs
- of EAP-AKA messages of the Subtype AKA-Identity before keys are
- derived and before the AT_MAC attribute can be applied. The EAP/-
- AKA-Identity messages may also be used upon fast re-authentication.
-
- The AT_CHECKCODE attribute MAY be used to protect the EAP/
- AKA-Identity messages. In full authentication, the server MAY
- include the AT_CHECKCODE in EAP-Request/AKA-Challenge, and the peer
- MAY include AT_CHECKCODE in EAP-Response/AKA-Challenge. In fast
- re-authentication, the server MAY include AT_CHECKCODE in
- EAP-Request/ AKA-Reauthentication, and the peer MAY include
- AT_CHECKCODE in EAP-Response/AKA-Reauthentication. The fact that the
- peer receives an EAP-Request with AT_CHECKCODE does not imply that
- the peer would have to include AT_CHECKCODE in the corresponding
- response. The peer MAY include AT_CHECKCODE even if the server did
- not include AT_CHECKCODE in the EAP request. Because the AT_MAC
- attribute is used in these messages, AT_CHECKCODE will be integrity
- protected with AT_MAC. The format of the AT_CHECKCODE attribute is
- shown below.
-
-
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 60]
-\f
-RFC 4187 EAP-AKA Authentication January 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_CHECKCODE | Length | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | Checkcode (0 or 20 bytes) |
- | |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of AT_CHECKCODE begins with two reserved bytes, which
- may be followed by a 20-byte checkcode. If the checkcode is not
- included in AT_CHECKCODE, then the attribute indicates that no EAP/-
- AKA-Identity messages were exchanged. This may occur in both full
- authentication and fast re-authentication. The reserved bytes are
- set to zero when sending and ignored on reception.
-
- The checkcode is a hash value, calculated with SHA1 [SHA-1], over all
- EAP-Request/AKA-Identity and EAP-Response/AKA-Identity packets
- exchanged in this authentication exchange. The packets are included
- in the order that they were transmitted, that is, starting with the
- first EAP-Request/AKA-Identity message, followed by the corresponding
- EAP-Response/AKA-Identity, followed by the second
- EAP-Request/AKA-Identity (if used), etc.
-
- EAP packets are included in the hash calculation "as-is" (as they
- were transmitted or received). All reserved bytes, padding bytes,
- etc., that are specified for various attributes are included as such,
- and the receiver must not reset them to zero. No delimiter bytes,
- padding, or any other framing are included between the EAP packets
- when calculating the checkcode.
-
- Messages are included in request/response pairs; in other words, only
- full "round trips" are included. Packets that are silently discarded
- are not included, and retransmitted packets (that have the same
- Identifier value) are only included once. (The base EAP protocol
- [RFC3748] ensures that requests and responses "match".) The EAP
- server must only include an EAP-Request/AKA-Identity in the
- calculation after it has received a corresponding response with the
- same Identifier value.
-
- The peer must include the EAP-Request/AKA-Identity and the
- corresponding response in the calculation only if the peer receives a
- subsequent EAP-Request/AKA-Challenge or a follow-up EAP-Request/
- AKA-Identity with a different Identifier value than in the first
- EAP-Request/AKA-Identity.
-
-
-
-Arkko & Haverinen Informational [Page 61]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- The AT_CHECKCODE attribute is optional to implement. It is specified
- in order to allow protection of the EAP/AKA-Identity messages and any
- future extensions to them. The implementation of AT_CHECKCODE is
- RECOMMENDED.
-
- If the receiver of AT_CHECKCODE implements this attribute, then the
- receiver MUST check that the checkcode is correct. If the checkcode
- is invalid, the receiver must operate as specified in Section 6.3.
-
- If the EAP/AKA-Identity messages are extended with new attributes,
- then AT_CHECKCODE MUST be implemented and used. More specifically,
- if the server includes any attributes other than AT_PERMANENT_ID_REQ,
- AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ in the EAP-Request/AKA-Identity
- packet, then the server MUST include AT_CHECKCODE in EAP-Request/
- AKA-Challenge or EAP-Request/AKA-Reauthentication. If the peer
- includes any attributes other than AT_IDENTITY in the EAP-Response/
- AKA-Identity message, then the peer MUST include AT_CHECKCODE in
- EAP-Response/AKA-Challenge or EAP-Response/AKA-Reauthentication.
-
- If the server implements the processing of any other attribute than
- AT_IDENTITY for the EAP-Response/AKA-Identity message, then the
- server MUST implement AT_CHECKCODE. In this case, if the server
- receives any attribute other than AT_IDENTITY in the
- EAP-Response/AKA-Identity message, then the server MUST check that
- AT_CHECKCODE is present in EAP-Response/AKA-Challenge or
- EAP-Response/ AKA-Reauthentication. The operation when a mandatory
- attribute is missing is specified in Section 6.3.
-
- Similarly, if the peer implements the processing of any attribute
- other than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ
- for the EAP-Request/AKA-Identity packet, then the peer MUST implement
- AT_CHECKCODE. In this case, if the peer receives any attribute other
- than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ in the
- EAP-Request/AKA-Identity packet, then the peer MUST check that
- AT_CHECKCODE is present in EAP-Request/AKA-Challenge or
- EAP-Request/AKA-Reauthentication. The operation when a mandatory
- attribute is missing is specified in Section 6.3.
-
-10.14. AT_RESULT_IND
-
- The format of the AT_RESULT_IND attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_RESULT_...| Length = 1 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-Arkko & Haverinen Informational [Page 62]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- The value field of this attribute consists of two reserved bytes,
- which are set to zero upon sending and ignored upon reception. This
- attribute is always sent unencrypted, so it MUST NOT be encapsulated
- within the AT_ENCR_DATA attribute.
-
-10.15. AT_MAC
-
- The AT_MAC attribute is used for EAP-AKA message authentication.
- Section 9 specifies in which messages AT_MAC MUST be included.
-
- The value field of the AT_MAC attribute contains two reserved bytes
- followed by a keyed message authentication code (MAC). The MAC is
- calculated over the whole EAP packet and concatenated with optional
- message-specific data, with the exception that the value field of the
- MAC attribute is set to zero when calculating the MAC. The EAP
- packet includes the EAP header that begins with the Code field, the
- EAP-AKA header that begins with the Subtype field, and all the
- attributes, as specified in Section 8.1. The reserved bytes in
- AT_MAC are set to zero when sending and ignored on reception. The
- contents of the message-specific data that may be included in the MAC
- calculation are specified separately for each EAP-AKA message in
- Section 9.
-
- The format of the AT_MAC attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_MAC | Length = 5 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | MAC |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The MAC algorithm is HMAC-SHA1-128 [RFC2104] keyed hash value. (The
- HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by
- truncating the output to 16 bytes. Hence, the length of the MAC is
- 16 bytes.) The derivation of the authentication key (K_aut) used in
- the calculation of the MAC is specified in Section 7.
-
- When the AT_MAC attribute is included in an EAP-AKA message, the
- recipient MUST process the AT_MAC attribute before looking at any
- other attributes, except when processing EAP-Request/AKA-Challenge.
- The processing of EAP-Request/AKA-Challenge is specified in
-
-
-
-
-
-Arkko & Haverinen Informational [Page 63]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- Section 9.3. If the message authentication code is invalid, then the
- recipient MUST ignore all other attributes in the message and operate
- as specified in Section 6.3.
-
-10.16. AT_COUNTER
-
- The format of the AT_COUNTER attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_COUNTER | Length = 1 | Counter |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of the AT_COUNTER attribute consists of a 16-bit
- unsigned integer counter value, represented in network byte order.
- This attribute MUST always be encrypted by encapsulating it within
- the AT_ENCR_DATA attribute.
-
-10.17. AT_COUNTER_TOO_SMALL
-
- The format of the AT_COUNTER_TOO_SMALL attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_COUNTER...| Length = 1 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of this attribute consists of two reserved bytes,
- which are set to zero upon sending and ignored upon reception. This
- attribute MUST always be encrypted by encapsulating it within the
- AT_ENCR_DATA attribute.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 64]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-10.18. AT_NONCE_S
-
- The format of the AT_NONCE_S attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AT_NONCE_S | Length = 5 | Reserved |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- | |
- | NONCE_S |
- | |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of the AT_NONCE_S attribute contains two reserved
- bytes followed by a random number (16 bytes) that is freshly
- generated by the server for this EAP-AKA fast re-authentication. The
- random number is used as challenge for the peer and also as a seed
- value for the new keying material. The reserved bytes are set to
- zero upon sending and ignored upon reception. This attribute MUST
- always be encrypted by encapsulating it within the AT_ENCR_DATA
- attribute.
-
- The server MUST NOT reuse the NONCE_S value from a previous EAP-AKA
- fast re-authentication exchange. The server SHOULD use a good source
- of randomness to generate NONCE_S. Please see [RFC4086] for more
- information about generating random numbers for security
- applications.
-
-10.19. AT_NOTIFICATION
-
- The format of the AT_NOTIFICATION attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |AT_NOTIFICATION| Length = 1 |S|P| Notification Code |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of this attribute contains a two-byte notification
- code. The first and second bit (S and P) of the notification code
- are interpreted as described in Section 6.
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 65]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- The notification code values listed below have been reserved. The
- descriptions below illustrate the semantics of the notifications.
- The peer implementation MAY use different wordings when presenting
- the notifications to the user. The "requested service" depends on
- the environment where EAP-AKA is applied.
-
- 0 - General failure after authentication. (Implies failure, used
- after successful authentication.)
-
- 16384 - General failure. (Implies failure, used before
- authentication.)
-
- 32768 - Success. User has been successfully authenticated. (Does
- not imply failure, used after successful authentication.) The usage
- of this code is discussed in Section 6.2.
-
- 1026 - User has been temporarily denied access to the requested
- service. (Implies failure, used after successful authentication.)
-
- 1031 - User has not subscribed to the requested service. (Implies
- failure, used after successful authentication.)
-
-10.20. AT_CLIENT_ERROR_CODE
-
- The format of the AT_CLIENT_ERROR_CODE attribute is shown below.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |AT_CLIENT_ERR..| Length = 1 | Client Error Code |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The value field of this attribute contains a two-byte client error
- code. The following error code values have been reserved.
-
- 0 "unable to process packet": a general error code
-
-11. IANA and Protocol Numbering Considerations
-
- IANA has assigned the EAP type number 23 for EAP-AKA authentication.
-
- EAP-AKA shares most of the protocol design, such as attributes and
- message Subtypes, with EAP-SIM [EAP-SIM]. EAP-AKA protocol numbers
- should be administered in the same IANA registry with EAP-SIM. This
- document establishes the registries and lists the initial protocol
- numbers for both protocols.
-
-
-
-
-
-Arkko & Haverinen Informational [Page 66]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- EAP-AKA and EAP-SIM messages include a Subtype field. The Subtype is
- a new numbering space for which IANA administration is required. The
- Subtype is an 8-bit integer. The following Subtypes are specified in
- this document and in [EAP-SIM]:
-
- AKA-Challenge...................................1
- AKA-Authentication-Reject.......................2
- AKA-Synchronization-Failure.....................4
- AKA-Identity....................................5
- SIM-Start......................................10
- SIM-Challenge..................................11
- AKA-Notification and SIM-Notification..........12
- AKA-Reauthentication and SIM-Reauthentication..13
- AKA-Client-Error and SIM-Client-Error..........14
-
- The messages are composed of attributes, which have 8-bit attribute
- type numbers. Attributes numbered within the range 0 through 127 are
- called non-skippable attributes, and attributes within the range of
- 128 through 255 are called skippable attributes. The EAP-AKA and
- EAP-SIM attribute type number is a new numbering space for which IANA
- administration is required. The following attribute types are
- specified in this document in [EAP-SIM]:
-
- AT_RAND.........................................1
- AT_AUTN.........................................2
- AT_RES..........................................3
- AT_AUTS.........................................4
- AT_PADDING......................................6
- AT_NONCE_MT.....................................7
- AT_PERMANENT_ID_REQ............................10
- AT_MAC.........................................11
- AT_NOTIFICATION................................12
- AT_ANY_ID_REQ..................................13
- AT_IDENTITY....................................14
- AT_VERSION_LIST................................15
- AT_SELECTED_VERSION............................16
- AT_FULLAUTH_ID_REQ.............................17
- AT_COUNTER.....................................19
- AT_COUNTER_TOO_SMALL...........................20
- AT_NONCE_S.....................................21
- AT_CLIENT_ERROR_CODE...........................22
- AT_IV.........................................129
- AT_ENCR_DATA..................................130
- AT_NEXT_PSEUDONYM.............................132
- AT_NEXT_REAUTH_ID.............................133
- AT_CHECKCODE..................................134
- AT_RESULT_IND.................................135
-
-
-
-
-Arkko & Haverinen Informational [Page 67]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- The AT_NOTIFICATION attribute contains a 16-bit notification code
- value. The most significant bit of the notification code is called
- the S bit (success) and the second most significant bit is called the
- P bit (phase). If the S bit is set to zero, then the notification
- code indicates failure; notification codes with the S bit set to one
- do not indicate failure. If the P bit is set to zero, then the
- notification code can only be used before authentication has
- occurred. If the P bit is set to one, then the notification code can
- only be used after authentication. The notification code is a new
- numbering space for which IANA administration is required. The
- following values have been specified in this document and in
- [EAP-SIM].
-
- General failure after authentication......................0
- User has been temporarily denied access................1026
- User has not subscribed to the requested service.......1031
- General failure.......................................16384
- Success...............................................32768
-
- The AT_VERSION_LIST and AT_SELECTED_VERSION attributes, specified in
- [EAP-SIM], contain 16-bit EAP method version numbers. The EAP method
- version number is a new numbering space for which IANA administration
- is required. Value 1 for "EAP-SIM Version 1" has been specified in
- [EAP-SIM]. Version numbers are not currently used in EAP-AKA.
-
- The AT_CLIENT_ERROR_CODE attribute contains a 16-bit client error
- code. The client error code is a new numbering space for which IANA
- administration is required. Values 0, 1, 2, and 3 have been
- specified in this document and in [EAP-SIM].
-
- All requests for value assignment from the various number spaces
- described in this document require proper documentation, according to
- the "Specification Required" policy described in [RFC2434]. Requests
- must be specified in sufficient detail so that interoperability
- between independent implementations is possible. Possible forms of
- documentation include, but are not limited to, RFCs, the products of
- another standards body (e.g., 3GPP), or permanently and readily
- available vendor design notes.
-
-12. Security Considerations
-
- The EAP specification [RFC3748] describes the security
- vulnerabilities of EAP, which does not include its own security
- mechanisms. This section discusses the claimed security properties
- of EAP-AKA as well as vulnerabilities and security recommendations.
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 68]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-12.1. Identity Protection
-
- EAP-AKA includes optional Identity privacy support that protects the
- privacy of the subscriber identity against passive eavesdropping.
- This document only specifies a mechanism to deliver pseudonyms from
- the server to the peer as part of an EAP-AKA exchange. Hence, a peer
- that has not yet performed any EAP-AKA exchanges does not typically
- have a pseudonym available. If the peer does not have a pseudonym
- available, then the privacy mechanism cannot be used, and the
- permanent identity will have to be sent in the clear. The terminal
- SHOULD store the pseudonym in non-volatile memory so that it can be
- maintained across reboots. An active attacker that impersonates the
- network may use the AT_PERMANENT_ID_REQ attribute (Section 4.1.2) to
- learn the subscriber's IMSI. However, as discussed in Section 4.1.2,
- the terminal can refuse to send the cleartext IMSI if it believes
- that the network should be able to recognize the pseudonym.
-
- If the peer and server cannot guarantee that the pseudonym will be
- maintained reliably, and Identity privacy is required then additional
- protection from an external security mechanism (such as Protected
- Extensible Authentication Protocol (PEAP) [PEAP]) may be used. The
- benefits and the security considerations of using an external
- security mechanism with EAP-AKA are beyond the scope of this
- document.
-
-12.2. Mutual Authentication
-
- EAP-AKA provides mutual authentication via the 3rd generation AKA
- mechanisms [TS33.102] and [S.S0055-A].
-
- Note that this mutual authentication is with the EAP server. In
- general, EAP methods do not authenticate the identity or services
- provided by the EAP authenticator (if distinct from the EAP server)
- unless they provide the so-called channel bindings property. The
- vulnerabilities related to this have been discussed in [RFC3748],
- [EAPKeying], [ServiceIdentity].
-
- EAP-AKA does not provide the channel bindings property, so it only
- authenticates the EAP server. However, ongoing work such as
- [ServiceIdentity] may provide such support as an extension to popular
- EAP methods such as EAP-TLS, EAP-SIM, or EAP-AKA.
-
-12.3. Flooding the Authentication Centre
-
- The EAP-AKA server typically obtains authentication vectors from the
- Authentication Centre (AuC). EAP-AKA introduces a new usage for the
- AuC. The protocols between the EAP-AKA server and the AuC are out of
- the scope of this document. However, it should be noted that a
-
-
-
-Arkko & Haverinen Informational [Page 69]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- malicious EAP-AKA peer may generate a lot of protocol requests to
- mount a denial-of-service attack. The EAP-AKA server implementation
- SHOULD take this into account and SHOULD take steps to limit the
- traffic that it generates towards the AuC, preventing the attacker
- from flooding the AuC and from extending the denial-of-service attack
- from EAP-AKA to other users of the AuC.
-
-12.4. Key Derivation
-
- EAP-AKA supports key derivation with 128-bit effective key strength.
- The key hierarchy is specified in Section 7.
-
- The Transient EAP Keys used to protect EAP-AKA packets (K_encr,
- K_aut), the Master Session Keys, and the Extended Master Session Keys
- are cryptographically separate. An attacker cannot derive any
- non-trivial information about any of these keys based on the other
- keys. An attacker also cannot calculate the pre-shared secret from
- AKA IK, AKA CK, EAP-AKA K_encr, EAP-AKA K_aut, the Master Session
- Key, or the Extended Master Session Key.
-
-12.5. Brute-Force and Dictionary Attacks
-
- The effective strength of EAP-AKA values is 128 bits, and there are
- no known, computationally feasible brute-force attacks. Because AKA
- is not a password protocol (the pre-shared secret is not a
- passphrase, or derived from a passphrase), EAP-AKA is not vulnerable
- to dictionary attacks.
-
-12.6. Protection, Replay Protection, and Confidentiality
-
- AT_MAC, AT_IV, AT_ENCR_DATA, and AT_COUNTER attributes are used to
- provide integrity, replay, and confidentiality protection for EAP-AKA
- Requests and Responses. Integrity protection with AT_MAC includes
- the EAP header. Integrity protection (AT_MAC) is based on a keyed
- message authentication code. Confidentiality (AT_ENCR_DATA and
- AT_IV) is based on a block cipher.
-
- Because keys are not available in the beginning of the EAP methods,
- the AT_MAC attribute cannot be used for protecting EAP/AKA-Identity
- messages. However, the AT_CHECKCODE attribute can optionally be used
- to protect the integrity of the EAP/AKA-Identity roundtrip.
-
- Confidentiality protection is applied only to a part of the protocol
- fields. The table of attributes in Section 10.1 summarizes which
- fields are confidentiality protected. It should be noted that the
- error and notification code attributes AT_CLIENT_ERROR_CODE and
- AT_NOTIFICATION are not confidential, but they are transmitted in the
- clear. Identity protection is discussed in Section 12.1.
-
-
-
-Arkko & Haverinen Informational [Page 70]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- On full authentication, replay protection of the EAP exchange is
- provided by RAND and AUTN values from the underlying AKA scheme.
- Protection against replays of EAP-AKA messages is also based on the
- fact that messages that can include AT_MAC can only be sent once with
- a certain EAP-AKA Subtype, and on the fact that a different K_aut key
- will be used for calculating AT_MAC in each full authentication
- exchange.
-
- On fast re-authentication, a counter included in AT_COUNTER and a
- server random nonce is used to provide replay protection. The
- AT_COUNTER attribute is also included in EAP-AKA notifications, if
- they are used after successful authentication in order to provide
- replay protection between re-authentication exchanges.
-
- The contents of the user identity string are implicitly integrity
- protected by including them in key derivation.
-
- Because EAP-AKA is not a tunneling method, EAP-Request/Notification,
- EAP-Response/Notification, EAP-Success, or EAP-Failure packets are
- not confidential, integrity protected, or replay protected. On
- physically insecure networks, this may enable an attacker to mount
- denial-of-service attacks by spoofing these packets. As discussed in
- Section 6.3, the peer will only accept EAP-Success after the peer
- successfully authenticates the server. Hence, the attacker cannot
- force the peer to believe successful mutual authentication has
- occurred before the peer successfully authenticates the server or
- after the peer failed to authenticate the server.
-
- The security considerations of EAP-AKA result indications are covered
- in Section 12.8
-
- An eavesdropper will see the EAP Notification, EAP_Success and
- EAP-Failure packets sent in the clear. With EAP-AKA, confidential
- information MUST NOT be transmitted in EAP Notification packets.
-
-12.7. Negotiation Attacks
-
- EAP-AKA does not protect the EAP-Response/Nak packet. Because
- EAP-AKA does not protect the EAP method negotiation, EAP method
- downgrading attacks may be possible, especially if the user uses the
- same identity with EAP-AKA and other EAP methods.
-
- As described in Section 8, EAP-AKA allows the protocol to be extended
- by defining new attribute types. When defining such attributes, it
- should be noted that any extra attributes included in
- EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are not
-
-
-
-
-
-Arkko & Haverinen Informational [Page 71]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- included in the MACs later on, and thus some other precautions must
- be taken to avoid modifications to them.
-
- EAP-AKA does not support ciphersuite negotiation or EAP-AKA protocol
- version negotiation.
-
-12.8. Protected Result Indications
-
- EAP-AKA supports optional protected success indications, and
- acknowledged failure indications. If a failure occurs after
- successful authentication, then the EAP-AKA failure indication is
- integrity and replay protected.
-
- Even if an EAP-Failure packet is lost when using EAP-AKA over an
- unreliable medium, then the EAP-AKA failure indications will help
- ensure that the peer and EAP server will know the other party's
- authentication decision. If protected success indications are used,
- then the loss of Success packet will also be addressed by the
- acknowledged, integrity, and replay protected EAP-AKA success
- indication. If the optional success indications are not used, then
- the peer may end up believing the server completed successful
- authentication, when actually it failed. Because access will not be
- granted in this case, protected result indications are not needed
- unless the client is not able to realize it does not have access for
- an extended period of time.
-
-12.9. Man-in-the-Middle Attacks
-
- In order to avoid man-in-the-middle attacks and session hijacking,
- user data SHOULD be integrity protected on physically insecure
- networks. The EAP-AKA Master Session Key or keys derived from it MAY
- be used as the integrity protection keys, or, if an external security
- mechanism such as PEAP is used, then the link integrity protection
- keys MAY be derived by the external security mechanism.
-
- There are man-in-the-middle attacks associated with the use of any
- EAP method within a tunneled protocol. For instance, an early
- version of PEAP [PEAP-02] was vulnerable to this attack. This
- specification does not address these attacks. If EAP-AKA is used
- with a tunneling protocol, there should be cryptographic binding
- provided between the protocol and EAP-AKA to prevent
- man-in-the-middle attacks through rogue authenticators being able to
- setup one-way authenticated tunnels. For example, newer versions of
- PEAP include such cryptographic binding. The EAP-AKA Master Session
- Key MAY be used to provide the cryptographic binding. However, the
- mechanism that provides the binding depends on the tunneling protocol
- and is beyond the scope of this document.
-
-
-
-
-Arkko & Haverinen Informational [Page 72]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-12.10. Generating Random Numbers
-
- An EAP-AKA implementation SHOULD use a good source of randomness to
- generate the random numbers required in the protocol. Please see
- [RFC4086] for more information on generating random numbers for
- security applications.
-
-13. Security Claims
-
- This section provides the security claims required by [RFC3748].
-
- Auth. Mechanism: EAP-AKA is based on the AKA mechanism, which is an
- authentication and key agreement mechanism based on a symmetric
- 128-bit pre-shared secret.
-
- Ciphersuite negotiation: No
-
- Mutual authentication: Yes (Section 12.2)
-
- Integrity protection: Yes (Section 12.6)
-
- Replay protection: Yes (Section 12.6)
-
- Confidentiality: Yes, except method-specific success and failure
- indications (Section 12.1, Section 12.6)
-
- Key derivation: Yes
-
- Key strength: EAP-AKA supports key derivation with 128-bit effective
- key strength.
-
- Description of key hierarchy: Please see Section 7.
-
- Dictionary attack protection: N/A (Section 12.5)
-
- Fast reconnect: Yes
-
- Cryptographic binding: N/A
-
- Session independence: Yes (Section 12.4)
-
- Fragmentation: No
-
- Channel binding: No
-
- Indication of vulnerabilities. Vulnerabilities are discussed in
- Section 12.
-
-
-
-
-Arkko & Haverinen Informational [Page 73]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-14. Acknowledgements and Contributions
-
- The authors wish to thank Rolf Blom of Ericsson, Bernard Aboba of
- Microsoft, Arne Norefors of Ericsson, N.Asokan of Nokia, Valtteri
- Niemi of Nokia, Kaisa Nyberg of Nokia, Jukka-Pekka Honkanen of Nokia,
- Pasi Eronen of Nokia, Olivier Paridaens of Alcatel, and Ilkka
- Uusitalo of Ericsson for interesting discussions in this problem
- space.
-
- Many thanks to Yoshihiro Ohba for reviewing the document.
-
- This protocol has been partly developed in parallel with EAP-SIM
- [EAP-SIM], and hence this specification incorporates many ideas from
- EAP-SIM, and many contributions from the reviewer's of EAP-SIM.
-
- The attribute format is based on the extension format of Mobile IPv4
- [RFC3344].
-
-15. References
-
-15.1. Normative References
-
- [TS33.102] 3rd Generation Partnership Project, "3GPP Technical
- Specification 3GPP TS 33.102 V5.1.0: "Technical
- Specification Group Services and System Aspects; 3G
- Security; Security Architecture (Release 5)"",
- December 2002.
-
- [S.S0055-A] 3rd Generation Partnership Project 2, "3GPP2
- Enhanced Cryptographic Algorithms", September 2003.
-
- [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen,
- "The Network Access Identifier", RFC 4282, December
- 2005.
-
- [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J.,
- and H. Levkowetz, "Extensible Authentication
- Protocol (EAP)", RFC 3748, June 2004.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [TS23.003] 3rd Generation Partnership Project, "3GPP Technical
- Specification 3GPP TS 23.003 V6.8.0: "3rd
- Generation Parnership Project; Technical
- Specification Group Core Network; Numbering,
- addressing and identification (Release 6)"",
- December 2005.
-
-
-
-Arkko & Haverinen Informational [Page 74]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
- [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:
- Keyed-Hashing for Message Authentication",
- RFC 2104, February 1997.
-
- [AES] National Institute of Standards and Technology,
- "Federal Information Processing Standards (FIPS)
- Publication 197, "Advanced Encryption Standard
- (AES)"", November 2001,
- http://csrc.nist.gov/publications/fips/fips197/
- fips-197.pdf.
-
- [CBC] National Institute of Standards and Technology,
- "NIST Special Publication 800-38A, "Recommendation
- for Block Cipher Modes of Operation - Methods and
- Techniques"", December 2001,
- http://csrc.nist.gov/publications/
- nistpubs/800-38a/sp800-38a.pdf.
-
- [SHA-1] National Institute of Standards and Technology,
- U.S. Department of Commerce, "Federal Information
- Processing Standard (FIPS) Publication 180-1,
- "Secure Hash Standard"", April 1995.
-
- [PRF] National Institute of Standards and Technology,
- "Federal Information Processing Standards (FIPS)
- Publication 186-2 (with change notice); Digital
- Signature Standard (DSS)", January 2000,
- http://csrc.nist.gov/publications/
- fips/fips186-2/fips186-2-change1.pdf.
-
- [TS33.105] 3rd Generation Partnership Project, "3GPP Technical
- Specification 3GPP TS 33.105 4.1.0: "Technical
- Specification Group Services and System Aspects; 3G
- Security; Cryptographic Algorithm Requirements
- (Release 4)"", June 2001.
-
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
- 10646", STD 63, RFC 3629, November 2003.
-
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
- Writing an IANA Considerations Section in RFCs",
- BCP 26, RFC 2434, October 1998.
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 75]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-15.2. Informative References
-
- [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS
- Attributes", RFC 2548, March 1999.
-
- [PEAP] Palekar, A., Simon, D., Zorn, G., Salowey, J.,
- Zhou, H., and S. Josefsson, "Protected EAP Protocol
- (PEAP) Version 2", work in progress, October 2004.
-
- [PEAP-02] Anderson, H., Josefsson, S., Zorn, G., Simon, D.,
- and A. Palekar, "Protected EAP Protocol (PEAP)",
- work in progress, February 2002.
-
- [EAPKeying] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H.
- Levkowetz, "Extensible Authentication Protocol
- (EAP) Key Management Framework", work in progress,
- October 2005.
-
- [ServiceIdentity] Arkko, J. and P. Eronen, "Authenticated Service
- Information for the Extensible Authentication
- Protocol (EAP)", Work in Progress, October 2004.
-
- [RFC4086] Eastlake, D., Schiller, J., and S. Crocker,
- "Randomness Requirements for Security", BCP 106,
- RFC 4086, June 2005.
-
- [RFC3344] Perkins, C., "IP Mobility Support for IPv4",
- RFC 3344, August 2002.
-
- [EAP-SIM] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible
- Authentication Protocol Method for Global System
- for Mobile Communications (GSM) Subscriber Identity
- Modules (EAP-SIM)", RFC 4186, January 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 76]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-Appendix A. Pseudo-Random Number Generator
-
- The "|" character denotes concatenation, and "^" denotes
- exponentiation.
-
- Step 1: Choose a new, secret value for the seed-key, XKEY
-
- Step 2: In hexadecimal notation let
- t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0
- This is the initial value for H0|H1|H2|H3|H4
- in the FIPS SHS [SHA-1]
-
- Step 3: For j = 0 to m - 1 do
- 3.1. XSEED_j = 0 /* no optional user input */
- 3.2. For i = 0 to 1 do
- a. XVAL = (XKEY + XSEED_j) mod 2^b
- b. w_i = G(t, XVAL)
- c. XKEY = (1 + XKEY + w_i) mod 2^b
- 3.3. x_j = w_0|w_1
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 77]
-\f
-RFC 4187 EAP-AKA Authentication January 2006
-
-
-Authors' Addresses
-
- Jari Arkko
- Ericsson
- FIN-02420 Jorvas
- Finland
-
- EMail: jari.Arkko@ericsson.com
-
-
- Henry Haverinen
- Nokia Enterprise Solutions
- P.O. Box 12
- FIN-40101 Jyvaskyla
- Finland
-
- EMail: henry.haverinen@nokia.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 78]
-\f
-RFC 4187 EAP-AKA Authentication January 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).
-
-
-
-
-
-
-
-Arkko & Haverinen Informational [Page 79]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group S. Kent
-Request for Comments: 4301 K. Seo
-Obsoletes: 2401 BBN Technologies
-Category: Standards Track December 2005
-
-
- Security Architecture for the Internet Protocol
-
-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
-
- This document describes an updated version of the "Security
- Architecture for IP", which is designed to provide security services
- for traffic at the IP layer. This document obsoletes RFC 2401
- (November 1998).
-
-Dedication
-
- This document is dedicated to the memory of Charlie Lynn, a long-time
- senior colleague at BBN, who made very significant contributions to
- the IPsec documents.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 1]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
-Table of Contents
-
- 1. Introduction ....................................................4
- 1.1. Summary of Contents of Document ............................4
- 1.2. Audience ...................................................4
- 1.3. Related Documents ..........................................5
- 2. Design Objectives ...............................................5
- 2.1. Goals/Objectives/Requirements/Problem Description ..........5
- 2.2. Caveats and Assumptions ....................................6
- 3. System Overview .................................................7
- 3.1. What IPsec Does ............................................7
- 3.2. How IPsec Works ............................................9
- 3.3. Where IPsec Can Be Implemented ............................10
- 4. Security Associations ..........................................11
- 4.1. Definition and Scope ......................................12
- 4.2. SA Functionality ..........................................16
- 4.3. Combining SAs .............................................17
- 4.4. Major IPsec Databases .....................................18
- 4.4.1. The Security Policy Database (SPD) .................19
- 4.4.1.1. Selectors .................................26
- 4.4.1.2. Structure of an SPD Entry .................30
- 4.4.1.3. More Regarding Fields Associated
- with Next Layer Protocols .................32
- 4.4.2. Security Association Database (SAD) ................34
- 4.4.2.1. Data Items in the SAD .....................36
- 4.4.2.2. Relationship between SPD, PFP
- flag, packet, and SAD .....................38
- 4.4.3. Peer Authorization Database (PAD) ..................43
- 4.4.3.1. PAD Entry IDs and Matching Rules ..........44
- 4.4.3.2. IKE Peer Authentication Data ..............45
- 4.4.3.3. Child SA Authorization Data ...............46
- 4.4.3.4. How the PAD Is Used .......................46
- 4.5. SA and Key Management .....................................47
- 4.5.1. Manual Techniques ..................................48
- 4.5.2. Automated SA and Key Management ....................48
- 4.5.3. Locating a Security Gateway ........................49
- 4.6. SAs and Multicast .........................................50
- 5. IP Traffic Processing ..........................................50
- 5.1. Outbound IP Traffic Processing
- (protected-to-unprotected) ................................52
- 5.1.1. Handling an Outbound Packet That Must Be
- Discarded ..........................................54
- 5.1.2. Header Construction for Tunnel Mode ................55
- 5.1.2.1. IPv4: Header Construction for
- Tunnel Mode ...............................57
- 5.1.2.2. IPv6: Header Construction for
- Tunnel Mode ...............................59
- 5.2. Processing Inbound IP Traffic (unprotected-to-protected) ..59
-
-
-
-Kent & Seo Standards Track [Page 2]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- 6. ICMP Processing ................................................63
- 6.1. Processing ICMP Error Messages Directed to an
- IPsec Implementation ......................................63
- 6.1.1. ICMP Error Messages Received on the
- Unprotected Side of the Boundary ...................63
- 6.1.2. ICMP Error Messages Received on the
- Protected Side of the Boundary .....................64
- 6.2. Processing Protected, Transit ICMP Error Messages .........64
- 7. Handling Fragments (on the protected side of the IPsec
- boundary) ......................................................66
- 7.1. Tunnel Mode SAs that Carry Initial and Non-Initial
- Fragments .................................................67
- 7.2. Separate Tunnel Mode SAs for Non-Initial Fragments ........67
- 7.3. Stateful Fragment Checking ................................68
- 7.4. BYPASS/DISCARD Traffic ....................................69
- 8. Path MTU/DF Processing .........................................69
- 8.1. DF Bit ....................................................69
- 8.2. Path MTU (PMTU) Discovery .................................70
- 8.2.1. Propagation of PMTU ................................70
- 8.2.2. PMTU Aging .........................................71
- 9. Auditing .......................................................71
- 10. Conformance Requirements ......................................71
- 11. Security Considerations .......................................72
- 12. IANA Considerations ...........................................72
- 13. Differences from RFC 2401 .....................................72
- 14. Acknowledgements ..............................................75
- Appendix A: Glossary ..............................................76
- Appendix B: Decorrelation .........................................79
- B.1. Decorrelation Algorithm ...................................79
- Appendix C: ASN.1 for an SPD Entry ................................82
- Appendix D: Fragment Handling Rationale ...........................88
- D.1. Transport Mode and Fragments ..............................88
- D.2. Tunnel Mode and Fragments .................................89
- D.3. The Problem of Non-Initial Fragments ......................90
- D.4. BYPASS/DISCARD Traffic ....................................93
- D.5. Just say no to ports? .....................................94
- D.6. Other Suggested Solutions..................................94
- D.7. Consistency................................................95
- D.8. Conclusions................................................95
- Appendix E: Example of Supporting Nested SAs via SPD and
- Forwarding Table Entries...............................96
- References.........................................................98
- Normative References............................................98
- Informative References..........................................99
-
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 3]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
-1. Introduction
-
-1.1. Summary of Contents of Document
-
- This document specifies the base architecture for IPsec-compliant
- systems. It describes how to provide a set of security services for
- traffic at the IP layer, in both the IPv4 [Pos81a] and IPv6 [DH98]
- environments. This document describes the requirements for systems
- that implement IPsec, the fundamental elements of such systems, and
- how the elements fit together and fit into the IP environment. It
- also describes the security services offered by the IPsec protocols,
- and how these services can be employed in the IP environment. This
- document does not address all aspects of the IPsec architecture.
- Other documents address additional architectural details in
- specialized environments, e.g., use of IPsec in Network Address
- Translation (NAT) environments and more comprehensive support for IP
- multicast. The fundamental components of the IPsec security
- architecture are discussed in terms of their underlying, required
- functionality. Additional RFCs (see Section 1.3 for pointers to
- other documents) define the protocols in (a), (c), and (d).
-
- a. Security Protocols -- Authentication Header (AH) and
- Encapsulating Security Payload (ESP)
- b. Security Associations -- what they are and how they work,
- how they are managed, associated processing
- c. Key Management -- manual and automated (The Internet Key
- Exchange (IKE))
- d. Cryptographic algorithms for authentication and encryption
-
- This document is not a Security Architecture for the Internet; it
- addresses security only at the IP layer, provided through the use of
- a combination of cryptographic and protocol security mechanisms.
-
- The spelling "IPsec" is preferred and used throughout this and all
- related IPsec standards. All other capitalizations of IPsec (e.g.,
- IPSEC, IPSec, ipsec) are deprecated. However, any capitalization of
- the sequence of letters "IPsec" should be understood to refer to the
- IPsec protocols.
-
- The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
- SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
- document, are to be interpreted as described in RFC 2119 [Bra97].
-
-1.2. Audience
-
- The target audience for this document is primarily individuals who
- implement this IP security technology or who architect systems that
- will use this technology. Technically adept users of this technology
-
-
-
-Kent & Seo Standards Track [Page 4]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- (end users or system administrators) also are part of the target
- audience. A glossary is provided in Appendix A to help fill in gaps
- in background/vocabulary. This document assumes that the reader is
- familiar with the Internet Protocol (IP), related networking
- technology, and general information system security terms and
- concepts.
-
-1.3. Related Documents
-
- As mentioned above, other documents provide detailed definitions of
- some of the components of IPsec and of their interrelationship. They
- include RFCs on the following topics:
-
- a. security protocols -- RFCs describing the Authentication
- Header (AH) [Ken05b] and Encapsulating Security Payload
- (ESP) [Ken05a] protocols.
- b. cryptographic algorithms for integrity and encryption -- one
- RFC that defines the mandatory, default algorithms for use
- with AH and ESP [Eas05], a similar RFC that defines the
- mandatory algorithms for use with IKEv2 [Sch05] plus a
- separate RFC for each cryptographic algorithm.
- c. automatic key management -- RFCs on "The Internet Key
- Exchange (IKEv2) Protocol" [Kau05] and "Cryptographic
- Algorithms for Use in the Internet Key Exchange Version 2
- (IKEv2)" [Sch05].
-
-2. Design Objectives
-
-2.1. Goals/Objectives/Requirements/Problem Description
-
- IPsec is designed to provide interoperable, high quality,
- cryptographically-based security for IPv4 and IPv6. The set of
- security services offered includes access control, connectionless
- integrity, data origin authentication, detection and rejection of
- replays (a form of partial sequence integrity), confidentiality (via
- encryption), and limited traffic flow confidentiality. These
- services are provided at the IP layer, offering protection in a
- standard fashion for all protocols that may be carried over IP
- (including IP itself).
-
- IPsec includes a specification for minimal firewall functionality,
- since that is an essential aspect of access control at the IP layer.
- Implementations are free to provide more sophisticated firewall
- mechanisms, and to implement the IPsec-mandated functionality using
- those more sophisticated mechanisms. (Note that interoperability may
- suffer if additional firewall constraints on traffic flows are
- imposed by an IPsec implementation but cannot be negotiated based on
- the traffic selector features defined in this document and negotiated
-
-
-
-Kent & Seo Standards Track [Page 5]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- via IKEv2.) The IPsec firewall function makes use of the
- cryptographically-enforced authentication and integrity provided for
- all IPsec traffic to offer better access control than could be
- obtained through use of a firewall (one not privy to IPsec internal
- parameters) plus separate cryptographic protection.
-
- Most of the security services are provided through use of two traffic
- security protocols, the Authentication Header (AH) and the
- Encapsulating Security Payload (ESP), and through the use of
- cryptographic key management procedures and protocols. The set of
- IPsec protocols employed in a context, and the ways in which they are
- employed, will be determined by the users/administrators in that
- context. It is the goal of the IPsec architecture to ensure that
- compliant implementations include the services and management
- interfaces needed to meet the security requirements of a broad user
- population.
-
- When IPsec is correctly implemented and deployed, it ought not
- adversely affect users, hosts, and other Internet components that do
- not employ IPsec for traffic protection. IPsec security protocols
- (AH and ESP, and to a lesser extent, IKE) are designed to be
- cryptographic algorithm independent. This modularity permits
- selection of different sets of cryptographic algorithms as
- appropriate, without affecting the other parts of the implementation.
- For example, different user communities may select different sets of
- cryptographic algorithms (creating cryptographically-enforced
- cliques) if required.
-
- To facilitate interoperability in the global Internet, a set of
- default cryptographic algorithms for use with AH and ESP is specified
- in [Eas05] and a set of mandatory-to-implement algorithms for IKEv2
- is specified in [Sch05]. [Eas05] and [Sch05] will be periodically
- updated to keep pace with computational and cryptologic advances. By
- specifying these algorithms in documents that are separate from the
- AH, ESP, and IKEv2 specifications, these algorithms can be updated or
- replaced without affecting the standardization progress of the rest
- of the IPsec document suite. The use of these cryptographic
- algorithms, in conjunction with IPsec traffic protection and key
- management protocols, is intended to permit system and application
- developers to deploy high quality, Internet-layer, cryptographic
- security technology.
-
-2.2. Caveats and Assumptions
-
- The suite of IPsec protocols and associated default cryptographic
- algorithms are designed to provide high quality security for Internet
- traffic. However, the security offered by use of these protocols
- ultimately depends on the quality of their implementation, which is
-
-
-
-Kent & Seo Standards Track [Page 6]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- outside the scope of this set of standards. Moreover, the security
- of a computer system or network is a function of many factors,
- including personnel, physical, procedural, compromising emanations,
- and computer security practices. Thus, IPsec is only one part of an
- overall system security architecture.
-
- Finally, the security afforded by the use of IPsec is critically
- dependent on many aspects of the operating environment in which the
- IPsec implementation executes. For example, defects in OS security,
- poor quality of random number sources, sloppy system management
- protocols and practices, etc., can all degrade the security provided
- by IPsec. As above, none of these environmental attributes are
- within the scope of this or other IPsec standards.
-
-3. System Overview
-
- This section provides a high level description of how IPsec works,
- the components of the system, and how they fit together to provide
- the security services noted above. The goal of this description is
- to enable the reader to "picture" the overall process/system, see how
- it fits into the IP environment, and to provide context for later
- sections of this document, which describe each of the components in
- more detail.
-
- An IPsec implementation operates in a host, as a security gateway
- (SG), or as an independent device, affording protection to IP
- traffic. (A security gateway is an intermediate system implementing
- IPsec, e.g., a firewall or router that has been IPsec-enabled.) More
- detail on these classes of implementations is provided later, in
- Section 3.3. The protection offered by IPsec is based on requirements
- defined by a Security Policy Database (SPD) established and
- maintained by a user or system administrator, or by an application
- operating within constraints established by either of the above. In
- general, packets are selected for one of three processing actions
- based on IP and next layer header information ("Selectors", Section
- 4.4.1.1) matched against entries in the SPD. Each packet is either
- PROTECTed using IPsec security services, DISCARDed, or allowed to
- BYPASS IPsec protection, based on the applicable SPD policies
- identified by the Selectors.
-
-3.1. What IPsec Does
-
- IPsec creates a boundary between unprotected and protected
- interfaces, for a host or a network (see Figure 1 below). Traffic
- traversing the boundary is subject to the access controls specified
- by the user or administrator responsible for the IPsec configuration.
- These controls indicate whether packets cross the boundary unimpeded,
- are afforded security services via AH or ESP, or are discarded.
-
-
-
-Kent & Seo Standards Track [Page 7]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- IPsec security services are offered at the IP layer through selection
- of appropriate security protocols, cryptographic algorithms, and
- cryptographic keys. IPsec can be used to protect one or more "paths"
- (a) between a pair of hosts, (b) between a pair of security gateways,
- or (c) between a security gateway and a host. A compliant host
- implementation MUST support (a) and (c) and a compliant security
- gateway must support all three of these forms of connectivity, since
- under certain circumstances a security gateway acts as a host.
-
- Unprotected
- ^ ^
- | |
- +-------------|-------|-------+
- | +-------+ | | |
- | |Discard|<--| V |
- | +-------+ |B +--------+ |
- ................|y..| AH/ESP |..... IPsec Boundary
- | +---+ |p +--------+ |
- | |IKE|<----|a ^ |
- | +---+ |s | |
- | +-------+ |s | |
- | |Discard|<--| | |
- | +-------+ | | |
- +-------------|-------|-------+
- | |
- V V
- Protected
-
- Figure 1. Top Level IPsec Processing Model
-
- In this diagram, "unprotected" refers to an interface that might also
- be described as "black" or "ciphertext". Here, "protected" refers to
- an interface that might also be described as "red" or "plaintext".
- The protected interface noted above may be internal, e.g., in a host
- implementation of IPsec, the protected interface may link to a socket
- layer interface presented by the OS. In this document, the term
- "inbound" refers to traffic entering an IPsec implementation via the
- unprotected interface or emitted by the implementation on the
- unprotected side of the boundary and directed towards the protected
- interface. The term "outbound" refers to traffic entering the
- implementation via the protected interface, or emitted by the
- implementation on the protected side of the boundary and directed
- toward the unprotected interface. An IPsec implementation may
- support more than one interface on either or both sides of the
- boundary.
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 8]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- Note the facilities for discarding traffic on either side of the
- IPsec boundary, the BYPASS facility that allows traffic to transit
- the boundary without cryptographic protection, and the reference to
- IKE as a protected-side key and security management function.
-
- IPsec optionally supports negotiation of IP compression [SMPT01],
- motivated in part by the observation that when encryption is employed
- within IPsec, it prevents effective compression by lower protocol
- layers.
-
-3.2. How IPsec Works
-
- IPsec uses two protocols to provide traffic security services --
- Authentication Header (AH) and Encapsulating Security Payload (ESP).
- Both protocols are described in detail in their respective RFCs
- [Ken05b, Ken05a]. IPsec implementations MUST support ESP and MAY
- support AH. (Support for AH has been downgraded to MAY because
- experience has shown that there are very few contexts in which ESP
- cannot provide the requisite security services. Note that ESP can be
- used to provide only integrity, without confidentiality, making it
- comparable to AH in most contexts.)
-
- o The IP Authentication Header (AH) [Ken05b] offers integrity and
- data origin authentication, with optional (at the discretion of
- the receiver) anti-replay features.
-
- o The Encapsulating Security Payload (ESP) protocol [Ken05a] offers
- the same set of services, and also offers confidentiality. Use of
- ESP to provide confidentiality without integrity is NOT
- RECOMMENDED. When ESP is used with confidentiality enabled, there
- are provisions for limited traffic flow confidentiality, i.e.,
- provisions for concealing packet length, and for facilitating
- efficient generation and discard of dummy packets. This
- capability is likely to be effective primarily in virtual private
- network (VPN) and overlay network contexts.
-
- o Both AH and ESP offer access control, enforced through the
- distribution of cryptographic keys and the management of traffic
- flows as dictated by the Security Policy Database (SPD, Section
- 4.4.1).
-
- These protocols may be applied individually or in combination with
- each other to provide IPv4 and IPv6 security services. However, most
- security requirements can be met through the use of ESP by itself.
- Each protocol supports two modes of use: transport mode and tunnel
- mode. In transport mode, AH and ESP provide protection primarily for
-
-
-
-
-
-Kent & Seo Standards Track [Page 9]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- next layer protocols; in tunnel mode, AH and ESP are applied to
- tunneled IP packets. The differences between the two modes are
- discussed in Section 4.1.
-
- IPsec allows the user (or system administrator) to control the
- granularity at which a security service is offered. For example, one
- can create a single encrypted tunnel to carry all the traffic between
- two security gateways, or a separate encrypted tunnel can be created
- for each TCP connection between each pair of hosts communicating
- across these gateways. IPsec, through the SPD management paradigm,
- incorporates facilities for specifying:
-
- o which security protocol (AH or ESP) to employ, the mode (transport
- or tunnel), security service options, what cryptographic
- algorithms to use, and in what combinations to use the specified
- protocols and services, and
-
- o the granularity at which protection should be applied.
-
- Because most of the security services provided by IPsec require the
- use of cryptographic keys, IPsec relies on a separate set of
- mechanisms for putting these keys in place. This document requires
- support for both manual and automated distribution of keys. It
- specifies a specific public-key based approach (IKEv2 [Kau05]) for
- automated key management, but other automated key distribution
- techniques MAY be used.
-
- Note: This document mandates support for several features for which
- support is available in IKEv2 but not in IKEv1, e.g., negotiation of
- an SA representing ranges of local and remote ports or negotiation of
- multiple SAs with the same selectors. Therefore, this document
- assumes use of IKEv2 or a key and security association management
- system with comparable features.
-
-3.3. Where IPsec Can Be Implemented
-
- There are many ways in which IPsec may be implemented in a host, or
- in conjunction with a router or firewall to create a security
- gateway, or as an independent security device.
-
- a. IPsec may be integrated into the native IP stack. This requires
- access to the IP source code and is applicable to both hosts and
- security gateways, although native host implementations benefit
- the most from this strategy, as explained later (Section 4.4.1,
- paragraph 6; Section 4.4.1.1, last paragraph).
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 10]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- b. In a "bump-in-the-stack" (BITS) implementation, IPsec is
- implemented "underneath" an existing implementation of an IP
- protocol stack, between the native IP and the local network
- drivers. Source code access for the IP stack is not required in
- this context, making this implementation approach appropriate for
- use with legacy systems. This approach, when it is adopted, is
- usually employed in hosts.
-
- c. The use of a dedicated, inline security protocol processor is a
- common design feature of systems used by the military, and of some
- commercial systems as well. It is sometimes referred to as a
- "bump-in-the-wire" (BITW) implementation. Such implementations
- may be designed to serve either a host or a gateway. Usually, the
- BITW device is itself IP addressable. When supporting a single
- host, it may be quite analogous to a BITS implementation, but in
- supporting a router or firewall, it must operate like a security
- gateway.
-
- This document often talks in terms of use of IPsec by a host or a
- security gateway, without regard to whether the implementation is
- native, BITS, or BITW. When the distinctions among these
- implementation options are significant, the document makes reference
- to specific implementation approaches.
-
- A host implementation of IPsec may appear in devices that might not
- be viewed as "hosts". For example, a router might employ IPsec to
- protect routing protocols (e.g., BGP) and management functions (e.g.,
- Telnet), without affecting subscriber traffic traversing the router.
- A security gateway might employ separate IPsec implementations to
- protect its management traffic and subscriber traffic. The
- architecture described in this document is very flexible. For
- example, a computer with a full-featured, compliant, native OS IPsec
- implementation should be capable of being configured to protect
- resident (host) applications and to provide security gateway
- protection for traffic traversing the computer. Such configuration
- would make use of the forwarding tables and the SPD selection
- function described in Sections 5.1 and 5.2.
-
-4. Security Associations
-
- This section defines Security Association management requirements for
- all IPv6 implementations and for those IPv4 implementations that
- implement AH, ESP, or both AH and ESP. The concept of a "Security
- Association" (SA) is fundamental to IPsec. Both AH and ESP make use
- of SAs, and a major function of IKE is the establishment and
- maintenance of SAs. All implementations of AH or ESP MUST support
- the concept of an SA as described below. The remainder of this
-
-
-
-
-Kent & Seo Standards Track [Page 11]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- section describes various aspects of SA management, defining required
- characteristics for SA policy management and SA management
- techniques.
-
-4.1. Definition and Scope
-
- An SA is a simplex "connection" that affords security services to the
- traffic carried by it. Security services are afforded to an SA by
- the use of AH, or ESP, but not both. If both AH and ESP protection
- are applied to a traffic stream, then two SAs must be created and
- coordinated to effect protection through iterated application of the
- security protocols. To secure typical, bi-directional communication
- between two IPsec-enabled systems, a pair of SAs (one in each
- direction) is required. IKE explicitly creates SA pairs in
- recognition of this common usage requirement.
-
- For an SA used to carry unicast traffic, the Security Parameters
- Index (SPI) by itself suffices to specify an SA. (For information on
- the SPI, see Appendix A and the AH and ESP specifications [Ken05b,
- Ken05a].) However, as a local matter, an implementation may choose
- to use the SPI in conjunction with the IPsec protocol type (AH or
- ESP) for SA identification. If an IPsec implementation supports
- multicast, then it MUST support multicast SAs using the algorithm
- below for mapping inbound IPsec datagrams to SAs. Implementations
- that support only unicast traffic need not implement this de-
- multiplexing algorithm.
-
- In many secure multicast architectures, e.g., [RFC3740], a central
- Group Controller/Key Server unilaterally assigns the Group Security
- Association's (GSA's) SPI. This SPI assignment is not negotiated or
- coordinated with the key management (e.g., IKE) subsystems that
- reside in the individual end systems that constitute the group.
- Consequently, it is possible that a GSA and a unicast SA can
- simultaneously use the same SPI. A multicast-capable IPsec
- implementation MUST correctly de-multiplex inbound traffic even in
- the context of SPI collisions.
-
- Each entry in the SA Database (SAD) (Section 4.4.2) must indicate
- whether the SA lookup makes use of the destination IP address, or the
- destination and source IP addresses, in addition to the SPI. For
- multicast SAs, the protocol field is not employed for SA lookups.
- For each inbound, IPsec-protected packet, an implementation must
- conduct its search of the SAD such that it finds the entry that
- matches the "longest" SA identifier. In this context, if two or more
- SAD entries match based on the SPI value, then the entry that also
- matches based on destination address, or destination and source
- address (as indicated in the SAD entry) is the "longest" match. This
- implies a logical ordering of the SAD search as follows:
-
-
-
-Kent & Seo Standards Track [Page 12]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- 1. Search the SAD for a match on the combination of SPI,
- destination address, and source address. If an SAD entry
- matches, then process the inbound packet with that
- matching SAD entry. Otherwise, proceed to step 2.
-
- 2. Search the SAD for a match on both SPI and destination address.
- If the SAD entry matches, then process the inbound packet
- with that matching SAD entry. Otherwise, proceed to step 3.
-
- 3. Search the SAD for a match on only SPI if the receiver has
- chosen to maintain a single SPI space for AH and ESP, and on
- both SPI and protocol, otherwise. If an SAD entry matches,
- then process the inbound packet with that matching SAD entry.
- Otherwise, discard the packet and log an auditable event.
-
- In practice, an implementation may choose any method (or none at all)
- to accelerate this search, although its externally visible behavior
- MUST be functionally equivalent to having searched the SAD in the
- above order. For example, a software-based implementation could
- index into a hash table by the SPI. The SAD entries in each hash
- table bucket's linked list could be kept sorted to have those SAD
- entries with the longest SA identifiers first in that linked list.
- Those SAD entries having the shortest SA identifiers could be sorted
- so that they are the last entries in the linked list. A
- hardware-based implementation may be able to effect the longest match
- search intrinsically, using commonly available Ternary
- Content-Addressable Memory (TCAM) features.
-
- The indication of whether source and destination address matching is
- required to map inbound IPsec traffic to SAs MUST be set either as a
- side effect of manual SA configuration or via negotiation using an SA
- management protocol, e.g., IKE or Group Domain of Interpretation
- (GDOI) [RFC3547]. Typically, Source-Specific Multicast (SSM) [HC03]
- groups use a 3-tuple SA identifier composed of an SPI, a destination
- multicast address, and source address. An Any-Source Multicast group
- SA requires only an SPI and a destination multicast address as an
- identifier.
-
- If different classes of traffic (distinguished by Differentiated
- Services Code Point (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on
- the same SA, and if the receiver is employing the optional
- anti-replay feature available in both AH and ESP, this could result
- in inappropriate discarding of lower priority packets due to the
- windowing mechanism used by this feature. Therefore, a sender SHOULD
- put traffic of different classes, but with the same selector values,
- on different SAs to support Quality of Service (QoS) appropriately.
- To permit this, the IPsec implementation MUST permit establishment
- and maintenance of multiple SAs between a given sender and receiver,
-
-
-
-Kent & Seo Standards Track [Page 13]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- with the same selectors. Distribution of traffic among these
- parallel SAs to support QoS is locally determined by the sender and
- is not negotiated by IKE. The receiver MUST process the packets from
- the different SAs without prejudice. These requirements apply to
- both transport and tunnel mode SAs. In the case of tunnel mode SAs,
- the DSCP values in question appear in the inner IP header. In
- transport mode, the DSCP value might change en route, but this should
- not cause problems with respect to IPsec processing since the value
- is not employed for SA selection and MUST NOT be checked as part of
- SA/packet validation. However, if significant re-ordering of packets
- occurs in an SA, e.g., as a result of changes to DSCP values en
- route, this may trigger packet discarding by a receiver due to
- application of the anti-replay mechanism.
-
- DISCUSSION: Although the DSCP [NiBlBaBL98, Gro02] and Explicit
- Congestion Notification (ECN) [RaFlBl01] fields are not "selectors",
- as that term in used in this architecture, the sender will need a
- mechanism to direct packets with a given (set of) DSCP values to the
- appropriate SA. This mechanism might be termed a "classifier".
-
- As noted above, two types of SAs are defined: transport mode and
- tunnel mode. IKE creates pairs of SAs, so for simplicity, we choose
- to require that both SAs in a pair be of the same mode, transport or
- tunnel.
-
- A transport mode SA is an SA typically employed between a pair of
- hosts to provide end-to-end security services. When security is
- desired between two intermediate systems along a path (vs. end-to-end
- use of IPsec), transport mode MAY be used between security gateways
- or between a security gateway and a host. In the case where
- transport mode is used between security gateways or between a
- security gateway and a host, transport mode may be used to support
- in-IP tunneling (e.g., IP-in-IP [Per96] or Generic Routing
- Encapsulation (GRE) tunneling [FaLiHaMeTr00] or dynamic routing
- [ToEgWa04]) over transport mode SAs. To clarify, the use of
- transport mode by an intermediate system (e.g., a security gateway)
- is permitted only when applied to packets whose source address (for
- outbound packets) or destination address (for inbound packets) is an
- address belonging to the intermediate system itself. The access
- control functions that are an important part of IPsec are
- significantly limited in this context, as they cannot be applied to
- the end-to-end headers of the packets that traverse a transport mode
- SA used in this fashion. Thus, this way of using transport mode
- should be evaluated carefully before being employed in a specific
- context.
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 14]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- In IPv4, a transport mode security protocol header appears
- immediately after the IP header and any options, and before any next
- layer protocols (e.g., TCP or UDP). In IPv6, the security protocol
- header appears after the base IP header and selected extension
- headers, but may appear before or after destination options; it MUST
- appear before next layer protocols (e.g., TCP, UDP, Stream Control
- Transmission Protocol (SCTP)). In the case of ESP, a transport mode
- SA provides security services only for these next layer protocols,
- not for the IP header or any extension headers preceding the ESP
- header. In the case of AH, the protection is also extended to
- selected portions of the IP header preceding it, selected portions of
- extension headers, and selected options (contained in the IPv4
- header, IPv6 Hop-by-Hop extension header, or IPv6 Destination
- extension headers). For more details on the coverage afforded by AH,
- see the AH specification [Ken05b].
-
- A tunnel mode SA is essentially an SA applied to an IP tunnel, with
- the access controls applied to the headers of the traffic inside the
- tunnel. Two hosts MAY establish a tunnel mode SA between themselves.
- Aside from the two exceptions below, whenever either end of a
- security association is a security gateway, the SA MUST be tunnel
- mode. Thus, an SA between two security gateways is typically a
- tunnel mode SA, as is an SA between a host and a security gateway.
- The two exceptions are as follows.
-
- o Where traffic is destined for a security gateway, e.g., Simple
- Network Management Protocol (SNMP) commands, the security gateway
- is acting as a host and transport mode is allowed. In this case,
- the SA terminates at a host (management) function within a
- security gateway and thus merits different treatment.
-
- o As noted above, security gateways MAY support a transport mode SA
- to provide security for IP traffic between two intermediate
- systems along a path, e.g., between a host and a security gateway
- or between two security gateways.
-
- Several concerns motivate the use of tunnel mode for an SA involving
- a security gateway. For example, if there are multiple paths (e.g.,
- via different security gateways) to the same destination behind a
- security gateway, it is important that an IPsec packet be sent to the
- security gateway with which the SA was negotiated. Similarly, a
- packet that might be fragmented en route must have all the fragments
- delivered to the same IPsec instance for reassembly prior to
- cryptographic processing. Also, when a fragment is processed by
- IPsec and transmitted, then fragmented en route, it is critical that
- there be inner and outer headers to retain the fragmentation state
- data for the pre- and post-IPsec packet formats. Hence there are
- several reasons for employing tunnel mode when either end of an SA is
-
-
-
-Kent & Seo Standards Track [Page 15]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- a security gateway. (Use of an IP-in-IP tunnel in conjunction with
- transport mode can also address these fragmentation issues. However,
- this configuration limits the ability of IPsec to enforce access
- control policies on traffic.)
-
- Note: AH and ESP cannot be applied using transport mode to IPv4
- packets that are fragments. Only tunnel mode can be employed in such
- cases. For IPv6, it would be feasible to carry a plaintext fragment
- on a transport mode SA; however, for simplicity, this restriction
- also applies to IPv6 packets. See Section 7 for more details on
- handling plaintext fragments on the protected side of the IPsec
- barrier.
-
- For a tunnel mode SA, there is an "outer" IP header that specifies
- the IPsec processing source and destination, plus an "inner" IP
- header that specifies the (apparently) ultimate source and
- destination for the packet. The security protocol header appears
- after the outer IP header, and before the inner IP header. If AH is
- employed in tunnel mode, portions of the outer IP header are afforded
- protection (as above), as well as all of the tunneled IP packet
- (i.e., all of the inner IP header is protected, as well as next layer
- protocols). If ESP is employed, the protection is afforded only to
- the tunneled packet, not to the outer header.
-
- In summary,
-
- a) A host implementation of IPsec MUST support both transport and
- tunnel mode. This is true for native, BITS, and BITW
- implementations for hosts.
-
- b) A security gateway MUST support tunnel mode and MAY support
- transport mode. If it supports transport mode, that should be
- used only when the security gateway is acting as a host, e.g., for
- network management, or to provide security between two
- intermediate systems along a path.
-
-4.2. SA Functionality
-
- The set of security services offered by an SA depends on the security
- protocol selected, the SA mode, the endpoints of the SA, and the
- election of optional services within the protocol.
-
- For example, both AH and ESP offer integrity and authentication
- services, but the coverage differs for each protocol and differs for
- transport vs. tunnel mode. If the integrity of an IPv4 option or
- IPv6 extension header must be protected en route between sender and
- receiver, AH can provide this service, except for IP or extension
- headers that may change in a fashion not predictable by the sender.
-
-
-
-Kent & Seo Standards Track [Page 16]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- However, the same security may be achieved in some contexts by
- applying ESP to a tunnel carrying a packet.
-
- The granularity of access control provided is determined by the
- choice of the selectors that define each SA. Moreover, the
- authentication means employed by IPsec peers, e.g., during creation
- of an IKE (vs. child) SA also affects the granularity of the access
- control afforded.
-
- If confidentiality is selected, then an ESP (tunnel mode) SA between
- two security gateways can offer partial traffic flow confidentiality.
- The use of tunnel mode allows the inner IP headers to be encrypted,
- concealing the identities of the (ultimate) traffic source and
- destination. Moreover, ESP payload padding also can be invoked to
- hide the size of the packets, further concealing the external
- characteristics of the traffic. Similar traffic flow confidentiality
- services may be offered when a mobile user is assigned a dynamic IP
- address in a dialup context, and establishes a (tunnel mode) ESP SA
- to a corporate firewall (acting as a security gateway). Note that
- fine-granularity SAs generally are more vulnerable to traffic
- analysis than coarse-granularity ones that are carrying traffic from
- many subscribers.
-
- Note: A compliant implementation MUST NOT allow instantiation of an
- ESP SA that employs both NULL encryption and no integrity algorithm.
- An attempt to negotiate such an SA is an auditable event by both
- initiator and responder. The audit log entry for this event SHOULD
- include the current date/time, local IKE IP address, and remote IKE
- IP address. The initiator SHOULD record the relevant SPD entry.
-
-4.3. Combining SAs
-
- This document does not require support for nested security
- associations or for what RFC 2401 [RFC2401] called "SA bundles".
- These features still can be effected by appropriate configuration of
- both the SPD and the local forwarding functions (for inbound and
- outbound traffic), but this capability is outside of the IPsec module
- and thus the scope of this specification. As a result, management of
- nested/bundled SAs is potentially more complex and less assured than
- under the model implied by RFC 2401 [RFC2401]. An implementation
- that provides support for nested SAs SHOULD provide a management
- interface that enables a user or administrator to express the nesting
- requirement, and then create the appropriate SPD entries and
- forwarding table entries to effect the requisite processing. (See
- Appendix E for an example of how to configure nested SAs.)
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 17]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
-4.4. Major IPsec Databases
-
- Many of the details associated with processing IP traffic in an IPsec
- implementation are largely a local matter, not subject to
- standardization. However, some external aspects of the processing
- must be standardized to ensure interoperability and to provide a
- minimum management capability that is essential for productive use of
- IPsec. This section describes a general model for processing IP
- traffic relative to IPsec functionality, in support of these
- interoperability and functionality goals. The model described below
- is nominal; implementations need not match details of this model as
- presented, but the external behavior of implementations MUST
- correspond to the externally observable characteristics of this model
- in order to be compliant.
-
- There are three nominal databases in this model: the Security Policy
- Database (SPD), the Security Association Database (SAD), and the Peer
- Authorization Database (PAD). The first specifies the policies that
- determine the disposition of all IP traffic inbound or outbound from
- a host or security gateway (Section 4.4.1). The second database
- contains parameters that are associated with each established (keyed)
- SA (Section 4.4.2). The third database, the PAD, provides a link
- between an SA management protocol (such as IKE) and the SPD (Section
- 4.4.3).
-
- Multiple Separate IPsec Contexts
-
- If an IPsec implementation acts as a security gateway for multiple
- subscribers, it MAY implement multiple separate IPsec contexts.
- Each context MAY have and MAY use completely independent
- identities, policies, key management SAs, and/or IPsec SAs. This
- is for the most part a local implementation matter. However, a
- means for associating inbound (SA) proposals with local contexts
- is required. To this end, if supported by the key management
- protocol in use, context identifiers MAY be conveyed from
- initiator to responder in the signaling messages, with the result
- that IPsec SAs are created with a binding to a particular context.
- For example, a security gateway that provides VPN service to
- multiple customers will be able to associate each customer's
- traffic with the correct VPN.
-
- Forwarding vs Security Decisions
-
- The IPsec model described here embodies a clear separation between
- forwarding (routing) and security decisions, to accommodate a wide
- range of contexts where IPsec may be employed. Forwarding may be
- trivial, in the case where there are only two interfaces, or it
- may be complex, e.g., if the context in which IPsec is implemented
-
-
-
-Kent & Seo Standards Track [Page 18]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- employs a sophisticated forwarding function. IPsec assumes only
- that outbound and inbound traffic that has passed through IPsec
- processing is forwarded in a fashion consistent with the context
- in which IPsec is implemented. Support for nested SAs is
- optional; if required, it requires coordination between forwarding
- tables and SPD entries to cause a packet to traverse the IPsec
- boundary more than once.
-
- "Local" vs "Remote"
-
- In this document, with respect to IP addresses and ports, the
- terms "Local" and "Remote" are used for policy rules. "Local"
- refers to the entity being protected by an IPsec implementation,
- i.e., the "source" address/port of outbound packets or the
- "destination" address/port of inbound packets. "Remote" refers to
- a peer entity or peer entities. The terms "source" and
- "destination" are used for packet header fields.
-
- "Non-initial" vs "Initial" Fragments
-
- Throughout this document, the phrase "non-initial fragments" is
- used to mean fragments that do not contain all of the selector
- values that may be needed for access control (e.g., they might not
- contain Next Layer Protocol, source and destination ports, ICMP
- message type/code, Mobility Header type). And the phrase "initial
- fragment" is used to mean a fragment that contains all the
- selector values needed for access control. However, it should be
- noted that for IPv6, which fragment contains the Next Layer
- Protocol and ports (or ICMP message type/code or Mobility Header
- type [Mobip]) will depend on the kind and number of extension
- headers present. The "initial fragment" might not be the first
- fragment, in this context.
-
-4.4.1. The Security Policy Database (SPD)
-
- An SA is a management construct used to enforce security policy for
- traffic crossing the IPsec boundary. Thus, an essential element of
- SA processing is an underlying Security Policy Database (SPD) that
- specifies what services are to be offered to IP datagrams and in what
- fashion. The form of the database and its interface are outside the
- scope of this specification. However, this section specifies minimum
- management functionality that must be provided, to allow a user or
- system administrator to control whether and how IPsec is applied to
- traffic transmitted or received by a host or transiting a security
- gateway. The SPD, or relevant caches, must be consulted during the
- processing of all traffic (inbound and outbound), including traffic
- not protected by IPsec, that traverses the IPsec boundary. This
- includes IPsec management traffic such as IKE. An IPsec
-
-
-
-Kent & Seo Standards Track [Page 19]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- implementation MUST have at least one SPD, and it MAY support
- multiple SPDs, if appropriate for the context in which the IPsec
- implementation operates. There is no requirement to maintain SPDs on
- a per-interface basis, as was specified in RFC 2401 [RFC2401].
- However, if an implementation supports multiple SPDs, then it MUST
- include an explicit SPD selection function that is invoked to select
- the appropriate SPD for outbound traffic processing. The inputs to
- this function are the outbound packet and any local metadata (e.g.,
- the interface via which the packet arrived) required to effect the
- SPD selection function. The output of the function is an SPD
- identifier (SPD-ID).
-
- The SPD is an ordered database, consistent with the use of Access
- Control Lists (ACLs) or packet filters in firewalls, routers, etc.
- The ordering requirement arises because entries often will overlap
- due to the presence of (non-trivial) ranges as values for selectors.
- Thus, a user or administrator MUST be able to order the entries to
- express a desired access control policy. There is no way to impose a
- general, canonical order on SPD entries, because of the allowed use
- of wildcards for selector values and because the different types of
- selectors are not hierarchically related.
-
- Processing Choices: DISCARD, BYPASS, PROTECT
-
- An SPD must discriminate among traffic that is afforded IPsec
- protection and traffic that is allowed to bypass IPsec. This
- applies to the IPsec protection to be applied by a sender and to
- the IPsec protection that must be present at the receiver. For
- any outbound or inbound datagram, three processing choices are
- possible: DISCARD, BYPASS IPsec, or PROTECT using IPsec. The
- first choice refers to traffic that is not allowed to traverse the
- IPsec boundary (in the specified direction). The second choice
- refers to traffic that is allowed to cross the IPsec boundary
- without IPsec protection. The third choice refers to traffic that
- is afforded IPsec protection, and for such traffic the SPD must
- specify the security protocols to be employed, their mode,
- security service options, and the cryptographic algorithms to be
- used.
-
- SPD-S, SPD-I, SPD-O
-
- An SPD is logically divided into three pieces. The SPD-S (secure
- traffic) contains entries for all traffic subject to IPsec
- protection. SPD-O (outbound) contains entries for all outbound
- traffic that is to be bypassed or discarded. SPD-I (inbound) is
- applied to inbound traffic that will be bypassed or discarded.
- All three of these can be decorrelated (with the exception noted
- above for native host implementations) to facilitate caching. If
-
-
-
-Kent & Seo Standards Track [Page 20]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- an IPsec implementation supports only one SPD, then the SPD
- consists of all three parts. If multiple SPDs are supported, some
- of them may be partial, e.g., some SPDs might contain only SPD-I
- entries, to control inbound bypassed traffic on a per-interface
- basis. The split allows SPD-I to be consulted without having to
- consult SPD-S, for such traffic. Since the SPD-I is just a part
- of the SPD, if a packet that is looked up in the SPD-I cannot be
- matched to an entry there, then the packet MUST be discarded.
- Note that for outbound traffic, if a match is not found in SPD-S,
- then SPD-O must be checked to see if the traffic should be
- bypassed. Similarly, if SPD-O is checked first and no match is
- found, then SPD-S must be checked. In an ordered,
- non-decorrelated SPD, the entries for the SPD-S, SPD-I, and SPD-O
- are interleaved. So there is one lookup in the SPD.
-
- SPD Entries
-
- Each SPD entry specifies packet disposition as BYPASS, DISCARD, or
- PROTECT. The entry is keyed by a list of one or more selectors.
- The SPD contains an ordered list of these entries. The required
- selector types are defined in Section 4.4.1.1. These selectors are
- used to define the granularity of the SAs that are created in
- response to an outbound packet or in response to a proposal from a
- peer. The detailed structure of an SPD entry is described in
- Section 4.4.1.2. Every SPD SHOULD have a nominal, final entry that
- matches anything that is otherwise unmatched, and discards it.
-
- The SPD MUST permit a user or administrator to specify policy
- entries as follows:
-
- - SPD-I: For inbound traffic that is to be bypassed or discarded,
- the entry consists of the values of the selectors that apply to
- the traffic to be bypassed or discarded.
-
- - SPD-O: For outbound traffic that is to be bypassed or
- discarded, the entry consists of the values of the selectors
- that apply to the traffic to be bypassed or discarded.
-
- - SPD-S: For traffic that is to be protected using IPsec, the
- entry consists of the values of the selectors that apply to the
- traffic to be protected via AH or ESP, controls on how to
- create SAs based on these selectors, and the parameters needed
- to effect this protection (e.g., algorithms, modes, etc.). Note
- that an SPD-S entry also contains information such as "populate
- from packet" (PFP) flag (see paragraphs below on "How To Derive
- the Values for an SAD entry") and bits indicating whether the
-
-
-
-
-
-Kent & Seo Standards Track [Page 21]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- SA lookup makes use of the local and remote IP addresses in
- addition to the SPI (see AH [Ken05b] or ESP [Ken05a]
- specifications).
-
- Representing Directionality in an SPD Entry
-
- For traffic protected by IPsec, the Local and Remote address and
- ports in an SPD entry are swapped to represent directionality,
- consistent with IKE conventions. In general, the protocols that
- IPsec deals with have the property of requiring symmetric SAs with
- flipped Local/Remote IP addresses. However, for ICMP, there is
- often no such bi-directional authorization requirement.
- Nonetheless, for the sake of uniformity and simplicity, SPD
- entries for ICMP are specified in the same way as for other
- protocols. Note also that for ICMP, Mobility Header, and
- non-initial fragments, there are no port fields in these packets.
- ICMP has message type and code and Mobility Header has mobility
- header type. Thus, SPD entries have provisions for expressing
- access controls appropriate for these protocols, in lieu of the
- normal port field controls. For bypassed or discarded traffic,
- separate inbound and outbound entries are supported, e.g., to
- permit unidirectional flows if required.
-
- OPAQUE and ANY
-
- For each selector in an SPD entry, in addition to the literal
- values that define a match, there are two special values: ANY and
- OPAQUE. ANY is a wildcard that matches any value in the
- corresponding field of the packet, or that matches packets where
- that field is not present or is obscured. OPAQUE indicates that
- the corresponding selector field is not available for examination
- because it may not be present in a fragment, it does not exist for
- the given Next Layer Protocol, or prior application of IPsec may
- have encrypted the value. The ANY value encompasses the OPAQUE
- value. Thus, OPAQUE need be used only when it is necessary to
- distinguish between the case of any allowed value for a field, vs.
- the absence or unavailability (e.g., due to encryption) of the
- field.
-
- How to Derive the Values for an SAD Entry
-
- For each selector in an SPD entry, the entry specifies how to
- derive the corresponding values for a new SA Database (SAD, see
- Section 4.4.2) entry from those in the SPD and the packet. The
- goal is to allow an SAD entry and an SPD cache entry to be created
- based on specific selector values from the packet, or from the
- matching SPD entry. For outbound traffic, there are SPD-S cache
- entries and SPD-O cache entries. For inbound traffic not
-
-
-
-Kent & Seo Standards Track [Page 22]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- protected by IPsec, there are SPD-I cache entries and there is the
- SAD, which represents the cache for inbound IPsec-protected
- traffic (see Section 4.4.2). If IPsec processing is specified for
- an entry, a "populate from packet" (PFP) flag may be asserted for
- one or more of the selectors in the SPD entry (Local IP address;
- Remote IP address; Next Layer Protocol; and, depending on Next
- Layer Protocol, Local port and Remote port, or ICMP type/code, or
- Mobility Header type). If asserted for a given selector X, the
- flag indicates that the SA to be created should take its value for
- X from the value in the packet. Otherwise, the SA should take its
- value(s) for X from the value(s) in the SPD entry. Note: In the
- non-PFP case, the selector values negotiated by the SA management
- protocol (e.g., IKEv2) may be a subset of those in the SPD entry,
- depending on the SPD policy of the peer. Also, whether a single
- flag is used for, e.g., source port, ICMP type/code, and Mobility
- Header (MH) type, or a separate flag is used for each, is a local
- matter.
-
- The following example illustrates the use of the PFP flag in the
- context of a security gateway or a BITS/BITW implementation.
- Consider an SPD entry where the allowed value for Remote address
- is a range of IPv4 addresses: 192.0.2.1 to 192.0.2.10. Suppose an
- outbound packet arrives with a destination address of 192.0.2.3,
- and there is no extant SA to carry this packet. The value used
- for the SA created to transmit this packet could be either of the
- two values shown below, depending on what the SPD entry for this
- selector says is the source of the selector value:
-
- PFP flag value example of new
- for the Remote SAD dest. address
- addr. selector selector value
- --------------- ------------
- a. PFP TRUE 192.0.2.3 (one host)
- b. PFP FALSE 192.0.2.1 to 192.0.2.10 (range of hosts)
-
- Note that if the SPD entry above had a value of ANY for the Remote
- address, then the SAD selector value would have to be ANY for case
- (b), but would still be as illustrated for case (a). Thus, the
- PFP flag can be used to prohibit sharing of an SA, even among
- packets that match the same SPD entry.
-
- Management Interface
-
- For every IPsec implementation, there MUST be a management
- interface that allows a user or system administrator to manage the
- SPD. The interface must allow the user (or administrator) to
- specify the security processing to be applied to every packet that
- traverses the IPsec boundary. (In a native host IPsec
-
-
-
-Kent & Seo Standards Track [Page 23]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- implementation making use of a socket interface, the SPD may not
- need to be consulted on a per-packet basis, as noted at the end of
- Section 4.4.1.1 and in Section 5.) The management interface for
- the SPD MUST allow creation of entries consistent with the
- selectors defined in Section 4.4.1.1, and MUST support (total)
- ordering of these entries, as seen via this interface. The SPD
- entries' selectors are analogous to the ACL or packet filters
- commonly found in a stateless firewall or packet filtering router
- and which are currently managed this way.
-
- In host systems, applications MAY be allowed to create SPD
- entries. (The means of signaling such requests to the IPsec
- implementation are outside the scope of this standard.) However,
- the system administrator MUST be able to specify whether or not a
- user or application can override (default) system policies. The
- form of the management interface is not specified by this document
- and may differ for hosts vs. security gateways, and within hosts
- the interface may differ for socket-based vs. BITS
- implementations. However, this document does specify a standard
- set of SPD elements that all IPsec implementations MUST support.
-
- Decorrelation
-
- The processing model described in this document assumes the
- ability to decorrelate overlapping SPD entries to permit caching,
- which enables more efficient processing of outbound traffic in
- security gateways and BITS/BITW implementations. Decorrelation
- [CoSa04] is only a means of improving performance and simplifying
- the processing description. This RFC does not require a compliant
- implementation to make use of decorrelation. For example, native
- host implementations typically make use of caching implicitly
- because they bind SAs to socket interfaces, and thus there is no
- requirement to be able to decorrelate SPD entries in these
- implementations.
-
- Note: Unless otherwise qualified, the use of "SPD" refers to the
- body of policy information in both ordered or decorrelated
- (unordered) state. Appendix B provides an algorithm that can be
- used to decorrelate SPD entries, but any algorithm that produces
- equivalent output may be used. Note that when an SPD entry is
- decorrelated all the resulting entries MUST be linked together, so
- that all members of the group derived from an individual, SPD
- entry (prior to decorrelation) can all be placed into caches and
- into the SAD at the same time. For example, suppose one starts
- with an entry A (from an ordered SPD) that when decorrelated,
- yields entries A1, A2, and A3. When a packet comes along that
- matches, say A2, and triggers the creation of an SA, the SA
- management protocol (e.g., IKEv2) negotiates A. And all 3
-
-
-
-Kent & Seo Standards Track [Page 24]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- decorrelated entries, A1, A2, and A3, are placed in the
- appropriate SPD-S cache and linked to the SA. The intent is that
- use of a decorrelated SPD ought not to create more SAs than would
- have resulted from use of a not-decorrelated SPD.
-
- If a decorrelated SPD is employed, there are three options for
- what an initiator sends to a peer via an SA management protocol
- (e.g., IKE). By sending the complete set of linked, decorrelated
- entries that were selected from the SPD, a peer is given the best
- possible information to enable selection of the appropriate SPD
- entry at its end, especially if the peer has also decorrelated its
- SPD. However, if a large number of decorrelated entries are
- linked, this may create large packets for SA negotiation, and
- hence fragmentation problems for the SA management protocol.
-
- Alternatively, the original entry from the (correlated) SPD may be
- retained and passed to the SA management protocol. Passing the
- correlated SPD entry keeps the use of a decorrelated SPD a local
- matter, not visible to peers, and avoids possible fragmentation
- concerns, although it provides less precise information to a
- responder for matching against the responder's SPD.
-
- An intermediate approach is to send a subset of the complete set
- of linked, decorrelated SPD entries. This approach can avoid the
- fragmentation problems cited above yet provide better information
- than the original, correlated entry. The major shortcoming of
- this approach is that it may cause additional SAs to be created
- later, since only a subset of the linked, decorrelated entries are
- sent to a peer. Implementers are free to employ any of the
- approaches cited above.
-
- A responder uses the traffic selector proposals it receives via an
- SA management protocol to select an appropriate entry in its SPD.
- The intent of the matching is to select an SPD entry and create an
- SA that most closely matches the intent of the initiator, so that
- traffic traversing the resulting SA will be accepted at both ends.
- If the responder employs a decorrelated SPD, it SHOULD use the
- decorrelated SPD entries for matching, as this will generally
- result in creation of SAs that are more likely to match the intent
- of both peers. If the responder has a correlated SPD, then it
- SHOULD match the proposals against the correlated entries. For
- IKEv2, use of a decorrelated SPD offers the best opportunity for a
- responder to generate a "narrowed" response.
-
- In all cases, when a decorrelated SPD is available, the
- decorrelated entries are used to populate the SPD-S cache. If the
- SPD is not decorrelated, caching is not allowed and an ordered
-
-
-
-
-Kent & Seo Standards Track [Page 25]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- search of SPD MUST be performed to verify that inbound traffic
- arriving on an SA is consistent with the access control policy
- expressed in the SPD.
-
- Handling Changes to the SPD While the System Is Running
-
- If a change is made to the SPD while the system is running, a
- check SHOULD be made of the effect of this change on extant SAs.
- An implementation SHOULD check the impact of an SPD change on
- extant SAs and SHOULD provide a user/administrator with a
- mechanism for configuring what actions to take, e.g., delete an
- affected SA, allow an affected SA to continue unchanged, etc.
-
-4.4.1.1. Selectors
-
- An SA may be fine-grained or coarse-grained, depending on the
- selectors used to define the set of traffic for the SA. For example,
- all traffic between two hosts may be carried via a single SA, and
- afforded a uniform set of security services. Alternatively, traffic
- between a pair of hosts might be spread over multiple SAs, depending
- on the applications being used (as defined by the Next Layer Protocol
- and related fields, e.g., ports), with different security services
- offered by different SAs. Similarly, all traffic between a pair of
- security gateways could be carried on a single SA, or one SA could be
- assigned for each communicating host pair. The following selector
- parameters MUST be supported by all IPsec implementations to
- facilitate control of SA granularity. Note that both Local and
- Remote addresses should either be IPv4 or IPv6, but not a mix of
- address types. Also, note that the Local/Remote port selectors (and
- ICMP message type and code, and Mobility Header type) may be labeled
- as OPAQUE to accommodate situations where these fields are
- inaccessible due to packet fragmentation.
-
- - Remote IP Address(es) (IPv4 or IPv6): This is a list of ranges
- of IP addresses (unicast, broadcast (IPv4 only)). This
- structure allows expression of a single IP address (via a
- trivial range), or a list of addresses (each a trivial range),
- or a range of addresses (low and high values, inclusive), as
- well as the most generic form of a list of ranges. Address
- ranges are used to support more than one remote system sharing
- the same SA, e.g., behind a security gateway.
-
- - Local IP Address(es) (IPv4 or IPv6): This is a list of ranges of
- IP addresses (unicast, broadcast (IPv4 only)). This structure
- allows expression of a single IP address (via a trivial range),
- or a list of addresses (each a trivial range), or a range of
- addresses (low and high values, inclusive), as well as the most
- generic form of a list of ranges. Address ranges are used to
-
-
-
-Kent & Seo Standards Track [Page 26]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- support more than one source system sharing the same SA, e.g.,
- behind a security gateway. Local refers to the address(es)
- being protected by this implementation (or policy entry).
-
- Note: The SPD does not include support for multicast address
- entries. To support multicast SAs, an implementation should
- make use of a Group SPD (GSPD) as defined in [RFC3740]. GSPD
- entries require a different structure, i.e., one cannot use the
- symmetric relationship associated with local and remote address
- values for unicast SAs in a multicast context. Specifically,
- outbound traffic directed to a multicast address on an SA would
- not be received on a companion, inbound SA with the multicast
- address as the source.
-
- - Next Layer Protocol: Obtained from the IPv4 "Protocol" or the
- IPv6 "Next Header" fields. This is an individual protocol
- number, ANY, or for IPv6 only, OPAQUE. The Next Layer Protocol
- is whatever comes after any IP extension headers that are
- present. To simplify locating the Next Layer Protocol, there
- SHOULD be a mechanism for configuring which IPv6 extension
- headers to skip. The default configuration for which protocols
- to skip SHOULD include the following protocols: 0 (Hop-by-hop
- options), 43 (Routing Header), 44 (Fragmentation Header), and 60
- (Destination Options). Note: The default list does NOT include
- 51 (AH) or 50 (ESP). From a selector lookup point of view,
- IPsec treats AH and ESP as Next Layer Protocols.
-
- Several additional selectors depend on the Next Layer Protocol
- value:
-
- * If the Next Layer Protocol uses two ports (as do TCP, UDP,
- SCTP, and others), then there are selectors for Local and
- Remote Ports. Each of these selectors has a list of ranges
- of values. Note that the Local and Remote ports may not be
- available in the case of receipt of a fragmented packet or if
- the port fields have been protected by IPsec (encrypted);
- thus, a value of OPAQUE also MUST be supported. Note: In a
- non-initial fragment, port values will not be available. If
- a port selector specifies a value other than ANY or OPAQUE,
- it cannot match packets that are non-initial fragments. If
- the SA requires a port value other than ANY or OPAQUE, an
- arriving fragment without ports MUST be discarded. (See
- Section 7, "Handling Fragments".)
-
- * If the Next Layer Protocol is a Mobility Header, then there
- is a selector for IPv6 Mobility Header message type (MH type)
- [Mobip]. This is an 8-bit value that identifies a particular
- mobility message. Note that the MH type may not be available
-
-
-
-Kent & Seo Standards Track [Page 27]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- in the case of receipt of a fragmented packet. (See Section
- 7, "Handling Fragments".) For IKE, the IPv6 Mobility Header
- message type (MH type) is placed in the most significant
- eight bits of the 16-bit local "port" selector.
-
- * If the Next Layer Protocol value is ICMP, then there is a
- 16-bit selector for the ICMP message type and code. The
- message type is a single 8-bit value, which defines the type
- of an ICMP message, or ANY. The ICMP code is a single 8-bit
- value that defines a specific subtype for an ICMP message.
- For IKE, the message type is placed in the most significant 8
- bits of the 16-bit selector and the code is placed in the
- least significant 8 bits. This 16-bit selector can contain a
- single type and a range of codes, a single type and ANY code,
- and ANY type and ANY code. Given a policy entry with a range
- of Types (T-start to T-end) and a range of Codes (C-start to
- C-end), and an ICMP packet with Type t and Code c, an
- implementation MUST test for a match using
-
- (T-start*256) + C-start <= (t*256) + c <= (T-end*256) +
- C-end
-
- Note that the ICMP message type and code may not be available
- in the case of receipt of a fragmented packet. (See Section
- 7, "Handling Fragments".)
-
- - Name: This is not a selector like the others above. It is not
- acquired from a packet. A name may be used as a symbolic
- identifier for an IPsec Local or Remote address. Named SPD
- entries are used in two ways:
-
- 1. A named SPD entry is used by a responder (not an initiator)
- in support of access control when an IP address would not be
- appropriate for the Remote IP address selector, e.g., for
- "road warriors". The name used to match this field is
- communicated during the IKE negotiation in the ID payload.
- In this context, the initiator's Source IP address (inner IP
- header in tunnel mode) is bound to the Remote IP address in
- the SAD entry created by the IKE negotiation. This address
- overrides the Remote IP address value in the SPD, when the
- SPD entry is selected in this fashion. All IPsec
- implementations MUST support this use of names.
-
- 2. A named SPD entry may be used by an initiator to identify a
- user for whom an IPsec SA will be created (or for whom
- traffic may be bypassed). The initiator's IP source address
- (from inner IP header in tunnel mode) is used to replace the
- following if and when they are created:
-
-
-
-Kent & Seo Standards Track [Page 28]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- - local address in the SPD cache entry
- - local address in the outbound SAD entry
- - remote address in the inbound SAD entry
-
- Support for this use is optional for multi-user, native host
- implementations and not applicable to other implementations.
- Note that this name is used only locally; it is not
- communicated by the key management protocol. Also, name
- forms other than those used for case 1 above (responder) are
- applicable in the initiator context (see below).
-
- An SPD entry can contain both a name (or a list of names) and
- also values for the Local or Remote IP address.
-
- For case 1, responder, the identifiers employed in named SPD
- entries are one of the following four types:
-
- a. a fully qualified user name string (email), e.g.,
- mozart@foo.example.com
- (this corresponds to ID_RFC822_ADDR in IKEv2)
-
- b. a fully qualified DNS name, e.g.,
- foo.example.com
- (this corresponds to ID_FQDN in IKEv2)
-
- c. X.500 distinguished name, e.g., [WaKiHo97],
- CN = Stephen T. Kent, O = BBN Technologies,
- SP = MA, C = US
- (this corresponds to ID_DER_ASN1_DN in IKEv2, after
- decoding)
-
- d. a byte string
- (this corresponds to Key_ID in IKEv2)
-
- For case 2, initiator, the identifiers employed in named SPD
- entries are of type byte string. They are likely to be Unix
- UIDs, Windows security IDs, or something similar, but could
- also be a user name or account name. In all cases, this
- identifier is only of local concern and is not transmitted.
-
- The IPsec implementation context determines how selectors are used.
- For example, a native host implementation typically makes use of a
- socket interface. When a new connection is established, the SPD can
- be consulted and an SA bound to the socket. Thus, traffic sent via
- that socket need not result in additional lookups to the SPD (SPD-O
- and SPD-S) cache. In contrast, a BITS, BITW, or security gateway
- implementation needs to look at each packet and perform an
- SPD-O/SPD-S cache lookup based on the selectors.
-
-
-
-Kent & Seo Standards Track [Page 29]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
-4.4.1.2. Structure of an SPD Entry
-
- This section contains a prose description of an SPD entry. Also,
- Appendix C provides an example of an ASN.1 definition of an SPD
- entry.
-
- This text describes the SPD in a fashion that is intended to map
- directly into IKE payloads to ensure that the policy required by SPD
- entries can be negotiated through IKE. Unfortunately, the semantics
- of the version of IKEv2 published concurrently with this document
- [Kau05] do not align precisely with those defined for the SPD.
- Specifically, IKEv2 does not enable negotiation of a single SA that
- binds multiple pairs of local and remote addresses and ports to a
- single SA. Instead, when multiple local and remote addresses and
- ports are negotiated for an SA, IKEv2 treats these not as pairs, but
- as (unordered) sets of local and remote values that can be
- arbitrarily paired. Until IKE provides a facility that conveys the
- semantics that are expressed in the SPD via selector sets (as
- described below), users MUST NOT include multiple selector sets in a
- single SPD entry unless the access control intent aligns with the IKE
- "mix and match" semantics. An implementation MAY warn users, to
- alert them to this problem if users create SPD entries with multiple
- selector sets, the syntax of which indicates possible conflicts with
- current IKE semantics.
-
- The management GUI can offer the user other forms of data entry and
- display, e.g., the option of using address prefixes as well as
- ranges, and symbolic names for protocols, ports, etc. (Do not confuse
- the use of symbolic names in a management interface with the SPD
- selector "Name".) Note that Remote/Local apply only to IP addresses
- and ports, not to ICMP message type/code or Mobility Header type.
- Also, if the reserved, symbolic selector value OPAQUE or ANY is
- employed for a given selector type, only that value may appear in the
- list for that selector, and it must appear only once in the list for
- that selector. Note that ANY and OPAQUE are local syntax conventions
- -- IKEv2 negotiates these values via the ranges indicated below:
-
- ANY: start = 0 end = <max>
- OPAQUE: start = <max> end = 0
-
- An SPD is an ordered list of entries each of which contains the
- following fields.
-
- o Name -- a list of IDs. This quasi-selector is optional.
- The forms that MUST be supported are described above in
- Section 4.4.1.1 under "Name".
-
-
-
-
-
-Kent & Seo Standards Track [Page 30]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- o PFP flags -- one per traffic selector. A given flag, e.g.,
- for Next Layer Protocol, applies to the relevant selector
- across all "selector sets" (see below) contained in an SPD
- entry. When creating an SA, each flag specifies for the
- corresponding traffic selector whether to instantiate the
- selector from the corresponding field in the packet that
- triggered the creation of the SA or from the value(s) in
- the corresponding SPD entry (see Section 4.4.1, "How to
- Derive the Values for an SAD Entry"). Whether a single
- flag is used for, e.g., source port, ICMP type/code, and
- MH type, or a separate flag is used for each, is a local
- matter. There are PFP flags for:
- - Local Address
- - Remote Address
- - Next Layer Protocol
- - Local Port, or ICMP message type/code or Mobility
- Header type (depending on the next layer protocol)
- - Remote Port, or ICMP message type/code or Mobility
- Header type (depending on the next layer protocol)
-
- o One to N selector sets that correspond to the "condition"
- for applying a particular IPsec action. Each selector set
- contains:
- - Local Address
- - Remote Address
- - Next Layer Protocol
- - Local Port, or ICMP message type/code or Mobility
- Header type (depending on the next layer protocol)
- - Remote Port, or ICMP message type/code or Mobility
- Header type (depending on the next layer protocol)
-
- Note: The "next protocol" selector is an individual value
- (unlike the local and remote IP addresses) in a selector
- set entry. This is consistent with how IKEv2 negotiates
- the Traffic Selector (TS) values for an SA. It also makes
- sense because one may need to associate different port
- fields with different protocols. It is possible to
- associate multiple protocols (and ports) with a single SA
- by specifying multiple selector sets for that SA.
-
- o Processing info -- which action is required -- PROTECT,
- BYPASS, or DISCARD. There is just one action that goes
- with all the selector sets, not a separate action for each
- set. If the required processing is PROTECT, the entry
- contains the following information.
- - IPsec mode -- tunnel or transport
-
-
-
-
-
-Kent & Seo Standards Track [Page 31]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- - (if tunnel mode) local tunnel address -- For a
- non-mobile host, if there is just one interface, this
- is straightforward; if there are multiple
- interfaces, this must be statically configured. For a
- mobile host, the specification of the local address
- is handled externally to IPsec.
- - (if tunnel mode) remote tunnel address -- There is no
- standard way to determine this. See 4.5.3, "Locating
- a Security Gateway".
- - Extended Sequence Number -- Is this SA using extended
- sequence numbers?
- - stateful fragment checking -- Is this SA using
- stateful fragment checking? (See Section 7 for more
- details.)
- - Bypass DF bit (T/F) -- applicable to tunnel mode SAs
- - Bypass DSCP (T/F) or map to unprotected DSCP values
- (array) if needed to restrict bypass of DSCP values --
- applicable to tunnel mode SAs
- - IPsec protocol -- AH or ESP
- - algorithms -- which ones to use for AH, which ones to
- use for ESP, which ones to use for combined mode,
- ordered by decreasing priority
-
- It is a local matter as to what information is kept with regard to
- handling extant SAs when the SPD is changed.
-
-4.4.1.3. More Regarding Fields Associated with Next Layer Protocols
-
- Additional selectors are often associated with fields in the Next
- Layer Protocol header. A particular Next Layer Protocol can have
- zero, one, or two selectors. There may be situations where there
- aren't both local and remote selectors for the fields that are
- dependent on the Next Layer Protocol. The IPv6 Mobility Header has
- only a Mobility Header message type. AH and ESP have no further
- selector fields. A system may be willing to send an ICMP message
- type and code that it does not want to receive. In the descriptions
- below, "port" is used to mean a field that is dependent on the Next
- Layer Protocol.
-
- A. If a Next Layer Protocol has no "port" selectors, then
- the Local and Remote "port" selectors are set to OPAQUE in
- the relevant SPD entry, e.g.,
-
- Local's
- next layer protocol = AH
- "port" selector = OPAQUE
-
-
-
-
-
-Kent & Seo Standards Track [Page 32]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- Remote's
- next layer protocol = AH
- "port" selector = OPAQUE
-
- B. Even if a Next Layer Protocol has only one selector, e.g.,
- Mobility Header type, then the Local and Remote "port"
- selectors are used to indicate whether a system is
- willing to send and/or receive traffic with the specified
- "port" values. For example, if Mobility Headers of a
- specified type are allowed to be sent and received via an
- SA, then the relevant SPD entry would be set as follows:
-
- Local's
- next layer protocol = Mobility Header
- "port" selector = Mobility Header message type
-
- Remote's
- next layer protocol = Mobility Header
- "port" selector = Mobility Header message type
-
- If Mobility Headers of a specified type are allowed to be
- sent but NOT received via an SA, then the relevant SPD
- entry would be set as follows:
-
- Local's
- next layer protocol = Mobility Header
- "port" selector = Mobility Header message type
-
- Remote's
- next layer protocol = Mobility Header
- "port" selector = OPAQUE
-
- If Mobility Headers of a specified type are allowed to be
- received but NOT sent via an SA, then the relevant SPD
- entry would be set as follows:
-
- Local's
- next layer protocol = Mobility Header
- "port" selector = OPAQUE
-
- Remote's
- next layer protocol = Mobility Header
- "port" selector = Mobility Header message type
-
- C. If a system is willing to send traffic with a particular
- "port" value but NOT receive traffic with that kind of
- port value, the system's traffic selectors are set as
- follows in the relevant SPD entry:
-
-
-
-Kent & Seo Standards Track [Page 33]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- Local's
- next layer protocol = ICMP
- "port" selector = <specific ICMP type & code>
-
- Remote's
- next layer protocol = ICMP
- "port" selector = OPAQUE
-
- D. To indicate that a system is willing to receive traffic
- with a particular "port" value but NOT send that kind of
- traffic, the system's traffic selectors are set as follows
- in the relevant SPD entry:
-
- Local's
- next layer protocol = ICMP
- "port" selector = OPAQUE
-
- Remote's
- next layer protocol = ICMP
- "port" selector = <specific ICMP type & code>
-
- For example, if a security gateway is willing to allow
- systems behind it to send ICMP traceroutes, but is not
- willing to let outside systems run ICMP traceroutes to
- systems behind it, then the security gateway's traffic
- selectors are set as follows in the relevant SPD entry:
-
- Local's
- next layer protocol = 1 (ICMPv4)
- "port" selector = 30 (traceroute)
-
- Remote's
- next layer protocol = 1 (ICMPv4)
- "port" selector = OPAQUE
-
-4.4.2. Security Association Database (SAD)
-
- In each IPsec implementation, there is a nominal Security Association
- Database (SAD), in which each entry defines the parameters associated
- with one SA. Each SA has an entry in the SAD. For outbound
- processing, each SAD entry is pointed to by entries in the SPD-S part
- of the SPD cache. For inbound processing, for unicast SAs, the SPI
- is used either alone to look up an SA or in conjunction with the
- IPsec protocol type. If an IPsec implementation supports multicast,
- the SPI plus destination address, or SPI plus destination and source
- addresses are used to look up the SA. (See Section 4.1 for details on
- the algorithm that MUST be used for mapping inbound IPsec datagrams
- to SAs.) The following parameters are associated with each entry in
-
-
-
-Kent & Seo Standards Track [Page 34]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- the SAD. They should all be present except where otherwise noted,
- e.g., AH Authentication algorithm. This description does not purport
- to be a MIB, only a specification of the minimal data items required
- to support an SA in an IPsec implementation.
-
- For each of the selectors defined in Section 4.4.1.1, the entry for
- an inbound SA in the SAD MUST be initially populated with the value
- or values negotiated at the time the SA was created. (See the
- paragraph in Section 4.4.1 under "Handling Changes to the SPD while
- the System is Running" for guidance on the effect of SPD changes on
- extant SAs.) For a receiver, these values are used to check that the
- header fields of an inbound packet (after IPsec processing) match the
- selector values negotiated for the SA. Thus, the SAD acts as a cache
- for checking the selectors of inbound traffic arriving on SAs. For
- the receiver, this is part of verifying that a packet arriving on an
- SA is consistent with the policy for the SA. (See Section 6 for rules
- for ICMP messages.) These fields can have the form of specific
- values, ranges, ANY, or OPAQUE, as described in Section 4.4.1.1,
- "Selectors". Note also that there are a couple of situations in
- which the SAD can have entries for SAs that do not have corresponding
- entries in the SPD. Since this document does not mandate that the
- SAD be selectively cleared when the SPD is changed, SAD entries can
- remain when the SPD entries that created them are changed or deleted.
- Also, if a manually keyed SA is created, there could be an SAD entry
- for this SA that does not correspond to any SPD entry.
-
- Note: The SAD can support multicast SAs, if manually configured. An
- outbound multicast SA has the same structure as a unicast SA. The
- source address is that of the sender, and the destination address is
- the multicast group address. An inbound, multicast SA must be
- configured with the source addresses of each peer authorized to
- transmit to the multicast SA in question. The SPI value for a
- multicast SA is provided by a multicast group controller, not by the
- receiver, as for a unicast SA. Because an SAD entry may be required
- to accommodate multiple, individual IP source addresses that were
- part of an SPD entry (for unicast SAs), the required facility for
- inbound, multicast SAs is a feature already present in an IPsec
- implementation. However, because the SPD has no provisions for
- accommodating multicast entries, this document does not specify an
- automated way to create an SAD entry for a multicast, inbound SA.
- Only manually configured SAD entries can be created to accommodate
- inbound, multicast traffic.
-
- Implementation Guidance: This document does not specify how an SPD-S
- entry refers to the corresponding SAD entry, as this is an
- implementation-specific detail. However, some implementations (based
- on experience from RFC 2401) are known to have problems in this
- regard. In particular, simply storing the (remote tunnel header IP
-
-
-
-Kent & Seo Standards Track [Page 35]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- address, remote SPI) pair in the SPD cache is not sufficient, since
- the pair does not always uniquely identify a single SAD entry. For
- instance, two hosts behind the same NAT could choose the same SPI
- value. The situation also may arise if a host is assigned an IP
- address (e.g., via DHCP) previously used by some other host, and the
- SAs associated with the old host have not yet been deleted via dead
- peer detection mechanisms. This may lead to packets being sent over
- the wrong SA or, if key management ensures the pair is unique,
- denying the creation of otherwise valid SAs. Thus, implementors
- should implement links between the SPD cache and the SAD in a way
- that does not engender such problems.
-
-4.4.2.1. Data Items in the SAD
-
- The following data items MUST be in the SAD:
-
- o Security Parameter Index (SPI): a 32-bit value selected by the
- receiving end of an SA to uniquely identify the SA. In an SAD
- entry for an outbound SA, the SPI is used to construct the
- packet's AH or ESP header. In an SAD entry for an inbound SA, the
- SPI is used to map traffic to the appropriate SA (see text on
- unicast/multicast in Section 4.1).
-
- o Sequence Number Counter: a 64-bit counter used to generate the
- Sequence Number field in AH or ESP headers. 64-bit sequence
- numbers are the default, but 32-bit sequence numbers are also
- supported if negotiated.
-
- o Sequence Counter Overflow: a flag indicating whether overflow of
- the sequence number counter should generate an auditable event and
- prevent transmission of additional packets on the SA, or whether
- rollover is permitted. The audit log entry for this event SHOULD
- include the SPI value, current date/time, Local Address, Remote
- Address, and the selectors from the relevant SAD entry.
-
- o Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent)
- used to determine whether an inbound AH or ESP packet is a replay.
-
- Note: If anti-replay has been disabled by the receiver for an SA,
- e.g., in the case of a manually keyed SA, then the Anti-Replay
- Window is ignored for the SA in question. 64-bit sequence numbers
- are the default, but this counter size accommodates 32-bit
- sequence numbers as well.
-
- o AH Authentication algorithm, key, etc. This is required only if
- AH is supported.
-
-
-
-
-
-Kent & Seo Standards Track [Page 36]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- o ESP Encryption algorithm, key, mode, IV, etc. If a combined mode
- algorithm is used, these fields will not be applicable.
-
- o ESP integrity algorithm, keys, etc. If the integrity service is
- not selected, these fields will not be applicable. If a combined
- mode algorithm is used, these fields will not be applicable.
-
- o ESP combined mode algorithms, key(s), etc. This data is used when
- a combined mode (encryption and integrity) algorithm is used with
- ESP. If a combined mode algorithm is not used, these fields are
- not applicable.
-
- o Lifetime of this SA: a time interval after which an SA must be
- replaced with a new SA (and new SPI) or terminated, plus an
- indication of which of these actions should occur. This may be
- expressed as a time or byte count, or a simultaneous use of both
- with the first lifetime to expire taking precedence. A compliant
- implementation MUST support both types of lifetimes, and MUST
- support a simultaneous use of both. If time is employed, and if
- IKE employs X.509 certificates for SA establishment, the SA
- lifetime must be constrained by the validity intervals of the
- certificates, and the NextIssueDate of the Certificate Revocation
- Lists (CRLs) used in the IKE exchange for the SA. Both initiator
- and responder are responsible for constraining the SA lifetime in
- this fashion. Note: The details of how to handle the refreshing
- of keys when SAs expire is a local matter. However, one
- reasonable approach is:
-
- (a) If byte count is used, then the implementation SHOULD count the
- number of bytes to which the IPsec cryptographic algorithm is
- applied. For ESP, this is the encryption algorithm (including
- Null encryption) and for AH, this is the authentication
- algorithm. This includes pad bytes, etc. Note that
- implementations MUST be able to handle having the counters at
- the ends of an SA get out of synch, e.g., because of packet
- loss or because the implementations at each end of the SA
- aren't doing things the same way.
-
- (b) There SHOULD be two kinds of lifetime -- a soft lifetime that
- warns the implementation to initiate action such as setting up
- a replacement SA, and a hard lifetime when the current SA ends
- and is destroyed.
-
- (c) If the entire packet does not get delivered during the SA's
- lifetime, the packet SHOULD be discarded.
-
- o IPsec protocol mode: tunnel or transport. Indicates which mode of
- AH or ESP is applied to traffic on this SA.
-
-
-
-Kent & Seo Standards Track [Page 37]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- o Stateful fragment checking flag. Indicates whether or not
- stateful fragment checking applies to this SA.
-
- o Bypass DF bit (T/F) -- applicable to tunnel mode SAs where both
- inner and outer headers are IPv4.
-
- o DSCP values -- the set of DSCP values allowed for packets carried
- over this SA. If no values are specified, no DSCP-specific
- filtering is applied. If one or more values are specified, these
- are used to select one SA among several that match the traffic
- selectors for an outbound packet. Note that these values are NOT
- checked against inbound traffic arriving on the SA.
-
- o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if
- needed to restrict bypass of DSCP values -- applicable to tunnel
- mode SAs. This feature maps DSCP values from an inner header to
- values in an outer header, e.g., to address covert channel
- signaling concerns.
-
- o Path MTU: any observed path MTU and aging variables.
-
- o Tunnel header IP source and destination address -- both addresses
- must be either IPv4 or IPv6 addresses. The version implies the
- type of IP header to be used. Only used when the IPsec protocol
- mode is tunnel.
-
-4.4.2.2. Relationship between SPD, PFP flag, packet, and SAD
-
- For each selector, the following tables show the relationship
- between the value in the SPD, the PFP flag, the value in the
- triggering packet, and the resulting value in the SAD. Note that
- the administrative interface for IPsec can use various syntactic
- options to make it easier for the administrator to enter rules.
- For example, although a list of ranges is what IKEv2 sends, it
- might be clearer and less error prone for the user to enter a
- single IP address or IP address prefix.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 38]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- Value in
- Triggering Resulting SAD
- Selector SPD Entry PFP Packet Entry
- -------- ---------------- --- ------------ --------------
- loc addr list of ranges 0 IP addr "S" list of ranges
- ANY 0 IP addr "S" ANY
- list of ranges 1 IP addr "S" "S"
- ANY 1 IP addr "S" "S"
-
- rem addr list of ranges 0 IP addr "D" list of ranges
- ANY 0 IP addr "D" ANY
- list of ranges 1 IP addr "D" "D"
- ANY 1 IP addr "D" "D"
-
- protocol list of prot's* 0 prot. "P" list of prot's*
- ANY** 0 prot. "P" ANY
- OPAQUE**** 0 prot. "P" OPAQUE
-
- list of prot's* 0 not avail. discard packet
- ANY** 0 not avail. ANY
- OPAQUE**** 0 not avail. OPAQUE
-
- list of prot's* 1 prot. "P" "P"
- ANY** 1 prot. "P" "P"
- OPAQUE**** 1 prot. "P" ***
-
- list of prot's* 1 not avail. discard packet
- ANY** 1 not avail. discard packet
- OPAQUE**** 1 not avail. ***
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 39]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- If the protocol is one that has two ports, then there will be
- selectors for both Local and Remote ports.
-
- Value in
- Triggering Resulting SAD
- Selector SPD Entry PFP Packet Entry
- -------- ---------------- --- ------------ --------------
- loc port list of ranges 0 src port "s" list of ranges
- ANY 0 src port "s" ANY
- OPAQUE 0 src port "s" OPAQUE
-
- list of ranges 0 not avail. discard packet
- ANY 0 not avail. ANY
- OPAQUE 0 not avail. OPAQUE
-
- list of ranges 1 src port "s" "s"
- ANY 1 src port "s" "s"
- OPAQUE 1 src port "s" ***
-
- list of ranges 1 not avail. discard packet
- ANY 1 not avail. discard packet
- OPAQUE 1 not avail. ***
-
-
- rem port list of ranges 0 dst port "d" list of ranges
- ANY 0 dst port "d" ANY
- OPAQUE 0 dst port "d" OPAQUE
-
- list of ranges 0 not avail. discard packet
- ANY 0 not avail. ANY
- OPAQUE 0 not avail. OPAQUE
-
- list of ranges 1 dst port "d" "d"
- ANY 1 dst port "d" "d"
- OPAQUE 1 dst port "d" ***
-
- list of ranges 1 not avail. discard packet
- ANY 1 not avail. discard packet
- OPAQUE 1 not avail. ***
-
-
-
-
-
-
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 40]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- If the protocol is mobility header, then there will be a selector
- for mh type.
-
- Value in
- Triggering Resulting SAD
- Selector SPD Entry PFP Packet Entry
- -------- ---------------- --- ------------ --------------
- mh type list of ranges 0 mh type "T" list of ranges
- ANY 0 mh type "T" ANY
- OPAQUE 0 mh type "T" OPAQUE
-
- list of ranges 0 not avail. discard packet
- ANY 0 not avail. ANY
- OPAQUE 0 not avail. OPAQUE
-
- list of ranges 1 mh type "T" "T"
- ANY 1 mh type "T" "T"
- OPAQUE 1 mh type "T" ***
-
- list of ranges 1 not avail. discard packet
- ANY 1 not avail. discard packet
- OPAQUE 1 not avail. ***
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 41]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- If the protocol is ICMP, then there will be a 16-bit selector for
- ICMP type and ICMP code. Note that the type and code are bound to
- each other, i.e., the codes apply to the particular type. This
- 16-bit selector can contain a single type and a range of codes, a
- single type and ANY code, and ANY type and ANY code.
-
- Value in
- Triggering Resulting SAD
- Selector SPD Entry PFP Packet Entry
- --------- ---------------- --- ------------ --------------
- ICMP type a single type & 0 type "t" & single type &
- and code range of codes code "c" range of codes
- a single type & 0 type "t" & single type &
- ANY code code "c" ANY code
- ANY type & ANY 0 type "t" & ANY type &
- code code "c" ANY code
- OPAQUE 0 type "t" & OPAQUE
- code "c"
-
- a single type & 0 not avail. discard packet
- range of codes
- a single type & 0 not avail. discard packet
- ANY code
- ANY type & 0 not avail. ANY type &
- ANY code ANY code
- OPAQUE 0 not avail. OPAQUE
-
- a single type & 1 type "t" & "t" and "c"
- range of codes code "c"
- a single type & 1 type "t" & "t" and "c"
- ANY code code "c"
- ANY type & 1 type "t" & "t" and "c"
- ANY code code "c"
- OPAQUE 1 type "t" & ***
- code "c"
-
- a single type & 1 not avail. discard packet
- range of codes
- a single type & 1 not avail. discard packet
- ANY code
- ANY type & 1 not avail. discard packet
- ANY code
- OPAQUE 1 not avail. ***
-
-
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 42]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- If the name selector is used:
-
- Value in
- Triggering Resulting SAD
- Selector SPD Entry PFP Packet Entry
- --------- ---------------- --- ------------ --------------
- name list of user or N/A N/A N/A
- system names
-
- * "List of protocols" is the information, not the way
- that the SPD or SAD or IKEv2 have to represent this
- information.
- ** 0 (zero) is used by IKE to indicate ANY for
- protocol.
- *** Use of PFP=1 with an OPAQUE value is an error and
- SHOULD be prohibited by an IPsec implementation.
- **** The protocol field cannot be OPAQUE in IPv4. This
- table entry applies only to IPv6.
-
-4.4.3. Peer Authorization Database (PAD)
-
- The Peer Authorization Database (PAD) provides the link between the
- SPD and a security association management protocol such as IKE. It
- embodies several critical functions:
-
- o identifies the peers or groups of peers that are authorized
- to communicate with this IPsec entity
- o specifies the protocol and method used to authenticate each
- peer
- o provides the authentication data for each peer
- o constrains the types and values of IDs that can be asserted
- by a peer with regard to child SA creation, to ensure that the
- peer does not assert identities for lookup in the SPD that it
- is not authorized to represent, when child SAs are created
- o peer gateway location info, e.g., IP address(es) or DNS names,
- MAY be included for peers that are known to be "behind" a
- security gateway
-
- The PAD provides these functions for an IKE peer when the peer acts
- as either the initiator or the responder.
-
- To perform these functions, the PAD contains an entry for each peer
- or group of peers with which the IPsec entity will communicate. An
- entry names an individual peer (a user, end system or security
- gateway) or specifies a group of peers (using ID matching rules
- defined below). The entry specifies the authentication protocol
- (e.g., IKEv1, IKEv2, KINK) method used (e.g., certificates or pre-
- shared secrets) and the authentication data (e.g., the pre-shared
-
-
-
-Kent & Seo Standards Track [Page 43]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- secret or the trust anchor relative to which the peer's certificate
- will be validated). For certificate-based authentication, the entry
- also may provide information to assist in verifying the revocation
- status of the peer, e.g., a pointer to a CRL repository or the name
- of an Online Certificate Status Protocol (OCSP) server associated
- with the peer or with the trust anchor associated with the peer.
-
- Each entry also specifies whether the IKE ID payload will be used as
- a symbolic name for SPD lookup, or whether the remote IP address
- provided in traffic selector payloads will be used for SPD lookups
- when child SAs are created.
-
- Note that the PAD information MAY be used to support creation of more
- than one tunnel mode SA at a time between two peers, e.g., two
- tunnels to protect the same addresses/hosts, but with different
- tunnel endpoints.
-
-4.4.3.1. PAD Entry IDs and Matching Rules
-
- The PAD is an ordered database, where the order is defined by an
- administrator (or a user in the case of a single-user end system).
- Usually, the same administrator will be responsible for both the PAD
- and SPD, since the two databases must be coordinated. The ordering
- requirement for the PAD arises for the same reason as for the SPD,
- i.e., because use of "star name" entries allows for overlaps in the
- set of IKE IDs that could match a specific entry.
-
- Six types of IDs are supported for entries in the PAD, consistent
- with the symbolic name types and IP addresses used to identify SPD
- entries. The ID for each entry acts as the index for the PAD, i.e.,
- it is the value used to select an entry. All of these ID types can
- be used to match IKE ID payload types. The six types are:
-
- o DNS name (specific or partial)
- o Distinguished Name (complete or sub-tree constrained)
- o RFC 822 email address (complete or partially qualified)
- o IPv4 address (range)
- o IPv6 address (range)
- o Key ID (exact match only)
-
- The first three name types can accommodate sub-tree matching as well
- as exact matches. A DNS name may be fully qualified and thus match
- exactly one name, e.g., foo.example.com. Alternatively, the name may
- encompass a group of peers by being partially specified, e.g., the
- string ".example.com" could be used to match any DNS name ending in
- these two domain name components.
-
-
-
-
-
-Kent & Seo Standards Track [Page 44]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- Similarly, a Distinguished Name may specify a complete Distinguished
- Name to match exactly one entry, e.g., CN = Stephen, O = BBN
- Technologies, SP = MA, C = US. Alternatively, an entry may encompass
- a group of peers by specifying a sub-tree, e.g., an entry of the form
- "C = US, SP = MA" might be used to match all DNs that contain these
- two attributes as the top two Relative Distinguished Names (RDNs).
-
- For an RFC 822 e-mail addresses, the same options exist. A complete
- address such as foo@example.com matches one entity, but a sub-tree
- name such as "@example.com" could be used to match all the entities
- with names ending in those two domain names to the right of the @.
-
- The specific syntax used by an implementation to accommodate sub-tree
- matching for distinguished names, domain names or RFC 822 e-mail
- addresses is a local matter. But, at a minimum, sub-tree matching of
- the sort described above MUST be supported. (Substring matching
- within a DN, DNS name, or RFC 822 address MAY be supported, but is
- not required.)
-
- For IPv4 and IPv6 addresses, the same address range syntax used for
- SPD entries MUST be supported. This allows specification of an
- individual address (via a trivial range), an address prefix (by
- choosing a range that adheres to Classless Inter-Domain Routing
- (CIDR)-style prefixes), or an arbitrary address range.
-
- The Key ID field is defined as an OCTET string in IKE. For this name
- type, only exact-match syntax MUST be supported (since there is no
- explicit structure for this ID type). Additional matching functions
- MAY be supported for this ID type.
-
-4.4.3.2. IKE Peer Authentication Data
-
- Once an entry is located based on an ordered search of the PAD based
- on ID field matching, it is necessary to verify the asserted
- identity, i.e., to authenticate the asserted ID. For each PAD entry,
- there is an indication of the type of authentication to be performed.
- This document requires support for two required authentication data
- types:
-
- - X.509 certificate
- - pre-shared secret
-
- For authentication based on an X.509 certificate, the PAD entry
- contains a trust anchor via which the end entity (EE) certificate for
- the peer must be verifiable, either directly or via a certificate
- path. See RFC 3280 for the definition of a trust anchor. An entry
- used with certificate-based authentication MAY include additional
- data to facilitate certificate revocation status, e.g., a list of
-
-
-
-Kent & Seo Standards Track [Page 45]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- appropriate OCSP responders or CRL repositories, and associated
- authentication data. For authentication based on a pre-shared
- secret, the PAD contains the pre-shared secret to be used by IKE.
-
- This document does not require that the IKE ID asserted by a peer be
- syntactically related to a specific field in an end entity
- certificate that is employed to authenticate the identity of that
- peer. However, it often will be appropriate to impose such a
- requirement, e.g., when a single entry represents a set of peers each
- of whom may have a distinct SPD entry. Thus, implementations MUST
- provide a means for an administrator to require a match between an
- asserted IKE ID and the subject name or subject alt name in a
- certificate. The former is applicable to IKE IDs expressed as
- distinguished names; the latter is appropriate for DNS names, RFC 822
- e-mail addresses, and IP addresses. Since KEY ID is intended for
- identifying a peer authenticated via a pre-shared secret, there is no
- requirement to match this ID type to a certificate field.
-
- See IKEv1 [HarCar98] and IKEv2 [Kau05] for details of how IKE
- performs peer authentication using certificates or pre-shared
- secrets.
-
- This document does not mandate support for any other authentication
- methods, although such methods MAY be employed.
-
-4.4.3.3. Child SA Authorization Data
-
- Once an IKE peer is authenticated, child SAs may be created. Each
- PAD entry contains data to constrain the set of IDs that can be
- asserted by an IKE peer, for matching against the SPD. Each PAD
- entry indicates whether the IKE ID is to be used as a symbolic name
- for SPD matching, or whether an IP address asserted in a traffic
- selector payload is to be used.
-
- If the entry indicates that the IKE ID is to be used, then the PAD
- entry ID field defines the authorized set of IDs. If the entry
- indicates that child SAs traffic selectors are to be used, then an
- additional data element is required, in the form of IPv4 and/or IPv6
- address ranges. (A peer may be authorized for both address types, so
- there MUST be provision for both a v4 and a v6 address range.)
-
-4.4.3.4. How the PAD Is Used
-
- During the initial IKE exchange, the initiator and responder each
- assert their identity via the IKE ID payload and send an AUTH payload
- to verify the asserted identity. One or more CERT payloads may be
- transmitted to facilitate the verification of each asserted identity.
-
-
-
-
-Kent & Seo Standards Track [Page 46]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- When an IKE entity receives an IKE ID payload, it uses the asserted
- ID to locate an entry in the PAD, using the matching rules described
- above. The PAD entry specifies the authentication method to be
- employed for the identified peer. This ensures that the right method
- is used for each peer and that different methods can be used for
- different peers. The entry also specifies the authentication data
- that will be used to verify the asserted identity. This data is
- employed in conjunction with the specified method to authenticate the
- peer, before any CHILD SAs are created.
-
- Child SAs are created based on the exchange of traffic selector
- payloads, either at the end of the initial IKE exchange or in
- subsequent CREATE_CHILD_SA exchanges. The PAD entry for the (now
- authenticated) IKE peer is used to constrain creation of child SAs;
- specifically, the PAD entry specifies how the SPD is searched using a
- traffic selector proposal from a peer. There are two choices: either
- the IKE ID asserted by the peer is used to find an SPD entry via its
- symbolic name, or peer IP addresses asserted in traffic selector
- payloads are used for SPD lookups based on the remote IP address
- field portion of an SPD entry. It is necessary to impose these
- constraints on creation of child SAs to prevent an authenticated peer
- from spoofing IDs associated with other, legitimate peers.
-
- Note that because the PAD is checked before searching for an SPD
- entry, this safeguard protects an initiator against spoofing attacks.
- For example, assume that IKE A receives an outbound packet destined
- for IP address X, a host served by a security gateway. RFC 2401
- [RFC2401] and this document do not specify how A determines the
- address of the IKE peer serving X. However, any peer contacted by A
- as the presumed representative for X must be registered in the PAD in
- order to allow the IKE exchange to be authenticated. Moreover, when
- the authenticated peer asserts that it represents X in its traffic
- selector exchange, the PAD will be consulted to determine if the peer
- in question is authorized to represent X. Thus, the PAD provides a
- binding of address ranges (or name sub-spaces) to peers, to counter
- such attacks.
-
-4.5. SA and Key Management
-
- All IPsec implementations MUST support both manual and automated SA
- and cryptographic key management. The IPsec protocols, AH and ESP,
- are largely independent of the associated SA management techniques,
- although the techniques involved do affect some of the security
- services offered by the protocols. For example, the optional
- anti-replay service available for AH and ESP requires automated SA
- management. Moreover, the granularity of key distribution employed
- with IPsec determines the granularity of authentication provided. In
- general, data origin authentication in AH and ESP is limited by the
-
-
-
-Kent & Seo Standards Track [Page 47]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- extent to which secrets used with the integrity algorithm (or with a
- key management protocol that creates such secrets) are shared among
- multiple possible sources.
-
- The following text describes the minimum requirements for both types
- of SA management.
-
-4.5.1. Manual Techniques
-
- The simplest form of management is manual management, in which a
- person manually configures each system with keying material and SA
- management data relevant to secure communication with other systems.
- Manual techniques are practical in small, static environments but
- they do not scale well. For example, a company could create a
- virtual private network (VPN) using IPsec in security gateways at
- several sites. If the number of sites is small, and since all the
- sites come under the purview of a single administrative domain, this
- might be a feasible context for manual management techniques. In
- this case, the security gateway might selectively protect traffic to
- and from other sites within the organization using a manually
- configured key, while not protecting traffic for other destinations.
- It also might be appropriate when only selected communications need
- to be secured. A similar argument might apply to use of IPsec
- entirely within an organization for a small number of hosts and/or
- gateways. Manual management techniques often employ statically
- configured, symmetric keys, though other options also exist.
-
-4.5.2. Automated SA and Key Management
-
- Widespread deployment and use of IPsec requires an Internet-standard,
- scalable, automated, SA management protocol. Such support is
- required to facilitate use of the anti-replay features of AH and ESP,
- and to accommodate on-demand creation of SAs, e.g., for user- and
- session-oriented keying. (Note that the notion of "rekeying" an SA
- actually implies creation of a new SA with a new SPI, a process that
- generally implies use of an automated SA/key management protocol.)
-
- The default automated key management protocol selected for use with
- IPsec is IKEv2 [Kau05]. This document assumes the availability of
- certain functions from the key management protocol that are not
- supported by IKEv1. Other automated SA management protocols MAY be
- employed.
-
- When an automated SA/key management protocol is employed, the output
- from this protocol is used to generate multiple keys for a single SA.
- This also occurs because distinct keys are used for each of the two
-
-
-
-
-
-Kent & Seo Standards Track [Page 48]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- SAs created by IKE. If both integrity and confidentiality are
- employed, then a minimum of four keys are required. Additionally,
- some cryptographic algorithms may require multiple keys, e.g., 3DES.
-
- The Key Management System may provide a separate string of bits for
- each key or it may generate one string of bits from which all keys
- are extracted. If a single string of bits is provided, care needs to
- be taken to ensure that the parts of the system that map the string
- of bits to the required keys do so in the same fashion at both ends
- of the SA. To ensure that the IPsec implementations at each end of
- the SA use the same bits for the same keys, and irrespective of which
- part of the system divides the string of bits into individual keys,
- the encryption keys MUST be taken from the first (left-most,
- high-order) bits and the integrity keys MUST be taken from the
- remaining bits. The number of bits for each key is defined in the
- relevant cryptographic algorithm specification RFC. In the case of
- multiple encryption keys or multiple integrity keys, the
- specification for the cryptographic algorithm must specify the order
- in which they are to be selected from a single string of bits
- provided to the cryptographic algorithm.
-
-4.5.3. Locating a Security Gateway
-
- This section discusses issues relating to how a host learns about the
- existence of relevant security gateways and, once a host has
- contacted these security gateways, how it knows that these are the
- correct security gateways. The details of where the required
- information is stored is a local matter, but the Peer Authorization
- Database (PAD) described in Section 4.4 is the most likely candidate.
- (Note: S* indicates a system that is running IPsec, e.g., SH1 and SG2
- below.)
-
- Consider a situation in which a remote host (SH1) is using the
- Internet to gain access to a server or other machine (H2) and there
- is a security gateway (SG2), e.g., a firewall, through which H1's
- traffic must pass. An example of this situation would be a mobile
- host crossing the Internet to his home organization's firewall (SG2).
- This situation raises several issues:
-
- 1. How does SH1 know/learn about the existence of the security
- gateway SG2?
-
- 2. How does it authenticate SG2, and once it has authenticated SG2,
- how does it confirm that SG2 has been authorized to represent H2?
-
- 3. How does SG2 authenticate SH1 and verify that SH1 is authorized to
- contact H2?
-
-
-
-
-Kent & Seo Standards Track [Page 49]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- 4. How does SH1 know/learn about any additional gateways that provide
- alternate paths to H2?
-
- To address these problems, an IPsec-supporting host or security
- gateway MUST have an administrative interface that allows the
- user/administrator to configure the address of one or more security
- gateways for ranges of destination addresses that require its use.
- This includes the ability to configure information for locating and
- authenticating one or more security gateways and verifying the
- authorization of these gateways to represent the destination host.
- (The authorization function is implied in the PAD.) This document
- does not address the issue of how to automate the
- discovery/verification of security gateways.
-
-4.6. SAs and Multicast
-
- The receiver-orientation of the SA implies that, in the case of
- unicast traffic, the destination system will select the SPI value.
- By having the destination select the SPI value, there is no potential
- for manually configured SAs to conflict with automatically configured
- (e.g., via a key management protocol) SAs or for SAs from multiple
- sources to conflict with each other. For multicast traffic, there
- are multiple destination systems associated with a single SA. So
- some system or person will need to coordinate among all multicast
- groups to select an SPI or SPIs on behalf of each multicast group and
- then communicate the group's IPsec information to all of the
- legitimate members of that multicast group via mechanisms not defined
- here.
-
- Multiple senders to a multicast group SHOULD use a single Security
- Association (and hence SPI) for all traffic to that group when a
- symmetric key encryption or integrity algorithm is employed. In such
- circumstances, the receiver knows only that the message came from a
- system possessing the key for that multicast group. In such
- circumstances, a receiver generally will not be able to authenticate
- which system sent the multicast traffic. Specifications for other,
- more general multicast approaches are deferred to the IETF Multicast
- Security Working Group.
-
-5. IP Traffic Processing
-
- As mentioned in Section 4.4.1, "The Security Policy Database (SPD)",
- the SPD (or associated caches) MUST be consulted during the
- processing of all traffic that crosses the IPsec protection boundary,
- including IPsec management traffic. If no policy is found in the SPD
- that matches a packet (for either inbound or outbound traffic), the
- packet MUST be discarded. To simplify processing, and to allow for
- very fast SA lookups (for SG/BITS/BITW), this document introduces the
-
-
-
-Kent & Seo Standards Track [Page 50]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- notion of an SPD cache for all outbound traffic (SPD-O plus SPD-S),
- and a cache for inbound, non-IPsec-protected traffic (SPD-I). (As
- mentioned earlier, the SAD acts as a cache for checking the selectors
- of inbound IPsec-protected traffic arriving on SAs.) There is
- nominally one cache per SPD. For the purposes of this specification,
- it is assumed that each cached entry will map to exactly one SA.
- Note, however, exceptions arise when one uses multiple SAs to carry
- traffic of different priorities (e.g., as indicated by distinct DSCP
- values) but the same selectors. Note also, that there are a couple
- of situations in which the SAD can have entries for SAs that do not
- have corresponding entries in the SPD. Since this document does not
- mandate that the SAD be selectively cleared when the SPD is changed,
- SAD entries can remain when the SPD entries that created them are
- changed or deleted. Also, if a manually keyed SA is created, there
- could be an SAD entry for this SA that does not correspond to any SPD
- entry.
-
- Since SPD entries may overlap, one cannot safely cache these entries
- in general. Simple caching might result in a match against a cache
- entry, whereas an ordered search of the SPD would have resulted in a
- match against a different entry. But, if the SPD entries are first
- decorrelated, then the resulting entries can safely be cached. Each
- cached entry will indicate that matching traffic should be bypassed
- or discarded, appropriately. (Note: The original SPD entry might
- result in multiple SAs, e.g., because of PFP.) Unless otherwise
- noted, all references below to the "SPD" or "SPD cache" or "cache"
- are to a decorrelated SPD (SPD-I, SPD-O, SPD-S) or the SPD cache
- containing entries from the decorrelated SPD.
-
- Note: In a host IPsec implementation based on sockets, the SPD will
- be consulted whenever a new socket is created to determine what, if
- any, IPsec processing will be applied to the traffic that will flow
- on that socket. This provides an implicit caching mechanism, and the
- portions of the preceding discussion that address caching can be
- ignored in such implementations.
-
- Note: It is assumed that one starts with a correlated SPD because
- that is how users and administrators are accustomed to managing these
- sorts of access control lists or firewall filter rules. Then the
- decorrelation algorithm is applied to build a list of cache-able SPD
- entries. The decorrelation is invisible at the management interface.
-
- For inbound IPsec traffic, the SAD entry selected by the SPI serves
- as the cache for the selectors to be matched against arriving IPsec
- packets, after AH or ESP processing has been performed.
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 51]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
-5.1. Outbound IP Traffic Processing (protected-to-unprotected)
-
- First consider the path for traffic entering the implementation via a
- protected interface and exiting via an unprotected interface.
-
- Unprotected Interface
- ^
- |
- (nested SAs) +----------+
- -------------------|Forwarding|<-----+
- | +----------+ |
- | ^ |
- | | BYPASS |
- V +-----+ |
- +-------+ | SPD | +--------+
- ...| SPD-I |.................|Cache|.....|PROCESS |...IPsec
- | (*) | | (*) |---->|(AH/ESP)| boundary
- +-------+ +-----+ +--------+
- | +-------+ / ^
- | |DISCARD| <--/ |
- | +-------+ |
- | |
- | +-------------+
- |---------------->|SPD Selection|
- +-------------+
- ^
- | +------+
- | -->| ICMP |
- | / +------+
- |/
- |
- |
- Protected Interface
-
-
- Figure 2. Processing Model for Outbound Traffic
- (*) = The SPD caches are shown here. If there
- is a cache miss, then the SPD is checked.
- There is no requirement that an
- implementation buffer the packet if
- there is a cache miss.
-
-
-
-
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 52]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- IPsec MUST perform the following steps when processing outbound
- packets:
-
- 1. When a packet arrives from the subscriber (protected) interface,
- invoke the SPD selection function to obtain the SPD-ID needed to
- choose the appropriate SPD. (If the implementation uses only one
- SPD, this step is a no-op.)
-
- 2. Match the packet headers against the cache for the SPD specified
- by the SPD-ID from step 1. Note that this cache contains entries
- from SPD-O and SPD-S.
-
- 3a. If there is a match, then process the packet as specified by the
- matching cache entry, i.e., BYPASS, DISCARD, or PROTECT using AH
- or ESP. If IPsec processing is applied, there is a link from the
- SPD cache entry to the relevant SAD entry (specifying the mode,
- cryptographic algorithms, keys, SPI, PMTU, etc.). IPsec
- processing is as previously defined, for tunnel or transport
- modes and for AH or ESP, as specified in their respective RFCs
- [Ken05b, Ken05a]. Note that the SA PMTU value, plus the value of
- the stateful fragment checking flag (and the DF bit in the IP
- header of the outbound packet) determine whether the packet can
- (must) be fragmented prior to or after IPsec processing, or if it
- must be discarded and an ICMP PMTU message is sent.
-
- 3b. If no match is found in the cache, search the SPD (SPD-S and
- SPD-O parts) specified by SPD-ID. If the SPD entry calls for
- BYPASS or DISCARD, create one or more new outbound SPD cache
- entries and if BYPASS, create one or more new inbound SPD cache
- entries. (More than one cache entry may be created since a
- decorrelated SPD entry may be linked to other such entries that
- were created as a side effect of the decorrelation process.) If
- the SPD entry calls for PROTECT, i.e., creation of an SA, the key
- management mechanism (e.g., IKEv2) is invoked to create the SA.
- If SA creation succeeds, a new outbound (SPD-S) cache entry is
- created, along with outbound and inbound SAD entries, otherwise
- the packet is discarded. (A packet that triggers an SPD lookup
- MAY be discarded by the implementation, or it MAY be processed
- against the newly created cache entry, if one is created.) Since
- SAs are created in pairs, an SAD entry for the corresponding
- inbound SA also is created, and it contains the selector values
- derived from the SPD entry (and packet, if any PFP flags were
- "true") used to create the inbound SA, for use in checking
- inbound traffic delivered via the SA.
-
- 4. The packet is passed to the outbound forwarding function
- (operating outside of the IPsec implementation), to select the
- interface to which the packet will be directed. This function
-
-
-
-Kent & Seo Standards Track [Page 53]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- may cause the packet to be passed back across the IPsec boundary,
- for additional IPsec processing, e.g., in support of nested SAs.
- If so, there MUST be an entry in SPD-I database that permits
- inbound bypassing of the packet, otherwise the packet will be
- discarded. If necessary, i.e., if there is more than one SPD-I,
- the traffic being looped back MAY be tagged as coming from this
- internal interface. This would allow the use of a different
- SPD-I for "real" external traffic vs. looped traffic, if needed.
-
- Note: With the exception of IPv4 and IPv6 transport mode, an SG,
- BITS, or BITW implementation MAY fragment packets before applying
- IPsec. (This applies only to IPv4. For IPv6 packets, only the
- originator is allowed to fragment them.) The device SHOULD have a
- configuration setting to disable this. The resulting fragments are
- evaluated against the SPD in the normal manner. Thus, fragments not
- containing port numbers (or ICMP message type and code, or Mobility
- Header type) will only match rules having port (or ICMP message type
- and code, or MH type) selectors of OPAQUE or ANY. (See Section 7 for
- more details.)
-
- Note: With regard to determining and enforcing the PMTU of an SA, the
- IPsec system MUST follow the steps described in Section 8.2.
-
-5.1.1. Handling an Outbound Packet That Must Be Discarded
-
- If an IPsec system receives an outbound packet that it finds it must
- discard, it SHOULD be capable of generating and sending an ICMP
- message to indicate to the sender of the outbound packet that the
- packet was discarded. The type and code of the ICMP message will
- depend on the reason for discarding the packet, as specified below.
- The reason SHOULD be recorded in the audit log. The audit log entry
- for this event SHOULD include the reason, current date/time, and the
- selector values from the packet.
-
- a. The selectors of the packet matched an SPD entry requiring the
- packet to be discarded.
-
- IPv4 Type = 3 (destination unreachable) Code = 13
- (Communication Administratively Prohibited)
-
- IPv6 Type = 1 (destination unreachable) Code = 1
- (Communication with destination administratively
- prohibited)
-
- b1. The IPsec system successfully reached the remote peer but was
- unable to negotiate the SA required by the SPD entry matching the
- packet because, for example, the remote peer is administratively
- prohibited from communicating with the initiator, the initiating
-
-
-
-Kent & Seo Standards Track [Page 54]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- peer was unable to authenticate itself to the remote peer, the
- remote peer was unable to authenticate itself to the initiating
- peer, or the SPD at the remote peer did not have a suitable
- entry.
-
- IPv4 Type = 3 (destination unreachable) Code = 13
- (Communication Administratively Prohibited)
-
- IPv6 Type = 1 (destination unreachable) Code = 1
- (Communication with destination administratively
- prohibited)
-
- b2. The IPsec system was unable to set up the SA required by the SPD
- entry matching the packet because the IPsec peer at the other end
- of the exchange could not be contacted.
-
- IPv4 Type = 3 (destination unreachable) Code = 1 (host
- unreachable)
-
- IPv6 Type = 1 (destination unreachable) Code = 3 (address
- unreachable)
-
- Note that an attacker behind a security gateway could send packets
- with a spoofed source address, W.X.Y.Z, to an IPsec entity causing it
- to send ICMP messages to W.X.Y.Z. This creates an opportunity for a
- denial of service (DoS) attack among hosts behind a security gateway.
- To address this, a security gateway SHOULD include a management
- control to allow an administrator to configure an IPsec
- implementation to send or not send the ICMP messages under these
- circumstances, and if this facility is selected, to rate limit the
- transmission of such ICMP responses.
-
-5.1.2. Header Construction for Tunnel Mode
-
- This section describes the handling of the inner and outer IP
- headers, extension headers, and options for AH and ESP tunnels, with
- regard to outbound traffic processing. This includes how to
- construct the encapsulating (outer) IP header, how to process fields
- in the inner IP header, and what other actions should be taken for
- outbound, tunnel mode traffic. The general processing described here
- is modeled after RFC 2003, "IP Encapsulation within IP" [Per96]:
-
- o The outer IP header Source Address and Destination Address
- identify the "endpoints" of the tunnel (the encapsulator and
- decapsulator). The inner IP header Source Address and Destination
- Addresses identify the original sender and recipient of the
- datagram (from the perspective of this tunnel), respectively.
-
-
-
-
-Kent & Seo Standards Track [Page 55]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- (See footnote 3 after the table in 5.1.2.1 for more details on the
- encapsulating source IP address.)
-
- o The inner IP header is not changed except as noted below for TTL
- (or Hop Limit) and the DS/ECN Fields. The inner IP header
- otherwise remains unchanged during its delivery to the tunnel exit
- point.
-
- o No change to IP options or extension headers in the inner header
- occurs during delivery of the encapsulated datagram through the
- tunnel.
-
- Note: IPsec tunnel mode is different from IP-in-IP tunneling (RFC
- 2003 [Per96]) in several ways:
-
- o IPsec offers certain controls to a security administrator to
- manage covert channels (which would not normally be a concern for
- tunneling) and to ensure that the receiver examines the right
- portions of the received packet with respect to application of
- access controls. An IPsec implementation MAY be configurable with
- regard to how it processes the outer DS field for tunnel mode for
- transmitted packets. For outbound traffic, one configuration
- setting for the outer DS field will operate as described in the
- following sections on IPv4 and IPv6 header processing for IPsec
- tunnels. Another will allow the outer DS field to be mapped to a
- fixed value, which MAY be configured on a per-SA basis. (The value
- might really be fixed for all traffic outbound from a device, but
- per-SA granularity allows that as well.) This configuration option
- allows a local administrator to decide whether the covert channel
- provided by copying these bits outweighs the benefits of copying.
-
- o IPsec describes how to handle ECN or DS and provides the ability
- to control propagation of changes in these fields between
- unprotected and protected domains. In general, propagation from a
- protected to an unprotected domain is a covert channel and thus
- controls are provided to manage the bandwidth of this channel.
- Propagation of ECN values in the other direction are controlled so
- that only legitimate ECN changes (indicating occurrence of
- congestion between the tunnel endpoints) are propagated. By
- default, DS propagation from an unprotected domain to a protected
- domain is not permitted. However, if the sender and receiver do
- not share the same DS code space, and the receiver has no way of
- learning how to map between the two spaces, then it may be
- appropriate to deviate from the default. Specifically, an IPsec
- implementation MAY be configurable in terms of how it processes
- the outer DS field for tunnel mode for received packets. It may
- be configured to either discard the outer DS value (the default)
- OR to overwrite the inner DS field with the outer DS field. If
-
-
-
-Kent & Seo Standards Track [Page 56]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- offered, the discard vs. overwrite behavior MAY be configured on a
- per-SA basis. This configuration option allows a local
- administrator to decide whether the vulnerabilities created by
- copying these bits outweigh the benefits of copying. See
- [RFC2983] for further information on when each of these behaviors
- may be useful, and also for the possible need for diffserv traffic
- conditioning prior or subsequent to IPsec processing (including
- tunnel decapsulation).
-
- o IPsec allows the IP version of the encapsulating header to be
- different from that of the inner header.
-
- The tables in the following sub-sections show the handling for the
- different header/option fields ("constructed" means that the value in
- the outer field is constructed independently of the value in the
- inner).
-
-5.1.2.1. IPv4: Header Construction for Tunnel Mode
-
- <-- How Outer Hdr Relates to Inner Hdr -->
- Outer Hdr at Inner Hdr at
- IPv4 Encapsulator Decapsulator
- Header fields: -------------------- ------------
- version 4 (1) no change
- header length constructed no change
- DS Field copied from inner hdr (5) no change
- ECN Field copied from inner hdr constructed (6)
- total length constructed no change
- ID constructed no change
- flags (DF,MF) constructed, DF (4) no change
- fragment offset constructed no change
- TTL constructed (2) decrement (2)
- protocol AH, ESP no change
- checksum constructed constructed (2)(6)
- src address constructed (3) no change
- dest address constructed (3) no change
- Options never copied no change
-
- Notes:
-
- (1) The IP version in the encapsulating header can be different
- from the value in the inner header.
-
- (2) The TTL in the inner header is decremented by the encapsulator
- prior to forwarding and by the decapsulator if it forwards the
- packet. (The IPv4 checksum changes when the TTL changes.)
-
-
-
-
-
-Kent & Seo Standards Track [Page 57]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- Note: Decrementing the TTL value is a normal part of
- forwarding a packet. Thus, a packet originating from the same
- node as the encapsulator does not have its TTL decremented,
- since the sending node is originating the packet rather than
- forwarding it. This applies to BITS and native IPsec
- implementations in hosts and routers. However, the IPsec
- processing model includes an external forwarding capability.
- TTL processing can be used to prevent looping of packets,
- e.g., due to configuration errors, within the context of this
- processing model.
-
- (3) Local and Remote addresses depend on the SA, which is used to
- determine the Remote address, which in turn determines which
- Local address (net interface) is used to forward the packet.
-
- Note: For multicast traffic, the destination address, or
- source and destination addresses, may be required for
- demuxing. In that case, it is important to ensure consistency
- over the lifetime of the SA by ensuring that the source
- address that appears in the encapsulating tunnel header is the
- same as the one that was negotiated during the SA
- establishment process. There is an exception to this general
- rule, i.e., a mobile IPsec implementation will update its
- source address as it moves.
-
- (4) Configuration determines whether to copy from the inner header
- (IPv4 only), clear, or set the DF.
-
- (5) If the packet will immediately enter a domain for which the
- DSCP value in the outer header is not appropriate, that value
- MUST be mapped to an appropriate value for the domain
- [NiBlBaBL98]. See RFC 2475 [BBCDWW98] for further
- information.
-
- (6) If the ECN field in the inner header is set to ECT(0) or
- ECT(1), where ECT is ECN-Capable Transport (ECT), and if the
- ECN field in the outer header is set to Congestion Experienced
- (CE), then set the ECN field in the inner header to CE;
- otherwise, make no change to the ECN field in the inner
- header. (The IPv4 checksum changes when the ECN changes.)
-
- Note: IPsec does not copy the options from the inner header into the
- outer header, nor does IPsec construct the options in the outer
- header. However, post-IPsec code MAY insert/construct options for
- the outer header.
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 58]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
-5.1.2.2. IPv6: Header Construction for Tunnel Mode
-
- <-- How Outer Hdr Relates Inner Hdr --->
- Outer Hdr at Inner Hdr at
- IPv6 Encapsulator Decapsulator
- Header fields: -------------------- ------------
- version 6 (1) no change
- DS Field copied from inner hdr (5) no change (9)
- ECN Field copied from inner hdr constructed (6)
- flow label copied or configured (8) no change
- payload length constructed no change
- next header AH,ESP,routing hdr no change
- hop limit constructed (2) decrement (2)
- src address constructed (3) no change
- dest address constructed (3) no change
- Extension headers never copied (7) no change
-
- Notes:
-
- (1) - (6) See Section 5.1.2.1.
-
- (7) IPsec does not copy the extension headers from the inner
- packet into outer headers, nor does IPsec construct extension
- headers in the outer header. However, post-IPsec code MAY
- insert/construct extension headers for the outer header.
-
- (8) See [RaCoCaDe04]. Copying is acceptable only for end systems,
- not SGs. If an SG copied flow labels from the inner header to
- the outer header, collisions might result.
-
- (9) An implementation MAY choose to provide a facility to pass the
- DS value from the outer header to the inner header, on a per-
- SA basis, for received tunnel mode packets. The motivation
- for providing this feature is to accommodate situations in
- which the DS code space at the receiver is different from that
- of the sender and the receiver has no way of knowing how to
- translate from the sender's space. There is a danger in
- copying this value from the outer header to the inner header,
- since it enables an attacker to modify the outer DSCP value in
- a fashion that may adversely affect other traffic at the
- receiver. Hence the default behavior for IPsec
- implementations is NOT to permit such copying.
-
-5.2. Processing Inbound IP Traffic (unprotected-to-protected)
-
- Inbound processing is somewhat different from outbound processing,
- because of the use of SPIs to map IPsec-protected traffic to SAs.
- The inbound SPD cache (SPD-I) is applied only to bypassed or
-
-
-
-Kent & Seo Standards Track [Page 59]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- discarded traffic. If an arriving packet appears to be an IPsec
- fragment from an unprotected interface, reassembly is performed prior
- to IPsec processing. The intent for any SPD cache is that a packet
- that fails to match any entry is then referred to the corresponding
- SPD. Every SPD SHOULD have a nominal, final entry that catches
- anything that is otherwise unmatched, and discards it. This ensures
- that non-IPsec-protected traffic that arrives and does not match any
- SPD-I entry will be discarded.
-
- Unprotected Interface
- |
- V
- +-----+ IPsec protected
- ------------------->|Demux|-------------------+
- | +-----+ |
- | | |
- | Not IPsec | |
- | | |
- | V |
- | +-------+ +---------+ |
- | |DISCARD|<---|SPD-I (*)| |
- | +-------+ +---------+ |
- | | |
- | |-----+ |
- | | | |
- | | V |
- | | +------+ |
- | | | ICMP | |
- | | +------+ |
- | | V
- +---------+ | +-----------+
- ....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec
- +---------+ | | (AH/ESP) | Boundary
- ^ | +-----------+
- | | +---+ |
- | BYPASS | +-->|IKE| |
- | | | +---+ |
- | V | V
- | +----------+ +---------+ +----+
- |--------<------|Forwarding|<---------|SAD Check|-->|ICMP|
- nested SAs +----------+ | (***) | +----+
- | +---------+
- V
- Protected Interface
-
- Figure 3. Processing Model for Inbound Traffic
-
-
-
-
-
-Kent & Seo Standards Track [Page 60]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- (*) = The caches are shown here. If there is
- a cache miss, then the SPD is checked.
- There is no requirement that an
- implementation buffer the packet if
- there is a cache miss.
- (**) = This processing includes using the
- packet's SPI, etc., to look up the SA
- in the SAD, which forms a cache of the
- SPD for inbound packets (except for
- cases noted in Sections 4.4.2 and 5).
- See step 3a below.
- (***) = This SAD check refers to step 4 below.
-
- Prior to performing AH or ESP processing, any IP fragments that
- arrive via the unprotected interface are reassembled (by IP). Each
- inbound IP datagram to which IPsec processing will be applied is
- identified by the appearance of the AH or ESP values in the IP Next
- Protocol field (or of AH or ESP as a next layer protocol in the IPv6
- context).
-
- IPsec MUST perform the following steps:
-
- 1. When a packet arrives, it may be tagged with the ID of the
- interface (physical or virtual) via which it arrived, if
- necessary, to support multiple SPDs and associated SPD-I caches.
- (The interface ID is mapped to a corresponding SPD-ID.)
-
- 2. The packet is examined and demuxed into one of two categories:
- - If the packet appears to be IPsec protected and it is addressed
- to this device, an attempt is made to map it to an active SA
- via the SAD. Note that the device may have multiple IP
- addresses that may be used in the SAD lookup, e.g., in the case
- of protocols such as SCTP.
- - Traffic not addressed to this device, or addressed to this
- device and not AH or ESP, is directed to SPD-I lookup. (This
- implies that IKE traffic MUST have an explicit BYPASS entry in
- the SPD.) If multiple SPDs are employed, the tag assigned to
- the packet in step 1 is used to select the appropriate SPD-I
- (and cache) to search. SPD-I lookup determines whether the
- action is DISCARD or BYPASS.
-
- 3a. If the packet is addressed to the IPsec device and AH or ESP is
- specified as the protocol, the packet is looked up in the SAD.
- For unicast traffic, use only the SPI (or SPI plus protocol).
- For multicast traffic, use the SPI plus the destination or SPI
- plus destination and source addresses, as specified in Section
- 4.1. In either case (unicast or multicast), if there is no match,
- discard the traffic. This is an auditable event. The audit log
-
-
-
-Kent & Seo Standards Track [Page 61]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- entry for this event SHOULD include the current date/time, SPI,
- source and destination of the packet, IPsec protocol, and any
- other selector values of the packet that are available. If the
- packet is found in the SAD, process it accordingly (see step 4).
-
- 3b. If the packet is not addressed to the device or is addressed to
- this device and is not AH or ESP, look up the packet header in
- the (appropriate) SPD-I cache. If there is a match and the
- packet is to be discarded or bypassed, do so. If there is no
- cache match, look up the packet in the corresponding SPD-I and
- create a cache entry as appropriate. (No SAs are created in
- response to receipt of a packet that requires IPsec protection;
- only BYPASS or DISCARD cache entries can be created this way.) If
- there is no match, discard the traffic. This is an auditable
- event. The audit log entry for this event SHOULD include the
- current date/time, SPI if available, IPsec protocol if available,
- source and destination of the packet, and any other selector
- values of the packet that are available.
-
- 3c. Processing of ICMP messages is assumed to take place on the
- unprotected side of the IPsec boundary. Unprotected ICMP
- messages are examined and local policy is applied to determine
- whether to accept or reject these messages and, if accepted, what
- action to take as a result. For example, if an ICMP unreachable
- message is received, the implementation must decide whether to
- act on it, reject it, or act on it with constraints. (See Section
- 6.)
-
- 4. Apply AH or ESP processing as specified, using the SAD entry
- selected in step 3a above. Then match the packet against the
- inbound selectors identified by the SAD entry to verify that the
- received packet is appropriate for the SA via which it was
- received.
-
- 5. If an IPsec system receives an inbound packet on an SA and the
- packet's header fields are not consistent with the selectors for
- the SA, it MUST discard the packet. This is an auditable event.
- The audit log entry for this event SHOULD include the current
- date/time, SPI, IPsec protocol(s), source and destination of the
- packet, any other selector values of the packet that are
- available, and the selector values from the relevant SAD entry.
- The system SHOULD also be capable of generating and sending an
- IKE notification of INVALID_SELECTORS to the sender (IPsec peer),
- indicating that the received packet was discarded because of
- failure to pass selector checks.
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 62]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- To minimize the impact of a DoS attack, or a mis-configured peer, the
- IPsec system SHOULD include a management control to allow an
- administrator to configure the IPsec implementation to send or not
- send this IKE notification, and if this facility is selected, to rate
- limit the transmission of such notifications.
-
- After traffic is bypassed or processed through IPsec, it is handed to
- the inbound forwarding function for disposition. This function may
- cause the packet to be sent (outbound) across the IPsec boundary for
- additional inbound IPsec processing, e.g., in support of nested SAs.
- If so, then as with ALL outbound traffic that is to be bypassed, the
- packet MUST be matched against an SPD-O entry. Ultimately, the
- packet should be forwarded to the destination host or process for
- disposition.
-
-6. ICMP Processing
-
- This section describes IPsec handling of ICMP traffic. There are two
- categories of ICMP traffic: error messages (e.g., type = destination
- unreachable) and non-error messages (e.g., type = echo). This
- section applies exclusively to error messages. Disposition of
- non-error, ICMP messages (that are not addressed to the IPsec
- implementation itself) MUST be explicitly accounted for using SPD
- entries.
-
- The discussion in this section applies to ICMPv6 as well as to
- ICMPv4. Also, a mechanism SHOULD be provided to allow an
- administrator to cause ICMP error messages (selected, all, or none)
- to be logged as an aid to problem diagnosis.
-
-6.1. Processing ICMP Error Messages Directed to an IPsec Implementation
-
-6.1.1. ICMP Error Messages Received on the Unprotected Side of the
- Boundary
-
- Figure 3 in Section 5.2 shows a distinct ICMP processing module on
- the unprotected side of the IPsec boundary, for processing ICMP
- messages (error or otherwise) that are addressed to the IPsec device
- and that are not protected via AH or ESP. An ICMP message of this
- sort is unauthenticated, and its processing may result in denial or
- degradation of service. This suggests that, in general, it would be
- desirable to ignore such messages. However, many ICMP messages will
- be received by hosts or security gateways from unauthenticated
- sources, e.g., routers in the public Internet. Ignoring these ICMP
- messages can degrade service, e.g., because of a failure to process
- PMTU message and redirection messages. Thus, there is also a
- motivation for accepting and acting upon unauthenticated ICMP
- messages.
-
-
-
-Kent & Seo Standards Track [Page 63]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- To accommodate both ends of this spectrum, a compliant IPsec
- implementation MUST permit a local administrator to configure an
- IPsec implementation to accept or reject unauthenticated ICMP
- traffic. This control MUST be at the granularity of ICMP type and
- MAY be at the granularity of ICMP type and code. Additionally, an
- implementation SHOULD incorporate mechanisms and parameters for
- dealing with such traffic. For example, there could be the ability
- to establish a minimum PMTU for traffic (on a per destination basis),
- to prevent receipt of an unauthenticated ICMP from setting the PMTU
- to a trivial size.
-
- If an ICMP PMTU message passes the checks above and the system is
- configured to accept it, then there are two possibilities. If the
- implementation applies fragmentation on the ciphertext side of the
- boundary, then the accepted PMTU information is passed to the
- forwarding module (outside of the IPsec implementation), which uses
- it to manage outbound packet fragmentation. If the implementation is
- configured to effect plaintext side fragmentation, then the PMTU
- information is passed to the plaintext side and processed as
- described in Section 8.2.
-
-6.1.2. ICMP Error Messages Received on the Protected Side of the
- Boundary
-
- These ICMP messages are not authenticated, but they do come from
- sources on the protected side of the IPsec boundary. Thus, these
- messages generally are viewed as more "trustworthy" than their
- counterparts arriving from sources on the unprotected side of the
- boundary. The major security concern here is that a compromised host
- or router might emit erroneous ICMP error messages that could degrade
- service for other devices "behind" the security gateway, or that
- could even result in violations of confidentiality. For example, if
- a bogus ICMP redirect were consumed by a security gateway, it could
- cause the forwarding table on the protected side of the boundary to
- be modified so as to deliver traffic to an inappropriate destination
- "behind" the gateway. Thus, implementers MUST provide controls to
- allow local administrators to constrain the processing of ICMP error
- messages received on the protected side of the boundary, and directed
- to the IPsec implementation. These controls are of the same type as
- those employed on the unprotected side, described above in Section
- 6.1.1.
-
-6.2. Processing Protected, Transit ICMP Error Messages
-
- When an ICMP error message is transmitted via an SA to a device
- "behind" an IPsec implementation, both the payload and the header of
- the ICMP message require checking from an access control perspective.
- If one of these messages is forwarded to a host behind a security
-
-
-
-Kent & Seo Standards Track [Page 64]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- gateway, the receiving host IP implementation will make decisions
- based on the payload, i.e., the header of the packet that purportedly
- triggered the error response. Thus, an IPsec implementation MUST be
- configurable to check that this payload header information is
- consistent with the SA via which it arrives. (This means that the
- payload header, with source and destination address and port fields
- reversed, matches the traffic selectors for the SA.) If this sort of
- check is not performed, then, for example, anyone with whom the
- receiving IPsec system (A) has an active SA could send an ICMP
- Destination Unreachable message that refers to any host/net with
- which A is currently communicating, and thus effect a highly
- efficient DoS attack regarding communication with other peers of A.
- Normal IPsec receiver processing of traffic is not sufficient to
- protect against such attacks. However, not all contexts may require
- such checks, so it is also necessary to allow a local administrator
- to configure an implementation to NOT perform such checks.
-
- To accommodate both policies, the following convention is adopted.
- If an administrator wants to allow ICMP error messages to be carried
- by an SA without inspection of the payload, then configure an SPD
- entry that explicitly allows for carriage of such traffic. If an
- administrator wants IPsec to check the payload of ICMP error messages
- for consistency, then do not create any SPD entries that accommodate
- carriage of such traffic based on the ICMP packet header. This
- convention motivates the following processing description.
-
- IPsec senders and receivers MUST support the following processing for
- ICMP error messages that are sent and received via SAs.
-
- If an SA exists that accommodates an outbound ICMP error message,
- then the message is mapped to the SA and only the IP and ICMP headers
- are checked upon receipt, just as would be the case for other
- traffic. If no SA exists that matches the traffic selectors
- associated with an ICMP error message, then the SPD is searched to
- determine if such an SA can be created. If so, the SA is created and
- the ICMP error message is transmitted via that SA. Upon receipt,
- this message is subject to the usual traffic selector checks at the
- receiver. This processing is exactly what would happen for traffic
- in general, and thus does not represent any special processing for
- ICMP error messages.
-
- If no SA exists that would carry the outbound ICMP message in
- question, and if no SPD entry would allow carriage of this outbound
- ICMP error message, then an IPsec implementation MUST map the message
- to the SA that would carry the return traffic associated with the
- packet that triggered the ICMP error message. This requires an IPsec
- implementation to detect outbound ICMP error messages that map to no
- extant SA or SPD entry, and treat them specially with regard to SA
-
-
-
-Kent & Seo Standards Track [Page 65]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- creation and lookup. The implementation extracts the header for the
- packet that triggered the error (from the ICMP message payload),
- reverses the source and destination IP address fields, extracts the
- protocol field, and reverses the port fields (if accessible). It
- then uses this extracted information to locate an appropriate, active
- outbound SA, and transmits the error message via this SA. If no such
- SA exists, no SA will be created, and this is an auditable event.
-
- If an IPsec implementation receives an inbound ICMP error message on
- an SA, and the IP and ICMP headers of the message do not match the
- traffic selectors for the SA, the receiver MUST process the received
- message in a special fashion. Specifically, the receiver must
- extract the header of the triggering packet from the ICMP payload,
- and reverse fields as described above to determine if the packet is
- consistent with the selectors for the SA via which the ICMP error
- message was received. If the packet fails this check, the IPsec
- implementation MUST NOT forwarded the ICMP message to the
- destination. This is an auditable event.
-
-7. Handling Fragments (on the protected side of the IPsec boundary)
-
- Earlier sections of this document describe mechanisms for (a)
- fragmenting an outbound packet after IPsec processing has been
- applied and reassembling it at the receiver before IPsec processing
- and (b) handling inbound fragments received from the unprotected side
- of the IPsec boundary. This section describes how an implementation
- should handle the processing of outbound plaintext fragments on the
- protected side of the IPsec boundary. (See Appendix D, "Fragment
- Handling Rationale".) In particular, it addresses:
-
- o mapping an outbound non-initial fragment to the right SA
- (or finding the right SPD entry)
- o verifying that a received non-initial fragment is
- authorized for the SA via which it was received
- o mapping outbound and inbound non-initial fragments to the
- right SPD-O/SPD-I entry or the relevant cache entry, for
- BYPASS/DISCARD traffic
-
- Note: In Section 4.1, transport mode SAs have been defined to not
- carry fragments (IPv4 or IPv6). Note also that in Section 4.4.1, two
- special values, ANY and OPAQUE, were defined for selectors and that
- ANY includes OPAQUE. The term "non-trivial" is used to mean that the
- selector has a value other than OPAQUE or ANY.
-
- Note: The term "non-initial fragment" is used here to indicate a
- fragment that does not contain all the selector values that may be
- needed for access control. As observed in Section 4.4.1, depending
- on the Next Layer Protocol, in addition to Ports, the ICMP message
-
-
-
-Kent & Seo Standards Track [Page 66]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- type/code or Mobility Header type could be missing from non-initial
- fragments. Also, for IPv6, even the first fragment might NOT contain
- the Next Layer Protocol or Ports (or ICMP message type/code, or
- Mobility Header type) depending on the kind and number of extension
- headers present. If a non-initial fragment contains the Port (or
- ICMP type and code or Mobility Header type) but not the Next Layer
- Protocol, then unless there is an SPD entry for the relevant
- Local/Remote addresses with ANY for Next Layer Protocol and Port (or
- ICMP type and code or Mobility Header type), the fragment would not
- contain all the selector information needed for access control.
-
- To address the above issues, three approaches have been defined:
-
- o Tunnel mode SAs that carry initial and non-initial fragments
- (See Section 7.1.)
- o Separate tunnel mode SAs for non-initial fragments (See
- Section 7.2.)
- o Stateful fragment checking (See Section 7.3.)
-
-7.1. Tunnel Mode SAs that Carry Initial and Non-Initial Fragments
-
- All implementations MUST support tunnel mode SAs that are configured
- to pass traffic without regard to port field (or ICMP type/code or
- Mobility Header type) values. If the SA will carry traffic for
- specified protocols, the selector set for the SA MUST specify the
- port fields (or ICMP type/code or Mobility Header type) as ANY. An
- SA defined in this fashion will carry all traffic including initial
- and non-initial fragments for the indicated Local/Remote addresses
- and specified Next Layer protocol(s). If the SA will carry traffic
- without regard to a specific protocol value (i.e., ANY is specified
- as the (Next Layer) protocol selector value), then the port field
- values are undefined and MUST be set to ANY as well. (As noted in
- 4.4.1, ANY includes OPAQUE as well as all specific values.)
-
-7.2. Separate Tunnel Mode SAs for Non-Initial Fragments
-
- An implementation MAY support tunnel mode SAs that will carry only
- non-initial fragments, separate from non-fragmented packets and
- initial fragments. The OPAQUE value will be used to specify port (or
- ICMP type/code or Mobility Header type) field selectors for an SA to
- carry such fragments. Receivers MUST perform a minimum offset check
- on IPv4 (non-initial) fragments to protect against overlapping
- fragment attacks when SAs of this type are employed. Because such
- checks cannot be performed on IPv6 non-initial fragments, users and
- administrators are advised that carriage of such fragments may be
- dangerous, and implementers may choose to NOT support such SAs for
- IPv6 traffic. Also, an SA of this sort will carry all non-initial
- fragments that match a specified Local/Remote address pair and
-
-
-
-Kent & Seo Standards Track [Page 67]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- protocol value, i.e., the fragments carried on this SA belong to
- packets that if not fragmented, might have gone on separate SAs of
- differing security. Therefore, users and administrators are advised
- to protect such traffic using ESP (with integrity) and the
- "strongest" integrity and encryption algorithms in use between both
- peers. (Determination of the "strongest" algorithms requires
- imposing an ordering of the available algorithms, a local
- determination at the discretion of the initiator of the SA.)
-
- Specific port (or ICMP type/code or Mobility Header type) selector
- values will be used to define SAs to carry initial fragments and
- non-fragmented packets. This approach can be used if a user or
- administrator wants to create one or more tunnel mode SAs between the
- same Local/Remote addresses that discriminate based on port (or ICMP
- type/code or Mobility Header type) fields. These SAs MUST have
- non-trivial protocol selector values, otherwise approach #1 above
- MUST be used.
-
- Note: In general, for the approach described in this section, one
- needs only a single SA between two implementations to carry all
- non-initial fragments. However, if one chooses to have multiple SAs
- between the two implementations for QoS differentiation, then one
- might also want multiple SAs to carry fragments-without-ports, one
- for each supported QoS class. Since support for QoS via distinct SAs
- is a local matter, not mandated by this document, the choice to have
- multiple SAs to carry non-initial fragments should also be local.
-
-7.3. Stateful Fragment Checking
-
- An implementation MAY support some form of stateful fragment checking
- for a tunnel mode SA with non-trivial port (or ICMP type/code or MH
- type) field values (not ANY or OPAQUE). Implementations that will
- transmit non-initial fragments on a tunnel mode SA that makes use of
- non-trivial port (or ICMP type/code or MH type) selectors MUST notify
- a peer via the IKE NOTIFY NON_FIRST_FRAGMENTS_ALSO payload.
-
- The peer MUST reject this proposal if it will not accept non-initial
- fragments in this context. If an implementation does not
- successfully negotiate transmission of non-initial fragments for such
- an SA, it MUST NOT send such fragments over the SA. This standard
- does not specify how peers will deal with such fragments, e.g., via
- reassembly or other means, at either sender or receiver. However, a
- receiver MUST discard non-initial fragments that arrive on an SA with
- non-trivial port (or ICMP type/code or MH type) selector values
- unless this feature has been negotiated. Also, the receiver MUST
- discard non-initial fragments that do not comply with the security
- policy applied to the overall packet. Discarding such packets is an
- auditable event. Note that in network configurations where fragments
-
-
-
-Kent & Seo Standards Track [Page 68]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- of a packet might be sent or received via different security gateways
- or BITW implementations, stateful strategies for tracking fragments
- may fail.
-
-7.4. BYPASS/DISCARD Traffic
-
- All implementations MUST support DISCARDing of fragments using the
- normal SPD packet classification mechanisms. All implementations
- MUST support stateful fragment checking to accommodate BYPASS traffic
- for which a non-trivial port range is specified. The concern is that
- BYPASS of a cleartext, non-initial fragment arriving at an IPsec
- implementation could undermine the security afforded IPsec-protected
- traffic directed to the same destination. For example, consider an
- IPsec implementation configured with an SPD entry that calls for
- IPsec protection of traffic between a specific source/destination
- address pair, and for a specific protocol and destination port, e.g.,
- TCP traffic on port 23 (Telnet). Assume that the implementation also
- allows BYPASS of traffic from the same source/destination address
- pair and protocol, but for a different destination port, e.g., port
- 119 (NNTP). An attacker could send a non-initial fragment (with a
- forged source address) that, if bypassed, could overlap with
- IPsec-protected traffic from the same source and thus violate the
- integrity of the IPsec-protected traffic. Requiring stateful
- fragment checking for BYPASS entries with non-trivial port ranges
- prevents attacks of this sort. As noted above, in network
- configurations where fragments of a packet might be sent or received
- via different security gateways or BITW implementations, stateful
- strategies for tracking fragments may fail.
-
-8. Path MTU/DF Processing
-
- The application of AH or ESP to an outbound packet increases the size
- of a packet and thus may cause a packet to exceed the PMTU for the SA
- via which the packet will travel. An IPsec implementation also may
- receive an unprotected ICMP PMTU message and, if it chooses to act
- upon the message, the result will affect outbound traffic processing.
- This section describes the processing required of an IPsec
- implementation to deal with these two PMTU issues.
-
-8.1. DF Bit
-
- All IPsec implementations MUST support the option of copying the DF
- bit from an outbound packet to the tunnel mode header that it emits,
- when traffic is carried via a tunnel mode SA. This means that it
- MUST be possible to configure the implementation's treatment of the
- DF bit (set, clear, copy from inner header) for each SA. This
- applies to SAs where both inner and outer headers are IPv4.
-
-
-
-
-Kent & Seo Standards Track [Page 69]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
-8.2. Path MTU (PMTU) Discovery
-
- This section discusses IPsec handling for unprotected Path MTU
- Discovery messages. ICMP PMTU is used here to refer to an ICMP
- message for:
-
- IPv4 (RFC 792 [Pos81b]):
- - Type = 3 (Destination Unreachable)
- - Code = 4 (Fragmentation needed and DF set)
- - Next-Hop MTU in the low-order 16 bits of the
- second word of the ICMP header (labeled "unused"
- in RFC 792), with high-order 16 bits set to zero)
-
- IPv6 (RFC 2463 [CD98]):
- - Type = 2 (Packet Too Big)
- - Code = 0 (Fragmentation needed)
- - Next-Hop MTU in the 32-bit MTU field of the ICMP6
- message
-
-8.2.1. Propagation of PMTU
-
- When an IPsec implementation receives an unauthenticated PMTU
- message, and it is configured to process (vs. ignore) such messages,
- it maps the message to the SA to which it corresponds. This mapping
- is effected by extracting the header information from the payload of
- the PMTU message and applying the procedure described in Section 5.2.
- The PMTU determined by this message is used to update the SAD PMTU
- field, taking into account the size of the AH or ESP header that will
- be applied, any crypto synchronization data, and the overhead imposed
- by an additional IP header, in the case of a tunnel mode SA.
-
- In a native host implementation, it is possible to maintain PMTU data
- at the same granularity as for unprotected communication, so there is
- no loss of functionality. Signaling of the PMTU information is
- internal to the host. For all other IPsec implementation options,
- the PMTU data must be propagated via a synthesized ICMP PMTU. In
- these cases, the IPsec implementation SHOULD wait for outbound
- traffic to be mapped to the SAD entry. When such traffic arrives, if
- the traffic would exceed the updated PMTU value the traffic MUST be
- handled as follows:
-
- Case 1: Original (cleartext) packet is IPv4 and has the DF
- bit set. The implementation SHOULD discard the packet
- and send a PMTU ICMP message.
-
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 70]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- Case 2: Original (cleartext) packet is IPv4 and has the DF
- bit clear. The implementation SHOULD fragment (before or
- after encryption per its configuration) and then forward
- the fragments. It SHOULD NOT send a PMTU ICMP message.
-
- Case 3: Original (cleartext) packet is IPv6. The implementation
- SHOULD discard the packet and send a PMTU ICMP message.
-
-8.2.2. PMTU Aging
-
- In all IPsec implementations, the PMTU associated with an SA MUST be
- "aged" and some mechanism is required to update the PMTU in a timely
- manner, especially for discovering if the PMTU is smaller than
- required by current network conditions. A given PMTU has to remain
- in place long enough for a packet to get from the source of the SA to
- the peer, and to propagate an ICMP error message if the current PMTU
- is too big.
-
- Implementations SHOULD use the approach described in the Path MTU
- Discovery document (RFC 1191 [MD90], Section 6.3), which suggests
- periodically resetting the PMTU to the first-hop data-link MTU and
- then letting the normal PMTU Discovery processes update the PMTU as
- necessary. The period SHOULD be configurable.
-
-9. Auditing
-
- IPsec implementations are not required to support auditing. For the
- most part, the granularity of auditing is a local matter. However,
- several auditable events are identified in this document, and for
- each of these events a minimum set of information that SHOULD be
- included in an audit log is defined. Additional information also MAY
- be included in the audit log for each of these events, and additional
- events, not explicitly called out in this specification, also MAY
- result in audit log entries. There is no requirement for the
- receiver to transmit any message to the purported transmitter in
- response to the detection of an auditable event, because of the
- potential to induce denial of service via such action.
-
-10. Conformance Requirements
-
- All IPv4 IPsec implementations MUST comply with all requirements of
- this document. All IPv6 implementations MUST comply with all
- requirements of this document.
-
-
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 71]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
-11. Security Considerations
-
- The focus of this document is security; hence security considerations
- permeate this specification.
-
- IPsec imposes stringent constraints on bypass of IP header data in
- both directions, across the IPsec barrier, especially when tunnel
- mode SAs are employed. Some constraints are absolute, while others
- are subject to local administrative controls, often on a per-SA
- basis. For outbound traffic, these constraints are designed to limit
- covert channel bandwidth. For inbound traffic, the constraints are
- designed to prevent an adversary who has the ability to tamper with
- one data stream (on the unprotected side of the IPsec barrier) from
- adversely affecting other data streams (on the protected side of the
- barrier). The discussion in Section 5 dealing with processing DSCP
- values for tunnel mode SAs illustrates this concern.
-
- If an IPsec implementation is configured to pass ICMP error messages
- over SAs based on the ICMP header values, without checking the header
- information from the ICMP message payload, serious vulnerabilities
- may arise. Consider a scenario in which several sites (A, B, and C)
- are connected to one another via ESP-protected tunnels: A-B, A-C, and
- B-C. Also assume that the traffic selectors for each tunnel specify
- ANY for protocol and port fields and IP source/destination address
- ranges that encompass the address range for the systems behind the
- security gateways serving each site. This would allow a host at site
- B to send an ICMP Destination Unreachable message to any host at site
- A, that declares all hosts on the net at site C to be unreachable.
- This is a very efficient DoS attack that could have been prevented if
- the ICMP error messages were subjected to the checks that IPsec
- provides, if the SPD is suitably configured, as described in Section
- 6.2.
-
-12. IANA Considerations
-
- The IANA has assigned the value (3) for the asn1-modules registry and
- has assigned the object identifier 1.3.6.1.5.8.3.1 for the SPD
- module. See Appendix C, "ASN.1 for an SPD Entry".
-
-13. Differences from RFC 2401
-
- This architecture document differs substantially from RFC 2401
- [RFC2401] in detail and in organization, but the fundamental notions
- are unchanged.
-
- o The processing model has been revised to address new IPsec
- scenarios, improve performance, and simplify implementation. This
- includes a separation between forwarding (routing) and SPD
-
-
-
-Kent & Seo Standards Track [Page 72]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- selection, several SPD changes, and the addition of an outbound SPD
- cache and an inbound SPD cache for bypassed or discarded traffic.
- There is also a new database, the Peer Authorization Database
- (PAD). This provides a link between an SA management protocol
- (such as IKE) and the SPD.
-
- o There is no longer a requirement to support nested SAs or "SA
- bundles". Instead this functionality can be achieved through SPD
- and forwarding table configuration. An example of a configuration
- has been added in Appendix E.
-
- o SPD entries were redefined to provide more flexibility. Each SPD
- entry now consists of 1 to N sets of selectors, where each selector
- set contains one protocol and a "list of ranges" can now be
- specified for the Local IP address, Remote IP address, and whatever
- fields (if any) are associated with the Next Layer Protocol (Local
- Port, Remote Port, ICMP message type and code, and Mobility Header
- type). An individual value for a selector is represented via a
- trivial range and ANY is represented via a range than spans all
- values for the selector. An example of an ASN.1 description is
- included in Appendix C.
-
- o TOS (IPv4) and Traffic Class (IPv6) have been replaced by DSCP and
- ECN. The tunnel section has been updated to explain how to handle
- DSCP and ECN bits.
-
- o For tunnel mode SAs, an SG, BITS, or BITW implementation is now
- allowed to fragment packets before applying IPsec. This applies
- only to IPv4. For IPv6 packets, only the originator is allowed to
- fragment them.
-
- o When security is desired between two intermediate systems along a
- path or between an intermediate system and an end system, transport
- mode may now be used between security gateways and between a
- security gateway and a host.
-
- o This document clarifies that for all traffic that crosses the IPsec
- boundary, including IPsec management traffic, the SPD or associated
- caches must be consulted.
-
- o This document defines how to handle the situation of a security
- gateway with multiple subscribers requiring separate IPsec
- contexts.
-
- o A definition of reserved SPIs has been added.
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 73]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- o Text has been added explaining why ALL IP packets must be checked
- -- IPsec includes minimal firewall functionality to support access
- control at the IP layer.
-
- o The tunnel section has been updated to clarify how to handle the IP
- options field and IPv6 extension headers when constructing the
- outer header.
-
- o SA mapping for inbound traffic has been updated to be consistent
- with the changes made in AH and ESP for support of unicast and
- multicast SAs.
-
- o Guidance has been added regarding how to handle the covert channel
- created in tunnel mode by copying the DSCP value to outer header.
-
- o Support for AH in both IPv4 and IPv6 is no longer required.
-
- o PMTU handling has been updated. The appendix on
- PMTU/DF/Fragmentation has been deleted.
-
- o Three approaches have been added for handling plaintext fragments
- on the protected side of the IPsec boundary. Appendix D documents
- the rationale behind them.
-
- o Added revised text describing how to derive selector values for SAs
- (from the SPD entry or from the packet, etc.)
-
- o Added a new table describing the relationship between selector
- values in an SPD entry, the PFP flag, and resulting selector values
- in the corresponding SAD entry.
-
- o Added Appendix B to describe decorrelation.
-
- o Added text describing how to handle an outbound packet that must be
- discarded.
-
- o Added text describing how to handle a DISCARDED inbound packet,
- i.e., one that does not match the SA upon which it arrived.
-
- o IPv6 mobility header has been added as a possible Next Layer
- Protocol. IPv6 Mobility Header message type has been added as a
- selector.
-
- o ICMP message type and code have been added as selectors.
-
- o The selector "data sensitivity level" has been removed to simplify
- things.
-
-
-
-
-Kent & Seo Standards Track [Page 74]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- o Updated text describing handling ICMP error messages. The appendix
- on "Categorization of ICMP Messages" has been deleted.
-
- o The text for the selector name has been updated and clarified.
-
- o The "Next Layer Protocol" has been further explained and a default
- list of protocols to skip when looking for the Next Layer Protocol
- has been added.
-
- o The text has been amended to say that this document assumes use of
- IKEv2 or an SA management protocol with comparable features.
-
- o Text has been added clarifying the algorithm for mapping inbound
- IPsec datagrams to SAs in the presence of multicast SAs.
-
- o The appendix "Sequence Space Window Code Example" has been removed.
-
- o With respect to IP addresses and ports, the terms "Local" and
- "Remote" are used for policy rules (replacing source and
- destination). "Local" refers to the entity being protected by an
- IPsec implementation, i.e., the "source" address/port of outbound
- packets or the "destination" address/port of inbound packets.
- "Remote" refers to a peer entity or peer entities. The terms
- "source" and "destination" are still used for packet header fields.
-
-14. Acknowledgements
-
- The authors would like to acknowledge the contributions of Ran
- Atkinson, who played a critical role in initial IPsec activities, and
- who authored the first series of IPsec standards: RFCs 1825-1827; and
- Charlie Lynn, who made significant contributions to the second series
- of IPsec standards (RFCs 2401, 2402, and 2406) and to the current
- versions, especially with regard to IPv6 issues. The authors also
- would like to thank the members of the IPsec and MSEC working groups
- who have contributed to the development of this protocol
- specification.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 75]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
-Appendix A: Glossary
-
- This section provides definitions for several key terms that are
- employed in this document. Other documents provide additional
- definitions and background information relevant to this technology,
- e.g., [Shi00], [VK83], and [HA94]. Included in this glossary are
- generic security service and security mechanism terms, plus
- IPsec-specific terms.
-
- Access Control
- A security service that prevents unauthorized use of a resource,
- including the prevention of use of a resource in an unauthorized
- manner. In the IPsec context, the resource to which access is
- being controlled is often:
-
- o for a host, computing cycles or data
- o for a security gateway, a network behind the gateway
- or bandwidth on that network.
-
- Anti-replay
- See "Integrity" below.
-
- Authentication
- Used informally to refer to the combination of two nominally
- distinct security services, data origin authentication and
- connectionless integrity. See the definitions below for each of
- these services.
-
- Availability
- When viewed as a security service, addresses the security concerns
- engendered by attacks against networks that deny or degrade
- service. For example, in the IPsec context, the use of
- anti-replay mechanisms in AH and ESP support availability.
-
- Confidentiality
- The security service that protects data from unauthorized
- disclosure. The primary confidentiality concern in most instances
- is unauthorized disclosure of application-level data, but
- disclosure of the external characteristics of communication also
- can be a concern in some circumstances. Traffic flow
- confidentiality is the service that addresses this latter concern
- by concealing source and destination addresses, message length, or
- frequency of communication. In the IPsec context, using ESP in
- tunnel mode, especially at a security gateway, can provide some
- level of traffic flow confidentiality. (See also "Traffic
- Analysis" below.)
-
-
-
-
-
-Kent & Seo Standards Track [Page 76]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- Data Origin Authentication
- A security service that verifies the identity of the claimed
- source of data. This service is usually bundled with
- connectionless integrity service.
-
- Encryption
- A security mechanism used to transform data from an intelligible
- form (plaintext) into an unintelligible form (ciphertext), to
- provide confidentiality. The inverse transformation process is
- designated "decryption". Often the term "encryption" is used to
- generically refer to both processes.
-
- Integrity
- A security service that ensures that modifications to data are
- detectable. Integrity comes in various flavors to match
- application requirements. IPsec supports two forms of integrity:
- connectionless and a form of partial sequence integrity.
- Connectionless integrity is a service that detects modification of
- an individual IP datagram, without regard to the ordering of the
- datagram in a stream of traffic. The form of partial sequence
- integrity offered in IPsec is referred to as anti-replay
- integrity, and it detects arrival of duplicate IP datagrams
- (within a constrained window). This is in contrast to
- connection-oriented integrity, which imposes more stringent
- sequencing requirements on traffic, e.g., to be able to detect
- lost or re-ordered messages. Although authentication and
- integrity services often are cited separately, in practice they
- are intimately connected and almost always offered in tandem.
-
- Protected vs. Unprotected
- "Protected" refers to the systems or interfaces that are inside
- the IPsec protection boundary, and "unprotected" refers to the
- systems or interfaces that are outside the IPsec protection
- boundary. IPsec provides a boundary through which traffic passes.
- There is an asymmetry to this barrier, which is reflected in the
- processing model. Outbound data, if not discarded or bypassed, is
- protected via the application of AH or ESP and the addition of the
- corresponding headers. Inbound data, if not discarded or
- bypassed, is processed via the removal of AH or ESP headers. In
- this document, inbound traffic enters an IPsec implementation from
- the "unprotected" interface. Outbound traffic enters the
- implementation via the "protected" interface, or is internally
- generated by the implementation on the "protected" side of the
- boundary and directed toward the "unprotected" interface. An
- IPsec implementation may support more than one interface on either
- or both sides of the boundary. The protected interface may be
-
-
-
-
-
-Kent & Seo Standards Track [Page 77]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- internal, e.g., in a host implementation of IPsec. The protected
- interface may link to a socket layer interface presented by the
- OS.
-
- Security Association (SA)
- A simplex (uni-directional) logical connection, created for
- security purposes. All traffic traversing an SA is provided the
- same security processing. In IPsec, an SA is an Internet-layer
- abstraction implemented through the use of AH or ESP. State data
- associated with an SA is represented in the SA Database (SAD).
-
- Security Gateway
- An intermediate system that acts as the communications interface
- between two networks. The set of hosts (and networks) on the
- external side of the security gateway is termed unprotected (they
- are generally at least less protected than those "behind" the SG),
- while the networks and hosts on the internal side are viewed as
- protected. The internal subnets and hosts served by a security
- gateway are presumed to be trusted by virtue of sharing a common,
- local, security administration. In the IPsec context, a security
- gateway is a point at which AH and/or ESP is implemented in order
- to serve a set of internal hosts, providing security services for
- these hosts when they communicate with external hosts also
- employing IPsec (either directly or via another security gateway).
-
- Security Parameters Index (SPI)
- An arbitrary 32-bit value that is used by a receiver to identify
- the SA to which an incoming packet should be bound. For a unicast
- SA, the SPI can be used by itself to specify an SA, or it may be
- used in conjunction with the IPsec protocol type. Additional IP
- address information is used to identify multicast SAs. The SPI is
- carried in AH and ESP protocols to enable the receiving system to
- select the SA under which a received packet will be processed. An
- SPI has only local significance, as defined by the creator of the
- SA (usually the receiver of the packet carrying the SPI); thus an
- SPI is generally viewed as an opaque bit string. However, the
- creator of an SA may choose to interpret the bits in an SPI to
- facilitate local processing.
-
- Traffic Analysis
- The analysis of network traffic flow for the purpose of deducing
- information that is useful to an adversary. Examples of such
- information are frequency of transmission, the identities of the
- conversing parties, sizes of packets, and flow identifiers
- [Sch94].
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 78]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
-Appendix B: Decorrelation
-
- This appendix is based on work done for caching of policies in the IP
- Security Policy Working Group by Luis Sanchez, Matt Condell, and John
- Zao.
-
- Two SPD entries are correlated if there is a non-null intersection
- between the values of corresponding selectors in each entry. Caching
- correlated SPD entries can lead to incorrect policy enforcement. A
- solution to this problem, which still allows for caching, is to
- remove the ambiguities by decorrelating the entries. That is, the
- SPD entries must be rewritten so that for every pair of entries there
- exists a selector for which there is a null intersection between the
- values in both of the entries. Once the entries are decorrelated,
- there is no longer any ordering requirement on them, since only one
- entry will match any lookup. The next section describes
- decorrelation in more detail and presents an algorithm that may be
- used to implement decorrelation.
-
-B.1. Decorrelation Algorithm
-
- The basic decorrelation algorithm takes each entry in a correlated
- SPD and divides it into a set of entries using a tree structure.
- The nodes of the tree are the selectors that may overlap between the
- policies. At each node, the algorithm creates a branch for each of
- the values of the selector. It also creates one branch for the
- complement of the union of all selector values. Policies are then
- formed by traversing the tree from the root to each leaf. The
- policies at the leaves are compared to the set of already
- decorrelated policy rules. Each policy at a leaf is either
- completely overridden by a policy in the already decorrelated set and
- is discarded or is decorrelated with all the policies in the
- decorrelated set and is added to it.
-
- The basic algorithm does not guarantee an optimal set of decorrelated
- entries. That is, the entries may be broken up into smaller sets
- than is necessary, though they will still provide all the necessary
- policy information. Some extensions to the basic algorithm are
- described later to improve this and improve the performance of the
- algorithm.
-
- C A set of ordered, correlated entries (a correlated SPD).
- Ci The ith entry in C.
- U The set of decorrelated entries being built from C.
- Ui The ith entry in U.
- Sik The kth selection for policy Ci.
- Ai The action for policy Ci.
-
-
-
-
-Kent & Seo Standards Track [Page 79]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- A policy (SPD entry) P may be expressed as a sequence of selector
- values and an action (BYPASS, DISCARD, or PROTECT):
-
- Ci = Si1 x Si2 x ... x Sik -> Ai
-
- 1) Put C1 in set U as U1
-
- For each policy Cj (j > 1) in C
-
- 2) If Cj is decorrelated with every entry in U, then add it to U.
-
- 3) If Cj is correlated with one or more entries in U, create a tree
- rooted at the policy Cj that partitions Cj into a set of decorrelated
- entries. The algorithm starts with a root node where no selectors
- have yet been chosen.
-
- A) Choose a selector in Cj, Sjn, that has not yet been chosen when
- traversing the tree from the root to this node. If there are no
- selectors not yet used, continue to the next unfinished branch
- until all branches have been completed. When the tree is
- completed, go to step D.
-
- T is the set of entries in U that are correlated with the entry
- at this node.
-
- The entry at this node is the entry formed by the selector
- values of each of the branches between the root and this node.
- Any selector values that are not yet represented by branches
- assume the corresponding selector value in Cj, since the values
- in Cj represent the maximum value for each selector.
-
- B) Add a branch to the tree for each value of the selector Sjn that
- appears in any of the entries in T. (If the value is a superset
- of the value of Sjn in Cj, then use the value in Cj, since that
- value represents the universal set.) Also add a branch for the
- complement of the union of all the values of the selector Sjn
- in T. When taking the complement, remember that the universal
- set is the value of Sjn in Cj. A branch need not be created
- for the null set.
-
- C) Repeat A and B until the tree is completed.
-
- D) The entry to each leaf now represents an entry that is a subset
- of Cj. The entries at the leaves completely partition Cj in
- such a way that each entry is either completely overridden by
- an entry in U, or is decorrelated with the entries in U.
-
- Add all the decorrelated entries at the leaves of the tree to U.
-
-
-
-Kent & Seo Standards Track [Page 80]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- 4) Get next Cj and go to 2.
-
- 5) When all entries in C have been processed, then U will contain an
- decorrelated version of C.
-
- There are several optimizations that can be made to this algorithm.
- A few of them are presented here.
-
- It is possible to optimize, or at least improve, the amount of
- branching that occurs by carefully choosing the order of the
- selectors used for the next branch. For example, if a selector Sjn
- can be chosen so that all the values for that selector in T are equal
- to or a superset of the value of Sjn in Cj, then only a single branch
- needs to be created (since the complement will be null).
-
- Branches of the tree do not have to proceed with the entire
- decorrelation algorithm. For example, if a node represents an entry
- that is decorrelated with all the entries in U, then there is no
- reason to continue decorrelating that branch. Also, if a branch is
- completely overridden by an entry in U, then there is no reason to
- continue decorrelating the branch.
-
- An additional optimization is to check to see if a branch is
- overridden by one of the CORRELATED entries in set C that has already
- been decorrelated. That is, if the branch is part of decorrelating
- Cj, then check to see if it was overridden by an entry Cm, m < j.
- This is a valid check, since all the entries Cm are already expressed
- in U.
-
- Along with checking if an entry is already decorrelated in step 2,
- check if Cj is overridden by any entry in U. If it is, skip it since
- it is not relevant. An entry x is overridden by another entry y if
- every selector in x is equal to or a subset of the corresponding
- selector in entry y.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 81]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
-Appendix C: ASN.1 for an SPD Entry
-
- This appendix is included as an additional way to describe SPD
- entries, as defined in Section 4.4.1. It uses ASN.1 syntax that has
- been successfully compiled. This syntax is merely illustrative and
- need not be employed in an implementation to achieve compliance. The
- SPD description in Section 4.4.1 is normative.
-
- SPDModule
-
- {iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5)
- ipsec (8) asn1-modules (3) spd-module (1) }
-
- DEFINITIONS IMPLICIT TAGS ::=
-
- BEGIN
-
- IMPORTS
- RDNSequence FROM PKIX1Explicit88
- { iso(1) identified-organization(3)
- dod(6) internet(1) security(5) mechanisms(5) pkix(7)
- id-mod(0) id-pkix1-explicit(18) } ;
-
- -- An SPD is a list of policies in decreasing order of preference
- SPD ::= SEQUENCE OF SPDEntry
-
- SPDEntry ::= CHOICE {
- iPsecEntry IPsecEntry, -- PROTECT traffic
- bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARD/BYPASS
-
- IPsecEntry ::= SEQUENCE { -- Each entry consists of
- name NameSets OPTIONAL,
- pFPs PacketFlags, -- Populate from packet flags
- -- Applies to ALL of the corresponding
- -- traffic selectors in the SelectorLists
- condition SelectorLists, -- Policy "condition"
- processing Processing -- Policy "action"
- }
-
- BypassOrDiscardEntry ::= SEQUENCE {
- bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD
- condition InOutBound }
-
- InOutBound ::= CHOICE {
- outbound [0] SelectorLists,
- inbound [1] SelectorLists,
- bothways [2] BothWays }
-
-
-
-
-Kent & Seo Standards Track [Page 82]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- BothWays ::= SEQUENCE {
- inbound SelectorLists,
- outbound SelectorLists }
-
- NameSets ::= SEQUENCE {
- passed SET OF Names-R, -- Matched to IKE ID by
- -- responder
- local SET OF Names-I } -- Used internally by IKE
- -- initiator
-
- Names-R ::= CHOICE { -- IKEv2 IDs
- dName RDNSequence, -- ID_DER_ASN1_DN
- fqdn FQDN, -- ID_FQDN
- rfc822 [0] RFC822Name, -- ID_RFC822_ADDR
- keyID OCTET STRING } -- KEY_ID
-
- Names-I ::= OCTET STRING -- Used internally by IKE
- -- initiator
-
- FQDN ::= IA5String
-
- RFC822Name ::= IA5String
-
- PacketFlags ::= BIT STRING {
- -- if set, take selector value from packet
- -- establishing SA
- -- else use value in SPD entry
- localAddr (0),
- remoteAddr (1),
- protocol (2),
- localPort (3),
- remotePort (4) }
-
- SelectorLists ::= SET OF SelectorList
-
- SelectorList ::= SEQUENCE {
- localAddr AddrList,
- remoteAddr AddrList,
- protocol ProtocolChoice }
-
- Processing ::= SEQUENCE {
- extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit
- seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit
- fragCheck BOOLEAN, -- TRUE stateful fragment checking,
- -- FALSE no stateful fragment checking
- lifetime SALifetime,
- spi ManualSPI,
- algorithms ProcessingAlgs,
-
-
-
-Kent & Seo Standards Track [Page 83]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- tunnel TunnelOptions OPTIONAL } -- if absent, use
- -- transport mode
-
- SALifetime ::= SEQUENCE {
- seconds [0] INTEGER OPTIONAL,
- bytes [1] INTEGER OPTIONAL }
-
- ManualSPI ::= SEQUENCE {
- spi INTEGER,
- keys KeyIDs }
-
- KeyIDs ::= SEQUENCE OF OCTET STRING
-
- ProcessingAlgs ::= CHOICE {
- ah [0] IntegrityAlgs, -- AH
- esp [1] ESPAlgs} -- ESP
-
- ESPAlgs ::= CHOICE {
- integrity [0] IntegrityAlgs, -- integrity only
- confidentiality [1] ConfidentialityAlgs, -- confidentiality
- -- only
- both [2] IntegrityConfidentialityAlgs,
- combined [3] CombinedModeAlgs }
-
- IntegrityConfidentialityAlgs ::= SEQUENCE {
- integrity IntegrityAlgs,
- confidentiality ConfidentialityAlgs }
-
- -- Integrity Algorithms, ordered by decreasing preference
- IntegrityAlgs ::= SEQUENCE OF IntegrityAlg
-
- -- Confidentiality Algorithms, ordered by decreasing preference
- ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg
-
- -- Integrity Algorithms
- IntegrityAlg ::= SEQUENCE {
- algorithm IntegrityAlgType,
- parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
-
- IntegrityAlgType ::= INTEGER {
- none (0),
- auth-HMAC-MD5-96 (1),
- auth-HMAC-SHA1-96 (2),
- auth-DES-MAC (3),
- auth-KPDK-MD5 (4),
- auth-AES-XCBC-96 (5)
- -- tbd (6..65535)
- }
-
-
-
-Kent & Seo Standards Track [Page 84]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- -- Confidentiality Algorithms
- ConfidentialityAlg ::= SEQUENCE {
- algorithm ConfidentialityAlgType,
- parameters ANY -- DEFINED BY algorithm -- OPTIONAL }
-
- ConfidentialityAlgType ::= INTEGER {
- encr-DES-IV64 (1),
- encr-DES (2),
- encr-3DES (3),
- encr-RC5 (4),
- encr-IDEA (5),
- encr-CAST (6),
- encr-BLOWFISH (7),
- encr-3IDEA (8),
- encr-DES-IV32 (9),
- encr-RC4 (10),
- encr-NULL (11),
- encr-AES-CBC (12),
- encr-AES-CTR (13)
- -- tbd (14..65535)
- }
-
- CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg
-
- CombinedModeAlg ::= SEQUENCE {
- algorithm CombinedModeType,
- parameters ANY -- DEFINED BY algorithm} -- defined outside
- -- of this document for AES modes.
-
- CombinedModeType ::= INTEGER {
- comb-AES-CCM (1),
- comb-AES-GCM (2)
- -- tbd (3..65535)
- }
-
- TunnelOptions ::= SEQUENCE {
- dscp DSCP,
- ecn BOOLEAN, -- TRUE Copy CE to inner header
- df DF,
- addresses TunnelAddresses }
-
- TunnelAddresses ::= CHOICE {
- ipv4 IPv4Pair,
- ipv6 [0] IPv6Pair }
-
- IPv4Pair ::= SEQUENCE {
- local OCTET STRING (SIZE(4)),
- remote OCTET STRING (SIZE(4)) }
-
-
-
-Kent & Seo Standards Track [Page 85]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- IPv6Pair ::= SEQUENCE {
- local OCTET STRING (SIZE(16)),
- remote OCTET STRING (SIZE(16)) }
-
- DSCP ::= SEQUENCE {
- copy BOOLEAN, -- TRUE copy from inner header
- -- FALSE do not copy
- mapping OCTET STRING OPTIONAL} -- points to table
- -- if no copy
-
- DF ::= INTEGER {
- clear (0),
- set (1),
- copy (2) }
-
- ProtocolChoice::= CHOICE {
- anyProt AnyProtocol, -- for ANY protocol
- noNext [0] NoNextLayerProtocol, -- has no next layer
- -- items
- oneNext [1] OneNextLayerProtocol, -- has one next layer
- -- item
- twoNext [2] TwoNextLayerProtocol, -- has two next layer
- -- items
- fragment FragmentNoNext } -- has no next layer
- -- info
-
- AnyProtocol ::= SEQUENCE {
- id INTEGER (0), -- ANY protocol
- nextLayer AnyNextLayers }
-
- AnyNextLayers ::= SEQUENCE { -- with either
- first AnyNextLayer, -- ANY next layer selector
- second AnyNextLayer } -- ANY next layer selector
-
- NoNextLayerProtocol ::= INTEGER (2..254)
-
- FragmentNoNext ::= INTEGER (44) -- Fragment identifier
-
- OneNextLayerProtocol ::= SEQUENCE {
- id INTEGER (1..254), -- ICMP, MH, ICMPv6
- nextLayer NextLayerChoice } -- ICMP Type*256+Code
- -- MH Type*256
-
- TwoNextLayerProtocol ::= SEQUENCE {
- id INTEGER (2..254), -- Protocol
- local NextLayerChoice, -- Local and
- remote NextLayerChoice } -- Remote ports
-
-
-
-
-Kent & Seo Standards Track [Page 86]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- NextLayerChoice ::= CHOICE {
- any AnyNextLayer,
- opaque [0] OpaqueNextLayer,
- range [1] NextLayerRange }
-
- -- Representation of ANY in next layer field
- AnyNextLayer ::= SEQUENCE {
- start INTEGER (0),
- end INTEGER (65535) }
-
- -- Representation of OPAQUE in next layer field.
- -- Matches IKE convention
- OpaqueNextLayer ::= SEQUENCE {
- start INTEGER (65535),
- end INTEGER (0) }
-
- -- Range for a next layer field
- NextLayerRange ::= SEQUENCE {
- start INTEGER (0..65535),
- end INTEGER (0..65535) }
-
- -- List of IP addresses
- AddrList ::= SEQUENCE {
- v4List IPv4List OPTIONAL,
- v6List [0] IPv6List OPTIONAL }
-
- -- IPv4 address representations
- IPv4List ::= SEQUENCE OF IPv4Range
-
- IPv4Range ::= SEQUENCE { -- close, but not quite right ...
- ipv4Start OCTET STRING (SIZE (4)),
- ipv4End OCTET STRING (SIZE (4)) }
-
- -- IPv6 address representations
- IPv6List ::= SEQUENCE OF IPv6Range
-
- IPv6Range ::= SEQUENCE { -- close, but not quite right ...
- ipv6Start OCTET STRING (SIZE (16)),
- ipv6End OCTET STRING (SIZE (16)) }
-
- END
-
-
-
-
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 87]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
-Appendix D: Fragment Handling Rationale
-
- There are three issues that must be resolved regarding processing of
- (plaintext) fragments in IPsec:
-
- - mapping a non-initial, outbound fragment to the right SA
- (or finding the right SPD entry)
- - verifying that a received, non-initial fragment is authorized
- for the SA via which it is received
- - mapping outbound and inbound non-initial fragments to the
- right SPD/cache entry, for BYPASS/DISCARD traffic
-
- The first and third issues arise because we need a deterministic
- algorithm for mapping traffic to SAs (and SPD/cache entries). All
- three issues are important because we want to make sure that
- non-initial fragments that cross the IPsec boundary do not cause the
- access control policies in place at the receiver (or transmitter) to
- be violated.
-
-D.1. Transport Mode and Fragments
-
- First, we note that transport mode SAs have been defined to not carry
- fragments. This is a carryover from RFC 2401, where transport mode
- SAs always terminated at endpoints. This is a fundamental
- requirement because, in the worst case, an IPv4 fragment to which
- IPsec was applied might then be fragmented (as a ciphertext packet),
- en route to the destination. IP fragment reassembly procedures at
- the IPsec receiver would not be able to distinguish between pre-IPsec
- fragments and fragments created after IPsec processing.
-
- For IPv6, only the sender is allowed to fragment a packet. As for
- IPv4, an IPsec implementation is allowed to fragment tunnel mode
- packets after IPsec processing, because it is the sender relative to
- the (outer) tunnel header. However, unlike IPv4, it would be
- feasible to carry a plaintext fragment on a transport mode SA,
- because the fragment header in IPv6 would appear after the AH or ESP
- header, and thus would not cause confusion at the receiver with
- respect to reassembly. Specifically, the receiver would not attempt
- reassembly for the fragment until after IPsec processing. To keep
- things simple, this specification prohibits carriage of fragments on
- transport mode SAs for IPv6 traffic.
-
- When only end systems used transport mode SAs, the prohibition on
- carriage of fragments was not a problem, since we assumed that the
- end system could be configured to not offer a fragment to IPsec. For
- a native host implementation, this seems reasonable, and, as someone
- already noted, RFC 2401 warned that a BITS implementation might have
- to reassemble fragments before performing an SA lookup. (It would
-
-
-
-Kent & Seo Standards Track [Page 88]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- then apply AH or ESP and could re-fragment the packet after IPsec
- processing.) Because a BITS implementation is assumed to be able to
- have access to all traffic emanating from its host, even if the host
- has multiple interfaces, this was deemed a reasonable mandate.
-
- In this specification, it is acceptable to use transport mode in
- cases where the IPsec implementation is not the ultimate destination,
- e.g., between two SGs. In principle, this creates a new opportunity
- for outbound, plaintext fragments to be mapped to a transport mode SA
- for IPsec processing. However, in these new contexts in which a
- transport mode SA is now approved for use, it seems likely that we
- can continue to prohibit transmission of fragments, as seen by IPsec,
- i.e., packets that have an "outer header" with a non-zero fragment
- offset field. For example, in an IP overlay network, packets being
- sent over transport mode SAs are IP-in-IP tunneled and thus have the
- necessary inner header to accommodate fragmentation prior to IPsec
- processing. When carried via a transport mode SA, IPsec would not
- examine the inner IP header for such traffic, and thus would not
- consider the packet to be a fragment.
-
-D.2. Tunnel Mode and Fragments
-
- For tunnel mode SAs, it has always been the case that outbound
- fragments might arrive for processing at an IPsec implementation.
- The need to accommodate fragmented outbound packets can pose a
- problem because a non-initial fragment generally will not contain the
- port fields associated with a next layer protocol such as TCP, UDP,
- or SCTP. Thus, depending on the SPD configuration for a given IPsec
- implementation, plaintext fragments might or might not pose a
- problem.
-
- For example, if the SPD requires that all traffic between two address
- ranges is offered IPsec protection (no BYPASS or DISCARD SPD entries
- apply to this address range), then it should be easy to carry
- non-initial fragments on the SA defined for this address range, since
- the SPD entry implies an intent to carry ALL traffic between the
- address ranges. But, if there are multiple SPD entries that could
- match a fragment, and if these entries reference different subsets of
- port fields (vs. ANY), then it is not possible to map an outbound
- non-initial fragment to the right entry, unambiguously. (If we choose
- to allow carriage of fragments on transport mode SAs for IPv6, the
- problems arises in that context as well.)
-
- This problem largely, though not exclusively, motivated the
- definition of OPAQUE as a selector value for port fields in RFC 2401.
- The other motivation for OPAQUE is the observation that port fields
- might not be accessible due to the prior application of IPsec. For
- example, if a host applied IPsec to its traffic and that traffic
-
-
-
-Kent & Seo Standards Track [Page 89]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- arrived at an SG, these fields would be encrypted. The algorithm
- specified for locating the "next layer protocol" described in RFC
- 2401 also motivated use of OPAQUE to accommodate an encrypted next
- layer protocol field in such circumstances. Nonetheless, the primary
- use of the OPAQUE value was to match traffic selector fields in
- packets that did not contain port fields (non-initial fragments), or
- packets in which the port fields were already encrypted (as a result
- of nested application of IPsec). RFC 2401 was ambiguous in
- discussing the use of OPAQUE vs. ANY, suggesting in some places that
- ANY might be an alternative to OPAQUE.
-
- We gain additional access control capability by defining both ANY and
- OPAQUE values. OPAQUE can be defined to match only fields that are
- not accessible. We could define ANY as the complement of OPAQUE,
- i.e., it would match all values but only for accessible port fields.
- We have therefore simplified the procedure employed to locate the
- next layer protocol in this document, so that we treat ESP and AH as
- next layer protocols. As a result, the notion of an encrypted next
- layer protocol field has vanished, and there is also no need to worry
- about encrypted port fields either. And accordingly, OPAQUE will be
- applicable only to non-initial fragments.
-
- Since we have adopted the definitions above for ANY and OPAQUE, we
- need to clarify how these values work when the specified protocol
- does not have port fields, and when ANY is used for the protocol
- selector. Accordingly, if a specific protocol value is used as a
- selector, and if that protocol has no port fields, then the port
- field selectors are to be ignored and ANY MUST be specified as the
- value for the port fields. (In this context, ICMP TYPE and CODE
- values are lumped together as a single port field (for IKEv2
- negotiation), as is the IPv6 Mobility Header TYPE value.) If the
- protocol selector is ANY, then this should be treated as equivalent
- to specifying a protocol for which no port fields are defined, and
- thus the port selectors should be ignored, and MUST be set to ANY.
-
-D.3. The Problem of Non-Initial Fragments
-
- For an SG implementation, it is obvious that fragments might arrive
- from end systems behind the SG. A BITW implementation also may
- encounter fragments from a host or gateway behind it. (As noted
- earlier, native host implementations and BITS implementations
- probably can avoid the problems described below.) In the worst case,
- fragments from a packet might arrive at distinct BITW or SG
- instantiations and thus preclude reassembly as a solution option.
- Hence, in RFC 2401 we adopted a general requirement that fragments
- must be accommodated in tunnel mode for all implementations. However,
-
-
-
-
-
-Kent & Seo Standards Track [Page 90]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- RFC 2401 did not provide a perfect solution. The use of OPAQUE as a
- selector value for port fields (a SHOULD in RFC 2401) allowed an SA
- to carry non-initial fragments.
-
- Using the features defined in RFC 2401, if one defined an SA between
- two IPsec (SG or BITW) implementations using the OPAQUE value for
- both port fields, then all non-initial fragments matching the
- source/destination (S/D) address and protocol values for the SA would
- be mapped to that SA. Initial fragments would NOT map to this SA, if
- we adopt a strict definition of OPAQUE. However, RFC 2401 did not
- provide detailed guidance on this and thus it may not have been
- apparent that use of this feature would essentially create a
- "non-initial fragment only" SA.
-
- In the course of discussing the "fragment-only" SA approach, it was
- noted that some subtle problems, problems not considered in RFC 2401,
- would have to be avoided. For example, an SA of this sort must be
- configured to offer the "highest quality" security services for any
- traffic between the indicated S/D addresses (for the specified
- protocol). This is necessary to ensure that any traffic captured by
- the fragment-only SA is not offered degraded security relative to
- what it would have been offered if the packet were not fragmented. A
- possible problem here is that we may not be able to identify the
- "highest quality" security services defined for use between two IPsec
- implementation, since the choice of security protocols, options, and
- algorithms is a lattice, not a totally ordered set. (We might safely
- say that BYPASS < AH < ESP w/integrity, but it gets complicated if we
- have multiple ESP encryption or integrity algorithm options.) So, one
- has to impose a total ordering on these security parameters to make
- this work, but this can be done locally.
-
- However, this conservative strategy has a possible performance
- downside. If most traffic traversing an IPsec implementation for a
- given S/D address pair (and specified protocol) is bypassed, then a
- fragment-only SA for that address pair might cause a dramatic
- increase in the volume of traffic afforded crypto processing. If the
- crypto implementation cannot support high traffic rates, this could
- cause problems. (An IPsec implementation that is capable of line rate
- or near line rate crypto performance would not be adversely affected
- by this SA configuration approach. Nonetheless, the performance
- impact is a potential concern, specific to implementation
- capabilities.)
-
- Another concern is that non-initial fragments sent over a dedicated
- SA might be used to effect overlapping reassembly attacks, when
- combined with an apparently acceptable initial fragment. (This sort
- of attack assumes creation of bogus fragments and is not a side
- effect of normal fragmentation.) This concern is easily addressed in
-
-
-
-Kent & Seo Standards Track [Page 91]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- IPv4, by checking the fragment offset value to ensure that no
- non-initial fragments have a small enough offset to overlap port
- fields that should be contained in the initial fragment. Recall that
- the IPv4 MTU minimum is 576 bytes, and the max IP header length is 60
- bytes, so any ports should be present in the initial fragment. If we
- require all non-initial fragments to have an offset of, say, 128 or
- greater, just to be on the safe side, this should prevent successful
- attacks of this sort. If the intent is only to protect against this
- sort of reassembly attack, this check need be implemented only by a
- receiver.
-
- IPv6 also has a fragment offset, carried in the fragmentation
- extension header. However, IPv6 extension headers are variable in
- length and there is no analogous max header length value that we can
- use to check non-initial fragments, to reject ones that might be used
- for an attack of the sort noted above. A receiver would need to
- maintain state analogous to reassembly state, to provide equivalent
- protection. So, only for IPv4 is it feasible to impose a fragment
- offset check that would reject attacks designed to circumvent port
- field checks by IPsec (or firewalls) when passing non-initial
- fragments.
-
- Another possible concern is that in some topologies and SPD
- configurations this approach might result in an access control
- surprise. The notion is that if we create an SA to carry ALL
- (non-initial) fragments, then that SA would carry some traffic that
- might otherwise arrive as plaintext via a separate path, e.g., a path
- monitored by a proxy firewall. But, this concern arises only if the
- other path allows initial fragments to traverse it without requiring
- reassembly, presumably a bad idea for a proxy firewall. Nonetheless,
- this does represent a potential problem in some topologies and under
- certain assumptions with respect to SPD and (other) firewall rule
- sets, and administrators need to be warned of this possibility.
-
- A less serious concern is that non-initial fragments sent over a
- non-initial fragment-only SA might represent a DoS opportunity, in
- that they could be sent when no valid, initial fragment will ever
- arrive. This might be used to attack hosts behind an SG or BITW
- device. However, the incremental risk posed by this sort of attack,
- which can be mounted only by hosts behind an SG or BITW device, seems
- small.
-
- If we interpret the ANY selector value as encompassing OPAQUE, then a
- single SA with ANY values for both port fields would be able to
- accommodate all traffic matching the S/D address and protocol traffic
- selectors, an alternative to using the OPAQUE value. But, using ANY
-
-
-
-
-
-Kent & Seo Standards Track [Page 92]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- here precludes multiple, distinct SAs between the same IPsec
- implementations for the same address pairs and protocol. So, it is
- not an exactly equivalent alternative.
-
- Fundamentally, fragment handling problems arise only when more than
- one SA is defined with the same S/D address and protocol selector
- values, but with different port field selector values.
-
-D.4. BYPASS/DISCARD Traffic
-
- We also have to address the non-initial fragment processing issue for
- BYPASS/DISCARD entries, independent of SA processing. This is
- largely a local matter for two reasons:
-
- 1) We have no means for coordinating SPD entries for such
- traffic between IPsec implementations since IKE is not
- invoked.
- 2) Many of these entries refer to traffic that is NOT
- directed to or received from a location that is using
- IPsec. So there is no peer IPsec implementation with
- which to coordinate via any means.
-
- However, this document should provide guidance here, consistent with
- our goal of offering a well-defined, access control function for all
- traffic, relative to the IPsec boundary. To that end, this document
- says that implementations MUST support fragment reassembly for
- BYPASS/DISCARD traffic when port fields are specified. An
- implementation also MUST permit a user or administrator to accept
- such traffic or reject such traffic using the SPD conventions
- described in Section 4.4.1. The concern is that BYPASS of a
- cleartext, non-initial fragment arriving at an IPsec implementation
- could undermine the security afforded IPsec-protected traffic
- directed to the same destination. For example, consider an IPsec
- implementation configured with an SPD entry that calls for
- IPsec-protection of traffic between a specific source/destination
- address pair, and for a specific protocol and destination port, e.g.,
- TCP traffic on port 23 (Telnet). Assume that the implementation also
- allows BYPASS of traffic from the same source/destination address
- pair and protocol, but for a different destination port, e.g., port
- 119 (NNTP). An attacker could send a non-initial fragment (with a
- forged source address) that, if bypassed, could overlap with
- IPsec-protected traffic from the same source and thus violate the
- integrity of the IPsec-protected traffic. Requiring stateful
- fragment checking for BYPASS entries with non-trivial port ranges
- prevents attacks of this sort.
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 93]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
-D.5. Just say no to ports?
-
- It has been suggested that we could avoid the problems described
- above by not allowing port field selectors to be used in tunnel mode.
- But the discussion above shows this to be an unnecessarily stringent
- approach, i.e., since no problems arise for the native OS and BITS
- implementations. Moreover, some WG members have described scenarios
- where use of tunnel mode SAs with (non-trivial) port field selectors
- is appropriate. So the challenge is defining a strategy that can
- deal with this problem in BITW and SG contexts. Also note that
- BYPASS/DISCARD entries in the SPD that make use of ports pose the
- same problems, irrespective of tunnel vs. transport mode notions.
-
- Some folks have suggested that a firewall behind an SG or BITW should
- be left to enforce port-level access controls and the effects of
- fragmentation. However, this seems to be an incongruous suggestion
- in that elsewhere in IPsec (e.g., in IKE payloads) we are concerned
- about firewalls that always discard fragments. If many firewalls
- don't pass fragments in general, why should we expect them to deal
- with fragments in this case? So, this analysis rejects the suggestion
- of disallowing use of port field selectors with tunnel mode SAs.
-
-D.6. Other Suggested Solutions
-
- One suggestion is to reassemble fragments at the sending IPsec
- implementation, and thus avoid the problem entirely. This approach
- is invisible to a receiver and thus could be adopted as a purely
- local implementation option.
-
- A more sophisticated version of this suggestion calls for
- establishing and maintaining minimal state from each initial fragment
- encountered, to allow non-initial fragments to be matched to the
- right SAs or SPD/cache entries. This implies an extension to the
- current processing model (and the old one). The IPsec implementation
- would intercept all fragments; capture Source/Destination IP
- addresses, protocol, packet ID, and port fields from initial
- fragments; and then use this data to map non-initial fragments to SAs
- that require port fields. If this approach is employed, the receiver
- needs to employ an equivalent scheme, as it too must verify that
- received fragments are consistent with SA selector values. A
- non-initial fragment that arrives prior to an initial fragment could
- be cached or discarded, awaiting arrival of the corresponding initial
- fragment.
-
- A downside of both approaches noted above is that they will not
- always work. When a BITW device or SG is configured in a topology
- that might allow some fragments for a packet to be processed at
- different SGs or BITW devices, then there is no guarantee that all
-
-
-
-Kent & Seo Standards Track [Page 94]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- fragments will ever arrive at the same IPsec device. This approach
- also raises possible processing problems. If the sender caches
- non-initial fragments until the corresponding initial fragment
- arrives, buffering problems might arise, especially at high speeds.
- If the non-initial fragments are discarded rather than cached, there
- is no guarantee that traffic will ever pass, e.g., retransmission
- will result in different packet IDs that cannot be matched with prior
- transmissions. In any case, housekeeping procedures will be needed
- to decide when to delete the fragment state data, adding some
- complexity to the system. Nonetheless, this is a viable solution in
- some topologies, and these are likely to be common topologies.
-
- The Working Group rejected an earlier version of the convention of
- creating an SA to carry only non-initial fragments, something that
- was supported implicitly under the RFC 2401 model via use of OPAQUE
- port fields, but never clearly articulated in RFC 2401. The
- (rejected) text called for each non-initial fragment to be treated as
- protocol 44 (the IPv6 fragment header protocol ID) by the sender and
- receiver. This approach has the potential to make IPv4 and IPv6
- fragment handling more uniform, but it does not fundamentally change
- the problem, nor does it address the issue of fragment handling for
- BYPASS/DISCARD traffic. Given the fragment overlap attack problem
- that IPv6 poses, it does not seem that it is worth the effort to
- adopt this strategy.
-
-D.7. Consistency
-
- Earlier, the WG agreed to allow an IPsec BITS, BITW, or SG to perform
- fragmentation prior to IPsec processing. If this fragmentation is
- performed after SA lookup at the sender, there is no "mapping to the
- right SA" problem. But, the receiver still needs to be able to
- verify that the non-initial fragments are consistent with the SA via
- which they are received. Since the initial fragment might be lost en
- route, the receiver encounters all of the potential problems noted
- above. Thus, if we are to be consistent in our decisions, we need to
- say how a receiver will deal with the non-initial fragments that
- arrive.
-
-D.8. Conclusions
-
- There is no simple, uniform way to handle fragments in all contexts.
- Different approaches work better in different contexts. Thus, this
- document offers 3 choices -- one MUST and two MAYs. At some point in
- the future, if the community gains experience with the two MAYs, they
- may become SHOULDs or MUSTs or other approaches may be proposed.
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 95]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
-Appendix E: Example of Supporting Nested SAs via SPD and Forwarding
- Table Entries
-
- This appendix provides an example of how to configure the SPD and
- forwarding tables to support a nested pair of SAs, consistent with
- the new processing model. For simplicity, this example assumes just
- one SPD-I.
-
- The goal in this example is to support a transport mode SA from A to
- C, carried over a tunnel mode SA from A to B. For example, A might
- be a laptop connected to the public Internet, B might be a firewall
- that protects a corporate network, and C might be a server on the
- corporate network that demands end-to-end authentication of A's
- traffic.
-
- +---+ +---+ +---+
- | A |=====| B | | C |
- | |------------| |
- | |=====| | | |
- +---+ +---+ +---+
-
- A's SPD contains entries of the form:
-
- Next Layer
- Rule Local Remote Protocol Action
- ---- ----- ------ ---------- -----------------------
- 1 C A ESP BYPASS
- 2 A C ICMP,ESP PROTECT(ESP,tunnel,integr+conf)
- 3 A C ANY PROTECT(ESP,transport,integr-only)
- 4 A B ICMP,IKE BYPASS
-
- A's unprotected-side forwarding table is set so that outbound packets
- destined for C are looped back to the protected side. A's
- protected-side forwarding table is set so that inbound ESP packets
- are looped back to the unprotected side. A's forwarding tables
- contain entries of the form:
-
- Unprotected-side forwarding table
-
- Rule Local Remote Protocol Action
- ---- ----- ------ -------- ---------------------------
- 1 A C ANY loop back to protected side
- 2 A B ANY forward to B
-
-
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 96]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- Protected-side forwarding table
-
- Rule Local Remote Protocol Action
- ---- ----- ------ -------- -----------------------------
- 1 A C ESP loop back to unprotected side
-
- An outbound TCP packet from A to C would match SPD rule 3 and have
- transport mode ESP applied to it. The unprotected-side forwarding
- table would then loop back the packet. The packet is compared
- against SPD-I (see Figure 2), matches SPD rule 1, and so it is
- BYPASSed. The packet is treated as an outbound packet and compared
- against the SPD for a third time. This time it matches SPD rule 2,
- so ESP is applied in tunnel mode. This time the forwarding table
- doesn't loop back the packet, because the outer destination address
- is B, so the packet goes out onto the wire.
-
- An inbound TCP packet from C to A is wrapped in two ESP headers; the
- outer header (ESP in tunnel mode) shows B as the source, whereas the
- inner header (ESP transport mode) shows C as the source. Upon
- arrival at A, the packet would be mapped to an SA based on the SPI,
- have the outer header removed, and be decrypted and
- integrity-checked. Then it would be matched against the SAD
- selectors for this SA, which would specify C as the source and A as
- the destination, derived from SPD rule 2. The protected-side
- forwarding function would then send it back to the unprotected side
- based on the addresses and the next layer protocol (ESP), indicative
- of nesting. It is compared against SPD-O (see Figure 3) and found to
- match SPD rule 1, so it is BYPASSed. The packet is mapped to an SA
- based on the SPI, integrity-checked, and compared against the SAD
- selectors derived from SPD rule 3. The forwarding function then
- passes it up to the next layer, because it isn't an ESP packet.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 97]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
-References
-
-Normative References
-
- [BBCDWW98] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
- Z., and W. Weiss, "An Architecture for Differentiated
- Service", RFC 2475, December 1998.
-
- [Bra97] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Level", BCP 14, RFC 2119, March 1997.
-
- [CD98] Conta, A. and S. Deering, "Internet Control Message
- Protocol (ICMPv6) for the Internet Protocol Version 6
- (IPv6) Specification", RFC 2463, December 1998.
-
- [DH98] Deering, S., and R. Hinden, "Internet Protocol,
- Version 6 (IPv6) Specification", RFC 2460, December
- 1998.
-
- [Eas05] 3rd Eastlake, D., "Cryptographic Algorithm
- Implementation Requirements For Encapsulating Security
- Payload (ESP) and Authentication Header (AH)", RFC
- 4305, December 2005.
-
- [HarCar98] Harkins, D. and D. Carrel, "The Internet Key Exchange
- (IKE)", RFC 2409, November 1998.
-
- [Kau05] Kaufman, C., Ed., "The Internet Key Exchange (IKEv2)
- Protocol", RFC 4306, December 2005.
-
- [Ken05a] Kent, S., "IP Encapsulating Security Payload (ESP)",
- RFC 4303, December 2005.
-
- [Ken05b] Kent, S., "IP Authentication Header", RFC 4302,
- December 2005.
-
- [MD90] Mogul, J. and S. Deering, "Path MTU discovery", RFC
- 1191, November 1990.
-
- [Mobip] Johnson, D., Perkins, C., and J. Arkko, "Mobility
- Support in IPv6", RFC 3775, June 2004.
-
- [Pos81a] Postel, J., "Internet Protocol", STD 5, RFC 791,
- September 1981.
-
- [Pos81b] Postel, J., "Internet Control Message Protocol", RFC
- 792, September 1981.
-
-
-
-
-Kent & Seo Standards Track [Page 98]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- [Sch05] Schiller, J., "Cryptographic Algorithms for use in the
- Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
- December 2005.
-
- [WaKiHo97] Wahl, M., Kille, S., and T. Howes, "Lightweight
- Directory Access Protocol (v3): UTF-8 String
- Representation of Distinguished Names", RFC 2253,
- December 1997.
-
-Informative References
-
- [CoSa04] Condell, M., and L. Sanchez, "On the Deterministic
- Enforcement of Un-ordered Security Policies", BBN
- Technical Memo 1346, March 2004.
-
- [FaLiHaMeTr00] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
- Traina, "Generic Routing Encapsulation (GRE)", RFC
- 2784, March 2000.
-
- [Gro02] Grossman, D., "New Terminology and Clarifications for
- Diffserv", RFC 3260, April 2002.
- [HC03] Holbrook, H. and B. Cain, "Source Specific Multicast
- for IP", Work in Progress, November 3, 2002.
-
- [HA94] Haller, N. and R. Atkinson, "On Internet
- Authentication", RFC 1704, October 1994.
-
- [NiBlBaBL98] Nichols, K., Blake, S., Baker, F., and D. Black,
- "Definition of the Differentiated Services Field (DS
- Field) in the IPv4 and IPv6 Headers", RFC 2474,
- December 1998.
-
- [Per96] Perkins, C., "IP Encapsulation within IP", RFC 2003,
- October 1996.
-
- [RaFlBl01] Ramakrishnan, K., Floyd, S., and D. Black, "The
- Addition of Explicit Congestion Notification (ECN) to
- IP", RFC 3168, September 2001.
-
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
- the Internet Protocol", RFC 2401, November 1998.
-
- [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
- 2983, October 2000.
-
- [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney,
- "The Group Domain of Interpretation", RFC 3547, July
- 2003.
-
-
-
-Kent & Seo Standards Track [Page 99]
-\f
-RFC 4301 Security Architecture for IP December 2005
-
-
- [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group
- Security Architecture", RFC 3740, March 2004.
-
- [RaCoCaDe04] Rajahalme, J., Conta, A., Carpenter, B., and S.
- Deering, "IPv6 Flow Label Specification", RFC 3697,
- March 2004.
-
- [Sch94] Schneier, B., Applied Cryptography, Section 8.6, John
- Wiley & Sons, New York, NY, 1994.
-
- [Shi00] Shirey, R., "Internet Security Glossary", RFC 2828,
- May 2000.
-
- [SMPT01] Shacham, A., Monsour, B., Pereira, R., and M. Thomas,
- "IP Payload Compression Protocol (IPComp)", RFC 3173,
- September 2001.
-
- [ToEgWa04] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
- Transport Mode for Dynamic Routing", RFC 3884,
- September 2004.
-
- [VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in
- High-level Networks", ACM Computing Surveys, Vol. 15,
- No. 2, June 1983.
-
-Authors' Addresses
-
- Stephen Kent
- BBN Technologies
- 10 Moulton Street
- Cambridge, MA 02138
- USA
-
- Phone: +1 (617) 873-3988
- EMail: kent@bbn.com
-
-
- Karen Seo
- BBN Technologies
- 10 Moulton Street
- Cambridge, MA 02138
- USA
-
- Phone: +1 (617) 873-3152
- EMail: kseo@bbn.com
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 100]
-\f
-RFC 4301 Security Architecture for IP 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.
-
-
-
-
-
-
-
-Kent & Seo Standards Track [Page 101]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group C. Kaufman, Ed.
-Request for Comments: 4306 Microsoft
-Obsoletes: 2407, 2408, 2409 December 2005
-Category: Standards Track
-
-
- Internet Key Exchange (IKEv2) Protocol
-
-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
-
- This document describes version 2 of the Internet Key Exchange (IKE)
- protocol. IKE is a component of IPsec used for performing mutual
- authentication and establishing and maintaining security associations
- (SAs).
-
- This version of the IKE specification combines the contents of what
- were previously separate documents, including Internet Security
- Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC
- 2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network
- Address Translation (NAT) Traversal, Legacy authentication, and
- remote address acquisition.
-
- Version 2 of IKE does not interoperate with version 1, but it has
- enough of the header format in common that both versions can
- unambiguously run over the same UDP port.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 1]
-\f
-RFC 4306 IKEv2 December 2005
-
-
-Table of Contents
-
- 1. Introduction ....................................................3
- 1.1. Usage Scenarios ............................................5
- 1.2. The Initial Exchanges ......................................7
- 1.3. The CREATE_CHILD_SA Exchange ...............................9
- 1.4. The INFORMATIONAL Exchange ................................11
- 1.5. Informational Messages outside of an IKE_SA ...............12
- 2. IKE Protocol Details and Variations ............................12
- 2.1. Use of Retransmission Timers ..............................13
- 2.2. Use of Sequence Numbers for Message ID ....................14
- 2.3. Window Size for Overlapping Requests ......................14
- 2.4. State Synchronization and Connection Timeouts .............15
- 2.5. Version Numbers and Forward Compatibility .................17
- 2.6. Cookies ...................................................18
- 2.7. Cryptographic Algorithm Negotiation .......................21
- 2.8. Rekeying ..................................................22
- 2.9. Traffic Selector Negotiation ..............................24
- 2.10. Nonces ...................................................26
- 2.11. Address and Port Agility .................................26
- 2.12. Reuse of Diffie-Hellman Exponentials .....................27
- 2.13. Generating Keying Material ...............................27
- 2.14. Generating Keying Material for the IKE_SA ................28
- 2.15. Authentication of the IKE_SA .............................29
- 2.16. Extensible Authentication Protocol Methods ...............31
- 2.17. Generating Keying Material for CHILD_SAs .................33
- 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA exchange ........34
- 2.19. Requesting an Internal Address on a Remote Network .......34
- 2.20. Requesting the Peer's Version ............................35
- 2.21. Error Handling ...........................................36
- 2.22. IPComp ...................................................37
- 2.23. NAT Traversal ............................................38
- 2.24. Explicit Congestion Notification (ECN) ...................40
- 3. Header and Payload Formats .....................................41
- 3.1. The IKE Header ............................................41
- 3.2. Generic Payload Header ....................................44
- 3.3. Security Association Payload ..............................46
- 3.4. Key Exchange Payload ......................................56
- 3.5. Identification Payloads ...................................56
- 3.6. Certificate Payload .......................................59
- 3.7. Certificate Request Payload ...............................61
- 3.8. Authentication Payload ....................................63
- 3.9. Nonce Payload .............................................64
- 3.10. Notify Payload ...........................................64
- 3.11. Delete Payload ...........................................72
- 3.12. Vendor ID Payload ........................................73
- 3.13. Traffic Selector Payload .................................74
- 3.14. Encrypted Payload ........................................77
-
-
-
-Kaufman Standards Track [Page 2]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- 3.15. Configuration Payload ....................................79
- 3.16. Extensible Authentication Protocol (EAP) Payload .........84
- 4. Conformance Requirements .......................................85
- 5. Security Considerations ........................................88
- 6. IANA Considerations ............................................90
- 7. Acknowledgements ...............................................91
- 8. References .....................................................91
- 8.1. Normative References ......................................91
- 8.2. Informative References ....................................92
- Appendix A: Summary of Changes from IKEv1 .........................96
- Appendix B: Diffie-Hellman Groups .................................97
- B.1. Group 1 - 768 Bit MODP ....................................97
- B.2. Group 2 - 1024 Bit MODP ...................................97
-
-1. Introduction
-
- IP Security (IPsec) provides confidentiality, data integrity, access
- control, and data source authentication to IP datagrams. These
- services are provided by maintaining shared state between the source
- and the sink of an IP datagram. This state defines, among other
- things, the specific services provided to the datagram, which
- cryptographic algorithms will be used to provide the services, and
- the keys used as input to the cryptographic algorithms.
-
- Establishing this shared state in a manual fashion does not scale
- well. Therefore, a protocol to establish this state dynamically is
- needed. This memo describes such a protocol -- the Internet Key
- Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was
- defined in RFCs 2407, 2408, and 2409 [Pip98, MSST98, HC98]. This
- single document is intended to replace all three of those RFCs.
-
- Definitions of the primitive terms in this document (such as Security
- Association or SA) can be found in [RFC4301].
-
- Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
- "MAY" that appear in this document are to be interpreted as described
- in [Bra97].
-
- The term "Expert Review" is to be interpreted as defined in
- [RFC2434].
-
- IKE performs mutual authentication between two parties and
- establishes an IKE security association (SA) that includes shared
- secret information that can be used to efficiently establish SAs for
- Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication
- Header (AH) [RFC4302] and a set of cryptographic algorithms to be
- used by the SAs to protect the traffic that they carry. In this
- document, the term "suite" or "cryptographic suite" refers to a
-
-
-
-Kaufman Standards Track [Page 3]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- complete set of algorithms used to protect an SA. An initiator
- proposes one or more suites by listing supported algorithms that can
- be combined into suites in a mix-and-match fashion. IKE can also
- negotiate use of IP Compression (IPComp) [IPCOMP] in connection with
- an ESP and/or AH SA. We call the IKE SA an "IKE_SA". The SAs for
- ESP and/or AH that get set up through that IKE_SA we call
- "CHILD_SAs".
-
- All IKE communications consist of pairs of messages: a request and a
- response. The pair is called an "exchange". We call the first
- messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges
- and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL
- exchanges. In the common case, there is a single IKE_SA_INIT
- exchange and a single IKE_AUTH exchange (a total of four messages) to
- establish the IKE_SA and the first CHILD_SA. In exceptional cases,
- there may be more than one of each of these exchanges. In all cases,
- all IKE_SA_INIT exchanges MUST complete before any other exchange
- type, then all IKE_AUTH exchanges MUST complete, and following that
- any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur
- in any order. In some scenarios, only a single CHILD_SA is needed
- between the IPsec endpoints, and therefore there would be no
- additional exchanges. Subsequent exchanges MAY be used to establish
- additional CHILD_SAs between the same authenticated pair of endpoints
- and to perform housekeeping functions.
-
- IKE message flow always consists of a request followed by a response.
- It is the responsibility of the requester to ensure reliability. If
- the response is not received within a timeout interval, the requester
- needs to retransmit the request (or abandon the connection).
-
- The first request/response of an IKE session (IKE_SA_INIT) negotiates
- security parameters for the IKE_SA, sends nonces, and sends Diffie-
- Hellman values.
-
- The second request/response (IKE_AUTH) transmits identities, proves
- knowledge of the secrets corresponding to the two identities, and
- sets up an SA for the first (and often only) AH and/or ESP CHILD_SA.
-
- The types of subsequent exchanges are CREATE_CHILD_SA (which creates
- a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error
- conditions, or does other housekeeping). Every request requires a
- response. An INFORMATIONAL request with no payloads (other than the
- empty Encrypted payload required by the syntax) is commonly used as a
- check for liveness. These subsequent exchanges cannot be used until
- the initial exchanges have completed.
-
-
-
-
-
-
-Kaufman Standards Track [Page 4]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- In the description that follows, we assume that no errors occur.
- Modifications to the flow should errors occur are described in
- section 2.21.
-
-1.1. Usage Scenarios
-
- IKE is expected to be used to negotiate ESP and/or AH SAs in a number
- of different scenarios, each with its own special requirements.
-
-1.1.1. Security Gateway to Security Gateway Tunnel
-
- +-+-+-+-+-+ +-+-+-+-+-+
- ! ! IPsec ! !
- Protected !Tunnel ! tunnel !Tunnel ! Protected
- Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet
- ! ! ! !
- +-+-+-+-+-+ +-+-+-+-+-+
-
- Figure 1: Security Gateway to Security Gateway Tunnel
-
- In this scenario, neither endpoint of the IP connection implements
- IPsec, but network nodes between them protect traffic for part of the
- way. Protection is transparent to the endpoints, and depends on
- ordinary routing to send packets through the tunnel endpoints for
- processing. Each endpoint would announce the set of addresses
- "behind" it, and packets would be sent in tunnel mode where the inner
- IP header would contain the IP addresses of the actual endpoints.
-
-1.1.2. Endpoint-to-Endpoint Transport
-
- +-+-+-+-+-+ +-+-+-+-+-+
- ! ! IPsec transport ! !
- !Protected! or tunnel mode SA !Protected!
- !Endpoint !<---------------------------------------->!Endpoint !
- ! ! ! !
- +-+-+-+-+-+ +-+-+-+-+-+
-
- Figure 2: Endpoint to Endpoint
-
- In this scenario, both endpoints of the IP connection implement
- IPsec, as required of hosts in [RFC4301]. Transport mode will
- commonly be used with no inner IP header. If there is an inner IP
- header, the inner addresses will be the same as the outer addresses.
- A single pair of addresses will be negotiated for packets to be
- protected by this SA. These endpoints MAY implement application
- layer access controls based on the IPsec authenticated identities of
- the participants. This scenario enables the end-to-end security that
- has been a guiding principle for the Internet since [RFC1958],
-
-
-
-Kaufman Standards Track [Page 5]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- [RFC2775], and a method of limiting the inherent problems with
- complexity in networks noted by [RFC3439]. Although this scenario
- may not be fully applicable to the IPv4 Internet, it has been
- deployed successfully in specific scenarios within intranets using
- IKEv1. It should be more broadly enabled during the transition to
- IPv6 and with the adoption of IKEv2.
-
- It is possible in this scenario that one or both of the protected
- endpoints will be behind a network address translation (NAT) node, in
- which case the tunneled packets will have to be UDP encapsulated so
- that port numbers in the UDP headers can be used to identify
- individual endpoints "behind" the NAT (see section 2.23).
-
-1.1.3. Endpoint to Security Gateway Tunnel
-
- +-+-+-+-+-+ +-+-+-+-+-+
- ! ! IPsec ! ! Protected
- !Protected! tunnel !Tunnel ! Subnet
- !Endpoint !<------------------------>!Endpoint !<--- and/or
- ! ! ! ! Internet
- +-+-+-+-+-+ +-+-+-+-+-+
-
- Figure 3: Endpoint to Security Gateway Tunnel
-
- In this scenario, a protected endpoint (typically a portable roaming
- computer) connects back to its corporate network through an IPsec-
- protected tunnel. It might use this tunnel only to access
- information on the corporate network, or it might tunnel all of its
- traffic back through the corporate network in order to take advantage
- of protection provided by a corporate firewall against Internet-based
- attacks. In either case, the protected endpoint will want an IP
- address associated with the security gateway so that packets returned
- to it will go to the security gateway and be tunneled back. This IP
- address may be static or may be dynamically allocated by the security
- gateway. In support of the latter case, IKEv2 includes a mechanism
- for the initiator to request an IP address owned by the security
- gateway for use for the duration of its SA.
-
- In this scenario, packets will use tunnel mode. On each packet from
- the protected endpoint, the outer IP header will contain the source
- IP address associated with its current location (i.e., the address
- that will get traffic routed to the endpoint directly), while the
- inner IP header will contain the source IP address assigned by the
- security gateway (i.e., the address that will get traffic routed to
- the security gateway for forwarding to the endpoint). The outer
- destination address will always be that of the security gateway,
- while the inner destination address will be the ultimate destination
- for the packet.
-
-
-
-Kaufman Standards Track [Page 6]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- In this scenario, it is possible that the protected endpoint will be
- behind a NAT. In that case, the IP address as seen by the security
- gateway will not be the same as the IP address sent by the protected
- endpoint, and packets will have to be UDP encapsulated in order to be
- routed properly.
-
-1.1.4. Other Scenarios
-
- Other scenarios are possible, as are nested combinations of the
- above. One notable example combines aspects of 1.1.1 and 1.1.3. A
- subnet may make all external accesses through a remote security
- gateway using an IPsec tunnel, where the addresses on the subnet are
- routed to the security gateway by the rest of the Internet. An
- example would be someone's home network being virtually on the
- Internet with static IP addresses even though connectivity is
- provided by an ISP that assigns a single dynamically assigned IP
- address to the user's security gateway (where the static IP addresses
- and an IPsec relay are provided by a third party located elsewhere).
-
-1.2. The Initial Exchanges
-
- Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
- exchanges (known in IKEv1 as Phase 1). These initial exchanges
- normally consist of four messages, though in some scenarios that
- number can grow. All communications using IKE consist of
- request/response pairs. We'll describe the base exchange first,
- followed by variations. The first pair of messages (IKE_SA_INIT)
- negotiate cryptographic algorithms, exchange nonces, and do a
- Diffie-Hellman exchange [DH].
-
- The second pair of messages (IKE_AUTH) authenticate the previous
- messages, exchange identities and certificates, and establish the
- first CHILD_SA. Parts of these messages are encrypted and integrity
- protected with keys established through the IKE_SA_INIT exchange, so
- the identities are hidden from eavesdroppers and all fields in all
- the messages are authenticated.
-
- In the following descriptions, the payloads contained in the message
- are indicated by names as listed below.
-
- Notation Payload
-
- AUTH Authentication
- CERT Certificate
- CERTREQ Certificate Request
- CP Configuration
- D Delete
- E Encrypted
-
-
-
-Kaufman Standards Track [Page 7]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- EAP Extensible Authentication
- HDR IKE Header
- IDi Identification - Initiator
- IDr Identification - Responder
- KE Key Exchange
- Ni, Nr Nonce
- N Notify
- SA Security Association
- TSi Traffic Selector - Initiator
- TSr Traffic Selector - Responder
- V Vendor ID
-
- The details of the contents of each payload are described in section
- 3. Payloads that may optionally appear will be shown in brackets,
- such as [CERTREQ], indicate that optionally a certificate request
- payload can be included.
-
- The initial exchanges are as follows:
-
- Initiator Responder
- ----------- -----------
- HDR, SAi1, KEi, Ni -->
-
- HDR contains the Security Parameter Indexes (SPIs), version numbers,
- and flags of various sorts. The SAi1 payload states the
- cryptographic algorithms the initiator supports for the IKE_SA. The
- KE payload sends the initiator's Diffie-Hellman value. Ni is the
- initiator's nonce.
-
- <-- HDR, SAr1, KEr, Nr, [CERTREQ]
-
- The responder chooses a cryptographic suite from the initiator's
- offered choices and expresses that choice in the SAr1 payload,
- completes the Diffie-Hellman exchange with the KEr payload, and sends
- its nonce in the Nr payload.
-
- At this point in the negotiation, each party can generate SKEYSEED,
- from which all keys are derived for that IKE_SA. All but the headers
- of all the messages that follow are encrypted and integrity
- protected. The keys used for the encryption and integrity protection
- are derived from SKEYSEED and are known as SK_e (encryption) and SK_a
- (authentication, a.k.a. integrity protection). A separate SK_e and
- SK_a is computed for each direction. In addition to the keys SK_e
- and SK_a derived from the DH value for protection of the IKE_SA,
- another quantity SK_d is derived and used for derivation of further
- keying material for CHILD_SAs. The notation SK { ... } indicates
- that these payloads are encrypted and integrity protected using that
- direction's SK_e and SK_a.
-
-
-
-Kaufman Standards Track [Page 8]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
- AUTH, SAi2, TSi, TSr} -->
-
- The initiator asserts its identity with the IDi payload, proves
- knowledge of the secret corresponding to IDi and integrity protects
- the contents of the first message using the AUTH payload (see section
- 2.15). It might also send its certificate(s) in CERT payload(s) and
- a list of its trust anchors in CERTREQ payload(s). If any CERT
- payloads are included, the first certificate provided MUST contain
- the public key used to verify the AUTH field. The optional payload
- IDr enables the initiator to specify which of the responder's
- identities it wants to talk to. This is useful when the machine on
- which the responder is running is hosting multiple identities at the
- same IP address. The initiator begins negotiation of a CHILD_SA
- using the SAi2 payload. The final fields (starting with SAi2) are
- described in the description of the CREATE_CHILD_SA exchange.
-
- <-- HDR, SK {IDr, [CERT,] AUTH,
- SAr2, TSi, TSr}
-
- The responder asserts its identity with the IDr payload, optionally
- sends one or more certificates (again with the certificate containing
- the public key used to verify AUTH listed first), authenticates its
- identity and protects the integrity of the second message with the
- AUTH payload, and completes negotiation of a CHILD_SA with the
- additional fields described below in the CREATE_CHILD_SA exchange.
-
- The recipients of messages 3 and 4 MUST verify that all signatures
- and MACs are computed correctly and that the names in the ID payloads
- correspond to the keys used to generate the AUTH payload.
-
-1.3. The CREATE_CHILD_SA Exchange
-
- This exchange consists of a single request/response pair, and was
- referred to as a phase 2 exchange in IKEv1. It MAY be initiated by
- either end of the IKE_SA after the initial exchanges are completed.
-
- All messages following the initial exchange are cryptographically
- protected using the cryptographic algorithms and keys negotiated in
- the first two messages of the IKE exchange. These subsequent
- messages use the syntax of the Encrypted Payload described in section
- 3.14. All subsequent messages included an Encrypted Payload, even if
- they are referred to in the text as "empty".
-
- Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
- section the term "initiator" refers to the endpoint initiating this
- exchange.
-
-
-
-
-Kaufman Standards Track [Page 9]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- A CHILD_SA is created by sending a CREATE_CHILD_SA request. The
- CREATE_CHILD_SA request MAY optionally contain a KE payload for an
- additional Diffie-Hellman exchange to enable stronger guarantees of
- forward secrecy for the CHILD_SA. The keying material for the
- CHILD_SA is a function of SK_d established during the establishment
- of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA
- exchange, and the Diffie-Hellman value (if KE payloads are included
- in the CREATE_CHILD_SA exchange).
-
- In the CHILD_SA created as part of the initial exchange, a second KE
- payload and nonce MUST NOT be sent. The nonces from the initial
- exchange are used in computing the keys for the CHILD_SA.
-
- The CREATE_CHILD_SA request contains:
-
- Initiator Responder
- ----------- -----------
- HDR, SK {[N], SA, Ni, [KEi],
- [TSi, TSr]} -->
-
- The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
- payload, optionally a Diffie-Hellman value in the KEi payload, and
- the proposed traffic selectors in the TSi and TSr payloads. If this
- CREATE_CHILD_SA exchange is rekeying an existing SA other than the
- IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA
- being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying an
- existing SA, the N payload MUST be omitted. If the SA offers include
- different Diffie-Hellman groups, KEi MUST be an element of the group
- the initiator expects the responder to accept. If it guesses wrong,
- the CREATE_CHILD_SA exchange will fail, and it will have to retry
- with a different KEi.
-
- The message following the header is encrypted and the message
- including the header is integrity protected using the cryptographic
- algorithms negotiated for the IKE_SA.
-
- The CREATE_CHILD_SA response contains:
-
- <-- HDR, SK {SA, Nr, [KEr],
- [TSi, TSr]}
-
- The responder replies (using the same Message ID to respond) with the
- accepted offer in an SA payload, and a Diffie-Hellman value in the
- KEr payload if KEi was included in the request and the selected
- cryptographic suite includes that group. If the responder chooses a
- cryptographic suite with a different group, it MUST reject the
- request. The initiator SHOULD repeat the request, but now with a KEi
- payload from the group the responder selected.
-
-
-
-Kaufman Standards Track [Page 10]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- The traffic selectors for traffic to be sent on that SA are specified
- in the TS payloads, which may be a subset of what the initiator of
- the CHILD_SA proposed. Traffic selectors are omitted if this
- CREATE_CHILD_SA request is being used to change the key of the
- IKE_SA.
-
-1.4. The INFORMATIONAL Exchange
-
- At various points during the operation of an IKE_SA, peers may desire
- to convey control messages to each other regarding errors or
- notifications of certain events. To accomplish this, IKE defines an
- INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur
- after the initial exchanges and are cryptographically protected with
- the negotiated keys.
-
- Control messages that pertain to an IKE_SA MUST be sent under that
- IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent
- under the protection of the IKE_SA which generated them (or its
- successor if the IKE_SA was replaced for the purpose of rekeying).
-
- Messages in an INFORMATIONAL exchange contain zero or more
- Notification, Delete, and Configuration payloads. The Recipient of
- an INFORMATIONAL exchange request MUST send some response (else the
- Sender will assume the message was lost in the network and will
- retransmit it). That response MAY be a message with no payloads.
- The request message in an INFORMATIONAL exchange MAY also contain no
- payloads. This is the expected way an endpoint can ask the other
- endpoint to verify that it is alive.
-
- ESP and AH SAs always exist in pairs, with one SA in each direction.
- When an SA is closed, both members of the pair MUST be closed. When
- SAs are nested, as when data (and IP headers if in tunnel mode) are
- encapsulated first with IPComp, then with ESP, and finally with AH
- between the same pair of endpoints, all of the SAs MUST be deleted
- together. Each endpoint MUST close its incoming SAs and allow the
- other endpoint to close the other SA in each pair. To delete an SA,
- an INFORMATIONAL exchange with one or more delete payloads is sent
- listing the SPIs (as they would be expected in the headers of inbound
- packets) of the SAs to be deleted. The recipient MUST close the
- designated SAs. Normally, the reply in the INFORMATIONAL exchange
- will contain delete payloads for the paired SAs going in the other
- direction. There is one exception. If by chance both ends of a set
- of SAs independently decide to close them, each may send a delete
- payload and the two requests may cross in the network. If a node
- receives a delete request for SAs for which it has already issued a
- delete request, it MUST delete the outgoing SAs while processing the
- request and the incoming SAs while processing the response. In that
-
-
-
-
-Kaufman Standards Track [Page 11]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- case, the responses MUST NOT include delete payloads for the deleted
- SAs, since that would result in duplicate deletion and could in
- theory delete the wrong SA.
-
- A node SHOULD regard half-closed connections as anomalous and audit
- their existence should they persist. Note that this specification
- nowhere specifies time periods, so it is up to individual endpoints
- to decide how long to wait. A node MAY refuse to accept incoming
- data on half-closed connections but MUST NOT unilaterally close them
- and reuse the SPIs. If connection state becomes sufficiently messed
- up, a node MAY close the IKE_SA; doing so will implicitly close all
- SAs negotiated under it. It can then rebuild the SAs it needs on a
- clean base under a new IKE_SA.
-
- The INFORMATIONAL exchange is defined as:
-
- Initiator Responder
- ----------- -----------
- HDR, SK {[N,] [D,] [CP,] ...} -->
- <-- HDR, SK {[N,] [D,] [CP], ...}
-
- The processing of an INFORMATIONAL exchange is determined by its
- component payloads.
-
-1.5. Informational Messages outside of an IKE_SA
-
- If an encrypted IKE packet arrives on port 500 or 4500 with an
- unrecognized SPI, it could be because the receiving node has recently
- crashed and lost state or because of some other system malfunction or
- attack. If the receiving node has an active IKE_SA to the IP address
- from whence the packet came, it MAY send a notification of the
- wayward packet over that IKE_SA in an INFORMATIONAL exchange. If it
- does not have such an IKE_SA, it MAY send an Informational message
- without cryptographic protection to the source IP address. Such a
- message is not part of an informational exchange, and the receiving
- node MUST NOT respond to it. Doing so could cause a message loop.
-
-2. IKE Protocol Details and Variations
-
- IKE normally listens and sends on UDP port 500, though IKE messages
- may also be received on UDP port 4500 with a slightly different
- format (see section 2.23). Since UDP is a datagram (unreliable)
- protocol, IKE includes in its definition recovery from transmission
- errors, including packet loss, packet replay, and packet forgery.
- IKE is designed to function so long as (1) at least one of a series
- of retransmitted packets reaches its destination before timing out;
- and (2) the channel is not so full of forged and replayed packets so
-
-
-
-
-Kaufman Standards Track [Page 12]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- as to exhaust the network or CPU capacities of either endpoint. Even
- in the absence of those minimum performance requirements, IKE is
- designed to fail cleanly (as though the network were broken).
-
- Although IKEv2 messages are intended to be short, they contain
- structures with no hard upper bound on size (in particular, X.509
- certificates), and IKEv2 itself does not have a mechanism for
- fragmenting large messages. IP defines a mechanism for fragmentation
- of oversize UDP messages, but implementations vary in the maximum
- message size supported. Furthermore, use of IP fragmentation opens
- an implementation to denial of service attacks [KPS03]. Finally,
- some NAT and/or firewall implementations may block IP fragments.
-
- All IKEv2 implementations MUST be able to send, receive, and process
- IKE messages that are up to 1280 bytes long, and they SHOULD be able
- to send, receive, and process messages that are up to 3000 bytes
- long. IKEv2 implementations SHOULD be aware of the maximum UDP
- message size supported and MAY shorten messages by leaving out some
- certificates or cryptographic suite proposals if that will keep
- messages below the maximum. Use of the "Hash and URL" formats rather
- than including certificates in exchanges where possible can avoid
- most problems. Implementations and configuration should keep in
- mind, however, that if the URL lookups are possible only after the
- IPsec SA is established, recursion issues could prevent this
- technique from working.
-
-2.1. Use of Retransmission Timers
-
- All messages in IKE exist in pairs: a request and a response. The
- setup of an IKE_SA normally consists of two request/response pairs.
- Once the IKE_SA is set up, either end of the security association may
- initiate requests at any time, and there can be many requests and
- responses "in flight" at any given moment. But each message is
- labeled as either a request or a response, and for each
- request/response pair one end of the security association is the
- initiator and the other is the responder.
-
- For every pair of IKE messages, the initiator is responsible for
- retransmission in the event of a timeout. The responder MUST never
- retransmit a response unless it receives a retransmission of the
- request. In that event, the responder MUST ignore the retransmitted
- request except insofar as it triggers a retransmission of the
- response. The initiator MUST remember each request until it receives
- the corresponding response. The responder MUST remember each
- response until it receives a request whose sequence number is larger
- than the sequence number in the response plus its window size (see
- section 2.3).
-
-
-
-
-Kaufman Standards Track [Page 13]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- IKE is a reliable protocol, in the sense that the initiator MUST
- retransmit a request until either it receives a corresponding reply
- OR it deems the IKE security association to have failed and it
- discards all state associated with the IKE_SA and any CHILD_SAs
- negotiated using that IKE_SA.
-
-2.2. Use of Sequence Numbers for Message ID
-
- Every IKE message contains a Message ID as part of its fixed header.
- This Message ID is used to match up requests and responses, and to
- identify retransmissions of messages.
-
- The Message ID is a 32-bit quantity, which is zero for the first IKE
- request in each direction. The IKE_SA initial setup messages will
- always be numbered 0 and 1. Each endpoint in the IKE Security
- Association maintains two "current" Message IDs: the next one to be
- used for a request it initiates and the next one it expects to see in
- a request from the other end. These counters increment as requests
- are generated and received. Responses always contain the same
- message ID as the corresponding request. That means that after the
- initial exchange, each integer n may appear as the message ID in four
- distinct messages: the nth request from the original IKE initiator,
- the corresponding response, the nth request from the original IKE
- responder, and the corresponding response. If the two ends make very
- different numbers of requests, the Message IDs in the two directions
- can be very different. There is no ambiguity in the messages,
- however, because the (I)nitiator and (R)esponse bits in the message
- header specify which of the four messages a particular one is.
-
- Note that Message IDs are cryptographically protected and provide
- protection against message replays. In the unlikely event that
- Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be
- closed. Rekeying an IKE_SA resets the sequence numbers.
-
-2.3. Window Size for Overlapping Requests
-
- In order to maximize IKE throughput, an IKE endpoint MAY issue
- multiple requests before getting a response to any of them if the
- other endpoint has indicated its ability to handle such requests.
- For simplicity, an IKE implementation MAY choose to process requests
- strictly in order and/or wait for a response to one request before
- issuing another. Certain rules must be followed to ensure
- interoperability between implementations using different strategies.
-
- After an IKE_SA is set up, either end can initiate one or more
- requests. These requests may pass one another over the network. An
- IKE endpoint MUST be prepared to accept and process a request while
-
-
-
-
-Kaufman Standards Track [Page 14]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- it has a request outstanding in order to avoid a deadlock in this
- situation. An IKE endpoint SHOULD be prepared to accept and process
- multiple requests while it has a request outstanding.
-
- An IKE endpoint MUST wait for a response to each of its messages
- before sending a subsequent message unless it has received a
- SET_WINDOW_SIZE Notify message from its peer informing it that the
- peer is prepared to maintain state for multiple outstanding messages
- in order to allow greater throughput.
-
- An IKE endpoint MUST NOT exceed the peer's stated window size for
- transmitted IKE requests. In other words, if the responder stated
- its window size is N, then when the initiator needs to make a request
- X, it MUST wait until it has received responses to all requests up
- through request X-N. An IKE endpoint MUST keep a copy of (or be able
- to regenerate exactly) each request it has sent until it receives the
- corresponding response. An IKE endpoint MUST keep a copy of (or be
- able to regenerate exactly) the number of previous responses equal to
- its declared window size in case its response was lost and the
- initiator requests its retransmission by retransmitting the request.
-
- An IKE endpoint supporting a window size greater than one SHOULD be
- capable of processing incoming requests out of order to maximize
- performance in the event of network failures or packet reordering.
-
-2.4. State Synchronization and Connection Timeouts
-
- An IKE endpoint is allowed to forget all of its state associated with
- an IKE_SA and the collection of corresponding CHILD_SAs at any time.
- This is the anticipated behavior in the event of an endpoint crash
- and restart. It is important when an endpoint either fails or
- reinitializes its state that the other endpoint detect those
- conditions and not continue to waste network bandwidth by sending
- packets over discarded SAs and having them fall into a black hole.
-
- Since IKE is designed to operate in spite of Denial of Service (DoS)
- attacks from the network, an endpoint MUST NOT conclude that the
- other endpoint has failed based on any routing information (e.g.,
- ICMP messages) or IKE messages that arrive without cryptographic
- protection (e.g., Notify messages complaining about unknown SPIs).
- An endpoint MUST conclude that the other endpoint has failed only
- when repeated attempts to contact it have gone unanswered for a
- timeout period or when a cryptographically protected INITIAL_CONTACT
- notification is received on a different IKE_SA to the same
- authenticated identity. An endpoint SHOULD suspect that the other
- endpoint has failed based on routing information and initiate a
- request to see whether the other endpoint is alive. To check whether
- the other side is alive, IKE specifies an empty INFORMATIONAL message
-
-
-
-Kaufman Standards Track [Page 15]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- that (like all IKE requests) requires an acknowledgement (note that
- within the context of an IKE_SA, an "empty" message consists of an
- IKE header followed by an Encrypted payload that contains no
- payloads). If a cryptographically protected message has been
- received from the other side recently, unprotected notifications MAY
- be ignored. Implementations MUST limit the rate at which they take
- actions based on unprotected messages.
-
- Numbers of retries and lengths of timeouts are not covered in this
- specification because they do not affect interoperability. It is
- suggested that messages be retransmitted at least a dozen times over
- a period of at least several minutes before giving up on an SA, but
- different environments may require different rules. To be a good
- network citizen, retranmission times MUST increase exponentially to
- avoid flooding the network and making an existing congestion
- situation worse. If there has only been outgoing traffic on all of
- the SAs associated with an IKE_SA, it is essential to confirm
- liveness of the other endpoint to avoid black holes. If no
- cryptographically protected messages have been received on an IKE_SA
- or any of its CHILD_SAs recently, the system needs to perform a
- liveness check in order to prevent sending messages to a dead peer.
- Receipt of a fresh cryptographically protected message on an IKE_SA
- or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its
- CHILD_SAs. Note that this places requirements on the failure modes
- of an IKE endpoint. An implementation MUST NOT continue sending on
- any SA if some failure prevents it from receiving on all of the
- associated SAs. If CHILD_SAs can fail independently from one another
- without the associated IKE_SA being able to send a delete message,
- then they MUST be negotiated by separate IKE_SAs.
-
- There is a Denial of Service attack on the initiator of an IKE_SA
- that can be avoided if the initiator takes the proper care. Since
- the first two messages of an SA setup are not cryptographically
- protected, an attacker could respond to the initiator's message
- before the genuine responder and poison the connection setup attempt.
- To prevent this, the initiator MAY be willing to accept multiple
- responses to its first message, treat each as potentially legitimate,
- respond to it, and then discard all the invalid half-open connections
- when it receives a valid cryptographically protected response to any
- one of its requests. Once a cryptographically valid response is
- received, all subsequent responses should be ignored whether or not
- they are cryptographically valid.
-
- Note that with these rules, there is no reason to negotiate and agree
- upon an SA lifetime. If IKE presumes the partner is dead, based on
- repeated lack of acknowledgement to an IKE message, then the IKE SA
- and all CHILD_SAs set up through that IKE_SA are deleted.
-
-
-
-
-Kaufman Standards Track [Page 16]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- An IKE endpoint may at any time delete inactive CHILD_SAs to recover
- resources used to hold their state. If an IKE endpoint chooses to
- delete CHILD_SAs, it MUST send Delete payloads to the other end
- notifying it of the deletion. It MAY similarly time out the IKE_SA.
- Closing the IKE_SA implicitly closes all associated CHILD_SAs. In
- this case, an IKE endpoint SHOULD send a Delete payload indicating
- that it has closed the IKE_SA.
-
-2.5. Version Numbers and Forward Compatibility
-
- This document describes version 2.0 of IKE, meaning the major version
- number is 2 and the minor version number is zero. It is likely that
- some implementations will want to support both version 1.0 and
- version 2.0, and in the future, other versions.
-
- The major version number should be incremented only if the packet
- formats or required actions have changed so dramatically that an
- older version node would not be able to interoperate with a newer
- version node if it simply ignored the fields it did not understand
- and took the actions specified in the older specification. The minor
- version number indicates new capabilities, and MUST be ignored by a
- node with a smaller minor version number, but used for informational
- purposes by the node with the larger minor version number. For
- example, it might indicate the ability to process a newly defined
- notification message. The node with the larger minor version number
- would simply note that its correspondent would not be able to
- understand that message and therefore would not send it.
-
- If an endpoint receives a message with a higher major version number,
- it MUST drop the message and SHOULD send an unauthenticated
- notification message containing the highest version number it
- supports. If an endpoint supports major version n, and major version
- m, it MUST support all versions between n and m. If it receives a
- message with a major version that it supports, it MUST respond with
- that version number. In order to prevent two nodes from being
- tricked into corresponding with a lower major version number than the
- maximum that they both support, IKE has a flag that indicates that
- the node is capable of speaking a higher major version number.
-
- Thus, the major version number in the IKE header indicates the
- version number of the message, not the highest version number that
- the transmitter supports. If the initiator is capable of speaking
- versions n, n+1, and n+2, and the responder is capable of speaking
- versions n and n+1, then they will negotiate speaking n+1, where the
- initiator will set the flag indicating its ability to speak a higher
- version. If they mistakenly (perhaps through an active attacker
-
-
-
-
-
-Kaufman Standards Track [Page 17]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- sending error messages) negotiate to version n, then both will notice
- that the other side can support a higher version number, and they
- MUST break the connection and reconnect using version n+1.
-
- Note that IKEv1 does not follow these rules, because there is no way
- in v1 of noting that you are capable of speaking a higher version
- number. So an active attacker can trick two v2-capable nodes into
- speaking v1. When a v2-capable node negotiates down to v1, it SHOULD
- note that fact in its logs.
-
- Also for forward compatibility, all fields marked RESERVED MUST be
- set to zero by a version 2.0 implementation and their content MUST be
- ignored by a version 2.0 implementation ("Be conservative in what you
- send and liberal in what you receive"). In this way, future versions
- of the protocol can use those fields in a way that is guaranteed to
- be ignored by implementations that do not understand them.
- Similarly, payload types that are not defined are reserved for future
- use; implementations of version 2.0 MUST skip over those payloads and
- ignore their contents.
-
- IKEv2 adds a "critical" flag to each payload header for further
- flexibility for forward compatibility. If the critical flag is set
- and the payload type is unrecognized, the message MUST be rejected
- and the response to the IKE request containing that payload MUST
- include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an
- unsupported critical payload was included. If the critical flag is
- not set and the payload type is unsupported, that payload MUST be
- ignored.
-
- Although new payload types may be added in the future and may appear
- interleaved with the fields defined in this specification,
- implementations MUST send the payloads defined in this specification
- in the order shown in the figures in section 2 and implementations
- SHOULD reject as invalid a message with those payloads in any other
- order.
-
-2.6. Cookies
-
- The term "cookies" originates with Karn and Simpson [RFC2522] in
- Photuris, an early proposal for key management with IPsec, and it has
- persisted. The Internet Security Association and Key Management
- Protocol (ISAKMP) [MSST98] fixed message header includes two eight-
- octet fields titled "cookies", and that syntax is used by both IKEv1
- and IKEv2 though in IKEv2 they are referred to as the IKE SPI and
- there is a new separate field in a Notify payload holding the cookie.
- The initial two eight-octet fields in the header are used as a
- connection identifier at the beginning of IKE packets. Each endpoint
-
-
-
-
-Kaufman Standards Track [Page 18]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- chooses one of the two SPIs and SHOULD choose them so as to be unique
- identifiers of an IKE_SA. An SPI value of zero is special and
- indicates that the remote SPI value is not yet known by the sender.
-
- Unlike ESP and AH where only the recipient's SPI appears in the
- header of a message, in IKE the sender's SPI is also sent in every
- message. Since the SPI chosen by the original initiator of the
- IKE_SA is always sent first, an endpoint with multiple IKE_SAs open
- that wants to find the appropriate IKE_SA using the SPI it assigned
- must look at the I(nitiator) Flag bit in the header to determine
- whether it assigned the first or the second eight octets.
-
- In the first message of an initial IKE exchange, the initiator will
- not know the responder's SPI value and will therefore set that field
- to zero.
-
- An expected attack against IKE is state and CPU exhaustion, where the
- target is flooded with session initiation requests from forged IP
- addresses. This attack can be made less effective if an
- implementation of a responder uses minimal CPU and commits no state
- to an SA until it knows the initiator can receive packets at the
- address from which it claims to be sending them. To accomplish this,
- a responder SHOULD -- when it detects a large number of half-open
- IKE_SAs -- reject initial IKE messages unless they contain a Notify
- payload of type COOKIE. It SHOULD instead send an unprotected IKE
- message as a response and include COOKIE Notify payload with the
- cookie data to be returned. Initiators who receive such responses
- MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE
- containing the responder supplied cookie data as the first payload
- and all other payloads unchanged. The initial exchange will then be
- as follows:
-
- Initiator Responder
- ----------- -----------
- HDR(A,0), SAi1, KEi, Ni -->
-
- <-- HDR(A,0), N(COOKIE)
-
- HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
-
- <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ]
-
- HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]
- AUTH, SAi2, TSi, TSr} -->
-
- <-- HDR(A,B), SK {IDr, [CERT,] AUTH,
- SAr2, TSi, TSr}
-
-
-
-
-Kaufman Standards Track [Page 19]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- The first two messages do not affect any initiator or responder state
- except for communicating the cookie. In particular, the message
- sequence numbers in the first four messages will all be zero and the
- message sequence numbers in the last two messages will be one. 'A' is
- the SPI assigned by the initiator, while 'B' is the SPI assigned by
- the responder.
-
- An IKE implementation SHOULD implement its responder cookie
- generation in such a way as to not require any saved state to
- recognize its valid cookie when the second IKE_SA_INIT message
- arrives. The exact algorithms and syntax they use to generate
- cookies do not affect interoperability and hence are not specified
- here. The following is an example of how an endpoint could use
- cookies to implement limited DOS protection.
-
- A good way to do this is to set the responder cookie to be:
-
- Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
-
- where <secret> is a randomly generated secret known only to the
- responder and periodically changed and | indicates concatenation.
- <VersionIDofSecret> should be changed whenever <secret> is
- regenerated. The cookie can be recomputed when the IKE_SA_INIT
- arrives the second time and compared to the cookie in the received
- message. If it matches, the responder knows that the cookie was
- generated since the last change to <secret> and that IPi must be the
- same as the source address it saw the first time. Incorporating SPIi
- into the calculation ensures that if multiple IKE_SAs are being set
- up in parallel they will all get different cookies (assuming the
- initiator chooses unique SPIi's). Incorporating Ni into the hash
- ensures that an attacker who sees only message 2 can't successfully
- forge a message 3.
-
- If a new value for <secret> is chosen while there are connections in
- the process of being initialized, an IKE_SA_INIT might be returned
- with other than the current <VersionIDofSecret>. The responder in
- that case MAY reject the message by sending another response with a
- new cookie or it MAY keep the old value of <secret> around for a
- short time and accept cookies computed from either one. The
- responder SHOULD NOT accept cookies indefinitely after <secret> is
- changed, since that would defeat part of the denial of service
- protection. The responder SHOULD change the value of <secret>
- frequently, especially if under attack.
-
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 20]
-\f
-RFC 4306 IKEv2 December 2005
-
-
-2.7. Cryptographic Algorithm Negotiation
-
- The payload type known as "SA" indicates a proposal for a set of
- choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well
- as cryptographic algorithms associated with each protocol.
-
- An SA payload consists of one or more proposals. Each proposal
- includes one or more protocols (usually one). Each protocol contains
- one or more transforms -- each specifying a cryptographic algorithm.
- Each transform contains zero or more attributes (attributes are
- needed only if the transform identifier does not completely specify
- the cryptographic algorithm).
-
- This hierarchical structure was designed to efficiently encode
- proposals for cryptographic suites when the number of supported
- suites is large because multiple values are acceptable for multiple
- transforms. The responder MUST choose a single suite, which MAY be
- any subset of the SA proposal following the rules below:
-
- Each proposal contains one or more protocols. If a proposal is
- accepted, the SA response MUST contain the same protocols in the
- same order as the proposal. The responder MUST accept a single
- proposal or reject them all and return an error. (Example: if a
- single proposal contains ESP and AH and that proposal is accepted,
- both ESP and AH MUST be accepted. If ESP and AH are included in
- separate proposals, the responder MUST accept only one of them).
-
- Each IPsec protocol proposal contains one or more transforms.
- Each transform contains a transform type. The accepted
- cryptographic suite MUST contain exactly one transform of each
- type included in the proposal. For example: if an ESP proposal
- includes transforms ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES
- w/keysize 256, AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted
- suite MUST contain one of the ENCR_ transforms and one of the
- AUTH_ transforms. Thus, six combinations are acceptable.
-
- Since the initiator sends its Diffie-Hellman value in the
- IKE_SA_INIT, it must guess the Diffie-Hellman group that the
- responder will select from its list of supported groups. If the
- initiator guesses wrong, the responder will respond with a Notify
- payload of type INVALID_KE_PAYLOAD indicating the selected group. In
- this case, the initiator MUST retry the IKE_SA_INIT with the
- corrected Diffie-Hellman group. The initiator MUST again propose its
- full set of acceptable cryptographic suites because the rejection
- message was unauthenticated and otherwise an active attacker could
- trick the endpoints into negotiating a weaker suite than a stronger
- one that they both prefer.
-
-
-
-
-Kaufman Standards Track [Page 21]
-\f
-RFC 4306 IKEv2 December 2005
-
-
-2.8. Rekeying
-
- IKE, ESP, and AH security associations use secret keys that SHOULD be
- used only for a limited amount of time and to protect a limited
- amount of data. This limits the lifetime of the entire security
- association. When the lifetime of a security association expires,
- the security association MUST NOT be used. If there is demand, new
- security associations MAY be established. Reestablishment of
- security associations to take the place of ones that expire is
- referred to as "rekeying".
-
- To allow for minimal IPsec implementations, the ability to rekey SAs
- without restarting the entire IKE_SA is optional. An implementation
- MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA
- has expired or is about to expire and rekeying attempts using the
- mechanisms described here fail, an implementation MUST close the
- IKE_SA and any associated CHILD_SAs and then MAY start new ones.
- Implementations SHOULD support in-place rekeying of SAs, since doing
- so offers better performance and is likely to reduce the number of
- packets lost during the transition.
-
- To rekey a CHILD_SA within an existing IKE_SA, create a new,
- equivalent SA (see section 2.17 below), and when the new one is
- established, delete the old one. To rekey an IKE_SA, establish a new
- equivalent IKE_SA (see section 2.18 below) with the peer to whom the
- old IKE_SA is shared using a CREATE_CHILD_SA within the existing
- IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's
- CHILD_SAs. Use the new IKE_SA for all control messages needed to
- maintain the CHILD_SAs created by the old IKE_SA, and delete the old
- IKE_SA. The Delete payload to delete itself MUST be the last request
- sent over an IKE_SA.
-
- SAs SHOULD be rekeyed proactively, i.e., the new SA should be
- established before the old one expires and becomes unusable. Enough
- time should elapse between the time the new SA is established and the
- old one becomes unusable so that traffic can be switched over to the
- new SA.
-
- A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
- were negotiated. In IKEv2, each end of the SA is responsible for
- enforcing its own lifetime policy on the SA and rekeying the SA when
- necessary. If the two ends have different lifetime policies, the end
- with the shorter lifetime will end up always being the one to request
- the rekeying. If an SA bundle has been inactive for a long time and
- if an endpoint would not initiate the SA in the absence of traffic,
- the endpoint MAY choose to close the SA instead of rekeying it when
- its lifetime expires. It SHOULD do so if there has been no traffic
- since the last time the SA was rekeyed.
-
-
-
-Kaufman Standards Track [Page 22]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- If the two ends have the same lifetime policies, it is possible that
- both will initiate a rekeying at the same time (which will result in
- redundant SAs). To reduce the probability of this happening, the
- timing of rekeying requests SHOULD be jittered (delayed by a random
- amount of time after the need for rekeying is noticed).
-
- This form of rekeying may temporarily result in multiple similar SAs
- between the same pairs of nodes. When there are two SAs eligible to
- receive packets, a node MUST accept incoming packets through either
- SA. If redundant SAs are created though such a collision, the SA
- created with the lowest of the four nonces used in the two exchanges
- SHOULD be closed by the endpoint that created it.
-
- Note that IKEv2 deliberately allows parallel SAs with the same
- traffic selectors between common endpoints. One of the purposes of
- this is to support traffic quality of service (QoS) differences among
- the SAs (see [RFC2474], [RFC2475], and section 4.1 of [RFC2983]).
- Hence unlike IKEv1, the combination of the endpoints and the traffic
- selectors may not uniquely identify an SA between those endpoints, so
- the IKEv1 rekeying heuristic of deleting SAs on the basis of
- duplicate traffic selectors SHOULD NOT be used.
-
- The node that initiated the surviving rekeyed SA SHOULD delete the
- replaced SA after the new one is established.
-
- There are timing windows -- particularly in the presence of lost
- packets -- where endpoints may not agree on the state of an SA. The
- responder to a CREATE_CHILD_SA MUST be prepared to accept messages on
- an SA before sending its response to the creation request, so there
- is no ambiguity for the initiator. The initiator MAY begin sending
- on an SA as soon as it processes the response. The initiator,
- however, cannot receive on a newly created SA until it receives and
- processes the response to its CREATE_CHILD_SA request. How, then, is
- the responder to know when it is OK to send on the newly created SA?
-
- From a technical correctness and interoperability perspective, the
- responder MAY begin sending on an SA as soon as it sends its response
- to the CREATE_CHILD_SA request. In some situations, however, this
- could result in packets unnecessarily being dropped, so an
- implementation MAY want to defer such sending.
-
- The responder can be assured that the initiator is prepared to
- receive messages on an SA if either (1) it has received a
- cryptographically valid message on the new SA, or (2) the new SA
- rekeys an existing SA and it receives an IKE request to close the
- replaced SA. When rekeying an SA, the responder SHOULD continue to
- send messages on the old SA until one of those events occurs. When
- establishing a new SA, the responder MAY defer sending messages on a
-
-
-
-Kaufman Standards Track [Page 23]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- new SA until either it receives one or a timeout has occurred. If an
- initiator receives a message on an SA for which it has not received a
- response to its CREATE_CHILD_SA request, it SHOULD interpret that as
- a likely packet loss and retransmit the CREATE_CHILD_SA request. An
- initiator MAY send a dummy message on a newly created SA if it has no
- messages queued in order to assure the responder that the initiator
- is ready to receive messages.
-
-2.9. Traffic Selector Negotiation
-
- When an IP packet is received by an RFC4301-compliant IPsec subsystem
- and matches a "protect" selector in its Security Policy Database
- (SPD), the subsystem MUST protect that packet with IPsec. When no SA
- exists yet, it is the task of IKE to create it. Maintenance of a
- system's SPD is outside the scope of IKE (see [PFKEY] for an example
- protocol), though some implementations might update their SPD in
- connection with the running of IKE (for an example scenario, see
- section 1.1.3).
-
- Traffic Selector (TS) payloads allow endpoints to communicate some of
- the information from their SPD to their peers. TS payloads specify
- the selection criteria for packets that will be forwarded over the
- newly set up SA. This can serve as a consistency check in some
- scenarios to assure that the SPDs are consistent. In others, it
- guides the dynamic update of the SPD.
-
- Two TS payloads appear in each of the messages in the exchange that
- creates a CHILD_SA pair. Each TS payload contains one or more
- Traffic Selectors. Each Traffic Selector consists of an address
- range (IPv4 or IPv6), a port range, and an IP protocol ID. In
- support of the scenario described in section 1.1.3, an initiator may
- request that the responder assign an IP address and tell the
- initiator what it is.
-
- IKEv2 allows the responder to choose a subset of the traffic proposed
- by the initiator. This could happen when the configurations of the
- two endpoints are being updated but only one end has received the new
- information. Since the two endpoints may be configured by different
- people, the incompatibility may persist for an extended period even
- in the absence of errors. It also allows for intentionally different
- configurations, as when one end is configured to tunnel all addresses
- and depends on the other end to have the up-to-date list.
-
- The first of the two TS payloads is known as TSi (Traffic Selector-
- initiator). The second is known as TSr (Traffic Selector-responder).
- TSi specifies the source address of traffic forwarded from (or the
- destination address of traffic forwarded to) the initiator of the
- CHILD_SA pair. TSr specifies the destination address of the traffic
-
-
-
-Kaufman Standards Track [Page 24]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- forwarded to (or the source address of the traffic forwarded from)
- the responder of the CHILD_SA pair. For example, if the original
- initiator request the creation of a CHILD_SA pair, and wishes to
- tunnel all traffic from subnet 192.0.1.* on the initiator's side to
- subnet 192.0.2.* on the responder's side, the initiator would include
- a single traffic selector in each TS payload. TSi would specify the
- address range (192.0.1.0 - 192.0.1.255) and TSr would specify the
- address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was
- acceptable to the responder, it would send identical TS payloads
- back. (Note: The IP address range 192.0.2.* has been reserved for
- use in examples in RFCs and similar documents. This document needed
- two such ranges, and so also used 192.0.1.*. This should not be
- confused with any actual address.)
-
- The responder is allowed to narrow the choices by selecting a subset
- of the traffic, for instance by eliminating or narrowing the range of
- one or more members of the set of traffic selectors, provided the set
- does not become the NULL set.
-
- It is possible for the responder's policy to contain multiple smaller
- ranges, all encompassed by the initiator's traffic selector, and with
- the responder's policy being that each of those ranges should be sent
- over a different SA. Continuing the example above, the responder
- might have a policy of being willing to tunnel those addresses to and
- from the initiator, but might require that each address pair be on a
- separately negotiated CHILD_SA. If the initiator generated its
- request in response to an incoming packet from 192.0.1.43 to
- 192.0.2.123, there would be no way for the responder to determine
- which pair of addresses should be included in this tunnel, and it
- would have to make a guess or reject the request with a status of
- SINGLE_PAIR_REQUIRED.
-
- To enable the responder to choose the appropriate range in this case,
- if the initiator has requested the SA due to a data packet, the
- initiator SHOULD include as the first traffic selector in each of TSi
- and TSr a very specific traffic selector including the addresses in
- the packet triggering the request. In the example, the initiator
- would include in TSi two traffic selectors: the first containing the
- address range (192.0.1.43 - 192.0.1.43) and the source port and IP
- protocol from the packet and the second containing (192.0.1.0 -
- 192.0.1.255) with all ports and IP protocols. The initiator would
- similarly include two traffic selectors in TSr.
-
- If the responder's policy does not allow it to accept the entire set
- of traffic selectors in the initiator's request, but does allow him
- to accept the first selector of TSi and TSr, then the responder MUST
- narrow the traffic selectors to a subset that includes the
-
-
-
-
-Kaufman Standards Track [Page 25]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- initiator's first choices. In this example, the responder might
- respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and
- IP protocols.
-
- If the initiator creates the CHILD_SA pair not in response to an
- arriving packet, but rather, say, upon startup, then there may be no
- specific addresses the initiator prefers for the initial tunnel over
- any other. In that case, the first values in TSi and TSr MAY be
- ranges rather than specific values, and the responder chooses a
- subset of the initiator's TSi and TSr that are acceptable. If more
- than one subset is acceptable but their union is not, the responder
- MUST accept some subset and MAY include a Notify payload of type
- ADDITIONAL_TS_POSSIBLE to indicate that the initiator might want to
- try again. This case will occur only when the initiator and
- responder are configured differently from one another. If the
- initiator and responder agree on the granularity of tunnels, the
- initiator will never request a tunnel wider than the responder will
- accept. Such misconfigurations SHOULD be recorded in error logs.
-
-2.10. Nonces
-
- The IKE_SA_INIT messages each contain a nonce. These nonces are used
- as inputs to cryptographic functions. The CREATE_CHILD_SA request
- and the CREATE_CHILD_SA response also contain nonces. These nonces
- are used to add freshness to the key derivation technique used to
- obtain keys for CHILD_SA, and to ensure creation of strong pseudo-
- random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST
- be randomly chosen, MUST be at least 128 bits in size, and MUST be at
- least half the key size of the negotiated prf. ("prf" refers to
- "pseudo-random function", one of the cryptographic algorithms
- negotiated in the IKE exchange.) If the same random number source is
- used for both keys and nonces, care must be taken to ensure that the
- latter use does not compromise the former.
-
-2.11. Address and Port Agility
-
- IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
- AH associations for the same IP addresses it runs over. The IP
- addresses and ports in the outer header are, however, not themselves
- cryptographically protected, and IKE is designed to work even through
- Network Address Translation (NAT) boxes. An implementation MUST
- accept incoming requests even if the source port is not 500 or 4500,
- and MUST respond to the address and port from which the request was
- received. It MUST specify the address and port at which the request
- was received as the source address and port in the response. IKE
- functions identically over IPv4 or IPv6.
-
-
-
-
-
-Kaufman Standards Track [Page 26]
-\f
-RFC 4306 IKEv2 December 2005
-
-
-2.12. Reuse of Diffie-Hellman Exponentials
-
- IKE generates keying material using an ephemeral Diffie-Hellman
- exchange in order to gain the property of "perfect forward secrecy".
- This means that once a connection is closed and its corresponding
- keys are forgotten, even someone who has recorded all of the data
- from the connection and gets access to all of the long-term keys of
- the two endpoints cannot reconstruct the keys used to protect the
- conversation without doing a brute force search of the session key
- space.
-
- Achieving perfect forward secrecy requires that when a connection is
- closed, each endpoint MUST forget not only the keys used by the
- connection but also any information that could be used to recompute
- those keys. In particular, it MUST forget the secrets used in the
- Diffie-Hellman calculation and any state that may persist in the
- state of a pseudo-random number generator that could be used to
- recompute the Diffie-Hellman secrets.
-
- Since the computing of Diffie-Hellman exponentials is computationally
- expensive, an endpoint may find it advantageous to reuse those
- exponentials for multiple connection setups. There are several
- reasonable strategies for doing this. An endpoint could choose a new
- exponential only periodically though this could result in less-than-
- perfect forward secrecy if some connection lasts for less than the
- lifetime of the exponential. Or it could keep track of which
- exponential was used for each connection and delete the information
- associated with the exponential only when some corresponding
- connection was closed. This would allow the exponential to be reused
- without losing perfect forward secrecy at the cost of maintaining
- more state.
-
- Decisions as to whether and when to reuse Diffie-Hellman exponentials
- is a private decision in the sense that it will not affect
- interoperability. An implementation that reuses exponentials MAY
- choose to remember the exponential used by the other endpoint on past
- exchanges and if one is reused to avoid the second half of the
- calculation.
-
-2.13. Generating Keying Material
-
- In the context of the IKE_SA, four cryptographic algorithms are
- negotiated: an encryption algorithm, an integrity protection
- algorithm, a Diffie-Hellman group, and a pseudo-random function
- (prf). The pseudo-random function is used for the construction of
- keying material for all of the cryptographic algorithms used in both
- the IKE_SA and the CHILD_SAs.
-
-
-
-
-Kaufman Standards Track [Page 27]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- We assume that each encryption algorithm and integrity protection
- algorithm uses a fixed-size key and that any randomly chosen value of
- that fixed size can serve as an appropriate key. For algorithms that
- accept a variable length key, a fixed key size MUST be specified as
- part of the cryptographic transform negotiated. For algorithms for
- which not all values are valid keys (such as DES or 3DES with key
- parity), the algorithm by which keys are derived from arbitrary
- values MUST be specified by the cryptographic transform. For
- integrity protection functions based on Hashed Message Authentication
- Code (HMAC), the fixed key size is the size of the output of the
- underlying hash function. When the prf function takes a variable
- length key, variable length data, and produces a fixed-length output
- (e.g., when using HMAC), the formulas in this document apply. When
- the key for the prf function has fixed length, the data provided as a
- key is truncated or padded with zeros as necessary unless exceptional
- processing is explained following the formula.
-
- Keying material will always be derived as the output of the
- negotiated prf algorithm. Since the amount of keying material needed
- may be greater than the size of the output of the prf algorithm, we
- will use the prf iteratively. We will use the terminology prf+ to
- describe the function that outputs a pseudo-random stream based on
- the inputs to a prf as follows: (where | indicates concatenation)
-
- prf+ (K,S) = T1 | T2 | T3 | T4 | ...
-
- where:
- T1 = prf (K, S | 0x01)
- T2 = prf (K, T1 | S | 0x02)
- T3 = prf (K, T2 | S | 0x03)
- T4 = prf (K, T3 | S | 0x04)
-
- continuing as needed to compute all required keys. The keys are
- taken from the output string without regard to boundaries (e.g., if
- the required keys are a 256-bit Advanced Encryption Standard (AES)
- key and a 160-bit HMAC key, and the prf function generates 160 bits,
- the AES key will come from T1 and the beginning of T2, while the HMAC
- key will come from the rest of T2 and the beginning of T3).
-
- The constant concatenated to the end of each string feeding the prf
- is a single octet. prf+ in this document is not defined beyond 255
- times the size of the prf output.
-
-2.14. Generating Keying Material for the IKE_SA
-
- The shared keys are computed as follows. A quantity called SKEYSEED
- is calculated from the nonces exchanged during the IKE_SA_INIT
- exchange and the Diffie-Hellman shared secret established during that
-
-
-
-Kaufman Standards Track [Page 28]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- exchange. SKEYSEED is used to calculate seven other secrets: SK_d
- used for deriving new keys for the CHILD_SAs established with this
- IKE_SA; SK_ai and SK_ar used as a key to the integrity protection
- algorithm for authenticating the component messages of subsequent
- exchanges; SK_ei and SK_er used for encrypting (and of course
- decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are
- used when generating an AUTH payload.
-
- SKEYSEED and its derivatives are computed as follows:
-
- SKEYSEED = prf(Ni | Nr, g^ir)
-
- {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+
- (SKEYSEED, Ni | Nr | SPIi | SPIr )
-
- (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er,
- SK_pi, and SK_pr are taken in order from the generated bits of the
- prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman
- exchange. g^ir is represented as a string of octets in big endian
- order padded with zeros if necessary to make it the length of the
- modulus. Ni and Nr are the nonces, stripped of any headers. If the
- negotiated prf takes a fixed-length key and the lengths of Ni and Nr
- do not add up to that length, half the bits must come from Ni and
- half from Nr, taking the first bits of each.
-
- The two directions of traffic flow use different keys. The keys used
- to protect messages from the original initiator are SK_ai and SK_ei.
- The keys used to protect messages in the other direction are SK_ar
- and SK_er. Each algorithm takes a fixed number of bits of keying
- material, which is specified as part of the algorithm. For integrity
- algorithms based on a keyed hash, the key size is always equal to the
- length of the output of the underlying hash function.
-
-2.15. Authentication of the IKE_SA
-
- When not using extensible authentication (see section 2.16), the
- peers are authenticated by having each sign (or MAC using a shared
- secret as the key) a block of data. For the responder, the octets to
- be signed start with the first octet of the first SPI in the header
- of the second message and end with the last octet of the last payload
- in the second message. Appended to this (for purposes of computing
- the signature) are the initiator's nonce Ni (just the value, not the
- payload containing it), and the value prf(SK_pr,IDr') where IDr' is
- the responder's ID payload excluding the fixed header. Note that
- neither the nonce Ni nor the value prf(SK_pr,IDr') are transmitted.
- Similarly, the initiator signs the first message, starting with the
- first octet of the first SPI in the header and ending with the last
- octet of the last payload. Appended to this (for purposes of
-
-
-
-Kaufman Standards Track [Page 29]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- computing the signature) are the responder's nonce Nr, and the value
- prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the
- entire ID payloads excluding the fixed header. It is critical to the
- security of the exchange that each side sign the other side's nonce.
-
- Note that all of the payloads are included under the signature,
- including any payload types not defined in this document. If the
- first message of the exchange is sent twice (the second time with a
- responder cookie and/or a different Diffie-Hellman group), it is the
- second version of the message that is signed.
-
- Optionally, messages 3 and 4 MAY include a certificate, or
- certificate chain providing evidence that the key used to compute a
- digital signature belongs to the name in the ID payload. The
- signature or MAC will be computed using algorithms dictated by the
- type of key used by the signer, and specified by the Auth Method
- field in the Authentication payload. There is no requirement that
- the initiator and responder sign with the same cryptographic
- algorithms. The choice of cryptographic algorithms depends on the
- type of key each has. In particular, the initiator may be using a
- shared key while the responder may have a public signature key and
- certificate. It will commonly be the case (but it is not required)
- that if a shared secret is used for authentication that the same key
- is used in both directions. Note that it is a common but typically
- insecure practice to have a shared key derived solely from a user-
- chosen password without incorporating another source of randomness.
-
- This is typically insecure because user-chosen passwords are unlikely
- to have sufficient unpredictability to resist dictionary attacks and
- these attacks are not prevented in this authentication method.
- (Applications using password-based authentication for bootstrapping
- and IKE_SA should use the authentication method in section 2.16,
- which is designed to prevent off-line dictionary attacks.) The pre-
- shared key SHOULD contain as much unpredictability as the strongest
- key being negotiated. In the case of a pre-shared key, the AUTH
- value is computed as:
-
- AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)
-
- where the string "Key Pad for IKEv2" is 17 ASCII characters without
- null termination. The shared secret can be variable length. The pad
- string is added so that if the shared secret is derived from a
- password, the IKE implementation need not store the password in
- cleartext, but rather can store the value prf(Shared Secret,"Key Pad
- for IKEv2"), which could not be used as a password equivalent for
- protocols other than IKEv2. As noted above, deriving the shared
- secret from a password is not secure. This construction is used
- because it is anticipated that people will do it anyway. The
-
-
-
-Kaufman Standards Track [Page 30]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- management interface by which the Shared Secret is provided MUST
- accept ASCII strings of at least 64 octets and MUST NOT add a null
- terminator before using them as shared secrets. It MUST also accept
- a HEX encoding of the Shared Secret. The management interface MAY
- accept other encodings if the algorithm for translating the encoding
- to a binary string is specified. If the negotiated prf takes a
- fixed-size key, the shared secret MUST be of that fixed size.
-
-2.16. Extensible Authentication Protocol Methods
-
- In addition to authentication using public key signatures and shared
- secrets, IKE supports authentication using methods defined in RFC
- 3748 [EAP]. Typically, these methods are asymmetric (designed for a
- user authenticating to a server), and they may not be mutual. For
- this reason, these protocols are typically used to authenticate the
- initiator to the responder and MUST be used in conjunction with a
- public key signature based authentication of the responder to the
- initiator. These methods are often associated with mechanisms
- referred to as "Legacy Authentication" mechanisms.
-
- While this memo references [EAP] with the intent that new methods can
- be added in the future without updating this specification, some
- simpler variations are documented here and in section 3.16. [EAP]
- defines an authentication protocol requiring a variable number of
- messages. Extensible Authentication is implemented in IKE as
- additional IKE_AUTH exchanges that MUST be completed in order to
- initialize the IKE_SA.
-
- An initiator indicates a desire to use extensible authentication by
- leaving out the AUTH payload from message 3. By including an IDi
- payload but not an AUTH payload, the initiator has declared an
- identity but has not proven it. If the responder is willing to use
- an extensible authentication method, it will place an Extensible
- Authentication Protocol (EAP) payload in message 4 and defer sending
- SAr2, TSi, and TSr until initiator authentication is complete in a
- subsequent IKE_AUTH exchange. In the case of a minimal extensible
- authentication, the initial SA establishment will appear as follows:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 31]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- Initiator Responder
- ----------- -----------
- HDR, SAi1, KEi, Ni -->
-
- <-- HDR, SAr1, KEr, Nr, [CERTREQ]
-
- HDR, SK {IDi, [CERTREQ,] [IDr,]
- SAi2, TSi, TSr} -->
-
- <-- HDR, SK {IDr, [CERT,] AUTH,
- EAP }
-
- HDR, SK {EAP} -->
-
- <-- HDR, SK {EAP (success)}
-
- HDR, SK {AUTH} -->
-
- <-- HDR, SK {AUTH, SAr2, TSi, TSr }
-
- For EAP methods that create a shared key as a side effect of
- authentication, that shared key MUST be used by both the initiator
- and responder to generate AUTH payloads in messages 7 and 8 using the
- syntax for shared secrets specified in section 2.15. The shared key
- from EAP is the field from the EAP specification named MSK. The
- shared key generated during an IKE exchange MUST NOT be used for any
- other purpose.
-
- 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. Please see the Security Considerations
- section for more details. If EAP methods that do not generate a
- shared key are used, the AUTH payloads in messages 7 and 8 MUST be
- generated using SK_pi and SK_pr, respectively.
-
- The initiator of an IKE_SA using EAP SHOULD be capable of extending
- the initial protocol exchange to at least ten IKE_AUTH exchanges in
- the event the responder sends notification messages and/or retries
- the authentication prompt. Once the protocol exchange defined by the
- chosen EAP authentication method has successfully terminated, the
- responder MUST send an EAP payload containing the Success message.
- Similarly, if the authentication method has failed, the responder
- MUST send an EAP payload containing the Failure message. The
- responder MAY at any time terminate the IKE exchange by sending an
- EAP payload containing the Failure message.
-
-
-
-
-
-Kaufman Standards Track [Page 32]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- Following such an extended exchange, the EAP AUTH payloads MUST be
- included in the two messages following the one containing the EAP
- Success message.
-
-2.17. Generating Keying Material for CHILD_SAs
-
- A single CHILD_SA is created by the IKE_AUTH exchange, and additional
- CHILD_SAs can optionally be created in CREATE_CHILD_SA exchanges.
- Keying material for them is generated as follows:
-
- KEYMAT = prf+(SK_d, Ni | Nr)
-
- Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this
- request is the first CHILD_SA created or the fresh Ni and Nr from the
- CREATE_CHILD_SA exchange if this is a subsequent creation.
-
- For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman
- exchange, the keying material is defined as:
-
- KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )
-
- where g^ir (new) is the shared secret from the ephemeral Diffie-
- Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
- octet string in big endian order padded with zeros in the high-order
- bits if necessary to make it the length of the modulus).
-
- A single CHILD_SA negotiation may result in multiple security
- associations. ESP and AH SAs exist in pairs (one in each direction),
- and four SAs could be created in a single CHILD_SA negotiation if a
- combination of ESP and AH is being negotiated.
-
- Keying material MUST be taken from the expanded KEYMAT in the
- following order:
-
- All keys for SAs carrying data from the initiator to the responder
- are taken before SAs going in the reverse direction.
-
- If multiple IPsec protocols are negotiated, keying material is
- taken in the order in which the protocol headers will appear in
- the encapsulated packet.
-
- If a single protocol has both encryption and authentication keys,
- the encryption key is taken from the first octets of KEYMAT and
- the authentication key is taken from the next octets.
-
- Each cryptographic algorithm takes a fixed number of bits of keying
- material specified as part of the algorithm.
-
-
-
-
-Kaufman Standards Track [Page 33]
-\f
-RFC 4306 IKEv2 December 2005
-
-
-2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA exchange
-
- The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA
- (see section 2.8). New initiator and responder SPIs are supplied in
- the SPI fields. The TS payloads are omitted when rekeying an IKE_SA.
- SKEYSEED for the new IKE_SA is computed using SK_d from the existing
- IKE_SA as follows:
-
- SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)
-
- where g^ir (new) is the shared secret from the ephemeral Diffie-
- Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
- octet string in big endian order padded with zeros if necessary to
- make it the length of the modulus) and Ni and Nr are the two nonces
- stripped of any headers.
-
- The new IKE_SA MUST reset its message counters to 0.
-
- SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as
- specified in section 2.14.
-
-2.19. Requesting an Internal Address on a Remote Network
-
- Most commonly occurring in the endpoint-to-security-gateway scenario,
- an endpoint may need an IP address in the network protected by the
- security gateway and may need to have that address dynamically
- assigned. A request for such a temporary address can be included in
- any request to create a CHILD_SA (including the implicit request in
- message 3) by including a CP payload.
-
- This function provides address allocation to an IPsec Remote Access
- Client (IRAC) trying to tunnel into a network protected by an IPsec
- Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an
- IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS-controlled
- address (and optionally other information concerning the protected
- network) in the IKE_AUTH exchange. The IRAS may procure an address
- for the IRAC from any number of sources such as a DHCP/BOOTP server
- or its own address pool.
-
- Initiator Responder
- ----------------------------- ---------------------------
- HDR, SK {IDi, [CERT,] [CERTREQ,]
- [IDr,] AUTH, CP(CFG_REQUEST),
- SAi2, TSi, TSr} -->
-
- <-- HDR, SK {IDr, [CERT,] AUTH,
- CP(CFG_REPLY), SAr2,
- TSi, TSr}
-
-
-
-Kaufman Standards Track [Page 34]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- In all cases, the CP payload MUST be inserted before the SA payload.
- In variations of the protocol where there are multiple IKE_AUTH
- exchanges, the CP payloads MUST be inserted in the messages
- containing the SA payloads.
-
- CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute
- (either IPv4 or IPv6) but MAY contain any number of additional
- attributes the initiator wants returned in the response.
-
- For example, message from initiator to responder:
- CP(CFG_REQUEST)=
- INTERNAL_ADDRESS(0.0.0.0)
- INTERNAL_NETMASK(0.0.0.0)
- INTERNAL_DNS(0.0.0.0)
- TSi = (0, 0-65535,0.0.0.0-255.255.255.255)
- TSr = (0, 0-65535,0.0.0.0-255.255.255.255)
-
- NOTE: Traffic Selectors contain (protocol, port range, address
- range).
-
- Message from responder to initiator:
-
- CP(CFG_REPLY)=
- INTERNAL_ADDRESS(192.0.2.202)
- INTERNAL_NETMASK(255.255.255.0)
- INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
- TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
- TSr = (0, 0-65535,192.0.2.0-192.0.2.255)
-
- All returned values will be implementation dependent. As can be seen
- in the above example, the IRAS MAY also send other attributes that
- were not included in CP(CFG_REQUEST) and MAY ignore the non-mandatory
- attributes that it does not support.
-
- The responder MUST NOT send a CFG_REPLY without having first received
- a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS
- to perform an unnecessary configuration lookup if the IRAC cannot
- process the REPLY. In the case where the IRAS's configuration
- requires that CP be used for a given identity IDi, but IRAC has
- failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and
- terminate the IKE exchange with a FAILED_CP_REQUIRED error.
-
-2.20. Requesting the Peer's Version
-
- An IKE peer wishing to inquire about the other peer's IKE software
- version information MAY use the method below. This is an example of
- a configuration request within an INFORMATIONAL exchange, after the
- IKE_SA and first CHILD_SA have been created.
-
-
-
-Kaufman Standards Track [Page 35]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- An IKE implementation MAY decline to give out version information
- prior to authentication or even after authentication to prevent
- trolling in case some implementation is known to have some security
- weakness. In that case, it MUST either return an empty string or no
- CP payload if CP is not supported.
-
- Initiator Responder
- ----------------------------- --------------------------
- HDR, SK{CP(CFG_REQUEST)} -->
- <-- HDR, SK{CP(CFG_REPLY)}
-
- CP(CFG_REQUEST)=
- APPLICATION_VERSION("")
-
- CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar
- Inc.")
-
-2.21. Error Handling
-
- There are many kinds of errors that can occur during IKE processing.
- If a request is received that is badly formatted or unacceptable for
- reasons of policy (e.g., no matching cryptographic algorithms), the
- response MUST contain a Notify payload indicating the error. If an
- error occurs outside the context of an IKE request (e.g., the node is
- getting ESP messages on a nonexistent SPI), the node SHOULD initiate
- an INFORMATIONAL exchange with a Notify payload describing the
- problem.
-
- Errors that occur before a cryptographically protected IKE_SA is
- established must be handled very carefully. There is a trade-off
- between wanting to be helpful in diagnosing a problem and responding
- to it and wanting to avoid being a dupe in a denial of service attack
- based on forged messages.
-
- If a node receives a message on UDP port 500 or 4500 outside the
- context of an IKE_SA known to it (and not a request to start one), it
- may be the result of a recent crash of the node. If the message is
- marked as a response, the node MAY audit the suspicious event but
- MUST NOT respond. If the message is marked as a request, the node
- MAY audit the suspicious event and MAY send a response. If a
- response is sent, the response MUST be sent to the IP address and
- port from whence it came with the same IKE SPIs and the Message ID
- copied. The response MUST NOT be cryptographically protected and
- MUST contain a Notify payload indicating INVALID_IKE_SPI.
-
- A node receiving such an unprotected Notify payload MUST NOT respond
- and MUST NOT change the state of any existing SAs. The message might
- be a forgery or might be a response the genuine correspondent was
-
-
-
-Kaufman Standards Track [Page 36]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- tricked into sending. A node SHOULD treat such a message (and also a
- network message like ICMP destination unreachable) as a hint that
- there might be problems with SAs to that IP address and SHOULD
- initiate a liveness test for any such IKE_SA. An implementation
- SHOULD limit the frequency of such tests to avoid being tricked into
- participating in a denial of service attack.
-
- A node receiving a suspicious message from an IP address with which
- it has an IKE_SA MAY send an IKE Notify payload in an IKE
- INFORMATIONAL exchange over that SA. The recipient MUST NOT change
- the state of any SA's as a result but SHOULD audit the event to aid
- in diagnosing malfunctions. A node MUST limit the rate at which it
- will send messages in response to unprotected messages.
-
-2.22. IPComp
-
- Use of IP compression [IPCOMP] can be negotiated as part of the setup
- of a CHILD_SA. While IP compression involves an extra header in each
- packet and a compression parameter index (CPI), the virtual
- "compression association" has no life outside the ESP or AH SA that
- contains it. Compression associations disappear when the
- corresponding ESP or AH SA goes away. It is not explicitly mentioned
- in any DELETE payload.
-
- Negotiation of IP compression is separate from the negotiation of
- cryptographic parameters associated with a CHILD_SA. A node
- requesting a CHILD_SA MAY advertise its support for one or more
- compression algorithms through one or more Notify payloads of type
- IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single
- compression algorithm with a Notify payload of type IPCOMP_SUPPORTED.
- These payloads MUST NOT occur in messages that do not contain SA
- payloads.
-
- Although there has been discussion of allowing multiple compression
- algorithms to be accepted and to have different compression
- algorithms available for the two directions of a CHILD_SA,
- implementations of this specification MUST NOT accept an IPComp
- algorithm that was not proposed, MUST NOT accept more than one, and
- MUST NOT compress using an algorithm other than one proposed and
- accepted in the setup of the CHILD_SA.
-
- A side effect of separating the negotiation of IPComp from
- cryptographic parameters is that it is not possible to propose
- multiple cryptographic suites and propose IP compression with some of
- them but not others.
-
-
-
-
-
-
-Kaufman Standards Track [Page 37]
-\f
-RFC 4306 IKEv2 December 2005
-
-
-2.23. NAT Traversal
-
- Network Address Translation (NAT) gateways are a controversial
- subject. This section briefly describes what they are and how they
- are likely to act on IKE traffic. Many people believe that NATs are
- evil and that we should not design our protocols so as to make them
- work better. IKEv2 does specify some unintuitive processing rules in
- order that NATs are more likely to work.
-
- NATs exist primarily because of the shortage of IPv4 addresses,
- though there are other rationales. IP nodes that are "behind" a NAT
- have IP addresses that are not globally unique, but rather are
- assigned from some space that is unique within the network behind the
- NAT but that are likely to be reused by nodes behind other NATs.
- Generally, nodes behind NATs can communicate with other nodes behind
- the same NAT and with nodes with globally unique addresses, but not
- with nodes behind other NATs. There are exceptions to that rule.
- When those nodes make connections to nodes on the real Internet, the
- NAT gateway "translates" the IP source address to an address that
- will be routed back to the gateway. Messages to the gateway from the
- Internet have their destination addresses "translated" to the
- internal address that will route the packet to the correct endnode.
-
- NATs are designed to be "transparent" to endnodes. Neither software
- on the node behind the NAT nor the node on the Internet requires
- modification to communicate through the NAT. Achieving this
- transparency is more difficult with some protocols than with others.
- Protocols that include IP addresses of the endpoints within the
- payloads of the packet will fail unless the NAT gateway understands
- the protocol and modifies the internal references as well as those in
- the headers. Such knowledge is inherently unreliable, is a network
- layer violation, and often results in subtle problems.
-
- Opening an IPsec connection through a NAT introduces special
- problems. If the connection runs in transport mode, changing the IP
- addresses on packets will cause the checksums to fail and the NAT
- cannot correct the checksums because they are cryptographically
- protected. Even in tunnel mode, there are routing problems because
- transparently translating the addresses of AH and ESP packets
- requires special logic in the NAT and that logic is heuristic and
- unreliable in nature. For that reason, IKEv2 can negotiate UDP
- encapsulation of IKE and ESP packets. This encoding is slightly less
- efficient but is easier for NATs to process. In addition, firewalls
- may be configured to pass IPsec traffic over UDP but not ESP/AH or
- vice versa.
-
-
-
-
-
-
-Kaufman Standards Track [Page 38]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- It is a common practice of NATs to translate TCP and UDP port numbers
- as well as addresses and use the port numbers of inbound packets to
- decide which internal node should get a given packet. For this
- reason, even though IKE packets MUST be sent from and to UDP port
- 500, they MUST be accepted coming from any port and responses MUST be
- sent to the port from whence they came. This is because the ports
- may be modified as the packets pass through NATs. Similarly, IP
- addresses of the IKE endpoints are generally not included in the IKE
- payloads because the payloads are cryptographically protected and
- could not be transparently modified by NATs.
-
- Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working
- through a NAT, it is generally better to pass IKE packets over port
- 4500 because some older NATs handle IKE traffic on port 500 cleverly
- in an attempt to transparently establish IPsec connections between
- endpoints that don't handle NAT traversal themselves. Such NATs may
- interfere with the straightforward NAT traversal envisioned by this
- document, so an IPsec endpoint that discovers a NAT between it and
- its correspondent MUST send all subsequent traffic to and from port
- 4500, which NATs should not treat specially (as they might with port
- 500).
-
- The specific requirements for supporting NAT traversal [RFC3715] are
- listed below. Support for NAT traversal is optional. In this
- section only, requirements listed as MUST apply only to
- implementations supporting NAT traversal.
-
- IKE MUST listen on port 4500 as well as port 500. IKE MUST
- respond to the IP address and port from which packets arrived.
-
- Both IKE initiator and responder MUST include in their IKE_SA_INIT
- packets Notify payloads of type NAT_DETECTION_SOURCE_IP and
- NAT_DETECTION_DESTINATION_IP. Those payloads can be used to
- detect if there is NAT between the hosts, and which end is behind
- the NAT. The location of the payloads in the IKE_SA_INIT packets
- are just after the Ni and Nr payloads (before the optional CERTREQ
- payload).
-
- If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches
- the hash of the source IP and port found from the IP header of the
- packet containing the payload, it means that the other end is
- behind NAT (i.e., someone along the route changed the source
- address of the original packet to match the address of the NAT
- box). In this case, this end should allow dynamic update of the
- other ends IP address, as described later.
-
-
-
-
-
-
-Kaufman Standards Track [Page 39]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- If the NAT_DETECTION_DESTINATION_IP payload received does not
- match the hash of the destination IP and port found from the IP
- header of the packet containing the payload, it means that this
- end is behind a NAT. In this case, this end SHOULD start sending
- keepalive packets as explained in [Hutt05].
-
- The IKE initiator MUST check these payloads if present and if they
- do not match the addresses in the outer packet MUST tunnel all
- future IKE and ESP packets associated with this IKE_SA over UDP
- port 4500.
-
- To tunnel IKE packets over UDP port 4500, the IKE header has four
- octets of zero prepended and the result immediately follows the
- UDP header. To tunnel ESP packets over UDP port 4500, the ESP
- header immediately follows the UDP header. Since the first four
- bytes of the ESP header contain the SPI, and the SPI cannot
- validly be zero, it is always possible to distinguish ESP and IKE
- messages.
-
- The original source and destination IP address required for the
- transport mode TCP and UDP packet checksum fixup (see [Hutt05])
- are obtained from the Traffic Selectors associated with the
- exchange. In the case of NAT traversal, the Traffic Selectors
- MUST contain exactly one IP address, which is then used as the
- original IP address.
-
- There are cases where a NAT box decides to remove mappings that
- are still alive (for example, the keepalive interval is too long,
- or the NAT box is rebooted). To recover in these cases, hosts
- that are not behind a NAT SHOULD send all packets (including
- retransmission packets) to the IP address and port from the last
- valid authenticated packet from the other end (i.e., dynamically
- update the address). A host behind a NAT SHOULD NOT do this
- because it opens a DoS attack possibility. Any authenticated IKE
- packet or any authenticated UDP-encapsulated ESP packet can be
- used to detect that the IP address or the port has changed.
-
- Note that similar but probably not identical actions will likely
- be needed to make IKE work with Mobile IP, but such processing is
- not addressed by this document.
-
-2.24. Explicit Congestion Notification (ECN)
-
- When IPsec tunnels behave as originally specified in [RFC2401], ECN
- usage is not appropriate for the outer IP headers because tunnel
- decapsulation processing discards ECN congestion indications to the
- detriment of the network. ECN support for IPsec tunnels for IKEv1-
- based IPsec requires multiple operating modes and negotiation (see
-
-
-
-Kaufman Standards Track [Page 40]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- [RFC3168]). IKEv2 simplifies this situation by requiring that ECN be
- usable in the outer IP headers of all tunnel-mode IPsec SAs created
- by IKEv2. Specifically, tunnel encapsulators and decapsulators for
- all tunnel-mode SAs created by IKEv2 MUST support the ECN full-
- functionality option for tunnels specified in [RFC3168] and MUST
- implement the tunnel encapsulation and decapsulation processing
- specified in [RFC4301] to prevent discarding of ECN congestion
- indications.
-
-3. Header and Payload Formats
-
-3.1. The IKE Header
-
- IKE messages use UDP ports 500 and/or 4500, with one IKE message per
- UDP datagram. Information from the beginning of the packet through
- the UDP header is largely ignored except that the IP addresses and
- UDP ports from the headers are reversed and used for return packets.
- When sent on UDP port 500, IKE messages begin immediately following
- the UDP header. When sent on UDP port 4500, IKE messages have
- prepended four octets of zero. These four octets of zero are not
- part of the IKE message and are not included in any of the length
- fields or checksums defined by IKE. Each IKE message begins with the
- IKE header, denoted HDR in this memo. Following the header are one
- or more IKE payloads each identified by a "Next Payload" field in the
- preceding payload. Payloads are processed in the order in which they
- appear in an IKE message by invoking the appropriate processing
- routine according to the "Next Payload" field in the IKE header and
- subsequently according to the "Next Payload" field in the IKE payload
- itself until a "Next Payload" field of zero indicates that no
- payloads follow. If a payload of type "Encrypted" is found, that
- payload is decrypted and its contents parsed as additional payloads.
- An Encrypted payload MUST be the last payload in a packet and an
- Encrypted payload MUST NOT contain another Encrypted payload.
-
- The Recipient SPI in the header identifies an instance of an IKE
- security association. It is therefore possible for a single instance
- of IKE to multiplex distinct sessions with multiple peers.
-
- All multi-octet fields representing integers are laid out in big
- endian order (aka most significant byte first, or network byte
- order).
-
- The format of the IKE header is shown in Figure 4.
-
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 41]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! IKE_SA Initiator's SPI !
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! IKE_SA Responder's SPI !
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Message ID !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Length !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 4: IKE Header Format
-
- o Initiator's SPI (8 octets) - A value chosen by the
- initiator to identify a unique IKE security association. This
- value MUST NOT be zero.
-
- o Responder's SPI (8 octets) - A value chosen by the
- responder to identify a unique IKE security association. This
- value MUST be zero in the first message of an IKE Initial
- Exchange (including repeats of that message including a
- cookie) and MUST NOT be zero in any other message.
-
- o Next Payload (1 octet) - Indicates the type of payload that
- immediately follows the header. The format and value of each
- payload are defined below.
-
- o Major Version (4 bits) - Indicates the major version of the IKE
- protocol in use. Implementations based on this version of IKE
- MUST set the Major Version to 2. Implementations based on
- previous versions of IKE and ISAKMP MUST set the Major Version
- to 1. Implementations based on this version of IKE MUST reject
- or ignore messages containing a version number greater than
- 2.
-
- o Minor Version (4 bits) - Indicates the minor version of the
- IKE protocol in use. Implementations based on this version of
- IKE MUST set the Minor Version to 0. They MUST ignore the
- minor version number of received messages.
-
- o Exchange Type (1 octet) - Indicates the type of exchange being
- used. This constrains the payloads sent in each message and
- orderings of messages in an exchange.
-
-
-
-Kaufman Standards Track [Page 42]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- Exchange Type Value
-
- RESERVED 0-33
- IKE_SA_INIT 34
- IKE_AUTH 35
- CREATE_CHILD_SA 36
- INFORMATIONAL 37
- RESERVED TO IANA 38-239
- Reserved for private use 240-255
-
- o Flags (1 octet) - Indicates specific options that are set
- for the message. Presence of options are indicated by the
- appropriate bit in the flags field being set. The bits are
- defined LSB first, so bit 0 would be the least significant
- bit of the Flags octet. In the description below, a bit
- being 'set' means its value is '1', while 'cleared' means
- its value is '0'.
-
- -- X(reserved) (bits 0-2) - These bits MUST be cleared
- when sending and MUST be ignored on receipt.
-
- -- I(nitiator) (bit 3 of Flags) - This bit MUST be set in
- messages sent by the original initiator of the IKE_SA
- and MUST be cleared in messages sent by the original
- responder. It is used by the recipient to determine
- which eight octets of the SPI were generated by the
- recipient.
-
- -- V(ersion) (bit 4 of Flags) - This bit indicates that
- the transmitter is capable of speaking a higher major
- version number of the protocol than the one indicated
- in the major version number field. Implementations of
- IKEv2 must clear this bit when sending and MUST ignore
- it in incoming messages.
-
- -- R(esponse) (bit 5 of Flags) - This bit indicates that
- this message is a response to a message containing
- the same message ID. This bit MUST be cleared in all
- request messages and MUST be set in all responses.
- An IKE endpoint MUST NOT generate a response to a
- message that is marked as being a response.
-
- -- X(reserved) (bits 6-7 of Flags) - These bits MUST be
- cleared when sending and MUST be ignored on receipt.
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 43]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- o Message ID (4 octets) - Message identifier used to control
- retransmission of lost packets and matching of requests and
- responses. It is essential to the security of the protocol
- because it is used to prevent message replay attacks.
- See sections 2.1 and 2.2.
-
- o Length (4 octets) - Length of total message (header + payloads)
- in octets.
-
-3.2. Generic Payload Header
-
- Each IKE payload defined in sections 3.3 through 3.16 begins with a
- generic payload header, shown in Figure 5. Figures for each payload
- below will include the generic payload header, but for brevity the
- description of each field will be omitted.
-
- 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 !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 5: Generic Payload Header
-
- The Generic Payload Header fields are defined as follows:
-
- o Next Payload (1 octet) - Identifier for the payload type of the
- next payload in the message. If the current payload is the last
- in the message, then this field will be 0. This field provides a
- "chaining" capability whereby additional payloads can be added to
- a message by appending it to the end of the message and setting
- the "Next Payload" field of the preceding payload to indicate the
- new payload's type. An Encrypted payload, which must always be
- the last payload of a message, is an exception. It contains data
- structures in the format of additional payloads. In the header of
- an Encrypted payload, the Next Payload field is set to the payload
- type of the first contained payload (instead of 0).
-
- Payload Type Values
-
- Next Payload Type Notation Value
-
- No Next Payload 0
-
- RESERVED 1-32
- Security Association SA 33
- Key Exchange KE 34
- Identification - Initiator IDi 35
-
-
-
-Kaufman Standards Track [Page 44]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- Identification - Responder IDr 36
- Certificate CERT 37
- Certificate Request CERTREQ 38
- Authentication AUTH 39
- Nonce Ni, Nr 40
- Notify N 41
- Delete D 42
- Vendor ID V 43
- Traffic Selector - Initiator TSi 44
- Traffic Selector - Responder TSr 45
- Encrypted E 46
- Configuration CP 47
- Extensible Authentication EAP 48
- RESERVED TO IANA 49-127
- PRIVATE USE 128-255
-
- Payload type values 1-32 should not be used so that there is no
- overlap with the code assignments for IKEv1. Payload type values
- 49-127 are reserved to IANA for future assignment in IKEv2 (see
- section 6). Payload type values 128-255 are for private use among
- mutually consenting parties.
-
- o Critical (1 bit) - MUST be set to zero if the sender wants the
- recipient to skip this payload if it does not understand the
- payload type code in the Next Payload field of the previous
- payload. MUST be set to one if the sender wants the recipient to
- reject this entire message if it does not understand the payload
- type. MUST be ignored by the recipient if the recipient
- understands the payload type code. MUST be set to zero for
- payload types defined in this document. Note that the critical
- bit applies to the current payload rather than the "next" payload
- whose type code appears in the first octet. The reasoning behind
- not setting the critical bit for payloads defined in this document
- is that all implementations MUST understand all payload types
- defined in this document and therefore must ignore the Critical
- bit's value. Skipped payloads are expected to have valid Next
- Payload and Payload Length fields.
-
- o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on
- receipt.
-
- o Payload Length (2 octets) - Length in octets of the current
- payload, including the generic payload header.
-
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 45]
-\f
-RFC 4306 IKEv2 December 2005
-
-
-3.3. Security Association Payload
-
- The Security Association Payload, denoted SA in this memo, is used to
- negotiate attributes of a security association. Assembly of Security
- Association Payloads requires great peace of mind. An SA payload MAY
- contain multiple proposals. If there is more than one, they MUST be
- ordered from most preferred to least preferred. Each proposal may
- contain multiple IPsec protocols (where a protocol is IKE, ESP, or
- AH), each protocol MAY contain multiple transforms, and each
- transform MAY contain multiple attributes. When parsing an SA, an
- implementation MUST check that the total Payload Length is consistent
- with the payload's internal lengths and counts. Proposals,
- Transforms, and Attributes each have their own variable length
- encodings. They are nested such that the Payload Length of an SA
- includes the combined contents of the SA, Proposal, Transform, and
- Attribute information. The length of a Proposal includes the lengths
- of all Transforms and Attributes it contains. The length of a
- Transform includes the lengths of all Attributes it contains.
-
- The syntax of Security Associations, Proposals, Transforms, and
- Attributes is based on ISAKMP; however, the semantics are somewhat
- different. The reason for the complexity and the hierarchy is to
- allow for multiple possible combinations of algorithms to be encoded
- in a single SA. Sometimes there is a choice of multiple algorithms,
- whereas other times there is a combination of algorithms. For
- example, an initiator might want to propose using (AH w/MD5 and ESP
- w/3DES) OR (ESP w/MD5 and 3DES).
-
- One of the reasons the semantics of the SA payload has changed from
- ISAKMP and IKEv1 is to make the encodings more compact in common
- cases.
-
- The Proposal structure contains within it a Proposal # and an IPsec
- protocol ID. Each structure MUST have the same Proposal # as the
- previous one or be one (1) greater. The first Proposal MUST have a
- Proposal # of one (1). If two successive structures have the same
- Proposal number, it means that the proposal consists of the first
- structure AND the second. So a proposal of AH AND ESP would have two
- proposal structures, one for AH and one for ESP and both would have
- Proposal #1. A proposal of AH OR ESP would have two proposal
- structures, one for AH with Proposal #1 and one for ESP with Proposal
- #2.
-
- Each Proposal/Protocol structure is followed by one or more transform
- structures. The number of different transforms is generally
- determined by the Protocol. AH generally has a single transform: an
- integrity check algorithm. ESP generally has two: an encryption
- algorithm and an integrity check algorithm. IKE generally has four
-
-
-
-Kaufman Standards Track [Page 46]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- transforms: a Diffie-Hellman group, an integrity check algorithm, a
- prf algorithm, and an encryption algorithm. If an algorithm that
- combines encryption and integrity protection is proposed, it MUST be
- proposed as an encryption algorithm and an integrity protection
- algorithm MUST NOT be proposed. For each Protocol, the set of
- permissible transforms is assigned transform ID numbers, which appear
- in the header of each transform.
-
- If there are multiple transforms with the same Transform Type, the
- proposal is an OR of those transforms. If there are multiple
- Transforms with different Transform Types, the proposal is an AND of
- the different groups. For example, to propose ESP with (3DES or
- IDEA) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two
- Transform Type 1 candidates (one for 3DES and one for IDEA) and two
- Transform Type 2 candidates (one for HMAC_MD5 and one for HMAC_SHA).
- This effectively proposes four combinations of algorithms. If the
- initiator wanted to propose only a subset of those, for example (3DES
- and HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that
- as multiple transforms within a single Proposal. Instead, the
- initiator would have to construct two different Proposals, each with
- two transforms.
-
- A given transform MAY have one or more Attributes. Attributes are
- necessary when the transform can be used in more than one way, as
- when an encryption algorithm has a variable key size. The transform
- would specify the algorithm and the attribute would specify the key
- size. Most transforms do not have attributes. A transform MUST NOT
- have multiple attributes of the same type. To propose alternate
- values for an attribute (for example, multiple key sizes for the AES
- encryption algorithm), and implementation MUST include multiple
- Transforms with the same Transform Type each with a single Attribute.
-
- Note that the semantics of Transforms and Attributes are quite
- different from those in IKEv1. In IKEv1, a single Transform carried
- multiple algorithms for a protocol with one carried in the Transform
- and the others carried in the Attributes.
-
- 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 !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ <Proposals> ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 6: Security Association Payload
-
-
-
-Kaufman Standards Track [Page 47]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- o Proposals (variable) - One or more proposal substructures.
-
- The payload type for the Security Association Payload is thirty
- three (33).
-
-3.3.1. Proposal Substructure
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! 0 (last) or 2 ! RESERVED ! Proposal Length !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Proposal # ! Protocol ID ! SPI Size !# of Transforms!
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ~ SPI (variable) ~
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ <Transforms> ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 7: Proposal Substructure
-
- o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the
- last Proposal Substructure in the SA. This syntax is inherited
- from ISAKMP, but is unnecessary because the last Proposal could
- be identified from the length of the SA. The value (2)
- corresponds to a Payload Type of Proposal in IKEv1, and the
- first 4 octets of the Proposal structure are designed to look
- somewhat like the header of a Payload.
-
- o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on
- receipt.
-
- o Proposal Length (2 octets) - Length of this proposal, including
- all transforms and attributes that follow.
-
- o Proposal # (1 octet) - When a proposal is made, the first
- proposal in an SA payload MUST be #1, and subsequent proposals
- MUST either be the same as the previous proposal (indicating an
- AND of the two proposals) or one more than the previous
- proposal (indicating an OR of the two proposals). When a
- proposal is accepted, all of the proposal numbers in the SA
- payload MUST be the same and MUST match the number on the
- proposal sent that was accepted.
-
-
-
-
-
-
-Kaufman Standards Track [Page 48]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- o Protocol ID (1 octet) - Specifies the IPsec protocol identifier
- for the current negotiation. The defined values are:
-
- Protocol Protocol ID
- RESERVED 0
- IKE 1
- AH 2
- ESP 3
- RESERVED TO IANA 4-200
- PRIVATE USE 201-255
-
- o SPI Size (1 octet) - For an initial IKE_SA negotiation, this
- field MUST be zero; the SPI is obtained from the outer header.
- During subsequent negotiations, it is equal to the size, in
- octets, of the SPI of the corresponding protocol (8 for IKE, 4
- for ESP and AH).
-
- o # of Transforms (1 octet) - Specifies the number of transforms
- in this proposal.
-
- o SPI (variable) - The sending entity's SPI. Even if the SPI Size
- is not a multiple of 4 octets, there is no padding applied to
- the payload. When the SPI Size field is zero, this field is
- not present in the Security Association payload.
-
- o Transforms (variable) - One or more transform substructures.
-
-3.3.2. Transform Substructure
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! 0 (last) or 3 ! RESERVED ! Transform Length !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- !Transform Type ! RESERVED ! Transform ID !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ Transform Attributes ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 8: Transform Substructure
-
- o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the
- last Transform Substructure in the Proposal. This syntax is
- inherited from ISAKMP, but is unnecessary because the last
- Proposal could be identified from the length of the SA. The
-
-
-
-
-Kaufman Standards Track [Page 49]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- value (3) corresponds to a Payload Type of Transform in IKEv1,
- and the first 4 octets of the Transform structure are designed
- to look somewhat like the header of a Payload.
-
- o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
-
- o Transform Length - The length (in octets) of the Transform
- Substructure including Header and Attributes.
-
- o Transform Type (1 octet) - The type of transform being
- specified in this transform. Different protocols support
- different transform types. For some protocols, some of the
- transforms may be optional. If a transform is optional and the
- initiator wishes to propose that the transform be omitted, no
- transform of the given type is included in the proposal. If
- the initiator wishes to make use of the transform optional to
- the responder, it includes a transform substructure with
- transform ID = 0 as one of the options.
-
- o Transform ID (2 octets) - The specific instance of the
- transform type being proposed.
-
- Transform Type Values
-
- Transform Used In
- Type
- RESERVED 0
- Encryption Algorithm (ENCR) 1 (IKE and ESP)
- Pseudo-random Function (PRF) 2 (IKE)
- Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP)
- Diffie-Hellman Group (D-H) 4 (IKE, optional in AH & ESP)
- Extended Sequence Numbers (ESN) 5 (AH and ESP)
- RESERVED TO IANA 6-240
- PRIVATE USE 241-255
-
- For Transform Type 1 (Encryption Algorithm), defined Transform IDs
- are:
-
- Name Number Defined In
- RESERVED 0
- ENCR_DES_IV64 1 (RFC1827)
- ENCR_DES 2 (RFC2405), [DES]
- ENCR_3DES 3 (RFC2451)
- ENCR_RC5 4 (RFC2451)
- ENCR_IDEA 5 (RFC2451), [IDEA]
- ENCR_CAST 6 (RFC2451)
- ENCR_BLOWFISH 7 (RFC2451)
- ENCR_3IDEA 8 (RFC2451)
-
-
-
-Kaufman Standards Track [Page 50]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- ENCR_DES_IV32 9
- RESERVED 10
- ENCR_NULL 11 (RFC2410)
- ENCR_AES_CBC 12 (RFC3602)
- ENCR_AES_CTR 13 (RFC3664)
-
- values 14-1023 are reserved to IANA. Values 1024-65535 are
- for private use among mutually consenting parties.
-
- For Transform Type 2 (Pseudo-random Function), defined Transform IDs
- are:
-
- Name Number Defined In
- RESERVED 0
- PRF_HMAC_MD5 1 (RFC2104), [MD5]
- PRF_HMAC_SHA1 2 (RFC2104), [SHA]
- PRF_HMAC_TIGER 3 (RFC2104)
- PRF_AES128_XCBC 4 (RFC3664)
-
- values 5-1023 are reserved to IANA. Values 1024-65535 are for
- private use among mutually consenting parties.
-
- For Transform Type 3 (Integrity Algorithm), defined Transform IDs
- are:
-
- Name Number Defined In
- NONE 0
- AUTH_HMAC_MD5_96 1 (RFC2403)
- AUTH_HMAC_SHA1_96 2 (RFC2404)
- AUTH_DES_MAC 3
- AUTH_KPDK_MD5 4 (RFC1826)
- AUTH_AES_XCBC_96 5 (RFC3566)
-
- values 6-1023 are reserved to IANA. Values 1024-65535 are for
- private use among mutually consenting parties.
-
- For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs
- are:
-
- Name Number
- NONE 0
- Defined in Appendix B 1 - 2
- RESERVED 3 - 4
- Defined in [ADDGROUP] 5
- RESERVED TO IANA 6 - 13
- Defined in [ADDGROUP] 14 - 18
- RESERVED TO IANA 19 - 1023
- PRIVATE USE 1024-65535
-
-
-
-Kaufman Standards Track [Page 51]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- For Transform Type 5 (Extended Sequence Numbers), defined Transform
- IDs are:
-
- Name Number
- No Extended Sequence Numbers 0
- Extended Sequence Numbers 1
- RESERVED 2 - 65535
-
-3.3.3. Valid Transform Types by Protocol
-
- The number and type of transforms that accompany an SA payload are
- dependent on the protocol in the SA itself. An SA payload proposing
- the establishment of an SA has the following mandatory and optional
- transform types. A compliant implementation MUST understand all
- mandatory and optional types for each protocol it supports (though it
- need not accept proposals with unacceptable suites). A proposal MAY
- omit the optional types if the only value for them it will accept is
- NONE.
-
- Protocol Mandatory Types Optional Types
- IKE ENCR, PRF, INTEG, D-H
- ESP ENCR, ESN INTEG, D-H
- AH INTEG, ESN D-H
-
-3.3.4. Mandatory Transform IDs
-
- The specification of suites that MUST and SHOULD be supported for
- interoperability has been removed from this document because they are
- likely to change more rapidly than this document evolves.
-
- An important lesson learned from IKEv1 is that no system should only
- implement the mandatory algorithms and expect them to be the best
- choice for all customers. For example, at the time that this
- document was written, many IKEv1 implementers were starting to
- migrate to AES in Cipher Block Chaining (CBC) mode for Virtual
- Private Network (VPN) applications. Many IPsec systems based on
- IKEv2 will implement AES, additional Diffie-Hellman groups, and
- additional hash algorithms, and some IPsec customers already require
- these algorithms in addition to the ones listed above.
-
- It is likely that IANA will add additional transforms in the future,
- and some users may want to use private suites, especially for IKE
- where implementations should be capable of supporting different
- parameters, up to certain size limits. In support of this goal, all
- implementations of IKEv2 SHOULD include a management facility that
- allows specification (by a user or system administrator) of Diffie-
- Hellman (DH) parameters (the generator, modulus, and exponent lengths
- and values) for new DH groups. Implementations SHOULD provide a
-
-
-
-Kaufman Standards Track [Page 52]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- management interface via which these parameters and the associated
- transform IDs may be entered (by a user or system administrator), to
- enable negotiating such groups.
-
- All implementations of IKEv2 MUST include a management facility that
- enables a user or system administrator to specify the suites that are
- acceptable for use with IKE. Upon receipt of a payload with a set of
- transform IDs, the implementation MUST compare the transmitted
- transform IDs against those locally configured via the management
- controls, to verify that the proposed suite is acceptable based on
- local policy. The implementation MUST reject SA proposals that are
- not authorized by these IKE suite controls. Note that cryptographic
- suites that MUST be implemented need not be configured as acceptable
- to local policy.
-
-3.3.5. Transform Attributes
-
- Each transform in a Security Association payload may include
- attributes that modify or complete the specification of the
- transform. These attributes are type/value pairs and are defined
- below. For example, if an encryption algorithm has a variable-length
- key, the key length to be used may be specified as an attribute.
- Attributes can have a value with a fixed two octet length or a
- variable-length value. For the latter, the attribute is encoded as
- type/length/value.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- !A! Attribute Type ! AF=0 Attribute Length !
- !F! ! AF=1 Attribute Value !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! AF=0 Attribute Value !
- ! AF=1 Not Transmitted !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 9: Data Attributes
-
- o Attribute Type (2 octets) - Unique identifier for each type of
- attribute (see below).
-
- The most significant bit of this field is the Attribute Format
- bit (AF). It indicates whether the data attributes follow the
- Type/Length/Value (TLV) format or a shortened Type/Value (TV)
- format. If the AF bit is zero (0), then the Data Attributes
- are of the Type/Length/Value (TLV) form. If the AF bit is a
- one (1), then the Data Attributes are of the Type/Value form.
-
-
-
-
-Kaufman Standards Track [Page 53]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- o Attribute Length (2 octets) - Length in octets of the Attribute
- Value. When the AF bit is a one (1), the Attribute Value is
- only 2 octets and the Attribute Length field is not present.
-
- o Attribute Value (variable length) - Value of the Attribute
- associated with the Attribute Type. If the AF bit is a zero
- (0), this field has a variable length defined by the Attribute
- Length field. If the AF bit is a one (1), the Attribute Value
- has a length of 2 octets.
-
- Note that only a single attribute type (Key Length) is defined, and
- it is fixed length. The variable-length encoding specification is
- included only for future extensions. The only algorithms defined in
- this document that accept attributes are the AES-based encryption,
- integrity, and pseudo-random functions, which require a single
- attribute specifying key width.
-
- Attributes described as basic MUST NOT be encoded using the
- variable-length encoding. Variable-length attributes MUST NOT be
- encoded as basic even if their value can fit into two octets. NOTE:
- This is a change from IKEv1, where increased flexibility may have
- simplified the composer of messages but certainly complicated the
- parser.
-
- Attribute Type Value Attribute Format
- --------------------------------------------------------------
- RESERVED 0-13 Key Length (in bits)
- 14 TV RESERVED 15-17
- RESERVED TO IANA 18-16383 PRIVATE USE
- 16384-32767
-
- Values 0-13 and 15-17 were used in a similar context in IKEv1 and
- should not be assigned except to matching values. Values 18-16383
- are reserved to IANA. Values 16384-32767 are for private use among
- mutually consenting parties.
-
- - Key Length
-
- When using an Encryption Algorithm that has a variable-length key,
- this attribute specifies the key length in bits (MUST use network
- byte order). This attribute MUST NOT be used when the specified
- Encryption Algorithm uses a fixed-length key.
-
-
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 54]
-\f
-RFC 4306 IKEv2 December 2005
-
-
-3.3.6. Attribute Negotiation
-
- During security association negotiation, initiators present offers to
- responders. Responders MUST select a single complete set of
- parameters from the offers (or reject all offers if none are
- acceptable). If there are multiple proposals, the responder MUST
- choose a single proposal number and return all of the Proposal
- substructures with that Proposal number. If there are multiple
- Transforms with the same type, the responder MUST choose a single
- one. Any attributes of a selected transform MUST be returned
- unmodified. The initiator of an exchange MUST check that the
- accepted offer is consistent with one of its proposals, and if not
- that response MUST be rejected.
-
- Negotiating Diffie-Hellman groups presents some special challenges.
- SA offers include proposed attributes and a Diffie-Hellman public
- number (KE) in the same message. If in the initial exchange the
- initiator offers to use one of several Diffie-Hellman groups, it
- SHOULD pick the one the responder is most likely to accept and
- include a KE corresponding to that group. If the guess turns out to
- be wrong, the responder will indicate the correct group in the
- response and the initiator SHOULD pick an element of that group for
- its KE value when retrying the first message. It SHOULD, however,
- continue to propose its full supported set of groups in order to
- prevent a man-in-the-middle downgrade attack.
-
- Implementation Note:
-
- Certain negotiable attributes can have ranges or could have
- multiple acceptable values. These include the key length of a
- variable key length symmetric cipher. To further interoperability
- and to support upgrading endpoints independently, implementers of
- this protocol SHOULD accept values that they deem to supply
- greater security. For instance, if a peer is configured to accept
- a variable-length cipher with a key length of X bits and is
- offered that cipher with a larger key length, the implementation
- SHOULD accept the offer if it supports use of the longer key.
-
- Support of this capability allows an implementation to express a
- concept of "at least" a certain level of security -- "a key length of
- _at least_ X bits for cipher Y".
-
-
-
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 55]
-\f
-RFC 4306 IKEv2 December 2005
-
-
-3.4. Key Exchange Payload
-
- The Key Exchange Payload, denoted KE in this memo, is used to
- exchange Diffie-Hellman public numbers as part of a Diffie-Hellman
- key exchange. The Key Exchange Payload consists of the IKE generic
- payload header followed by the Diffie-Hellman public value itself.
-
- 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 !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! DH Group # ! RESERVED !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ Key Exchange Data ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 10: Key Exchange Payload Format
-
- A key exchange payload is constructed by copying one's Diffie-Hellman
- public value into the "Key Exchange Data" portion of the payload.
- The length of the Diffie-Hellman public value MUST be equal to the
- length of the prime modulus over which the exponentiation was
- performed, prepending zero bits to the value if necessary.
-
- The DH Group # identifies the Diffie-Hellman group in which the Key
- Exchange Data was computed (see section 3.3.2). If the selected
- proposal uses a different Diffie-Hellman group, the message MUST be
- rejected with a Notify payload of type INVALID_KE_PAYLOAD.
-
- The payload type for the Key Exchange payload is thirty four (34).
-
-3.5. Identification Payloads
-
- The Identification Payloads, denoted IDi and IDr in this memo, allow
- peers to assert an identity to one another. This identity may be
- used for policy lookup, but does not necessarily have to match
- anything in the CERT payload; both fields may be used by an
- implementation to perform access control decisions.
-
- NOTE: In IKEv1, two ID payloads were used in each direction to hold
- Traffic Selector (TS) information for data passing over the SA. In
- IKEv2, this information is carried in TS payloads (see section 3.13).
-
-
-
-
-
-
-Kaufman Standards Track [Page 56]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- The Identification Payload consists of the IKE generic payload header
- followed by identification fields 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 !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! ID Type ! RESERVED |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ Identification Data ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 11: Identification Payload Format
-
- o ID Type (1 octet) - Specifies the type of Identification being
- used.
-
- o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
-
- o Identification Data (variable length) - Value, as indicated by the
- Identification Type. The length of the Identification Data is
- computed from the size in the ID payload header.
-
- The payload types for the Identification Payload are thirty five (35)
- for IDi and thirty six (36) for IDr.
-
- The following table lists the assigned values for the Identification
- Type field, followed by a description of the Identification Data
- which follows:
-
- ID Type Value
- ------- -----
- RESERVED 0
-
- ID_IPV4_ADDR 1
-
- A single four (4) octet IPv4 address.
-
- ID_FQDN 2
-
- A fully-qualified domain name string. An example of a
- ID_FQDN is, "example.com". The string MUST not contain any
- terminators (e.g., NULL, CR, etc.).
-
-
-
-
-
-Kaufman Standards Track [Page 57]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- ID_RFC822_ADDR 3
-
- A fully-qualified RFC822 email address string, An example of
- a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST
- not contain any terminators.
-
- Reserved to IANA 4
-
- ID_IPV6_ADDR 5
-
- A single sixteen (16) octet IPv6 address.
-
- Reserved to IANA 6 - 8
-
- ID_DER_ASN1_DN 9
-
- The binary Distinguished Encoding Rules (DER) encoding of an
- ASN.1 X.500 Distinguished Name [X.501].
-
- ID_DER_ASN1_GN 10
-
- The binary DER encoding of an ASN.1 X.500 GeneralName
- [X.509].
-
- ID_KEY_ID 11
-
- An opaque octet stream which may be used to pass vendor-
- specific information necessary to do certain proprietary
- types of identification.
-
- Reserved to IANA 12-200
-
- Reserved for private use 201-255
-
- Two implementations will interoperate only if each can generate a
- type of ID acceptable to the other. To assure maximum
- interoperability, implementations MUST be configurable to send at
- least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
- MUST be configurable to accept all of these types. Implementations
- SHOULD be capable of generating and accepting all of these types.
- IPv6-capable implementations MUST additionally be configurable to
- accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable
- to send only ID_IPV6_ADDR.
-
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 58]
-\f
-RFC 4306 IKEv2 December 2005
-
-
-3.6. Certificate Payload
-
- The Certificate Payload, denoted CERT in this memo, provides a means
- to transport certificates or other authentication-related information
- via IKE. Certificate payloads SHOULD be included in an exchange if
- certificates are available to the sender unless the peer has
- indicated an ability to retrieve this information from elsewhere
- using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the
- term "Certificate Payload" is somewhat misleading, because not all
- authentication mechanisms use certificates and data other than
- certificates may be passed in this payload.
-
- The Certificate Payload is defined 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 !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Cert Encoding ! !
- +-+-+-+-+-+-+-+-+ !
- ~ Certificate Data ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 12: Certificate Payload Format
-
- o Certificate Encoding (1 octet) - This field indicates the type
- of certificate or certificate-related information contained in
- the Certificate Data field.
-
- Certificate Encoding Value
- -------------------- -----
- RESERVED 0
- PKCS #7 wrapped X.509 certificate 1
- PGP Certificate 2
- DNS Signed Key 3
- X.509 Certificate - Signature 4
- Kerberos Token 6
- Certificate Revocation List (CRL) 7
- Authority Revocation List (ARL) 8
- SPKI Certificate 9
- X.509 Certificate - Attribute 10
- Raw RSA Key 11
- Hash and URL of X.509 certificate 12
- Hash and URL of X.509 bundle 13
- RESERVED to IANA 14 - 200
- PRIVATE USE 201 - 255
-
-
-
-Kaufman Standards Track [Page 59]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- o Certificate Data (variable length) - Actual encoding of
- certificate data. The type of certificate is indicated by the
- Certificate Encoding field.
-
- The payload type for the Certificate Payload is thirty seven (37).
-
- Specific syntax is for some of the certificate type codes above is
- not defined in this document. The types whose syntax is defined in
- this document are:
-
- X.509 Certificate - Signature (4) contains a DER encoded X.509
- certificate whose public key is used to validate the sender's AUTH
- payload.
-
- Certificate Revocation List (7) contains a DER encoded X.509
- certificate revocation list.
-
- Raw RSA Key (11) contains a PKCS #1 encoded RSA key (see [RSA] and
- [PKCS1]).
-
- Hash and URL encodings (12-13) allow IKE messages to remain short
- by replacing long data structures with a 20 octet SHA-1 hash (see
- [SHA]) of the replaced value followed by a variable-length URL
- that resolves to the DER encoded data structure itself. This
- improves efficiency when the endpoints have certificate data
- cached and makes IKE less subject to denial of service attacks
- that become easier to mount when IKE messages are large enough to
- require IP fragmentation [KPS03].
-
- Use the following ASN.1 definition for an X.509 bundle:
-
- CertBundle
- { iso(1) identified-organization(3) dod(6) internet(1)
- security(5) mechanisms(5) pkix(7) id-mod(0)
- id-mod-cert-bundle(34) }
-
- DEFINITIONS EXPLICIT TAGS ::=
- BEGIN
-
- IMPORTS
- Certificate, CertificateList
- FROM PKIX1Explicit88
- { iso(1) identified-organization(3) dod(6)
- internet(1) security(5) mechanisms(5) pkix(7)
- id-mod(0) id-pkix1-explicit(18) } ;
-
-
-
-
-
-
-Kaufman Standards Track [Page 60]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- CertificateOrCRL ::= CHOICE {
- cert [0] Certificate,
- crl [1] CertificateList }
-
- CertificateBundle ::= SEQUENCE OF CertificateOrCRL
-
- END
-
- Implementations MUST be capable of being configured to send and
- accept up to four X.509 certificates in support of authentication,
- and also MUST be capable of being configured to send and accept the
- first two Hash and URL formats (with HTTP URLs). Implementations
- SHOULD be capable of being configured to send and accept Raw RSA
- keys. If multiple certificates are sent, the first certificate MUST
- contain the public key used to sign the AUTH payload. The other
- certificates may be sent in any order.
-
-3.7. Certificate Request Payload
-
- The Certificate Request Payload, denoted CERTREQ in this memo,
- provides a means to request preferred certificates via IKE and can
- appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
- Certificate Request payloads MAY be included in an exchange when the
- sender needs to get the certificate of the receiver. If multiple CAs
- are trusted and the cert encoding does not allow a list, then
- multiple Certificate Request payloads SHOULD be transmitted.
-
- The Certificate Request Payload is defined 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 !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Cert Encoding ! !
- +-+-+-+-+-+-+-+-+ !
- ~ Certification Authority ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 13: Certificate Request Payload Format
-
- o Certificate Encoding (1 octet) - Contains an encoding of the type
- or format of certificate requested. Values are listed in section
- 3.6.
-
-
-
-
-
-
-Kaufman Standards Track [Page 61]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- o Certification Authority (variable length) - Contains an encoding
- of an acceptable certification authority for the type of
- certificate requested.
-
- The payload type for the Certificate Request Payload is thirty eight
- (38).
-
- The Certificate Encoding field has the same values as those defined
- in section 3.6. The Certification Authority field contains an
- indicator of trusted authorities for this certificate type. The
- Certification Authority value is a concatenated list of SHA-1 hashes
- of the public keys of trusted Certification Authorities (CAs). Each
- is encoded as the SHA-1 hash of the Subject Public Key Info element
- (see section 4.1.2.7 of [RFC3280]) from each Trust Anchor
- certificate. The twenty-octet hashes are concatenated and included
- with no other formatting.
-
- Note that the term "Certificate Request" is somewhat misleading, in
- that values other than certificates are defined in a "Certificate"
- payload and requests for those values can be present in a Certificate
- Request Payload. The syntax of the Certificate Request payload in
- such cases is not defined in this document.
-
- The Certificate Request Payload is processed by inspecting the "Cert
- Encoding" field to determine whether the processor has any
- certificates of this type. If so, the "Certification Authority"
- field is inspected to determine if the processor has any certificates
- that can be validated up to one of the specified certification
- authorities. This can be a chain of certificates.
-
- If an end-entity certificate exists that satisfies the criteria
- specified in the CERTREQ, a certificate or certificate chain SHOULD
- be sent back to the certificate requestor if the recipient of the
- CERTREQ:
-
- - is configured to use certificate authentication,
-
- - is allowed to send a CERT payload,
-
- - has matching CA trust policy governing the current negotiation, and
-
- - has at least one time-wise and usage appropriate end-entity
- certificate chaining to a CA provided in the CERTREQ.
-
- Certificate revocation checking must be considered during the
- chaining process used to select a certificate. Note that even if two
- peers are configured to use two different CAs, cross-certification
- relationships should be supported by appropriate selection logic.
-
-
-
-Kaufman Standards Track [Page 62]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- The intent is not to prevent communication through the strict
- adherence of selection of a certificate based on CERTREQ, when an
- alternate certificate could be selected by the sender that would
- still enable the recipient to successfully validate and trust it
- through trust conveyed by cross-certification, CRLs, or other out-
- of-band configured means. Thus, the processing of a CERTREQ should
- be seen as a suggestion for a certificate to select, not a mandated
- one. If no certificates exist, then the CERTREQ is ignored. This is
- not an error condition of the protocol. There may be cases where
- there is a preferred CA sent in the CERTREQ, but an alternate might
- be acceptable (perhaps after prompting a human operator).
-
-3.8. Authentication Payload
-
- The Authentication Payload, denoted AUTH in this memo, contains data
- used for authentication purposes. The syntax of the Authentication
- data varies according to the Auth Method as specified below.
-
- The Authentication Payload is defined 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 !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Auth Method ! RESERVED !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ Authentication Data ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 14: Authentication Payload Format
-
- o Auth Method (1 octet) - Specifies the method of authentication
- used. Values defined are:
-
- RSA Digital Signature (1) - Computed as specified in section
- 2.15 using an RSA private key over a PKCS#1 padded hash (see
- [RSA] and [PKCS1]).
-
- Shared Key Message Integrity Code (2) - Computed as specified in
- section 2.15 using the shared key associated with the identity
- in the ID payload and the negotiated prf function
-
- DSS Digital Signature (3) - Computed as specified in section
- 2.15 using a DSS private key (see [DSS]) over a SHA-1 hash.
-
-
-
-
-Kaufman Standards Track [Page 63]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- The values 0 and 4-200 are reserved to IANA. The values 201-255
- are available for private use.
-
- o Authentication Data (variable length) - see section 2.15.
-
- The payload type for the Authentication Payload is thirty nine (39).
-
-3.9. Nonce Payload
-
- The Nonce Payload, denoted Ni and Nr in this memo for the initiator's
- and responder's nonce respectively, contains random data used to
- guarantee liveness during an exchange and protect against replay
- attacks.
-
- The Nonce Payload is defined 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 !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ Nonce Data ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 15: Nonce Payload Format
-
- o Nonce Data (variable length) - Contains the random data generated
- by the transmitting entity.
-
- The payload type for the Nonce Payload is forty (40).
-
- The size of a Nonce MUST be between 16 and 256 octets inclusive.
- Nonce values MUST NOT be reused.
-
-3.10. Notify Payload
-
- The Notify Payload, denoted N in this document, is used to transmit
- informational data, such as error conditions and state transitions,
- to an IKE peer. A Notify Payload may appear in a response message
- (usually specifying why a request was rejected), in an INFORMATIONAL
- Exchange (to report an error not in an IKE request), or in any other
- message to indicate sender capabilities or to modify the meaning of
- the request.
-
-
-
-
-
-
-Kaufman Standards Track [Page 64]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- The Notify Payload is defined 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 !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ Security Parameter Index (SPI) ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ Notification Data ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 16: Notify Payload Format
-
- o Protocol ID (1 octet) - If this notification concerns an existing
- SA, this field indicates the type of that SA. For IKE_SA
- notifications, this field MUST be one (1). For notifications
- concerning IPsec SAs this field MUST contain either (2) to
- indicate AH or (3) to indicate ESP. For notifications that do not
- relate to an existing SA, this field MUST be sent as zero and MUST
- be ignored on receipt. All other values for this field are
- reserved to IANA for future assignment.
-
- o SPI Size (1 octet) - Length in octets of the SPI as defined by the
- IPsec protocol ID or zero if no SPI is applicable. For a
- notification concerning the IKE_SA, the SPI Size MUST be zero.
-
- o Notify Message Type (2 octets) - Specifies the type of
- notification message.
-
- o SPI (variable length) - Security Parameter Index.
-
- o Notification Data (variable length) - Informational or error data
- transmitted in addition to the Notify Message Type. Values for
- this field are type specific (see below).
-
- The payload type for the Notify Payload is forty one (41).
-
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 65]
-\f
-RFC 4306 IKEv2 December 2005
-
-
-3.10.1. Notify Message Types
-
- Notification information can be error messages specifying why an SA
- could not be established. It can also be status data that a process
- managing an SA database wishes to communicate with a peer process.
- The table below lists the Notification messages and their
- corresponding values. The number of different error statuses was
- greatly reduced from IKEv1 both for simplification and to avoid
- giving configuration information to probers.
-
- Types in the range 0 - 16383 are intended for reporting errors. An
- implementation receiving a Notify payload with one of these types
- that it does not recognize in a response MUST assume that the
- corresponding request has failed entirely. Unrecognized error types
- in a request and status types in a request or response MUST be
- ignored except that they SHOULD be logged.
-
- Notify payloads with status types MAY be added to any message and
- MUST be ignored if not recognized. They are intended to indicate
- capabilities, and as part of SA negotiation are used to negotiate
- non-cryptographic parameters.
-
- NOTIFY MESSAGES - ERROR TYPES Value
- ----------------------------- -----
- RESERVED 0
-
- UNSUPPORTED_CRITICAL_PAYLOAD 1
-
- Sent if the payload has the "critical" bit set and the
- payload type is not recognized. Notification Data contains
- the one-octet payload type.
-
- INVALID_IKE_SPI 4
-
- Indicates an IKE message was received with an unrecognized
- destination SPI. This usually indicates that the recipient
- has rebooted and forgotten the existence of an IKE_SA.
-
- INVALID_MAJOR_VERSION 5
-
- Indicates the recipient cannot handle the version of IKE
- specified in the header. The closest version number that
- the recipient can support will be in the reply header.
-
- INVALID_SYNTAX 7
-
- Indicates the IKE message that was received was invalid
- because some type, length, or value was out of range or
-
-
-
-Kaufman Standards Track [Page 66]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- because the request was rejected for policy reasons. To
- avoid a denial of service attack using forged messages, this
- status may only be returned for and in an encrypted packet
- if the message ID and cryptographic checksum were valid. To
- avoid leaking information to someone probing a node, this
- status MUST be sent in response to any error not covered by
- one of the other status types. To aid debugging, more
- detailed error information SHOULD be written to a console or
- log.
-
- INVALID_MESSAGE_ID 9
-
- Sent when an IKE message ID outside the supported window is
- received. This Notify MUST NOT be sent in a response; the
- invalid request MUST NOT be acknowledged. Instead, inform
- the other side by initiating an INFORMATIONAL exchange with
- Notification data containing the four octet invalid message
- ID. Sending this notification is optional, and
- notifications of this type MUST be rate limited.
-
- INVALID_SPI 11
-
- MAY be sent in an IKE INFORMATIONAL exchange when a node
- receives an ESP or AH packet with an invalid SPI. The
- Notification Data contains the SPI of the invalid packet.
- This usually indicates a node has rebooted and forgotten an
- SA. If this Informational Message is sent outside the
- context of an IKE_SA, it should be used by the recipient
- only as a "hint" that something might be wrong (because it
- could easily be forged).
-
- NO_PROPOSAL_CHOSEN 14
-
- None of the proposed crypto suites was acceptable.
-
- INVALID_KE_PAYLOAD 17
-
- The D-H Group # field in the KE payload is not the group #
- selected by the responder for this exchange. There are two
- octets of data associated with this notification: the
- accepted D-H Group # in big endian order.
-
- AUTHENTICATION_FAILED 24
-
- Sent in the response to an IKE_AUTH message when for some
- reason the authentication failed. There is no associated
- data.
-
-
-
-
-Kaufman Standards Track [Page 67]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- SINGLE_PAIR_REQUIRED 34
-
- This error indicates that a CREATE_CHILD_SA request is
- unacceptable because its sender is only willing to accept
- traffic selectors specifying a single pair of addresses. The
- requestor is expected to respond by requesting an SA for only
- the specific traffic it is trying to forward.
-
- NO_ADDITIONAL_SAS 35
-
- This error indicates that a CREATE_CHILD_SA request is
- unacceptable because the responder is unwilling to accept any
- more CHILD_SAs on this IKE_SA. Some minimal implementations may
- only accept a single CHILD_SA setup in the context of an initial
- IKE exchange and reject any subsequent attempts to add more.
-
- INTERNAL_ADDRESS_FAILURE 36
-
- Indicates an error assigning an internal address (i.e.,
- INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the
- processing of a Configuration Payload by a responder. If this
- error is generated within an IKE_AUTH exchange, no CHILD_SA will
- be created.
-
- FAILED_CP_REQUIRED 37
-
- Sent by responder in the case where CP(CFG_REQUEST) was expected
- but not received, and so is a conflict with locally configured
- policy. There is no associated data.
-
- TS_UNACCEPTABLE 38
-
- Indicates that none of the addresses/protocols/ports in the
- supplied traffic selectors is acceptable.
-
- INVALID_SELECTORS 39
-
- MAY be sent in an IKE INFORMATIONAL exchange when a node
- receives an ESP or AH packet whose selectors do not match
- those of the SA on which it was delivered (and that caused
- the packet to be dropped). The Notification Data contains
- the start of the offending packet (as in ICMP messages) and
- the SPI field of the notification is set to match the SPI of
- the IPsec SA.
-
- RESERVED TO IANA - Error types 40 - 8191
-
- Private Use - Errors 8192 - 16383
-
-
-
-Kaufman Standards Track [Page 68]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- NOTIFY MESSAGES - STATUS TYPES Value
- ------------------------------ -----
-
- INITIAL_CONTACT 16384
-
- This notification asserts that this IKE_SA is the only
- IKE_SA currently active between the authenticated
- identities. It MAY be sent when an IKE_SA is established
- after a crash, and the recipient MAY use this information to
- delete any other IKE_SAs it has to the same authenticated
- identity without waiting for a timeout. This notification
- MUST NOT be sent by an entity that may be replicated (e.g.,
- a roaming user's credentials where the user is allowed to
- connect to the corporate firewall from two remote systems at
- the same time).
-
- SET_WINDOW_SIZE 16385
-
- This notification asserts that the sending endpoint is
- capable of keeping state for multiple outstanding exchanges,
- permitting the recipient to send multiple requests before
- getting a response to the first. The data associated with a
- SET_WINDOW_SIZE notification MUST be 4 octets long and
- contain the big endian representation of the number of
- messages the sender promises to keep. Window size is always
- one until the initial exchanges complete.
-
- ADDITIONAL_TS_POSSIBLE 16386
-
- This notification asserts that the sending endpoint narrowed
- the proposed traffic selectors but that other traffic
- selectors would also have been acceptable, though only in a
- separate SA (see section 2.9). There is no data associated
- with this Notify type. It may be sent only as an additional
- payload in a message including accepted TSs.
-
- IPCOMP_SUPPORTED 16387
-
- This notification may be included only in a message
- containing an SA payload negotiating a CHILD_SA and
- indicates a willingness by its sender to use IPComp on this
- SA. The data associated with this notification includes a
- two-octet IPComp CPI followed by a one-octet transform ID
- optionally followed by attributes whose length and format
- are defined by that transform ID. A message proposing an SA
- may contain multiple IPCOMP_SUPPORTED notifications to
- indicate multiple supported algorithms. A message accepting
- an SA may contain at most one.
-
-
-
-Kaufman Standards Track [Page 69]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- The transform IDs currently defined are:
-
- NAME NUMBER DEFINED IN
- ----------- ------ -----------
- RESERVED 0
- IPCOMP_OUI 1
- IPCOMP_DEFLATE 2 RFC 2394
- IPCOMP_LZS 3 RFC 2395
- IPCOMP_LZJH 4 RFC 3051
-
- values 5-240 are reserved to IANA. Values 241-255 are
- for private use among mutually consenting parties.
-
- NAT_DETECTION_SOURCE_IP 16388
-
- This notification is used by its recipient to determine
- whether the source is behind a NAT box. The data associated
- with this notification is a SHA-1 digest of the SPIs (in the
- order they appear in the header), IP address, and port on
- which this packet was sent. There MAY be multiple Notify
- payloads of this type in a message if the sender does not
- know which of several network attachments will be used to
- send the packet. The recipient of this notification MAY
- compare the supplied value to a SHA-1 hash of the SPIs,
- source IP address, and port, and if they don't match it
- SHOULD enable NAT traversal (see section 2.23).
- Alternately, it MAY reject the connection attempt if NAT
- traversal is not supported.
-
- NAT_DETECTION_DESTINATION_IP 16389
-
- This notification is used by its recipient to determine
- whether it is behind a NAT box. The data associated with
- this notification is a SHA-1 digest of the SPIs (in the
- order they appear in the header), IP address, and port to
- which this packet was sent. The recipient of this
- notification MAY compare the supplied value to a hash of the
- SPIs, destination IP address, and port, and if they don't
- match it SHOULD invoke NAT traversal (see section 2.23). If
- they don't match, it means that this end is behind a NAT and
- this end SHOULD start sending keepalive packets as defined
- in [Hutt05]. Alternately, it MAY reject the connection
- attempt if NAT traversal is not supported.
-
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 70]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- COOKIE 16390
-
- This notification MAY be included in an IKE_SA_INIT
- response. It indicates that the request should be retried
- with a copy of this notification as the first payload. This
- notification MUST be included in an IKE_SA_INIT request
- retry if a COOKIE notification was included in the initial
- response. The data associated with this notification MUST
- be between 1 and 64 octets in length (inclusive).
-
- USE_TRANSPORT_MODE 16391
-
- This notification MAY be included in a request message that
- also includes an SA payload requesting a CHILD_SA. It
- requests that the CHILD_SA use transport mode rather than
- tunnel mode for the SA created. If the request is accepted,
- the response MUST also include a notification of type
- USE_TRANSPORT_MODE. If the responder declines the request,
- the CHILD_SA will be established in tunnel mode. If this is
- unacceptable to the initiator, the initiator MUST delete the
- SA. Note: Except when using this option to negotiate
- transport mode, all CHILD_SAs will use tunnel mode.
-
- Note: The ECN decapsulation modifications specified in
- [RFC4301] MUST be performed for every tunnel mode SA created
- by IKEv2.
-
- HTTP_CERT_LOOKUP_SUPPORTED 16392
-
- This notification MAY be included in any message that can
- include a CERTREQ payload and indicates that the sender is
- capable of looking up certificates based on an HTTP-based
- URL (and hence presumably would prefer to receive
- certificate specifications in that format).
-
- REKEY_SA 16393
-
- This notification MUST be included in a CREATE_CHILD_SA
- exchange if the purpose of the exchange is to replace an
- existing ESP or AH SA. The SPI field identifies the SA
- being rekeyed. There is no data.
-
- ESP_TFC_PADDING_NOT_SUPPORTED 16394
-
- This notification asserts that the sending endpoint will NOT
- accept packets that contain Flow Confidentiality (TFC)
- padding.
-
-
-
-
-Kaufman Standards Track [Page 71]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- NON_FIRST_FRAGMENTS_ALSO 16395
-
- Used for fragmentation control. See [RFC4301] for
- explanation.
-
- RESERVED TO IANA - STATUS TYPES 16396 - 40959
-
- Private Use - STATUS TYPES 40960 - 65535
-
-3.11. Delete Payload
-
- The Delete Payload, denoted D in this memo, contains a protocol-
- specific security association identifier that the sender has removed
- from its security association database and is, therefore, no longer
- valid. Figure 17 shows the format of the Delete Payload. It is
- possible to send multiple SPIs in a Delete payload; however, each SPI
- MUST be for the same protocol. Mixing of protocol identifiers MUST
- NOT be performed in a Delete payload. It is permitted, however, to
- include multiple Delete payloads in a single INFORMATIONAL exchange
- where each Delete payload lists SPIs for a different protocol.
-
- Deletion of the IKE_SA is indicated by a protocol ID of 1 (IKE) but
- no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will contain the
- IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI
- is the SPI the sending endpoint would expect in inbound ESP or AH
- packets.
-
- The Delete Payload is defined 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 ! # of SPIs !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ Security Parameter Index(es) (SPI) ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 17: Delete Payload Format
-
- o Protocol ID (1 octet) - Must be 1 for an IKE_SA, 2 for AH, or 3
- for ESP.
-
-
-
-
-
-
-Kaufman Standards Track [Page 72]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- o SPI Size (1 octet) - Length in octets of the SPI as defined by the
- protocol ID. It MUST be zero for IKE (SPI is in message header)
- or four for AH and ESP.
-
- o # of SPIs (2 octets) - The number of SPIs contained in the Delete
- payload. The size of each SPI is defined by the SPI Size field.
-
- o Security Parameter Index(es) (variable length) - Identifies the
- specific security association(s) to delete. The length of this
- field is determined by the SPI Size and # of SPIs fields.
-
- The payload type for the Delete Payload is forty two (42).
-
-3.12. Vendor ID Payload
-
- The Vendor ID Payload, denoted V in this memo, contains a vendor
- defined constant. The constant is used by vendors to identify and
- recognize remote instances of their implementations. This mechanism
- allows a vendor to experiment with new features while maintaining
- backward compatibility.
-
- A Vendor ID payload MAY announce that the sender is capable to
- accepting certain extensions to the protocol, or it MAY simply
- identify the implementation as an aid in debugging. A Vendor ID
- payload MUST NOT change the interpretation of any information defined
- in this specification (i.e., the critical bit MUST be set to 0).
- Multiple Vendor ID payloads MAY be sent. An implementation is NOT
- REQUIRED to send any Vendor ID payload at all.
-
- A Vendor ID payload may be sent as part of any message. Reception of
- a familiar Vendor ID payload allows an implementation to make use of
- Private USE numbers described throughout this memo -- private
- payloads, private exchanges, private notifications, etc. Unfamiliar
- Vendor IDs MUST be ignored.
-
- Writers of Internet-Drafts who wish to extend this protocol MUST
- define a Vendor ID payload to announce the ability to implement the
- extension in the Internet-Draft. It is expected that Internet-Drafts
- that gain acceptance and are standardized will be given "magic
- numbers" out of the Future Use range by IANA, and the requirement to
- use a Vendor ID will go away.
-
-
-
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 73]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- The Vendor ID Payload fields are defined 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 !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ Vendor ID (VID) ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 18: Vendor ID Payload Format
-
- o Vendor ID (variable length) - It is the responsibility of the
- person choosing the Vendor ID to assure its uniqueness in spite of
- the absence of any central registry for IDs. Good practice is to
- include a company name, a person name, or some such. If you want
- to show off, you might include the latitude and longitude and time
- where you were when you chose the ID and some random input. A
- message digest of a long unique string is preferable to the long
- unique string itself.
-
- The payload type for the Vendor ID Payload is forty three (43).
-
-3.13. Traffic Selector Payload
-
- The Traffic Selector Payload, denoted TS in this memo, allows peers
- to identify packet flows for processing by IPsec security services.
- The Traffic Selector Payload consists of the IKE generic payload
- header followed by individual traffic selectors 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 !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Number of TSs ! RESERVED !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ <Traffic Selectors> ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 19: Traffic Selectors Payload Format
-
- o Number of TSs (1 octet) - Number of traffic selectors being
- provided.
-
-
-
-Kaufman Standards Track [Page 74]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- o RESERVED - This field MUST be sent as zero and MUST be ignored on
- receipt.
-
- o Traffic Selectors (variable length) - One or more individual
- traffic selectors.
-
- The length of the Traffic Selector payload includes the TS header and
- all the traffic selectors.
-
- The payload type for the Traffic Selector payload is forty four (44)
- for addresses at the initiator's end of the SA and forty five (45)
- for addresses at the responder's end.
-
-3.13.1. Traffic Selector
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! TS Type !IP Protocol ID*| Selector Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Start Port* | End Port* |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ Starting Address* ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ Ending Address* ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 20: Traffic Selector
-
- * Note: All fields other than TS Type and Selector Length depend on
- the TS Type. The fields shown are for TS Types 7 and 8, the only two
- values currently defined.
-
- o TS Type (one octet) - Specifies the type of traffic selector.
-
- o IP protocol ID (1 octet) - Value specifying an associated IP
- protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the
- protocol ID is not relevant to this traffic selector -- the SA can
- carry all protocols.
-
- o Selector Length - Specifies the length of this Traffic Selector
- Substructure including the header.
-
-
-
-
-
-Kaufman Standards Track [Page 75]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- o Start Port (2 octets) - Value specifying the smallest port number
- allowed by this Traffic Selector. For protocols for which port is
- undefined, or if all ports are allowed, this field MUST be zero.
- For the ICMP protocol, the two one-octet fields Type and Code are
- treated as a single 16-bit integer (with Type in the most
- significant eight bits and Code in the least significant eight
- bits) port number for the purposes of filtering based on this
- field.
-
- o End Port (2 octets) - Value specifying the largest port number
- allowed by this Traffic Selector. For protocols for which port is
- undefined, or if all ports are allowed, this field MUST be 65535.
- For the ICMP protocol, the two one-octet fields Type and Code are
- treated as a single 16-bit integer (with Type in the most
- significant eight bits and Code in the least significant eight
- bits) port number for the purposed of filtering based on this
- field.
-
- o Starting Address - The smallest address included in this Traffic
- Selector (length determined by TS type).
-
- o Ending Address - The largest address included in this Traffic
- Selector (length determined by TS type).
-
- Systems that are complying with [RFC4301] that wish to indicate "ANY"
- ports MUST set the start port to 0 and the end port to 65535; note
- that according to [RFC4301], "ANY" includes "OPAQUE". Systems
- working with [RFC4301] that wish to indicate "OPAQUE" ports, but not
- "ANY" ports, MUST set the start port to 65535 and the end port to 0.
-
- The following table lists the assigned values for the Traffic
- Selector Type field and the corresponding Address Selector Data.
-
- TS Type Value
- ------- -----
- RESERVED 0-6
-
- TS_IPV4_ADDR_RANGE 7
-
- A range of IPv4 addresses, represented by two four-octet
- values. The first value is the beginning IPv4 address
- (inclusive) and the second value is the ending IPv4 address
- (inclusive). All addresses falling between the two
- specified addresses are considered to be within the list.
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 76]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- TS_IPV6_ADDR_RANGE 8
-
- A range of IPv6 addresses, represented by two sixteen-octet
- values. The first value is the beginning IPv6 address
- (inclusive) and the second value is the ending IPv6 address
- (inclusive). All addresses falling between the two
- specified addresses are considered to be within the list.
-
- RESERVED TO IANA 9-240
- PRIVATE USE 241-255
-
-3.14. Encrypted Payload
-
- The Encrypted Payload, denoted SK{...} or E in this memo, contains
- other payloads in encrypted form. The Encrypted Payload, if present
- in a message, MUST be the last payload in the message. Often, it is
- the only payload in the message.
-
- The algorithms for encryption and integrity protection are negotiated
- during IKE_SA setup, and the keys are computed as specified in
- sections 2.14 and 2.18.
-
- The encryption and integrity protection algorithms are modeled after
- the ESP algorithms described in RFCs 2104 [KBC96], 4303 [RFC4303],
- and 2451 [ESPCBC]. This document completely specifies the
- cryptographic processing of IKE data, but those documents should be
- consulted for design rationale. We require a block cipher with a
- fixed block size and an integrity check algorithm that computes a
- fixed-length checksum over a variable size message.
-
- The payload type for an Encrypted payload is forty six (46). The
- Encrypted Payload consists of the IKE generic payload header followed
- by individual fields as follows:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 77]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- 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 !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Initialization Vector !
- ! (length is block size for encryption algorithm) !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ~ Encrypted IKE Payloads ~
- + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! ! Padding (0-255 octets) !
- +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
- ! ! Pad Length !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ~ Integrity Checksum Data ~
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 21: Encrypted Payload Format
-
- o Next Payload - The payload type of the first embedded payload.
- Note that this is an exception in the standard header format,
- since the Encrypted payload is the last payload in the message and
- therefore the Next Payload field would normally be zero. But
- because the content of this payload is embedded payloads and there
- was no natural place to put the type of the first one, that type
- is placed here.
-
- o Payload Length - Includes the lengths of the header, IV, Encrypted
- IKE Payloads, Padding, Pad Length, and Integrity Checksum Data.
-
- o Initialization Vector - A randomly chosen value whose length is
- equal to the block length of the underlying encryption algorithm.
- Recipients MUST accept any value. Senders SHOULD either pick this
- value pseudo-randomly and independently for each message or use
- the final ciphertext block of the previous message sent. Senders
- MUST NOT use the same value for each message, use a sequence of
- values with low hamming distance (e.g., a sequence number), or use
- ciphertext from a received message.
-
- o IKE Payloads are as specified earlier in this section. This field
- is encrypted with the negotiated cipher.
-
- o Padding MAY contain any value chosen by the sender, and MUST have
- a length that makes the combination of the Payloads, the Padding,
- and the Pad Length to be a multiple of the encryption block size.
- This field is encrypted with the negotiated cipher.
-
-
-
-
-
-Kaufman Standards Track [Page 78]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- o Pad Length is the length of the Padding field. The sender SHOULD
- set the Pad Length to the minimum value that makes the combination
- of the Payloads, the Padding, and the Pad Length a multiple of the
- block size, but the recipient MUST accept any length that results
- in proper alignment. This field is encrypted with the negotiated
- cipher.
-
- o Integrity Checksum Data is the cryptographic checksum of the
- entire message starting with the Fixed IKE Header through the Pad
- Length. The checksum MUST be computed over the encrypted message.
- Its length is determined by the integrity algorithm negotiated.
-
-3.15. Configuration Payload
-
- The Configuration payload, denoted CP in this document, is used to
- exchange configuration information between IKE peers. The exchange
- is for an IRAC to request an internal IP address from an IRAS and to
- exchange other information of the sort that one would acquire with
- Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly
- connected to a LAN.
-
- Configuration payloads are of type CFG_REQUEST/CFG_REPLY or
- CFG_SET/CFG_ACK (see CFG Type in the payload description below).
- CFG_REQUEST and CFG_SET payloads may optionally be added to any IKE
- request. The IKE response MUST include either a corresponding
- CFG_REPLY or CFG_ACK or a Notify payload with an error type
- indicating why the request could not be honored. An exception is
- that a minimal implementation MAY ignore all CFG_REQUEST and CFG_SET
- payloads, so a response message without a corresponding CFG_REPLY or
- CFG_ACK MUST be accepted as an indication that the request was not
- supported.
-
- "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information
- from its peer. If an attribute in the CFG_REQUEST Configuration
- Payload is not zero-length, it is taken as a suggestion for that
- attribute. The CFG_REPLY Configuration Payload MAY return that
- value, or a new one. It MAY also add new attributes and not include
- some requested ones. Requestors MUST ignore returned attributes that
- they do not recognize.
-
- Some attributes MAY be multi-valued, in which case multiple attribute
- values of the same type are sent and/or returned. Generally, all
- values of an attribute are returned when the attribute is requested.
- For some attributes (in this version of the specification only
- internal addresses), multiple requests indicates a request that
- multiple values be assigned. For these attributes, the number of
- values returned SHOULD NOT exceed the number requested.
-
-
-
-
-Kaufman Standards Track [Page 79]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- If the data type requested in a CFG_REQUEST is not recognized or not
- supported, the responder MUST NOT return an error type but rather
- MUST either send a CFG_REPLY that MAY be empty or a reply not
- containing a CFG_REPLY payload at all. Error returns are reserved
- for cases where the request is recognized but cannot be performed as
- requested or the request is badly formatted.
-
- "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data
- to its peer. In this case, the CFG_SET Configuration Payload
- contains attributes the initiator wants its peer to alter. The
- responder MUST return a Configuration Payload if it accepted any of
- the configuration data and it MUST contain the attributes that the
- responder accepted with zero-length data. Those attributes that it
- did not accept MUST NOT be in the CFG_ACK Configuration Payload. If
- no attributes were accepted, the responder MUST return either an
- empty CFG_ACK payload or a response message without a CFG_ACK
- payload. There are currently no defined uses for the CFG_SET/CFG_ACK
- exchange, though they may be used in connection with extensions based
- on Vendor IDs. An minimal implementation of this specification MAY
- ignore CFG_SET payloads.
-
- Extensions via the CP payload SHOULD NOT be used for general purpose
- management. Its main intent is to provide a bootstrap mechanism to
- exchange information within IPsec from IRAS to IRAC. While it MAY be
- useful to use such a method to exchange information between some
- Security Gateways (SGW) or small networks, existing management
- protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP, or LDAP [LDAP]
- should be preferred for enterprise management as well as subsequent
- information exchanges.
-
- The Configuration Payload is defined 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 !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! CFG Type ! RESERVED !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ Configuration Attributes ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 22: Configuration Payload Format
-
- The payload type for the Configuration Payload is forty seven (47).
-
-
-
-
-Kaufman Standards Track [Page 80]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- o CFG Type (1 octet) - The type of exchange represented by the
- Configuration Attributes.
-
- CFG Type Value
- =========== =====
- RESERVED 0
- CFG_REQUEST 1
- CFG_REPLY 2
- CFG_SET 3
- CFG_ACK 4
-
- values 5-127 are reserved to IANA. Values 128-255 are for private
- use among mutually consenting parties.
-
- o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on
- receipt.
-
- o Configuration Attributes (variable length) - These are type length
- values specific to the Configuration Payload and are defined
- below. There may be zero or more Configuration Attributes in this
- payload.
-
-3.15.1. Configuration Attributes
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- !R| Attribute Type ! Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ Value ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 23: Configuration Attribute Format
-
- o Reserved (1 bit) - This bit MUST be set to zero and MUST be
- ignored on receipt.
-
- o Attribute Type (15 bits) - A unique identifier for each of the
- Configuration Attribute Types.
-
- o Length (2 octets) - Length in octets of Value.
-
- o Value (0 or more octets) - The variable-length value of this
- Configuration Attribute.
-
-
-
-
-
-Kaufman Standards Track [Page 81]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- The following attribute types have been defined:
-
- Multi-
- Attribute Type Value Valued Length
- ======================= ===== ====== ==================
- RESERVED 0
- INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets
- INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets
- INTERNAL_IP4_DNS 3 YES 0 or 4 octets
- INTERNAL_IP4_NBNS 4 YES 0 or 4 octets
- INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets
- INTERNAL_IP4_DHCP 6 YES 0 or 4 octets
- APPLICATION_VERSION 7 NO 0 or more
- INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets
- RESERVED 9
- INTERNAL_IP6_DNS 10 YES 0 or 16 octets
- INTERNAL_IP6_NBNS 11 YES 0 or 16 octets
- INTERNAL_IP6_DHCP 12 YES 0 or 16 octets
- INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets
- SUPPORTED_ATTRIBUTES 14 NO Multiple of 2
- INTERNAL_IP6_SUBNET 15 YES 17 octets
-
- * These attributes may be multi-valued on return only if multiple
- values were requested.
-
- Types 16-16383 are reserved to IANA. Values 16384-32767 are for
- private use among mutually consenting parties.
-
- o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
- internal network, sometimes called a red node address or
- private address and MAY be a private address on the Internet.
- In a request message, the address specified is a requested
- address (or zero if no specific address is requested). If a
- specific address is requested, it likely indicates that a
- previous connection existed with this address and the requestor
- would like to reuse that address. With IPv6, a requestor MAY
- supply the low-order address bytes it wants to use. Multiple
- internal addresses MAY be requested by requesting multiple
- internal address attributes. The responder MAY only send up to
- the number of addresses requested. The INTERNAL_IP6_ADDRESS is
- made up of two fields: the first is a sixteen-octet IPv6
- address and the second is a one-octet prefix-length as defined
- in [ADDRIPV6].
-
- The requested address is valid until the expiry time defined
- with the INTERNAL_ADDRESS EXPIRY attribute or there are no
- IKE_SAs between the peers.
-
-
-
-
-Kaufman Standards Track [Page 82]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- o INTERNAL_IP4_NETMASK - The internal network's netmask. Only
- one netmask is allowed in the request and reply messages (e.g.,
- 255.255.255.0), and it MUST be used only with an
- INTERNAL_IP4_ADDRESS attribute.
-
- o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a
- DNS server within the network. Multiple DNS servers MAY be
- requested. The responder MAY respond with zero or more DNS
- server attributes.
-
- o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of
- a NetBios Name Server (WINS) within the network. Multiple NBNS
- servers MAY be requested. The responder MAY respond with zero
- or more NBNS server attributes.
-
- o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that
- the host can use the internal IP address. The host MUST renew
- the IP address before this expiry time. Only one of these
- attributes MAY be present in the reply.
-
- o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to
- send any internal DHCP requests to the address contained within
- the attribute. Multiple DHCP servers MAY be requested. The
- responder MAY respond with zero or more DHCP server attributes.
-
- o APPLICATION_VERSION - The version or application information of
- the IPsec host. This is a string of printable ASCII characters
- that is NOT null terminated.
-
- o INTERNAL_IP4_SUBNET - The protected sub-networks that this
- edge-device protects. This attribute is made up of two fields:
- the first is an IP address and the second is a netmask.
- Multiple sub-networks MAY be requested. The responder MAY
- respond with zero or more sub-network attributes.
-
- o SUPPORTED_ATTRIBUTES - When used within a Request, this
- attribute MUST be zero-length and specifies a query to the
- responder to reply back with all of the attributes that it
- supports. The response contains an attribute that contains a
- set of attribute identifiers each in 2 octets. The length
- divided by 2 (octets) would state the number of supported
- attributes contained in the response.
-
-
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 83]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- o INTERNAL_IP6_SUBNET - The protected sub-networks that this
- edge-device protects. This attribute is made up of two fields:
- the first is a sixteen-octet IPv6 address and the second is a
- one-octet prefix-length as defined in [ADDRIPV6]. Multiple
- sub-networks MAY be requested. The responder MAY respond with
- zero or more sub-network attributes.
-
- Note that no recommendations are made in this document as to how
- an implementation actually figures out what information to send in
- a reply. That is, we do not recommend any specific method of an
- IRAS determining which DNS server should be returned to a
- requesting IRAC.
-
-3.16. Extensible Authentication Protocol (EAP) Payload
-
- The Extensible Authentication Protocol Payload, denoted EAP in this
- memo, allows IKE_SAs to be authenticated using the protocol defined
- in RFC 3748 [EAP] and subsequent extensions to that protocol. The
- full set of acceptable values for the payload is defined elsewhere,
- but a short summary of RFC 3748 is included here to make this
- document stand alone in the common cases.
-
- 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 !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ~ EAP Message ~
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 24: EAP Payload Format
-
- The payload type for an EAP Payload is forty eight (48).
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Code ! Identifier ! Length !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Type ! Type_Data...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Figure 25: EAP Message Format
-
- o Code (1 octet) indicates whether this message is a Request (1),
- Response (2), Success (3), or Failure (4).
-
-
-
-Kaufman Standards Track [Page 84]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- o Identifier (1 octet) is used in PPP to distinguish replayed
- messages from repeated ones. Since in IKE, EAP runs over a
- reliable protocol, it serves no function here. In a response
- message, this octet MUST be set to match the identifier in the
- corresponding request. In other messages, this field MAY be set
- to any value.
-
- o Length (2 octets) is the length of the EAP message and MUST be
- four less than the Payload Length of the encapsulating payload.
-
- o Type (1 octet) is present only if the Code field is Request (1) or
- Response (2). For other codes, the EAP message length MUST be
- four octets and the Type and Type_Data fields MUST NOT be present.
- In a Request (1) message, Type indicates the data being requested.
- In a Response (2) message, Type MUST either be Nak or match the
- type of the data requested. The following types are defined in
- RFC 3748:
-
- 1 Identity
- 2 Notification
- 3 Nak (Response Only)
- 4 MD5-Challenge
- 5 One-Time Password (OTP)
- 6 Generic Token Card
-
- o Type_Data (Variable Length) varies with the Type of Request and
- the associated Response. For the documentation of the EAP
- methods, see [EAP].
-
- Note that since IKE passes an indication of initiator identity in
- message 3 of the protocol, the responder SHOULD NOT send EAP Identity
- requests. The initiator SHOULD, however, respond to such requests if
- it receives them.
-
-4. Conformance Requirements
-
- In order to assure that all implementations of IKEv2 can
- interoperate, there are "MUST support" requirements in addition to
- those listed elsewhere. Of course, IKEv2 is a security protocol, and
- one of its major functions is to allow only authorized parties to
- successfully complete establishment of SAs. So a particular
- implementation may be configured with any of a number of restrictions
- concerning algorithms and trusted authorities that will prevent
- universal interoperability.
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 85]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- IKEv2 is designed to permit minimal implementations that can
- interoperate with all compliant implementations. There are a series
- of optional features that can easily be ignored by a particular
- implementation if it does not support that feature. Those features
- include:
-
- Ability to negotiate SAs through a NAT and tunnel the resulting
- ESP SA over UDP.
-
- Ability to request (and respond to a request for) a temporary IP
- address on the remote end of a tunnel.
-
- Ability to support various types of legacy authentication.
-
- Ability to support window sizes greater than one.
-
- Ability to establish multiple ESP and/or AH SAs within a single
- IKE_SA.
-
- Ability to rekey SAs.
-
- To assure interoperability, all implementations MUST be capable of
- parsing all payload types (if only to skip over them) and to ignore
- payload types that it does not support unless the critical bit is set
- in the payload header. If the critical bit is set in an unsupported
- payload header, all implementations MUST reject the messages
- containing those payloads.
-
- Every implementation MUST be capable of doing four-message
- IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE,
- one for ESP and/or AH). Implementations MAY be initiate-only or
- respond-only if appropriate for their platform. Every implementation
- MUST be capable of responding to an INFORMATIONAL exchange, but a
- minimal implementation MAY respond to any INFORMATIONAL message with
- an empty INFORMATIONAL reply (note that within the context of an
- IKE_SA, an "empty" message consists of an IKE header followed by an
- Encrypted payload with no payloads contained in it). A minimal
- implementation MAY support the CREATE_CHILD_SA exchange only in so
- far as to recognize requests and reject them with a Notify payload of
- type NO_ADDITIONAL_SAS. A minimal implementation need not be able to
- initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA
- expires (based on locally configured values of either lifetime or
- octets passed), and implementation MAY either try to renew it with a
- CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and
- create a new one. If the responder rejects the CREATE_CHILD_SA
- request with a NO_ADDITIONAL_SAS notification, the implementation
- MUST be capable of instead closing the old SA and creating a new one.
-
-
-
-
-Kaufman Standards Track [Page 86]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- Implementations are not required to support requesting temporary IP
- addresses or responding to such requests. If an implementation does
- support issuing such requests, it MUST include a CP payload in
- message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or
- INTERNAL_IP6_ADDRESS. All other fields are optional. If an
- implementation supports responding to such requests, it MUST parse
- the CP payload of type CFG_REQUEST in message 3 and recognize a field
- of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports
- leasing an address of the appropriate type, it MUST return a CP
- payload of type CFG_REPLY containing an address of the requested
- type. The responder SHOULD include all of the other related
- attributes if it has them.
-
- A minimal IPv4 responder implementation will ignore the contents of
- the CP payload except to determine that it includes an
- INTERNAL_IP4_ADDRESS attribute and will respond with the address and
- other related attributes regardless of whether the initiator
- requested them.
-
- A minimal IPv4 initiator will generate a CP payload containing only
- an INTERNAL_IP4_ADDRESS attribute and will parse the response
- ignoring attributes it does not know how to use. The only attribute
- it MUST be able to process is INTERNAL_ADDRESS_EXPIRY, which it must
- use to bound the lifetime of the SA unless it successfully renews the
- lease before it expires. Minimal initiators need not be able to
- request lease renewals and minimal responders need not respond to
- them.
-
- For an implementation to be called conforming to this specification,
- it MUST be possible to configure it to accept the following:
-
- PKIX Certificates containing and signed by RSA keys of size 1024 or
- 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
- ID_RFC822_ADDR, or ID_DER_ASN1_DN.
-
- Shared key authentication where the ID passes is any of ID_KEY_ID,
- ID_FQDN, or ID_RFC822_ADDR.
-
- Authentication where the responder is authenticated using PKIX
- Certificates and the initiator is authenticated using shared key
- authentication.
-
-
-
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 87]
-\f
-RFC 4306 IKEv2 December 2005
-
-
-5. Security Considerations
-
- While this protocol is designed to minimize disclosure of
- configuration information to unauthenticated peers, some such
- disclosure is unavoidable. One peer or the other must identify
- itself first and prove its identity first. To avoid probing, the
- initiator of an exchange is required to identify itself first, and
- usually is required to authenticate itself first. The initiator can,
- however, learn that the responder supports IKE and what cryptographic
- protocols it supports. The responder (or someone impersonating the
- responder) can probe the initiator not only for its identity, but
- using CERTREQ payloads may be able to determine what certificates the
- initiator is willing to use.
-
- Use of EAP authentication changes the probing possibilities somewhat.
- When EAP authentication is used, the responder proves its identity
- before the initiator does, so an initiator that knew the name of a
- valid initiator could probe the responder for both its name and
- certificates.
-
- Repeated rekeying using CREATE_CHILD_SA without additional Diffie-
- Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a
- single key or overrun of either endpoint. Implementers should take
- note of this fact and set a limit on CREATE_CHILD_SA exchanges
- between exponentiations. This memo does not prescribe such a limit.
-
- The strength of a key derived from a Diffie-Hellman exchange using
- any of the groups defined here depends on the inherent strength of
- the group, the size of the exponent used, and the entropy provided by
- the random number generator used. Due to these inputs, it is
- difficult to determine the strength of a key for any of the defined
- groups. Diffie-Hellman group number two, when used with a strong
- random number generator and an exponent no less than 200 bits, is
- common for use with 3DES. Group five provides greater security than
- group two. Group one is for historic purposes only and does not
- provide sufficient strength except for use with DES, which is also
- for historic use only. Implementations should make note of these
- estimates when establishing policy and negotiating security
- parameters.
-
- Note that these limitations are on the Diffie-Hellman groups
- themselves. There is nothing in IKE that prohibits using stronger
- groups nor is there anything that will dilute the strength obtained
- from stronger groups (limited by the strength of the other algorithms
- negotiated including the prf function). In fact, the extensible
- framework of IKE encourages the definition of more groups; use of
- elliptical curve groups may greatly increase strength using much
- smaller numbers.
-
-
-
-Kaufman Standards Track [Page 88]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- It is assumed that all Diffie-Hellman exponents are erased from
- memory after use. In particular, these exponents MUST NOT be derived
- from long-lived secrets like the seed to a pseudo-random generator
- that is not erased after use.
-
- The strength of all keys is limited by the size of the output of the
- negotiated prf function. For this reason, a prf function whose
- output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with
- this protocol.
-
- The security of this protocol is critically dependent on the
- randomness of the randomly chosen parameters. These should be
- generated by a strong random or properly seeded pseudo-random source
- (see [RFC4086]). Implementers should take care to ensure that use of
- random numbers for both keys and nonces is engineered in a fashion
- that does not undermine the security of the keys.
-
- For information on the rationale of many of the cryptographic design
- choices in this protocol, see [SIGMA] and [SKEME]. Though the
- security of negotiated CHILD_SAs does not depend on the strength of
- the encryption and integrity protection negotiated in the IKE_SA,
- implementations MUST NOT negotiate NONE as the IKE integrity
- protection algorithm or ENCR_NULL as the IKE encryption algorithm.
-
- When using pre-shared keys, a critical consideration is how to assure
- the randomness of these secrets. The strongest practice is to ensure
- that any pre-shared key contain as much randomness as the strongest
- key being negotiated. Deriving a shared secret from a password,
- name, or other low-entropy source is not secure. These sources are
- subject to dictionary and social engineering attacks, among others.
-
- The NAT_DETECTION_*_IP notifications contain a hash of the addresses
- and ports in an attempt to hide internal IP addresses behind a NAT.
- Since the IPv4 address space is only 32 bits, and it is usually very
- sparse, it would be possible for an attacker to find out the internal
- address used behind the NAT box by trying all possible IP addresses
- and trying to find the matching hash. The port numbers are normally
- fixed to 500, and the SPIs can be extracted from the packet. This
- reduces the number of hash calculations to 2^32. With an educated
- guess of the use of private address space, the number of hash
- calculations is much smaller. Designers should therefore not assume
- that use of IKE will not leak internal address information.
-
- When using an EAP authentication method that does not generate a
- shared key for protecting a subsequent AUTH payload, certain man-in-
- the-middle and server impersonation attacks are possible [EAPMITM].
- These vulnerabilities occur when EAP is also used in protocols that
- are not protected with a secure tunnel. Since EAP is a general-
-
-
-
-Kaufman Standards Track [Page 89]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- purpose authentication protocol, which is often used to provide
- single-signon facilities, a deployed IPsec solution that relies on an
- EAP authentication method that does not generate a shared key (also
- known as a non-key-generating EAP method) can become compromised due
- to the deployment of an entirely unrelated application that also
- happens to use the same non-key-generating EAP method, but in an
- unprotected fashion. Note that this vulnerability is not limited to
- just EAP, but can occur in other scenarios where an authentication
- infrastructure is reused. For example, if the EAP mechanism used by
- IKEv2 utilizes a token authenticator, a man-in-the-middle attacker
- could impersonate the web server, intercept the token authentication
- exchange, and use it to initiate an IKEv2 connection. For this
- reason, use of non-key-generating EAP methods SHOULD be avoided where
- possible. Where they are used, it is extremely important that all
- usages of these EAP methods SHOULD utilize a protected tunnel, where
- the initiator validates the responder's certificate before initiating
- the EAP exchange. Implementers SHOULD describe the vulnerabilities
- of using non-key-generating EAP methods in the documentation of their
- implementations so that the administrators deploying IPsec solutions
- are aware of these dangers.
-
- An implementation using EAP MUST also use a public-key-based
- authentication of the server to the client before the EAP exchange
- begins, even if the EAP method offers mutual authentication. This
- avoids having additional IKEv2 protocol variations and protects the
- EAP data from active attackers.
-
- If the messages of IKEv2 are long enough that IP-level fragmentation
- is necessary, it is possible that attackers could prevent the
- exchange from completing by exhausting the reassembly buffers. The
- chances of this can be minimized by using the Hash and URL encodings
- instead of sending certificates (see section 3.6). Additional
- mitigations are discussed in [KPS03].
-
-6. IANA Considerations
-
- This document defines a number of new field types and values where
- future assignments will be managed by the IANA.
-
- The following registries have been created by the IANA:
-
- IKEv2 Exchange Types (section 3.1)
- IKEv2 Payload Types (section 3.2)
- IKEv2 Transform Types (section 3.3.2)
- IKEv2 Transform Attribute Types (section 3.3.2)
- IKEv2 Encryption Transform IDs (section 3.3.2)
- IKEv2 Pseudo-random Function Transform IDs (section 3.3.2)
- IKEv2 Integrity Algorithm Transform IDs (section 3.3.2)
-
-
-
-Kaufman Standards Track [Page 90]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- IKEv2 Diffie-Hellman Transform IDs (section 3.3.2)
- IKEv2 Identification Payload ID Types (section 3.5)
- IKEv2 Certificate Encodings (section 3.6)
- IKEv2 Authentication Method (section 3.8)
- IKEv2 Notify Message Types (section 3.10.1)
- IKEv2 Notification IPCOMP Transform IDs (section 3.10.1)
- IKEv2 Security Protocol Identifiers (section 3.3.1)
- IKEv2 Traffic Selector Types (section 3.13.1)
- IKEv2 Configuration Payload CFG Types (section 3.15)
- IKEv2 Configuration Payload Attribute Types (section 3.15.1)
-
- Note: When creating a new Transform Type, a new registry for it must
- be created.
-
- Changes and additions to any of those registries are by expert
- review.
-
-7. Acknowledgements
-
- This document is a collaborative effort of the entire IPsec WG. If
- there were no limit to the number of authors that could appear on an
- RFC, the following, in alphabetical order, would have been listed:
- Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt
- Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John
- Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero
- Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer
- Reingold, and Michael Richardson. Many other people contributed to
- the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI,
- each of which has its own list of authors. Hugh Daniel suggested the
- feature of having the initiator, in message 3, specify a name for the
- responder, and gave the feature the cute name "You Tarzan, Me Jane".
- David Faucher and Valery Smyzlov helped refine the design of the
- traffic selector negotiation.
-
-8. References
-
-8.1. Normative References
-
- [ADDGROUP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
- Diffie-Hellman groups for Internet Key Exchange (IKE)",
- RFC 3526, May 2003.
-
- [ADDRIPV6] Hinden, R. and S. Deering, "Internet Protocol Version 6
- (IPv6) Addressing Architecture", RFC 3513, April 2003.
-
- [Bra97] Bradner, S., "Key Words for use in RFCs to indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
-
-
-
-Kaufman Standards Track [Page 91]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
- Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
- 3748, June 2004.
-
- [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
- Algorithms", RFC 2451, November 1998.
-
- [Hutt05] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
- Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
- 3948, January 2005.
-
- [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", BCP 26, RFC 2434,
- October 1998.
-
- [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
- of Explicit Congestion Notification (ECN) to IP", RFC
- 3168, September 2001.
-
- [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.
-
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
- Internet Protocol", RFC 4301, December 2005.
-
-8.2. Informative References
-
- [DES] ANSI X3.106, "American National Standard for Information
- Systems-Data Link Encryption", American National Standards
- Institute, 1983.
-
- [DH] Diffie, W., and Hellman M., "New Directions in
- Cryptography", IEEE Transactions on Information Theory, V.
- IT-22, n. 6, June 1977.
-
- [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC
- 2131, March 1997.
-
- [DSS] NIST, "Digital Signature Standard", FIPS 186, National
- Institute of Standards and Technology, U.S. Department of
- Commerce, May, 1994.
-
- [EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., "Man-in-the-Middle
- in Tunneled Authentication Protocols",
- http://eprint.iacr.org/2002/163, November 2002.
-
-
-
-
-Kaufman Standards Track [Page 92]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- [HC98] Harkins, D. and D. Carrel, "The Internet Key Exchange
- (IKE)", RFC 2409, November 1998.
-
- [IDEA] Lai, X., "On the Design and Security of Block Ciphers,"
- ETH Series in Information Processing, v. 1, Konstanz:
- Hartung-Gorre Verlag, 1992.
-
- [IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP
- Payload Compression Protocol (IPComp)", RFC 3173,
- September 2001.
-
- [KPS03] Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS
- protection for UDP-based protocols", ACM Conference on
- Computer and Communications Security, October 2003.
-
- [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
- Hashing for Message Authentication", RFC 2104, February
- 1997.
-
- [LDAP] Wahl, M., Howes, T., and S Kille, "Lightweight Directory
- Access Protocol (v3)", RFC 2251, December 1997.
-
- [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
- April 1992.
-
- [MSST98] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
- "Internet Security Association and Key Management Protocol
- (ISAKMP)", RFC 2408, November 1998.
-
- [Orm96] Orman, H., "The OAKLEY Key Determination Protocol", RFC
- 2412, November 1998.
-
- [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
- Management API, Version 2", RFC 2367, July 1998.
-
- [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
- Standards (PKCS) #1: RSA Cryptography Specifications
- Version 2.1", RFC 3447, February 2003.
-
- [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key
- exchange Standard", WET-ICE Security Conference, MIT,2001,
- http://sec.femto.org/wetice-2001/papers/radia-paper.pdf.
-
- [Pip98] Piper, D., "The Internet IP Security Domain Of
- Interpretation for ISAKMP", RFC 2407, November 1998.
-
-
-
-
-
-
-Kaufman Standards Track [Page 93]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- [RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
- "Remote Authentication Dial In User Service (RADIUS)", RFC
- 2865, June 2000.
-
- [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
- "Randomness Requirements for Security", BCP 106, RFC 4086,
- June 2005.
-
- [RFC1958] Carpenter, B., "Architectural Principles of the Internet",
- RFC 1958, June 1996.
-
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
- Internet Protocol", RFC 2401, November 1998.
-
- [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
- "Definition of the Differentiated Services Field (DS
- Field) in the IPv4 and IPv6 Headers", RFC 2474, December
- 1998.
-
- [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
- and W. Weiss, "An Architecture for Differentiated
- Service", RFC 2475, December 1998.
-
- [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
- Protocol", RFC 2522, March 1999.
-
- [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February
- 2000.
-
- [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
- 2983, October 2000.
-
- [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
- Guidelines and Philosophy", RFC 3439, December 2002.
-
- [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
- (NAT) Compatibility Requirements", RFC 3715, March 2004.
-
- [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
- 2005.
-
- [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
- 4303, December 2005.
-
- [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for
- Obtaining Digital Signatures and Public-Key
- Cryptosystems", Communications of the ACM, v. 21, n. 2,
- February 1978.
-
-
-
-Kaufman Standards Track [Page 94]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National
- Institute of Standards and Technology, U.S. Department of
- Commerce, May 1994.
-
- [SIGMA] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to
- Authenticated Diffie-Hellman and its Use in the IKE
- Protocols", in Advances in Cryptography - CRYPTO 2003
- Proceedings, LNCS 2729, Springer, 2003. Available at:
- http://www.informatik.uni-trier.de/~ley/db/conf/
- crypto/crypto2003.html.
-
- [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
- Mechanism for Internet", from IEEE Proceedings of the 1996
- Symposium on Network and Distributed Systems Security.
-
- [X.501] ITU-T Recommendation X.501: Information Technology - Open
- Systems Interconnection - The Directory: Models, 1993.
-
- [X.509] ITU-T Recommendation X.509 (1997 E): Information
- Technology - Open Systems Interconnection - The Directory:
- Authentication Framework, June 1997.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 95]
-\f
-RFC 4306 IKEv2 December 2005
-
-
-Appendix A: Summary of changes from IKEv1
-
- The goals of this revision to IKE are:
-
- 1) To define the entire IKE protocol in a single document, replacing
- RFCs 2407, 2408, and 2409 and incorporating subsequent changes to
- support NAT Traversal, Extensible Authentication, and Remote Address
- acquisition;
-
- 2) To simplify IKE by replacing the eight different initial exchanges
- with a single four-message exchange (with changes in authentication
- mechanisms affecting only a single AUTH payload rather than
- restructuring the entire exchange) see [PK01];
-
- 3) To remove the Domain of Interpretation (DOI), Situation (SIT), and
- Labeled Domain Identifier fields, and the Commit and Authentication
- only bits;
-
- 4) To decrease IKE's latency in the common case by making the initial
- exchange be 2 round trips (4 messages), and allowing the ability to
- piggyback setup of a CHILD_SA on that exchange;
-
- 5) To replace the cryptographic syntax for protecting the IKE
- messages themselves with one based closely on ESP to simplify
- implementation and security analysis;
-
- 6) To reduce the number of possible error states by making the
- protocol reliable (all messages are acknowledged) and sequenced.
- This allows shortening CREATE_CHILD_SA exchanges from 3 messages to
- 2;
-
- 7) To increase robustness by allowing the responder to not do
- significant processing until it receives a message proving that the
- initiator can receive messages at its claimed IP address, and not
- commit any state to an exchange until the initiator can be
- cryptographically authenticated;
-
- 8) To fix cryptographic weaknesses such as the problem with
- symmetries in hashes used for authentication documented by Tero
- Kivinen;
-
- 9) To specify Traffic Selectors in their own payloads type rather
- than overloading ID payloads, and making more flexible the Traffic
- Selectors that may be specified;
-
- 10) To specify required behavior under certain error conditions or
- when data that is not understood is received, to make it easier to
- make future revisions that do not break backward compatibility;
-
-
-
-Kaufman Standards Track [Page 96]
-\f
-RFC 4306 IKEv2 December 2005
-
-
- 11) To simplify and clarify how shared state is maintained in the
- presence of network failures and Denial of Service attacks; and
-
- 12) To maintain existing syntax and magic numbers to the extent
- possible to make it likely that implementations of IKEv1 can be
- enhanced to support IKEv2 with minimum effort.
-
-Appendix B: Diffie-Hellman Groups
-
- There are two Diffie-Hellman groups defined here for use in IKE.
- These groups were generated by Richard Schroeppel at the University
- of Arizona. Properties of these primes are described in [Orm96].
-
- The strength supplied by group one may not be sufficient for the
- mandatory-to-implement encryption algorithm and is here for historic
- reasons.
-
- Additional Diffie-Hellman groups have been defined in [ADDGROUP].
-
-B.1. Group 1 - 768 Bit MODP
-
- This group is assigned id 1 (one).
-
- The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } Its
- hexadecimal value is:
-
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
- 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
- 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
- A63A3620 FFFFFFFF FFFFFFFF
-
- The generator is 2.
-
-B.2. Group 2 - 1024 Bit MODP
-
- This group is assigned id 2 (two).
-
- The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
- Its hexadecimal value is:
-
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
- 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
- 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
- A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
- 49286651 ECE65381 FFFFFFFF FFFFFFFF
-
- The generator is 2.
-
-
-
-
-Kaufman Standards Track [Page 97]
-\f
-RFC 4306 IKEv2 December 2005
-
-
-Editor's Address
-
- Charlie Kaufman
- Microsoft Corporation
- 1 Microsoft Way
- Redmond, WA 98052
-
- Phone: 1-425-707-3335
- EMail: charliek@microsoft.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 98]
-\f
-RFC 4306 IKEv2 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.
-
-
-
-
-
-
-
-Kaufman Standards Track [Page 99]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group P. Eronen, Ed.
-Request for Comments: 4555 Nokia
-Category: Standards Track June 2006
-
-
- IKEv2 Mobility and Multihoming Protocol (MOBIKE)
-
-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 document describes the MOBIKE protocol, a mobility and
- multihoming extension to Internet Key Exchange (IKEv2). MOBIKE
- allows the IP addresses associated with IKEv2 and tunnel mode IPsec
- Security Associations to change. A mobile Virtual Private Network
- (VPN) client could use MOBIKE to keep the connection with the VPN
- gateway active while moving from one address to another. Similarly,
- a multihomed host could use MOBIKE to move the traffic to a different
- interface if, for instance, the one currently being used stops
- working.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen Standards Track [Page 1]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
-Table of Contents
-
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
- 1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 4
- 1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 4
- 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
- 2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5
- 2.2. Example Protocol Exchanges . . . . . . . . . . . . . . . . 6
- 2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 9
- 3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 10
- 3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 10
- 3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 10
- 3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 11
- 3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 11
- 3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 12
- 3.6. Updating Additional Addresses . . . . . . . . . . . . . . 15
- 3.7. Return Routability Check . . . . . . . . . . . . . . . . . 17
- 3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 18
- 3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 19
- 3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 20
- 3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 20
- 3.12. Dead Peer Detection . . . . . . . . . . . . . . . . . . . 20
- 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 21
- 4.1. Notify Messages - Error Types . . . . . . . . . . . . . . 21
- 4.2. Notify Messages - Status Types . . . . . . . . . . . . . . 21
- 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
- 5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 24
- 5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 24
- 5.3. Denial-of-Service Attacks against Third Parties . . . . . 25
- 5.4. Spoofing Network Connectivity Indications . . . . . . . . 26
- 5.5. Address and Topology Disclosure . . . . . . . . . . . . . 27
- 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
- 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
- 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
- 8.1. Normative References . . . . . . . . . . . . . . . . . . . 29
- 8.2. Informative References . . . . . . . . . . . . . . . . . . 29
- Appendix A. Implementation Considerations . . . . . . . . . . . . 31
- A.1. Links from SPD Cache to Outbound SAD Entries . . . . . . . 31
- A.2. Creating Outbound SAs . . . . . . . . . . . . . . . . . . 31
-
-
-
-
-
-
-
-
-
-
-
-Eronen Standards Track [Page 2]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
-1. Introduction
-
-1.1. Motivation
-
- IKEv2 is used for performing mutual authentication, as well as
- establishing and maintaining IPsec Security Associations (SAs). In
- the base IKEv2 protocol [IKEv2], the IKE SAs and tunnel mode IPsec
- SAs are created implicitly between the IP addresses that are used
- when the IKE_SA is established. These IP addresses are then used as
- the outer (tunnel header) addresses for tunnel mode IPsec packets
- (transport mode IPsec SAs are beyond the scope of this document).
- Currently, it is not possible to change these addresses after the
- IKE_SA has been created.
-
- There are scenarios where these IP addresses might change. One
- example is mobility: a host changes its point of network attachment
- and receives a new IP address. Another example is a multihoming host
- that would like to change to a different interface if, for instance,
- the currently used interface stops working for some reason.
-
- Although the problem can be solved by creating new IKE and IPsec SAs
- when the addresses need to be changed, this may not be optimal for
- several reasons. In some cases, creating a new IKE_SA may require
- user interaction for authentication, such as entering a code from a
- token card. Creating new SAs often involves expensive calculations
- and possibly a large number of round-trips. For these reasons, a
- mechanism for updating the IP addresses of existing IKE and IPsec SAs
- is needed. The MOBIKE protocol described in this document provides
- such a mechanism.
-
- The main scenario for MOBIKE is enabling a remote access VPN user to
- move from one address to another without re-establishing all security
- associations with the VPN gateway. For instance, a user could start
- from fixed Ethernet in the office and then disconnect the laptop and
- move to the office's wireless LAN. When the user leaves the office,
- the laptop could start using General Packet Radio Service (GPRS);
- when the user arrives home, the laptop could switch to the home
- wireless LAN. MOBIKE updates only the outer (tunnel header)
- addresses of IPsec SAs, and the addresses and other traffic selectors
- used inside the tunnel stay unchanged. Thus, mobility can be
- (mostly) invisible to applications and their connections using the
- VPN.
-
-
-
-
-
-
-
-
-
-Eronen Standards Track [Page 3]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- MOBIKE also supports more complex scenarios where the VPN gateway
- also has several network interfaces: these interfaces could be
- connected to different networks or ISPs, they may be a mix of IPv4
- and IPv6 addresses, and the addresses may change over time.
- Furthermore, both parties could be VPN gateways relaying traffic for
- other parties.
-
-1.2. Scope and Limitations
-
- This document focuses on the main scenario outlined above and
- supports only tunnel mode IPsec SAs.
-
- The mobility support in MOBIKE allows both parties to move, but does
- not provide a "rendezvous" mechanism that would allow simultaneous
- movement of both parties or discovery of the addresses when the
- IKE_SA is first established. Therefore, MOBIKE is best suited for
- situations where the address of at least one endpoint is relatively
- stable and can be discovered using existing mechanisms such as DNS
- (see Section 3.1).
-
- MOBIKE allows both parties to be multihomed; however, only one pair
- of addresses is used for an SA at a time. In particular, load
- balancing is beyond the scope of this specification.
-
- MOBIKE follows the IKEv2 practice where a response message is sent to
- the same address and port from which the request was received. This
- implies that MOBIKE does not work over address pairs that provide
- only unidirectional connectivity.
-
- Network Address Translators (NATs) introduce additional limitations
- beyond those listed above. For details, refer to Section 2.3.
-
- The base version of the MOBIKE protocol does not cover all potential
- future use scenarios, such as transport mode, application to securing
- SCTP, or optimizations desirable in specific circumstances. Future
- extensions may be defined later to support additional requirements.
- Please consult the MOBIKE design document [Design] for further
- information and rationale behind these limitations.
-
-1.3. Terminology and Notation
-
- 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+"). To provide context, some diagrams also show what
- existing IKEv2 payloads would typically be included in the exchanges.
- These payloads are shown for illustrative purposes only; see [IKEv2]
- for an authoritative description.
-
-
-
-Eronen Standards Track [Page 4]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- When this document describes updating the source/destination
- addresses of an IPsec SA, it means updating IPsec-related state so
- that outgoing Encapsulating Security Payload (ESP)/Authentication
- Header (AH) packets use those addresses in the tunnel header.
- Depending on how the nominal divisions between Security Association
- Database (SAD), Security Policy Database (SPD), and Peer
- Authorization Database (PAD) described in [IPsecArch] are actually
- implemented, an implementation can have several different places that
- have to be updated.
-
- In this document, the term "initiator" means the party who originally
- initiated the first IKE_SA (in a series of possibly several rekeyed
- IKE_SAs); "responder" is the other peer. During the lifetime of the
- IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA
- exchanges; in this case, the terms "exchange initiator" and "exchange
- responder" are used. The term "original initiator" (which in [IKEv2]
- refers to the party who started the latest IKE_SA rekeying) is not
- 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 [KEYWORDS].
-
-2. Protocol Overview
-
-2.1. Basic Operation
-
- MOBIKE allows both parties to have several addresses, and there are
- up to N*M pairs of IP addresses that could potentially be used. The
- decision of which of these pairs to use has to take into account
- several factors. First, the parties may have preferences about which
- interface should be used due to, for instance, performance and cost
- reasons. Second, the decision is constrained by the fact that some
- of the pairs may not work at all due to incompatible IP versions,
- outages in the network, problems at the local link at either end, and
- so on.
-
- MOBIKE solves this problem by taking a simple approach: the party
- that initiated the IKE_SA (the "client" in a remote access VPN
- scenario) is responsible for deciding which address pair is used for
- the IPsec SAs and for collecting the information it needs to make
- this decision (such as determining which address pairs work or do not
- work). The other party (the "gateway" in a remote access VPN
- scenario) simply tells the initiator what addresses it has, but does
- not update the IPsec SAs until it receives a message from the
- initiator to do so. This approach applies to the addresses in the
- IPsec SAs; in the IKE_SA case, the exchange initiator can decide
- which addresses are used.
-
-
-
-Eronen Standards Track [Page 5]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- Making the decision at the initiator is consistent with how normal
- IKEv2 works: the initiator decides which addresses it uses when
- contacting the responder. It also makes sense, especially when the
- initiator is a mobile node: it is in a better position to decide
- which of its network interfaces should be used for both upstream and
- downstream traffic.
-
- The details of exactly how the initiator makes the decision, what
- information is used in making it, how the information is collected,
- how preferences affect the decision, and when a decision needs to be
- changed are largely beyond the scope of MOBIKE. This does not mean
- that these details are unimportant: on the contrary, they are likely
- to be crucial in any real system. However, MOBIKE is concerned with
- these details only to the extent that they are visible in IKEv2/IPsec
- messages exchanged between the peers (and thus need to be
- standardized to ensure interoperability).
-
- Many of these issues are not specific to MOBIKE, but are common with
- the use of existing hosts in dynamic environments or with mobility
- protocols such as Mobile IP [MIP4] [MIP6]. A number of mechanisms
- already exist or are being developed to deal with these issues. For
- instance, link-layer and IP-layer mechanisms can be used to track the
- status of connectivity within the local link [RFC2461]; movement
- detection is being specified for both IPv4 and IPv6 in [DNA4],
- [DNA6], and so on.
-
- Naturally, updating the addresses of IPsec SAs has to take into
- account several security considerations. MOBIKE includes two
- features designed to address these considerations. First, a "return
- routability" check can be used to verify the addresses provided by
- the peer. This makes it more difficult to flood third parties with
- large amounts of traffic. Second, a "NAT prohibition" feature
- ensures that IP addresses have not been modified by NATs, IPv4/IPv6
- translation agents, or other similar devices. This feature is
- enabled only when NAT Traversal is not used.
-
-2.2. Example Protocol Exchanges
-
- A simple MOBIKE exchange in a mobile scenario is illustrated below.
- The notation is based on [IKEv2], Section 1.2. In addition, the
- source/destination IP addresses and ports are shown for each packet:
- here IP_I1, IP_I2, IP_R1, and IP_R2 represent IP addresses used by
- the initiator and the responder.
-
-
-
-
-
-
-
-
-Eronen Standards Track [Page 6]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- Initiator Responder
- ----------- -----------
- 1) (IP_I1:500 -> IP_R1:500)
- HDR, SAi1, KEi, Ni,
- N(NAT_DETECTION_SOURCE_IP),
- N(NAT_DETECTION_DESTINATION_IP) -->
-
- <-- (IP_R1:500 -> IP_I1:500)
- HDR, SAr1, KEr, Nr,
- N(NAT_DETECTION_SOURCE_IP),
- N(NAT_DETECTION_DESTINATION_IP)
-
- 2) (IP_I1:4500 -> IP_R1:4500)
- HDR, SK { IDi, CERT, AUTH,
- CP(CFG_REQUEST),
- SAi2, TSi, TSr,
- N(MOBIKE_SUPPORTED) } -->
-
- <-- (IP_R1:4500 -> IP_I1:4500)
- HDR, SK { IDr, CERT, AUTH,
- CP(CFG_REPLY),
- SAr2, TSi, TSr,
- N(MOBIKE_SUPPORTED) }
-
- (Initiator gets information from lower layers that its attachment
- point and address have changed.)
-
- 3) (IP_I2:4500 -> IP_R1:4500)
- HDR, SK { N(UPDATE_SA_ADDRESSES),
- N(NAT_DETECTION_SOURCE_IP),
- N(NAT_DETECTION_DESTINATION_IP) } -->
-
- <-- (IP_R1:4500 -> IP_I2:4500)
- HDR, SK { N(NAT_DETECTION_SOURCE_IP),
- N(NAT_DETECTION_DESTINATION_IP) }
-
- (Responder verifies that the initiator has given it a correct IP
- address.)
-
- 4) <-- (IP_R1:4500 -> IP_I2:4500)
- HDR, SK { N(COOKIE2) }
-
- (IP_I2:4500 -> IP_R1:4500)
- HDR, SK { N(COOKIE2) } -->
-
- Step 1 is the normal IKE_INIT exchange. In step 2, the peers inform
- each other that they support MOBIKE. In step 3, the initiator
- notices a change in its own address, and informs the responder about
-
-
-
-Eronen Standards Track [Page 7]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- this by sending an INFORMATIONAL request containing the
- UPDATE_SA_ADDRESSES notification. The request is sent using the new
- IP address. At this point, it also starts to use the new address as
- a source address in its own outgoing ESP traffic. Upon receiving the
- UPDATE_SA_ADDRESSES notification, the responder records the new
- address and, if it is required by policy, performs a return
- routability check of the address. When this check (step 4)
- completes, the responder starts to use the new address as the
- destination for its outgoing ESP traffic.
-
- Another protocol run in a multihoming scenario is illustrated below.
- In this scenario, the initiator has one address but the responder has
- two.
-
- Initiator Responder
- ----------- -----------
- 1) (IP_I1:500 -> IP_R1:500)
- HDR, SAi1, KEi, Ni,
- N(NAT_DETECTION_SOURCE_IP),
- N(NAT_DETECTION_DESTINATION_IP) -->
-
- <-- (IP_R1:500 -> IP_I1:500)
- HDR, SAr1, KEr, Nr,
- N(NAT_DETECTION_SOURCE_IP),
- N(NAT_DETECTION_DESTINATION_IP)
-
- 2) (IP_I1:4500 -> IP_R1:4500)
- HDR, SK { IDi, CERT, AUTH,
- CP(CFG_REQUEST),
- SAi2, TSi, TSr,
- N(MOBIKE_SUPPORTED) } -->
-
- <-- (IP_R1:4500 -> IP_I1:4500)
- HDR, SK { IDr, CERT, AUTH,
- CP(CFG_REPLY),
- SAr2, TSi, TSr,
- N(MOBIKE_SUPPORTED),
- N(ADDITIONAL_IP4_ADDRESS) }
-
- (The initiator suspects a problem in the currently used address pair
- and probes its liveness.)
-
-
-
-
-
-
-
-
-
-
-Eronen Standards Track [Page 8]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- 3) (IP_I1:4500 -> IP_R1:4500)
- HDR, SK { N(NAT_DETECTION_SOURCE_IP),
- N(NAT_DETECTION_DESTINATION_IP) } -->
-
- (IP_I1:4500 -> IP_R1:4500)
- HDR, SK { N(NAT_DETECTION_SOURCE_IP),
- N(NAT_DETECTION_DESTINATION_IP) } -->
-
- ...
-
- (Eventually, the initiator gives up on the current address pair and
- tests the other available address pair.)
-
- 4) (IP_I1:4500 -> IP_R2:4500)
- HDR, SK { N(NAT_DETECTION_SOURCE_IP),
- N(NAT_DETECTION_DESTINATION_IP) }
-
- <-- (IP_R2:4500 -> IP_I1:4500)
- HDR, SK { N(NAT_DETECTION_SOURCE_IP),
- N(NAT_DETECTION_DESTINATION_IP) }
-
- (This worked, and the initiator requests the peer to switch to new
- addresses.)
-
- 5) (IP_I1:4500 -> IP_R2:4500)
- HDR, SK { N(UPDATE_SA_ADDRESSES),
- N(NAT_DETECTION_SOURCE_IP),
- N(NAT_DETECTION_DESTINATION_IP),
- N(COOKIE2) } -->
-
- <-- (IP_R2:4500 -> IP_I1:4500)
- HDR, SK { N(NAT_DETECTION_SOURCE_IP),
- N(NAT_DETECTION_DESTINATION_IP),
- N(COOKIE2) }
-
-2.3. MOBIKE and Network Address Translation (NAT)
-
- In some MOBIKE scenarios, the network may contain NATs or stateful
- packet filters (for brevity, the rest of this document simply
- describes NATs). The NAT Traversal feature specified in [IKEv2]
- allows IKEv2 to work through NATs in many cases, and MOBIKE can
- leverage this functionality: when the addresses used for IPsec SAs
- are changed, MOBIKE can enable or disable IKEv2 NAT Traversal, as
- needed.
-
- Nevertheless, there are some limitations because NATs usually
- introduce an asymmetry into the network: only packets coming from the
- "inside" cause state to be created. This asymmetry leads to
-
-
-
-Eronen Standards Track [Page 9]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- restrictions on what MOBIKE can do. To give a concrete example,
- consider a situation where both peers have only a single address, and
- the initiator is behind a NAT. If the responder's address now
- changes, it needs to send a packet to the initiator using its new
- address. However, if the NAT is, for instance, of the common
- "restricted cone" type (see [STUN] for one description of different
- NAT types), this is not possible. The NAT will drop packets sent
- from the new address (unless the initiator has previously sent a
- packet to that address -- which it cannot do until it knows the
- address).
-
- For simplicity, MOBIKE does not attempt to handle all possible NAT-
- related scenarios. Instead, MOBIKE assumes that if NATs are present,
- the initiator is the party "behind" the NAT, and the case where the
- responder's addresses change is not fully supported (meaning that no
- special effort is made to support this functionality). Responders
- may also be unaware of NATs or specific types of NATs they are
- behind. However, when a change has occurred that will cause a loss
- of connectivity, MOBIKE responders will still attempt to inform the
- initiator of the change. Depending on, for instance, the exact type
- of NAT, it may or may not succeed. However, analyzing the exact
- circumstances when this will or will not work is not done in this
- document.
-
-3. Protocol Exchanges
-
-3.1. Initial IKE Exchange
-
- The initiator is responsible for finding a working pair of addresses
- so that the initial IKE exchange can be carried out. Any information
- from MOBIKE extensions will only be available later, when the
- exchange has progressed far enough. Exactly how the addresses used
- for the initial exchange are discovered is beyond the scope of this
- specification; typical sources of information include local
- configuration and DNS.
-
- If either or both of the peers have multiple addresses, some
- combinations may not work. Thus, the initiator SHOULD try various
- source and destination address combinations when retransmitting the
- IKE_SA_INIT request.
-
-3.2. Signaling Support for MOBIKE
-
- Implementations that wish to use MOBIKE for a particular IKE_SA MUST
- include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in
- case of multiple IKE_AUTH exchanges, in the message containing the SA
- payload).
-
-
-
-
-Eronen Standards Track [Page 10]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- The format of the MOBIKE_SUPPORTED notification is described in
- Section 4.
-
-3.3. Initial Tunnel Header Addresses
-
- When an IPsec SA is created, the tunnel header IP addresses (and
- port, if doing UDP encapsulation) are taken from the IKE_SA, not the
- IP header of the IKEv2 message requesting the IPsec SA. The
- addresses in the IKE_SA are initialized from the IP header of the
- first IKE_AUTH request.
-
- The addresses are taken from the IKE_AUTH request because IKEv2
- requires changing from port 500 to 4500 if a NAT is discovered. To
- simplify things, implementations that support both this specification
- and NAT Traversal MUST change to port 4500 if the correspondent also
- supports both, even if no NAT was detected between them (this way,
- there is no need to change the ports later if a NAT is detected on
- some other path).
-
-3.4. Additional Addresses
-
- Both the initiator and responder MAY include one or more
- ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in
- the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the
- message containing the SA payload). Here "ADDITIONAL_*_ADDRESS"
- means either an ADDITIONAL_IP4_ADDRESS or an ADDITIONAL_IP6_ADDRESS
- notification.
-
- Initiator Responder
- ----------- -----------
- HDR, SK { IDi, [CERT], [IDr], AUTH,
- [CP(CFG_REQUEST)]
- SAi2, TSi, TSr,
- N(MOBIKE_SUPPORTED),
- [N(ADDITIONAL_*_ADDRESS)+] } -->
-
- <-- HDR, SK { IDr, [CERT], AUTH,
- [CP(CFG_REPLY)],
- SAr2, TSi, TSr,
- N(MOBIKE_SUPPORTED)
- [N(ADDITIONAL_*_ADDRESS)+] }
-
- The recipient stores this information, but no other action is taken
- at this time.
-
- Although both the initiator and responder maintain a set of peer
- addresses (logically associated with the IKE_SA), it is important to
- note that they use this information for slightly different purposes.
-
-
-
-Eronen Standards Track [Page 11]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- The initiator uses the set of responder addresses as an input to its
- address selection policy; it may, at some later point, decide to move
- the IPsec traffic to one of these addresses using the procedure
- described in Section 3.5. The responder normally does not use the
- set of initiator addresses for anything: the addresses are used only
- when the responder's own addresses change (see Section 3.6).
-
- The set of addresses available to the peers can change during the
- lifetime of the IKE_SA. The procedure for updating this information
- is described in Section 3.6.
-
- Note that if some of the initiator's interfaces are behind a NAT
- (from the responder's point of view), the addresses received by the
- responder will be incorrect. This means the procedure for changing
- responder addresses described in Section 3.6 does not fully work when
- the initiator is behind a NAT. For the same reason, the peers also
- SHOULD NOT use this information for any other purpose than what is
- explicitly described either in this document or a future
- specification updating it.
-
-3.5. Changing Addresses in IPsec SAs
-
- In MOBIKE, the initiator decides what addresses are used in the IPsec
- SAs. That is, the responder does not normally update any IPsec SAs
- without receiving an explicit UPDATE_SA_ADDRESSES request from the
- initiator. (As described below, the responder can, however, update
- the IKE_SA in some circumstances.)
-
- The reasons why the initiator wishes to change the addresses are
- largely beyond the scope of MOBIKE. Typically, triggers include
- information received from lower layers, such as changes in IP
- addresses or link-down indications. Some of this information can be
- unreliable: for instance, ICMP messages could be spoofed by an
- attacker. Unreliable information SHOULD be treated only as a hint
- that there might be a problem, and the initiator SHOULD trigger Dead
- Peer Detection (that is, send an INFORMATIONAL request) to determine
- if the current path is still usable.
-
- Changing addresses can also be triggered by events within IKEv2. At
- least the following events can cause the initiator to re-evaluate its
- local address selection policy, possibly leading to changing the
- addresses.
-
- o An IKEv2 request has been re-transmitted several times, but no
- valid reply has been received. This suggests the current path is
- no longer working.
-
-
-
-
-
-Eronen Standards Track [Page 12]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- o An INFORMATIONAL request containing an ADDITIONAL_IP4_ADDRESS,
- ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is
- received. This means the peer's addresses may have changed. This
- is particularly important if the announced set of addresses no
- longer contains the currently used address.
-
- o An UNACCEPTABLE_ADDRESSES notification is received as a response
- to address update request (described below).
-
- o The initiator receives a NAT_DETECTION_DESTINATION_IP notification
- that does not match the previous UPDATE_SA_ADDRESSES response (see
- Section 3.8 for a more detailed description).
-
- The description in the rest of this section assumes that the
- initiator has already decided what the new addresses should be. When
- this decision has been made, the initiator:
-
- o Updates the IKE_SA with the new addresses, and sets the
- "pending_update" flag in the IKE_SA.
-
- o Updates the IPsec SAs associated with this IKE_SA with the new
- addresses (unless the initiator's policy requires a return
- routability check before updating the IPsec SAs, and the check has
- not been done for this responder address yet).
-
- o If the IPsec SAs were updated in the previous step: If NAT
- Traversal is not enabled, and the responder supports NAT Traversal
- (as indicated by NAT detection payloads in the IKE_SA_INIT
- exchange), and the initiator either suspects or knows that a NAT
- is likely to be present, enables NAT Traversal (that is, enables
- UDP encapsulation of outgoing ESP packets and sending of NAT-
- Keepalive packets).
-
- o If there are outstanding IKEv2 requests (requests for which the
- initiator has not yet received a reply), continues retransmitting
- them using the addresses in the IKE_SA (the new addresses).
-
- o When the window size allows, sends an INFORMATIONAL request
- containing the UPDATE_SA_ADDRESSES notification (which does not
- contain any data), and clears the "pending_update" flag. The
- request will be as follows:
-
-
-
-
-
-
-
-
-
-
-Eronen Standards Track [Page 13]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- Initiator Responder
- ----------- -----------
- HDR, SK { N(UPDATE_SA_ADDRESSES),
- [N(NAT_DETECTION_SOURCE_IP),
- N(NAT_DETECTION_DESTINATION_IP)],
- [N(NO_NATS_ALLOWED)],
- [N(COOKIE2)] } -->
-
- o If a new address change occurs while waiting for the response,
- starts again from the first step (and ignores responses to this
- UPDATE_SA_ADDRESSES request).
-
- When processing an INFORMATIONAL request containing the
- UPDATE_SA_ADDRESSES notification, the responder:
-
- o Determines whether it has already received a newer
- UPDATE_SA_ADDRESSES request than this one (if the responder uses a
- window size greater than one, it is possible that requests are
- received out of order). If it has, a normal response message
- (described below) is sent, but no other action is taken.
-
- o If the NO_NATS_ALLOWED notification is present, processes it as
- described in Section 3.9.
-
- o Checks that the (source IP address, destination IP address) pair
- in the IP header is acceptable according to local policy. If it
- is not, replies with a message containing the
- UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2).
-
- o Updates the IP addresses in the IKE_SA with the values from the IP
- header. (Using the address from the IP header is consistent with
- normal IKEv2, and allows IKEv2 to work with NATs without needing
- unilateral self-address fixing [UNSAF].)
-
- o Replies with an INFORMATIONAL response:
-
- Initiator Responder
- ----------- -----------
- <-- HDR, SK { [N(NAT_DETECTION_SOURCE_IP),
- N(NAT_DETECTION_DESTINATION_IP)],
- [N(COOKIE2)] }
-
- o If necessary, initiates a return routability check for the new
- initiator address (see Section 3.7) and waits until the check is
- completed.
-
- o Updates the IPsec SAs associated with this IKE_SA with the new
- addresses.
-
-
-
-Eronen Standards Track [Page 14]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- o If NAT Traversal is supported and NAT detection payloads were
- included, enables or disables NAT Traversal.
-
- When the initiator receives the reply:
-
- o If an address change has occurred after the request was first
- sent, no MOBIKE processing is done for the reply message because a
- new UPDATE_SA_ADDRESSES is going to be sent (or has already been
- sent, if window size greater than one is in use).
-
- o If the response contains the UNEXPECTED_NAT_DETECTED notification,
- the initiator processes the response as described in Section 3.9.
-
- o If the response contains an UNACCEPTABLE_ADDRESSES notification,
- the initiator MAY select another addresses and retry the exchange,
- keep on using the previously used addresses, or disconnect.
-
- o It updates the IPsec SAs associated with this IKE_SA with the new
- addresses (unless this was already done earlier before sending the
- request; this is the case when no return routability check was
- required).
-
- o If NAT Traversal is supported and NAT detection payloads were
- included, the initiator enables or disables NAT Traversal.
-
- There is one exception to the rule that the responder never updates
- any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If
- the source address that the responder is currently using becomes
- unavailable (i.e., sending packets using that source address is no
- longer possible), the responder is allowed to update the IPsec SAs to
- use some other address (in addition to initiating the procedure
- described in the next section).
-
-3.6. Updating Additional Addresses
-
- As described in Section 3.4, both the initiator and responder can
- send a list of additional addresses in the IKE_AUTH exchange. This
- information can be updated by sending an INFORMATIONAL exchange
- request message that contains either one or more
- ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications or the
- NO_ADDITIONAL_ADDRESSES notification.
-
- If the exchange initiator has only a single IP address, it is placed
- in the IP header, and the message contains the
- NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has
- several addresses, one of them is placed in the IP header, and the
- rest in ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications.
-
-
-
-
-Eronen Standards Track [Page 15]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- The new list of addresses replaces the old information (in other
- words, there are no separate add/delete operations; instead, the
- complete list is sent every time these notifications are used).
-
- The message exchange will look as follows:
-
- Initiator Responder
- ----------- -----------
- HDR, SK { [N(ADDITIONAL_*_ADDRESS)+],
- [N(NO_ADDITIONAL_ADDRESSES)],
- [N(NO_NATS_ALLOWED)],
- [N(COOKIE2)] } -->
-
- <-- HDR, SK { [N(COOKIE2)] }
-
- When a request containing an ADDITIONAL_IP4_ADDRESS,
- ADDITIONAL_IP6_ADDRESS, or NO_ADDITIONAL_ADDRESSES notification is
- received, the exchange responder:
-
- o Determines whether it has already received a newer request to
- update the addresses (if a window size greater than one is used,
- it is possible that the requests are received out of order). If
- it has, a response message is sent, but the address set is not
- updated.
-
- o If the NO_NATS_ALLOWED notification is present, processes it as
- described in Section 3.9.
-
- o Updates the set of peer addresses based on the IP header and the
- ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS, and
- NO_ADDITIONAL_ADDRESSES notifications.
-
- o Sends a response.
-
- The initiator MAY include these notifications in the same request as
- UPDATE_SA_ADDRESSES.
-
- If the request to update the addresses is retransmitted using several
- different source addresses, a new INFORMATIONAL request MUST be sent.
-
- There is one additional complication: when the responder wants to
- update the address set, the currently used addresses may no longer
- work. In this case, the responder uses the additional address list
- received from the initiator, and the list of its own addresses, to
- determine which addresses to use for sending the INFORMATIONAL
- request. This is the only time the responder uses the additional
- address list received from the initiator.
-
-
-
-
-Eronen Standards Track [Page 16]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- Note that both peers can have their own policies about what addresses
- are acceptable to use, and certain types of policies may simplify
- implementation. For instance, if the responder has a single fixed
- address, it does not need to process the ADDITIONAL_IP4_ADDRESS and
- ADDITIONAL_IP6_ADDRESS notifications it receives (beyond ignoring
- unrecognized status notifications, as already required in [IKEv2]).
- Furthermore, if the initiator has a policy saying that only the
- responder address specified in local configuration is acceptable, it
- does not have to send its own additional addresses to the responder
- (since the responder does not need them except when changing its own
- address).
-
-3.7. Return Routability Check
-
- Both parties can optionally verify that the other party can actually
- receive packets at the claimed address. By default, this "return
- routability check" SHOULD be performed. In environments where the
- peer is expected to be well-behaved (many corporate VPNs, for
- instance), or the address can be verified by some other means (e.g.,
- a certificate issued by an authority trusted for this purpose), the
- return routability check MAY be omitted.
-
- The check can be done before updating the IPsec SAs, immediately
- after updating them, or continuously during the connection. By
- default, the return routability check SHOULD be done before updating
- the IPsec SAs, but in some environments it MAY be postponed until
- after the IPsec SAs have been updated.
-
- Any INFORMATIONAL exchange can be used for return routability
- purposes, with one exception (described later in this section): when
- a valid response is received, we know the other party can receive
- packets at the claimed address.
-
- To ensure that the peer cannot generate the correct INFORMATIONAL
- response without seeing the request, a new payload is added to
- INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY
- include a COOKIE2 notification, and if included, the recipient of an
- INFORMATIONAL request MUST copy the notification as-is to the
- response. When processing the response, the original sender MUST
- verify that the value is the same one as sent. If the values do not
- match, the IKE_SA MUST be closed. (See also Section 4.2.5 for the
- format of the COOKIE2 notification.)
-
-
-
-
-
-
-
-
-
-Eronen Standards Track [Page 17]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- The exception mentioned earlier is as follows: If the same
- INFORMATIONAL request has been sent to several different addresses
- (i.e., the destination address in the IKE_SA has been updated after
- the request was first sent), receiving the INFORMATIONAL response
- does not tell which address is the working one. In this case, a new
- INFORMATIONAL request needs to be sent to check return routability.
-
-3.8. Changes in NAT Mappings
-
- IKEv2 performs Dead Peer Detection (DPD) if there has recently been
- only outgoing traffic on all of the SAs associated with the IKE_SA.
-
- In MOBIKE, these messages can also be used to detect if NAT mappings
- have changed (for example, if the keepalive interval is too long, or
- the NAT box is rebooted). More specifically, if both peers support
- both this specification and NAT Traversal, the
- NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
- notifications MAY be included in any INFORMATIONAL request; if the
- request includes them, the responder MUST also include them in the
- response (but no other action is taken, unless otherwise specified).
-
- When the initiator is behind a NAT (as detected earlier using the
- NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
- notifications), it SHOULD include these notifications in DPD messages
- and compare the received NAT_DETECTION_DESTINATION_IP notifications
- with the value from the previous UPDATE_SA_ADDRESSES response (or the
- IKE_SA_INIT response). If the values do not match, the IP address
- and/or port seen by the responder has changed, and the initiator
- SHOULD send UPDATE_SA_ADDRESSES as described in Section 3.5. If the
- initiator suspects that the NAT mapping has changed, it MAY also skip
- the detection step and send UPDATE_SA_ADDRESSES immediately. This
- saves one roundtrip if the NAT mapping has indeed changed.
-
- Note that this approach to detecting NAT mapping changes may cause an
- extra address update when the IKE_SA is rekeyed. This is because the
- NAT_DETECTION_DESTINATION_IP hash also includes the IKE Security
- Parameter Indexes (SPIs), which change when performing rekeying.
- This unnecessary update is harmless, however.
-
- When MOBIKE is in use, the dynamic updates (specified in [IKEv2],
- Section 2.23), where the peer address and port are updated from the
- last valid authenticated packet, work in a slightly different
- fashion. The host not behind a NAT MUST NOT use these dynamic
- updates for IKEv2 packets, but MAY use them for ESP packets. This
- ensures that an INFORMATIONAL exchange that does not contain
- UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be
- used for, e.g., testing whether a particular path works.
-
-
-
-
-Eronen Standards Track [Page 18]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
-3.9. NAT Prohibition
-
- Basic IKEv2/IPsec without NAT Traversal support may work across some
- types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in
- tunnel mode. This is because the IKEv2 integrity checksum does not
- cover the addresses in the IP header. This may be considered a
- problem in some circumstances, because in some sense any modification
- of the IP addresses can be considered an attack.
-
- This specification addresses the issue by protecting the IP addresses
- when NAT Traversal has not been explicitly enabled. This means that
- MOBIKE without NAT Traversal support will not work if the paths
- contain NATs, IPv4/IPv6 translation agents, or other nodes that
- modify the addresses in the IP header. This feature is mainly
- intended for IPv6 and site-to-site VPN cases, where the
- administrators may know beforehand that NATs are not present, and
- thus any modification to the packet can be considered an attack.
-
- More specifically, when NAT Traversal is not enabled, all messages
- that can update the addresses associated with the IKE_SA and/or IPsec
- SAs (the first IKE_AUTH request and all INFORMATIONAL requests that
- contain any of the following notifications: UPDATE_SA_ADDRESSES,
- ADDITIONAL_IP4_ADDRESS, ADDITIONAL_IP6_ADDRESS,
- NO_ADDITIONAL_ADDRESSES) MUST also include a NO_NATS_ALLOWED
- notification. The exchange responder MUST verify that the contents
- of the NO_NATS_ALLOWED notification match the addresses in the IP
- header. If they do not match, a response containing an
- UNEXPECTED_NAT_DETECTED notification is sent. The response message
- is sent to the address and port that the corresponding request came
- from, not to the address contained in the NO_NATS_ALLOWED
- notification.
-
- If the exchange initiator receives an UNEXPECTED_NAT_DETECTED
- notification in response to its INFORMATIONAL request, it SHOULD
- retry the operation several times using new INFORMATIONAL requests.
- Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the
- IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several
- times, starting from a new IKE_SA_INIT request. This ensures that an
- attacker who is able to modify only a single packet does not
- unnecessarily cause a path to remain unused. The exact number of
- retries is not specified in this document because it does not affect
- interoperability. However, because the IKE message will also be
- rejected if the attacker modifies the integrity checksum field, a
- reasonable number here would be the number of retries that is being
- used for normal retransmissions.
-
-
-
-
-
-
-Eronen Standards Track [Page 19]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange
- responder MUST NOT use the contents of the NO_NATS_ALLOWED
- notification for any other purpose than possibly logging the
- information for troubleshooting purposes.
-
-3.10. Path Testing
-
- IKEv2 Dead Peer Detection allows the peers to detect if the currently
- used path has stopped working. However, if either of the peers has
- several addresses, Dead Peer Detection alone does not tell which of
- the other paths might work.
-
- If required by its address selection policy, the initiator can use
- normal IKEv2 INFORMATIONAL request/response messages to test whether
- a certain path works. Implementations MAY do path testing even if
- the path currently being used is working to, for example, detect when
- a better (but previously unavailable) path becomes available.
-
-3.11. Failure Recovery and Timeouts
-
- In MOBIKE, the initiator is responsible for detecting and recovering
- from most failures.
-
- To give the initiator enough time to detect the error, the responder
- SHOULD use relatively long timeout intervals when, for instance,
- retransmitting IKEv2 requests or deciding whether to initiate Dead
- Peer Detection. While no specific timeout lengths are required, it
- is suggested that responders continue retransmitting IKEv2 requests
- for at least five minutes before giving up.
-
-3.12. Dead Peer Detection
-
- MOBIKE uses the same Dead Peer Detection method as normal IKEv2, but
- as addresses may change, it is not sufficient to just verify that the
- peer is alive, but also that it is synchronized with the address
- updates and has not, for instance, ignored an address update due to
- failure to complete return routability test. This means that when
- there are incoming IPsec packets, MOBIKE nodes SHOULD inspect the
- addresses used in those packets and determine that they correspond to
- those that should be employed. If they do not, such packets SHOULD
- NOT be used as evidence that the peer is able to communicate with
- this node and or that the peer has received all address updates.
-
-
-
-
-
-
-
-
-
-Eronen Standards Track [Page 20]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
-4. Payload Formats
-
- This specification defines several new IKEv2 Notify payload types.
- See [IKEv2], Section 3.10, for a general description of the Notify
- payload.
-
-4.1. Notify Messages - Error Types
-
-4.1.1. UNACCEPTABLE_ADDRESSES Notify Payload
-
- The responder can include this notification in an INFORMATIONAL
- exchange response to indicate that the address change in the
- corresponding request message (which contained an UPDATE_SA_ADDRESSES
- notification) was not carried out.
-
- The Notify Message Type for UNACCEPTABLE_ADDRESSES is 40. The
- Protocol ID and SPI Size fields are set to zero. There is no data
- associated with this Notify type.
-
-4.1.2. UNEXPECTED_NAT_DETECTED Notify Payload
-
- See Section 3.9 for a description of this notification.
-
- The Notify Message Type for UNEXPECTED_NAT_DETECTED is 41. The
- Protocol ID and SPI Size fields are set to zero. There is no data
- associated with this Notify type.
-
-4.2. Notify Messages - Status Types
-
-4.2.1. MOBIKE_SUPPORTED Notify Payload
-
- The MOBIKE_SUPPORTED notification is included in the IKE_AUTH
- exchange to indicate that the implementation supports this
- specification.
-
- The Notify Message Type for MOBIKE_SUPPORTED is 16396. The Protocol
- ID and SPI Size fields are set to zero. The notification data field
- MUST be left empty (zero-length) when sending, and its contents (if
- any) MUST be ignored when this notification is received. This allows
- the field to be used by future versions of this protocol.
-
-4.2.2. ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify
- Payloads
-
- Both parties can include ADDITIONAL_IP4_ADDRESS and/or
- ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and
- INFORMATIONAL exchange request messages; see Section 3.4 and
- Section 3.6 for more detailed description.
-
-
-
-Eronen Standards Track [Page 21]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- The Notify Message Types for ADDITIONAL_IP4_ADDRESS and
- ADDITIONAL_IP6_ADDRESS are 16397 and 16398, respectively. The
- Protocol ID and SPI Size fields are set to zero. The data associated
- with these Notify types is either a four-octet IPv4 address or a
- 16-octet IPv6 address.
-
-4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload
-
- The NO_ADDITIONAL_ADDRESSES notification can be included in an
- INFORMATIONAL exchange request message to indicate that the exchange
- initiator does not have addresses beyond the one used in the exchange
- (see Section 3.6 for more detailed description).
-
- The Notify Message Type for NO_ADDITIONAL_ADDRESSES is 16399. The
- Protocol ID and SPI Size fields are set to zero. There is no data
- associated with this Notify type.
-
-4.2.4. UPDATE_SA_ADDRESSES Notify Payload
-
- This notification is included in INFORMATIONAL exchange requests sent
- by the initiator to update addresses of the IKE_SA and IPsec SAs (see
- Section 3.5).
-
- The Notify Message Type for UPDATE_SA_ADDRESSES is 16400. The
- Protocol ID and SPI Size fields are set to zero. There is no data
- associated with this Notify type.
-
-4.2.5. COOKIE2 Notify Payload
-
- This notification MAY be included in any INFORMATIONAL request for
- return routability check purposes (see Section 3.7). If the
- INFORMATIONAL request includes COOKIE2, the exchange responder MUST
- copy the notification to the response message.
-
- The data associated with this notification MUST be between 8 and 64
- octets in length (inclusive), and MUST be chosen by the exchange
- initiator in a way that is unpredictable to the exchange responder.
- The Notify Message Type for this message is 16401. The Protocol ID
- and SPI Size fields are set to zero.
-
-4.2.6. NO_NATS_ALLOWED Notify Payload
-
- See Section 3.9 for a description of this notification.
-
- The Notify Message Type for this message is 16402. The notification
- data contains the IP addresses and ports from/to which the packet was
- sent. For IPv4, the notification data is 12 octets long and is
- defined as follows:
-
-
-
-Eronen Standards Track [Page 22]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Source IPv4 address !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Destination IPv4 address !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Source port ! Destination port !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- For IPv6, the notification data is 36 octets long and is defined 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ! Source IPv6 address !
- ! !
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! !
- ! Destination IPv6 address !
- ! !
- ! !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ! Source port ! Destination port !
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- The Protocol ID and SPI Size fields are set to zero.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen Standards Track [Page 23]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
-5. Security Considerations
-
- The main goals of this specification are to maintain the security
- offered by usual IKEv2 procedures and to counter mobility-related
- threats in an appropriate manner. This section describes new
- security considerations introduced by MOBIKE. See [IKEv2] for
- security considerations for IKEv2 in general.
-
-5.1. Traffic Redirection and Hijacking
-
- MOBIKE payloads relating to updating addresses are encrypted,
- integrity protected, and replay protected using the IKE_SA. This
- assures that no one except the participants can, for instance, give a
- control message to change the addresses.
-
- However, as with normal IKEv2, the actual IP addresses in the IP
- header are not covered by the integrity protection. This means that
- a NAT between the parties (or an attacker acting as a NAT) can modify
- the addresses and cause incorrect tunnel header (outer) IP addresses
- to be used for IPsec SAs. The scope of this attack is limited mainly
- to denial of service because all traffic is protected using IPsec.
-
- This attack can only be launched by on-path attackers that are
- capable of modifying IKEv2 messages carrying NAT detection payloads
- (such as Dead Peer Detection messages). By modifying the IP header
- of these packets, the attackers can lead the peers to believe a new
- NAT or a changed NAT binding exists between them. The attack can
- continue as long as the attacker is on the path, modifying the IKEv2
- messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms
- designed to detect NAT mapping changes will eventually recognize that
- the intended traffic is not getting through, and will update the
- addresses appropriately.
-
- MOBIKE introduces the NO_NATS_ALLOWED notification that is used to
- detect modification, by outsiders, of the addresses in the IP header.
- When this notification is used, communication through NATs and other
- address translators is impossible, so it is sent only when not doing
- NAT Traversal. This feature is mainly intended for IPv6 and site-to-
- site VPN cases, where the administrators may know beforehand that
- NATs are not present.
-
-5.2. IPsec Payload Protection
-
- The use of IPsec protection on payload traffic protects the
- participants against disclosure of the contents of the traffic,
- should the traffic end up in an incorrect destination or be subject
- to eavesdropping.
-
-
-
-
-Eronen Standards Track [Page 24]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- However, security associations originally created for the protection
- of a specific flow between specific addresses may be updated by
- MOBIKE later on. This has to be taken into account if the (outer) IP
- address of the peer was used when deciding what kind of IPsec SAs the
- peer is allowed to create.
-
- For instance, the level of required protection might depend on the
- current location of the VPN client, or access might be allowed only
- from certain IP addresses.
-
- It is recommended that security policies, for peers that are allowed
- to use MOBIKE, are configured in a manner that takes into account
- that a single security association can be used at different times
- through paths of varying security properties.
-
- This is especially critical for traffic selector authorization. The
- (logical) Peer Authorization Database (PAD) contains the information
- used by IKEv2 when determining what kind of IPsec SAs a peer is
- allowed to create. This process is described in [IPsecArch], Section
- 4.4.3. When a peer requests the creation of an IPsec SA with some
- traffic selectors, the PAD must contain "Child SA Authorization Data"
- linking the identity authenticated by IKEv2 and the addresses
- permitted for traffic selectors. See also [Clarifications] for a
- more extensive discussion.
-
- It is important to note that simply sending IKEv2 packets using some
- particular address does not automatically imply a permission to
- create IPsec SAs with that address in the traffic selectors.
- However, some implementations are known to use policies where simply
- being reachable at some address X implies a temporary permission to
- create IPsec SAs for address X. Here "being reachable" usually means
- the ability to send (or spoof) IP packets with source address X and
- receive (or eavesdrop) packets sent to X.
-
- Using this kind of policies or extensions with MOBIKE may need
- special care to enforce the temporary nature of the permission. For
- example, when the peer moves to some other address Y (and is no
- longer reachable at X), it might be necessary to close IPsec SAs with
- traffic selectors matching X. However, these interactions are beyond
- the scope of this document.
-
-5.3. Denial-of-Service Attacks against Third Parties
-
- Traffic redirection may be performed not just to gain access to the
- traffic or to deny service to the peers, but also to cause a denial-
- of-service attack on a third party. For instance, a high-speed TCP
- session or a multimedia stream may be redirected towards a victim
- host, causing its communications capabilities to suffer.
-
-
-
-Eronen Standards Track [Page 25]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- The attackers in this threat can be either outsiders or even one of
- the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers
- can be easily dealt with if the authentication performed in the
- initial IKEv2 negotiation can be traced to persons who can be held
- responsible for the attack. This may not be the case in all
- scenarios, particularly with opportunistic approaches to security.
-
- If the attack is launched by an outsider, the traffic flow would
- normally stop soon due to the lack of responses (such as transport
- layer acknowledgements). However, if the original recipient of the
- flow is malicious, it could maintain the traffic flow for an extended
- period of time, since it often would be able to send the required
- acknowledgements (see [Aura02] for more discussion).
-
- It should also be noted, as shown in [Bombing], that without ingress
- filtering in the attacker's network, such attacks are already
- possible simply by sending spoofed packets from the attacker to the
- victim directly. Furthermore, if the attacker's network has ingress
- filtering, this attack is largely prevented for MOBIKE as well.
- Consequently, it makes little sense to protect against attacks of
- similar nature in MOBIKE. However, it still makes sense to limit the
- amplification capabilities provided to attackers, so that they cannot
- use stream redirection to send a large number of packets to the
- victim by sending just a few packets themselves.
-
- This specification includes return routability tests to limit the
- duration of any "third party bombing" attacks by off-path (relative
- to the victim) attackers. The tests are authenticated messages that
- the peer has to respond to, and can be performed before the address
- change takes effect, immediately afterwards, or even periodically
- during the session. The tests contain unpredictable data, and only
- someone who has the keys associated with the IKE SA and has seen the
- request packet can properly respond to the test.
-
- The duration of the attack can also be limited if the victim reports
- the unwanted traffic to the originating IPsec tunnel endpoint using
- ICMP error messages or INVALID_SPI notifications. As described in
- [IKEv2], Section 2.21, this SHOULD trigger a liveness test, which
- also doubles as a return routability check if the COOKIE2
- notification is included.
-
-5.4. Spoofing Network Connectivity Indications
-
- Attackers may spoof various indications from lower layers and the
- network in an effort to confuse the peers about which addresses are
- or are not working. For example, attackers may spoof link-layer
- error messages in an effort to cause the parties to move their
- traffic elsewhere or even to disconnect. Attackers may also spoof
-
-
-
-Eronen Standards Track [Page 26]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- information related to network attachments, router discovery, and
- address assignments in an effort to make the parties believe they
- have Internet connectivity when, in reality, they do not.
-
- This may cause use of non-preferred addresses or even denial of
- service.
-
- MOBIKE does not provide any protection of its own for indications
- from other parts of the protocol stack. These vulnerabilities can be
- mitigated through the use of techniques specific to the other parts
- of the stack, such as validation of ICMP errors [ICMPAttacks], link
- layer security, or the use of [SEND] to protect IPv6 Router and
- Neighbor Discovery.
-
- Ultimately, MOBIKE depends on the delivery of IKEv2 messages to
- determine which paths can be used. If IKEv2 messages sent using a
- particular source and destination addresses reach the recipient and a
- reply is received, MOBIKE will usually consider the path working; if
- no reply is received even after retransmissions, MOBIKE will suspect
- the path is broken. An attacker who can consistently control the
- delivery or non-delivery of the IKEv2 messages in the network can
- thus influence which addresses actually get used.
-
-5.5. Address and Topology Disclosure
-
- MOBIKE address updates and the ADDITIONAL_IP4_ADDRESS/
- ADDITIONAL_IP6_ADDRESS notifications reveal information about which
- networks the peers are connected to.
-
- For example, consider a host A with two network interfaces: a
- cellular connection and a wired Ethernet connection to a company LAN.
- If host A now contacts host B using IKEv2 and sends
- ADDITIONAL_IP4_ADDRESS/ADDITIONAL_IP6_ADDRESS notifications, host B
- receives additional information it might not otherwise know. If host
- A used the cellular connection for the IKEv2 traffic, host B can also
- see the company LAN address (and perhaps further guess that host A is
- used by an employee of that company). If host A used the company LAN
- to make the connection, host B can see that host A has a subscription
- from this particular cellular operator.
-
- These additional addresses can also disclose more accurate location
- information than just a single address. Suppose that host A uses its
- cellular connection for IKEv2 traffic, but also sends an
- ADDITIONAL_IP4_ADDRESS notification containing an IP address
- corresponding to, say, a wireless LAN at a particular coffee shop
- location. It is likely that host B can now make a much better guess
- at A's location than would be possible based on the cellular IP
- address alone.
-
-
-
-Eronen Standards Track [Page 27]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- Furthermore, as described in Section 3.4, some of the addresses could
- also be private addresses behind a NAT.
-
- In many environments, disclosing address information is not a problem
- (and indeed it cannot be avoided if the hosts wish to use those
- addresses for IPsec traffic). For instance, a remote access VPN
- client could consider the corporate VPN gateway sufficiently
- trustworthy for this purpose. Furthermore, the
- ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS notifications are
- sent encrypted, so the addresses are not visible to eavesdroppers
- (unless, of course, they are later used for sending IKEv2/IPsec
- traffic).
-
- However, if MOBIKE is used in some more opportunistic approach, it
- can be desirable to limit the information that is sent. Naturally,
- the peers do not have to disclose any addresses they do not want to
- use for IPsec traffic. Also, as noted in Section 3.6, an initiator
- whose policy is to always use the locally configured responder
- address does not have to send any ADDITIONAL_IP4_ADDRESS/
- ADDITIONAL_IP6_ADDRESS payloads.
-
-6. IANA Considerations
-
- This document does not create any new namespaces to be maintained by
- IANA, but it requires new values in namespaces that have been defined
- in the IKEv2 base specification [IKEv2].
-
- This document defines several new IKEv2 notifications whose values
- have been allocated from the "IKEv2 Notify Message Types" namespace.
-
- Notify Messages - Error Types Value
- ----------------------------- -----
- UNACCEPTABLE_ADDRESSES 40
- UNEXPECTED_NAT_DETECTED 41
-
- Notify Messages - Status Types Value
- ------------------------------ -----
- MOBIKE_SUPPORTED 16396
- ADDITIONAL_IP4_ADDRESS 16397
- ADDITIONAL_IP6_ADDRESS 16398
- NO_ADDITIONAL_ADDRESSES 16399
- UPDATE_SA_ADDRESSES 16400
- COOKIE2 16401
- NO_NATS_ALLOWED 16402
-
- These notifications are described in Section 4.
-
-
-
-
-
-Eronen Standards Track [Page 28]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
-7. Acknowledgements
-
- This document is a collaborative effort of the entire MOBIKE WG. We
- would particularly like to thank Jari Arkko, Tuomas Aura, Marcelo
- Bagnulo, Stephane Beaulieu, Elwyn Davies, Lakshminath Dondeti,
- Francis Dupont, Paul Hoffman, James Kempf, Tero Kivinen, Pete McCann,
- Erik Nordmark, Mohan Parthasarathy, Pekka Savola, Bill Sommerfeld,
- Maureen Stillman, Shinta Sugimoto, Hannes Tschofenig, and Sami
- Vaarala. This document also incorporates ideas and text from earlier
- MOBIKE-like protocol proposals, including [AddrMgmt], [Kivinen],
- [MOPO], and [SMOBIKE], and the MOBIKE design document [Design].
-
-8. References
-
-8.1. Normative References
-
- [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2)
- Protocol", RFC 4306, December 2005.
-
- [IPsecArch] Kent, S. and K. Seo, "Security Architecture for the
- Internet Protocol", RFC 4301, December 2005.
-
- [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
-8.2. Informative References
-
- [AddrMgmt] Dupont, F., "Address Management for IKE version 2",
- Work in Progress, November 2005.
-
- [Aura02] Aura, T., Roe, M., and J. Arkko, "Security of
- Internet Location Management", Proc. 18th Annual
- Computer Security Applications Conference (ACSAC),
- December 2002.
-
- [Bombing] Dupont, F., "A note about 3rd party bombing in
- Mobile IPv6", Work in Progress, December 2005.
-
- [Clarifications] Eronen, P. and P. Hoffman, "IKEv2 Clarifications
- and Implementation Guidelines", Work in Progress,
- February 2006.
-
- [DNA4] Aboba, B., Carlson, J., and S. Cheshire, "Detecting
- Network Attachment in IPv4 (DNAv4)", RFC 4436,
- March 2006.
-
-
-
-
-
-
-Eronen Standards Track [Page 29]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- [DNA6] Narayanan, S., Daley, G., and N. Montavont,
- "Detecting Network Attachment in IPv6 - Best
- Current Practices for hosts", Work in Progress,
- October 2005.
-
- [Design] Kivinen, T. and H. Tschofenig, "Design of the
- MOBIKE protocol", Work in Progress, January 2006.
-
- [ICMPAttacks] Gont, F., "ICMP attacks against TCP", Work in
- Progress, October 2005.
-
- [Kivinen] Kivinen, T., "MOBIKE protocol", Work in Progress,
- February 2004.
-
- [MIP4] Perkins, C., "IP Mobility Support for IPv4",
- RFC 3344, August 2002.
-
- [MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility
- Support in IPv6", RFC 3775, June 2004.
-
- [MOPO] Eronen, P., "Mobility Protocol Options for IKEv2
- (MOPO-IKE)", Work in Progress, February 2005.
-
- [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
- Discovery for IP Version 6 (IPv6)", RFC 2461,
- December 1998.
-
- [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander,
- "SEcure Neighbor Discovery (SEND)", RFC 3971,
- March 2005.
-
- [SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and
- Multihoming Extensions for IKEv2 (SMOBIKE)",
- Work in Progress, March 2004.
-
- [STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R.
- Mahy, "STUN - Simple Traversal of User Datagram
- Protocol (UDP) Through Network Address Translators
- (NATs)", RFC 3489, March 2003.
-
- [UNSAF] Daigle, L., "IAB Considerations for UNilateral
- Self-Address Fixing (UNSAF) Across Network Address
- Translation", RFC 3424, November 2002.
-
-
-
-
-
-
-
-
-Eronen Standards Track [Page 30]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
-Appendix A. Implementation Considerations
-
-A.1. Links from SPD Cache to Outbound SAD Entries
-
- [IPsecArch], Section 4.4.2, says that "For outbound processing, each
- SAD entry is pointed to by entries in the SPD-S part of the SPD
- cache". The document does not specify how exactly this "pointing" is
- done, since this is an implementation detail that does not have to be
- standardized.
-
- However, it is clear that the links between the SPD cache and the SAD
- have to be done correctly to ensure that outbound packets are sent
- over the right SA. Some implementations are known to have problems
- in this area.
-
- In particular, simply storing the (remote tunnel header IP address,
- remote SPI) pair in the SPD cache is not sufficient, since the pair
- does not always uniquely identify a single SAD entry. For instance,
- two hosts behind the same NAT can accidentally happen to choose the
- same SPI value. The situation can also occur when a host is assigned
- an IP address previously used by some other host, and the SAs
- associated with the old host have not yet been deleted by Dead Peer
- Detection. This may lead to packets being sent over the wrong SA or,
- if the key management daemon ensures the pair is unique, denying the
- creation of otherwise valid SAs.
-
- Storing the remote tunnel header IP address in the SPD cache may also
- complicate the implementation of MOBIKE, since the address can change
- during the lifetime of the SA. Thus, we recommend implementing the
- links between the SPD cache and the SAD in a way that does not
- require modification when the tunnel header IP address is updated by
- MOBIKE.
-
-A.2. Creating Outbound SAs
-
- When an outbound packet requires IPsec processing but no suitable SA
- exists, a new SA will be created. In this case, the host has to
- determine (1) who is the right peer for this SA, (2) whether the host
- already has an IKE_SA with this peer, and (3) if no IKE_SA exists,
- the IP address(es) of the peer for contacting it.
-
- Neither [IPsecArch] nor MOBIKE specifies how exactly these three
- steps are carried out. [IPsecArch], Section 4.4.3.4, says:
-
-
-
-
-
-
-
-
-Eronen Standards Track [Page 31]
-\f
-RFC 4555 MOBIKE Protocol June 2006
-
-
- For example, assume that IKE A receives an outbound packet
- destined for IP address X, a host served by a security gateway.
- RFC 2401 [RFC2401] and this document do not specify how A
- determines the address of the IKE peer serving X. However, any
- peer contacted by A as the presumed representative for X must be
- registered in the PAD in order to allow the IKE exchange to be
- authenticated. Moreover, when the authenticated peer asserts that
- it represents X in its traffic selector exchange, the PAD will be
- consulted to determine if the peer in question is authorized to
- represent X.
-
- In step 1, there may be more than one possible peer (e.g., several
- security gateways that are allowed to represent X). In step 3, the
- host may need to consult a directory such as DNS to determine the
- peer IP address(es).
-
- When performing these steps, implementations may use information
- contained in the SPD, the PAD, and possibly some other
- implementation-specific databases. Regardless of how exactly the
- steps are implemented, it is important to remember that IP addresses
- can change, and that an IP address alone does not always uniquely
- identify a single IKE peer (for the same reasons as why the
- combination of the remote IP address and SPI does not uniquely
- identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1
- and 2 it may be easier to identify the "right peer" using its
- authenticated identity instead of its current IP address. However,
- these implementation details are beyond the scope of this
- specification.
-
-Author's Address
-
- Pasi Eronen (editor)
- Nokia Research Center
- P.O. Box 407
- FIN-00045 Nokia Group
- Finland
-
- EMail: pasi.eronen@nokia.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen Standards Track [Page 32]
-\f
-RFC 4555 MOBIKE Protocol June 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).
-
-
-
-
-
-
-
-Eronen Standards Track [Page 33]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group P. Eronen
-Request for Comments: 4718 Nokia
-Category: Informational P. Hoffman
- VPN Consortium
- October 2006
-
-
- IKEv2 Clarifications and Implementation Guidelines
-
-Status of This Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- This document clarifies many areas of the IKEv2 specification. It
- does not to introduce any changes to the protocol, but rather
- provides descriptions that are less prone to ambiguous
- interpretations. The purpose of this document is to encourage the
- development of interoperable implementations.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 1]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-Table of Contents
-
- 1. Introduction ....................................................4
- 2. Creating the IKE_SA .............................................4
- 2.1. SPI Values in IKE_SA_INIT Exchange .........................4
- 2.2. Message IDs for IKE_SA_INIT Messages .......................5
- 2.3. Retransmissions of IKE_SA_INIT Requests ....................5
- 2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD ...............6
- 2.5. Invalid Cookies ............................................8
- 3. Authentication ..................................................9
- 3.1. Data Included in AUTH Payload Calculation ..................9
- 3.2. Hash Function for RSA Signatures ...........................9
- 3.3. Encoding Method for RSA Signatures ........................10
- 3.4. Identification Type for EAP ...............................11
- 3.5. Identity for Policy Lookups When Using EAP ................11
- 3.6. Certificate Encoding Types ................................12
- 3.7. Shared Key Authentication and Fixed PRF Key Size ..........12
- 3.8. EAP Authentication and Fixed PRF Key Size .................13
- 3.9. Matching ID Payloads to Certificate Contents ..............13
- 3.10. Message IDs for IKE_AUTH Messages ........................14
- 4. Creating CHILD_SAs .............................................14
- 4.1. Creating SAs with the CREATE_CHILD_SA Exchange ............14
- 4.2. Creating an IKE_SA without a CHILD_SA .....................16
- 4.3. Diffie-Hellman for First CHILD_SA .........................16
- 4.4. Extended Sequence Numbers (ESN) Transform .................17
- 4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED ..............17
- 4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO ...................18
- 4.7. Semantics of Complex Traffic Selector Payloads ............18
- 4.8. ICMP Type/Code in Traffic Selector Payloads ...............19
- 4.9. Mobility Header in Traffic Selector Payloads ..............20
- 4.10. Narrowing the Traffic Selectors ..........................20
- 4.11. SINGLE_PAIR_REQUIRED .....................................21
- 4.12. Traffic Selectors Violating Own Policy ...................21
- 4.13. Traffic Selector Authorization ...........................22
- 5. Rekeying and Deleting SAs ......................................23
- 5.1. Rekeying SAs with the CREATE_CHILD_SA Exchange ............23
- 5.2. Rekeying the IKE_SA vs. Reauthentication ..................24
- 5.3. SPIs When Rekeying the IKE_SA .............................25
- 5.4. SPI When Rekeying a CHILD_SA ..............................25
- 5.5. Changing PRFs When Rekeying the IKE_SA ....................26
- 5.6. Deleting vs. Closing SAs ..................................26
- 5.7. Deleting a CHILD_SA Pair ..................................26
- 5.8. Deleting an IKE_SA ........................................27
- 5.9. Who is the original initiator of IKE_SA ...................27
- 5.10. Comparing Nonces .........................................27
- 5.11. Exchange Collisions ......................................28
- 5.12. Diffie-Hellman and Rekeying the IKE_SA ...................36
-
-
-
-
-Eronen & Hoffman Informational [Page 2]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- 6. Configuration Payloads .........................................37
- 6.1. Assigning IP Addresses ....................................37
- 6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS ...................38
- 6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET ...................38
- 6.4. INTERNAL_IP4_NETMASK ......................................41
- 6.5. Configuration Payloads for IPv6 ...........................42
- 6.6. INTERNAL_IP6_NBNS .........................................43
- 6.7. INTERNAL_ADDRESS_EXPIRY ...................................43
- 6.8. Address Assignment Failures ...............................44
- 7. Miscellaneous Issues ...........................................45
- 7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR ....................45
- 7.2. Relationship of IKEv2 to RFC 4301 .........................45
- 7.3. Reducing the Window Size ..................................46
- 7.4. Minimum Size of Nonces ....................................46
- 7.5. Initial Zero Octets on Port 4500 ..........................46
- 7.6. Destination Port for NAT Traversal ........................47
- 7.7. SPI Values for Messages outside an IKE_SA .................47
- 7.8. Protocol ID/SPI Fields in Notify Payloads .................48
- 7.9. Which message should contain INITIAL_CONTACT ..............48
- 7.10. Alignment of Payloads ....................................48
- 7.11. Key Length Transform Attribute ...........................48
- 7.12. IPsec IANA Considerations ................................49
- 7.13. Combining ESP and AH .....................................50
- 8. Implementation Mistakes ........................................50
- 9. Security Considerations ........................................51
- 10. Acknowledgments ...............................................51
- 11. References ....................................................51
- 11.1. Normative References .....................................51
- 11.2. Informative References ...................................52
- Appendix A. Exchanges and Payloads ................................54
- A.1. IKE_SA_INIT Exchange ......................................54
- A.2. IKE_AUTH Exchange without EAP .............................54
- A.3. IKE_AUTH Exchange with EAP ................................55
- A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying
- CHILD_SAs .................................................56
- A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA ..........56
- A.6. INFORMATIONAL Exchange ....................................56
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 3]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-1. Introduction
-
- This document clarifies many areas of the IKEv2 specification that
- may be difficult to understand to developers not intimately familiar
- with the specification and its history. The clarifications in this
- document come from the discussion on the IPsec WG mailing list, from
- experience in interoperability testing, and from implementation
- issues that have been brought to the editors' attention.
-
- IKEv2/IPsec can be used for several different purposes, including
- IPsec-based remote access (sometimes called the "road warrior" case),
- site-to-site virtual private networks (VPNs), and host-to-host
- protection of application traffic. While this document attempts to
- consider all of these uses, the remote access scenario has perhaps
- received more attention here than the other uses.
-
- This document does not place any requirements on anyone and does not
- use [RFC2119] keywords such as "MUST" and "SHOULD", except in
- quotations from the original IKEv2 documents. The requirements are
- given in the IKEv2 specification [IKEv2] and IKEv2 cryptographic
- algorithms document [IKEv2ALG].
-
- In this document, references to a numbered section (such as "Section
- 2.15") mean that section in [IKEv2]. References to mailing list
- messages or threads refer to the IPsec WG mailing list at
- ipsec@ietf.org. Archives of the mailing list can be found at
- <http://www.ietf.org/mail-archive/web/ipsec/index.html>.
-
-2. Creating the IKE_SA
-
-2.1. SPI Values in IKE_SA_INIT Exchange
-
- Normal IKE messages include the initiator's and responder's Security
- Parameter Indexes (SPIs), both of which are non-zero, in the IKE
- header. However, there are some corner cases where the IKEv2
- specification is not fully consistent about what values should be
- used.
-
- First, Section 3.1 says that the Responder's SPI "...MUST NOT be zero
- in any other message" (than the first message of the IKE_SA_INIT
- exchange). However, the figure in Section 2.6 shows the second
- IKE_SA_INIT message as "HDR(A,0), N(COOKIE)", contradicting the text
- in 3.1.
-
- Since the responder's SPI identifies security-related state held by
- the responder, and in this case no state is created, sending a zero
- value seems reasonable.
-
-
-
-
-Eronen & Hoffman Informational [Page 4]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- Second, in addition to cookies, there are several other cases when
- the IKE_SA_INIT exchange does not result in the creation of an IKE_SA
- (for instance, INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). What
- responder SPI value should be used in the IKE_SA_INIT response in
- this case?
-
- Since the IKE_SA_INIT request always has a zero responder SPI, the
- value will not be actually used by the initiator. Thus, we think
- sending a zero value is correct also in this case.
-
- If the responder sends a non-zero responder SPI, the initiator should
- not reject the response only for that reason. However, when retrying
- the IKE_SA_INIT request, the initiator will use a zero responder SPI,
- as described in Section 3.1: "Responder's SPI [...] This value MUST
- be zero in the first message of an IKE Initial Exchange (including
- repeats of that message including a cookie) [...]". We believe the
- intent was to cover repeats of that message due to other reasons,
- such as INVALID_KE_PAYLOAD, as well.
-
- (References: "INVALID_KE_PAYLOAD and clarifications document" thread,
- Sep-Oct 2005.)
-
-2.2. Message IDs for IKE_SA_INIT Messages
-
- The Message ID for IKE_SA_INIT messages is always zero. This
- includes retries of the message due to responses such as COOKIE and
- INVALID_KE_PAYLOAD.
-
- This is because Message IDs are part of the IKE_SA state, and when
- the responder replies to IKE_SA_INIT request with N(COOKIE) or
- N(INVALID_KE_PAYLOAD), the responder does not allocate any state.
-
- (References: "Question about N(COOKIE) and N(INVALID_KE_PAYLOAD)
- combination" thread, Oct 2004. Tero Kivinen's mail "Comments of
- draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)
-
-2.3. Retransmissions of IKE_SA_INIT Requests
-
- When a responder receives an IKE_SA_INIT request, it has to determine
- whether the packet is a retransmission belonging to an existing
- "half-open" IKE_SA (in which case the responder retransmits the same
- response), or a new request (in which case the responder creates a
- new IKE_SA and sends a fresh response).
-
- The specification does not describe in detail how this determination
- is done. In particular, it is not sufficient to use the initiator's
- SPI and/or IP address for this purpose: two different peers behind a
- single NAT could choose the same initiator SPI (and the probability
-
-
-
-Eronen & Hoffman Informational [Page 5]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- of this happening is not necessarily small, since IKEv2 does not
- require SPIs to be chosen randomly). Instead, the responder should
- do the IKE_SA lookup using the whole packet or its hash (or at the
- minimum, the Ni payload which is always chosen randomly).
-
- For all other packets than IKE_SA_INIT requests, looking up right
- IKE_SA is of course done based on the recipient's SPI (either the
- initiator or responder SPI depending on the value of the Initiator
- bit in the IKE header).
-
-2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD
-
- There are two common reasons why the initiator may have to retry the
- IKE_SA_INIT exchange: the responder requests a cookie or wants a
- different Diffie-Hellman group than was included in the KEi payload.
- Both of these cases are quite simple alone, but it is not totally
- obvious what happens when they occur at the same time, that is, the
- IKE_SA_INIT exchange is retried several times.
-
- The main question seems to be the following: if the initiator
- receives a cookie from the responder, should it include the cookie in
- only the next retry of the IKE_SA_INIT request, or in all subsequent
- retries as well? Section 3.10.1 says that:
-
- "This notification MUST be included in an IKE_SA_INIT request
- retry if a COOKIE notification was included in the initial
- response."
-
- This could be interpreted as saying that when a cookie is received in
- the initial response, it is included in all retries. On the other
- hand, Section 2.6 says that:
-
- "Initiators who receive such responses MUST retry the
- IKE_SA_INIT with a Notify payload of type COOKIE containing
- the responder supplied cookie data as the first payload and
- all other payloads unchanged."
-
- Including the same cookie in later retries makes sense only if the
- "all other payloads unchanged" restriction applies only to the first
- retry, but not to subsequent retries.
-
- It seems that both interpretations can peacefully coexist. If the
- initiator includes the cookie only in the next retry, one additional
- roundtrip may be needed in some cases:
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 6]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- Initiator Responder
- ----------- -----------
- HDR(A,0), SAi1, KEi, Ni -->
- <-- HDR(A,0), N(COOKIE)
- HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
- <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
- HDR(A,0), SAi1, KEi', Ni -->
- <-- HDR(A,0), N(COOKIE')
- HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
- <-- HDR(A,B), SAr1, KEr, Nr
-
- An additional roundtrip is needed also if the initiator includes the
- cookie in all retries, but the responder does not support this
- functionality. For instance, if the responder includes the SAi1 and
- KEi payloads in cookie calculation, it will reject the request by
- sending a new cookie (see also Section 2.5 of this document for more
- text about invalid cookies):
-
-
- Initiator Responder
- ----------- -----------
- HDR(A,0), SAi1, KEi, Ni -->
- <-- HDR(A,0), N(COOKIE)
- HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
- <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
- HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
- <-- HDR(A,0), N(COOKIE')
- HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
- <-- HDR(A,B), SAr1, KEr, Nr
-
- If both peers support including the cookie in all retries, a slightly
- shorter exchange can happen:
-
- Initiator Responder
- ----------- -----------
- HDR(A,0), SAi1, KEi, Ni -->
- <-- HDR(A,0), N(COOKIE)
- HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
- <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
- HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
- <-- HDR(A,B), SAr1, KEr, Nr
-
- This document recommends that implementations should support this
- shorter exchange, but it must not be assumed the other peer also
- supports the shorter exchange.
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 7]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- In theory, even this exchange has one unnecessary roundtrip, as both
- the cookie and Diffie-Hellman group could be checked at the same
- time:
-
- Initiator Responder
- ----------- -----------
- HDR(A,0), SAi1, KEi, Ni -->
- <-- HDR(A,0), N(COOKIE),
- N(INVALID_KE_PAYLOAD)
- HDR(A,0), N(COOKIE), SAi1, KEi',Ni -->
- <-- HDR(A,B), SAr1, KEr, Nr
-
- However, it is clear that this case is not allowed by the text in
- Section 2.6, since "all other payloads" clearly includes the KEi
- payload as well.
-
- (References: "INVALID_KE_PAYLOAD and clarifications document" thread,
- Sep-Oct 2005.)
-
-2.5. Invalid Cookies
-
- There has been some confusion what should be done when an IKE_SA_INIT
- request containing an invalid cookie is received ("invalid" in the
- sense that its contents do not match the value expected by the
- responder).
-
- The correct action is to ignore the cookie and process the message as
- if no cookie had been included (usually this means sending a response
- containing a new cookie). This is shown in Section 2.6 when it says
- "The responder in that case MAY reject the message by sending another
- response with a new cookie [...]".
-
- Other possible actions, such as ignoring the whole request (or even
- all requests from this IP address for some time), create strange
- failure modes even in the absence of any malicious attackers and do
- not provide any additional protection against DoS attacks.
-
- (References: "Invalid Cookie" thread, Sep-Oct 2005.)
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 8]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-3. Authentication
-
-3.1. Data Included in AUTH Payload Calculation
-
- Section 2.15 describes how the AUTH payloads are calculated; this
- calculation involves values prf(SK_pi,IDi') and prf(SK_pr,IDr'). The
- text describes the method in words, but does not give clear
- definitions of what is signed or MACed (i.e., protected with a
- message authentication code).
-
- The initiator's signed octets can be described as:
-
- InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
- GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
- RealIKEHDR = SPIi | SPIr | . . . | Length
- RealMessage1 = RealIKEHDR | RestOfMessage1
- NonceRPayload = PayloadHeader | NonceRData
- InitiatorIDPayload = PayloadHeader | RestOfIDPayload
- RestOfInitIDPayload = IDType | RESERVED | InitIDData
- MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
-
- The responder's signed octets can be described as:
-
- ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
- GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
- RealIKEHDR = SPIi | SPIr | . . . | Length
- RealMessage2 = RealIKEHDR | RestOfMessage2
- NonceIPayload = PayloadHeader | NonceIData
- ResponderIDPayload = PayloadHeader | RestOfIDPayload
- RestOfRespIDPayload = IDType | RESERVED | InitIDData
- MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
-
-3.2. Hash Function for RSA Signatures
-
- Section 3.8 says that RSA digital signature is "Computed as specified
- in section 2.15 using an RSA private key over a PKCS#1 padded hash."
-
- Unlike IKEv1, IKEv2 does not negotiate a hash function for the
- IKE_SA. The algorithm for signatures is selected by the signing
- party who, in general, may not know beforehand what algorithms the
- verifying party supports. Furthermore, [IKEv2ALG] does not say what
- algorithms implementations are required or recommended to support.
- This clearly has a potential for causing interoperability problems,
- since authentication will fail if the signing party selects an
- algorithm that is not supported by the verifying party, or not
- acceptable according to the verifying party's policy.
-
-
-
-
-
-Eronen & Hoffman Informational [Page 9]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- This document recommends that all implementations support SHA-1 and
- use SHA-1 as the default hash function when generating the
- signatures, unless there are good reasons (such as explicit manual
- configuration) to believe that the peer supports something else.
-
- Note that hash function collision attacks are not important for the
- AUTH payloads, since they are not intended for third-party
- verification, and the data includes fresh nonces. See [HashUse] for
- more discussion about hash function attacks and IPsec.
-
- Another reasonable choice would be to use the hash function that was
- used by the CA when signing the peer certificate. However, this does
- not guarantee that the IKEv2 peer would be able to validate the AUTH
- payload, because the same code might not be used to validate
- certificate signatures and IKEv2 message signatures, and these two
- routines may support a different set of hash algorithms. The peer
- could be configured with a fingerprint of the certificate, or
- certificate validation could be performed by an external entity using
- [SCVP]. Furthermore, not all CERT payloads types include a
- signature, and the certificate could be signed with some algorithm
- other than RSA.
-
- Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20]
- signature encoding method (see next section for details), which
- includes the algorithm identifier for the hash algorithm. Thus, when
- the verifying party receives the AUTH payload it can at least
- determine which hash function was used.
-
- (References: Magnus Alstrom's mail "RE:", 2005-01-03. Pasi Eronen's
- reply, 2005-01-04. Tero Kivinen's reply, 2005-01-04. "First draft
- of IKEv2.1" thread, Dec 2005/Jan 2006.)
-
-3.3. Encoding Method for RSA Signatures
-
- Section 3.8 says that the RSA digital signature is "Computed as
- specified in section 2.15 using an RSA private key over a PKCS#1
- padded hash."
-
- The PKCS#1 specification [PKCS1v21] defines two different encoding
- methods (ways of "padding the hash") for signatures. However, the
- Internet-Draft approved by the IESG had a reference to the older
- PKCS#1 v2.0 [PKCS1v20]. That version has only one encoding method
- for signatures (EMSA-PKCS1-v1_5), and thus there is no ambiguity.
-
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 10]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- Note that this encoding method is different from the encoding method
- used in IKEv1. If future revisions of IKEv2 provide support for
- other encoding methods (such as EMSA-PSS), they will be given new
- Auth Method numbers.
-
- (References: Pasi Eronen's mail "RE:", 2005-01-04.)
-
-3.4. Identification Type for EAP
-
- Section 3.5 defines several different types for identification
- payloads, including, e.g., ID_FQDN, ID_RFC822_ADDR, and ID_KEY_ID.
- EAP [EAP] does not mandate the use of any particular type of
- identifier, but often EAP is used with Network Access Identifiers
- (NAIs) defined in [NAI]. Although NAIs look a bit like email
- addresses (e.g., "joe@example.com"), the syntax is not exactly the
- same as the syntax of email address in [RFC822]. This raises the
- question of which identification type should be used.
-
- This document recommends that ID_RFC822_ADDR identification type is
- used for those NAIs that include the realm component. Therefore,
- responder implementations should not attempt to verify that the
- contents actually conform to the exact syntax given in [RFC822] or
- [RFC2822], but instead should accept any reasonable looking NAI.
-
- For NAIs that do not include the realm component, this document
- recommends using the ID_KEY_ID identification type.
-
- (References: "need your help on this IKEv2/i18n/EAP issue" and "IKEv2
- identifier issue with EAP" threads, Aug 2004.)
-
-3.5. Identity for Policy Lookups When Using EAP
-
- When the initiator authentication uses EAP, it is possible that the
- contents of the IDi payload is used only for AAA routing purposes and
- selecting which EAP method to use. This value may be different from
- the identity authenticated by the EAP method (see [EAP], Sections 5.1
- and 7.3).
-
- It is important that policy lookups and access control decisions use
- the actual authenticated identity. Often the EAP server is
- implemented in a separate AAA server that communicates with the IKEv2
- responder using, e.g., RADIUS [RADEAP]. In this case, the
- authenticated identity has to be sent from the AAA server to the
- IKEv2 responder.
-
- (References: Pasi Eronen's mail "RE: Reauthentication in IKEv2",
- 2004-10-28. "Policy lookups" thread, Oct/Nov 2004. RFC 3748,
- Section 7.3.)
-
-
-
-Eronen & Hoffman Informational [Page 11]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-3.6. Certificate Encoding Types
-
- Section 3.6 defines a total of twelve different certificate encoding
- types, and continues that "Specific syntax is for some of the
- certificate type codes above is not defined in this document."
- However, the text does not provide references to other documents that
- would contain information about the exact contents and use of those
- values.
-
- Without this information, it is not possible to develop interoperable
- implementations. Therefore, this document recommends that the
- following certificate encoding values should not be used before new
- specifications that specify their use are available.
-
- PKCS #7 wrapped X.509 certificate 1
- PGP Certificate 2
- DNS Signed Key 3
- Kerberos Token 6
- SPKI Certificate 9
-
- This document recommends that most implementations should use only
- those values that are "MUST"/"SHOULD" requirements in [IKEv2]; i.e.,
- "X.509 Certificate - Signature" (4), "Raw RSA Key" (11), "Hash and
- URL of X.509 certificate" (12), and "Hash and URL of X.509 bundle"
- (13).
-
- Furthermore, Section 3.7 says that the "Certificate Encoding" field
- for the Certificate Request payload uses the same values as for
- Certificate payload. However, the contents of the "Certification
- Authority" field are defined only for X.509 certificates (presumably
- covering at least types 4, 10, 12, and 13). This document recommends
- that other values should not be used before new specifications that
- specify their use are available.
-
- The "Raw RSA Key" type needs one additional clarification. Section
- 3.6 says it contains "a PKCS #1 encoded RSA key". What this means is
- a DER-encoded RSAPublicKey structure from PKCS#1 [PKCS1v21].
-
-3.7. Shared Key Authentication and Fixed PRF Key Size
-
- Section 2.15 says that "If the negotiated prf takes a fixed-size key,
- the shared secret MUST be of that fixed size". This statement is
- correct: the shared secret must be of the correct size. If it is
- not, it cannot be used; there is no padding, truncation, or other
- processing involved to force it to that correct size.
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 12]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- This requirement means that it is difficult to use these pseudo-
- random functions (PRFs) with shared key authentication. The authors
- think this part of the specification was very poorly thought out, and
- using PRFs with a fixed key size is likely to result in
- interoperability problems. Thus, we recommend that such PRFs should
- not be used with shared key authentication. PRF_AES128_XCBC
- [RFC3664] originally used fixed key sizes; that RFC has been updated
- to handle variable key sizes in [RFC4434].
-
- Note that Section 2.13 also contains text that is related to PRFs
- with fixed key size: "When the key for the prf function has fixed
- length, the data provided as a key is truncated or padded with zeros
- as necessary unless exceptional processing is explained following the
- formula". However, this text applies only to the prf+ construction,
- so it does not contradict the text in Section 2.15.
-
- (References: Paul Hoffman's mail "Re: ikev2-07: last nits",
- 2003-05-02. Hugo Krawczyk's reply, 2003-05-12. Thread "Question
- about PRFs with fixed size key", Jan 2005.)
-
-3.8. EAP Authentication and Fixed PRF Key Size
-
- As described in the previous section, PRFs with a fixed key size
- require a shared secret of exactly that size. This restriction
- applies also to EAP authentication. For instance, a PRF that
- requires a 128-bit key cannot be used with EAP since [EAP] specifies
- that the MSK is at least 512 bits long.
-
- (References: Thread "Question about PRFs with fixed size key", Jan
- 2005.)
-
-3.9. Matching ID Payloads to Certificate Contents
-
- In IKEv1, there was some confusion about whether or not the
- identities in certificates used to authenticate IKE were required to
- match the contents of the ID payloads. The PKI4IPsec Working Group
- produced the document [PKI4IPsec] which covers this topic in much
- more detail. However, Section 3.5 of [IKEv2] explicitly says that
- the ID payload "does not necessarily have to match anything in the
- CERT payload".
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 13]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-3.10. Message IDs for IKE_AUTH Messages
-
- According to Section 2.2, "The IKE_SA initial setup messages will
- always be numbered 0 and 1." That is true when the IKE_AUTH exchange
- does not use EAP. When EAP is used, each pair of messages has their
- message numbers incremented. The first pair of AUTH messages will
- have an ID of 1, the second will be 2, and so on.
-
- (References: "Question about MsgID in AUTH exchange" thread, April
- 2005.)
-
-4. Creating CHILD_SAs
-
-4.1. Creating SAs with the CREATE_CHILD_SA Exchange
-
- Section 1.3's organization does not lead to clear understanding of
- what is needed in which environment. The section can be reorganized
- with subsections for each use of the CREATE_CHILD_SA exchange
- (creating child SAs, rekeying IKE SAs, and rekeying child SAs.)
-
- The new Section 1.3 with subsections and the above changes might look
- like the following.
-
- NEW-1.3 The CREATE_CHILD_SA Exchange
-
- The CREATE_CHILD_SA Exchange is used to create new CHILD_SAs and
- to rekey both IKE_SAs and CHILD_SAs. This exchange consists of
- a single request/response pair, and some of its function was
- referred to as a phase 2 exchange in IKEv1. It MAY be initiated
- by either end of the IKE_SA after the initial exchanges are
- completed.
-
- All messages following the initial exchange are
- cryptographically protected using the cryptographic algorithms
- and keys negotiated in the first two messages of the IKE
- exchange. These subsequent messages use the syntax of the
- Encrypted Payload described in section 3.14. All subsequent
- messages include an Encrypted Payload, even if they are referred
- to in the text as "empty".
-
- The CREATE_CHILD_SA is used for rekeying IKE_SAs and CHILD_SAs.
- This section describes the first part of rekeying, the creation
- of new SAs; Section 2.8 covers the mechanics of rekeying,
- including moving traffic from old to new SAs and the deletion of
- the old SAs. The two sections must be read together to
- understand the entire process of rekeying.
-
-
-
-
-
-Eronen & Hoffman Informational [Page 14]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- Either endpoint may initiate a CREATE_CHILD_SA exchange, so in
- this section the term initiator refers to the endpoint
- initiating this exchange. An implementation MAY refuse all
- CREATE_CHILD_SA requests within an IKE_SA.
-
- The CREATE_CHILD_SA request MAY optionally contain a KE payload
- for an additional Diffie-Hellman exchange to enable stronger
- guarantees of forward secrecy for the CHILD_SA or IKE_SA. The
- keying material for the SA is a function of SK_d established
- during the establishment of the IKE_SA, the nonces exchanged
- during the CREATE_CHILD_SA exchange, and the Diffie-Hellman
- value (if KE payloads are included in the CREATE_CHILD_SA
- exchange). The details are described in sections 2.17 and 2.18.
-
- If a CREATE_CHILD_SA exchange includes a KEi payload, at least
- one of the SA offers MUST include the Diffie-Hellman group of
- the KEi. The Diffie-Hellman group of the KEi MUST be an element
- of the group the initiator expects the responder to accept
- (additional Diffie-Hellman groups can be proposed). If the
- responder rejects the Diffie-Hellman group of the KEi payload,
- the responder MUST reject the request and indicate its preferred
- Diffie-Hellman group in the INVALID_KE_PAYLOAD Notification
- payload. In the case of such a rejection, the CREATE_CHILD_SA
- exchange fails, and the initiator SHOULD retry the exchange with
- a Diffie-Hellman proposal and KEi in the group that the
- responder gave in the INVALID_KE_PAYLOAD.
-
- NEW-1.3.1 Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange
-
- A CHILD_SA may be created by sending a CREATE_CHILD_SA request.
- The CREATE_CHILD_SA request for creating a new CHILD_SA is:
-
- Initiator Responder
- ----------- -----------
- HDR, SK {[N+], SA, Ni, [KEi],
- TSi, TSr} -->
-
- The initiator sends SA offer(s) in the SA payload, a nonce in
- the Ni payload, optionally a Diffie-Hellman value in the KEi
- payload, and the proposed traffic selectors for the proposed
- CHILD_SA in the TSi and TSr payloads. The request can also
- contain Notify payloads that specify additional details for the
- CHILD_SA: these include IPCOMP_SUPPORTED, USE_TRANSPORT_MODE,
- ESP_TFC_PADDING_NOT_SUPPORTED, and NON_FIRST_FRAGMENTS_ALSO.
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 15]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- The CREATE_CHILD_SA response for creating a new CHILD_SA is:
-
- <-- HDR, SK {[N+], SA, Nr,
- [KEr], TSi, TSr}
-
- The responder replies with the accepted offer in an SA payload,
- and a Diffie-Hellman value in the KEr payload if KEi was
- included in the request and the selected cryptographic suite
- includes that group. As with the request, optional Notification
- payloads can specify additional details for the CHILD_SA.
-
- The traffic selectors for traffic to be sent on that SA are
- specified in the TS payloads in the response, which may be a
- subset of what the initiator of the CHILD_SA proposed.
-
- The text about rekeying SAs can be found in Section 5.1 of this
- document.
-
-4.2. Creating an IKE_SA without a CHILD_SA
-
- CHILD_SAs can be created either by being piggybacked on the IKE_AUTH
- exchange, or using a separate CREATE_CHILD_SA exchange. The
- specification is not clear about what happens if creating the
- CHILD_SA during the IKE_AUTH exchange fails for some reason.
-
- Our recommendation in this situation is that the IKE_SA is created as
- usual. This is also in line with how the CREATE_CHILD_SA exchange
- works: a failure to create a CHILD_SA does not close the IKE_SA.
-
- The list of responses in the IKE_AUTH exchange that do not prevent an
- IKE_SA from being set up include at least the following:
- NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
- INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
-
- (References: "Questions about internal address" thread, April 2005.)
-
-4.3. Diffie-Hellman for First CHILD_SA
-
- Section 1.2 shows that IKE_AUTH messages do not contain KEi/KEr or
- Ni/Nr payloads. This implies that the SA payload in IKE_AUTH
- exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with
- any other value than NONE. Implementations should probably leave the
- transform out entirely in this case.
-
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 16]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-4.4. Extended Sequence Numbers (ESN) Transform
-
- The description of the ESN transform in Section 3.3 has be proved
- difficult to understand. The ESN transform has the following
- meaning:
-
- o A proposal containing one ESN transform with value 0 means "do not
- use extended sequence numbers".
-
- o A proposal containing one ESN transform with value 1 means "use
- extended sequence numbers".
-
- o A proposal containing two ESN transforms with values 0 and 1 means
- "I support both normal and extended sequence numbers, you choose".
- (Obviously this case is only allowed in requests; the response
- will contain only one ESN transform.)
-
- In most cases, the exchange initiator will include either the first
- or third alternative in its SA payload. The second alternative is
- rarely useful for the initiator: it means that using normal sequence
- numbers is not acceptable (so if the responder does not support ESNs,
- the exchange will fail with NO_PROPOSAL_CHOSEN).
-
- Note that including the ESN transform is mandatory when creating
- ESP/AH SAs (it was optional in earlier drafts of the IKEv2
- specification).
-
- (References: "Technical change needed to IKEv2 before publication",
- "STRAW POLL: Dealing with the ESN negotiation interop issue in IKEv2"
- and "Results of straw poll regarding: IKEv2 interoperability issue"
- threads, March-April 2005.)
-
-4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED
-
- The description of ESP_TFC_PADDING_NOT_SUPPORTED notification in
- Section 3.10.1 says that "This notification asserts that the sending
- endpoint will NOT accept packets that contain Flow Confidentiality
- (TFC) padding".
-
- However, the text does not say in which messages this notification
- should be included, or whether the scope of this notification is a
- single CHILD_SA or all CHILD_SAs of the peer.
-
- Our interpretation is that the scope is a single CHILD_SA, and thus
- this notification is included in messages containing an SA payload
- negotiating a CHILD_SA. If neither endpoint accepts TFC padding,
- this notification will be included in both the request proposing an
- SA and the response accepting it. If this notification is included
-
-
-
-Eronen & Hoffman Informational [Page 17]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- in only one of the messages, TFC padding can still be sent in one
- direction.
-
-4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO
-
- NON_FIRST_FRAGMENTS_ALSO notification is described in Section 3.10.1
- simply as "Used for fragmentation control. See [RFC4301] for
- explanation."
-
- [RFC4301] says "Implementations that will transmit non-initial
- fragments on a tunnel mode SA that makes use of non-trivial port (or
- ICMP type/code or MH type) selectors MUST notify a peer via the IKE
- NOTIFY NON_FIRST_FRAGMENTS_ALSO payload. The peer MUST reject this
- proposal if it will not accept non-initial fragments in this context.
- If an implementation does not successfully negotiate transmission of
- non-initial fragments for such an SA, it MUST NOT send such fragments
- over the SA."
-
- However, it is not clear exactly how the negotiation works. Our
- interpretation is that the negotiation works the same way as for
- IPCOMP_SUPPORTED and USE_TRANSPORT_MODE: sending non-first fragments
- is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is included
- in both the request proposing an SA and the response accepting it.
- In other words, if the peer "rejects this proposal", it only omits
- NON_FIRST_FRAGMENTS_ALSO notification from the response, but does not
- reject the whole CHILD_SA creation.
-
-4.7. Semantics of Complex Traffic Selector Payloads
-
- As described in Section 3.13, the TSi/TSr payloads can include one or
- more individual traffic selectors.
-
- There is no requirement that TSi and TSr contain the same number of
- individual traffic selectors. Thus, they are interpreted as follows:
- a packet matches a given TSi/TSr if it matches at least one of the
- individual selectors in TSi, and at least one of the individual
- selectors in TSr.
-
- For instance, the following traffic selectors:
-
- TSi = ((17, 100, 192.0.1.66-192.0.1.66),
- (17, 200, 192.0.1.66-192.0.1.66))
- TSr = ((17, 300, 0.0.0.0-255.255.255.255),
- (17, 400, 0.0.0.0-255.255.255.255))
-
- would match UDP packets from 192.0.1.66 to anywhere, with any of the
- four combinations of source/destination ports (100,300), (100,400),
- (200,300), and (200, 400).
-
-
-
-Eronen & Hoffman Informational [Page 18]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- This implies that some types of policies may require several CHILD_SA
- pairs. For instance, a policy matching only source/destination ports
- (100,300) and (200,400), but not the other two combinations, cannot
- be negotiated as a single CHILD_SA pair using IKEv2.
-
- (References: "IKEv2 Traffic Selectors?" thread, Feb 2005.)
-
-4.8. ICMP Type/Code in Traffic Selector Payloads
-
- The traffic selector types 7 and 8 can also refer to ICMP type and
- code fields. As described in Section 3.13.1, "For the ICMP protocol,
- the two one-octet fields Type and Code are treated as a single 16-bit
- integer (with Type in the most significant eight bits and Code in the
- least significant eight bits) port number for the purposes of
- filtering based on this field."
-
- Since ICMP packets do not have separate source and destination port
- fields, there is some room for confusion what exactly the four TS
- payloads (two in the request, two in the response, each containing
- both start and end port fields) should contain.
-
- The answer to this question can be found from [RFC4301] Section
- 4.4.1.3.
-
- To give a concrete example, if a host at 192.0.1.234 wants to create
- a transport mode SA for sending "Destination Unreachable" packets
- (ICMPv4 type 3) to 192.0.2.155, but is not willing to receive them
- over this SA pair, the CREATE_CHILD_SA exchange would look like this:
-
- Initiator Responder
- ----------- -----------
- HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
- TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
- TSr(1, 65535-0, 192.0.2.155-192.0.2.155) } -->
-
- <-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
- TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
- TSr(1, 65535-0, 192.0.2.155-192.0.2.155) }
-
- Since IKEv2 always creates IPsec SAs in pairs, two SAs are also
- created in this case, even though the second SA is never used for
- data traffic.
-
- An exchange creating an SA pair that can be used both for sending and
- receiving "Destination Unreachable" places the same value in all the
- port:
-
-
-
-
-
-Eronen & Hoffman Informational [Page 19]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- Initiator Responder
- ----------- -----------
- HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
- TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
- TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) } -->
-
- <-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
- TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
- TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) }
-
- (References: "ICMP and MH TSs for IKEv2" thread, Sep 2005.)
-
-4.9. Mobility Header in Traffic Selector Payloads
-
- Traffic selectors can use IP Protocol ID 135 to match the IPv6
- mobility header [MIPv6]. However, the IKEv2 specification does not
- define how to represent the "MH Type" field in traffic selectors.
-
- At some point, it was expected that this will be defined in a
- separate document later. However, [RFC4301] says that "For IKE, the
- IPv6 mobility header message type (MH type) is placed in the most
- significant eight bits of the 16 bit local "port" selector". The
- direction semantics of TSi/TSr port fields are the same as for ICMP
- and are described in the previous section.
-
- (References: Tero Kivinen's mail "Issue #86: Add IPv6 mobility header
- message type as selector", 2003-10-14. "ICMP and MH TSs for IKEv2"
- thread, Sep 2005.)
-
-4.10. Narrowing the Traffic Selectors
-
- Section 2.9 describes how traffic selectors are negotiated when
- creating a CHILD_SA. A more concise summary of the narrowing process
- is presented below.
-
- o If the responder's policy does not allow any part of the traffic
- covered by TSi/TSr, it responds with TS_UNACCEPTABLE.
-
- o If the responder's policy allows the entire set of traffic covered
- by TSi/TSr, no narrowing is necessary, and the responder can
- return the same TSi/TSr values.
-
- o Otherwise, narrowing is needed. If the responder's policy allows
- all traffic covered by TSi[1]/TSr[1] (the first traffic selectors
- in TSi/TSr) but not entire TSi/TSr, the responder narrows to an
- acceptable subset of TSi/TSr that includes TSi[1]/TSr[1].
-
-
-
-
-
-Eronen & Hoffman Informational [Page 20]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- o If the responder's policy does not allow all traffic covered by
- TSi[1]/TSr[1], but does allow some parts of TSi/TSr, it narrows to
- an acceptable subset of TSi/TSr.
-
- In the last two cases, there may be several subsets that are
- acceptable (but their union is not); in this case, the responder
- arbitrarily chooses one of them and includes ADDITIONAL_TS_POSSIBLE
- notification in the response.
-
-4.11. SINGLE_PAIR_REQUIRED
-
- The description of the SINGLE_PAIR_REQUIRED notify payload in
- Sections 2.9 and 3.10.1 is not fully consistent.
-
- We do not attempt to describe this payload in this document either,
- since it is expected that most implementations will not have policies
- that require separate SAs for each address pair.
-
- Thus, if only some part (or parts) of the TSi/TSr proposed by the
- initiator is (are) acceptable to the responder, most responders
- should simply narrow TSi/TSr to an acceptable subset (as described in
- the last two paragraphs of Section 2.9), rather than use
- SINGLE_PAIR_REQUIRED.
-
-4.12. Traffic Selectors Violating Own Policy
-
- Section 2.9 describes traffic selector negotiation in great detail.
- One aspect of this negotiation that may need some clarification is
- that when creating a new SA, the initiator should not propose traffic
- selectors that violate its own policy. If this rule is not followed,
- valid traffic may be dropped.
-
- This is best illustrated by an example. Suppose that host A has a
- policy whose effect is that traffic to 192.0.1.66 is sent via host B
- encrypted using Advanced Encryption Standard (AES), and traffic to
- all other hosts in 192.0.1.0/24 is also sent via B, but encrypted
- using Triple Data Encryption Standard (3DES). Suppose also that host
- B accepts any combination of AES and 3DES.
-
- If host A now proposes an SA that uses 3DES, and includes TSr
- containing (192.0.1.0-192.0.1.0.255), this will be accepted by host
- B. Now, host B can also use this SA to send traffic from 192.0.1.66,
- but those packets will be dropped by A since it requires the use of
- AES for those traffic. Even if host A creates a new SA only for
- 192.0.1.66 that uses AES, host B may freely continue to use the first
- SA for the traffic. In this situation, when proposing the SA, host A
- should have followed its own policy, and included a TSr containing
- ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.
-
-
-
-Eronen & Hoffman Informational [Page 21]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- In general, if (1) the initiator makes a proposal "for traffic X
- (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator
- does not actually accept traffic X' with SA, and (3) the initiator
- would be willing to accept traffic X' with some SA' (!=SA), valid
- traffic can be unnecessarily dropped since the responder can apply
- either SA or SA' to traffic X'.
-
- (References: "Question about "narrowing" ..." thread, Feb 2005.
- "IKEv2 needs a "policy usage mode"..." thread, Feb 2005. "IKEv2
- Traffic Selectors?" thread, Feb 2005. "IKEv2 traffic selector
- negotiation examples", 2004-08-08.)
-
-4.13. Traffic Selector Authorization
-
- IKEv2 relies on information in the Peer Authorization Database (PAD)
- when determining what kind of IPsec SAs a peer is allowed to create.
- This process is described in [RFC4301] Section 4.4.3. When a peer
- requests the creation of an IPsec SA with some traffic selectors, the
- PAD must contain "Child SA Authorization Data" linking the identity
- authenticated by IKEv2 and the addresses permitted for traffic
- selectors.
-
- For example, the PAD might be configured so that authenticated
- identity "sgw23.example.com" is allowed to create IPsec SAs for
- 192.0.2.0/24, meaning this security gateway is a valid
- "representative" for these addresses. Host-to-host IPsec requires
- similar entries, linking, for example, "fooserver4.example.com" with
- 192.0.1.66/32, meaning this identity a valid "owner" or
- "representative" of the address in question.
-
- As noted in [RFC4301], "It is necessary to impose these constraints
- on creation of child SAs to prevent an authenticated peer from
- spoofing IDs associated with other, legitimate peers." In the
- example given above, a correct configuration of the PAD prevents
- sgw23 from creating IPsec SAs with address 192.0.1.66 and prevents
- fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24.
-
- It is important to note that simply sending IKEv2 packets using some
- particular address does not imply a permission to create IPsec SAs
- with that address in the traffic selectors. For example, even if
- sgw23 would be able to spoof its IP address as 192.0.1.66, it could
- not create IPsec SAs matching fooserver4's traffic.
-
- The IKEv2 specification does not specify how exactly IP address
- assignment using configuration payloads interacts with the PAD. Our
- interpretation is that when a security gateway assigns an address
-
-
-
-
-
-Eronen & Hoffman Informational [Page 22]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- using configuration payloads, it also creates a temporary PAD entry
- linking the authenticated peer identity and the newly allocated inner
- address.
-
- It has been recognized that configuring the PAD correctly may be
- difficult in some environments. For instance, if IPsec is used
- between a pair of hosts whose addresses are allocated dynamically
- using Dynamic Host Configuration Protocol (DHCP), it is extremely
- difficult to ensure that the PAD specifies the correct "owner" for
- each IP address. This would require a mechanism to securely convey
- address assignments from the DHCP server and link them to identities
- authenticated using IKEv2.
-
- Due to this limitation, some vendors have been known to configure
- their PADs to allow an authenticated peer to create IPsec SAs with
- traffic selectors containing the same address that was used for the
- IKEv2 packets. In environments where IP spoofing is possible (i.e.,
- almost everywhere) this essentially allows any peer to create IPsec
- SAs with any traffic selectors. This is not an appropriate or secure
- configuration in most circumstances. See [Aura05] for an extensive
- discussion about this issue, and the limitations of host-to-host
- IPsec in general.
-
-5. Rekeying and Deleting SAs
-
-5.1. Rekeying SAs with the CREATE_CHILD_SA Exchange
-
- Continued from Section 4.1 of this document.
-
- NEW-1.3.2 Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange
-
- The CREATE_CHILD_SA request for rekeying an IKE_SA is:
-
- Initiator Responder
- ----------- -----------
- HDR, SK {SA, Ni, [KEi]} -->
-
- The initiator sends SA offer(s) in the SA payload, a nonce in
- the Ni payload, and optionally a Diffie-Hellman value in the KEi
- payload.
-
- The CREATE_CHILD_SA response for rekeying an IKE_SA is:
-
- <-- HDR, SK {SA, Nr, [KEr]}
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 23]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- The responder replies (using the same Message ID to respond)
- with the accepted offer in an SA payload, a nonce in the Nr
- payload, and, optionally, a Diffie-Hellman value in the KEr
- payload.
-
- The new IKE_SA has its message counters set to 0, regardless of
- what they were in the earlier IKE_SA. The window size starts at
- 1 for any new IKE_SA. The new initiator and responder SPIs are
- supplied in the SPI fields of the SA payloads.
-
- NEW-1.3.3 Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange
-
- The CREATE_CHILD_SA request for rekeying a CHILD_SA is:
-
- Initiator Responder
- ----------- -----------
- HDR, SK {N(REKEY_SA), [N+], SA,
- Ni, [KEi], TSi, TSr} -->
-
- The leading Notify payload of type REKEY_SA identifies the
- CHILD_SA being rekeyed, and it contains the SPI that the initiator
- expects in the headers of inbound packets. In addition, the
- initiator sends SA offer(s) in the SA payload, a nonce in the Ni
- payload, optionally a Diffie-Hellman value in the KEi payload,
- and the proposed traffic selectors in the TSi and TSr payloads.
- The request can also contain Notify payloads that specify
- additional details for the CHILD_SA.
-
- The CREATE_CHILD_SA response for rekeying a CHILD_SA is:
-
- <-- HDR, SK {[N+], SA, Nr,
- [KEr], TSi, TSr}
-
- The responder replies with the accepted offer in an SA payload,
- and a Diffie-Hellman value in the KEr payload if KEi was
- included in the request and the selected cryptographic suite
- includes that group.
-
- The traffic selectors for traffic to be sent on that SA are
- specified in the TS payloads in the response, which may be a
- subset of what the initiator of the CHILD_SA proposed.
-
-5.2. Rekeying the IKE_SA vs. Reauthentication
-
- Rekeying the IKE_SA and reauthentication are different concepts in
- IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and
- resets the Message ID counters, but it does not authenticate the
- parties again (no AUTH or EAP payloads are involved).
-
-
-
-Eronen & Hoffman Informational [Page 24]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- While rekeying the IKE_SA may be important in some environments,
- reauthentication (the verification that the parties still have access
- to the long-term credentials) is often more important.
-
- IKEv2 does not have any special support for reauthentication.
- Reauthentication is done by creating a new IKE_SA from scratch (using
- IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
- payloads), creating new CHILD_SAs within the new IKE_SA (without
- REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
- deletes the old CHILD_SAs as well).
-
- This means that reauthentication also establishes new keys for the
- IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed
- more often than reauthentication, the situation where "authentication
- lifetime" is shorter than "key lifetime" does not make sense.
-
- While creation of a new IKE_SA can be initiated by either party
- (initiator or responder in the original IKE_SA), the use of EAP
- authentication and/or configuration payloads means in practice that
- reauthentication has to be initiated by the same party as the
- original IKE_SA. IKEv2 base specification does not allow the
- responder to request reauthentication in this case; however, this
- functionality is added in [ReAuth].
-
- (References: "Reauthentication in IKEv2" thread, Oct/Nov 2004.)
-
-5.3. SPIs When Rekeying the IKE_SA
-
- Section 2.18 says that "New initiator and responder SPIs are supplied
- in the SPI fields". This refers to the SPI fields in the Proposal
- structures inside the Security Association (SA) payloads, not the SPI
- fields in the IKE header.
-
- (References: Tom Stiemerling's mail "Rekey IKE SA", 2005-01-24.
- Geoffrey Huang's reply, 2005-01-24.)
-
-5.4. SPI When Rekeying a CHILD_SA
-
- Section 3.10.1 says that in REKEY_SA notifications, "The SPI field
- identifies the SA being rekeyed."
-
- Since CHILD_SAs always exist in pairs, there are two different SPIs.
- The SPI placed in the REKEY_SA notification is the SPI the exchange
- initiator would expect in inbound ESP or AH packets (just as in
- Delete payloads).
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 25]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-5.5. Changing PRFs When Rekeying the IKE_SA
-
- When rekeying the IKE_SA, Section 2.18 says that "SKEYSEED for the
- new IKE_SA is computed using SK_d from the existing IKE_SA as
- follows:
-
- SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)"
-
- If the old and new IKE_SA selected a different PRF, it is not totally
- clear which PRF should be used.
-
- Since the rekeying exchange belongs to the old IKE_SA, it is the old
- IKE_SA's PRF that is used. This also follows the principle that the
- same key (the old SK_d) should not be used with multiple
- cryptographic algorithms.
-
- Note that this may work poorly if the new IKE_SA's PRF has a fixed
- key size, since the output of the PRF may not be of the correct size.
- This supports our opinion earlier in the document that the use of
- PRFs with a fixed key size is a bad idea.
-
- (References: "Changing PRFs when rekeying the IKE_SA" thread, June
- 2005.)
-
-5.6. Deleting vs. Closing SAs
-
- The IKEv2 specification talks about "closing" and "deleting" SAs, but
- it is not always clear what exactly is meant. However, other parts
- of the specification make it clear that when local state related to a
- CHILD_SA is removed, the SA must also be actively deleted with a
- Delete payload.
-
- In particular, Section 2.4 says that "If an IKE endpoint chooses to
- delete CHILD_SAs, it MUST send Delete payloads to the other end
- notifying it of the deletion". Section 1.4 also explains that "ESP
- and AH SAs always exist in pairs, with one SA in each direction.
- When an SA is closed, both members of the pair MUST be closed."
-
-5.7. Deleting a CHILD_SA Pair
-
- Section 1.4 describes how to delete SA pairs using the Informational
- exchange: "To delete an SA, an INFORMATIONAL exchange with one or
- more delete payloads is sent listing the SPIs (as they would be
- expected in the headers of inbound packets) of the SAs to be deleted.
- The recipient MUST close the designated SAs."
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 26]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- The "one or more delete payloads" phrase has caused some confusion.
- You never send delete payloads for the two sides of an SA in a single
- message. If you have many SAs to delete at the same time (such as
- the nested example given in that paragraph), you include delete
- payloads for the inbound half of each SA in your Informational
- exchange.
-
-5.8. Deleting an IKE_SA
-
- Since IKE_SAs do not exist in pairs, it is not totally clear what the
- response message should contain when the request deleted the IKE_SA.
-
- Since there is no information that needs to be sent to the other side
- (except that the request was received), an empty Informational
- response seems like the most logical choice.
-
- (References: "Question about delete IKE SA" thread, May 2005.)
-
-5.9. Who is the original initiator of IKE_SA
-
- In the IKEv2 document, "initiator" refers to the party who initiated
- the exchange being described, and "original initiator" refers to the
- party who initiated the whole IKE_SA. However, there is some
- potential for confusion because the IKE_SA can be rekeyed by either
- party.
-
- To clear up this confusion, we propose that "original initiator"
- always refers to the party who initiated the exchange that resulted
- in the current IKE_SA. In other words, if the "original responder"
- starts rekeying the IKE_SA, that party becomes the "original
- initiator" of the new IKE_SA.
-
- (References: Paul Hoffman's mail "Original initiator in IKEv2",
- 2005-04-21.)
-
-5.10. Comparing Nonces
-
- Section 2.8 about rekeying says that "If redundant SAs are created
- though such a collision, the SA created with the lowest of the four
- nonces used in the two exchanges SHOULD be closed by the endpoint
- that created it."
-
-
-
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 27]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- Here "lowest" uses an octet-by-octet (lexicographical) comparison
- (instead of, for instance, comparing the nonces as large integers).
- In other words, start by comparing the first octet; if they're equal,
- move to the next octet, and so on. If you reach the end of one
- nonce, that nonce is the lower one.
-
- (References: "IKEv2 rekeying question" thread, July 2005.)
-
-5.11. Exchange Collisions
-
- Since IKEv2 exchanges can be initiated by both peers, it is possible
- that two exchanges affecting the same SA partly overlap. This can
- lead to a situation where the SA state information is temporarily not
- synchronized, and a peer can receive a request it cannot process in a
- normal fashion. Some of these corner cases are discussed in the
- specification, some are not.
-
- Obviously, using a window size greater than one leads to infinitely
- more complex situations, especially if requests are processed out of
- order. In this section, we concentrate on problems that can arise
- even with window size 1.
-
- (References: "IKEv2: invalid SPI in DELETE payload" thread, Dec 2005/
- Jan 2006. "Problem with exchanges collisions" thread, Dec 2005.)
-
-5.11.1. Simultaneous CHILD_SA Close
-
- Probably the simplest case happens if both peers decide to close the
- same CHILD_SA pair at the same time:
-
- Host A Host B
- -------- --------
- send req1: D(SPIa) -->
- <-- send req2: D(SPIb)
- --> recv req1
- <-- send resp1: ()
- recv resp1
- recv req2
- send resp2: () -->
- --> recv resp2
-
- This case is described in Section 1.4 and is handled by omitting the
- Delete payloads from the response messages.
-
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 28]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-5.11.2. Simultaneous IKE_SA Close
-
- Both peers can also decide to close the IKE_SA at the same time. The
- desired end result is obvious; however, in certain cases the final
- exchanges may not be fully completed.
-
- Host A Host B
- -------- --------
- send req1: D() -->
- <-- send req2: D()
- --> recv req1
-
- At this point, host B should reply as usual (with empty Informational
- response), close the IKE_SA, and stop retransmitting req2. This is
- because once host A receives resp1, it may not be able to reply any
- longer. The situation is symmetric, so host A should behave the same
- way.
-
- Host A Host B
- -------- --------
- <-- send resp1: ()
- send resp2: ()
-
- Even if neither resp1 nor resp2 ever arrives, the end result is still
- correct: the IKE_SA is gone. The same happens if host A never
- receives req2.
-
-5.11.3. Simultaneous CHILD_SA Rekeying
-
- Another case that is described in the specification is simultaneous
- rekeying. Section 2.8 says
-
- "If the two ends have the same lifetime policies, it is possible
- that both will initiate a rekeying at the same time (which will
- result in redundant SAs). To reduce the probability of this
- happening, the timing of rekeying requests SHOULD be jittered
- (delayed by a random amount of time after the need for rekeying is
- noticed).
-
- This form of rekeying may temporarily result in multiple similar
- SAs between the same pairs of nodes. When there are two SAs
- eligible to receive packets, a node MUST accept incoming packets
- through either SA. If redundant SAs are created though such a
- collision, the SA created with the lowest of the four nonces used
- in the two exchanges SHOULD be closed by the endpoint that created
- it."
-
-
-
-
-
-Eronen & Hoffman Informational [Page 29]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- However, a better explanation on what impact this has on
- implementations is needed. Assume that hosts A and B have an
- existing IPsec SA pair with SPIs (SPIa1,SPIb1), and both start
- rekeying it at the same time:
-
- Host A Host B
- -------- --------
- send req1: N(REKEY_SA,SPIa1),
- SA(..,SPIa2,..),Ni1,.. -->
- <-- send req2: N(REKEY_SA,SPIb1),
- SA(..,SPIb2,..),Ni2,..
- recv req2 <--
-
- At this point, A knows there is a simultaneous rekeying going on.
- However, it cannot yet know which of the exchanges will have the
- lowest nonce, so it will just note the situation and respond as
- usual.
-
- send resp2: SA(..,SPIa3,..),Nr1,.. -->
- --> recv req1
-
- Now B also knows that simultaneous rekeying is going on. Similarly
- as host A, it has to respond as usual.
-
- <-- send resp1: SA(..,SPIb3,..),Nr2,..
- recv resp1 <--
- --> recv resp2
-
- At this point, there are three CHILD_SA pairs between A and B (the
- old one and two new ones). A and B can now compare the nonces.
- Suppose that the lowest nonce was Nr1 in message resp2; in this case,
- B (the sender of req2) deletes the redundant new SA, and A (the node
- that initiated the surviving rekeyed SA) deletes the old one.
-
- send req3: D(SPIa1) -->
- <-- send req4: D(SPIb2)
- --> recv req3
- <-- send resp4: D(SPIb1)
- recv req4 <--
- send resp4: D(SPIa3) -->
-
- The rekeying is now finished.
-
- However, there is a second possible sequence of events that can
- happen if some packets are lost in the network, resulting in
- retransmissions. The rekeying begins as usual, but A's first packet
- (req1) is lost.
-
-
-
-
-Eronen & Hoffman Informational [Page 30]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- Host A Host B
- -------- --------
- send req1: N(REKEY_SA,SPIa1),
- SA(..,SPIa2,..),Ni1,.. --> (lost)
- <-- send req2: N(REKEY_SA,SPIb1),
- SA(..,SPIb2,..),Ni2,..
- recv req2 <--
- send resp2: SA(..,SPIa3,..),Nr1,.. -->
- --> recv resp2
- <-- send req3: D(SPIb1)
- recv req3 <--
- send resp3: D(SPIa1) -->
- --> recv resp3
-
- From B's point of view, the rekeying is now completed, and since it
- has not yet received A's req1, it does not even know that these was
- simultaneous rekeying. However, A will continue retransmitting the
- message, and eventually it will reach B.
-
- resend req1 -->
- --> recv req1
-
- What should B do in this point? To B, it looks like A is trying to
- rekey an SA that no longer exists; thus failing the request with
- something non-fatal such as NO_PROPOSAL_CHOSEN seems like a
- reasonable approach.
-
- <-- send resp1: N(NO_PROPOSAL_CHOSEN)
- recv resp1 <--
-
- When A receives this error, it already knows there was simultaneous
- rekeying, so it can ignore the error message.
-
-5.11.4. Simultaneous IKE_SA Rekeying
-
- Probably the most complex case occurs when both peers try to rekey
- the IKE_SA at the same time. Basically, the text in Section 2.8
- applies to this case as well; however, it is important to ensure that
- the CHILD_SAs are inherited by the right IKE_SA.
-
- The case where both endpoints notice the simultaneous rekeying works
- the same way as with CHILD_SAs. After the CREATE_CHILD_SA exchanges,
- three IKE_SAs exist between A and B; the one containing the lowest
- nonce inherits the CHILD_SAs.
-
- However, there is a twist to the other case where one rekeying
- finishes first:
-
-
-
-
-Eronen & Hoffman Informational [Page 31]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- Host A Host B
- -------- --------
- send req1:
- SA(..,SPIa1,..),Ni1,.. -->
- <-- send req2: SA(..,SPIb1,..),Ni2,..
- --> recv req1
- <-- send resp1: SA(..,SPIb2,..),Nr2,..
- recv resp1 <--
- send req3: D() -->
- --> recv req3
-
- At this point, host B sees a request to close the IKE_SA. There's
- not much more to do than to reply as usual. However, at this point
- host B should stop retransmitting req2, since once host A receives
- resp3, it will delete all the state associated with the old IKE_SA
- and will not be able to reply to it.
-
- <-- send resp3: ()
-
-5.11.5. Closing and Rekeying a CHILD_SA
-
- A case similar to simultaneous rekeying can occur if one peer decides
- to close an SA and the other peer tries to rekey it:
-
- Host A Host B
- -------- --------
- send req1: D(SPIa) -->
- <-- send req2: N(REKEY_SA,SPIb),SA,..
- --> recv req1
-
- At this point, host B notices that host A is trying to close an SA
- that host B is currently rekeying. Replying as usual is probably the
- best choice:
-
- <-- send resp1: D(SPIb)
-
- Depending on in which order req2 and resp1 arrive, host A sees either
- a request to rekey an SA that it is currently closing, or a request
- to rekey an SA that does not exist. In both cases,
- NO_PROPOSAL_CHOSEN is probably fine.
-
- recv req2
- recv resp1
- send resp2: N(NO_PROPOSAL_CHOSEN) -->
- --> recv resp2
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 32]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-5.11.6. Closing a New CHILD_SA
-
- Yet another case occurs when host A creates a CHILD_SA pair, but soon
- thereafter host B decides to delete it (possible because its policy
- changed):
-
- Host A Host B
- -------- --------
- send req1: [N(REKEY_SA,SPIa1)],
- SA(..,SPIa2,..),.. -->
- --> recv req1
- (lost) <-- send resp1: SA(..,SPIb2,..),..
-
- <-- send req2: D(SPIb2)
- recv req2
-
- At this point, host A has not yet received message resp1 (and is
- retransmitting message req1), so it does not recognize SPIb in
- message req2. What should host A do?
-
- One option would be to reply with an empty Informational response.
- However, this same reply would also be sent if host A has received
- resp1, but has already sent a new request to delete the SA that was
- just created. This would lead to a situation where the peers are no
- longer in sync about which SAs exist between them. However, host B
- would eventually notice that the other half of the CHILD_SA pair has
- not been deleted. Section 1.4 describes this case and notes that "a
- node SHOULD regard half-closed connections as anomalous and audit
- their existence should they persist", and continues that "if
- connection state becomes sufficiently messed up, a node MAY close the
- IKE_SA".
-
- Another solution that has been proposed is to reply with an
- INVALID_SPI notification that contains SPIb. This would explicitly
- tell host B that the SA was not deleted, so host B could try deleting
- it again later. However, this usage is not part of the IKEv2
- specification and would not be in line with normal use of the
- INVALID_SPI notification where the data field contains the SPI the
- recipient of the notification would put in outbound packets.
-
- Yet another solution would be to ignore req2 at this time and wait
- until we have received resp1. However, this alternative has not been
- fully analyzed at this time; in general, ignoring valid requests is
- always a bit dangerous, because both endpoints could do it, leading
- to a deadlock.
-
- This document recommends the first alternative.
-
-
-
-
-Eronen & Hoffman Informational [Page 33]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-5.11.7. Rekeying a New CHILD_SA
-
- Yet another case occurs when a CHILD_SA is rekeyed soon after it has
- been created:
-
- Host A Host B
- -------- --------
- send req1: [N(REKEY_SA,SPIa1)],
- SA(..,SPIa2,..),.. -->
- (lost) <-- send resp1: SA(..,SPIb2,..),..
-
- <-- send req2: N(REKEY_SA,SPIb2),
- SA(..,SPIb3,..),..
- recv req2 <--
-
- To host A, this looks like a request to rekey an SA that does not
- exist. Like in the simultaneous rekeying case, replying with
- NO_PROPOSAL_CHOSEN is probably reasonable:
-
- send resp2: N(NO_PROPOSAL_CHOSEN) -->
- recv resp1
-
-5.11.8. Collisions with IKE_SA Rekeying
-
- Another set of cases occurs when one peer starts rekeying the IKE_SA
- at the same time the other peer starts creating, rekeying, or closing
- a CHILD_SA. Suppose that host B starts creating a CHILD_SA, and soon
- after, host A starts rekeying the IKE_SA:
-
- Host A Host B
- -------- --------
- <-- send req1: SA,Ni1,TSi,TSr
- send req2: SA,Ni2,.. -->
- --> recv req2
-
- What should host B do at this point? Replying as usual would seem
- like a reasonable choice:
-
- <-- send resp2: SA,Ni2,..
- recv resp2 <--
- send req3: D() -->
- --> recv req3
-
- Now, a problem arises: If host B now replies normally with an empty
- Informational response, this will cause host A to delete state
- associated with the IKE_SA. This means host B should stop
- retransmitting req1. However, host B cannot know whether or not host
- A has received req1. If host A did receive it, it will move the
-
-
-
-Eronen & Hoffman Informational [Page 34]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- CHILD_SA to the new IKE_SA as usual, and the state information will
- then be out of sync.
-
- It seems this situation is tricky to handle correctly. Our proposal
- is as follows: if a host receives a request to rekey the IKE_SA when
- it has CHILD_SAs in "half-open" state (currently being created or
- rekeyed), it should reply with NO_PROPOSAL_CHOSEN. If a host
- receives a request to create or rekey a CHILD_SA after it has started
- rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS.
-
- The case where CHILD_SAs are being closed is even worse. Our
- recommendation is that if a host receives a request to rekey the
- IKE_SA when it has CHILD_SAs in "half-closed" state (currently being
- closed), it should reply with NO_PROPOSAL_CHOSEN. And if a host
- receives a request to close a CHILD_SA after it has started rekeying
- the IKE_SA, it should reply with an empty Informational response.
- This ensures that at least the other peer will eventually notice that
- the CHILD_SA is still in "half-closed" state and will start a new
- IKE_SA from scratch.
-
-5.11.9. Closing and Rekeying the IKE_SA
-
- The final case considered in this section occurs if one peer decides
- to close the IKE_SA while the other peer tries to rekey it.
-
- Host A Host B
- -------- --------
- send req1: SA(..,SPIa1,..),Ni1 -->
- <-- send req2: D()
- --> recv req1
- recv req2 <--
-
- At this point, host B should probably reply with NO_PROPOSAL_CHOSEN,
- and host A should reply as usual, close the IKE_SA, and stop
- retransmitting req1.
-
- <-- send resp1: N(NO_PROPOSAL_CHOSEN)
- send resp2: ()
-
- If host A wants to continue communication with B, it can now start a
- new IKE_SA.
-
-5.11.10. Summary
-
- If a host receives a request to rekey:
-
- o a CHILD_SA pair that the host is currently trying to close: reply
- with NO_PROPOSAL_CHOSEN.
-
-
-
-Eronen & Hoffman Informational [Page 35]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- o a CHILD_SA pair that the host is currently rekeying: reply as
- usual, but prepare to close redundant SAs later based on the
- nonces.
-
- o a CHILD_SA pair that does not exist: reply with
- NO_PROPOSAL_CHOSEN.
-
- o the IKE_SA, and the host is currently rekeying the IKE_SA: reply
- as usual, but prepare to close redundant SAs and move inherited
- CHILD_SAs later based on the nonces.
-
- o the IKE_SA, and the host is currently creating, rekeying, or
- closing a CHILD_SA: reply with NO_PROPOSAL_CHOSEN.
-
- o the IKE_SA, and the host is currently trying to close the IKE_SA:
- reply with NO_PROPOSAL_CHOSEN.
-
- If a host receives a request to close:
-
- o a CHILD_SA pair that the host is currently trying to close: reply
- without Delete payloads.
-
- o a CHILD_SA pair that the host is currently rekeying: reply as
- usual, with Delete payload.
-
- o a CHILD_SA pair that does not exist: reply without Delete
- payloads.
-
- o the IKE_SA, and the host is currently rekeying the IKE_SA: reply
- as usual, and forget about our own rekeying request.
-
- o the IKE_SA, and the host is currently trying to close the IKE_SA:
- reply as usual, and forget about our own close request.
-
- If a host receives a request to create or rekey a CHILD_SA when it is
- currently rekeying the IKE_SA: reply with NO_ADDITIONAL_SAS.
-
- If a host receives a request to delete a CHILD_SA when it is
- currently rekeying the IKE_SA: reply without Delete payloads.
-
-5.12. Diffie-Hellman and Rekeying the IKE_SA
-
- There has been some confusion whether doing a new Diffie-Hellman
- exchange is mandatory when the IKE_SA is rekeyed.
-
- It seems that this case is allowed by the IKEv2 specification.
- Section 2.18 shows the Diffie-Hellman term (g^ir) in brackets.
- Section 3.3.3 does not contradict this when it says that including
-
-
-
-Eronen & Hoffman Informational [Page 36]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- the D-H transform is mandatory: although including the transform is
- mandatory, it can contain the value "NONE".
-
- However, having the option to skip the Diffie-Hellman exchange when
- rekeying the IKE_SA does not add useful functionality to the
- protocol. The main purpose of rekeying the IKE_SA is to ensure that
- the compromise of old keying material does not provide information
- about the current keys, or vice versa. This requires performing the
- Diffie-Hellman exchange when rekeying. Furthermore, it is likely
- that this option would have been removed from the protocol as
- unnecessary complexity had it been discussed earlier.
-
- Given this, we recommend that implementations should have a hard-
- coded policy that requires performing a new Diffie-Hellman exchange
- when rekeying the IKE_SA. In other words, the initiator should not
- propose the value "NONE" for the D-H transform, and the responder
- should not accept such a proposal. This policy also implies that a
- successful exchange rekeying the IKE_SA always includes the KEi/KEr
- payloads.
-
- (References: "Rekeying IKE_SAs with the CREATE_CHILD_SA exhange"
- thread, Oct 2005. "Comments of
- draft-eronen-ipsec-ikev2-clarifications-02.txt" thread, Apr 2005.)
-
-6. Configuration Payloads
-
-6.1. Assigning IP Addresses
-
- Section 2.9 talks about traffic selector negotiation and mentions
- that "In support of the scenario described in section 1.1.3, an
- initiator may request that the responder assign an IP address and
- tell the initiator what it is."
-
- This sentence is correct, but its placement is slightly confusing.
- IKEv2 does allow the initiator to request assignment of an IP address
- from the responder, but this is done using configuration payloads,
- not traffic selector payloads. An address in a TSi payload in a
- response does not mean that the responder has assigned that address
- to the initiator; it only means that if packets matching these
- traffic selectors are sent by the initiator, IPsec processing can be
- performed as agreed for this SA. The TSi payload itself does not
- give the initiator permission to configure the initiator's TCP/IP
- stack with the address and use it as its source address.
-
- In other words, IKEv2 does not have two different mechanisms for
- assigning addresses, but only one: configuration payloads. In the
- scenario described in Section 1.1.3, both configuration and traffic
- selector payloads are usually included in the same message, and they
-
-
-
-Eronen & Hoffman Informational [Page 37]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- often contain the same information in the response message (see
- Section 6.3 of this document for some examples). However, their
- semantics are still different.
-
-6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS
-
- When describing the INTERNAL_IP4/IP6_ADDRESS attributes, Section
- 3.15.1 says that "In a request message, the address specified is a
- requested address (or zero if no specific address is requested)".
- The question here is whether "zero" means an address "0.0.0.0" or a
- zero-length string.
-
- Earlier, the same section also says that "If an attribute in the
- CFG_REQUEST Configuration Payload is not zero-length, it is taken as
- a suggestion for that attribute". Also, the table of configuration
- attributes shows that the length of INTERNAL_IP4_ADDRESS is either "0
- or 4 octets", and likewise, INTERNAL_IP6_ADDRESS is either "0 or 17
- octets".
-
- Thus, if the client does not request a specific address, it includes
- a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, not an attribute
- containing an all-zeroes address. The example in 2.19 is thus
- incorrect, since it shows the attribute as
- "INTERNAL_ADDRESS(0.0.0.0)".
-
- However, since the value is only a suggestion, implementations are
- recommended to ignore suggestions they do not accept; or in other
- words, to treat the same way a zero-length INTERNAL_IP4_ADDRESS,
- "0.0.0.0", and any other addresses the implementation does not
- recognize as a reasonable suggestion.
-
-6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET
-
- Section 3.15.1 describes the INTERNAL_IP4_SUBNET as "The protected
- sub-networks that this edge-device protects. This attribute is made
- up of two fields: the first is an IP address and the second is a
- netmask. Multiple sub-networks MAY be requested. The responder MAY
- respond with zero or more sub-network attributes."
- INTERNAL_IP6_SUBNET is defined in a similar manner.
-
- This raises two questions: first, since this information is usually
- included in the TSr payload, what functionality does this attribute
- add? And second, what does this attribute mean in CFG_REQUESTs?
-
- For the first question, there seem to be two sensible
- interpretations. Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA
- response) indicates which subnets are accessible through the SA that
- was just created.
-
-
-
-Eronen & Hoffman Informational [Page 38]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- The first interpretation of the INTERNAL_IP4/6_SUBNET attributes is
- that they indicate additional subnets that can be reached through
- this gateway, but need a separate SA. According to this
- interpretation, the INTERNAL_IP4/6_SUBNET attributes are useful
- mainly when they contain addresses not included in TSr.
-
- The second interpretation is that the INTERNAL_IP4/6_SUBNET
- attributes express the gateway's policy about what traffic should be
- sent through the gateway. The client can choose whether other
- traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is sent
- through the gateway or directly to the destination. According to
- this interpretation, the attributes are useful mainly when TSr
- contains addresses not included in the INTERNAL_IP4/6_SUBNET
- attributes.
-
- It turns out that these two interpretations are not incompatible, but
- rather two sides of the same principle: traffic to the addresses
- listed in the INTERNAL_IP4/6_SUBNET attributes should be sent via
- this gateway. If there are no existing IPsec SAs whose traffic
- selectors cover the address in question, new SAs have to be created.
-
- A couple of examples are given below. For instance, if there are two
- subnets, 192.0.1.0/26 and 192.0.2.0/24, and the client's request
- contains the following:
-
- CP(CFG_REQUEST) =
- INTERNAL_IP4_ADDRESS()
- TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
- TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
-
- Then a valid response could be the following (in which TSr and
- INTERNAL_IP4_SUBNET contain the same information):
-
- CP(CFG_REPLY) =
- INTERNAL_IP4_ADDRESS(192.0.1.234)
- INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
- INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
- TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
- TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63),
- (0, 0-65535, 192.0.2.0-192.0.2.255))
-
- In these cases, the INTERNAL_IP4_SUBNET does not really carry any
- useful information. Another possible reply would have been this:
-
- CP(CFG_REPLY) =
- INTERNAL_IP4_ADDRESS(192.0.1.234)
- INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
- INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
-
-
-
-Eronen & Hoffman Informational [Page 39]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
- TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
-
- This would mean that the client can send all its traffic through the
- gateway, but the gateway does not mind if the client sends traffic
- not included by INTERNAL_IP4_SUBNET directly to the destination
- (without going through the gateway).
-
- A different situation arises if the gateway has a policy that
- requires the traffic for the two subnets to be carried in separate
- SAs. Then a response like this would indicate to the client that if
- it wants access to the second subnet, it needs to create a separate
- SA:
-
- CP(CFG_REPLY) =
- INTERNAL_IP4_ADDRESS(192.0.1.234)
- INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
- INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
- TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
- TSr = (0, 0-65535, 192.0.1.0-192.0.1.63)
-
- INTERNAL_IP4_SUBNET can also be useful if the client's TSr included
- only part of the address space. For instance, if the client requests
- the following:
-
- CP(CFG_REQUEST) =
- INTERNAL_IP4_ADDRESS()
- TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
- TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
-
- Then the gateway's reply could be this:
-
- CP(CFG_REPLY) =
- INTERNAL_IP4_ADDRESS(192.0.1.234)
- INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
- INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
- TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
- TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
-
- It is less clear what the attributes mean in CFG_REQUESTs, and
- whether other lengths than zero make sense in this situation (but for
- INTERNAL_IP6_SUBNET, zero length is not allowed at all!). This
- document recommends that implementations should not include
- INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in
- CFG_REQUESTs.
-
- For the IPv4 case, this document recommends using only netmasks
- consisting of some amount of "1" bits followed by "0" bits; for
-
-
-
-Eronen & Hoffman Informational [Page 40]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- instance, "255.0.255.0" would not be a valid netmask for
- INTERNAL_IP4_SUBNET.
-
- It is also worthwhile to note that the contents of the INTERNAL_IP4/
- 6_SUBNET attributes do not imply link boundaries. For instance, a
- gateway providing access to a large company intranet using addresses
- from the 10.0.0.0/8 block can send a single INTERNAL_IP4_SUBNET
- attribute (10.0.0.0/255.0.0.0) even if the intranet has hundreds of
- routers and separate links.
-
- (References: Tero Kivinen's mail "Intent of couple of attributes in
- Configuration Payload in IKEv2?", 2004-11-19. Srinivasa Rao
- Addepalli's mail "INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET in
- IKEv2", 2004-09-10. Yoav Nir's mail "Re: New I-D: IKEv2
- Clarifications and Implementation Guidelines", 2005-02-07.
- "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
- April 2005.)
-
-6.4. INTERNAL_IP4_NETMASK
-
- Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute and says
- that "The internal network's netmask. Only one netmask is allowed in
- the request and reply messages (e.g., 255.255.255.0) and it MUST be
- used only with an INTERNAL_IP4_ADDRESS attribute".
-
- However, it is not clear what exactly this attribute means, as the
- concept of "netmask" is not very well defined for point-to-point
- links (unlike multi-access links, where it means "you can reach hosts
- inside this netmask directly using layer 2, instead of sending
- packets via a router"). Even if the operating system's TCP/IP stack
- requires a netmask to be configured, for point-to-point links it
- could be just set to 255.255.255.255. So, why is this information
- sent in IKEv2?
-
- One possible interpretation would be that the host is given a whole
- block of IP addresses instead of a single address. This is also what
- Framed-IP-Netmask does in [RADIUS], the IPCP "subnet mask" extension
- does in PPP [IPCPSubnet], and the prefix length in the IPv6 Framed-
- IPv6-Prefix attribute does in [RADIUS6]. However, nothing in the
- specification supports this interpretation, and discussions on the
- IPsec WG mailing list have confirmed it was not intended. Section
- 3.15.1 also says that multiple addresses are assigned using multiple
- INTERNAL_IP4/6_ADDRESS attributes.
-
- Currently, this document's interpretation is the following:
- INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing as
- INTERNAL_IP4_SUBNET containing the same information ("send traffic to
- these addresses through me"), but also implies a link boundary. For
-
-
-
-Eronen & Hoffman Informational [Page 41]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- instance, the client could use its own address and the netmask to
- calculate the broadcast address of the link. (Whether the gateway
- will actually deliver broadcast packets to other VPN clients and/or
- other nodes connected to this link is another matter.)
-
- An empty INTERNAL_IP4_NETMASK attribute can be included in a
- CFG_REQUEST to request this information (although the gateway can
- send the information even when not requested). However, it seems
- that non-empty values for this attribute do not make sense in
- CFG_REQUESTs.
-
- Fortunately, Section 4 clearly says that a minimal implementation
- does not need to include or understand the INTERNAL_IP4_NETMASK
- attribute, and thus this document recommends that implementations
- should not use the INTERNAL_IP4_NETMASK attribute or assume that the
- other peer supports it.
-
- (References: Charlie Kaufman's mail "RE: Proposed Last Call based
- revisions to IKEv2", 2004-05-27. Email discussion with Tero Kivinen,
- Jan 2005. Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and
- Implementation Guidelines", 2005-02-07. "Clarifications open issue:
- INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)
-
-6.5. Configuration Payloads for IPv6
-
- IKEv2 also defines configuration payloads for IPv6. However, they
- are based on the corresponding IPv4 payloads and do not fully follow
- the "normal IPv6 way of doing things".
-
- A client can be assigned an IPv6 address using the
- INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange could
- look like this:
-
- CP(CFG_REQUEST) =
- INTERNAL_IP6_ADDRESS()
- INTERNAL_IP6_DNS()
- TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
- TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
-
- CP(CFG_REPLY) =
- INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
- INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
- TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
- TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
-
- In particular, IPv6 stateless autoconfiguration or router
- advertisement messages are not used; neither is neighbor discovery.
-
-
-
-
-Eronen & Hoffman Informational [Page 42]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- The client can also send a non-empty INTERNAL_IP6_ADDRESS attribute
- in the CFG_REQUEST to request a specific address or interface
- identifier. The gateway first checks if the specified address is
- acceptable, and if it is, returns that one. If the address was not
- acceptable, the gateway will attempt to use the interface identifier
- with some other prefix; if even that fails, the gateway will select
- another interface identifier.
-
- The INTERNAL_IP6_ADDRESS attribute also contains a prefix length
- field. When used in a CFG_REPLY, this corresponds to the
- INTERNAL_IP4_NETMASK attribute in the IPv4 case (and indeed, was
- called INTERNAL_IP6_NETMASK in earlier versions of the IKEv2 draft).
- See the previous section for more details.
-
- While this approach to configuring IPv6 addresses is reasonably
- simple, it has some limitations: IPsec tunnels configured using IKEv2
- are not fully-featured "interfaces" in the IPv6 addressing
- architecture [IPv6Addr] sense. In particular, they do not
- necessarily have link-local addresses, and this may complicate the
- use of protocols that assume them, such as [MLDv2]. (Whether they
- are called "interfaces" in some particular operating system is a
- different issue.)
-
- (References: "VPN remote host configuration IPv6 ?" thread, May 2004.
- "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
- April 2005.)
-
-6.6. INTERNAL_IP6_NBNS
-
- Section 3.15.1 defines the INTERNAL_IP6_NBNS attribute for sending
- the IPv6 address of NetBIOS name servers.
-
- However, NetBIOS is not defined for IPv6 and probably never will be.
- Thus, this attribute most likely does not make much sense.
-
- (Pointed out by Bernard Aboba in the IP Configuration Security (ICOS)
- BoF at IETF62.)
-
-6.7. INTERNAL_ADDRESS_EXPIRY
-
- Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as
- "Specifies the number of seconds that the host can use the internal
- IP address. The host MUST renew the IP address before this expiry
- time. Only one of these attributes MAY be present in the reply."
-
- Expiry times and explicit renewals are primarily useful in
- environments like DHCP, where the server cannot reliably know when
-
-
-
-
-Eronen & Hoffman Informational [Page 43]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- the client has gone away. However, in IKEv2 this is known, and the
- gateway can simply free the address when the IKE_SA is deleted.
-
- Also, Section 4 says that supporting renewals is not mandatory.
- Given that this functionality is usually not needed, we recommend
- that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute.
- (And since this attribute does not seem to make much sense for
- CFG_REQUESTs, clients should not send it either.)
-
- Note that according to Section 4, clients are required to understand
- INTERNAL_ADDRESS_EXPIRY if they receive it. A minimum implementation
- would use the value to limit the lifetime of the IKE_SA.
-
- (References: Tero Kivinen's mail "Comments of
- draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.
- "Questions about internal address" thread, April 2005.)
-
-6.8. Address Assignment Failures
-
- If the responder encounters an error while attempting to assign an IP
- address to the initiator, it responds with an
- INTERNAL_ADDRESS_FAILURE notification as described in Section 3.10.1.
- However, there are some more complex error cases.
-
- First, if the responder does not support configuration payloads at
- all, it can simply ignore all configuration payloads. This type of
- implementation never sends INTERNAL_ADDRESS_FAILURE notifications.
- If the initiator requires the assignment of an IP address, it will
- treat a response without CFG_REPLY as an error.
-
- A second case is where the responder does support configuration
- payloads, but only for particular type of addresses (IPv4 or IPv6).
- Section 4 says that "A minimal IPv4 responder implementation will
- ignore the contents of the CP payload except to determine that it
- includes an INTERNAL_IP4_ADDRESS attribute". If, for instance, the
- initiator includes both INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS
- in the CFG_REQUEST, an IPv4-only responder can thus simply ignore the
- IPv6 part and process the IPv4 request as usual.
-
- A third case is where the initiator requests multiple addresses of a
- type that the responder supports: what should happen if some (but not
- all) of the requests fail? It seems that an optimistic approach
- would be the best one here: if the responder is able to assign at
- least one address, it replies with those; it sends
- INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.
-
- (References: "ikev2 and internal_ivpn_address" thread, June 2005.)
-
-
-
-
-Eronen & Hoffman Informational [Page 44]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-7. Miscellaneous Issues
-
-7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR
-
- When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr
- payloads, IKEv2 does not require this address to match anything in
- the TSi/TSr payloads. For example, in a site-to-site VPN between two
- security gateways, the gateways could authenticate each other as
- ID_IPV4_ADDR(192.0.1.1) and ID_IPV4_ADDR(192.0.2.1), and then create
- a CHILD_SA for protecting traffic between 192.0.1.55/32 (a host
- behind the first security gateway) and 192.0.2.240/28 (a network
- behind the second security gateway). The authenticated identities
- (IDi/IDr) are linked to the authorized traffic selectors (TSi/TSr)
- using "Child SA Authorization Data" in the Peer Authorization
- Database (PAD).
-
- Furthermore, IKEv2 does not require that the addresses in
- ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of the
- IKE packets. However, other specifications may place additional
- requirements regarding this. For example, [PKI4IPsec] requires that
- implementation must be capable of comparing the addresses in the
- ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in the IP header of the
- IKE packets, and this comparison must be enabled by default.
-
- (References: "Identities types IP address,FQDN/user FQDN and DN and
- its usage in preshared key authentication" thread, Jan 2005.
- "Matching ID_IPV4_ADDR and ID_IPV6_ADDR" thread, May 2006.)
-
-7.2. Relationship of IKEv2 to RFC 4301
-
- The IKEv2 specification refers to [RFC4301], but it never clearly
- defines the exact relationship.
-
- However, there are some requirements in the specification that make
- it clear that IKEv2 requires [RFC4301]. In other words, an
- implementation that does IPsec processing strictly according to
- [RFC2401] cannot be compliant with the IKEv2 specification.
-
- One such example can be found in Section 2.24: "Specifically, tunnel
- encapsulators and decapsulators for all tunnel-mode SAs created by
- IKEv2 [...] MUST implement the tunnel encapsulation and
- decapsulation processing specified in [RFC4301] to prevent discarding
- of ECN congestion indications."
-
- Nevertheless, the changes required to existing [RFC2401]
- implementations are not very large, especially since supporting many
- of the new features (such as Extended Sequence Numbers) is optional.
-
-
-
-
-Eronen & Hoffman Informational [Page 45]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-7.3. Reducing the Window Size
-
- In IKEv2, the window size is assumed to be a (possibly configurable)
- property of a particular implementation and is not related to
- congestion control (unlike the window size in TCP, for instance).
-
- In particular, it is not defined what the responder should do when it
- receives a SET_WINDOW_SIZE notification containing a smaller value
- than is currently in effect. Thus, there is currently no way to
- reduce the window size of an existing IKE_SA. However, when rekeying
- an IKE_SA, the new IKE_SA starts with window size 1 until it is
- explicitly increased by sending a new SET_WINDOW_SIZE notification.
-
- (References: Tero Kivinen's mail "Comments of
- draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)
-
-7.4. Minimum Size of Nonces
-
- Section 2.10 says that "Nonces used in IKEv2 MUST be randomly chosen,
- MUST be at least 128 bits in size, and MUST be at least half the key
- size of the negotiated prf."
-
- However, the initiator chooses the nonce before the outcome of the
- negotiation is known. In this case, the nonce has to be long enough
- for all the PRFs being proposed.
-
-7.5. Initial Zero Octets on Port 4500
-
- It is not clear whether a peer sending an IKE_SA_INIT request on port
- 4500 should include the initial four zero octets. Section 2.23 talks
- about how to upgrade to tunneling over port 4500 after message 2, but
- it does not say what to do if message 1 is sent on port 4500.
-
- IKE MUST listen on port 4500 as well as port 500.
-
- [...]
-
- The IKE initiator MUST check these payloads if present and if
- they do not match the addresses in the outer packet MUST tunnel
- all future IKE and ESP packets associated with this IKE_SA over
- UDP port 4500.
-
- To tunnel IKE packets over UDP port 4500, the IKE header has four
- octets of zero prepended and the result immediately follows the
- UDP header. [...]
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 46]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- The very beginning of Section 2 says "... though IKE messages may
- also be received on UDP port 4500 with a slightly different format
- (see section 2.23)."
-
- That "slightly different format" is only described in discussing what
- to do after changing to port 4500. However, [RFC3948] shows clearly
- the format has the initial zeros even for initiators on port 4500.
- Furthermore, without the initial zeros, the processing engine cannot
- determine whether the packet is an IKE packet or an ESP packet.
-
- Thus, all packets sent on port 4500 need the four-zero prefix;
- otherwise, the receiver won't know how to handle them.
-
-7.6. Destination Port for NAT Traversal
-
- Section 2.23 says that "an IPsec endpoint that discovers a NAT
- between it and its correspondent MUST send all subsequent traffic to
- and from port 4500".
-
- This sentence is misleading. The peer "outside" the NAT uses source
- port 4500 for the traffic it sends, but the destination port is, of
- course, taken from packets sent by the peer behind the NAT. This
- port number is usually dynamically allocated by the NAT.
-
-7.7. SPI Values for Messages outside an IKE_SA
-
- The IKEv2 specification is not quite clear what SPI values should be
- used in the IKE header for the small number of notifications that are
- allowed to be sent outside an IKE_SA. Note that such notifications
- are explicitly not Informational exchanges; Section 1.5 makes it
- clear that these are one-way messages that must not be responded to.
-
- There are two cases when such a one-way notification can be sent:
- INVALID_IKE_SPI and INVALID_SPI.
-
- In case of INVALID_IKE_SPI, the message sent is a response message,
- and Section 2.21 says that "If a response is sent, the response MUST
- be sent to the IP address and port from whence it came with the same
- IKE SPIs and the Message ID copied."
-
- In case of INVALID_SPI, however, there are no IKE SPI values that
- would be meaningful to the recipient of such a notification. Also,
- the message sent is now an INFORMATIONAL request. A strict
- interpretation of the specification would require the sender to
- invent garbage values for the SPI fields. However, we think this was
- not the intention, and using zero values is acceptable.
-
- (References: "INVALID_IKE_SPI" thread, June 2005.)
-
-
-
-Eronen & Hoffman Informational [Page 47]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-7.8. Protocol ID/SPI Fields in Notify Payloads
-
- Section 3.10 says that the Protocol ID field in Notify payloads "For
- notifications that do not relate to an existing SA, this field MUST
- be sent as zero and MUST be ignored on receipt". However, the
- specification does not clearly say which notifications are related to
- existing SAs and which are not.
-
- Since the main purpose of the Protocol ID field is to specify the
- type of the SPI, our interpretation is that the Protocol ID field
- should be non-zero only when the SPI field is non-empty.
-
- There are currently only two notifications where this is the case:
- INVALID_SELECTORS and REKEY_SA.
-
-7.9. Which message should contain INITIAL_CONTACT
-
- The description of the INITIAL_CONTACT notification in Section 3.10.1
- says that "This notification asserts that this IKE_SA is the only
- IKE_SA currently active between the authenticated identities".
- However, neither Section 2.4 nor 3.10.1 says in which message this
- payload should be placed.
-
- The general agreement is that INITIAL_CONTACT is best communicated in
- the first IKE_AUTH request, not as a separate exchange afterwards.
-
- (References: "Clarifying the use of INITIAL_CONTACT in IKEv2" thread,
- April 2005. "Initial Contact messages" thread, December 2004.
- "IKEv2 and Initial Contact" thread, September 2004 and April 2005.)
-
-7.10. Alignment of Payloads
-
- Many IKEv2 payloads contain fields marked as "RESERVED", mostly
- because IKEv1 had them, and partly because they make the pictures
- easier to draw. In particular, payloads in IKEv2 are not, in
- general, aligned to 4-octet boundaries. (Note that payloads were not
- aligned to 4-octet boundaries in IKEv1 either.)
-
- (References: "IKEv2: potential 4-byte alignment problem" thread, June
- 2004.)
-
-7.11. Key Length Transform Attribute
-
- Section 3.3.5 says that "The only algorithms defined in this document
- that accept attributes are the AES based encryption, integrity, and
- pseudo-random functions, which require a single attribute specifying
- key width."
-
-
-
-
-Eronen & Hoffman Informational [Page 48]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- This is incorrect. The AES-based integrity and pseudo-random
- functions defined in [IKEv2] always use a 128-bit key. In fact,
- there are currently no integrity or PRF algorithms that use the key
- length attribute (and we recommend that they should not be defined in
- the future either).
-
- For encryption algorithms, the situation is slightly more complex
- since there are three different types of algorithms:
-
- o The key length attribute is never used with algorithms that use a
- fixed length key, such as DES and IDEA.
-
- o The key length attribute is always included for the currently
- defined AES-based algorithms (Cipher Block Chaining (CBC), Counter
- (CTR) Mode, Counter with CBC-MAC (CCM), and Galois/Counter Mode
- (GCM)). Omitting the key length attribute is not allowed; if the
- proposal does not contain it, the proposal has to be rejected.
-
- o For other algorithms, the key length attribute can be included but
- is not mandatory. These algorithms include, e.g., RC5, CAST, and
- BLOWFISH. If the key length attribute is not included, the
- default value specified in [RFC2451] is used.
-
-7.12. IPsec IANA Considerations
-
- There are currently three different IANA registry files that contain
- important numbers for IPsec: ikev2-registry, isakmp-registry, and
- ipsec-registry. Implementers should note that IKEv2 may use numbers
- different from those of IKEv1 for a particular algorithm.
-
- For instance, an encryption algorithm can have up to three different
- numbers: the IKEv2 "Transform Type 1" identifier in ikev2-registry,
- the IKEv1 phase 1 "Encryption Algorithm" identifier in ipsec-
- registry, and the IKEv1 phase 2 "IPSEC ESP Transform Identifier"
- isakmp-registry. Although some algorithms have the same number in
- all three registries, the registries are not identical.
-
- Similarly, an integrity algorithm can have at least the IKEv2
- "Transform Type 3" identifier in ikev2-registry, the IKEv1 phase 2
- "IPSEC AH Transform Identifier" in isakmp-registry, and the IKEv1
- phase 2 ESP "Authentication Algorithm Security Association Attribute"
- identifier in isakmp-registry. And there is also the IKEv1 phase 1
- "Hash Algorithm" list in ipsec-registry.
-
- This issue needs special care also when writing a specification for
- how a new algorithm is used with IPsec.
-
-
-
-
-
-Eronen & Hoffman Informational [Page 49]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-7.13. Combining ESP and AH
-
- The IKEv2 specification contains some misleading text about how ESP
- and AH can be combined.
-
- IKEv2 is based on [RFC4301], which does not include "SA bundles" that
- were part of [RFC2401]. While a single packet can go through IPsec
- processing multiple times, each of these passes uses a separate SA,
- and the passes are coordinated by the forwarding tables. In IKEv2,
- each of these SAs has to be created using a separate CREATE_CHILD_SA
- exchange. Thus, the text in Section 2.7 about a single proposal
- containing both ESP and AH is incorrect.
-
- Moreover, the combination of ESP and AH (between the same endpoints)
- had already become largely obsolete in 1998 when RFC 2406 was
- published. Our recommendation is that IKEv2 implementations should
- not support this combination, and implementers should not assume the
- combination can be made to work in an interoperable manner.
-
- (References: "Rekeying SA bundles" thread, Oct 2005.)
-
-8. Implementation Mistakes
-
- Some implementers at the early IKEv2 bakeoffs didn't do everything
- correctly. This may seem like an obvious statement, but it is
- probably useful to list a few things that were clear in the document,
- but that some implementers didn't do. All of these things caused
- interoperability problems.
-
- o Some implementations continued to send traffic on a CHILD_SA after
- it was rekeyed, even after receiving an DELETE payload.
-
- o After rekeying an IKE_SA, some implementations did not reset their
- message counters to zero. One set the counter to 2, another did
- not reset the counter at all.
-
- o Some implementations could only handle a single pair of traffic
- selectors or would only process the first pair in the proposal.
-
- o Some implementations responded to a delete request by sending an
- empty INFORMATIONAL response and then initiated their own
- INFORMATIONAL exchange with the pair of SAs to delete.
-
- o Although this did not happen at the bakeoff, from the discussion
- there, it is clear that some people had not implemented message
- window sizes correctly. Some implementations might have sent
-
-
-
-
-
-Eronen & Hoffman Informational [Page 50]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- messages that did not fit into the responder's message windows,
- and some implementations may not have torn down an SA if they did
- not ever receive a message that they know they should have.
-
-9. Security Considerations
-
- This document does not introduce any new security considerations to
- IKEv2. If anything, clarifying complex areas of the specification
- can reduce the likelihood of implementation problems that may have
- security implications.
-
-10. Acknowledgments
-
- This document is mainly based on conversations on the IPsec WG
- mailing list. The authors would especially like to thank Bernard
- Aboba, Jari Arkko, Vijay Devarapalli, William Dixon, Francis Dupont,
- Alfred Hoenes, Mika Joutsenvirta, Charlie Kaufman, Stephen Kent, Tero
- Kivinen, Yoav Nir, Michael Richardson, and Joel Snyder for their
- contributions.
-
- In addition, the authors would like to thank all the participants of
- the first public IKEv2 bakeoff, held in Santa Clara in February 2005,
- for their questions and proposed clarifications.
-
-11. References
-
-11.1. Normative References
-
- [IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
- Protocol", RFC 4306, December 2005.
-
- [IKEv2ALG] Schiller, J., "Cryptographic Algorithms for Use in the
- Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
- December 2005.
-
- [PKCS1v20] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
- Specifications Version 2.0", RFC 2437, October 1998.
-
- [PKCS1v21] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
- Standards (PKCS) #1: RSA Cryptography Specifications
- Version 2.1", RFC 3447, February 2003.
-
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
- the Internet Protocol", RFC 2401, November 1998.
-
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
- Internet Protocol", RFC 4301, December 2005.
-
-
-
-
-Eronen & Hoffman Informational [Page 51]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-11.2. Informative References
-
- [Aura05] Aura, T., Roe, M., and A. Mohammed, "Experiences with
- Host-to-Host IPsec", 13th International Workshop on
- Security Protocols, Cambridge, UK, April 2005.
-
- [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
- H. Levkowetz, "Extensible Authentication Protocol
- (EAP)", RFC 3748, June 2004.
-
- [HashUse] Hoffman, P., "Use of Hash Algorithms in IKE and IPsec",
- Work in Progress, July 2006.
-
- [IPCPSubnet] Cisco Systems, Inc., "IPCP Subnet Mask Support
- Enhancements", http://www.cisco.com/univercd/cc/td/
- doc/product/software/ios121/121newft/121limit/121dc/
- 121dc3/ipcp_msk.htm, January 2003.
-
- [IPv6Addr] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 4291, February 2006.
-
- [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility
- Support in IPv6", RFC 3775, June 2004.
-
- [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
- Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
-
- [NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
- Network Access Identifier", RFC 4282, December 2005.
-
- [PKI4IPsec] Korver, B., "Internet PKI Profile of IKEv1/ISAKMP,
- IKEv2, and PKIX", Work in Progress, April 2006.
-
- [RADEAP] Aboba, B. and P. Calhoun, "RADIUS (Remote
- Authentication Dial In User Service) Support For
- Extensible Authentication Protocol (EAP)", RFC 3579,
- September 2003.
-
- [RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
- "Remote Authentication Dial In User Service (RADIUS)",
- RFC 2865, June 2000.
-
- [RADIUS6] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
- RFC 3162, August 2001.
-
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", RFC 2119, March 1997.
-
-
-
-
-Eronen & Hoffman Informational [Page 52]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
- Algorithms", RFC 2451, November 1998.
-
- [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
- April 2001.
-
- [RFC3664] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
- Internet Key Exchange Protocol (IKE)", RFC 3664,
- January 2004.
-
- [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
- M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
- RFC 3948, January 2005.
-
- [RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
- Internet Key Exchange Protocol (IKE)", RFC 4434,
- February 2006.
-
- [RFC822] Crocker, D., "Standard for the format of ARPA Internet
- text messages", RFC 822, August 1982.
-
- [ReAuth] Nir, Y., "Repeated Authentication in Internet Key
- Exchange (IKEv2) Protocol", RFC 4478, April 2006.
-
- [SCVP] Freeman, T., Housley, R., Malpani, A., Cooper, D., and
- T. Polk, "Simple Certificate Validation Protocol
- (SCVP)", Work in Progress, June 2006.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 53]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-Appendix A. Exchanges and Payloads
-
- This appendix contains a short summary of the IKEv2 exchanges, and
- what payloads can appear in which message. This appendix is purely
- informative; if it disagrees with the body of this document or the
- IKEv2 specification, the other text is considered correct.
-
- Vendor-ID (V) payloads may be included in any place in any message.
- This sequence shows what are, in our opinion, the most logical places
- for them.
-
- The specification does not say which messages can contain
- N(SET_WINDOW_SIZE). It can possibly be included in any message, but
- it is not yet shown below.
-
-A.1. IKE_SA_INIT Exchange
-
- request --> [N(COOKIE)],
- SA, KE, Ni,
- [N(NAT_DETECTION_SOURCE_IP)+,
- N(NAT_DETECTION_DESTINATION_IP)],
- [V+]
-
- normal response <-- SA, KE, Nr,
- (no cookie) [N(NAT_DETECTION_SOURCE_IP),
- N(NAT_DETECTION_DESTINATION_IP)],
- [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
- [V+]
-
-A.2. IKE_AUTH Exchange without EAP
-
- request --> IDi, [CERT+],
- [N(INITIAL_CONTACT)],
- [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
- [IDr],
- AUTH,
- [CP(CFG_REQUEST)],
- [N(IPCOMP_SUPPORTED)+],
- [N(USE_TRANSPORT_MODE)],
- [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
- [N(NON_FIRST_FRAGMENTS_ALSO)],
- SA, TSi, TSr,
- [V+]
-
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 54]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
- response <-- IDr, [CERT+],
- AUTH,
- [CP(CFG_REPLY)],
- [N(IPCOMP_SUPPORTED)],
- [N(USE_TRANSPORT_MODE)],
- [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
- [N(NON_FIRST_FRAGMENTS_ALSO)],
- SA, TSi, TSr,
- [N(ADDITIONAL_TS_POSSIBLE)],
- [V+]
-
-A.3. IKE_AUTH Exchange with EAP
-
- first request --> IDi,
- [N(INITIAL_CONTACT)],
- [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
- [IDr],
- [CP(CFG_REQUEST)],
- [N(IPCOMP_SUPPORTED)+],
- [N(USE_TRANSPORT_MODE)],
- [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
- [N(NON_FIRST_FRAGMENTS_ALSO)],
- SA, TSi, TSr,
- [V+]
-
- first response <-- IDr, [CERT+], AUTH,
- EAP,
- [V+]
-
- / --> EAP
- repeat 1..N times |
- \ <-- EAP
-
- last request --> AUTH
-
- last response <-- AUTH,
- [CP(CFG_REPLY)],
- [N(IPCOMP_SUPPORTED)],
- [N(USE_TRANSPORT_MODE)],
- [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
- [N(NON_FIRST_FRAGMENTS_ALSO)],
- SA, TSi, TSr,
- [N(ADDITIONAL_TS_POSSIBLE)],
- [V+]
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 55]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying CHILD_SAs
-
- request --> [N(REKEY_SA)],
- [N(IPCOMP_SUPPORTED)+],
- [N(USE_TRANSPORT_MODE)],
- [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
- [N(NON_FIRST_FRAGMENTS_ALSO)],
- SA, Ni, [KEi], TSi, TSr
-
- response <-- [N(IPCOMP_SUPPORTED)],
- [N(USE_TRANSPORT_MODE)],
- [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
- [N(NON_FIRST_FRAGMENTS_ALSO)],
- SA, Nr, [KEr], TSi, TSr,
- [N(ADDITIONAL_TS_POSSIBLE)]
-
-A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA
-
- request --> SA, Ni, [KEi]
-
- response <-- SA, Nr, [KEr]
-
-A.6. INFORMATIONAL Exchange
-
- request --> [N+],
- [D+],
- [CP(CFG_REQUEST)]
-
- response <-- [N+],
- [D+],
- [CP(CFG_REPLY)]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 56]
-\f
-RFC 4718 IKEv2 Clarifications October 2006
-
-
-Authors' Addresses
-
- Pasi Eronen
- Nokia Research Center
- P.O. Box 407
- FIN-00045 Nokia Group
- Finland
-
- EMail: pasi.eronen@nokia.com
-
-
- Paul Hoffman
- VPN Consortium
- 127 Segre Place
- Santa Cruz, CA 95060
- USA
-
- EMail: paul.hoffman@vpnc.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 57]
-\f
-RFC 4718 IKEv2 Clarifications October 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).
-
-
-
-
-
-
-
-Eronen & Hoffman Informational [Page 58]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
+++ /dev/null
-
-
-
-
-
-
-Internet Engineering Task Force (IETF) C. Kaufman
-Request for Comments: 5996 Microsoft
-Obsoletes: 4306, 4718 P. Hoffman
-Category: Standards Track VPN Consortium
-ISSN: 2070-1721 Y. Nir
- Check Point
- P. Eronen
- Independent
- September 2010
-
-
- Internet Key Exchange Protocol Version 2 (IKEv2)
-
-Abstract
-
- This document describes version 2 of the Internet Key Exchange (IKE)
- protocol. IKE is a component of IPsec used for performing mutual
- authentication and establishing and maintaining Security Associations
- (SAs). This document replaces and updates RFC 4306, and includes all
- of the clarifications from RFC 4718.
-
-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/rfc5996.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 1]
-\f
-RFC 5996 IKEv2bis 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.
-
-Table of Contents
-
- 1. Introduction ....................................................5
- 1.1. Usage Scenarios ............................................6
- 1.1.1. Security Gateway to Security Gateway in
- Tunnel Mode .........................................7
- 1.1.2. Endpoint-to-Endpoint Transport Mode .................7
- 1.1.3. Endpoint to Security Gateway in Tunnel Mode .........8
- 1.1.4. Other Scenarios .....................................9
- 1.2. The Initial Exchanges ......................................9
- 1.3. The CREATE_CHILD_SA Exchange ..............................13
- 1.3.1. Creating New Child SAs with the
- CREATE_CHILD_SA Exchange ...........................14
- 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA
- Exchange ...........................................15
- 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA
- Exchange ...........................................16
- 1.4. The INFORMATIONAL Exchange ................................17
- 1.4.1. Deleting an SA with INFORMATIONAL Exchanges ........17
- 1.5. Informational Messages outside of an IKE SA ...............18
- 1.6. Requirements Terminology ..................................19
-
-
-
-Kaufman, et al. Standards Track [Page 2]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- 1.7. Significant Differences between RFC 4306 and This
- Document ..................................................20
- 2. IKE Protocol Details and Variations ............................22
- 2.1. Use of Retransmission Timers ..............................23
- 2.2. Use of Sequence Numbers for Message ID ....................24
- 2.3. Window Size for Overlapping Requests ......................25
- 2.4. State Synchronization and Connection Timeouts .............26
- 2.5. Version Numbers and Forward Compatibility .................28
- 2.6. IKE SA SPIs and Cookies ...................................30
- 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD .......33
- 2.7. Cryptographic Algorithm Negotiation .......................34
- 2.8. Rekeying ..................................................34
- 2.8.1. Simultaneous Child SA Rekeying .....................36
- 2.8.2. Simultaneous IKE SA Rekeying .......................39
- 2.8.3. Rekeying the IKE SA versus Reauthentication ........40
- 2.9. Traffic Selector Negotiation ..............................40
- 2.9.1. Traffic Selectors Violating Own Policy .............43
- 2.10. Nonces ...................................................44
- 2.11. Address and Port Agility .................................44
- 2.12. Reuse of Diffie-Hellman Exponentials .....................44
- 2.13. Generating Keying Material ...............................45
- 2.14. Generating Keying Material for the IKE SA ................46
- 2.15. Authentication of the IKE SA .............................47
- 2.16. Extensible Authentication Protocol Methods ...............50
- 2.17. Generating Keying Material for Child SAs .................52
- 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange ........53
- 2.19. Requesting an Internal Address on a Remote Network .......53
- 2.20. Requesting the Peer's Version ............................55
- 2.21. Error Handling ...........................................56
- 2.21.1. Error Handling in IKE_SA_INIT .....................56
- 2.21.2. Error Handling in IKE_AUTH ........................57
- 2.21.3. Error Handling after IKE SA is Authenticated ......58
- 2.21.4. Error Handling Outside IKE SA .....................58
- 2.22. IPComp ...................................................59
- 2.23. NAT Traversal ............................................60
- 2.23.1. Transport Mode NAT Traversal ......................64
- 2.24. Explicit Congestion Notification (ECN) ...................68
- 2.25. Exchange Collisions ......................................68
- 2.25.1. Collisions while Rekeying or Closing Child SAs ....69
- 2.25.2. Collisions while Rekeying or Closing IKE SAs ......69
- 3. Header and Payload Formats .....................................69
- 3.1. The IKE Header ............................................70
- 3.2. Generic Payload Header ....................................73
- 3.3. Security Association Payload ..............................75
- 3.3.1. Proposal Substructure ..............................78
- 3.3.2. Transform Substructure .............................79
- 3.3.3. Valid Transform Types by Protocol ..................82
- 3.3.4. Mandatory Transform IDs ............................83
-
-
-
-Kaufman, et al. Standards Track [Page 3]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- 3.3.5. Transform Attributes ...............................84
- 3.3.6. Attribute Negotiation ..............................86
- 3.4. Key Exchange Payload ......................................87
- 3.5. Identification Payloads ...................................87
- 3.6. Certificate Payload .......................................90
- 3.7. Certificate Request Payload ...............................93
- 3.8. Authentication Payload ....................................95
- 3.9. Nonce Payload .............................................96
- 3.10. Notify Payload ...........................................97
- 3.10.1. Notify Message Types ..............................98
- 3.11. Delete Payload ..........................................101
- 3.12. Vendor ID Payload .......................................102
- 3.13. Traffic Selector Payload ................................103
- 3.13.1. Traffic Selector .................................105
- 3.14. Encrypted Payload .......................................107
- 3.15. Configuration Payload ...................................109
- 3.15.1. Configuration Attributes .........................110
- 3.15.2. Meaning of INTERNAL_IP4_SUBNET and
- INTERNAL_IP6_SUBNET ..............................113
- 3.15.3. Configuration Payloads for IPv6 ..................115
- 3.15.4. Address Assignment Failures ......................116
- 3.16. Extensible Authentication Protocol (EAP) Payload ........117
- 4. Conformance Requirements ......................................118
- 5. Security Considerations .......................................120
- 5.1. Traffic Selector Authorization ...........................123
- 6. IANA Considerations ...........................................124
- 7. Acknowledgements ..............................................125
- 8. References ....................................................126
- 8.1. Normative References .....................................126
- 8.2. Informative References ...................................127
- Appendix A. Summary of Changes from IKEv1 ........................132
- Appendix B. Diffie-Hellman Groups ................................133
- B.1. Group 1 - 768-bit MODP ....................................133
- B.2. Group 2 - 1024-bit MODP ...................................133
- Appendix C. Exchanges and Payloads ..............................134
- C.1. IKE_SA_INIT Exchange .....................................134
- C.2. IKE_AUTH Exchange without EAP .............................135
- C.3. IKE_AUTH Exchange with EAP ...............................136
- C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
- Child SAs .................................................137
- C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA ..........137
- C.6. INFORMATIONAL Exchange ....................................137
-
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 4]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-1. Introduction
-
- IP Security (IPsec) provides confidentiality, data integrity, access
- control, and data source authentication to IP datagrams. These
- services are provided by maintaining shared state between the source
- and the sink of an IP datagram. This state defines, among other
- things, the specific services provided to the datagram, which
- cryptographic algorithms will be used to provide the services, and
- the keys used as input to the cryptographic algorithms.
-
- Establishing this shared state in a manual fashion does not scale
- well. Therefore, a protocol to establish this state dynamically is
- needed. This document describes such a protocol -- the Internet Key
- Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI],
- 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs.
- IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif]
- (RFC 4718). This document replaces and updates RFC 4306 and RFC
- 4718. IKEv2 was a change to the IKE protocol that was not backward
- compatible. In contrast, the current document not only provides a
- clarification of IKEv2, but makes minimum changes to the IKE
- protocol. A list of the significant differences between RFC 4306 and
- this document is given in Section 1.7.
-
- IKE performs mutual authentication between two parties and
- establishes an IKE security association (SA) that includes shared
- secret information that can be used to efficiently establish SAs for
- Encapsulating Security Payload (ESP) [ESP] or Authentication Header
- (AH) [AH] and a set of cryptographic algorithms to be used by the SAs
- to protect the traffic that they carry. In this document, the term
- "suite" or "cryptographic suite" refers to a complete set of
- algorithms used to protect an SA. An initiator proposes one or more
- suites by listing supported algorithms that can be combined into
- suites in a mix-and-match fashion. IKE can also negotiate use of IP
- Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA.
- The SAs for ESP or AH that get set up through that IKE SA we call
- "Child SAs".
-
- All IKE communications consist of pairs of messages: a request and a
- response. The pair is called an "exchange", and is sometimes called
- a "request/response pair". The first exchange of messages
- establishing an IKE SA are called the IKE_SA_INIT and IKE_AUTH
- exchanges; subsequent IKE exchanges are called the CREATE_CHILD_SA or
- INFORMATIONAL exchanges. In the common case, there is a single
- IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four
- messages) to establish the IKE SA and the first Child SA. In
- exceptional cases, there may be more than one of each of these
- exchanges. In all cases, all IKE_SA_INIT exchanges MUST complete
- before any other exchange type, then all IKE_AUTH exchanges MUST
-
-
-
-Kaufman, et al. Standards Track [Page 5]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- complete, and following that, any number of CREATE_CHILD_SA and
- INFORMATIONAL exchanges may occur in any order. In some scenarios,
- only a single Child SA is needed between the IPsec endpoints, and
- therefore there would be no additional exchanges. Subsequent
- exchanges MAY be used to establish additional Child SAs between the
- same authenticated pair of endpoints and to perform housekeeping
- functions.
-
- An IKE message flow always consists of a request followed by a
- response. It is the responsibility of the requester to ensure
- reliability. If the response is not received within a timeout
- interval, the requester needs to retransmit the request (or abandon
- the connection).
-
- The first exchange of an IKE session, IKE_SA_INIT, negotiates
- security parameters for the IKE SA, sends nonces, and sends Diffie-
- Hellman values.
-
- The second exchange, IKE_AUTH, transmits identities, proves knowledge
- of the secrets corresponding to the two identities, and sets up an SA
- for the first (and often only) AH or ESP Child SA (unless there is
- failure setting up the AH or ESP Child SA, in which case the IKE SA
- is still established without the Child SA).
-
- The types of subsequent exchanges are CREATE_CHILD_SA (which creates
- a Child SA) and INFORMATIONAL (which deletes an SA, reports error
- conditions, or does other housekeeping). Every request requires a
- response. An INFORMATIONAL request with no payloads (other than the
- empty Encrypted payload required by the syntax) is commonly used as a
- check for liveness. These subsequent exchanges cannot be used until
- the initial exchanges have completed.
-
- In the description that follows, we assume that no errors occur.
- Modifications to the flow when errors occur are described in
- Section 2.21.
-
-1.1. Usage Scenarios
-
- IKE is used to negotiate ESP or AH SAs in a number of different
- scenarios, each with its own special requirements.
-
-
-
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 6]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-1.1.1. Security Gateway to Security Gateway in Tunnel Mode
-
- +-+-+-+-+-+ +-+-+-+-+-+
- | | IPsec | |
- Protected |Tunnel | tunnel |Tunnel | Protected
- Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet
- | | | |
- +-+-+-+-+-+ +-+-+-+-+-+
-
- Figure 1: Security Gateway to Security Gateway Tunnel
-
- In this scenario, neither endpoint of the IP connection implements
- IPsec, but network nodes between them protect traffic for part of the
- way. Protection is transparent to the endpoints, and depends on
- ordinary routing to send packets through the tunnel endpoints for
- processing. Each endpoint would announce the set of addresses
- "behind" it, and packets would be sent in tunnel mode where the inner
- IP header would contain the IP addresses of the actual endpoints.
-
-1.1.2. Endpoint-to-Endpoint Transport Mode
-
- +-+-+-+-+-+ +-+-+-+-+-+
- | | IPsec transport | |
- |Protected| or tunnel mode SA |Protected|
- |Endpoint |<---------------------------------------->|Endpoint |
- | | | |
- +-+-+-+-+-+ +-+-+-+-+-+
-
- Figure 2: Endpoint to Endpoint
-
- In this scenario, both endpoints of the IP connection implement
- IPsec, as required of hosts in [IPSECARCH]. Transport mode will
- commonly be used with no inner IP header. A single pair of addresses
- will be negotiated for packets to be protected by this SA. These
- endpoints MAY implement application-layer access controls based on
- the IPsec authenticated identities of the participants. This
- scenario enables the end-to-end security that has been a guiding
- principle for the Internet since [ARCHPRINC], [TRANSPARENCY], and a
- method of limiting the inherent problems with complexity in networks
- noted by [ARCHGUIDEPHIL]. Although this scenario may not be fully
- applicable to the IPv4 Internet, it has been deployed successfully in
- specific scenarios within intranets using IKEv1. It should be more
- broadly enabled during the transition to IPv6 and with the adoption
- of IKEv2.
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 7]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- It is possible in this scenario that one or both of the protected
- endpoints will be behind a network address translation (NAT) node, in
- which case the tunneled packets will have to be UDP encapsulated so
- that port numbers in the UDP headers can be used to identify
- individual endpoints "behind" the NAT (see Section 2.23).
-
-1.1.3. Endpoint to Security Gateway in Tunnel Mode
-
- +-+-+-+-+-+ +-+-+-+-+-+
- | | IPsec | | Protected
- |Protected| tunnel |Tunnel | Subnet
- |Endpoint |<------------------------>|Endpoint |<--- and/or
- | | | | Internet
- +-+-+-+-+-+ +-+-+-+-+-+
-
- Figure 3: Endpoint to Security Gateway Tunnel
-
- In this scenario, a protected endpoint (typically a portable roaming
- computer) connects back to its corporate network through an IPsec-
- protected tunnel. It might use this tunnel only to access
- information on the corporate network, or it might tunnel all of its
- traffic back through the corporate network in order to take advantage
- of protection provided by a corporate firewall against Internet-based
- attacks. In either case, the protected endpoint will want an IP
- address associated with the security gateway so that packets returned
- to it will go to the security gateway and be tunneled back. This IP
- address may be static or may be dynamically allocated by the security
- gateway. In support of the latter case, IKEv2 includes a mechanism
- (namely, configuration payloads) for the initiator to request an IP
- address owned by the security gateway for use for the duration of its
- SA.
-
- In this scenario, packets will use tunnel mode. On each packet from
- the protected endpoint, the outer IP header will contain the source
- IP address associated with its current location (i.e., the address
- that will get traffic routed to the endpoint directly), while the
- inner IP header will contain the source IP address assigned by the
- security gateway (i.e., the address that will get traffic routed to
- the security gateway for forwarding to the endpoint). The outer
- destination address will always be that of the security gateway,
- while the inner destination address will be the ultimate destination
- for the packet.
-
- In this scenario, it is possible that the protected endpoint will be
- behind a NAT. In that case, the IP address as seen by the security
- gateway will not be the same as the IP address sent by the protected
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 8]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- endpoint, and packets will have to be UDP encapsulated in order to be
- routed properly. Interaction with NATs is covered in detail in
- Section 2.23.
-
-1.1.4. Other Scenarios
-
- Other scenarios are possible, as are nested combinations of the
- above. One notable example combines aspects of Sections 1.1.1 and
- 1.1.3. A subnet may make all external accesses through a remote
- security gateway using an IPsec tunnel, where the addresses on the
- subnet are routed to the security gateway by the rest of the
- Internet. An example would be someone's home network being virtually
- on the Internet with static IP addresses even though connectivity is
- provided by an ISP that assigns a single dynamically assigned IP
- address to the user's security gateway (where the static IP addresses
- and an IPsec relay are provided by a third party located elsewhere).
-
-1.2. The Initial Exchanges
-
- Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
- exchanges (known in IKEv1 as Phase 1). These initial exchanges
- normally consist of four messages, though in some scenarios that
- number can grow. All communications using IKE consist of request/
- response pairs. We'll describe the base exchange first, followed by
- variations. The first pair of messages (IKE_SA_INIT) negotiate
- cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
- exchange [DH].
-
- The second pair of messages (IKE_AUTH) authenticate the previous
- messages, exchange identities and certificates, and establish the
- first Child SA. Parts of these messages are encrypted and integrity
- protected with keys established through the IKE_SA_INIT exchange, so
- the identities are hidden from eavesdroppers and all fields in all
- the messages are authenticated. See Section 2.14 for information on
- how the encryption keys are generated. (A man-in-the-middle attacker
- who cannot complete the IKE_AUTH exchange can nonetheless see the
- identity of the initiator.)
-
- All messages following the initial exchange are cryptographically
- protected using the cryptographic algorithms and keys negotiated in
- the IKE_SA_INIT exchange. These subsequent messages use the syntax
- of the Encrypted payload described in Section 3.14, encrypted with
- keys that are derived as described in Section 2.14. All subsequent
- messages include an Encrypted payload, even if they are referred to
- in the text as "empty". For the CREATE_CHILD_SA, IKE_AUTH, or
- INFORMATIONAL exchanges, the message following the header is
- encrypted and the message including the header is integrity protected
- using the cryptographic algorithms negotiated for the IKE SA.
-
-
-
-Kaufman, et al. Standards Track [Page 9]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Every IKE message contains a Message ID as part of its fixed header.
- This Message ID is used to match up requests and responses, and to
- identify retransmissions of messages.
-
- In the following descriptions, the payloads contained in the message
- are indicated by names as listed below.
-
- Notation Payload
- -----------------------------------------
- AUTH Authentication
- CERT Certificate
- CERTREQ Certificate Request
- CP Configuration
- D Delete
- EAP Extensible Authentication
- HDR IKE header (not a payload)
- IDi Identification - Initiator
- IDr Identification - Responder
- KE Key Exchange
- Ni, Nr Nonce
- N Notify
- SA Security Association
- SK Encrypted and Authenticated
- TSi Traffic Selector - Initiator
- TSr Traffic Selector - Responder
- V Vendor ID
-
- The details of the contents of each payload are described in section
- 3. Payloads that may optionally appear will be shown in brackets,
- such as [CERTREQ]; this indicates that a Certificate Request payload
- can optionally be included.
-
- The initial exchanges are as follows:
-
- Initiator Responder
- -------------------------------------------------------------------
- HDR, SAi1, KEi, Ni -->
-
- HDR contains the Security Parameter Indexes (SPIs), version numbers,
- and flags of various sorts. The SAi1 payload states the
- cryptographic algorithms the initiator supports for the IKE SA. The
- KE payload sends the initiator's Diffie-Hellman value. Ni is the
- initiator's nonce.
-
- <-- HDR, SAr1, KEr, Nr, [CERTREQ]
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 10]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- The responder chooses a cryptographic suite from the initiator's
- offered choices and expresses that choice in the SAr1 payload,
- completes the Diffie-Hellman exchange with the KEr payload, and sends
- its nonce in the Nr payload.
-
- At this point in the negotiation, each party can generate SKEYSEED,
- from which all keys are derived for that IKE SA. The messages that
- follow are encrypted and integrity protected in their entirety, with
- the exception of the message headers. The keys used for the
- encryption and integrity protection are derived from SKEYSEED and are
- known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity
- protection); see Sections 2.13 and 2.14 for details on the key
- derivation. A separate SK_e and SK_a is computed for each direction.
- In addition to the keys SK_e and SK_a derived from the Diffie-Hellman
- value for protection of the IKE SA, another quantity SK_d is derived
- and used for derivation of further keying material for Child SAs.
- The notation SK { ... } indicates that these payloads are encrypted
- and integrity protected using that direction's SK_e and SK_a.
-
- HDR, SK {IDi, [CERT,] [CERTREQ,]
- [IDr,] AUTH, SAi2,
- TSi, TSr} -->
-
- The initiator asserts its identity with the IDi payload, proves
- knowledge of the secret corresponding to IDi and integrity protects
- the contents of the first message using the AUTH payload (see
- Section 2.15). It might also send its certificate(s) in CERT
- payload(s) and a list of its trust anchors in CERTREQ payload(s). If
- any CERT payloads are included, the first certificate provided MUST
- contain the public key used to verify the AUTH field.
-
- The optional payload IDr enables the initiator to specify to which of
- the responder's identities it wants to talk. This is useful when the
- machine on which the responder is running is hosting multiple
- identities at the same IP address. If the IDr proposed by the
- initiator is not acceptable to the responder, the responder might use
- some other IDr to finish the exchange. If the initiator then does
- not accept the fact that responder used an IDr different than the one
- that was requested, the initiator can close the SA after noticing the
- fact.
-
- The Traffic Selectors (TSi and TSr) are discussed in Section 2.9.
-
- The initiator begins negotiation of a Child SA using the SAi2
- payload. The final fields (starting with SAi2) are described in the
- description of the CREATE_CHILD_SA exchange.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 11]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- <-- HDR, SK {IDr, [CERT,] AUTH,
- SAr2, TSi, TSr}
-
- The responder asserts its identity with the IDr payload, optionally
- sends one or more certificates (again with the certificate containing
- the public key used to verify AUTH listed first), authenticates its
- identity and protects the integrity of the second message with the
- AUTH payload, and completes negotiation of a Child SA with the
- additional fields described below in the CREATE_CHILD_SA exchange.
-
- Both parties in the IKE_AUTH exchange MUST verify that all signatures
- and Message Authentication Codes (MACs) are computed correctly. If
- either side uses a shared secret for authentication, the names in the
- ID payload MUST correspond to the key used to generate the AUTH
- payload.
-
- Because the initiator sends its Diffie-Hellman value in the
- IKE_SA_INIT, it must guess the Diffie-Hellman group that the
- responder will select from its list of supported groups. If the
- initiator guesses wrong, the responder will respond with a Notify
- payload of type INVALID_KE_PAYLOAD indicating the selected group. In
- this case, the initiator MUST retry the IKE_SA_INIT with the
- corrected Diffie-Hellman group. The initiator MUST again propose its
- full set of acceptable cryptographic suites because the rejection
- message was unauthenticated and otherwise an active attacker could
- trick the endpoints into negotiating a weaker suite than a stronger
- one that they both prefer.
-
- If creating the Child SA during the IKE_AUTH exchange fails for some
- reason, the IKE SA is still created as usual. The list of Notify
- message types in the IKE_AUTH exchange that do not prevent an IKE SA
- from being set up include at least the following: NO_PROPOSAL_CHOSEN,
- TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and
- FAILED_CP_REQUIRED.
-
- If the failure is related to creating the IKE SA (for example, an
- AUTHENTICATION_FAILED Notify error message is returned), the IKE SA
- is not created. Note that although the IKE_AUTH messages are
- encrypted and integrity protected, if the peer receiving this Notify
- error message has not yet authenticated the other end (or if the peer
- fails to authenticate the other end for some reason), the information
- needs to be treated with caution. More precisely, assuming that the
- MAC verifies correctly, the sender of the error Notify message is
- known to be the responder of the IKE_SA_INIT exchange, but the
- sender's identity cannot be assured.
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 12]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads.
- Thus, the SA payloads in the IKE_AUTH exchange cannot contain
- Transform Type 4 (Diffie-Hellman group) with any value other than
- NONE. Implementations SHOULD omit the whole transform substructure
- instead of sending value NONE.
-
-1.3. The CREATE_CHILD_SA Exchange
-
- The CREATE_CHILD_SA exchange is used to create new Child SAs and to
- rekey both IKE SAs and Child SAs. This exchange consists of a single
- request/response pair, and some of its function was referred to as a
- Phase 2 exchange in IKEv1. It MAY be initiated by either end of the
- IKE SA after the initial exchanges are completed.
-
- An SA is rekeyed by creating a new SA and then deleting the old one.
- This section describes the first part of rekeying, the creation of
- new SAs; Section 2.8 covers the mechanics of rekeying, including
- moving traffic from old to new SAs and the deletion of the old SAs.
- The two sections must be read together to understand the entire
- process of rekeying.
-
- Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
- section the term initiator refers to the endpoint initiating this
- exchange. An implementation MAY refuse all CREATE_CHILD_SA requests
- within an IKE SA.
-
- The CREATE_CHILD_SA request MAY optionally contain a KE payload for
- an additional Diffie-Hellman exchange to enable stronger guarantees
- of forward secrecy for the Child SA. The keying material for the
- Child SA is a function of SK_d established during the establishment
- of the IKE SA, the nonces exchanged during the CREATE_CHILD_SA
- exchange, and the Diffie-Hellman value (if KE payloads are included
- in the CREATE_CHILD_SA exchange).
-
- If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of
- the SA offers MUST include the Diffie-Hellman group of the KEi. The
- Diffie-Hellman group of the KEi MUST be an element of the group the
- initiator expects the responder to accept (additional Diffie-Hellman
- groups can be proposed). If the responder selects a proposal using a
- different Diffie-Hellman group (other than NONE), the responder MUST
- reject the request and indicate its preferred Diffie-Hellman group in
- the INVALID_KE_PAYLOAD Notify payload. There are two octets of data
- associated with this notification: the accepted Diffie-Hellman group
- number in big endian order. In the case of such a rejection, the
- CREATE_CHILD_SA exchange fails, and the initiator will probably retry
- the exchange with a Diffie-Hellman proposal and KEi in the group that
- the responder gave in the INVALID_KE_PAYLOAD Notify payload.
-
-
-
-
-Kaufman, et al. Standards Track [Page 13]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- The responder sends a NO_ADDITIONAL_SAS notification to indicate that
- a CREATE_CHILD_SA request is unacceptable because the responder is
- unwilling to accept any more Child SAs on this IKE SA. This
- notification can also be used to reject IKE SA rekey. Some minimal
- implementations may only accept a single Child SA setup in the
- context of an initial IKE exchange and reject any subsequent attempts
- to add more.
-
-1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange
-
- A Child SA may be created by sending a CREATE_CHILD_SA request. The
- CREATE_CHILD_SA request for creating a new Child SA is:
-
- Initiator Responder
- -------------------------------------------------------------------
- HDR, SK {SA, Ni, [KEi],
- TSi, TSr} -->
-
- The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
- payload, optionally a Diffie-Hellman value in the KEi payload, and
- the proposed Traffic Selectors for the proposed Child SA in the TSi
- and TSr payloads.
-
- The CREATE_CHILD_SA response for creating a new Child SA is:
-
- <-- HDR, SK {SA, Nr, [KEr],
- TSi, TSr}
-
- The responder replies (using the same Message ID to respond) with the
- accepted offer in an SA payload, and a Diffie-Hellman value in the
- KEr payload if KEi was included in the request and the selected
- cryptographic suite includes that group.
-
- The Traffic Selectors for traffic to be sent on that SA are specified
- in the TS payloads in the response, which may be a subset of what the
- initiator of the Child SA proposed.
-
- The USE_TRANSPORT_MODE notification MAY be included in a request
- message that also includes an SA payload requesting a Child SA. It
- requests that the Child SA use transport mode rather than tunnel mode
- for the SA created. If the request is accepted, the response MUST
- also include a notification of type USE_TRANSPORT_MODE. If the
- responder declines the request, the Child SA will be established in
- tunnel mode. If this is unacceptable to the initiator, the initiator
- MUST delete the SA. Note: Except when using this option to negotiate
- transport mode, all Child SAs will use tunnel mode.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 14]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- The ESP_TFC_PADDING_NOT_SUPPORTED notification asserts that the
- sending endpoint will not accept packets that contain Traffic Flow
- Confidentiality (TFC) padding over the Child SA being negotiated. If
- neither endpoint accepts TFC padding, this notification is included
- in both the request and the response. If this notification is
- included in only one of the messages, TFC padding can still be sent
- in the other direction.
-
- The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation
- control. See [IPSECARCH] for a fuller explanation. Both parties
- need to agree to sending non-first fragments before either party does
- so. It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is
- included in both the request proposing an SA and the response
- accepting it. If the responder does not want to send or receive non-
- first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification
- from its response, but does not reject the whole Child SA creation.
-
- An IPCOMP_SUPPORTED notification, covered in Section 2.22, can also
- be included in the exchange.
-
- A failed attempt to create a Child SA SHOULD NOT tear down the IKE
- SA: there is no reason to lose the work done to set up the IKE SA.
- See Section 2.21 for a list of error messages that might occur if
- creating a Child SA fails.
-
-1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange
-
- The CREATE_CHILD_SA request for rekeying an IKE SA is:
-
- Initiator Responder
- -------------------------------------------------------------------
- HDR, SK {SA, Ni, KEi} -->
-
- The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
- payload, and a Diffie-Hellman value in the KEi payload. The KEi
- payload MUST be included. A new initiator SPI is supplied in the SPI
- field of the SA payload. Once a peer receives a request to rekey an
- IKE SA or sends a request to rekey an IKE SA, it SHOULD NOT start any
- new CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed.
-
- The CREATE_CHILD_SA response for rekeying an IKE SA is:
-
- <-- HDR, SK {SA, Nr, KEr}
-
- The responder replies (using the same Message ID to respond) with the
- accepted offer in an SA payload, and a Diffie-Hellman value in the
- KEr payload if the selected cryptographic suite includes that group.
- A new responder SPI is supplied in the SPI field of the SA payload.
-
-
-
-Kaufman, et al. Standards Track [Page 15]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- The new IKE SA has its message counters set to 0, regardless of what
- they were in the earlier IKE SA. The first IKE requests from both
- sides on the new IKE SA will have Message ID 0. The old IKE SA
- retains its numbering, so any further requests (for example, to
- delete the IKE SA) will have consecutive numbering. The new IKE SA
- also has its window size reset to 1, and the initiator in this rekey
- exchange is the new "original initiator" of the new IKE SA.
-
- Section 2.18 also covers IKE SA rekeying in detail.
-
-1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange
-
- The CREATE_CHILD_SA request for rekeying a Child SA is:
-
- Initiator Responder
- -------------------------------------------------------------------
- HDR, SK {N(REKEY_SA), SA, Ni, [KEi],
- TSi, TSr} -->
-
- The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
- payload, optionally a Diffie-Hellman value in the KEi payload, and
- the proposed Traffic Selectors for the proposed Child SA in the TSi
- and TSr payloads.
-
- The notifications described in Section 1.3.1 may also be sent in a
- rekeying exchange. Usually, these will be the same notifications
- that were used in the original exchange; for example, when rekeying a
- transport mode SA, the USE_TRANSPORT_MODE notification will be used.
-
- The REKEY_SA notification MUST be included in a CREATE_CHILD_SA
- exchange if the purpose of the exchange is to replace an existing ESP
- or AH SA. The SA being rekeyed is identified by the SPI field in the
- Notify payload; this is the SPI the exchange initiator would expect
- in inbound ESP or AH packets. There is no data associated with this
- Notify message type. The Protocol ID field of the REKEY_SA
- notification is set to match the protocol of the SA we are rekeying,
- for example, 3 for ESP and 2 for AH.
-
- The CREATE_CHILD_SA response for rekeying a Child SA is:
-
- <-- HDR, SK {SA, Nr, [KEr],
- TSi, TSr}
-
- The responder replies (using the same Message ID to respond) with the
- accepted offer in an SA payload, and a Diffie-Hellman value in the
- KEr payload if KEi was included in the request and the selected
- cryptographic suite includes that group.
-
-
-
-
-Kaufman, et al. Standards Track [Page 16]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- The Traffic Selectors for traffic to be sent on that SA are specified
- in the TS payloads in the response, which may be a subset of what the
- initiator of the Child SA proposed.
-
-1.4. The INFORMATIONAL Exchange
-
- At various points during the operation of an IKE SA, peers may desire
- to convey control messages to each other regarding errors or
- notifications of certain events. To accomplish this, IKE defines an
- INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur
- after the initial exchanges and are cryptographically protected with
- the negotiated keys. Note that some informational messages, not
- exchanges, can be sent outside the context of an IKE SA. Section
- 2.21 also covers error messages in great detail.
-
- Control messages that pertain to an IKE SA MUST be sent under that
- IKE SA. Control messages that pertain to Child SAs MUST be sent
- under the protection of the IKE SA that generated them (or its
- successor if the IKE SA was rekeyed).
-
- Messages in an INFORMATIONAL exchange contain zero or more
- Notification, Delete, and Configuration payloads. The recipient of
- an INFORMATIONAL exchange request MUST send some response; otherwise,
- the sender will assume the message was lost in the network and will
- retransmit it. That response MAY be an empty message. The request
- message in an INFORMATIONAL exchange MAY also contain no payloads.
- This is the expected way an endpoint can ask the other endpoint to
- verify that it is alive.
-
- The INFORMATIONAL exchange is defined as:
-
- Initiator Responder
- -------------------------------------------------------------------
- HDR, SK {[N,] [D,]
- [CP,] ...} -->
- <-- HDR, SK {[N,] [D,]
- [CP], ...}
-
- The processing of an INFORMATIONAL exchange is determined by its
- component payloads.
-
-1.4.1. Deleting an SA with INFORMATIONAL Exchanges
-
- ESP and AH SAs always exist in pairs, with one SA in each direction.
- When an SA is closed, both members of the pair MUST be closed (that
- is, deleted). Each endpoint MUST close its incoming SAs and allow
- the other endpoint to close the other SA in each pair. To delete an
- SA, an INFORMATIONAL exchange with one or more Delete payloads is
-
-
-
-Kaufman, et al. Standards Track [Page 17]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- sent listing the SPIs (as they would be expected in the headers of
- inbound packets) of the SAs to be deleted. The recipient MUST close
- the designated SAs. Note that one never sends Delete payloads for
- the two sides of an SA in a single message. If there are many SAs to
- delete at the same time, one includes Delete payloads for the inbound
- half of each SA pair in the INFORMATIONAL exchange.
-
- Normally, the response in the INFORMATIONAL exchange will contain
- Delete payloads for the paired SAs going in the other direction.
- There is one exception. If, by chance, both ends of a set of SAs
- independently decide to close them, each may send a Delete payload
- and the two requests may cross in the network. If a node receives a
- delete request for SAs for which it has already issued a delete
- request, it MUST delete the outgoing SAs while processing the request
- and the incoming SAs while processing the response. In that case,
- the responses MUST NOT include Delete payloads for the deleted SAs,
- since that would result in duplicate deletion and could in theory
- delete the wrong SA.
-
- Similar to ESP and AH SAs, IKE SAs are also deleted by sending an
- Informational exchange. Deleting an IKE SA implicitly closes any
- remaining Child SAs negotiated under it. The response to a request
- that deletes the IKE SA is an empty INFORMATIONAL response.
-
- Half-closed ESP or AH connections are anomalous, and a node with
- auditing capability should probably audit their existence if they
- persist. Note that this specification does not specify time periods,
- so it is up to individual endpoints to decide how long to wait. A
- node MAY refuse to accept incoming data on half-closed connections
- but MUST NOT unilaterally close them and reuse the SPIs. If
- connection state becomes sufficiently messed up, a node MAY close the
- IKE SA, as described above. It can then rebuild the SAs it needs on
- a clean base under a new IKE SA.
-
-1.5. Informational Messages outside of an IKE SA
-
- There are some cases in which a node receives a packet that it cannot
- process, but it may want to notify the sender about this situation.
-
- o If an ESP or AH packet arrives with an unrecognized SPI. This
- might be due to the receiving node having recently crashed and
- lost state, or because of some other system malfunction or attack.
-
- o If an encrypted IKE request packet arrives on port 500 or 4500
- with an unrecognized IKE SPI. This might be due to the receiving
- node having recently crashed and lost state, or because of some
- other system malfunction or attack.
-
-
-
-
-Kaufman, et al. Standards Track [Page 18]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- o If an IKE request packet arrives with a higher major version
- number than the implementation supports.
-
- In the first case, if the receiving node has an active IKE SA to the
- IP address from whence the packet came, it MAY send an INVALID_SPI
- notification of the wayward packet over that IKE SA in an
- INFORMATIONAL exchange. The Notification Data contains the SPI of
- the invalid packet. The recipient of this notification cannot tell
- whether the SPI is for AH or ESP, but this is not important because
- the SPIs are supposed to be different for the two. If no suitable
- IKE SA exists, the node MAY send an informational message without
- cryptographic protection to the source IP address, using the source
- UDP port as the destination port if the packet was UDP (UDP-
- encapsulated ESP or AH). In this case, it should only be used by the
- recipient as a hint that something might be wrong (because it could
- easily be forged). This message is not part of an INFORMATIONAL
- exchange, and the receiving node MUST NOT respond to it because doing
- so could cause a message loop. The message is constructed as
- follows: there are no IKE SPI values that would be meaningful to the
- recipient of such a notification; using zero values or random values
- are both acceptable, this being the exception to the rule in
- Section 3.1 that prohibits zero IKE Initiator SPIs. The Initiator
- flag is set to 1, the Response flag is set to 0, and the version
- flags are set in the normal fashion; these flags are described in
- Section 3.1.
-
- In the second and third cases, the message is always sent without
- cryptographic protection (outside of an IKE SA), and includes either
- an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no
- notification data). The message is a response message, and thus it
- is sent to the IP address and port from whence it came with the same
- IKE SPIs and the Message ID and Exchange Type are copied from the
- request. The Response flag is set to 1, and the version flags are
- set in the normal fashion.
-
-1.6. Requirements Terminology
-
- Definitions of the primitive terms in this document (such as Security
- Association or SA) can be found in [IPSECARCH]. It should be noted
- that parts of IKEv2 rely on some of the processing rules in
- [IPSECARCH], as described in various sections of 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 [MUSTSHOULD].
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 19]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-1.7. Significant Differences between RFC 4306 and This Document
-
- This document contains clarifications and amplifications to IKEv2
- [IKEV2]. Many of the clarifications are based on [Clarif]. The
- changes listed in that document were discussed in the IPsec Working
- Group and, after the Working Group was disbanded, on the IPsec
- mailing list. That document contains detailed explanations of areas
- that were unclear in IKEv2, and is thus useful to implementers of
- IKEv2.
-
- The protocol described in this document retains the same major
- version number (2) and minor version number (0) as was used in RFC
- 4306. That is, the version number is *not* changed from RFC 4306.
- The small number of technical changes listed here are not expected to
- affect RFC 4306 implementations that have already been deployed at
- the time of publication of this document.
-
- This document makes the figures and references a bit more consistent
- than they were in [IKEV2].
-
- IKEv2 developers have noted that the SHOULD-level requirements in RFC
- 4306 are often unclear in that they don't say when it is OK to not
- obey the requirements. They also have noted that there are MUST-
- level requirements that are not related to interoperability. This
- document has more explanation of some of these requirements. All
- non-capitalized uses of the words SHOULD and MUST now mean their
- normal English sense, not the interoperability sense of [MUSTSHOULD].
-
- IKEv2 (and IKEv1) developers have noted that there is a great deal of
- material in the tables of codes in Section 3.10.1 in RFC 4306. This
- leads to implementers not having all the needed information in the
- main body of the document. Much of the material from those tables
- has been moved into the associated parts of the main body of the
- document.
-
- This document removes discussion of nesting AH and ESP. This was a
- mistake in RFC 4306 caused by the lag between finishing RFC 4306 and
- RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not
- include "SA bundles" that were part of RFC 2401. While a single
- packet can go through IPsec processing multiple times, each of these
- passes uses a separate SA, and the passes are coordinated by the
- forwarding tables. In IKEv2, each of these SAs has to be created
- using a separate CREATE_CHILD_SA exchange.
-
- This document removes discussion of the INTERNAL_ADDRESS_EXPIRY
- configuration attribute because its implementation was very
- problematic. Implementations that conform to this document MUST
-
-
-
-
-Kaufman, et al. Standards Track [Page 20]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- ignore proposals that have configuration attribute type 5, the old
- value for INTERNAL_ADDRESS_EXPIRY. This document also removed
- INTERNAL_IP6_NBNS as a configuration attribute.
-
- This document removes the allowance for rejecting messages in which
- the payloads were not in the "right" order; now implementations MUST
- NOT reject them. This is due to the lack of clarity where the orders
- for the payloads are described.
-
- The lists of items from RFC 4306 that ended up in the IANA registry
- were trimmed to only include items that were actually defined in RFC
- 4306. Also, many of those lists are now preceded with the very
- important instruction to developers that they really should look at
- the IANA registry at the time of development because new items have
- been added since RFC 4306.
-
- This document adds clarification on when notifications are and are
- not sent encrypted, depending on the state of the negotiation at the
- time.
-
- This document discusses more about how to negotiate combined-mode
- ciphers.
-
- In Section 1.3.2, "The KEi payload SHOULD be included" was changed to
- be "The KEi payload MUST be included". This also led to changes in
- Section 2.18.
-
- In Section 2.1, there is new material covering how the initiator's
- SPI and/or IP is used to differentiate if this is a "half-open" IKE
- SA or a new request.
-
- This document clarifies the use of the critical flag in Section 2.5.
-
- In Section 2.8, "Note that, when rekeying, the new Child SA MAY have
- different Traffic Selectors and algorithms than the old one" was
- changed to "Note that, when rekeying, the new Child SA SHOULD NOT
- have different Traffic Selectors and algorithms than the old one".
-
- The new Section 2.8.2 covers simultaneous IKE SA rekeying.
-
- The new Section 2.9.2 covers Traffic Selectors in rekeying.
-
- This document adds the restriction in Section 2.13 that all
- pseudorandom functions (PRFs) used with IKEv2 MUST take variable-
- sized keys. This should not affect any implementations because there
- were no standardized PRFs that have fixed-size keys.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 21]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Section 2.18 requires doing a Diffie-Hellman exchange when rekeying
- the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie-
- Hellman exchange was optional, but this was not useful (or
- appropriate) when rekeying the IKE_SA.
-
- Section 2.21 has been greatly expanded to cover the different cases
- where error responses are needed and the appropriate responses to
- them.
-
- Section 2.23 clarified that, in NAT traversal, now both UDP-
- encapsulated IPsec packets and non-UDP-encapsulated IPsec packets
- need to be understood when receiving.
-
- Added Section 2.23.1 to describe NAT traversal when transport mode is
- requested.
-
- Added Section 2.25 to explain how to act when there are timing
- collisions when deleting and/or rekeying SAs, and two new error
- notifications (TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND) were
- defined.
-
- In Section 3.6, "Implementations MUST support the HTTP method for
- hash-and-URL lookup. The behavior of other URL methods is not
- currently specified, and such methods SHOULD NOT be used in the
- absence of a document specifying them" was added.
-
- In Section 3.15.3, a pointer to a new document that is related to
- configuration of IPv6 addresses was added.
-
- Appendix C was expanded and clarified.
-
-2. IKE Protocol Details and Variations
-
- IKE normally listens and sends on UDP port 500, though IKE messages
- may also be received on UDP port 4500 with a slightly different
- format (see Section 2.23). Since UDP is a datagram (unreliable)
- protocol, IKE includes in its definition recovery from transmission
- errors, including packet loss, packet replay, and packet forgery.
- IKE is designed to function so long as (1) at least one of a series
- of retransmitted packets reaches its destination before timing out;
- and (2) the channel is not so full of forged and replayed packets so
- as to exhaust the network or CPU capacities of either endpoint. Even
- in the absence of those minimum performance requirements, IKE is
- designed to fail cleanly (as though the network were broken).
-
- Although IKEv2 messages are intended to be short, they contain
- structures with no hard upper bound on size (in particular, digital
- certificates), and IKEv2 itself does not have a mechanism for
-
-
-
-Kaufman, et al. Standards Track [Page 22]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- fragmenting large messages. IP defines a mechanism for fragmentation
- of oversized UDP messages, but implementations vary in the maximum
- message size supported. Furthermore, use of IP fragmentation opens
- an implementation to denial-of-service (DoS) attacks [DOSUDPPROT].
- Finally, some NAT and/or firewall implementations may block IP
- fragments.
-
- All IKEv2 implementations MUST be able to send, receive, and process
- IKE messages that are up to 1280 octets long, and they SHOULD be able
- to send, receive, and process messages that are up to 3000 octets
- long. IKEv2 implementations need to be aware of the maximum UDP
- message size supported and MAY shorten messages by leaving out some
- certificates or cryptographic suite proposals if that will keep
- messages below the maximum. Use of the "Hash and URL" formats rather
- than including certificates in exchanges where possible can avoid
- most problems. Implementations and configuration need to keep in
- mind, however, that if the URL lookups are possible only after the
- Child SA is established, recursion issues could prevent this
- technique from working.
-
- The UDP payload of all packets containing IKE messages sent on port
- 4500 MUST begin with the prefix of four zeros; otherwise, the
- receiver won't know how to handle them.
-
-2.1. Use of Retransmission Timers
-
- All messages in IKE exist in pairs: a request and a response. The
- setup of an IKE SA normally consists of two exchanges. Once the IKE
- SA is set up, either end of the Security Association may initiate
- requests at any time, and there can be many requests and responses
- "in flight" at any given moment. But each message is labeled as
- either a request or a response, and for each exchange, one end of the
- Security Association is the initiator and the other is the responder.
-
- For every pair of IKE messages, the initiator is responsible for
- retransmission in the event of a timeout. The responder MUST never
- retransmit a response unless it receives a retransmission of the
- request. In that event, the responder MUST ignore the retransmitted
- request except insofar as it causes a retransmission of the response.
- The initiator MUST remember each request until it receives the
- corresponding response. The responder MUST remember each response
- until it receives a request whose sequence number is larger than or
- equal to the sequence number in the response plus its window size
- (see Section 2.3). In order to allow saving memory, responders are
- allowed to forget the response after a timeout of several minutes.
- If the responder receives a retransmitted request for which it has
- already forgotten the response, it MUST ignore the request (and not,
- for example, attempt constructing a new response).
-
-
-
-Kaufman, et al. Standards Track [Page 23]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- IKE is a reliable protocol: the initiator MUST retransmit a request
- until it either receives a corresponding response or deems the IKE SA
- to have failed. In the latter case, the initiator discards all state
- associated with the IKE SA and any Child SAs that were negotiated
- using that IKE SA. A retransmission from the initiator MUST be
- bitwise identical to the original request. That is, everything
- starting from the IKE header (the IKE SA initiator's SPI onwards)
- must be bitwise identical; items before it (such as the IP and UDP
- headers) do not have to be identical.
-
- Retransmissions of the IKE_SA_INIT request require some special
- handling. When a responder receives an IKE_SA_INIT request, it has
- to determine whether the packet is a retransmission belonging to an
- existing "half-open" IKE SA (in which case the responder retransmits
- the same response), or a new request (in which case the responder
- creates a new IKE SA and sends a fresh response), or it belongs to an
- existing IKE SA where the IKE_AUTH request has been already received
- (in which case the responder ignores it).
-
- It is not sufficient to use the initiator's SPI and/or IP address to
- differentiate between these three cases because two different peers
- behind a single NAT could choose the same initiator SPI. Instead, a
- robust responder will do the IKE SA lookup using the whole packet,
- its hash, or the Ni payload.
-
- The retransmission policy for one-way messages is somewhat different
- from that for regular messages. Because no acknowledgement is ever
- sent, there is no reason to gratuitously retransmit one-way messages.
- Given that all these messages are errors, it makes sense to send them
- only once per "offending" packet, and only retransmit if further
- offending packets are received. Still, it also makes sense to limit
- retransmissions of such error messages.
-
-2.2. Use of Sequence Numbers for Message ID
-
- Every IKE message contains a Message ID as part of its fixed header.
- This Message ID is used to match up requests and responses and to
- identify retransmissions of messages. Retransmission of a message
- MUST use the same Message ID as the original message.
-
- The Message ID is a 32-bit quantity, which is zero for the
- IKE_SA_INIT messages (including retries of the message due to
- responses such as COOKIE and INVALID_KE_PAYLOAD), and incremented for
- each subsequent exchange. Thus, the first pair of IKE_AUTH messages
- will have an ID of 1, the second (when EAP is used) will be 2, and so
- on. The Message ID is reset to zero in the new IKE SA after the IKE
- SA is rekeyed.
-
-
-
-
-Kaufman, et al. Standards Track [Page 24]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Each endpoint in the IKE Security Association maintains two "current"
- Message IDs: the next one to be used for a request it initiates and
- the next one it expects to see in a request from the other end.
- These counters increment as requests are generated and received.
- Responses always contain the same Message ID as the corresponding
- request. That means that after the initial exchange, each integer n
- may appear as the Message ID in four distinct messages: the nth
- request from the original IKE initiator, the corresponding response,
- the nth request from the original IKE responder, and the
- corresponding response. If the two ends make a very different number
- of requests, the Message IDs in the two directions can be very
- different. There is no ambiguity in the messages, however, because
- the Initiator and Response flags in the message header specify which
- of the four messages a particular one is.
-
- Throughout this document, "initiator" refers to the party who
- initiated the exchange being described. The "original initiator"
- always refers to the party who initiated the exchange that resulted
- in the current IKE SA. In other words, if the "original responder"
- starts rekeying the IKE SA, that party becomes the "original
- initiator" of the new IKE SA.
-
- Note that Message IDs are cryptographically protected and provide
- protection against message replays. In the unlikely event that
- Message IDs grow too large to fit in 32 bits, the IKE SA MUST be
- closed or rekeyed.
-
-2.3. Window Size for Overlapping Requests
-
- The SET_WINDOW_SIZE notification asserts that the sending endpoint is
- capable of keeping state for multiple outstanding exchanges,
- permitting the recipient to send multiple requests before getting a
- response to the first. The data associated with a SET_WINDOW_SIZE
- notification MUST be 4 octets long and contain the big endian
- representation of the number of messages the sender promises to keep.
- The window size is always one until the initial exchanges complete.
-
- An IKE endpoint MUST wait for a response to each of its messages
- before sending a subsequent message unless it has received a
- SET_WINDOW_SIZE Notify message from its peer informing it that the
- peer is prepared to maintain state for multiple outstanding messages
- in order to allow greater throughput.
-
- After an IKE SA is set up, in order to maximize IKE throughput, an
- IKE endpoint MAY issue multiple requests before getting a response to
- any of them, up to the limit set by its peer's SET_WINDOW_SIZE.
- These requests may pass one another over the network. An IKE
- endpoint MUST be prepared to accept and process a request while it
-
-
-
-Kaufman, et al. Standards Track [Page 25]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- has a request outstanding in order to avoid a deadlock in this
- situation. An IKE endpoint may also accept and process multiple
- requests while it has a request outstanding.
-
- An IKE endpoint MUST NOT exceed the peer's stated window size for
- transmitted IKE requests. In other words, if the responder stated
- its window size is N, then when the initiator needs to make a request
- X, it MUST wait until it has received responses to all requests up
- through request X-N. An IKE endpoint MUST keep a copy of (or be able
- to regenerate exactly) each request it has sent until it receives the
- corresponding response. An IKE endpoint MUST keep a copy of (or be
- able to regenerate exactly) the number of previous responses equal to
- its declared window size in case its response was lost and the
- initiator requests its retransmission by retransmitting the request.
-
- An IKE endpoint supporting a window size greater than one ought to be
- capable of processing incoming requests out of order to maximize
- performance in the event of network failures or packet reordering.
-
- The window size is normally a (possibly configurable) property of a
- particular implementation, and is not related to congestion control
- (unlike the window size in TCP, for example). In particular, what
- the responder should do when it receives a SET_WINDOW_SIZE
- notification containing a smaller value than is currently in effect
- is not defined. Thus, there is currently no way to reduce the window
- size of an existing IKE SA; you can only increase it. When rekeying
- an IKE SA, the new IKE SA starts with window size 1 until it is
- explicitly increased by sending a new SET_WINDOW_SIZE notification.
-
- The INVALID_MESSAGE_ID notification is sent when an IKE Message ID
- outside the supported window is received. This Notify message MUST
- NOT be sent in a response; the invalid request MUST NOT be
- acknowledged. Instead, inform the other side by initiating an
- INFORMATIONAL exchange with Notification data containing the four-
- octet invalid Message ID. Sending this notification is OPTIONAL, and
- notifications of this type MUST be rate limited.
-
-2.4. State Synchronization and Connection Timeouts
-
- An IKE endpoint is allowed to forget all of its state associated with
- an IKE SA and the collection of corresponding Child SAs at any time.
- This is the anticipated behavior in the event of an endpoint crash
- and restart. It is important when an endpoint either fails or
- reinitializes its state that the other endpoint detect those
- conditions and not continue to waste network bandwidth by sending
- packets over discarded SAs and having them fall into a black hole.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 26]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- The INITIAL_CONTACT notification asserts that this IKE SA is the only
- IKE SA currently active between the authenticated identities. It MAY
- be sent when an IKE SA is established after a crash, and the
- recipient MAY use this information to delete any other IKE SAs it has
- to the same authenticated identity without waiting for a timeout.
- This notification MUST NOT be sent by an entity that may be
- replicated (e.g., a roaming user's credentials where the user is
- allowed to connect to the corporate firewall from two remote systems
- at the same time). The INITIAL_CONTACT notification, if sent, MUST
- be in the first IKE_AUTH request or response, not as a separate
- exchange afterwards; receiving parties MAY ignore it in other
- messages.
-
- Since IKE is designed to operate in spite of DoS attacks from the
- network, an endpoint MUST NOT conclude that the other endpoint has
- failed based on any routing information (e.g., ICMP messages) or IKE
- messages that arrive without cryptographic protection (e.g., Notify
- messages complaining about unknown SPIs). An endpoint MUST conclude
- that the other endpoint has failed only when repeated attempts to
- contact it have gone unanswered for a timeout period or when a
- cryptographically protected INITIAL_CONTACT notification is received
- on a different IKE SA to the same authenticated identity. An
- endpoint should suspect that the other endpoint has failed based on
- routing information and initiate a request to see whether the other
- endpoint is alive. To check whether the other side is alive, IKE
- specifies an empty INFORMATIONAL message that (like all IKE requests)
- requires an acknowledgement (note that within the context of an IKE
- SA, an "empty" message consists of an IKE header followed by an
- Encrypted payload that contains no payloads). If a cryptographically
- protected (fresh, i.e., not retransmitted) message has been received
- from the other side recently, unprotected Notify messages MAY be
- ignored. Implementations MUST limit the rate at which they take
- actions based on unprotected messages.
-
- The number of retries and length of timeouts are not covered in this
- specification because they do not affect interoperability. It is
- suggested that messages be retransmitted at least a dozen times over
- a period of at least several minutes before giving up on an SA, but
- different environments may require different rules. To be a good
- network citizen, retransmission times MUST increase exponentially to
- avoid flooding the network and making an existing congestion
- situation worse. If there has only been outgoing traffic on all of
- the SAs associated with an IKE SA, it is essential to confirm
- liveness of the other endpoint to avoid black holes. If no
- cryptographically protected messages have been received on an IKE SA
- or any of its Child SAs recently, the system needs to perform a
- liveness check in order to prevent sending messages to a dead peer.
- (This is sometimes called "dead peer detection" or "DPD", although it
-
-
-
-Kaufman, et al. Standards Track [Page 27]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- is really detecting live peers, not dead ones.) Receipt of a fresh
- cryptographically protected message on an IKE SA or any of its Child
- SAs ensures liveness of the IKE SA and all of its Child SAs. Note
- that this places requirements on the failure modes of an IKE
- endpoint. An implementation needs to stop sending over any SA if
- some failure prevents it from receiving on all of the associated SAs.
- If a system creates Child SAs that can fail independently from one
- another without the associated IKE SA being able to send a delete
- message, then the system MUST negotiate such Child SAs using separate
- IKE SAs.
-
- There is a DoS attack on the initiator of an IKE SA that can be
- avoided if the initiator takes the proper care. Since the first two
- messages of an SA setup are not cryptographically protected, an
- attacker could respond to the initiator's message before the genuine
- responder and poison the connection setup attempt. To prevent this,
- the initiator MAY be willing to accept multiple responses to its
- first message, treat each as potentially legitimate, respond to it,
- and then discard all the invalid half-open connections when it
- receives a valid cryptographically protected response to any one of
- its requests. Once a cryptographically valid response is received,
- all subsequent responses should be ignored whether or not they are
- cryptographically valid.
-
- Note that with these rules, there is no reason to negotiate and agree
- upon an SA lifetime. If IKE presumes the partner is dead, based on
- repeated lack of acknowledgement to an IKE message, then the IKE SA
- and all Child SAs set up through that IKE SA are deleted.
-
- An IKE endpoint may at any time delete inactive Child SAs to recover
- resources used to hold their state. If an IKE endpoint chooses to
- delete Child SAs, it MUST send Delete payloads to the other end
- notifying it of the deletion. It MAY similarly time out the IKE SA.
- Closing the IKE SA implicitly closes all associated Child SAs. In
- this case, an IKE endpoint SHOULD send a Delete payload indicating
- that it has closed the IKE SA unless the other endpoint is no longer
- responding.
-
-2.5. Version Numbers and Forward Compatibility
-
- This document describes version 2.0 of IKE, meaning the major version
- number is 2 and the minor version number is 0. This document is a
- replacement for [IKEV2]. It is likely that some implementations will
- want to support version 1.0 and version 2.0, and in the future, other
- versions.
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 28]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- The major version number should be incremented only if the packet
- formats or required actions have changed so dramatically that an
- older version node would not be able to interoperate with a newer
- version node if it simply ignored the fields it did not understand
- and took the actions specified in the older specification. The minor
- version number indicates new capabilities, and MUST be ignored by a
- node with a smaller minor version number, but used for informational
- purposes by the node with the larger minor version number. For
- example, it might indicate the ability to process a newly defined
- Notify message type. The node with the larger minor version number
- would simply note that its correspondent would not be able to
- understand that message and therefore would not send it.
-
- If an endpoint receives a message with a higher major version number,
- it MUST drop the message and SHOULD send an unauthenticated Notify
- message of type INVALID_MAJOR_VERSION containing the highest
- (closest) version number it supports. If an endpoint supports major
- version n, and major version m, it MUST support all versions between
- n and m. If it receives a message with a major version that it
- supports, it MUST respond with that version number. In order to
- prevent two nodes from being tricked into corresponding with a lower
- major version number than the maximum that they both support, IKE has
- a flag that indicates that the node is capable of speaking a higher
- major version number.
-
- Thus, the major version number in the IKE header indicates the
- version number of the message, not the highest version number that
- the transmitter supports. If the initiator is capable of speaking
- versions n, n+1, and n+2, and the responder is capable of speaking
- versions n and n+1, then they will negotiate speaking n+1, where the
- initiator will set a flag indicating its ability to speak a higher
- version. If they mistakenly (perhaps through an active attacker
- sending error messages) negotiate to version n, then both will notice
- that the other side can support a higher version number, and they
- MUST break the connection and reconnect using version n+1.
-
- Note that IKEv1 does not follow these rules, because there is no way
- in v1 of noting that you are capable of speaking a higher version
- number. So an active attacker can trick two v2-capable nodes into
- speaking v1. When a v2-capable node negotiates down to v1, it should
- note that fact in its logs.
-
- Also, for forward compatibility, all fields marked RESERVED MUST be
- set to zero by an implementation running version 2.0, and their
- content MUST be ignored by an implementation running version 2.0 ("Be
- conservative in what you send and liberal in what you receive" [IP]).
- In this way, future versions of the protocol can use those fields in
- a way that is guaranteed to be ignored by implementations that do not
-
-
-
-Kaufman, et al. Standards Track [Page 29]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- understand them. Similarly, payload types that are not defined are
- reserved for future use; implementations of a version where they are
- undefined MUST skip over those payloads and ignore their contents.
-
- IKEv2 adds a "critical" flag to each payload header for further
- flexibility for forward compatibility. If the critical flag is set
- and the payload type is unrecognized, the message MUST be rejected
- and the response to the IKE request containing that payload MUST
- include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an
- unsupported critical payload was included. In that Notify payload,
- the notification data contains the one-octet payload type. If the
- critical flag is not set and the payload type is unsupported, that
- payload MUST be ignored. Payloads sent in IKE response messages MUST
- NOT have the critical flag set. Note that the critical flag applies
- only to the payload type, not the contents. If the payload type is
- recognized, but the payload contains something that is not (such as
- an unknown transform inside an SA payload, or an unknown Notify
- Message Type inside a Notify payload), the critical flag is ignored.
-
- Although new payload types may be added in the future and may appear
- interleaved with the fields defined in this specification,
- implementations SHOULD send the payloads defined in this
- specification in the order shown in the figures in Sections 1 and 2;
- implementations MUST NOT reject as invalid a message with those
- payloads in any other order.
-
-2.6. IKE SA SPIs and Cookies
-
- The initial two eight-octet fields in the header, called the "IKE
- SPIs", are used as a connection identifier at the beginning of IKE
- packets. Each endpoint chooses one of the two SPIs and MUST choose
- them so as to be unique identifiers of an IKE SA. An SPI value of
- zero is special: it indicates that the remote SPI value is not yet
- known by the sender.
-
- Incoming IKE packets are mapped to an IKE SA only using the packet's
- SPI, not using (for example) the source IP address of the packet.
-
- Unlike ESP and AH where only the recipient's SPI appears in the
- header of a message, in IKE the sender's SPI is also sent in every
- message. Since the SPI chosen by the original initiator of the IKE
- SA is always sent first, an endpoint with multiple IKE SAs open that
- wants to find the appropriate IKE SA using the SPI it assigned must
- look at the Initiator flag in the header to determine whether it
- assigned the first or the second eight octets.
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 30]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- In the first message of an initial IKE exchange, the initiator will
- not know the responder's SPI value and will therefore set that field
- to zero. When the IKE_SA_INIT exchange does not result in the
- creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN,
- or COOKIE (see Section 2.6), the responder's SPI will be zero also in
- the response message. However, if the responder sends a non-zero
- responder SPI, the initiator should not reject the response for only
- that reason.
-
- Two expected attacks against IKE are state and CPU exhaustion, where
- the target is flooded with session initiation requests from forged IP
- addresses. These attacks can be made less effective if a responder
- uses minimal CPU and commits no state to an SA until it knows the
- initiator can receive packets at the address from which it claims to
- be sending them.
-
- When a responder detects a large number of half-open IKE SAs, it
- SHOULD reply to IKE_SA_INIT requests with a response containing the
- COOKIE notification. The data associated with this notification MUST
- be between 1 and 64 octets in length (inclusive), and its generation
- is described later in this section. If the IKE_SA_INIT response
- includes the COOKIE notification, the initiator MUST then retry the
- IKE_SA_INIT request, and include the COOKIE notification containing
- the received data as the first payload, and all other payloads
- unchanged. The initial exchange will then be as follows:
-
- Initiator Responder
- -------------------------------------------------------------------
- HDR(A,0), SAi1, KEi, Ni -->
- <-- HDR(A,0), N(COOKIE)
- HDR(A,0), N(COOKIE), SAi1,
- KEi, Ni -->
- <-- HDR(A,B), SAr1, KEr,
- Nr, [CERTREQ]
- HDR(A,B), SK {IDi, [CERT,]
- [CERTREQ,] [IDr,] AUTH,
- SAi2, TSi, TSr} -->
- <-- HDR(A,B), SK {IDr, [CERT,]
- AUTH, SAr2, TSi, TSr}
-
- The first two messages do not affect any initiator or responder state
- except for communicating the cookie. In particular, the message
- sequence numbers in the first four messages will all be zero and the
- message sequence numbers in the last two messages will be one. 'A'
- is the SPI assigned by the initiator, while 'B' is the SPI assigned
- by the responder.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 31]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- An IKE implementation can implement its responder cookie generation
- in such a way as to not require any saved state to recognize its
- valid cookie when the second IKE_SA_INIT message arrives. The exact
- algorithms and syntax used to generate cookies do not affect
- interoperability and hence are not specified here. The following is
- an example of how an endpoint could use cookies to implement limited
- DoS protection.
-
- A good way to do this is to set the responder cookie to be:
-
- Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
-
- where <secret> is a randomly generated secret known only to the
- responder and periodically changed and | indicates concatenation.
- <VersionIDofSecret> should be changed whenever <secret> is
- regenerated. The cookie can be recomputed when the IKE_SA_INIT
- arrives the second time and compared to the cookie in the received
- message. If it matches, the responder knows that the cookie was
- generated since the last change to <secret> and that IPi must be the
- same as the source address it saw the first time. Incorporating SPIi
- into the calculation ensures that if multiple IKE SAs are being set
- up in parallel they will all get different cookies (assuming the
- initiator chooses unique SPIi's). Incorporating Ni in the hash
- ensures that an attacker who sees only message 2 can't successfully
- forge a message 3. Also, incorporating SPIi in the hash prevents an
- attacker from fetching one cookie from the other end, and then
- initiating many IKE_SA_INIT exchanges all with different initiator
- SPIs (and perhaps port numbers) so that the responder thinks that
- there are a lot of machines behind one NAT box that are all trying to
- connect.
-
- If a new value for <secret> is chosen while there are connections in
- the process of being initialized, an IKE_SA_INIT might be returned
- with other than the current <VersionIDofSecret>. The responder in
- that case MAY reject the message by sending another response with a
- new cookie or it MAY keep the old value of <secret> around for a
- short time and accept cookies computed from either one. The
- responder should not accept cookies indefinitely after <secret> is
- changed, since that would defeat part of the DoS protection. The
- responder should change the value of <secret> frequently, especially
- if under attack.
-
- When one party receives an IKE_SA_INIT request containing a cookie
- whose contents do not match the value expected, that party MUST
- ignore the cookie and process the message as if no cookie had been
- included; usually this means sending a response containing a new
- cookie. The initiator should limit the number of cookie exchanges it
- tries before giving up, possibly using exponential back-off. An
-
-
-
-Kaufman, et al. Standards Track [Page 32]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- attacker can forge multiple cookie responses to the initiator's
- IKE_SA_INIT message, and each of those forged cookie replies will
- cause two packets to be sent: one packet from the initiator to the
- responder (which will reject those cookies), and one response from
- responder to initiator that includes the correct cookie.
-
- A note on terminology: the term "cookies" originates with Karn and
- Simpson [PHOTURIS] in Photuris, an early proposal for key management
- with IPsec, and it has persisted. The Internet Security Association
- and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header
- includes two eight-octet fields called "cookies", and that syntax is
- used by both IKEv1 and IKEv2, although in IKEv2 they are referred to
- as the "IKE SPI" and there is a new separate field in a Notify
- payload holding the cookie.
-
-2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD
-
- There are two common reasons why the initiator may have to retry the
- IKE_SA_INIT exchange: the responder requests a cookie or wants a
- different Diffie-Hellman group than was included in the KEi payload.
- If the initiator receives a cookie from the responder, the initiator
- needs to decide whether or not to include the cookie in only the next
- retry of the IKE_SA_INIT request, or in all subsequent retries as
- well.
-
- If the initiator includes the cookie only in the next retry, one
- additional round trip may be needed in some cases. An additional
- round trip is needed also if the initiator includes the cookie in all
- retries, but the responder does not support this. For instance, if
- the responder includes the KEi payloads in cookie calculation, it
- will reject the request by sending a new cookie.
-
- If both peers support including the cookie in all retries, a slightly
- shorter exchange can happen.
-
- Initiator Responder
- -----------------------------------------------------------
- HDR(A,0), SAi1, KEi, Ni -->
- <-- HDR(A,0), N(COOKIE)
- HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
- <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
- HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
- <-- HDR(A,B), SAr1, KEr, Nr
-
- Implementations SHOULD support this shorter exchange, but MUST NOT
- fail if other implementations do not support this shorter exchange.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 33]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-2.7. Cryptographic Algorithm Negotiation
-
- The payload type known as "SA" indicates a proposal for a set of
- choices of IPsec protocols (IKE, ESP, or AH) for the SA as well as
- cryptographic algorithms associated with each protocol.
-
- An SA payload consists of one or more proposals. Each proposal
- includes one protocol. Each protocol contains one or more transforms
- -- each specifying a cryptographic algorithm. Each transform
- contains zero or more attributes (attributes are needed only if the
- Transform ID does not completely specify the cryptographic
- algorithm).
-
- This hierarchical structure was designed to efficiently encode
- proposals for cryptographic suites when the number of supported
- suites is large because multiple values are acceptable for multiple
- transforms. The responder MUST choose a single suite, which may be
- any subset of the SA proposal following the rules below.
-
- Each proposal contains one protocol. If a proposal is accepted, the
- SA response MUST contain the same protocol. The responder MUST
- accept a single proposal or reject them all and return an error. The
- error is given in a notification of type NO_PROPOSAL_CHOSEN.
-
- Each IPsec protocol proposal contains one or more transforms. Each
- transform contains a Transform Type. The accepted cryptographic
- suite MUST contain exactly one transform of each type included in the
- proposal. For example: if an ESP proposal includes transforms
- ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256,
- AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one
- of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six
- combinations are acceptable.
-
- If an initiator proposes both normal ciphers with integrity
- protection as well as combined-mode ciphers, then two proposals are
- needed. One of the proposals includes the normal ciphers with the
- integrity algorithms for them, and the other proposal includes all
- the combined-mode ciphers without the integrity algorithms (because
- combined-mode ciphers are not allowed to have any integrity algorithm
- other than "none").
-
-2.8. Rekeying
-
- IKE, ESP, and AH Security Associations use secret keys that should be
- used only for a limited amount of time and to protect a limited
- amount of data. This limits the lifetime of the entire Security
- Association. When the lifetime of a Security Association expires,
- the Security Association MUST NOT be used. If there is demand, new
-
-
-
-Kaufman, et al. Standards Track [Page 34]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Security Associations MAY be established. Reestablishment of
- Security Associations to take the place of ones that expire is
- referred to as "rekeying".
-
- To allow for minimal IPsec implementations, the ability to rekey SAs
- without restarting the entire IKE SA is optional. An implementation
- MAY refuse all CREATE_CHILD_SA requests within an IKE SA. If an SA
- has expired or is about to expire and rekeying attempts using the
- mechanisms described here fail, an implementation MUST close the IKE
- SA and any associated Child SAs and then MAY start new ones.
- Implementations may wish to support in-place rekeying of SAs, since
- doing so offers better performance and is likely to reduce the number
- of packets lost during the transition.
-
- To rekey a Child SA within an existing IKE SA, create a new,
- equivalent SA (see Section 2.17 below), and when the new one is
- established, delete the old one. Note that, when rekeying, the new
- Child SA SHOULD NOT have different Traffic Selectors and algorithms
- than the old one.
-
- To rekey an IKE SA, establish a new equivalent IKE SA (see
- Section 2.18 below) with the peer to whom the old IKE SA is shared
- using a CREATE_CHILD_SA within the existing IKE SA. An IKE SA so
- created inherits all of the original IKE SA's Child SAs, and the new
- IKE SA is used for all control messages needed to maintain those
- Child SAs. After the new equivalent IKE SA is created, the initiator
- deletes the old IKE SA, and the Delete payload to delete itself MUST
- be the last request sent over the old IKE SA.
-
- SAs should be rekeyed proactively, i.e., the new SA should be
- established before the old one expires and becomes unusable. Enough
- time should elapse between the time the new SA is established and the
- old one becomes unusable so that traffic can be switched over to the
- new SA.
-
- A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
- were negotiated. In IKEv2, each end of the SA is responsible for
- enforcing its own lifetime policy on the SA and rekeying the SA when
- necessary. If the two ends have different lifetime policies, the end
- with the shorter lifetime will end up always being the one to request
- the rekeying. If an SA has been inactive for a long time and if an
- endpoint would not initiate the SA in the absence of traffic, the
- endpoint MAY choose to close the SA instead of rekeying it when its
- lifetime expires. It can also do so if there has been no traffic
- since the last time the SA was rekeyed.
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 35]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Note that IKEv2 deliberately allows parallel SAs with the same
- Traffic Selectors between common endpoints. One of the purposes of
- this is to support traffic quality of service (QoS) differences among
- the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and Section 4.1 of
- [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints
- and the Traffic Selectors may not uniquely identify an SA between
- those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on
- the basis of duplicate Traffic Selectors SHOULD NOT be used.
-
- There are timing windows -- particularly in the presence of lost
- packets -- where endpoints may not agree on the state of an SA. The
- responder to a CREATE_CHILD_SA MUST be prepared to accept messages on
- an SA before sending its response to the creation request, so there
- is no ambiguity for the initiator. The initiator MAY begin sending
- on an SA as soon as it processes the response. The initiator,
- however, cannot receive on a newly created SA until it receives and
- processes the response to its CREATE_CHILD_SA request. How, then, is
- the responder to know when it is OK to send on the newly created SA?
-
- From a technical correctness and interoperability perspective, the
- responder MAY begin sending on an SA as soon as it sends its response
- to the CREATE_CHILD_SA request. In some situations, however, this
- could result in packets unnecessarily being dropped, so an
- implementation MAY defer such sending.
-
- The responder can be assured that the initiator is prepared to
- receive messages on an SA if either (1) it has received a
- cryptographically valid message on the other half of the SA pair, or
- (2) the new SA rekeys an existing SA and it receives an IKE request
- to close the replaced SA. When rekeying an SA, the responder
- continues to send traffic on the old SA until one of those events
- occurs. When establishing a new SA, the responder MAY defer sending
- messages on a new SA until either it receives one or a timeout has
- occurred. If an initiator receives a message on an SA for which it
- has not received a response to its CREATE_CHILD_SA request, it
- interprets that as a likely packet loss and retransmits the
- CREATE_CHILD_SA request. An initiator MAY send a dummy ESP message
- on a newly created ESP SA if it has no messages queued in order to
- assure the responder that the initiator is ready to receive messages.
-
-2.8.1. Simultaneous Child SA Rekeying
-
- If the two ends have the same lifetime policies, it is possible that
- both will initiate a rekeying at the same time (which will result in
- redundant SAs). To reduce the probability of this happening, the
- timing of rekeying requests SHOULD be jittered (delayed by a random
- amount of time after the need for rekeying is noticed).
-
-
-
-
-Kaufman, et al. Standards Track [Page 36]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- This form of rekeying may temporarily result in multiple similar SAs
- between the same pairs of nodes. When there are two SAs eligible to
- receive packets, a node MUST accept incoming packets through either
- SA. If redundant SAs are created though such a collision, the SA
- created with the lowest of the four nonces used in the two exchanges
- SHOULD be closed by the endpoint that created it. "Lowest" means an
- octet-by-octet comparison (instead of, for instance, comparing the
- nonces as large integers). In other words, start by comparing the
- first octet; if they're equal, move to the next octet, and so on. If
- you reach the end of one nonce, that nonce is the lower one. The
- node that initiated the surviving rekeyed SA should delete the
- replaced SA after the new one is established.
-
- The following is an explanation on the impact this has on
- implementations. Assume that hosts A and B have an existing Child SA
- pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same
- time:
-
- Host A Host B
- -------------------------------------------------------------------
- send req1: N(REKEY_SA,SPIa1),
- SA(..,SPIa2,..),Ni1,.. -->
- <-- send req2: N(REKEY_SA,SPIb1),
- SA(..,SPIb2,..),Ni2
- recv req2 <--
-
- At this point, A knows there is a simultaneous rekeying happening.
- However, it cannot yet know which of the exchanges will have the
- lowest nonce, so it will just note the situation and respond as
- usual.
-
- send resp2: SA(..,SPIa3,..),
- Nr1,.. -->
- --> recv req1
-
- Now B also knows that simultaneous rekeying is going on. It responds
- as usual.
-
- <-- send resp1: SA(..,SPIb3,..),
- Nr2,..
- recv resp1 <--
- --> recv resp2
-
- At this point, there are three Child SA pairs between A and B (the
- old one and two new ones). A and B can now compare the nonces.
- Suppose that the lowest nonce was Nr1 in message resp2; in this case,
- B (the sender of req2) deletes the redundant new SA, and A (the node
- that initiated the surviving rekeyed SA), deletes the old one.
-
-
-
-Kaufman, et al. Standards Track [Page 37]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- send req3: D(SPIa1) -->
- <-- send req4: D(SPIb2)
- --> recv req3
- <-- send resp3: D(SPIb1)
- recv req4 <--
- send resp4: D(SPIa3) -->
-
- The rekeying is now finished.
-
- However, there is a second possible sequence of events that can
- happen if some packets are lost in the network, resulting in
- retransmissions. The rekeying begins as usual, but A's first packet
- (req1) is lost.
-
- Host A Host B
- -------------------------------------------------------------------
- send req1: N(REKEY_SA,SPIa1),
- SA(..,SPIa2,..),
- Ni1,.. --> (lost)
- <-- send req2: N(REKEY_SA,SPIb1),
- SA(..,SPIb2,..),Ni2
- recv req2 <--
- send resp2: SA(..,SPIa3,..),
- Nr1,.. -->
- --> recv resp2
- <-- send req3: D(SPIb1)
- recv req3 <--
- send resp3: D(SPIa1) -->
- --> recv resp3
-
- From B's point of view, the rekeying is now completed, and since it
- has not yet received A's req1, it does not even know that there was
- simultaneous rekeying. However, A will continue retransmitting the
- message, and eventually it will reach B.
-
- resend req1 -->
- --> recv req1
-
- To B, it looks like A is trying to rekey an SA that no longer exists;
- thus, B responds to the request with something non-fatal such as
- CHILD_SA_NOT_FOUND.
-
- <-- send resp1: N(CHILD_SA_NOT_FOUND)
- recv resp1 <--
-
- When A receives this error, it already knows there was simultaneous
- rekeying, so it can ignore the error message.
-
-
-
-
-Kaufman, et al. Standards Track [Page 38]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-2.8.2. Simultaneous IKE SA Rekeying
-
- Probably the most complex case occurs when both peers try to rekey
- the IKE_SA at the same time. Basically, the text in Section 2.8
- applies to this case as well; however, it is important to ensure that
- the Child SAs are inherited by the correct IKE_SA.
-
- The case where both endpoints notice the simultaneous rekeying works
- the same way as with Child SAs. After the CREATE_CHILD_SA exchanges,
- three IKE SAs exist between A and B: the old IKE SA and two new IKE
- SAs. The new IKE SA containing the lowest nonce SHOULD be deleted by
- the node that created it, and the other surviving new IKE SA MUST
- inherit all the Child SAs.
-
- In addition to normal simultaneous rekeying cases, there is a special
- case where one peer finishes its rekey before it even notices that
- other peer is doing a rekey. If only one peer detects a simultaneous
- rekey, redundant SAs are not created. In this case, when the peer
- that did not notice the simultaneous rekey gets the request to rekey
- the IKE SA that it has already successfully rekeyed, it SHOULD return
- TEMPORARY_FAILURE because it is an IKE SA that it is currently trying
- to close (whether or not it has already sent the delete notification
- for the SA). If the peer that did notice the simultaneous rekey gets
- the delete request from the other peer for the old IKE SA, it knows
- that the other peer did not detect the simultaneous rekey, and the
- first peer can forget its own rekey attempt.
-
- Host A Host B
- -------------------------------------------------------------------
- send req1:
- SA(..,SPIa1,..),Ni1,.. -->
- <-- send req2: SA(..,SPIb1,..),Ni2,..
- --> recv req1
- <-- send resp1: SA(..,SPIb2,..),Nr2,..
- recv resp1 <--
- send req3: D() -->
- --> recv req3
-
- At this point, host B sees a request to close the IKE_SA. There's
- not much more to do than to reply as usual. However, at this point
- host B should stop retransmitting req2, since once host A receives
- resp3, it will delete all the state associated with the old IKE_SA
- and will not be able to reply to it.
-
- <-- send resp3: ()
-
- The TEMPORARY_FAILURE notification was not included in RFC 4306, and
- support of the TEMPORARY_FAILURE notification is not negotiated.
-
-
-
-Kaufman, et al. Standards Track [Page 39]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Thus, older peers that implement RFC 4306 but not this document may
- receive these notifications. In that case, they will treat it the
- same as any other unknown error notification, and will stop the
- exchange. Because the other peer has already rekeyed the exchange,
- doing so does not have any ill effects.
-
-2.8.3. Rekeying the IKE SA versus Reauthentication
-
- Rekeying the IKE SA and reauthentication are different concepts in
- IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and
- resets the Message ID counters, but it does not authenticate the
- parties again (no AUTH or EAP payloads are involved).
-
- Although rekeying the IKE SA may be important in some environments,
- reauthentication (the verification that the parties still have access
- to the long-term credentials) is often more important.
-
- IKEv2 does not have any special support for reauthentication.
- Reauthentication is done by creating a new IKE SA from scratch (using
- IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA Notify
- payloads), creating new Child SAs within the new IKE SA (without
- REKEY_SA Notify payloads), and finally deleting the old IKE SA (which
- deletes the old Child SAs as well).
-
- This means that reauthentication also establishes new keys for the
- IKE SA and Child SAs. Therefore, while rekeying can be performed
- more often than reauthentication, the situation where "authentication
- lifetime" is shorter than "key lifetime" does not make sense.
-
- While creation of a new IKE SA can be initiated by either party
- (initiator or responder in the original IKE SA), the use of EAP
- and/or Configuration payloads means in practice that reauthentication
- has to be initiated by the same party as the original IKE SA. IKEv2
- does not currently allow the responder to request reauthentication in
- this case; however, there are extensions that add this functionality
- such as [REAUTH].
-
-2.9. Traffic Selector Negotiation
-
- When an RFC4301-compliant IPsec subsystem receives an IP packet that
- matches a "protect" selector in its Security Policy Database (SPD),
- the subsystem protects that packet with IPsec. When no SA exists
- yet, it is the task of IKE to create it. Maintenance of a system's
- SPD is outside the scope of IKE, although some implementations might
- update their SPD in connection with the running of IKE (for an
- example scenario, see Section 1.1.3).
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 40]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Traffic Selector (TS) payloads allow endpoints to communicate some of
- the information from their SPD to their peers. These must be
- communicated to IKE from the SPD (for example, the PF_KEY API [PFKEY]
- uses the SADB_ACQUIRE message). TS payloads specify the selection
- criteria for packets that will be forwarded over the newly set up SA.
- This can serve as a consistency check in some scenarios to assure
- that the SPDs are consistent. In others, it guides the dynamic
- update of the SPD.
-
- Two TS payloads appear in each of the messages in the exchange that
- creates a Child SA pair. Each TS payload contains one or more
- Traffic Selectors. Each Traffic Selector consists of an address
- range (IPv4 or IPv6), a port range, and an IP protocol ID.
-
- The first of the two TS payloads is known as TSi (Traffic Selector-
- initiator). The second is known as TSr (Traffic Selector-responder).
- TSi specifies the source address of traffic forwarded from (or the
- destination address of traffic forwarded to) the initiator of the
- Child SA pair. TSr specifies the destination address of the traffic
- forwarded to (or the source address of the traffic forwarded from)
- the responder of the Child SA pair. For example, if the original
- initiator requests the creation of a Child SA pair, and wishes to
- tunnel all traffic from subnet 198.51.100.* on the initiator's side
- to subnet 192.0.2.* on the responder's side, the initiator would
- include a single Traffic Selector in each TS payload. TSi would
- specify the address range (198.51.100.0 - 198.51.100.255) and TSr
- would specify the address range (192.0.2.0 - 192.0.2.255). Assuming
- that proposal was acceptable to the responder, it would send
- identical TS payloads back.
-
- IKEv2 allows the responder to choose a subset of the traffic proposed
- by the initiator. This could happen when the configurations of the
- two endpoints are being updated but only one end has received the new
- information. Since the two endpoints may be configured by different
- people, the incompatibility may persist for an extended period even
- in the absence of errors. It also allows for intentionally different
- configurations, as when one end is configured to tunnel all addresses
- and depends on the other end to have the up-to-date list.
-
- When the responder chooses a subset of the traffic proposed by the
- initiator, it narrows the Traffic Selectors to some subset of the
- initiator's proposal (provided the set does not become the null set).
- If the type of Traffic Selector proposed is unknown, the responder
- ignores that Traffic Selector, so that the unknown type is not
- returned in the narrowed set.
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 41]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- To enable the responder to choose the appropriate range in this case,
- if the initiator has requested the SA due to a data packet, the
- initiator SHOULD include as the first Traffic Selector in each of TSi
- and TSr a very specific Traffic Selector including the addresses in
- the packet triggering the request. In the example, the initiator
- would include in TSi two Traffic Selectors: the first containing the
- address range (198.51.100.43 - 198.51.100.43) and the source port and
- IP protocol from the packet and the second containing (198.51.100.0 -
- 198.51.100.255) with all ports and IP protocols. The initiator would
- similarly include two Traffic Selectors in TSr. If the initiator
- creates the Child SA pair not in response to an arriving packet, but
- rather, say, upon startup, then there may be no specific addresses
- the initiator prefers for the initial tunnel over any other. In that
- case, the first values in TSi and TSr can be ranges rather than
- specific values.
-
- The responder performs the narrowing as follows:
-
- o If the responder's policy does not allow it to accept any part of
- the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE
- Notify message.
-
- o If the responder's policy allows the entire set of traffic covered
- by TSi and TSr, no narrowing is necessary, and the responder can
- return the same TSi and TSr values.
-
- o If the responder's policy allows it to accept the first selector
- of TSi and TSr, then the responder MUST narrow the Traffic
- Selectors to a subset that includes the initiator's first choices.
- In this example above, the responder might respond with TSi being
- (198.51.100.43 - 198.51.100.43) with all ports and IP protocols.
-
- o If the responder's policy does not allow it to accept the first
- selector of TSi and TSr, the responder narrows to an acceptable
- subset of TSi and TSr.
-
- When narrowing is done, there may be several subsets that are
- acceptable but their union is not. In this case, the responder
- arbitrarily chooses one of them, and MAY include an
- ADDITIONAL_TS_POSSIBLE notification in the response. The
- ADDITIONAL_TS_POSSIBLE notification asserts that the responder
- narrowed the proposed Traffic Selectors but that other Traffic
- Selectors would also have been acceptable, though only in a separate
- SA. There is no data associated with this Notify type. This case
- will occur only when the initiator and responder are configured
- differently from one another. If the initiator and responder agree
- on the granularity of tunnels, the initiator will never request a
- tunnel wider than the responder will accept.
-
-
-
-Kaufman, et al. Standards Track [Page 42]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- It is possible for the responder's policy to contain multiple smaller
- ranges, all encompassed by the initiator's Traffic Selector, and with
- the responder's policy being that each of those ranges should be sent
- over a different SA. Continuing the example above, the responder
- might have a policy of being willing to tunnel those addresses to and
- from the initiator, but might require that each address pair be on a
- separately negotiated Child SA. If the initiator didn't generate its
- request based on the packet, but (for example) upon startup, there
- would not be the very specific first Traffic Selectors helping the
- responder to select the correct range. There would be no way for the
- responder to determine which pair of addresses should be included in
- this tunnel, and it would have to make a guess or reject the request
- with a SINGLE_PAIR_REQUIRED Notify message.
-
- The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA
- request is unacceptable because its sender is only willing to accept
- Traffic Selectors specifying a single pair of addresses. The
- requestor is expected to respond by requesting an SA for only the
- specific traffic it is trying to forward.
-
- Few implementations will have policies that require separate SAs for
- each address pair. Because of this, if only some parts of the TSi
- and TSr proposed by the initiator are acceptable to the responder,
- responders SHOULD narrow the selectors to an acceptable subset rather
- than use SINGLE_PAIR_REQUIRED.
-
-2.9.1. Traffic Selectors Violating Own Policy
-
- When creating a new SA, the initiator needs to avoid proposing
- Traffic Selectors that violate its own policy. If this rule is not
- followed, valid traffic may be dropped. If you use decorrelated
- policies from [IPSECARCH], this kind of policy violations cannot
- happen.
-
- This is best illustrated by an example. Suppose that host A has a
- policy whose effect is that traffic to 198.51.100.66 is sent via host
- B encrypted using AES, and traffic to all other hosts in
- 198.51.100.0/24 is also sent via B, but must use 3DES. Suppose also
- that host B accepts any combination of AES and 3DES.
-
- If host A now proposes an SA that uses 3DES, and includes TSr
- containing (198.51.100.0-198.51.100.255), this will be accepted by
- host B. Now, host B can also use this SA to send traffic from
- 198.51.100.66, but those packets will be dropped by A since it
- requires the use of AES for this traffic. Even if host A creates a
- new SA only for 198.51.100.66 that uses AES, host B may freely
- continue to use the first SA for the traffic. In this situation,
-
-
-
-
-Kaufman, et al. Standards Track [Page 43]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- when proposing the SA, host A should have followed its own policy,
- and included a TSr containing ((198.51.100.0-
- 198.51.100.65),(198.51.100.67-198.51.100.255)) instead.
-
- In general, if (1) the initiator makes a proposal "for traffic X
- (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator
- does not actually accept traffic X' with SA, and (3) the initiator
- would be willing to accept traffic X' with some SA' (!=SA), valid
- traffic can be unnecessarily dropped since the responder can apply
- either SA or SA' to traffic X'.
-
-2.10. Nonces
-
- The IKE_SA_INIT messages each contain a nonce. These nonces are used
- as inputs to cryptographic functions. The CREATE_CHILD_SA request
- and the CREATE_CHILD_SA response also contain nonces. These nonces
- are used to add freshness to the key derivation technique used to
- obtain keys for Child SA, and to ensure creation of strong
- pseudorandom bits from the Diffie-Hellman key. Nonces used in IKEv2
- MUST be randomly chosen, MUST be at least 128 bits in size, and MUST
- be at least half the key size of the negotiated pseudorandom function
- (PRF). However, the initiator chooses the nonce before the outcome
- of the negotiation is known. Because of that, the nonce has to be
- long enough for all the PRFs being proposed. If the same random
- number source is used for both keys and nonces, care must be taken to
- ensure that the latter use does not compromise the former.
-
-2.11. Address and Port Agility
-
- IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
- AH associations for the same IP addresses over which it runs. The IP
- addresses and ports in the outer header are, however, not themselves
- cryptographically protected, and IKE is designed to work even through
- Network Address Translation (NAT) boxes. An implementation MUST
- accept incoming requests even if the source port is not 500 or 4500,
- and MUST respond to the address and port from which the request was
- received. It MUST specify the address and port at which the request
- was received as the source address and port in the response. IKE
- functions identically over IPv4 or IPv6.
-
-2.12. Reuse of Diffie-Hellman Exponentials
-
- IKE generates keying material using an ephemeral Diffie-Hellman
- exchange in order to gain the property of "perfect forward secrecy".
- This means that once a connection is closed and its corresponding
- keys are forgotten, even someone who has recorded all of the data
- from the connection and gets access to all of the long-term keys of
-
-
-
-
-Kaufman, et al. Standards Track [Page 44]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- the two endpoints cannot reconstruct the keys used to protect the
- conversation without doing a brute force search of the session key
- space.
-
- Achieving perfect forward secrecy requires that when a connection is
- closed, each endpoint MUST forget not only the keys used by the
- connection but also any information that could be used to recompute
- those keys.
-
- Because computing Diffie-Hellman exponentials is computationally
- expensive, an endpoint may find it advantageous to reuse those
- exponentials for multiple connection setups. There are several
- reasonable strategies for doing this. An endpoint could choose a new
- exponential only periodically though this could result in less-than-
- perfect forward secrecy if some connection lasts for less than the
- lifetime of the exponential. Or it could keep track of which
- exponential was used for each connection and delete the information
- associated with the exponential only when some corresponding
- connection was closed. This would allow the exponential to be reused
- without losing perfect forward secrecy at the cost of maintaining
- more state.
-
- Whether and when to reuse Diffie-Hellman exponentials are private
- decisions in the sense that they will not affect interoperability.
- An implementation that reuses exponentials MAY choose to remember the
- exponential used by the other endpoint on past exchanges and if one
- is reused to avoid the second half of the calculation. See [REUSE]
- for a security analysis of this practice and for additional security
- considerations when reusing ephemeral Diffie-Hellman keys.
-
-2.13. Generating Keying Material
-
- In the context of the IKE SA, four cryptographic algorithms are
- negotiated: an encryption algorithm, an integrity protection
- algorithm, a Diffie-Hellman group, and a pseudorandom function (PRF).
- The PRF is used for the construction of keying material for all of
- the cryptographic algorithms used in both the IKE SA and the Child
- SAs.
-
- We assume that each encryption algorithm and integrity protection
- algorithm uses a fixed-size key and that any randomly chosen value of
- that fixed size can serve as an appropriate key. For algorithms that
- accept a variable-length key, a fixed key size MUST be specified as
- part of the cryptographic transform negotiated (see Section 3.3.5 for
- the definition of the Key Length transform attribute). For
- algorithms for which not all values are valid keys (such as DES or
- 3DES with key parity), the algorithm by which keys are derived from
- arbitrary values MUST be specified by the cryptographic transform.
-
-
-
-Kaufman, et al. Standards Track [Page 45]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- For integrity protection functions based on Hashed Message
- Authentication Code (HMAC), the fixed key size is the size of the
- output of the underlying hash function.
-
- It is assumed that PRFs accept keys of any length, but have a
- preferred key size. The preferred key size MUST be used as the
- length of SK_d, SK_pi, and SK_pr (see Section 2.14). For PRFs based
- on the HMAC construction, the preferred key size is equal to the
- length of the output of the underlying hash function. Other types of
- PRFs MUST specify their preferred key size.
-
- Keying material will always be derived as the output of the
- negotiated PRF algorithm. Since the amount of keying material needed
- may be greater than the size of the output of the PRF, the PRF is
- used iteratively. The term "prf+" describes a function that outputs
- a pseudorandom stream based on the inputs to a pseudorandom function
- called "prf".
-
- In the following, | indicates concatenation. prf+ is defined as:
-
- prf+ (K,S) = T1 | T2 | T3 | T4 | ...
-
- where:
- T1 = prf (K, S | 0x01)
- T2 = prf (K, T1 | S | 0x02)
- T3 = prf (K, T2 | S | 0x03)
- T4 = prf (K, T3 | S | 0x04)
- ...
-
- This continues until all the material needed to compute all required
- keys has been output from prf+. The keys are taken from the output
- string without regard to boundaries (e.g., if the required keys are a
- 256-bit Advanced Encryption Standard (AES) key and a 160-bit HMAC
- key, and the prf function generates 160 bits, the AES key will come
- from T1 and the beginning of T2, while the HMAC key will come from
- the rest of T2 and the beginning of T3).
-
- The constant concatenated to the end of each prf function is a single
- octet. The prf+ function is not defined beyond 255 times the size of
- the prf function output.
-
-2.14. Generating Keying Material for the IKE SA
-
- The shared keys are computed as follows. A quantity called SKEYSEED
- is calculated from the nonces exchanged during the IKE_SA_INIT
- exchange and the Diffie-Hellman shared secret established during that
- exchange. SKEYSEED is used to calculate seven other secrets: SK_d
- used for deriving new keys for the Child SAs established with this
-
-
-
-Kaufman, et al. Standards Track [Page 46]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- IKE SA; SK_ai and SK_ar used as a key to the integrity protection
- algorithm for authenticating the component messages of subsequent
- exchanges; SK_ei and SK_er used for encrypting (and of course
- decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are
- used when generating an AUTH payload. The lengths of SK_d, SK_pi,
- and SK_pr MUST be the preferred key length of the PRF agreed upon.
-
- SKEYSEED and its derivatives are computed as follows:
-
- SKEYSEED = prf(Ni | Nr, g^ir)
-
- {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
- = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
-
- (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er,
- SK_pi, and SK_pr are taken in order from the generated bits of the
- prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman
- exchange. g^ir is represented as a string of octets in big endian
- order padded with zeros if necessary to make it the length of the
- modulus. Ni and Nr are the nonces, stripped of any headers. For
- historical backward-compatibility reasons, there are two PRFs that
- are treated specially in this calculation. If the negotiated PRF is
- AES-XCBC-PRF-128 [AESXCBCPRF128] or AES-CMAC-PRF-128 [AESCMACPRF128],
- only the first 64 bits of Ni and the first 64 bits of Nr are used in
- calculating SKEYSEED, but all the bits are used for input to the prf+
- function.
-
- The two directions of traffic flow use different keys. The keys used
- to protect messages from the original initiator are SK_ai and SK_ei.
- The keys used to protect messages in the other direction are SK_ar
- and SK_er.
-
-2.15. Authentication of the IKE SA
-
- When not using extensible authentication (see Section 2.16), the
- peers are authenticated by having each sign (or MAC using a padded
- shared secret as the key, as described later in this section) a block
- of data. In these calculations, IDi' and IDr' are the entire ID
- payloads excluding the fixed header. For the responder, the octets
- to be signed start with the first octet of the first SPI in the
- header of the second message (IKE_SA_INIT response) and end with the
- last octet of the last payload in the second message. Appended to
- this (for the purposes of computing the signature) are the
- initiator's nonce Ni (just the value, not the payload containing it),
- and the value prf(SK_pr, IDr'). Note that neither the nonce Ni nor
- the value prf(SK_pr, IDr') are transmitted. Similarly, the initiator
- signs the first message (IKE_SA_INIT request), starting with the
- first octet of the first SPI in the header and ending with the last
-
-
-
-Kaufman, et al. Standards Track [Page 47]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- octet of the last payload. Appended to this (for purposes of
- computing the signature) are the responder's nonce Nr, and the value
- prf(SK_pi, IDi'). It is critical to the security of the exchange
- that each side sign the other side's nonce.
-
- The initiator's signed octets can be described as:
-
- InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
- GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
- RealIKEHDR = SPIi | SPIr | . . . | Length
- RealMessage1 = RealIKEHDR | RestOfMessage1
- NonceRPayload = PayloadHeader | NonceRData
- InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload
- RestOfInitIDPayload = IDType | RESERVED | InitIDData
- MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
-
- The responder's signed octets can be described as:
-
- ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
- GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
- RealIKEHDR = SPIi | SPIr | . . . | Length
- RealMessage2 = RealIKEHDR | RestOfMessage2
- NonceIPayload = PayloadHeader | NonceIData
- ResponderIDPayload = PayloadHeader | RestOfRespIDPayload
- RestOfRespIDPayload = IDType | RESERVED | RespIDData
- MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
-
- Note that all of the payloads are included under the signature,
- including any payload types not defined in this document. If the
- first message of the exchange is sent multiple times (such as with a
- responder cookie and/or a different Diffie-Hellman group), it is the
- latest version of the message that is signed.
-
- Optionally, messages 3 and 4 MAY include a certificate, or
- certificate chain providing evidence that the key used to compute a
- digital signature belongs to the name in the ID payload. The
- signature or MAC will be computed using algorithms dictated by the
- type of key used by the signer, and specified by the Auth Method
- field in the Authentication payload. There is no requirement that
- the initiator and responder sign with the same cryptographic
- algorithms. The choice of cryptographic algorithms depends on the
- type of key each has. In particular, the initiator may be using a
- shared key while the responder may have a public signature key and
- certificate. It will commonly be the case (but it is not required)
- that, if a shared secret is used for authentication, the same key is
- used in both directions.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 48]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Note that it is a common but typically insecure practice to have a
- shared key derived solely from a user-chosen password without
- incorporating another source of randomness. This is typically
- insecure because user-chosen passwords are unlikely to have
- sufficient unpredictability to resist dictionary attacks and these
- attacks are not prevented in this authentication method.
- (Applications using password-based authentication for bootstrapping
- and IKE SA should use the authentication method in Section 2.16,
- which is designed to prevent off-line dictionary attacks.) The pre-
- shared key needs to contain as much unpredictability as the strongest
- key being negotiated. In the case of a pre-shared key, the AUTH
- value is computed as:
-
- For the initiator:
- AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
- <InitiatorSignedOctets>)
- For the responder:
- AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"),
- <ResponderSignedOctets>)
-
- where the string "Key Pad for IKEv2" is 17 ASCII characters without
- null termination. The shared secret can be variable length. The pad
- string is added so that if the shared secret is derived from a
- password, the IKE implementation need not store the password in
- cleartext, but rather can store the value prf(Shared Secret,"Key Pad
- for IKEv2"), which could not be used as a password equivalent for
- protocols other than IKEv2. As noted above, deriving the shared
- secret from a password is not secure. This construction is used
- because it is anticipated that people will do it anyway. The
- management interface by which the shared secret is provided MUST
- accept ASCII strings of at least 64 octets and MUST NOT add a null
- terminator before using them as shared secrets. It MUST also accept
- a hex encoding of the shared secret. The management interface MAY
- accept other encodings if the algorithm for translating the encoding
- to a binary string is specified.
-
- There are two types of EAP authentication (described in
- Section 2.16), and each type uses different values in the AUTH
- computations shown above. If the EAP method is key-generating,
- substitute master session key (MSK) for the shared secret in the
- computation. For non-key-generating methods, substitute SK_pi and
- SK_pr, respectively, for the shared secret in the two AUTH
- computations.
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 49]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-2.16. Extensible Authentication Protocol Methods
-
- In addition to authentication using public key signatures and shared
- secrets, IKE supports authentication using methods defined in RFC
- 3748 [EAP]. Typically, these methods are asymmetric (designed for a
- user authenticating to a server), and they may not be mutual. For
- this reason, these protocols are typically used to authenticate the
- initiator to the responder and MUST be used in conjunction with a
- public-key-signature-based authentication of the responder to the
- initiator. These methods are often associated with mechanisms
- referred to as "Legacy Authentication" mechanisms.
-
- While this document references [EAP] with the intent that new methods
- can be added in the future without updating this specification, some
- simpler variations are documented here. [EAP] defines an
- authentication protocol requiring a variable number of messages.
- Extensible Authentication is implemented in IKE as additional
- IKE_AUTH exchanges that MUST be completed in order to initialize the
- IKE SA.
-
- An initiator indicates a desire to use EAP by leaving out the AUTH
- payload from the first message in the IKE_AUTH exchange. (Note that
- the AUTH payload is required for non-EAP authentication, and is thus
- not marked as optional in the rest of this document.) By including
- an IDi payload but not an AUTH payload, the initiator has declared an
- identity but has not proven it. If the responder is willing to use
- an EAP method, it will place an Extensible Authentication Protocol
- (EAP) payload in the response of the IKE_AUTH exchange and defer
- sending SAr2, TSi, and TSr until initiator authentication is complete
- in a subsequent IKE_AUTH exchange. In the case of a minimal EAP
- method, the initial SA establishment will appear as follows:
-
- Initiator Responder
- -------------------------------------------------------------------
- HDR, SAi1, KEi, Ni -->
- <-- HDR, SAr1, KEr, Nr, [CERTREQ]
- HDR, SK {IDi, [CERTREQ,]
- [IDr,] SAi2,
- TSi, TSr} -->
- <-- HDR, SK {IDr, [CERT,] AUTH,
- EAP }
- HDR, SK {EAP} -->
- <-- HDR, SK {EAP (success)}
- HDR, SK {AUTH} -->
- <-- HDR, SK {AUTH, SAr2, TSi, TSr }
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 50]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- As described in Section 2.2, when EAP is used, each pair of IKE SA
- initial setup messages will have their message numbers incremented;
- the first pair of AUTH messages will have an ID of 1, the second will
- be 2, and so on.
-
- For EAP methods that create a shared key as a side effect of
- authentication, that shared key MUST be used by both the initiator
- and responder to generate AUTH payloads in messages 7 and 8 using the
- syntax for shared secrets specified in Section 2.15. The shared key
- from EAP is the field from the EAP specification named MSK. This
- shared key generated during an IKE exchange MUST NOT be used for any
- other purpose.
-
- 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. Please see the Security Considerations
- section for more details. If EAP methods that do not generate a
- shared key are used, the AUTH payloads in messages 7 and 8 MUST be
- generated using SK_pi and SK_pr, respectively.
-
- The initiator of an IKE SA using EAP needs to be capable of extending
- the initial protocol exchange to at least ten IKE_AUTH exchanges in
- the event the responder sends notification messages and/or retries
- the authentication prompt. Once the protocol exchange defined by the
- chosen EAP authentication method has successfully terminated, the
- responder MUST send an EAP payload containing the Success message.
- Similarly, if the authentication method has failed, the responder
- MUST send an EAP payload containing the Failure message. The
- responder MAY at any time terminate the IKE exchange by sending an
- EAP payload containing the Failure message.
-
- Following such an extended exchange, the EAP AUTH payloads MUST be
- included in the two messages following the one containing the EAP
- Success message.
-
- When the initiator authentication uses EAP, it is possible that the
- contents of the IDi payload is used only for Authentication,
- Authorization, and Accounting (AAA) routing purposes and selecting
- which EAP method to use. This value may be different from the
- identity authenticated by the EAP method. It is important that
- policy lookups and access control decisions use the actual
- authenticated identity. Often the EAP server is implemented in a
- separate AAA server that communicates with the IKEv2 responder. In
- this case, the authenticated identity, if different from that in the
- IDi payload, has to be sent from the AAA server to the IKEv2
- responder.
-
-
-
-
-Kaufman, et al. Standards Track [Page 51]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-2.17. Generating Keying Material for Child SAs
-
- A single Child SA is created by the IKE_AUTH exchange, and additional
- Child SAs can optionally be created in CREATE_CHILD_SA exchanges.
- Keying material for them is generated as follows:
-
- KEYMAT = prf+(SK_d, Ni | Nr)
-
- Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this
- request is the first Child SA created or the fresh Ni and Nr from the
- CREATE_CHILD_SA exchange if this is a subsequent creation.
-
- For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman
- exchange, the keying material is defined as:
-
- KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )
-
- where g^ir (new) is the shared secret from the ephemeral Diffie-
- Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
- octet string in big endian order padded with zeros in the high-order
- bits if necessary to make it the length of the modulus).
-
- A single CHILD_SA negotiation may result in multiple Security
- Associations. ESP and AH SAs exist in pairs (one in each direction),
- so two SAs are created in a single Child SA negotiation for them.
- Furthermore, Child SA negotiation may include some future IPsec
- protocol(s) in addition to, or instead of, ESP or AH (for example,
- ROHC_INTEG as described in [ROHCV2]). In any case, keying material
- for each Child SA MUST be taken from the expanded KEYMAT using the
- following rules:
-
- o All keys for SAs carrying data from the initiator to the responder
- are taken before SAs going from the responder to the initiator.
-
- o If multiple IPsec protocols are negotiated, keying material for
- each Child SA is taken in the order in which the protocol headers
- will appear in the encapsulated packet.
-
- o If an IPsec protocol requires multiple keys, the order in which
- they are taken from the SA's keying material needs to be described
- in the protocol's specification. For ESP and AH, [IPSECARCH]
- defines the order, namely: the encryption key (if any) MUST be
- taken from the first bits and the integrity key (if any) MUST be
- taken from the remaining bits.
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 52]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Each cryptographic algorithm takes a fixed number of bits of keying
- material specified as part of the algorithm, or negotiated in SA
- payloads (see Section 2.13 for description of key lengths, and
- Section 3.3.5 for the definition of the Key Length transform
- attribute).
-
-2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange
-
- The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA
- (see Sections 1.3.2 and 2.8). New initiator and responder SPIs are
- supplied in the SPI fields in the Proposal structures inside the
- Security Association (SA) payloads (not the SPI fields in the IKE
- header). The TS payloads are omitted when rekeying an IKE SA.
- SKEYSEED for the new IKE SA is computed using SK_d from the existing
- IKE SA as follows:
-
- SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr)
-
- where g^ir (new) is the shared secret from the ephemeral Diffie-
- Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
- octet string in big endian order padded with zeros if necessary to
- make it the length of the modulus) and Ni and Nr are the two nonces
- stripped of any headers.
-
- The old and new IKE SA may have selected a different PRF. Because
- the rekeying exchange belongs to the old IKE SA, it is the old IKE
- SA's PRF that is used to generate SKEYSEED.
-
- The main reason for rekeying the IKE SA is to ensure that the
- compromise of old keying material does not provide information about
- the current keys, or vice versa. Therefore, implementations MUST
- perform a new Diffie-Hellman exchange when rekeying the IKE SA. In
- other words, an initiator MUST NOT propose the value "NONE" for the
- Diffie-Hellman transform, and a responder MUST NOT accept such a
- proposal. This means that a successful exchange rekeying the IKE SA
- always includes the KEi/KEr payloads.
-
- The new IKE SA MUST reset its message counters to 0.
-
- SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as
- specified in Section 2.14, using SPIi, SPIr, Ni, and Nr from the new
- exchange, and using the new IKE SA's PRF.
-
-2.19. Requesting an Internal Address on a Remote Network
-
- Most commonly occurring in the endpoint-to-security-gateway scenario,
- an endpoint may need an IP address in the network protected by the
- security gateway and may need to have that address dynamically
-
-
-
-Kaufman, et al. Standards Track [Page 53]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- assigned. A request for such a temporary address can be included in
- any request to create a Child SA (including the implicit request in
- message 3) by including a CP payload. Note, however, it is usual to
- only assign one IP address during the IKE_AUTH exchange. That
- address persists at least until the deletion of the IKE SA.
-
- This function provides address allocation to an IPsec Remote Access
- Client (IRAC) trying to tunnel into a network protected by an IPsec
- Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an
- IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled
- address (and optionally other information concerning the protected
- network) in the IKE_AUTH exchange. The IRAS may procure an address
- for the IRAC from any number of sources such as a DHCP/BOOTP
- (Bootstrap Protocol) server or its own address pool.
-
- Initiator Responder
- -------------------------------------------------------------------
- HDR, SK {IDi, [CERT,]
- [CERTREQ,] [IDr,] AUTH,
- CP(CFG_REQUEST), SAi2,
- TSi, TSr} -->
- <-- HDR, SK {IDr, [CERT,] AUTH,
- CP(CFG_REPLY), SAr2,
- TSi, TSr}
-
- In all cases, the CP payload MUST be inserted before the SA payload.
- In variations of the protocol where there are multiple IKE_AUTH
- exchanges, the CP payloads MUST be inserted in the messages
- containing the SA payloads.
-
- CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute
- (either IPv4 or IPv6) but MAY contain any number of additional
- attributes the initiator wants returned in the response.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 54]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- For example, message from initiator to responder:
-
- CP(CFG_REQUEST)=
- INTERNAL_ADDRESS()
- TSi = (0, 0-65535,0.0.0.0-255.255.255.255)
- TSr = (0, 0-65535,0.0.0.0-255.255.255.255)
-
- NOTE: Traffic Selectors contain (protocol, port range, address
- range).
-
- Message from responder to initiator:
-
- CP(CFG_REPLY)=
- INTERNAL_ADDRESS(192.0.2.202)
- INTERNAL_NETMASK(255.255.255.0)
- INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
- TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
- TSr = (0, 0-65535,192.0.2.0-192.0.2.255)
-
- All returned values will be implementation dependent. As can be seen
- in the above example, the IRAS MAY also send other attributes that
- were not included in CP(CFG_REQUEST) and MAY ignore the non-
- mandatory attributes that it does not support.
-
- The responder MUST NOT send a CFG_REPLY without having first received
- a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS
- to perform an unnecessary configuration lookup if the IRAC cannot
- process the REPLY.
-
- In the case where the IRAS's configuration requires that CP be used
- for a given identity IDi, but IRAC has failed to send a
- CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child
- SA creation with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED
- is not fatal to the IKE SA; it simply causes the Child SA creation to
- fail. The initiator can fix this by later starting a new
- Configuration payload request. There is no associated data in the
- FAILED_CP_REQUIRED error.
-
-2.20. Requesting the Peer's Version
-
- An IKE peer wishing to inquire about the other peer's IKE software
- version information MAY use the method below. This is an example of
- a configuration request within an INFORMATIONAL exchange, after the
- IKE SA and first Child SA have been created.
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 55]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- An IKE implementation MAY decline to give out version information
- prior to authentication or even after authentication in case some
- implementation is known to have some security weakness. In that
- case, it MUST either return an empty string or no CP payload if CP is
- not supported.
-
- Initiator Responder
- -------------------------------------------------------------------
- HDR, SK{CP(CFG_REQUEST)} -->
- <-- HDR, SK{CP(CFG_REPLY)}
-
- CP(CFG_REQUEST)=
- APPLICATION_VERSION("")
-
- CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar
- Inc.")
-
-2.21. Error Handling
-
- There are many kinds of errors that can occur during IKE processing.
- The general rule is that if a request is received that is badly
- formatted, or unacceptable for reasons of policy (such as no matching
- cryptographic algorithms), the response contains a Notify payload
- indicating the error. The decision whether or not to send such a
- response depends whether or not there is an authenticated IKE SA.
-
- If there is an error parsing or processing a response packet, the
- general rule is to not send back any error message because responses
- should not generate new requests (and a new request would be the only
- way to send back an error message). Such errors in parsing or
- processing response packets should still cause the recipient to clean
- up the IKE state (for example, by sending a Delete for a bad SA).
-
- Only authentication failures (AUTHENTICATION_FAILED and EAP failure)
- and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE
- SA without requiring an explicit INFORMATIONAL exchange carrying a
- Delete payload. Other error conditions MAY require such an exchange
- if policy dictates that this is needed. If the exchange is
- terminated with EAP Failure, an AUTHENTICATION_FAILED notification is
- not sent.
-
-2.21.1. Error Handling in IKE_SA_INIT
-
- Errors that occur before a cryptographically protected IKE SA is
- established need to be handled very carefully. There is a trade-off
- between wanting to help the peer to diagnose a problem and thus
- responding to the error and wanting to avoid being part of a DoS
- attack based on forged messages.
-
-
-
-Kaufman, et al. Standards Track [Page 56]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- In an IKE_SA_INIT exchange, any error notification causes the
- exchange to fail. Note that some error notifications such as COOKIE,
- INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent
- successful exchange. Because all error notifications are completely
- unauthenticated, the recipient should continue trying for some time
- before giving up. The recipient should not immediately act based on
- the error notification unless corrective actions are defined in this
- specification, such as for COOKIE, INVALID_KE_PAYLOAD, and
- INVALID_MAJOR_VERSION.
-
-2.21.2. Error Handling in IKE_AUTH
-
- All errors that occur in an IKE_AUTH exchange, causing the
- authentication to fail for whatever reason (invalid shared secret,
- invalid ID, untrusted certificate issuer, revoked or expired
- certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED
- notification. If the error occurred on the responder, the
- notification is returned in the protected response, and is usually
- the only payload in that response. Although the IKE_AUTH messages
- are encrypted and integrity protected, if the peer receiving this
- notification has not authenticated the other end yet, that peer needs
- to treat the information with caution.
-
- If the error occurs on the initiator, the notification MAY be
- returned in a separate INFORMATIONAL exchange, usually with no other
- payloads. This is an exception for the general rule of not starting
- new exchanges based on errors in responses.
-
- Note, however, that request messages that contain an unsupported
- critical payload, or where the whole message is malformed (rather
- than just bad payload contents), MUST be rejected in their entirety,
- and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or
- INVALID_SYNTAX Notification sent as a response. The receiver should
- not verify the payloads related to authentication in this case.
-
- If authentication has succeeded in the IKE_AUTH exchange, the IKE SA
- is established; however, establishing the Child SA or requesting
- configuration information may still fail. This failure does not
- automatically cause the IKE SA to be deleted. Specifically, a
- responder may include all the payloads associated with authentication
- (IDr, CERT, and AUTH) while sending error notifications for the
- piggybacked exchanges (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN, and so
- on), and the initiator MUST NOT fail the authentication because of
- this. The initiator MAY, of course, for reasons of policy later
- delete such an IKE SA.
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 57]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately
- following it (in case an error happened when processing a response to
- IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and
- AUTHENTICATION_FAILED notifications are the only ones to cause the
- IKE SA to be deleted or not created, without a Delete payload.
- Extension documents may define new error notifications with these
- semantics, but MUST NOT use them unless the peer has been shown to
- understand them, such as by using the Vendor ID payload.
-
-2.21.3. Error Handling after IKE SA is Authenticated
-
- After the IKE SA is authenticated, all requests having errors MUST
- result in a response notifying about the error.
-
- In normal situations, there should not be cases where a valid
- response from one peer results in an error situation in the other
- peer, so there should not be any reason for a peer to send error
- messages to the other end except as a response. Because sending such
- error messages as an INFORMATIONAL exchange might lead to further
- errors that could cause loops, such errors SHOULD NOT be sent. If
- errors are seen that indicate that the peers do not have the same
- state, it might be good to delete the IKE SA to clean up state and
- start over.
-
- If a peer parsing a request notices that it is badly formatted (after
- it has passed the message authentication code checks and window
- checks) and it returns an INVALID_SYNTAX notification, then this
- error notification is considered fatal in both peers, meaning that
- the IKE SA is deleted without needing an explicit Delete payload.
-
-2.21.4. Error Handling Outside IKE SA
-
- A node needs to limit the rate at which it will send messages in
- response to unprotected messages.
-
- If a node receives a message on UDP port 500 or 4500 outside the
- context of an IKE SA known to it (and the message is not a request to
- start an IKE SA), this may be the result of a recent crash of the
- node. If the message is marked as a response, the node can audit the
- suspicious event but MUST NOT respond. If the message is marked as a
- request, the node can audit the suspicious event and MAY send a
- response. If a response is sent, the response MUST be sent to the IP
- address and port from where it came with the same IKE SPIs and the
- Message ID copied. The response MUST NOT be cryptographically
- protected and MUST contain an INVALID_IKE_SPI Notify payload. The
- INVALID_IKE_SPI notification indicates an IKE message was received
- with an unrecognized destination SPI; this usually indicates that the
- recipient has rebooted and forgotten the existence of an IKE SA.
-
-
-
-Kaufman, et al. Standards Track [Page 58]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- A peer receiving such an unprotected Notify payload MUST NOT respond
- and MUST NOT change the state of any existing SAs. The message might
- be a forgery or might be a response that a genuine correspondent was
- tricked into sending. A node should treat such a message (and also a
- network message like ICMP destination unreachable) as a hint that
- there might be problems with SAs to that IP address and should
- initiate a liveness check for any such IKE SA. An implementation
- SHOULD limit the frequency of such tests to avoid being tricked into
- participating in a DoS attack.
-
- If an error occurs outside the context of an IKE request (e.g., the
- node is getting ESP messages on a nonexistent SPI), the node SHOULD
- initiate an INFORMATIONAL exchange with a Notify payload describing
- the problem.
-
- A node receiving a suspicious message from an IP address (and port,
- if NAT traversal is used) with which it has an IKE SA SHOULD send an
- IKE Notify payload in an IKE INFORMATIONAL exchange over that SA.
- The recipient MUST NOT change the state of any SAs as a result, but
- may wish to audit the event to aid in diagnosing malfunctions.
-
-2.22. IPComp
-
- Use of IP Compression [IP-COMP] can be negotiated as part of the
- setup of a Child SA. While IP Compression involves an extra header
- in each packet and a compression parameter index (CPI), the virtual
- "compression association" has no life outside the ESP or AH SA that
- contains it. Compression associations disappear when the
- corresponding ESP or AH SA goes away. It is not explicitly mentioned
- in any Delete payload.
-
- Negotiation of IP Compression is separate from the negotiation of
- cryptographic parameters associated with a Child SA. A node
- requesting a Child SA MAY advertise its support for one or more
- compression algorithms through one or more Notify payloads of type
- IPCOMP_SUPPORTED. This Notify message may be included only in a
- message containing an SA payload negotiating a Child SA and indicates
- a willingness by its sender to use IPComp on this SA. The response
- MAY indicate acceptance of a single compression algorithm with a
- Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT
- occur in messages that do not contain SA payloads.
-
- The data associated with this Notify message includes a two-octet
- IPComp CPI followed by a one-octet Transform ID optionally followed
- by attributes whose length and format are defined by that Transform
- ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED
- notifications to indicate multiple supported algorithms. A message
- accepting an SA may contain at most one.
-
-
-
-Kaufman, et al. Standards Track [Page 59]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- The Transform IDs are listed here. The values in the following table
- are only current as of the publication date of RFC 4306. Other
- values may have been added since then or will be added after the
- publication of this document. Readers should refer to [IKEV2IANA]
- for the latest values.
-
- Name Number Defined In
- -------------------------------------
- IPCOMP_OUI 1
- IPCOMP_DEFLATE 2 RFC 2394
- IPCOMP_LZS 3 RFC 2395
- IPCOMP_LZJH 4 RFC 3051
-
- Although there has been discussion of allowing multiple compression
- algorithms to be accepted and to have different compression
- algorithms available for the two directions of a Child SA,
- implementations of this specification MUST NOT accept an IPComp
- algorithm that was not proposed, MUST NOT accept more than one, and
- MUST NOT compress using an algorithm other than one proposed and
- accepted in the setup of the Child SA.
-
- A side effect of separating the negotiation of IPComp from
- cryptographic parameters is that it is not possible to propose
- multiple cryptographic suites and propose IP Compression with some of
- them but not others.
-
- In some cases, Robust Header Compression (ROHC) may be more
- appropriate than IP Compression. [ROHCV2] defines the use of ROHC
- with IKEv2 and IPsec.
-
-2.23. NAT Traversal
-
- Network Address Translation (NAT) gateways are a controversial
- subject. This section briefly describes what they are and how they
- are likely to act on IKE traffic. Many people believe that NATs are
- evil and that we should not design our protocols so as to make them
- work better. IKEv2 does specify some unintuitive processing rules in
- order that NATs are more likely to work.
-
- NATs exist primarily because of the shortage of IPv4 addresses,
- though there are other rationales. IP nodes that are "behind" a NAT
- have IP addresses that are not globally unique, but rather are
- assigned from some space that is unique within the network behind the
- NAT but that are likely to be reused by nodes behind other NATs.
- Generally, nodes behind NATs can communicate with other nodes behind
- the same NAT and with nodes with globally unique addresses, but not
- with nodes behind other NATs. There are exceptions to that rule.
- When those nodes make connections to nodes on the real Internet, the
-
-
-
-Kaufman, et al. Standards Track [Page 60]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- NAT gateway "translates" the IP source address to an address that
- will be routed back to the gateway. Messages to the gateway from the
- Internet have their destination addresses "translated" to the
- internal address that will route the packet to the correct endnode.
-
- NATs are designed to be "transparent" to endnodes. Neither software
- on the node behind the NAT nor the node on the Internet requires
- modification to communicate through the NAT. Achieving this
- transparency is more difficult with some protocols than with others.
- Protocols that include IP addresses of the endpoints within the
- payloads of the packet will fail unless the NAT gateway understands
- the protocol and modifies the internal references as well as those in
- the headers. Such knowledge is inherently unreliable, is a network
- layer violation, and often results in subtle problems.
-
- Opening an IPsec connection through a NAT introduces special
- problems. If the connection runs in transport mode, changing the IP
- addresses on packets will cause the checksums to fail and the NAT
- cannot correct the checksums because they are cryptographically
- protected. Even in tunnel mode, there are routing problems because
- transparently translating the addresses of AH and ESP packets
- requires special logic in the NAT and that logic is heuristic and
- unreliable in nature. For that reason, IKEv2 will use UDP
- encapsulation of IKE and ESP packets. This encoding is slightly less
- efficient but is easier for NATs to process. In addition, firewalls
- may be configured to pass UDP-encapsulated IPsec traffic but not
- plain, unencapsulated ESP/AH or vice versa.
-
- It is a common practice of NATs to translate TCP and UDP port numbers
- as well as addresses and use the port numbers of inbound packets to
- decide which internal node should get a given packet. For this
- reason, even though IKE packets MUST be sent to and from UDP port 500
- or 4500, they MUST be accepted coming from any port and responses
- MUST be sent to the port from whence they came. This is because the
- ports may be modified as the packets pass through NATs. Similarly,
- IP addresses of the IKE endpoints are generally not included in the
- IKE payloads because the payloads are cryptographically protected and
- could not be transparently modified by NATs.
-
- Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec
- endpoint that discovers a NAT between it and its correspondent (as
- described below) MUST send all subsequent traffic from port 4500,
- which NATs should not treat specially (as they might with port 500).
-
- An initiator can use port 4500 for both IKE and ESP, regardless of
- whether or not there is a NAT, even at the beginning of IKE. When
- either side is using port 4500, sending ESP with UDP encapsulation is
- not required, but understanding received UDP-encapsulated ESP packets
-
-
-
-Kaufman, et al. Standards Track [Page 61]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- is required. UDP encapsulation MUST NOT be done on port 500. If
- Network Address Translation Traversal (NAT-T) is supported (that is,
- if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT),
- all devices MUST be able to receive and process both UDP-encapsulated
- ESP and non-UDP-encapsulated ESP packets at any time. Either side
- can decide whether or not to use UDP encapsulation for ESP
- irrespective of the choice made by the other side. However, if a NAT
- is detected, both devices MUST use UDP encapsulation for ESP.
-
- The specific requirements for supporting NAT traversal [NATREQ] are
- listed below. Support for NAT traversal is optional. In this
- section only, requirements listed as MUST apply only to
- implementations supporting NAT traversal.
-
- o Both the IKE initiator and responder MUST include in their
- IKE_SA_INIT packets Notify payloads of type
- NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP. Those
- payloads can be used to detect if there is NAT between the hosts,
- and which end is behind the NAT. The location of the payloads in
- the IKE_SA_INIT packets is just after the Ni and Nr payloads
- (before the optional CERTREQ payload).
-
- o The data associated with the NAT_DETECTION_SOURCE_IP notification
- is a SHA-1 digest of the SPIs (in the order they appear in the
- header), IP address, and port from which this packet was sent.
- There MAY be multiple NAT_DETECTION_SOURCE_IP payloads in a
- message if the sender does not know which of several network
- attachments will be used to send the packet.
-
- o The data associated with the NAT_DETECTION_DESTINATION_IP
- notification is a SHA-1 digest of the SPIs (in the order they
- appear in the header), IP address, and port to which this packet
- was sent.
-
- o The recipient of either the NAT_DETECTION_SOURCE_IP or
- NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied
- value to a SHA-1 hash of the SPIs, source or recipient IP address
- (respectively), address, and port, and if they don't match, it
- SHOULD enable NAT traversal. In the case there is a mismatch of
- the NAT_DETECTION_SOURCE_IP hash with all of the
- NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY
- reject the connection attempt if NAT traversal is not supported.
- In the case of a mismatching NAT_DETECTION_DESTINATION_IP hash, it
- means that the system receiving the NAT_DETECTION_DESTINATION_IP
- payload is behind a NAT and that system SHOULD start sending
- keepalive packets as defined in [UDPENCAPS]; alternately, it MAY
- reject the connection attempt if NAT traversal is not supported.
-
-
-
-
-Kaufman, et al. Standards Track [Page 62]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches
- the expected value of the source IP and port found from the IP
- header of the packet containing the payload, it means that the
- system sending those payloads is behind a NAT (i.e., someone along
- the route changed the source address of the original packet to
- match the address of the NAT box). In this case, the system
- receiving the payloads should allow dynamic updates of the other
- systems' IP address, as described later.
-
- o The IKE initiator MUST check the NAT_DETECTION_SOURCE_IP or
- NAT_DETECTION_DESTINATION_IP payloads if present, and if they do
- not match the addresses in the outer packet, MUST tunnel all
- future IKE and ESP packets associated with this IKE SA over UDP
- port 4500.
-
- o To tunnel IKE packets over UDP port 4500, the IKE header has four
- octets of zero prepended and the result immediately follows the
- UDP header. To tunnel ESP packets over UDP port 4500, the ESP
- header immediately follows the UDP header. Since the first four
- octets of the ESP header contain the SPI, and the SPI cannot
- validly be zero, it is always possible to distinguish ESP and IKE
- messages.
-
- o Implementations MUST process received UDP-encapsulated ESP packets
- even when no NAT was detected.
-
- o The original source and destination IP address required for the
- transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS])
- are obtained from the Traffic Selectors associated with the
- exchange. In the case of transport mode NAT traversal, the
- Traffic Selectors MUST contain exactly one IP address, which is
- then used as the original IP address. This is covered in greater
- detail in Section 2.23.1.
-
- o There are cases where a NAT box decides to remove mappings that
- are still alive (for example, the keepalive interval is too long,
- or the NAT box is rebooted). This will be apparent to a host if
- it receives a packet whose integrity protection validates, but has
- a different port, address, or both from the one that was
- associated with the SA in the validated packet. When such a
- validated packet is found, a host that does not support other
- methods of recovery such as IKEv2 Mobility and Multihoming
- (MOBIKE) [MOBIKE], and that is not behind a NAT, SHOULD send all
- packets (including retransmission packets) to the IP address and
- port in the validated packet, and SHOULD store this as the new
- address and port combination for the SA (that is, they SHOULD
- dynamically update the address). A host behind a NAT SHOULD NOT
- do this type of dynamic address update if a validated packet has
-
-
-
-Kaufman, et al. Standards Track [Page 63]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- different port and/or address values because it opens a possible
- DoS attack (such as allowing an attacker to break the connection
- with a single packet). Also, dynamic address update should only
- be done in response to a new packet; otherwise, an attacker can
- revert the addresses with old replayed packets. Because of this,
- dynamic updates can only be done safely if replay protection is
- enabled. When IKEv2 is used with MOBIKE, dynamically updating the
- addresses described above interferes with MOBIKE's way of
- recovering from the same situation. See Section 3.8 of [MOBIKE]
- for more information.
-
-2.23.1. Transport Mode NAT Traversal
-
- Transport mode used with NAT Traversal requires special handling of
- the Traffic Selectors used in the IKEv2. The complete scenario looks
- like:
-
- +------+ +------+ +------+ +------+
- |Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server|
- |node |<------>| A |<---------->| B |<------->| |
- +------+ +------+ +------+ +------+
-
- (Other scenarios are simplifications of this complex case, so this
- discussion uses the complete scenario.)
-
- In this scenario, there are two address translating NATs: NAT A and
- NAT B. NAT A is a dynamic NAT that maps the client's source address
- IP1 to IPN1. NAT B is a static NAT configured so that connections
- coming to IPN2 address are mapped to the gateway's address IP2, that
- is, IPN2 destination address is mapped to IP2. This allows the
- client to connect to a server by connecting to the IPN2. NAT B does
- not necessarily need to be a static NAT, but the client needs to know
- how to connect to the server, and it can only do that if it somehow
- knows the outer address of the NAT B, that is, the IPN2 address. If
- NAT B is a static NAT, then its address can be configured to the
- client's configuration. Another option would be to find it using
- some other protocol (like DNS), but that is outside of scope of
- IKEv2.
-
- In this scenario, both the client and server are configured to use
- transport mode for the traffic originating from the client node and
- destined to the server.
-
- When the client starts creating the IKEv2 SA and Child SA for sending
- traffic to the server, it may have a triggering packet with source IP
- address of IP1, and a destination IP address of IPN2. Its Peer
- Authorization Database (PAD) and SPD needs to have a configuration
- matching those addresses (or wildcard entries covering them).
-
-
-
-Kaufman, et al. Standards Track [Page 64]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Because this is transport mode, it uses exactly same addresses as the
- Traffic Selectors and outer IP address of the IKE packets. For
- transport mode, it MUST use exactly one IP address in the TSi and TSr
- payloads. It can have multiple Traffic Selectors if it has, for
- example, multiple port ranges that it wants to negotiate, but all TSi
- entries must use the IP1-IP1 range as the IP addresses, and all TSr
- entries must have the IPN2-IPN2 range as IP addresses. The first
- Traffic Selector of TSi and TSr SHOULD have very specific Traffic
- Selectors including protocol and port numbers, such as from the
- packet triggering the request.
-
- NAT A will then replace the source address of the IKE packet from IP1
- to IPN1, and NAT B will replace the destination address of the IKE
- packet from IPN2 to IP2, so when the packet arrives to the server it
- will still have the exactly same Traffic Selectors that were sent by
- the client, but the IP address of the IKE packet has been replaced by
- IPN1 and IP2.
-
- When the server receives this packet, it normally looks in the Peer
- Authorization Database (PAD) described in RFC 4301 [IPSECARCH] based
- on the ID and then searches the SPD based on the Traffic Selectors.
- Because IP1 does not really mean anything to the server (it is the
- address client has behind the NAT), it is useless to do a lookup
- based on that if transport mode is used. On the other hand, the
- server cannot know whether transport mode is allowed by its policy
- before it finds the matching SPD entry.
-
- In this case, the server should first check that the initiator
- requested transport mode, and then do address substitution on the
- Traffic Selectors. It needs to first store the old Traffic Selector
- IP addresses to be used later for the incremental checksum fixup (the
- IP address in the TSi can be stored as the original source address
- and the IP address in the TSr can be stored as the original
- destination address). After that, if the other end was detected as
- being behind a NAT, the server replaces the IP address in TSi
- payloads with the IP address obtained from the source address of the
- IKE packet received (that is, it replaces IP1 in TSi with IPN1). If
- the server's end was detected to be behind NAT, it replaces the IP
- address in the TSr payloads with the IP address obtained from the
- destination address of the IKE packet received (that is, it replaces
- IPN2 in TSr with IP2).
-
- After this address substitution, both the Traffic Selectors and the
- IKE UDP source/destination addresses look the same, and the server
- does SPD lookup based on those new Traffic Selectors. If an entry is
- found and it allows transport mode, then that entry is used. If an
- entry is found but it does not allow transport mode, then the server
- MAY undo the address substitution and redo the SPD lookup using the
-
-
-
-Kaufman, et al. Standards Track [Page 65]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- original Traffic Selectors. If the second lookup succeeds, the
- server will create an SA in tunnel mode using real Traffic Selectors
- sent by the other end.
-
- This address substitution in transport mode is needed because the SPD
- is looked up using the addresses that will be seen by the local host.
- This also will make sure the Security Association Database (SAD)
- entries for the tunnel exit checks and return packets is added using
- the addresses as seen by the local operating system stack.
-
- The most common case is that the server's SPD will contain wildcard
- entries matching any addresses, but this also allows making different
- SPD entries, for example, for different known NATs' outer addresses.
-
- After the SPD lookup, the server will do Traffic Selector narrowing
- based on the SPD entry it found. It will again use the already
- substituted Traffic Selectors, and it will thus send back Traffic
- Selectors having IPN1 and IP2 as their IP addresses; it can still
- narrow down the protocol number or port ranges used by the Traffic
- Selectors. The SAD entry created for the Child SA will have the
- addresses as seen by the server, namely IPN1 and IP2.
-
- When the client receives the server's response to the Child SA, it
- will do similar processing. If the transport mode SA was created,
- the client can store the original returned Traffic Selectors as
- original source and destination addresses. It will replace the IP
- addresses in the Traffic Selectors with the ones from the IP header
- of the IKE packet: it will replace IPN1 with IP1 and IP2 with IPN2.
- Then, it will use those Traffic Selectors when verifying the SA
- against sent Traffic Selectors, and when installing the SAD entry.
-
- A summary of the rules for NAT traversal in transport mode is:
-
- For the client proposing transport mode:
-
- - The TSi entries MUST have exactly one IP address, and that MUST
- match the source address of the IKE SA.
-
- - The TSr entries MUST have exactly one IP address, and that MUST
- match the destination address of the IKE SA.
-
- - The first TSi and TSr Traffic Selectors SHOULD have very specific
- Traffic Selectors including protocol and port numbers, such as
- from the packet triggering the request.
-
- - There MAY be multiple TSi and TSr entries.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 66]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- - If transport mode for the SA was selected (that is, if the server
- included USE_TRANSPORT_MODE notification in its response):
-
- - Store the original Traffic Selectors as the received source and
- destination address.
-
- - If the server is behind a NAT, substitute the IP address in the
- TSr entries with the remote address of the IKE SA.
-
- - If the client is behind a NAT, substitute the IP address in the
- TSi entries with the local address of the IKE SA.
-
- - Do address substitution before using those Traffic Selectors
- for anything other than storing original content of them.
- This includes verification that Traffic Selectors were narrowed
- correctly by the other end, creation of the SAD entry, and so on.
-
- For the responder, when transport mode is proposed by client:
-
- - Store the original Traffic Selector IP addresses as received source
- and destination address, in case undo address
- substitution is needed, to use as the "real source and destination
- address" specified by [UDPENCAPS], and for TCP/UDP checksum fixup.
-
- - If the client is behind a NAT, substitute the IP address in the
- TSi entries with the remote address of the IKE SA.
-
- - If the server is behind a NAT, substitute the IP address in the
- TSr entries with the local address of the IKE SA.
-
- - Do PAD and SPD lookup using the ID and substituted Traffic
- Selectors.
-
- - If no SPD entry was found, or if found SPD entry does not
- allow transport mode, undo the Traffic Selector substitutions.
- Do PAD and SPD lookup again using the ID and original Traffic
- Selectors, but also searching for tunnel mode SPD entry (that
- is, fall back to tunnel mode).
-
- - However, if a transport mode SPD entry was found, do normal
- traffic selection narrowing based on the substituted Traffic
- Selectors and SPD entry. Use the resulting Traffic Selectors when
- creating SAD entries, and when sending Traffic Selectors back to
- the client.
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 67]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-2.24. Explicit Congestion Notification (ECN)
-
- When IPsec tunnels behave as originally specified in [IPSECARCH-OLD],
- ECN usage is not appropriate for the outer IP headers because tunnel
- decapsulation processing discards ECN congestion indications to the
- detriment of the network. ECN support for IPsec tunnels for IKEv1-
- based IPsec requires multiple operating modes and negotiation (see
- [ECN]). IKEv2 simplifies this situation by requiring that ECN be
- usable in the outer IP headers of all tunnel mode Child SAs created
- by IKEv2. Specifically, tunnel encapsulators and decapsulators for
- all tunnel mode SAs created by IKEv2 MUST support the ECN full-
- functionality option for tunnels specified in [ECN] and MUST
- implement the tunnel encapsulation and decapsulation processing
- specified in [IPSECARCH] to prevent discarding of ECN congestion
- indications.
-
-2.25. Exchange Collisions
-
- Because IKEv2 exchanges can be initiated by either peer, it is
- possible that two exchanges affecting the same SA partly overlap.
- This can lead to a situation where the SA state information is
- temporarily not synchronized, and a peer can receive a request that
- it cannot process in a normal fashion.
-
- Obviously, using a window size greater than 1 leads to more complex
- situations, especially if requests are processed out of order. This
- section concentrates on problems that can arise even with a window
- size of 1, and recommends solutions.
-
- A TEMPORARY_FAILURE notification SHOULD be sent when a peer receives
- a request that cannot be completed due to a temporary condition such
- as a rekeying operation. When a peer receives a TEMPORARY_FAILURE
- notification, it MUST NOT immediately retry the operation; it MUST
- wait so that the sender may complete whatever operation caused the
- temporary condition. The recipient MAY retry the request one or more
- times over a period of several minutes. If a peer continues to
- receive TEMPORARY_FAILURE on the same IKE SA after several minutes,
- it SHOULD conclude that the state information is out of sync and
- close the IKE SA.
-
- A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives
- a request to rekey a Child SA that does not exist. The SA that the
- initiator attempted to rekey is indicated by the SPI field in the
- Notify payload, which is copied from the SPI field in the REKEY_SA
- notification. A peer that receives a CHILD_SA_NOT_FOUND notification
- SHOULD silently delete the Child SA (if it still exists) and send a
- request to create a new Child SA from scratch (if the Child SA does
- not yet exist).
-
-
-
-Kaufman, et al. Standards Track [Page 68]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-2.25.1. Collisions while Rekeying or Closing Child SAs
-
- If a peer receives a request to rekey a Child SA that it is currently
- trying to close, it SHOULD reply with TEMPORARY_FAILURE. If a peer
- receives a request to rekey a Child SA that it is currently rekeying,
- it SHOULD reply as usual, and SHOULD prepare to close redundant SAs
- later based on the nonces (see Section 2.8.1). If a peer receives a
- request to rekey a Child SA that does not exist, it SHOULD reply with
- CHILD_SA_NOT_FOUND.
-
- If a peer receives a request to close a Child SA that it is currently
- trying to close, it SHOULD reply without a Delete payload (see
- Section 1.4.1). If a peer receives a request to close a Child SA
- that it is currently rekeying, it SHOULD reply as usual, with a
- Delete payload. If a peer receives a request to close a Child SA
- that does not exist, it SHOULD reply without a Delete payload.
-
- If a peer receives a request to rekey the IKE SA, and it is currently
- creating, rekeying, or closing a Child SA of that IKE SA, it SHOULD
- reply with TEMPORARY_FAILURE.
-
-2.25.2. Collisions while Rekeying or Closing IKE SAs
-
- If a peer receives a request to rekey an IKE SA that it is currently
- rekeying, it SHOULD reply as usual, and SHOULD prepare to close
- redundant SAs and move inherited Child SAs later based on the nonces
- (see Section 2.8.2). If a peer receives a request to rekey an IKE SA
- that it is currently trying to close, it SHOULD reply with
- TEMPORARY_FAILURE.
-
- If a peer receives a request to close an IKE SA that it is currently
- rekeying, it SHOULD reply as usual, and forget about its own rekeying
- request. If a peer receives a request to close an IKE SA that it is
- currently trying to close, it SHOULD reply as usual, and forget about
- its own close request.
-
- If a peer receives a request to create or rekey a Child SA when it is
- currently rekeying the IKE SA, it SHOULD reply with
- TEMPORARY_FAILURE. If a peer receives a request to delete a Child SA
- when it is currently rekeying the IKE SA, it SHOULD reply as usual,
- with a Delete payload.
-
-3. Header and Payload Formats
-
- In the tables in this section, some cryptographic primitives and
- configuration attributes are marked as "UNSPECIFIED". These are
- items for which there are no known specifications and therefore
- interoperability is currently impossible. A future specification may
-
-
-
-Kaufman, et al. Standards Track [Page 69]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- describe their use, but until such specification is made,
- implementations SHOULD NOT attempt to use items marked as
- "UNSPECIFIED" in implementations that are meant to be interoperable.
-
-3.1. The IKE Header
-
- IKE messages use UDP ports 500 and/or 4500, with one IKE message per
- UDP datagram. Information from the beginning of the packet through
- the UDP header is largely ignored except that the IP addresses and
- UDP ports from the headers are reversed and used for return packets.
- When sent on UDP port 500, IKE messages begin immediately following
- the UDP header. When sent on UDP port 4500, IKE messages have
- prepended four octets of zero. These four octets of zeros are not
- part of the IKE message and are not included in any of the length
- fields or checksums defined by IKE. Each IKE message begins with the
- IKE header, denoted HDR in this document. Following the header are
- one or more IKE payloads each identified by a "Next Payload" field in
- the preceding payload. Payloads are identified in the order in which
- they appear in an IKE message by looking in the "Next Payload" field
- in the IKE header, and subsequently according to the "Next Payload"
- field in the IKE payload itself until a "Next Payload" field of zero
- indicates that no payloads follow. If a payload of type "Encrypted"
- is found, that payload is decrypted and its contents parsed as
- additional payloads. An Encrypted payload MUST be the last payload
- in a packet and an Encrypted payload MUST NOT contain another
- Encrypted payload.
-
- The responder's SPI in the header identifies an instance of an IKE
- Security Association. It is therefore possible for a single instance
- of IKE to multiplex distinct sessions with multiple peers, including
- multiple sessions per peer.
-
- All multi-octet fields representing integers are laid out in big
- endian order (also known as "most significant byte first", or
- "network byte order").
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 70]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- The format of the IKE header is shown in Figure 4.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | IKE SA Initiator's SPI |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | IKE SA Responder's SPI |
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Next Payload | MjVer | MnVer | Exchange Type | Flags |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Message ID |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 4: IKE Header Format
-
- o Initiator's SPI (8 octets) - A value chosen by the initiator to
- identify a unique IKE Security Association. This value MUST NOT
- be zero.
-
- o Responder's SPI (8 octets) - A value chosen by the responder to
- identify a unique IKE Security Association. This value MUST be
- zero in the first message of an IKE initial exchange (including
- repeats of that message including a cookie).
-
- o Next Payload (1 octet) - Indicates the type of payload that
- immediately follows the header. The format and value of each
- payload are defined below.
-
- o Major Version (4 bits) - Indicates the major version of the IKE
- protocol in use. Implementations based on this version of IKE
- MUST set the major version to 2. Implementations based on
- previous versions of IKE and ISAKMP MUST set the major version to
- 1. Implementations based on this version of IKE MUST reject or
- ignore messages containing a version number greater than 2 with an
- INVALID_MAJOR_VERSION notification message as described in Section
- 2.5.
-
- o Minor Version (4 bits) - Indicates the minor version of the IKE
- protocol in use. Implementations based on this version of IKE
- MUST set the minor version to 0. They MUST ignore the minor
- version number of received messages.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 71]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- o Exchange Type (1 octet) - Indicates the type of exchange being
- used. This constrains the payloads sent in each message in an
- exchange. The values in the following table are only current as
- of the publication date of RFC 4306. Other values may have been
- added since then or will be added after the publication of this
- document. Readers should refer to [IKEV2IANA] for the latest
- values.
-
- Exchange Type Value
- ----------------------------------
- IKE_SA_INIT 34
- IKE_AUTH 35
- CREATE_CHILD_SA 36
- INFORMATIONAL 37
-
- o Flags (1 octet) - Indicates specific options that are set for the
- message. Presence of options is indicated by the appropriate bit
- in the flags field being set. The bits are as follows:
-
- +-+-+-+-+-+-+-+-+
- |X|X|R|V|I|X|X|X|
- +-+-+-+-+-+-+-+-+
-
- In the description below, a bit being 'set' means its value is '1',
- while 'cleared' means its value is '0'. 'X' bits MUST be cleared
- when sending and MUST be ignored on receipt.
-
- * R (Response) - This bit indicates that this message is a
- response to a message containing the same Message ID. This bit
- MUST be cleared in all request messages and MUST be set in all
- responses. An IKE endpoint MUST NOT generate a response to a
- message that is marked as being a response (with one exception;
- see Section 2.21.2).
-
- * V (Version) - This bit indicates that the transmitter is
- capable of speaking a higher major version number of the
- protocol than the one indicated in the major version number
- field. Implementations of IKEv2 MUST clear this bit when
- sending and MUST ignore it in incoming messages.
-
- * I (Initiator) - This bit MUST be set in messages sent by the
- original initiator of the IKE SA and MUST be cleared in
- messages sent by the original responder. It is used by the
- recipient to determine which eight octets of the SPI were
- generated by the recipient. This bit changes to reflect who
- initiated the last rekey of the IKE SA.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 72]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- o Message ID (4 octets, unsigned integer) - Message identifier used
- to control retransmission of lost packets and matching of requests
- and responses. It is essential to the security of the protocol
- because it is used to prevent message replay attacks. See
- Sections 2.1 and 2.2.
-
- o Length (4 octets, unsigned integer) - Length of the total message
- (header + payloads) in octets.
-
-3.2. Generic Payload Header
-
- Each IKE payload defined in Sections 3.3 through 3.16 begins with a
- generic payload header, shown in Figure 5. Figures for each payload
- below will include the generic payload header, but for brevity, the
- description of each field will be omitted.
-
- 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 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 5: Generic Payload Header
-
- The Generic Payload Header fields are defined as follows:
-
- o Next Payload (1 octet) - Identifier for the payload type of the
- next payload in the message. If the current payload is the last
- in the message, then this field will be 0. This field provides a
- "chaining" capability whereby additional payloads can be added to
- a message by appending each one to the end of the message and
- setting the "Next Payload" field of the preceding payload to
- indicate the new payload's type. An Encrypted payload, which must
- always be the last payload of a message, is an exception. It
- contains data structures in the format of additional payloads. In
- the header of an Encrypted payload, the Next Payload field is set
- to the payload type of the first contained payload (instead of 0);
- conversely, the Next Payload field of the last contained payload
- is set to zero). The payload type values are listed here. The
- values in the following table are only current as of the
- publication date of RFC 4306. Other values may have been added
- since then or will be added after the publication of this
- document. Readers should refer to [IKEV2IANA] for the latest
- values.
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 73]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Next Payload Type Notation Value
- --------------------------------------------------
- No Next Payload 0
- Security Association SA 33
- Key Exchange KE 34
- Identification - Initiator IDi 35
- Identification - Responder IDr 36
- Certificate CERT 37
- Certificate Request CERTREQ 38
- Authentication AUTH 39
- Nonce Ni, Nr 40
- Notify N 41
- Delete D 42
- Vendor ID V 43
- Traffic Selector - Initiator TSi 44
- Traffic Selector - Responder TSr 45
- Encrypted and Authenticated SK 46
- Configuration CP 47
- Extensible Authentication EAP 48
-
- (Payload type values 1-32 should not be assigned in the
- future so that there is no overlap with the code assignments
- for IKEv1.)
-
- o Critical (1 bit) - MUST be set to zero if the sender wants the
- recipient to skip this payload if it does not understand the
- payload type code in the Next Payload field of the previous
- payload. MUST be set to one if the sender wants the recipient to
- reject this entire message if it does not understand the payload
- type. MUST be ignored by the recipient if the recipient
- understands the payload type code. MUST be set to zero for
- payload types defined in this document. Note that the critical
- bit applies to the current payload rather than the "next" payload
- whose type code appears in the first octet. The reasoning behind
- not setting the critical bit for payloads defined in this document
- is that all implementations MUST understand all payload types
- defined in this document and therefore must ignore the critical
- bit's value. Skipped payloads are expected to have valid Next
- Payload and Payload Length fields. See Section 2.5 for more
- information on this bit.
-
- o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on
- receipt.
-
- o Payload Length (2 octets, unsigned integer) - Length in octets of
- the current payload, including the generic payload header.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 74]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Many payloads contain fields marked as "RESERVED". Some payloads in
- IKEv2 (and historically in IKEv1) are not aligned to 4-octet
- boundaries.
-
-3.3. Security Association Payload
-
- The Security Association payload, denoted SA in this document, is
- used to negotiate attributes of a Security Association. Assembly of
- Security Association payloads requires great peace of mind. An SA
- payload MAY contain multiple proposals. If there is more than one,
- they MUST be ordered from most preferred to least preferred. Each
- proposal contains a single IPsec protocol (where a protocol is IKE,
- ESP, or AH), each protocol MAY contain multiple transforms, and each
- transform MAY contain multiple attributes. When parsing an SA, an
- implementation MUST check that the total Payload Length is consistent
- with the payload's internal lengths and counts. Proposals,
- Transforms, and Attributes each have their own variable-length
- encodings. They are nested such that the Payload Length of an SA
- includes the combined contents of the SA, Proposal, Transform, and
- Attribute information. The length of a Proposal includes the lengths
- of all Transforms and Attributes it contains. The length of a
- Transform includes the lengths of all Attributes it contains.
-
- The syntax of Security Associations, Proposals, Transforms, and
- Attributes is based on ISAKMP; however, the semantics are somewhat
- different. The reason for the complexity and the hierarchy is to
- allow for multiple possible combinations of algorithms to be encoded
- in a single SA. Sometimes there is a choice of multiple algorithms,
- whereas other times there is a combination of algorithms. For
- example, an initiator might want to propose using ESP with either
- (3DES and HMAC_MD5) or (AES and HMAC_SHA1).
-
- One of the reasons the semantics of the SA payload have changed from
- ISAKMP and IKEv1 is to make the encodings more compact in common
- cases.
-
- The Proposal structure contains within it a Proposal Num and an IPsec
- protocol ID. Each structure MUST have a proposal number one (1)
- greater than the previous structure. The first Proposal in the
- initiator's SA payload MUST have a Proposal Num of one (1). One
- reason to use multiple proposals is to propose both standard crypto
- ciphers and combined-mode ciphers. Combined-mode ciphers include
- both integrity and encryption in a single encryption algorithm, and
- MUST either offer no integrity algorithm or a single integrity
- algorithm of "none", with no integrity algorithm being the
- RECOMMENDED method. If an initiator wants to propose both combined-
- mode ciphers and normal ciphers, it must include two proposals: one
- will have all the combined-mode ciphers, and the other will have all
-
-
-
-Kaufman, et al. Standards Track [Page 75]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- the normal ciphers with the integrity algorithms. For example, one
- such proposal would have two proposal structures. Proposal 1 is ESP
- with AES-128, AES-192, and AES-256 bits in Cipher Block Chaining
- (CBC) mode, with either HMAC-SHA1-96 or XCBC-96 as the integrity
- algorithm; Proposal 2 is AES-128 or AES-256 in GCM mode with an
- 8-octet Integrity Check Value (ICV). Both proposals allow but do not
- require the use of ESNs (Extended Sequence Numbers). This can be
- illustrated as:
-
- SA Payload
- |
- +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
- | | 7 transforms, SPI = 0x052357bb )
- | |
- | +-- Transform ENCR ( Name = ENCR_AES_CBC )
- | | +-- Attribute ( Key Length = 128 )
- | |
- | +-- Transform ENCR ( Name = ENCR_AES_CBC )
- | | +-- Attribute ( Key Length = 192 )
- | |
- | +-- Transform ENCR ( Name = ENCR_AES_CBC )
- | | +-- Attribute ( Key Length = 256 )
- | |
- | +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
- | +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 )
- | +-- Transform ESN ( Name = ESNs )
- | +-- Transform ESN ( Name = No ESNs )
- |
- +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
- | 4 transforms, SPI = 0x35a1d6f2 )
- |
- +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
- | +-- Attribute ( Key Length = 128 )
- |
- +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
- | +-- Attribute ( Key Length = 256 )
- |
- +-- Transform ESN ( Name = ESNs )
- +-- Transform ESN ( Name = No ESNs )
-
- Each Proposal/Protocol structure is followed by one or more transform
- structures. The number of different transforms is generally
- determined by the Protocol. AH generally has two transforms:
- Extended Sequence Numbers (ESNs) and an integrity check algorithm.
- ESP generally has three: ESN, an encryption algorithm, and an
- integrity check algorithm. IKE generally has four transforms: a
- Diffie-Hellman group, an integrity check algorithm, a PRF algorithm,
-
-
-
-
-Kaufman, et al. Standards Track [Page 76]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- and an encryption algorithm. For each Protocol, the set of
- permissible transforms is assigned Transform ID numbers, which appear
- in the header of each transform.
-
- If there are multiple transforms with the same Transform Type, the
- proposal is an OR of those transforms. If there are multiple
- transforms with different Transform Types, the proposal is an AND of
- the different groups. For example, to propose ESP with (3DES or AES-
- CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two
- Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and
- two Transform Type 3 candidates (one for HMAC_MD5 and one for
- HMAC_SHA). This effectively proposes four combinations of
- algorithms. If the initiator wanted to propose only a subset of
- those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there
- is no way to encode that as multiple transforms within a single
- Proposal. Instead, the initiator would have to construct two
- different Proposals, each with two transforms.
-
- A given transform MAY have one or more Attributes. Attributes are
- necessary when the transform can be used in more than one way, as
- when an encryption algorithm has a variable key size. The transform
- would specify the algorithm and the attribute would specify the key
- size. Most transforms do not have attributes. A transform MUST NOT
- have multiple attributes of the same type. To propose alternate
- values for an attribute (for example, multiple key sizes for the AES
- encryption algorithm), an implementation MUST include multiple
- transforms with the same Transform Type each with a single Attribute.
-
- Note that the semantics of Transforms and Attributes are quite
- different from those in IKEv1. In IKEv1, a single Transform carried
- multiple algorithms for a protocol with one carried in the Transform
- and the others carried in the Attributes.
-
- 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 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ <Proposals> ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 6: Security Association Payload
-
- o Proposals (variable) - One or more proposal substructures.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 77]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- The payload type for the Security Association payload is thirty-three
- (33).
-
-3.3.1. Proposal Substructure
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 0 (last) or 2 | RESERVED | Proposal Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Proposal Num | Protocol ID | SPI Size |Num Transforms|
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ~ SPI (variable) ~
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ <Transforms> ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 7: Proposal Substructure
-
- o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the
- last Proposal Substructure in the SA. This syntax is inherited
- from ISAKMP, but is unnecessary because the last Proposal could be
- identified from the length of the SA. The value (2) corresponds
- to a payload type of Proposal in IKEv1, and the first four octets
- of the Proposal structure are designed to look somewhat like the
- header of a payload.
-
- o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on
- receipt.
-
- o Proposal Length (2 octets, unsigned integer) - Length of this
- proposal, including all transforms and attributes that follow.
-
- o Proposal Num (1 octet) - When a proposal is made, the first
- proposal in an SA payload MUST be 1, and subsequent proposals MUST
- be one more than the previous proposal (indicating an OR of the
- two proposals). When a proposal is accepted, the proposal number
- in the SA payload MUST match the number on the proposal sent that
- was accepted.
-
- o Protocol ID (1 octet) - Specifies the IPsec protocol identifier
- for the current negotiation. The values in the following table
- are only current as of the publication date of RFC 4306. Other
- values may have been added since then or will be added after the
- publication of this document. Readers should refer to [IKEV2IANA]
- for the latest values.
-
-
-
-Kaufman, et al. Standards Track [Page 78]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Protocol Protocol ID
- -----------------------------------
- IKE 1
- AH 2
- ESP 3
-
- o SPI Size (1 octet) - For an initial IKE SA negotiation, this field
- MUST be zero; the SPI is obtained from the outer header. During
- subsequent negotiations, it is equal to the size, in octets, of
- the SPI of the corresponding protocol (8 for IKE, 4 for ESP and
- AH).
-
- o Num Transforms (1 octet) - Specifies the number of transforms in
- this proposal.
-
- o SPI (variable) - The sending entity's SPI. Even if the SPI Size
- is not a multiple of 4 octets, there is no padding applied to the
- payload. When the SPI Size field is zero, this field is not
- present in the Security Association payload.
-
- o Transforms (variable) - One or more transform substructures.
-
-3.3.2. Transform Substructure
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 0 (last) or 3 | RESERVED | Transform Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |Transform Type | RESERVED | Transform ID |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ Transform Attributes ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 8: Transform Substructure
-
- o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the
- last Transform Substructure in the Proposal. This syntax is
- inherited from ISAKMP, but is unnecessary because the last
- transform could be identified from the length of the proposal.
- The value (3) corresponds to a payload type of Transform in IKEv1,
- and the first four octets of the Transform structure are designed
- to look somewhat like the header of a payload.
-
- o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
-
-
-
-
-Kaufman, et al. Standards Track [Page 79]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- o Transform Length - The length (in octets) of the Transform
- Substructure including Header and Attributes.
-
- o Transform Type (1 octet) - The type of transform being specified
- in this transform. Different protocols support different
- Transform Types. For some protocols, some of the transforms may
- be optional. If a transform is optional and the initiator wishes
- to propose that the transform be omitted, no transform of the
- given type is included in the proposal. If the initiator wishes
- to make use of the transform optional to the responder, it
- includes a transform substructure with Transform ID = 0 as one of
- the options.
-
- o Transform ID (2 octets) - The specific instance of the Transform
- Type being proposed.
-
- The Transform Type values are listed below. The values in the
- following table are only current as of the publication date of RFC
- 4306. Other values may have been added since then or will be added
- after the publication of this document. Readers should refer to
- [IKEV2IANA] for the latest values.
-
- Description Trans. Used In
- Type
- ------------------------------------------------------------------
- Encryption Algorithm (ENCR) 1 IKE and ESP
- Pseudorandom Function (PRF) 2 IKE
- Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP
- Diffie-Hellman group (D-H) 4 IKE, optional in AH & ESP
- Extended Sequence Numbers (ESN) 5 AH and ESP
-
- (*) Negotiating an integrity algorithm is mandatory for the
- Encrypted payload format specified in this document. For example,
- [AEAD] specifies additional formats based on authenticated
- encryption, in which a separate integrity algorithm is not
- negotiated.
-
- For Transform Type 1 (Encryption Algorithm), the Transform IDs are
- listed below. The values in the following table are only current as
- of the publication date of RFC 4306. Other values may have been
- added since then or will be added after the publication of this
- document. Readers should refer to [IKEV2IANA] for the latest values.
-
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 80]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Name Number Defined In
- ---------------------------------------------------
- ENCR_DES_IV64 1 (UNSPECIFIED)
- ENCR_DES 2 (RFC2405), [DES]
- ENCR_3DES 3 (RFC2451)
- ENCR_RC5 4 (RFC2451)
- ENCR_IDEA 5 (RFC2451), [IDEA]
- ENCR_CAST 6 (RFC2451)
- ENCR_BLOWFISH 7 (RFC2451)
- ENCR_3IDEA 8 (UNSPECIFIED)
- ENCR_DES_IV32 9 (UNSPECIFIED)
- ENCR_NULL 11 (RFC2410)
- ENCR_AES_CBC 12 (RFC3602)
- ENCR_AES_CTR 13 (RFC3686)
-
- For Transform Type 2 (Pseudorandom Function), the Transform IDs are
- listed below. The values in the following table are only current as
- of the publication date of RFC 4306. Other values may have been
- added since then or will be added after the publication of this
- document. Readers should refer to [IKEV2IANA] for the latest values.
-
- Name Number Defined In
- ------------------------------------------------------
- PRF_HMAC_MD5 1 (RFC2104), [MD5]
- PRF_HMAC_SHA1 2 (RFC2104), [SHA]
- PRF_HMAC_TIGER 3 (UNSPECIFIED)
-
- For Transform Type 3 (Integrity Algorithm), defined Transform IDs are
- listed below. The values in the following table are only current as
- of the publication date of RFC 4306. Other values may have been
- added since then or will be added after the publication of this
- document. Readers should refer to [IKEV2IANA] for the latest values.
-
- Name Number Defined In
- ----------------------------------------
- NONE 0
- AUTH_HMAC_MD5_96 1 (RFC2403)
- AUTH_HMAC_SHA1_96 2 (RFC2404)
- AUTH_DES_MAC 3 (UNSPECIFIED)
- AUTH_KPDK_MD5 4 (UNSPECIFIED)
- AUTH_AES_XCBC_96 5 (RFC3566)
-
- For Transform Type 4 (Diffie-Hellman group), defined Transform IDs
- are listed below. The values in the following table are only current
- as of the publication date of RFC 4306. Other values may have been
- added since then or will be added after the publication of this
- document. Readers should refer to [IKEV2IANA] for the latest values.
-
-
-
-
-Kaufman, et al. Standards Track [Page 81]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Name Number Defined In
- ----------------------------------------
- NONE 0
- 768-bit MODP 1 Appendix B
- 1024-bit MODP 2 Appendix B
- 1536-bit MODP 5 [ADDGROUP]
- 2048-bit MODP 14 [ADDGROUP]
- 3072-bit MODP 15 [ADDGROUP]
- 4096-bit MODP 16 [ADDGROUP]
- 6144-bit MODP 17 [ADDGROUP]
- 8192-bit MODP 18 [ADDGROUP]
-
- Although ESP and AH do not directly include a Diffie-Hellman
- exchange, a Diffie-Hellman group MAY be negotiated for the Child SA.
- This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA
- exchange, providing perfect forward secrecy for the generated Child
- SA keys.
-
- For Transform Type 5 (Extended Sequence Numbers), defined Transform
- IDs are listed below. The values in the following table are only
- current as of the publication date of RFC 4306. Other values may
- have been added since then or will be added after the publication of
- this document. Readers should refer to [IKEV2IANA] for the latest
- values.
-
- Name Number
- --------------------------------------------
- No Extended Sequence Numbers 0
- Extended Sequence Numbers 1
-
- Note that an initiator who supports ESNs will usually include two ESN
- transforms, with values "0" and "1", in its proposals. A proposal
- containing a single ESN transform with value "1" means that using
- normal (non-extended) sequence numbers is not acceptable.
-
- Numerous additional Transform Types have been defined since the
- publication of RFC 4306. Please refer to the IANA IKEv2 registry for
- details.
-
-3.3.3. Valid Transform Types by Protocol
-
- The number and type of transforms that accompany an SA payload are
- dependent on the protocol in the SA itself. An SA payload proposing
- the establishment of an SA has the following mandatory and optional
- Transform Types. A compliant implementation MUST understand all
- mandatory and optional types for each protocol it supports (though it
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 82]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- need not accept proposals with unacceptable suites). A proposal MAY
- omit the optional types if the only value for them it will accept is
- NONE.
-
- Protocol Mandatory Types Optional Types
- ---------------------------------------------------
- IKE ENCR, PRF, INTEG*, D-H
- ESP ENCR, ESN INTEG, D-H
- AH INTEG, ESN D-H
-
- (*) Negotiating an integrity algorithm is mandatory for the
- Encrypted payload format specified in this document. For example,
- [AEAD] specifies additional formats based on authenticated
- encryption, in which a separate integrity algorithm is not
- negotiated.
-
-3.3.4. Mandatory Transform IDs
-
- The specification of suites that MUST and SHOULD be supported for
- interoperability has been removed from this document because they are
- likely to change more rapidly than this document evolves. At the
- time of publication of this document, [RFC4307] specifies these
- suites, but note that it might be updated in the future, and other
- RFCs might specify different sets of suites.
-
- An important lesson learned from IKEv1 is that no system should only
- implement the mandatory algorithms and expect them to be the best
- choice for all customers.
-
- It is likely that IANA will add additional transforms in the future,
- and some users may want to use private suites, especially for IKE
- where implementations should be capable of supporting different
- parameters, up to certain size limits. In support of this goal, all
- implementations of IKEv2 SHOULD include a management facility that
- allows specification (by a user or system administrator) of Diffie-
- Hellman parameters (the generator, modulus, and exponent lengths and
- values) for new Diffie-Hellman groups. Implementations SHOULD
- provide a management interface through which these parameters and the
- associated Transform IDs may be entered (by a user or system
- administrator), to enable negotiating such groups.
-
- All implementations of IKEv2 MUST include a management facility that
- enables a user or system administrator to specify the suites that are
- acceptable for use with IKE. Upon receipt of a payload with a set of
- Transform IDs, the implementation MUST compare the transmitted
- Transform IDs against those locally configured via the management
- controls, to verify that the proposed suite is acceptable based on
- local policy. The implementation MUST reject SA proposals that are
-
-
-
-Kaufman, et al. Standards Track [Page 83]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- not authorized by these IKE suite controls. Note that cryptographic
- suites that MUST be implemented need not be configured as acceptable
- to local policy.
-
-3.3.5. Transform Attributes
-
- Each transform in a Security Association payload may include
- attributes that modify or complete the specification of the
- transform. The set of valid attributes depends on the transform.
- Currently, only a single attribute type is defined: the Key Length
- attribute is used by certain encryption transforms with variable-
- length keys (see below for details).
-
- The attributes are type/value pairs and are defined below.
- Attributes can have a value with a fixed two-octet length or a
- variable-length value. For the latter, the attribute is encoded as
- type/length/value.
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |A| Attribute Type | AF=0 Attribute Length |
- |F| | AF=1 Attribute Value |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | AF=0 Attribute Value |
- | AF=1 Not Transmitted |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 9: Data Attributes
-
- o Attribute Format (AF) (1 bit) - Indicates whether the data
- attribute follows the Type/Length/Value (TLV) format or a
- shortened Type/Value (TV) format. If the AF bit is zero (0), then
- the attribute uses TLV format; if the AF bit is one (1), the TV
- format (with two-byte value) is used.
-
- o Attribute Type (15 bits) - Unique identifier for each type of
- attribute (see below).
-
- o Attribute Value (variable length) - Value of the attribute
- associated with the attribute type. If the AF bit is a zero (0),
- this field has a variable length defined by the Attribute Length
- field. If the AF bit is a one (1), the Attribute Value has a
- length of 2 octets.
-
- The only currently defined attribute type (Key Length) is fixed
- length; the variable-length encoding specification is included only
- for future extensions. Attributes described as fixed length MUST NOT
-
-
-
-Kaufman, et al. Standards Track [Page 84]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- be encoded using the variable-length encoding unless that length
- exceeds two bytes. Variable-length attributes MUST NOT be encoded as
- fixed-length even if their value can fit into two octets. Note: This
- is a change from IKEv1, where increased flexibility may have
- simplified the composer of messages but certainly complicated the
- parser.
-
- The values in the following table are only current as of the
- publication date of RFC 4306. Other values may have been added since
- then or will be added after the publication of this document.
- Readers should refer to [IKEV2IANA] for the latest values.
-
- Attribute Type Value Attribute Format
- ------------------------------------------------------------
- Key Length (in bits) 14 TV
-
- Values 0-13 and 15-17 were used in a similar context in IKEv1, and
- should not be assigned except to matching values.
-
- The Key Length attribute specifies the key length in bits (MUST use
- network byte order) for certain transforms as follows:
-
- o The Key Length attribute MUST NOT be used with transforms that use
- a fixed-length key. For example, this includes ENCR_DES,
- ENCR_IDEA, and all the Type 2 (Pseudorandom function) and Type 3
- (Integrity Algorithm) transforms specified in this document. It
- is recommended that future Type 2 or 3 transforms do not use this
- attribute.
-
- o Some transforms specify that the Key Length attribute MUST be
- always included (omitting the attribute is not allowed, and
- proposals not containing it MUST be rejected). For example, this
- includes ENCR_AES_CBC and ENCR_AES_CTR.
-
- o Some transforms allow variable-length keys, but also specify a
- default key length if the attribute is not included. For example,
- these transforms include ENCR_RC5 and ENCR_BLOWFISH.
-
- Implementation note: To further interoperability and to support
- upgrading endpoints independently, implementers of this protocol
- SHOULD accept values that they deem to supply greater security. For
- instance, if a peer is configured to accept a variable-length cipher
- with a key length of X bits and is offered that cipher with a larger
- key length, the implementation SHOULD accept the offer if it supports
- use of the longer key.
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 85]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Support for this capability allows a responder to express a concept
- of "at least" a certain level of security -- "a key length of _at
- least_ X bits for cipher Y". However, as the attribute is always
- returned unchanged (see the next section), an initiator willing to
- accept multiple key lengths has to include multiple transforms with
- the same Transform Type, each with a different Key Length attribute.
-
-3.3.6. Attribute Negotiation
-
- During Security Association negotiation initiators present offers to
- responders. Responders MUST select a single complete set of
- parameters from the offers (or reject all offers if none are
- acceptable). If there are multiple proposals, the responder MUST
- choose a single proposal. If the selected proposal has multiple
- transforms with the same type, the responder MUST choose a single
- one. Any attributes of a selected transform MUST be returned
- unmodified. The initiator of an exchange MUST check that the
- accepted offer is consistent with one of its proposals, and if not
- MUST terminate the exchange.
-
- If the responder receives a proposal that contains a Transform Type
- it does not understand, or a proposal that is missing a mandatory
- Transform Type, it MUST consider this proposal unacceptable; however,
- other proposals in the same SA payload are processed as usual.
- Similarly, if the responder receives a transform that it does not
- understand, or one that contains a Transform Attribute it does not
- understand, it MUST consider this transform unacceptable; other
- transforms with the same Transform Type are processed as usual. This
- allows new Transform Types and Transform Attributes to be defined in
- the future.
-
- Negotiating Diffie-Hellman groups presents some special challenges.
- SA offers include proposed attributes and a Diffie-Hellman public
- number (KE) in the same message. If in the initial exchange the
- initiator offers to use one of several Diffie-Hellman groups, it
- SHOULD pick the one the responder is most likely to accept and
- include a KE corresponding to that group. If the responder selects a
- proposal using a different Diffie-Hellman group (other than NONE),
- the responder will indicate the correct group in the response and the
- initiator SHOULD pick an element of that group for its KE value when
- retrying the first message. It SHOULD, however, continue to propose
- its full supported set of groups in order to prevent a man-in-the-
- middle downgrade attack. If one of the proposals offered is for the
- Diffie-Hellman group of NONE, and the responder selects that Diffie-
- Hellman group, then it MUST ignore the initiator's KE payload and
- omit the KE payload from the response.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 86]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-3.4. Key Exchange Payload
-
- The Key Exchange payload, denoted KE in this document, is used to
- exchange Diffie-Hellman public numbers as part of a Diffie-Hellman
- key exchange. The Key Exchange payload consists of the IKE generic
- payload header followed by the Diffie-Hellman public value itself.
-
- 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 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Diffie-Hellman Group Num | RESERVED |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ Key Exchange Data ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 10: Key Exchange Payload Format
-
- A Key Exchange payload is constructed by copying one's Diffie-Hellman
- public value into the "Key Exchange Data" portion of the payload.
- The length of the Diffie-Hellman public value for modular
- exponentiation group (MODP) groups MUST be equal to the length of the
- prime modulus over which the exponentiation was performed, prepending
- zero bits to the value if necessary.
-
- The Diffie-Hellman Group Num identifies the Diffie-Hellman group in
- which the Key Exchange Data was computed (see Section 3.3.2). This
- Diffie-Hellman Group Num MUST match a Diffie-Hellman group specified
- in a proposal in the SA payload that is sent in the same message, and
- SHOULD match the Diffie-Hellman group in the first group in the first
- proposal, if such exists. If none of the proposals in that SA
- payload specifies a Diffie-Hellman group, the KE payload MUST NOT be
- present. If the selected proposal uses a different Diffie-Hellman
- group (other than NONE), the message MUST be rejected with a Notify
- payload of type INVALID_KE_PAYLOAD. See also Sections 1.2 and 2.7.
-
- The payload type for the Key Exchange payload is thirty-four (34).
-
-3.5. Identification Payloads
-
- The Identification payloads, denoted IDi and IDr in this document,
- allow peers to assert an identity to one another. This identity may
- be used for policy lookup, but does not necessarily have to match
- anything in the CERT payload; both fields may be used by an
- implementation to perform access control decisions. When using the
-
-
-
-Kaufman, et al. Standards Track [Page 87]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2
- does not require this address to match the address in the IP header
- of IKEv2 packets, or anything in the TSi/TSr payloads. The contents
- of IDi/IDr are used purely to fetch the policy and authentication
- data related to the other party.
-
- NOTE: In IKEv1, two ID payloads were used in each direction to hold
- Traffic Selector (TS) information for data passing over the SA. In
- IKEv2, this information is carried in TS payloads (see Section 3.13).
-
- The Peer Authorization Database (PAD) as described in RFC 4301
- [IPSECARCH] describes the use of the ID payload in IKEv2 and provides
- a formal model for the binding of identity to policy in addition to
- providing services that deal more specifically with the details of
- policy enforcement. The PAD is intended to provide a link between
- the SPD and the IKE Security Association management. See Section
- 4.4.3 of RFC 4301 for more details.
-
- The Identification payload consists of the IKE generic payload header
- followed by identification fields 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 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | ID Type | RESERVED |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ Identification Data ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 11: Identification Payload Format
-
- o ID Type (1 octet) - Specifies the type of Identification being
- used.
-
- o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
-
- o Identification Data (variable length) - Value, as indicated by the
- Identification Type. The length of the Identification Data is
- computed from the size in the ID payload header.
-
- The payload types for the Identification payload are thirty-five (35)
- for IDi and thirty-six (36) for IDr.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 88]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- The following table lists the assigned semantics for the
- Identification Type field. The values in the following table are
- only current as of the publication date of RFC 4306. Other values
- may have been added since then or will be added after the publication
- of this document. Readers should refer to [IKEV2IANA] for the latest
- values.
-
- ID Type Value
- -------------------------------------------------------------------
- ID_IPV4_ADDR 1
- A single four (4) octet IPv4 address.
-
- ID_FQDN 2
- A fully-qualified domain name string. An example of an ID_FQDN
- is "example.com". The string MUST NOT contain any terminators
- (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII;
- for an "internationalized domain name", the syntax is as defined
- in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net".
-
- ID_RFC822_ADDR 3
- A fully-qualified RFC 822 email address string. An example of a
- ID_RFC822_ADDR is "jsmith@example.com". The string MUST NOT
- contain any terminators. Because of [EAI], implementations would
- be wise to treat this field as UTF-8 encoded text, not as
- pure ASCII.
-
- ID_IPV6_ADDR 5
- A single sixteen (16) octet IPv6 address.
-
- ID_DER_ASN1_DN 9
- The binary Distinguished Encoding Rules (DER) encoding of an
- ASN.1 X.500 Distinguished Name [PKIX].
-
- ID_DER_ASN1_GN 10
- The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX].
-
- ID_KEY_ID 11
- An opaque octet stream that may be used to pass vendor-
- specific information necessary to do certain proprietary
- types of identification.
-
- Two implementations will interoperate only if each can generate a
- type of ID acceptable to the other. To assure maximum
- interoperability, implementations MUST be configurable to send at
- least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
- MUST be configurable to accept all of these four types.
- Implementations SHOULD be capable of generating and accepting all of
- these types. IPv6-capable implementations MUST additionally be
-
-
-
-Kaufman, et al. Standards Track [Page 89]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY
- be configurable to send only ID_IPV6_ADDR instead of ID_IPV4_ADDR for
- IP addresses.
-
- EAP [EAP] does not mandate the use of any particular type of
- identifier, but often EAP is used with Network Access Identifiers
- (NAIs) defined in [NAI]. Although NAIs look a bit like email
- addresses (e.g., "joe@example.com"), the syntax is not exactly the
- same as the syntax of email address in [MAILFORMAT]. For those NAIs
- that include the realm component, the ID_RFC822_ADDR identification
- type SHOULD be used. Responder implementations should not attempt to
- verify that the contents actually conform to the exact syntax given
- in [MAILFORMAT], but instead should accept any reasonable-looking
- NAI. For NAIs that do not include the realm component, the ID_KEY_ID
- identification type SHOULD be used.
-
-3.6. Certificate Payload
-
- The Certificate payload, denoted CERT in this document, provides a
- means to transport certificates or other authentication-related
- information via IKE. Certificate payloads SHOULD be included in an
- exchange if certificates are available to the sender. The Hash and
- URL formats of the Certificate payloads should be used in case the
- peer has indicated an ability to retrieve this information from
- elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note
- that the term "Certificate payload" is somewhat misleading, because
- not all authentication mechanisms use certificates and data other
- than certificates may be passed in this payload.
-
- The Certificate payload is defined 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 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Cert Encoding | |
- +-+-+-+-+-+-+-+-+ |
- ~ Certificate Data ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 12: Certificate Payload Format
-
- o Certificate Encoding (1 octet) - This field indicates the type of
- certificate or certificate-related information contained in the
- Certificate Data field. The values in the following table are
- only current as of the publication date of RFC 4306. Other values
-
-
-
-Kaufman, et al. Standards Track [Page 90]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- may have been added since then or will be added after the
- publication of this document. Readers should refer to [IKEV2IANA]
- for the latest values.
-
- Certificate Encoding Value
- ----------------------------------------------------
- PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED
- PGP Certificate 2 UNSPECIFIED
- DNS Signed Key 3 UNSPECIFIED
- X.509 Certificate - Signature 4
- Kerberos Token 6 UNSPECIFIED
- Certificate Revocation List (CRL) 7
- Authority Revocation List (ARL) 8 UNSPECIFIED
- SPKI Certificate 9 UNSPECIFIED
- X.509 Certificate - Attribute 10 UNSPECIFIED
- Raw RSA Key 11
- Hash and URL of X.509 certificate 12
- Hash and URL of X.509 bundle 13
-
- o Certificate Data (variable length) - Actual encoding of
- certificate data. The type of certificate is indicated by the
- Certificate Encoding field.
-
- The payload type for the Certificate payload is thirty-seven (37).
-
- Specific syntax for some of the certificate type codes above is not
- defined in this document. The types whose syntax is defined in this
- document are:
-
- o "X.509 Certificate - Signature" contains a DER-encoded X.509
- certificate whose public key is used to validate the sender's AUTH
- payload. Note that with this encoding, if a chain of certificates
- needs to be sent, multiple CERT payloads are used, only the first
- of which holds the public key used to validate the sender's AUTH
- payload.
-
- o "Certificate Revocation List" contains a DER-encoded X.509
- certificate revocation list.
-
- o "Raw RSA Key" contains a PKCS #1 encoded RSA key, that is, a DER-
- encoded RSAPublicKey structure (see [RSA] and [PKCS1]).
-
- o Hash and URL encodings allow IKE messages to remain short by
- replacing long data structures with a 20-octet SHA-1 hash (see
- [SHA]) of the replaced value followed by a variable-length URL
- that resolves to the DER-encoded data structure itself. This
- improves efficiency when the endpoints have certificate data
-
-
-
-
-Kaufman, et al. Standards Track [Page 91]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- cached and makes IKE less subject to DoS attacks that become
- easier to mount when IKE messages are large enough to require IP
- fragmentation [DOSUDPPROT].
-
- The "Hash and URL of a bundle" type uses the following ASN.1
- definition for the X.509 bundle:
-
- CertBundle
- { iso(1) identified-organization(3) dod(6) internet(1)
- security(5) mechanisms(5) pkix(7) id-mod(0)
- id-mod-cert-bundle(34) }
-
- DEFINITIONS EXPLICIT TAGS ::=
- BEGIN
-
- IMPORTS
- Certificate, CertificateList
- FROM PKIX1Explicit88
- { iso(1) identified-organization(3) dod(6)
- internet(1) security(5) mechanisms(5) pkix(7)
- id-mod(0) id-pkix1-explicit(18) } ;
-
- CertificateOrCRL ::= CHOICE {
- cert [0] Certificate,
- crl [1] CertificateList }
-
- CertificateBundle ::= SEQUENCE OF CertificateOrCRL
-
- END
-
- Implementations MUST be capable of being configured to send and
- accept up to four X.509 certificates in support of authentication,
- and also MUST be capable of being configured to send and accept the
- Hash and URL format (with HTTP URLs). Implementations SHOULD be
- capable of being configured to send and accept Raw RSA keys. If
- multiple certificates are sent, the first certificate MUST contain
- the public key used to sign the AUTH payload. The other certificates
- may be sent in any order.
-
- Implementations MUST support the HTTP [HTTP] method for hash-and-URL
- lookup. The behavior of other URL methods [URLS] is not currently
- specified, and such methods SHOULD NOT be used in the absence of a
- document specifying them.
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 92]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-3.7. Certificate Request Payload
-
- The Certificate Request payload, denoted CERTREQ in this document,
- provides a means to request preferred certificates via IKE and can
- appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
- Certificate Request payloads MAY be included in an exchange when the
- sender needs to get the certificate of the receiver.
-
- The Certificate Request payload is defined 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 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Cert Encoding | |
- +-+-+-+-+-+-+-+-+ |
- ~ Certification Authority ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 13: Certificate Request Payload Format
-
- o Certificate Encoding (1 octet) - Contains an encoding of the type
- or format of certificate requested. Values are listed in
- Section 3.6.
-
- o Certification Authority (variable length) - Contains an encoding
- of an acceptable certification authority for the type of
- certificate requested.
-
- The payload type for the Certificate Request payload is thirty-eight
- (38).
-
- The Certificate Encoding field has the same values as those defined
- in Section 3.6. The Certification Authority field contains an
- indicator of trusted authorities for this certificate type. The
- Certification Authority value is a concatenated list of SHA-1 hashes
- of the public keys of trusted Certification Authorities (CAs). Each
- is encoded as the SHA-1 hash of the Subject Public Key Info element
- (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate.
- The 20-octet hashes are concatenated and included with no other
- formatting.
-
- The contents of the "Certification Authority" field are defined only
- for X.509 certificates, which are types 4, 12, and 13. Other values
- SHOULD NOT be used until Standards-Track specifications that specify
- their use are published.
-
-
-
-
-Kaufman, et al. Standards Track [Page 93]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Note that the term "Certificate Request" is somewhat misleading, in
- that values other than certificates are defined in a "Certificate"
- payload and requests for those values can be present in a Certificate
- Request payload. The syntax of the Certificate Request payload in
- such cases is not defined in this document.
-
- The Certificate Request payload is processed by inspecting the "Cert
- Encoding" field to determine whether the processor has any
- certificates of this type. If so, the "Certification Authority"
- field is inspected to determine if the processor has any certificates
- that can be validated up to one of the specified certification
- authorities. This can be a chain of certificates.
-
- If an end-entity certificate exists that satisfies the criteria
- specified in the CERTREQ, a certificate or certificate chain SHOULD
- be sent back to the certificate requestor if the recipient of the
- CERTREQ:
-
- o is configured to use certificate authentication,
-
- o is allowed to send a CERT payload,
-
- o has matching CA trust policy governing the current negotiation,
- and
-
- o has at least one time-wise and usage-appropriate end-entity
- certificate chaining to a CA provided in the CERTREQ.
-
- Certificate revocation checking must be considered during the
- chaining process used to select a certificate. Note that even if two
- peers are configured to use two different CAs, cross-certification
- relationships should be supported by appropriate selection logic.
-
- The intent is not to prevent communication through the strict
- adherence of selection of a certificate based on CERTREQ, when an
- alternate certificate could be selected by the sender that would
- still enable the recipient to successfully validate and trust it
- through trust conveyed by cross-certification, CRLs, or other out-of-
- band configured means. Thus, the processing of a CERTREQ should be
- seen as a suggestion for a certificate to select, not a mandated one.
- If no certificates exist, then the CERTREQ is ignored. This is not
- an error condition of the protocol. There may be cases where there
- is a preferred CA sent in the CERTREQ, but an alternate might be
- acceptable (perhaps after prompting a human operator).
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 94]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any
- message that can include a CERTREQ payload and indicates that the
- sender is capable of looking up certificates based on an HTTP-based
- URL (and hence presumably would prefer to receive certificate
- specifications in that format).
-
-3.8. Authentication Payload
-
- The Authentication payload, denoted AUTH in this document, contains
- data used for authentication purposes. The syntax of the
- Authentication data varies according to the Auth Method as specified
- below.
-
- The Authentication payload is defined 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 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Auth Method | RESERVED |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ Authentication Data ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 14: Authentication Payload Format
-
- o Auth Method (1 octet) - Specifies the method of authentication
- used. The types of signatures are listed here. The values in the
- following table are only current as of the publication date of RFC
- 4306. Other values may have been added since then or will be
- added after the publication of this document. Readers should
- refer to [IKEV2IANA] for the latest values.
-
- Mechanism Value
- -----------------------------------------------------------------
- RSA Digital Signature 1
- Computed as specified in Section 2.15 using an RSA private key
- with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1]
- (implementers should note that IKEv1 used a different method for
- RSA signatures). To promote interoperability, implementations
- that support this type SHOULD support signatures that use SHA-1
- as the hash function and SHOULD use SHA-1 as the default hash
- function when generating signatures. Implementations can use the
- certificates received from a given peer as a hint for selecting a
- mutually understood hash function for the AUTH payload signature.
-
-
-
-Kaufman, et al. Standards Track [Page 95]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Note, however, that the hash algorithm used in the AUTH payload
- signature doesn't have to be the same as any hash algorithm(s)
- used in the certificate(s).
-
- Shared Key Message Integrity Code 2
- Computed as specified in Section 2.15 using the shared key
- associated with the identity in the ID payload and the negotiated
- PRF.
-
- DSS Digital Signature 3
- Computed as specified in Section 2.15 using a DSS private key
- (see [DSS]) over a SHA-1 hash.
-
- o Authentication Data (variable length) - see Section 2.15.
-
- The payload type for the Authentication payload is thirty-nine (39).
-
-3.9. Nonce Payload
-
- The Nonce payload, denoted as Ni and Nr in this document for the
- initiator's and responder's nonce, respectively, contains random data
- used to guarantee liveness during an exchange and protect against
- replay attacks.
-
- The Nonce payload is defined 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 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ Nonce Data ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 15: Nonce Payload Format
-
- o Nonce Data (variable length) - Contains the random data generated
- by the transmitting entity.
-
- The payload type for the Nonce payload is forty (40).
-
- The size of the Nonce Data MUST be between 16 and 256 octets,
- inclusive. Nonce values MUST NOT be reused.
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 96]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-3.10. Notify Payload
-
- The Notify payload, denoted N in this document, is used to transmit
- informational data, such as error conditions and state transitions,
- to an IKE peer. A Notify payload may appear in a response message
- (usually specifying why a request was rejected), in an INFORMATIONAL
- Exchange (to report an error not in an IKE request), or in any other
- message to indicate sender capabilities or to modify the meaning of
- the request.
-
- The Notify payload is defined 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 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ Security Parameter Index (SPI) ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ Notification Data ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 16: Notify Payload Format
-
- o Protocol ID (1 octet) - If this notification concerns an existing
- SA whose SPI is given in the SPI field, this field indicates the
- type of that SA. For notifications concerning Child SAs, this
- field MUST contain either (2) to indicate AH or (3) to indicate
- ESP. Of the notifications defined in this document, the SPI is
- included only with INVALID_SELECTORS and REKEY_SA. If the SPI
- field is empty, this field MUST be sent as zero and MUST be
- ignored on receipt.
-
- o SPI Size (1 octet) - Length in octets of the SPI as defined by the
- IPsec protocol ID or zero if no SPI is applicable. For a
- notification concerning the IKE SA, the SPI Size MUST be zero and
- the field must be empty.
-
- o Notify Message Type (2 octets) - Specifies the type of
- notification message.
-
- o SPI (variable length) - Security Parameter Index.
-
-
-
-
-Kaufman, et al. Standards Track [Page 97]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- o Notification Data (variable length) - Status or error data
- transmitted in addition to the Notify Message Type. Values for
- this field are type specific (see below).
-
- The payload type for the Notify payload is forty-one (41).
-
-3.10.1. Notify Message Types
-
- Notification information can be error messages specifying why an SA
- could not be established. It can also be status data that a process
- managing an SA database wishes to communicate with a peer process.
-
- The table below lists the Notification messages and their
- corresponding values. The number of different error statuses was
- greatly reduced from IKEv1 both for simplification and to avoid
- giving configuration information to probers.
-
- Types in the range 0 - 16383 are intended for reporting errors. An
- implementation receiving a Notify payload with one of these types
- that it does not recognize in a response MUST assume that the
- corresponding request has failed entirely. Unrecognized error types
- in a request and status types in a request or response MUST be
- ignored, and they should be logged.
-
- Notify payloads with status types MAY be added to any message and
- MUST be ignored if not recognized. They are intended to indicate
- capabilities, and as part of SA negotiation, are used to negotiate
- non-cryptographic parameters.
-
- More information on error handling can be found in Section 2.21.
-
- The values in the following table are only current as of the
- publication date of RFC 4306, plus two error types added in this
- document. Other values may have been added since then or will be
- added after the publication of this document. Readers should refer
- to [IKEV2IANA] for the latest values.
-
- NOTIFY messages: error types Value
- -------------------------------------------------------------------
- UNSUPPORTED_CRITICAL_PAYLOAD 1
- See Section 2.5.
-
- INVALID_IKE_SPI 4
- See Section 2.21.
-
- INVALID_MAJOR_VERSION 5
- See Section 2.5.
-
-
-
-
-Kaufman, et al. Standards Track [Page 98]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- INVALID_SYNTAX 7
- Indicates the IKE message that was received was invalid because
- some type, length, or value was out of range or because the
- request was rejected for policy reasons. To avoid a DoS
- attack using forged messages, this status may only be
- returned for and in an encrypted packet if the Message ID and
- cryptographic checksum were valid. To avoid leaking information
- to someone probing a node, this status MUST be sent in response
- to any error not covered by one of the other status types.
- To aid debugging, more detailed error information should be
- written to a console or log.
-
- INVALID_MESSAGE_ID 9
- See Section 2.3.
-
- INVALID_SPI 11
- See Section 1.5.
-
- NO_PROPOSAL_CHOSEN 14
- None of the proposed crypto suites was acceptable. This can be
- sent in any case where the offered proposals (including but not
- limited to SA payload values, USE_TRANSPORT_MODE notify,
- IPCOMP_SUPPORTED notify) are not acceptable for the responder.
- This can also be used as "generic" Child SA error when Child SA
- cannot be created for some other reason. See also Section 2.7.
-
- INVALID_KE_PAYLOAD 17
- See Sections 1.2 and 1.3.
-
- AUTHENTICATION_FAILED 24
- Sent in the response to an IKE_AUTH message when, for some reason,
- the authentication failed. There is no associated data. See also
- Section 2.21.2.
-
- SINGLE_PAIR_REQUIRED 34
- See Section 2.9.
-
- NO_ADDITIONAL_SAS 35
- See Section 1.3.
-
- INTERNAL_ADDRESS_FAILURE 36
- See Section 3.15.4.
-
- FAILED_CP_REQUIRED 37
- See Section 2.19.
-
- TS_UNACCEPTABLE 38
- See Section 2.9.
-
-
-
-Kaufman, et al. Standards Track [Page 99]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- INVALID_SELECTORS 39
- MAY be sent in an IKE INFORMATIONAL exchange when a node receives
- an ESP or AH packet whose selectors do not match those of the SA
- on which it was delivered (and that caused the packet to be
- dropped). The Notification Data contains the start of the
- offending packet (as in ICMP messages) and the SPI field of the
- notification is set to match the SPI of the Child SA.
-
- TEMPORARY_FAILURE 43
- See section 2.25.
-
- CHILD_SA_NOT_FOUND 44
- See section 2.25.
-
-
-
- NOTIFY messages: status types Value
- -------------------------------------------------------------------
- INITIAL_CONTACT 16384
- See Section 2.4.
-
- SET_WINDOW_SIZE 16385
- See Section 2.3.
-
- ADDITIONAL_TS_POSSIBLE 16386
- See Section 2.9.
-
- IPCOMP_SUPPORTED 16387
- See Section 2.22.
-
- NAT_DETECTION_SOURCE_IP 16388
- See Section 2.23.
-
- NAT_DETECTION_DESTINATION_IP 16389
- See Section 2.23.
-
- COOKIE 16390
- See Section 2.6.
-
- USE_TRANSPORT_MODE 16391
- See Section 1.3.1.
-
- HTTP_CERT_LOOKUP_SUPPORTED 16392
- See Section 3.6.
-
- REKEY_SA 16393
- See Section 1.3.3.
-
-
-
-
-Kaufman, et al. Standards Track [Page 100]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- ESP_TFC_PADDING_NOT_SUPPORTED 16394
- See Section 1.3.1.
-
- NON_FIRST_FRAGMENTS_ALSO 16395
- See Section 1.3.1.
-
-3.11. Delete Payload
-
- The Delete payload, denoted D in this document, contains a protocol-
- specific Security Association identifier that the sender has removed
- from its Security Association database and is, therefore, no longer
- valid. Figure 17 shows the format of the Delete payload. It is
- possible to send multiple SPIs in a Delete payload; however, each SPI
- MUST be for the same protocol. Mixing of protocol identifiers MUST
- NOT be performed in the Delete payload. It is permitted, however, to
- include multiple Delete payloads in a single INFORMATIONAL exchange
- where each Delete payload lists SPIs for a different protocol.
-
- Deletion of the IKE SA is indicated by a protocol ID of 1 (IKE) but
- no SPIs. Deletion of a Child SA, such as ESP or AH, will contain the
- IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI
- is the SPI the sending endpoint would expect in inbound ESP or AH
- packets.
-
- The Delete payload is defined 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 | Num of SPIs |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ Security Parameter Index(es) (SPI) ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 17: Delete Payload Format
-
- o Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3
- for ESP.
-
- o SPI Size (1 octet) - Length in octets of the SPI as defined by the
- protocol ID. It MUST be zero for IKE (SPI is in message header)
- or four for AH and ESP.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 101]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- o Num of SPIs (2 octets, unsigned integer) - The number of SPIs
- contained in the Delete payload. The size of each SPI is defined
- by the SPI Size field.
-
- o Security Parameter Index(es) (variable length) - Identifies the
- specific Security Association(s) to delete. The length of this
- field is determined by the SPI Size and Num of SPIs fields.
-
- The payload type for the Delete payload is forty-two (42).
-
-3.12. Vendor ID Payload
-
- The Vendor ID payload, denoted V in this document, contains a vendor-
- defined constant. The constant is used by vendors to identify and
- recognize remote instances of their implementations. This mechanism
- allows a vendor to experiment with new features while maintaining
- backward compatibility.
-
- A Vendor ID payload MAY announce that the sender is capable of
- accepting certain extensions to the protocol, or it MAY simply
- identify the implementation as an aid in debugging. A Vendor ID
- payload MUST NOT change the interpretation of any information defined
- in this specification (i.e., the critical bit MUST be set to 0).
- Multiple Vendor ID payloads MAY be sent. An implementation is not
- required to send any Vendor ID payload at all.
-
- A Vendor ID payload may be sent as part of any message. Reception of
- a familiar Vendor ID payload allows an implementation to make use of
- private use numbers described throughout this document, such as
- private payloads, private exchanges, private notifications, etc.
- Unfamiliar Vendor IDs MUST be ignored.
-
- Writers of documents who wish to extend this protocol MUST define a
- Vendor ID payload to announce the ability to implement the extension
- in the document. It is expected that documents that gain acceptance
- and are standardized will be given "magic numbers" out of the Future
- Use range by IANA, and the requirement to use a Vendor ID will go
- away.
-
- The Vendor ID payload fields are defined as follows:
-
-
-
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 102]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- 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 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ Vendor ID (VID) ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 18: Vendor ID Payload Format
-
- o Vendor ID (variable length) - It is the responsibility of the
- person choosing the Vendor ID to assure its uniqueness in spite of
- the absence of any central registry for IDs. Good practice is to
- include a company name, a person name, or some such information.
- If you want to show off, you might include the latitude and
- longitude and time where you were when you chose the ID and some
- random input. A message digest of a long unique string is
- preferable to the long unique string itself.
-
- The payload type for the Vendor ID payload is forty-three (43).
-
-3.13. Traffic Selector Payload
-
- The Traffic Selector payload, denoted TS in this document, allows
- peers to identify packet flows for processing by IPsec security
- services. The Traffic Selector payload consists of the IKE generic
- payload header followed by individual Traffic Selectors 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 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Number of TSs | RESERVED |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ <Traffic Selectors> ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 19: Traffic Selectors Payload Format
-
- o Number of TSs (1 octet) - Number of Traffic Selectors being
- provided.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 103]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- o RESERVED - This field MUST be sent as zero and MUST be ignored on
- receipt.
-
- o Traffic Selectors (variable length) - One or more individual
- Traffic Selectors.
-
- The length of the Traffic Selector payload includes the TS header and
- all the Traffic Selectors.
-
- The payload type for the Traffic Selector payload is forty-four (44)
- for addresses at the initiator's end of the SA and forty-five (45)
- for addresses at the responder's end.
-
- There is no requirement that TSi and TSr contain the same number of
- individual Traffic Selectors. Thus, they are interpreted as follows:
- a packet matches a given TSi/TSr if it matches at least one of the
- individual selectors in TSi, and at least one of the individual
- selectors in TSr.
-
- For instance, the following Traffic Selectors:
-
- TSi = ((17, 100, 198.51.100.66-198.51.100.66),
- (17, 200, 198.51.100.66-198.51.100.66))
- TSr = ((17, 300, 0.0.0.0-255.255.255.255),
- (17, 400, 0.0.0.0-255.255.255.255))
-
- would match UDP packets from 198.51.100.66 to anywhere, with any of
- the four combinations of source/destination ports (100,300),
- (100,400), (200,300), and (200, 400).
-
- Thus, some types of policies may require several Child SA pairs. For
- instance, a policy matching only source/destination ports (100,300)
- and (200,400), but not the other two combinations, cannot be
- negotiated as a single Child SA pair.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 104]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-3.13.1. Traffic Selector
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | TS Type |IP Protocol ID*| Selector Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Start Port* | End Port* |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ Starting Address* ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ Ending Address* ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 20: Traffic Selector
-
- *Note: All fields other than TS Type and Selector Length depend on
- the TS Type. The fields shown are for TS Types 7 and 8, the only two
- values currently defined.
-
- o TS Type (one octet) - Specifies the type of Traffic Selector.
-
- o IP protocol ID (1 octet) - Value specifying an associated IP
- protocol ID (such as UDP, TCP, and ICMP). A value of zero means
- that the protocol ID is not relevant to this Traffic Selector --
- the SA can carry all protocols.
-
- o Selector Length - Specifies the length of this Traffic Selector
- substructure including the header.
-
- o Start Port (2 octets, unsigned integer) - Value specifying the
- smallest port number allowed by this Traffic Selector. For
- protocols for which port is undefined (including protocol 0), or
- if all ports are allowed, this field MUST be zero. ICMP and
- ICMPv6 Type and Code values, as well as Mobile IP version 6
- (MIPv6) mobility header (MH) Type values, are represented in this
- field as specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type
- and Code values are treated as a single 16-bit integer port
- number, with Type in the most significant eight bits and Code in
- the least significant eight bits. MIPv6 MH Type values are
- treated as a single 16-bit integer port number, with Type in the
- most significant eight bits and the least significant eight bits
- set to zero.
-
-
-
-
-Kaufman, et al. Standards Track [Page 105]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- o End Port (2 octets, unsigned integer) - Value specifying the
- largest port number allowed by this Traffic Selector. For
- protocols for which port is undefined (including protocol 0), or
- if all ports are allowed, this field MUST be 65535. ICMP and
- ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are
- represented in this field as specified in Section 4.4.1.1 of
- [IPSECARCH]. ICMP Type and Code values are treated as a single
- 16-bit integer port number, with Type in the most significant
- eight bits and Code in the least significant eight bits. MIPv6 MH
- Type values are treated as a single 16-bit integer port number,
- with Type in the most significant eight bits and the least
- significant eight bits set to zero.
-
- o Starting Address - The smallest address included in this Traffic
- Selector (length determined by TS Type).
-
- o Ending Address - The largest address included in this Traffic
- Selector (length determined by TS Type).
-
- Systems that are complying with [IPSECARCH] that wish to indicate
- "ANY" ports MUST set the start port to 0 and the end port to 65535;
- note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems
- working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but
- not "ANY" ports, MUST set the start port to 65535 and the end port to
- 0.
-
- The Traffic Selector types 7 and 8 can also refer to ICMP or ICMPv6
- type and code fields, as well as MH Type fields for the IPv6 mobility
- header [MIPV6]. Note, however, that neither ICMP nor MIPv6 packets
- have separate source and destination fields. The method for
- specifying the Traffic Selectors for ICMP and MIPv6 is shown by
- example in Section 4.4.1.3 of [IPSECARCH].
-
- The following table lists values for the Traffic Selector Type field
- and the corresponding Address Selector Data. The values in the
- following table are only current as of the publication date of RFC
- 4306. Other values may have been added since then or will be added
- after the publication of this document. Readers should refer to
- [IKEV2IANA] for the latest values.
-
- TS Type Value
- -------------------------------------------------------------------
- TS_IPV4_ADDR_RANGE 7
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 106]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- A range of IPv4 addresses, represented by two four-octet
- values. The first value is the beginning IPv4 address
- (inclusive) and the second value is the ending IPv4 address
- (inclusive). All addresses falling between the two specified
- addresses are considered to be within the list.
-
- TS_IPV6_ADDR_RANGE 8
-
- A range of IPv6 addresses, represented by two sixteen-octet
- values. The first value is the beginning IPv6 address
- (inclusive) and the second value is the ending IPv6 address
- (inclusive). All addresses falling between the two specified
- addresses are considered to be within the list.
-
-3.14. Encrypted Payload
-
- The Encrypted payload, denoted SK{...} in this document, contains
- other payloads in encrypted form. The Encrypted payload, if present
- in a message, MUST be the last payload in the message. Often, it is
- the only payload in the message. This payload is also called the
- "Encrypted and Authenticated" payload.
-
- The algorithms for encryption and integrity protection are negotiated
- during IKE SA setup, and the keys are computed as specified in
- Sections 2.14 and 2.18.
-
- This document specifies the cryptographic processing of Encrypted
- payloads using a block cipher in CBC mode and an integrity check
- algorithm that computes a fixed-length checksum over a variable size
- message. The design is modeled after the ESP algorithms described in
- RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document
- completely specifies the cryptographic processing of IKE data, but
- those documents should be consulted for design rationale. Future
- documents may specify the processing of Encrypted payloads for other
- types of transforms, such as counter mode encryption and
- authenticated encryption algorithms. Peers MUST NOT negotiate
- transforms for which no such specification exists.
-
- When an authenticated encryption algorithm is used to protect the IKE
- SA, the construction of the Encrypted payload is different than what
- is described here. See [AEAD] for more information on authenticated
- encryption algorithms and their use in ESP.
-
- The payload type for an Encrypted payload is forty-six (46). The
- Encrypted payload consists of the IKE generic payload header followed
- by individual fields as follows:
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 107]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- 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 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Initialization Vector |
- | (length is block size for encryption algorithm) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ~ Encrypted IKE Payloads ~
- + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | | Padding (0-255 octets) |
- +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
- | | Pad Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- ~ Integrity Checksum Data ~
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 21: Encrypted Payload Format
-
- o Next Payload - The payload type of the first embedded payload.
- Note that this is an exception in the standard header format,
- since the Encrypted payload is the last payload in the message and
- therefore the Next Payload field would normally be zero. But
- because the content of this payload is embedded payloads and there
- was no natural place to put the type of the first one, that type
- is placed here.
-
- o Payload Length - Includes the lengths of the header,
- initialization vector (IV), Encrypted IKE payloads, Padding, Pad
- Length, and Integrity Checksum Data.
-
- o Initialization Vector - For CBC mode ciphers, the length of the
- initialization vector (IV) is equal to the block length of the
- underlying encryption algorithm. Senders MUST select a new
- unpredictable IV for every message; recipients MUST accept any
- value. The reader is encouraged to consult [MODES] for advice on
- IV generation. In particular, using the final ciphertext block of
- the previous message is not considered unpredictable. For modes
- other than CBC, the IV format and processing is specified in the
- document specifying the encryption algorithm and mode.
-
- o IKE payloads are as specified earlier in this section. This field
- is encrypted with the negotiated cipher.
-
- o Padding MAY contain any value chosen by the sender, and MUST have
- a length that makes the combination of the payloads, the Padding,
- and the Pad Length to be a multiple of the encryption block size.
- This field is encrypted with the negotiated cipher.
-
-
-
-Kaufman, et al. Standards Track [Page 108]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- o Pad Length is the length of the Padding field. The sender SHOULD
- set the Pad Length to the minimum value that makes the combination
- of the payloads, the Padding, and the Pad Length a multiple of the
- block size, but the recipient MUST accept any length that results
- in proper alignment. This field is encrypted with the negotiated
- cipher.
-
- o Integrity Checksum Data is the cryptographic checksum of the
- entire message starting with the Fixed IKE header through the Pad
- Length. The checksum MUST be computed over the encrypted message.
- Its length is determined by the integrity algorithm negotiated.
-
-3.15. Configuration Payload
-
- The Configuration payload, denoted CP in this document, is used to
- exchange configuration information between IKE peers. The exchange
- is for an IRAC to request an internal IP address from an IRAS and to
- exchange other information of the sort that one would acquire with
- Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly
- connected to a LAN.
-
- The Configuration payload is defined 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 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | CFG Type | RESERVED |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ Configuration Attributes ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 22: Configuration Payload Format
-
- The payload type for the Configuration payload is forty-seven (47).
-
- o CFG Type (1 octet) - The type of exchange represented by the
- Configuration Attributes. The values in the following table are
- only current as of the publication date of RFC 4306. Other values
- may have been added since then or will be added after the
- publication of this document. Readers should refer to [IKEV2IANA]
- for the latest values.
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 109]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- CFG Type Value
- --------------------------
- CFG_REQUEST 1
- CFG_REPLY 2
- CFG_SET 3
- CFG_ACK 4
-
- o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on
- receipt.
-
- o Configuration Attributes (variable length) - These are type length
- value (TLV) structures specific to the Configuration payload and
- are defined below. There may be zero or more Configuration
- Attributes in this payload.
-
-3.15.1. Configuration Attributes
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |R| Attribute Type | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ Value ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 23: Configuration Attribute Format
-
- o Reserved (1 bit) - This bit MUST be set to zero and MUST be
- ignored on receipt.
-
- o Attribute Type (15 bits) - A unique identifier for each of the
- Configuration Attribute Types.
-
- o Length (2 octets, unsigned integer) - Length in octets of value.
-
- o Value (0 or more octets) - The variable-length value of this
- Configuration Attribute. The following lists the attribute types.
-
- The values in the following table are only current as of the
- publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and
- INTERNAL_IP6_NBNS which were removed by this document). Other values
- may have been added since then or will be added after the publication
- of this document. Readers should refer to [IKEV2IANA] for the latest
- values.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 110]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Attribute Type Value Multi-Valued Length
- ------------------------------------------------------------
- INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets
- INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets
- INTERNAL_IP4_DNS 3 YES 0 or 4 octets
- INTERNAL_IP4_NBNS 4 YES 0 or 4 octets
- INTERNAL_IP4_DHCP 6 YES 0 or 4 octets
- APPLICATION_VERSION 7 NO 0 or more
- INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets
- INTERNAL_IP6_DNS 10 YES 0 or 16 octets
- INTERNAL_IP6_DHCP 12 YES 0 or 16 octets
- INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets
- SUPPORTED_ATTRIBUTES 14 NO Multiple of 2
- INTERNAL_IP6_SUBNET 15 YES 17 octets
-
- * These attributes may be multi-valued on return only if
- multiple values were requested.
-
- o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
- internal network, sometimes called a red node address or private
- address, and it MAY be a private address on the Internet. In a
- request message, the address specified is a requested address (or
- a zero-length address if no specific address is requested). If a
- specific address is requested, it likely indicates that a previous
- connection existed with this address and the requestor would like
- to reuse that address. With IPv6, a requestor MAY supply the low-
- order address octets it wants to use. Multiple internal addresses
- MAY be requested by requesting multiple internal address
- attributes. The responder MAY only send up to the number of
- addresses requested. The INTERNAL_IP6_ADDRESS is made up of two
- fields: the first is a 16-octet IPv6 address, and the second is a
- one-octet prefix-length as defined in [ADDRIPV6]. The requested
- address is valid as long as this IKE SA (or its rekeyed
- successors) requesting the address is valid. This is described in
- more detail in Section 3.15.3.
-
- o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one
- netmask is allowed in the request and response messages (e.g.,
- 255.255.255.0), and it MUST be used only with an
- INTERNAL_IP4_ADDRESS attribute. INTERNAL_IP4_NETMASK in a
- CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET
- containing the same information ("send traffic to these addresses
- through me"), but also implies a link boundary. For instance, the
- client could use its own address and the netmask to calculate the
- broadcast address of the link. An empty INTERNAL_IP4_NETMASK
- attribute can be included in a CFG_REQUEST to request this
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 111]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- information (although the gateway can send the information even
- when not requested). Non-empty values for this attribute in a
- CFG_REQUEST do not make sense and thus MUST NOT be included.
-
- o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS
- server within the network. Multiple DNS servers MAY be requested.
- The responder MAY respond with zero or more DNS server attributes.
-
- o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server
- (WINS) within the network. Multiple NBNS servers MAY be
- requested. The responder MAY respond with zero or more NBNS
- server attributes.
-
- o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send
- any internal DHCP requests to the address contained within the
- attribute. Multiple DHCP servers MAY be requested. The responder
- MAY respond with zero or more DHCP server attributes.
-
- o APPLICATION_VERSION - The version or application information of
- the IPsec host. This is a string of printable ASCII characters
- that is NOT null terminated.
-
- o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge-
- device protects. This attribute is made up of two fields: the
- first being an IP address and the second being a netmask.
- Multiple sub-networks MAY be requested. The responder MAY respond
- with zero or more sub-network attributes. This is discussed in
- more detail in Section 3.15.2.
-
- o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute
- MUST be zero-length and specifies a query to the responder to
- reply back with all of the attributes that it supports. The
- response contains an attribute that contains a set of attribute
- identifiers each in 2 octets. The length divided by 2 (octets)
- would state the number of supported attributes contained in the
- response.
-
- o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge-
- device protects. This attribute is made up of two fields: the
- first is a 16-octet IPv6 address, and the second is a one-octet
- prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY
- be requested. The responder MAY respond with zero or more sub-
- network attributes. This is discussed in more detail in
- Section 3.15.2.
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 112]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Note that no recommendations are made in this document as to how an
- implementation actually figures out what information to send in a
- response. That is, we do not recommend any specific method of an
- IRAS determining which DNS server should be returned to a requesting
- IRAC.
-
- The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request
- information from its peer. If an attribute in the CFG_REQUEST
- Configuration payload is not zero-length, it is taken as a suggestion
- for that attribute. The CFG_REPLY Configuration payload MAY return
- that value, or a new one. It MAY also add new attributes and not
- include some requested ones. Unrecognized or unsupported attributes
- MUST be ignored in both requests and responses.
-
- The CFG_SET and CFG_ACK pair allows an IKE endpoint to push
- configuration data to its peer. In this case, the CFG_SET
- Configuration payload contains attributes the initiator wants its
- peer to alter. The responder MUST return a Configuration payload if
- it accepted any of the configuration data and it MUST contain the
- attributes that the responder accepted with zero-length data. Those
- attributes that it did not accept MUST NOT be in the CFG_ACK
- Configuration payload. If no attributes were accepted, the responder
- MUST return either an empty CFG_ACK payload or a response message
- without a CFG_ACK payload. There are currently no defined uses for
- the CFG_SET/CFG_ACK exchange, though they may be used in connection
- with extensions based on Vendor IDs. An implementation of this
- specification MAY ignore CFG_SET payloads.
-
-3.15.2. Meaning of INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET
-
- INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets,
- ones that need one or more separate SAs, that can be reached through
- the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET
- attributes may also express the gateway's policy about what traffic
- should be sent through the gateway; the client can choose whether
- other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is
- sent through the gateway or directly to the destination. Thus,
- traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET
- attributes should be sent through the gateway that announces the
- attributes. If there are no existing Child SAs whose Traffic
- Selectors cover the address in question, new SAs need to be created.
-
-
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 113]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- For instance, if there are two subnets, 198.51.100.0/26 and
- 192.0.2.0/24, and the client's request contains the following:
-
- CP(CFG_REQUEST) =
- INTERNAL_IP4_ADDRESS()
- TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
- TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
-
- then a valid response could be the following (in which TSr and
- INTERNAL_IP4_SUBNET contain the same information):
-
- CP(CFG_REPLY) =
- INTERNAL_IP4_ADDRESS(198.51.100.234)
- INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
- INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
- TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
- TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63),
- (0, 0-65535, 192.0.2.0-192.0.2.255))
-
- In these cases, the INTERNAL_IP4_SUBNET does not really carry any
- useful information.
-
- A different possible response would have been this:
-
- CP(CFG_REPLY) =
- INTERNAL_IP4_ADDRESS(198.51.100.234)
- INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
- INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
- TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
- TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
-
- That response would mean that the client can send all its traffic
- through the gateway, but the gateway does not mind if the client
- sends traffic not included by INTERNAL_IP4_SUBNET directly to the
- destination (without going through the gateway).
-
- A different situation arises if the gateway has a policy that
- requires the traffic for the two subnets to be carried in separate
- SAs. Then a response like this would indicate to the client that if
- it wants access to the second subnet, it needs to create a separate
- SA:
-
- CP(CFG_REPLY) =
- INTERNAL_IP4_ADDRESS(198.51.100.234)
- INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
- INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
- TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
- TSr = (0, 0-65535, 198.51.100.0-198.51.100.63)
-
-
-
-Kaufman, et al. Standards Track [Page 114]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- INTERNAL_IP4_SUBNET can also be useful if the client's TSr included
- only part of the address space. For instance, if the client requests
- the following:
-
- CP(CFG_REQUEST) =
- INTERNAL_IP4_ADDRESS()
- TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
- TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
-
- then the gateway's response might be:
-
- CP(CFG_REPLY) =
- INTERNAL_IP4_ADDRESS(198.51.100.234)
- INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
- INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
- TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
- TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
-
- Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET in
- CFG_REQUESTs is unclear, they cannot be used reliably in
- CFG_REQUESTs.
-
-3.15.3. Configuration Payloads for IPv6
-
- The Configuration payloads for IPv6 are based on the corresponding
- IPv4 payloads, and do not fully follow the "normal IPv6 way of doing
- things". In particular, IPv6 stateless autoconfiguration or router
- advertisement messages are not used, neither is neighbor discovery.
- Note that there is an additional document that discusses IPv6
- configuration in IKEv2, [IPV6CONFIG]. At the present time, it is an
- experimental document, but there is a hope that with more
- implementation experience, it will gain the same standards treatment
- as this document.
-
- A client can be assigned an IPv6 address using the
- INTERNAL_IP6_ADDRESS Configuration payload. A minimal exchange might
- look like this:
-
- CP(CFG_REQUEST) =
- INTERNAL_IP6_ADDRESS()
- INTERNAL_IP6_DNS()
- TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
- TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 115]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- CP(CFG_REPLY) =
- INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
- INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
- TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
- TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
-
- The client MAY send a non-empty INTERNAL_IP6_ADDRESS attribute in the
- CFG_REQUEST to request a specific address or interface identifier.
- The gateway first checks if the specified address is acceptable, and
- if it is, returns that one. If the address was not acceptable, the
- gateway attempts to use the interface identifier with some other
- prefix; if even that fails, the gateway selects another interface
- identifier.
-
- The INTERNAL_IP6_ADDRESS attribute also contains a prefix length
- field. When used in a CFG_REPLY, this corresponds to the
- INTERNAL_IP4_NETMASK attribute in the IPv4 case.
-
- Although this approach to configuring IPv6 addresses is reasonably
- simple, it has some limitations. IPsec tunnels configured using
- IKEv2 are not fully featured "interfaces" in the IPv6 addressing
- architecture sense [ADDRIPV6]. In particular, they do not
- necessarily have link-local addresses, and this may complicate the
- use of protocols that assume them, such as [MLDV2].
-
-3.15.4. Address Assignment Failures
-
- If the responder encounters an error while attempting to assign an IP
- address to the initiator during the processing of a Configuration
- payload, it responds with an INTERNAL_ADDRESS_FAILURE notification.
- The IKE SA is still created even if the initial Child SA cannot be
- created because of this failure. If this error is generated within
- an IKE_AUTH exchange, no Child SA will be created. However, there
- are some more complex error cases.
-
- If the responder does not support Configuration payloads at all, it
- can simply ignore all Configuration payloads. This type of
- implementation never sends INTERNAL_ADDRESS_FAILURE notifications.
- If the initiator requires the assignment of an IP address, it will
- treat a response without CFG_REPLY as an error.
-
- The initiator may request a particular type of address (IPv4 or IPv6)
- that the responder does not support, even though the responder
- supports Configuration payloads. In this case, the responder simply
- ignores the type of address it does not support and processes the
- rest of the request as usual.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 116]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- If the initiator requests multiple addresses of a type that the
- responder supports, and some (but not all) of the requests fail, the
- responder replies with the successful addresses only. The responder
- sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.
-
- If the initiator does not receive the IP address(es) required by its
- policy, it MAY keep the IKE SA up and retry the Configuration payload
- as separate INFORMATIONAL exchange after suitable timeout, or it MAY
- tear down the IKE SA by sending a Delete payload inside a separate
- INFORMATIONAL exchange and later retry IKE SA from the beginning
- after some timeout. Such a timeout should not be too short
- (especially if the IKE SA is started from the beginning) because
- these error situations may not be able to be fixed quickly; the
- timeout should likely be several minutes. For example, an address
- shortage problem on the responder will probably only be fixed when
- more entries are returned to the address pool when other clients
- disconnect or when responder is reconfigured with larger address
- pool.
-
-3.16. Extensible Authentication Protocol (EAP) Payload
-
- The Extensible Authentication Protocol payload, denoted EAP in this
- document, allows IKE SAs to be authenticated using the protocol
- defined in RFC 3748 [EAP] and subsequent extensions to that protocol.
- When using EAP, an appropriate EAP method needs to be selected. Many
- of these methods have been defined, specifying the protocol's use
- with various authentication mechanisms. EAP method types are listed
- in [EAP-IANA]. A short summary of the EAP format is included here
- for clarity.
-
- 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 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | |
- ~ EAP Message ~
- | |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 24: EAP Payload Format
-
- The payload type for an EAP payload is forty-eight (48).
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 117]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- 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
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Code | Identifier | Length |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Type_Data...
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-
- Figure 25: EAP Message Format
-
- o Code (1 octet) indicates whether this message is a Request (1),
- Response (2), Success (3), or Failure (4).
-
- o Identifier (1 octet) is used in PPP to distinguish replayed
- messages from repeated ones. Since in IKE, EAP runs over a
- reliable protocol, it serves no function here. In a response
- message, this octet MUST be set to match the identifier in the
- corresponding request.
-
- o Length (2 octets, unsigned integer) is the length of the EAP
- message and MUST be four less than the Payload Length of the
- encapsulating payload.
-
- o Type (1 octet) is present only if the Code field is Request (1) or
- Response (2). For other codes, the EAP message length MUST be
- four octets and the Type and Type_Data fields MUST NOT be present.
- In a Request (1) message, Type indicates the data being requested.
- In a Response (2) message, Type MUST either be Nak or match the
- type of the data requested. Note that since IKE passes an
- indication of initiator identity in the first message in the
- IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity
- requests (type 1). The initiator MAY, however, respond to such
- requests if it receives them.
-
- o Type_Data (Variable Length) varies with the Type of Request and
- the associated Response. For the documentation of the EAP
- methods, see [EAP].
-
- Note that since IKE passes an indication of initiator identity in the
- first message in the IKE_AUTH exchange, the responder should not send
- EAP Identity requests. The initiator may, however, respond to such
- requests if it receives them.
-
-4. Conformance Requirements
-
- In order to assure that all implementations of IKEv2 can
- interoperate, there are "MUST support" requirements in addition to
- those listed elsewhere. Of course, IKEv2 is a security protocol, and
-
-
-
-Kaufman, et al. Standards Track [Page 118]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- one of its major functions is to allow only authorized parties to
- successfully complete establishment of SAs. So a particular
- implementation may be configured with any of a number of restrictions
- concerning algorithms and trusted authorities that will prevent
- universal interoperability.
-
- IKEv2 is designed to permit minimal implementations that can
- interoperate with all compliant implementations. The following are
- features that can be omitted in a minimal implementation:
-
- o Ability to negotiate SAs through a NAT and tunnel the resulting
- ESP SA over UDP.
-
- o Ability to request (and respond to a request for) a temporary IP
- address on the remote end of a tunnel.
-
- o Ability to support EAP-based authentication.
-
- o Ability to support window sizes greater than one.
-
- o Ability to establish multiple ESP or AH SAs within a single IKE
- SA.
-
- o Ability to rekey SAs.
-
- To assure interoperability, all implementations MUST be capable of
- parsing all payload types (if only to skip over them) and to ignore
- payload types that it does not support unless the critical bit is set
- in the payload header. If the critical bit is set in an unsupported
- payload header, all implementations MUST reject the messages
- containing those payloads.
-
- Every implementation MUST be capable of doing four-message
- IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE,
- one for ESP or AH). Implementations MAY be initiate-only or respond-
- only if appropriate for their platform. Every implementation MUST be
- capable of responding to an INFORMATIONAL exchange, but a minimal
- implementation MAY respond to any request in the INFORMATIONAL
- exchange with an empty response (note that within the context of an
- IKE SA, an "empty" message consists of an IKE header followed by an
- Encrypted payload with no payloads contained in it). A minimal
- implementation MAY support the CREATE_CHILD_SA exchange only in so
- far as to recognize requests and reject them with a Notify payload of
- type NO_ADDITIONAL_SAS. A minimal implementation need not be able to
- initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA
- expires (based on locally configured values of either lifetime or
- octets passed), and implementation MAY either try to renew it with a
- CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and
-
-
-
-Kaufman, et al. Standards Track [Page 119]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- create a new one. If the responder rejects the CREATE_CHILD_SA
- request with a NO_ADDITIONAL_SAS notification, the implementation
- MUST be capable of instead deleting the old SA and creating a new
- one.
-
- Implementations are not required to support requesting temporary IP
- addresses or responding to such requests. If an implementation does
- support issuing such requests and its policy requires using temporary
- IP addresses, it MUST include a CP payload in the first message in
- the IKE_AUTH exchange containing at least a field of type
- INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. All other fields are
- optional. If an implementation supports responding to such requests,
- it MUST parse the CP payload of type CFG_REQUEST in the first message
- in the IKE_AUTH exchange and recognize a field of type
- INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports leasing
- an address of the appropriate type, it MUST return a CP payload of
- type CFG_REPLY containing an address of the requested type. The
- responder may include any other related attributes.
-
- For an implementation to be called conforming to this specification,
- it MUST be possible to configure it to accept the following:
-
- o Public Key Infrastructure using X.509 (PKIX) Certificates
- containing and signed by RSA keys of size 1024 or 2048 bits, where
- the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or
- ID_DER_ASN1_DN.
-
- o Shared key authentication where the ID passed is any of ID_KEY_ID,
- ID_FQDN, or ID_RFC822_ADDR.
-
- o Authentication where the responder is authenticated using PKIX
- Certificates and the initiator is authenticated using shared key
- authentication.
-
-5. Security Considerations
-
- While this protocol is designed to minimize disclosure of
- configuration information to unauthenticated peers, some such
- disclosure is unavoidable. One peer or the other must identify
- itself first and prove its identity first. To avoid probing, the
- initiator of an exchange is required to identify itself first, and
- usually is required to authenticate itself first. The initiator can,
- however, learn that the responder supports IKE and what cryptographic
- protocols it supports. The responder (or someone impersonating the
- responder) can probe the initiator not only for its identity, but
- using CERTREQ payloads may be able to determine what certificates the
- initiator is willing to use.
-
-
-
-
-Kaufman, et al. Standards Track [Page 120]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Use of EAP authentication changes the probing possibilities somewhat.
- When EAP authentication is used, the responder proves its identity
- before the initiator does, so an initiator that knew the name of a
- valid initiator could probe the responder for both its name and
- certificates.
-
- Repeated rekeying using CREATE_CHILD_SA without additional Diffie-
- Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a
- single key. Implementers should take note of this fact and set a
- limit on CREATE_CHILD_SA exchanges between exponentiations. This
- document does not prescribe such a limit.
-
- The strength of a key derived from a Diffie-Hellman exchange using
- any of the groups defined here depends on the inherent strength of
- the group, the size of the exponent used, and the entropy provided by
- the random number generator used. Due to these inputs, it is
- difficult to determine the strength of a key for any of the defined
- groups. Diffie-Hellman group number two, when used with a strong
- random number generator and an exponent no less than 200 bits, is
- common for use with 3DES. Group five provides greater security than
- group two. Group one is for historic purposes only and does not
- provide sufficient strength except for use with DES, which is also
- for historic use only. Implementations should make note of these
- estimates when establishing policy and negotiating security
- parameters.
-
- Note that these limitations are on the Diffie-Hellman groups
- themselves. There is nothing in IKE that prohibits using stronger
- groups nor is there anything that will dilute the strength obtained
- from stronger groups (limited by the strength of the other algorithms
- negotiated including the PRF). In fact, the extensible framework of
- IKE encourages the definition of more groups; use of elliptic curve
- groups may greatly increase strength using much smaller numbers.
-
- It is assumed that all Diffie-Hellman exponents are erased from
- memory after use.
-
- The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator
- has been authenticated. As a result, an implementation of this
- protocol needs to be completely robust when deployed on any insecure
- network. Implementation vulnerabilities, particularly DoS attacks,
- can be exploited by unauthenticated peers. This issue is
- particularly worrisome because of the unlimited number of messages in
- EAP-based authentication.
-
- The strength of all keys is limited by the size of the output of the
- negotiated PRF. For this reason, a PRF whose output is less than 128
- bits (e.g., 3DES-CBC) MUST NOT be used with this protocol.
-
-
-
-Kaufman, et al. Standards Track [Page 121]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- The security of this protocol is critically dependent on the
- randomness of the randomly chosen parameters. These should be
- generated by a strong random or properly seeded pseudorandom source
- (see [RANDOMNESS]). Implementers should take care to ensure that use
- of random numbers for both keys and nonces is engineered in a fashion
- that does not undermine the security of the keys.
-
- For information on the rationale of many of the cryptographic design
- choices in this protocol, see [SIGMA] and [SKEME]. Though the
- security of negotiated Child SAs does not depend on the strength of
- the encryption and integrity protection negotiated in the IKE SA,
- implementations MUST NOT negotiate NONE as the IKE integrity
- protection algorithm or ENCR_NULL as the IKE encryption algorithm.
-
- When using pre-shared keys, a critical consideration is how to assure
- the randomness of these secrets. The strongest practice is to ensure
- that any pre-shared key contain as much randomness as the strongest
- key being negotiated. Deriving a shared secret from a password,
- name, or other low-entropy source is not secure. These sources are
- subject to dictionary and social-engineering attacks, among others.
-
- The NAT_DETECTION_*_IP notifications contain a hash of the addresses
- and ports in an attempt to hide internal IP addresses behind a NAT.
- Since the IPv4 address space is only 32 bits, and it is usually very
- sparse, it would be possible for an attacker to find out the internal
- address used behind the NAT box by trying all possible IP addresses
- and trying to find the matching hash. The port numbers are normally
- fixed to 500, and the SPIs can be extracted from the packet. This
- reduces the number of hash calculations to 2^32. With an educated
- guess of the use of private address space, the number of hash
- calculations is much smaller. Designers should therefore not assume
- that use of IKE will not leak internal address information.
-
- When using an EAP authentication method that does not generate a
- shared key for protecting a subsequent AUTH payload, certain man-in-
- the-middle and server-impersonation attacks are possible [EAPMITM].
- These vulnerabilities occur when EAP is also used in protocols that
- are not protected with a secure tunnel. Since EAP is a general-
- purpose authentication protocol, which is often used to provide
- single-signon facilities, a deployed IPsec solution that relies on an
- EAP authentication method that does not generate a shared key (also
- known as a non-key-generating EAP method) can become compromised due
- to the deployment of an entirely unrelated application that also
- happens to use the same non-key-generating EAP method, but in an
- unprotected fashion. Note that this vulnerability is not limited to
- just EAP, but can occur in other scenarios where an authentication
- infrastructure is reused. For example, if the EAP mechanism used by
- IKEv2 utilizes a token authenticator, a man-in-the-middle attacker
-
-
-
-Kaufman, et al. Standards Track [Page 122]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- could impersonate the web server, intercept the token authentication
- exchange, and use it to initiate an IKEv2 connection. For this
- reason, use of non-key-generating EAP methods SHOULD be avoided where
- possible. Where they are used, it is extremely important that all
- usages of these EAP methods SHOULD utilize a protected tunnel, where
- the initiator validates the responder's certificate before initiating
- the EAP authentication. Implementers should describe the
- vulnerabilities of using non-key-generating EAP methods in the
- documentation of their implementations so that the administrators
- deploying IPsec solutions are aware of these dangers.
-
- An implementation using EAP MUST also use a public-key-based
- authentication of the server to the client before the EAP
- authentication begins, even if the EAP method offers mutual
- authentication. This avoids having additional IKEv2 protocol
- variations and protects the EAP data from active attackers.
-
- If the messages of IKEv2 are long enough that IP-level fragmentation
- is necessary, it is possible that attackers could prevent the
- exchange from completing by exhausting the reassembly buffers. The
- chances of this can be minimized by using the Hash and URL encodings
- instead of sending certificates (see Section 3.6). Additional
- mitigations are discussed in [DOSUDPPROT].
-
- Admission control is critical to the security of the protocol. For
- example, trust anchors used for identifying IKE peers should probably
- be different than those used for other forms of trust, such as those
- used to identify public web servers. Moreover, although IKE provides
- a great deal of leeway in defining the security policy for a trusted
- peer's identity, credentials, and the correlation between them,
- having such security policy defined explicitly is essential to a
- secure implementation.
-
-5.1. Traffic Selector Authorization
-
- IKEv2 relies on information in the Peer Authorization Database (PAD)
- when determining what kind of Child SAs a peer is allowed to create.
- This process is described in Section 4.4.3 of [IPSECARCH]. When a
- peer requests the creation of an Child SA with some Traffic
- Selectors, the PAD must contain "Child SA Authorization Data" linking
- the identity authenticated by IKEv2 and the addresses permitted for
- Traffic Selectors.
-
- For example, the PAD might be configured so that authenticated
- identity "sgw23.example.com" is allowed to create Child SAs for
- 192.0.2.0/24, meaning this security gateway is a valid
- "representative" for these addresses. Host-to-host IPsec requires
-
-
-
-
-Kaufman, et al. Standards Track [Page 123]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- similar entries, linking, for example, "fooserver4.example.com" with
- 198.51.100.66/32, meaning this identity is a valid "owner" or
- "representative" of the address in question.
-
- As noted in [IPSECARCH], "It is necessary to impose these constraints
- on creation of child SAs to prevent an authenticated peer from
- spoofing IDs associated with other, legitimate peers". In the
- example given above, a correct configuration of the PAD prevents
- sgw23 from creating Child SAs with address 198.51.100.66, and
- prevents fooserver4 from creating Child SAs with addresses from
- 192.0.2.0/24.
-
- It is important to note that simply sending IKEv2 packets using some
- particular address does not imply a permission to create Child SAs
- with that address in the Traffic Selectors. For example, even if
- sgw23 would be able to spoof its IP address as 198.51.100.66, it
- could not create Child SAs matching fooserver4's traffic.
-
- The IKEv2 specification does not specify how exactly IP address
- assignment using Configuration payloads interacts with the PAD. Our
- interpretation is that when a security gateway assigns an address
- using Configuration payloads, it also creates a temporary PAD entry
- linking the authenticated peer identity and the newly allocated inner
- address.
-
- It has been recognized that configuring the PAD correctly may be
- difficult in some environments. For instance, if IPsec is used
- between a pair of hosts whose addresses are allocated dynamically
- using DHCP, it is extremely difficult to ensure that the PAD
- specifies the correct "owner" for each IP address. This would
- require a mechanism to securely convey address assignments from the
- DHCP server, and link them to identities authenticated using IKEv2.
-
- Due to this limitation, some vendors have been known to configure
- their PADs to allow an authenticated peer to create Child SAs with
- Traffic Selectors containing the same address that was used for the
- IKEv2 packets. In environments where IP spoofing is possible (i.e.,
- almost everywhere) this essentially allows any peer to create Child
- SAs with any Traffic Selectors. This is not an appropriate or secure
- configuration in most circumstances. See [H2HIPSEC] for an extensive
- discussion about this issue, and the limitations of host-to-host
- IPsec in general.
-
-6. IANA Considerations
-
- [IKEV2] defined many field types and values. IANA has already
- registered those types and values in [IKEV2IANA], so they are not
- listed here again.
-
-
-
-Kaufman, et al. Standards Track [Page 124]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- Two items have been removed from the IKEv2 Configuration Payload
- Attribute Types table: INTERNAL_IP6_NBNS and INTERNAL_ADDRESS_EXPIRY.
-
- Two new additions to the IKEv2 parameters "NOTIFY MESSAGES - ERROR
- TYPES" registry are defined here that were not defined in [IKEV2]:
-
- 43 TEMPORARY_FAILURE
- 44 CHILD_SA_NOT_FOUND
-
- IANA has changed the existing IKEv2 Payload Types table from:
-
- 46 Encrypted E [IKEV2]
-
- to
-
- 46 Encrypted and Authenticated SK [This document]
-
- IANA has updated all references to RFC 4306 to point to this
- document.
-
-7. Acknowledgements
-
- Many individuals in the IPsecME Working Group were very helpful in
- contributing ideas and text for this document, as well as in
- reviewing the clarifications suggested by others.
-
- The acknowledgements from the IKEv2 document were:
-
- This document is a collaborative effort of the entire IPsec WG. If
- there were no limit to the number of authors that could appear on an
- RFC, the following, in alphabetical order, would have been listed:
- Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt
- Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John
- Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero
- Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer
- Reingold, and Michael Richardson. Many other people contributed to
- the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI,
- each of which has its own list of authors. Hugh Daniel suggested the
- feature of having the initiator, in message 3, specify a name for the
- responder, and gave the feature the cute name "You Tarzan, Me Jane".
- David Faucher and Valery Smyslov helped refine the design of the
- Traffic Selector negotiation.
-
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 125]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-8. References
-
-8.1. Normative References
-
- [ADDGROUP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
- Diffie-Hellman groups for Internet Key Exchange (IKE)",
- RFC 3526, May 2003.
-
- [ADDRIPV6] Hinden, R. and S. Deering, "IP Version 6 Addressing
- Architecture", RFC 4291, February 2006.
-
- [AEAD] Black, D. and D. McGrew, "Using Authenticated Encryption
- Algorithms with the Encrypted Payload of the Internet Key
- Exchange version 2 (IKEv2) Protocol", RFC 5282,
- August 2008.
-
- [AESCMACPRF128]
- Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
- Advanced Encryption Standard-Cipher-based Message
- Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
- PRF-128) Algorithm for the Internet Key Exchange Protocol
- (IKE)", RFC 4615, August 2006.
-
- [AESXCBCPRF128]
- Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
- Internet Key Exchange Protocol (IKE)", RFC 4434,
- February 2006.
-
- [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
- Levkowetz, "Extensible Authentication Protocol (EAP)",
- RFC 3748, June 2004.
-
- [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
- of Explicit Congestion Notification (ECN) to IP",
- RFC 3168, September 2001.
-
- [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
- Algorithms", RFC 2451, November 1998.
-
- [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
- Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
- Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
-
- [IKEV2IANA]
- "Internet Key Exchange Version 2 (IKEv2) Parameters",
- <http://www.iana.org>.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 126]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- [IPSECARCH]
- Kent, S. and K. Seo, "Security Architecture for the
- Internet Protocol", RFC 4301, December 2005.
-
- [MUSTSHOULD]
- Bradner, S., "Key words for use in RFCs to Indicate
- Requirement Levels", BCP 14, RFC 2119, March 1997.
-
- [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
- Standards (PKCS) #1: RSA Cryptography Specifications
- Version 2.1", RFC 3447, February 2003.
-
- [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
- Housley, R., and W. Polk, "Internet X.509 Public Key
- Infrastructure Certificate and Certificate Revocation List
- (CRL) Profile", RFC 5280, May 2008.
-
- [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
- Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
- December 2005.
-
- [UDPENCAPS]
- Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
- Stenberg, "UDP Encapsulation of IPsec ESP Packets",
- RFC 3948, January 2005.
-
- [URLS] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
- Resource Identifier (URI): Generic Syntax", STD 66,
- RFC 3986, January 2005.
-
-8.2. Informative References
-
- [AH] Kent, S., "IP Authentication Header", RFC 4302,
- December 2005.
-
- [ARCHGUIDEPHIL]
- Bush, R. and D. Meyer, "Some Internet Architectural
- Guidelines and Philosophy", RFC 3439, December 2002.
-
- [ARCHPRINC]
- Carpenter, B., "Architectural Principles of the Internet",
- RFC 1958, June 1996.
-
- [Clarif] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
- Implementation Guidelines", RFC 4718, October 2006.
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 127]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- [DES] American National Standards Institute, "American National
- Standard for Information Systems-Data Link Encryption",
- ANSI X3.106, 1983.
-
- [DH] Diffie, W. and M. Hellman, "New Directions in
- Cryptography", IEEE Transactions on Information Theory,
- V.IT-22 n. 6, June 1977.
-
- [DIFFSERVARCH]
- Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
- and W. Weiss, "An Architecture for Differentiated
- Services", RFC 2475, December 1998.
-
- [DIFFSERVFIELD]
- Nichols, K., Blake, S., Baker, F., and D. Black,
- "Definition of the Differentiated Services Field (DS
- Field) in the IPv4 and IPv6 Headers", RFC 2474,
- December 1998.
-
- [DIFFTUNNEL]
- Black, D., "Differentiated Services and Tunnels",
- RFC 2983, October 2000.
-
- [DOI] Piper, D., "The Internet IP Security Domain of
- Interpretation for ISAKMP", RFC 2407, November 1998.
-
- [DOSUDPPROT]
- C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection
- for UDP-based protocols", ACM Conference on Computer and
- Communications Security, October 2003.
-
- [DSS] National Institute of Standards and Technology, U.S.
- Department of Commerce, "Digital Signature Standard",
- Draft FIPS 186-3, June 2008.
-
- [EAI] Abel, Y., "Internationalized Email Headers", RFC 5335,
- September 2008.
-
- [EAP-IANA] "Extensible Authentication Protocol (EAP) Registry: Method
- Types", <http://www.iana.org>.
-
- [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in
- Tunneled Authentication Protocols", November 2002,
- <http://eprint.iacr.org/2002/163>.
-
- [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)",
- RFC 4303, December 2005.
-
-
-
-
-Kaufman, et al. Standards Track [Page 128]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- [EXCHANGEANALYSIS]
- R. Perlman and C. Kaufman, "Analysis of the IPsec key
- exchange Standard", WET-ICE Security Conference, MIT,
- 2001,
- <http://sec.femto.org/wetice-2001/papers/radia-paper.pdf>.
-
- [H2HIPSEC] Aura, T., Roe, M., and A. Mohammed, "Experiences with
- Host-to-Host IPsec", 13th International Workshop on
- Security Protocols, Cambridge, UK, April 2005.
-
- [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
- Hashing for Message Authentication", RFC 2104,
- February 1997.
-
- [IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH
- Series in Information Processing, v. 1, Konstanz: Hartung-
- Gorre Verlag, 1992.
-
- [IDNA] Klensin, J., "Internationalized Domain Names for
- Applications (IDNA): Definitions and Document Framework",
- RFC 5890, August 2010.
-
- [IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange
- (IKE)", RFC 2409, November 1998.
-
- [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
- RFC 4306, December 2005.
-
- [IP] Postel, J., "Internet Protocol", STD 5, RFC 791,
- September 1981.
-
- [IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP
- Payload Compression Protocol (IPComp)", RFC 3173,
- September 2001.
-
- [IPSECARCH-OLD]
- Kent, S. and R. Atkinson, "Security Architecture for the
- Internet Protocol", RFC 2401, November 1998.
-
- [IPV6CONFIG]
- Eronen, P., Laganier, J., and C. Madson, "IPv6
- Configuration in Internet Key Exchange Protocol Version 2
- (IKEv2)", RFC 5739, February 2010.
-
- [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet
- Security Association and Key Management Protocol
- (ISAKMP)", RFC 2408, November 1998.
-
-
-
-
-Kaufman, et al. Standards Track [Page 129]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- [MAILFORMAT]
- Resnick, P., Ed., "Internet Message Format", RFC 5322,
- October 2008.
-
- [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
- April 1992.
-
- [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
- in IPv6", RFC 3775, June 2004.
-
- [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery
- Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
-
- [MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
- (MOBIKE)", RFC 4555, June 2006.
-
- [MODES] National Institute of Standards and Technology, U.S.
- Department of Commerce, "Recommendation for Block Cipher
- Modes of Operation", SP 800-38A, 2001.
-
- [NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
- Network Access Identifier", RFC 4282, December 2005.
-
- [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
- (NAT) Compatibility Requirements", RFC 3715, March 2004.
-
- [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol",
- RFC 2412, November 1998.
-
- [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
- Management API, Version 2", RFC 2367, July 1998.
-
- [PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management
- Protocol", RFC 2522, March 1999.
-
- [RANDOMNESS]
- Eastlake, D., Schiller, J., and S. Crocker, "Randomness
- Requirements for Security", BCP 106, RFC 4086, June 2005.
-
- [REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange
- (IKEv2) Protocol", RFC 4478, April 2006.
-
- [REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In
- Diffie-Hellman Key Agreement Protocols", December 2008,
- <http://www.cacr.math.uwaterloo.ca/techreports/2008/
- cacr2008-24.pdf>.
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 130]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- [ROHCV2] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C.
- Bormann, "IKEv2 Extensions to Support Robust Header
- Compression over IPsec", RFC 5857, May 2010.
-
- [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for
- Obtaining Digital Signatures and Public-Key
- Cryptosystems", February 1978.
-
- [SHA] National Institute of Standards and Technology, U.S.
- Department of Commerce, "Secure Hash Standard",
- FIPS 180-3, October 2008.
-
- [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to
- Authenticated Diffie-Hellman and its Use in the IKE
- Protocols", Advances in Cryptography - CRYPTO 2003
- Proceedings LNCS 2729, 2003, <http://
- www.informatik.uni-trier.de/~ley/db/conf/crypto/
- crypto2003.html>.
-
- [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange
- Mechanism for Internet", IEEE Proceedings of the 1996
- Symposium on Network and Distributed Systems Security ,
- 1996.
-
- [TRANSPARENCY]
- Carpenter, B., "Internet Transparency", RFC 2775,
- February 2000.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 131]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-Appendix A. Summary of Changes from IKEv1
-
- The goals of this revision to IKE are:
-
- 1. To define the entire IKE protocol in a single document,
- replacing RFCs 2407, 2408, and 2409 and incorporating subsequent
- changes to support NAT Traversal, Extensible Authentication, and
- Remote Address acquisition;
-
- 2. To simplify IKE by replacing the eight different initial
- exchanges with a single four-message exchange (with changes in
- authentication mechanisms affecting only a single AUTH payload
- rather than restructuring the entire exchange) see
- [EXCHANGEANALYSIS];
-
- 3. To remove the Domain of Interpretation (DOI), Situation (SIT),
- and Labeled Domain Identifier fields, and the Commit and
- Authentication only bits;
-
- 4. To decrease IKE's latency in the common case by making the
- initial exchange be 2 round trips (4 messages), and allowing the
- ability to piggyback setup of a Child SA on that exchange;
-
- 5. To replace the cryptographic syntax for protecting the IKE
- messages themselves with one based closely on ESP to simplify
- implementation and security analysis;
-
- 6. To reduce the number of possible error states by making the
- protocol reliable (all messages are acknowledged) and sequenced.
- This allows shortening CREATE_CHILD_SA exchanges from 3 messages
- to 2;
-
- 7. To increase robustness by allowing the responder to not do
- significant processing until it receives a message proving that
- the initiator can receive messages at its claimed IP address;
-
- 8. To fix cryptographic weaknesses such as the problem with
- symmetries in hashes used for authentication (documented by Tero
- Kivinen);
-
- 9. To specify Traffic Selectors in their own payloads type rather
- than overloading ID payloads, and making more flexible the
- Traffic Selectors that may be specified;
-
- 10. To specify required behavior under certain error conditions or
- when data that is not understood is received in order to make it
- easier to make future revisions in a way that does not break
- backward compatibility;
-
-
-
-Kaufman, et al. Standards Track [Page 132]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
- 11. To simplify and clarify how shared state is maintained in the
- presence of network failures and DoS attacks; and
-
- 12. To maintain existing syntax and magic numbers to the extent
- possible to make it likely that implementations of IKEv1 can be
- enhanced to support IKEv2 with minimum effort.
-
-Appendix B. Diffie-Hellman Groups
-
- There are two Diffie-Hellman groups defined here for use in IKE.
- These groups were generated by Richard Schroeppel at the University
- of Arizona. Properties of these primes are described in [OAKLEY].
-
- The strength supplied by group 1 may not be sufficient for typical
- uses and is here for historic reasons.
-
- Additional Diffie-Hellman groups have been defined in [ADDGROUP].
-
-B.1. Group 1 - 768-bit MODP
-
- This group is assigned ID 1 (one).
-
- The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 }
- Its hexadecimal value is:
-
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
-
- The generator is 2.
-
-B.2. Group 2 - 1024-bit MODP
-
- This group is assigned ID 2 (two).
-
- The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
- Its hexadecimal value is:
-
- FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
- 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
- EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
- E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
- EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
- FFFFFFFF FFFFFFFF
-
- The generator is 2.
-
-
-
-
-Kaufman, et al. Standards Track [Page 133]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-Appendix C. Exchanges and Payloads
-
- This appendix contains a short summary of the IKEv2 exchanges, and
- what payloads can appear in which message. This appendix is purely
- informative; if it disagrees with the body of this document, the
- other text is considered correct.
-
- Vendor ID (V) payloads may be included in any place in any message.
- This sequence here shows what are the most logical places for them.
-
-C.1. IKE_SA_INIT Exchange
-
- request --> [N(COOKIE)],
- SA, KE, Ni,
- [N(NAT_DETECTION_SOURCE_IP)+,
- N(NAT_DETECTION_DESTINATION_IP)],
- [V+][N+]
-
- normal response <-- SA, KE, Nr,
- (no cookie) [N(NAT_DETECTION_SOURCE_IP),
- N(NAT_DETECTION_DESTINATION_IP)],
- [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
- [V+][N+]
-
- cookie response <-- N(COOKIE),
- [V+][N+]
-
- different Diffie- <-- N(INVALID_KE_PAYLOAD),
- Hellman group [V+][N+]
- wanted
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 134]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-C.2. IKE_AUTH Exchange without EAP
-
- request --> IDi, [CERT+],
- [N(INITIAL_CONTACT)],
- [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
- [IDr],
- AUTH,
- [CP(CFG_REQUEST)],
- [N(IPCOMP_SUPPORTED)+],
- [N(USE_TRANSPORT_MODE)],
- [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
- [N(NON_FIRST_FRAGMENTS_ALSO)],
- SA, TSi, TSr,
- [V+][N+]
-
- response <-- IDr, [CERT+],
- AUTH,
- [CP(CFG_REPLY)],
- [N(IPCOMP_SUPPORTED)],
- [N(USE_TRANSPORT_MODE)],
- [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
- [N(NON_FIRST_FRAGMENTS_ALSO)],
- SA, TSi, TSr,
- [N(ADDITIONAL_TS_POSSIBLE)],
- [V+][N+]
-
- error in Child SA <-- IDr, [CERT+],
- creation AUTH,
- N(error),
- [V+][N+]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 135]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-C.3. IKE_AUTH Exchange with EAP
-
- first request --> IDi,
- [N(INITIAL_CONTACT)],
- [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
- [IDr],
- [CP(CFG_REQUEST)],
- [N(IPCOMP_SUPPORTED)+],
- [N(USE_TRANSPORT_MODE)],
- [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
- [N(NON_FIRST_FRAGMENTS_ALSO)],
- SA, TSi, TSr,
- [V+][N+]
-
- first response <-- IDr, [CERT+], AUTH,
- EAP,
- [V+][N+]
-
- / --> EAP
- repeat 1..N times |
- \ <-- EAP
-
- last request --> AUTH
-
- last response <-- AUTH,
- [CP(CFG_REPLY)],
- [N(IPCOMP_SUPPORTED)],
- [N(USE_TRANSPORT_MODE)],
- [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
- [N(NON_FIRST_FRAGMENTS_ALSO)],
- SA, TSi, TSr,
- [N(ADDITIONAL_TS_POSSIBLE)],
- [V+][N+]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 136]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs
-
- request --> [N(REKEY_SA)],
- [CP(CFG_REQUEST)],
- [N(IPCOMP_SUPPORTED)+],
- [N(USE_TRANSPORT_MODE)],
- [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
- [N(NON_FIRST_FRAGMENTS_ALSO)],
- SA, Ni, [KEi], TSi, TSr
- [V+][N+]
-
- normal <-- [CP(CFG_REPLY)],
- response [N(IPCOMP_SUPPORTED)],
- [N(USE_TRANSPORT_MODE)],
- [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
- [N(NON_FIRST_FRAGMENTS_ALSO)],
- SA, Nr, [KEr], TSi, TSr,
- [N(ADDITIONAL_TS_POSSIBLE)]
- [V+][N+]
-
- error case <-- N(error)
-
- different Diffie- <-- N(INVALID_KE_PAYLOAD),
- Hellman group [V+][N+]
- wanted
-
-C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA
-
- request --> SA, Ni, KEi
- [V+][N+]
-
- response <-- SA, Nr, KEr
- [V+][N+]
-
-C.6. INFORMATIONAL Exchange
-
- request --> [N+],
- [D+],
- [CP(CFG_REQUEST)]
-
- response <-- [N+],
- [D+],
- [CP(CFG_REPLY)]
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 137]
-\f
-RFC 5996 IKEv2bis September 2010
-
-
-Authors' Addresses
-
- Charlie Kaufman
- Microsoft
- 1 Microsoft Way
- Redmond, WA 98052
- US
-
- Phone: 1-425-707-3335
- EMail: charliek@microsoft.com
-
-
- Paul Hoffman
- VPN Consortium
- 127 Segre Place
- Santa Cruz, CA 95060
- US
-
- Phone: 1-831-426-9827
- EMail: paul.hoffman@vpnc.org
-
-
- Yoav Nir
- Check Point Software Technologies Ltd.
- 5 Hasolelim St.
- Tel Aviv 67897
- Israel
-
- EMail: ynir@checkpoint.com
-
-
- Pasi Eronen
- Independent
-
- EMail: pe@iki.fi
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Kaufman, et al. Standards Track [Page 138]
-\f
+++ /dev/null
-
-
-
-
-
-
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
-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]
-\f
projects / thirdparty / strongswan.git / commitdiff
