EAP Working Group INTERNET DRAFT M. Grayson draft-grayson-eap-authorisation-00.txt J. Salowey Expires: July 2003 Cisco Systems January 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. To view the entire list of current Internet-Drafts, please check the ``1id-abstracts.txtÆÆ listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 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 and allows an authentic user to provide the network with additional information in order to determine which Internet Service is being requested. This mechanism may be chained after any EAP-Authentication mechanism. Grayson and Salowey Expires in six months [Page 1] Internet Draft EAP Authorization January 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 4. Message Format...........................................6 4.1. EAP-TLV/Authorization-Start............................6 4.2. EAP-TLV/Authorization-Request..........................6 4.3. EAP-TLV/Authorization-Response.........................7 4.4. Authorization Attribute Format.........................8 4.5. Protected TLV..........................................8 5. Defined attributes.......................................9 5.1. Authorization Identity.................................9 5.2. Service Type...........................................9 5.3. Tunnel FQDN...........................................10 5.4. Tunnel Password.......................................11 6. Protection of EAP-TLV/Authorization.....................11 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 Expires in six months [Page 2] Internet Draft EAP Authorization January 2003 configuring compulsory network based tunnels [4]. Other authorization attributes are expected to be defined in the future. 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 Grayson and Salowey Expires in six months [Page 3] Internet Draft EAP Authorization January 2003 PEAP Protected 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 provide additional authorization information towards the EAP server. The EAP Authorization phase must be chained after Authentication 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 mechanism such as PEAP or by Protected TLVs described in [9]. After authentication is complete and keys are established the server sends a request of type EAP-TLV/Start-Authorization. The peer responds with an EAP-TLV/Request-Authorization packet including one or more EAP-Authorization attributes which the peer provides to the network in order to define service parameters which are to be authorized. After receiving the EAP-TLV/Authorization-Request packet, the EAP sever can confirm which services the peer is requesting resources for 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. EAP-TLV/Authorization-Request therefore includes the capability to carry additional identification and authentication information, according to the service being authorized. It is possible that the authenticating server may wish to request additional information from the client. It may use an EAP- TLV/Authorization-Request packet containing one or more Authorization attributes for this purpose. Grayson and Salowey Expires in six months [Page 4] Internet Draft EAP Authorization January 2003 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. 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-Start request to see if the client wishes to request additional services. The client then responds with an EAP- TLV/Authorization-Request message containing the following attributes: Authorization Identity Service Type Tunnel FQDN Tunnel Password The authenticator then verifies that the authenticated user is allowed to use the authorization 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 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. This is just one example of how EAP Authorization may be used, there are many other possibilities. Grayson and Salowey Expires in six months [Page 5] Internet Draft EAP Authorization January 2003 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-Start This message is sent by the EAP Server to indicate that it supports 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 0 û Authorization Request is not mandatory 1 û Authorization Request is mandatory R Reserved, set to zero (0) Type TBD TLV-Authorization-Start Length 0 4.2. EAP-TLV/Authorization-Request The EA-TLV/Authorization-Request message is used by a peer to request authorization to certain services. It has the following format: Grayson and Salowey Expires in six months [Page 6] Internet Draft EAP Authorization January 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 0 - Non-mandatory TLV 1 - Mandatory TLV R Reserved, set to zero (0) Type TBD TLV-Authorization-Request Length The length of the Value field in octets. Value One or more authorization attributes 4.3. 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 Grayson and Salowey Expires in six months [Page 7] Internet Draft EAP Authorization January 2003 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 Request for additional information from the server. 4.4. 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.5. Protected TLV Grayson and Salowey Expires in six months [Page 8] Internet Draft EAP Authorization January 2003 The protected TLV is described in the protected TLV draft [9]. 5. Defined attributes 5.1. 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 String representation of the authorization identity 5.2. Service Type This attribute contains the type of service being requested. Grayson and Salowey Expires in six months [Page 9] Internet Draft EAP Authorization January 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 = 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.3. Tunnel FQDN 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 FQDN | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Value . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Tunnel FQDN = 0x0101 Length Grayson and Salowey Expires in six months [Page 10] Internet Draft EAP Authorization January 2003 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.4. 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 Length Length of packet format Value Tunnel password 6. Protection of EAP-TLV/Authorization The EAP-TLV/Authorization mechanism SHOULD be protected. The recommended way to achieve this is to run within a protected EAP mechanism such as PEAP or Protected TLV. Grayson and Salowey Expires in six months [Page 11] Internet Draft EAP Authorization January 2003 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 should be protected either by an external mechanism such as PEAP or by using protected TLVs. 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 [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-07.txt, November 2002 (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- 00.txt, January 2003 (work in progress) Grayson and Salowey Expires in six months [Page 12] Internet Draft EAP Authorization January 2003 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 Expires in six months [Page 13]