Internet Drafts related to TLS

Internet Drafts related to TLS
(as of 26 March 1998)
[Thanks to  Chris Allen for compiling earlier lists.]

The following drafts are under consideration by the TLS
working group. The IETF Secretariat's up-to-date list of such
drafts is at http://www.ietf.org/ids.by.wg/tls.html

"Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", M. Hur, A. Medvinsky, 02/25/1998.
ftp://ietf.org/internet-drafts/draft-ietf-tls-kerb-cipher-suites-02.txt

    This document proposes the addition of new cipher suites
    to the TLS protocol [1] to support Kerberos-based
    authentication. Kerberos credentials are used to achieve
    mutual authentication and to establish a master secret
    which is subsequently used to secure client-server
    communication.

"The TLS Protocol Version 1.0", C. Allen, T. Dierks, 11/13/1997.
ftp://ietf.org/internet-drafts/draft-ietf-tls-protocol-05.txt

    This document specifies Version 1.0 of the Transport
    Layer Security (TLS) protocol. The TLS protocol provides
    communications privacy over the Internet. The protocol
    allows client/server applications to communicate in a way
    that is designed to prevent eavesdropping, tampering, or
    message forgery. 
    
"HTTP Over TLS", E. Rescorla, 03/13/1998.
ftp://ietf.org/internet-drafts/draft-ietf-tls-https-01.txt
    
    This memo describes how to use TLS to secure HTTP
    connections over the Internet. Current practice is to
    layer HTTP over SSL (the prede- cessor to TLS),
    distinguishing secured traffic from insecure traffic by
    the use of a different server port. This document
    documents that practice using TLS. A companion document
    describes a method for using HTTP/TLS over the same port
    as normal HTTP. 
    
    
"TLS extensions for AttributeCertificate based authorization", S. Farrell,
    03/02/1998.
ftp://ietf.org/internet-drafts/draft-ietf-tls-attr-cert-00.txt

    Authorization support is required for various internet
    protocols including TLS (and its cosumers), IPSEC and
    others. This document presents requirements for providing
    such support as well as an outline specification for
    AttributeCertificate based authorization as an extension
    to the TLS protocol. Future versions of this
    specification will define an encoding for the data
    structures required (ASN.1 or not) and will refine the
    description of the use AttributeCertificates in the TLS
    protocol. 
    
"ECC Cipher Suites For TLS", T. Dierks, Bill Anderson, 03/16/1998.
ftp://ietf.org/internet-drafts/draft-ietf-tls-ecc-00.txt

    This document describes additions to TLS to support the
    Elliptic Curve Cryptosystem (ECC). The document assumes
    that the reader is familiar with the TLS protocol. The
    document defines cipher suites which use the Elliptic
    Curve Encryption Scheme (ECES), the Elliptic Curve
    Digital Signature Algorithm (ECDSA), the Elliptic Curve
    Nyberg-Rueppel Signature Scheme with Appendix (ECNRA),
    the Elliptic Curve Diffie-Hellman Key Agreement (ECDH),
    and the Elliptic Curve Menezes-Qu-Vanstone Key Agreement
    (ECMQV) key establishment algorithms. References to these
    algorithms can be found in section 13. 

Drafts Referring to TLS
    
"Tunneling TCP based protocols through Web proxy servers", A. Luotonen,
    02/25/1998.
ftp://ietf.org/internet-drafts/draft-luotonen-web-proxy-tunneling-00.txt

    This document specifies a generic tunneling mechanism for
    TCP based protocols through Web proxy servers. This
    tunneling mechanism was initially introduced for the SSL
    protocol [SSL] to allow secure Web traffic to pass
    through firewalls, but its utility is not limited to SSL.
    Earlier drafts of this specification were titled
    ''Tunneling SSL through Web Proxy Servers".
    Implementations of this tunneling feature are commonly
    referred to as ''SSL tunneling'', although, again, it can
    be used for tunneling any TCP based protocol. A wide
    variety of existing client and proxy server
    implementations conform to this specification. The
    purpose of this specification is to describe the current
    practice, to propose some good practices for implementing
    this specification, and to document the security
    considerations that are involved with this protocol. 

"Lightweight Directory Access Protocol (v3): Extension for Transport
    Layer Security", B. Morgan, J. Hodges, M. Wahl, 03/12/1998.
ftp://ietf.org/internet-drafts/draft-ietf-ldapext-ldapv3-tls-00.txt

    This document defines the ''Start Transport Layer
    Security (TLS) Opera- tion'' for LDAP [LDAPv3, TLS]. This
    operation provides for TLS establish- ment in an LDAP
    association and is defined in terms of an LDAP extended
    request. 

"Securing FTP with TLS", E. Murray, P. Ford-Hutchinson, T. Hudson,
    Martin Carpenter, 01/29/1998.
ftp://ietf.org/internet-drafts/draft-murray-auth-ftp-ssl-03.txt

    This document describes a mechanism that can be used by
    FTP clients and servers to implement security and
    authentication using the TLS protocol defined by the IETF
    TLS working group and the extensions to the FTP protocol
    defined by the IETF CAT working group. It describes the
    subset of the extensions that are required and the
    parameters to be used; discusses some of the policy
    issues that clients and servers will need to take;
    considers some of the implications of those policies and
    discusses some expected behaviours of implementations to
    allow interoperation. TLS is not the only mechanism for
    securing file transfer, however it does offer some of the
    following positive attributes:- - Flexible security
    levels. TLS can support privacy, integrity,
    authentication or some combination of all of these. This
    allows clients and servers to dynamically, during a
    session, decide on the level of security required for a
    particular data transfer, - Formalised public key
    management. By use of X.509 public certificates during
    the authentication phase, certificate management can be
    built into a central function. Whilst this may not be
    desirable for all uses of secured file transfer, it
    offers advantages in certain structured environments such
    as access to corporate data sources. - Co-existence and
    interoperation with authentication mechanisms that are
    already in place for the HTTPS protocol. This allows web
    browsers to incorporate secure file transfer using the
    same infrastructure that has been set up to allow secure
    web browsing. The TLS protocol is a development of the
    Netscape Communication Corporation's SSL protocol and
    this document can be used to allow the FTP protocol to be
    used with either SSL or TLS. The actual protocol used
    will be decided by the negotiation of the protected
    session.

"SMTP Service Extension for Secure SMTP over TLS", Paul Hoffman, 11/17/1997.
ftp://ietf.org/internet-drafts/draft-hoffman-smtp-ssl-05.txt

    This document describes an extension to the SMTP service
    that allows an SMTP server and client to use
    transport-layer security to provide private,
    authenticated communication over the Internet. This gives
    SMTP agents the ability to protect some or all of their
    communications from eavesdroppers and attackers. 

"Firewall Traversal authorization system", M. Richardson, K. Martius,
    07/10/1997.
ftp://ietf.org/internet-drafts/draft-richardson-ipsec-traversal-01.txt

    This document describes a public key certificate
    mechanism to authorize traversal of multiple security
    gateways (firewalls). This work is independant of
    transport layer in concept, and could apply to IPsec,
    TLS, or SecSH. It is applied here to IPsec. The SPKI
    certificate format is used here. 

"Using TLS with IMAP4, POP3 and ACAP", Chris Newman, 03/10/1998.
ftp://ietf.org/internet-drafts/draft-newman-tls-imappop-03.txt

    The TLS protocol [TLS] (formerly known as SSL) provides a
    way to secure a connection from tampering and
    evesdropping. Obviously, the option of using such
    security is desirable for IMAP [IMAP4], POP [POP3] and
    ACAP [ACAP]. Although advanced SASL [SASL] authentication
    mechanisms can provide a lightweight version of this
    service, TLS is a full service security layer and is also
    useful in combination with plaintext password logins and
    other simple mechanisms as it doesn't require a site to
    upgrade its authentication database. This specification
    defines extensions to IMAP4, ACAP and POP3 which activate
    TLS. It also defines a set of server security policy
    response codes for use with IMAP4. The response codes MAY
    be used independently of the TLS extension. Finally, this
    defines a simple PLAIN SASL mechanism for use underneath
    strong TLS encryption with ACAP. [NOTE: Public discussion
    of this mechanism may take place on the
    [email protected] mailing list with a subscription
    address of [email protected]. Private
    comments may be sent to the author]. 

"PPP EAP TLS Authentication Protocol", B. Aboba, D. Simon, 10/21/1997.
ftp://ietf.org/internet-drafts/draft-ietf-pppext-eaptls-02.txt

    The Point-to-Point Protocol (PPP) provides a standard
    method for transporting multi-protocol datagrams over
    point-to-point links. PPP also defines an extensible Link
    Control Protocol (LCP), which can be used to negotiate
    authentication methods, as well as an Encryption Control
    Protocol (ECP), used to negotiate data encryption over
    PPP links, and a Compression Control Protocol (CCP), used
    to negotiate compression methods. The Extensible
    Authentication Protocol (EAP) is a PPP extension that
    provides support for additional authentication methods
    within PPP. Transport Level Security (TLS) provides for
    mutual authentication, integrity-protected ciphersuite
    negotiation and key exchange between two endpoints. This
    document describes how EAP-TLS, which includes support
    for fragmentation and reassembly, provides for these TLS
    mechanisms within EAP. 

"TLS-based Telnet Security", Michael Boe, 12/30/1997. 
ftp://ietf.org/internet-drafts/draft-ietf-tn3270e-telnet-tls-00.txt

    Telnet service has long been a standard Internet
    protocol. However, a standard way of ensuring privacy and
    integrity of Telnet sessions has been lacking. This
    document proposes a standard method for Telnet servers
    and clients to use the Transport Layer Security (TLS)
    protocol. It describes how two Telnet participants can
    decide whether or not to attempt TLS negotiation, and how
    the two participants should process authentication
    credentials exchanged as a part of TLS startup. 
    
"Secure Sockets Layer for SOCKS Version 5", M. VanHeyningen, 03/20/1997.
ftp://ietf.org/internet-drafts/draft-ietf-aft-socks-ssl-00.txt

    This document specifies the use of SSL 3.0 and possible
    successor protocols as an authentication method for SOCKS
    Version 5. The design is similar to, and largely derived
    from, the integration of GSS-API into SOCKS5 [RFC 1961].
    A framework is provided for future extensions, and the
    use of other 'subauthentication' methods inside SSL is
    supported.