< draft-ietf-ipsec-ikev2-15.txt   draft-ietf-ipsec-ikev2-16.txt >
INTERNET-DRAFT Charlie Kaufman, Editor INTERNET-DRAFT Charlie Kaufman, Editor
draft-ietf-ipsec-ikev2-15.txt draft-ietf-ipsec-ikev2-16.txt
Obsoletes: 2407, 2408, 2409 August 13, 2004 Obsoletes: 2407, 2408, 2409 September 13, 2004
Expires: February 2005 Expires: March 2005
Internet Key Exchange (IKEv2) Protocol Internet Key Exchange (IKEv2) Protocol
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. Internet-Drafts are working documents of of Section 10 of RFC2026. Internet-Drafts are working documents of
the Internet Engineering Task Force (IETF), its areas, and its the Internet Engineering Task Force (IETF), its areas, and its
working groups. Note that other groups may also distribute working working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
This Internet-Draft expires in February 2005. This Internet-Draft expires in February 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document describes version 2 of the Internet Key Exchange (IKE) This document describes version 2 of the Internet Key Exchange (IKE)
protocol. IKE is a component of IPsec used for performing mutual protocol. IKE is a component of IPsec used for performing mutual
authentication and establishing and maintaining security authentication and establishing and maintaining security associations
associations. (SAs).
This version of the IKE specification combines the contents of what This version of the IKE specification combines the contents of what
were previously separate documents, including ISAKMP (RFC 2408), IKE were previously separate documents, including ISAKMP (RFC 2408), IKE
(RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy
authentication, and remote address acquisition. authentication, and remote address acquisition.
Version 2 of IKE does not interoperate with version 1, but it has Version 2 of IKE does not interoperate with version 1, but it has
enough of the header format in common that both versions can enough of the header format in common that both versions can
unambiguously run over the same UDP port. unambiguously run over the same UDP port.
Table of Contents Table of Contents
1 Introduction...............................................3 1 Introduction...............................................3
1.1 Usage Scenarios..........................................5 1.1 Usage Scenarios..........................................5
1.2 The Initial Exchange.....................................7 1.2 The Initial Exchanges....................................7
1.3 The CREATE_CHILD_SA Exchange.............................9 1.3 The CREATE_CHILD_SA Exchange.............................9
1.4 The INFORMATIONAL Exchange..............................11 1.4 The INFORMATIONAL Exchange..............................11
1.5 Informational Messages outside of an IKE_SA.............12 1.5 Informational Messages outside of an IKE_SA.............12
2 IKE Protocol Details and Variations.......................12 2 IKE Protocol Details and Variations.......................12
2.1 Use of Retransmission Timers............................13 2.1 Use of Retransmission Timers............................13
2.2 Use of Sequence Numbers for Message ID..................13 2.2 Use of Sequence Numbers for Message ID..................14
2.3 Window Size for overlapping requests....................14 2.3 Window Size for overlapping requests....................14
2.4 State Synchronization and Connection Timeouts...........15 2.4 State Synchronization and Connection Timeouts...........15
2.5 Version Numbers and Forward Compatibility...............16 2.5 Version Numbers and Forward Compatibility...............17
2.6 Cookies.................................................18 2.6 Cookies.................................................18
2.7 Cryptographic Algorithm Negotiation.....................20 2.7 Cryptographic Algorithm Negotiation.....................20
2.8 Rekeying................................................21 2.8 Rekeying................................................21
2.9 Traffic Selector Negotiation............................23 2.9 Traffic Selector Negotiation............................23
2.10 Nonces.................................................25 2.10 Nonces.................................................25
2.11 Address and Port Agility...............................26 2.11 Address and Port Agility...............................26
2.12 Reuse of Diffie-Hellman Exponentials...................26 2.12 Reuse of Diffie-Hellman Exponentials...................26
2.13 Generating Keying Material.............................27 2.13 Generating Keying Material.............................27
2.14 Generating Keying Material for the IKE_SA..............28 2.14 Generating Keying Material for the IKE_SA..............28
2.15 Authentication of the IKE_SA...........................29 2.15 Authentication of the IKE_SA...........................29
2.16 Extended Authentication Protocol Methods...............30 2.16 Extensible Authentication Protocol Methods.............30
2.17 Generating Keying Material for CHILD_SAs...............32 2.17 Generating Keying Material for CHILD_SAs...............32
2.18 Rekeying IKE_SAs using a CREATE_CHILD_SA exchange......33 2.18 Rekeying IKE_SAs using a CREATE_CHILD_SA exchange......33
2.19 Requesting an internal address on a remote network.....33 2.19 Requesting an internal address on a remote network.....33
2.20 Requesting a Peer's Version............................34 2.20 Requesting a Peer's Version............................35
2.21 Error Handling.........................................35 2.21 Error Handling.........................................35
2.22 IPComp.................................................36 2.22 IPComp.................................................36
2.23 NAT Traversal..........................................37 2.23 NAT Traversal..........................................37
2.24 ECN (Explicit Congestion Notification).................39 2.24 ECN (Explicit Congestion Notification).................40
3 Header and Payload Formats................................40 3 Header and Payload Formats................................40
3.1 The IKE Header..........................................40 3.1 The IKE Header..........................................40
3.2 Generic Payload Header..................................43 3.2 Generic Payload Header..................................43
3.3 Security Association Payload............................44 3.3 Security Association Payload............................44
3.4 Key Exchange Payload....................................55 3.4 Key Exchange Payload....................................54
3.5 Identification Payloads.................................55 3.5 Identification Payloads.................................55
3.6 Certificate Payload.....................................57 3.6 Certificate Payload.....................................57
3.7 Certificate Request Payload.............................60 3.7 Certificate Request Payload.............................60
3.8 Authentication Payload..................................62 3.8 Authentication Payload..................................62
3.9 Nonce Payload...........................................62 3.9 Nonce Payload...........................................62
3.10 Notify Payload.........................................63 3.10 Notify Payload.........................................63
3.11 Delete Payload.........................................71 3.11 Delete Payload.........................................71
3.12 Vendor ID Payload......................................72 3.12 Vendor ID Payload......................................72
3.13 Traffic Selector Payload...............................73 3.13 Traffic Selector Payload...............................73
3.14 Encrypted Payload......................................76 3.14 Encrypted Payload......................................76
3.15 Configuration Payload..................................77 3.15 Configuration Payload..................................77
3.16 Extended Authentication Protocol (EAP) Payload.........82 3.16 Extensible Authentication Protocol (EAP) Payload.......82
4 Conformance Requirements..................................84 4 Conformance Requirements..................................84
5 Security Considerations...................................86 5 Security Considerations...................................86
6 IANA Considerations.......................................89 6 IANA Considerations.......................................89
7 Acknowledgements..........................................89 7 Acknowledgements..........................................89
8 References................................................90 8 References................................................90
8.1 Normative References....................................90 8.1 Normative References....................................90
8.2 Informative References..................................91 8.2 Informative References..................................91
Appendix A: Summary of Changes from IKEv1...................94 Appendix A: Summary of Changes from IKEv1...................94
Appendix B: Diffie-Hellman Groups...........................96 Appendix B: Diffie-Hellman Groups...........................96
Change History (To be removed from RFC).....................98 Change History (To be removed from RFC).....................97
Editor's Address...........................................108 Editor's Address...........................................107
Full Copyright Statement...................................108 Full Copyright Statement...................................107
Intellectual Property Statement............................108 Intellectual Property Statement............................107
Requirements Terminology Requirements Terminology
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
"MAY" that appear in this document are to be interpreted as described "MAY" that appear in this document are to be interpreted as described
in [Bra97]. in [Bra97].
The term "Expert Review" is to be interpreted as defined in The term "Expert Review" is to be interpreted as defined in
[RFC2434]. [RFC2434].
skipping to change at page 4, line 11 skipping to change at page 4, line 11
well. Therefore a protocol to establish this state dynamically is well. Therefore a protocol to establish this state dynamically is
needed. This memo describes such a protocol-- the Internet Key needed. This memo describes such a protocol-- the Internet Key
Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was
defined in RFCs 2407, 2408, and 2409. This single document is defined in RFCs 2407, 2408, and 2409. This single document is
intended to replace all three of those RFCs. intended to replace all three of those RFCs.
Definitions of the primitive terms in this document (such as Security Definitions of the primitive terms in this document (such as Security
Association or SA) can be found in [RFC2401bis]. Association or SA) can be found in [RFC2401bis].
IKE performs mutual authentication between two parties and IKE performs mutual authentication between two parties and
establishes an IKE security association that includes shared secret establishes an IKE security association (SA) that includes shared
information that can be used to efficiently establish SAs for ESP secret information that can be used to efficiently establish SAs for
[RFC2406] and/or AH [RFC2402] and a set of cryptographic algorithms ESP [RFC2406] and/or AH [RFC2402] and a set of cryptographic
to be used by the SAs to protect the traffic that they carry. In algorithms to be used by the SAs to protect the traffic that they
this document, the term "suite" or "cryptographic suite" refers to a carry. In this document, the term "suite" or "cryptographic suite"
complete set of algorithms used to protect an SA. An initiator refers to a complete set of algorithms used to protect an SA. An
proposes one or more suites by listing supported algorithms that can initiator proposes one or more suites by listing supported algorithms
be combined into suites in a mix and match fashion. IKE can also that can be combined into suites in a mix and match fashion. IKE can
negotiate use of IPComp [IPCOMP] in connection with an ESP and/or AH also negotiate use of IPComp [IPCOMP] in connection with an ESP
SA. We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that and/or AH SA. We call the IKE SA an "IKE_SA". The SAs for ESP and/or
get set up through that IKE_SA we call "CHILD_SA"s. AH that get set up through that IKE_SA we call "CHILD_SA"s.
All IKE communications consist of pairs of messages: a request and a All IKE communications consist of pairs of messages: a request and a
response. The pair is called an "exchange". We call the first response. The pair is called an "exchange". We call the first
messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges
and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL
exchanges. In the common case, there is a single IKE_SA_INIT exchange 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 and a single IKE_AUTH exchange (a total of four messages) to
establish the IKE_SA and the first CHILD_SA. In exceptional cases, 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, 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 all IKE_SA_INIT exchanges MUST complete before any other exchange
skipping to change at page 4, line 45 skipping to change at page 4, line 45
between the IPsec endpoints and therefore there would be no between the IPsec endpoints and therefore there would be no
additional exchanges. Subsequent exchanges MAY be used to establish additional exchanges. Subsequent exchanges MAY be used to establish
additional CHILD_SAs between the same authenticated pair of endpoints additional CHILD_SAs between the same authenticated pair of endpoints
and to perform housekeeping functions. and to perform housekeeping functions.
IKE message flow always consists of a request followed by a response. IKE message flow always consists of a request followed by a response.
It is the responsibility of the requester to ensure reliability. If It is the responsibility of the requester to ensure reliability. If
the response is not received within a timeout interval, the requester the response is not received within a timeout interval, the requester
needs to retransmit the request (or abandon the connection). needs to retransmit the request (or abandon the connection).
The first request/response of an IKE session negotiates security The first request/response of an IKE session (IKE_SA_INIT) negotiates
parameters for the IKE_SA, sends nonces, and sends Diffie-Hellman security parameters for the IKE_SA, sends nonces, and sends Diffie-
values. We call the initial exchange IKE_SA_INIT (request and Hellman values.
response).
The second request/response, which we'll call IKE_AUTH transmits The second request/response (IKE_AUTH) transmits identities, proves
identities, proves knowledge of the secrets corresponding to the two knowledge of the secrets corresponding to the two identities, and
identities, and sets up an SA for the first (and often only) AH sets up an SA for the first (and often only) AH and/or ESP CHILD_SA.
and/or ESP CHILD_SA.
The types of subsequent exchanges are CREATE_CHILD_SA (which creates The types of subsequent exchanges are CREATE_CHILD_SA (which creates
a CHILD_SA), and INFORMATIONAL (which deletes an SA, reports error a CHILD_SA), and INFORMATIONAL (which deletes an SA, reports error
conditions, or does other housekeeping). Every request requires a conditions, or does other housekeeping). Every request requires a
response. An INFORMATIONAL request with no payloads is commonly used response. An INFORMATIONAL request with no payloads (other than the
as a check for liveness. These subsequent exchanges cannot be used empty Encrypted payload required by the syntax) is commonly used as a
until the initial exchanges have completed. 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. In the description that follows, we assume that no errors occur.
Modifications to the flow should errors occur are described in Modifications to the flow should errors occur are described in
section 2.21. section 2.21.
1.1 Usage Scenarios 1.1 Usage Scenarios
IKE is expected to be used to negotiate ESP and/or AH SAs in a number 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. of different scenarios, each with its own special requirements.
skipping to change at page 8, line 10 skipping to change at page 8, line 9
the identities are hidden from eavesdroppers and all fields in all the identities are hidden from eavesdroppers and all fields in all
the messages are authenticated. the messages are authenticated.
In the following description, the payloads contained in the message In the following description, the payloads contained in the message
are indicated by names such as SA. The details of the contents of are indicated by names such as SA. The details of the contents of
each payload are described later. Payloads which may optionally each payload are described later. Payloads which may optionally
appear will be shown in brackets, such as [CERTREQ], would indicate appear will be shown in brackets, such as [CERTREQ], would indicate
that optionally a certificate request payload can be included. that optionally a certificate request payload can be included.
To simplify the descriptions that follow by allowing the use of To simplify the descriptions that follow by allowing the use of
gender specific personal pronouns, the initiator is assumed to be gender specific personal pronouns, the initiator will sometimes be
named "Alice" and the responder "Bob". referred to as "Alice" and the responder "Bob".
The initial exchanges are as follows: The initial exchanges are as follows:
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
HDR contains the SPIs, version numbers, and flags of various sorts. HDR contains the SPIs, version numbers, and flags of various sorts.
The SAi1 payload states the cryptographic algorithms the Initiator The SAi1 payload states the cryptographic algorithms the Initiator
supports for the IKE_SA. The KE payload sends the Initiator's supports for the IKE_SA. The KE payload sends the Initiator's
skipping to change at page 9, line 36 skipping to change at page 9, line 35
1.3 The CREATE_CHILD_SA Exchange 1.3 The CREATE_CHILD_SA Exchange
This exchange consists of a single request/response pair, and was 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 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. either end of the IKE_SA after the initial exchanges are completed.
All messages following the initial exchange are cryptographically All messages following the initial exchange are cryptographically
protected using the cryptographic algorithms and keys negotiated in protected using the cryptographic algorithms and keys negotiated in
the first two messages of the IKE exchange. These subsequent the first two messages of the IKE exchange. These subsequent
messages use the syntax of the Encrypted Payload described in section messages use the syntax of the Encrypted Payload described in section
3.14. 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 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
section the term initiator refers to the endpoint initiating this section the term initiator refers to the endpoint initiating this
exchange. The term "Alice" will always refer to the initiator of the exchange. The term "Alice" will always refer to the initiator of the
outer IKE_SA. outer IKE_SA.
A CHILD_SA is created by sending a CREATE_CHILD_SA request. The 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 CREATE_CHILD_SA request MAY optionally contain a KE payload for an
additional Diffie-Hellman exchange to enable stronger guarantees of additional Diffie-Hellman exchange to enable stronger guarantees of
forward secrecy for the CHILD_SA. The keying material for the forward secrecy for the CHILD_SA. The keying material for the
skipping to change at page 13, line 9 skipping to change at page 13, line 9
While IKEv2 messages are intended to be short, they contain While IKEv2 messages are intended to be short, they contain
structures with no hard upper bound on size (in particular, X.509 structures with no hard upper bound on size (in particular, X.509
certificates), and IKEv2 itself does not have a mechanism for certificates), and IKEv2 itself does not have a mechanism for
fragmenting large messages. IP defines a mechanism for fragmentation fragmenting large messages. IP defines a mechanism for fragmentation
of oversize UDP messages, but implementations vary in the maximum of oversize UDP messages, but implementations vary in the maximum
message size supported. Further, use of IP fragmentation opens an message size supported. Further, use of IP fragmentation opens an
implementation to denial of service attacks [KPS03]. Finally, some implementation to denial of service attacks [KPS03]. Finally, some
NAT and/or firewall implementations may block IP fragments. NAT and/or firewall implementations may block IP fragments.
IKEv2 implementations SHOULD be aware of the maximum UDP message size All IKEv2 implementations MUST be able to send, receive, and process
supported and MAY shorten messages by leaving out some certificates IKE messages that are up to 1280 bytes long, and they SHOULD be able
or cryptographic suite proposals if that will keep messages below the to send, receive, and process messages that are up to 3000 bytes
maximum. Use of the "Hash and URL" formats rather then including long. IKEv2 implementations SHOULD be aware of the maximum UDP
certificates in exchanges where possible can avoid most problems. message size supported and MAY shorten messages by leaving out some
Implementations and configuration should keep in mind, however, that certificates or cryptographic suite proposals if that will keep
if the URL lookups are only possible after the IPsec SA is messages below the maximum. Use of the "Hash and URL" formats rather
established, recursion issues could prevent this technique from then including certificates in exchanges where possible can avoid
most problems. Implementations and configuration should keep in mind,
however, that if the URL lookups are only possible after the IPsec SA
is established, recursion issues could prevent this technique from
working. working.
2.1 Use of Retransmission Timers 2.1 Use of Retransmission Timers
All messages in IKE exist in pairs: a request and a response. The 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. 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 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 initiate requests at any time, and there can be many requests and
responses "in flight" at any given moment. But each message is responses "in flight" at any given moment. But each message is
labeled as either a request or a response and for each labeled as either a request or a response and for each
skipping to change at page 15, line 39 skipping to change at page 15, line 45
ICMP messages) or IKE messages that arrive without cryptographic ICMP messages) or IKE messages that arrive without cryptographic
protection (e.g., Notify messages complaining about unknown SPIs). An protection (e.g., Notify messages complaining about unknown SPIs). An
endpoint MUST conclude that the other endpoint has failed only when endpoint MUST conclude that the other endpoint has failed only when
repeated attempts to contact it have gone unanswered for a timeout repeated attempts to contact it have gone unanswered for a timeout
period or when a cryptographically protected INITIAL_CONTACT period or when a cryptographically protected INITIAL_CONTACT
notification is received on a different IKE_SA to the same notification is received on a different IKE_SA to the same
authenticated identity. An endpoint SHOULD suspect that the other authenticated identity. An endpoint SHOULD suspect that the other
endpoint has failed based on routing information and initiate a endpoint has failed based on routing information and initiate a
request to see whether the other endpoint is alive. To check whether request to see whether the other endpoint is alive. To check whether
the other side is alive, IKE specifies an empty INFORMATIONAL message the other side is alive, IKE specifies an empty INFORMATIONAL message
that (like all IKE requests) requires an acknowledgment. If a that (like all IKE requests) requires an acknowledgment (note that
cryptographically protected message has been received from the other within the context of an IKE_SA, an "empty" message consists of an
side recently, unprotected notifications MAY be ignored. IKE header followed by an Encrypted payload that contains no
Implementations MUST limit the rate at which they take actions based payloads). If a cryptographically protected message has been received
on unprotected messages. 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 Numbers of retries and lengths of timeouts are not covered in this
specification because they do not affect interoperability. It is specification because they do not affect interoperability. It is
suggested that messages be retransmitted at least a dozen times over 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 a period of at least several minutes before giving up on an SA, but
different environments may require different rules. To be a good different environments may require different rules. To be a good
network citizen, retranmission times MUST increase exponentially to network citizen, retranmission times MUST increase exponentially to
avoid flooding the network and making an existing congestion avoid flooding the network and making an existing congestion
situation worse. If there has only been outgoing traffic on all of situation worse. If there has only been outgoing traffic on all of
the SAs associated with an IKE_SA, it is essential to confirm the SAs associated with an IKE_SA, it is essential to confirm
skipping to change at page 16, line 38 skipping to change at page 16, line 46
one of her requests. Once a cryptographically valid response is one of her requests. Once a cryptographically valid response is
received, all subsequent responses should be ignored whether or not received, all subsequent responses should be ignored whether or not
they are cryptographically valid. they are cryptographically valid.
Note that with these rules, there is no reason to negotiate and agree 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 upon an SA lifetime. If IKE presumes the partner is dead, based on
repeated lack of acknowledgment to an IKE message, then the IKE SA repeated lack of acknowledgment to an IKE message, then the IKE SA
and all CHILD_SAs set up through that IKE_SA are deleted. 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 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 do resources used to hold their state. If an IKE endpoint chooses to
so, it MUST send Delete payloads to the other end notifying it of the delete CHILD_SAs, it MUST send Delete payloads to the other end
deletion. It MAY similarly time out the IKE_SA. Closing the IKE_SA notifying it of the deletion. It MAY similarly time out the IKE_SA.
implicitly closes all associated CHILD_SAs. In this case, an IKE Closing the IKE_SA implicitly closes all associated CHILD_SAs. In
endpoint SHOULD send a Delete payload indicating that it has closed this case, an IKE endpoint SHOULD send a Delete payload indicating
the IKE_SA. that it has closed the IKE_SA.
2.5 Version Numbers and Forward Compatibility 2.5 Version Numbers and Forward Compatibility
This document describes version 2.0 of IKE, meaning the major version 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 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 some implementations will want to support both version 1.0 and
version 2.0, and in the future, other versions. version 2.0, and in the future, other versions.
The major version number should only be incremented if the packet The major version number should only be incremented if the packet
formats or required actions have changed so dramatically that an formats or required actions have changed so dramatically that an
skipping to change at page 25, line 37 skipping to change at page 25, line 45
packet, but rather - say - upon startup, then there may be no packet, but rather - say - upon startup, then there may be no
specific addresses Alice prefers for the initial tunnel over any specific addresses Alice prefers for the initial tunnel over any
other. In that case, the first values in TSi and TSr MAY be ranges other. In that case, the first values in TSi and TSr MAY be ranges
rather than specific values, and Bob chooses a subset of Alice's TSi rather than specific values, and Bob chooses a subset of Alice's TSi
and TSr that are acceptable to him. If more than one subset is and TSr that are acceptable to him. If more than one subset is
acceptable but their union is not, Bob MUST accept some subset and acceptable but their union is not, Bob MUST accept some subset and
MAY include a Notify payload of type ADDITIONAL_TS_POSSIBLE to MAY include a Notify payload of type ADDITIONAL_TS_POSSIBLE to
indicate that Alice might want to try again. This case will only indicate that Alice might want to try again. This case will only
occur when Alice and Bob are configured differently from one another. occur when Alice and Bob are configured differently from one another.
If Alice and Bob agree on the granularity of tunnels, she will never If Alice and Bob agree on the granularity of tunnels, she will never
request a tunnel wider than Bob will accept. request a tunnel wider than Bob will accept. Such misconfigurations
SHOULD be recorded in error logs.
2.10 Nonces 2.10 Nonces
The IKE_SA_INIT messages each contain a nonce. These nonces are used The IKE_SA_INIT messages each contain a nonce. These nonces are used
as inputs to cryptographic functions. The CREATE_CHILD_SA request as inputs to cryptographic functions. The CREATE_CHILD_SA request
and the CREATE_CHILD_SA response also contain nonces. These nonces and the CREATE_CHILD_SA response also contain nonces. These nonces
are used to add freshness to the key derivation technique used to are used to add freshness to the key derivation technique used to
obtain keys for CHILD_SA, and to ensure creation of strong obtain keys for CHILD_SA, and to ensure creation of strong
pseudorandom bits from the Diffie-Hellman key. Nonces used in IKEv2 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 MUST be randomly chosen, MUST be at least 128 bits in size, and MUST
skipping to change at page 29, line 7 skipping to change at page 29, line 13
The two directions of traffic flow use different keys. The keys used 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. 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 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 and SK_er. Each algorithm takes a fixed number of bits of keying
material, which is specified as part of the algorithm. For integrity 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 algorithms based on a keyed hash, the key size is always equal to the
length of the output of the underlying hash function. length of the output of the underlying hash function.
2.15 Authentication of the IKE_SA 2.15 Authentication of the IKE_SA
When not using extended authentication (see section 2.16), the peers When not using extensible authentication (see section 2.16), the
are authenticated by having each sign (or MAC using a shared secret peers are authenticated by having each sign (or MAC using a shared
as the key) a block of data. For the responder, the octets to be secret as the key) a block of data. For the responder, the octets to
signed start with the first octet of the first SPI in the header of be signed start with the first octet of the first SPI in the header
the second message and end with the last octet of the last payload in of the second message and end with the last octet of the last payload
the second message. Appended to this (for purposes of computing the in the second message. Appended to this (for purposes of computing
signature) are the initiator's nonce Ni (just the value, not the 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 payload containing it), and the value prf(SK_pr,IDr') where IDr' is
the responder's ID payload excluding the fixed header. Note that the responder's ID payload excluding the fixed header. Note that
neither the nonce Ni nor the value prf(SK_pr,IDr') are transmitted. neither the nonce Ni nor the value prf(SK_pr,IDr') are transmitted.
Similarly, the initiator signs the first message, starting with the Similarly, the initiator signs the first message, starting with the
first octet of the first SPI in the header and ending with the last 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 octet of the last payload. Appended to this (for purposes of
computing the signature) are the responder's nonce Nr, and the value 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 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 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. security of the exchange that each side sign the other side's nonce.
skipping to change at page 30, line 27 skipping to change at page 30, line 35
secret from a password is not secure. This construction is used secret from a password is not secure. This construction is used
because it is anticipated that people will do it anyway. The because it is anticipated that people will do it anyway. The
management interface by which the Shared Secret is provided MUST management interface by which the Shared Secret is provided MUST
accept ASCII strings of at least 64 octets and MUST NOT add a null 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 terminator before using them as shared secrets. It MUST also accept a
HEX encoding of the Shared Secret. The management interface MAY HEX encoding of the Shared Secret. The management interface MAY
accept other encodings if the algorithm for translating the encoding accept other encodings if the algorithm for translating the encoding
to a binary string is specified. If the negotiated prf takes a fixed to a binary string is specified. If the negotiated prf takes a fixed
size key, the shared secret MUST be of that fixed size. size key, the shared secret MUST be of that fixed size.
2.16 Extended Authentication Protocol Methods 2.16 Extensible Authentication Protocol Methods
In addition to authentication using public key signatures and shared In addition to authentication using public key signatures and shared
secrets, IKE supports authentication using methods defined in RFC secrets, IKE supports authentication using methods defined in RFC
2284 [EAP]. Typically, these methods are asymmetric (designed for a 3748 [EAP]. Typically, these methods are asymmetric (designed for a
user authenticating to a server), and they may not be mutual. For user authenticating to a server), and they may not be mutual. For
this reason, these protocols are typically used to authenticate the this reason, these protocols are typically used to authenticate the
initiator to the responder and MUST be used in conjunction with a initiator to the responder and MUST be used in conjunction with a
public key signature based authentication of the responder to the public key signature based authentication of the responder to the
initiator. These methods are often associated with mechanisms initiator. These methods are often associated with mechanisms
referred to as "Legacy Authentication" mechanisms. referred to as "Legacy Authentication" mechanisms.
While this memo references [EAP] with the intent that new methods can While this memo references [EAP] with the intent that new methods can
be added in the future without updating this specification, the be added in the future without updating this specification, some
protocols expected to be used most commonly are documented here and simpler variations are documented here and in section 3.16. [EAP]
in section 3.16. [EAP] defines an authentication protocol requiring defines an authentication protocol requiring a variable number of
a variable number of messages. Extended Authentication is implemented messages. Extensible Authentication is implemented in IKE as
in IKE as additional IKE_AUTH exchanges that MUST be completed in additional IKE_AUTH exchanges that MUST be completed in order to
order to initialize the IKE_SA. initialize the IKE_SA.
An initiator indicates a desire to use extended authentication by An initiator indicates a desire to use extensible authentication by
leaving out the AUTH payload from message 3. By including an IDi leaving out the AUTH payload from message 3. By including an IDi
payload but not an AUTH payload, the initiator has declared an 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 identity but has not proven it. If the responder is willing to use an
extended authentication method, it will place an EAP payload in extensible authentication method, it will place an EAP payload in
message 4 and defer sending SAr2, TSi, and TSr until initiator message 4 and defer sending SAr2, TSi, and TSr until initiator
authentication is complete in a subsequent IKE_AUTH exchange. In the authentication is complete in a subsequent IKE_AUTH exchange. In the
case of a minimal extended authentication, the initial SA case of a minimal extensible authentication, the initial SA
establishment will appear as follows: establishment will appear as follows:
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
HDR, SAi1, KEi, Ni --> HDR, SAi1, KEi, Ni -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ] <-- HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERTREQ,] [IDr,] HDR, SK {IDi, [CERTREQ,] [IDr,]
SAi2, TSi, TSr} --> SAi2, TSi, TSr} -->
skipping to change at page 31, line 48 skipping to change at page 32, line 8
they are subject to a number of man-in-the-middle attacks [EAPMITM] 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 if these EAP methods are used in other protocols that do not use a
server-authenticated tunnel. Please see the Security Considerations server-authenticated tunnel. Please see the Security Considerations
section for more details. If EAP methods that do not generate a 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 shared key are used, the AUTH payloads in messages 7 and 8 MUST be
generated using SK_pi and SK_pr respectively. generated using SK_pi and SK_pr respectively.
The Initiator of an IKE_SA using EAP SHOULD be capable of extending 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 initial protocol exchange to at least ten IKE_AUTH exchanges in
the event the Responder sends notification messages and/or retries the event the Responder sends notification messages and/or retries
the authentication prompt. The protocol terminates when the Responder the authentication prompt. Once the protocol exchange defined by the
sends the Initiator an EAP payload containing either a success or chosen EAP authentication method has successfully terminated, the
failure type. In such an extended exchange, the EAP AUTH payloads responder MUST send an EAP payload containing the Success message.
MUST be included in the two messages following the one containing the Similarly, if the authentication method has failed, the responder
EAP (success) message. 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.
2.17 Generating Keying Material for CHILD_SAs 2.17 Generating Keying Material for CHILD_SAs
CHILD_SAs are created either by being piggybacked on the IKE_AUTH CHILD_SAs are created either by being piggybacked on the IKE_AUTH
exchange, or in a CREATE_CHILD_SA exchange. Keying material for them exchange, or in a CREATE_CHILD_SA exchange. Keying material for them
is generated as follows: is generated as follows:
KEYMAT = prf+(SK_d, Ni | Nr) KEYMAT = prf+(SK_d, Ni | Nr)
Where Ni and Nr are the Nonces from the IKE_SA_INIT exchange if this Where Ni and Nr are the Nonces from the IKE_SA_INIT exchange if this
skipping to change at page 44, line 16 skipping to change at page 44, line 16
Certificate Request CERTREQ 38 Certificate Request CERTREQ 38
Authentication AUTH 39 Authentication AUTH 39
Nonce Ni, Nr 40 Nonce Ni, Nr 40
Notify N 41 Notify N 41
Delete D 42 Delete D 42
Vendor ID V 43 Vendor ID V 43
Traffic Selector - Initiator TSi 44 Traffic Selector - Initiator TSi 44
Traffic Selector - Responder TSr 45 Traffic Selector - Responder TSr 45
Encrypted E 46 Encrypted E 46
Configuration CP 47 Configuration CP 47
Extended Authentication EAP 48 Extensible Authentication EAP 48
RESERVED TO IANA 49-127 RESERVED TO IANA 49-127
PRIVATE USE 128-255 PRIVATE USE 128-255
Payload type values 1-32 should not be used so that there is no Payload type values 1-32 should not be used so that there is no
overlap with the code assignments for IKEv1. Payload type values overlap with the code assignments for IKEv1. Payload type values
49-127 are reserved to IANA for future assignment in IKEv2 (see 49-127 are reserved to IANA for future assignment in IKEv2 (see
section 6). Payload type values 128-255 are for private use among section 6). Payload type values 128-255 are for private use among
mutually consenting parties. mutually consenting parties.
o Critical (1 bit) - MUST be set to zero if the sender wants o Critical (1 bit) - MUST be set to zero if the sender wants
skipping to change at page 49, line 36 skipping to change at page 49, line 36
o Transform ID (2 octets) - The specific instance of the transform o Transform ID (2 octets) - The specific instance of the transform
type being proposed. type being proposed.
Transform Type Values Transform Type Values
Transform Used In Transform Used In
Type Type
RESERVED 0 RESERVED 0
Encryption Algorithm (ENCR) 1 (IKE and ESP) Encryption Algorithm (ENCR) 1 (IKE and ESP)
Pseudo-random Function (PRF) 2 (IKE) Pseudo-random Function (PRF) 2 (IKE)
Integrity Algorithm (INTEG) 3 (IKE, AH, and optional in Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP)
ESP) Diffie-Hellman Group (D-H) 4 (IKE, optional in AH & ESP)
Diffie-Hellman Group (D-H) 4 (IKE and optional in AH and
ESP)
Extended Sequence Numbers (ESN) 5 (Optional in AH and ESP) Extended Sequence Numbers (ESN) 5 (Optional in AH and ESP)
RESERVED TO IANA 6-240 RESERVED TO IANA 6-240
PRIVATE USE 241-255 PRIVATE USE 241-255
For Transform Type 1 (Encryption Algorithm), defined Transform IDs For Transform Type 1 (Encryption Algorithm), defined Transform IDs
are: are:
Name Number Defined In Name Number Defined In
RESERVED 0 RESERVED 0
ENCR_DES_IV64 1 (RFC1827) ENCR_DES_IV64 1 (RFC1827)
skipping to change at page 50, line 50 skipping to change at page 50, line 48
AUTH_AES_XCBC_96 5 (RFC3566) AUTH_AES_XCBC_96 5 (RFC3566)
values 6-1023 are reserved to IANA. Values 1024-65535 are for values 6-1023 are reserved to IANA. Values 1024-65535 are for
private use among mutually consenting parties. private use among mutually consenting parties.
For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs
are: are:
Name Number Name Number
NONE 0 NONE 0
Defined in Appendix B 1 - 4 Defined in Appendix B 1 - 2
RESERVED 3 - 4
Defined in [ADDGROUP] 5 Defined in [ADDGROUP] 5
RESERVED TO IANA 6 - 13 RESERVED TO IANA 6 - 13
Defined in [ADDGROUP] 14 - 18 Defined in [ADDGROUP] 14 - 18
RESERVED TO IANA 19 - 1023 RESERVED TO IANA 19 - 1023
PRIVATE USE 1024-65535 PRIVATE USE 1024-65535
For Transform Type 5 (Extended Sequence Numbers), defined Transform For Transform Type 5 (Extended Sequence Numbers), defined Transform
IDs are: IDs are:
Name Number Name Number
skipping to change at page 82, line 37 skipping to change at page 82, line 37
octet prefix-length as defined in [ADDRIPV6]. Multiple octet prefix-length as defined in [ADDRIPV6]. Multiple
sub-networks MAY be requested. The responder MAY respond with sub-networks MAY be requested. The responder MAY respond with
zero or more sub-network attributes. zero or more sub-network attributes.
Note that no recommendations are made in this document how an Note that no recommendations are made in this document how an
implementation actually figures out what information to send in a implementation actually figures out what information to send in a
reply. i.e., we do not recommend any specific method of an IRAS reply. i.e., we do not recommend any specific method of an IRAS
determining which DNS server should be returned to a requesting determining which DNS server should be returned to a requesting
IRAC. IRAC.
3.16 Extended Authentication Protocol (EAP) Payload 3.16 Extensible Authentication Protocol (EAP) Payload
The Extended Authentication Protocol Payload, denoted EAP in this The Extensible Authentication Protocol Payload, denoted EAP in this
memo, allows IKE_SAs to be authenticated using the protocol defined memo, allows IKE_SAs to be authenticated using the protocol defined
in RFC 2284 [EAP] and subsequent extensions to that protocol. The in RFC 3748 [EAP] and subsequent extensions to that protocol. The
full set of acceptable values for the payload are defined elsewhere, full set of acceptable values for the payload are defined elsewhere,
but a short summary of RFC 2284 is included here to make this but a short summary of RFC 3748 is included here to make this
document stand alone in the common cases. document stand alone in the common cases.
1 2 3 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 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 ! ! Next Payload !C! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ! ! !
~ EAP Message ~ ~ EAP Message ~
! ! ! !
skipping to change at page 83, line 48 skipping to change at page 83, line 48
o Length (two octets) is the length of the EAP message and MUST o Length (two octets) is the length of the EAP message and MUST
be four less than the Payload Length of the encapsulating be four less than the Payload Length of the encapsulating
payload. payload.
o Type (one octet) is present only if the Code field is Request o Type (one octet) is present only if the Code field is Request
(1) or Response (2). For other codes, the EAP message length (1) or Response (2). For other codes, the EAP message length
MUST be four octets and the Type and Type_Data fields MUST NOT MUST be four octets and the Type and Type_Data fields MUST NOT
be present. In a Request (1) message, Type indicates the be present. In a Request (1) message, Type indicates the
data being requested. In a Response (2) message, Type MUST data being requested. In a Response (2) message, Type MUST
either be NAC or match the type of the data requested. The either be Nak or match the type of the data requested. The
following types are defined in RFC 2284: following types are defined in RFC 3748:
1 Identity 1 Identity
2 Notification 2 Notification
3 NAK (Response Only) 3 Nak (Response Only)
4 MD5-Challenge 4 MD5-Challenge
5 One-Time Password (OTP) 5 One-Time Password (OTP)
6 Generic Token Card 6 Generic Token Card
o Type_Data (Variable Length) contains data depending on the Code o Type_Data (Variable Length) varies with the Type of Request
and Type. In Requests other than MD5-Challenge, this field and the associated Response. For the documentation of the
contains a prompt to be displayed to a human user. For NAK, it EAP methods, see [EAP].
contains one octet suggesting the type of authentication the
Initiator would prefer to use. For most other responses, it
contains the authentication code typed by the human user.
Note that since IKE passes an indication of initiator identity in Note that since IKE passes an indication of initiator identity in
message 3 of the protocol, EAP based prompts for Identity SHOULD NOT message 3 of the protocol, the responder SHOULD NOT send EAP Identity
be used. requests. The initiator SHOULD, however, respond to such requests if
it receives them.
4 Conformance Requirements 4 Conformance Requirements
In order to assure that all implementations of IKEv2 can In order to assure that all implementations of IKEv2 can
interoperate, there are MUST support requirements in addition to interoperate, there are MUST support requirements in addition to
those listed elsewhere. Of course, IKEv2 is a security protocol, and those listed elsewhere. Of course, IKEv2 is a security protocol, and
one of its major functions is to only allow authorized parties to one of its major functions is to only allow authorized parties to
successfully complete establishment of SAs. So a particular successfully complete establishment of SAs. So a particular
implementation may be configured with any of a number of restrictions implementation may be configured with any of a number of restrictions
concerning algorithms and trusted authorities that will prevent concerning algorithms and trusted authorities that will prevent
skipping to change at page 85, line 18 skipping to change at page 85, line 15
in the payload header. If the critical bit is set in an unsupported in the payload header. If the critical bit is set in an unsupported
payload header, all implementations MUST reject the messages payload header, all implementations MUST reject the messages
containing those payloads. containing those payloads.
Every implementation MUST be capable of doing four message Every implementation MUST be capable of doing four message
IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, 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 one for ESP and/or AH). Implementations MAY be initiate-only or
respond-only if appropriate for their platform. Every implementation respond-only if appropriate for their platform. Every implementation
MUST be capable of responding to an INFORMATIONAL exchange, but a MUST be capable of responding to an INFORMATIONAL exchange, but a
minimal implementation MAY respond to any INFORMATIONAL message with minimal implementation MAY respond to any INFORMATIONAL message with
an empty INFORMATIONAL reply. A minimal implementation MAY support an empty INFORMATIONAL reply (note that within the context of an
the CREATE_CHILD_SA exchange only in so far as to recognize requests IKE_SA, an "empty" message consists of an IKE header followed by an
and reject them with a Notify payload of type NO_ADDITIONAL_SAS. A Encrypted payload with no payloads contained in it). A minimal
minimal implementation need not be able to initiate CREATE_CHILD_SA implementation MAY support the CREATE_CHILD_SA exchange only in so
or INFORMATIONAL exchanges. When an SA expires (based on locally far as to recognize requests and reject them with a Notify payload of
configured values of either lifetime or octets passed), and type NO_ADDITIONAL_SAS. A minimal implementation need not be able to
implementation MAY either try to renew it with a CREATE_CHILD_SA initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA
exchange or it MAY delete (close) the old SA and create a new one. If expires (based on locally configured values of either lifetime or
the responder rejects the CREATE_CHILD_SA request with a octets passed), and implementation MAY either try to renew it with a
NO_ADDITIONAL_SAS notification, the implementation MUST be capable of CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and
instead closing the old SA and creating a new one. 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.
Implementations are not required to support requesting temporary IP Implementations are not required to support requesting temporary IP
addresses or responding to such requests. If an implementation does addresses or responding to such requests. If an implementation does
support issuing such requests, it MUST include a CP payload in support issuing such requests, it MUST include a CP payload in
message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or
INTERNAL_IP6_ADDRESS. All other fields are optional. If an INTERNAL_IP6_ADDRESS. All other fields are optional. If an
implementation supports responding to such requests, it MUST parse implementation supports responding to such requests, it MUST parse
the CP payload of type CFG_REQUEST in message 3 and recognize a field 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 of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports
leasing an address of the appropriate type, it MUST return a CP leasing an address of the appropriate type, it MUST return a CP
skipping to change at page 87, line 42 skipping to change at page 87, line 42
protocol. protocol.
The security of this protocol is critically dependent on the The security of this protocol is critically dependent on the
randomness of the randomly chosen parameters. These should be randomness of the randomly chosen parameters. These should be
generated by a strong random or properly seeded pseudo-random source generated by a strong random or properly seeded pseudo-random source
(see [RFC1750]). Implementers should take care to ensure that use of (see [RFC1750]). Implementers should take care to ensure that use of
random numbers for both keys and nonces is engineered in a fashion random numbers for both keys and nonces is engineered in a fashion
that does not undermine the security of the keys. that does not undermine the security of the keys.
For information on the rationale of many of the cryptographic design For information on the rationale of many of the cryptographic design
choices in this protocol, see [SIGMA]. choices in this protocol, see [SIGMA]. 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 When using pre-shared keys, a critical consideration is how to assure
the randomness of these secrets. The strongest practice is to ensure the randomness of these secrets. The strongest practice is to ensure
that any pre-shared key contain as much randomness as the strongest that any pre-shared key contain as much randomness as the strongest
key being negotiated. Deriving a shared secret from a password, name, key being negotiated. Deriving a shared secret from a password, name,
or other low entropy source is not secure. These sources are subject or other low entropy source is not secure. These sources are subject
to dictionary and social engineering attacks, among others. to dictionary and social engineering attacks, among others.
The NAT_DETECTION_*_IP notifications contain a hash of the addresses The NAT_DETECTION_*_IP notifications contain a hash of the addresses
and ports in an attempt to hide internal IP addresses behind a NAT. and ports in an attempt to hide internal IP addresses behind a NAT.
skipping to change at page 90, line 21 skipping to change at page 90, line 25
(MODP) Diffie-Hellman groups for Internet Key (MODP) Diffie-Hellman groups for Internet Key
Exchange (IKE)", RFC 3526, May 2003. Exchange (IKE)", RFC 3526, May 2003.
[ADDRIPV6] Hinden, R., and Deering, S., [ADDRIPV6] Hinden, R., and Deering, S.,
"Internet Protocol Version 6 (IPv6) Addressing "Internet Protocol Version 6 (IPv6) Addressing
Architecture", RFC 3513, April 2003. Architecture", RFC 3513, April 2003.
[Bra97] Bradner, S., "Key Words for use in RFCs to indicate [Bra97] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[EAP] Blunk, L. and Vollbrecht, J., "PPP Extensible [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
Authentication Protocol (EAP), RFC 2284, March 1998. Levkowetz, H., "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher [ESPCBC] Pereira, R., Adams, R., "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998. Algorithms", RFC 2451, November 1998.
[Hutt04] Huttunen, A. et. al., "UDP Encapsulation of IPsec [Hutt04] Huttunen, A. et. al., "UDP Encapsulation of IPsec
Packets", draft-ietf-ipsec-udp-encaps-08.txt, February Packets", draft-ietf-ipsec-udp-encaps-08.txt, February
2004, work in progress. 2004, work in progress.
[RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture [RFC2401bis] Kent, S. and Atkinson, R., "Security Architecture
for the Internet Protocol", un-issued Internet for the Internet Protocol", un-issued Internet
skipping to change at page 94, line 11 skipping to change at page 94, line 11
[X.509] ITU-T Recommendation X.509 (1997 E): Information [X.509] ITU-T Recommendation X.509 (1997 E): Information
Technology - Open Systems Interconnection - The Technology - Open Systems Interconnection - The
Directory: Authentication Framework, June 1997. Directory: Authentication Framework, June 1997.
Appendix A: Summary of changes from IKEv1 Appendix A: Summary of changes from IKEv1
The goals of this revision to IKE are: The goals of this revision to IKE are:
1) To define the entire IKE protocol in a single document, replacing 1) To define the entire IKE protocol in a single document, replacing
RFCs 2407, 2408, and 2409 and incorporating subsequent changes to RFCs 2407, 2408, and 2409 and incorporating subsequent changes to
support NAT Traversal, Extended Authentication, and Remote Address support NAT Traversal, Extensible Authentication, and Remote Address
acquisition. acquisition.
2) To simplify IKE by replacing the eight different initial exchanges 2) To simplify IKE by replacing the eight different initial exchanges
with a single four message exchange (with changes in authentication with a single four message exchange (with changes in authentication
mechanisms affecting only a single AUTH payload rather than mechanisms affecting only a single AUTH payload rather than
restructuring the entire exchange); restructuring the entire exchange);
3) To remove the Domain of Interpretation (DOI), Situation (SIT), and 3) To remove the Domain of Interpretation (DOI), Situation (SIT), and
Labeled Domain Identifier fields, and the Commit and Authentication Labeled Domain Identifier fields, and the Commit and Authentication
only bits; only bits;
skipping to change at page 96, line 7 skipping to change at page 96, line 7
11) To simplify and clarify how shared state is maintained in the 11) To simplify and clarify how shared state is maintained in the
presence of network failures and Denial of Service attacks; and presence of network failures and Denial of Service attacks; and
12) To maintain existing syntax and magic numbers to the extent 12) To maintain existing syntax and magic numbers to the extent
possible to make it likely that implementations of IKEv1 can be possible to make it likely that implementations of IKEv1 can be
enhanced to support IKEv2 with minimum effort. enhanced to support IKEv2 with minimum effort.
Appendix B: Diffie-Hellman Groups Appendix B: Diffie-Hellman Groups
There are 4 different Diffie-Hellman groups defined here for use in There are two Diffie-Hellman groups defined here for use in IKE.
IKE. These groups were generated by Richard Schroeppel at the These groups were generated by Richard Schroeppel at the University
University of Arizona. Properties of these primes are described in of Arizona. Properties of these primes are described in [Orm96].
[Orm96].
The strength supplied by group one may not be sufficient for the The strength supplied by group one may not be sufficient for the
mandatory-to-implement encryption algorithm and is here for historic mandatory-to-implement encryption algorithm and is here for historic
reasons. reasons.
Additional Diffie-Hellman groups have been defined in [ADDGROUP]. Additional Diffie-Hellman groups have been defined in [ADDGROUP].
B.1 Group 1 - 768 Bit MODP B.1 Group 1 - 768 Bit MODP
This group is assigned id 1 (one). This group is assigned id 1 (one).
skipping to change at page 96, line 47 skipping to change at page 97, line 5
Its hexadecimal value is: Its hexadecimal value is:
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
49286651 ECE65381 FFFFFFFF FFFFFFFF 49286651 ECE65381 FFFFFFFF FFFFFFFF
The generator is 2. The generator is 2.
B.3 Group 3 - 155 Bit EC2N
This group is assigned id 3 (three). The curve is based on the Galois
Field GF[2^155]. The field size is 155. The irreducible polynomial
for the field is:
u^155 + u^62 + 1.
The equation for the elliptic curve is:
y^2 + xy = x^3 + ax^2 + b.
Field Size: 155
Group Prime/Irreducible Polynomial:
0x0800000000000000000000004000000000000001
Group Generator One: 0x7b
Group Curve A: 0x0
Group Curve B: 0x07338f
Group Order: 0x0800000000000000000057db5698537193aef944
The data in the KE payload when using this group is the value x from
the solution (x,y), the point on the curve chosen by taking the
randomly chosen secret Ka and computing Ka*P, where * is the
repetition of the group addition and double operations, P is the
curve point with x coordinate equal to generator 1 and the y
coordinate determined from the defining equation. The equation of
curve is implicitly known by the Group Type and the A and B
coefficients. There are two possible values for the y coordinate;
either one can be used successfully (the two parties need not agree
on the selection).
B.4 Group 4 - 185 Bit EC2N
This group is assigned id 4 (four). The curve is based on the Galois
Field GF[2^185]. The field size is 185. The irreducible polynomial
for the field is:
u^185 + u^69 + 1.
The equation for the elliptic curve is:
y^2 + xy = x^3 + ax^2 + b.
Field Size: 185
Group Prime/Irreducible Polynomial:
0x020000000000000000000000000000200000000000000001
Group Generator One: 0x18
Group Curve A: 0x0
Group Curve B: 0x1ee9
Group Order: 0x01ffffffffffffffffffffffdbf2f889b73e484175f94ebc
The data in the KE payload when using this group will be identical to
that as when using Oakley Group 3 (three).
Change History (To be removed from RFC) Change History (To be removed from RFC)
H.1 Changes from IKEv2-00 to IKEv2-01 February 2002 H.1 Changes from IKEv2-00 to IKEv2-01 February 2002
1) Changed Appendix B to specify the encryption and authentication 1) Changed Appendix B to specify the encryption and authentication
processing for IKE rather than referencing ESP. Simplified the format processing for IKE rather than referencing ESP. Simplified the format
by removing idiosyncrasies not needed for IKE. by removing idiosyncrasies not needed for IKE.
2) Added option for authentication via a shared secret key. 2) Added option for authentication via a shared secret key.
skipping to change at page 102, line 48 skipping to change at page 101, line 48
9) Removed ability to negotiate Diffie-Hellman groups by explicitly 9) Removed ability to negotiate Diffie-Hellman groups by explicitly
passing parameters. They must now be negotiated using Transform IDs. passing parameters. They must now be negotiated using Transform IDs.
10) Renumbered status codes to be contiguous. 10) Renumbered status codes to be contiguous.
11) Specified the meaning of the "Port" fields in Traffic Selectors 11) Specified the meaning of the "Port" fields in Traffic Selectors
when the ICMP protocol is being used. when the ICMP protocol is being used.
12) Removed the specification of D-H Group #5 since it is already 12) Removed the specification of D-H Group #5 since it is already
specified in [ADDGROUP. specified in [ADDGROUP].
H.10 Changes from IKEv2-09 to IKEv2-10 August 2003 H.10 Changes from IKEv2-09 to IKEv2-10 August 2003
1) Numerous boilerplate and formatting corrections to comply with RFC 1) Numerous boilerplate and formatting corrections to comply with RFC
Editorial Guidelines and procedures. Editorial Guidelines and procedures.
2) Fixed five typographical errors. 2) Fixed five typographical errors.
3) Added a sentence to the end of "Security considerations" 3) Added a sentence to the end of "Security considerations"
discouraging the use of non-key-generating EAP mechanisms. discouraging the use of non-key-generating EAP mechanisms.
skipping to change at page 108, line 5 skipping to change at page 106, line 14
19) ISSUE #113: Added requirement that backoff timers on 19) ISSUE #113: Added requirement that backoff timers on
retransmissions must increase exponentially to avoid network retransmissions must increase exponentially to avoid network
congestion. congestion.
20) Replaced dubious explanation of NON_FIRST_FRAGMENTS_ALSO with a 20) Replaced dubious explanation of NON_FIRST_FRAGMENTS_ALSO with a
reference to RFC2401bis. reference to RFC2401bis.
21) Fixed 16 spelling/typographical/gramatical errors. 21) Fixed 16 spelling/typographical/gramatical errors.
H.16 Changes from IKEv2-15 to IKEv2-16 September 2004
1) Added the text: "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."
2) Removed the two ECC groups from Appendix B.
3) Changed references to RFC 2284 to RFC 3748, references to Extended
Authentication Protocol to Extensible Authentication Protocol, and
made some editorial corrections related to EAP proposed by Jari
Arkko.
4) Added a note to security considerations saying that IKE MUST NOT
negotiate NONE as its integrity protection algorithm or ENCR_NULL as
its encryption algorithm.
5) Added I-D boilerplate concerning IPR claim disclosure.
6) Clarified that "empty" messages included a single empty Encrypted
payload.
7) Added (SA) after first reference to "Security Association".
8) Noted that incompatible configurations of traffic selectors SHOULD
be noted in error logs.
9) 3 minor editorial clarifications.
Editor's Address Editor's Address
Charlie Kaufman Charlie Kaufman
Microsoft Corporation Microsoft Corporation
1 Microsoft Way 1 Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
1-425-707-3335 1-425-707-3335
charliek@microsoft.com charliek@microsoft.com
By submitting this Internet-Draft, the editor represents that any
applicable patent or other IPR claims of which he is aware have been
or will be disclosed, and any of which he becomes aware will be
disclosed, in accordance with RFC 3668.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
skipping to change at page 109, line 12 skipping to change at page 108, line 16
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Expiration Expiration
This Internet-Draft (draft-ietf-ipsec-ikev2-15.txt) expires in This Internet-Draft (draft-ietf-ipsec-ikev2-16.txt) expires in March
February 2005. 2005.
 End of changes. 50 change blocks. 
176 lines changed or deleted 176 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/