[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Internet Engineering Task Force                         T. Hardjono, Ed.
Internet-Draft                                   MIT Kerberos Consortium
Intended status: Standards Track                        December 8, 2010
Expires: June 11, 2011


     OAuth 2.0 support for the Kerberos V5 Authentication Protocol
                    draft-hardjono-oauth-kerberos-01

Abstract

   This draft proposes an OAuth2.0 profile for Kerberos v5.  We compare
   the Kerberos protocol flow with the OAuth protocol flow and as far as
   possible map the relevant parameters in Kerberos to OAuth parameters.
   We propose the use of the OAuth 2.0 message flows and its tokens to
   carry Kerberos TGTs and Service Tickets in an opaque manner.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on June 11, 2011.

Copyright Notice

   Copyright (c) 2010 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Hardjono                  Expires June 11, 2011                 [Page 1]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Background: Kerberos protocol (v5) . . . . . . . . . . . . . .  4
     2.1.  History of Kerberos  . . . . . . . . . . . . . . . . . . .  4
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Overview of the Kerberos (V5) protocol . . . . . . . . . .  6
       2.3.1.  Advantages and disadvantages of the Kerberos
               paradigm . . . . . . . . . . . . . . . . . . . . . . .  8
   3.  Functional Comparison of OAuth 2.0 and Kerberos V5 . . . . . .  9
     3.1.  Client Authentication  . . . . . . . . . . . . . . . . . .  9
       3.1.1.  OAuth Client Authentication Request  . . . . . . . . .  9
       3.1.2.  Kerberos Client Authentication Request . . . . . . . . 10
     3.2.  Access Token Response  . . . . . . . . . . . . . . . . . . 11
       3.2.1.  OAuth Access Token Response  . . . . . . . . . . . . . 11
       3.2.2.  Kerberos Service Ticket  . . . . . . . . . . . . . . . 12
     3.3.  Resource Access Request  . . . . . . . . . . . . . . . . . 13
     3.4.  Refresh Token  . . . . . . . . . . . . . . . . . . . . . . 13
     3.5.  Conclusions and Recommendations  . . . . . . . . . . . . . 15
   4.  An OAuth 2.0 Profile for Kerberos (DRAFT)  . . . . . . . . . . 16
     4.1.  Design Assumptions . . . . . . . . . . . . . . . . . . . . 16
       4.1.1.  Separation of Kerberos functions from OAuth
               functions  . . . . . . . . . . . . . . . . . . . . . . 17
       4.1.2.  Opaqueness of Kerberos Messages  . . . . . . . . . . . 17
       4.1.3.  Resource Server as a Service Principal . . . . . . . . 17
     4.2.  OAuth-Kerberos Architecture Overview . . . . . . . . . . . 17
   5.  Kerberized Token Exchange Service  . . . . . . . . . . . . . . 18
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 19
   Appendix A.  Document History  . . . . . . . . . . . . . . . . . . 20
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20















Hardjono                  Expires June 11, 2011                 [Page 2]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


1.  Introduction

   There are a number of reasons why Oauth 2.0 support for the Kerberos
   protocol would be useful to the security industry.  First, there is a
   large degree of similarity at the protocol design level and intended
   functions between Oauth 2.0 and Kerberos.  There is also strong
   similarities in the entities involved in OAuth2.0 and Kerberos,
   albeit OAuth focuses on the application layer (above the HTTP layer).
   Access to a service requires the client to obtain an Access Token (or
   Service Ticket in Kerberos), while the Refresh Token (or Ticket
   Granting Ticket in Kerberos) is used to limit the number of re-
   authentications by the user seeking to use the same service.

   Secondly, easily upwards of 60% of medium to large Enterprises today
   use the Kerberos protocol in one form or another (proprietary
   implementations or open source), for various authentication
   requirements.  These range from user-logons at the operating system
   level, to Web-SSO and to server-to-server authentication at the
   backend infrastructure.  Support for Kerberos is built into various
   operating systems and open-source distributions (e.g.  Windows,
   RedHat, Open Solaris, Ubuntu, etc), and the majority of browsers
   support some Kerberos functions.  Allowing organizations to place
   Outh 2.0 servers as a front-end layer allows them to further re-use
   their existing Kerberos infrastructure, thereby allowing easier
   adoption of Oauth 2.0 within these organizations.

   Thirdly, there are a number similarities in intended functions
   between Kerberos and OAuth 2.0.  Any OAuth 2.0 function that can re-
   use Kerberos functionality and code may provide the developer with
   faster development time.

   Finally, interoperability between OAuth2.0 and Kerberos is highly
   desired from a deployment perspective.  There are a number of ways to
   achieve such interoperability.  For example, OAuth2.0 opaque tokens
   and other structures can be used to transport Kerberos messages.
   Transporting or tunneling Kerberos above other protocols is not a new
   idea.  Various other protocols have previously been used to transport
   Kerberos message structures opaquely in order to satisfy certain
   security and deployment constraints.  Examples include Kerberos
   within HTTP-Negotiate [RFC4559] and Kerberos over Web Services
   Security (over SOAP)[WSS-Kerberos].

   The aim of this draft is to identify and define mechanisms that would
   allow a high degree of interoperability between OAuth 2.0 and
   Kerberos.  As such, it is not the intent of the current work to
   replace OAuth 2.0, but instead to allow organizations to deploy OAuth
   2.0 compliant Authorization Servers and Resource Servers, while
   retaining (and value-adding to) their Kerberos infrastructure in the



Hardjono                  Expires June 11, 2011                 [Page 3]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


   back-end.

   In the next section we will provide an overview of the Kerberos (v5)
   protocol.  The text of the discussion is intentionally kept at the
   same level of abstraction as the Oauth 2.0 Framework specification.
   This is to avoid the reader from having to read through RFC4120 and
   to avoid the discussion from diving into the specific details and
   constraints of RFC4120.  The interested reader is directed to RFC4120
   for the details of the Kerberos authentication protocol.

1.1.  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].


2.  Background: Kerberos protocol (v5)

2.1.  History of Kerberos

   The Kerberos authentication protocol [REF] was one of the earliest
   authentication protocols based purely on symmetric key cryptography.
   Founded on the Needham-Schroeder protocol [REF], Kerberos was
   designed as the authentication mechanism within Project Athena [REF]
   at MIT in the mid-1980s.  In order to realize and implement the
   Needham-Schroeder protocol, a number of constructs were added to the
   basic Needham-Schroeder protocol to create Kerberos.  Notable among
   these additions were the Kerberos ticket, and later the Ticket
   Granting Service (TGS) as a separate function from the Authentication
   Server (AS) within the Key Distribution Center (KDC).  The Kerberos
   V5 protocol was defined in 1993 within RFC1510 (obsoleted), with the
   current authoritative definition being RFC4210.

   Kerberos is one of the few symmetric key based authentication
   protocols that has been well studied and scrutinized over the last
   two decades.  The security of Kerberos in founded on the sharing of
   long-term symmetric keys (pair-wise between entities) and the usage
   of shorter term session keys between the Client and the Service.  In
   summary, the Client and the KDC share a pair-wise unique symmetric
   key (long-term) that is used by both parties to communicate with data
   confidentiality and perform authentication based on proof-of-
   possession (POP) the correct keys.  When a Client seeks to access
   services or resources at the Server, the Client must request a
   Service Ticket to the KDC specifically designated for the target
   Server.  In order to prove to the Server that the Client is
   authorized by the KDC to access the Server, the KDC generates a
   Session Key and delivers it in an encrypted fashion to the Client and



Hardjono                  Expires June 11, 2011                 [Page 4]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


   Server (using their respective long-term keys which they share pair-
   wise with the KDC).  When seeking access to the Server, the Client
   must prove possession of the session-key (to the Server) by
   encrypting a so called Authenticator structure using that session-key
   and sending it to the Server with the request.  Successful decryption
   of the Authenticator structure by the Server indicates to the Server
   that the requestor is a legitimate Client who has been authenticated
   previously by the KDC.  Here the Client must actually excersize its
   copy of the session-key to prove POP.  In this manner, Kerberos is
   different from bearer-token protocols in which the client needs only
   present a token that was previously created by another entity.

2.2.  Terminology

   In this section we briefly summarize some of the terminology commonly
   used in the Kerberos literature, while providing the approximate
   OAuth 2.0 equivalent:

   Client  A process that makes use of a service or resource on behalf
           of a user.  Note that in some cases a Server may itself be a
           client of some other server (e.g., a print server may be a
           client of a file server).

   Authentication Server (AS)  Authentication Server (AS) The service
           operating within the Key Distribution Center (KDC) that
           authenticates the client based on symmetric key cryptography.
           The client and the AS shares a long-term secret (long term
           symmetric key).  The AS issues the client with a Ticket
           Granting Ticket (TGT) intended for a specific TGS (i.e.
           decipherable only by the intended TGS).  The matching
           function in OAuth 2.0 is that of the token endpoint in the
           Authorization Server that issues the initial Access Token.

   Authenticator  A Kerberos record or structure containing information
           that can be shown to have been recently generated using the
           session key known only (shared) by the client and server.  In
           Kerberos the authenticator is one way the client proves to
           the server that the client is in possession of the correct
           session key.

   Ticket Granting Server (TGS)  The service operating within the Key
           Distribution Center (KDC) that authenticates a client based
           on (a) the client's presentation of a legitimate Ticket
           Granting Ticket (TGT) issued by the AS and (b) the client's
           proof-of-possession of the correct symmetric key (used by the
           client to create the Authenticator portion of the TGS
           Request).  The matching function in OAuth 2.0 is that of the
           token endpoint in the Authorization Server that issues the



Hardjono                  Expires June 11, 2011                 [Page 5]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


           Refresh Token.

   Key Distribution Center (KDC)  A Kerberos service that is comprised
           of the Authentication Server (AS) and Ticket Granting Server
           (TGS).  The combined Kerberos AS and TGS could be matched to
           the OAuth 2.0 Authorization Server, where the TGS matches
           more closely the Refresh Token issuing function of the
           Authorization Server.

   Principal  A uniquely named client or server instance that
           participates in a network communication.

   Server (or Kerberos Server)  A particular Principal which provides a
           service or resource to clients.  In OAuth 2.0 this is the
           Resource Server.

   Session Key  A temporary encryption key used between two principals,
           with a lifetime limited to the duration of a single Kerberos
           "session".

   Sub-session Key  A temporary encryption key used between two
           principals, selected and exchanged by the principals using
           the session key, and with a lifetime limited to the duration
           of a single association.

   Ticket  A record or data structure that helps a client authenticate
           itself to a server.  It contains the client's identity, a
           session key, a timestamp and other information, all of which
           are sealed using the server's secret key.  The term "service
           ticket" is often used to distinguish from the Ticket-
           Granting-Ticket (TGT) which is consumable only by the Ticket
           Granting Server (TGS).  A ticket only serves to authenticate
           a client to a service when presented along with a fresh
           Authenticator.  In OAuth 2.0 the closest structure to a
           ticket is the Access Token and Refresh Token, together with
           parameters accompany the token when transmitted.

2.3.  Overview of the Kerberos (V5) protocol

   The basic purpose of Kerberos is to provide access control of a
   client (user or host) to a service or resource.  To simplify the
   current description, we will use the term "client" to mean the entity
   associated with the symmetric key shared with the Authentication
   Server (though the intent is clear that both human users and host
   computers can in fact be Kerberos principals).

   The following summarizes the main message flows within Kerberos:




Hardjono                  Expires June 11, 2011                 [Page 6]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


   (A) Authentication Request (AS_REQ)
           The Authentication Request (AS_REQ) message is sent by the
           Kerberos Client to the Authentication Server (AS) within the
           KDC.

   (B) Authentication Response (AS_REP)
           The AS/KDC returns a response (AS_REP) message to the Client
           that contains the encrypted Service Ticket and the encrypted
           AS Response Part.  These two parts contain the session-key
           that the Client and Service (Resource Server) will later use
           to secure their session.

   (C) Service Request (AP_REQ)
           The Client constructs the Authenticator structure that it
           encrypts using the session-key (obtained in the previous
           step).  This Authenticator provides proof-of-possession (of
           the session-key) to the Service (Resource Server).  The
           Client delivers both the Service Ticket (unmodified from the
           previous step) and the Authenticator within the AP_REQ
           message.

   (D) Service Response (AP_REP)
           The Service (Resource Server) obtains the AP_REQ message,
           decrypts the Session Ticket (created by the KDC) and extracts
           the session-key.  It then uses the session-key to verify the
           Authenticator structure.

   (E) Optional Ticket-Granting Service Request (TGS_REQ)
           In order to prevent the Client from having to authenticate
           repeatedly to the KDC (e.g. due to short-life tickets), the
           Client can request a Ticket-Granting-Ticket (TGT) from the
           Ticket Granting Service (TGS), which is a special service
           operating at the KDC.

   (F) Optional Ticket-Granting Service Response (TGS_REP)
           If the TGS_REQ message is used, the TGS (instead of the AS)
           will return the Service Ticket destined for a given Service
           (Resource Server).  Note that the Service Ticket life is
           shorter than the TGT life.












Hardjono                  Expires June 11, 2011                 [Page 7]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


                                            +---------------------+
                                            |        KDC          |
   +--------+                               |  +---------------+  |
   |        |--(A)------ Authentication ----|->|Authentication |  |
   |        |             Request (AS_REQ)  |  |  Server (AS)  |  |
   |        |<-(B)------ Authentication ----|--|               |  |
   |        |             Response (AS_REP) |  +---------------+  |
   |        |                               |                     |
   |        |                               |  +---------------+  |
   |        |--(E)------ TGS Request -------|->|     Ticket    |  |
   | Client |         (TGS_REQ) optional    |  |    Granting   |  |
   |        |<-(F)------ TGS Response ------|--|  Server (TGS) |  |
   |        |         (TGS_REP) optional    |  +---------------+  |
   |        |                               +---------------------+
   |        |
   |        |                                  +---------------+
   |        |--(C)------ Service Request ----->|   Service or  |
   |        |             (AP_REQ)             |    Resource   |
   |        |<-(D)------ Service Response - ---|     Server    |
   |        |             (AP_REP)             +---------------+
   +--------+



                                 Figure 1

2.3.1.   Advantages and disadvantages of the Kerberos paradigm

   As an authentication protocol based on symmetric key cryptography,
   there a number of advantages as well as inherent limitations of
   Kerberos:

   o  Limited impact of key compromise: The compromise of a client or
      server (or the keys in these entities) impacts only these
      entities.  Other clients and servers are not impacted since they
      share a unique key with the KDC.

   o  Speed of cryptographic operations: One of the original motivations
      behind Kerberos was the desire to use symmetric key ciphers due to
      their significant performance over public key ciphers.

   o  Cross realm/domain authentication: Kerberos v5 addressed the
      requirement of cross-realm authentication and authorization by the
      introduction of cross-realm tickets.  This provides the advantage
      of scaling Kerberos across realms (within one administrative
      boundary) and across realms in differing administrative
      boundaries.




Hardjono                  Expires June 11, 2011                 [Page 8]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


   o  Delegation: Kerberos v5 addressed supports the notion of
      delegation through the use of special tickets (refered to as
      proxiable tickets and forwardable tickets).  In essence,
      delegation in Kerberos allows a Client to name another entity
      (e.g. a Server) within a ticket-request (to the KDC) with the
      explicit intent of allowing that entity to later request service-
      tickets in the name of the Client.  Delegation can also be used to
      realize the notion of "transitive-trust" that may cross domain
      boundaries.

   o  Compromise of KDC impacts other entities: Since the KDC shares a
      symmetric key pair-wise with every entity in the system (clients
      and server), the compromise of the KDC and the keys stored at the
      KDC renders the entire system compromised.  Thus, additional
      security is required for keys stored at the KDC.  Additional
      precautions, such as separating the Authentication Server (AS)
      into a more secure computing environment may reduce the risks
      associate with attacks.

   o  Initial key establishment problem: Similar to many symmetric key
      based authentication protocols, Kerberos requires initial key
      establishment between a Client and the KDC, and between a Server
      and the KDC.  Several methods to establish the initial shared key
      between entities have been proposed.  These are referred to as
      "pre-authentication" protocols in the Kerberos literature, and
      includes a password-based method (defined as part of RFC4210), a
      public-key based approach (PKINIT [RFC4556]) using the Diffie-
      Hellman or RSA cryptosystems) as well as One-Time-passwords or
      tokens (draft-ietf-krb-wg-otp-preauth-17).


3.  Functional Comparison of OAuth 2.0 and Kerberos V5

   In this section we compare the intent/purpose of the OAuth 2.0
   messages against those in Kerberos V5.  The aim here is to understand
   the semantic similarities between OAuth 2.0 and Kerberos, and
   identifying the gaps needing solutions in order for OAuth 2.0 to
   support Kerberos V5.  Another aspect of this exercise is also to
   understand the design decisions of Kerberos V5 over the last two
   decades, hopefully to inform a better design to OAuth 2.0 and other
   new protocols in the future.

3.1.  Client Authentication

3.1.1.  OAuth Client Authentication Request

   The OAuth 2.0 protocol caters for a number of use-cases, though in
   many of these scenarios there are some common fundamental parameters



Hardjono                  Expires June 11, 2011                 [Page 9]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


   that are being exchanged with the Authorization Server.

   In the Client Authentication exchange the token endpoint at the
   Authorization Server requires the client to provide the client
   identifier (client_id) and the optional client secret
   (client_secret).  These two parameters can be delivered using a
   simple HTTP POST message or using an HTTP authentication scheme.  How
   the client obtains these credentials are outside the scope of the
   OAuth 2.0 specification.  Additional parameters thar are communicated
   between the client and Authorization server:

   o  Type of authentication (user_agent, web_server, device_code,
      username, client_credentials, assertion or refresh).

   o  Client identity (client_id)

   o  Client secret (client_secret)

   o  Server identity (Host name)

   o  Transport mechanism (e.g.  HTTP POST)

   o  Encoding method or content type (e.g. urlencoded)

   The OAuth 2.0 specification, however, considers as out-of- scope the
   method used by the Authorization Server to authenticate the end-user.
   As such, the current OAuth 2.0 specification could be considered more
   as a framework for authentication and authorization, which needs to
   be instantiated with a specific authentication mechanism/method and
   which would therefore necessitate bindings to specific transports.

3.1.2.  Kerberos Client Authentication Request

   In Kerberos, the client initiates an authentication request by
   sending the AS_REQ message to the Authentication Server (AS).
   Ignoring for the moment the format of the AS_REQ message, the client
   sends the following parameters to the AS:

   o  Message type

   o  Kerberos protocol version number (v5)

   o  Pre-authentication data (optional)

   o  Client principal name

   o  Client's realm




Hardjono                  Expires June 11, 2011                [Page 10]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


   o  KDC principal name)

   o  Start-time of requested ticket (optional)

   o  Expiration time of requested ticket

   o  Nonce generated by the client

   o  Encryption algorithm desired

   o  Client host address (optional)

   o  Additional tickets (optional)

   In Kerberos the client has the option of selecting the lifetime of
   tickets, though the KDC can set the upper bounds of the lifetimes
   according to some predefined policy.  The client has to explicitly
   choose a unique random nonce for the purposes of detecting replays of
   the responses coming from the KDC.

   Although RFC4120 allows the Kerberos authentication request message
   to be sent in clear text, in practice it is beneficial to protect
   this message from unauthorized modifications in-transit.  Similar to
   OAuth, the request could be sent over a secure channel such as TLS/
   SSL or within some tunneling mechanism (e.g.  FAST tunnel).

3.2.  Access Token Response

3.2.1.  OAuth Access Token Response

   In OAuth 2.0 the access token response from the Authorization Server
   caries a number of parameters explicitly and implicitly (Section
   3.3.2.1):

   o  Access Token

   o  Duration of token (expires in seconds)

   o  Optional Refresh Token

   o  Access Token Secret (optional, determined by client)

   o  Scope

   o  Transport mechanism (e.g.  HTTP 1.1)

   o  Encoding method or content type (e.g. app/json)




Hardjono                  Expires June 11, 2011                [Page 11]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


   The OAuth 2.0 specification currently does not specify the sizes of
   tokens and other values received from the Authorization Server.

3.2.2.  Kerberos Service Ticket

   The Kerberos v5 equivalent to the OAuth 2.0 Access Token is that of
   the Service Ticket.  The client can obtain a Service Ticket directly
   from the KDC using the Authentication Request (AS_REQ) message.  The
   response coming back from the KDC contains a number of relevant
   parameters:

   o  Message type

   o  Kerberos protocol version number (v5)

   o  Pre-authentication data (optional)

   o  Client principal name

   o  Client's realm

   o  Service Ticket (encrypted structure)

   o  Response Part (encrypted structure)

   The two important structures inside the Kerberos response message are
   the Response Part structure that is intended for the Client, and the
   Service Ticket (ST) structure which the Client must forward
   unmodified to the Server (or Resource Server).  Generally each of
   these structures carry a number of parameters in-turn, including (a)
   the identities of the Client and Server, (b) the lifetime of the
   Ticket and (c) the Session-Key to be used by the Client in requesting
   service or access to the Server (Resource Server).

   Here, an important security feature is that the Response Part
   structure (containing the Session-Key) is encrypted by the KDC using
   the long-term key it shares with the Client.  This ensures that only
   the authenticated Client can decrypt the Response Part and make use
   of the contained Session-Key.  Similarly, the important parameters
   within the Service Ticket structure is encrypted by the KDC using the
   long term key it shares with the Server (i.e.  Resource Server).
   This ensures that only the Client and Server know the given Session-
   Key, and thus allows the Server to later recognize an authentic
   service request from the Client (encrypted by the Client using that
   very same Session-Key).

   In comparing the OAuth Access Token Response message with the
   Kerberos authentication response message containing a Service Ticket,



Hardjono                  Expires June 11, 2011                [Page 12]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


   there are a number of interesting aspects:

   a.  OAuth Access Token Secret vs Kerberos Session-Key: The OAuth 2.0
       specification allows Clients to make authenticated protected
       resource requests using an access token with a matching secret by
       calculating a set of values and including them in the request
       using the "Authorization" header field.  The OAuth 2.0
       specification defines the "hmac-sha256" algorithm to verify this
       secret.

       In contrast, in Kerberos the Session-Key is used by the Client to
       encrypt (not hash) the Authenticator structure that the Client
       creates.  The encrypted Authenticator structure is then sent
       together with the Service Ticket (obtained from the KDC in the
       prior step) to the Server (or Resource Server).

       Kerberos uses encryption instead of hashing only die to the
       sensitivity of the parameters exchanged between the Client and
       KDC, and between the Client and Server.

   b.  Selectable Ciphers and Hash Functions: Kerberos supports various
       ciphers and hash functions as negotiated upon between the Client
       and KDC at the initial authentication request.

3.3.  Resource Access Request

   Once the Client obtains an OAuth 2.0 Access Token, it delivers the
   Access Token to the Resource Server within an HTTP Request message.
   OAuth supports a number of use-cases which it supports (User-Agent
   Flow, Web Server Flow, Device Flow, Username/Password Flow, Client
   Credential Flow and Assertion Flow).  These use-cases are in fact
   distinct from the fundamental authentication feature of OAuth 2.0
   based on Access Tokens.  The use-cases address the various deployment
   scenarios and technologies that are available today to implement
   them.

   In Kerberos, in order to access the Server the Client must present
   both the Authenticator (created by the Client) and the Service Ticket
   (created by the KDC).  These two structures when combined allow the
   Server (or Resource Server) to establish that the Client has been
   authenticated by the KDC.  The Server does not have to interact with
   the KDC when validating the Service Ticket.

3.4.  Refresh Token

   In OAuth 2.0 the token refresh is used when the lifetime of an access
   token is shorter than the lifetime of the authorization grant
   (Section 4).  It allows clients to obtain a new access token without



Hardjono                  Expires June 11, 2011                [Page 13]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


   having to go through the OAuth authorization flow again (to the
   Authorization Server) or involve the resource owner.

   The relevant parameters of the OAuth 2.0 Refresh Token request
   message are as follows:

   o  Type of authentication (set to "refresh")

   o  Client identity (client_id)

   o  Client secret (if client issued a secret)

   o  Refresh Token (refresh_token)

   o  Secret Type (optional, defaults to bearer token if there is no
      secret)

   o  Response format (one of "json", "xml", or "form").

   In Kerberos, in order to avoid the Client from having to authenticate
   to the KDC each time it wishes to access a Server, the Client must
   first obtain a Ticket Granting Ticket (TGT) from the Ticket Granting
   Service (TGS) operating in the KDC.  The Client then uses the TGT
   each time it requests a Service Ticket to access the Server.  This
   can be done as a system process, without the need to prompt the user.
   In this sense, the Refresh Token is identical in purpose to the
   Kerberos TGT.

   The message structure of the TGT request message is identical to the
   message structure of a Service Ticket request.  Indeed, in Kerberos
   the Ticket Granting Service (TGS) is viewed in the same manner as the
   services offered by any Kerberos Server.

   In Kerberos the AS Response (AS_REP) message carries a number of
   parameters, including those intended for consumption by the Ticket
   Granting Service (TGS).  These are summarized as follows:

   o  Message type

   o  Kerberos protocol version number (v5)

   o  Pre-authentication data (optional)

   o  Client principal name

   o  Client's realm





Hardjono                  Expires June 11, 2011                [Page 14]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


   o  Ticket Granting Ticket (encrypted structure)

   o  AS Response Part (encrypted structure)

   The two important structures inside the AS_REP message are the AS
   Response Part structure that is intended for the client, and the
   Ticket Granting Ticket (TGT) structure which the client must forward
   unmodified to the Ticket Granting Service.  Each of these structures
   carry a number of parameters in-turn, including (a) the identities of
   the client, TGS and Server, (b) the lifetime of the TGT and (c) the
   Session-key to be used by the Client in requesting the Service Ticket
   to the TGS.

   Here, an important security feature is that the AS Response Part
   structure (containing a session-key) is encrypted by the AS using the
   long-term key it shares with the client.  This ensures that only the
   authenticated client can decrypt the AS Response Part and make use of
   the contained session- key.  Similarly, the important parameters
   within the TGT structure is encrypted by the AS using the long term
   key it shares with the TGS entity.  This ensures that only the client
   and TGS know the given session-key, and thus allows the TGS to later
   recognize an authentic Service Ticket request from the client
   (encrypted by the client using that very same session-key).

   It is important to note that obtaining a TGT is optional in Kerberos,
   and the client can in fact request a Service Ticket directly from the
   AS by simply designating the identity of the Server in the AS Request
   message.  This may prove cumbersome in practice, since the client may
   need to newly authenticate itself to the AS each time it seeks to
   access the Server.

3.5.  Conclusions and Recommendations

   In this section we offer some observations and recommendations
   regarding OAuth 2.0, in the light of the various lessons learned from
   the development of the Kerberos authentication protocol over the last
   couple of decades:

   [1] Refresh Tokens and Access Tokens
           In Kerberos, the introduction of the Ticket Granting Service
           (TGS) as a special service on the KDC was done to address the
           issue of the end-user having to re-authenticate each time the
           user wanted to access the server (resource server).  In
           practice, Kerberos is almost always deployed using the TGS
           where the TGT has a longer lifetime compared to the service-
           tickets requested using a given TGT.
           In OAuth the cases for using a Refresh Token (as a means to
           extend the life of the Access Token) needs to be made clear



Hardjono                  Expires June 11, 2011                [Page 15]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


           and explicit.  Furthermore, Refresh Tokens need to be
           provably related to its parent Access Token, in such a way
           that a third-party entity (e.g. auditor) can verify the
           sequence of events/messages that has been logged by the
           Resource Server.

   [2] Support for multiple authentication methods
           Being a framework, OAuth2.0 currently does not (and should
           not) call-out specific authentication protocols.  In order to
           gain broad adoption in various organizations, and to gain
           usage in higher assurance environments, OAuth needs to
           support a broad range of authentication protocols and
           methods, including username/passwords, OTP-tokens, Kerberos
           tickets, and others.

   [3] Delegation support
           A key feature of Kerberos that is used extensively in some
           deployments is delegation (or "constrained delegation" in the
           Kerberos literature).  In Kerberos delegation is expressed
           using proxiable tickets and forwardable tickets, where a
           Kerberos client can request a ticket within which the client
           can explicitly name a server who will act as a delegate.
           This server will in-turn request service ticket on behalf of
           the client.  Although delegation is not explicitly supported
           as a feature in the current OAuth 2.0 specification one could
           conceivably introduce the notion of a "delegation access
           token" that implements the same function as that in Kerberos.


4.  An OAuth 2.0 Profile for Kerberos (DRAFT)

   In this section we propose a "profile" of OAuth 2.0 for Kerberos that
   provides one approach for interoperability between OAuth2.0 and
   Kerberos.  In this approach, the Kerberos messages are delivered
   using OAuth as a mechanism of transport between the relevant Kerberos
   entities.

   A key aspect of this proposal is the representation of the Kerberos
   messages in the form of GSS-Tokens as defined in RFC2743 and RFC4121.
   This provides opaqueness of the Kerberos messages to the higher layer
   applications, which in this case are the OAuth entities operating at
   the HTTP layer.

4.1.  Design Assumptions







Hardjono                  Expires June 11, 2011                [Page 16]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


4.1.1.  Separation of Kerberos functions from OAuth functions

   Since one of the main goals of OAuth 2.0 is to provide simplicity to
   the end-user, one of the design assumptions here is that the creation
   and consumption of Kerberos is performed by Kerberos entities (or
   components) that are distinct from OAuth entities.  Thus, for
   example, although the OAuth Authorization Server could also be
   implemented as an enhanced Kerberos KDC, we assume that the KDC is
   distinct from the Authorization Server.

   This architectural separation allows organizations already deploying
   a Kerberos infrastructure to layer OAuth as front- end service for
   authenticating users and OAuth clients, following the use-cases
   defined in the OAuth specification.

4.1.2.  Opaqueness of Kerberos Messages

   Following the approach used by HTTP-Negotiate (RFC4559) which
   introduced a new auth-scheme based on the SPNEGO GSSAPI-Tokens, in
   this document we also propose the use the GSSAPI-Tokens (RFC2743) for
   all Kerberos messages that will be over (through) through OAuth
   messages.  The GSSAPI-Tokens is assumed to be encoded in some HTTP-
   friendly manner (e.g.  Base64 encoded).

   The approach of using Kerberos GSSAPI-Tokens (RFC4121) is also used
   in the Web Services Security standard, notably in the WSS Kerberos
   Token Profile 1.1 [WSS-Kerberos].  There the Kerberos AP_REQ message
   (wrapped GSS-Token) is delivered by a client to a service over WSS
   (over SOAP).

4.1.3.  Resource Server as a Service Principal

   In orde to achieve some degree of interoperability, we assume that
   the OAuth Resource Server is also a service principal in the
   traditional Kerberos sense.  This means (among others) that (a) the
   Resource Server shares a long-term key with the KDC, and (b) that it
   is able to consume and process Service Tickets in the usual Kerberos
   manner.  How a Resource Server implements the Kerberos Service is
   outside the scope of the OAuth 2.0 specification and of this current
   document.

4.2.  OAuth-Kerberos Architecture Overview

   The overall architecture underlying the OAuth 2.0 profile for
   Kerberos is shown in Figure 2.






Hardjono                  Expires June 11, 2011                [Page 17]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


   +--------+                               +---------+ +------+
   |        |--(A)----- Credentials    ---->|         | |      |
   |        |          (w. opaque AS_REQ)   |       <-|-|->    |
   |        |<-(B)----- Access Token   -----| OAuth   | |      |
   |        |          (w. opaque AS_REP)   | Authzn  | | KDC  |
   |        |                               | Server  | |      |
   |        |                               |         | |      |
   |  OAuth |--(E)----- Refresh Token ----->|         | |      |
   | Client |        (w. opaque TGS_REQ)    |       <-|-|->    |
   |        |<-(F)----- New Access Token ---|         | |      |
   |        |        (w. opaque TGS_REP)    +---------+ +------|
   |        |
   |        |                                  +---------------+
   |        |--(C)--HTTP Req w. Access Token-->|   Service or  |
   |   ^    |         (w. opaque AP_REQ)       |    Resource   |
   |   |    |<-(D)----- HTTP Response ---------|     Server    |
   +---|----+          (w. opaque AP_REP)      +---------------+
   |   v    |
   |        |
   |  Kerb. |
   | Client |
   +--------+



                                 Figure 2

   The Kerberos client is assumed to be present in the underlying
   operating system, within the browser or as part of the web
   application.  Similar to the case of HTTP-Negotiate in which the
   browser performs a call to the underlying Kerberos client, in this
   case we assume that the OAuth Client is able to perform a similar
   call.  The details of this are outside the scope of OAuth and of the
   current document.


5.  Kerberized Token Exchange Service

   TBD


6.  Acknowledgements

   TBD







Hardjono                  Expires June 11, 2011                [Page 18]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


7.  IANA Considerations

   TBD


8.  Security Considerations

   TBD

   All drafts are required to have a security considerations section.
   See RFC 3552 [RFC3552] for a guide.


9.  References

9.1.  Normative References

   [Needham-Schoeder]
              Needham, Roger. and Michael. Schoeder, "Using encryption
              for authentication in large networks of computers,
              Communications of the ACM 21 (12)", 1978.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              July 2005.

   [RFC4559]  Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
              Kerberos and NTLM HTTP Authentication in Microsoft
              Windows", RFC 4559, June 2006.

9.2.  Informative References

   [MIT-Athena]
              Steiner, J., Neuman, B., and J. Schiller, "Kerberos: An
              Authentication Service for Open Network Systems.  In
              Proceedings of the Winter 1988 Usenix Conference.
              February.", 1988.

   [RFC1510]  Kohl, J. and B. Neuman, "The Kerberos Network
              Authentication Service (V5)", RFC 1510, September 1993.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.




Hardjono                  Expires June 11, 2011                [Page 19]


Internet-Draft        Kerberos Support in OAuth 2.0        December 2010


   [WSS-Kerberos]
              Oasis-Open, "Web Services Security: Kerberos Token Profile
              1.1", 2006, <http://www.oasis-open.org/committees/
              download.php/16788/
              wss-v1.1-spec-os-KerberosTokenProfile.pdf>.


Appendix A.  Document History

   Changes from -00

   o  Removed Oauth-Kerberos message Flows section due to the huge
      change occuring between OAuth-draft-5 and OAuth-draft-11.  Awating
      stable version of Auth 2.0 spec.


Author's Address

   Thomas Hardjono (editor)
   MIT Kerberos Consortium
   77 Massachussetts Avenue W92-152
   Cambridge, MA  02139
   US

   Email: hardjono@mit.edu


























Hardjono                  Expires June 11, 2011                [Page 20]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/