| blob | 98a615c3d5ca6db3d008420998a7b3ed4e61fe88 |
3 NETWORK WORKING GROUP L. Zhu
4 Internet-Draft G. Chander
5 Updates: 4279 (if approved) Microsoft Corporation
6 Intended status: Standards Track J. Altman
7 Expires: January 26, 2008 Secure Endpoints Inc.
8 S. Santesson
9 Microsoft Corporation
10 July 25, 2007
13 Flexible Key Agreement for Transport Layer Security (FKA-TLS)
14 draft-santesson-tls-gssapi-03
16 Status of this Memo
18 By submitting this Internet-Draft, each author represents that any
19 applicable patent or other IPR claims of which he or she is aware
20 have been or will be disclosed, and any of which he or she becomes
21 aware will be disclosed, in accordance with Section 6 of BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that
25 other groups may also distribute working documents as Internet-
26 Drafts.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 The list of current Internet-Drafts can be accessed at
34 http://www.ietf.org/ietf/1id-abstracts.txt.
36 The list of Internet-Draft Shadow Directories can be accessed at
37 http://www.ietf.org/shadow.html.
39 This Internet-Draft will expire on January 26, 2008.
41 Copyright Notice
43 Copyright (C) The IETF Trust (2007).
45 Abstract
47 This document defines extensions to RFC 4279, "Pre-Shared Key
48 Ciphersuites for Transport Layer Security (TLS)", to enable dynamic
49 key sharing in distributed environments using a Generic Security
50 Service Application Program Interface (GSS-API) mechanism, and then
54 Zhu, et al. Expires January 26, 2008 [Page 1]
55 \f
56 Internet-Draft FKA-TLS July 2007
59 import that shared key as the "Pre-Shared Key" to complete the TLS
60 handshake.
62 This is a modular approach to perform authentication and key exchange
63 based on off-shelf libraries. And it obviates the need of pair-wise
64 key sharing by enabling the use of the widely-deployed Kerberos alike
65 trust infrastructures that are highly scalable and robust.
66 Furthermore, conforming implementations can provide server
67 authentication without the use of certificates.
70 Table of Contents
72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
73 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
74 3. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 3
75 4. Choosing GSS-API Mechanisms . . . . . . . . . . . . . . . . . 8
76 5. Client Authentication . . . . . . . . . . . . . . . . . . . . 8
77 6. Protecting GSS-API Authentication Data . . . . . . . . . . . . 8
78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
82 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
83 10.2. Informative References . . . . . . . . . . . . . . . . . 11
84 Appendix A. An FKA-TLS Example: Kerberos TLS . . . . . . . . . . 13
85 Appendix B. Additional Use Cases for FXA-TLS . . . . . . . . . . 13
86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
87 Intellectual Property and Copyright Statements . . . . . . . . . . 16
110 Zhu, et al. Expires January 26, 2008 [Page 2]
111 \f
112 Internet-Draft FKA-TLS July 2007
115 1. Introduction
117 [RFC4279] defines Transport Layer Security (TLS) based on pre-shared
118 keys (PSK). This assumes a pair-wise key sharing scheme that is less
119 scalable and more costly to manage in comparison with a trusted third
120 party scheme such as Kerberos [RFC4120]. In addition, off-shelf GSS-
121 API libraries that allow dynamic key sharing are not currently
122 accessible to TLS applications. Lastly, [RFC4279] does not provide
123 true mutual authentication against the server.
125 This document extends [RFC4279] to establish a shared key, and
126 optionally provide client or server authentication, by using off-
127 shelf GSS-API libraries, and the established shared key is then
128 imported as "PSK" to [RFC4279]. No new key cipher suite is defined
129 in this document.
131 As an example usage scenario, Kerberos [RFC4121] is a GSS-API
132 mechanism that can be selected to establish a shared key between a
133 client and a server based on either asymmetric keys [RFC4556] or
134 symmetric keys [RFC4120]. By using the extensions defined in this
135 document, a TLS connection is secured using the Kerberos version 5
136 mechanism exposed as a generic security service via GSS-API.
138 With regard to the previous work for the Kerberos support in TLS,
139 [RFC2712] defines "Addition of Kerberos Cipher Suites to Transport
140 Layer Security (TLS)" which has not been widely implemented due to
141 violations of Kerberos Version 5 library abstraction layers,
142 incompatible implementations from two major distributions (Sun Java
143 and OpenSSL), and its lack of support for credential delegation.
144 This document defines a generic extensible method that addresses the
145 limitations associated with [RFC2712] and integrates Kerberos and
146 TLS. Relying on [RFC4121] for Kerberos Version 5 support will
147 significantly reduce the challenges associated with implementing this
148 protocol as a replacement for [RFC2712].
151 2. Conventions Used in This Document
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].
158 3. Protocol Definition
160 In this protocol, the on-demand key exchange is implemented by
161 encapsulating the GSS security context establishment within the TLS
162 handshake messages when PSK cipher suites are requested in the
166 Zhu, et al. Expires January 26, 2008 [Page 3]
167 \f
168 Internet-Draft FKA-TLS July 2007
171 extended ClientHello message.
173 The gss_api TLS extension is defined according to [RFC3546]. The
174 extension data carries GSS-API token within the TLS hello messages.
176 enum {
177 gss_api(TBD), (65535)
178 } ExtensionType;
180 The client MUST NOT include a gss_api TLS extension if there is no
181 PSK ciphersuite [RFC4279] included in the cipher_suites field of the
182 client hello message.
184 Initially the client computes the gss_api TLS extension data by
185 calling GSS_Init_sec_context() [RFC2743] to establish a security
186 context. The TLS client MUST set the mutual_req_flag and identify
187 the server by targ_name so that mutual authentication is performed in
188 the course of context establishment. The extension_data from the
189 client contains the output token of GSS_Init_sec_context().
191 If a GSS-API context cannot be established, the gss_api TLS extension
192 MUST NOT be included in the client hello message and it is a matter
193 of local policy on the client whether to continue or reject the TLS
194 authentication as if the gss_api TLS extension is not supported.
196 If the mutual authentication is not available on the established GSS-
197 API context, the PSK key exchange described in Section 2 of [RFC4279]
198 MUST NOT be selected, and the DHE_PSK or RSA_PSK key exchange MUST be
199 negotiated instead in order to authenticate the server.
201 Upon receipt of the gss_api TLS extension from the client, and if the
202 server supports the gss_api TLS extension, the server calls
203 GSS_Accept_sec_context() with the client GSS-API output token in the
204 client's extension data as the input token. If
205 GSS_Accept_sec_context() returns a token successfully, the server
206 responds by including a gss_api TLS extension in the server hello
207 message and places the output token in the extension_data. If
208 GSS_Accept_sec_context() fails, it is a matter of local policy on the
209 server whether to continue or reject the TLS authentication as if the
210 gss_api TLS extension is not supported.
212 The server MUST ignore a TLS gss_api extension in the extended
213 ClientHello if its selected CipherSuite is not a PSK CipherSuite
214 [RFC4279], and the server MUST NOT include a gss_api TLS extension in
215 the server hello message.
217 If after the exchange of extended ClientHello and extended
218 ServerHello with the gss_api extension, at least one more additional
222 Zhu, et al. Expires January 26, 2008 [Page 4]
223 \f
224 Internet-Draft FKA-TLS July 2007
227 GSS token is required in order to complete the GSS security context
228 establishment, the additional GSS-API token is encapsulated in a new
229 TLS Handshake message called the token_transfer message.
231 enum {
232 token_transfer(TBD), (255)
233 } HandshakeType;
235 struct {
236 HandshakeType msg_type; /* handshake type */
237 uint24 length; /* bytes in message */
238 select (HandshakeType) {
239 case token_transfer: /* NEW */
240 TokenTransfer;
241 } body;
242 } Handshake;
244 enum {
245 gss_api_token(1), (255)
246 } TokenTransferType;
248 struct {
249 TokenTransferType token_type; /* token type */
250 opaque token<0..2^16-1>;
251 } TokenTransfer;
253 The TokenTransfer structure is filled out as follows:
255 o The token_type is gss_api_token.
257 o The token field contains the GSS-API context establishment tokens
258 from the client and the server.
260 The client calls GSS_Init_sec_context() with the token in the
261 TokenTransfer stucture from the server as the input token, and then
262 places the output token, if any, into the TokenTransfer message and
263 sends the handshake message to the server. The server calls
264 GSS_Accept_sec_context() with the token in the TokenTransfer
265 structure from the client as the input token, and then places the
266 output token, if any, into the TokenTransfer message and sends the
267 handshake message to the client.
269 This loop repeats until either the context fails to establish or the
270 context is established successfully. To prevent an infinite loop,
271 both the client and the server MUST have a policy to limit the
272 maximum number of GSS-API context establishment calls for a given
273 session. The recommended value is a total of five (5) calls
274 including the GSS_Init_sec_context() and GSS_Accept_sec_context()
278 Zhu, et al. Expires January 26, 2008 [Page 5]
279 \f
280 Internet-Draft FKA-TLS July 2007
283 from both the client and server. Exceeding the maximum number of
284 calls is to be treated as a GSS security context establishment
285 failure. It is RECOMMENDED that the client and server enforce the
286 same maximum number
288 If the GSS-API context fails to establish, it is a matter of local
289 policy whether to continue or reject the TLS authentication as if the
290 gss_api TLS extension is not supported.
292 When the last GSS-API context establishment token is sent by the
293 client or when the GSS-API context fails to establish on the client
294 side and the local policy allows the TLS authentication to proceed as
295 if the TLS gss_api extension is not supported, the client sends an
296 empty TokenTransfer handshake message.
298 If the GSS-API context fails to establish and local policy allows the
299 TLS authentication continue as if the gss_api TLS extension is not
300 supported, the server MAY send another ServerHello message in order
301 to choose a different cipher suite. The client then MUST expect the
302 second ServerHello message from the server before the session is
303 established. The additional ServerHello message MUST only differ
304 from the first ServerHello message in the choice of CipherSuite and
305 it MUST NOT include a TLS gss_api extension. The second ServerHello
306 MUST NOT be present if there is no TokenTransfer message.
308 If the client and the server establish a security context
309 successfully, both the client and the server call GSS_Pseudo_random()
310 [RFC4401] to compute a sufficiently long shared secret with the same
311 value based on the negotiated cipher suite (see details below), and
312 then proceed according to [RFC4279] using this shared secret value as
313 the "PSK".
315 When the shared key is established using a GSS-API mechanism as
316 described in this document, the identity of the server and the
317 identity of the client MUST be obtained from the GSS security
318 context. In this case, the PSK identity MUST be processed as
319 follows:
321 o The PSK identity as defined in Section 5.1 of [RFC4279] MUST be
322 specified as an empty string.
324 o If the server key exchange message is present, the PSK identity
325 hint as defined in Section 5.2 of [RFC4279] MUST be empty, and it
326 MUST be ignored by the client.
328 The input parameters to GSS_Pseudo_random() to compute the shared
329 secret value MUST be provided as follows:
334 Zhu, et al. Expires January 26, 2008 [Page 6]
335 \f
336 Internet-Draft FKA-TLS July 2007
339 o The context is the handle to the GSS-API context established in
340 the given session.
342 o The prf_key is GSS_C_PRF_KEY_FULL.
344 o The prf_in contains the UTF8 encoding of the string "GSS-API TLS
345 PSK".
347 o The desired_output_len is 64. In other words, the output keying
348 mastering size is 64 in bytes. Note that this is the maximum PSK
349 length required to be supported by implementations conforming to
350 [RFC4279].
352 The following text art summaries the protocol message flow.
355 Client Server
357 ClientHello -------->
358 <--------* ServerHello
359 TokenTransfer* -------->
360 <-------- TokenTransfer*
361 .
362 .
363 .
364 TokenTransfer* -------->
365 ServerHello*
366 Certificate*
367 ServerKeyExchange*
368 CertificateRequest*
369 <-------- ServerHelloDone
370 Certificate*
371 ClientKeyExchange
372 CertificateVerify*
373 [ChangeCipherSpec]
374 Finished -------->
375 [ChangeCipherSpec]
376 <-------- Finished
377 Application Data <--------> Application Data
379 Fig. 1. Message flow for a full handshake
381 * Indicates optional or situation-dependent messages that are
382 not always sent.
385 There could be multiple TokenTransfer handshake messages, and the
386 last TokenTransfer message, if present, is always sent from the
387 client to the server and it can carry an empty token.
392 Zhu, et al. Expires January 26, 2008 [Page 7]
393 \f
394 Internet-Draft FKA-TLS July 2007
397 4. Choosing GSS-API Mechanisms
399 If more than one GSS-API mechanism is shared between the client and
400 the server, it is RECOMMENDED to deploy a pseudo GSS-API mechanism
401 such as [RFC4178] to choose a mutually preferred GSS-API mechanism.
403 When Kerberos is selected as the GSS-API mechanism, the extensions
404 defined in [KRB-ANON] can perform server authentication without
405 client authentication, thus provide the functional equivalence to the
406 certificate-based TLS [RFC4346].
408 If the Kerberos client does not have access to the KDC but the server
409 does, [IAKERB] can be chosen to tunnel the Kerberos authentication
410 exchange within the TLS handshake messages.
413 5. Client Authentication
415 If the GSS-API mechanism in the gss_api TLS extension provides client
416 authentication [RFC2743], the CertificateRequest, the client
417 Certificate and the CertificateVerify handshake messages MUST NOT be
418 present. This is illustrated in Appendix A.
421 6. Protecting GSS-API Authentication Data
423 GSS-API [RFC2743] provides security services to callers in a generic
424 fashion, supportable with a range of underlying mechanisms and
425 technologies and hence allowing source-level portability of
426 applications to different environments. For example, Kerberos is a
427 GSS-API mechanism defined in [RFC4121]. It is possible to design a
428 GSS-API mechanism that can be used with FKA-TLS in order to, for
429 example, provide client authentication, and is so weak that its GSS-
430 API token MUST NOT be in clear text over the open network. A good
431 example is a GSS-API mechanism that implements basic authentication.
432 Although such mechanisms are unlikely to be standardized and will be
433 encouraged in no circumstance, they exist for practical reasons. In
434 addition, it is generally beneficial to provide privacy protection
435 for mechanisms that send client identities in the clear.
437 In order to provide a standard way for protecting weak GSS-API data
438 for use over FKA-TLS, TLSWrap is defined in this section as a pseudo
439 GSS-API mechanism that wraps around the real GSS-API authentication
440 context establishment tokens. This pseudo GSS-API mechanism does not
441 provide per-message security. The real GSS-API mechanism protected
442 by TLSWrap may provide per-message security after the context is
443 established.
448 Zhu, et al. Expires January 26, 2008 [Page 8]
449 \f
450 Internet-Draft FKA-TLS July 2007
453 The syntax of the initial TLSWrap token follows the
454 initialContextToken syntax defined in Section 3.1 of [RFC2743]. The
455 TLSWrap pseudo mechanism is identified by the Object Identifier
456 iso.org.dod.internet.security.mechanism.tls-wrap (1.3.6.1.5.5.16).
457 Subsequent TLSWrap tokens MUST NOT be encapsulated in this GSS-API
458 generic token framing.
460 TLSWrap encapsulates the TLS handshake and data protection in its
461 context establishment tokens.
463 The innerContextToken [RFC2743] for the initial TLSWrap context token
464 contains the ClientHello message encoded according to [RFC4346]. No
465 PSK ciphersuite can be included in the client hello message. The
466 targ_name is used by the client to identify the server and it follows
467 the name forms defined in Section 4 of [PKU2U].
469 Upon receipt of the initial TLSWrap context token, the GSS-API server
470 processes the client hello message. The output GSS-API context token
471 for TLSWrap contains the ServerHello message and the ServerHelloDone
472 potentially with the optional handshake messages in the order as
473 defined in [RFC4346].
475 The GSS-API client then processes the server reply and returns the
476 ClientKeyExchange message and the Finished message potentially with
477 the optional handshake messages in the order as defined in [RFC4346].
478 The client places the real GSS-API authentication mechanism token as
479 an application data record right after the TLS Finished message in
480 the same GSS-API context token for TLSWrap. Because the real
481 mechanism token is placed after the ChangeCipherSpec message, the
482 GSS-API data for the real mechanism is encrypted. If the GSS-API
483 server is not authenticated at this point of the TLS handshake for
484 TLSWrap, the TLSWrap context establishment MUST fail and the real
485 authentication mechanism token MUST not be returned.
487 The GSS-API server in turn processes the client reply and returns the
488 TLS Finished message, the server places the reply token from the real
489 authentication mechanism, if present, as an application data record.
491 If additional TLS messages are needed before the application data,
492 these additional TLS messages are encapsulated in the context token
493 of TLSWrap in the same manner how the client hello message and the
494 server hello message are encapsulated as described above.
496 If additional tokens are required by the real authentication
497 mechanism in order to establish the context, these tokens are placed
498 as an application data record, encoded according to [RFC4346] and
499 then returned as TLSWrap GSS-API context tokens, with one TLSWrap
500 context token per each real mechanism context token. The real
504 Zhu, et al. Expires January 26, 2008 [Page 9]
505 \f
506 Internet-Draft FKA-TLS July 2007
509 mechanism context tokens are decrypted by TLSWrap and then supply to
510 the real mechanism to complete the context establishment.
513 7. Security Considerations
515 As described in Section 3, when the shared key is established using a
516 GSS-API mechanism as described in this document, the identity of the
517 server MUST be obtained from the GSS security context and the
518 identity of the client MUST be obtained from the GSS security
519 context. Authentication methods such as GSS security context and
520 X.509 certificate mixed MUST NOT conflict. Such confusion about the
521 identity will interfere with the ability to properly determine the
522 client's authorization privileges, thus potentially result in a
523 security weakness.
525 When Kerberos as defined in [RFC4120] is used to establish the share
526 key, it is vulnerable to offline dictionary attacks. The threat is
527 mitigated by deploying Kerberos FAST [KRB-FAST].
529 Shared symmetric keys obtained from mutual calls to
530 GSS_Pseudo_random() are not susceptible to off-line dictionary
531 attacks in the same way that traditional pre-shared keys are. The
532 strength of the generated keys are determined based upon the security
533 properties of the selected GSS mechanism. Implementers MUST take
534 into account the Security Considerations associated with the GSS
535 mechanisms they decide to support.
538 8. Acknowledgements
540 Ari Medvinsky was one of the designers of the original TLS Kerberos
541 version 5 CipherSuite and contributed to the first two revisions of
542 this protocol specification.
544 Raghu Malpani provided insightful comments and was very helpful along
545 the way.
547 Ryan Hurst contributed significantly to the use cases of FKA-TLS.
549 Love Hornquist Astrand, Nicolas Williams and Martin Rex provided
550 helpful comments while reviewing early revisions of this document.
553 9. IANA Considerations
555 A new handshake message token_transfer is defined according to
556 [RFC4346] and a new TLS extension called the gss_api extension is
560 Zhu, et al. Expires January 26, 2008 [Page 10]
561 \f
562 Internet-Draft FKA-TLS July 2007
565 defined according to [RFC3546]. The registry needs to be updated to
566 include these new types.
568 This document defines the type of the transfer tokens in Section 3, a
569 registry need to be setup and the allocation policy is "Specification
570 Required".
573 10. References
575 10.1. Normative References
577 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
578 Requirement Levels", BCP 14, RFC 2119, March 1997.
580 [RFC2743] Linn, J., "Generic Security Service Application Program
581 Interface Version 2, Update 1", RFC 2743, January 2000.
583 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
584 and T. Wright, "Transport Layer Security (TLS)
585 Extensions", RFC 3546, June 2003.
587 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
588 Simple and Protected Generic Security Service Application
589 Program Interface (GSS-API) Negotiation Mechanism",
590 RFC 4178, October 2005.
592 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
593 for Transport Layer Security (TLS)", RFC 4279,
594 December 2005.
596 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
597 (TLS) Protocol Version 1.1", RFC 4346, April 2006.
599 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API
600 Extension for the Generic Security Service Application
601 Program Interface (GSS-API)", RFC 4401, February 2006.
603 10.2. Informative References
605 [IAKERB] Zhu, L., "Initial and Pass Through Authentication Using
606 Kerberos V5 and the GSS-API", draft-zhu-ws-kerb-03.txt
607 (work in progress), 2007.
609 [KRB-ANON]
610 Zhu, L. and P. Leach, "Kerberos Anonymity Support",
611 draft-ietf-krb-wg-anon-04.txt (work in progress), 2007.
616 Zhu, et al. Expires January 26, 2008 [Page 11]
617 \f
618 Internet-Draft FKA-TLS July 2007
621 [KRB-FAST]
622 Zhu, L. and S. Hartman, "A Generalized Framework for
623 Kerberos Pre-Authentication",
624 draft-ietf-krb-wg-preauth-framework-06.txt (work in
625 progress), 2007.
627 [PKU2U] Zhu, L., Altman, J., and A. Medvinsky, "Public Key
628 Cryptography Based User-to-User Authentication - (PKU2U)",
629 draft-zhu-pku2u-02.txt (work in progress), 2007.
631 [RFC2487] Hoffman, P., "SMTP Service Extension for Secure SMTP over
632 TLS", RFC 2487, January 1999.
634 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
635 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
636 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
638 [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
639 Suites to Transport Layer Security (TLS)", RFC 2712,
640 October 1999.
642 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
643 A., Peterson, J., Sparks, R., Handley, M., and E.
644 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
645 June 2002.
647 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
648 Protocol (XMPP): Core", RFC 3920, October 2004.
650 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
651 Kerberos Network Authentication Service (V5)", RFC 4120,
652 July 2005.
654 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
655 Version 5 Generic Security Service Application Program
656 Interface (GSS-API) Mechanism: Version 2", RFC 4121,
657 July 2005.
659 [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the
660 Kerberos V Generic Security Service Application Program
661 Interface (GSS-API) Mechanism", RFC 4402, February 2006.
663 [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
664 (LDAP): Technical Specification Road Map", RFC 4510,
665 June 2006.
667 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial
668 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
672 Zhu, et al. Expires January 26, 2008 [Page 12]
673 \f
674 Internet-Draft FKA-TLS July 2007
677 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
678 Kerberos and NTLM HTTP Authentication in Microsoft
679 Windows", RFC 4559, June 2006.
682 Appendix A. An FKA-TLS Example: Kerberos TLS
684 This section provides a non-normative description of the message flow
685 when Kerberos Version 5 is used to established the shared secret
686 according to [RFC4121] and that shared secret is then used to secure
687 the TLS connection according to FKA-TLS defined in this document.
690 Client Server
692 ClientHello(with AP-REQ) -------->
693 ServerHello(with AP-REP)
694 <-------- ServerHelloDone
695 ClientKeyExchange
696 [ChangeCipherSpec]
697 Finished -------->
698 [ChangeCipherSpec]
699 <-------- Finished
700 Application Data <--------> Application Data
702 Fig. 2. Kerberos FKA-TLS example message flow
705 In this successful authentication sample, the TLS client sends the
706 Kerberos AP-REQ [RFC4120] in the inital context token according to
707 [RFC4121]. The initial GSS-API context token from the GSS-API client
708 contains the Object Identifier that signifies the Kerberos mechanism
709 and it is encapsulated in the gss_api TLS extension in the client
710 hello message. The TLS client always requests mutual authentication,
711 and the TLS server then sends a GSS-API context token that contains
712 the AP-REP [RFC4120] according to [RFC4121]. The TLS server's GSS-
713 API context token is encapsulated in the gss_api TLS extension in the
714 server hello message. The GSS-API context is established at that
715 point and both sides can derive the shared secret value according to
716 [RFC4402].
718 In this example, the ServerKeyExchange handshake message is not
719 needed and it is not present. And according to Section 5 none of the
720 CertificateRequest, the client Certificate or the CertificateVerify
721 handshake messages is present.
724 Appendix B. Additional Use Cases for FXA-TLS
726 TLS runs on layers beneath a wide range of application protocols such
730 Zhu, et al. Expires January 26, 2008 [Page 13]
731 \f
732 Internet-Draft FKA-TLS July 2007
735 as LDAP [RFC4510], SMTP [RFC2487], and XMPP [RFC3920] and above a
736 reliable transport protocol. TLS can add security to any protocol
737 that uses reliable connections (such as TCP). TLS is also
738 increasingly being used as the standard method for protecting SIP
739 [RFC3261] application signaling. TLS can provide authentication and
740 encryption of the SIP signaling associated with VOIP (Voice over IP)
741 and other SIP-based applications.
743 Today these applications use public key certificates to verify the
744 identity of endpoints.
746 However, it is overwhelmingly complex to manage the assurance level
747 of the certificates when deploying PKI and such complexity has
748 gradually eroded the confidence for the PKI-based systems in general.
749 In addition, the perceived overhead of deploying and managing
750 certificates is fairly high. As a result, the industry badly needs
751 the ability to secure TLS connections by leveraging the existing
752 credential infrastructure. For many customers that means Kerberos.
753 It is highly desirable to enable PKI-less deployments yet still offer
754 strong authentication.
756 Having Kerberos/GSS-API in the layer above TLS means all TLS
757 applications need to be changed in the protocol level. In many
758 cases, such changes are not technically feasible. For example,
759 [RFC4559] provides integration with Kerberos in the HTTP level. It
760 suffers from a couple of drawbacks, most notably it only supports
761 single-round-trip GSS-API mechanisms and it lacks of channel bindings
762 to the underlying TLS connection which makes in unsuitable for
763 deployment in situations where proxies exists. Furthermore,
764 [RFC4559] lacks of session-based re-authentication (comparing with
765 TLS). The root causes of these problems are inherent to the HTTP
766 protocol and can't be fixed trivially.
768 Consequently, It is a better solution to integrate Kerberos/GSS-API
769 in the TLS layer. Such integration allows the existing
770 infrastructure work seamlessly with TLS for the products based on
771 them in ways that were not practical to do before. For instance, an
772 increasing number of client and server products support TLS natively,
773 but many still lack support. As an alternative, users may wish to
774 use standalone TLS products that rely on being able to obtain a TLS
775 connection immediately, by simply connecting to a separate port
776 reserved for the purpose. For example, by default the TCP port for
777 HTTPS is 443, to distinguish it from HTTP on port 80. TLS can also
778 be used to tunnel an entire network stack to create a VPN, as is the
779 case with OpenVPN. Many vendors now marry TLS's encryption and
780 authentication capabilities with authorization. There has also been
781 substantial development since the late 1990s in creating client
782 technology outside of the browser to enable support for client/server
786 Zhu, et al. Expires January 26, 2008 [Page 14]
787 \f
788 Internet-Draft FKA-TLS July 2007
791 applications. When compared against traditional IPSec VPN
792 technologies, TLS has some inherent advantages in firewall and NAT
793 traversal that make it easier to administer for large remote-access
794 populations.
796 PSK-TLS as defined in [RFC4279] is a good start but this document
797 finishes the job by making it more deployable. FKA-TLS also fixes
798 the mutual-authentication problem in [RFC4279] in the cases where the
799 PSK can be shared among services on the same host.
802 Authors' Addresses
804 Larry Zhu
805 Microsoft Corporation
806 One Microsoft Way
807 Redmond, WA 98052
808 US
810 Email: lzhu@microsoft.com
813 Girish Chander
814 Microsoft Corporation
815 One Microsoft Way
816 Redmond, WA 98052
817 US
819 Email: gchander@microsoft.com
822 Jeffrey Altman
823 Secure Endpoints Inc.
824 255 W 94th St
825 New York, NY 10025
826 US
828 Email: jaltman@secure-endpoints.com
831 Stefan Santesson
832 Microsoft Corporation
833 Tuborg Boulevard 12
834 2900 Hellerup, WA
835 Denmark
837 Email: stefans@microsoft.com
842 Zhu, et al. Expires January 26, 2008 [Page 15]
843 \f
844 Internet-Draft FKA-TLS July 2007
847 Full Copyright Statement
849 Copyright (C) The IETF Trust (2007).
851 This document is subject to the rights, licenses and restrictions
852 contained in BCP 78, and except as set forth therein, the authors
853 retain all their rights.
855 This document and the information contained herein are provided on an
856 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
857 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
858 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
859 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
860 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
861 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
864 Intellectual Property
866 The IETF takes no position regarding the validity or scope of any
867 Intellectual Property Rights or other rights that might be claimed to
868 pertain to the implementation or use of the technology described in
869 this document or the extent to which any license under such rights
870 might or might not be available; nor does it represent that it has
871 made any independent effort to identify any such rights. Information
872 on the procedures with respect to rights in RFC documents can be
873 found in BCP 78 and BCP 79.
875 Copies of IPR disclosures made to the IETF Secretariat and any
876 assurances of licenses to be made available, or the result of an
877 attempt made to obtain a general license or permission for the use of
878 such proprietary rights by implementers or users of this
879 specification can be obtained from the IETF on-line IPR repository at
880 http://www.ietf.org/ipr.
882 The IETF invites any interested party to bring to its attention any
883 copyrights, patents or patent applications, or other proprietary
884 rights that may cover technology that may be required to implement
885 this standard. Please address the information to the IETF at
886 ietf-ipr@ietf.org.
889 Acknowledgment
891 Funding for the RFC Editor function is provided by the IETF
892 Administrative Support Activity (IASA).
898 Zhu, et al. Expires January 26, 2008 [Page 16]
899 \f