1 2 3Kerberos Working Group M. Swift 4Internet Draft University of WA 5Document: draft-swift-win2k-krb-user2user-03.txt J. Brezak 6Category: Informational Microsoft 7 P. Moore 8 Sandia National Labs 9 October 2001 10 11 12 User to User Kerberos Authentication using GSS-API 13 14 15Status of this Memo 16 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026 [1]. 19 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 27 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 32 331. Abstract 34 35 This draft documents a simple extension to the Kerberos GSS-API 36 mechanism to support user to user authentication both in the case 37 where the client application explicitly requests user to user 38 authentication and when it does not know whether the server supports 39 user to user authentication. 40 412. Conventions used in this document 42 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 45 this document are to be interpreted as described in RFC-2119 [2]. 46 47 483. Introduction 49 50 The Kerberos user to user authentication mechanism allows for a 51 client application to connect to a service that is not in possession 52 of a long term secret key. Instead, the session ticket from the 53 KERB-AP-REQ is encrypted using the session key from the service's 54 ticket granting ticket. According to RFC 1510 [3]: 55 56 57 58Swift Category - Informational 1 59 60 61 62 63 64 65 66 67 User to User Kerberos Authentication October 1999 68 69 70 If the ENC-TKT-IN-SKEY option has been specified and an 71 additional ticket has been included in the request, the KDC 72 will decrypt the additional ticket using the key for the server 73 to which the additional ticket was issued and verify that it is 74 a ticket-granting ticket. If the request succeeds, the session 75 key from the additional ticket will be used to encrypt the new 76 ticket that is issued instead of using the key of the server 77 for which the new ticket will be used (This allows easy 78 implementation of user-to-user authentication, which uses 79 ticket-granting ticket session keys in lieu of secret server 80 keys in situations where such secret keys could be easily 81 compromised). 82 83 RFC2078 [5], in section 5.2, discusses a "Double-TGT K-5" mechanism 84 and scenario, but not in the detail required in order to implement 85 the mechanism. The RFC for the Kerberos V5 GSS-API mechanism at the 86 time this draft was prepared, RFC 1964 [4] does not support user-to- 87 user authentication. 88 89 This draft provides details as to mechanism type, token identifiers, 90 messages and message types sufficient to document an implementation 91 of user-to-user authentication in Kerberos GSS-API. It follows the 92 scenario described in RFC2078. 93 94 The approach documented in this draft has been used to support user- 95 to-user authentication in the Microsoft Windows 2000 SSPI with the 96 Kerberos V5 protocol, and in a patched Kerberos V5 implementation 97 being used to support a computing grid at Sandia, Lawrence 98 Livermore, and Los Alamos National Laboratories. 99 1004. User to User as a New Mechanism 101 102 A new mechanism OID may be used to establish a user-to-user session: 103 104 {iso(1) member-body(2) United States(840) mit(113554) 105 infosys(1) gssapi(2) krb5(2) usertouser(3)} 106 107 In the case that the client application knows that the server 108 requires user-to-user authentication, then the initial call to 109 GSS_Init_Sec_Context will request this mechanism. This new mechanism 110 is used with a token exchange that extends the conventional Kerberos 111 GSS-API protocol by adding an additional round trip to request the 112 TGT from the service. As with all Kerberos GSS-API messages, the 113 following tokens are encapsulated in the GSS-API framing. The first 114 token of the exchange will have an innerContextToken with a 2-octet 115 TOK_ID field containing 04 00 (KERB-TGT-REQUEST) followed by a 116 Kerberos V5 message as follows: 117 118 KERB-TGT-REQUEST ::= SEQUENCE { 119 pvno[0] INTEGER, 120 msg-type[1] INTEGER, 121 server-name[2] PrincipalName OPTIONAL, 122 realm[3] Realm OPTIONAL 123 124Swift Category - Informational 2 125 126 127 128 129 130 131 132 133 User to User Kerberos Authentication October 1999 134 135 136 } 137 138 The TGT request consists of four fields: 139 140 pvno and msg-type are as defined in RFC1510 section 5.4.1. msg- 141 type is KRB_TGT_REQ (16). 142 143 server-name : this field optionally contains the name of the 144 server. If the client application doesn't know the 145 server name this can be left blank and the server 146 application will pick the appropriate server 147 credentials which may be the default credential. 148 149 realm : this field optionally contains the realm of the server. 150 If the client application doesn't know the server realm 151 this field can be left blank and the server application 152 will pick the appropriate server credentials which may 153 be the server's default realm. 154 155 The server name and realm are included to allow a server application 156 to act for multiple principles in different realms and to choose 157 which credentials to use. 158 159 The response to the KERB-TGT-REQUEST message will be a 160 KERB_TGT_REPLY token which will have an innerContextToken with a 2- 161 octet TOK_ID field containing 04 01 (KERB-TGT-REPLY) followed by a 162 Kerberos V5 message as follows: 163 164 KERB-TGT-REPLY ::= SEQUENCE { 165 pvno[0] INTEGER, 166 msg-type[1] INTEGER, 167 ticket[2] Ticket 168 } 169 170 The TGT reply contains the following fields: 171 172 pvno and msg-type are as defined in RFC1510 section 5.4.1. msg- 173 type is KRB_TGT_REP (17) 174 175 ticket : contains the TGT for the service specified by the 176 server name and realm passed by the client or the 177 default service. 178 179 If the service does not possess a ticket granting ticket, it should 180 return the error KRB_AP_ERR_NO_TGT (0x43). 181 182 If the server name and realm in the KERB-TGT-REQUEST message do not 183 match the name of the service, then the service should return the 184 error KRB_AP_ERR_NOT_US. 185 186 Following the exchange of the TGT request messages, the initiator 187 requests a ticket to the service from the KDC using a KERB-TGS-REQ 188 with the KDCoption ENC-TKT-IN_SKEY and the second ticket in the 189 190Swift Category - Informational 3 191 192 193 194 195 196 197 198 199 User to User Kerberos Authentication October 1999 200 201 202 additional-tickets of the KDC-REQ-BODY. Upon receipt of the TGS-REP 203 the rest of the authentication identical to the Kerberos GSS-API 204 mechanism defined in RFC 1964 [4]. 205 2065. User-to-User when applied via KDC policy 207 208 Implementations MAY support the ability apply a policy on a user 209 account such that the KDC will not allow conventional service ticket 210 requests, and when presented with a KERB_TGS_REQ that does not 211 contain a second ticket with an ENC_TKT_IN_SKEY KDCoption will 212 respond with a KRB-ERROR with the msg-type 213 KDC_ERR_MUST_USE_USER2USER (or KRB5PLACEHOLD_27). 214 215 In this case, the client need not explicitly request user-to-user in 216 order to get a user-to-user connection. Implementations may use this 217 error code to set a flag and return a GSS_C_CONTINUE_NEEDED so that 218 the next round uses the mechanism described in section 4. 219 2206. User to User when applied by server policy 221 222 In the case that the client application doesn't know that a service 223 requires user-to-user authentication, and requests and receives a 224 conventional KRB_AP_REP, the client will send the KRB_AP_REP 225 request, and the server will respond with a KRB_ERROR token as 226 described in RFC1964, with a msg-type of 227 KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally 228 pass the TGT in the data field of this error message. In response to 229 this error, the initiator sets flags and returns a 230 GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism 231 described in section 4. 232 2337. Security Considerations 234 235 These extensions simply enable an existing Kerberos 5 authentication 236 protocol so that it may be used from GSSAPI. 237 238 There is some risk in a server handing out its ticket-granting- 239 ticket to any client that requests it, in that it gives an attacker 240 a piece of encrypted material to decrypt. However, the same material 241 may be obtained from listening to any legitimate client connection. 242 243 It should be noted here that the exchange described in section 6 244 requires that the KDC provide tickets for user accounts, which will 245 contain known plaintext encrypted in the users� private key. The 246 risk associated with this is entirely mitigated where a KDC supports 247 the KDC_MUST_USE_USER2USER feature, which allows a restriction on 248 user accounts to ensure that all tickets for that account are 249 encrypted in the TGT session key, and not the long term key of the 250 user. 251 2528. References 253 254 255 256Swift Category - Informational 4 257 258 259 260 261 262 263 264 265 User to User Kerberos Authentication October 1999 266 267 268 269 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 270 9, RFC 2026, October 1996. 271 272 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 273 Levels", BCP 14, RFC 2119, March 1997 274 275 3 J. Kohl, C. Neuman, "The Kerberos Network Authentication 276 Service(V5)", RFC 1510. 277 278 4 J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964 279 280 5 J. Linn, "Generic Security Service Application Program Interface, 281 Version 2", RFC 2078 282 2839. Author's Addresses 284 285 Michael Swift 286 University of Washington 287 Seattle, Washington 288 Email: mikesw@cs.washington.edu 289 290 John Brezak 291 Microsoft 292 One Microsoft Way 293 Redmond, Washington 294 Email: jbrezak@microsoft.com 295 296 Patrick Moore 297 Sandia National Laboratories 298 PO Box 5800 Mail Stop 299 Albuquerque, New Mexico 300 Email: pcmoore@sandia.gov 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322Swift Category - Informational 5 323 324 325 326 327 328 329 330 331 User to User Kerberos Authentication October 1999 332 333 334 335Full Copyright Statement 336 337 Copyright (C) The Internet Society (1999). All Rights Reserved. 338 339 This document and translations of it may be copied and furnished to 340 others, and derivative works that comment on or otherwise explain it 341 or assist in its implementation may be prepared, copied, published 342 and distributed, in whole or in part, without restriction of any 343 kind, provided that the above copyright notice and this paragraph 344 are included on all such copies and derivative works. However, this 345 document itself may not be modified in any way, such as by removing 346 the copyright notice or references to the Internet Society or other 347 Internet organizations, except as needed for the purpose of 348 developing Internet standards in which case the procedures for 349 copyrights defined in the Internet Standards process must be 350 followed, or as required to translate it into languages other than 351 English. 352 353 The limited permissions granted above are perpetual and will not be 354 revoked by the Internet Society or its successors or assigns. 355 356 This document and the information contained herein is provided on an 357 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 358 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 359 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 360 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 361 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388Swift Category - Informational 6 389 390 391 392 393 394 395 396