@techreport{williams-tls-app-sasl-opt-04,
    number =    {draft-williams-tls-app-sasl-opt-04},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-williams-tls-app-sasl-opt/04/},
    author =    {Nicolás Williams},
    title =     {{TLS Extension for Optimizing Application Protocols, Specifically SASL with GSS-API mechanisms}},
    pagetotal = 27,
    year =      2010,
    month =     jul,
    day =       26,
    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.},
}