idnits 2.17.1 draft-ietf-cat-iakerb-07.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 1) being 63 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 1 character 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. -- The draft header indicates that this document updates RFC1964, but the abstract doesn't seem to directly say this. It does mention RFC1964 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) -- Looks like a reference, but probably isn't: 'APPLICATION 0' on line 193 -- Looks like a reference, but probably isn't: 'APPLICATION 17' on line 347 == Missing Reference: '0' is mentioned on line 348, but not defined ** Obsolete normative reference: RFC 1510 (ref. '1') (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 2078 (ref. '3') (Obsoleted by RFC 2743) -- No information found for draft-ietf-cat-kerberos-pkinit - is the name correct? -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-06) exists of draft-hornstein-dhc-kerbauth-02 -- Possible downref: Normative reference to a draft: ref. '5' ** Obsolete normative reference: RFC 2478 (ref. '8') (Obsoleted by RFC 4178) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Mike Swift 3 draft-ietf-cat-iakerb-07.txt University of WA 4 Updates: RFC 1510, 1964 Jonathan Trostle 5 July 2001 Cisco Systems 6 Bernard Aboba 7 Microsoft 8 Glen Zorn 9 Cisco Systems 11 Extending the GSS Kerberos Mechanism for Initial Kerberos Authentication 12 (IAKERB) 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026 [6]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This draft expires in January 2002. Please send comments to the 37 authors. 39 1. Abstract 41 This document defines extensions to the Kerberos protocol 42 specification (RFC 1510 [1]) and GSSAPI Kerberos mechanism (RFC 1964 43 [2]) that enables a RFC 1964 client to obtain Kerberos tickets for 44 services where the KDC is not accessible to the client, but is 45 accessible to the application server. Some common scenarios where 46 lack of accessibility would occur are when the client does not have 47 an IP address prior to authenticating to an access point, the client 48 is unable to locate a KDC, or a KDC is behind a firewall. The 49 document specifies two protocols to allow a client to exchange KDC 50 messages (which are GSS encapsulated) with an IAKERB proxy instead of 51 a KDC. 53 2. Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC2119 [7]. 59 3. Motivation 61 When authenticating using Kerberos V5, clients obtain tickets from a 62 KDC and present them to services. This method of operation works well 63 in many situations, but is not always applicable. The following is a 64 list of some of the scenarios that this proposal addresses: 66 (1) The client must initially authenticate to an access point in 67 order to gain full access to the network. Here the client may be 68 unable to directly contact the KDC either because it does not have an 69 IP address, or the access point packet filter does not allow the 70 client to send packets to the Internet before it authenticates to the 71 access point. 73 (2) A KDC is behind a firewall so the client will send Kerberos 74 messages to the IAKERB proxy which will transmit the KDC request and 75 reply messages between the client and the KDC. (The IAKERB proxy is a 76 special type of Kerberos application server that also relays KDC 77 request and reply messages between a client and the KDC). 79 4. Overview 81 This proposal specifies two protocols that address the above 82 scenarios: the IAKERB proxy option and the IAKERB minimal messages 83 option. In the IAKERB proxy option (see Figure 1) an application 84 server called the IAKERB proxy acts as a protocol gateway and proxies 85 Kerberos messages back and forth between the client and the KDC. The 86 IAKERB proxy is also responsible for locating the KDC and may 87 additionally perform other application proxy level functions such as 88 auditing. 90 Client <---------> IAKERB proxy <----------> KDC 92 Figure 1: IAKERB proxying 94 The second protocol is the minimal messages protocol that extends the 95 technique in [5]; this protocol is targetted at environments where 96 the number of messages (prior to key establishment) needs to be 97 minimized. Here the client sends its ticket granting ticket (TGT) to 98 the IAKERB proxy (in a KRB_TKT_PUSH message) for the TGS case. The 99 IAKERB proxy then sends a TGS_REQ to the KDC with the client's TGT in 100 the additional tickets field of the TGS_REQ message. As a result, the 101 returned ticket will list the client as the ticket's server 102 principal, and will be encrypted with the session key from the 103 client's TGT. The IAKERB proxy then uses this ticket to generate an 104 AP request that is sent to the client (see Figure 2). Thus mutual 105 authentication is accomplished with three messages between the client 106 and the IAKERB proxy versus four or more (the difference is larger if 107 crossrealm operations are involved). Subsequent to mutual 108 authentication and key establishment, the IAKERB proxy sends a ticket 109 to the client (in a KRB_TKT_PUSH message) that contains the same 110 fields as the original service ticket except the client and server 111 names are reversed and it is encrypted in a long term key known to 112 the IAKERB proxy. Its purpose is to enable fast subsequent re- 113 authentication by the client to the application server (using the 114 conventional AP request AP reply exchange) for subsequent sessions. 115 In addition to minimizing the number of messages, a secondary goal is 116 to minimize the number of bytes transferred between the client and 117 the IAKERB proxy prior to mutual authentication and key 118 establishment. Therefore, the final service ticket (the reverse 119 ticket) is sent after mutual authentication and key establishment is 120 complete, rather than as part of the initial AP_REQ from the IAKERB 121 proxy to the client. 123 The AS_REQ case for the minimal messages option is similar, where the 124 client sends up the AS_REQ message and the IAKERB proxy forwards it 125 to the KDC. The IAKERB proxy pulls the client TGT out of the AS_REP 126 message and also forwards the AS_REP message back to the client. The 127 protocol now proceeds as in the TGS_REQ case with the IAKERB proxy 128 including the client's TGT in the additional tickets field of the 129 TGS_REQ message. 131 Client --------> IAKERB proxy 132 TKT_PUSH (w/ TGT) 134 Client IAKERB proxy --------------------> KDC 135 TGS_REQ with client 136 TGT as additional TGT 138 Client IAKERB proxy <-------------------- KDC 139 TGS_REP with service 140 ticket 142 Client <-------- IAKERB proxy KDC 143 AP_REQ 145 Client --------> IAKERB proxy KDC 146 AP_REP 148 ------------------------------------------------------------- 149 post-key establishment and application data flow phase: 151 Client <-------- IAKERB proxy KDC 152 TKT_PUSH (w/ticket targetted at IAKERB proxy 153 to enable fast subsequent authentication) 155 Figure 2: IAKERB Minimal Messages Option: TGS case 157 A compliant IAKERB proxy MUST implement the IAKERB proxy protocol, 158 and MAY implement the IAKERB minimal message protocol. In general, 159 the existing Kerberos paradigm where clients contact the KDC to 160 obtain service tickets should be preserved where possible. 162 If the client has a service ticket for the target server, needs to 163 authenticate to the target server, and does not have direct 164 connectivity with the target server, it should use the IAKERB proxy 165 protocol. If the client needs to obtain a crossrealm TGT (and the 166 conventional Kerberos protocol cannot be used), then the IAKERB proxy 167 protocol must be used. In a scenario where the client does not have a 168 service ticket for the target server, it is crucial that the number 169 of messages between the client and the target server be minimized 170 (especially if the client and target server are in different realms), 171 and/or it is crucial that the number of bytes transferred between the 172 client and the target server be minimized, then the client should 173 consider using the minimal messages protocol. The reader should see 174 the security considerations section regarding the minimal messages 175 protocol. 177 5. GSSAPI Encapsulation 179 The mechanism ID for IAKERB proxy GSS-API Kerberos, in accordance 180 with the mechanism proposed by SPNEGO [8] for negotiating protocol 181 variations, is: {iso(1) org(3) dod(6) internet(1) security(5) 182 mechanisms(5) iakerb(10) iakerbProxyProtocol(1)}. The proposed 183 mechanism ID for IAKERB minimum messages GSS-API Kerberos, in 184 accordance with the mechanism proposed by SPNEGO for negotiating 185 protocol variations, is: {iso(1) org(3) dod(6) internet(1) 186 security(5) mechanisms(5) iakerb(10) 187 iakerbMinimumMessagesProtocol(2)}. 189 The AS request, AS reply, TGS request, and TGS reply messages are all 190 encapsulated using the format defined by RFC1964 [2]. This consists 191 of the GSS-API token framing defined in appendix B of RFC1508 [3]: 193 InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { 194 thisMech MechType 195 -- MechType is OBJECT IDENTIFIER 196 -- representing "Kerberos V5" 197 innerContextToken ANY DEFINED BY thisMech 198 -- contents mechanism-specific; 199 -- ASN.1 usage within innerContextToken 200 -- is not required 201 } 203 The innerContextToken consists of a 2-byte TOK_ID field (defined 204 below), followed by the Kerberos V5 KRB_AS_REQ, KRB_AS_REP, 205 KRB_TGS_REQ, or KRB_TGS_REP messages, as appropriate. The TOK_ID 206 field shall be one of the following values, to denote that the 207 message is either a request to the KDC or a response from the KDC. 209 Message TOK_ID 211 KRB_KDC_REQ 00 03 213 KRB_KDC_REP 01 03 215 We also define the token ID for the KRB_TKT_PUSH message (defined 216 below and used in the minimal messages variation): 218 Message TOK_ID 220 KRB_TKT_PUSH 02 03 222 For completeness, we list the other RFC 1964 defined token ID's here: 224 Message TOK_ID 226 AP_REQ 01 00 228 AP_REP 02 00 230 KRB_ERROR 03 00 232 6. The IAKERB proxy protocol 234 The IAKERB proxy will proxy Kerberos KDC request, KDC reply, and 235 KRB_ERROR messages back and forth between the client and the KDC as 236 illustrated in Figure 1. Messages received from the client must first 237 have the Kerberos GSS header (RFC1964 [2]) stripped off. The 238 unencapsulated message will then be forwarded to a KDC. The IAKERB 239 proxy is responsible for locating an appropriate KDC using the realm 240 information in the KDC request message it received from the client. 241 In addition, the IAKERB proxy SHOULD implement a retry algorithm for 242 KDC requests over UDP (including selection of alternate KDC's if the 243 initial KDC does not respond to its requests). For messages sent by 244 the KDC, the IAKERB proxy encapsulates them with a Kerberos GSS 245 header before sending them to the client. 247 We define two new Kerberos error codes that allow the proxy to 248 indicate the following error conditions to the client: 250 (a) when the proxy is unable to obtain an IP address for a KDC in the 251 client's realm, it sends the KRB_IAKERB_ERR_KDC_NOT_FOUND KRB_ERROR 252 (80) message to the client. 254 (b) when the proxy has an IP address for a KDC in the client realm, 255 but does not receive a response from any KDC in the realm (including 256 in response to retries), it sends the KRB_IAKERB_ERR_KDC_NO_RESPONSE 257 KRB_ERROR (81) message to the client. 259 To summarize, the sequence of steps for processing is as follows: 261 Servers: 263 1. For received KDC_REQ messages (with token ID 00 03) 264 - process GSS framing (check OID) 265 if the OID is not one of the two OID's specified in the GSSAPI 266 Encapsulation section above, then process according to mechanism 267 defined by that OID (if the OID is recognized). The processing 268 is outside the scope of this specification. Otherwise, strip 269 off GSS framing. 270 - find KDC for specified realm (if KDC IP address cannot be 271 obtained, send a KRB_ERROR message with error code 272 KRB_IAKERB_ERR_KDC_NOT_FOUND to the client). 273 - send to KDC (storing client IP address, port, and indication 274 whether IAKERB proxy option or minimal messages option is 275 being used) 276 - retry with same or another KDC if no response is received. If 277 the retries also fail, send an error message with error code 278 KRB_IAKERB_ERR_KDC_NO_RESPONSE to the client. 280 2. For received KDC_REP messages 281 - encapsulate with GSS framing, using token ID 01 03 and the OID 282 that corresponds to the stored protocol option 283 - send to client (using the stored client IP address and port) 285 3. For received AP_REQ and AP_REP messages 286 - process locally per RFC 1964 288 Clients: 290 1. For sending KDC_REQ messages 291 - create AS_REQ or TGS_REQ message 292 - encapsulate with GSS framing (token ID 00 03 and OID 293 corresponding to the protocol option). 294 - send to server 296 2. For received KDC_REP messages 297 - decapsulate by removing GSS framing (token ID 01 03) 298 - process inner Kerberos message according to RFC 1510 300 3. For received AP_REQ and AP_REP messages 301 - process locally per RFC 1964 303 7. The IAKERB minimal messages protocol 305 The client MAY initiate the IAKERB minimal messages variation when 306 the number of messages must be minimized (the most significant 307 reduction in the number of messages can occur when the client and the 308 IAKERB proxy are in different realms). SPNEGO [8] may be used to 309 securely negotiate between the protocols. A compliant IAKERB server 310 MAY support the IAKERB minimal messages protocol. 312 (a) AS_REQ case: (used when the client does not have a TGT) 314 We extend the technique used in Hornstein [5]. The client indicates 315 that the minimal message sub-protocol will be used by using the 316 appropriate OID as described above. The client sends the GSS 317 encapsulated AS_REQ message to the IAKERB proxy, and the IAKERB proxy 318 processes the GSS framing (as described above for the IAKERB proxy 319 option) and forwards the AS_REQ message to the KDC. 321 The IAKERB proxy will proxy the returned message (AS_REP or 322 KRB_ERROR) from the KDC back to the client (after processing and 323 removing the GSS framing). The protocol is complete in the KRB_ERROR 324 case (from the server perspective, but the client should retry 325 depending on the error type). In the AS_REP case, the IAKERB proxy 326 will obtain the client's TGT from the AS_REP message before 327 forwarding the AS_REP message to the client. The IAKERB proxy then 328 sends a TGS_REQ message with the client's TGT in the additional 329 tickets field to the client's KDC (ENC-TKT-IN-SKEY option). 331 The IAKERB proxy MAY handle returned KRB_ERROR messages and retry the 332 TGS request message. Ultimately, the IAKERB proxy either proxies a 333 KRB_ERROR message to the client, or it sends a GSS Initial Context 334 token containing an AP_REQ message to the client. (Note: although the 335 server sends the initial context token, the client is the initiator.) 336 The IAKERB proxy MUST set the MUTUAL AUTH flag in the Initial Context 337 token in order to cause the client to authenticate as well. The 338 client will reply with the GSSAPI enscapsulated AP_REP message, if 339 the IAKERB proxy's authentication succeeds. If all goes well, then, 340 in order to enable subsequent efficient client authentications, the 341 IAKERB proxy will then send a final message of type KRB_TKT_PUSH 342 containing a Kerberos ticket (the reverse ticket) that has the IAKERB 343 client principal identifier in the client identifier field of the 344 ticket and its own principal identity in the server identifier field 345 of the ticket: 347 KRB_TKT_PUSH :: = [APPLICATION 17] SEQUENCE { 348 pvno[0] INTEGER, -- 5 (protocol version) 349 msg-type[1] INTEGER, -- 17 (message type) 350 ticket[2] Ticket 351 } 353 The key used to encrypt the reverse ticket is a long term secret key 354 chosen by the IAKERB proxy. The fields are identical to the AP_REQ 355 ticket, except the client name will be switched with the server name, 356 and the server realm will be switched with the client realm. (The one 357 other exception is that addresses should not be copied unless the 358 IAKERB proxy has included the client's address in the TGS_REQ message 359 to the KDC). Sending the reverse ticket allows the client to 360 efficiently initiate subsequent reauthentication attempts with a 361 RFC1964 AP_REQ message. Note that the TKT_PUSH message is sent after 362 mutual authentication and key establishment are complete. 364 (b) TGS_REQ case: (used when the client has a TGT) 366 The client indicates that the minimal messages sub-protocol will be 367 used by using the appropriate OID as described above. The client 368 initially sends a KRB_TKT_PUSH message (with the GSS header) to the 369 IAKERB proxy in order to send it a TGT. The IAKERB proxy will obtain 370 the client's TGT from the KRB_TKT_PUSH message and then proceed to 371 send a TGS_REQ message to a KDC where the realm of the KDC is equal 372 to the realm from the server realm field in the TGT sent by the 373 client in the KRB_TKT_PUSH message. The protocol then continues as in 374 the minimal messages AS_REQ case described above (see Figure 2); the 375 IAKERB proxy's TGS_REQ message contains the client's TGT in the 376 additional tickets field (ENC-TKT-IN-SKEY option). The IAKERB proxy 377 then receives the TGS_REP message from the KDC and then sends a RFC 378 1964 AP_REQ message to the client (with the MUTUAL AUTH flag set - 379 see AS_REQ case). 381 8. Addresses in Tickets 383 In IAKERB, the machine sending requests to the KDC is the server and 384 not the client. As a result, the client should not include its 385 addresses in any KDC requests for two reasons. First, the KDC may 386 reject the forwarded request as being from the wrong client. Second, 387 in the case of initial authentication for a dial-up client, the 388 client machine may not yet possess a network address. Hence, as 389 allowed by RFC1510 [1], the addresses field of the AS and TGS 390 requests SHOULD be blank and the caddr field of the ticket SHOULD 391 similarly be left blank. One exception is in an AS request (where the 392 request body is not integrity protected); the IAKERB proxy MAY add 393 its own addresses and the addresses of the client to the AS request. 395 9. Combining IAKERB with Other Kerberos Extensions 397 This protocol is usable with other proposed Kerberos extensions such 398 as PKINIT (Public Key Cryptography for Initial Authentication in 399 Kerberos [4]). In such cases, the messages which would normally be 400 sent to the KDC are instead sent by the client application to the 401 server, which then forwards them to a KDC. 403 10. Security Considerations 405 In the minimal messages protocol option, the application server sends 406 an AP_REQ message to the client. The ticket in the AP_REQ message 407 SHOULD NOT contain authorization data since some operating systems 408 may allow the client to impersonate the server and increase its own 409 privileges. If the ticket from the server connotes any authorization, 410 then the minimal messages protocol should not be used. Also, the 411 minimal messages protocol may facilitate denial of service attacks in 412 some environments; to prevent these attacks, it may make sense for 413 the minimal messages protocol server to only accept a KRB_TGT_PUSH 414 message on a local network interface (to ensure that the message was 415 not sent from a remote malicious host). 417 11. Acknowledgements 419 We thank Ken Raeburn for his helpful comments. 421 12. References 423 [1] J. Kohl, C. Neuman, "The Kerberos Network Authentication 424 Service (V5)", RFC 1510. 426 [2] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964. 428 [3] J. Linn, "Generic Security Service Application Program Interface", 429 RFC 2078. 431 [4] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, J. Wray, 432 J. Trostle, "Public Key Cryptography for Initial Authentication in 433 Kerberos", WORK IN PROGRESS Internet Draft 434 draft-ietf-cat-kerberos-pkinit-12.txt. 436 [5] K. Hornstein, T. Lemon, B. Aboba, J. Trostle, "DHCP Authentication 437 via Kerberos V", WORK IN PROGRESS Internet Draft 438 draft-hornstein-dhc-kerbauth-02.txt. 440 [6] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 441 9, RFC 2026, October 1996. 443 [7] S. Bradner, "Key words for use in RFCs to Indicate Requirement 444 Levels", BCP 14, RFC 2119, March 1997. 446 [8] E. Baize, D. Pinkas, "The Simple and Protected GSS-API Negotiation 447 Mechanism," RFC 2478, December 1998. 449 12. Author's Addresses 451 Michael Swift 452 University of Washington 453 Seattle, WA 454 Email: mikesw@cs.washington.edu 456 Jonathan Trostle 457 Cisco Systems 458 170 W. Tasman Dr. 459 San Jose, CA 95134, U.S.A. 460 Email: jtrostle@cisco.com 461 Phone: (408) 527-6201 463 Bernard Aboba 464 Microsoft 465 One Microsoft Way 466 Redmond, Washington, 98052, U.S.A. 467 Email: bernarda@microsoft.com 469 Glen Zorn 470 Cisco Systems 471 Bellevue, WA U.S.A. 472 Email: gwz@cisco.com 473 Phone: (425) 468-0955 475 This draft expires on January 31st, 2002.