idnits 2.17.1 draft-ietf-cat-user2user-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 260 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 110: '... OPTIONAL,...' RFC 2119 keyword, line 111: '... realm[3] Realm OPTIONAL...' RFC 2119 keyword, line 148: '... OPTIONAL,...' RFC 2119 keyword, line 149: '... realm[5] Realm OPTIONAL...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '0' is mentioned on line 144, but not defined == Missing Reference: '4' is mentioned on line 147, but not defined == Missing Reference: '5' is mentioned on line 149, but not defined ** Obsolete normative reference: RFC 1510 (ref. '1') (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 1508 (ref. '3') (Obsoleted by RFC 2078) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 2 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 4 Expires April 31, 1998 October, 31, 1997 6 User to User Kerberos Authentication using GSS-API 7 Preliminary Draft 9 STATUS OF THIS MEMO 11 THIS IS A PRELIMINARY DRAFT OF AN INTERNET-DRAFT. IT 12 DOES NOT REPRESENT THE CONSENSUS OF THE CAT WORKING 13 GROUP. 15 This document is an Internet-Draft. Internet-Drafts are 16 working documents of the Internet Engineering Task Force 17 (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum 22 of six months and may be updated, replaced, or obsoleted 23 by other documents at any time. It is inappropriate to 24 use Internet-Drafts as reference material or to cite them 25 other than as "work in progress". 27 To learn the current status of any Internet-Draft, please 28 check the "1id-abstracts.txt" listing contained in the 29 Internet-Drafts Shadow Directories on ftp.is.co.za 30 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 31 Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US 32 West Coast). 34 Distribution of this document is unlimited. Please send 35 comments to the CAT working group at cat-ietf@mit.edu or 36 the authors. 38 ABSTRACT 40 This draft proposes a simple extension to the Kerberos 41 GSS-API mechanism to support user to user authentication 42 both in the case where the client application explicitly 43 requests user to user authentication and when it does not 44 know whether the server supports user to user 45 authentication. 47 Table of Contents 49 1. Introduction 2 51 2. User to User as a New Mechanism 3 53 3. User to User With The Existing Mechanism 5 55 4. Security Considerations 5 57 5. References 5 59 1. Introduction 61 The Kerberos user to user authentication mechanism allows 62 for a client application to connect to a service that is 63 not in possession of a long term secret key. Instead, the 64 authentication request (AP request) is encrypted using 65 the session key from the service's ticket granting 66 ticket. According to RFC 1510 [1]: 68 If the ENC-TKT-IN-SKEY option has been specified and 69 an additional ticket has been included in the 70 request, the KDC will decrypt the additional ticket 71 using the key for the server to which the additional 72 ticket was issued and verify that it is a ticket- 73 granting ticket. . If the request succeeds, the 74 session key from the additional ticket will be used 75 to encrypt the new ticket that is issued instead of 76 using the key of the server for which the new ticket 77 will be used (This allows easy implementation of user- 78 to- user authentication, which uses ticket-granting 79 ticket session keys in lieu of secret server keys in 80 situations where such secret keys could be easily 81 compromised.). 83 The current Kerberos GSS-API mechanism does not support 84 this flavor of authentication, and new messages and flags 85 are defined to add this support. For the case that the 86 client knows that the service requires user-to-user 87 authentication, a new message (KERB-TGT-REQUEST) is 88 defined. In the case that a client sends a normal AP 89 request but the service only supports user-to-user 90 authentication, a new Kerberos error as well as error 91 data type is defined. 93 2. User to User as a New Mechanism 95 In the case that the client application knows that the 96 server only supports user-to-user authentication, then it 97 is easiest to add this functionality as a new mechanism. 98 The new protocol extends the existing Kerberos GSS-API 99 protocol by adding an additional round trip to request 100 the TGT from the service. As with all Kerberos GSS-API 101 messages, the following tokens are encapsulated in the 102 GSS-API framing. 104 The first token of the exchange is as follows: 106 KERB-TGT-REQUEST ::= SEQUENCE { 107 pvno[0] INTEGER, 108 msg-type[1] INTEGER, 109 server-name[2] PrincipalName 110 OPTIONAL, 111 realm[3] Realm OPTIONAL 112 } 114 The TGT request consists of four fields: 116 pvno and msg-type are as defined in RFC1510 section 117 5.4.1. msg-type is 118 KRB_TGT_REQ (16). 120 server-name - this field optionally contains the name 121 of the server. If the client application doesn't 122 know the server name this can be left blank and 123 the server application will pick the appropriate 124 server credentials. 126 realm - this field optionally contains the realm of 127 the server. If the client application doesn't know 128 the server realm this field can be left blank and 129 the server application will pick the appropriate 130 server credentials. 132 The server name and realm are included to allow a server 133 application to act for multiple principles in different 134 realms and to choose which credentials to use. Depending 135 on the implementation of the Kerberos mechanism, the 136 application may call gss_accept_sec_context() multiple 137 times until the token is accepted. 139 The response to the KERB-TGT-REQUEST message is as 140 follows: 142 KERB-TGT-REPLY ::= SEQUENCE { 144 pvno[0] INTEGER, 145 msg-type[1] INTEGER, 146 ticket[2] Ticket, 147 server-name[4] PrincipalName 148 OPTIONAL, 149 realm[5] Realm OPTIONAL 150 } 152 The TGT reply contains the following fields: 154 pvno and msg-type are as defined in RFC1510 section 155 5.4.1. msg-type is KRB_TGT_REQ (17) 157 ticket - contains the TGT for the service specified 158 by the server name and realm passed by the client 159 or the default service. 161 server-name - server's principal name. If the client 162 does not supply the server name, the server will 163 return the name. This allows the client to 164 discover the server's principal name in situations 165 where it isn't known. However, if the client 166 doesn't know the server's principal name then 167 authentication is not mutual - any server can 168 respond to the client. 170 realm - server's realm name. Similar to the server- 171 name field, this is returned if the client doesn't 172 provide a realm in the request. 174 The mechanism ID for user to user GSS-API Kerberos, in 175 accordance with the mechanism proposed by SPNEGO for 176 negotiating protocol variations, is: 178 {iso(1) member-body(2) United States(840) mit(113554) 179 infosys(1) gssapi(2) krb5(2) usertouser(1)} 181 Following the exchange of the TGT request messages, the 182 rest of the authentication is identical to the Kerberos 183 GSS-API mechanism defined in RFC 1964 [2]. 185 3. User to User With The Existing Mechanism 187 In the case that the client application doesn't know that 188 a service requires user-to-user authentication and sends 189 a normal AP request, it may be useful to recover and have 190 the server return the TGT in the error message. In this 191 case, the server returns a KRB-ERROR message with the 192 KRB_AP_ERR_USER_TO_USER_REQUIRED (0x42). The error data 193 for contains a KERB-TGT-REPLY structure without the 194 server name and realm fields, as they are already 195 included in the KERB-ERROR message. The Kerberos 196 mechanism then continues as in [2] but with a user-to- 197 user ticket instead of a normal session ticket. 199 4. Security Considerations 201 There is some risk in a server handing out its ticket- 202 granting-ticket to any client that requests it, in that 203 it gives an attacker a piece of encrypted material to 204 decrypt. However, the same material may be obtained from 205 listening to any legitimate client connect. In addition, 206 the server may divulge its name in the KERB-TGT-RESPONSE 207 message allowing, but again this may be obtained from 208 capturing any legitimate request to the server. 210 5. References 212 [1] J. Kohl, C. Neuman. The Kerberos Network 213 Authentication Service(V5). Request for Comments 1510. 215 [2] J. Linn. The Kerberos Version 5 GSS-API Mechanism. 216 Request for Comments 1964 218 [3] J. Linn. Generic Security Service Application 219 Programming Interface. Request For Comments 1508. 221 Author's address 223 Michael Swift 224 Microsoft 225 1 Microsoft Way 226 Redmond, Washington, 98052, U.S.A. 228 Email: mikesw@microsoft.com