[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
   Internet Draft                                         H. Tschofenig
                                                          D. Kroeselberg
                                                                 Siemens
                                                    Corporate Technology
   Document: draft-tschofenig-eap-ikev2-01.txt
   Expires: December 2003                                     June 2003


                             EAP IKEv2 Method
                                (EAP-IKEv2)


Status of this Memo


   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   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/1id-abstracts.html

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

Abstract

   EAP-IKEv2 is an EAP method which reuses the cryptography and the
   payloads of IKEv2, creating a flexible EAP method that supports both
   symmetric and asymmetric authentication. Furthermore protection of
   legacy authentication mechanisms is supported. This EAP method
   offers the security benefits of IKEv2 without the goal of
   establishing IPsec security associations.









Tschofenig, Kroselberg   Expires - December 2003              [Page 1]

                              EAP IKEv2                     June 2003


Table of Contents

   1. Introduction..................................................2
   2. Terminology...................................................3
   3. Protocol overview.............................................3
   4. Identities used in EAP-IKEv2..................................6
   5. Packet Format.................................................8
   6. Key derivation................................................9
   7. Security Considerations.......................................9
   8. Open Issues..................................................10
   9. References...................................................10
   Acknowledgments.................................................11
   Author's Addresses..............................................11
   Full Copyright Statement........................................12

1. Introduction

   IKEv2 [2] is a protocol which consists of two exchanges:

   (1) an authentication and key exchange protocol which establishes an
   IKE-SA.

   (2) messages and payloads which focus on the negotiation of
   parameters in order to establish IPsec security associations (i.e.
   Child-SAs). These payloads contain algorithm parameters and traffic
   selector fields.

   In addition to the above-mentioned parts IKEv2 also includes some
   payloads and messages which allow configuration parameters to be
   exchanged primarily for remote access scenarios.

   The EAP-IKEv2 method defined by this document uses the IKEv2
   payloads and messages used for the initial IKEv2 exchange which
   establishes an IKE-SA.

   IKEv2 provides an improvement over IKEv1 [5] as described in
   Appendix A of [2]. Important for this document are the reduced
   number of initial exchanges, support of legacy authentication,
   decreased latency of the initial exchange, optional Denial-of-
   Service (DoS) protection capability and some other fixes (e.g. hash
   problem). IKEv2 is a cryptographically sound protocol that has
   received a considerable amount of expert review and that benefits
   from a long practical experience with IKE.
   The goal of EAP-IKEv2 is to inherit these properties within an
   efficient, secure EAP method.

   In addition, IKEv2 provides authentication and key exchange
   capabilities which allow an entity to use symmetric as well as
   asymmetric authentication in addition to legacy authentication


Tschofenig, Kroselberg   Expires - December 2003              [Page 2]

                              EAP IKEv2                     June 2003


   support within a single protocol. Such flexibility is considered
   important for an EAP method and is provided by EAP-IKEv2.

   [6] provides a good tutorial for IKEv2 design decisions.

   EAP-IKEv2 therefore provides

   a) a well-known IKEv2 symmetric/asymmetric authentication and
   b) a new EAP tunneling method.

2. Terminology

   This document does not introduce new terms other than those defined
   in [1] or in [2].

   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 [10].

3. Protocol overview

   This section provides some overview over EAP-IKEv2 message
   exchanges. Note that some payloads are omitted (such as SAi2 and
   SAr2 ) which are mandatory for IKEv2 but are not required in EAP-
   IKEv2 since they are used to establish an IPsec SA.

   IKEv2 uses the same protocol message exchanges for both symmetric
   and asymmetric authentication. The difference lies only in the
   computation of the AUTH payload. See Section 2.15 of [2] for more
   information about the details of the AUTH payload computation. It is
   even possible to combine symmetric (e.g. from the client to the
   server) with asymmetric authentication (e.g. from the server to the
   client) in a single protocol exchange. Additionally, for symmetric
   authentication no CERT and CERTREQ payloads are required. Figure 1
   depicts such a protocol exchange.

   Message exchanges are reused from [2], and are adapted. Since this
   document does not describe frameworks or particular architectures
   the message exchange takes place between two parties - between the
   Initiator (I) and the Responder (R). In context of EAP the Initiator
   is often called Authenticating Peer whereas the Responder is
   referred as Authenticator.

   The first message flow shows EAP-IKEv2 without the optional DoS
   protection exchanges. The DoS protection mechanism prevents the
   responder from allocating state and performing heavy cryptographic
   operations based on the first incoming message. The core EAP-IKEv2
   exchange (message (4) - (7)) consists of four messages (two round



Tschofenig, Kroselberg   Expires - December 2003              [Page 3]

                              EAP IKEv2                     June 2003


   trips)_only. The first two messages constitute the standard EAP
   identity exchange and are not mandatory if the EAP server is known.

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

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

   3) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start)

   4) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)

   5) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
            HDR(A,B), SAr1, KEr, Nr, [CERTREQ])

   6) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
            HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH})

   7) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
            HDR(A,B), SK {IDr, [CERT,] AUTH})

   8) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(Finish)

   9) I <-- R: EAP-Success

                     Figure 1: EAP-IKEv2 message flow



   The subsequent message flow shows EAP-IKEv2 with DoS protection
   enabled. The IKEv2 DoS protection mechanism uses cookies and keeps
   the responder stateless when it receives the first IKEv2 message. As
   a consequence of DoS protection an additional round trip (message
   (5) and (6)) is required.

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

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

   3) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start)

   4) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni)

   5) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
            HDR(A,0), N(COOKIE-REQUIRED), N(COOKIE))

   6) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
            HDR(A,0), N(COOKIE), SAi1, KEi, Ni)

   7) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(


Tschofenig, Kroselberg   Expires - December 2003              [Page 4]

                              EAP IKEv2                     June 2003


            HDR(A,B), SAr1, KEr, Nr, [CERTREQ])

   8) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
            HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH})

   9) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
            HDR(A,B), SK {IDr, [CERT,] AUTH})

   10) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(Finish)

   11) I <-- R: EAP-Success

                     Figure 2: EAP-IKEv2 with Cookies

   The Secure Legacy Authentication (SLA) EAP message exchange shown in
   Figure 3 is taken from Section 2.16 of [2] and adapted. It provides
   an example of a successful inner EAP exchange using the EAP-SIM
   Authentication method [8], which is secured by the IKE-SA.

   Implementations MUST ensure that infinite recursions of EAP and EAP-
   IKEv2 exchanges are not allowed. (TBD: some limit necessary)

   I <-- R: EAP-Request/Identity

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

   I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start)

   I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
            HDR, SAi1, KEi, Ni)

   I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(
            HDR, SAr1, KEr, Nr, [CERTREQ])

   I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
            HDR, SK {IDi, [CERTREQ,] [IDr,]})

   I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(HDR,
            SK {EAP(EAP- Request/SIM/Start(AT_VERSION_LIST)),[AUTH]})

   I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {EAP(EAP-
   Response/SIM/Start(AT_NONCE_MT, AT_SELECTED_VERSION)), [AUTH]})

   I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {EAP(EAP-
   Request/SIM/Challenge(AT_RAND, AT_MAC)), [AUTH]})

   I --> R: EAP-Response/EAP-Type=EAP-IKEv2(
            HDR, SK {EAP(EAP-Response/SIM/Challenge(AT_MAC) ), [AUTH]})



Tschofenig, Kroselberg   Expires - December 2003              [Page 5]

                              EAP IKEv2                     June 2003



   I <-- R: EAP-Success

            Figure 3: EAP-IKEv2 SLA with EAP-SIM Authentication

   Please note that the message flow in Figure 3 does not include an
   EAP-Request/Identity and the corresponding EAP-Response/Identity
   message inside the EAP-IKEv2 tunnel. Although it would be possible
   to perform such an exchange IKEv2 suggests using the IDi payload for
   this purpose. As a consequence the initiators identity is not
   protected against active attacks.

   Since the goal of this EAP method is not to establish an IPsec SA
   some payloads used in IKEv2 are omitted. In particularly the
   following messages and payloads are not required:

   - Traffic Selectors
   - IPsec SA negotiation payloads
     (e.g. CREATE_CHILD_SA exchange or SAx2 payloads)
   - ECN Notification
   - Port handling
   - NAT traversal


   Rekeying of IKE-SAs might be required but requires further study.

   Some of these messages and payloads are optional in IKEv2.
   In general it does not make sense to directly negotiate IPsec SAs
   with EAP-IKEv2, as such SAs were unlikely to be used between the EAP
   endpoints.

   IKEv2 also provides functionality for the initiator to request
   address information from the responder as described in Section 2.19
   of [2]. Using this functionality it is possible for an end host to
   securely request address configuration information from the local
   network.

4. Identities used in EAP-IKEv2

   A number of identities are used in IKEv2 and particularly when EAP
   is used. This section describes their function within the different
   exchanges. Note that EAP-IKEv2 does not introduce more identities
   than any other tunneling approach. Figure 4 shows which identities
   are used during the individual phases of the protocol.

    +-------+       +-------------+   +---------+     +--------+
    |Client |       |Front-End    |   |Local AAA|     |Home AAA|
    |       |       |Authenticator|   |Server   |     |Server  |
    +-------+       +-------------+   +---------+     +--------+


Tschofenig, Kroselberg   Expires - December 2003              [Page 6]

                              EAP IKEv2                     June 2003



          EAP/Identity-Request
        <---------------------
    (a)   EAP/Identity-Response
        ---------------------------------->

           Tunnel-Establishment
    (b)    (Identities of IKEv2 are used)
           Server (Network) Authentication
        <----------------------------------
                      ...
        ---------------------------------->

        +---------------------------------+
        |      Secure Tunnel              |
        +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+
        |  Secure Legacy Authentication   |
        |  protected with the IKE-SA      |
    (c) |  (Identities of the tunneled    |
        |  EAP method are used)           |
        |  Client Authentication          |
        |---------------------------------+---------------->
        |<--------------------------------+-----------------
        +---------------------------------+

                  Figure 4: Identities used in EAP-IKEv2

   a) The first part of the (outer) EAP message exchange provides
   information about the identities of the EAP endpoints. This message
   exchange mainly is an identity request/response. This exchange is
   optional if the EAP server is known already or can be learned by
   other means.

   b) The identities used within EAP-IKEv2 for both the initiator and
   the responder. The initiator identity is often associated with a
   user identity such as a fully-qualified RFC 822 email address. The
   identity of the responder might be a FQDN. The identity is of
   importance for authorization.

   For secure legacy authentication an EAP message exchange is
   protected with the established IKE-SA as shown in Figure 3. This
   exchange again adds EAP identities.

   c) This inner EAP message exchange serves the purpose of client
   authentication. The two identities used thereby are the EAP identity
   (i.e. a NAI) and possibly a separate identity for the selected EAP
   method.




Tschofenig, Kroselberg   Expires - December 2003              [Page 7]

                              EAP IKEv2                     June 2003


   The large number of identities is required due to nesting of
   authentication methods and due to overloaded function of the
   identity for routing (i.e. authentication end point indication).

   Hence with this additional (nested) EAP exchange the end point of
   the EAP-IKEv2 exchange might not be the same as the end point of the
   inner EAP exchange which is protected by the IKE-SA (which in this
   case is not protected by the IKE-SA any more between the EAP-IKEv2
   endpoint and the endpoint of the inner EAP exchange, but might be
   protected by other means that are not considered in this document).

5. Packet Format

   The IKEv2 payloads, which are defined in [2], are embedded into the
   Data field of the standard EAP Request/Response packets. The Code,
   Identifier, Length and Type field is described in [1]. The Type-Data
   field carries a one byte Flags field following the IKEv2 payloads.
   Each IKEv2 payload starts with a header field HDR (see [2]).

   The packet format is shown in
   Figure 5:

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

                          Figure 5: Packet Format

   No additional packet formats other than those defined in [2] are
   required for this EAP method.

   The Flags field is required to indicate Start and Finish messages
   which are required due to the asymmetric nature of IKEv2 and the
   Request/Response message handling of EAP.

   Currently four bits of the eight bit flags field are defined. The
   remaining bits are set to zero.

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



Tschofenig, Kroselberg   Expires - December 2003              [Page 8]

                              EAP IKEv2                     June 2003


   S = EAP-IKEv2 start message
   F = EAP-IKEv2 finish message
   L = Length included
   M = More fragments

   EAP-IKEv2 messages which have neither the S nor the F flag set
   contain regular IKEv2 message payloads inside the Data field.

   With regard to fragmentation we follow the suggestions and
   descriptions given in Section 2.8 of [9]: The L indicates that a
   length field is present and the M flag indicates fragments. The L
   flag MUST be set for the first fragment and the M flag MUST be set
   on all fragments expect for the last one. Each fragment sent must
   subsequently be acknowledged.

   The Message Length field is four octets long and present only if the
   L bit is set. This field provides the total message length that is
   being fragmented.

   The EAP Type for this EAP method is <TBD>.

6. Key derivation

   The EAP-IKEv2 method described in this document generates sessions
   keys. These session keys are used to establish an IKE-SA which
   provides protection of other payloads. To export a session key as
   part of the EAP keying framework [7] it is required to derive
   another session key for usage with EAP (sometimes referred as Pre-
   Master-Secret). It is good cryptographic security practice to use
   different keys for different "applications". Hence we suggest to
   reuse the key derivation function suggested in Section 2.17 of [2]
   to export the KEYMAT (as a Pre-Master-Secret) for further key
   derivation.

   The key derivation function defined is KEYMAT = prf+(SK_d, Ni | Nr),
   where Ni and Nr are the Nonces from the IKE_SA_INIT exchange.

7. Security Considerations

   The security of the proposed EAP method is intentionally based on
   IKEv2 [2]. Man-in-the-middle attacks discovered in the context of
   tunneled authentication protocols (see [3] and [4]) are applicable
   to IKEv2 if legacy authentication with EAP [1] is used. To counter
   this threat IKEv2 provides a compound authentication by including
   the EAP provided session key inside the AUTH payload.

   Further security considerations will be provided with future
   versions of this document. An example of the security issues which
   are pending at the moment is active user identity confidentiality


Tschofenig, Kroselberg   Expires - December 2003              [Page 9]

                              EAP IKEv2                     June 2003


   for the initiator (particularly for tunneling of EAP packets
   protected by the IKE-SA).

8. Open Issues

   The following issues are still under consideration:

   - Session resumption

   TLS provides the capability of resuming a session. This offers
   primarily performance improvement for a new authentication and key
   exchange protocol run. It is for further study whether the concept
   of session resumption (i.e. a fast re-authentication procedure) is a
   useful context for EAP methods and for the AAA environment in
   particular.  If it turns out to be useful then one possible approach
   is to reuse the dead peer detection informational exchange, which is
   able to provide fast re-authentication based on the established IKE-
   SA. This exchange is cheap in terms of processing complexity and
   provides both end points the capability to perform authentication
   based on an available IKE-SA.

   - Reducing the number of messages

   The message flows given in this document finish with an EAP-Success
   message. In some cases it might be possible to skip these messages.
   Furthermore it is possible to omit the first exchange if the
   identity can be learned by other means.

   - Fragmentation

   Fragments sent must subsequently be acknowledged. Typically an empty
   EAP packet is used. This, however, adds a vulnerability to the
   protocol.

   - EAP-IKEv2 Finish Message

   It might be advisable to protect the EAP-IKEv2 finish message since
   a key is already available.

   - Rekeying

   As mentioned in Section 3 it might be useful to keep rekeying
   functionality of IKEv2.


9. References

   [1] L. Blunk and J. Vollbrecht: "PPP Extensible Authentication
   Protocol (EAP)", RFC 2284, March 1998.


Tschofenig, Kroselberg   Expires - December 2003             [Page 10]

                              EAP IKEv2                     June 2003



   [2] C. Kaufman: "Internet Key Exchange (IKEv2) Protocol", internet
   draft, Internet Engineering Task Force, 2003.  Work in progress.

   [3] N. Asokan, V. Niemi, and K. Nyberg: "Man-in-the-middle in
   tunnelled authentication", In the Proceedings of the 11th
   International Workshop on Security Protocols, Cambridge, UK, April
   2003. To be published in the Springer-Verlag LNCS series.

   [4] J. Puthenkulam, V. Lortz, A. Palekar, D. Simon, and B. Aboba,
   "The compound authentication binding problem," internet draft,
   Internet Engineering Task Force, 2003.  Work in progress.

   [5] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC
   2409, November 1998.

   [6] R. Perlman: "Understanding IKEv2: Tutorial, and rationale for
   decisions", internet draft, Internet Engineering Task Force, 2003.
   Work in progress.

   [7] B. Aboba and D. Simon: "EAP Keying Framework", internet draft,
   Internet Engineering Task Force, 2003.  Work in progress.

   [8] H. Haverinen, J. Salowey: "EAP SIM Authentication", internet
   draft, Internet Engineering Task Force, 2003.  Work in progress.

   [9] A. Palekar, D. Simon, G. Zorn and S. Josefsson: "Protected EAP
   Protocol (PEAP)", internet draft, Internet Engineering Task Force,
   March 2003.  Work in progress.

   [10]  S. Bradner: "Key words for use in RFCs to Indicate Requirement
   Levels", RFC 2119, Internet Engineering Task Force, March 1997.

Acknowledgments

   We would like to thank Jari Arkko and Paoulo Pagliusi for their
   comments to the initial version of this draft.

   Additionally we would like to thank members of the PANA design team
   (namely D. Forsberg, Y. Ohba and A. Yegin) for their comments and
   input to this draft.

Author's Addresses

   Hannes Tschofenig
   Siemens AG
   Otto-Hahn-Ring 6
   81739 Munich
   Germany


Tschofenig, Kroselberg   Expires - December 2003             [Page 11]

                              EAP IKEv2                     June 2003


   EMail: Hannes.Tschofenig@siemens.com

   Dirk Kroeselberg
   Siemens AG
   Otto-Hahn-Ring 6
   81739 Munich
   Germany
   EMail: Dirk.Kroeselberg@siemens.com

Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgement

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









Tschofenig, Kroselberg   Expires - December 2003             [Page 12]


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