Internet Engineering Task Force T. Hardjono, Ed. Internet-Draft MIT Kerberos Consortium Intended status: Standards Track June 9, 2010 Expires: December 11, 2010 OAuth 2.0 support for the Kerberos V5 Authentication Protocol draft-hardjono-oauth-kerberos-00 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 December 11, 2010. 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 December 11, 2010 [Page 1] Internet-Draft Kerberos Support in OAuth 2.0 June 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 4.3. OAuth-Kerberos Message Flows . . . . . . . . . . . . . . . 18 4.3.1. Client Requests Access Token . . . . . . . . . . . . . 18 4.3.2. Access Token Response . . . . . . . . . . . . . . . . 19 4.3.3. Client Accesses Resource Server . . . . . . . . . . . 19 5. Kerberized Token Exchange Service . . . . . . . . . . . . . . 20 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Hardjono Expires December 11, 2010 [Page 2] Internet-Draft Kerberos Support in OAuth 2.0 June 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 December 11, 2010 [Page 3] Internet-Draft Kerberos Support in OAuth 2.0 June 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 specification [Oauth-v2- draft-05]. 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 Hardjono Expires December 11, 2010 [Page 4] Internet-Draft Kerberos Support in OAuth 2.0 June 2010 Session Key and delivers it in an encrypted fashion to the Client and 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 Hardjono Expires December 11, 2010 [Page 5] Internet-Draft Kerberos Support in OAuth 2.0 June 2010 token endpoint in the Authorization Server that issues the 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 December 11, 2010 [Page 6] Internet-Draft Kerberos Support in OAuth 2.0 June 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 December 11, 2010 [Page 7] Internet-Draft Kerberos Support in OAuth 2.0 June 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 December 11, 2010 [Page 8] Internet-Draft Kerberos Support in OAuth 2.0 June 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-10). 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 December 11, 2010 [Page 9] Internet-Draft Kerberos Support in OAuth 2.0 June 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 December 11, 2010 [Page 10] Internet-Draft Kerberos Support in OAuth 2.0 June 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 December 11, 2010 [Page 11] Internet-Draft Kerberos Support in OAuth 2.0 June 2010 The OAuth 2.0 specification currently does not specify the sizes of tokens and other values received from the Authorization Server (OAuth 2.0 Specification draft-05, Section 3.4). 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 Hardjono Expires December 11, 2010 [Page 12] Internet-Draft Kerberos Support in OAuth 2.0 June 2010 Kerberos authentication response message containing a Service Ticket, there are a number of interesting aspects: a. OAuth Access Token Secret vs Kerberos Session-Key: The OAuth 2.0 specification (draft-05) 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 Hardjono Expires December 11, 2010 [Page 13] Internet-Draft Kerberos Support in OAuth 2.0 June 2010 (Section 4). It allows clients to obtain a new access token without 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 December 11, 2010 [Page 14] Internet-Draft Kerberos Support in OAuth 2.0 June 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 December 11, 2010 [Page 15] Internet-Draft Kerberos Support in OAuth 2.0 June 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 The current OAuth specification (draft-05) does not specify other authentication protocols beyond username/password (presumably within an HTML form over SSL). In order to gain broad adoption in various organizations, and to gain usage in higher assurance environments, OAuth needs to support other means of authentication beyond username/passwords. [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 (draft-05) 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 December 11, 2010 [Page 16] Internet-Draft Kerberos Support in OAuth 2.0 June 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 (Section 2.2 of draft-05). 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 December 11, 2010 [Page 17] Internet-Draft Kerberos Support in OAuth 2.0 June 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. 4.3. OAuth-Kerberos Message Flows The proposed approach makes use of the existing OAuth message flow, with some modification in the contents of some of the OAuth (opaque) parameters. 4.3.1. Client Requests Access Token The OAuth client provides the user credentials to the Authorization Server. As part of the message construction, the OAuth Client obtains an opaque AS_REQ message from the underlying Kerberos Client. The OAuth client then constructs the usual OAuth request with the following parameters: Hardjono Expires December 11, 2010 [Page 18] Internet-Draft Kerberos Support in OAuth 2.0 June 2010 o secret_type: The secret_type value is set to "Kerberos-v5. o client_id: The client_id parameter is set to the Kerberos client principal name o client_secret: The client_secret contains a string which a concatenation of the string "KRB_AS_REQ" with the string representation of the GSS-Token of the actual AS_REQ message. Thus: client_secret = "KRB_AS_REQ|apaquegsstoken1". 4.3.2. Access Token Response The Authorization Server processes the received request in the usual OAuth manner. Upon detecting that the secret_type being "kerberos-v5", it passes the opaque portion of the client_secret to the back-end Kerberos KDC. Upon successful authentication of the user by the KDC, the KDC constructs an AS_REP message in the GSS-Token format and encodes into an opaque string. The KDC then passes the string to the OAuth Authorization Server. The OAuth Authorization Server returns the following parameters to the OAuth Client: o secret_type = "kerberos-v5" o access_token = "KRB_AS_REP|apaquegsstoken2" Note that since the Kerberos TGS is not used in this scenario, the AS_REP message from the KDC contains a Service Ticket destined for the Resource Server. 4.3.3. Client Accesses Resource Server Upon detecting that the secret_type is set to "Kerberos-v5", the OAuth client passes the opaque portion to the underlying Kerberos Client. The Kerberos Client then constructs an AP_REQ message in the GSS- Token format and encodes into an opaque string. The Kerberos Client then passes the string to the OAuth Client, which in turn constructs the request to the Resource Server with the following parameters: o secret_type = "kerberos-v5" o access_token = "KRB_AS_REP|apaquegsstoken2" (from previous step) Hardjono Expires December 11, 2010 [Page 19] Internet-Draft Kerberos Support in OAuth 2.0 June 2010 o client_secret = "KRB_AP_REQ|apaquegsstoken3" Note that the Kerberos Authenticator and Service Ticket is in fact contained within the client_secret. The Access Token is delivered to the Resource Server for the purposes of: (a) to allow the Server to verify the Service Ticket within the access_token is identical to that in the client_secret, (b) to allow the Server to cache the access_token for future access by the OAuth Client, and (c) to allow the Server to perform logging as part of audit tracking. 5. Kerberized Token Exchange Service TBD 6. Acknowledgements TBD 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 Hardjono Expires December 11, 2010 [Page 20] Internet-Draft Kerberos Support in OAuth 2.0 June 2010 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. [WSS-Kerberos] Oasis-Open, "Web Services Security: Kerberos Token Profile 1.1", 2006, . Appendix A. Additional Stuff This becomes an Appendix. Author's Address Thomas Hardjono (editor) MIT Kerberos Consortium 77 Massachussetts Avenue W92-152 Cambridge, MA 02139 US Email: hardjono@mit.edu Hardjono Expires December 11, 2010 [Page 21]