idnits 2.17.1 draft-swift-win2k-krb-user2user-00.txt: ** The Abstract section seems to be numbered -(103): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(104): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 are 7 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 4 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 (October 1999) is 8931 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 122 looks like a reference -- Missing reference section? '2' on line 123 looks like a reference -- Missing reference section? '3' on line 89 looks like a reference -- Missing reference section? '0' on line 121 looks like a reference -- Missing reference section? '4' on line 171 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CAT Working Group Michael M. Swift 2 Internet Draft Microsoft 3 Document: draft-swift-win2k-krb-user2user-00.txt October 1999 4 Category: Informational 6 User to User Kerberos Authentication using GSS-API 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. Internet-Drafts are draft documents valid for a maximum of 17 six months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts as 19 reference material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 1. Abstract 29 This draft documents a simple extension to the Kerberos GSS-API 30 mechanism to support user to user authentication both in the case 31 where the client application explicitly requests user to user 32 authentication and when it does not know whether the server supports 33 user to user authentication. This is used in Microsoft's Windows 34 2000 Implementation of Kerberos. 36 2. Conventions used in this document 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 40 this document are to be interpreted as described in RFC-2119 [2]. 42 3. Introduction 44 The Kerberos user to user authentication mechanism allows for a 45 client application to connect to a service that is not in possession 46 of a long term secret key. Instead, the authentication request (AP 47 request) is encrypted using the session key from the service�s 48 ticket granting ticket. According to RFC 1510 [3]: 50 If the ENC-TKT-IN-SKEY option has been specified and an 51 additional ticket has been included in the request, the KDC 52 will decrypt the additional ticket using the key for the server 54 Swift Category - Informational 1 55 User to User Kerberos Authentication October 1999 57 to which the additional ticket was issued and verify that it is 58 a ticket-granting ticket. If the request succeeds, the session 59 key from the additional ticket will be used to encrypt the new 60 ticket that is issued instead of using the key of the server 61 for which the new ticket will be used (This allows easy 62 implementation of user-to-user authentication, which uses 63 ticket-granting ticket session keys in lieu of secret server 64 keys in situations where such secret keys could be easily 65 compromised). 67 The current Kerberos GSS-API mechanism does not support this flavor 68 of authentication, and new messages and flags are defined to add 69 this support. For the case that the client knows that the service 70 requires user-to-user authentication, a new message (KERB-TGT- 71 REQUEST) is defined. In the case that a client sends a normal AP 72 request but the service only supports user-to-user authentication, a 73 new Kerberos error as well as error data type is defined. 75 4. User to User as a New Mechanism 77 In the case that the client application knows that the server only 78 supports user-to-user authentication, then it is easiest to add this 79 functionality as a new mechanism. The new protocol extends the 80 existing Kerberos GSS-API protocol by adding an additional round 81 trip to request the TGT from the service. As with all Kerberos GSS- 82 API messages, the following tokens are encapsulated in the GSS-API 83 framing. The first token of the exchange is as follows: 85 KERB-TGT-REQUEST ::= SEQUENCE { 86 pvno[0] INTEGER, 87 msg-type[1] INTEGER, 88 server-name[2] PrincipalName OPTIONAL, 89 realm[3] Realm OPTIONAL 90 } 92 The TGT request consists of four fields: 94 pvno and msg-type are as defined in RFC1510 section 5.4.1. msg- 95 type is KRB_TGT_REQ (16). 97 server-name � this field optionally contains the name of the 98 server. If the client application doesn�t know the 99 server name this can be left blank and the server 100 application will pick the appropriate server 101 credentials. 103 realm � this field optionally contains the realm of the server. 104 If the client application doesn�t know the server realm 105 this field can be left blank and the server application 106 will pick the appropriate server credentials. 108 The server name and realm are included to allow a server application 109 to act for multiple principles in different realms and to choose 111 Swift Category - Informational 2 112 User to User Kerberos Authentication October 1999 114 which credentials to use. Depending on the implementation of the 115 Kerberos mechanism, the application may call 116 gss_accept_sec_context() multiple times until the token is accepted. 118 The response to the KERB-TGT-REQUEST message is as follows: 120 KERB-TGT-REPLY ::= SEQUENCE { 121 pvno[0] INTEGER, 122 msg-type[1] INTEGER, 123 ticket[2] Ticket 124 } 126 The TGT reply contains the following fields: 128 pvno and msg-type are as defined in RFC1510 section 5.4.1. msg- 129 type is KRB_TGT_REP (17) 131 ticket � contains the TGT for the service specified by the 132 server name and realm passed by the client or the 133 default service. 135 If the service does not possess a ticket granting ticket, it should 136 return the error KRB_AP_ERR_NO_TGT (0x43). 138 If the server name and realm in the KERB-TGT-REQUEST message do not 139 match the name of the service, then the service should return the 140 error KRB_AP_ERR_NOT_US. 142 The mechanism ID for user to user GSS-API Kerberos, in accordance 143 with the mechanism proposed by SPNEGO for negotiating protocol 144 variations, is: 146 {iso(1) member-body(2) United States(840) mit(113554) 147 infosys(1) gssapi(2) krb5(2) usertouser(3)} 149 Following the exchange of the TGT request messages, the rest of the 150 authentication is identical to the Kerberos GSS-API mechanism 151 defined in RFC 1964 [4]. 153 As with the Kerberos GSS-API mechanism, the innerContextToken field 154 of the context establishment tokens contain context message (KERB- 155 TGT-REQUEST, KERB-TGT-REPLY) preceded by a 2-byte TOK_ID field 156 containing 04 00 for the KERB-TGT-REQUEST message and 04 01 for the 157 KERB-TGT-REPLY message. 159 5. User to User With The Existing Mechanism 161 In the case that the client application doesn�t know that a service 162 requires user-to-user authentication and sends a normal AP request, 163 it may be useful to recover and have the server return the TGT in 164 the error message. In this case, the server returns a KRB-ERROR 165 message with the KRB_AP_ERR_USER_TO_USER_REQUIRED (0x43). The error 167 Swift Category - Informational 3 168 User to User Kerberos Authentication October 1999 170 data for contains a KERB-TGT-REPLY. The Kerberos mechanism then 171 continues as in [4] but with a user-to-user ticket instead of a 172 normal session ticket. 174 6. Security Considerations 176 There is some risk in a server handing out its ticket-granting- 177 ticket to any client that requests it, in that it gives an attacker 178 a piece of encrypted material to decrypt. However, the same material 179 may be obtained from listening to any legitimate client connect. 180 7. References 182 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 183 9, RFC 2026, October 1996. 185 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 186 Levels", BCP 14, RFC 2119, March 1997 188 3 J. Kohl, C. Neuman, "The Kerberos Network Authentication 189 Service(V5)", RFC 1510. 191 4 J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964 193 8. Author's Addresses 195 Michael Swift 196 Microsoft 197 One Microsoft Way 198 Redmond, Washington 199 Email: mikesw@microsoft.com 201 Swift Category - Informational 4 202 User to User Kerberos Authentication October 1999 204 Full Copyright Statement 206 Copyright (C) The Internet Society (1999). All Rights Reserved. 208 This document and translations of it may be copied and furnished to 209 others, and derivative works that comment on or otherwise explain it 210 or assist in its implementation may be prepared, copied, published 211 and distributed, in whole or in part, without restriction of any 212 kind, provided that the above copyright notice and this paragraph 213 are included on all such copies and derivative works. However, this 214 document itself may not be modified in any way, such as by removing 215 the copyright notice or references to the Internet Society or other 216 Internet organizations, except as needed for the purpose of 217 developing Internet standards in which case the procedures for 218 copyrights defined in the Internet Standards process must be 219 followed, or as required to translate it into languages other than 220 English. 222 The limited permissions granted above are perpetual and will not be 223 revoked by the Internet Society or its successors or assigns. 225 This document and the information contained herein is provided on an 226 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 227 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 228 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 229 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 230 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 232 Swift Category - Informational 5