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

Versions: 00

Host Identity Protocol                                          Varjonen
Internet-Draft                        Helsinki Institute for Information
Intended status: Informational                                Technology
Expires: January 7, 2010                                    July 6, 2009


                      HIP and User Authentication
                       draft-varjonen-hip-eap-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may not be modified,
   and derivative works of it may not be created, except to format it
   for publication as an RFC or to translate it into languages other
   than English.

   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 January 7, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.






Varjonen                 Expires January 7, 2010                [Page 1]


Internet-Draft                   HIP EAP                       July 2009


Abstract

   This document specifies how to use Extensible Authentication Protocol
   (EAP) in HIP to incorporate user authentication in the IPsec tunnel
   creation.  This document describes two new parameters for
   transporting EAP messages inside HIP control packets.  The main focus
   of this document is to describe how to use these parameters to
   combine needed EAP negotiation in order to authenticate the user.
   This document also describes how on-path middleboxes can take part in
   the negotiation as authenticators.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].



































Varjonen                 Expires January 7, 2010                [Page 2]


Internet-Draft                   HIP EAP                       July 2009


Table of Contents

   1.  Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   3.  EAP Parameters . . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  EAP_SIGNED parameter . . . . . . . . . . . . . . . . . . .  6
     3.2.  EAP_UNSIGNED parameter . . . . . . . . . . . . . . . . . .  6

   4.  EAP Parameters and End-Hosts . . . . . . . . . . . . . . . . .  6

   5.  EAP and on-path middleboxes  . . . . . . . . . . . . . . . . .  9

   6.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 12

   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12

   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12

   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12

   10. Normative References . . . . . . . . . . . . . . . . . . . . . 12

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13


























Varjonen                 Expires January 7, 2010                [Page 3]


Internet-Draft                   HIP EAP                       July 2009


1.  Glossary

   Terminology and notation used in this document is in most parts
   borrowed from [RFC3748].

      AUTHENTICATOR: Is the entity that initiates the authentication.
      In HIP the authenticator is equivalent to responder but in mutual
      authentication, where both communicating parties are
      authenticated, the supplicant can also be the responder.

      SUPPLICANT: The end of the link that responds to the authenticator
      in [IEEE-802.1X].  In HIP a supplicant maps to the initiator but
      in mutual authentication, where both communicating parties are
      authenticated, supplicant can also be the responder.

      BACKEND AUTHENTICATION SERVER: A backend authentication server is
      an entity that provides an authentication service to an
      authenticator.  When used, this server typically executes EAP
      methods for the authenticator.

      EAP SERVER: The entity that terminates the EAP authentication
      method with the peer.  In the case where no backend authentication
      server is used, the EAP server is part of the authenticator.  In
      the case where the authenticator operates in pass-through mode,
      the EAP server is located on the backend authentication server.


2.  Introduction

   Host Identity Protocol (HIP) [RFC4423] offers a cryptographic
   namespace and a way to negotiate creation of Security Association
   (SA) between two hosts.  By default, SAs are created by contacting
   the Responder.  With HIP firewalls, administrators can achieve access
   control on the connection attempts.  In some cases access control
   based only on HITs is not enough.  Organizations can have mobile
   employees that need access to the organizations network from outside
   the network.  HIP can be used to authenticate the host, but by
   default, anyone possessing the host and its keys can create a HIP
   association.  By introducing Extensible Authentication Protocol (EAP,
   [RFC3748], [RFC5247]) to HIP, we can extend the authentication of the
   host to include the authentication of the user.

   The extensible Authentication Protocol (EAP) is a universal
   authentication framework for point-to-point connections and it has
   been adapted to work with [IEEE-802.1X].  EAP can also be used in
   other environments and is not specific to wireless applications.  In
   practice the supplicant triggers the authenticator to start the
   authentication towards the supplicant and the authentication method



Varjonen                 Expires January 7, 2010                [Page 4]


Internet-Draft                   HIP EAP                       July 2009


   is run on the EAP server.  It should be noted that the authentication
   server can be located at the authenticator.  Authenticators can
   degrade or restrict service such as bandwidth limitation up to
   refusing connections and reporting access violations when
   authenticator does not successfully authenticate peer.  EAP itself is
   a framework and does not provide any specific authentication method
   but it can be extended, hence the name.  In this document, as an
   example, we use extension that provides password only authentication
   [EAP.Pwd] and the challenge-response exchanges from [RFC3748].

   In the following illustration, we depict the message flow of EAP
   between the supplicant, authenticator and the backend authentication
   server.


     Supplicant                   Authenticator           Backend
     |                                 |                  Authentication
     |                                 |                  Server       |
     | -- Start ---------------------> |                               |
     | <- Request identity ----------- |                               |
     | -- Response identity ---------> | -- Response identity -------> |
     |                                 | <- Request 1 ---------------- |
     | <- Request 1 ------------------ |                               |
     | -- Response 1 ----------------> |                               |
     |                                 | -- Response 1 --------------> |
     |    .                            |    .                          |
     |    .                            |    .                          |
     |    .                            |    .                          |
     |                                 | <- Request n ---------------- |
     | <- Request n ------------------ |                               |
     | -- Response n ----------------> |                               |
     |                                 | -- Response n---------------> |
     |                                 | <- Success ------------------ |
     | <- Success -------------------- |                               |
     |                                 |                               |


3.  EAP Parameters

   This section defines two parameters to be used when using EAP with
   HIP.  EAP_SIGNED and EAP_UNSIGNED parameters carry EAP messages
   between HIP end-hosts and middleboxes.  EAP_SIGNED and EAP_UNSIGNED
   parameters are non-critical parameters and they contain EAP header
   defined in [RFC3748] in section 4. and EAP request, EAP response, EAP
   success or EAP failure, which are used as described in [RFC3748] in
   section 4.1.  These parameters can be used in R1, I2, R2 and UPDATE
   control packets.




Varjonen                 Expires January 7, 2010                [Page 5]


Internet-Draft                   HIP EAP                       July 2009


3.1.  EAP_SIGNED parameter


     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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     EAP (Variable length)                     /
     /                                               +-+-+-+-+-+-+-+-+
     /                                               |    Padding    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Type          TBD-IANA (998)
     Length        Length in octets, excluding Type, Length, and Padding
     EAP           EAP message, variable length.
     Padding       Any Padding, if necessary, to make the parameter a
                   multiple of 8 bytes as defined in [RFC5201] in
                   section 5.2.1.


3.2.  EAP_UNSIGNED parameter

   On-path middleboxes append this parameter to the control packets.
   Also authenticators that preserve the R1 pre-creation must use this
   parameter (as discussed in next section).  This parameter is
   identical with EAP_SIGNED parameter differing only by its type number
   (TBD-IANA (632997)).


4.  EAP Parameters and End-Hosts

   This section defines how end-hosts should behave when EAP related
   parameters are present in HIP control packets.  In the following we
   present the simplest case of EAP usage with challenge-response
   exchange.  Only relevant parameters are depicted, see [RFC3748]
   section 5 for more details.














Varjonen                 Expires January 7, 2010                [Page 6]


Internet-Draft                   HIP EAP                       July 2009


       Initiator                                   Responder

                   I1
                  -------------------------------->
                                                   Select precomputed R1
                   R1: puzzle,
                       key, sig, SERVICE_OFFER,
                       EAP_UNSIGNED(challenge)
                  <--------------------------------
    Check sig                                      Remain stateless
    Solve puzzle
    Calculate response
                   I2: solution,
                       EAP_SIGNED(response),
                       SERVICE_ACK, {key}, sig
                  -------------------------------->
    Compute D-H                                    Check solution
                                                   Check sig
                                                   Check response
                   R2: EAP_SIGNED(success), sig
                  <-------------------------------
    Check sig                                      Calculate session key
                                                   Change traffic
                                                   restrictions
                   ESP
                  <------------------------------>


                                 Figure 1

   A HIP Responder pre-creates R1s in order to minimize the expensive
   cryptographic operations until Responder has established state.
   Using EAP parameter will prevent this.  In order to use pre-created
   R1s, a Responder can append the EAP_M parameter into the unsigned
   part of the message.

   EAP messages may be so large that if included into the R1, I2 or R2
   control packets, they would exceed the allowed parameter section size
   or the minimum MTU of the used link.  EAP negotiation may be longer
   than two messages and hence could not be piggybacked in BEX packets.
   Due to these reasons EAP negotiation may be run after BEX using
   UPDATE control packets.  In practice this means that while the HIP
   association is created while BEX its in "unauthorized" state in which
   the usage of the association is limited until the authentication is
   approved

   In the following, we present a BEX continued with EAP-based password
   only authentication [EAP.Pwd] using EAP parameter in UPDATE control



Varjonen                 Expires January 7, 2010                [Page 7]


Internet-Draft                   HIP EAP                       July 2009


   packets.  Only relevant parameters are depicted.


       Initiator                                   Responder
       (EAP peer)                                  (EAP server)
                   I1
                  -------------------------------->
                                                   Select precomputed R1
                   R1: puzzle, SERVICE_OFFER,
                       key, sig
                  <--------------------------------
    Check sig                                      Remain stateless
    Solve puzzles
                   I2: solution, SERVICE_ACK,
                       {key}, sig
                  -------------------------------->
    Compute D-H                                    Check solution
                                                   Check sig
                   R2: sig,
                       EAP_SIGNED(pwd-ID/Request)
                  <-------------------------------
    Check sig                                      Calculate session key
                   UPDATE:
                     EAP_SIGNED(pwd-ID/Response)
                  ------------------------------->
                   UPDATE:
                     EAP_SIGNED(pwd-Commit/Request)
                  <-------------------------------
                   UPDATE:
                     EAP_SIGNED(pwd-Commit/Response)
                  ------------------------------->
                   UPDATE:
                     EAP_SIGNED(pwd-Confirm/Request)
                  <-------------------------------
                   UPDATE:
                     EAP_SIGNED(pwd-Confirm/Response)
                  ------------------------------->
                   UPDATE: EAP_SIGNED(Success)
                  <-------------------------------
                                                   Change traffic
                                                   restrictions
                   ESP
                  <------------------------------>


   Responder announces service requiring authentication and the method
   of authentication using the SERVICE_OFFER parameter (defined in
   [HIP.Servid]) in R1 control packet.  Initiator notifies the responder



Varjonen                 Expires January 7, 2010                [Page 8]


Internet-Draft                   HIP EAP                       July 2009


   about the agreement with SERVICE_ACK parameter defined in
   [HIP.Servid].  Responder can use SP field of SERVICE_OFFER parameter
   to announce the characteristics of the service.  For example
   (depicted in the following), the service requires authentication
   (REQ), the service is commercial (COM) forwarding service (FOR) and
   that EAP [RFC3748] is used (bit 9, TBD-IANA).


         0                                       1
         0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
     0 | 1   1   1   0   0   0   0   0   0   1   0   0   0   0   0   0 |
     1 | 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0 |
       +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   The actual service is identified in the SID field of SERVICE_OFFER
   parameter.  SD field of the SERVICE_OFFER parameter contains needed
   information on the service itself and specifies which authentication
   method should be used (in the above example [EAP.Pwd] is used).  If
   the initiator accepts the terms laid out in the SERVICE_OFFER it
   answers with a SERVICE_ACK parameter.  In practice, this exchange
   acts as an early warning for the peer that the connection will be
   throttled or otherwise restricted and that the supplicant must
   authenticate itself in order to access the service.

   Finally the authenticator (here Responder) completes the negotiation
   with EAP success message, contained in EAP parameter, to successful
   authentication and to failure with EAP failure message contained in
   EAP parameter (as defined in [RFC3748].


5.  EAP and on-path middleboxes

   In the following, we depict the situation where a on-path middlebox
   needs to authenticate the user using simple challenge-response
   exchange.  The middlebox appends its parameters to the BEX packets
   traversing through it.  Only relevant parameters are depicted.














Varjonen                 Expires January 7, 2010                [Page 9]


Internet-Draft                   HIP EAP                       July 2009


    Initiator              Middlebox                        Responder
                          .---------------------.
     I1,                  |                     |  I1,
    --------------------> |                     | --------------------->
                          |                     |
     R1, EAP_UNSIGNED(*), | Add EAP_UNSIGNED(*) |  R1
         SERVICE_OFFER    | and SERVICE_OFFER   |
    <-------------------- |                     | <---------------------
                          |                     |
     I2, EAP_SIGNED(**),  | Verify response     |  I2, EAP_SIGNED(**),
         SERVICE_ACK      |                     |      SERVICE_ACK
    --------------------> |                     | --------------------->
                          | Change traffic      |
                          | restrictions        |
     R2,                  |                     |
      EAP_SIGNED(success) | Add response        |  R2
    <-------------------- |                     | <---------------------
                          '---------------------'
    * = Challenge
    ** = Response

   In the following we present a BEX continued with EAP authentication
   with only a password [EAP.Pwd] traversing through a middlebox (Only
   relevant parameters are depicted).



























Varjonen                 Expires January 7, 2010               [Page 10]


Internet-Draft                   HIP EAP                       July 2009


    Initiator              Middlebox                           Responder
                           .--------------------.
     I1,                   |                    |  I1,
    ---------------------> |                    | --------------------->
                           |                    |
     R1, SERVICE_OFFER     | Add SERVICE_OFFER  |  R1
    <--------------------- |                    | <---------------------
                           |                    |
     I2, SERVICE_ACK       | Verify response    |  I2, SERVICE_ACK
    ---------------------> | Let I2 through     | --------------------->
                           |                    |
     R2,                   | Add                |
      EAP_US(pwd-ID/*)     | EAP_US(pwd-ID/*)   |  R2
    <--------------------- |                    | <---------------------
     UPD,                  |                    |  UPD,
     EAP_S(pwd-ID/**), SEQ |                    | EAP_S(pwd-ID/**), SEQ
    ---------------------> |                    | --------------------->
     UPD, ACK,             | Add pwd-Commit/*   |
     EAP_US(pwd-Commit/*)  |                    |  UPD, ACK
    <--------------------- |                    | <---------------------
     UPD, SEQ,             |                    |  UPD, SEQ,
     EAP(pwd-Commit/**)    |                    |  EAP_S(pwd-Commit(**)
    ---------------------> |                    | --------------------->
     UPD, ACK,             |                    |
     EAP_US(pwd-Confirm/*) | Add pwd-Confirm/*  |  UPD, ACK
    <--------------------- |                    | <---------------------
     UPD, SEQ,             |                    |  UPD, SEQ,
     EAP_S(pwd-Confirm/**) |                    |  EAP_S(pwd-Confirm/**)
    ---------------------> |                    | --------------------->
                           | Change traffic     |
                           | restrictions       |
     UPD, ACK,             |                    |
     EAP_US(success)       | Add EAP response   |  UPD, ACK
    <--------------------- |                    | <---------------------
                           '--------------------'
    * = Challenge
    ** = Response
    EAP_S = EAP_SIGNED
    EAP_US = EAP_UNSIGNED

   When the authentication is run after the BEX and the the
   authenticator is the middlebox, them Initiator must add SEQ parameter
   to the UPDATE control packets in order to request the Responder to
   respond with an ACK parameter.

   With multiple middleboxes the SERVICE_OFFER parameters SD field will
   differentiates different middleboxes associated with the same
   service.  Otherwise the SID field will be unique (assigned by IANA,



Varjonen                 Expires January 7, 2010               [Page 11]


Internet-Draft                   HIP EAP                       July 2009


   see [HIP.Servid]).


6.  Discussion

   Most of the devices (phones, PDAs, laptops) are operated by single
   user hence the main approach described in this document is
   applicable.  Problems arise with multi-user clients.  For example,
   let's consider a case where machine A has users Aa and Ab.  When Aa
   connects to server B, he creates a tunnel between the HITs of A and
   B. The problem in this, related to the EAP, is that now user Ab can
   also communicate using the same tunnel.  At least two possible
   solutions exist.  First, usage of Simultaneous Multi-Access extension
   [HIP.Sima], because it allows HIP to use flow binding to identify and
   separate multiple ongoing upper layer data flows.  Second, Local
   access control measures, that restrict the use of HITs per UID.


7.  IANA Considerations

   This document defines the EAP related parameters for the Host
   Identity Protocol [RFC5201].  These parameter are defined in
   Section 3.


8.  Security Considerations

   Same security considerations apply as for EAP [RFC3748]

   As an additional measure of protection participants can encapsulate
   the EAP parameters inside ENCRYPTED parameter defined in [RFC5201]


9.  Acknowledgements

   The authors would like to thank M. Komu and T. Heer of fruitful
   conversations on the subject.


10.  Normative References

   [EAP.Pwd]  Harkins, D. and G. Zorn, "EAP Authentication Using Only A
              Password", <draft-harkins-emu-eap-pwd-03>.

   [HIP.Servid]
              Heer, T., Varjonen, S., and H. Wirtz, "Service Identifiers
              for HIP>", <draft-heer-hip-service-00>.




Varjonen                 Expires January 7, 2010               [Page 12]


Internet-Draft                   HIP EAP                       July 2009


   [HIP.Sima]
              Pierrel, S., Jokela, P., and J. Melen, "Simultaneous
              Multi-Access extension to the Host Identity Protocol",
              <draft-pierrel-hip-sima-00>.

   [IEEE-802.1X]
              Institute of Electrical and Electronics Engineers, "Local
              and Metropolitan Area Networks: Port-Based Network Access
              Control", IEEE Standard 802.1X, Sep 2001.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", RFC 5201, April 2008.

   [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",
              RFC 5247, August 2008.


Author's Address

   Samu Varjonen
   Helsinki Institute for Information Technology
   Metsnneidonkuja 4
   Helsinki
   Finland

   Fax:   +35896949768
   Email: samu.varjonen@hiit.fi
   URI:   http://www.hiit.fi












Varjonen                 Expires January 7, 2010               [Page 13]


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