1 2 3NETWORK WORKING GROUP L. Zhu 4Internet-Draft Microsoft Corporation 5Updates: 4120 (if approved) October 2006 6Intended status: Standards Track 7Expires: April 4, 2007 8 9 10 Kerberos for Web Services 11 draft-zhu-ws-kerb-01 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 4, 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 acceptor as the 47 proxy, by encapsulating the Kerberos messages inside GSS-API tokens. 48 With these extensions, Kerberos is suitable for securing 49 communication between the client and web services over the Internet. 50 51 52 53 54Zhu Expires April 4, 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 4, 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 initiator and the acceptor via the application traffic, 134 independent of the underlying transports. A protocol based on 135 [RFC4121] is thus defined to allow the GSS-API initiator to exchange 136 Kerberos messages with the KDC by using the GSS-API acceptor as the 137 proxy. The acceptor-pull model defined in this specification is 138 benefical for initiators with limited processing power such as mobile 139 devices, or when the transport layer between the initiator and the 140 acceptor has high network latency. 141 142 Client --------- WS-KERB proxy ---------- KDC 143 144 The Kerberos client MUST avoid exposure of long term client keys to 145 the GSS-API acceptor, before and after the Kerberos server is 146 authenticated. This can be accomplished by using Kerberos-FAST [KRB- 147 PAFW]. Furthermore, the initiator can use the anonymous option as 148 defined in Section 6.5.2 of [KRB-PAFW], to hide the client identity 149 from adversary who can eavesdrop the application traffic. 150 151 1522. Conventions Used in This Document 153 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in [RFC2119]. 157 158 1593. GSS-API Encapsulation 160 161 The mechanism Objection Identifier (OID) for GSS-API WS-KERB, in 162 accordance with the mechanism proposed by [RFC4178] for negotiating 163 164 165 166Zhu Expires April 4, 2007 [Page 3] 167 168Internet-Draft WS-KERB October 2006 169 170 171 protocol variations, is id-kerberos-ws. 172 173 id-kerberos-ws ::= 174 { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2) 175 webService(6) } 176 177 The first token of the GSS-API WS-KERB mechanism MUST have the 178 generic token framing described in section 3.1 of [RFC2743] with the 179 mechanism OID being id-kerberos-ws, and any subsequent GSS-API WS- 180 KERB token MUST NOT have this framing. 181 182 The GSS-API WS-KERB mechanism MUST always provide mutual 183 authentication, even if the initiator does not ask for it. When 184 mutual-authentication is performed, the GSS-API acceptor will always 185 send back an AP-REP, and as described later in this section this 186 mechanism provides integrity protection for all initiator-acceptor 187 proxy message exchanges. 188 189 The innerToken described in section 3.1 of [RFC2743] and subsequent 190 GSS-API tokens have the following formats: it starts with a two-octet 191 token-identifier (TOK_ID), followed by a WS-KERB message or a 192 Kerberos message. 193 194 195 Token/Message TOK_ID Value in Hex 196 ----------------------------------------- 197 WS_KRB_PROXY 05 01 198 199 Only one WS-KERB specific message, namely the WS_KRB_PROXY message, 200 is defined in this document. The TOK_ID values for [RFC4120] 201 Kerberos messages are the same as those defined for the GSS-API 202 Kerberos mechanism [RFC4121]. 203 204 The message of the WS_KRB_PROXY type is defined as a WS-KRB-HEADER 205 structure immediately followed by a Kerberos message. The Kerberos 206 message can be an AS-REQ, an AS-REP, a TGS-REQ, a TGS-REP, or a KRB- 207 ERROR as defined in [RFC4120]. 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222Zhu Expires April 4, 2007 [Page 4] 223 224Internet-Draft WS-KERB October 2006 225 226 227 WS-KRB-HEADER ::= SEQUENCE { 228 proxy-data [1] ProxyData, 229 ... 230 } 231 232 ProxyData :: = SEQUENCE { 233 realm [1] Realm, 234 cookie [3] OCTET STRING OPTIONAL, 235 -- opaque data, if sent by the acceptor, 236 -- MUST be copied by the client unchanged into 237 -- the next WS-KERB message. 238 ... 239 } 240 241 242 The WS-KRB-HEADER structure and all the Kerberos messages MUST be 243 encoded using Abstract Syntax Notation One (ASN.1) Distinguished 244 Encoding Rules (DER) [X680] [X690]. 245 246 The GSS-API initiator fills out the realm field in the ProxyData of 247 the first request with the client realm. If the client does not know 248 the client realm [REFERALS], it MUST fill it out using the client's 249 default realm name such as the realm of the client host. Typically 250 the Kerberos message in the first WS_KRB_PROXY message from the 251 client is an AS-REQ message. 252 253 Upon receipt of the WS_KRB_PROXY message, the GSS-API WS-KERB 254 acceptor MUST use the proxy-data in the message from the client to 255 locate the KDC and sends the encapsulated Kerberos message to that 256 KDC. Unless otherwise specified, the acceptor can locate the KDC per 257 Section 7.2.3.2 of [RFC4120]. 258 259 In order to reduce the number of roundtrips between the initiator and 260 the acceptor, the acceptor SHOULD process any message exchange with 261 the KDC if the exchange is unauthenticated, such as client-referral 262 message exchange [REFERALS]. If the acceptor can not process the KDC 263 response by itself, for example when the knowledge of the client keys 264 is required, it sends back to the client the KDC reply message 265 encapsulated in a WS_KRB_PROXY message. The acceptor MUST fill out 266 the realm name whose KDC produced the response. The acceptor SHOULD 267 use the kdc-referrals option described in Section 6.5.2 of [KRB-PAFW] 268 to allow the KDC of the client's realm to obtain a service ticket 269 addressed to the acceptor, thus further reduce the number of 270 roundtrips between the GSS-API initiator and the GSS-API acceptor. 271 The GSS-API acceptor can send opaque data in the cookie field of the 272 WS-KRB-HEADER structure in the reply from the acceptor to the 273 initiator, in order to, for example, to facilitate state managements 274 on the GSS-API acceptor. The content and the encoding of the cookie 275 276 277 278Zhu Expires April 4, 2007 [Page 5] 279 280Internet-Draft WS-KERB October 2006 281 282 283 field is a local matter of the acceptor. The initiator MUST copy the 284 verbatim cookie from the previous acceptor response, when the cookie 285 is present, whenever it sends an additional WS-KRB-PROXY message to 286 the acceptor. The client processes the KDC response, and fills out 287 the realm name it believes to whom the acceptor should send the 288 encapsulated Kerberos message. 289 290 When the client obtains a service ticket, the initiator then sends a 291 KRB_AP_REQ message to the acceptor, and proceed as defined in 292 [RFC4121]. A GSS-API authenticator extension [GSS-EXTS] MUST be sent 293 by the initiator. The extension type is 2 and the content is the 294 ASN.1 DER encoding of the type Checksum. The checksum is performed 295 over all GSS-API messages as exchanged between the initiator and the 296 acceptor before the KRB_AP_REQ message, and in the order of the 297 exchange. The checksum type is the required checksum type for the 298 enctype of the subkey in the authenticator, the protocol key is the 299 authenticator subkey, and the key usage number is TBA-1. The 300 acceptor MUST verify this checksum in the GSS-API authenticator 301 extension, then respond with an AP-REP extension [GSS-EXTS]. The AP- 302 REP extension type is 2 and the the content is the ASN.1 DER encoding 303 of the type Checksum. This checksum is performed over all GSS-API 304 messages as exchanged between the initiator and the acceptor before 305 the KRB_AP_REQ message, and in the order of the exchange. The 306 checksum type is the required checksum type for the enctype of the 307 authenticator subkey in the request, and the protocol key is the 308 authenticator subkey, and the key usage number is TBA-2. The 309 initiator MUST then verify this checksum. 310 311 3124. Addresses in Tickets 313 314 In WS-KERB, the machine sending requests to the KDC is the GSS-API 315 acceptor and not the initiator. As a result, the initiator should 316 not include its addresses in any KDC requests for two reasons. 317 First, the KDC may reject the forwarded request as being from the 318 wrong client. Second, in the case of initial authentication for a 319 dial-up client, the client machine may not yet possess a network 320 address. Hence, as allowed by [RFC4120], the addresses field of the 321 AS-REQ and TGS-REQ requests SHOULD be blank and the caddr field of 322 the ticket SHOULD similarly be left blank. 323 324 3255. Security Considerations 326 327 Similar to other network access protocols, WS-KERB allows an 328 unauthenticated client (possibly outside the security perimeter of an 329 organization) to send messages that are proxied to interior servers. 330 331 332 333 334Zhu Expires April 4, 2007 [Page 6] 335 336Internet-Draft WS-KERB October 2006 337 338 339 In a scenario where DNS SRV RR's are being used to locate the KDC, 340 WS-KERB is being used, and an external attacker can modify DNS 341 responses to the WS-KERB proxy, there are several countermeasures to 342 prevent arbitrary messages from being sent to internal servers: 343 344 1. KDC port numbers can be statically configured on the WS-KERB 345 proxy. In this case, the messages will always be sent to KDC's. 346 For an organization that runs KDC's on a static port (usually 347 port 88) and does not run any other servers on the same port, 348 this countermeasure would be easy to administer and should be 349 effective. 350 351 2. The proxy can do application level sanity checking and filtering. 352 This countermeasure should eliminate many of the above attacks. 353 354 3. DNS security can be deployed. This countermeasure is probably 355 overkill for this particular problem, but if an organization has 356 already deployed DNS security for other reasons, then it might 357 make sense to leverage it here. Note that Kerberos could be used 358 to protect the DNS exchanges. The initial DNS SRV KDC lookup by 359 the proxy will be unprotected, but an attack here is at most a 360 denial of service (the initial lookup will be for the proxy's KDC 361 to facilitate Kerberos protection of subsequent DNS exchanges 362 between itself and the DNS server). 363 364 3656. Acknowledgements 366 367 The acceptor-proxy idea is based on the early revisions of this 368 document written by Jonathan Trostle, Michael Swift, Bernard Aboba 369 and Glen Zorn. 370 371 The rest of the ideas mostly came from hallway conversations between 372 the author and Nicolas Williams. 373 374 3757. IANA Considerations 376 377 There is no IANA action required for this document. 378 379 3808. Normative References 381 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 384 385 [RFC2743] Linn, J., "Generic Security Service Application Program 386 Interface Version 2, Update 1", RFC 2743, January 2000. 387 388 389 390Zhu Expires April 4, 2007 [Page 7] 391 392Internet-Draft WS-KERB October 2006 393 394 395 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 396 Kerberos Network Authentication Service (V5)", RFC 4120, 397 July 2005. 398 399 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 400 Version 5 Generic Security Service Application Program 401 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 402 July 2005. 403 404 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 405 Simple and Protected Generic Security Service Application 406 Program Interface (GSS-API) Negotiation Mechanism", 407 RFC 4178, October 2005. 408 409 [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity 410 Support", draft-ietf-krb-wg-anon, work in progress. 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 447Zhu Expires April 4, 2007 [Page 8] 448 449Internet-Draft WS-KERB October 2006 450 451 452Full Copyright Statement 453 454 Copyright (C) The Internet Society (2006). 455 456 This document is subject to the rights, licenses and restrictions 457 contained in BCP 78, and except as set forth therein, the authors 458 retain all their rights. 459 460 This document and the information contained herein are provided on an 461 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 462 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 463 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 464 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 465 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 466 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 467 468 469Intellectual Property 470 471 The IETF takes no position regarding the validity or scope of any 472 Intellectual Property Rights or other rights that might be claimed to 473 pertain to the implementation or use of the technology described in 474 this document or the extent to which any license under such rights 475 might or might not be available; nor does it represent that it has 476 made any independent effort to identify any such rights. Information 477 on the procedures with respect to rights in RFC documents can be 478 found in BCP 78 and BCP 79. 479 480 Copies of IPR disclosures made to the IETF Secretariat and any 481 assurances of licenses to be made available, or the result of an 482 attempt made to obtain a general license or permission for the use of 483 such proprietary rights by implementers or users of this 484 specification can be obtained from the IETF on-line IPR repository at 485 http://www.ietf.org/ipr. 486 487 The IETF invites any interested party to bring to its attention any 488 copyrights, patents or patent applications, or other proprietary 489 rights that may cover technology that may be required to implement 490 this standard. Please address the information to the IETF at 491 ietf-ipr@ietf.org. 492 493 494Acknowledgment 495 496 Funding for the RFC Editor function is provided by the IETF 497 Administrative Support Activity (IASA). 498 499 500 501 502 503Zhu Expires April 4, 2007 [Page 9] 504 505 506