1 2 3NETWORK WORKING GROUP L. Zhu 4Internet-Draft Microsoft Corporation 5Updates: 4120 (if approved) J. Altman 6Intended status: Standards Track Secure Endpoints 7Expires: January 10, 2008 July 9, 2007 8 9 10 Initial and Pass Through Authentication Using Kerberos V5 and the GSS- 11 API (IAKERB) 12 draft-zhu-ws-kerb-03 13 14Status of this Memo 15 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 25 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 30 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 33 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 36 37 This Internet-Draft will expire on January 10, 2008. 38 39Copyright Notice 40 41 Copyright (C) The IETF Trust (2007). 42 43Abstract 44 45 This document defines extensions to the Kerberos protocol and the 46 GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to 47 exchange messages with the KDC using the GSS-API acceptor as the 48 proxy, by encapsulating the Kerberos messages inside GSS-API tokens. 49 With these extensions a client can obtain Kerberos tickets for 50 services where the KDC is not accessible to the client, but is 51 52 53 54Zhu & Altman Expires January 10, 2008 [Page 1] 55 56Internet-Draft IAKERB July 2007 57 58 59 accessible to the application server. 60 61 62Table of Contents 63 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 66 3. GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . 3 67 4. Addresses in Tickets . . . . . . . . . . . . . . . . . . . . . 7 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 73 8.2. Informative references . . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 Intellectual Property and Copyright Statements . . . . . . . . . . 11 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110Zhu & Altman Expires January 10, 2008 [Page 2] 111 112Internet-Draft IAKERB July 2007 113 114 1151. Introduction 116 117 When authenticating using Kerberos V5, clients obtain tickets from a 118 KDC and present them to services. This model of operation cannot 119 work if the client does not have access to the KDC. For example, in 120 remote access scenarios, the client must initially authenticate to an 121 access point in order to gain full access to the network. Here the 122 client may be unable to directly contact the KDC either because it 123 does not have an IP address, or the access point packet filter does 124 not allow the client to send packets to the Internet before it 125 authenticates to the access point. 126 127 Recent advancements in extending Kerberos permit Kerberos 128 authentication to complete with the assistance of a proxy. The 129 Kerberos [RFC4120] pre-authentication framework [KRB-PAFW] prevents 130 the exposure of weak client keys over the open network. The Kerberos 131 support of anonymity [KRB-ANON] provides for privacy and further 132 complicates traffic analysis. The kdc-referrals option defined in 133 [KRB-PAFW] may reduce the number of messages exchanged while 134 obtaining a ticket to exactly two even in cross-realm 135 authentications. 136 137 Building upon these Kerberos extensions, this document extends 138 [RFC4120] and [RFC4121] such that the client can communicate with the 139 KDC using a Generic Security Service Application Program Interface 140 (GSS-API) [RFC2743] acceptor as the proxy. The GSS-API acceptor 141 relays the KDC request and reply messages between the client and the 142 KDC. The GSS-API acceptor, when relaying the Kerberos messages, is 143 called an IAKERB proxy. Consequently, IAKERB as defined in this 144 document requires the use of GSS-API. 145 146 1472. Conventions Used in This Document 148 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 152 153 1543. GSS-API Encapsulation 155 156 The mechanism Objection Identifier (OID) for GSS-API IAKERB, in 157 accordance with the mechanism proposed by [RFC4178] for negotiating 158 protocol variations, is id-kerberos-iakerb: 159 160 id-kerberos-iakerb ::= 161 { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) 162 iakerb(5) } 163 164 165 166Zhu & Altman Expires January 10, 2008 [Page 3] 167 168Internet-Draft IAKERB July 2007 169 170 171 The initial context establishment token of IAKERB MUST have the 172 generic token framing described in section 3.1 of [RFC2743] with the 173 mechanism OID being id-kerberos-iakerb, and any subsequent IAKERB 174 context establishment token MUST NOT have this token framing. 175 176 The client starts by constructing the ticket request, and if the 177 ticket request is being made to the KDC, the client, instead of 178 contacting the KDC directly, encapsulates the request message into 179 the output token of the GSS_Init_security_context() call and returns 180 GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more 181 token is required in order to establish the context. The output 182 token is then passed for use as the input token to the 183 GSS_Accept_sec_context() call in accordance with GSS-API. The GSS- 184 API acceptor extracts the Kerberos request in the input token, 185 locates the target KDC, and sends the request on behalf of the 186 client. After receiving the KDC reply, the GSS-API acceptor then 187 encapsulates the reply message into the output token of 188 GSS_Accept_sec_context(). The GSS-API acceptor returns 189 GSS_S_CONTINUE_NEEDED [RFC2743] indicating that at least one more 190 token is required in order to establish the context. The output 191 token is passed to the initiator in accordance with GSS-API. 192 193 Client <---------> IAKERB proxy <---------> KDC 194 195 The innerToken described in section 3.1 of [RFC2743] and subsequent 196 GSS-API mechanism tokens have the following formats: it starts with a 197 two-octet token-identifier (TOK_ID), followed by an IAKERB message or 198 a Kerberos message. 199 200 Only one IAKERB specific message, namely the IAKERB_PROXY message, is 201 defined in this document. The TOK_ID values for Kerberos messages 202 are the same as defined in [RFC4121]. 203 204 Token TOK_ID Value in Hex 205 -------------------------------------- 206 IAKERB_PROXY 05 01 207 208 The content of the IAKERB_PROXY message is defined as an IAKERB- 209 HEADER structure immediately followed by a Kerberos message. The 210 Kerberos message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, 211 or a KRB-ERROR as defined in [RFC4120]. 212 213 214 215 216 217 218 219 220 221 222Zhu & Altman Expires January 10, 2008 [Page 4] 223 224Internet-Draft IAKERB July 2007 225 226 227 IAKERB-HEADER ::= SEQUENCE { 228 target-realm [1] UTF8String, 229 -- The name of the target realm. 230 cookie [2] OCTET STRING OPTIONAL, 231 -- Opaque data, if sent by the server, 232 -- MUST be copied by the client verbatim into 233 -- the next IAKRB_PROXY message. 234 ... 235 } 236 237 The IAKERB-HEADER structure and all the Kerberos messages MUST be 238 encoded using Abstract Syntax Notation One (ASN.1) Distinguished 239 Encoding Rules (DER) [X680] [X690]. 240 241 The IAKERB client fills out the IAKERB-HEADER structure as follows: 242 the target-realm contains the realm name the ticket request is 243 addressed to. In the initial message from the client, the cookie 244 field is absent. The client MUST specify a target-realm. If the 245 client does not know the realm of the client's true principal name 246 [REFERALS], it MUST specify a realm it knows. This can be the realm 247 of the client's host. 248 249 Upon receipt of the IAKERB_PROXY message, the GSS-API acceptor 250 inspects the target-realm field in the IAKERB_HEADER, and locates a 251 KDC of that realm, and sends the ticket request to that KDC. 252 253 When the GSS-API acceptor is unable to obtain an IP address for a KDC 254 in the client's realm, it sends a KRB_ERROR message with the code 255 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND to the client and the context fails 256 to establish. There is no accompanying error data defined in this 257 document for this error code. 258 259 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND 85 260 -- The IAKERB proxy could not find a KDC. 261 262 When the GSS-API acceptor has an IP address for a KDC in the client 263 realm, but does not receive a response from any KDC in the realm 264 (including in response to retries), it sends a KRB_ERROR message with 265 the code KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE to the client and the 266 context fails to establish. There is no accompanying error data 267 defined in this document for this error code. 268 269 KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE 86 270 -- The KDC did not respond to the IAKERB proxy. 271 272 The IAKERB proxy can send opaque data in the cookie field of the 273 IAKERB-HEADER structure in the server reply to the client, in order 274 to, for example, minimize the amount of state information kept by the 275 276 277 278Zhu & Altman Expires January 10, 2008 [Page 5] 279 280Internet-Draft IAKERB July 2007 281 282 283 GSS-API acceptor. The content and the encoding of the cookie field 284 is a local matter of the IAKERB proxy. The client MUST copy the 285 cookie verbatim from the previous server response whenever the cookie 286 is present into the subsequent tokens that contains an IAKERB_PROXY 287 message. 288 289 When the client obtained a service ticket, the client sends a 290 KRB_AP_REQ message to the server, and performs the client-server 291 application exchange as defined in [RFC4120] and [RFC4121]. 292 293 For implementations comforming to this specification, the 294 authenticator subkey in the AP-REQ MUST alway be present, and the 295 Exts field in the GSS-API authenticator [GSS-EXTS] MUST contain an 296 extension of the type GSS_EXTS_IAKERB_FINISHED and the extension data 297 contains the ASN.1 DER encoding of the structure IAKERB-FINISHED. 298 299 GSS_EXTS_IAKERB_FINISHED TBD 300 --- Data type for the IAKERB checksum. 301 302 IAKERB-FINISHED ::= { 303 iakerb-messages [1] Checksum, 304 -- Contains the checksum of the GSS-API tokens 305 -- exchanged between the initiator and the acceptor, 306 -- and prior to the containing AP_REQ GSS-API token. 307 -- The checksum is performed over the GSS-API tokens 308 -- in the order that the tokens were sent. 309 ... 310 } 311 312 The iakerb-messages field in the IAKERB-FINISHED structure contains a 313 checksum of all the GSS-API tokens exchanged between the initiator 314 and the acceptor, and prior to the GSS-API token containing the 315 AP_REQ. This checksum is performed over these GSS-API tokens in the 316 order that the tokens were sent. In the parlance of [RFC3961], the 317 checksum type is the required checksum type for the enctype of the 318 subkey in the authenticator, the protocol key for the checksum 319 operation is the authenticator subkey, and the key usage number is 320 KEY_USAGE_IAKERB_FINISHED. 321 322 KEY_USAGE_IAKERB_FINISHED 42 323 324 The GSS-API acceptor MUST then verify the checksum contained in the 325 GSS_EXTS_IAKERB_FINISHED extension. This checksum provides integrity 326 protection for the messages exchanged including the unauthenticated 327 clear texts in the IAKERB-HEADER structure. 328 329 If the pre-authentication data is encrypted in the long-term 330 password-based key of the principal, the risk of security exposures 331 332 333 334Zhu & Altman Expires January 10, 2008 [Page 6] 335 336Internet-Draft IAKERB July 2007 337 338 339 is significant. Implementations SHOULD provide the AS_REQ armoring 340 as defined in [KRB-PAFW] unless an alternative protection is 341 deployed. In addition, the anonymous Kerberos FAST option is 342 RECOMMENDED for the client to complicate traffic analysis. 343 344 3454. Addresses in Tickets 346 347 In IAKERB, the machine sending requests to the KDC is the GSS-API 348 acceptor and not the client. As a result, the client should not 349 include its addresses in any KDC requests for two reasons. First, 350 the KDC may reject the forwarded request as being from the wrong 351 client. Second, in the case of initial authentication for a dial-up 352 client, the client machine may not yet possess a network address. 353 Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and 354 TGS-REQ requests SHOULD be blank and the caddr field of the ticket 355 SHOULD similarly be left blank. 356 357 3585. Security Considerations 359 360 A typical IAKERB client sends the AS_REQ with pre-authentication data 361 encrypted in the long-term keys of the user before the server is 362 authenticated. This enables offline attacks by un-trusted servers. 363 To mitigate this threat, the client SHOULD use Kerberos 364 FAST[KRB-PAFW] and require KDC authentication to protect the user's 365 credentials. 366 367 The client name is in clear text in the authentication exchange 368 messages and ticket granting service exchanges according to [RFC4120] 369 whereas the client name is encrypted in client- server application 370 exchange messages. By using the IAKERB proxy to relay the ticket 371 requests and responses, the client's identity could be revealed in 372 the client-server traffic where the same identity could have been 373 concealed if IAKERB were not used. Hence, to complicate traffic 374 analysis and provide privacy for the IAKERB client, the IAKERB client 375 SHOULD request the anonymous Kerberos FAST option [KRB-PAFW]. 376 377 Similar to other network access protocols, IAKERB allows an 378 unauthenticated client (possibly outside the security perimeter of an 379 organization) to send messages that are proxied to interior servers. 380 381 In a scenario where DNS SRV RR's are being used to locate the KDC, 382 IAKERB is being used, and an external attacker can modify DNS 383 responses to the IAKERB proxy, there are several countermeasures to 384 prevent arbitrary messages from being sent to internal servers: 385 386 387 388 389 390Zhu & Altman Expires January 10, 2008 [Page 7] 391 392Internet-Draft IAKERB July 2007 393 394 395 1. KDC port numbers can be statically configured on the IAKERB 396 proxy. In this case, the messages will always be sent to KDC's. 397 For an organization that runs KDC's on a static port (usually 398 port 88) and does not run any other servers on the same port, 399 this countermeasure would be easy to administer and should be 400 effective. 401 402 2. The proxy can do application level sanity checking and filtering. 403 This countermeasure should eliminate many of the above attacks. 404 405 3. DNS security can be deployed. This countermeasure is probably 406 overkill for this particular problem, but if an organization has 407 already deployed DNS security for other reasons, then it might 408 make sense to leverage it here. Note that Kerberos could be used 409 to protect the DNS exchanges. The initial DNS SRV KDC lookup by 410 the proxy will be unprotected, but an attack here is at most a 411 denial of service (the initial lookup will be for the proxy's KDC 412 to facilitate Kerberos protection of subsequent DNS exchanges 413 between itself and the DNS server). 414 415 4166. Acknowledgements 417 418 Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote 419 earlier revision of this document. 420 421 The hallway conversations between Larry Zhu and Nicolas Williams 422 formed the basis of this document. 423 424 4257. IANA Considerations 426 427 There is no IANA action required for this document. 428 429 4308. References 431 4328.1. Normative References 433 434 [GSS-EXTS] 435 Emery, S., "Kerberos Version 5 GSS-API Channel Binding 436 Hash Agility", 437 draft-ietf-krb-wg-gss-cb-hash-agility-03.txt (work in 438 progress), 2007. 439 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, March 1997. 442 443 444 445 446Zhu & Altman Expires January 10, 2008 [Page 8] 447 448Internet-Draft IAKERB July 2007 449 450 451 [RFC2743] Linn, J., "Generic Security Service Application Program 452 Interface Version 2, Update 1", RFC 2743, January 2000. 453 454 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 455 Kerberos 5", RFC 3961, February 2005. 456 457 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 458 Kerberos Network Authentication Service (V5)", RFC 4120, 459 July 2005. 460 461 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 462 Version 5 Generic Security Service Application Program 463 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 464 July 2005. 465 466 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 467 Simple and Protected Generic Security Service Application 468 Program Interface (GSS-API) Negotiation Mechanism", 469 RFC 4178, October 2005. 470 4718.2. Informative references 472 473 [KRB-ANON] 474 Zhu, L. and P. Leach, "Kerberos Anonymity Support", 475 draft-ietf-krb-wg-anon-04.txt (work in progress), 2007. 476 477 [KRB-PAFW] 478 Zhu, L. and S. Hartman, "A Generalized Framework for 479 Kerberos Pre-Authentication", 480 draft-ietf-krb-wg-preauth-framework-06.txt (work in 481 progress), 2007. 482 483 484Authors' Addresses 485 486 Larry Zhu 487 Microsoft Corporation 488 One Microsoft Way 489 Redmond, WA 98052 490 US 491 492 Email: lzhu@microsoft.com 493 494 495 496 497 498 499 500 501 502Zhu & Altman Expires January 10, 2008 [Page 9] 503 504Internet-Draft IAKERB July 2007 505 506 507 Jeffery Altman 508 Secure Endpoints 509 255 W 94th St 510 New York, NY 10025 511 US 512 513 Email: jaltman@secure-endpoints.com 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558Zhu & Altman Expires January 10, 2008 [Page 10] 559 560Internet-Draft IAKERB July 2007 561 562 563Full Copyright Statement 564 565 Copyright (C) The IETF Trust (2007). 566 567 This document is subject to the rights, licenses and restrictions 568 contained in BCP 78, and except as set forth therein, the authors 569 retain all their rights. 570 571 This document and the information contained herein are provided on an 572 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 573 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 574 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 575 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 576 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 577 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 578 579 580Intellectual Property 581 582 The IETF takes no position regarding the validity or scope of any 583 Intellectual Property Rights or other rights that might be claimed to 584 pertain to the implementation or use of the technology described in 585 this document or the extent to which any license under such rights 586 might or might not be available; nor does it represent that it has 587 made any independent effort to identify any such rights. Information 588 on the procedures with respect to rights in RFC documents can be 589 found in BCP 78 and BCP 79. 590 591 Copies of IPR disclosures made to the IETF Secretariat and any 592 assurances of licenses to be made available, or the result of an 593 attempt made to obtain a general license or permission for the use of 594 such proprietary rights by implementers or users of this 595 specification can be obtained from the IETF on-line IPR repository at 596 http://www.ietf.org/ipr. 597 598 The IETF invites any interested party to bring to its attention any 599 copyrights, patents or patent applications, or other proprietary 600 rights that may cover technology that may be required to implement 601 this standard. Please address the information to the IETF at 602 ietf-ipr@ietf.org. 603 604 605Acknowledgment 606 607 Funding for the RFC Editor function is provided by the IETF 608 Administrative Support Activity (IASA). 609 610 611 612 613 614Zhu & Altman Expires January 10, 2008 [Page 11] 615 616 617