idnits 2.17.1 draft-ietf-cat-iakerb-04.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** There are 14 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 217: '... received ticket MUST NOT set any mutu...' == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC1510, but the abstract doesn't seem to directly say this. It does mention RFC1510 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- (Using the creation date from RFC1510, updated by this document, for RFC5378 checks: 1993-09-01) -- 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 section? '1' on line 251 looks like a reference -- Missing reference section? '2' on line 254 looks like a reference -- Missing reference section? '3' on line 257 looks like a reference -- Missing reference section? 'APPLICATION 0' on line 127 looks like a reference -- Missing reference section? '4' on line 260 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Mike Swift 2 draft-ietf-cat-iakerb-04.txt Microsoft 3 Updates: RFC 1510 Jonathan Trostle 4 July 2000 Cisco Systems 6 Initial Authentication and Pass Through Authentication 7 Using Kerberos V5 and the GSS-API (IAKERB) 9 0. Status Of This Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This draft expires on January 31st, 2001. 33 1. Abstract 35 This document defines an extension to the Kerberos protocol 36 specification (RFC 1510 [1]) and GSSAPI Kerberos mechanism (RFC 37 1964 [2]) that enables a client to obtain Kerberos tickets for 38 services where: 40 (1) The client knows its principal name and password, but not 41 its realm name (applicable in the situation where a user is already 42 on the network but needs to authenticate to an ISP, and the user 43 does not know his ISP realm name). 44 (2) The client is able to obtain the IP address of the service in 45 a realm which it wants to send a request to, but is otherwise unable 46 to locate or communicate with a KDC in the service realm or one of 47 the intermediate realms. (One example would be a dial up user who 48 does not have direct IP connectivity). 49 (3) The client does not know the realm name of the service. 51 2. Motivation 53 When authenticating using Kerberos V5, clients obtain tickets from 54 a KDC and present them to services. This method of operation works 55 well in many situations, but is not always applicable since it 56 requires the client to know its own realm, the realm of the target 57 service, the names of the KDC's, and to be able to connect to the 58 KDC's. 60 This document defines an extension to the Kerberos protocol 61 specification (RFC 1510) [1] that enables a client to obtain 62 Kerberos tickets for services where: 64 (1) The client knows its principal name and password, but not 65 its realm name (applicable in the situation where a user is already 66 on the network but needs to authenticate to an ISP, and the user 67 does not know his ISP realm name). 68 (2) The client is able to obtain the IP address of the service in 69 a realm which it wants to send a request to, but is otherwise unable 70 to locate or communicate with a KDC in the service realm or one of 71 the intermediate realms. (One example would be a dial up user who 72 does not have direct IP connectivity). 73 (3) The client does not know the realm name of the service. 75 In this proposal, the client sends KDC request messages directly 76 to application servers if one of the above failure cases develops. 77 The application server acts as a proxy, forwarding messages back 78 and forth between the client and various KDC's (see Figure 1). 80 Client <---------> App Server <----------> KDC 81 proxies 83 Figure 1: IAKERB proxying 85 In the case where the client has sent a TGS_REQ message to the 86 application server without a realm name in the request, the 87 application server will forward an error message to the client 88 with its realm name in the e-data field of the error message. 89 The client will attempt to proceed using conventional Kerberos. 91 3. When Clients Should Use IAKERB 93 We list several, but possibly not all, cases where the client 94 should use IAKERB. In general, the existing Kerberos paradigm 95 where clients contact the KDC to obtain service tickets should 96 be preserved where possible. 98 (a) AS_REQ cases: 100 (i) The client is unable to locate the user's KDC or the KDC's 101 in the user's realm are not responding, or 102 (ii) The user has not entered a name which can be converted 103 into a realm name (and the realm name cannot be derived from 104 a certificate). 106 (b) TGS_REQ cases: 108 (i) the client determines that the KDC(s) in either an 109 intermediate realm or the service realm are not responding or 110 the client is unable to locate a KDC, 112 (ii) the client is not able to generate the application server 113 realm name. 115 4. GSSAPI Encapsulation 117 The mechanism ID for IAKERB GSS-API Kerberos, in accordance with the 118 mechanism proposed by SPNEGO for negotiating protocol variations, is: 119 {iso(1) member-body(2) United States(840) mit(113554) infosys(1) 120 gssapi(2) krb5(2) initialauth(4)} 122 The AS request, AS reply, TGS request, and TGS reply messages are all 123 encapsulated using the format defined by RFC1964 [2]. This consists 124 of the GSS-API token framing defined in appendix B of RFC1508 [3]: 126 InitialContextToken ::= 127 [APPLICATION 0] IMPLICIT SEQUENCE { 128 thisMech MechType 129 -- MechType is OBJECT IDENTIFIER 130 -- representing "Kerberos V5" 131 innerContextToken ANY DEFINED BY thisMech 132 -- contents mechanism-specific; 133 -- ASN.1 usage within innerContextToken 134 -- is not required 135 } 137 The innerContextToken consists of a 2-byte TOK_ID field (defined 138 below), followed by the Kerberos V5 KRB-AS-REQ, KRB-AS-REP, 139 KRB-TGS-REQ, or KRB-TGS-REP messages, as appropriate. The TOK_ID field 140 shall be one of the following values, to denote that the message is 141 either a request to the KDC or a response from the KDC. 143 Message TOK_ID 144 KRB-KDC-REQ 00 03 145 KRB-KDC-REP 01 03 147 5. The Protocol 149 a. The user supplies a password (AS_REQ): Here the Kerberos client 150 will send an AS_REQ message to the application server if it cannot 151 locate a KDC for the user's realm, or such KDC's do not respond, 152 or the user does not enter a name from which the client can derive 153 the user's realm name. The client sets the realm field of the 154 request equal to its own realm if the realm name is known, 155 otherwise the realm length is set to 0. Upon receipt of the AS_REQ 156 message, the application server checks if the client has included 157 a realm. 159 If the realm was not included in the original request, the 160 application server must determine the realm and add it to the 161 AS_REQ message before forwarding it. If the application server 162 cannot determine the client realm, it returns the 163 KRB_AP_ERR_REALM_REQUIRED error-code in an error message to 164 the client: 166 KRB_AP_ERR_REALM_REQUIRED 77 168 The error message can be sent in response to either an AS_REQ 169 message, or in response to a TGS_REQ message, in which case the 170 realm and principal name of the application server are placed 171 into the realm and sname fields respectively, of the KRB-ERROR 172 message. In the AS_REQ case, once the realm is filled in, the 173 application server forwards the request to a KDC in the user's 174 realm. It will retry the request if necessary, and forward the 175 KDC response back to the client. 177 At the time the user enters a username and password, the client 178 should create a new credential with an INTERNAL NAME [3] that can 179 be used as an input into the GSS_Acquire_cred function call. 181 This functionality is useful when there is no trust relationship 182 between the user's logon realm and the target realm (Figure 2). 184 User Realm KDC 185 / 186 / 187 / 188 / 2,3 189 1,4 / 190 Client<-------------->App Server 192 1 Client sends AS_REQ to App Server 193 2 App server forwards AS_REQ to User Realm KDC 194 3 App server receives AS_REP from User Realm KDC 195 4 App server sends AS_REP back to Client 197 Figure 2: IAKERB AS_REQ 199 b. The user does not supply a password (TGS_REQ): The user includes a 200 TGT targetted at the user's realm, or an intermediate realm, in a 201 TGS_REQ message. The TGS_REQ message is sent to the application 202 server. 204 If the client has included the realm name in the TGS request, then 205 the application server will forward the request to a KDC in the 206 request TGT srealm. It will forward the response back to the client. 208 If the client has not included the realm name in the TGS request, 209 then the application server will return its realm name and principal 210 name to the client using the KRB_AP_ERR_REALM_REQUIRED error 211 described above. Sending a TGS_REQ message to the application server 212 without a realm name in the request, followed by a TGS request using 213 the returned realm name and then sending an AP request with a mutual 214 authentication flag should be subject to a local policy decision 215 (see security considerations below). Using the returned server 216 principal name in a TGS request followed by sending an AP request 217 message using the received ticket MUST NOT set any mutual 218 authentication flags. 220 6. Addresses in Tickets 222 In IAKERB, the machine sending requests to the KDC is the server and 223 not the client. As a result, the client should not include its 224 addresses in any KDC requests for two reasons. First, the KDC may 225 reject the forwarded request as being from the wrong client. Second, 226 in the case of initial authentication for a dial-up client, the client 227 machine may not yet possess a network address. Hence, as allowed by 228 RFC1510 [1], the addresses field of the AS and TGS requests should be 229 blank and the caddr field of the ticket should similarly be left blank. 231 7. Combining IAKERB with Other Kerberos Extensions 233 This protocol is usable with other proposed Kerberos extensions such as 234 PKINIT (Public Key Cryptography for Initial Authentication in Kerberos 235 [4]). In such cases, the messages which would normally be sent to the 236 KDC by the GSS runtime are instead sent by the client application to the 237 server, which then forwards them to a KDC. 239 8. Security Considerations 241 A principal is identified by its principal name and realm. A client 242 that sends a TGS request to an application server without the request 243 realm name will only be able to mutually authenticate the server 244 up to its principal name. Thus when requesting mutual authentication, 245 it is preferable if clients can either determine the server realm name 246 beforehand, or apply some policy checks to the realm name obtained from 247 the returned error message. 249 9. Bibliography 251 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication 252 Service (V5). Request for Comments 1510. 254 [2] J. Linn. The Kerberos Version 5 GSS-API Mechanism. Request 255 for Comments 1964 257 [3] J. Linn. Generic Security Service Application Program Interface. 258 Request for Comments 1508 260 [4] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, 261 J. Trostle, Public Key Cryptography for Initial Authentication in 262 Kerberos, http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos- 263 pkinit-10.txt. 265 10. This draft expires on January 31st, 2001. 267 11. Authors' Addresses 269 Michael Swift 270 Microsoft 271 One Microsoft Way 272 Redmond, Washington, 98052, U.S.A. 273 Email: mikesw@microsoft.com 275 Jonathan Trostle 276 170 W. Tasman Dr. 277 San Jose, CA 95134, U.S.A. 278 Email: jtrostle@cisco.com 279 Phone: (408) 527-6201