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", . [HIP.Servid] Heer, T., Varjonen, S., and H. Wirtz, "Service Identifiers for HIP>", . 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", . [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]