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