| blob | 2704bb86f883cfa5c4cc0b990b4c2ee909d4d3a8 |
3 NETWORK WORKING GROUP L. Zhu
4 Internet-Draft Microsoft Corporation
5 Updates: 4120 (if approved) J. Altman
6 Intended status: Standards Track Secure Endpoints
7 Expires: August 30, 2007 February 26, 2007
10 Initial and Pass Through Authentication Using Kerberos V5 and the GSS-
11 API (IAKERB)
12 draft-zhu-ws-kerb-01
14 Status of this Memo
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.
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.
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."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 This Internet-Draft will expire on August 30, 2007.
39 Copyright Notice
41 Copyright (C) The IETF Trust (2007).
43 Abstract
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
54 Zhu & Altman Expires August 30, 2007 [Page 1]
55 \f
56 Internet-Draft IAKERB February 2007
59 accessible to the application server.
62 Table of Contents
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. Normative References . . . . . . . . . . . . . . . . . . . . . 8
72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
73 Intellectual Property and Copyright Statements . . . . . . . . . . 10
110 Zhu & Altman Expires August 30, 2007 [Page 2]
111 \f
112 Internet-Draft IAKERB February 2007
115 1. Introduction
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.
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.
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.
147 2. Conventions Used in This Document
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].
154 3. GSS-API Encapsulation
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:
160 id-kerberos-iakerb ::=
161 { iso(1) org(3) dod(6) internet(1) security(5) kerberosV5(2)
162 iakerb(TBD) }
166 Zhu & Altman Expires August 30, 2007 [Page 3]
167 \f
168 Internet-Draft IAKERB February 2007
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.
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.
193 Client <---------> IAKERB proxy <---------> KDC
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.
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].
204 Token TOK_ID Value in Hex
205 --------------------------------------
206 IAKERB_PROXY 05 01
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].
222 Zhu & Altman Expires August 30, 2007 [Page 4]
223 \f
224 Internet-Draft IAKERB February 2007
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 }
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].
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.
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.
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 (TBD) to the client and the context
256 fails to establish. There is no accompanying error data defined in
257 this document for this error code.
259 KRB_AP_ERR_IAKERB_KDC_NOT_FOUND TBD
260 -- The IAKERB proxy could not find a KDC.
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 KRB_ERROR (TBD) to the
266 client and the context fails to establish. There is no accompanying
267 error data defined in this document for this error code.
269 KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE TBD
270 -- The KDC did not respond to the IAKERB proxy.
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
278 Zhu & Altman Expires August 30, 2007 [Page 5]
279 \f
280 Internet-Draft IAKERB February 2007
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.
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].
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 MUST contain the a TYPED_DATA
296 element per [GSS-EXTS], whose data-type is TD_IAKERB_FINISHED (TBD)
297 and whose data-value contains the ASN.1 DER encoding of the structure
298 TD-IAKERB-FINISHED.
300 TD-IAKERB-FINISHED TBD
301 --- Data type for the IAKERB checksum.
303 TD-IAKERB-FINISHED ::= {
304 iakerb-messages [1] Checksum,
305 -- Contains the checksum of the GSS-API tokens
306 -- exchanged between the initiator and the acceptor,
307 -- and prior to the containing AP_REQ GSS-API token.
308 -- The checksum is performed on the tokens in the
309 -- order that the tokens were sent.
310 ...
311 }
313 The iakerb-messages field in the TD-IAKERB-FINISHED structure
314 contains a checksum of all the GSS-API tokens exchanged between the
315 initiator and the acceptor, and prior to the GSS-API token containing
316 the AP_REQ. This checksum is performed over these GSS-API tokens in
317 the order that the tokens were sent. In the parlance of [RFC3961],
318 the checksum type is the required checksum type for the enctype of
319 the subkey in the authenticator, the protocol key for the checksum
320 operation is the authenticator subkey, and the key usage number is
321 KEY_USAGE_IAKERB_FINISHED (TBD).
323 The GSS-API acceptor MUST then verify the checksum contained in the
324 TD-IAKERB-FINISHED element. This checksum provides integrity
325 protection for the messages exchanged including the unauthenticated
326 clear texts in the IAKERB-HEADER structure.
328 If the pre-authentication data is encrypted in the long-term
329 password-based key of the principal, the risk of security exposures
330 is real. Implementations SHOULD provide the AS_REQ armoring as
334 Zhu & Altman Expires August 30, 2007 [Page 6]
335 \f
336 Internet-Draft IAKERB February 2007
339 defined in [KRB-PAFW] unless an alternative protection is deployed.
340 In addition, the anonymous Kerberos FAST option is RECOMMENDED for
341 the client to complicate traffic analysis by the adversary.
344 4. Addresses in Tickets
346 In IAKERB, the machine sending requests to the KDC is the GSS-API
347 acceptor and not the client. As a result, the client should not
348 include its addresses in any KDC requests for two reasons. First,
349 the KDC may reject the forwarded request as being from the wrong
350 client. Second, in the case of initial authentication for a dial-up
351 client, the client machine may not yet possess a network address.
352 Hence, as allowed by [RFC4120], the addresses field of the AS-REQ and
353 TGS-REQ requests SHOULD be blank and the caddr field of the ticket
354 SHOULD similarly be left blank.
357 5. Security Considerations
359 A typical IAKERB client sends the AS_REQ with pre-authentication data
360 encrypted in the long-term keys of the user before the server is
361 authenticated. This enables offline attacks by un-trusted servers.
362 To mitigate this threat, the client SHOULD use Kerberos FAST [KRB-
363 PAFW] and require KDC authentication to protect the user's
364 credentials.
366 The client name is in clear text in the authentication exchange
367 messages and ticket granting service exchanges according to [RFC4120]
368 whereas the client name is encrypted in client- server application
369 exchange messages. By using the IAKERB proxy to relay the ticket
370 requests and responses, the client's identity could be revealed in
371 the client-server traffic where the same identity could have been
372 concealed if IAKERB were not used. Hence, to complicate traffic
373 analysis and provide privacy for the IAKERB client, the IAKERB client
374 SHOULD request the anonymous Kerberos FAST option [KRB-PAFW].
376 Similar to other network access protocols, IAKERB allows an
377 unauthenticated client (possibly outside the security perimeter of an
378 organization) to send messages that are proxied to interior servers.
380 In a scenario where DNS SRV RR's are being used to locate the KDC,
381 IAKERB is being used, and an external attacker can modify DNS
382 responses to the IAKERB proxy, there are several countermeasures to
383 prevent arbitrary messages from being sent to internal servers:
390 Zhu & Altman Expires August 30, 2007 [Page 7]
391 \f
392 Internet-Draft IAKERB February 2007
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.
402 2. The proxy can do application level sanity checking and filtering.
403 This countermeasure should eliminate many of the above attacks.
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).
416 6. Acknowledgements
418 Jonathan Trostle, Michael Swift, Bernard Aboba and Glen Zorn wrote
419 earlier revision of this document.
421 The hallway conversations between Larry Zhu and Nicolas Williams
422 formed the basis of this document.
425 7. IANA Considerations
427 There is no IANA action required for this document.
430 8. Normative References
432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
433 Requirement Levels", BCP 14, RFC 2119, March 1997.
435 [RFC2743] Linn, J., "Generic Security Service Application Program
436 Interface Version 2, Update 1", RFC 2743, January 2000.
438 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
439 Kerberos 5", RFC 3961, February 2005.
441 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
442 Kerberos Network Authentication Service (V5)", RFC 4120,
446 Zhu & Altman Expires August 30, 2007 [Page 8]
447 \f
448 Internet-Draft IAKERB February 2007
451 July 2005.
453 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
454 Version 5 Generic Security Service Application Program
455 Interface (GSS-API) Mechanism: Version 2", RFC 4121,
456 July 2005.
458 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
459 Simple and Protected Generic Security Service Application
460 Program Interface (GSS-API) Negotiation Mechanism",
461 RFC 4178, October 2005.
464 Authors' Addresses
466 Larry Zhu
467 Microsoft Corporation
468 One Microsoft Way
469 Redmond, WA 98052
470 US
472 Email: lzhu@microsoft.com
475 Jeffery Altman
476 Secure Endpoints
477 255 W 94th St
478 New York, NY 10025
479 US
481 Email: jaltman@secure-endpoints.com
502 Zhu & Altman Expires August 30, 2007 [Page 9]
503 \f
504 Internet-Draft IAKERB February 2007
507 Full Copyright Statement
509 Copyright (C) The IETF Trust (2007).
511 This document is subject to the rights, licenses and restrictions
512 contained in BCP 78, and except as set forth therein, the authors
513 retain all their rights.
515 This document and the information contained herein are provided on an
516 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
517 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
518 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
519 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
520 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
521 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
524 Intellectual Property
526 The IETF takes no position regarding the validity or scope of any
527 Intellectual Property Rights or other rights that might be claimed to
528 pertain to the implementation or use of the technology described in
529 this document or the extent to which any license under such rights
530 might or might not be available; nor does it represent that it has
531 made any independent effort to identify any such rights. Information
532 on the procedures with respect to rights in RFC documents can be
533 found in BCP 78 and BCP 79.
535 Copies of IPR disclosures made to the IETF Secretariat and any
536 assurances of licenses to be made available, or the result of an
537 attempt made to obtain a general license or permission for the use of
538 such proprietary rights by implementers or users of this
539 specification can be obtained from the IETF on-line IPR repository at
540 http://www.ietf.org/ipr.
542 The IETF invites any interested party to bring to its attention any
543 copyrights, patents or patent applications, or other proprietary
544 rights that may cover technology that may be required to implement
545 this standard. Please address the information to the IETF at
546 ietf-ipr@ietf.org.
549 Acknowledgment
551 Funding for the RFC Editor function is provided by the IETF
552 Administrative Support Activity (IASA).
558 Zhu & Altman Expires August 30, 2007 [Page 10]
559 \f