idnits 2.17.1 draft-ietf-cat-iakerb-03.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 1 longer page, the longest (page 1) being 284 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 8 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 '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 252 looks like a reference -- Missing reference section? '2' on line 255 looks like a reference -- Missing reference section? '3' on line 258 looks like a reference -- Missing reference section? 'APPLICATION 0' on line 126 looks like a reference -- Missing reference section? '4' on line 261 looks like a reference Summary: 6 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-03.txt Microsoft 3 Updates: RFC 1510 Jonathan Trostle 4 expires April 30, 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 1. Abstract 33 This document defines an extension to the Kerberos protocol 34 specification (RFC 1510 [1]) and GSSAPI Kerberos mechanism (RFC 35 1964 [2]) that enables a client to obtain Kerberos tickets for 36 services where: 38 (1) The client knows its principal name and password, but not 39 its realm name (applicable in the situation where a user is already 40 on the network but needs to authenticate to an ISP, and the user 41 does not know his ISP realm name). 42 (2) The client is able to obtain the IP address of the service in 43 a realm which it wants to send a request to, but is otherwise unable 44 to locate or communicate with a KDC in the service realm or one of 45 the intermediate realms. (One example would be a dial up user who 46 does not have direct IP connectivity). 47 (3) The client does not know the realm name of the service. 49 2. Motivation 51 When authenticating using Kerberos V5, clients obtain tickets from 52 a KDC and present them to services. This method of operation works 53 well in many situations, but is not always applicable since it 54 requires the client to know its own realm, the realm of the target 56 service, the names of the KDC's, and to be able to connect to the 57 KDC's. 59 This document defines an extension to the Kerberos protocol 60 specification (RFC 1510) [1] that enables a client to obtain 61 Kerberos tickets for services where: 63 (1) The client knows its principal name and password, but not 64 its realm name (applicable in the situation where a user is already 65 on the network but needs to authenticate to an ISP, and the user 66 does not know his ISP realm name). 67 (2) The client is able to obtain the IP address of the service in 68 a realm which it wants to send a request to, but is otherwise unable 69 to locate or communicate with a KDC in the service realm or one of 70 the intermediate realms. (One example would be a dial up user who 71 does not have direct IP connectivity). 72 (3) The client does not know the realm name of the service. 74 In this proposal, the client sends KDC request messages directly 75 to application servers if one of the above failure cases develops. 76 The application server acts as a proxy, forwarding messages back 77 and forth between the client and various KDC's (see Figure 1). 79 Client <---------> App Server <----------> KDC 80 proxies 82 Figure 1: IAKERB proxying 84 In the case where the client has sent a TGS_REQ message to the 85 application server without a realm name in the request, the 86 application server will forward an error message to the client 87 with its realm name in the e-data field of the error message. 88 The client will attempt to proceed using conventional Kerberos. 90 3. When Clients Should Use IAKERB 92 We list several, but possibly not all, cases where the client 93 should use IAKERB. In general, the existing Kerberos paradigm 94 where clients contact the KDC to obtain service tickets should 95 be preserved where possible. 97 (a) AS_REQ cases: 99 (i) The client is unable to locate the user's KDC or the KDC's 100 in the user's realm are not responding, or 101 (ii) The user has not entered a name which can be converted 102 into a realm name (and the realm name cannot be derived from 103 a certificate). 105 (b) TGS_REQ cases: 107 (i) the client determines that the KDC(s) in either an 108 intermediate realm or the service realm are not responding or 109 the client is unable to locate a KDC, 111 (ii) the client is not able to generate the application server 112 realm name. 114 4. GSSAPI Encapsulation 116 The mechanism ID for IAKERB GSS-API Kerberos, in accordance with the 117 mechanism proposed by SPNEGO for negotiating protocol variations, is: 118 {iso(1) member-body(2) United States(840) mit(113554) infosys(1) 119 gssapi(2) krb5(2) initialauth(4)} 121 The AS request, AS reply, TGS request, and TGS reply messages are all 122 encapsulated using the format defined by RFC1964 [2]. This consists 123 of the GSS-API token framing defined in appendix B of RFC1508 [3]: 125 InitialContextToken ::= 126 [APPLICATION 0] IMPLICIT SEQUENCE { 127 thisMech MechType 128 -- MechType is OBJECT IDENTIFIER 129 -- representing "Kerberos V5" 130 innerContextToken ANY DEFINED BY thisMech 131 -- contents mechanism-specific; 132 -- ASN.1 usage within innerContextToken 133 -- is not required 134 } 136 The innerContextToken consists of a 2-byte TOK_ID field (defined 137 below), followed by the Kerberos V5 KRB-AS-REQ, KRB-AS-REP, 138 KRB-TGS-REQ, or KRB-TGS-REP messages, as appropriate. The TOK_ID field 139 shall be one of the following values, to denote that the message is 140 either a request to the KDC or a response from the KDC. 142 Message TOK_ID 143 KRB-KDC-REQ 00 03 144 KRB-KDC-REP 01 03 146 5. The Protocol 148 a. The user supplies a password (AS_REQ): Here the Kerberos client 149 will send an AS_REQ message to the application server if it cannot 150 locate a KDC for the user's realm, or such KDC's do not respond, 151 or the user does not enter a name from which the client can derive 152 the user's realm name. The client sets the realm field of the 153 request equal to its own realm if the realm name is known, 154 otherwise the realm length is set to 0. Upon receipt of the AS_REQ 155 message, the application server checks if the client has included 156 a realm. 158 If the realm was not included in the original request, the 159 application server must determine the realm and add it to the 160 AS_REQ message before forwarding it. If the application server 161 cannot determine the client realm, it returns the 162 KRB_AP_ERR_REALM_REQUIRED error-code in an error message to 163 the client): 165 KRB_AP_ERR_REALM_REQUIRED 77 167 The error message can be sent in response to either an AS_REQ 168 message, in which case the e-data is empty; or in response to 169 a TGS_REQ message, in which case the e-data will contain the 170 realm of the application server encoded as an OCTET STRING. 171 Once the realm is filled in, the application server forwards 172 the request to a KDC in the user's realm. It will retry the 173 request if necessary, and forward the KDC response back to 174 the client. 176 At the time the user enters a username and password, the client 177 should create a new credential with an INTERNAL NAME [3] that can 178 be used as an input into the GSS_Acquire_cred function call. 180 This functionality is useful when there is no trust relationship 181 between the user's logon realm and the target realm (Figure 2). 183 User Realm KDC 184 / 185 / 186 / 187 / 2,3 188 1,4 / 189 Client<-------------->App Server 191 1 Client sends AS_REQ to App Server 192 2 App server forwards AS_REQ to User Realm KDC 193 3 App server receives AS_REP from User Realm KDC 194 4 App server sends AS_REP back to Client 196 Figure 2: IAKERB AS_REQ 198 b. The user does not supply a password (TGS_REQ): The user includes a 199 TGT targetted at the user's realm, or an intermediate realm, in a 200 TGS_REQ message. The TGS_REQ message is sent to the application 201 server. 203 If the client has included the realm name in the TGS request, then 204 the application server will forward the request to a KDC in the 205 request TGT srealm. It will forward the response back to the client. 207 If the client has not included the realm name in the TGS request, 208 then the application server will return its realm name to the 209 client using the KRB_AP_ERR_REALM_REQUIRED error described above. 210 The error message e-data field contains the application server 211 realm name. Note that another principal with the same principal 212 name and a different realm than the intended application server 213 can replace the realm name with its own, thus setting the stage 214 for an impersonation attack. Therefore, sending a TGS_REQ message 215 to the application server without a realm name in the request 216 is a last resort (see security considerations below). 218 The client can now proceed using conventional Kerberos with the 219 realm name from the error message. 221 6. Addresses in Tickets 223 In IAKERB, the machine sending requests to the KDC is the server and 224 not the client. As a result, the client should not include its 225 addresses in any KDC requests for two reasons. First, the KDC may 226 reject the forwarded request as being from the wrong client. Second, 227 in the case of initial authentication for a dial-up client, the client 228 machine may not yet possess a network address. Hence, as allowed by 229 RFC1510 [1], the addresses field of the AS and TGS requests should be 230 blank and the caddr field of the ticket should similarly be left blank. 232 7. Combining IAKERB with Other Kerberos Extensions 234 This protocol is usable with other proposed Kerberos extensions such as 235 PKINIT (Public Key Cryptography for Initial Authentication in Kerberos 236 [4]). In such cases, the messages which would normally be sent to the 237 KDC by the GSS runtime are instead sent by the client application to the 238 server, which then forwards them to a KDC. 240 8. Security Considerations 242 A principal is identified by its principal name and realm. A client 243 that sends a TGS request to an application server without the request 244 realm name will only be able to mutually authenticate the server 245 up to its principal name; another server with the same principal name 246 and a different realm name, that has a trust relationship with the 247 client, will be able to impersonate the intended application server. 248 Thus, such requests should only be used as a last resort. 250 9. Bibliography 252 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication 253 Service (V5). Request for Comments 1510. 255 [2] J. Linn. The Kerberos Version 5 GSS-API Mechanism. Request 256 for Comments 1964 258 [3] J. Linn. Generic Security Service Application Program Interface. 259 Request for Comments 1508 261 [4] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, 262 J. Trostle, Public Key Cryptography for Initial Authentication in 263 Kerberos, http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos- 264 pkinit-10.txt. 266 10. Expires April 30, 2000. 268 11. Authors' Addresses 270 Michael Swift 271 Microsoft 272 One Microsoft Way 273 Redmond, Washington, 98052, U.S.A. 274 Email: mikesw@microsoft.com 276 Jonathan Trostle 277 170 W. Tasman Dr. 278 San Jose, CA 95134, U.S.A. 279 Email: jtrostle@cisco.com 280 Phone: (408) 527-6201