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]