[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 4718

Network Working Group                                          P. Eronen
Internet-Draft                                                     Nokia
Expires: August 18, 2005                               February 17, 2005


           IKEv2 Clarifications and Implementation Guidelines
             draft-eronen-ipsec-ikev2-clarifications-01.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 18, 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 18, 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  EAP authentication and the AUTH payload  . . . . . . . . .   7
     2.8  Certificate encoding types . . . . . . . . . . . . . . . .   7
     2.9  Hash-and-URL certificate encoding  . . . . . . . . . . . .   8
     2.10   Rekeying CHILD_SAs . . . . . . . . . . . . . . . . . . .   8
     2.11   Rekeying the IKE_SA vs. reauthentication . . . . . . . .  11
     2.12   Rekeying the IKE_SA  . . . . . . . . . . . . . . . . . .  11
   3.   Configuration payloads . . . . . . . . . . . . . . . . . . .  11
     3.1  Length of configuration attribute type field . . . . . . .  11
     3.2  Requesting any INTERNAL_IP4/IP6_ADDRESS  . . . . . . . . .  12
     3.3  INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET  . . . . . . . . .  12
     3.4  INTERNAL_IP4_NETMASK . . . . . . . . . . . . . . . . . . .  15
     3.5  INTERNAL_IP6_ADDRESS prefix length . . . . . . . . . . . .  16
   4.   Other issues . . . . . . . . . . . . . . . . . . . . . . . .  17
     4.1  Message ID in IKE_SA_INIT messages . . . . . . . . . . . .  17
     4.2  INITIAL_CONTACT notify payload . . . . . . . . . . . . . .  17
     4.3  Diffie-Hellman for first CHILD_SA  . . . . . . . . . . . .  17
     4.4  Matching ID_IPV4_ADDR/ID_IPV6_ADDR . . . . . . . . . . . .  18
     4.5  Semantics of traffic selector payloads . . . . . . . . . .  18
     4.6  Traffic selector negotiation . . . . . . . . . . . . . . .  18
     4.7  Coexistence of multiple IPsec implementations  . . . . . .  19
   5.   Security considerations  . . . . . . . . . . . . . . . . . .  20
   6.   IANA considerations  . . . . . . . . . . . . . . . . . . . .  20
   7.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  20
   8.   References . . . . . . . . . . . . . . . . . . . . . . . . .  20
   8.1  Normative References . . . . . . . . . . . . . . . . . . . .  20
   8.2  Informative References . . . . . . . . . . . . . . . . . . .  20
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  22
        Intellectual Property and Copyright Statements . . . . . . .  23













Eronen                  Expires August 18, 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 18, 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 18, 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 18, 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 18, 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  EAP authentication and the AUTH payload

   Section 2.16 says that "For EAP methods that create a shared key as a
   side effect of authentication, that shared key MUST be used by both
   the initiator and responder to generate AUTH payloads in messages 5
   and 6 using the syntax for shared secrets specified in section 2.15."

   This text should say "messages 7 and 8".

   (References: "How to do authentication with EAP" thread, Feb 2005)

2.8  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.




Eronen                  Expires August 18, 2005                 [Page 7]

Internet-Draft            IKEv2 Clarifications             February 2005


      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.,
   "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.9  Hash-and-URL certificate encoding

   To be written.

2.10  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.





















Eronen                  Expires August 18, 2005                 [Page 8]

Internet-Draft            IKEv2 Clarifications             February 2005


   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
   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.




Eronen                  Expires August 18, 2005                 [Page 9]

Internet-Draft            IKEv2 Clarifications             February 2005


       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.

   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.)

   Yet another interpretation is that an IPsec implementation that does
   not work strictly on per-packet basis, but instead associates SAs
   with transport layer sockets, could use this information to update
   the socket instead of searching the SADB/SPD for a suitable SA.  (TO
   BE WRITTEN: details, and whether this makes sense.)

   (References: Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and
   Implementation Guidelines", 2005-02-07.)





Eronen                  Expires August 18, 2005                [Page 10]

Internet-Draft            IKEv2 Clarifications             February 2005


2.11  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.12  Rekeying the IKE_SA

   To be written.

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.




Eronen                  Expires August 18, 2005                [Page 11]

Internet-Draft            IKEv2 Clarifications             February 2005


   (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

   (Preliminary text, still open.)

   Section 3.15.1 describes the INTERNAL_IP4_SUBNET as "The protected
   sub-networks that this edge-device protects.  This attribute is made
   up of two fields; the first 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 usually
   included in the TSr payload, what functionality does this attribute
   add? And second, what does this attribute mean in CFG_REQUESTs?



Eronen                  Expires August 18, 2005                [Page 12]

Internet-Draft            IKEv2 Clarifications             February 2005


   For the first question, there seem to be two sensible
   interpretations.  Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA
   response) indicates which subnets are accessible through the SA that
   was just created.

   The first interpretation of the INTERNAL_IP4/6_SUBNET attributes is
   that they indicate additional subnets that can be reached through
   this gateway, but need a separate SA.  According to this
   interpretation, the INTERNAL_IP4/6_SUBNET attributes are useful
   mainly when they contain addresses not included in TSr.

   The second interpretation is that the INTERNAL_IP4/6_SUBNET
   attributes express the gateway's policy about what traffic should be
   sent through the gateway.  The client can choose whether other
   traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is sent
   through the gateway or directly the destination.  According to this
   interpretation, the attributes are useful mainly when TSr contains
   addresses not included in the INTERNAL_IP4/6_SUBNET attributes.

   These two interpretations are not totally incompatible: in both
   cases, they suggest that traffic to the addresses listed in the
   INTERNAL_IP4/6_SUBNET attributes should be sent via this gateway
   (and, of course, the packets have to be sent over some SA whose
   traffic selectors cover the address in question).

   A couple of examples are given below.  For instance, if there are two
   subnets, 192.0.1.0/26 and 192.0.2.0/24, and the client's request
   contains the following:

      CP(CFG_REQUEST) =
        INTERNAL_IP4_ADDRESS()
      TSi = (0, 0-65536, 0.0.0.0-255.255.255.255)
      TSr = (0, 0-65536, 0.0.0.0-255.255.255.255)

   Then a valid response could be the following (in which TSr and
   INTERNAL_IP4_SUBNET contain the same information):

      CP(CFG_REPLY) =
        INTERNAL_IP4_ADDRESS(192.0.1.234)
        INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
        INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
      TSi = (0, 0-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))

   In these cases, the INTERNAL_IP4_SUBNET does not really carry any
   useful information.  Another possible reply would have been this:




Eronen                  Expires August 18, 2005                [Page 13]

Internet-Draft            IKEv2 Clarifications             February 2005


      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, 0.0.0.0-255.255.255.255)

   This would mean that the client can send all its traffic through the
   gateway, but the gateway does not mind if the client sends traffic
   not included by INTERNAL_IP4_SUBNET directly to the destination
   (without going through the gateway).

   A different situation arises if the gateway has a policy that
   requires the traffic for the two subnets to be carried in separate
   SAs.  Then a response like this would indicate to the client that if
   it wants access to the second subnet, it needs to create a separate
   SA:

      CP(CFG_REPLY) =
        INTERNAL_IP4_ADDRESS(192.0.1.234)
        INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
        INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
      TSi = (0, 0-65536, 192.0.1.234-192.0.1.234)
      TSr = (0, 0-65536, 192.0.1.0-192.0.1.63)

   INTERNAL_IP4_SUBNET can also be useful if the client's TSr included
   only part of the address space.  For instance, if the client requests
   the following:

      CP(CFG_REQUEST) =
        INTERNAL_IP4_ADDRESS()
      TSi = (0, 0-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)

   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



Eronen                  Expires August 18, 2005                [Page 14]

Internet-Draft            IKEv2 Clarifications             February 2005


   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.  Yoav Nir's mail "Re: New I-D: IKEv2
   Clarifications and Implementation Guidelines", 2005-02-07.)

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".

   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



Eronen                  Expires August 18, 2005                [Page 15]

Internet-Draft            IKEv2 Clarifications             February 2005


      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.

   Yet another possible interpretation would be that
   INTERNAL_IP4_NETMASK indicates a broadcast address, meaning that if a
   client sends a packet to this address, the gateway will decrypt it
   and send copies to all other VPN clients in that address range.
   However, no implementation is known to do this, and there is nothing
   in the IKEv2 spec that would support this interpretation.

   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.  Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and
   Implementation Guidelines", 2005-02-07.)

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
   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.



Eronen                  Expires August 18, 2005                [Page 16]

Internet-Draft            IKEv2 Clarifications             February 2005


   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.

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



Eronen                  Expires August 18, 2005                [Page 17]

Internet-Draft            IKEv2 Clarifications             February 2005


   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.)

4.5  Semantics of traffic selector payloads

   As described in Section 3.13, the TSi/TSr payloads can include one or
   more individual traffic selectors.

   There is no requirement that TSi and TSr contain the same number of
   individual traffic selectors.  Thus, they are interpreted as follows:
   a packet matches a given TSi/TSr if it matches at least one of the
   individual selectors in TSi, and at least one of the individual
   selectors in TSr.

   For instance, the following traffic selectors:

      TSi = ((17, 100, 192.0.1.66-192.0.1.66),
             (17, 200, 192.0.1.66-192.0.1.66))
      TSr = ((17, 300, 0.0.0.0-255.255.255.255),
             (17, 400, 0.0.0.0-255.255.255.255))

   would match UDP packets from 192.0.1.66 to anywhere, with any of the
   four combinations of source/destination ports (100,300), (100,400),
   (200,300), and (200, 400).

   This implies that some types of policies may require several CHILD_SA
   pairs.  For instance, a policy matching only source/destination ports
   (100,300) and (200,400), but not the other two combinations, cannot
   be negotiated as a single CHILD_SA pair using IKEv2.

   (References: "IKEv2 Traffic Selectors?" thread, Feb 2005.)

4.6  Traffic selector negotiation

   (Preliminary text, more text needed.)




Eronen                  Expires August 18, 2005                [Page 18]

Internet-Draft            IKEv2 Clarifications             February 2005


   Section 2.9 describes traffic selector negotiation in great detail.

   One aspect of this negotiation that may need some clarification is
   that when creating a new SA, the initiator should not propose traffic
   selectors that violate its own policy.  If this rule is not followed,
   valid traffic may be dropped.

   This is best illustrated by an example.  Suppose that host A has a
   policy whose effect is that traffic to 192.0.1.66 is sent via host B
   encrypted using AES, and traffic to all other hosts in 192.0.1.0/24
   is also sent via B, but must use 3DES.  Suppose also that host B
   accepts any combination of AES and 3DES.

   If host A now proposes an SA that uses 3DES, and includes TSr
   containing (192.0.1.0-192.0.1.0.255), this will be accepted by host
   B.  Now, host B can also use this SA to send traffic from 192.0.1.66,
   but those packets will be dropped by A since it requires the use of
   AES for those traffic.  Even if host A creates a new SA only for
   192.0.1.66 that uses AES, host B may freely continue to use the first
   SA for the traffic.  In this situation, when proposing the SA, host A
   should have followed its own policy, and included a TSr containing
   ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.

   (References: "Question about "narrowing" ..." thread, Feb 2005.
   "IKEv2 needs a "policy usage mode"..." thread, Feb 2005.  "IKEv2
   Traffic Selectors?" thread, Feb 2005.  "IKEv2 traffic selector
   negotiation examples", 2004-08-08.)

4.7  Coexistence of multiple IPsec implementations

   To be written.




















Eronen                  Expires August 18, 2005                [Page 19]

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, William Dixon, 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 18, 2005                [Page 20]

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 18, 2005                [Page 21]

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 18, 2005                [Page 22]

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 18, 2005                [Page 23]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/