Network Working Group P. Eronen
Internet-Draft Nokia
Expires: August 5, 2005 February 4, 2005
IKEv2 Clarifications and Implementation Guidelines
draft-eronen-ipsec-ikev2-clarifications-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 August 5, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document clarifies some areas of the IKEv2 specification that
may be difficult to understand to developers not intimately familiar
with the specification and its history. The intent is not to
introduce any changes to the protocol, but rather to provide
descriptions less prone to ambiguous interpretations, and thus
encourage the development of interoperable implementations. Readers
are advised that this document is work-in-progress, and may contain
incorrect interpretations.
Eronen Expires August 5, 2005 [Page 1]
Internet-Draft IKEv2 Clarifications February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Authentication . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Calculating prf(SK_pi,IDi') and prf(SK_pr,IDr') . . . . . 3
2.2 PRFs with a fixed key size . . . . . . . . . . . . . . . . 4
2.3 Hash function for RSA signatures . . . . . . . . . . . . . 5
2.4 Encoding method for RSA signatures . . . . . . . . . . . . 6
2.5 Identification type for EAP . . . . . . . . . . . . . . . 6
2.6 Identity for policy lookups when using EAP . . . . . . . . 7
2.7 Certificate encoding types . . . . . . . . . . . . . . . . 7
2.8 Rekeying CHILD_SAs . . . . . . . . . . . . . . . . . . . . 8
2.9 Rekeying the IKE_SA vs. reauthentication . . . . . . . . . 10
2.10 Rekeying the IKE_SA . . . . . . . . . . . . . . . . . . 10
3. Configuration payloads . . . . . . . . . . . . . . . . . . . 11
3.1 Length of configuration attribute type field . . . . . . . 11
3.2 Requesting any INTERNAL_IP4/IP6_ADDRESS . . . . . . . . . 11
3.3 INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . . . . . . . . . 11
3.4 INTERNAL_IP4_NETMASK . . . . . . . . . . . . . . . . . . . 13
3.5 INTERNAL_IP6_ADDRESS prefix length . . . . . . . . . . . . 14
4. Other issues . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1 Message ID in IKE_SA_INIT messages . . . . . . . . . . . . 16
4.2 INITIAL_CONTACT notify payload . . . . . . . . . . . . . . 16
4.3 Diffie-Hellman for first CHILD_SA . . . . . . . . . . . . 16
4.4 Matching ID_IPV4_ADDR/ID_IPV6_ADDR . . . . . . . . . . . . 16
5. Security considerations . . . . . . . . . . . . . . . . . . 17
6. IANA considerations . . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 17
8.2 Informative References . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . 20
Eronen Expires August 5, 2005 [Page 2]
Internet-Draft IKEv2 Clarifications February 2005
1. Introduction
This document clarifies some areas of the IKEv2 specification that
may be difficult to understand to developers not intimately familiar
with the specification and its history. The intent is not to
introduce any changes to the protocol, but rather to provide
descriptions less prone to ambiguous interpretations, and thus
encourage the development of interoperable implementations.
Readers are advised that this document is work-in-progress, and may
contain incorrect interpretations. Issues where the clarification is
known to be incomplete, or there is no consensus on what the the
interpretation should be, are marked as such. Clarifications that
are incorrect but the author does not know this are not marked as
such :-).
This document does not place any requirements on anyone, and does not
use [RFC2119] keywords such as "MUST" and "SHOULD". 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 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. Authentication
2.1 Calculating prf(SK_pi,IDi') and prf(SK_pr,IDr')
Section 2.15 describes how AUTH payloads are calculated; this
calculation involves values prf(SK_pi,IDi') and prf(SK_pr,IDr'). The
text continues that "In the above calculation, IDi' and IDr' are the
entire ID payloads excluding the fixed header.".
Here "fixed header" refers to the "generic payload header" described
in Section 3.2. In other words, the data fed to the prf includes the
ID Type (1 octet), three RESERVED octets, followed by the
Identification data (see Section 3.5).
(References: Lakshminath Dondeti's mail "prf(SK_p, ID') computation",
2004-11-14. Charlie Kaufman's reply, 2004-11-16.)
Eronen Expires August 5, 2005 [Page 3]
Internet-Draft IKEv2 Clarifications February 2005
2.2 PRFs with a fixed key size
(Preliminary text, still open.)
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.
This requirement means that some special care must be taken when
using these PRFs for shared key authentication. The implementation
must not propose these PRFs when the secret is of incorrect size; or
in other words, if the implementation proposes one of these PRFs, it
must not allow the user to configure a shared secret with incorrect
size.
A strict interpretation of this text also means that these PRFs are
unlikely to be useful for EAP authentication, since [EAP] specifies
that the MSK is at least 64 octets (512 bits) long, while currently
the only PRF that takes a fixed size key (PRF_AES128_CBC) requires a
128-bit key. It is currently under discussion whether truncation or
padding should be allowed in the EAP case.
Due to the way the AUTH payload is calculated, this requirement also
implies that a PRF with a fixed size key can be used for shared key
authentication only if the PRF produces an output of the same size as
the key. This is the case for PRF_AES128_CBC, which uses a 128-bit
key and produces a 128-bit output.
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".
It seems that this text applies to the prf+ construction described in
Section 2.13; or in other words, prf+ always accepts a key of any
length, even if the underlying prf does not. Since in IKEv2 the key
for prf+ is always an output from prf, this padding or truncation can
happen only if the prf has a fixed key size that is different from
the output size (e.g., it cannot happen for PRF_AES128_CBC).
Section 2.14 continues that "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". This raises the question about what happens if either
of the nonces is shorter than half of the key length (note that the
nonces are at least 128 bits, so this case cannot happen with
PRF_AES128_CBC).
Eronen Expires August 5, 2005 [Page 4]
Internet-Draft IKEv2 Clarifications February 2005
Due to these complications, this document recommends that
o Implementations that use shared secret authentication should
prefer PRFs that accept a variable length key, since this makes
the life of the administrator easier.
o New IKEv2 PRFs defined in the future should accept variable length
keys.
o If, despite the previous recommendation, a new IKEv2 PRF with a
fixed key size is defined in the future, it should produce an
output of the same size as the key.
o If some future implementation supports a PRF with a fixed key size
of greater than 256 bits: when such a PRF is included in a
Security Association payload, the corresponding Ni/Nr payload must
be at least key size/2 bits long.
(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.)
2.3 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.
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 other end supports something else.
Other possible choices include, for example, using the hash function
that was used to sign the certificate. However, this approach
assumes that the recipient's "IKEv2 module" supports the same
algorithms as the "certificate validation module" (which may not be
true, especially if something like [SCVP] is used). Furthermore, not
all CERT payloads types include a signature; and the certificate
Eronen Expires August 5, 2005 [Page 5]
Internet-Draft IKEv2 Clarifications February 2005
could be signed with some other algorithm than RSA.
(References: Magnus Alstrom's mail "RE:", 2005-01-03. Pasi Eronen's
reply, 2005-01-04. Tero Kivinen's reply, 2005-01-04.)
2.4 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 current version of PKCS#1 (v2.1) [PKCS1v21] defines two different
encoding methods (ways of "padding the hash") for signatures.
However, IKEv2 points 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.
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.)
2.5 Identification type for EAP
(Preliminary text, still open.)
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] and [NAIbis]. 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.)
Eronen Expires August 5, 2005 [Page 6]
Internet-Draft IKEv2 Clarifications February 2005
2.6 Identity for policy lookups when using EAP
(Preliminary text, better explanation needed.)
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.)
2.7 Certificate encoding types
(Preliminary text, still open.)
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
(Future versions of this document may also contain clarifications
about how these values are to be used.)
This document recommends that most implementations should use only
those values that are "MUST"/"SHOULD" requirements in [IKEv2]; i.e.,
Eronen Expires August 5, 2005 [Page 7]
Internet-Draft IKEv2 Clarifications February 2005
"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).
2.8 Rekeying CHILD_SAs
(Preliminary text, still open.)
Section 2.8 describes that rekeying a CHILD_SA within an existing
IKE_SA is done by first creating a new equivalent SA, and then
deleting the old one. However, this section does not describe
exactly what payloads are involved, and does not even mention the
REKEY_SA notify payload. Another description about rekeying can be
found in Section 1.3, but this section also omits some of the details
that are in Section 2.8.
A typical conversation that rekeys an existing CHILD_SA pair and then
deletes the old SAs would look like this:
Initiator Responder
----------- -----------
[traffic flowing via CHILD_SA pair with SPIi1/SPIr1]
HDR, SK {N(REKEY_SA, SPIi1),
SA(..., SPIi2, ...),
Ni, [KEi], TSi, TSr} -->
<-- HDR, SK {SA(..., SPIr2, ...),
Nr, [KEr], TSi, TSr}
HDR, SK {D(SPIi1)} -->
<-- HDR, SK {D(SPIr1)}
[traffic flowing via new CHILD_SA pair with SPIi2/SPIr2]
However, it seems that exactly the same (or almost the same) end
result would have been achieved if the REKEY_SA notify payload was
not included. Not including REKEY_SA here is allowed in IKEv2; in
that case, it is not called rekeying, but creating a parallel SA with
identical traffic selectors, and coincidentally, deleting one of them
very soon after that. Why, then, was the REKEY_SA notify payload
included in the spec?
This document's interpretation is that by including REKEY_SA, the
initiator promises that (1) it will move its outbound traffic to the
new SA as soon as it receives the CREATE_CHILD_SA response, (2) it
Eronen Expires August 5, 2005 [Page 8]
Internet-Draft IKEv2 Clarifications February 2005
will not use the old outbound SA after that, and (3) it will delete
the old SA pair soon afterwards.
If this interpretation is correct (which is not clear yet), there
seems to be three main differences between the cases with and without
REKEY_SA. First, if REKEY_SA is included, the responder can do
certain optimizations that would not be possible without it. Second,
the exact point when the responder moves the outbound traffic to the
new SA may be different. Third, there may be some differences if
rekeying is started simultaneously by both parties.
Let's consider the optimization case first. It seems that when doing
rekeying, a simple responder implementation could, in fact, replace
the old SAs "in place". This can result in some packets being lost,
so Section 2.8 recommends against this.
Initiator Responder
----------- -----------
HDR, SK {N(REKEY_SA, SPIi1),
SA(..., SPIi2, ...),
Ni, [KEi], TSi, TSr} -->
[responder replaces the old SAs
with new ones, but remembers
the values SPIi1/SPIr1]
<-- HDR, SK {SA(..., SPIr2, ...),
Nr, [KEr], TSi, TSr}
HDR, SK {D(SPIi1)} -->
[the old SA is already gone,
but the responder still
remembers SPIi1/SPIr1]
<-- HDR, SK {D(SPIr1)}
[now responder can forget
SPIi1 and SPIr1]
The second difference seems to be when exactly the responder should
move the traffic to the new SA. When REKEY_SA is used, Section 2.8
says that the responder should continue using the old SA until it
either receives a packet on the new inbound SA, or receives a Delete
request for the old SA pair. When REKEY_SA is not used, the traffic
is obviously moved when the old SA is deleted, but not necessarily
earlier.
Eronen Expires August 5, 2005 [Page 9]
Internet-Draft IKEv2 Clarifications February 2005
The third difference may be what exactly happens when both parties
start rekeying at the same time, and the requests cross in the
network. Here REKEY_SA indicates that neither party wants to keep
parallel CHILD_SAs around. (TO BE WRITTEN: details of exactly what
happens in this case.)
2.9 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). This procedure
is described in more detail in the next section.
While rekeying the IKE_SA may be important in some environments,
reauthentication, i.e., verifying 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 does not currently allow the responder to
request reauthentication in this case; however, there is ongoing work
to add this functionality [ReAuth].
(References: "Reauthentication in IKEv2" thread, Oct/Nov 2004.)
2.10 Rekeying the IKE_SA
To be written.
Eronen Expires August 5, 2005 [Page 10]
Internet-Draft IKEv2 Clarifications February 2005
3. Configuration payloads
3.1 Length of configuration attribute type field
In Section 3.15.1, Figure 23 shows that the length of the "Attribute
Type" field is 15 bits, while the text below the figure says the
length is 7 bits.
The figure is correct, the field is 15 bits.
(References: Tero Kivinen's mail "Comments to the
draft-ietf-ipsec-ikev2-11.txt", 2003-11-09. Yoav Nir's mail "Will
ikev2-16 be the charm?", 2004-09-23. Charlie Kaufman's
mail"draft-ietf-ipsec-ikev2-17.txt", 2004-10-04. It is expected that
this issue will be fixed during the "Authors' 48 hours" before the
RFC is published.)
3.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 that does "zero" mean 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, 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.
3.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
Eronen Expires August 5, 2005 [Page 11]
Internet-Draft IKEv2 Clarifications February 2005
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."
INTERNAL_IP6_SUBNET is defined in a similar manner.
This raises two questions: first, since this information is often
included in the TSr payload, what does this attribute do? And second,
what does this attribute mean in CFG_REQUESTs?
To answer the first question, this attribute can indeed sometimes
contain exactly the same information as TSr. 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-65536, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65536, 0.0.0.0-255.255.255.255)
Then a typical valid response would 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-65536, 192.0.1.234-192.0.1.234)
TSr = ((0, 0-65536, 192.0.1.0-192.0.1.63),
(0, 0-65536, 192.0.2.0-192.0.2.255))
However, the gateway could have 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-65536, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65536, 192.0.1.0-192.0.1.63)
Eronen Expires August 5, 2005 [Page 12]
Internet-Draft IKEv2 Clarifications February 2005
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-65536, 0.0.0.0-255.255.255.255)
TSr = (0, 0-65536, 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-65536, 192.0.1.234-192.0.1.234)
TSr = (0, 0-65536, 192.0.2.155-192.0.2.155)
To summarize, TSr indicates which subnets are accessible through this
SA; the INTERNAL_IP4/6_SUBNET attributes indicate additional subnets
that can be reached through this gateway, but need a separate SA.
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!). Currently
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
instance, "255.0.255.0" would not be a valid netmask for
INTERNAL_IP4_SUBNET.
(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.)
3.4 INTERNAL_IP4_NETMASK
(Preliminary text, still open.)
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".
Eronen Expires August 5, 2005 [Page 13]
Internet-Draft IKEv2 Clarifications February 2005
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").
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] and the IPCP "subnet mask"
extension does in PPP [IPCPSubnet]. This interpretation would also
work nicely with IPv6 (see the following section).
However, one IKEv2 guru assured the author that this interpretation
is not correct. Section 3.15.1 also says that multiple addresses are
assigned using multiple INTERNAL_IP4_ADDRESS attributes.
Currently, this document's interpretation is the following:
o INTERNAL_IP4_NETMASK in a CFG_REPLY means exactly the same thing
as INTERNAL_IP4_SUBNET containing the same information (see the
previous section for description of INTERNAL_IP4_SUBNET).
o INTERNAL_IP4_NETMASK does not make sense for CFG_REQUESTs, and the
example in Section 2.19 is incorrect in this sense. (Another
interpretation would be that by sending, for instance, the
combination of INTERNAL_IP4_ADDRESS(192.0.2.0) and
INTERNAL_IP4_NETMASK(255.255.255.0), the client is asking to be
assigned one IP address from the network 192.0.2.0/24. However,
this interpretation is not supported by the IKEv2 spec.)
This interpretation is not yet settled; and it would imply that the
whole attribute is totally unnecessary.
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 at all.
(References: Charlie Kaufman's mail "RE: Proposed Last Call based
revisions to IKEv2", 2004-05-27. Email discussion with Tero Kivinen,
Jan 2005.)
3.5 INTERNAL_IP6_ADDRESS prefix length
(Preliminary text, still open.)
Earlier versions of the IKEv2 draft had an INTERNAL_IP6_NETMASK
attribute corresponding to INTERNAL_IP4_NETMASK, but this was deleted
Eronen Expires August 5, 2005 [Page 14]
Internet-Draft IKEv2 Clarifications February 2005
when the prefix length field was added to the INTERNAL_IP6_ADDRESS
attribute. Thus, it seems logical to assume that their purpose would
be similar; however, this is far from obvious.
But first a step back: the draft quite clearly says that the client
is assigned an IPv6 address using the INTERNAL_IP6_ADDRESS attribute;
so using this attribute with prefix length 128 in a CFG_REPLY seems
to be clear. Also, this implies that IPv6 stateless
autoconfiguration is not involved (and indeed, that would be quite
difficult to align with TSi/TSr payloads).
Again, one possible interpretation is that a prefix length smaller
than 128 in a CFG_REPLY means that the client is assigned a whole
block of IPv6 addresses. This would be in line with the IPv6
addressing architecture in general, and with, e.g., the
Framed-IPv6-Prefix attribute in [RADIUS6]. However, the previous
section rejected this interpretation for IPv4, so it would seem
strange to adopt it only for IPv6.
Thus, if we assume that INTERNAL_IP4_NETMASK and the prefix length in
INTERNAL_IP6_ADDRESS have the same meaning, and the reasoning in the
previous section is correct, then a CFG_REPLY containing a prefix
length smaller than 128 has the same purpose as INTERNAL_IP6_SUBNET.
However, CFG_REQUESTs are more complicated. It seems that a
CFG_REQUEST message that requests a specific IPv6 address (usually an
address this client was using earlier) should have prefix length 128.
But what do other prefix lengths mean in CFG_REQUESTs?
Section 3.15.1 says that "With IPv6, a requestor MAY supply the low
order address bytes it wants to use": presumably the prefix length
tells how many low order bits there are (i.e., if the prefix length
is X, there requester supplies 128-X low order address bits).
However, this is quite confusing: if, say, a prefix length 126 means
that "I want to use these 128-126=2 low order bits", why does prefix
length 128 mean that "I want to use these 128 low order bits"?
Another interpretation is that instead of "low order", the draft
should have said "high order", and thus a prefix length smaller than
128 means "I'd like to get an address from this subnet".
Given this very confusing discussion, this document recommends that
implementations should not use other INTERNAL_IP6_ADDRESS prefix
lengths than 128.
Eronen Expires August 5, 2005 [Page 15]
Internet-Draft IKEv2 Clarifications February 2005
4. Other issues
4.1 Message ID in IKE_SA_INIT messages
To be written.
(References: "Question about N(COOKIE) and N(INVALID_KE_PAYLOAD)
combination" thread, Oct 2004.)
4.2 INITIAL_CONTACT notify payload
To be written.
(References: Michael Richardson's mail "Initial Contact Messages",
2004-12-05. Paul Hoffman's reply, 2004-12-05. Tero Kivinen's reply,
2004-12-07. "Replicated identities" thread in Jan 2005.)
4.3 Diffie-Hellman for first CHILD_SA
(Preliminary text, references missing.)
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.
4.4 Matching ID_IPV4_ADDR/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 the address in
the IP header (of IKEv2 packets), or anything in the TSi/TSr
payloads. The contents of IDi/IDr is used purely to fetch the policy
and authentication data related to the other party.
(References: "Identities types IP address,FQDN/user FQDN and DN and
its usage in pershared key authentication" thread, Jan 2005.)
Eronen Expires August 5, 2005 [Page 16]
Internet-Draft IKEv2 Clarifications February 2005
5. 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.
6. IANA considerations
This document has no IANA Actions.
7. Acknowledgments
This document is mainly based on conversations on the IPsec WG
mailing list. The author would especially like to thank Bernard
Aboba, Jari Arkko, Paul Hoffman, Mika Joutsenvirta, Charlie Kaufman,
Tero Kivinen, Yoav Nir, and Michael Richardson for their
contributions.
8. References
8.1 Normative References
[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", draft-ietf-ipsec-ikev2-17 (work in progress),
September 2004.
[IKEv2ALG]
Schiller, J., "Cryptographic Algorithms for use in the
Internet Key Exchange Version 2",
draft-ietf-ipsec-ikev2-algorithms-05 (work in progress),
April 2004.
[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.
8.2 Informative References
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
Eronen Expires August 5, 2005 [Page 17]
Internet-Draft IKEv2 Clarifications February 2005
[EAPKey] Aboba, B., Simon, D., Arkko, J., Eronen, P. and H.
Levkowetz, "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-04 (work in
progress), November 2004.
[IPCPSubnet]
Cisco Systems, Inc., "IPCP Subnet Mask Support
Enhancements",
http://www.cisco.com/univercd/cc/td/doc/product/software/i
os121/121newft/121limit/121dc/121dc3/ipcp_msk.htm, January
2003.
[NAI] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[NAIbis] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The
Network Access Identifier",
draft-ietf-radext-rfc2486bis-03 (work in progress),
November 2004.
[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.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[RFC822] Crocker, D., "Standard for the format of ARPA Internet
text messages", RFC 822, August 1982.
[ReAuth] Nir, Y., "Repeated Authentication in IKEv2",
draft-nir-ikev2-auth-lt-01 (work in progress), November
2004.
[SCVP] Freeman, T., Housley, R. and A. Malpani, "Simple
Certificate Validation Protocol (SCVP)",
draft-ietf-pkix-scvp-16 (work in progress), October 2004.
Eronen Expires August 5, 2005 [Page 18]
Internet-Draft IKEv2 Clarifications February 2005
Author's Address
Pasi Eronen
Nokia Research Center
P.O. Box 407
FIN-00045 Nokia Group
Finland
EMail: pasi.eronen@nokia.com
Eronen Expires August 5, 2005 [Page 19]
Internet-Draft IKEv2 Clarifications February 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eronen Expires August 5, 2005 [Page 20]
