idnits 2.17.1 draft-swift-win2k-krb-user2user-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2001) is 8411 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 142 looks like a reference -- Missing reference section? '2' on line 143 looks like a reference -- Missing reference section? '3' on line 107 looks like a reference -- Missing reference section? '5' on line 68 looks like a reference -- Missing reference section? '4' on line 171 looks like a reference -- Missing reference section? '0' on line 141 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kerberos Working Group M. Swift 3 Internet Draft University of WA 4 Document: draft-swift-win2k-krb-user2user-02.txt J. Brezak 5 Category: Informational Microsoft 6 P. Moore 7 Sandia National Labs 8 April 2001 10 User to User Kerberos Authentication using GSS-API 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 1. Abstract 32 This draft documents a simple extension to the Kerberos GSS-API 33 mechanism to support user to user authentication both in the case 34 where the client application explicitly requests user to user 35 authentication and when it does not know whether the server supports 36 user to user authentication. 38 2. Conventions used in this document 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 42 this document are to be interpreted as described in RFC-2119 [2]. 44 3. Introduction 46 The Kerberos user to user authentication mechanism allows for a 47 client application to connect to a service that is not in possession 48 of a long term secret key. Instead, the session ticket from the 49 KERB-AP-REQ is encrypted using the session key from the service's 50 ticket granting ticket. According to RFC 1510 [3]: 52 Swift Category - Informational 1 53 User to User Kerberos Authentication October 1999 55 If the ENC-TKT-IN-SKEY option has been specified and an 56 additional ticket has been included in the request, the KDC 57 will decrypt the additional ticket using the key for the server 58 to which the additional ticket was issued and verify that it is 59 a ticket-granting ticket. If the request succeeds, the session 60 key from the additional ticket will be used to encrypt the new 61 ticket that is issued instead of using the key of the server 62 for which the new ticket will be used (This allows easy 63 implementation of user-to-user authentication, which uses 64 ticket-granting ticket session keys in lieu of secret server 65 keys in situations where such secret keys could be easily 66 compromised). 68 RFC2078 [5], in section 5.2, discusses a "Double-TGT K-5" mechanism 69 and scenario, but not in the detail required in order to implement 70 the mechanism. The RFC for the Kerberos V5 GSS-API mechanism at the 71 time this draft was prepared, RFC 1964 [4] does not support user-to- 72 user authentication. 74 This draft provides details as to mechanism type, token identifiers, 75 messages and message types sufficient to document an implementation 76 of user-to-user authentication in Kerberos GSS-API. It follows the 77 scenario described in RFC2078. 79 The approach documented in this draft has been used to support user- 80 to-user authentication in the Microsoft Windows 2000 SSPI with the 81 Kerberos V5 protocol, and in a patched Kerberos V5 implementation 82 being used to support a computing grid at Sandia, Lawrence 83 Livermore, and Los Alamos National Laboratories. 85 4. User to User as a New Mechanism 87 A new mechanism OID may be used to establish a user-to-user session: 89 {iso(1) member-body(2) United States(840) mit(113554) 90 infosys(1) gssapi(2) krb5(2) usertouser(3)} 92 In the case that the client application knows that the server 93 requires user-to-user authentication, then the initial call to 94 GSS_Init_Sec_Context will request this mechanism. This new mechanism 95 is used with a token exchange that extends the conventional Kerberos 96 GSS-API protocol by adding an additional round trip to request the 97 TGT from the service. As with all Kerberos GSS-API messages, the 98 following tokens are encapsulated in the GSS-API framing. The first 99 token of the exchange will have an innerContextToken with a 2-octet 100 TOK_ID field containing 04 00 (KERB-TGT-REQUEST) followed by a 101 Kerberos V5 message as follows: 103 KERB-TGT-REQUEST ::= SEQUENCE { 104 pvno[0] INTEGER, 105 msg-type[1] INTEGER, 106 server-name[2] PrincipalName OPTIONAL, 107 realm[3] Realm OPTIONAL 109 Swift Category - Informational 2 110 User to User Kerberos Authentication October 1999 112 } 114 The TGT request consists of four fields: 116 pvno and msg-type are as defined in RFC1510 section 5.4.1. msg- 117 type is KRB_TGT_REQ (16). 119 server-name : this field optionally contains the name of the 120 server. If the client application doesn't know the 121 server name this can be left blank and the server 122 application will pick the appropriate server 123 credentials which may be the default credential. 125 realm : this field optionally contains the realm of the server. 126 If the client application doesn't know the server realm 127 this field can be left blank and the server application 128 will pick the appropriate server credentials which may 129 be the server's default realm. 131 The server name and realm are included to allow a server application 132 to act for multiple principles in different realms and to choose 133 which credentials to use. 135 The response to the KERB-TGT-REQUEST message will be a 136 KERB_TGT_REPLY token which will have an innerContextToken with a 2- 137 octet TOK_ID field containing 04 01 (KERB-TGT-REPLY) followed by a 138 Kerberos V5 message as follows: 140 KERB-TGT-REPLY ::= SEQUENCE { 141 pvno[0] INTEGER, 142 msg-type[1] INTEGER, 143 ticket[2] Ticket 144 } 146 The TGT reply contains the following fields: 148 pvno and msg-type are as defined in RFC1510 section 5.4.1. msg- 149 type is KRB_TGT_REP (17) 151 ticket : contains the TGT for the service specified by the 152 server name and realm passed by the client or the 153 default service. 155 If the service does not possess a ticket granting ticket, it should 156 return the error KRB_AP_ERR_NO_TGT (0x43). 158 If the server name and realm in the KERB-TGT-REQUEST message do not 159 match the name of the service, then the service should return the 160 error KRB_AP_ERR_NOT_US. 162 Following the exchange of the TGT request messages, the initiator 163 requests a ticket to the service from the KDC using a KERB-TGS-REQ 164 with the KDCoption ENC-TKT-IN_SKEY and the second ticket in the 166 Swift Category - Informational 3 167 User to User Kerberos Authentication October 1999 169 additional-tickets of the KDC-REQ-BODY. Upon receipt of the TGS-REP 170 the rest of the authentication identical to the Kerberos GSS-API 171 mechanism defined in RFC 1964 [4]. 173 5. User-to-User when applied via KDC policy 175 Implementations MAY support the ability apply a policy on a user 176 account such that the KDC will not allow conventional service ticket 177 requests, and when presented with a KERB_TGS_REQ that does not 178 contain a second ticket with an ENC_TKT_IN_SKEY KDCoption will 179 respond with a KRB-ERROR with the msg-type 180 KDC_ERR_MUST_USE_USER2USER (or KRB5PLACEHOLD_27). 182 In this case, the client need not explicitly request user-to-user in 183 order to get a user-to-user connection. Implementations may use this 184 error code to set a flag and return a GSS_C_CONTINUE_NEEDED so that 185 the next round uses the mechanism described in section 4. 187 6. User to User when applied by server policy 189 In the case that the client application doesn't know that a service 190 requires user-to-user authentication, and requests and receives a 191 conventional KRB_AP_REP, the client will send the KRB_AP_REP 192 request, and the server will respond with a KRB_ERROR token as 193 described in RFC1964, with a msg-type of 194 KRB_AP_ERR_USER_TO_USER_REQUIRED (0x45). The server may optionally 195 pass the TGT in the data field of this error message. In response to 196 this error, the initiator sets flags and returns a 197 GSS_C_CONTINUE_NEEDED so that the next round uses the mechanism 198 described in section 4. 200 7. Security Considerations 202 These extensions simply enable an existing Kerberos 5 authentication 203 protocol so that it may be used from GSSAPI. 205 There is some risk in a server handing out its ticket-granting- 206 ticket to any client that requests it, in that it gives an attacker 207 a piece of encrypted material to decrypt. However, the same material 208 may be obtained from listening to any legitimate client connection. 210 It should be noted here that the exchange described in section 6 211 requires that the KDC provide tickets for user accounts, which will 212 contain known plaintext encrypted in the users� private key. The 213 risk associated with this is entirely mitigated where a KDC supports 214 the KDC_MUST_USE_USER2USER feature, which allows a restriction on 215 user accounts to ensure that all tickets for that account are 216 encrypted in the TGT session key, and not the long term key of the 217 user. 219 8. References 221 Swift Category - Informational 4 222 User to User Kerberos Authentication October 1999 224 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 225 9, RFC 2026, October 1996. 227 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 228 Levels", BCP 14, RFC 2119, March 1997 230 3 J. Kohl, C. Neuman, "The Kerberos Network Authentication 231 Service(V5)", RFC 1510. 233 4 J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964 235 5 J. Linn, "Generic Security Service Application Program Interface, 236 Version 2", RFC 2078 238 9. Author's Addresses 240 Michael Swift 241 University of Washington 242 Seattle, Washington 243 Email: mikesw@cs.washington.edu 245 John Brezak 246 Microsoft 247 One Microsoft Way 248 Redmond, Washington 249 Email: jbrezak@microsoft.com 251 Patrick Moore 252 Sandia National Laboratories 253 PO Box 5800 Mail Stop 254 Albuquerque, New Mexico 255 Email: pcmoore@sandia.gov 257 Swift Category - Informational 5 258 User to User Kerberos Authentication October 1999 260 Full Copyright Statement 262 Copyright (C) The Internet Society (1999). All Rights Reserved. 264 This document and translations of it may be copied and furnished to 265 others, and derivative works that comment on or otherwise explain it 266 or assist in its implementation may be prepared, copied, published 267 and distributed, in whole or in part, without restriction of any 268 kind, provided that the above copyright notice and this paragraph 269 are included on all such copies and derivative works. However, this 270 document itself may not be modified in any way, such as by removing 271 the copyright notice or references to the Internet Society or other 272 Internet organizations, except as needed for the purpose of 273 developing Internet standards in which case the procedures for 274 copyrights defined in the Internet Standards process must be 275 followed, or as required to translate it into languages other than 276 English. 278 The limited permissions granted above are perpetual and will not be 279 revoked by the Internet Society or its successors or assigns. 281 This document and the information contained herein is provided on an 282 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 283 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 284 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 285 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 286 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 288 Swift Category - Informational 6