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]