Internet DRAFT - draft-grayson-eap-authorisation
draft-grayson-eap-authorisation
Network Working Group
INTERNET DRAFT M. Grayson
draft-grayson-eap-authorisation-01.txt J. Salowey
Expires: September 2003 Cisco Systems
March 2003
EAP Authorization
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Distribution of this memo
is unlimited.
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 1of 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.
Abstract
This document specifies an Extensible Authentication Protocol (EAP)
mechanism for authorization information exchange. EAP TLV is a
container type for EAP messages. This mechanism describes an EAP TLV
for exchange of authorization related information which can take
place within the EAP framework. It allows an authentic user to
provide the network with additional information in order to
determine which Internet Service is being requested. It also allows
an EAP server to request authorization for session parameters from
an EAP peer. This mechanism may be chained after any EAP-
Authentication mechanism.
Grayson and Salowey Expires in six months [Page 1]
Internet Draft EAP Authorization March 2003
Table of Contents
Status of this Memo.........................................1
Abstract....................................................1
Table of Contents...........................................2
1. Introduction.............................................2
2. Terms....................................................3
3. Overview.................................................4
3.1. Providing Additional Information.......................5
3.2. Mandatory Tunnel Example...............................5
3.3. Billing Rate Authorization.............................6
4. Message Format...........................................6
4.1. EAP-TLV/Authorization-Request..........................6
4.2. EAP-TLV/Authorization-Response.........................7
4.3. Authorization Attribute Format.........................8
4.4. Protected TLV..........................................8
5. Defined attributes.......................................8
5.1. Status.................................................8
5.2. Authorization Identity.................................9
5.3. Quality of Service....................................10
5.4. Billing Rate..........................................10
5.5. Terms and Conditions..................................10
5.6. Service Type..........................................10
5.7. Tunnel FQDN...........................................10
5.8. Tunnel Password.......................................11
6. Protection of EAP-TLV/Authorization.....................12
IANA Considerations........................................12
Security Considerations....................................12
Intellectual Property Right Notice.........................12
Acknowledgements and Contributions.........................12
References.................................................12
Editor's Address...........................................13
1. Introduction
The Extensible Authentication Protocol (EAP), described in [2],
provides a standard mechanism for support of multiple authentication
methods. Through the use of EAP, support for a number of
authentication schemes may be added, including GSM smart card
support, one time password and others.
The encapsulation of EAP has been defined over IEEE 802 link layers
in IEEE 802.1X [3]. In 802.1X, an authentication failure will result
in denied access to the controlled port. Conversely, an
authenticated peer will be allowed access.
This document specifies an extension to EAP using TLV encapsulation
for authorization exchange which may be used to authorize additional
resources for the peer, e.g., above access to the controlled port
defined in 802.1X. In particular, this document describes techniques
for the definition and authorization of tunnel resources in a manner
which is secure, independent of the selected authentication method
and compatible with existing AAA based configuration, e.g., for
Grayson and Salowey September 2003 [Page 2]
Internet Draft EAP Authorization March 2003
configuring compulsory network based tunnels [4]. The authorization
TLV provides a way for the EAP server to request the EAP Peer to
authorize certain session attributes such as quality of service or
charging options.
This method relies upon a security association to provide message
protection established using PEAP [1] or Protected TLV [9]. This
approach provides a consistent authorization interfaces for various
access systems and allows the authorization to be decoupled from a
specific authentication method.
2. Terms
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 [5].
This document frequently uses the following terms and abbreviations:
AAA protocol
Authentication, Authorization and Accounting protocol
Authentication service
The Authentication Service verifies, from the credentials
supplied by the peer, the claim of identity made by the peer.
Authorization Service
The Authorization Service verifies the service requested by the
peer is valid. Optionally, the Authorization Service may be
involved in configuring the authorized service on behalf of the
peer.
EAP
Extensible Authentication Protocol.
EAP Server
The network element that terminates the EAP protocol. Typically,
the EAP server functionality is implemented in a AAA server. In
this document, the AAA server provides both Authentication and
Authorization service.
NAI
Network Access Identifier
PEAP
Grayson and Salowey September 2003 [Page 3]
Internet Draft EAP Authorization March 2003
Protected EAP
EAP Peer
A peer is an entity that is being authenticated by an
Authenticator. Once authenticity is validated the peer can be
allowed access to authorized resources.
TLV
A TLV is an attribute formatted as type, length and value.
3. Overview
Whilst established EAP methods define exchanges for providing an
Authentication Service for a peer, EAP-TLV/Authorization exchanges
define procedures for providing an Authorization Service. EAP-
TLV/Authorization uses a minimum of a single roundtrip to exchange
additional authorization information between the EAP peer and
server. The peer may be requested to authorize certain session
attributes such as quality of service or billing rate and the server
may be request to provide various services to the client.
The EAP Authorization phase must be chained after an EAP
Authentication mechanism has completed and a key is available for
protecting the confidentiality and authenticity of the authorization
exchange. The protection of the exchange may be provided by a
tunneling mechanism such as PEAP [1] or by Protected TLVs described
in [9].
After authentication is complete and keys are established the server
sends a request of type EAP-TLV/Request-Authorization. The request
may contain attributes that the EAP-Server requests the client to
authorize. If the request does not contain any attributes it
indicates that the server is willing to accept an authorization
request from the client.
The peer responds with an EAP-TLV/Response-Authorization packet
including zero or more EAP-Authorization attributes which the peer
provides to the network in order to define service parameters which
are to be authorized. The EAP-TLV/Response-Authorization message
MUST contain a status attribute indicating the result of any
authorization carried out as a result of the EAP-TLV/Request-
Authorization Packet.
After receiving the EAP-TLV/Authorization-Request or EAP-
TLV/Response-Authorization packet, the EAP sever or EAP Peer can
confirm which services and attribute are being requested and perform
authorization checks. Authorization checks may involve third parties
for which the peer may use an identification distinct from that
which was previously used for port based authentication. The
Grayson and Salowey September 2003 [Page 4]
Internet Draft EAP Authorization March 2003
Authorization Identity attribute provides the capability to carry
additional identification information.
The server may indicate authorization failure with a Authorization-
Status attribute in the Request-Authorization message or it may
indicate failure with an EAP-Failure message. An EAP-Failure
message will terminate the EAP conversation. Since the EAP-failure
message does not include the option to transport a Displayable
Message, the EAP server can use an EAP-Notification message to
provide the supplicant with additional information, e.g., if service
authorization fails.
3.1. Providing Additional Information
The specific information related to authorization will depend upon
the authorized resources being requested. The EAP-Authorization
methods are extensible to allow new authorization information to be
defined. The document describes the minimum supported attributes for
the mandatory tunnel service includes authorization identifier,
tunnel password and tunnel endpoint description. Additional
attributes may be defined to represent quality of service or billing
rate.
These are just two examples of how EAP Authorization may be used,
there are many other possibilities.
3.2. Mandatory Tunnel Example
In the mandatory tunnel example the client is requesting that a
secure tunnel be established from within the local network to which
the client is connected to a home network. A pre-arranged
relationship is established between the local network and the home
network to allow for this. The authentication is proxied by the
local network to the home network using AAA techniques.
After the user has successfully completed an EAP authentication
method such as EAP-MD5 within PEAP the authenticator sends an EAP-
TLV/Authorization-Request message to see if the client wishes to
request additional services. The client then responds with an EAP-
TLV/Authorization-Response message containing the following
attributes:
Status
Authorisation Identity
Service Type
Tunnel FQDN
Tunnel Password
The authenticator then verifies that the authenticated user is
allowed to use the authorisation identity and service defined by the
service type and tunnel FQDN. It may also verify the tunnel
password. The authenticator then saves these parameters to be
Grayson and Salowey September 2003 [Page 5]
Internet Draft EAP Authorization March 2003
passed back to the local network using AAA, e.g., using RADIUS
attributes in the Access-Accept defined in RFC 2868. It is possible
that the authenticator may return different attributes to the local
network based on its policy (for example it may return a different
tunnel password). The local network then establishes a tunnel back
to the home network according to the parameters in the access
accept. The tunnel endpoint in the home network authenticates the
local endpoint using the username (authorization identity) and
password passed back in the access accept.
3.3. Billing Rate Authorization
If the peer is receiving service that it will be charged for the
EAP-Server may request authorization for those charges. In this case
the EAP-Server sends an EAP/Request-Authorization message with a
Billing Rate attribute. The request message may contain attributes
that ask for additional information for the peer.
4. Message Format
The authorization message consists of a series of attributes. The
collection of all attributes MUST be protected with PEAP and/or
protected TLV as in [11]. The following attributes are defined by
this document.
4.1. EAP-TLV/Authorization-Request
The EA-TLV/Authorization-Request message is used by a peer or server
to request authorization of certain services or session attributes.
It has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
0 - Non-mandatory TLV
1 - Mandatory TLV
R
Reserved, set to zero (0)
Grayson and Salowey September 2003 [Page 6]
Internet Draft EAP Authorization March 2003
Type
TBD TLV-Authorization-Request
Length
The length of the Value field in octets.
Value
One or more authorization attributes
4.2. EAP-TLV/Authorization-Response
The EAP-TLV/Authorization-Response message is used by an EAP Server
to request additional information from the peer related to certain
services authorization requests. It has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
0 - Non-mandatory TLV
1 - Mandatory TLV
R
Reserved, set to zero (0)
Type
TBD TLV-Authorization-Response
Length
The length of the Value field in octets.
Value
Status attribute and request for additional information from
the server.
Grayson and Salowey September 2003 [Page 7]
Internet Draft EAP Authorization March 2003
4.3. Authorization Attribute Format
Each authorization attribute has the following format:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
Type of authorization attribute
Length
Length of value. The combine length of all the attributes MUST
NOT exceed 2^16.
Value
Value of attribute.
4.4. Protected TLV
The protected TLV is described in the protected TLV draft [9].
5. Defined attributes
5.1. Status
The Status attribute is used to indicate the status of any
outstanding authorization requests. It MUST be present in an EAP-
TLV/Response-Authorization message.
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 = Status | Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
Grayson and Salowey September 2003 [Page 8]
Internet Draft EAP Authorization March 2003
TBD Authorization-Status
Length
Length of value
Status Code
Result of the outstanding authorization indicated by the
following values.
STATUS_PASS = 0
STATUS_FAIL = 1
STATUS_PENDING = 2
A value of STATUS_PASS indicates that all authorization
requests passed. A value of STATUS_FAIL indicated that at least
one authorization request failed. A value of STATUS_PENDING
indicates that additional information is being requested. It
STATUS_PENDING is returned the message MUST contain additional
attributes indicating the information being requested.
5.2. Authorization Identity
This represents an alternate identity for the authenticated
principal. It may be a username on a specific system, a group name
that the user belongs to, or a proxy name. The authorizing service
SHOULD validate that the authenticated identity can use the
authorization identity.
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 = AZN Identity | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Value .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD Authorization-Identity
Length
Length of value
Value
Grayson and Salowey September 2003 [Page 9]
Internet Draft EAP Authorization March 2003
String representation of the authorization identity
5.3. Quality of Service
<TBD>
5.4. Billing Rate
<TBD>
5.5. Terms and Conditions
<TBD>
5.6. Service Type
This attribute contains the type of service being requested.
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 = Service type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Value .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
TBD Service-Type
Length
Length of value
Value
This is a string representation of the service types. This
document defines the following service types:
None
Mandatory Tunnel
5.7. Tunnel FQDN
This attribute refers to the Mandatory Tunnel service.
Grayson and Salowey September 2003 [Page 10]
Internet Draft EAP Authorization March 2003
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 = Tunnel FQDN | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Value .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
Tunnel FQDN = 0x0101
Length
Length of Tunnel FQDN string
Value
A string corresponding to the FQDN identifying the tunnel
endpoint and can be used by the Authorization Service to
determine which resources require authorization, and possible
configuration.
5.8. Tunnel Password
This attribute refers to the mandatory tunnel service.
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 = Tunnel Password | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Value .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
Tunnel Client Password = 0xC023
Grayson and Salowey September 2003 [Page 11]
Internet Draft EAP Authorization March 2003
Length
Length of packet format
Value
Tunnel password
6. Protection of EAP-TLV/Authorization
The EAP-TLV/Authorization mechanism MUST be protected. The
recommended way to achieve this is to run within a protected EAP
mechanism such as PEAP or Protected TLV.
IANA Considerations
Since multi-vendor interoperability is desired, an EAP Authorization
Type number is required to be allocated by IANA.
Security Considerations
The authorization exchange MUST be protected either by an external
mechanism such as PEAP or by using protected TLVs. The endpoints
must be careful to authenticate each other before requiring
authorization. These mechanisms SHOULD only be used when mutual
authentication is in place.
Intellectual Property Right Notice
Acknowledgements and Contributions
References
[1] H. Andersson, F. Josefsson, G. Zorn, D. Simon, A. Palekar,
"Protected EAP Protocol (PEAP)", draft-josefsson-pppext-eap-tls-eap-
05.txt, September 2002 (work in progress)
[2] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication Protocol
(EAP)", RFC 2284, March 1998
[3] IEEE Standards for Local and Metropolitan Area Networks: Port
based Network Access Control, IEE Std 802.1X-2001, June 2001
Grayson and Salowey September 2003 [Page 12]
Internet Draft EAP Authorization March 2003
[4] G. Zorn, "RADIUS Attributed for Tunnel Protocol Support", RFC
2868, June 2000
[5] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Level", RFC 2119, March 1997
[6] H. Haverinen, J. Salowey, "EAP SIM Authentication", draft-
haverinen-pppext-eap-sim-10.txt, February 2003 (work in progress)
[7] B. Aboba, M. Beadles, "The Network Access Identifier", RFC 2486,
January 1999
[8] Hiller, Palekar, and Zorn "A Container Type for the Extensible
Authentication Protocol (EAP)", http://www.ietf.org/internet-
drafts/draft-hiller-eap-tlv-00.txt, October 2002 (work in progress)
[9] J. Salowey, "Protected EAP TLV", draft-salowey-eap-protectedtlv-
01.txt, March 2003 (work in progress)
Editor's Address
Joseph Salowey
Cisco Systems
2901 Third Avenue
Seattle, WA 98121
US
E-mail: jsalowey@cisco.com
Phone: +1 206 256 3380
Mark Grayson
Cisco Systems
11 Rue Desmoulins
Issy Les Moulineaux
92782
France
E-mail: mgrayson@cisco.com
Phone: +33 6 19 98 40 99
Grayson and Salowey September 2003 [Page 13]
