1 2 3NETWORK WORKING GROUP L. Zhu 4Internet-Draft Microsoft Corporation 5Updates: 4120 (if approved) October 17, 2006 6Intended status: Standards Track 7Expires: April 20, 2007 8 9 10 Kerberos for Web Services 11 draft-zhu-ws-kerb-00 12 13Status of this Memo 14 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 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. 24 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." 29 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 32 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 35 36 This Internet-Draft will expire on April 20, 2007. 37 38Copyright Notice 39 40 Copyright (C) The Internet Society (2006). 41 42Abstract 43 44 This document defines extensions to the Kerberos protocol and the 45 GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to 46 exchange messages with the KDC using the GSS-API server as the proxy, 47 by encapsulating the Kerberos messages inside GSS-API tokens. With 48 these extensions, Kerberos is suitable for securing communication 49 between the client and web services over the Internet. 50 51 52 53 54Zhu Expires April 20, 2007 [Page 1] 55 56Internet-Draft WS-KERB October 2006 57 58 59Table of Contents 60 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 63 3. GSS-API Encapsulation . . . . . . . . . . . . . . . . . . . . . 3 64 4. Addresses in Tickets . . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 Intellectual Property and Copyright Statements . . . . . . . . . . 9 71 72 73 74 75 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 Expires April 20, 2007 [Page 2] 111 112Internet-Draft WS-KERB October 2006 113 114 1151. Introduction 116 117 The Kerberos [RFC4120] pre-authentication framework [KRB-PAFW] 118 promises minimal or no exposure of weak client keys and strong client 119 authentication. The Kerberos support of anonymity [KRB-ANON] 120 provides for privacy. These advancements make Kerberos suitable over 121 the Internet. 122 123 The traditional client-push Kerberos protocol does not work well in 124 the Web services environments where the KDC is not accessible to the 125 client, but is accessible to the web server. For example, the KDC is 126 commonly placed behind a firewall together with the application 127 server. The lack of accessibility to the KDC by the client could 128 also occur are when the client does not have an IP address prior to 129 authenticating to an access point. 130 131 Generic Security Service Application Program Interface (GSS-API) 132 [RFC2743] allows security mechanisms exchange arbitrary messages 133 between the client and the server via the application traffic, 134 independent of the underlying transports. A protocol based on 135 [RFC4121] is thus defined to allow the GSS-API client to exchange 136 Kerberos messages with the KDC by using the GSS-API server as the 137 proxy. The server-pull model defined in this specification is 138 benefical for clients with limited processing power such as mobile 139 devices, or when the client and the server message exchange has high 140 network latency. 141 142 Client <---------> WS-KERB proxy <----------> KDC 143 144 The Kerberos client MUST use a pre-authentication mechanism such as 145 FAST [KRB-PAFW] to avoid exposure of long term client keys to the 146 server, before and after the server is authenticated, and hide the 147 client identity from adversary who can eavesdrop the application 148 traffic if such level of privacy is desirable. 149 150 1512. Conventions Used in This Document 152 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 156 157 1583. GSS-API Encapsulation 159 160 The mechanism Objection Identifier (OID) for GSS-API WS-KERB, in 161 accordance with the mechanism proposed by [RFC4178] for negotiating 162 protocol variations, is id-kerberos-ws: 163 164 165 166Zhu Expires April 20, 2007 [Page 3] 167 168Internet-Draft WS-KERB October 2006 169 170 171 id-kerberos-ws ::= 172 { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) 173 webService(6) } 174 175 The first token of the GSS-API WS-KERB mechanism MUST have the 176 generic token framing described in section 3.1 of [RFC2743] with the 177 mechanism OID being id-kerberos-ws, and any subsequent GSS-API WS- 178 KERB token MUST NOT have this framing. 179 180 The GSS-API WS-KERB mechanism MUST always provide server 181 authentication, even if the client does not ask for it. When server- 182 authentication is performed, the GSS-API server will always send back 183 an AP-REP, and as described later in this section this mechanism 184 provides integrity protection for all client-server proxy message 185 exchanges. 186 187 The innerToken described in section 3.1 of [RFC2743] and subsequent 188 GSS-API tokens have the following formats: it starts with a two-octet 189 token-identifier (TOK_ID), followed by a WS-KERB message or a 190 Kerberos message. 191 192 193 Token/Message TOK_ID Value in Hex 194 ----------------------------------------- 195 WS_KRB_PROXY 05 01 196 197 Only one WS-KERB specific message, namely the WS_KRB_PROXY message, 198 is defined in this document. The TOK_ID values for [RFC4120] 199 Kerberos messages are the same as those defined for the GSS-API 200 Kerberos mechanism [RFC4121]. 201 202 The message of the WS_KRB_PROXY type is defined as a WS-KRB-HEADER 203 structure immediately followed by a Kerberos message. The Kerberos 204 message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, or a KRB- 205 ERROR as defined in [RFC4120]. 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222Zhu Expires April 20, 2007 [Page 4] 223 224Internet-Draft WS-KERB October 2006 225 226 227 WS-KRB-HEADER ::= SEQUENCE { 228 pvno [1] INTEGER (5) , 229 msg-type [2] INTEGER (23), 230 proxy-data [3] ProxyData, 231 ... 232 } 233 234 ProxyData :: = SEQUENCE { 235 realm [1] Realm, 236 cookie [3] OCTET STRING OPTIONAL, 237 -- opaque data, if sent by the server, 238 -- MUST be copied by the client unchanged into 239 -- the next WS-KERB message. 240 ... 241 } 242 243 244 The WS-KRB-HEADER structure and all the Kerberos messages MUST be 245 encoded using Abstract Syntax Notation One (ASN.1) Distinguished 246 Encoding Rules (DER) [X680] [X690]. 247 248 The GSS-API WS-KERB client fills out the realm field in the ProxyData 249 of the first request with the client realm. If the client does not 250 know the client realm [REFERALS], it MUST fill it out using the 251 client's default realm name such as the realm of the client host. 252 Typically the Kerberos message in the first WS_KRB_PROXY message from 253 the client is an AS-REQ message. 254 255 Upon receipt of the WS_KRB_PROXY message, the GSS-API WS-KERB server 256 MUST use the proxy-data in the message from the client to locate the 257 KDC and sends the encapsulated Kerberos message to that KDC. In 258 order to reduce the number of roundtrips between the client and the 259 server, the server SHOULD process any message exchange with the KDC 260 if the exchange is unauthenticated, such as client-referral message 261 exchange [REFERALS]. If the server can not process the KDC response 262 by itself, for example when the knowledge of the client keys is 263 required, it sends back to the client the KDC reply message 264 encapsulated in a WS_KRB_PROXY message. The server MUST fill out the 265 realm name whose KDC produced the response. The server SHOULD use 266 the XKDC mechanism described in [KRB-PAFW] to allow the client's KDC 267 to obtain a service ticket to the server, thus further reduce the 268 number of roundtrips between the GSS-API client and the GSS-API 269 server. The GSS-API server can send opaque data in the cookie field 270 of the WS-KRB-HEADER structure in the server reply to the client, in 271 order to, for example, reduce the amount of state information kept by 272 the GSS-API server. The content and the encoding of the cookie field 273 is a local matter of the server. The client MUST copy the verbatim 274 cookie from the previous server response, when the cookie is present, 275 276 277 278Zhu Expires April 20, 2007 [Page 5] 279 280Internet-Draft WS-KERB October 2006 281 282 283 whenever it sends an additional WS-KRB-PROXY message to the server. 284 The client processes the KDC response, and fills out the realm name 285 it believes to whom the server should send the encapsulated Kerberos 286 message. 287 288 When the client obtains a service ticket, the client then sends a 289 KRB_AP_REQ message to the server, and proceed as defined in 290 [RFC4121]. A GSS-API authenticator extension [GSS-EXTS] MUST be sent 291 by the client. The extension type is 2 and the content is the ASN.1 292 DER encoding of the type Checksum. The checksum is performed over 293 all GSS-API messages as exchanged between the client and the server 294 before the KRB_AP_REQ message, and in the order of the exchange. The 295 checksum type is the required checksum type for the enctype of the 296 subkey in the authenticator, the protocol key is the authenticator 297 subkey, and the key usage number is TBA-1. The server MUST verify 298 this checksum in the GSS-API authenticator extension, then respond 299 with an AP-REP extension [GSS-EXTS]. The AP-REP extension type is 2 300 and the the content is the ASN.1 DER encoding of the type Checksum. 301 This checksum is performed over all GSS-API messages as exchanged 302 between the client and the server before the KRB_AP_REQ message, and 303 in the order of the exchange. The checksum type is the required 304 checksum type for the enctype of the authenticator subkey in the 305 request, and the protocol key is the authenticator subkey, and the 306 key usage number is TBA-2. The client MUST then verify this 307 checksum. 308 309 3104. Addresses in Tickets 311 312 In WS-KERB, the machine sending requests to the KDC is the GSS-API 313 server and not the client. As a result, the client should not 314 include its addresses in any KDC requests for two reasons. First, 315 the KDC may reject the forwarded request as being from the wrong 316 client. Second, in the case of initial authentication for a dial-up 317 client, the client machine may not yet possess a network address. 318 Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and 319 TGS-REQ requests SHOULD be blank and the caddr field of the ticket 320 SHOULD similarly be left blank. 321 322 3235. Security Considerations 324 325 Similar to other network access protocols, WS-KERB allows an 326 unauthenticated client (possibly outside the security perimeter of an 327 organization) to send messages that are proxied to interior servers. 328 329 In a scenario where DNS SRV RR's are being used to locate the KDC, 330 WS-KERB is being used, and an external attacker can modify DNS 331 332 333 334Zhu Expires April 20, 2007 [Page 6] 335 336Internet-Draft WS-KERB October 2006 337 338 339 responses to the WS-KERB proxy, there are several countermeasures to 340 prevent arbitrary messages from being sent to internal servers: 341 342 1. KDC port numbers can be statically configured on the WS-KERB 343 proxy. In this case, the messages will always be sent to KDC's. 344 For an organization that runs KDC's on a static port (usually 345 port 88) and does not run any other servers on the same port, 346 this countermeasure would be easy to administer and should be 347 effective. 348 349 2. The proxy can do application level sanity checking and filtering. 350 This countermeasure should eliminate many of the above attacks. 351 352 3. DNS security can be deployed. This countermeasure is probably 353 overkill for this particular problem, but if an organization has 354 already deployed DNS security for other reasons, then it might 355 make sense to leverage it here. Note that Kerberos could be used 356 to protect the DNS exchanges. The initial DNS SRV KDC lookup by 357 the proxy will be unprotected, but an attack here is at most a 358 denial of service (the initial lookup will be for the proxy's KDC 359 to facilitate Kerberos protection of subsequent DNS exchanges 360 between itself and the DNS server). 361 362 3636. Acknowledgements 364 365 The server-proxy idea is based on the early revisions of this 366 document written by Jonathan Trostle, Michael Swift, Bernard Aboba 367 and Glen Zorn. 368 369 The rest of the ideas mostly came from hallway conversations between 370 the author and Nicolas Williams. 371 372 3737. IANA Considerations 374 375 There is no IANA action required for this document. 376 377 3788. Normative References 379 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 383 [RFC2743] Linn, J., "Generic Security Service Application Program 384 Interface Version 2, Update 1", RFC 2743, January 2000. 385 386 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 387 388 389 390Zhu Expires April 20, 2007 [Page 7] 391 392Internet-Draft WS-KERB October 2006 393 394 395 Kerberos Network Authentication Service (V5)", RFC 4120, 396 July 2005. 397 398 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 399 Version 5 Generic Security Service Application Program 400 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 401 July 2005. 402 403 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 404 Simple and Protected Generic Security Service Application 405 Program Interface (GSS-API) Negotiation Mechanism", 406 RFC 4178, October 2005. 407 408 [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity 409 Support", draft-ietf-krb-wg-anon, work in progress. 410 411 412 [KRB-PAFW] Zhu, etl, "Kerberos Pre-Authentication framework", 413 draft-ietf-krb-wg-preauth-framework, work in progress. 414 415 [GSS-EXTS] Emery, S., draft-ietf-krb-wg-gss-cb-hash-agility, work in 416 progess. 417 418 [REFERALS] Raeburn, K., "Generating KDC Referrals to Locate Kerberos 419 Realms", draft-ietf-krb-wg-kerberos-referrals, work in 420 progress. 421 422 [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 423 Information technology - Abstract Syntax Notation One 424 (ASN.1): Specification of basic notation. 425 426 [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, 427 Information technology - ASN.1 encoding Rules: 428 Specification of Basic Encoding Rules (BER), Canonical 429 Encoding Rules (CER) and Distinguished Encoding Rules 430 (DER). 431 432 433Author's Address 434 435 Larry Zhu 436 Microsoft Corporation 437 One Microsoft Way 438 Redmond, WA 98052 439 US 440 441 Email: lzhu@microsoft.com 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470Zhu Expires April 20, 2007 [Page 8] 471 472Internet-Draft WS-KERB October 2006 473 474 475Full Copyright Statement 476 477 Copyright (C) The Internet Society (2006). 478 479 This document is subject to the rights, licenses and restrictions 480 contained in BCP 78, and except as set forth therein, the authors 481 retain all their rights. 482 483 This document and the information contained herein are provided on an 484 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 485 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 486 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 487 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 488 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 489 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 490 491 492Intellectual Property 493 494 The IETF takes no position regarding the validity or scope of any 495 Intellectual Property Rights or other rights that might be claimed to 496 pertain to the implementation or use of the technology described in 497 this document or the extent to which any license under such rights 498 might or might not be available; nor does it represent that it has 499 made any independent effort to identify any such rights. Information 500 on the procedures with respect to rights in RFC documents can be 501 found in BCP 78 and BCP 79. 502 503 Copies of IPR disclosures made to the IETF Secretariat and any 504 assurances of licenses to be made available, or the result of an 505 attempt made to obtain a general license or permission for the use of 506 such proprietary rights by implementers or users of this 507 specification can be obtained from the IETF on-line IPR repository at 508 http://www.ietf.org/ipr. 509 510 The IETF invites any interested party to bring to its attention any 511 copyrights, patents or patent applications, or other proprietary 512 rights that may cover technology that may be required to implement 513 this standard. Please address the information to the IETF at 514 ietf-ipr@ietf.org. 515 516 517Acknowledgment 518 519 Funding for the RFC Editor function is provided by the IETF 520 Administrative Support Activity (IASA). 521 522 523 524 525 526Zhu Expires April 20, 2007 [Page 9] 527 528 529