Skip to main content

TLS Extension for Optimizing Application Protocols, Specifically SASL with GSS-API mechanisms
draft-williams-tls-app-sasl-opt-04

Document Type Expired Internet-Draft (individual)
Expired & archived
Author Nicolás Williams
Last updated 2010-07-26
RFC stream (None)
Intended RFC status (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

This document specifies Hello extensions to Transport Layer Security (TLS). One extension is used for carrying application data which is suitable for delayed integrity protection and does not require privacy protection. Another extension is used to negotiate an early start to the application data protocol in the case of initial TLS connections (i.e., which do not resume sessions). We describe how to use these extensions to reduce the number of round trips needed for application-layer authentication, by piggy-backing Simple Authentication (SASL) mechanism negotiation on the first leg of a TLS handshake and the first round of SASL authentication messages on the second leg of the same TLS handshake. Through SASL we get support for Generic Security Services (GSS-API) mechanisms. Channel binding is used from SASL authentication to the TLS channel. This results in a two round-trip optimization for applications that use SASL on top of TLS. We also provide generic framing for SASL authentication messages which, combined with the use of these extensions, will be referred to as "TLS/SA". These extensions can also be used to optimize application protocols separately from SASL.

Authors

Nicolás Williams

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)