1 2 3 4 5 6 7INTERNET-DRAFT Jonathan Trostle 8draft-ietf-cat-iakerb-09.txt Cisco Systems 9Updates: RFC 1510, 1964 Michael Swift 10October 2002 University of WA 11 Bernard Aboba 12 Microsoft 13 Glen Zorn 14 Cisco Systems 15 16 17Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API 18(IAKERB) 19 <draft-ietf-cat-iakerb-09.txt> 20 21 22 23 24Status of this Memo 25 26 This document is an Internet-Draft and is in full conformance with 27 all provisions of Section 10 of RFC2026 [5]. 28 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 33 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 38 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 41 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 44 45 This draft expires in March 2003. Please send comments to the 46 authors. 47 481. Abstract 49 50 This document defines extensions to the Kerberos protocol 51 specification (RFC 1510 [1]) and GSSAPI Kerberos protocol mechanism 52 (RFC 1964 [2]) that enables a client to obtain Kerberos tickets for 53 services where the KDC is not accessible to the client, but is 54 accessible to the application server. Some common scenarios where 55 lack of accessibility would occur are when the client does not have 56 an IP address prior to authenticating to an access point, the client 57 is unable to locate a KDC, or a KDC is behind a firewall. The 58 document specifies two protocols to allow a client to exchange KDC 59 messages (which are GSS encapsulated) with an IAKERB proxy instead of 60 a KDC. 61 62 63 64Trostle, Swift, Aboba, Zorn [Page 1] 65 66INTERNET DRAFT October 2002 Expires March 2003 67 68 692. Conventions used in this document 70 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC2119 [6]. 74 753. Motivation 76 77 When authenticating using Kerberos V5, clients obtain tickets from a 78 KDC and present them to services. This method of operation works well 79 in many situations, but is not always applicable. The following is a 80 list of some of the scenarios that this proposal addresses: 81 82 (1) The client must initially authenticate to an access point in 83 order to gain full access to the network. Here the client may be 84 unable to directly contact the KDC either because it does not have an 85 IP address, or the access point packet filter does not allow the 86 client to send packets to the Internet before it authenticates to the 87 access point [8]. 88 89 (2) A KDC is behind a firewall so the client will send Kerberos 90 messages to the IAKERB proxy which will transmit the KDC request and 91 reply messages between the client and the KDC. (The IAKERB proxy is a 92 special type of Kerberos application server that also relays KDC 93 request and reply messages between a client and the KDC). 94 954. Overview 96 97 This proposal specifies two protocols that address the above 98 scenarios: the IAKERB proxy option and the IAKERB minimal messages 99 option. In the IAKERB proxy option (see Figure 1) an application 100 server called the IAKERB proxy acts as a protocol gateway and proxies 101 Kerberos messages back and forth between the client and the KDC. The 102 IAKERB proxy is also responsible for locating the KDC and may 103 additionally perform other application proxy level functions such as 104 auditing. A compliant IAKERB proxy MUST implement the IAKERB proxy 105 protocol. 106 107 108 Client <---------> IAKERB proxy <----------> KDC 109 110 111 Figure 1: IAKERB proxying 112 113 The second protocol is the minimal messages protocol which is based 114 on user-user authentication [4]; this protocol is targetted at 115 environments where the number of messages, prior to key 116 establishment, needs to be minimized. In the normal minimal messages 117 protocol, the client sends its ticket granting ticket (TGT) to the 118 IAKERB proxy (in a KRB_TKT_PUSH message) for the TGS case. The IAKERB 119 proxy then sends a TGS_REQ to the KDC with the client's TGT in the 120 additional tickets field of the TGS_REQ message. The returned ticket 121 will list the client as the ticket's server principal, and will be 122 encrypted with the session key from the client's TGT. The IAKERB 123 124 125 126Trostle, Swift, Aboba, Zorn [Page 2] 127 128INTERNET DRAFT October 2002 Expires March 2003 129 130 131 proxy then uses this ticket to generate an AP request that is sent to 132 the client (see Figure 2). Thus mutual authentication is accomplished 133 with three messages between the client and the IAKERB proxy versus 134 four or more (the difference is larger if crossrealm operations are 135 involved). 136 137 Subsequent to mutual authentication and key establishment, the IAKERB 138 proxy sends a ticket to the client (in a KRB_TKT_PUSH message). This 139 ticket is created by the IAKERB proxy and contains the same fields as 140 the original service ticket that the proxy sent in the AP_REQ 141 message, except the client and server names are reversed and it is 142 encrypted in a long term key known to the IAKERB proxy. Its purpose 143 is to enable fast subsequent re-authentication by the client to the 144 application server (using the conventional AP request AP reply 145 exchange) for subsequent sessions. In addition to minimizing the 146 number of messages, a secondary goal is to minimize the number of 147 bytes transferred between the client and the IAKERB proxy prior to 148 mutual authentication and key establishment. Therefore, the final 149 service ticket (the reverse ticket) is sent after mutual 150 authentication and key establishment is complete, rather than as part 151 of the initial AP_REQ from the IAKERB proxy to the client. Thus 152 protected application data (e.g., GSS signed and wrapped messages) 153 can flow before this final message is sent. 154 155 The AS_REQ case for the minimal messages option is similar, where the 156 client sends up the AS_REQ message and the IAKERB proxy forwards it 157 to the KDC. The IAKERB proxy pulls the client TGT out of the AS_REP 158 message; the protocol now proceeds as in the TGS_REQ case described 159 above with the IAKERB proxy including the client's TGT in the 160 additional tickets field of the TGS_REQ message. 161 162 A compliant IAKERB proxy MUST implement the IAKERB proxy protocol, 163 and MAY implement the IAKERB minimal message protocol. In general, 164 the existing Kerberos paradigm where clients contact the KDC to 165 obtain service tickets should be preserved where possible. 166 167 For most IAKERB scenarios, such as when the client does not have an 168 IP address, or cannot directly contact a KDC, the IAKERB proxy 169 protocol should be adequate. If the client needs to obtain a 170 crossrealm TGT (and the conventional Kerberos protocol cannot be 171 used), then the IAKERB proxy protocol must be used. In a scenario 172 where the client does not have a service ticket for the target 173 server, it is crucial that the number of messages between the client 174 and the target server be minimized (especially if the client and 175 target server are in different realms), and/or it is crucial that the 176 number of bytes transferred between the client and the target server 177 be minimized, then the client should consider using the minimal 178 messages protocol. The reader should see the security considerations 179 section regarding the minimal messages protocol. 180 181 182 183 184 185 186 187 188Trostle, Swift, Aboba, Zorn [Page 3] 189 190INTERNET DRAFT October 2002 Expires March 2003 191 192 193 Client --------> IAKERB proxy 194 TKT_PUSH (w/ TGT) 195 196 Client IAKERB proxy --------------------> KDC 197 TGS_REQ with client 198 TGT as additional TGT 199 200 Client IAKERB proxy <-------------------- KDC 201 TGS_REP with service 202 ticket 203 204 Client <-------- IAKERB proxy KDC 205 AP_REQ 206 207 Client --------> IAKERB proxy KDC 208 AP_REP 209 210 ------------------------------------------------------------- 211 post-key establishment and application data flow phase: 212 213 Client <-------- IAKERB proxy KDC 214 TKT_PUSH (w/ticket targetted at IAKERB proxy 215 to enable fast subsequent authentication) 216 217 218 Figure 2: IAKERB Minimal Messages Option: TGS case 219 220 221 2225. GSSAPI Encapsulation 223 224 The mechanism ID for IAKERB proxy GSS-API Kerberos, in accordance 225 with the mechanism proposed by SPNEGO [7] for negotiating protocol 226 variations, is: {iso(1) org(3) dod(6) internet(1) security(5) 227 mechanisms(5) iakerb(10) iakerbProxyProtocol(1)}. The proposed 228 mechanism ID for IAKERB minimum messages GSS-API Kerberos, in 229 accordance with the mechanism proposed by SPNEGO for negotiating 230 protocol variations, is: {iso(1) org(3) dod(6) internet(1) 231 security(5) mechanisms(5) iakerb(10) 232 iakerbMinimumMessagesProtocol(2)}. 233 234 NOTE: An IAKERB implementation does not require SPNEGO in order to 235 achieve interoperability with other IAKERB peers. Two IAKERB 236 implementations may interoperate in the same way that any two peers 237 can interoperate using a pre-established GSSAPI mechanism. The above 238 OID's allow two SPNEGO peers to securely negotiate IAKERB from among 239 a set of GSS mechanisms. 240 241 The AS request, AS reply, TGS request, and TGS reply messages are all 242 encapsulated using the format defined by RFC1964 [2]. This consists 243 of the GSS-API token framing defined in appendix B of [3]: 244 245 246 247 248 249 250Trostle, Swift, Aboba, Zorn [Page 4] 251 252INTERNET DRAFT October 2002 Expires March 2003 253 254 255 InitialContextToken ::= [APPLICATION 0] IMPLICIT SEQUENCE { 256 thisMech MechType 257 -- MechType is OBJECT IDENTIFIER 258 -- representing iakerb proxy or iakerb min messages 259 innerContextToken ANY DEFINED BY thisMech 260 -- contents mechanism-specific; 261 -- ASN.1 usage within innerContextToken 262 -- is not required 263 } 264 265 The innerContextToken consists of a 2-byte TOK_ID field (defined 266 below), followed by the Kerberos V5 KRB_AS_REQ, KRB_AS_REP, 267 KRB_TGS_REQ, or KRB_TGS_REP messages, as appropriate. The TOK_ID 268 field shall be one of the following values, to denote that the 269 message is either a request to the KDC or a response from the KDC. 270 271 272 273 Message TOK_ID 274 275 KRB_KDC_REQ 00 03 276 277 KRB_KDC_REP 01 03 278 279 We also define the token ID for the KRB_TKT_PUSH token (defined below 280 and used in the minimal messages variation): 281 282 Message TOK_ID 283 284 KRB_TKT_PUSH 02 03 285 286 For completeness, we list the other RFC 1964 defined token ID's here: 287 288 Message TOK_ID 289 290 AP_REQ 01 00 291 292 AP_REP 02 00 293 294 KRB_ERROR 03 00 295 2966. The IAKERB proxy protocol 297 298 The IAKERB proxy will proxy Kerberos KDC request, KDC reply, and 299 KRB_ERROR messages back and forth between the client and the KDC as 300 illustrated in Figure 1. Messages received from the client must first 301 have the Kerberos GSS header (RFC1964 [2]) stripped off. The 302 unencapsulated message will then be forwarded to a KDC. The IAKERB 303 proxy is responsible for locating an appropriate KDC using the realm 304 information in the KDC request message it received from the client. 305 In addition, the IAKERB proxy SHOULD implement a retry algorithm for 306 KDC requests over UDP (including selection of alternate KDC's if the 307 initial KDC does not respond to its requests). For messages sent by 308 the KDC, the IAKERB proxy encapsulates them with a Kerberos GSS 309 310 311 312Trostle, Swift, Aboba, Zorn [Page 5] 313 314INTERNET DRAFT October 2002 Expires March 2003 315 316 317 header before sending them to the client. 318 319 We define two new Kerberos error codes that allow the proxy to 320 indicate the following error conditions to the client: 321 322 (a) when the proxy is unable to obtain an IP address for a KDC in the 323 client's realm, it sends the KRB_IAKERB_ERR_KDC_NOT_FOUND KRB_ERROR 324 (80) message to the client. 325 326 (b) when the proxy has an IP address for a KDC in the client realm, 327 but does not receive a response from any KDC in the realm (including 328 in response to retries), it sends the KRB_IAKERB_ERR_KDC_NO_RESPONSE 329 KRB_ERROR (81) message to the client. 330 331 To summarize, the sequence of steps for processing is as follows: 332 333 Servers: 334 335 1. For received KDC_REQ messages (with token ID 00 03) 336 - process GSS framing (check OID) 337 if the OID is not one of the two OID's specified in the GSSAPI 338 Encapsulation section above, then process according to mechanism 339 defined by that OID (if the OID is recognized). The processing 340 is outside the scope of this specification. Otherwise, strip 341 off GSS framing. 342 - find KDC for specified realm (if KDC IP address cannot be 343 obtained, send a KRB_ERROR message with error code 344 KRB_IAKERB_ERR_KDC_NOT_FOUND to the client). 345 - send to KDC (storing client IP address, port, and indication 346 whether IAKERB proxy option or minimal messages option is 347 being used) 348 - retry with same or another KDC if no response is received. If 349 the retries also fail, send an error message with error code 350 KRB_IAKERB_ERR_KDC_NO_RESPONSE to the client. 351 352 2. For received KDC_REP messages 353 - encapsulate with GSS framing, using token ID 01 03 and the OID 354 that corresponds to the stored protocol option 355 - send to client (using the stored client IP address and port) 356 357 3. For KRB_ERROR messages received from the KDC 358 - encapsulate with GSS framing, using token ID 03 00 and the OID 359 that corresponds to the stored protocol option 360 - send to client (using the stored client IP address and port) 361 (one possible exception is the KRB_ERR_RESPONSE_TOO_BIG error 362 which can lead to a retry of the KDC_REQ message over the TCP 363 transport by the server, instead of simply proxying the error 364 to the client). 365 366 4. For sending/receiving AP_REQ and AP_REP messages 367 - process per RFC 1510 and RFC 1964; the created AP_REP message 368 SHOULD include the subkey (with same etype as the session key) 369 to facilitate use with other key derivation algorithms outside 370 of [2]. The subkey SHOULD be created using locally generated 371 372 373 374Trostle, Swift, Aboba, Zorn [Page 6] 375 376INTERNET DRAFT October 2002 Expires March 2003 377 378 379 entropy as one of the inputs (in addition to other inputs 380 such as the session key). 381 382 Clients: 383 384 1. For sending KDC_REQ messages 385 - create AS_REQ or TGS_REQ message 386 - encapsulate with GSS framing (token ID 00 03 and OID 387 corresponding to the protocol option). 388 - send to server 389 390 2. For received KDC_REP messages 391 - decapsulate by removing GSS framing (token ID 01 03) 392 - process inner Kerberos message according to RFC 1510 393 394 3. For received KRB_ERROR messages 395 - decapsulate by removing GSS framing (token ID 03 00) 396 - process inner Kerberos message according to RFC 1510 397 and possibly retry the request (time skew errors lead 398 to retries in most existing Kerberos implementations) 399 400 4. For sending/receiving AP_REQ and AP_REP messages 401 - process per RFC 1510 and RFC 1964; the created AP_REQ 402 message SHOULD include the subsession key in the 403 authenticator field. 404 4057. The IAKERB minimal messages protocol 406 407 The client MAY initiate the IAKERB minimal messages variation when 408 the number of messages must be minimized (the most significant 409 reduction in the number of messages can occur when the client and the 410 IAKERB proxy are in different realms). SPNEGO [7] MAY be used to 411 securely negotiate between the protocols (and amongst other GSS 412 mechanism protocols). A compliant IAKERB server MAY support the 413 IAKERB minimal messages protocol. 414 415 (a) AS_REQ case: (used when the client does not have a TGT) 416 417 We apply the Kerberos user-user authentication protocol [4] in this 418 scenario (other work in this area includes the IETF work in progress 419 effort to apply Kerberos user user authentication to DHCP 420 authentication). 421 422 The client indicates that the minimal message sub-protocol will be 423 used by using the appropriate OID as described above. The client 424 sends the GSS encapsulated AS_REQ message to the IAKERB proxy, and 425 the IAKERB proxy processes the GSS framing (as described above for 426 the IAKERB proxy option) and forwards the AS_REQ message to the KDC. 427 428 The IAKERB proxy will either send a KRB_ERROR message back to the 429 client, or it will send an initial context token consisting of the 430 GSS header (minimal messages OID with a two byte token header 01 03), 431 followed by an AS_REP message. The AS_REP message will contain the 432 AP_REQ message in a padata field; the ticket in the AP_REQ is a 433 434 435 436Trostle, Swift, Aboba, Zorn [Page 7] 437 438INTERNET DRAFT October 2002 Expires March 2003 439 440 441 user-user ticket encrypted in the session key from the client's 442 original TGT. We define the padata type PA-AP-REQ with type number 443 25. The corresponding padata value is the AP_REQ message without any 444 GSS framing. For the IAKERB minimal messages AS option, the AP_REQ 445 message authenticator MUST include the RFC 1964 [2] checksum. The 446 mutual-required and use-session-key flags are set in the ap-options 447 field of the AP_REQ message. 448 449 The protocol is complete in the KRB_ERROR case (from the server 450 perspective, but the client should retry depending on the error 451 type). If the IAKERB proxy receives an AS_REP message from the KDC, 452 the IAKERB proxy will then obtain the client's TGT from the AS_REP 453 message. The IAKERB proxy then sends a TGS_REQ message with the 454 client's TGT in the additional tickets field to the client's KDC 455 (ENC-TKT-IN-SKEY option). 456 457 The IAKERB proxy MAY handle returned KRB_ERROR messages and retry the 458 TGS request message (e.g. on a KRB_ERR_RESPONSE_TOO_BIG error, 459 switching to TCP from UDP). Ultimately, the IAKERB proxy either 460 proxies a KRB_ERROR message to the client (after adding the GSS 461 framing), sends one of the new GSS framed KRB_ERROR messages defined 462 above, or it receives the TGS_REP message from the KDC and then 463 creates the AP_REQ message according to RFC 1964 [2]. The IAKERB 464 proxy then sends a GSS token containing the AS_REP message with the 465 AP_REQ message in the padata field as described above. (Note: 466 although the server sends the context token with the AP_REQ, the 467 client is the initiator.) The IAKERB proxy MUST set both the mutual- 468 required and use-session-key flags in the AP_REQ message in order to 469 cause the client to authenticate as well. The authenticator SHOULD 470 include the subsession key (containing locally added entropy). The 471 client will reply with the GSSAPI enscapsulated AP_REP message, if 472 the IAKERB proxy's authentication succeeds (which SHOULD include the 473 subkey field to facilitate use with other key derivation algorithms 474 outside of [2]). If all goes well, then, in order to enable 475 subsequent efficient client authentications, the IAKERB proxy will 476 then send a final message of type KRB_TKT_PUSH containing a Kerberos 477 ticket (the reverse ticket) that has the IAKERB client principal 478 identifier in the client identifier field of the ticket and its own 479 principal identity in the server identifier field of the ticket (see 480 Figure 3): 481 482 KRB_TKT_PUSH :: = [APPLICATION 17] SEQUENCE { 483 pvno[0] INTEGER, -- 5 (protocol version) 484 msg-type[1] INTEGER, -- 17 (message type) 485 ticket[2] Ticket 486 } 487 488 NOTE: The KRB_TKT_PUSH message must be encoded using ASN.1 DER. The 489 key used to encrypt the reverse ticket is a long term secret key 490 chosen by the IAKERB proxy. The fields are identical to the AP_REQ 491 ticket, except the client name will be switched with the server name, 492 and the server realm will be switched with the client realm. (The one 493 other exception is that addresses should not be copied from the 494 AP_REQ ticket to the reverse ticket). Sending the reverse ticket 495 496 497 498Trostle, Swift, Aboba, Zorn [Page 8] 499 500INTERNET DRAFT October 2002 Expires March 2003 501 502 503 allows the client to efficiently initiate subsequent reauthentication 504 attempts with a RFC1964 AP_REQ message. Note that the TKT_PUSH 505 message is sent after mutual authentication and key establishment are 506 complete. 507 508 509 Client --------> IAKERB proxy --------------------> KDC 510 AS_REQ AS_REQ 511 512 Client IAKERB proxy <-------------------- KDC 513 AS_REP w/ client TGT 514 515 Client IAKERB proxy --------------------> KDC 516 TGS_REQ with client 517 TGT as additional TGT 518 519 Client IAKERB proxy <-------------------- KDC 520 TGS_REP with service 521 ticket 522 523 Client <-------- IAKERB proxy KDC 524 AS_REP w/ AP_REQ in padata field 525 526 Client --------> IAKERB proxy KDC 527 AP_REP 528 529 ------------------------------------------------------------- 530 post-key establishment and application data flow phase: 531 532 Client <-------- IAKERB proxy KDC 533 TKT_PUSH (w/ticket targetted at IAKERB proxy 534 to enable fast subsequent authentication) 535 536 537 Figure 3: IAKERB Minimal Messages Option: AS case 538 539 540 541 (b) TGS_REQ case: (used when the client has a TGT) 542 543 The client indicates that the minimal messages sub-protocol will be 544 used by using the appropriate OID as described above. The client 545 initially sends a KRB_TKT_PUSH message (with the GSS header) to the 546 IAKERB proxy in order to send it a TGT. The IAKERB proxy will obtain 547 the client's TGT from the KRB_TKT_PUSH message and then proceed to 548 send a TGS_REQ message to a KDC where the realm of the KDC is equal 549 to the realm from the server realm field in the TGT sent by the 550 client in the KRB_TKT_PUSH message. NOTE: this realm could be the 551 client's home realm, the proxy's realm, or an intermediate realm. The 552 protocol then continues as in the minimal messages AS_REQ case 553 described above (see Figure 2); the IAKERB proxy's TGS_REQ message 554 contains the client's TGT in the additional tickets field (ENC-TKT- 555 IN-SKEY option). The IAKERB proxy then receives the TGS_REP message 556 from the KDC and then sends a RFC 1964 AP_REQ message to the client 557 558 559 560Trostle, Swift, Aboba, Zorn [Page 9] 561 562INTERNET DRAFT October 2002 Expires March 2003 563 564 565 (with the MUTUAL AUTH flag set - see AS_REQ case). 566 567 To summarize, here are the steps for the minimal messages TGS 568 protocol: 569 570 Client: 571 (has TGT already for, or targetted at, realm X.ORG) 572 sends TKT_PUSH message to server containing client's ticket 573 for X.ORG (which could be a crossrealm TGT) 574 575 Server: 576 (has TGT already targetted at realm X.ORG) 577 sends to KDC (where KDC has principal id = server name, 578 server realm from client ticket) a TGS_REQ: 579 TGT in TGS_REQ is server's TGT 580 Additional ticket in TGS_REQ is client's TGT from TKT_PUSH 581 message 582 Server name in TGS_REQ (optional by rfc1510) is not present 583 Server realm in TGS_REQ is realm in server's TGT - X.ORG 584 585 KDC: 586 Builds a ticket: 587 Server name = client's name 588 Client name = server's name, Client realm = server's realm 589 Server realm = client's realm 590 Encrypted with: session key from client's TGT (passed in 591 additional tickets field) 592 Build a TGS_REP 593 Encrypted with session key from server's TGT 594 Sends TGS_REP and ticket to server 595 596 Server: 597 Decrypts TGS_REP from KDC using session key from its TGT 598 Constructs AP_REQ 599 Ticket = ticket from KDC (which was encrypted with 600 client's TGT session key) 601 authenticator clientname = server's name (matches 602 clientname in AP-REQ ticket) 603 authenticator clientrealm = server's realm 604 subsession key in authenticator is present (same 605 etype as the etype of the session key in the ticket) 606 checksum in authenticator is the RFC 1964 checksum 607 sequence number in authenticator is present (RFC 1964) 608 ap-options has both use-session-key and mutual-required 609 flags set 610 Sends AP_REQ (with GSS-API framing) to client 611 612 Client: 613 Receives AP_REQ 614 Decrypts ticket using session key from its TGT 615 Verifies AP_REQ 616 Builds AP_REP and sends to server (AP_REP SHOULD include 617 subkey field to facilitate use with other key derivation 618 algorithms outside of [2] e.g., [8] and its successors. 619 620 621 622Trostle, Swift, Aboba, Zorn [Page 10] 623 624INTERNET DRAFT October 2002 Expires March 2003 625 626 627 Some apps may have their own message protection key 628 derivation algorithm and protected message format. 629 AP_REP includes the sequence number per RFC 1964.) 630 631 Server: 632 Verifies AP-REP. Builds reverse ticket as described above 633 and sends reverse ticket to client using the KRB_TKT_PUSH 634 message. The reverse ticket is the same as the AP_REQ 635 ticket except the client name, realm are switched with the 636 server name, realm fields and it is encrypted in a secret 637 key known to the IAKERB proxy. 638 6398. Addresses in Tickets 640 641 In IAKERB, the machine sending requests to the KDC is the server and 642 not the client. As a result, the client should not include its 643 addresses in any KDC requests for two reasons. First, the KDC may 644 reject the forwarded request as being from the wrong client. Second, 645 in the case of initial authentication for a dial-up client, the 646 client machine may not yet possess a network address. Hence, as 647 allowed by RFC1510 [1], the addresses field of the AS and TGS 648 requests SHOULD be blank and the caddr field of the ticket SHOULD 649 similarly be left blank. 650 6519. Security Considerations 652 653 Similar to other network access protocols, IAKERB allows an 654 unauthenticated client (possibly outside the security perimeter of an 655 organization) to send messages that are proxied to interior servers. 656 When combined with DNS SRV RR's for KDC lookup, there is the 657 possibility that an attacker can send an arbitrary message to an 658 interior server. There are several aspects to note here: 659 660 (1) in many scenarios, compromise of the DNS lookup will require the 661 attacker to already have access to the internal network. Thus the 662 attacker would already be able to send arbitrary messages to interior 663 servers. No new vulnerabilities are added in these scenarios. 664 665 (2) in a scenario where DNS SRV RR's are being used to locate the 666 KDC, IAKERB is being used, and an external attacker can modify DNS 667 responses to the IAKERB proxy, there are several countermeasures to 668 prevent arbitrary messages from being sent to internal servers: 669 670 (a) KDC port numbers can be statically configured on the IAKERB 671 proxy. In this case, the messages will always be sent to KDC's. For 672 an organization that runs KDC's on a static port (usually port 88) 673 and does not run any other servers on the same port, this 674 countermeasure would be easy to administer and should be effective. 675 676 (b) the proxy can do application level sanity checking and filtering. 677 This countermeasure should eliminate many of the above attacks. 678 679 (c) DNS security can be deployed. This countermeasure is probably 680 overkill for this particular problem, but if an organization has 681 682 683 684Trostle, Swift, Aboba, Zorn [Page 11] 685 686INTERNET DRAFT October 2002 Expires March 2003 687 688 689 already deployed DNS security for other reasons, then it might make 690 sense to leverage it here. Note that Kerberos could be used to 691 protect the DNS exchanges. The initial DNS SRV KDC lookup by the 692 proxy will be unprotected, but an attack here is at most a denial of 693 service (the initial lookup will be for the proxy's KDC to facilitate 694 Kerberos protection of subsequent DNS exchanges between itself and 695 the DNS server). 696 697 In the minimal messages protocol option, the application server sends 698 an AP_REQ message to the client. The ticket in the AP_REQ message 699 SHOULD NOT contain authorization data since some operating systems 700 may allow the client to impersonate the server and increase its own 701 privileges. If the ticket from the server connotes any authorization, 702 then the minimal messages protocol should not be used. Also, the 703 minimal messages protocol may facilitate denial of service attacks in 704 some environments; to prevent these attacks, it may make sense for 705 the minimal messages protocol server to only accept a KRB_TGT_PUSH 706 message on a local network interface (to ensure that the message was 707 not sent from a remote malicious host). 708 70910. Acknowledgements 710 711 We thank the Kerberos Working Group chair, Doug Engert, for his 712 efforts in helping to progress this specification. We also thank Ken 713 Raeburn for his comments and the other working group participants for 714 their input. 715 71611. References 717 718 [1] J. Kohl, C. Neuman, "The Kerberos Network Authentication 719 Service (V5)", RFC 1510. 720 721 [2] J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964. 722 723 [3] J. Linn, "Generic Security Service Application Program 724 Interface Version 2, Update 1", RFC 2743. 725 726 [4] D. Davis, R. Swick, "Workstation Services and Kerberos 727 Authentication at Project Athena", Technical Memorandum TM-424, 728 MIT Laboratory for Computer Science, February 1990. 729 730 [5] S. Bradner, "The Internet Standards Process -- Revision 3", BCP 731 9, RFC 2026, October 1996. 732 733 [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement 734 Levels", BCP 14, RFC 2119, March 1997. 735 736 [7] E. Baize, D. Pinkas, "The Simple and Protected GSS-API Negotiation 737 Mechanism," RFC 2478, December 1998. 738 739 [8] Part 11: Wireless LAN Medium Access Control (MAC) and Physical 740 Layer (PHY) Specifications, ANSI/IEEE Std. 802.11, 1999 Edition. 741 742 743 744 745 746Trostle, Swift, Aboba, Zorn [Page 12] 747 748INTERNET DRAFT October 2002 Expires March 2003 749 750 75112. Author's Addresses 752 753 Jonathan Trostle 754 Cisco Systems 755 170 W. Tasman Dr. 756 San Jose, CA 95134, U.S.A. 757 Email: jtrostle@cisco.com 758 Phone: (408) 527-6201 759 760 Michael Swift 761 University of Washington 762 Seattle, WA 763 Email: mikesw@cs.washington.edu 764 765 Bernard Aboba 766 Microsoft 767 One Microsoft Way 768 Redmond, Washington, 98052, U.S.A. 769 Email: bernarda@microsoft.com 770 Phone: (425) 706-6605 771 772 Glen Zorn 773 Cisco Systems 774 Bellevue, WA U.S.A. 775 Email: gwz@cisco.com 776 Phone: (425) 468-0955 777 778 This draft expires on March 31st, 2003. 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808Trostle, Swift, Aboba, Zorn [Page 13] 809 810