idnits 2.17.1 draft-hardjono-oauth-kerberos-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 9, 2010) is 5070 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'REF' is mentioned on line 163, but not defined == Missing Reference: 'RFC4556' is mentioned on line 395, but not defined -- Looks like a reference, but probably isn't: '1' on line 691 -- Looks like a reference, but probably isn't: '2' on line 707 -- Looks like a reference, but probably isn't: '3' on line 715 == Unused Reference: 'Needham-Schoeder' is defined on line 917, but no explicit reference was found in the text == Unused Reference: 'RFC4120' is defined on line 922, but no explicit reference was found in the text == Unused Reference: 'MIT-Athena' is defined on line 932, but no explicit reference was found in the text == Unused Reference: 'RFC1510' is defined on line 938, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Needham-Schoeder' ** Downref: Normative reference to an Informational RFC: RFC 4559 -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Hardjono, Ed. 3 Internet-Draft MIT Kerberos Consortium 4 Intended status: Standards Track June 9, 2010 5 Expires: December 11, 2010 7 OAuth 2.0 support for the Kerberos V5 Authentication Protocol 8 draft-hardjono-oauth-kerberos-00 10 Abstract 12 This draft proposes an OAuth2.0 profile for Kerberos v5. We compare 13 the Kerberos protocol flow with the OAuth protocol flow and as far as 14 possible map the relevant parameters in Kerberos to OAuth parameters. 15 We propose the use of the OAuth 2.0 message flows and its tokens to 16 carry Kerberos TGTs and Service Tickets in an opaque manner. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 11, 2010. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 54 2. Background: Kerberos protocol (v5) . . . . . . . . . . . . . . 4 55 2.1. History of Kerberos . . . . . . . . . . . . . . . . . . . 4 56 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.3. Overview of the Kerberos (V5) protocol . . . . . . . . . . 6 58 2.3.1. Advantages and disadvantages of the Kerberos 59 paradigm . . . . . . . . . . . . . . . . . . . . . . . 8 60 3. Functional Comparison of OAuth 2.0 and Kerberos V5 . . . . . . 9 61 3.1. Client Authentication . . . . . . . . . . . . . . . . . . 9 62 3.1.1. OAuth Client Authentication Request . . . . . . . . . 9 63 3.1.2. Kerberos Client Authentication Request . . . . . . . . 10 64 3.2. Access Token Response . . . . . . . . . . . . . . . . . . 11 65 3.2.1. OAuth Access Token Response . . . . . . . . . . . . . 11 66 3.2.2. Kerberos Service Ticket . . . . . . . . . . . . . . . 12 67 3.3. Resource Access Request . . . . . . . . . . . . . . . . . 13 68 3.4. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 13 69 3.5. Conclusions and Recommendations . . . . . . . . . . . . . 15 70 4. An OAuth 2.0 Profile for Kerberos (DRAFT) . . . . . . . . . . 16 71 4.1. Design Assumptions . . . . . . . . . . . . . . . . . . . . 16 72 4.1.1. Separation of Kerberos functions from OAuth 73 functions . . . . . . . . . . . . . . . . . . . . . . 17 74 4.1.2. Opaqueness of Kerberos Messages . . . . . . . . . . . 17 75 4.1.3. Resource Server as a Service Principal . . . . . . . . 17 76 4.2. OAuth-Kerberos Architecture Overview . . . . . . . . . . . 17 77 4.3. OAuth-Kerberos Message Flows . . . . . . . . . . . . . . . 18 78 4.3.1. Client Requests Access Token . . . . . . . . . . . . . 18 79 4.3.2. Access Token Response . . . . . . . . . . . . . . . . 19 80 4.3.3. Client Accesses Resource Server . . . . . . . . . . . 19 81 5. Kerberized Token Exchange Service . . . . . . . . . . . . . . 20 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 88 Appendix A. Additional Stuff . . . . . . . . . . . . . . . . . . 21 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 1. Introduction 93 There are a number of reasons why Oauth 2.0 support for the Kerberos 94 protocol would be useful to the security industry. First, there is a 95 large degree of similarity at the protocol design level and intended 96 functions between Oauth 2.0 and Kerberos. There is also strong 97 similarities in the entities involved in OAuth2.0 and Kerberos, 98 albeit OAuth focuses on the application layer (above the HTTP layer). 99 Access to a service requires the client to obtain an Access Token (or 100 Service Ticket in Kerberos), while the Refresh Token (or Ticket 101 Granting Ticket in Kerberos) is used to limit the number of re- 102 authentications by the user seeking to use the same service. 104 Secondly, easily upwards of 60% of medium to large Enterprises today 105 use the Kerberos protocol in one form or another (proprietary 106 implementations or open source), for various authentication 107 requirements. These range from user-logons at the operating system 108 level, to Web-SSO and to server-to-server authentication at the 109 backend infrastructure. Support for Kerberos is built into various 110 operating systems and open-source distributions (e.g. Windows, 111 RedHat, Open Solaris, Ubuntu, etc), and the majority of browsers 112 support some Kerberos functions. Allowing organizations to place 113 Outh 2.0 servers as a front-end layer allows them to further re-use 114 their existing Kerberos infrastructure, thereby allowing easier 115 adoption of Oauth 2.0 within these organizations. 117 Thirdly, there are a number similarities in intended functions 118 between Kerberos and OAuth 2.0. Any OAuth 2.0 function that can re- 119 use Kerberos functionality and code may provide the developer with 120 faster development time. 122 Finally, interoperability between OAuth2.0 and Kerberos is highly 123 desired from a deployment perspective. There are a number of ways to 124 achieve such interoperability. For example, OAuth2.0 opaque tokens 125 and other structures can be used to transport Kerberos messages. 126 Transporting or tunneling Kerberos above other protocols is not a new 127 idea. Various other protocols have previously been used to transport 128 Kerberos message structures opaquely in order to satisfy certain 129 security and deployment constraints. Examples include Kerberos 130 within HTTP-Negotiate [RFC4559] and Kerberos over Web Services 131 Security (over SOAP)[WSS-Kerberos]. 133 The aim of this draft is to identify and define mechanisms that would 134 allow a high degree of interoperability between OAuth 2.0 and 135 Kerberos. As such, it is not the intent of the current work to 136 replace OAuth 2.0, but instead to allow organizations to deploy OAuth 137 2.0 compliant Authorization Servers and Resource Servers, while 138 retaining (and value-adding to) their Kerberos infrastructure in the 139 back-end. 141 In the next section we will provide an overview of the Kerberos (v5) 142 protocol. The text of the discussion is intentionally kept at the 143 same level of abstraction as the Oauth 2.0 specification [Oauth-v2- 144 draft-05]. This is to avoid the reader from having to read through 145 RFC4120 and to avoid the discussion from diving into the specific 146 details and constraints of RFC4120. The interested reader is 147 directed to RFC4120 for the details of the Kerberos authentication 148 protocol. 150 1.1. Requirements Language 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC 2119 [RFC2119]. 156 2. Background: Kerberos protocol (v5) 158 2.1. History of Kerberos 160 The Kerberos authentication protocol [REF] was one of the earliest 161 authentication protocols based purely on symmetric key cryptography. 162 Founded on the Needham-Schroeder protocol [REF], Kerberos was 163 designed as the authentication mechanism within Project Athena [REF] 164 at MIT in the mid-1980s. In order to realize and implement the 165 Needham-Schroeder protocol, a number of constructs were added to the 166 basic Needham-Schroeder protocol to create Kerberos. Notable among 167 these additions were the Kerberos ticket, and later the Ticket 168 Granting Service (TGS) as a separate function from the Authentication 169 Server (AS) within the Key Distribution Center (KDC). The Kerberos 170 V5 protocol was defined in 1993 within RFC1510 (obsoleted), with the 171 current authoritative definition being RFC4210. 173 Kerberos is one of the few symmetric key based authentication 174 protocols that has been well studied and scrutinized over the last 175 two decades. The security of Kerberos in founded on the sharing of 176 long-term symmetric keys (pair-wise between entities) and the usage 177 of shorter term session keys between the Client and the Service. In 178 summary, the Client and the KDC share a pair-wise unique symmetric 179 key (long-term) that is used by both parties to communicate with data 180 confidentiality and perform authentication based on proof-of- 181 possession (POP) the correct keys. When a Client seeks to access 182 services or resources at the Server, the Client must request a 183 Service Ticket to the KDC specifically designated for the target 184 Server. In order to prove to the Server that the Client is 185 authorized by the KDC to access the Server, the KDC generates a 186 Session Key and delivers it in an encrypted fashion to the Client and 187 Server (using their respective long-term keys which they share pair- 188 wise with the KDC). When seeking access to the Server, the Client 189 must prove possession of the session-key (to the Server) by 190 encrypting a so called Authenticator structure using that session-key 191 and sending it to the Server with the request. Successful decryption 192 of the Authenticator structure by the Server indicates to the Server 193 that the requestor is a legitimate Client who has been authenticated 194 previously by the KDC. Here the Client must actually excersize its 195 copy of the session-key to prove POP. In this manner, Kerberos is 196 different from bearer-token protocols in which the client needs only 197 present a token that was previously created by another entity. 199 2.2. Terminology 201 In this section we briefly summarize some of the terminology commonly 202 used in the Kerberos literature, while providing the approximate 203 OAuth 2.0 equivalent: 205 Client A process that makes use of a service or resource on behalf 206 of a user. Note that in some cases a Server may itself be a 207 client of some other server (e.g., a print server may be a 208 client of a file server). 210 Authentication Server (AS) Authentication Server (AS) The service 211 operating within the Key Distribution Center (KDC) that 212 authenticates the client based on symmetric key cryptography. 213 The client and the AS shares a long-term secret (long term 214 symmetric key). The AS issues the client with a Ticket 215 Granting Ticket (TGT) intended for a specific TGS (i.e. 216 decipherable only by the intended TGS). The matching 217 function in OAuth 2.0 is that of the token endpoint in the 218 Authorization Server that issues the initial Access Token. 220 Authenticator A Kerberos record or structure containing information 221 that can be shown to have been recently generated using the 222 session key known only (shared) by the client and server. In 223 Kerberos the authenticator is one way the client proves to 224 the server that the client is in possession of the correct 225 session key. 227 Ticket Granting Server (TGS) The service operating within the Key 228 Distribution Center (KDC) that authenticates a client based 229 on (a) the client's presentation of a legitimate Ticket 230 Granting Ticket (TGT) issued by the AS and (b) the client's 231 proof-of-possession of the correct symmetric key (used by the 232 client to create the Authenticator portion of the TGS 233 Request). The matching function in OAuth 2.0 is that of the 234 token endpoint in the Authorization Server that issues the 235 Refresh Token. 237 Key Distribution Center (KDC) A Kerberos service that is comprised 238 of the Authentication Server (AS) and Ticket Granting Server 239 (TGS). The combined Kerberos AS and TGS could be matched to 240 the OAuth 2.0 Authorization Server, where the TGS matches 241 more closely the Refresh Token issuing function of the 242 Authorization Server. 244 Principal A uniquely named client or server instance that 245 participates in a network communication. 247 Server (or Kerberos Server) A particular Principal which provides a 248 service or resource to clients. In OAuth 2.0 this is the 249 Resource Server. 251 Session Key A temporary encryption key used between two principals, 252 with a lifetime limited to the duration of a single Kerberos 253 "session". 255 Sub-session Key A temporary encryption key used between two 256 principals, selected and exchanged by the principals using 257 the session key, and with a lifetime limited to the duration 258 of a single association. 260 Ticket A record or data structure that helps a client authenticate 261 itself to a server. It contains the client's identity, a 262 session key, a timestamp and other information, all of which 263 are sealed using the server's secret key. The term "service 264 ticket" is often used to distinguish from the Ticket- 265 Granting-Ticket (TGT) which is consumable only by the Ticket 266 Granting Server (TGS). A ticket only serves to authenticate 267 a client to a service when presented along with a fresh 268 Authenticator. In OAuth 2.0 the closest structure to a 269 ticket is the Access Token and Refresh Token, together with 270 parameters accompany the token when transmitted. 272 2.3. Overview of the Kerberos (V5) protocol 274 The basic purpose of Kerberos is to provide access control of a 275 client (user or host) to a service or resource. To simplify the 276 current description, we will use the term "client" to mean the entity 277 associated with the symmetric key shared with the Authentication 278 Server (though the intent is clear that both human users and host 279 computers can in fact be Kerberos principals). 281 The following summarizes the main message flows within Kerberos: 283 (A) Authentication Request (AS_REQ) 284 The Authentication Request (AS_REQ) message is sent by the 285 Kerberos Client to the Authentication Server (AS) within the 286 KDC. 288 (B) Authentication Response (AS_REP) 289 The AS/KDC returns a response (AS_REP) message to the Client 290 that contains the encrypted Service Ticket and the encrypted 291 AS Response Part. These two parts contain the session-key 292 that the Client and Service (Resource Server) will later use 293 to secure their session. 295 (C) Service Request (AP_REQ) 296 The Client constructs the Authenticator structure that it 297 encrypts using the session-key (obtained in the previous 298 step). This Authenticator provides proof-of-possession (of 299 the session-key) to the Service (Resource Server). The 300 Client delivers both the Service Ticket (unmodified from the 301 previous step) and the Authenticator within the AP_REQ 302 message. 304 (D) Service Response (AP_REP) 305 The Service (Resource Server) obtains the AP_REQ message, 306 decrypts the Session Ticket (created by the KDC) and extracts 307 the session-key. It then uses the session-key to verify the 308 Authenticator structure. 310 (E) Optional Ticket-Granting Service Request (TGS_REQ) 311 In order to prevent the Client from having to authenticate 312 repeatedly to the KDC (e.g. due to short-life tickets), the 313 Client can request a Ticket-Granting-Ticket (TGT) from the 314 Ticket Granting Service (TGS), which is a special service 315 operating at the KDC. 317 (F) Optional Ticket-Granting Service Response (TGS_REP) 318 If the TGS_REQ message is used, the TGS (instead of the AS) 319 will return the Service Ticket destined for a given Service 320 (Resource Server). Note that the Service Ticket life is 321 shorter than the TGT life. 323 +---------------------+ 324 | KDC | 325 +--------+ | +---------------+ | 326 | |--(A)------ Authentication ----|->|Authentication | | 327 | | Request (AS_REQ) | | Server (AS) | | 328 | |<-(B)------ Authentication ----|--| | | 329 | | Response (AS_REP) | +---------------+ | 330 | | | | 331 | | | +---------------+ | 332 | |--(E)------ TGS Request -------|->| Ticket | | 333 | Client | (TGS_REQ) optional | | Granting | | 334 | |<-(F)------ TGS Response ------|--| Server (TGS) | | 335 | | (TGS_REP) optional | +---------------+ | 336 | | +---------------------+ 337 | | 338 | | +---------------+ 339 | |--(C)------ Service Request ----->| Service or | 340 | | (AP_REQ) | Resource | 341 | |<-(D)------ Service Response - ---| Server | 342 | | (AP_REP) +---------------+ 343 +--------+ 345 Figure 1 347 2.3.1. Advantages and disadvantages of the Kerberos paradigm 349 As an authentication protocol based on symmetric key cryptography, 350 there a number of advantages as well as inherent limitations of 351 Kerberos: 353 o Limited impact of key compromise: The compromise of a client or 354 server (or the keys in these entities) impacts only these 355 entities. Other clients and servers are not impacted since they 356 share a unique key with the KDC. 358 o Speed of cryptographic operations: One of the original motivations 359 behind Kerberos was the desire to use symmetric key ciphers due to 360 their significant performance over public key ciphers. 362 o Cross realm/domain authentication: Kerberos v5 addressed the 363 requirement of cross-realm authentication and authorization by the 364 introduction of cross-realm tickets. This provides the advantage 365 of scaling Kerberos across realms (within one administrative 366 boundary) and across realms in differing administrative 367 boundaries. 369 o Delegation: Kerberos v5 addressed supports the notion of 370 delegation through the use of special tickets (refered to as 371 proxiable tickets and forwardable tickets). In essence, 372 delegation in Kerberos allows a Client to name another entity 373 (e.g. a Server) within a ticket-request (to the KDC) with the 374 explicit intent of allowing that entity to later request service- 375 tickets in the name of the Client. Delegation can also be used to 376 realize the notion of "transitive-trust" that may cross domain 377 boundaries. 379 o Compromise of KDC impacts other entities: Since the KDC shares a 380 symmetric key pair-wise with every entity in the system (clients 381 and server), the compromise of the KDC and the keys stored at the 382 KDC renders the entire system compromised. Thus, additional 383 security is required for keys stored at the KDC. Additional 384 precautions, such as separating the Authentication Server (AS) 385 into a more secure computing environment may reduce the risks 386 associate with attacks. 388 o Initial key establishment problem: Similar to many symmetric key 389 based authentication protocols, Kerberos requires initial key 390 establishment between a Client and the KDC, and between a Server 391 and the KDC. Several methods to establish the initial shared key 392 between entities have been proposed. These are referred to as 393 "pre-authentication" protocols in the Kerberos literature, and 394 includes a password-based method (defined as part of RFC4210), a 395 public-key based approach (PKINIT [RFC4556]) using the Diffie- 396 Hellman or RSA cryptosystems) as well as One-Time-passwords or 397 tokens (draft-ietf-krb-wg-otp-preauth-10). 399 3. Functional Comparison of OAuth 2.0 and Kerberos V5 401 In this section we compare the intent/purpose of the OAuth 2.0 402 messages against those in Kerberos V5. The aim here is to understand 403 the semantic similarities between OAuth 2.0 and Kerberos, and 404 identifying the gaps needing solutions in order for OAuth 2.0 to 405 support Kerberos V5. Another aspect of this exercise is also to 406 understand the design decisions of Kerberos V5 over the last two 407 decades, hopefully to inform a better design to OAuth 2.0 and other 408 new protocols in the future. 410 3.1. Client Authentication 412 3.1.1. OAuth Client Authentication Request 414 The OAuth 2.0 protocol caters for a number of use-cases, though in 415 many of these scenarios there are some common fundamental parameters 416 that are being exchanged with the Authorization Server. 418 In the Client Authentication exchange the token endpoint at the 419 Authorization Server requires the client to provide the client 420 identifier (client_id) and the optional client secret 421 (client_secret). These two parameters can be delivered using a 422 simple HTTP POST message or using an HTTP authentication scheme. How 423 the client obtains these credentials are outside the scope of the 424 OAuth 2.0 specification. Additional parameters thar are communicated 425 between the client and Authorization server: 427 o Type of authentication (user_agent, web_server, device_code, 428 username, client_credentials, assertion or refresh). 430 o Client identity (client_id) 432 o Client secret (client_secret) 434 o Server identity (Host name) 436 o Transport mechanism (e.g. HTTP POST) 438 o Encoding method or content type (e.g. urlencoded) 440 The OAuth 2.0 specification, however, considers as out-of- scope the 441 method used by the Authorization Server to authenticate the end-user. 442 As such, the current OAuth 2.0 specification could be considered more 443 as a framework for authentication and authorization, which needs to 444 be instantiated with a specific authentication mechanism/method and 445 which would therefore necessitate bindings to specific transports. 447 3.1.2. Kerberos Client Authentication Request 449 In Kerberos, the client initiates an authentication request by 450 sending the AS_REQ message to the Authentication Server (AS). 451 Ignoring for the moment the format of the AS_REQ message, the client 452 sends the following parameters to the AS: 454 o Message type 456 o Kerberos protocol version number (v5) 458 o Pre-authentication data (optional) 460 o Client principal name 462 o Client's realm 463 o KDC principal name) 465 o Start-time of requested ticket (optional) 467 o Expiration time of requested ticket 469 o Nonce generated by the client 471 o Encryption algorithm desired 473 o Client host address (optional) 475 o Additional tickets (optional) 477 In Kerberos the client has the option of selecting the lifetime of 478 tickets, though the KDC can set the upper bounds of the lifetimes 479 according to some predefined policy. The client has to explicitly 480 choose a unique random nonce for the purposes of detecting replays of 481 the responses coming from the KDC. 483 Although RFC4120 allows the Kerberos authentication request message 484 to be sent in clear text, in practice it is beneficial to protect 485 this message from unauthorized modifications in-transit. Similar to 486 OAuth, the request could be sent over a secure channel such as TLS/ 487 SSL or within some tunneling mechanism (e.g. FAST tunnel). 489 3.2. Access Token Response 491 3.2.1. OAuth Access Token Response 493 In OAuth 2.0 the access token response from the Authorization Server 494 caries a number of parameters explicitly and implicitly (Section 495 3.3.2.1): 497 o Access Token 499 o Duration of token (expires in seconds) 501 o Optional Refresh Token 503 o Access Token Secret (optional, determined by client) 505 o Scope 507 o Transport mechanism (e.g. HTTP 1.1) 509 o Encoding method or content type (e.g. app/json) 510 The OAuth 2.0 specification currently does not specify the sizes of 511 tokens and other values received from the Authorization Server (OAuth 512 2.0 Specification draft-05, Section 3.4). 514 3.2.2. Kerberos Service Ticket 516 The Kerberos v5 equivalent to the OAuth 2.0 Access Token is that of 517 the Service Ticket. The client can obtain a Service Ticket directly 518 from the KDC using the Authentication Request (AS_REQ) message. The 519 response coming back from the KDC contains a number of relevant 520 parameters: 522 o Message type 524 o Kerberos protocol version number (v5) 526 o Pre-authentication data (optional) 528 o Client principal name 530 o Client's realm 532 o Service Ticket (encrypted structure) 534 o Response Part (encrypted structure) 536 The two important structures inside the Kerberos response message are 537 the Response Part structure that is intended for the Client, and the 538 Service Ticket (ST) structure which the Client must forward 539 unmodified to the Server (or Resource Server). Generally each of 540 these structures carry a number of parameters in-turn, including (a) 541 the identities of the Client and Server, (b) the lifetime of the 542 Ticket and (c) the Session-Key to be used by the Client in requesting 543 service or access to the Server (Resource Server). 545 Here, an important security feature is that the Response Part 546 structure (containing the Session-Key) is encrypted by the KDC using 547 the long-term key it shares with the Client. This ensures that only 548 the authenticated Client can decrypt the Response Part and make use 549 of the contained Session-Key. Similarly, the important parameters 550 within the Service Ticket structure is encrypted by the KDC using the 551 long term key it shares with the Server (i.e. Resource Server). 552 This ensures that only the Client and Server know the given Session- 553 Key, and thus allows the Server to later recognize an authentic 554 service request from the Client (encrypted by the Client using that 555 very same Session-Key). 557 In comparing the OAuth Access Token Response message with the 558 Kerberos authentication response message containing a Service Ticket, 559 there are a number of interesting aspects: 561 a. OAuth Access Token Secret vs Kerberos Session-Key: The OAuth 2.0 562 specification (draft-05) allows Clients to make authenticated 563 protected resource requests using an access token with a matching 564 secret by calculating a set of values and including them in the 565 request using the "Authorization" header field. The OAuth 2.0 566 specification defines the "hmac-sha256" algorithm to verify this 567 secret. 569 In contrast, in Kerberos the Session-Key is used by the Client to 570 encrypt (not hash) the Authenticator structure that the Client 571 creates. The encrypted Authenticator structure is then sent 572 together with the Service Ticket (obtained from the KDC in the 573 prior step) to the Server (or Resource Server). 575 Kerberos uses encryption instead of hashing only die to the 576 sensitivity of the parameters exchanged between the Client and 577 KDC, and between the Client and Server. 579 b. Selectable Ciphers and Hash Functions: Kerberos supports various 580 ciphers and hash functions as negotiated upon between the Client 581 and KDC at the initial authentication request. 583 3.3. Resource Access Request 585 Once the Client obtains an OAuth 2.0 Access Token, it delivers the 586 Access Token to the Resource Server within an HTTP Request message. 587 OAuth supports a number of use-cases which it supports (User-Agent 588 Flow, Web Server Flow, Device Flow, Username/Password Flow, Client 589 Credential Flow and Assertion Flow). These use-cases are in fact 590 distinct from the fundamental authentication feature of OAuth 2.0 591 based on Access Tokens. The use-cases address the various deployment 592 scenarios and technologies that are available today to implement 593 them. 595 In Kerberos, in order to access the Server the Client must present 596 both the Authenticator (created by the Client) and the Service Ticket 597 (created by the KDC). These two structures when combined allow the 598 Server (or Resource Server) to establish that the Client has been 599 authenticated by the KDC. The Server does not have to interact with 600 the KDC when validating the Service Ticket. 602 3.4. Refresh Token 604 In OAuth 2.0 the token refresh is used when the lifetime of an access 605 token is shorter than the lifetime of the authorization grant 606 (Section 4). It allows clients to obtain a new access token without 607 having to go through the OAuth authorization flow again (to the 608 Authorization Server) or involve the resource owner. 610 The relevant parameters of the OAuth 2.0 Refresh Token request 611 message are as follows: 613 o Type of authentication (set to "refresh") 615 o Client identity (client_id) 617 o Client secret (if client issued a secret) 619 o Refresh Token (refresh_token) 621 o Secret Type (optional, defaults to bearer token if there is no 622 secret) 624 o Response format (one of "json", "xml", or "form"). 626 In Kerberos, in order to avoid the Client from having to authenticate 627 to the KDC each time it wishes to access a Server, the Client must 628 first obtain a Ticket Granting Ticket (TGT) from the Ticket Granting 629 Service (TGS) operating in the KDC. The Client then uses the TGT 630 each time it requests a Service Ticket to access the Server. This 631 can be done as a system process, without the need to prompt the user. 632 In this sense, the Refresh Token is identical in purpose to the 633 Kerberos TGT. 635 The message structure of the TGT request message is identical to the 636 message structure of a Service Ticket request. Indeed, in Kerberos 637 the Ticket Granting Service (TGS) is viewed in the same manner as the 638 services offered by any Kerberos Server. 640 In Kerberos the AS Response (AS_REP) message carries a number of 641 parameters, including those intended for consumption by the Ticket 642 Granting Service (TGS). These are summarized as follows: 644 o Message type 646 o Kerberos protocol version number (v5) 648 o Pre-authentication data (optional) 650 o Client principal name 652 o Client's realm 653 o Ticket Granting Ticket (encrypted structure) 655 o AS Response Part (encrypted structure) 657 The two important structures inside the AS_REP message are the AS 658 Response Part structure that is intended for the client, and the 659 Ticket Granting Ticket (TGT) structure which the client must forward 660 unmodified to the Ticket Granting Service. Each of these structures 661 carry a number of parameters in-turn, including (a) the identities of 662 the client, TGS and Server, (b) the lifetime of the TGT and (c) the 663 Session-key to be used by the Client in requesting the Service Ticket 664 to the TGS. 666 Here, an important security feature is that the AS Response Part 667 structure (containing a session-key) is encrypted by the AS using the 668 long-term key it shares with the client. This ensures that only the 669 authenticated client can decrypt the AS Response Part and make use of 670 the contained session- key. Similarly, the important parameters 671 within the TGT structure is encrypted by the AS using the long term 672 key it shares with the TGS entity. This ensures that only the client 673 and TGS know the given session-key, and thus allows the TGS to later 674 recognize an authentic Service Ticket request from the client 675 (encrypted by the client using that very same session-key). 677 It is important to note that obtaining a TGT is optional in Kerberos, 678 and the client can in fact request a Service Ticket directly from the 679 AS by simply designating the identity of the Server in the AS Request 680 message. This may prove cumbersome in practice, since the client may 681 need to newly authenticate itself to the AS each time it seeks to 682 access the Server. 684 3.5. Conclusions and Recommendations 686 In this section we offer some observations and recommendations 687 regarding OAuth 2.0, in the light of the various lessons learned from 688 the development of the Kerberos authentication protocol over the last 689 couple of decades: 691 [1] Refresh Tokens and Access Tokens 692 In Kerberos, the introduction of the Ticket Granting Service 693 (TGS) as a special service on the KDC was done to address the 694 issue of the end-user having to re-authenticate each time the 695 user wanted to access the server (resource server). In 696 practice, Kerberos is almost always deployed using the TGS 697 where the TGT has a longer lifetime compared to the service- 698 tickets requested using a given TGT. 699 In OAuth the cases for using a Refresh Token (as a means to 700 extend the life of the Access Token) needs to be made clear 701 and explicit. Furthermore, Refresh Tokens need to be 702 provably related to its parent Access Token, in such a way 703 that a third-party entity (e.g. auditor) can verify the 704 sequence of events/messages that has been logged by the 705 Resource Server. 707 [2] Support for multiple authentication methods 708 The current OAuth specification (draft-05) does not specify 709 other authentication protocols beyond username/password 710 (presumably within an HTML form over SSL). In order to gain 711 broad adoption in various organizations, and to gain usage in 712 higher assurance environments, OAuth needs to support other 713 means of authentication beyond username/passwords. 715 [3] Delegation support 716 A key feature of Kerberos that is used extensively in some 717 deployments is delegation (or "constrained delegation" in the 718 Kerberos literature). In Kerberos delegation is expressed 719 using proxiable tickets and forwardable tickets, where a 720 Kerberos client can request a ticket within which the client 721 can explicitly name a server who will act as a delegate. 722 This server will in-turn request service ticket on behalf of 723 the client. Although delegation is not explicitly supported 724 as a feature in the current OAuth 2.0 specification 725 (draft-05) one could conceivably introduce the notion of a 726 "delegation access token" that implements the same function 727 as that in Kerberos. 729 4. An OAuth 2.0 Profile for Kerberos (DRAFT) 731 In this section we propose a "profile" of OAuth 2.0 for Kerberos that 732 provides one approach for interoperability between OAuth2.0 and 733 Kerberos. In this approach, the Kerberos messages are delivered 734 using OAuth as a mechanism of transport between the relevant Kerberos 735 entities. 737 A key aspect of this proposal is the representation of the Kerberos 738 messages in the form of GSS-Tokens as defined in RFC2743 and RFC4121. 739 This provides opaqueness of the Kerberos messages to the higher layer 740 applications, which in this case are the OAuth entities operating at 741 the HTTP layer. 743 4.1. Design Assumptions 744 4.1.1. Separation of Kerberos functions from OAuth functions 746 Since one of the main goals of OAuth 2.0 is to provide simplicity to 747 the end-user, one of the design assumptions here is that the creation 748 and consumption of Kerberos is performed by Kerberos entities (or 749 components) that are distinct from OAuth entities. Thus, for 750 example, although the OAuth Authorization Server could also be 751 implemented as an enhanced Kerberos KDC, we assume that the KDC is 752 distinct from the Authorization Server. 754 This architectural separation allows organizations already deploying 755 a Kerberos infrastructure to layer OAuth as front- end service for 756 authenticating users and OAuth clients, following the use-cases 757 defined in the OAuth specification (Section 2.2 of draft-05). 759 4.1.2. Opaqueness of Kerberos Messages 761 Following the approach used by HTTP-Negotiate (RFC4559) which 762 introduced a new auth-scheme based on the SPNEGO GSSAPI-Tokens, in 763 this document we also propose the use the GSSAPI-Tokens (RFC2743) for 764 all Kerberos messages that will be over (through) through OAuth 765 messages. The GSSAPI-Tokens is assumed to be encoded in some HTTP- 766 friendly manner (e.g. Base64 encoded). 768 The approach of using Kerberos GSSAPI-Tokens (RFC4121) is also used 769 in the Web Services Security standard, notably in the WSS Kerberos 770 Token Profile 1.1 [WSS-Kerberos]. There the Kerberos AP_REQ message 771 (wrapped GSS-Token) is delivered by a client to a service over WSS 772 (over SOAP). 774 4.1.3. Resource Server as a Service Principal 776 In orde to achieve some degree of interoperability, we assume that 777 the OAuth Resource Server is also a service principal in the 778 traditional Kerberos sense. This means (among others) that (a) the 779 Resource Server shares a long-term key with the KDC, and (b) that it 780 is able to consume and process Service Tickets in the usual Kerberos 781 manner. How a Resource Server implements the Kerberos Service is 782 outside the scope of the OAuth 2.0 specification and of this current 783 document. 785 4.2. OAuth-Kerberos Architecture Overview 787 The overall architecture underlying the OAuth 2.0 profile for 788 Kerberos is shown in Figure 2. 790 +--------+ +---------+ +------+ 791 | |--(A)----- Credentials ---->| | | | 792 | | (w. opaque AS_REQ) | <-|-|-> | 793 | |<-(B)----- Access Token -----| OAuth | | | 794 | | (w. opaque AS_REP) | Authzn | | KDC | 795 | | | Server | | | 796 | | | | | | 797 | OAuth |--(E)----- Refresh Token ----->| | | | 798 | Client | (w. opaque TGS_REQ) | <-|-|-> | 799 | |<-(F)----- New Access Token ---| | | | 800 | | (w. opaque TGS_REP) +---------+ +------| 801 | | 802 | | +---------------+ 803 | |--(C)--HTTP Req w. Access Token-->| Service or | 804 | ^ | (w. opaque AP_REQ) | Resource | 805 | | |<-(D)----- HTTP Response ---------| Server | 806 +---|----+ (w. opaque AP_REP) +---------------+ 807 | v | 808 | | 809 | Kerb. | 810 | Client | 811 +--------+ 813 Figure 2 815 The Kerberos client is assumed to be present in the underlying 816 operating system, within the browser or as part of the web 817 application. Similar to the case of HTTP-Negotiate in which the 818 browser performs a call to the underlying Kerberos client, in this 819 case we assume that the OAuth Client is able to perform a similar 820 call. The details of this are outside the scope of OAuth and of the 821 current document. 823 4.3. OAuth-Kerberos Message Flows 825 The proposed approach makes use of the existing OAuth message flow, 826 with some modification in the contents of some of the OAuth (opaque) 827 parameters. 829 4.3.1. Client Requests Access Token 831 The OAuth client provides the user credentials to the Authorization 832 Server. As part of the message construction, the OAuth Client 833 obtains an opaque AS_REQ message from the underlying Kerberos Client. 834 The OAuth client then constructs the usual OAuth request with the 835 following parameters: 837 o secret_type: The secret_type value is set to "Kerberos-v5. 839 o client_id: The client_id parameter is set to the Kerberos client 840 principal name 842 o client_secret: The client_secret contains a string which a 843 concatenation of the string "KRB_AS_REQ" with the string 844 representation of the GSS-Token of the actual AS_REQ message. 845 Thus: client_secret = "KRB_AS_REQ|apaquegsstoken1". 847 4.3.2. Access Token Response 849 The Authorization Server processes the received request in the usual 850 OAuth manner. Upon detecting that the secret_type being 851 "kerberos-v5", it passes the opaque portion of the client_secret to 852 the back-end Kerberos KDC. 854 Upon successful authentication of the user by the KDC, the KDC 855 constructs an AS_REP message in the GSS-Token format and encodes into 856 an opaque string. The KDC then passes the string to the OAuth 857 Authorization Server. 859 The OAuth Authorization Server returns the following parameters to 860 the OAuth Client: 862 o secret_type = "kerberos-v5" 864 o access_token = "KRB_AS_REP|apaquegsstoken2" 866 Note that since the Kerberos TGS is not used in this scenario, the 867 AS_REP message from the KDC contains a Service Ticket destined for 868 the Resource Server. 870 4.3.3. Client Accesses Resource Server 872 Upon detecting that the secret_type is set to "Kerberos-v5", the 873 OAuth client passes the opaque portion to the underlying Kerberos 874 Client. 876 The Kerberos Client then constructs an AP_REQ message in the GSS- 877 Token format and encodes into an opaque string. The Kerberos Client 878 then passes the string to the OAuth Client, which in turn constructs 879 the request to the Resource Server with the following parameters: 881 o secret_type = "kerberos-v5" 883 o access_token = "KRB_AS_REP|apaquegsstoken2" (from previous step) 884 o client_secret = "KRB_AP_REQ|apaquegsstoken3" 886 Note that the Kerberos Authenticator and Service Ticket is in fact 887 contained within the client_secret. The Access Token is delivered to 888 the Resource Server for the purposes of: (a) to allow the Server to 889 verify the Service Ticket within the access_token is identical to 890 that in the client_secret, (b) to allow the Server to cache the 891 access_token for future access by the OAuth Client, and (c) to allow 892 the Server to perform logging as part of audit tracking. 894 5. Kerberized Token Exchange Service 896 TBD 898 6. Acknowledgements 900 TBD 902 7. IANA Considerations 904 TBD 906 8. Security Considerations 908 TBD 910 All drafts are required to have a security considerations section. 911 See RFC 3552 [RFC3552] for a guide. 913 9. References 915 9.1. Normative References 917 [Needham-Schoeder] 918 Needham, Roger. and Michael. Schoeder, "Using encryption 919 for authentication in large networks of computers, 920 Communications of the ACM 21 (12)", 1978. 922 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 923 Kerberos Network Authentication Service (V5)", RFC 4120, 924 July 2005. 926 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 927 Kerberos and NTLM HTTP Authentication in Microsoft 928 Windows", RFC 4559, June 2006. 930 9.2. Informative References 932 [MIT-Athena] 933 Steiner, J., Neuman, B., and J. Schiller, "Kerberos: An 934 Authentication Service for Open Network Systems. In 935 Proceedings of the Winter 1988 Usenix Conference. 936 February.", 1988. 938 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 939 Authentication Service (V5)", RFC 1510, September 1993. 941 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 942 Requirement Levels", BCP 14, RFC 2119, March 1997. 944 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 945 Text on Security Considerations", BCP 72, RFC 3552, 946 July 2003. 948 [WSS-Kerberos] 949 Oasis-Open, "Web Services Security: Kerberos Token Profile 950 1.1", 2006, . 954 Appendix A. Additional Stuff 956 This becomes an Appendix. 958 Author's Address 960 Thomas Hardjono (editor) 961 MIT Kerberos Consortium 962 77 Massachussetts Avenue W92-152 963 Cambridge, MA 02139 964 US 966 Email: hardjono@mit.edu