idnits 2.17.1 draft-ietf-cat-user2user-01.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-04-19) 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 258 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 104: '... OPTIONAL,...' RFC 2119 keyword, line 105: '... realm[3] Realm OPTIONAL...' RFC 2119 keyword, line 142: '... 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 138, but not defined == Missing Reference: '4' is mentioned on line 141, 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 (~~), 4 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 30, 1998 October, 31, 1997 6 User to User Kerberos Authentication using GSS-API 8 STATUS OF THIS MEMO 10 This document is an Internet-Draft. Internet-Drafts are 11 working documents of the Internet Engineering Task Force 12 (IETF), its areas, and its working groups. Note that 13 other groups may also distribute working documents as 14 Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum 17 of six months and may be updated, replaced, or obsoleted 18 by other documents at any time. It is inappropriate to 19 use Internet-Drafts as reference material or to cite them 20 other than as "work in progress". 22 To learn the current status of any Internet-Draft, please 23 check the "1id-abstracts.txt" listing contained in the 24 Internet-Drafts Shadow Directories on ftp.is.co.za 25 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 26 Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US 27 West Coast). 29 Distribution of this document is unlimited. Please send 30 comments to the CAT working group at cat-ietf@mit.edu or 31 the authors. 33 ABSTRACT 35 This draft proposes a simple extension to the Kerberos 36 GSS-API mechanism to support user to user authentication 37 both in the case where the client application explicitly 38 requests user to user authentication and when it does not 39 know whether the server supports user to user 40 authentication. 42 Table of Contents 44 1. Introduction 2 46 2. User to User as a New Mechanism 2 48 3. User to User With The Existing Mechanism 4 50 4. Security Considerations 4 52 5. References 4 54 1. Introduction 56 The Kerberos user to user authentication mechanism allows 57 for a client application to connect to a service that is 58 not in possession of a long term secret key. Instead, the 59 authentication request (AP request) is encrypted using 60 the session key from the service's ticket granting 61 ticket. According to RFC 1510 [1]: 63 If the ENC-TKT-IN-SKEY option has been specified and 64 an additional ticket has been included in the 65 request, the KDC will decrypt the additional ticket 66 using the key for the server to which the additional 67 ticket was issued and verify that it is a ticket- 68 granting ticket. ... If the request succeeds, the 69 session key from the additional ticket will be used 70 to encrypt the new ticket that is issued instead of 71 using the key of the server for which the new ticket 72 will be used (This allows easy implementation of user- 73 to- user authentication, which uses ticket-granting 74 ticket session keys in lieu of secret server keys in 75 situations where such secret keys could be easily 76 compromised.). 78 The current Kerberos GSS-API mechanism does not support 79 this flavor of authentication, and new messages and flags 80 are defined to add this support. For the case that the 81 client knows that the service requires user-to-user 82 authentication, a new message (KERB-TGT-REQUEST) is 83 defined. In the case that a client sends a normal AP 84 request but the service only supports user-to-user 85 authentication, a new Kerberos error as well as error 86 data type is defined. 88 2. User to User as a New Mechanism 90 In the case that the client application knows that the 91 server only supports user-to-user authentication, then it 92 is easiest to add this functionality as a new mechanism. 93 The new protocol extends the existing Kerberos GSS-API 94 protocol by adding an additional round trip to request 95 the TGT from the service. As with all Kerberos GSS-API 96 messages, the following tokens are encapsulated in the 97 GSS-API framing. The first token of the exchange is as 98 follows: 100 KERB-TGT-REQUEST ::= SEQUENCE { 101 pvno[0] INTEGER, 102 msg-type[1] INTEGER, 103 server-name[2] PrincipalName 104 OPTIONAL, 105 realm[3] Realm OPTIONAL 106 } 108 The TGT request consists of four fields: 110 pvno and msg-type are as defined in RFC1510 section 111 5.4.1. msg-type is 112 KRB_TGT_REQ (16). 114 server-name - this field optionally contains the name 115 of the server. If the client application doesn't 116 know the server name this can be left blank and 117 the server application will pick the appropriate 118 server credentials. 120 realm - this field optionally contains the realm of 121 the server. If the client application doesn't know 122 the server realm this field can be left blank and 123 the server application will pick the appropriate 124 server credentials. 126 The server name and realm are included to allow a server 127 application to act for multiple principles in different 128 realms and to choose which credentials to use. Depending 129 on the implementation of the Kerberos mechanism, the 130 application may call gss_accept_sec_context() multiple 131 times until the token is accepted. 133 The response to the KERB-TGT-REQUEST message is as 134 follows: 136 KERB-TGT-REPLY ::= SEQUENCE { 138 pvno[0] INTEGER, 139 msg-type[1] INTEGER, 140 ticket[2] Ticket, 141 server-name[4] PrincipalName 142 OPTIONAL, 143 } 145 The TGT reply contains the following fields: 147 pvno and msg-type are as defined in RFC1510 section 148 5.4.1. msg-type is KRB_TGT_REP (17) 150 ticket - contains the TGT for the service specified 151 by the server name and realm passed by the client 152 or the default service. 154 server-name - server's principal name. If the client 155 does not supply the server name, the server will 156 return the name. This allows the client to 157 discover the server's principal name in situations 158 where it isn't known. However, if the client 159 doesn't know the server's principal name then 160 authentication is not mutual - any server can 161 respond to the client. The server realm is not 162 returned separately because it is in the ticket 163 structure. 165 If the service does not possess a ticket granting ticket, 166 it should return the error KRB_AP_ERR_NO_TGT (0x42). 168 If the server name and realm in the TGT request message 169 do not match the name of the service, then the service 170 should return the error KRB_AP_ERR_NOT_US. 172 The mechanism ID for user to user GSS-API Kerberos, in 173 accordance with the mechanism proposed by SPNEGO for 174 negotiating protocol variations, is: 176 {iso(1) member-body(2) United States(840) mit(113554) 177 infosys(1) gssapi(2) krb5(2) usertouser(3)} 179 Following the exchange of the TGT request messages, the 180 rest of the authentication is identical to the Kerberos 181 GSS-API mechanism defined in RFC 1964 [2]. 183 As with the Kerberos GSS-API mechanism, the 184 innerContextToken field of the context establishment 185 tokens contain context message (KERB-TGT-REQUEST, KERB- 186 TGT-REPLY) preceded by a 2-byte TOK_ID field containing 187 04 03 for the KERB_TGT_REQUEST message and 05 03 for the 188 KERB_TGT_REPLY message 190 3. User to User With The Existing Mechanism 192 In the case that the client application doesn't know that 193 a service requires user-to-user authentication and sends 194 a normal AP request, it may be useful to recover and have 195 the server return the TGT in the error message. In this 196 case, the server returns a KRB-ERROR message with the 197 KRB_AP_ERR_USER_TO_USER_REQUIRED (0x42). The error data 198 for contains a KERB-TGT-REPLY structure without the 199 server name and realm fields, as they are already 200 included in the KERB-ERROR message. The Kerberos 201 mechanism then continues as in [2] but with a user-to- 202 user ticket instead of a normal session ticket. 204 4. Security Considerations 206 There is some risk in a server handing out its ticket- 207 granting-ticket to any client that requests it, in that 208 it gives an attacker a piece of encrypted material to 209 decrypt. However, the same material may be obtained from 210 listening to any legitimate client connect. In addition, 211 the server may divulge its name in the KERB-TGT-RESPONSE 212 message allowing, but again this may be obtained from 213 capturing any legitimate request to the server. 215 5. References 217 [1] J. Kohl, C. Neuman. The Kerberos Network 218 Authentication Service(V5). Request for Comments 1510. 220 [2] J. Linn. The Kerberos Version 5 GSS-API Mechanism. 221 Request for Comments 1964 223 [3] J. Linn. Generic Security Service Application 224 Programming Interface. Request For Comments 1508. 226 Author's address 228 Michael Swift 229 Microsoft 230 One Microsoft Way 231 Redmond, Washington, 98052, U.S.A. 233 Email: mikesw@microsoft.com