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