idnits 2.17.1 draft-ietf-cat-iakerb-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-04-24) 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 312 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: ---------------------------------------------------------------------------- == Line 162 has weird spacing: '... client gener...' -- 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) ** Obsolete normative reference: RFC 1510 (ref. '1') (Obsoleted by RFC 4120, RFC 6649) == Outdated reference: A later version (-34) exists of draft-ietf-cat-kerberos-pk-init-04 == Outdated reference: A later version (-02) exists of draft-ietf-cat-user2user-01 -- Possible downref: Normative reference to a draft: ref. '4' Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 3 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 Initial Authentication with Kerberos and the GSS-API 7 (IAKERB) 9 STATUS OF THIS MEMO 11 This document is an Internet-Draft. Internet-Drafts are 12 working documents of the Internet Engineering Task Force 13 (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as 15 Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum 18 of six months and may be updated, replaced, or obsoleted 19 by other documents at any time. It is inappropriate to 20 use Internet-Drafts as reference material or to cite them 21 other than as "work in progress". 23 To learn the current status of any Internet-Draft, please 24 check the "1id-abstracts.txt" listing contained in the 25 Internet-Drafts Shadow Directories on ftp.is.co.za 26 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 27 Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US 28 West Coast). 30 Distribution of this document is unlimited. Please send 31 comments to the CAT working group at cat-ietf@mit.edu or 32 the authors. 34 ABSTRACT 36 This draft proposes a new Kerberos authentication 37 mechanism for use when the client computer is unable to 38 contact a Key Distribution Center (KDC). Instead, the 39 client will send Authentication Service (AS) and Ticket 40 Granting Service (TGS) requests to the server, which will 41 then forward them to the appropriate KDC. 43 Table of Contents 45 1. Introduction 2 47 2. Basic Protocol 2 49 3. Addresses in Tickets 3 51 4. Generating Initial Credentials 3 53 5. Sample Usage Scenarios 3 55 5.1 Case 1: Client and Server are in same realm 3 57 5.2 Case 2: Client and Server in different realm 4 59 5.3 Case 3: Client and Server in different realms with a 60 TGT 4 62 6. Combining IAKERB with other Kerberos Extensions 5 64 7. Security Considerations 5 66 8. References 5 68 1. Introduction 70 The standard Kerberos mechanism works well in a LAN 71 environment where clients are well connected and can 72 quickly locate and communicate with network services such 73 as the KDC. Unlike many other authentication protocols, 74 Kerberos requires that the client do most of the work of 75 authentication by locating and calling a KDC to obtain 76 tickets. All a server must do is to decrypt the AP 77 request and verify that it is not a replay 79 However, in certain circumstances this is not a good use 80 of computer resources. On the Internet, for example, 81 servers tend to be far better connected and more able to 82 locate a KDC then clients are. Similarly, when dialing up 83 to an Internet Service Provider (ISP) the client computer 84 is essentially unconnected while the ISP's computer are 85 well connected to the Internet as well as other servers 86 locally. Hence, it makes sense in these situations to 87 allow the client to forward KDC requests to the server 88 and let the server communicate with the KDC. 90 2. Basic Protocol 92 The mechanism ID for user to user GSS-API Kerberos, in 93 accordance with the mechanism proposed by SPNEGO for 94 negotiating protocol variations, is: 96 {iso(1) member-body(2) United States(840) mit(113554) 97 infosys(1) gssapi(2) krb5(2) initialauth(4)} 99 The basic protocol is the existing exchanges between 100 clients and the KDC detailed in RFC1510 [1]. The first 101 context message is an AS request, to which the server 102 responds with an AS reply. The client may either request 103 a TGT during the AS request or directly request a session 104 ticket if the connection is for a short period, only one 105 service will be contacted, and the service principal and 106 client principal are both in the same realm. Otherwise, 107 the client will use the TGT it initially obtained and use 108 it to create further TGS requests which will also be sent 109 to the server as context messages. 111 As with all Kerberos GSS-API messages, the following 112 tokens are encapsulated in the GSS-API framing. In 113 addition, the innerContextToken field of the context 114 establishment tokens contain the context message preceded 115 by a 2-byte TOK_ID field. The messages and their 116 respective IDs are listed below. 118 Message TOK_ID 120 KRB-AS-REQ 05 00 121 KRB-AS-REP 05 01 122 KRB-TGS-REQ 05 02 123 KRB-TGS-REP 05 03 125 3. Addresses in Tickets 127 In IAKERB, the machine sending requests to the KDC is the 128 server and not the client. As a result, the client should 129 not include its addresses in any KDC requests for two 130 reasons. First, the, the KDC may reject the forwarded 131 request as being from the wrong client. Second, in the 132 case of initial authentication for a dial-up client, the 133 client machine may not yet possess a network address. 134 Hence, as allowed by RFC1510 [1], the addresses field of 135 the AS and TGS requests should be blank and the caddr 136 field of the ticket should similarly be left blank. 138 4. Generating Initial Credentials 140 As this flavor of authentication uses AS requests, the 141 client name, realm, and password must be available to the 142 mechanism implementation. The GSS-API does not support 143 passing in credentials to the GSS_acquire_cred_handle, 144 and credentials are by their nature extemely package 145 specific. Hence, it is left to the implementation to add 146 an interface for setting the initial credentials. 148 5. Sample Usage Scenarios 150 Below are detailed three different scenarios using IAKERB 151 and the messages sent in each case. In the first two 152 cases the client never procures a ticket granting ticket. 153 This is useful for an environment where communication is 154 slow and the TGT would not later be used. In the third 155 scenario the client procures a TGT first and uses it to 156 request a ticket to the service. It is up to the 157 implementation which variety to implement. 159 5.1 Case 1: Client and Server are in same realm 161 In this case, the first call to gss_init_sec_context() on 162 the client generates an AS request with the client name 163 set to the client's principal name and the server name 164 set to the server's principal name. The client 165 application sends this to the server application, which 166 then calls gss_accept_sec_context(). The GSS runtime on 167 the server forwards the request to the KDC, which 168 responds with an AS reply. The runtime returns the AS 169 reply from gss_accept_sec_context() and the service 170 returns it to the client application. 172 The client application passes the AS reply to 173 gss_init_sec_context(), which creates an AP request and 174 packages it up identically to the format in RFC 1964 [2]. 175 The client application then sends the AP request to the 176 server, which calls gss_accept_sec_context() to verify 177 the AP request. 179 Client Server KDC 181 AS-REQ(cname,sname,realm)--> forwards --> 182 <-- forwards <-- AS-REP 184 AP-REQ --> Verifies AP request 186 5.2 Case 2: Client and Server in different realm 188 In this case, the client GSS runtime analyzes the target 189 name and determines that it is from a different realm 190 than the client. It then generates an AS request for a 191 cross-realm TGT for the server's realm. The server 192 runtime forwards the request to the client's KDC (C.KDC) 193 and returns the AS reply containing a TGT for the 194 server's realm. The client runtime then generates a TGS 195 request for a ticket to the server with the cross-realm 196 TGT. The server runtime forwards this to the server's KDC 197 (S.KDC), which returns a session ticket to the server. 198 The client runtime then generates a normal AP request for 199 the server using this ticket. 201 Client Server S.KDC C.KDC 203 AS-REQ(cname,krbtgt/srealm,crealm) 204 forwards ---------------> 205 <-- forwards <------ AS-REP 207 TGS-REQ(krbtgt/srealm,server) forwards ----> 208 <-- forwards <-- TGS-REP 210 AP-REQ --> Verifies AP request 212 5.3 Case 3: Client and Server in different realms with a TGT 214 In this case, the client plans on contacting additional 215 services after authenticating with the server so it wants 216 to obtain a TGT. The transaction is very similar to the 217 previous example, but in this case the client obtains a 218 TGT in its own realm before obtaining a cross-realm TGT 219 for the server's realm. 221 Client Server S.KDC C.KDC 223 AS-REQ(cname,krbtgt/crealm,crealm) 224 --> forwards ---------------> 225 <-- forwards <------ AS-REP 227 TGS-REQ(krbtgt/crealm,krbtgt\srealm) 228 --> forwards ---------------> 229 <-- forwards <------ TGS-REP 231 TGS-REQ(krbtgt/srealm,server) 232 --> forwards ----> 233 <-- forwards <-- TGS-REP 235 AP-REQ --> Verifies AP request 237 6. Combining IAKERB with other Kerberos Extensions 239 This protocol is usable with other proposed Kerberos 240 extensions such as PKINIT (Public Key Cryptography for 241 Initial Authentication in Kerberos [3]) or User-to-User 242 Kerberos [4]. In both cases, the messages which would 243 normally be sent to the KDC by the GSS runtime are 244 instead sent by the client application to the server, 245 which then forwards them to a KDC. 247 7. Security Considerations 249 This variation on the Kerberos protocol does not change 250 its security characteristics much. The biggest difference 251 is the lack of addresses in the tickets. As addresses 252 cannot be relied on to provide security but are at best 253 make it more difficult to break a protocol, this is not a 254 serious threat. 256 8. References 258 [1] J. Kohl, C. Neuman. The Kerberos Network 259 Authentication Service(V5). Request for Comments 1510. 261 [2] J. Linn. The Kerberos Version 5 GSS-API Mechanism. 262 Request for Comments 1964 264 [3] B. Tung, C. Neuman, J. Wray, A. Medvinsky, M. Hur, J. 265 Trostle, Public Key Cryptography for Initial 266 Authentication in Kerberos, draft-ietf-cat-kerberos-pk- 267 init-04.txt. 269 [4] M. Swift, User to User Kerberos Authentication using 270 GSS-API, draft-ietf-cat-user2user-01.txt. 272 Author's address 274 Michael Swift 275 Microsoft 276 1 Microsoft Way 277 Redmond, Washington, 98052, U.S.A. 279 Email: mikesw@microsoft.com