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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 RFC 5106

EAP WG                                                     H. Tschofenig
Internet-Draft                                            D. Kroeselberg
Expires: August 12, 2006                                   A. Pashalidis
                                                                 Siemens
                                                                 Y. Ohba
                                                                 Toshiba
                                                              F. Bersani
                                                          France Telecom
                                                       February 12, 2006


                            EAP IKEv2 Method
                   draft-tschofenig-eap-ikev2-10.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 10, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document specifies EAP-IKEv2, an EAP authentication method that
   is based on the Internet Key Exchange (IKEv2) protocol.  EAP-IKEv2
   provides mutual authentication and session key establishment between



Tschofenig, et al.       Expires August 10, 2006                [Page 1]

Internet-Draft                  eap-ikev2                  February 2006


   an EAP peer and an EAP server.  It supports authentication techniques
   that are based on passwords, high-entropy shared keys, and public key
   certificates.  These techniques can be combined in a number of ways.
   EAP-IKEv2 further provides support for cryptographic ciphersuite
   negotiation, hash function agility, identity confidentiality (in
   certain modes of operation), fragmentation, and a "fast reconnect"
   mode.












































Tschofenig, et al.       Expires August 10, 2006                [Page 2]

Internet-Draft                  eap-ikev2                  February 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  Error handling . . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Specification of Protocol Fields . . . . . . . . . . . . . . . 17
     7.1.  The Flags, Message Length, and Integrity Checksum Data
           fields . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     7.2.  EAP-IKEv2 header . . . . . . . . . . . . . . . . . . . . . 19
     7.3.  Security Association Payload . . . . . . . . . . . . . . . 19
     7.4.  Key Exchange Payload . . . . . . . . . . . . . . . . . . . 20
     7.5.  Nonce Payload  . . . . . . . . . . . . . . . . . . . . . . 20
     7.6.  Identification Payload . . . . . . . . . . . . . . . . . . 20
     7.7.  Certificate Payload  . . . . . . . . . . . . . . . . . . . 20
     7.8.  Certificate Request Payload  . . . . . . . . . . . . . . . 20
     7.9.  Encrypted Payload  . . . . . . . . . . . . . . . . . . . . 20
     7.10. Authentication Payload . . . . . . . . . . . . . . . . . . 20
     7.11. Notify Payload . . . . . . . . . . . . . . . . . . . . . . 21
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 22
     8.1.  Protected Ciphersuite Negotiation  . . . . . . . . . . . . 22
     8.2.  Mutual Authentication  . . . . . . . . . . . . . . . . . . 22
     8.3.  Integrity Protection . . . . . . . . . . . . . . . . . . . 22
     8.4.  Replay Protection  . . . . . . . . . . . . . . . . . . . . 23
     8.5.  Confidentiality  . . . . . . . . . . . . . . . . . . . . . 23
     8.6.  Key Strength . . . . . . . . . . . . . . . . . . . . . . . 23
     8.7.  Dictionary Attack Resistance . . . . . . . . . . . . . . . 24
     8.8.  Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . 24
     8.9.  Cryptographic Binding  . . . . . . . . . . . . . . . . . . 24
     8.10. Session Independence . . . . . . . . . . . . . . . . . . . 24
     8.11. Fragmentation  . . . . . . . . . . . . . . . . . . . . . . 25
     8.12. Channel Binding  . . . . . . . . . . . . . . . . . . . . . 25
   9.  IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 26
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 28
     11.2. Informative References . . . . . . . . . . . . . . . . . . 28
   Appendix A.  EAP-IKEv2 Protocol Runs with Failed Authentication  . 29
     A.1.  Full EAP-IKEv2 . . . . . . . . . . . . . . . . . . . . . . 29
     A.2.  EAP-IKEv2 Fast Reconnect . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
   Intellectual Property and Copyright Statements . . . . . . . . . . 33







Tschofenig, et al.       Expires August 10, 2006                [Page 3]

Internet-Draft                  eap-ikev2                  February 2006


1.  Introduction

   This document specifies EAP-IKEv2, an EAP authentication method that
   is based on the Internet Key Exchange Protocol version 2 (IKEv2) [1].
   It provides mutual authentication and session key establishment
   between an EAP peer and an EAP server.  It supports authentication
   techniques that are based on the following types of credential.

   o  Asymmetric key pairs: these are public/private key pairs where the
      public key is embedded into a digital certificate, and the
      corresponding private key is known only to a single party.

   o  Passwords: these are low-entropy bit strings that are known to
      both the server and the peer.

   o  Symmetric keys: these are high-entropy bit strings that known to
      both the server and the peer.

   It is possible to use a different authentication credential (and
   thereby technique) in each direction, e.g. that the EAP server
   authenticates itself based on a public/private key pair and the EAP
   client based on a symmetric key.  In particular, the following
   combinations are expected to be used in practice.  These are referred
   to as "use cases" in the remainder of this document.

   1.  EAP server: asym. key pair, EAP peer: asym. key pair

   2.  EAP server: asym. key pair, EAP peer: symmetric key

   3.  EAP server: asym. key pair, EAP peer: password

   4.  EAP server: symmetric key, EAP peer: symmetric key

   Other conceivable use cases are not expected to be used in practice
   due to key management issues, and have not been considered in this
   document.

   The remainder of this document is structured as follows.

   o  The next section provides an overview of some of the terms and
      abbreviations used in this document.

   o  Section 3 provides an overview of the full EAP-IKEv2 exchange and
      thereby specifies the protocol message composition.

   o  Section 4 specifies the message composition for the EAP-IKEv2
      "fast reconnect" mode of operation.




Tschofenig, et al.       Expires August 10, 2006                [Page 4]

Internet-Draft                  eap-ikev2                  February 2006


   o  Section 5 specifies how exportable session keys are derived.

   o  Section 6 specifies how possible errors that may occur during
      protocol execution are handled.

   o  Section 7 specifies the format of the EAP-IKEv2 data fields is
      specified, where Section 7.1 also describes how fragmentation is
      handled in EAP-IKEv2.

   o  Section 8 provides a list of claimed security properties.









































Tschofenig, et al.       Expires August 10, 2006                [Page 5]

Internet-Draft                  eap-ikev2                  February 2006


2.  Terminology

   This document makes use of terms defined in [2] and [1].  In
   addition, the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,
   SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear
   in this document, are to be interpreted as described in [3].

   A list of abbreviations that are used in this document follows.

   o  AUTH: Denotes a data field containing either a MAC or a signature.
      This field is in embedded into an Authentication payload, defined
      in Section 7.10.

   o  CERT: Public key certificate or similar structure.

   o  CERTREQ: Certificate Request.

   o  EMSK: Extended Master Session Key, defined in [2].

   o  HDR: EAP-IKEv2 header, defined in Section 7.2.

   o  I: Initiator, the party that sends the first message of an EAP-
      IKEv2 protocol run.  This is always the EAP server.

   o  MAC: Message Authentication Code.  The result of a cryptographic
      operation that involves a symmetric key.

   o  MSK: Master Session Key, defined in [2].

   o  prf: Pseudorandom function: a cryptographic function whose output
      is assumed to be indistinguishable from that of a truly random
      function.

   o  R: Responder, the party that sends the second message of an EAP-
      IKEv2 protocol run.  This is always the EAP peer.

   o  SA: Security Association.  In this document SA denotes a type of
      payload that is used for the negotiation of the cryptographic
      algorithms that are to be used within an EAP-IKEv2 protocol run.
      Specifically, SAi denotes a set of choices that are accepted by an
      initiator, and SAr denotes the choice of the responder.

   o  Signature: The result of a cryptographic operation that involves
      an asymmetric key.  In particular, it involves the private part of
      a public/private key pair.

   o  SK: Session Key. In this document, the notation SK{x} denotes that
      x is embedded within an Encrypted payload, i.e. that x is



Tschofenig, et al.       Expires August 10, 2006                [Page 6]

Internet-Draft                  eap-ikev2                  February 2006


      encrypted and integrity-protected using EAP-IKEv2 internal keys.
      These keys are different in each direction.

   o  SK_xx: EAP-IKEv2 internal key, defined in section 2.14 of [1].

   o  SKEYSEED: Keying material, defined in section 2.14 of [1].













































Tschofenig, et al.       Expires August 10, 2006                [Page 7]

Internet-Draft                  eap-ikev2                  February 2006


3.  Protocol Overview

   In this section, the full EAP-IKEv2 protocol run is specified.  All
   messages are sent between two parties, namely an EAP peer and an EAP
   server.  In EAP-IKEv2, the EAP server always assumes the role of the
   initiator (I), and the EAP peer that of the responder (R) of an
   exchange.

   The semantics and formats of EAP-IKEv2 messages are similar, albeit
   not identical, to those specified in IKEv2 [1] for the establishment
   of an IKE Security Association.  The full EAP-IKEv2 protocol run
   consists of two roundtrips that are followed by either an EAP-Success
   or an EAP-Failure message.  An optional roundtrip for exchanging EAP
   identities may precede the two exchanges.


   1. R<-I: EAP-Request/Identity

   2. R->I: EAP-Response/Identity(Id)

   3. R<-I: EAP-Req (HDR, SAi, KEi, Ni)

   4. R->I: EAP-Res (HDR, SAr, KEr, Nr, [CERTREQ], [SK{IDr}])

   5. R<-I: EAP-Req (HDR, SK{IDi, [CERT], [CERTREQ], AUTH})

   6. R->I: EAP-Res (HDR, SK{IDr, [CERT], AUTH})

   7. R<-I: EAP-Success

   Figure 1: EAP-IKEv2 full, successful protocol run

   Figure 1 shows the full EAP-IKEv2 protocol run, including the
   optional EAP identity exchange (messages 1 and 2).  A detailed
   specification of the message composition follows.

   Messages 1 and 2 are a standard EAP Identity Request and Response, as
   defined in [2].  Message 3 is the first EAP-IKEv2-specific message.
   With this, the server starts the actual EAP authentication exchange.
   It contains the initiator SPI in the EAP-IKEv2 header (HDR) (the
   initiator selects this value on a per-protocol run basis), the set of
   cryptographic algorithms the server is willing to accept for the
   protection of EAP-IKEv2 traffic (encryption and integrity protection)
   and the derivation of the session key.  This set is encoded in the
   Security Association payload (SAi).  It also contains a Diffie-
   Hellman payload (KEi), and a Nonce payload (Ni).

   When the peer receives message 3, it selects a set of cryptographic



Tschofenig, et al.       Expires August 10, 2006                [Page 8]

Internet-Draft                  eap-ikev2                  February 2006


   algorithms from the ones that are proposed in the message.  In this
   overview, it is assumed that an acceptable such set exists (and is
   thus selected), and that the Diffie-Hellman value KEi belongs to an
   acceptable group.  The peer then generates a non-zero Responder SPI
   value for this protocol run, its own Diffie-Hellman value (KEr) and
   nonce (Nr), and calculates the keys SKEYSEED, SK_d, SK_ai, SK_ar,
   SK_ei, SK_er, SK_pi, and SK_pr according to section 2.14 of [1].  The
   peer then constructs message 4.  In the context of use cases 1, 2 and
   3, the peer's local policy MAY dictate the inclusion of the optional
   CERTREQ payload in that message, which gives a hint to the server to
   include a certificate for its public key in its next message.  In the
   context of use case 4, the peer MUST include the optional SK{IDr}
   payload, which contains its EAP-IKEv2 identifier, encrypted and
   integrity-protected within an Encrypted payload.  The keys used to
   construct this Encrypted payload are SK_er (for encryption) and SK_ar
   (for integrity protection), in accordance with [1].  The responder's
   EAP-IKEv2 identifier (IDr) is likely to be needed in these use cases
   by the server in order to select the correct symmetric key or
   password for the construction of the AUTH payload of message 5.

   Upon reception of message 4, the server also computes SKEYSEED, SK_d,
   SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr according to section
   2.14 of [1].  If an SK{IDr} payload is included, the server decrypts
   it and verifies its integrity with the corresponding keys.  In this
   overview, decryption and verification is assumed to succeed.  The
   server then constructs message 5 which contains only the EAP-IKEv2
   header followed by a single Encrypted payload.  The keys used to
   generate the encrypted payload MUST be SK_ei (for encryption) and
   SK_ai (for integrity protection), in accordance with [1].  The
   initiator MUST embed at least two payloads in the Encrypted Payload,
   as follows.  An Identification payload with the initiator's EAP-IKEv2
   identifer MUST be embedded in the Encrypted payload.  The
   Authentication payload MUST be embedded in the Encrypted payload.  A
   Certificate payload, and/or a Certificate Request payload MAY also be
   embedded in the Encrypted payload.  Message 5 is sent to the
   responder.

   Upon reception of message 5, the responder (EAP peer) authenticates
   the initiator (EAP server).  The checks that are performed to this
   end depend on the use case, local policies, and are specified in [1].
   These checks include (but may not be limited to) decrypting the
   Encrypted payload, verifying its integrity, and checking that the
   Authentication payload contains the expected value.  If all checks
   succeed (which is assumed in this overview), the responder constructs
   message 6.  That message MUST contain the EAP-IKEv2 header followed
   by a single Encrypted payload, in which at least two further payloads
   MUST be embedded, as shown in Figure 1.




Tschofenig, et al.       Expires August 10, 2006                [Page 9]

Internet-Draft                  eap-ikev2                  February 2006


   Upon reception of message 6, the initiator (EAP server) authenticates
   the responder (EAP peer).  As above, the checks that are performed to
   this end depend on the use case, local policies, and MUST include
   decryption and verification of the Encrypted payload, as well as
   checking that the Authentication payload contains the expected value.
   If the optional SK{IDr} payload was included in message 4, the EAP
   server MUST also ensure that the IDr paylod in message 6 is identical
   to that in message 4.

   If authentication succeeds, an EAP-Success message is sent to the
   responder as message 7.  The EAP server and the EAP peer generate a
   Master Session Key (MSK) and an Extended Master Session Key (EMSK)
   after a successful EAP-IKEv2 protocol run, according to Section 5.






































Tschofenig, et al.       Expires August 10, 2006               [Page 10]

Internet-Draft                  eap-ikev2                  February 2006


4.  Fast Reconnect

   This section specifies a "fast reconnect" mode of operation for EAP-
   IKEv2.  This mode can only be used by an EAP server/EAP peer pair
   that has already been mutually authenticated in a previous EAP-IKEv2
   protocol run.

   The purpose of fast reconnect is to enable an efficient re-
   authentication procedure that also results in a fresh MSK and EMSK.
   The "fast reconnect" mode can only be used where an EAP-IKEv2
   security context already exists at both the server and the peer, and
   its usage is subject to the local policies.

   The EAP-IKEv2 fast reconnect exchange is similar, albeit not
   identical, to the IKE-SA rekeying procedure as specified in section
   2.18 of [1].  During fast reconnect, the server and the peer MAY
   exchange fresh Diffie-Hellman values.




   1. R<-I: EAP-Request/Identity

   2. R->I: EAP-Response/Identity(Id)

   3. R<-I: EAP-Req(HDR, SK{SA, Ni, [KEi]})

   4. R->I: EAP-Res(HDR, SK{SA, Nr, [KEr]})

   5. R<-I: EAP-Success


   Figure 2: EAP-IKEv2 successful fast reconnect protocol run

   Figure 2 shows the message composition for the EAP-IKEv2 fast
   reconnect mode.  As in the full mode, the EAP server is the initiator
   and the EAP peer is the responder.  The first two messages constitute
   the standard EAP identity exchange and are optional; they are not
   required if the EAP server is known to the peer and vice versa.
   Messages 3 and 4 establish a fresh EAP-IKEv2 security context.  In
   message 3, the initiator MAY select a new (non-zero) SPI value in the
   IKE_SA Initiator's SPI field of the EAP-IKEv2 header.  The value of
   the IKE_SA Responder's SPI field MUST be the one from the previous
   EAP-IKEv2 protocol run.  The nonce inside the Nonce payload (Ni) MUST
   be fresh, and the Diffie-Hellman value inside the Diffie-Hellman
   payload (if present, KEi) MUST also be fresh.  Note that the
   algorithms and keys that are used to construct the Encrypted payload
   in message 3, are the same as in the previous successful EAP-IKEv2



Tschofenig, et al.       Expires August 10, 2006               [Page 11]

Internet-Draft                  eap-ikev2                  February 2006


   protocol run.

   Upon reception of message 3, the responder (EAP peer) decrypts and
   verifies the Encrypted payload.  If successful (as assumed in
   Figure 2), it constructs message 4 in a fashion similar to the
   construction of message 3.  Note that the IKE_SA Responder's SPI
   field in the EAP-IKEv2 header of message 4 MUST contain the same
   value as in message 3.  The responder MAY choose a new (non-zero)
   value for the IKE_SA Initiator's SPI in message 4.  Upon reception of
   message 4, the initiator (EAP server) decrypts and verifies the
   Encrypted payload.  If successful, this protocol run is deemed
   successful, and the server responds with an EAP-Success message
   (message 5).

   After successful EAP-IKEv2 fast reconnect protocol run, both the
   initiator and the responder generate fresh keying material, that is
   used for the protection of subsequent EAP-IKEv2 traffic.
   Furthermore, both the initiator and the responder MAY generate a
   fresh MSK and EMSK and export them.

   The new EAP-IKEv2-specific keying material is computed in the same
   way as in the full EAP-IKEv2 protocol run, and in accordance with
   section 2.18 of [1].  That is, SKEYSEED is computed as SKEYSEED =
   prf(SK_d (old), [g^ir (new)] | Ni | Nr), where SK_d (old) is the key
   SK_d from the previous successful EAP-IKEv2 protocol run, Ni and Nr
   are the nonces (without the Nonce payload headers) that were
   exchanged in messages 3 and 4, and g^ir (new) is the newly computed
   Diffie-Hellman key, if both the values KEi and KEr were present in
   messages 3 and 4.  The remaining EAP-IKEv2-specific keys (SK_d,
   SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr) are generated as in the
   full EAP-IKEv2 protocol run.

   The generation of a fresh MSK and EMSK follows the generation of the
   EAP-IKEv2-specific keys and adheres to the rules in Section 5.

   Note: In EAP-IKEv2, the EAP server initiates the fast reconnect mode
   and thereby causes fresh session keys to be established.  If the
   client wishes to initiate this "fast rekeying", it needs to indicate
   this to the network by an appropriate out-of-band means (e.g. at the
   link-layer).











Tschofenig, et al.       Expires August 10, 2006               [Page 12]

Internet-Draft                  eap-ikev2                  February 2006


5.  Key Derivation

   This section describes how the Master Session Key (MSK) and the
   Extended Master Session Key (EMSK) are derived in EAP-IKEv2.  It is
   expected that these keys are exported by the EAP-IKEv2 process and be
   used in accordance with the EAP keying framework [5].

   During an EAP-IKEv2 protocol run, the initiator and the responder
   generate a number of keys, as described above and in accordance with
   section 2.14 of [1].  The generation is these keys is based on a
   pseudorandom function (prf) that both parties have agreed to use and
   which is applied in an iterative fashion.  This iterative fashion is
   specified in section 2.13 of [1].  The same prf is used in the same
   fashion in order to generate the MSK and the EMSK.

   In particular, following a successful EAP-IKEv2 protocol run, both
   parties generate 128 octets of keying material, denoted KEYMAT, as
   KEYMAT = prf+(SK_d, Ni | Nr), where Ni and Nr are the nonces from
   messages 3 and 4 shown in Figure 1 (in the context of a full EAP-
   IKEv2 protocol run) or Figure 2 (in the context of a fast reconnect
   EAP-IKEv2 protocol run).  Note that only the nonces are used, i.e.
   not the entire Nonce payload that contains them.  If the output size
   of the prf is less than 128 octets, then the prf is used iteratively,
   as specified in section 2.13 of [1], until 128 octets are generated.

   The first 64 octets of KEYMAT are exported as the EAP MSK, and the
   second 64 octets are exported as the EMSK.  The MSK and EMSK must
   only be exported when an EAP-IKEv2 protocol run completes
   successfully.

   Finally, note that the EAP-IKEv2 method does not produce an
   initialisation vector.



















Tschofenig, et al.       Expires August 10, 2006               [Page 13]

Internet-Draft                  eap-ikev2                  February 2006


6.  Error handling

   This section specifies how errors are handled within EAP-IKEv2.  For
   conveying error information from one party to the other, the Notify
   payload is defined and used (see Section 7.11).

   If authentication fails (i.e. the verification of the AUTH field
   fails at the server or the peer), but no other errors have occurred,
   the message flow of the full and "fast reconnect" EAP-IKEv2 protocol
   run deviates from that described in Section 3 and Section 4.  The
   message flows in the presence of authentication failures are
   specified in Appendix A.

   If, in message 3 of a full or "fast reconnect" EAP-IKEv2 protocol run
   (see Figure 1 and Figure 2), the responder receives a Diffie-Hellman
   value (KEi) that belongs to a group that is not supported (and in the
   absence of other errors), then the responder MUST send a message of
   the form shown in Figure 3 to the initiator.  This effectively
   becomes message 4 in the protocol run.



   4. R->I: EAP-Res (HDR, N(INVALID_KE_PAYLOAD))


   Figure 3: Error handling in case of unsupported D-H value

   The above message consists of the EAP-IKEv2 header and a Notification
   payload with the value of the Notify Message Type field value set to
   17 (INVALID_KE_PAYLOAD).  There are two octets of data associated
   with this notification: the number of the accepted DH Group in big
   endian order, as specified in section 3.10.1 of [1].

   If, during a full EAP-IKEv2 protocol run (see Figure 1), the
   initiator receives a message conforming to Figure 3 instead of the
   usual message 4, then the protocol continues with a new message 3
   that the initiator sends to the peer.  In this new message 3 the
   initiator SHOULD use a Diffie-Hellman value that is drawn from the
   group that is indicated in the Notify payload of message 4 in
   Figure 3.  If local policy does not allow this, or if the initiator
   does not support the indicated group, then it MUST resend the
   original message 3 (or a "usual" message 3 with fresh values), up to
   a predetermined number of times.  If the error persists (i.e. if the
   initiator keeps receiving a message conforming to Figure 3) beyond
   that, then the initiator MUST give up with an EAP-Failure message.

   If, during a fast reconnect EAP-IKEv2 protocol run (see Figure 2),
   the initiator receives a message conforming to Figure 3 instead of



Tschofenig, et al.       Expires August 10, 2006               [Page 14]

Internet-Draft                  eap-ikev2                  February 2006


   the usual message 4, then the protocol continues with a new message 3
   that the initiator sends to the peer.  In this new message 3 the
   initiator MUST use a Diffie-Hellman value that is drawn from the same
   group as the one from which the Diffie-Hellman value in message 3 of
   the initial full EAP-IKEv2 protocol run with this peer was drawn.  If
   the error persists (i.e. if the initiator receives another message
   conforming to Figure 3), then the initiator MUST give up with an EAP-
   Failure message.

   Other errors do not trigger messages with Notification payloads to be
   sent, and MUST be treated as if nothing happened (i.e. the erroneous
   EAP-IKEv2 packet MUST be silently discarded).  This includes
   situations where at least one of the following conditions is met,
   with respect to an incoming EAP-IKEv2 packet.

   o  The packet contains an Encrypted payload that, when decrypted with
      the appropriate key, yields an invalid decryption.

   o  The packet contains an Encrypted payload with a Checksum field
      that does not verify with the appropriate key.

   o  The packet contains an Integrity Checksum Data field (see
      Figure 4) that is incorrect.

   o  The packet does not contain a compulsory field.

   o  A field in the packet contains an invalid value (e.g. an invalid
      combination of flags, a length field that is inconsistent with the
      real length of the field or packet, or the responder's choice of a
      cryptographic algorithm is different to NONE and any of those that
      were offered by the initiator).

   o  The packet contains an invalid combination of fields (e.g. it
      contains two or more Notify payloads with the same Notify Message
      Type value, or two or more Transform substructures with the same
      Transform Type and Transform ID value).

   o  The packet causes a defragmentation error.

   o  The format of the packet is invalid.

   If an incoming packet causes both an authentication failure and a
   channel binding error (and no other errors), then the packet MUST be
   treated as if it only caused the authentication failure.

   If an incoming packet contains an error for which behaviour is
   specified in this section, and an error that, in the absence of the
   former error, would cause the packet to be silently discarded, then



Tschofenig, et al.       Expires August 10, 2006               [Page 15]

Internet-Draft                  eap-ikev2                  February 2006


   the packet MUST be silently discarded.


















































Tschofenig, et al.       Expires August 10, 2006               [Page 16]

Internet-Draft                  eap-ikev2                  February 2006


7.  Specification of Protocol Fields

   In this section, the format of the EAP-IKEv2 data fields and
   applicable processing rules are specified.  Figure 4 shows the
   general packet format of EAP-IKEv2 messages, and the embedding of
   EAP-IKEv2 into EAP.  The EAP-IKEv2 messages are embedded in the Data
   field of the standard EAP Request/Response packets.  The Code,
   Identifier, Length and Type fields are described in [2].  The EAP
   Type for this EAP method is TBD.



      0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Code      |   Identifier  |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |   Flags       |       Message Length          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Message Length          |       HDR + payloads          ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Integrity Checksum Data                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Figure 4: General packet format of EAP-IKEv2

   The Flags field is always present and is used for fragmentation
   support, as described in Section 7.1.  The Message Length field is
   not always present; it's presence is determined by a certain flag in
   the Flags field, as described in Section 7.1.  The field denoted as
   "HDR + payloads" in Figure 4 contains the EAP-IKEv2 header (see
   Section 7.2), followed by a number of payloads, in accordance with
   the composition of EAP-IKEv2 messages, as described in the previous
   sections.  Note that each payload begins with a generic payload
   header that is specified in section 3.2 of [1].

   The Integrity Checksum Data field is not always present; its presence
   is determined by a certain flag in the Flags field, as described in
   Section 7.1.

   In the remainder of this section, the protocol fields that are used
   in EAP-IKEv2 are specified.  This specification heavily relies on the
   IKEv2 specification [1], and many fields are constructed, formatted
   and processed in way that is almost identical to that in IKEv2.
   However, certain deviations from standard IKEv2 formatting and
   processing exist.  These are also highlighted in the remainder of
   this section.



Tschofenig, et al.       Expires August 10, 2006               [Page 17]

Internet-Draft                  eap-ikev2                  February 2006


7.1.  The Flags, Message Length, and Integrity Checksum Data fields

   This section describes EAP-IKEv2 fragmentation, and specifies the
   encoding and processing rules for the Flags, Message Length, and
   Integrity Checksum Data field shown in Figure 4.

   Fragmentation support in EAP-IKEv2 is provided by the Flags and
   Message Length fields shown in Figure 4.  These are encoded and used
   as follows.


    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |L M I 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+

   L = Length included
   M = More fragments
   I = Integrity Checksum Data included


   Figure 5: Flags field

   Only the first three bits (0-2) are used; all remaining bits MUST be
   set to zero.  The L flag indicates the presence of a Message Length
   field, and the M flag indicates whether or not the current EAP
   message has more fragments.  In particular, if the L bit is set, then
   a Message Length field MUST be present in the EAP message, as shown
   in Figure 4.  The Message Length field is four octets long and
   contains the length of the entire message (i.e. the length of the EAP
   Data field.).  Note that, in contrast, the Length field shown in
   Figure 4 contains the length of only the current fragment.  If the L
   bit is not set, the Message Length field MUST NOT be present.

   The M flag MUST be set on all fragments except the last one.  In the
   last fragment, the M flag MUST NOT be set.  Reliable fragment
   delivery is provided by the retransmission mechanism of EAP.

   The Integrity Checksum Data field contains a cryptographic checksum
   that covers the entire EAP message, starting with the Code field, and
   ending at the end of the EAP Data field.  This field, shown in
   Figure 4, is present only if the I bit is set in the Flags field.
   The Integrity Checksum Data field immediately follows the EAP Data
   field without padding.

   Whenever possible, the Integrity Checksum Data field MUST be present
   (and the I bit set) for each fragment, including the case where the
   entire EAP-IKEv2 message is carried in a single fragment.  The



Tschofenig, et al.       Expires August 10, 2006               [Page 18]

Internet-Draft                  eap-ikev2                  February 2006


   algorithm and keys that are used to compute the Integrity Checksum
   Data field MUST be identical to those used to compute the Integrity
   Checksum Data field of the Encrypted Payload (see Section 7.9).  That
   is, the algorithm and keys that were negotiated and established
   during this EAP-IKEv2 protocol run are used.  Note that this means
   that different keys are used to compute the Integrity Checksum Data
   field in each direction.  Also note that, for messages where this
   algorithm and the keys are not yet established, the Integrity
   Checksum Data field cannot be computed and is therefore not included.
   This applies, for example, to messages 3 and 4 in Figure 1.

   In order to minimize the exposure to denial-of-service attacks on
   fragmented packets, messages that are not protected with an Integrity
   Checksum Data field SHOULD NOT be fragmented.  Note, however, that
   those packets are not likely to be fragmented anyway since they do
   not carry certificates.

7.2.  EAP-IKEv2 header

   The EAP-IKEv2 header, denoted HDR in this specification, is
   constructed and formatted according to the rules specified in section
   3.1 of [1].

   In the first EAP-IKEv2 message that is sent by the initiator (message
   3 in Figure 1), the IKE_SA Responder's SPI field is set to zero.
   This is because, at this point in time, the initiator does not know
   what SPI value the responder will choose for this protocol run.  In
   all other messages, both SPI fields MUST contain non-zero values that
   reflect the initiator and responder-chosen SPI values.

   In accordance with [1], for this version of EAP-IKEv2, the MjVer
   (major version) and MnVer (minor version) fields in the header MUST
   be 2 and 0 respectively.  The value of the Exchange Type field MUST
   be set to 34 (IKE_SA_INIT) in messages 3 and 4, and to 35
   (IKE_SA_AUTH) in messages 5 and 6 in Figure 1.  In messages 3 and 4
   in Figure 2 this value MUST be set to 36 (CREATE_CHILD_SA).

   The Flags field of the EAP-IKEv2 header is also constructed according
   to section 3.1 of [1].  Note that this is not the same field as the
   Flags field shown in Figure 4.

7.3.  Security Association Payload

   The SA payload is used for the negotiation of cryptographic
   algorithms between the initiator and the responder.  The rules for
   its construction adhere to [1], in particular section 2.7 and 3.3.

   In EAP-IKEv2 the SA payload MUST contain a single Proposal



Tschofenig, et al.       Expires August 10, 2006               [Page 19]

Internet-Draft                  eap-ikev2                  February 2006


   Substructure where the Protocol ID value is 1 (IKE).

7.4.  Key Exchange Payload

   The Key Exchange payload, denoted KEi if constructed by the initiator
   and KEr if constructed by the responder, is formatted according to
   the rules specified in section 3.4 of [1].

7.5.  Nonce Payload

   The Nonce payload, denoted Ni if constructed by the initiator and Nr
   if constructed by the responder, is constructed and formatted
   according to the rules specified in section 3.9 of [1].

7.6.  Identification Payload

   The Identification payload, denoted IDi if it contains an identifier
   for the initiator and IDr if it contains an identifier for the
   responder, is constructed and formatted according to the rules
   specified in section 3.5 of [1].

7.7.  Certificate Payload

   The Certificate payload, denoted CERT, is constructed and formatted
   according to the rules specified in section 3.6 of [1].  Note that
   certain certificate encodings for the EAP server certificate, e.g.
   those that need to be resolved via another network protocol, cannot
   be used in some typical EAP-IKEv2 deployment scenarios.  A user, for
   example, that authenticates himself by means of EAP-IKEv2 in order to
   obtain network access, cannot resolve the server certificate at the
   time of EAP-IKEv2 protocol execution.

7.8.  Certificate Request Payload

   The Certificate payload, denoted CERTREQ, is constructed and
   formatted according to the rules specified in section 3.7 of [1].

7.9.  Encrypted Payload

   The Encrypted payload, denoted SK{...}, is constructed and formatted
   according to the rules specified in section 3.14 of [1].

7.10.  Authentication Payload

   The Authentication payload, denoted AUTH, is constructed and
   formatted according to the rules specified in sections 2.15 and 3.8
   of [1].




Tschofenig, et al.       Expires August 10, 2006               [Page 20]

Internet-Draft                  eap-ikev2                  February 2006


   The contents of the Authentication payload depend on which party
   generates this field, the use case, and the algorithm that
   corresponds to the credential (asymmetric key, symmetric key, or
   password) that this party uses to authenticate itself.  The
   Authentication payload contains either a MAC or a signature.

   If the party that generates the Authentication payload authenticates
   itself based on a shared secret (i.e. a password or a symmetric key),
   then the Authentication payload MUST contain a MAC.  This MAC is
   calculated using a key that is derived from the shared secret,
   according to section 2.15 of [1].  According to that section, the
   shared secret is padded with the string "Key Pad for IKEv2" as part
   of this key derivation.  For the EAP-IKEv2 method, this rule is
   overridden, in that the padding string is redefined as "Key Pad for
   EAP-IKEv2".  The latter padding string MUST be used for the
   derivation of the MAC key from a shared secret in the context of EAP-
   IKEv2.  This is done in order to avoid the same MAC key to be used
   for both IKEv2 and EAP-IKEv2 in scenarios where the same shared
   secret is used for both.  Note that using a shared secret (e.g. a
   password) in the context EAP-IKEv2 that is identical or similar to a
   shared secret that is used in another context (including IKEv2) is
   nevertheless NOT RECOMMENDED.

7.11.  Notify Payload

   The Notify payload, denoted N(...), is constructed and formatted
   according to the rules specified in section 3.10 of [1].  The
   Protocol ID field of this payload MUST be set to 1 (IKE_SA).























Tschofenig, et al.       Expires August 10, 2006               [Page 21]

Internet-Draft                  eap-ikev2                  February 2006


8.  Security Considerations

   As mentioned in Section 3, in EAP-IKEv2, the EAP server always
   assumes the role of the initiator (I), and the EAP peer takes on the
   role of the responder (R) of an exchange.  This is in order to ensure
   that, in scenarios where the peer authenticates itself based on a
   password (i.e. in use case 3), operations that involve this password
   only take place after the server has been successfully authenticated.
   In other words, this assignment of initiator and responder roles
   results in protection against offline dictionary attacks on the
   password that is used by the peer to authenticate itself (see
   Section 8.7).

   In order for two EAP-IKEv2 implementations to be interoperable, they
   must support at least one common set of cryptographic algorithms.  In
   order to promote interoperability, EAP-IKEv2 implementations MUST
   adhere to the same rules with regard to mandatory-to-implement
   cryptographic algorithms as IKEv2.  These rules are specified in [4].

   The remainder of this section describes EAP-IKEv2 in terms of
   specific security terminology as required by [2].  The discussion
   makes reference to the use cases defined in Section 1 above.

8.1.  Protected Ciphersuite Negotiation

   In message 3, the EAP server provides the set of ciphersuites it is
   willing to accept in an EAP-IKEv2 protocol run.  Hence, the server is
   in control of the ciphersuite.  An EAP peer that does not support any
   of the indicated ciphersuites is not able to authenticate.  The local
   security policy of the peer MUST specify the set of ciphersuites that
   the peer accepts.  The server MUST verify that the ciphersuite that
   is indicated as being chosen by the peer in message 4, belongs to the
   set of ciphersuites that were offered in message 3.  If this
   verification fails, the server MUST silently discard the packet.

8.2.  Mutual Authentication

   EAP-IKEv2 supports mutual authentication.

8.3.  Integrity Protection

   EAP-IKEv2 provides integrity protection of EAP-IKEv2 traffic.  This
   protection is offered after authentication is completed and is
   facilitated by inclusion of two Integrity Checksum Data fields: one
   at the end of the EAP packet (see Figure 4), and one as part of an
   Encrypted payload (see Section 7.9).





Tschofenig, et al.       Expires August 10, 2006               [Page 22]

Internet-Draft                  eap-ikev2                  February 2006


8.4.  Replay Protection

   EAP-IKEv2 provides protection against replay attacks by a variety of
   means.  This includes the requirement that the Authentication payload
   is computed as a function of, among other things, a server-provided
   nonce and a peer-provided nonce.  These nonces are required to be
   practically unpredictable by an adversary.  Assuming that the
   algorithm that is used to compute the Authentication payload does not
   contain cryptographic weaknesses, the probability that an
   Authentication payload that is valid in a particular protocol run,
   will also be valid in a subsequent run, is therefore negligible.

8.5.  Confidentiality

   EAP-IKEv2 provides confidentiality of certain EAP-IKEv2 fields,
   namely those included in Encrypted payloads.  With respect to
   identity confidentiality, the following claims are made.  Note that
   identity confidentiality refers to the EAP-IKEv2 identity of the EAP
   peer.

   Identity confidentiality is provided in the face of a passive
   adversary, i.e. an adversary that does not modify traffic as it is in
   transit.  Whenever the optional SK{IDr} payload in message 4 of a
   full EAP-IKEv2 protocol (see Figure 1) is not included, identity
   confidentiality is also provided in the face of an active adversary.
   This payload MUST NOT be included in use cases 1, 2, and 3.  In use
   case 4 this payload MUST be included.  Therefore, in use case 4, EAP-
   IKEv2 does not provide identity confidentiality in the face of an
   active adversary.

8.6.  Key Strength

   EAP-IKEv2 supports the establishment of session keys (MSK and EMSK)
   of a variety of key strengths, with the theoretical maximum at 512
   bits per key (since this is the size of the MSK and the EMSK).
   However, in practice the effective key strength is likely to be
   significantly lower, and depends on the authentication credentials
   used, the negotiated ciphersuite (including the output size of the
   pseudorandom function), the Diffie-Hellman group used, and on the
   extent to which the assumptions on which the underlying cryptographic
   algorithms depend really hold.  Of the above mechanisms, the one that
   offers the lowest key strength can be regarded as a measure of the
   effective key strength of the resulting session keys.  Note that this
   holds for other EAP methods, too.

   Due to the large variety of possible combinations, no indication of a
   practical effective key strength for MSK or EMSK is given here.
   However, those responsible for the deployment of EAP-IKEv2 in a



Tschofenig, et al.       Expires August 10, 2006               [Page 23]

Internet-Draft                  eap-ikev2                  February 2006


   particular environment should consider the threats this environment
   may be exposed to, and configure the EAP-IKEv2 server and peer
   policies and authentication credentials such that the established
   session keys are of a sufficiently high effective key strength.

8.7.  Dictionary Attack Resistance

   EAP-IKEv2 can be used in a variety of use cases, as explained in
   Section 1.  In some of these uses cases, namely use case 1, 2, and 4,
   dictionary attacks cannot be launched since no passwords are used.
   In use case 3, EAP-IKEv2 provides protection against offline
   dictionary attacks, since operations that involve the password are
   executed only after the server has authenticated itself (based on a
   credential other than a password).

   In order to reduce exposure against online dictionary attacks, in use
   case 3, the server SHOULD provide the capability to log failed peer
   authentication events, and SHOULD implement a suitable policy in case
   of consecutive failed peer authentication attempts within a short
   period of time (such as responding with an EAP-Failure instead of
   message 5 for a predetermined amount of time).

8.8.  Fast Reconnect

   EAP-IKEv2 supports a "fast reconnect" mode of operation, as described
   in Section 4.

8.9.  Cryptographic Binding

   EAP-IKEv2 is not a tunnel EAP method.  Thus, cryptographic binding
   does not apply to EAP-IKEv2.

8.10.  Session Independence

   EAP-IKEv2 provides session independence in a number of ways, as
   follows.  Firstly, knowledge of captured EAP-IKEv2 conversations
   (i.e. the information that a passive adversary may obtain) does not
   enable the adversary to compute the Master Session Key (MSK) and
   Extended Master Session Key (EMSK) that resulted from these
   conversations.  This holds even in the case where the adversary later
   obtains access to the server and/or the peer's long-term
   authentication credentials that were used in these conversations.
   That is, EAP-IKEv2 provides support for "perfect forward secrecy".
   However, whether or not this support is made use of in a particular
   EAP-IKEv2 protocol run, depends on when the peer and the server
   delete the Diffie-Hellman values that they used in that run, and on
   whether or not they use fresh Diffie-Hellman values in each protocol
   run.  The discussion in section 2.12 of [1] applies.



Tschofenig, et al.       Expires August 10, 2006               [Page 24]

Internet-Draft                  eap-ikev2                  February 2006


   Secondly, an active adversary that does not know the peer's and the
   server's long-term authentication credentials cannot learn the MSK
   and EMSK that were established in a particular protocol run of EAP-
   IKEv2, even if it obtains access to the MSK and EMSK that were
   established in other protocol runs of EAP-IKEv2.  This is because the
   MSK and the EMSK are a function of, among other things, data items
   that are assumed to be generated independently at random in each
   protocol run.

8.11.  Fragmentation

   EAP-IKEv2 provides support for fragmentation, as described in
   Section 7.1.

8.12.  Channel Binding

   Channel binding support in EAP-IKEv2 is TBD.


































Tschofenig, et al.       Expires August 10, 2006               [Page 25]

Internet-Draft                  eap-ikev2                  February 2006


9.  IAB Considerations

   IANA should allocate a value for the EAP method type indicating EAP-
   IKEv2.















































Tschofenig, et al.       Expires August 10, 2006               [Page 26]

Internet-Draft                  eap-ikev2                  February 2006


10.  Acknowledgements

   The authors would like to thank Bernard Aboba, Jari Arkko, Guenther
   Horn, Thomas Otto, Paulo Pagliusi and John Vollbrecht for their
   insightful comments and suggestions.

   In addition, the authors would like to thank the members of the PANA
   design team, in particular D. Forsberg and A. Yegin, for their
   comments and input to the initial version of the draft.

   Finally, the authors are grateful to the members of the EAP keying
   design team for their discussion in the area of the EAP Key
   Management Framework. .






































Tschofenig, et al.       Expires August 10, 2006               [Page 27]

Internet-Draft                  eap-ikev2                  February 2006


11.  References

11.1.  Normative References

   [1]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
        December 2005.

   [2]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
        Levkowetz, "Extensible Authentication Protocol (EAP) (RFC
        3748)", Request For Comments 3748, June 2004.

   [3]  Bradner, S., "Internet Key Exchange (IKEv2) Protocol", RFC 2119,
        March 1997.

   [4]  Schiller, J., "Cryptographic Algorithms for Use in the Internet
        Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.

11.2.  Informative References

   [5]  Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. Levkowetz,
        "Extensible Authentication Protocol (EAP) Key Management
        Framework", Internet Draft (work in progress), January 2006.





























Tschofenig, et al.       Expires August 10, 2006               [Page 28]

Internet-Draft                  eap-ikev2                  February 2006


Appendix A.  EAP-IKEv2 Protocol Runs with Failed Authentication

   This appendix illustrates how authentication failures are handled
   within EAP-IKEv2.

A.1.  Full EAP-IKEv2

   Figure 6 shows the message flow in case the EAP peer fails to
   authenticate the EAP server.


   1. R<-I: EAP-Request/Identity

   2. R->I: EAP-Response/Identity(Id)

   3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni)

   4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}])

   5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], [IDr], AUTH})

   6. R->I: EAP-Res(HDR, SK {N(AUTHENTICATION_FAILED)})

   7. R<-I: EAP-Failure


   Figure 6: EAP-IKEv2 with failed server authentication

   The difference to the full successful exchange described in Section 3
   is that, in message 6, the EAP peer MUST answer the EAP server with
   an Encrypted payload that contains a Notify payload with the Notify
   Message Type value set to 24 (AUTHENTICATION_FAILED).  In message 7,
   an EAP-Failure message MUST be returned by the EAP server.

   Figure 7 shows the message flow in case the EAP server fails to
   authenticate the EAP peer.















Tschofenig, et al.       Expires August 10, 2006               [Page 29]

Internet-Draft                  eap-ikev2                  February 2006


   1. R<-I: EAP-Request/Identity

   2. R->I: EAP-Response/Identity(Id)

   3. R<-I: EAP-Req (HDR, SAi1, KEi, Ni)

   4. R->I: EAP-Res (HDR, SAr1, KEr, Nr, [CERTREQ], [SK{IDr}])

   5. R<-I: EAP-Req (HDR, SK {IDi, [CERT], [CERTREQ], AUTH})

   6. R->I: EAP-Res (HDR, SK {IDr, [CERT], AUTH})

   7. R<-I: EAP-Req (HDR, SK {N(AUTHENTICATION_FAILED)})

   8. R->I: EAP-Res (HDR, SK {})

   9. R<-I: EAP-Failure



   Figure 7: EAP-IKEv2 with failed peer authentication

   Compared to the full successful exchange, one additional roundtrip is
   required.  In message 7 the EAP server MUST send an EAP request with
   Encrypted payload that contains a Notify payload with the Notify
   Message Type value set to 24 (AUTHENTICATION_FAILED), instead of
   sending an EAP-Success message.  The EAP peer, upon receiving message
   7, MUST send an empty EAP-IKEv2 (informational) message in reply to
   the EAP server's error indication, as shown in message 8.  The EAP
   server then answers with an EAP-Failure.

A.2.  EAP-IKEv2 Fast Reconnect

   Figure 8 shows the message flow in case the EAP peer fails to
   authenticate the EAP server. in a fast reconnect protocol run.


   1. R<-I: EAP-Request/Identity

   2. R->I: EAP-Response/Identity(Id)

   3. R<-I: EAP-Req (HDR, SK {SA, Ni, [KEi]})

   4. R->I: EAP-Res (HDR, SK {N(AUTHENTICATION_FAILED)})

   5. R <-- I: EAP-Failure





Tschofenig, et al.       Expires August 10, 2006               [Page 30]

Internet-Draft                  eap-ikev2                  February 2006


   Figure 8: EAP-IKEv2 fast reconnect with failed server authentication

   The message format of message 3 is identical to that of message 6 in
   Figure 6.  The message processing is analogous to the case of failed
   server authentication in a full EAP-IKEv2 protocol run.

   Figure 9 shows the message flow in case the EAP server fails to
   authenticate the EAP peer. in a fast reconnect protocol run



   1. R<-I: EAP-Request/Identity

   2. R->I: EAP-Response/Identity(Id)

   3. R<-I: EAP-Req (HDR, SK {SA, Ni, [KEi]})

   4. R->I: EAP-Res (HDR, SK {SA, Nr, [KEr]})

   5. R<-I: EAP-Req (HDR, SK {N(AUTHENTICATION_FAILED)})

   6. R->I: EAP-Res (HDR, SK {})

   7. R<-I: EAP-Failure


   Figure 9: EAP-IKEv2 fast reconnect with failed peer authentication

   This case is analogous to the case of peer authentication failure in
   a full EAP-IKEv2 protocol run.  The EAP peer MUST send an empty EAP-
   IKEv2 informational message (empty Encrypted payload, message 6) in
   reply to the error indication message of the EAP server (message 5).
   The EAP server answers with an EAP-Failure.


















Tschofenig, et al.       Expires August 10, 2006               [Page 31]

Internet-Draft                  eap-ikev2                  February 2006


Authors' Addresses

   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@siemens.com


   Dirk Kroeselberg
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Dirk.Kroeselberg@siemens.com


   Andreas Pashalidis
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Andreas.Pashalidis@siemens.com


   Yoshihiro Ohba
   Toshiba America Research, Inc.
   1 Telcordia Drive
   Piscataway, NJ  08854
   USA

   Email: yohba@tari.toshiba.com


   Florent Bersani
   France Telecom R&D
   38, rue du General Leclerc
   Issy-Les-Moulineaux, Cedex  92794
   France

   Email: bersani_florent@yahoo.fr






Tschofenig, et al.       Expires August 10, 2006               [Page 32]

Internet-Draft                  eap-ikev2                  February 2006


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 (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Tschofenig, et al.       Expires August 10, 2006               [Page 33]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/