idnits 2.17.1 draft-hardjono-oauth-kerberos-01.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 (December 8, 2010) is 4881 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 158, but not defined == Missing Reference: 'RFC4556' is mentioned on line 390, but not defined -- Looks like a reference, but probably isn't: '1' on line 685 -- Looks like a reference, but probably isn't: '2' on line 701 -- Looks like a reference, but probably isn't: '3' on line 710 == Unused Reference: 'Needham-Schoeder' is defined on line 840, but no explicit reference was found in the text == Unused Reference: 'RFC4120' is defined on line 845, but no explicit reference was found in the text == Unused Reference: 'MIT-Athena' is defined on line 855, but no explicit reference was found in the text == Unused Reference: 'RFC1510' is defined on line 861, 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 December 8, 2010 5 Expires: June 11, 2011 7 OAuth 2.0 support for the Kerberos V5 Authentication Protocol 8 draft-hardjono-oauth-kerberos-01 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 June 11, 2011. 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 5. Kerberized Token Exchange Service . . . . . . . . . . . . . . 18 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 84 Appendix A. Document History . . . . . . . . . . . . . . . . . . 20 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Introduction 89 There are a number of reasons why Oauth 2.0 support for the Kerberos 90 protocol would be useful to the security industry. First, there is a 91 large degree of similarity at the protocol design level and intended 92 functions between Oauth 2.0 and Kerberos. There is also strong 93 similarities in the entities involved in OAuth2.0 and Kerberos, 94 albeit OAuth focuses on the application layer (above the HTTP layer). 95 Access to a service requires the client to obtain an Access Token (or 96 Service Ticket in Kerberos), while the Refresh Token (or Ticket 97 Granting Ticket in Kerberos) is used to limit the number of re- 98 authentications by the user seeking to use the same service. 100 Secondly, easily upwards of 60% of medium to large Enterprises today 101 use the Kerberos protocol in one form or another (proprietary 102 implementations or open source), for various authentication 103 requirements. These range from user-logons at the operating system 104 level, to Web-SSO and to server-to-server authentication at the 105 backend infrastructure. Support for Kerberos is built into various 106 operating systems and open-source distributions (e.g. Windows, 107 RedHat, Open Solaris, Ubuntu, etc), and the majority of browsers 108 support some Kerberos functions. Allowing organizations to place 109 Outh 2.0 servers as a front-end layer allows them to further re-use 110 their existing Kerberos infrastructure, thereby allowing easier 111 adoption of Oauth 2.0 within these organizations. 113 Thirdly, there are a number similarities in intended functions 114 between Kerberos and OAuth 2.0. Any OAuth 2.0 function that can re- 115 use Kerberos functionality and code may provide the developer with 116 faster development time. 118 Finally, interoperability between OAuth2.0 and Kerberos is highly 119 desired from a deployment perspective. There are a number of ways to 120 achieve such interoperability. For example, OAuth2.0 opaque tokens 121 and other structures can be used to transport Kerberos messages. 122 Transporting or tunneling Kerberos above other protocols is not a new 123 idea. Various other protocols have previously been used to transport 124 Kerberos message structures opaquely in order to satisfy certain 125 security and deployment constraints. Examples include Kerberos 126 within HTTP-Negotiate [RFC4559] and Kerberos over Web Services 127 Security (over SOAP)[WSS-Kerberos]. 129 The aim of this draft is to identify and define mechanisms that would 130 allow a high degree of interoperability between OAuth 2.0 and 131 Kerberos. As such, it is not the intent of the current work to 132 replace OAuth 2.0, but instead to allow organizations to deploy OAuth 133 2.0 compliant Authorization Servers and Resource Servers, while 134 retaining (and value-adding to) their Kerberos infrastructure in the 135 back-end. 137 In the next section we will provide an overview of the Kerberos (v5) 138 protocol. The text of the discussion is intentionally kept at the 139 same level of abstraction as the Oauth 2.0 Framework specification. 140 This is to avoid the reader from having to read through RFC4120 and 141 to avoid the discussion from diving into the specific details and 142 constraints of RFC4120. The interested reader is directed to RFC4120 143 for the details of the Kerberos authentication protocol. 145 1.1. Requirements Language 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 151 2. Background: Kerberos protocol (v5) 153 2.1. History of Kerberos 155 The Kerberos authentication protocol [REF] was one of the earliest 156 authentication protocols based purely on symmetric key cryptography. 157 Founded on the Needham-Schroeder protocol [REF], Kerberos was 158 designed as the authentication mechanism within Project Athena [REF] 159 at MIT in the mid-1980s. In order to realize and implement the 160 Needham-Schroeder protocol, a number of constructs were added to the 161 basic Needham-Schroeder protocol to create Kerberos. Notable among 162 these additions were the Kerberos ticket, and later the Ticket 163 Granting Service (TGS) as a separate function from the Authentication 164 Server (AS) within the Key Distribution Center (KDC). The Kerberos 165 V5 protocol was defined in 1993 within RFC1510 (obsoleted), with the 166 current authoritative definition being RFC4210. 168 Kerberos is one of the few symmetric key based authentication 169 protocols that has been well studied and scrutinized over the last 170 two decades. The security of Kerberos in founded on the sharing of 171 long-term symmetric keys (pair-wise between entities) and the usage 172 of shorter term session keys between the Client and the Service. In 173 summary, the Client and the KDC share a pair-wise unique symmetric 174 key (long-term) that is used by both parties to communicate with data 175 confidentiality and perform authentication based on proof-of- 176 possession (POP) the correct keys. When a Client seeks to access 177 services or resources at the Server, the Client must request a 178 Service Ticket to the KDC specifically designated for the target 179 Server. In order to prove to the Server that the Client is 180 authorized by the KDC to access the Server, the KDC generates a 181 Session Key and delivers it in an encrypted fashion to the Client and 182 Server (using their respective long-term keys which they share pair- 183 wise with the KDC). When seeking access to the Server, the Client 184 must prove possession of the session-key (to the Server) by 185 encrypting a so called Authenticator structure using that session-key 186 and sending it to the Server with the request. Successful decryption 187 of the Authenticator structure by the Server indicates to the Server 188 that the requestor is a legitimate Client who has been authenticated 189 previously by the KDC. Here the Client must actually excersize its 190 copy of the session-key to prove POP. In this manner, Kerberos is 191 different from bearer-token protocols in which the client needs only 192 present a token that was previously created by another entity. 194 2.2. Terminology 196 In this section we briefly summarize some of the terminology commonly 197 used in the Kerberos literature, while providing the approximate 198 OAuth 2.0 equivalent: 200 Client A process that makes use of a service or resource on behalf 201 of a user. Note that in some cases a Server may itself be a 202 client of some other server (e.g., a print server may be a 203 client of a file server). 205 Authentication Server (AS) Authentication Server (AS) The service 206 operating within the Key Distribution Center (KDC) that 207 authenticates the client based on symmetric key cryptography. 208 The client and the AS shares a long-term secret (long term 209 symmetric key). The AS issues the client with a Ticket 210 Granting Ticket (TGT) intended for a specific TGS (i.e. 211 decipherable only by the intended TGS). The matching 212 function in OAuth 2.0 is that of the token endpoint in the 213 Authorization Server that issues the initial Access Token. 215 Authenticator A Kerberos record or structure containing information 216 that can be shown to have been recently generated using the 217 session key known only (shared) by the client and server. In 218 Kerberos the authenticator is one way the client proves to 219 the server that the client is in possession of the correct 220 session key. 222 Ticket Granting Server (TGS) The service operating within the Key 223 Distribution Center (KDC) that authenticates a client based 224 on (a) the client's presentation of a legitimate Ticket 225 Granting Ticket (TGT) issued by the AS and (b) the client's 226 proof-of-possession of the correct symmetric key (used by the 227 client to create the Authenticator portion of the TGS 228 Request). The matching function in OAuth 2.0 is that of the 229 token endpoint in the Authorization Server that issues the 230 Refresh Token. 232 Key Distribution Center (KDC) A Kerberos service that is comprised 233 of the Authentication Server (AS) and Ticket Granting Server 234 (TGS). The combined Kerberos AS and TGS could be matched to 235 the OAuth 2.0 Authorization Server, where the TGS matches 236 more closely the Refresh Token issuing function of the 237 Authorization Server. 239 Principal A uniquely named client or server instance that 240 participates in a network communication. 242 Server (or Kerberos Server) A particular Principal which provides a 243 service or resource to clients. In OAuth 2.0 this is the 244 Resource Server. 246 Session Key A temporary encryption key used between two principals, 247 with a lifetime limited to the duration of a single Kerberos 248 "session". 250 Sub-session Key A temporary encryption key used between two 251 principals, selected and exchanged by the principals using 252 the session key, and with a lifetime limited to the duration 253 of a single association. 255 Ticket A record or data structure that helps a client authenticate 256 itself to a server. It contains the client's identity, a 257 session key, a timestamp and other information, all of which 258 are sealed using the server's secret key. The term "service 259 ticket" is often used to distinguish from the Ticket- 260 Granting-Ticket (TGT) which is consumable only by the Ticket 261 Granting Server (TGS). A ticket only serves to authenticate 262 a client to a service when presented along with a fresh 263 Authenticator. In OAuth 2.0 the closest structure to a 264 ticket is the Access Token and Refresh Token, together with 265 parameters accompany the token when transmitted. 267 2.3. Overview of the Kerberos (V5) protocol 269 The basic purpose of Kerberos is to provide access control of a 270 client (user or host) to a service or resource. To simplify the 271 current description, we will use the term "client" to mean the entity 272 associated with the symmetric key shared with the Authentication 273 Server (though the intent is clear that both human users and host 274 computers can in fact be Kerberos principals). 276 The following summarizes the main message flows within Kerberos: 278 (A) Authentication Request (AS_REQ) 279 The Authentication Request (AS_REQ) message is sent by the 280 Kerberos Client to the Authentication Server (AS) within the 281 KDC. 283 (B) Authentication Response (AS_REP) 284 The AS/KDC returns a response (AS_REP) message to the Client 285 that contains the encrypted Service Ticket and the encrypted 286 AS Response Part. These two parts contain the session-key 287 that the Client and Service (Resource Server) will later use 288 to secure their session. 290 (C) Service Request (AP_REQ) 291 The Client constructs the Authenticator structure that it 292 encrypts using the session-key (obtained in the previous 293 step). This Authenticator provides proof-of-possession (of 294 the session-key) to the Service (Resource Server). The 295 Client delivers both the Service Ticket (unmodified from the 296 previous step) and the Authenticator within the AP_REQ 297 message. 299 (D) Service Response (AP_REP) 300 The Service (Resource Server) obtains the AP_REQ message, 301 decrypts the Session Ticket (created by the KDC) and extracts 302 the session-key. It then uses the session-key to verify the 303 Authenticator structure. 305 (E) Optional Ticket-Granting Service Request (TGS_REQ) 306 In order to prevent the Client from having to authenticate 307 repeatedly to the KDC (e.g. due to short-life tickets), the 308 Client can request a Ticket-Granting-Ticket (TGT) from the 309 Ticket Granting Service (TGS), which is a special service 310 operating at the KDC. 312 (F) Optional Ticket-Granting Service Response (TGS_REP) 313 If the TGS_REQ message is used, the TGS (instead of the AS) 314 will return the Service Ticket destined for a given Service 315 (Resource Server). Note that the Service Ticket life is 316 shorter than the TGT life. 318 +---------------------+ 319 | KDC | 320 +--------+ | +---------------+ | 321 | |--(A)------ Authentication ----|->|Authentication | | 322 | | Request (AS_REQ) | | Server (AS) | | 323 | |<-(B)------ Authentication ----|--| | | 324 | | Response (AS_REP) | +---------------+ | 325 | | | | 326 | | | +---------------+ | 327 | |--(E)------ TGS Request -------|->| Ticket | | 328 | Client | (TGS_REQ) optional | | Granting | | 329 | |<-(F)------ TGS Response ------|--| Server (TGS) | | 330 | | (TGS_REP) optional | +---------------+ | 331 | | +---------------------+ 332 | | 333 | | +---------------+ 334 | |--(C)------ Service Request ----->| Service or | 335 | | (AP_REQ) | Resource | 336 | |<-(D)------ Service Response - ---| Server | 337 | | (AP_REP) +---------------+ 338 +--------+ 340 Figure 1 342 2.3.1. Advantages and disadvantages of the Kerberos paradigm 344 As an authentication protocol based on symmetric key cryptography, 345 there a number of advantages as well as inherent limitations of 346 Kerberos: 348 o Limited impact of key compromise: The compromise of a client or 349 server (or the keys in these entities) impacts only these 350 entities. Other clients and servers are not impacted since they 351 share a unique key with the KDC. 353 o Speed of cryptographic operations: One of the original motivations 354 behind Kerberos was the desire to use symmetric key ciphers due to 355 their significant performance over public key ciphers. 357 o Cross realm/domain authentication: Kerberos v5 addressed the 358 requirement of cross-realm authentication and authorization by the 359 introduction of cross-realm tickets. This provides the advantage 360 of scaling Kerberos across realms (within one administrative 361 boundary) and across realms in differing administrative 362 boundaries. 364 o Delegation: Kerberos v5 addressed supports the notion of 365 delegation through the use of special tickets (refered to as 366 proxiable tickets and forwardable tickets). In essence, 367 delegation in Kerberos allows a Client to name another entity 368 (e.g. a Server) within a ticket-request (to the KDC) with the 369 explicit intent of allowing that entity to later request service- 370 tickets in the name of the Client. Delegation can also be used to 371 realize the notion of "transitive-trust" that may cross domain 372 boundaries. 374 o Compromise of KDC impacts other entities: Since the KDC shares a 375 symmetric key pair-wise with every entity in the system (clients 376 and server), the compromise of the KDC and the keys stored at the 377 KDC renders the entire system compromised. Thus, additional 378 security is required for keys stored at the KDC. Additional 379 precautions, such as separating the Authentication Server (AS) 380 into a more secure computing environment may reduce the risks 381 associate with attacks. 383 o Initial key establishment problem: Similar to many symmetric key 384 based authentication protocols, Kerberos requires initial key 385 establishment between a Client and the KDC, and between a Server 386 and the KDC. Several methods to establish the initial shared key 387 between entities have been proposed. These are referred to as 388 "pre-authentication" protocols in the Kerberos literature, and 389 includes a password-based method (defined as part of RFC4210), a 390 public-key based approach (PKINIT [RFC4556]) using the Diffie- 391 Hellman or RSA cryptosystems) as well as One-Time-passwords or 392 tokens (draft-ietf-krb-wg-otp-preauth-17). 394 3. Functional Comparison of OAuth 2.0 and Kerberos V5 396 In this section we compare the intent/purpose of the OAuth 2.0 397 messages against those in Kerberos V5. The aim here is to understand 398 the semantic similarities between OAuth 2.0 and Kerberos, and 399 identifying the gaps needing solutions in order for OAuth 2.0 to 400 support Kerberos V5. Another aspect of this exercise is also to 401 understand the design decisions of Kerberos V5 over the last two 402 decades, hopefully to inform a better design to OAuth 2.0 and other 403 new protocols in the future. 405 3.1. Client Authentication 407 3.1.1. OAuth Client Authentication Request 409 The OAuth 2.0 protocol caters for a number of use-cases, though in 410 many of these scenarios there are some common fundamental parameters 411 that are being exchanged with the Authorization Server. 413 In the Client Authentication exchange the token endpoint at the 414 Authorization Server requires the client to provide the client 415 identifier (client_id) and the optional client secret 416 (client_secret). These two parameters can be delivered using a 417 simple HTTP POST message or using an HTTP authentication scheme. How 418 the client obtains these credentials are outside the scope of the 419 OAuth 2.0 specification. Additional parameters thar are communicated 420 between the client and Authorization server: 422 o Type of authentication (user_agent, web_server, device_code, 423 username, client_credentials, assertion or refresh). 425 o Client identity (client_id) 427 o Client secret (client_secret) 429 o Server identity (Host name) 431 o Transport mechanism (e.g. HTTP POST) 433 o Encoding method or content type (e.g. urlencoded) 435 The OAuth 2.0 specification, however, considers as out-of- scope the 436 method used by the Authorization Server to authenticate the end-user. 437 As such, the current OAuth 2.0 specification could be considered more 438 as a framework for authentication and authorization, which needs to 439 be instantiated with a specific authentication mechanism/method and 440 which would therefore necessitate bindings to specific transports. 442 3.1.2. Kerberos Client Authentication Request 444 In Kerberos, the client initiates an authentication request by 445 sending the AS_REQ message to the Authentication Server (AS). 446 Ignoring for the moment the format of the AS_REQ message, the client 447 sends the following parameters to the AS: 449 o Message type 451 o Kerberos protocol version number (v5) 453 o Pre-authentication data (optional) 455 o Client principal name 457 o Client's realm 458 o KDC principal name) 460 o Start-time of requested ticket (optional) 462 o Expiration time of requested ticket 464 o Nonce generated by the client 466 o Encryption algorithm desired 468 o Client host address (optional) 470 o Additional tickets (optional) 472 In Kerberos the client has the option of selecting the lifetime of 473 tickets, though the KDC can set the upper bounds of the lifetimes 474 according to some predefined policy. The client has to explicitly 475 choose a unique random nonce for the purposes of detecting replays of 476 the responses coming from the KDC. 478 Although RFC4120 allows the Kerberos authentication request message 479 to be sent in clear text, in practice it is beneficial to protect 480 this message from unauthorized modifications in-transit. Similar to 481 OAuth, the request could be sent over a secure channel such as TLS/ 482 SSL or within some tunneling mechanism (e.g. FAST tunnel). 484 3.2. Access Token Response 486 3.2.1. OAuth Access Token Response 488 In OAuth 2.0 the access token response from the Authorization Server 489 caries a number of parameters explicitly and implicitly (Section 490 3.3.2.1): 492 o Access Token 494 o Duration of token (expires in seconds) 496 o Optional Refresh Token 498 o Access Token Secret (optional, determined by client) 500 o Scope 502 o Transport mechanism (e.g. HTTP 1.1) 504 o Encoding method or content type (e.g. app/json) 505 The OAuth 2.0 specification currently does not specify the sizes of 506 tokens and other values received from the Authorization Server. 508 3.2.2. Kerberos Service Ticket 510 The Kerberos v5 equivalent to the OAuth 2.0 Access Token is that of 511 the Service Ticket. The client can obtain a Service Ticket directly 512 from the KDC using the Authentication Request (AS_REQ) message. The 513 response coming back from the KDC contains a number of relevant 514 parameters: 516 o Message type 518 o Kerberos protocol version number (v5) 520 o Pre-authentication data (optional) 522 o Client principal name 524 o Client's realm 526 o Service Ticket (encrypted structure) 528 o Response Part (encrypted structure) 530 The two important structures inside the Kerberos response message are 531 the Response Part structure that is intended for the Client, and the 532 Service Ticket (ST) structure which the Client must forward 533 unmodified to the Server (or Resource Server). Generally each of 534 these structures carry a number of parameters in-turn, including (a) 535 the identities of the Client and Server, (b) the lifetime of the 536 Ticket and (c) the Session-Key to be used by the Client in requesting 537 service or access to the Server (Resource Server). 539 Here, an important security feature is that the Response Part 540 structure (containing the Session-Key) is encrypted by the KDC using 541 the long-term key it shares with the Client. This ensures that only 542 the authenticated Client can decrypt the Response Part and make use 543 of the contained Session-Key. Similarly, the important parameters 544 within the Service Ticket structure is encrypted by the KDC using the 545 long term key it shares with the Server (i.e. Resource Server). 546 This ensures that only the Client and Server know the given Session- 547 Key, and thus allows the Server to later recognize an authentic 548 service request from the Client (encrypted by the Client using that 549 very same Session-Key). 551 In comparing the OAuth Access Token Response message with the 552 Kerberos authentication response message containing a Service Ticket, 553 there are a number of interesting aspects: 555 a. OAuth Access Token Secret vs Kerberos Session-Key: The OAuth 2.0 556 specification allows Clients to make authenticated protected 557 resource requests using an access token with a matching secret by 558 calculating a set of values and including them in the request 559 using the "Authorization" header field. The OAuth 2.0 560 specification defines the "hmac-sha256" algorithm to verify this 561 secret. 563 In contrast, in Kerberos the Session-Key is used by the Client to 564 encrypt (not hash) the Authenticator structure that the Client 565 creates. The encrypted Authenticator structure is then sent 566 together with the Service Ticket (obtained from the KDC in the 567 prior step) to the Server (or Resource Server). 569 Kerberos uses encryption instead of hashing only die to the 570 sensitivity of the parameters exchanged between the Client and 571 KDC, and between the Client and Server. 573 b. Selectable Ciphers and Hash Functions: Kerberos supports various 574 ciphers and hash functions as negotiated upon between the Client 575 and KDC at the initial authentication request. 577 3.3. Resource Access Request 579 Once the Client obtains an OAuth 2.0 Access Token, it delivers the 580 Access Token to the Resource Server within an HTTP Request message. 581 OAuth supports a number of use-cases which it supports (User-Agent 582 Flow, Web Server Flow, Device Flow, Username/Password Flow, Client 583 Credential Flow and Assertion Flow). These use-cases are in fact 584 distinct from the fundamental authentication feature of OAuth 2.0 585 based on Access Tokens. The use-cases address the various deployment 586 scenarios and technologies that are available today to implement 587 them. 589 In Kerberos, in order to access the Server the Client must present 590 both the Authenticator (created by the Client) and the Service Ticket 591 (created by the KDC). These two structures when combined allow the 592 Server (or Resource Server) to establish that the Client has been 593 authenticated by the KDC. The Server does not have to interact with 594 the KDC when validating the Service Ticket. 596 3.4. Refresh Token 598 In OAuth 2.0 the token refresh is used when the lifetime of an access 599 token is shorter than the lifetime of the authorization grant 600 (Section 4). It allows clients to obtain a new access token without 601 having to go through the OAuth authorization flow again (to the 602 Authorization Server) or involve the resource owner. 604 The relevant parameters of the OAuth 2.0 Refresh Token request 605 message are as follows: 607 o Type of authentication (set to "refresh") 609 o Client identity (client_id) 611 o Client secret (if client issued a secret) 613 o Refresh Token (refresh_token) 615 o Secret Type (optional, defaults to bearer token if there is no 616 secret) 618 o Response format (one of "json", "xml", or "form"). 620 In Kerberos, in order to avoid the Client from having to authenticate 621 to the KDC each time it wishes to access a Server, the Client must 622 first obtain a Ticket Granting Ticket (TGT) from the Ticket Granting 623 Service (TGS) operating in the KDC. The Client then uses the TGT 624 each time it requests a Service Ticket to access the Server. This 625 can be done as a system process, without the need to prompt the user. 626 In this sense, the Refresh Token is identical in purpose to the 627 Kerberos TGT. 629 The message structure of the TGT request message is identical to the 630 message structure of a Service Ticket request. Indeed, in Kerberos 631 the Ticket Granting Service (TGS) is viewed in the same manner as the 632 services offered by any Kerberos Server. 634 In Kerberos the AS Response (AS_REP) message carries a number of 635 parameters, including those intended for consumption by the Ticket 636 Granting Service (TGS). These are summarized as follows: 638 o Message type 640 o Kerberos protocol version number (v5) 642 o Pre-authentication data (optional) 644 o Client principal name 646 o Client's realm 647 o Ticket Granting Ticket (encrypted structure) 649 o AS Response Part (encrypted structure) 651 The two important structures inside the AS_REP message are the AS 652 Response Part structure that is intended for the client, and the 653 Ticket Granting Ticket (TGT) structure which the client must forward 654 unmodified to the Ticket Granting Service. Each of these structures 655 carry a number of parameters in-turn, including (a) the identities of 656 the client, TGS and Server, (b) the lifetime of the TGT and (c) the 657 Session-key to be used by the Client in requesting the Service Ticket 658 to the TGS. 660 Here, an important security feature is that the AS Response Part 661 structure (containing a session-key) is encrypted by the AS using the 662 long-term key it shares with the client. This ensures that only the 663 authenticated client can decrypt the AS Response Part and make use of 664 the contained session- key. Similarly, the important parameters 665 within the TGT structure is encrypted by the AS using the long term 666 key it shares with the TGS entity. This ensures that only the client 667 and TGS know the given session-key, and thus allows the TGS to later 668 recognize an authentic Service Ticket request from the client 669 (encrypted by the client using that very same session-key). 671 It is important to note that obtaining a TGT is optional in Kerberos, 672 and the client can in fact request a Service Ticket directly from the 673 AS by simply designating the identity of the Server in the AS Request 674 message. This may prove cumbersome in practice, since the client may 675 need to newly authenticate itself to the AS each time it seeks to 676 access the Server. 678 3.5. Conclusions and Recommendations 680 In this section we offer some observations and recommendations 681 regarding OAuth 2.0, in the light of the various lessons learned from 682 the development of the Kerberos authentication protocol over the last 683 couple of decades: 685 [1] Refresh Tokens and Access Tokens 686 In Kerberos, the introduction of the Ticket Granting Service 687 (TGS) as a special service on the KDC was done to address the 688 issue of the end-user having to re-authenticate each time the 689 user wanted to access the server (resource server). In 690 practice, Kerberos is almost always deployed using the TGS 691 where the TGT has a longer lifetime compared to the service- 692 tickets requested using a given TGT. 693 In OAuth the cases for using a Refresh Token (as a means to 694 extend the life of the Access Token) needs to be made clear 695 and explicit. Furthermore, Refresh Tokens need to be 696 provably related to its parent Access Token, in such a way 697 that a third-party entity (e.g. auditor) can verify the 698 sequence of events/messages that has been logged by the 699 Resource Server. 701 [2] Support for multiple authentication methods 702 Being a framework, OAuth2.0 currently does not (and should 703 not) call-out specific authentication protocols. In order to 704 gain broad adoption in various organizations, and to gain 705 usage in higher assurance environments, OAuth needs to 706 support a broad range of authentication protocols and 707 methods, including username/passwords, OTP-tokens, Kerberos 708 tickets, and others. 710 [3] Delegation support 711 A key feature of Kerberos that is used extensively in some 712 deployments is delegation (or "constrained delegation" in the 713 Kerberos literature). In Kerberos delegation is expressed 714 using proxiable tickets and forwardable tickets, where a 715 Kerberos client can request a ticket within which the client 716 can explicitly name a server who will act as a delegate. 717 This server will in-turn request service ticket on behalf of 718 the client. Although delegation is not explicitly supported 719 as a feature in the current OAuth 2.0 specification one could 720 conceivably introduce the notion of a "delegation access 721 token" that implements the same function as that in Kerberos. 723 4. An OAuth 2.0 Profile for Kerberos (DRAFT) 725 In this section we propose a "profile" of OAuth 2.0 for Kerberos that 726 provides one approach for interoperability between OAuth2.0 and 727 Kerberos. In this approach, the Kerberos messages are delivered 728 using OAuth as a mechanism of transport between the relevant Kerberos 729 entities. 731 A key aspect of this proposal is the representation of the Kerberos 732 messages in the form of GSS-Tokens as defined in RFC2743 and RFC4121. 733 This provides opaqueness of the Kerberos messages to the higher layer 734 applications, which in this case are the OAuth entities operating at 735 the HTTP layer. 737 4.1. Design Assumptions 738 4.1.1. Separation of Kerberos functions from OAuth functions 740 Since one of the main goals of OAuth 2.0 is to provide simplicity to 741 the end-user, one of the design assumptions here is that the creation 742 and consumption of Kerberos is performed by Kerberos entities (or 743 components) that are distinct from OAuth entities. Thus, for 744 example, although the OAuth Authorization Server could also be 745 implemented as an enhanced Kerberos KDC, we assume that the KDC is 746 distinct from the Authorization Server. 748 This architectural separation allows organizations already deploying 749 a Kerberos infrastructure to layer OAuth as front- end service for 750 authenticating users and OAuth clients, following the use-cases 751 defined in the OAuth specification. 753 4.1.2. Opaqueness of Kerberos Messages 755 Following the approach used by HTTP-Negotiate (RFC4559) which 756 introduced a new auth-scheme based on the SPNEGO GSSAPI-Tokens, in 757 this document we also propose the use the GSSAPI-Tokens (RFC2743) for 758 all Kerberos messages that will be over (through) through OAuth 759 messages. The GSSAPI-Tokens is assumed to be encoded in some HTTP- 760 friendly manner (e.g. Base64 encoded). 762 The approach of using Kerberos GSSAPI-Tokens (RFC4121) is also used 763 in the Web Services Security standard, notably in the WSS Kerberos 764 Token Profile 1.1 [WSS-Kerberos]. There the Kerberos AP_REQ message 765 (wrapped GSS-Token) is delivered by a client to a service over WSS 766 (over SOAP). 768 4.1.3. Resource Server as a Service Principal 770 In orde to achieve some degree of interoperability, we assume that 771 the OAuth Resource Server is also a service principal in the 772 traditional Kerberos sense. This means (among others) that (a) the 773 Resource Server shares a long-term key with the KDC, and (b) that it 774 is able to consume and process Service Tickets in the usual Kerberos 775 manner. How a Resource Server implements the Kerberos Service is 776 outside the scope of the OAuth 2.0 specification and of this current 777 document. 779 4.2. OAuth-Kerberos Architecture Overview 781 The overall architecture underlying the OAuth 2.0 profile for 782 Kerberos is shown in Figure 2. 784 +--------+ +---------+ +------+ 785 | |--(A)----- Credentials ---->| | | | 786 | | (w. opaque AS_REQ) | <-|-|-> | 787 | |<-(B)----- Access Token -----| OAuth | | | 788 | | (w. opaque AS_REP) | Authzn | | KDC | 789 | | | Server | | | 790 | | | | | | 791 | OAuth |--(E)----- Refresh Token ----->| | | | 792 | Client | (w. opaque TGS_REQ) | <-|-|-> | 793 | |<-(F)----- New Access Token ---| | | | 794 | | (w. opaque TGS_REP) +---------+ +------| 795 | | 796 | | +---------------+ 797 | |--(C)--HTTP Req w. Access Token-->| Service or | 798 | ^ | (w. opaque AP_REQ) | Resource | 799 | | |<-(D)----- HTTP Response ---------| Server | 800 +---|----+ (w. opaque AP_REP) +---------------+ 801 | v | 802 | | 803 | Kerb. | 804 | Client | 805 +--------+ 807 Figure 2 809 The Kerberos client is assumed to be present in the underlying 810 operating system, within the browser or as part of the web 811 application. Similar to the case of HTTP-Negotiate in which the 812 browser performs a call to the underlying Kerberos client, in this 813 case we assume that the OAuth Client is able to perform a similar 814 call. The details of this are outside the scope of OAuth and of the 815 current document. 817 5. Kerberized Token Exchange Service 819 TBD 821 6. Acknowledgements 823 TBD 825 7. IANA Considerations 827 TBD 829 8. Security Considerations 831 TBD 833 All drafts are required to have a security considerations section. 834 See RFC 3552 [RFC3552] for a guide. 836 9. References 838 9.1. Normative References 840 [Needham-Schoeder] 841 Needham, Roger. and Michael. Schoeder, "Using encryption 842 for authentication in large networks of computers, 843 Communications of the ACM 21 (12)", 1978. 845 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 846 Kerberos Network Authentication Service (V5)", RFC 4120, 847 July 2005. 849 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 850 Kerberos and NTLM HTTP Authentication in Microsoft 851 Windows", RFC 4559, June 2006. 853 9.2. Informative References 855 [MIT-Athena] 856 Steiner, J., Neuman, B., and J. Schiller, "Kerberos: An 857 Authentication Service for Open Network Systems. In 858 Proceedings of the Winter 1988 Usenix Conference. 859 February.", 1988. 861 [RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network 862 Authentication Service (V5)", RFC 1510, September 1993. 864 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 865 Requirement Levels", BCP 14, RFC 2119, March 1997. 867 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 868 Text on Security Considerations", BCP 72, RFC 3552, 869 July 2003. 871 [WSS-Kerberos] 872 Oasis-Open, "Web Services Security: Kerberos Token Profile 873 1.1", 2006, . 877 Appendix A. Document History 879 Changes from -00 881 o Removed Oauth-Kerberos message Flows section due to the huge 882 change occuring between OAuth-draft-5 and OAuth-draft-11. Awating 883 stable version of Auth 2.0 spec. 885 Author's Address 887 Thomas Hardjono (editor) 888 MIT Kerberos Consortium 889 77 Massachussetts Avenue W92-152 890 Cambridge, MA 02139 891 US 893 Email: hardjono@mit.edu