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 5.4. Billing Rate 5.5. Terms and Conditions 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]