idnits 2.17.1 draft-ietf-cat-iakerb-08.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 13 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 2 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 204 -- Looks like a reference, but probably isn't: 'APPLICATION 17' on line 405 == Missing Reference: '0' is mentioned on line 406, but not defined ** Obsolete normative reference: RFC 1510 (ref. '1') (Obsoleted by RFC 4120, RFC 6649) -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2478 (ref. '7') (Obsoleted by RFC 4178) -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Jonathan Trostle 3 draft-ietf-cat-iakerb-08.txt Cisco Systems 4 Updates: RFC 1510, 1964 Michael Swift 5 September 2001 University of WA 6 Bernard Aboba 7 Microsoft 8 Glen Zorn 9 Cisco Systems 11 Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API 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 [5]. 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 March 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 protocol mechanism 43 (RFC 1964 [2]) that enables a 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 [6]. 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 [8]. 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. A compliant IAKERB proxy MUST implement the IAKERB proxy 89 protocol. 91 Client <---------> IAKERB proxy <----------> KDC 93 Figure 1: IAKERB proxying 95 The second protocol is the minimal messages protocol which is based 96 on user-user authentication [4]; this protocol is targetted at 97 environments where the number of messages, prior to key 98 establishment, needs to be minimized. In the normal minimal messages 99 protocol, the client sends its ticket granting ticket (TGT) to the 100 IAKERB proxy (in a KRB_TKT_PUSH message) for the TGS case. The IAKERB 101 proxy then sends a TGS_REQ to the KDC with the client's TGT in the 102 additional tickets field of the TGS_REQ message. The returned ticket 103 will list the client as the ticket's server principal, and will be 104 encrypted with the session key from the client's TGT. The IAKERB 105 proxy then uses this ticket to generate an AP request that is sent to 106 the client (see Figure 2). Thus mutual authentication is accomplished 107 with three messages between the client and the IAKERB proxy versus 108 four or more (the difference is larger if crossrealm operations are 109 involved). 111 Subsequent to mutual authentication and key establishment, the IAKERB 112 proxy sends a ticket to the client (in a KRB_TKT_PUSH message). This 113 ticket is created by the IAKERB proxy and contains the same fields as 114 the original service ticket that the proxy sent in the AP_REQ 115 message, except the client and server names are reversed and it is 116 encrypted in a long term key known to the IAKERB proxy. Its purpose 117 is to enable fast subsequent re-authentication by the client to the 118 application server (using the conventional AP request AP reply 119 exchange) for subsequent sessions. In addition to minimizing the 120 number of messages, a secondary goal is to minimize the number of 121 bytes transferred between the client and the IAKERB proxy prior to 122 mutual authentication and key establishment. Therefore, the final 123 service ticket (the reverse ticket) is sent after mutual 124 authentication and key establishment is complete, rather than as part 125 of the initial AP_REQ from the IAKERB proxy to the client. Thus 126 protected application data (e.g., GSS signed and wrapped messages) 127 can flow before this final message is sent. 129 The AS_REQ case for the minimal messages option is similar, where the 130 client sends up the AS_REQ message and the IAKERB proxy forwards it 131 to the KDC. The IAKERB proxy pulls the client TGT out of the AS_REP 132 message; the protocol now proceeds as in the TGS_REQ case described 133 above with the IAKERB proxy including the client's TGT in the 134 additional tickets field of the TGS_REQ message. 136 A compliant IAKERB proxy MUST implement the IAKERB proxy protocol, 137 and MAY implement the IAKERB minimal message protocol. In general, 138 the existing Kerberos paradigm where clients contact the KDC to 139 obtain service tickets should be preserved where possible. 141 For most IAKERB scenarios, such as when the client does not have an 142 IP address, or cannot directly contact a KDC, the IAKERB proxy 143 protocol should be adequate. If the client needs to obtain a 144 crossrealm TGT (and the conventional Kerberos protocol cannot be 145 used), then the IAKERB proxy protocol must be used. In a scenario 146 where the client does not have a service ticket for the target 147 server, it is crucial that the number of messages between the client 148 and the target server be minimized (especially if the client and 149 target server are in different realms), and/or it is crucial that the 150 number of bytes transferred between the client and the target server 151 be minimized, then the client should consider using the minimal 152 messages protocol. The reader should see the security considerations 153 section regarding the minimal messages protocol. 155 Client --------> IAKERB proxy 156 TKT_PUSH (w/ TGT) 158 Client IAKERB proxy --------------------> KDC 159 TGS_REQ with client 160 TGT as additional TGT 162 Client IAKERB proxy <-------------------- KDC 163 TGS_REP with service 164 ticket 166 Client <-------- IAKERB proxy KDC 167 AP_REQ 169 Client --------> IAKERB proxy KDC 170 AP_REP 172 ------------------------------------------------------------- 173 post-key establishment and application data flow phase: 175 Client <-------- IAKERB proxy KDC 176 TKT_PUSH (w/ticket targetted at IAKERB proxy 177 to enable fast subsequent authentication) 179 Figure 2: IAKERB Minimal Messages Option: TGS case 181 5. GSSAPI Encapsulation 183 The mechanism ID for IAKERB proxy GSS-API Kerberos, in accordance 184 with the mechanism proposed by SPNEGO [7] for negotiating protocol 185 variations, is: {iso(1) org(3) dod(6) internet(1) security(5) 186 mechanisms(5) iakerb(10) iakerbProxyProtocol(1)}. The proposed 187 mechanism ID for IAKERB minimum messages GSS-API Kerberos, in 188 accordance with the mechanism proposed by SPNEGO for negotiating 189 protocol variations, is: {iso(1) org(3) dod(6) internet(1) 190 security(5) mechanisms(5) iakerb(10) 191 iakerbMinimumMessagesProtocol(2)}. 193 NOTE: An IAKERB implementation does not require SPNEGO in order to 194 achieve interoperability with other IAKERB peers. Two IAKERB 195 implementations may interoperate in the same way that any two peers 196 can interoperate using a pre-established GSSAPI mechanism. The above 197 OID's allow two SPNEGO peers to securely negotiate IAKERB from among 198 a set of GSS mechanisms. 200 The AS request, AS reply, TGS request, and TGS reply messages are all 201 encapsulated using the format defined by RFC1964 [2]. This consists 202 of the GSS-API token framing defined in appendix B of [3]: 204 InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { 205 thisMech MechType 206 -- MechType is OBJECT IDENTIFIER 207 -- representing iakerb proxy or iakerb min messages 208 innerContextToken ANY DEFINED BY thisMech 209 -- contents mechanism-specific; 210 -- ASN.1 usage within innerContextToken 211 -- is not required 212 } 214 The innerContextToken consists of a 2-byte TOK_ID field (defined 215 below), followed by the Kerberos V5 KRB_AS_REQ, KRB_AS_REP, 216 KRB_TGS_REQ, or KRB_TGS_REP messages, as appropriate. The TOK_ID 217 field shall be one of the following values, to denote that the 218 message is either a request to the KDC or a response from the KDC. 220 Message TOK_ID 222 KRB_KDC_REQ 00 03 224 KRB_KDC_REP 01 03 226 We also define the token ID for the KRB_TKT_PUSH token (defined below 227 and used in the minimal messages variation): 229 Message TOK_ID 231 KRB_TKT_PUSH 02 03 233 For completeness, we list the other RFC 1964 defined token ID's here: 235 Message TOK_ID 237 AP_REQ 01 00 239 AP_REP 02 00 241 KRB_ERROR 03 00 243 6. The IAKERB proxy protocol 245 The IAKERB proxy will proxy Kerberos KDC request, KDC reply, and 246 KRB_ERROR messages back and forth between the client and the KDC as 247 illustrated in Figure 1. Messages received from the client must first 248 have the Kerberos GSS header (RFC1964 [2]) stripped off. The 249 unencapsulated message will then be forwarded to a KDC. The IAKERB 250 proxy is responsible for locating an appropriate KDC using the realm 251 information in the KDC request message it received from the client. 252 In addition, the IAKERB proxy SHOULD implement a retry algorithm for 253 KDC requests over UDP (including selection of alternate KDC's if the 254 initial KDC does not respond to its requests). For messages sent by 255 the KDC, the IAKERB proxy encapsulates them with a Kerberos GSS 256 header before sending them to the client. 258 We define two new Kerberos error codes that allow the proxy to 259 indicate the following error conditions to the client: 261 (a) when the proxy is unable to obtain an IP address for a KDC in the 262 client's realm, it sends the KRB_IAKERB_ERR_KDC_NOT_FOUND KRB_ERROR 263 (80) message to the client. 265 (b) when the proxy has an IP address for a KDC in the client realm, 266 but does not receive a response from any KDC in the realm (including 267 in response to retries), it sends the KRB_IAKERB_ERR_KDC_NO_RESPONSE 268 KRB_ERROR (81) message to the client. 270 To summarize, the sequence of steps for processing is as follows: 272 Servers: 274 1. For received KDC_REQ messages (with token ID 00 03) 275 - process GSS framing (check OID) 276 if the OID is not one of the two OID's specified in the GSSAPI 277 Encapsulation section above, then process according to mechanism 278 defined by that OID (if the OID is recognized). The processing 279 is outside the scope of this specification. Otherwise, strip 280 off GSS framing. 281 - find KDC for specified realm (if KDC IP address cannot be 282 obtained, send a KRB_ERROR message with error code 283 KRB_IAKERB_ERR_KDC_NOT_FOUND to the client). 284 - send to KDC (storing client IP address, port, and indication 285 whether IAKERB proxy option or minimal messages option is 286 being used) 287 - retry with same or another KDC if no response is received. If 288 the retries also fail, send an error message with error code 289 KRB_IAKERB_ERR_KDC_NO_RESPONSE to the client. 291 2. For received KDC_REP messages 292 - encapsulate with GSS framing, using token ID 01 03 and the OID 293 that corresponds to the stored protocol option 294 - send to client (using the stored client IP address and port) 296 3. For KRB_ERROR messages received from the KDC 297 - encapsulate with GSS framing, using token ID 03 00 and the OID 298 that corresponds to the stored protocol option 299 - send to client (using the stored client IP address and port) 300 (one possible exception is the KRB_ERR_RESPONSE_TOO_BIG error 301 which can lead to a retry of the KDC_REQ message over the TCP 302 transport by the server, instead of simply proxying the error 303 to the client). 305 4. For sending/receiving AP_REQ and AP_REP messages 306 - process per RFC 1510 and RFC 1964; the created AP_REP message 307 SHOULD include the subkey (with same etype as the session key) 308 to facilitate use with other key derivation algorithms outside 309 of [2]. The subkey SHOULD be created using locally generated 310 entropy as one of the inputs (in addition to other inputs 311 such as the session key). 313 Clients: 315 1. For sending KDC_REQ messages 316 - create AS_REQ or TGS_REQ message 317 - encapsulate with GSS framing (token ID 00 03 and OID 318 corresponding to the protocol option). 319 - send to server 321 2. For received KDC_REP messages 322 - decapsulate by removing GSS framing (token ID 01 03) 323 - process inner Kerberos message according to RFC 1510 325 3. For received KRB_ERROR messages 326 - decapsulate by removing GSS framing (token ID 03 00) 327 - process inner Kerberos message according to RFC 1510 328 and possibly retry the request (time skew errors lead 329 to retries in most existing Kerberos implementations) 331 4. For sending/receiving AP_REQ and AP_REP messages 332 - process per RFC 1510 and RFC 1964; the created AP_REQ 333 message SHOULD include the subsession key in the 334 authenticator field. 336 7. The IAKERB minimal messages protocol 338 The client MAY initiate the IAKERB minimal messages variation when 339 the number of messages must be minimized (the most significant 340 reduction in the number of messages can occur when the client and the 341 IAKERB proxy are in different realms). SPNEGO [7] MAY be used to 342 securely negotiate between the protocols (and amongst other GSS 343 mechanism protocols). A compliant IAKERB server MAY support the 344 IAKERB minimal messages protocol. 346 (a) AS_REQ case: (used when the client does not have a TGT) 348 We apply the Kerberos user-user authentication protocol [4] in this 349 scenario (other work in this area includes the IETF work in progress 350 effort to apply Kerberos user user authentication to DHCP 351 authentication). 353 The client indicates that the minimal message sub-protocol will be 354 used by using the appropriate OID as described above. The client 355 sends the GSS encapsulated AS_REQ message to the IAKERB proxy, and 356 the IAKERB proxy processes the GSS framing (as described above for 357 the IAKERB proxy option) and forwards the AS_REQ message to the KDC. 359 The IAKERB proxy will either send a KRB_ERROR message back to the 360 client, or it will send an initial context token consisting of the 361 GSS header (minimal messages OID with a two byte token header 01 03), 362 followed by an AS_REP message. The AS_REP message will contain the 363 AP_REQ message in a padata field; the ticket in the AP_REQ is a 364 user-user ticket encrypted in the session key from the client's 365 original TGT. We define the padata type PA-AP-REQ with type number 366 25. The corresponding padata value is the AP_REQ message without any 367 GSS framing. For the IAKERB minimal messages AS option, the AP_REQ 368 message authenticator MUST include the RFC 1964 [2] checksum. The 369 mutual-required and use-session-key flags are set in the ap-options 370 field of the AP_REQ message. 372 The protocol is complete in the KRB_ERROR case (from the server 373 perspective, but the client should retry depending on the error 374 type). If the IAKERB proxy receives an AS_REP message from the KDC, 375 the IAKERB proxy will then obtain the client's TGT from the AS_REP 376 message. The IAKERB proxy then sends a TGS_REQ message with the 377 client's TGT in the additional tickets field to the client's KDC 378 (ENC-TKT-IN-SKEY option). 380 The IAKERB proxy MAY handle returned KRB_ERROR messages and retry the 381 TGS request message (e.g. on a KRB_ERR_RESPONSE_TOO_BIG error, 382 switching to TCP from UDP). Ultimately, the IAKERB proxy either 383 proxies a KRB_ERROR message to the client (after adding the GSS 384 framing), sends one of the new GSS framed KRB_ERROR messages defined 385 above, or it receives the TGS_REP message from the KDC and then 386 creates the AP_REQ message according to RFC 1964 [2]. The IAKERB 387 proxy then sends a GSS token containing the AS_REP message with the 388 AP_REQ message in the padata field as described above. (Note: 389 although the server sends the context token with the AP_REQ, the 390 client is the initiator.) The IAKERB proxy MUST set both the mutual- 391 required and use-session-key flags in the AP_REQ message in order to 392 cause the client to authenticate as well. The authenticator SHOULD 393 include the subsession key (containing locally added entropy). The 394 client will reply with the GSSAPI enscapsulated AP_REP message, if 395 the IAKERB proxy's authentication succeeds (which SHOULD include the 396 subkey field to facilitate use with other key derivation algorithms 397 outside of [2]). If all goes well, then, in order to enable 398 subsequent efficient client authentications, the IAKERB proxy will 399 then send a final message of type KRB_TKT_PUSH containing a Kerberos 400 ticket (the reverse ticket) that has the IAKERB client principal 401 identifier in the client identifier field of the ticket and its own 402 principal identity in the server identifier field of the ticket (see 403 Figure 3): 405 KRB_TKT_PUSH :: = [APPLICATION 17] SEQUENCE { 406 pvno[0] INTEGER, -- 5 (protocol version) 407 msg-type[1] INTEGER, -- 17 (message type) 408 ticket[2] Ticket 409 } 411 NOTE: The KRB_TKT_PUSH message must be encoded using ASN.1 DER. The 412 key used to encrypt the reverse ticket is a long term secret key 413 chosen by the IAKERB proxy. The fields are identical to the AP_REQ 414 ticket, except the client name will be switched with the server name, 415 and the server realm will be switched with the client realm. (The one 416 other exception is that addresses should not be copied from the 417 AP_REQ ticket to the reverse ticket). Sending the reverse ticket 418 allows the client to efficiently initiate subsequent reauthentication 419 attempts with a RFC1964 AP_REQ message. Note that the TKT_PUSH 420 message is sent after mutual authentication and key establishment are 421 complete. 423 Client --------> IAKERB proxy --------------------> KDC 424 AS_REQ AS_REQ 426 Client IAKERB proxy <-------------------- KDC 427 AS_REP w/ client TGT 429 Client IAKERB proxy --------------------> KDC 430 TGS_REQ with client 431 TGT as additional TGT 433 Client IAKERB proxy <-------------------- KDC 434 TGS_REP with service 435 ticket 437 Client <-------- IAKERB proxy KDC 438 AS_REP w/ AP_REQ in padata field 440 Client --------> IAKERB proxy KDC 441 AP_REP 443 ------------------------------------------------------------- 444 post-key establishment and application data flow phase: 446 Client <-------- IAKERB proxy KDC 447 TKT_PUSH (w/ticket targetted at IAKERB proxy 448 to enable fast subsequent authentication) 450 Figure 3: IAKERB Minimal Messages Option: AS case 452 (b) TGS_REQ case: (used when the client has a TGT) 454 The client indicates that the minimal messages sub-protocol will be 455 used by using the appropriate OID as described above. The client 456 initially sends a KRB_TKT_PUSH message (with the GSS header) to the 457 IAKERB proxy in order to send it a TGT. The IAKERB proxy will obtain 458 the client's TGT from the KRB_TKT_PUSH message and then proceed to 459 send a TGS_REQ message to a KDC where the realm of the KDC is equal 460 to the realm from the server realm field in the TGT sent by the 461 client in the KRB_TKT_PUSH message. NOTE: this realm could be the 462 client's home realm, the proxy's realm, or an intermediate realm. The 463 protocol then continues as in the minimal messages AS_REQ case 464 described above (see Figure 2); the IAKERB proxy's TGS_REQ message 465 contains the client's TGT in the additional tickets field (ENC-TKT- 466 IN-SKEY option). The IAKERB proxy then receives the TGS_REP message 467 from the KDC and then sends a RFC 1964 AP_REQ message to the client 468 (with the MUTUAL AUTH flag set - see AS_REQ case). 470 To summarize, here are the steps for the minimal messages TGS 471 protocol: 473 Client: 474 (has TGT already for, or targetted at, realm X.ORG) 475 sends TKT_PUSH message to server containing client's ticket 476 for X.ORG (which could be a crossrealm TGT) 478 Server: 479 (has TGT already targetted at realm X.ORG) 480 sends to KDC (where KDC has principal id = server name, 481 server realm from client ticket) a TGS_REQ: 482 TGT in TGS_REQ is server's TGT 483 Additional ticket in TGS_REQ is client's TGT from TKT_PUSH 484 message 485 Server name in TGS_REQ (optional by rfc1510) is not present 486 Server realm in TGS_REQ is realm in server's TGT - X.ORG 488 KDC: 489 Builds a ticket: 490 Server name = client's name 491 Client name = server's name, Client realm = server's realm 492 Server realm = client's realm 493 Encrypted with: session key from client's TGT (passed in 494 additional tickets field) 495 Build a TGS_REP 496 Encrypted with session key from server's TGT 497 Sends TGS_REP and ticket to server 499 Server: 500 Decrypts TGS_REP from KDC using session key from its TGT 501 Constructs AP_REQ 502 Ticket = ticket from KDC (which was encrypted with 503 client's TGT session key) 504 authenticator clientname = server's name (matches 505 clientname in AP-REQ ticket) 506 authenticator clientrealm = server's realm 507 subsession key in authenticator is present (same 508 etype as the etype of the session key in the ticket) 509 checksum in authenticator is the RFC 1964 checksum 510 sequence number in authenticator is present (RFC 1964) 511 ap-options has both use-session-key and mutual-required 512 flags set 513 Sends AP_REQ (with GSS-API framing) to client 515 Client: 516 Receives AP_REQ 517 Decrypts ticket using session key from its TGT 518 Verifies AP_REQ 519 Builds AP_REP and sends to server (AP_REP SHOULD include 520 subkey field to facilitate use with other key derivation 521 algorithms outside of [2] e.g., [8] and its successors. 523 Some apps may have their own message protection key 524 derivation algorithm and protected message format. 525 AP_REP includes the sequence number per RFC 1964.) 527 Server: 528 Verifies AP-REP. Builds reverse ticket as described above 529 and sends reverse ticket to client using the KRB_TKT_PUSH 530 message. The reverse ticket is the same as the AP_REQ 531 ticket except the client name, realm are switched with the 532 server name, realm fields and it is encrypted in a secret 533 key known to the IAKERB proxy. 535 8. Addresses in Tickets 537 In IAKERB, the machine sending requests to the KDC is the server and 538 not the client. As a result, the client should not include its 539 addresses in any KDC requests for two reasons. First, the KDC may 540 reject the forwarded request as being from the wrong client. Second, 541 in the case of initial authentication for a dial-up client, the 542 client machine may not yet possess a network address. Hence, as 543 allowed by RFC1510 [1], the addresses field of the AS and TGS 544 requests SHOULD be blank and the caddr field of the ticket SHOULD 545 similarly be left blank. 547 9. Security Considerations 549 Similar to other network access protocols, IAKERB allows an 550 unauthenticated client (possibly outside the security perimeter of an 551 organization) to send messages that are proxied to interior servers. 552 When combined with DNS SRV RR's for KDC lookup, there is the 553 possibility that an attacker can send an arbitrary message to an 554 interior server. There are several aspects to note here: 556 (1) in many scenarios, compromise of the DNS lookup will require the 557 attacker to already have access to the internal network. Thus the 558 attacker would already be able to send arbitrary messages to interior 559 servers. No new vulnerabilities are added in these scenarios. 561 (2) in a scenario where DNS SRV RR's are being used to locate the 562 KDC, IAKERB is being used, and an external attacker can modify DNS 563 responses to the IAKERB proxy, there are several countermeasures to 564 prevent arbitrary messages from being sent to internal servers: 566 (a) KDC port numbers can be statically configured on the IAKERB 567 proxy. In this case, the messages will always be sent to KDC's. For 568 an organization that runs KDC's on a static port (usually port 88) 569 and does not run any other servers on the same port, this 570 countermeasure would be easy to administer and should be effective. 572 (b) the proxy can do application level sanity checking and filtering. 573 This countermeasure should eliminate many of the above attacks. 575 (c) DNS security can be deployed. This countermeasure is probably 576 overkill for this particular problem, but if an organization has 577 already deployed DNS security for other reasons, then it might make 578 sense to leverage it here. Note that Kerberos could be used to 579 protect the DNS exchanges. The initial DNS SRV KDC lookup by the 580 proxy will be unprotected, but an attack here is at most a denial of 581 service (the initial lookup will be for the proxy's KDC to facilitate 582 Kerberos protection of subsequent DNS exchanges between itself and 583 the DNS server). 585 In the minimal messages protocol option, the application server sends 586 an AP_REQ message to the client. The ticket in the AP_REQ message 587 SHOULD NOT contain authorization data since some operating systems 588 may allow the client to impersonate the server and increase its own 589 privileges. If the ticket from the server connotes any authorization, 590 then the minimal messages protocol should not be used. Also, the 591 minimal messages protocol may facilitate denial of service attacks in 592 some environments; to prevent these attacks, it may make sense for 593 the minimal messages protocol server to only accept a KRB_TGT_PUSH 594 message on a local network interface (to ensure that the message was 595 not sent from a remote malicious host). 597 10. Acknowledgements 599 We thank the Kerberos Working Group chair, Doug Engert, for his 600 efforts in helping to progress this specification. We also thank Ken 601 Raeburn for his comments and the other working group participants for 602 their input. 604 11. References 606 [1] J. Kohl, C. Neuman, "The Kerberos Network Authentication 607 Service (V5)", RFC 1510. 609 [2] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964. 611 [3] J. Linn, "Generic Security Service Application Program 612 Interface Version 2, Update 1", RFC 2743. 614 [4] D. Davis, R. Swick, "Workstation Services and Kerberos 615 Authentication at Project Athena", Technical Memorandum TM-424, 616 MIT Laboratory for Computer Science, February 1990. 618 [5] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 619 9, RFC 2026, October 1996. 621 [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement 622 Levels", BCP 14, RFC 2119, March 1997. 624 [7] E. Baize, D. Pinkas, "The Simple and Protected GSS-API Negotiation 625 Mechanism," RFC 2478, December 1998. 627 [8] Part 11: Wireless LAN Medium Access Control (MAC) and Physical 628 Layer (PHY) Specifications, ANSI/IEEE Std. 802.11, 1999 Edition. 630 12. Author's Addresses 632 Jonathan Trostle 633 Cisco Systems 634 170 W. Tasman Dr. 635 San Jose, CA 95134, U.S.A. 636 Email: jtrostle@cisco.com 637 Phone: (408) 527-6201 639 Michael Swift 640 University of Washington 641 Seattle, WA 642 Email: mikesw@cs.washington.edu 644 Bernard Aboba 645 Microsoft 646 One Microsoft Way 647 Redmond, Washington, 98052, U.S.A. 648 Email: bernarda@microsoft.com 650 Glen Zorn 651 Cisco Systems 652 Bellevue, WA U.S.A. 653 Email: gwz@cisco.com 654 Phone: (425) 468-0955 656 This draft expires on March 31st, 2002.