|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
## TLSwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: May 12, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
##
## TLSwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
##
## TLSwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
| The charter of the TLS working group -- updated on Jan 11, 2006 --
is reported below.
|
|
|
|
The TLS Working Group was established in 1996 to standardize a
'transport layer' security protocol. The working group began with SSL
version 3.0. The TLS Working Group has completed a series of
specifications that describe the Transport Layer Security protocol
versions 1.0 and 1.1, extensions to the protocol, and new
ciphersuites to be used with TLS.
The primary goal of the WG is to publish a revision of TLS, version
1.2, that removes the protocol's dependency on the MD5 and SHA-1 digest
algorithms, which have been either wholly or partially compromised by
recent research. The TLS WG will also work on new authenticated
encryption modes for TLS, including modes based on counter mode
encryption (CTR) and combined encryption/authentication modes, and
may define major new cipher suites for TLS for this purpose. In the
preparation of TLS 1.2, the WG will attempt to avoid gratuitous
changes to TLS 1.1.
|
|
|
|
|
|
|
|
##
## TLSwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
RFC2712
10/1999
(7 p.)
[html]
[pdf(2)] |
A. Medvinsky
M. Hur |
|
Addition of Kerberos Cipher Suites to TLS |
|
This document proposes the addition of new cipher suites to the TLS
protocol 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.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC2817
05/2000
(13 p.)
[html]
[pdf(2)] |
R. Khare
S. Lawrence |
|
Upgrading to TLS Within HTTP/1.1 |
This memo explains how to use the Upgrade mechanism in HTTP/1.1 to
initiate Transport Layer Security (TLS) over an existing TCP
connection. This allows unsecured and secured HTTP traffic to share
the same well known port (in this case, http: at 80 rather than
https: at 443). It also enables "virtual hosting", so a single HTTP +
TLS server can disambiguate traffic intended for several hostnames at
a single IP address.
Since HTTP/1.1 defines Upgrade as a hop-by-hop mechanism, this
memo also documents the HTTP CONNECT method for establishing end-to-
end tunnels across HTTP proxies. Finally, this memo establishes new
IANA registries for public HTTP status codes, as well as public or
private Upgrade product tokens.
This memo does NOT affect the current definition of the 'https' URI
scheme, which already defines a separate namespace
(http://example.org/ and https://example.org/ are not equivalent).
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC2818
05/2000
(7 p.)
[html]
[pdf(2)] |
E. Rescorla |
|
HTTP Over TLS |
|
This memo describes how to use TLS to secure HTTP connections over
the Internet. Current practice is to layer HTTP over SSL (the
predecessor 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
[RFC 2817].
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC3268
06/2002
(7 p.)
[html]
[pdf(2)] |
P. Chown |
|
Advanced Encryption Standard (AES) Ciphersuites for TLS |
|
This document proposes several new ciphersuites. At present, the
symmetric ciphers supported by Transport Layer Security (TLS) are
RC2, RC4, International Data Encryption Algorithm (IDEA), Data
Encryption Standard (DES), and triple DES. The protocol would be
enhanced by the addition of Advanced Encryption Standard (AES)
ciphersuites.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3749
05/2004
(8 p.)
[html]
[pdf(2)] |
S. Hollenbeck |
|
Transport Layer Security Protocol Compression Methods |
|
The Transport Layer Security (TLS) protocol includes
features to negotiate selection of a lossless data compression method
as part of the TLS Handshake Protocol and to then apply the algorithm
associated with the selected method as part of the TLS Record
Protocol. TLS defines one standard compression method which
specifies that data exchanged via the record protocol will not be
compressed. This document describes an additional compression method
associated with a lossless data compression algorithm for use with
TLS, and it describes a method for the specification of additional
TLS compression methods.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC3943
11/2004
(13 p.)
[html]
[pdf(2)] |
R. Friend |
|
TLS Protocol Compression Using Lempel-Ziv-Stac (LZS) |
|
The Transport Layer Security (TLS) protocol includes
features to negotiate selection of a lossless data compression method
as part of the TLS Handshake Protocol and then to apply the algorithm
associated with the selected method as part of the TLS Record
Protocol. TLS defines one standard compression method, which
specifies that data exchanged via the record protocol will not be
compressed. This document describes an additional compression method
associated with the Lempel-Ziv-Stac (LZS) lossless data compression
algorithm for use with TLS. This document also defines the
application of the LZS algorithm to the TLS Record Protocol.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4162
08/2005
(6 p.)
[html]
[pdf(2)] |
H.J. Lee
J.H. Yoon
J.I. Lee |
|
Addition of SEED Cipher Suites to TLS |
|
This document proposes the addition of new cipher suites to the
Transport Layer Security (TLS) protocol to support the SEED
encryption algorithm as a bulk cipher algorithm.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4279
12/2005
(15 p.)
[html]
[pdf(2)] |
P. Eronen
H. Tschofenig |
|
Pre-Shared Key Ciphersuites for TLS |
|
This document specifies three sets of new ciphersuites for the
Transport Layer Security (TLS) protocol to support authentication
based on pre-shared keys (PSKs). These pre-shared keys are symmetric
keys, shared in advance among the communicating parties. The first
set of ciphersuites uses only symmetric key operations for
authentication. The second set uses a Diffie-Hellman exchange
authenticated with a pre-shared key, and the third set combines
public key authentication of the server with pre-shared key
authentication of the client.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC4346
04/2006
(87 p.)
[html]
[pdf(2)] |
T. Dierks
E. Rescorla |
|
The Transport Layer Security (TLS) Protocol Version 1.1 |
|
This document specifies Version 1.1 of the Transport Layer Security
(TLS) protocol. The TLS protocol provides communications security
over the Internet. The protocol allows client/server applications to
communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4366
04/2006
(30 p.)
[html]
[pdf(2)] |
S. Blake-Wilson
M. Nystrom
D. Hopwood
J. Mikkelsen
T. Wright |
|
Transport Layer Security (TLS) Extensions |
This document describes extensions that may be used to add
functionality to Transport Layer Security (TLS). It provides both
generic extension mechanisms for the TLS handshake client and server
hellos, and specific extensions using these generic mechanisms.
The extensions may be used by TLS clients and servers. The
extensions are backwards compatible: communication is possible
between TLS clients that support the extensions and TLS servers that
do not support the extensions, and vice versa.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4492
05/2006
(35 p.)
[html]
[pdf(2)] |
S. Blake-Wilson
N. Bolyard
V. Gupta
C. Hawk
B. Moeller |
|
Elliptic Curve Cryptography (ECC) Cipher Suites for TLS |
|
This document describes new key exchange algorithms based on Elliptic
Curve Cryptography (ECC) for the Transport Layer Security (TLS)
protocol. In particular, it specifies the use of Elliptic Curve
Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of
Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
authentication mechanism.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4680
09/2006
(9 p.)
[html]
[pdf(2)] |
S. Santesson |
|
TLS Handshake Message for Supplemental Data |
|
This specification defines a TLS handshake message for exchange of
supplemental application data. TLS hello message extensions are used
to determine which supplemental data types are supported by both the
TLS client and the TLS server. Then, the supplemental data handshake
message is used to exchange the data. Other documents will define
the syntax of these extensions and the syntax of the associated
supplemental data types.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4681
10/2006
(11 p.)
[html]
[pdf(2)] |
S. Santesson
A. Medvinsky
J. Ball |
|
TLS User Mapping Extension |
|
This document specifies a TLS extension that enables clients to send
generic user mapping hints in a supplemental data handshake message
defined in RFC 4680. One such mapping hint is defined in an
informative section, the UpnDomainHint, which may be used by a server
to locate a user in a directory database. Other mapping hints may be
defined in other documents in the future.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4785
01/2007
(5 p.)
[html]
[pdf(2)] |
U. Blumenthal
P. Goel |
|
Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for TLS |
|
This document specifies authentication-only ciphersuites (with no
encryption) for the Pre-Shared Key (PSK) based Transport Layer
Security (TLS) protocol. These ciphersuites are useful when
authentication and integrity protection is desired, but
confidentiality is not needed or not permitted.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC5077
01/2008
(20 p.)
[html]
[pdf(2)] |
J. Salowey
H. Zhou
P. Eronen
H. Tschofenig |
|
TLS Session Resumption without Server-Side State |
|
This document describes a mechanism that enables the Transport Layer
Security (TLS) server to resume sessions and avoid keeping per-client
session state. The TLS server encapsulates the session state into a
ticket and forwards it to the client. The client can subsequently
resume a session using the obtained ticket. This document obsoletes
RFC 4507.
|
|
|
| |
| Up List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
| | |
RFC5081
11/2007
(8 p.)
[html]
[pdf(2)] |
N. Mavrogian-
nopoulos |
|
Using OpenPGP Keys for TLS Authentication |
|
This memo proposes extensions to the Transport Layer Security (TLS)
protocol to support the OpenPGP key format. The extensions discussed
here include a certificate type negotiation mechanism, and the
required modifications to the TLS Handshake Protocol.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
##
## TLSwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
##
## TLSwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Experimental |
|
|
|
|
|
|
|
|
|
|
|
|
##
## TLSwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
tls-des-idea-01
ID Exists
Mar 10, 2008
(6 p.)
[pdf(2)]
[html]
|
P. Eronen |
|
DES and IDEA Cipher Suites for Transport Layer Security (TLS) |
|
TLS specification versions 1.0 (RFC 2246) and 1.1 (RFC 4346) included
cipher suites based on DES (Data Encryption Standard) and IDEA
(International Data Encryption Algorithm) algorithms. DES (when used
in single-DES mode) and IDEA are no longer recommended for general
use in TLS, and have been removed from TLS 1.2 main specification
(RFC NNNN). This document specifies these cipher suites for
completeness, and discusses reasons why their use is no longer
recommended.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
tls-rsa-aes-gcm-03
ID Exists
Apr 14, 2008
(9 p.)
[pdf(2)]
[html]
|
J. Salowey
A. Choudhury
D. McGrew |
|
RSA based AES-GCM Cipher Suites for TLS |
|
This memo describes the use of the Advanced Encryption Standard (AES)
in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS)
authenticated encryption operation. GCM provides both
confidentiality and data origin authentication, can be efficiently
implemented in hardware for speeds of 10 gigabits per second and
above, and is also well-suited to software implementations. This
memo defines TLS ciphersuites that use AES-GCM with RSA, DSS and
Diffie-Hellman based key exchange mechanisms.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
##
## TLSwg
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
hajjeh-tls-identity-
protection-05
ID Exists
Apr 3, 2008
(22 p.)
[pdf(2)]
[html]
|
I. Hajjeh
M. Badra |
|
Credential Protection Ciphersuites for Transport Layer Security |
The Transport Layer Security (TLS) supports three authentication
modes: authentication of both parties, server authentication with an
unauthenticated client, and total anonymity. For each mode, TLS
specifies a set of cipher suites. Whenever the server is
authenticated, the channel is secure against man-in-the-middle
attacks, but completely anonymous sessions are inherently vulnerable
to such attacks.
The authentication is usually based on either preshared keys or
public key certificates. If a public key certificate is used to
authenticate the TLS client during the TLS Handshake, the TLS client
credentials are sent in clear text over the wire. Thus, any observer
can determine the credentials used by the client, learn who is
reaching the network, when, and from where, and hence correlate the
client credentials to the connection location.
This document defines a set of cipher suites to add client credential
protection to the TLS protocol. This is useful especially if TLS is
used in wireless environments or to secure remote access.
|
|
|
| |
| Up List |
Intended Status: | Experimental |
|
|
|
|
|
|
|
|
| | |
hajjeh-tls-
sign-04
ID Exists
Dec 15, 2007
(12 p.)
[pdf(2)]
[html]
|
I. Hajjeh
M. Badra |
|
TLS Sign |
|
TLS protocol provides authentication and data protection for
communication between two entities. However, missing from the
protocol is a way to perform non-repudiation service.
This document defines extensions to the TLS protocol to allow it to
perform non-repudiation service. It is based on [TLSSIGN] and it
provides the client and the server the ability to sign by TLS,
handshake and applications data using certificates such as X.509.
|
|
|
| |
| Up List |
Intended Status: | Experimental |
|
|
|
|
|
|
|
|
| | |
harkins-tls-
rsa-aes-siv-00
ID Exists
Dec 15, 2007
(12 p.)
[pdf(2)]
[html]
|
D. Harkins |
|
RSA AES-SIV Ciphersuites for TLS |
|
This memo describes two new ciphersuites for the Transport Layer
Security (TLS) protocol using the Advanced Encryption Standard (AES)
in Synthetic IV (SIV) mode. SIV provides authenticated encryption
with associated data (AEAD) and, unlike other AEAD cipher modes,
provides resistance to nonce misuse.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
keromytis-tls-
authz-keynote-00
ID Exists
Mar 28, 2008
(4 p.)
[pdf(2)]
[html]
|
A. D. Keromytis |
|
Transport Layer Security (TLS) Authorization Using KeyNote |
|
This document specifies the use of the KeyNote trust-management
system as an authorization extension in the Transport Layer
Security (TLS) Handshake Protocol, according to [AUTHZ].
Extensions carried in the client and server hello messages
confirm that both parties support the desired authorization
data types. Then, if supported by both the client and the
server, KeyNote credentials are exchanged during the
supplemental data handshake message.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
nir-tls-eap-03
ID Exists
Apr 4, 2008
(21 p.)
[pdf(2)]
[html]
|
Y. Nir
Y. Sheffer
H. Tschofenig
P. Gutmann |
|
TLS using EAP Authentication |
This document describes an extension to the TLS protocol to allow TLS
clients to authenticate with legacy credentials using the Extensible
Authentication Protocol (EAP).
This work follows the example of IKEv2, where EAP has been added to
the IKEv2 protocol to allow clients to use different credentials such
as passwords, token cards, and shared secrets.
When TLS is used with EAP, additional records are sent after the
ChangeCipherSpec protocol message and before the Finished message,
effectively creating an extended handshake before the application
layer data can be sent. Each EapMsg handshake record contains
exactly one EAP message. Using EAP for client authentication allows
TLS to be used with various AAA back-end servers such as RADIUS or
Diameter.
TLS with EAP may be used for securing a data connection such as HTTP
or POP3. We believe it has three main benefits:
| |
| o |
The ability of EAP to work with backend servers can remove that
burden from the application layer.
|
| |
| o |
Moving the user authentication into the TLS handshake protects the
presumably less secure application layer from attacks by
unauthenticated parties.
| | |
| o |
Using mutual authentication methods within EAP can help thwart
certain classes of phishing attacks.
|
| |
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
rescorla-tls-
suiteb-02
ID Exists
Apr 14, 2008
(8 p.)
[pdf(2)]
[html]
|
M. Salter
E. Rescorla |
|
Suite B Cipher Suites for TLS |
|
The United States Government has published guidelines for "NSA Suite
B Cryptography" dated July, 2005, which defines cryptographic
algorithm polcy for national security applications. This document
defines a profile of TLS which is conformant with Suite B.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
