view Side-By-Side changes
Tim Dierks
Independent
Eric Rescorla
INTERNET-DRAFT Network Resonance, Inc.
<draft-ietf-tls-rfc4346-bis-02.txt> October 2006
<draft-ietf-tls-rfc4346-bis-03.txt> March 2007 (Expires April 2006) September 2007)
The TLS Protocol
Version 1.2
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2006). IETF Trust (2007).
Abstract
This document specifies Version 1.2 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.
Table of Contents
1. Introduction 4 3
1.1 Requirements Terminology 4
1.2 Major Differences from TLS 1.1 5
1.1 Requirements Terminology 5
Dierks & Rescorla Standards Track [Page 1] draft-ietf-tls-rfc4346-bis-02.txt draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006 March 2007
2. Goals 5
3. Goals of this document This Document 6
4. Presentation language Language 6
4.1. Basic block size 7 Block Size 6
4.2. Miscellaneous 7
4.3. Vectors 7
4.4. Numbers 8
4.5. Enumerateds 8
4.6. Constructed types Types 9
4.6.1. Variants 10 9
4.7. Cryptographic attributes 11 Attributes 10
4.8. Constants 12
5. HMAC and the pseudorandom function Pseudorandom fFunction 12
6. The TLS Record Protocol 14
6.1. Connection states States 14
6.2. Record layer 17
6.2.1. Fragmentation 17
6.2.2. Record compression Compression and decompression Decompression 18
6.2.3. Record payload protection Payload Protection 19
6.2.3.1. Null or standard stream cipher Standard Stream Cipher 19
6.2.3.2. CBC block cipher Block Cipher 20
6.2.3.3. AEAD ciphers 23 22
6.3. Key calculation 24 Calculation 23
7. The TLS Handshaking Protocols 24
7.1. Change cipher spec protocol Cipher Spec Protocol 25
7.2. Alert protocol 26 Protocol 25
7.2.1. Closure alerts 27 Alerts 26
7.2.2. Error alerts 28 Alerts 27
7.3. Handshake Protocol overview 31 Overview 30
7.4. Handshake protocol 35 Protocol 34
7.4.1. Hello messages 36 Messages 35
7.4.1.1. Hello request 36 Request 35
7.4.1.2. Client hello 37 Hello 36
7.4.1.3. Server hello 40 Hello 39
7.4.1.4 Hello Extensions 41 40
7.4.1.4.1 Server Name Indication 43
7.4.1.4.2 Maximum Fragment Length Negotiation 44
7.4.1.4.3 Client Certificate URLs 46
7.4.1.4.4 Trusted CA Indication 46
7.4.1.4.5 Truncated HMAC 48
7.4.1.4.6 Certificate Status Request 49
7.4.1.4.7 Cert Hash Types 50
7.4.1.4.8 Procedure for Defining New Extensions 51 42
7.4.2. Server certificate 52 Certificate 42
7.4.3. Server key exchange message 53 Key Exchange Message 44
7.4.4. CertificateStatus 56
7.4.5. Certificate request 56
7.4.6. Request 46
7.4.5 Server hello done 58
Dierks & Rescorla Standards Track [Page 2] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
7.4.7. Client certificate 59
7.4.8. 47
7.4.6. Client Certificate URLs 59
7.4.9. 48
7.4.7. Client key exchange message 61
7.4.9.1. Key Exchange Message 48
7.4.7.1. RSA encrypted premaster secret message 62
7.4.9.2. Encrypted Premaster Secret Message 49
7.4.7.1. Client Diffie-Hellman public value 64
7.4.10. Public Value 51
7.4.8. Certificate verify 65
7.4.10. 52
7.4.9. Finished 65 52
8. Cryptographic computations 66 Computations 53
8.1. Computing the master secret 67 Master Secret 54
Dierks & Rescorla Standards Track [Page 2] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
8.1.1. RSA 67 54
8.1.2. Diffie-Hellman 67 54
9. Mandatory Cipher Suites 67 54
A. Protocol constant values 71 Constant Values 58
A.1. Record layer 71 Layer 58
A.2. Change cipher specs message 72 Cipher Specs Message 59
A.3. Alert messages 72 Messages 59
A.4. Handshake protocol 74 Protocol 61
A.4.1. Hello messages 74 Messages 61
A.4.2. Server authentication Authentication and key exchange messages 77 Key Exchange Messages 62
A.4.3. Client authentication Authentication and key exchange messages 78 Key Exchange Messages 63
A.4.4. Handshake finalization message 79 Finalization Message 64
A.5. The CipherSuite 80 64
A.6. The Security Parameters 83 67
B. Glossary 84 69
C. CipherSuite definitions 88 Definitions 73
D. Implementation Notes 90 75
D.1 Random Number Generation and Seeding 90 75
D.2 Certificates and authentication 90 Authentication 75
D.3 CipherSuites 90 75
E. Backward Compatibility 91
E.1. Version 2 client hello 92
E.2. Avoiding man-in-the-middle version rollback 93 76
E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 76
E.2 Compatibility with SSL 2.0 77
E.2. Avoiding Man-in-the-Middle Version Rollback 79
F. Security analysis 95 Analysis 80
F.1. Handshake protocol 95 Protocol 80
F.1.1. Authentication and key exchange 95 Key Exchange 80
F.1.1.1. Anonymous key exchange 95 Key Exchange 80
F.1.1.2. RSA key exchange Key Exchange and authentication 96 Authentication 81
F.1.1.3. Diffie-Hellman key exchange Key Exchange with authentication 97 Authentication 81
F.1.2. Version rollback attacks 97 Rollback Attacks 82
F.1.3. Detecting attacks against Attacks Against the handshake protocol 98 Handshake Protocol 83
F.1.4. Resuming sessions 98 Sessions 83
F.1.5 Extensions 99
F.1.5.1 Security of server_name 99
F.1.5.2 Security of client_certificate_url 100
F.1.5.4. Security of trusted_ca_keys 101
F.1.5.5. Security of truncated_hmac 101
F.1.5.6. Security of status_request 102 83
F.2. Protecting application data 102
Dierks & Rescorla Standards Track [Page 3] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006 Application Data 84
F.3. Explicit IVs 103
F.4 84
F.4. Security of Composite Cipher Modes 103 84
F.5 Denial of Service 104 85
F.6. Final notes 104 Notes 86
1. Introduction
The primary goal of the TLS Protocol is to provide privacy and data
integrity between two communicating applications. The protocol is
composed of two layers: the TLS Record Protocol and the TLS Handshake
Protocol. At the lowest level, layered on top of some reliable
transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The
Dierks & Rescorla Standards Track [Page 3] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
TLS Record Protocol provides connection security that has two basic
properties:
- The connection is private. Symmetric cryptography is used for
data encryption (e.g., DES [DES], RC4 [SCH], [SCH] etc.). The keys for
this symmetric encryption are generated uniquely for each
connection and are based on a secret negotiated by another
protocol (such as the TLS Handshake Protocol). The Record
Protocol can also be used without encryption.
- The connection is reliable. Message transport includes a message
integrity check using a keyed MAC. Secure hash functions (e.g.,
SHA, MD5, etc.) are used for MAC computations. The Record
Protocol can operate without a MAC, but is generally only used in
this mode while another protocol is using the Record Protocol as
a transport for negotiating security parameters.
The TLS Record Protocol is used for encapsulation of various higher
level protocols. One such encapsulated protocol, the TLS Handshake
Protocol, allows the server and client to authenticate each other and
to negotiate an encryption algorithm and cryptographic keys before
the application protocol transmits or receives its first byte of
data. The TLS Handshake Protocol provides connection security that
has three basic properties:
- The peer's identity can be authenticated using asymmetric, or
public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
authentication can be made optional, but is generally required
for at least one of the peers.
- The negotiation of a shared secret is secure: the negotiated
secret is unavailable to eavesdroppers, and for any authenticated
connection the secret cannot be obtained, even by an attacker who
can place himself in the middle of the connection.
Dierks & Rescorla Standards Track [Page 4] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
- The negotiation is reliable: no attacker can modify the
negotiation communication without being detected by the parties
to the communication.
One advantage of TLS is that it is application protocol independent.
Higher level
Higher-level protocols can layer on top of the TLS Protocol
transparently. The TLS standard, however, does not specify how
protocols add security with TLS; the decisions on how to initiate TLS
handshaking and how to interpret the authentication certificates
exchanged are left up to the judgment of the designers and implementors
of protocols which run on top of TLS.
1.1 Requirements Terminology
Dierks & Rescorla Standards Track [Page 4] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2 Major Differences from TLS 1.1
This document is a revision of the TLS 1.1 [TLS1.1] protocol which
contains improved flexibility, particularly for negotiation of
cryptographic algorithms. The major changes are:
- Merged in TLS Extensions definition and AES Cipher Suites from
external documents.
- Replacement of MD5/SHA-1 combination in the PRF PRF. Addition
of cipher-suite specified PRFs.
- Replacement of MD5/SHA-1 combination in the digitally-signed
element.
- Allow the client to indicate which hash functions it supports. supports
for digital signature.
- Allow the server to indicate which hash functions it supports
for digital signature.
- Addition of support for authenticated encryption with additional
data modes.
1.1 Requirements Terminology
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT"
- Tightened up a number of requirements.
- The usual clarifications and
"MAY" that appear in this document are to be interpreted as described
in RFC 2119 [REQ]. editorial work.
2. Goals
The goals of TLS Protocol, in order of their priority, are: are as
follows:
1. Cryptographic security: TLS should be used to establish a secure
connection between two parties.
2. Interoperability: Independent programmers should be able to
develop applications utilizing TLS that will then be able to can successfully exchange
cryptographic parameters without knowledge
Dierks & Rescorla Standards Track [Page 5] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006 of one another's code.
3. Extensibility: TLS seeks to provide a framework into which new
public key and bulk encryption methods can be incorporated as
necessary. This will also accomplish two sub-goals: to prevent preventing
the need to create a new protocol (and risking the introduction
Dierks & Rescorla Standards Track [Page 5] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
of possible new weaknesses) and to avoid avoiding the need to implement an
entire new security library.
4. Relative efficiency: Cryptographic operations tend to be highly
CPU intensive, particularly public key operations. For this
reason, the TLS protocol has incorporated an optional session
caching scheme to reduce the number of connections that need to
be established from scratch. Additionally, care has been taken to
reduce network activity.
3. Goals of this document This Document
This document and the TLS protocol itself are based on the SSL 3.0
Protocol Specification as published by Netscape. The differences
between this protocol and SSL 3.0 are not dramatic, but they are
significant enough that the various versions of TLS and SSL 3.0 do
not interoperate (although each protocol incorporates a mechanism by
which an implementation can back down to prior versions.) versions). This
document is intended primarily for readers who will be implementing
the protocol and for those doing cryptographic analysis of it. The
specification has been written with this in mind, and it is intended
to reflect the needs of those two groups. For that reason, many of
the algorithm-dependent data structures and rules are included in the
body of the text (as opposed to in an appendix), providing easier
access to them.
This document is not intended to supply any details of service
definition nor or of interface definition, although it does cover select
areas of policy as they are required for the maintenance of solid
security.
4. Presentation language Language
This document deals with the formatting of data in an external
representation. The following very basic and somewhat casually
defined presentation syntax will be used. The syntax draws from
several sources in its structure. Although it resembles the
programming language "C" in its syntax and XDR [XDR] in both its
syntax and intent, it would be risky to draw too many parallels. The
purpose of this presentation language is to document TLS only, not to only; it has
no have general application beyond that particular goal.
Dierks & Rescorla Standards Track [Page 6] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
4.1. Basic block size Block Size
The representation of all data items is explicitly specified. The
basic data block size is one byte (i.e. (i.e., 8 bits). Multiple byte data
items are concatenations of bytes, from left to right, from top to
bottom. From the bytestream bytestream, a multi-byte item (a numeric in the
example)
Dierks & Rescorla Standards Track [Page 6] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
example) is formed (using C notation) by:
value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
... | byte[n-1];
This byte ordering for multi-byte values is the commonplace network
byte order or big endian format.
4.2. Miscellaneous
Comments begin with "/*" and end with "*/".
Optional components are denoted by enclosing them in "[[ ]]" double
brackets.
Single byte
Single-byte entities containing uninterpreted data are of type
opaque.
4.3. Vectors
A vector (single dimensioned array) is a stream of homogeneous data
elements. The size of the vector may be specified at documentation
time or left unspecified until runtime. In either case case, the length
declares the number of bytes, not the number of elements, in the
vector. The syntax for specifying a new type type, T' that is a fixed fixed-
length vector of type T is
T T'[n];
Here
Here, T' occupies n bytes in the data stream, where n is a multiple
of the size of T. The length of the vector is not included in the
encoded stream.
In the following example, Datum is defined to be three consecutive
bytes that the protocol does not interpret, while Data is three
consecutive Datum, consuming a total of nine bytes.
opaque Datum[3]; /* three uninterpreted bytes */
Datum Data[9]; /* 3 consecutive 3 byte vectors */
Dierks & Rescorla Standards Track [Page 7] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
Variable length
Variable-length vectors are defined by specifying a subrange of legal
lengths, inclusively, using the notation <floor..ceiling>. When
these are encoded, the actual length precedes the vector's contents
in the byte stream. The length will be in the form of a number
consuming as many bytes as required to hold the vector's specified
maximum (ceiling) length. A variable length variable-length vector with an actual
length field of zero is referred to as an empty vector.
Dierks & Rescorla Standards Track [Page 7] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
T T'<floor..ceiling>;
In the following example, mandatory is a vector that must contain
between 300 and 400 bytes of type opaque. It can never be empty. The
actual length field consumes two bytes, a uint16, sufficient to
represent the value 400 (see Section 4.4). On the other hand, longer
can represent up to 800 bytes of data, or 400 uint16 elements, and it
may be empty. Its encoding will include a two byte two-byte actual length
field prepended to the vector. The length of an encoded vector must
be an even multiple of the length of a single element (for example, a
17 byte
17-byte vector of uint16 would be illegal).
opaque mandatory<300..400>;
/* length field is 2 bytes, cannot be empty */
uint16 longer<0..800>;
/* zero to 400 16-bit unsigned integers */
4.4. Numbers
The basic numeric data type is an unsigned byte (uint8). All larger
numeric data types are formed from fixed length fixed-length series of bytes
concatenated as described in Section 4.1 and are also unsigned. The
following numeric types are predefined.
uint8 uint16[2];
uint8 uint24[3];
uint8 uint32[4];
uint8 uint64[8];
All values, here and elsewhere in the specification, are stored in
"network" or "big-endian" order; the uint32 represented by the hex
bytes 01 02 03 04 is equivalent to the decimal value 16909060.
Note that in some cases (e.g., DH parameters) it is necessary to
represent integers as opaque vectors. In such cases, they are
represented as unsigned integers (i.e., leading zero octets are not
required even if the most significant bit is set).
4.5. Enumerateds
An additional sparse data type is available called enum. A field of
type enum can only assume the values declared in the definition.
Each definition is a different type. Only enumerateds of the same
type may be assigned or compared. Every element of an enumerated must
Dierks & Rescorla Standards Track [Page 8] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
be assigned a value, as demonstrated in the following example. Since
the elements of the enumerated are not ordered, they can be assigned
any unique value, in any order.
Dierks & Rescorla Standards Track [Page 8] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;
Enumerateds occupy as much space in the byte stream as would its
maximal defined ordinal value. The following definition would cause
one byte to be used to carry fields of type Color.
enum { red(3), blue(5), white(7) } Color;
One may optionally specify a value without its associated tag to
force the width definition without defining a superfluous element.
In the following example, Taste will consume two bytes in the data
stream but can only assume the values 1, 2 2, or 4.
enum { sweet(1), sour(2), bitter(4), (32000) } Taste;
The names of the elements of an enumeration are scoped within the
defined type. In the first example, a fully qualified reference to
the second element of the enumeration would be Color.blue. Such
qualification is not required if the target of the assignment is well
specified.
Color color = Color.blue; /* overspecified, legal */
Color color = blue; /* correct, type implicit */
For enumerateds that are never converted to external representation,
the numerical information may be omitted.
enum { low, medium, high } Amount;
4.6. Constructed types Types
Structure types may be constructed from primitive types for
convenience. Each specification declares a new, unique type. The
syntax for definition is much like that of C.
struct {
T1 f1;
T2 f2;
...
Tn fn;
} [[T]];
Dierks & Rescorla Standards Track [Page 9] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
The fields within a structure may be qualified using the type's name
using name,
with a syntax much like that available for enumerateds. For example,
T.f2 refers to the second field of the previous declaration.
Structure definitions may be embedded.
4.6.1. Variants
Dierks & Rescorla Standards Track [Page 9] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
Defined structures may have variants based on some knowledge that is
available within the environment. The selector must be an enumerated
type that defines the possible variants the structure defines. There
must be a case arm for every element of the enumeration declared in
the select. The body of the variant structure may be given a label
for reference. The mechanism by which the variant is selected at
runtime is not prescribed by the presentation language.
struct {
T1 f1;
T2 f2;
....
Tn fn;
select (E) {
case e1: Te1;
case e2: Te2;
....
case en: Ten;
} [[fv]];
} [[Tv]];
For example:
enum { apple, orange } VariantTag;
struct {
uint16 number;
opaque string<0..10>; /* variable length */
} V1;
struct {
uint32 number;
opaque string[10]; /* fixed length */
} V2;
struct {
select (VariantTag) { /* value of selector is implicit */
case apple: V1; /* VariantBody, tag = apple */
case orange: V2; /* VariantBody, tag = orange */
} variant_body; /* optional label on variant */
} VariantRecord;
Variant structures may be qualified (narrowed) by specifying a value
for the selector prior to the type. For example, a
Dierks & Rescorla Standards Track [Page 10] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
orange VariantRecord
is a narrowed type of a VariantRecord containing a variant_body of
type V2.
4.7. Cryptographic attributes Attributes
Dierks & Rescorla Standards Track [Page 10] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
The five cryptographic operations digital signing, stream cipher
encryption, block cipher encryption, authenticated encryption with
additional data (AEAD) encryption and public key encryption are
designated digitally-signed, stream-ciphered, block-ciphered, aead-
ciphered, and public-key-encrypted, respectively. A field's
cryptographic processing is specified by prepending an appropriate
key word designation before the field's type specification.
Cryptographic keys are implied by the current session state (see
Section 6.1).
In digital signing, one-way hash functions are used as input for a
signing algorithm. A digitally-signed element is encoded as an opaque
vector <0..2^16-1>, where the length is specified by the signing
algorithm and key.
In RSA signing, the output of opaque vector contains the chosen hash function is encoded as
a PKCS #1 DigestInfo and then signed signature generated
using block type 01 as described the RSASSA-PKCS1-v1_5 signature scheme defined in Section 8.1 as described [PKCS1B]. As
discussed in [PKCS1A].
Note: [PKCS1B], the standard reference DigestInfo MUST be DER encoded and for PKCS#1 is now RFC 3447 [PKCS1B].
However, to minimize differences with TLS 1.0 text, we are using
digest algorithms without parameters (which include SHA-1) the
terminology
DigestInfo.AlgorithmIdentifier.parameters field SHOULD be omitted but
implementations MUST accept both without parameters and with NULL
parameters. Note that earlier versions of RFC 2313 [PKCS1A]. TLS used a different RSA
signature scheme which did not include a DigestInfo encoding.
In DSS, the 20 bytes of the SHA-1 hash are run directly through the
Digital Signing Algorithm with no additional hashing. This produces
two values, r and s. The DSS signature is an opaque vector, as above,
the contents of which are the DER encoding of:
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
In stream cipher encryption, the plaintext is exclusive-ORed with an
identical amount of output generated from a cryptographically-secure cryptographically secure
keyed pseudorandom number generator.
In block cipher encryption, every block of plaintext encrypts to a
block of ciphertext. All block cipher encryption is done in CBC
(Cipher Block Chaining) mode, and all items which that are block-ciphered
will be an exact multiple of the cipher block length.
Dierks & Rescorla Standards Track [Page 11] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
In AEAD encryption, the plaintext is simultaneously encrypted and
integrity protected. The input may be of any length and the output is
generally larger than the input in order to accomodate the integrity
check value.
Dierks & Rescorla Standards Track [Page 11] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
In public key encryption, a public key algorithm is used to encrypt
data in such a way that it can be decrypted only with the matching
private key. A public-key-encrypted element is encoded as an opaque
vector <0..2^16-1>, where the length is specified by the signing
algorithm and key.
An
RSA encrypted value encryption is encoded with PKCS #1 block type 2 as
described done using the RSAES-PKCS1-v1_5 encryption scheme
defined in [PKCS1A]. [PKCS1B].
In the following example: example
stream-ciphered struct {
uint8 field1;
uint8 field2;
digitally-signed opaque hash[20];
} UserType;
The
the contents of hash are used as input for the signing algorithm, and
then the entire structure is encrypted with a stream cipher. The
length of this structure, in bytes would be equal to 2 two bytes for
field1 and field2, plus two bytes for the length of the signature,
plus the length of the output of the signing algorithm. This is known
due to the fact that
because the algorithm and key used for the signing are known prior to
encoding or decoding this structure.
4.8. Constants
Typed constants can be defined for purposes of specification by
declaring a symbol of the desired type and assigning values to it.
Under-specified types (opaque, variable length vectors, and
structures that contain opaque) cannot be assigned values. No fields
of a multi-element structure or vector may be elided.
For example, example:
struct {
uint8 f1;
uint8 f2;
} Example1;
Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
5. HMAC and the pseudorandom function
Dierks & Rescorla Standards Track [Page 12] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006 Pseudorandom fFunction
A number of operations in the TLS record and handshake layer required requires
a keyed MAC; this is a secure digest of some data protected by a
secret. Forging the MAC is infeasible without knowledge of the MAC
secret. The construction we use TLS provides for this operation is known as HMAC,
Dierks & Rescorla Standards Track [Page 12] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
HMAC and is described in [HMAC]. Cipher suites MAY define their own
MACs.
In addition, a construction is required to do expansion of secrets
into blocks of data for the purposes of key generation or validation.
This pseudo-random function (PRF) takes as input a secret, a seed,
and an identifying label and produces an output of arbitrary length.
We define one PRF, based on HMAC, which is used for all cipher suites
in this document. Cipher suites MAY define their own PRFs.
First, we define a data expansion function, P_hash(secret, data)
which that
uses a single hash function to expand a secret and seed into an
arbitrary quantity of output:
P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
HMAC_hash(secret, A(2) + seed) +
HMAC_hash(secret, A(3) + seed) + ...
Where + indicates concatenation.
A() is defined as:
A(0) = seed
A(i) = HMAC_hash(secret, A(i-1))
P_hash can be iterated as many times as is necessary to produce the
required quantity of data. For example, if P_SHA-1 was is being used to
create 64 bytes of data, it would will have to be iterated 4 times (through
A(4)), creating 80 bytes of output data; the last 16 bytes of the
final iteration would will then be discarded, leaving 64 bytes of output
data.
TLS's PRF is created by applying P_hash to the secret S as:
PRF(secret, label, seed) = P_<hash>(secret, label + seed)
Unless
All the cipher suite definition specifies otherwise, the hash
function used suites defined in P this document and in TLS documents
prior to this document MUST be use SHA-256 as the same hash function selected basis for the
HMAC in the cipher suite. For existing their PRF.
New cipher suites (which use MD5
or SHA-1), the hash MUST be SHA-1. New ciphers which do not use HMAC MUST explicitly specify a PRF. PRF and in general SHOULD use the
TLS PRF with SHA-256 or a stronger standard hash function.
The label is an ASCII string. It should be included in the exact form
it is given without a length byte or trailing null character. For
example, the label "slithy toves" would be processed by hashing the
following bytes:
73 6C 69 74 68 79 20 74 6F 76 65 73
Dierks & Rescorla Standards Track [Page 13] draft-ietf-tls-rfc4346-bis-02.txt draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006 March 2007
6. The TLS Record Protocol
The TLS Record Protocol is a layered protocol. At each layer,
messages may include fields for length, description, and content.
The Record Protocol takes messages to be transmitted, fragments the
data into manageable blocks, optionally compresses the data, applies
a MAC, encrypts, and transmits the result. Received data is
decrypted, verified, decompressed, and reassembled, and then
delivered to
higher level higher-level clients.
Four record protocol clients are described in this document: the
handshake protocol, the alert protocol, the change cipher spec
protocol, and the application data protocol. In order to allow
extension of the TLS protocol, additional record types can be
supported by the record protocol. Any new New record types SHOULD
allocate type values immediately beyond the ContentType values for
the four record types described here (see Appendix A.1). All such
values must be defined are assigned
by RFC 2434 Standards Action. See section 11
for IANA Considerations for ContentType values. as described in Section 11.
If a TLS implementation receives a record type it does not
understand, it SHOULD just ignore it. Any protocol designed for use
over TLS MUST be carefully designed to deal with all possible attacks
against it. Note that because the type and length of a record are
not protected by encryption, care SHOULD be taken to minimize the
value of traffic analysis of these values. Implementations MUST not
send record types not defined in this document unless negotiated by
some extension.
6.1. Connection states States
A TLS connection state is the operating environment of the TLS Record
Protocol. It specifies a compression algorithm, encryption algorithm,
and MAC algorithm. In addition, the parameters for these algorithms
are known: the MAC secret and the bulk encryption keys for the
connection in both the read and the write directions. Logically,
there are always four connection states outstanding: the current read
and write states, and the pending read and write states. All records
are processed under the current read and write states. The security
parameters for the pending states can be set by the TLS Handshake
Protocol, and the Change Cipher Spec can selectively make either of
the pending states current, in which case the appropriate current
state is disposed of and replaced with the pending state; the pending
state is then reinitialized to an empty state. It is illegal to make
a state which that has not been initialized with security parameters a
current state. The initial current state always specifies that no
encryption, compression, or MAC will be used.
The security parameters for a TLS Connection read and write state are
set by providing the following values:
Dierks & Rescorla Standards Track [Page 14] draft-ietf-tls-rfc4346-bis-02.txt draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006 March 2007
connection end
Whether this entity is considered the "client" or the "server" in
this connection.
bulk encryption algorithm
An algorithm to be used for bulk encryption. This specification
includes the key size of this algorithm, how much of that key is
secret, whether it is a block, stream, or AEAD cipher, and the
block size of the cipher (if appropriate).
MAC algorithm
An algorithm to be used for message authentication. This
specification includes the size of the hash which that is returned by
the MAC algorithm.
compression algorithm
An algorithm to be used for data compression. This specification
must include all information the algorithm requires to do
compression.
master secret
A 48 byte 48-byte secret shared between the two peers in the connection.
client random
A 32 byte 32-byte value provided by the client.
server random
A 32 byte 32-byte value provided by the server.
These parameters are defined in the presentation language as:
enum { server, client } ConnectionEnd;
enum { null, rc4, rc2, des, 3des, des40, idea, aes } BulkCipherAlgorithm;
enum { stream, block, aead } CipherType;
enum { null, md5, sha, sha256, sha384, sha512} MACAlgorithm;
/* The use of "sha" above is historical and denotes SHA-1 */
enum { null(0), (255) } CompressionMethod;
/* The algorithms specified in CompressionMethod,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */
struct {
ConnectionEnd entity;
Dierks & Rescorla Standards Track [Page 15] draft-ietf-tls-rfc4346-bis-02.txt draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006 March 2007
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 key_size; enc_key_length;
uint8 key_material_length; block_length;
uint8 iv_length;
MACAlgorithm mac_algorithm;
uint8 hash_size; mac_length;
uint8 mac_key_length;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
The record layer will use the security parameters to generate the
following four items:
client write MAC secret
server write MAC secret
client write key
server write key
The client write parameters are used by the server when receiving and
processing records and vice-versa. The algorithm used for generating
these items from the security parameters is described in section Section 6.3.
Once the security parameters have been set and the keys have been
generated, the connection states can be instantiated by making them
the current states. These current states MUST be updated for each
record processed. Each connection state includes the following
elements:
compression state
The current state of the compression algorithm.
cipher state
The current state of the encryption algorithm. This will consist
of the scheduled key for that connection. For stream ciphers,
this will also contain whatever the necessary state information is necessary to
allow the stream to continue to encrypt or decrypt data.
MAC secret
The MAC secret for this connection connection, as generated above.
sequence number
Each connection state contains a sequence number, which is
maintained separately for read and write states. The sequence
number MUST be set to zero whenever a connection state is made
Dierks & Rescorla Standards Track [Page 16] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
the active state. Sequence numbers are of type uint64 and may not
exceed 2^64-1. Sequence numbers do not wrap. If a TLS
Dierks & Rescorla Standards Track [Page 16] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
implementation would need to wrap a sequence number number, it must
renegotiate instead. A sequence number is incremented after each
record: specifically, the first record which is transmitted under a
particular connection state MUST use sequence number 0.
6.2. Record layer
The TLS Record Layer receives uninterpreted data from higher layers
in non-empty blocks of arbitrary size.
6.2.1. Fragmentation
The record layer fragments information blocks into TLSPlaintext
records carrying data in chunks of 2^14 bytes or less. Client message
boundaries are not preserved in the record layer (i.e., multiple
client messages of the same ContentType MAY be coalesced into a
single TLSPlaintext record, or a single message MAY be fragmented
across several records).
struct {
uint8 major, minor;
} ProtocolVersion;
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
type
The higher level higher-level protocol used to process the enclosed fragment.
version
The version of the protocol being employed. This document
describes TLS Version 1.2, which uses the version { 3, 3 }. The
version value 3.3 is historical, deriving from the use of 3.1 for
TLS 1.0. (See Appendix A.1). Note that a client that supports
multiple versions of TLS may not know what version will be
employed before it receives ServerHello. See Appendix E for
Dierks & Rescorla Standards Track [Page 17] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
discussion about what record layer version number should be
employed for ClientHello.
length
The length (in bytes) of the following TLSPlaintext.fragment.
The length should MUST not exceed 2^14.
Dierks & Rescorla Standards Track [Page 17] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
fragment
The application data. This data is transparent and treated as an
independent block to be dealt with by the higher level higher-level protocol
specified by the type field.
Implementations MUST not send zero-length fragments of Handshake,
Alert, or Change Cipher Spec content types. Zero-length fragments
of Application data MAY be sent as they are potentially useful as
a traffic analysis countermeasure.
Note: Data of different TLS Record layer content types MAY be
interleaved. Application data is generally of lower precedence
for transmission than other content types. However, records MUST
be delivered to the network in the same order as they are
protected by the record layer. Recipients MUST receive and
process interleaved application layer traffic during handshakes
subsequent to the first one on a connection.
6.2.2. Record compression Compression and decompression Decompression
All records are compressed using the compression algorithm defined in
the current session state. There is always an active compression
algorithm; however, initially it is defined as
CompressionMethod.null. The compression algorithm translates a
TLSPlaintext structure into a TLSCompressed structure. Compression
functions are initialized with default state information whenever a
connection state is made active.
Compression must be lossless and may not increase the content length
by more than 1024 bytes. If the decompression function encounters a
TLSCompressed.fragment that would decompress to a length in excess of
2^14 bytes, it should MUST report a fatal decompression failure error.
struct {
ContentType type; /* same as TLSPlaintext.type */
ProtocolVersion version;/* same as TLSPlaintext.version */
uint16 length;
opaque fragment[TLSCompressed.length];
} TLSCompressed;
Dierks & Rescorla Standards Track [Page 18] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
length
The length (in bytes) of the following TLSCompressed.fragment.
The length should not exceed 2^14 + 1024.
fragment
The compressed form of TLSPlaintext.fragment.
Note: A CompressionMethod.null operation is an identity operation; no
fields are altered.
Implementation note:
Decompression functions are responsible for ensuring that
Dierks & Rescorla Standards Track [Page 18] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
messages cannot cause internal buffer overflows.
6.2.3. Record payload protection Payload Protection
The encryption and MAC functions translate a TLSCompressed structure
into a TLSCiphertext. The decryption functions reverse the process.
The MAC of the record also includes a sequence number so that
missing, extra extra, or repeated messages are detectable.
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) (SecurityParameters.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
case aead: GenericAEADCipher;
} fragment;
} TLSCiphertext;
type
The type field is identical to TLSCompressed.type.
version
The version field is identical to TLSCompressed.version.
length
The length (in bytes) of the following TLSCiphertext.fragment.
The length may not exceed 2^14 + 2048.
fragment
The encrypted form of TLSCompressed.fragment, with the MAC.
6.2.3.1. Null or standard stream cipher Standard Stream Cipher
Stream ciphers (including BulkCipherAlgorithm.null - BulkCipherAlgorithm.null, see Appendix A.6)
Dierks & Rescorla Standards Track [Page 19] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
convert TLSCompressed.fragment structures to and from stream
TLSCiphertext.fragment structures.
stream-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size]; MAC[SecurityParameters.mac_length];
} GenericStreamCipher;
The MAC is generated as:
HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length +
Dierks & Rescorla Standards Track [Page 19] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
TLSCompressed.fragment));
where "+" denotes concatenation.
seq_num
The sequence number for this record.
hash
The hashing algorithm specified by
SecurityParameters.mac_algorithm.
Note that the MAC is computed before encryption. The stream cipher
encrypts the entire block, including the MAC. For stream ciphers that
do not use a synchronization vector (such as RC4), the stream cipher
state from the end of one record is simply used on the subsequent
packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
consists of the identity operation (i.e., the data is not encrypted encrypted,
and the MAC size is zero zero, implying that no MAC is used).
TLSCiphertext.length is TLSCompressed.length plus
CipherSpec.hash_size.
SecurityParameters.mac_length.
6.2.3.2. CBC block cipher Block Cipher
For block ciphers (such as RC2, DES, or AES), the encryption and MAC
functions convert TLSCompressed.fragment structures to and from block
TLSCiphertext.fragment structures.
block-ciphered struct {
opaque IV[CipherSpec.block_length]; IV[SecurityParameters.block_length];
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size]; MAC[SecurityParameters.mac_length];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
The MAC is generated as described in Section 6.2.3.1.
Dierks & Rescorla Standards Track [Page 20] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
IV
TLS 1.2 uses an explicit IV in order to prevent the attacks
described by [CBCATT]. We recommend The IV SHOULD be chosen at random and MUST
be unpredictable. In order to decrypt, thereceiver decrypts the following equivalently strong
procedures. For clarity we use
entire GenericBlockCipher structure and then discards the first
cipher block, corresponding to the following notation. IV -- component.
padding
Padding that is added to force the transmitted value length of the IV field in the
GenericBlockCipher structure.
CBC residue -- the last ciphertext block of the previous record
mask -- the actual value which the cipher XORs with the plaintext prior to encryption be
an integral multiple of the first cipher block
of the record.
Dierks & Rescorla Standards Track [Page 20] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
In versions of TLS prior cipher's block length. The
padding MAY be any length up to 1.1, there was no IV field and the CBC residue
and mask were one and 255 bytes, as long as it results
in the same. See Sections 6.1, 6.2.3.2 and 6.3,
of [TLS1.0] for details of TLS 1.0 IV handling.
One TLSCiphertext.length being an integral multiple of the following two algorithms SHOULD
block length. Lengths longer than necessary might be used desirable to generate the
per-record IV:
(1) Generate
frustrate attacks on a cryptographically strong random string R protocol based on analysis of
length CipherSpec.block_length. Place R
in the IV field. Set the mask to R. Thus, lengths
of exchanged messages. Each uint8 in the first
cipher block will padding data vector MUST
be encrypted as E(R XOR Data).
(2) Generate a cryptographically strong random number R of filled with the padding length CipherSpec.block_length value. The receiver MUST check
this padding and prepend it to SHOULD use the plaintext
prior bad_record_mac alert to encryption. In
this case either:
(a) The cipher may use a fixed mask such as zero.
(b) indicate
padding errors.
padding_length
The CBC residue from the previous record may padding length MUST be used
as the mask. This preserves maximum code compatibility
with TLS 1.0 and SSL 3. It also has the advantage such that
it does not require the ability to quickly reset total size of the IV,
which
GenericBlockCipher structure is known to be a problem on some systems.
In either 2(a) or 2(b) the data (R || data) is fed into multiple of the
encryption process. The first cipher block (containing
E(mask XOR R) is placed in the IV field. The first
block of content contains E(IV XOR data)
The following alternative procedure MAY be used: However, it has
not been demonstrated to be equivalently cryptographically strong
to the above procedures. The sender prepends a fixed block F to
the plaintext (or alternatively a block generated with a weak
PRNG). He then encrypts as in (2) above, using the CBC residue
from the previous block as the mask for the prepended block. Note
that in this case the mask for the first record transmitted by
the application (the Finished) MUST be generated using a
cryptographically strong PRNG.
The decryption operation for all three alternatives is the same.
The receiver decrypts the entire GenericBlockCipher structure and
then discards the first cipher block, corresponding to the IV
component.
padding
Padding that is added to force the length of the plaintext to be
an integral multiple of the block cipher's block length. The
padding MAY be any length up to 255 bytes long, as long as it
Dierks & Rescorla Standards Track [Page 21] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
results in the TLSCiphertext.length being an integral multiple of
the block length. Lengths longer than necessary might be
desirable to frustrate attacks on a protocol based on analysis of
the lengths of exchanged messages. Each uint8 in the padding data
vector MUST be filled with the padding length value. The receiver
MUST check this padding and SHOULD use the bad_record_mac alert
to indicate padding errors.
padding_length
The padding length MUST be such that the total size of the
GenericBlockCipher structure is a multiple of the cipher's cipher's block
length. Legal values range from zero to 255, inclusive. This
length specifies the length of the padding field exclusive of the
padding_length field itself.
The encrypted data length (TLSCiphertext.length) is one more than the
sum of TLSCompressed.length, CipherSpec.hash_size, SecurityParameters.mac_length, and
padding_length.
Example: If the block length is 8 bytes, the content length
(TLSCompressed.length) is 61 bytes, and the MAC length is 20
bytes, then the length before padding is 82 bytes (this does
not include the IV, which may or may not be encrypted, as
discussed above). Thus, the padding length modulo 8 must be
equal to 6 in order to make the total length an even multiple
of 8 bytes (the block length). The padding length can be 6,
14, 22, and so on, through 254. If the padding length were the
minimum necessary, 6, the padding would be 6 bytes, each
containing the value 6. Thus, the last 8 octets of the
GenericBlockCipher before block encryption would be xx 06 06
06 06 06 06 06, where xx is the last octet of the MAC.
Note: With block ciphers in CBC mode (Cipher Block Chaining),
it is critical that the entire plaintext of the record be known
before any ciphertext is transmitted. Otherwise Otherwise, it is possible
for the attacker to mount the attack described in [CBCATT].
Dierks & Rescorla Standards Track [Page 21] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
Implementation Note: Canvel et. et al. [CBCTIME] have demonstrated a timing
attack on CBC padding based on the time required to compute the
MAC. In order to defend against this attack, implementations MUST
ensure that record processing time is essentially the same
whether or not the padding is correct. In general, the best way
to to do this is to compute the MAC even if the padding is
incorrect, and only then reject the packet. For instance, if the
pad appears to be incorrect incorrect, the implementation might assume a
zero-length pad and then compute the MAC. This leaves a small
timing channel, since MAC performance depends to some extent on
the size of the data fragment, but it is not
Dierks & Rescorla Standards Track [Page 22] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006 believed to be large
enough to be exploitable exploitable, due to the large block size of existing
MACs and the small size of the timing signal.
6.2.3.3. AEAD ciphers
For AEAD [AEAD] ciphers (such as [CCM] or [GCM]) the AEAD function
converts TLSCompressed.fragment structures to and from AEAD
TLSCiphertext.fragment structures.
aead-ciphered struct {
opaque IV[CipherSpec.iv_length]; IV[SecurityParameters.iv_length];
opaque aead_output[AEADEncrypted.length];
} GenericAEADCipher;
AEAD ciphers take as input a single key, optional IV (depending on
the cipher), a nonce, a plaintext, and
"additional data" to be included in the authentication check. I.e.,
AEADEncrypted = AEAD-Encrypt(key, IV, plaintext,
additional_data) check, as
described in Section 2.1 of [AEAD]. These inputs are as follows.
The key is either the client_write_key or the server_write_key. When The
MAC key will be of length zero.
The nonce supplied to the AEAD algorithms are operations is determined by the IV in
aead-ciphered struct. Each IV used in distinct invocations of the MAC keys are
AEAD encryption operation MUST be distinct, for any fixed value of zero length
the key. Implementations SHOULD use the recommended nonce formation
method of [AEAD] to generate IVs, and are not
used. MAY use any other method that
meets this requirement. The length of the IV depends on the cipher suite. If it is
required it MUST AEAD
cipher; that length MAY be generated using a cryptographically strong random
number generator. zero. Note that in many cases it is
appropriate to use the IV may partially implicit nonce technique of S 3.2.1
of AEAD, in which case the client_write_iv and server_write_iv should
be zero length. used as the "fixed-common".
The plaintext is the TLSCompressed.fragment.
The additional_data additional authenticated data, which we denote as
additional_data, is defined as follows:
Dierks & Rescorla Standards Track [Page 22] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
additional_data = seq_num + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.length;
Where "+" denotes concatenation.
The aead_output consists of the ciphertext output by the AEAD
encryption operation. AEADEncrypted.length will generally be larger
than TLSCompressed.length, but by an amount that varies with the cipher
and AEAD
cipher. Since the required padding (if any). ciphers might incorporate padding, the amount of
overhead could vary with different TLSCompressed.length values. Each
AEAD algorithms cipher MUST NOT produce an expansion of greater than 1024 bytes.
Symbolically,
AEADEncrypted = AEAD-Encrypt(key, IV, plaintext,
additional_data)
Where "+" denotes concatenation.
In order to decrypt and verify, the cipher takes as input the key,
IV, the "additional_data", and the AEADEncrypted value. The output is
either the plaintext or an error indicating that the decryption
failed. There is no separate integrity check. I.e.,
TLSCompressed.fragment = AEAD-Decrypt(write_key, IV, AEADEncrypted,
TLSCiphertext.type + TLSCiphertext.version +
TLSCiphertext.length);
Dierks & Rescorla Standards Track [Page 23] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
If the decryption fails, a fatal bad_record_mac alert MUST be
generated.
6.3. Key calculation Calculation
The Record Protocol requires an algorithm to generate keys, and MAC
secrets from the security parameters provided by the handshake
protocol.
The master secret is hashed into a sequence of secure bytes, which
are assigned to the MAC secrets and keys required by the current
connection state (see Appendix A.6). CipherSpecs require a client
write MAC secret, a server write MAC secret, a client write key, and
a server write key, each of which are is generated from the master secret
in that order. Unused values are empty.
When generating keys and MAC secrets, secrets are generated, the master secret is used as
an entropy source.
To generate the key material, compute
key_block = PRF(SecurityParameters.master_secret,
Dierks & Rescorla Standards Track [Page 23] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
"key expansion",
SecurityParameters.server_random +
SecurityParameters.client_random);
until enough output has been generated. Then the key_block is
partitioned as follows:
client_write_MAC_secret[SecurityParameters.hash_size]
server_write_MAC_secret[SecurityParameters.hash_size]
client_write_key[SecurityParameters.key_material_length]
server_write_key[SecurityParameters.key_material_length]
client_write_MAC_secret[SecurityParameters.mac_key_length]
server_write_MAC_secret[SecurityParameters.mac_key_length]
client_write_key[SecurityParameters.enc_key_length]
server_write_key[SecurityParameters.enc_key_length]
Implementation note:
The currently defined cipher suite which requires the most
material is AES_256_CBC_SHA, defined in [TLSAES]. It requires 2 x
32 byte keys and 2 x 20 byte MAC secrets, for a total 104 bytes
of key material.
7. The TLS Handshaking Protocols
TLS has three subprotocols which that are used to allow peers to agree
upon security parameters for the record layer, to authenticate
themselves, to instantiate negotiated security parameters, and to
report error conditions to each other.
Dierks & Rescorla Standards Track [Page 24] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
The Handshake Protocol is responsible for negotiating a session,
which consists of the following items:
session identifier
An arbitrary byte sequence chosen by the server to identify an
active or resumable session state.
peer certificate
X509v3 [X509] certificate of the peer. This element of the
state may be null.
compression method
The algorithm used to compress data prior to encryption.
cipher spec
Specifies the bulk data encryption algorithm (such as null,
DES, etc.) and a MAC algorithm (such as MD5 or SHA). It also
defines cryptographic attributes such as the hash_size. (See
Appendix A.6 for formal definition) definition,)
master secret
48-byte secret shared between the client and server.
is resumable
A flag
Dierks & Rescorla Standards Track [Page 24] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
is resumable
A flag indicating whether the session can be used to initiate
new connections.
These items are then used to create security parameters for use by
the Record Layer when protecting application data. Many connections
can be instantiated using the same session through the resumption
feature of the TLS Handshake Protocol.
7.1. Change cipher spec protocol Cipher Spec Protocol
The change cipher spec protocol exists to signal transitions in
ciphering strategies. The protocol consists of a single message,
which is encrypted and compressed under the current (not the pending)
connection state. The message consists of a single byte of value 1.
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
The change cipher spec message is sent by both the client and the
server to notify the receiving party that subsequent records will be
protected under the newly negotiated CipherSpec and keys. Reception
of this message causes the receiver to instruct the Record Layer to
immediately copy the read pending state into the read current state.
Dierks & Rescorla Standards Track [Page 25] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
Immediately after sending this message, the sender MUST instruct the
record layer to make the write pending state the write active state.
(See section Section 6.1.) The change cipher spec message is sent during the
handshake after the security parameters have been agreed upon, but
before the verifying finished message is sent (see section Section 7.4.11
Note: if If a rehandshake occurs while data is flowing on a connection,
the communicating parties may continue to send data using the old
CipherSpec. However, once the ChangeCipherSpec has been sent, the new
CipherSpec MUST be used. The first side to send the ChangeCipherSpec
does not know that the other side has finished computing the new
keying material (e.g. (e.g., if it has to perform a time consuming public
key operation). Thus, a small window of time time, during which the
recipient must buffer the data data, MAY exist. In practice, with modern
machines this interval is likely to be fairly short.
7.2. Alert protocol Protocol
One of the content types supported by the TLS Record layer is the
alert type. Alert messages convey the severity of the message and a
description of the alert. Alert messages with a level of fatal result
in the immediate termination of the connection. In this case, other
connections corresponding to the session may continue, but the
Dierks & Rescorla Standards Track [Page 25] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
session identifier MUST be invalidated, preventing the failed session
from being used to establish new connections. Like other messages,
alert messages are encrypted and compressed, as specified by the
current connection state.
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed(21),
decryption_failed_RESERVED(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
no_certificate_RESERVED (41),
no_certificate_RESERVED(41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
Dierks & Rescorla Standards Track [Page 26] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110), /* new */
certificate_unobtainable(111), /* new */
unrecognized_name(112), /* new */
bad_certificate_status_response(113), /* new */
bad_certificate_hash_value(114), /* new */
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
7.2.1. Closure alerts Alerts
The client and the server must share knowledge that the connection is
ending in order to avoid a truncation attack. Either party may
initiate the exchange of closing messages.
close_notify
Dierks & Rescorla Standards Track [Page 26] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
This message notifies the recipient that the sender will not send
any more messages on this connection. Note that as of TLS 1.1,
failure to properly close a connection no longer requires that a
session not be resumed. This is a change from TLS 1.0 to conform
with widespread implementation practice.
Either party may initiate a close by sending a close_notify alert.
Any data received after a closure alert is ignored.
Unless some other fatal alert has been transmitted, each party is
required to send a close_notify alert before closing the write side
of the connection. The other party MUST respond with a close_notify
alert of its own and close down the connection immediately,
discarding any pending writes. It is not required for the initiator
of the close to wait for the responding close_notify alert before
closing the read side of the connection.
If the application protocol using TLS provides that any data may be
carried over the underlying transport after the TLS connection is
closed, the TLS implementation must receive the responding
close_notify alert before indicating to the application layer that
Dierks & Rescorla Standards Track [Page 27] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
the TLS connection has ended. If the application protocol will not
transfer any additional data, but will only close the underlying
transport connection, then the implementation MAY choose to close the
transport without waiting for the responding close_notify. No part of
this standard should be taken to dictate the manner in which a usage
profile for TLS manages its data transport, including when
connections are opened or closed.
Note: It is assumed that closing a connection reliably delivers
pending data before destroying the transport.
7.2.2. Error alerts Alerts
Error handling in the TLS Handshake protocol is very simple. When an
error is detected, the detecting party sends a message to the other
party. Upon transmission or receipt of an a fatal alert message, both
parties immediately close the connection. Servers and clients MUST
forget any session-identifiers, keys, and secrets associated with a
failed connection. Thus, any connection terminated with a fatal alert
MUST NOT be resumed. The following error alerts are defined:
unexpected_message
An inappropriate message was received. This alert is always fatal
and should never be observed in communication between proper
implementations.
bad_record_mac
Dierks & Rescorla Standards Track [Page 27] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
This alert is returned if a record is received with an incorrect
MAC. This alert also MUST be returned if an alert is sent because
a TLSCiphertext decrypted in an invalid way: either it wasn't an
even multiple of the block length, or its padding values, when
checked, weren't correct. This message is always fatal.
decryption_failed
decryption_failed_RESERVED
This alert MAY be returned if a TLSCiphertext decrypted was used in an
invalid way: either it wasn't an even multiple some earlier versions of the block
length, or its padding values, when checked, weren't correct.
This message is always fatal.
Note: Differentiating between bad_record_mac TLS, and
decryption_failed alerts may permit have
permitted certain attacks against the CBC mode as used in TLS [CBCATT]. It is preferable to uniformly use
the bad_record_mac alert to hide the specific type of the error. MUST
NOT be sent by compliant implementations.
record_overflow
A TLSCiphertext record was received which that had a length more than
2^14+2048 bytes, or a record decrypted to a TLSCompressed record
Dierks & Rescorla Standards Track [Page 28] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
with more than 2^14+1024 bytes. This message is always fatal.
decompression_failure
The decompression function received improper input (e.g. (e.g., data
that would expand to excessive length). This message is always
fatal.
handshake_failure
Reception of a handshake_failure alert message indicates that the
sender was unable to negotiate an acceptable set of security
parameters given the options available. This is a fatal error.
no_certificate_RESERVED
This alert was used in SSLv3 but not in any version of TLS. It should not MUST
NOT be sent by compliant implementations.
bad_certificate
A certificate was corrupt, contained signatures that did not
verify correctly, etc.
unsupported_certificate
A certificate was of an unsupported type.
certificate_revoked
A certificate was revoked by its signer.
certificate_expired
A certificate has expired or is not currently valid.
certificate_unknown
Some other (unspecified) issue arose in processing the
certificate, rendering it unacceptable.
illegal_parameter
Dierks & Rescorla Standards Track [Page 28] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
A field in the handshake was out of range or inconsistent with
other fields. This is always fatal.
unknown_ca
A valid certificate chain or partial chain was received, but the
certificate was not accepted because the CA certificate could not
be located or couldn't be matched with a known, trusted CA. This
message is always fatal.
access_denied
A valid certificate was received, but when access control was
applied, the sender decided not to proceed with negotiation.
This message is always fatal.
Dierks & Rescorla Standards Track [Page 29] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
decode_error
A message could not be decoded because some field was out of the
specified range or the length of the message was incorrect. This
message is always fatal.
decrypt_error
A handshake cryptographic operation failed, including being
unable to correctly verify a signature, decrypt a key exchange,
or validate a finished message.
export_restriction_RESERVED
This alert was used in TLS 1.0 but not TLS 1.1. some earlier versions of TLS. It MUST NOT
be sent by compliant implementations.
protocol_version
The protocol version the client has attempted to negotiate is
recognized,
recognized but not supported. (For example, old protocol versions
might be avoided for security reasons). This message is always
fatal.
insufficient_security
Returned instead of handshake_failure when a negotiation has
failed specifically because the server requires ciphers more
secure than those supported by the client. This message is always
fatal.
internal_error
An internal error unrelated to the peer or the correctness of the
protocol makes it impossible to continue (such as a memory allocation failure). failure) makes it
impossible to continue. This message is always fatal.
user_canceled
This handshake is being canceled for some reason unrelated to a
protocol failure. If the user cancels an operation after the
Dierks & Rescorla Standards Track [Page 29] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
handshake is complete, just closing the connection by sending a
close_notify is more appropriate. This alert should be followed
by a close_notify. This message is generally a warning.
no_renegotiation
Sent by the client in response to a hello request or by the
server in response to a client hello after initial handshaking.
Either of these would normally lead to renegotiation; when that
is not appropriate, the recipient should respond with this alert;
at alert.
At that point, the original requester can decide whether to
proceed with the connection. One case where this would be
appropriate would be is where a server has spawned a process to satisfy a
request; the process might receive security parameters (key
length, authentication, etc.) at startup and it might be
difficult to communicate changes to these parameters after that
Dierks & Rescorla Standards Track [Page 30] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
point. This message is always a warning.
The following error alerts apply only to the extensions described
in Section XXX. To avoid "breaking" existing clients and servers,
these alerts MUST NOT be sent unless the sending party has
received an extended hello message from the party they are
communicating with.
unsupported_extension
sent by clients that receive an extended server hello containing
an extension that they did not put in the corresponding client
hello (see Section 2.3). This message is always fatal.
unrecognized_name
sent by servers that receive a server_name extension request, but
do not recognize the server name. This message MAY be fatal.
certificate_unobtainable
sent by servers who are unable to retrieve a certificate chain
from the URL supplied by the client (see Section 3.3). This
message MAY be fatal - for example if client authentication is
required by the server for the handshake to continue and the
server is unable to retrieve the certificate chain, it may send a
fatal alert.
bad_certificate_status_response
sent by clients that receive an invalid certificate status
response (see Section 3.6). This message is always fatal.
bad_certificate_hash_value
sent by servers when a certificate hash does not match a client
provided certificate_hash. This message is always fatal.
For all errors where an alert level is not explicitly specified, the
sending party MAY determine at its discretion whether this is a fatal
error or not; if an alert with a level of warning is received, the
receiving party MAY decide at its discretion whether to treat this as
a fatal error or not. However, all messages which are transmitted
with a level of fatal MUST be treated as fatal messages.
New alerts Alert values MUST be defined are assigned by RFC 2434 Standards Action. See
Section 11 for IANA Considerations for alert values. as described in Section 11.
7.3. Handshake Protocol overview Overview
The cryptographic parameters of the session state are produced by the
TLS Handshake Protocol, which operates on top of the TLS Record
Layer. When a TLS client and server first start communicating, they
Dierks & Rescorla Standards Track [Page 31] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
agree on a protocol version, select cryptographic algorithms,
optionally authenticate each other, and use public-key encryption
techniques to generate shared secrets.
The TLS Handshake Protocol involves the following steps:
- Exchange hello messages to agree on algorithms, exchange random
values, and check for session resumption.
- Exchange the necessary cryptographic parameters to allow the
client and server to agree on a premaster secret.
Dierks & Rescorla Standards Track [Page 30] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
- Exchange certificates and cryptographic information to allow the
client and server to authenticate themselves.
- Generate a master secret from the premaster secret and exchanged
random values.
- Provide security parameters to the record layer.
- Allow the client and server to verify that their peer has
calculated the same security parameters and that the handshake
occurred without tampering by an attacker.
Note that higher layers should not be overly reliant on whether TLS
always
negotiating negotiates the strongest possible connection between two peers:
there
peers. There are a number of ways in which a man in the middle
attacker can attempt to make two entities drop down to the least
secure method they support. The protocol has been designed to
minimize this risk, but there are still attacks available: for
example, an attacker could block access to the port a secure service
runs on, or attempt to get the peers to negotiate an unauthenticated
connection. The fundamental rule is that higher levels must be
cognizant of what their security requirements are and never transmit
information over a channel less secure than what they require. The
TLS protocol is secure, secure in that any cipher suite offers its promised
level of security: if you negotiate 3DES with a 1024 bit RSA key
exchange with a host whose certificate you have verified, you can
expect to be that secure.
Dierks & Rescorla Standards Track [Page 32] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
However, you SHOULD never send data over a link encrypted with 40 bit
security unless you feel that data is worth no more than the effort
required to break that encryption.
These goals are achieved by the handshake protocol, which can be
summarized as follows: The client sends a client hello message to
which the server must respond with a server hello message, or else a
fatal error will occur and the connection will fail. The client hello
and server hello are used to establish security enhancement
capabilities between client and server. The client hello and server
hello establish the following attributes: Protocol Version, Session
ID, Cipher Suite, and Compression Method. Additionally, two random
values are generated and exchanged: ClientHello.random and
ServerHello.random.
The actual key exchange uses up to four messages: the server
certificate, the server key exchange, the client certificate, and the
client key exchange. New key exchange methods can be created by
specifying a format for these messages and by defining the use of the
messages to allow the client and server to agree upon a shared
secret. This secret MUST be quite long; currently defined key
exchange methods exchange secrets which that range from 48 to 128 bytes in
length.
Following the hello messages, the server will
Dierks & Rescorla Standards Track [Page 31] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
Following the hello messages, the server will send its certificate,
if it is to be authenticated. Additionally, a server key exchange
message may be sent, if it is required (e.g. (e.g., if their server has no
certificate, or if its certificate is for signing only). If the
server is authenticated, it may request a certificate from the
client, if that is appropriate to the cipher suite selected. Now Next,
the server will send the server hello done message, indicating that
the hello-message phase of the handshake is complete. The server will
then wait for a client response. If the server has sent a certificate
request message, the client must send the certificate message. The
client key exchange message is now sent, and the content of that
message will depend on the public key algorithm selected between the
client hello and the server hello. If the client has sent a
certificate with signing ability, a digitally-signed certificate
verify message is sent to explicitly verify possession of the private
key in the certificate.
At this point, a change cipher spec message is sent by the client,
and the client copies the pending Cipher Spec into the current Cipher
Spec. The client then immediately sends the finished message under
the new algorithms, keys, and secrets. In response, the server will
send its own change cipher spec message, transfer the pending to the
current Cipher Spec, and send its finished message under the new
Dierks & Rescorla Standards Track [Page 33] draft-ietf-tls-rfc4346-bis-02.txt 32] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006 March 2007
Cipher Spec. At this point, the handshake is complete complete, and the client
and server may begin to exchange application layer data. (See flow
chart below.) Application data MUST NOT be sent prior to the
completion of the first handshake (before a cipher suite other
TLS_NULL_WITH_NULL_NULL is established).
Client Server
ClientHello -------->
ServerHello
Certificate*
CertificateStatus*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
CertificateURL*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
Fig. 1 - 1. Message flow for a full handshake
* Indicates optional or situation-dependent messages that are not
always sent.
Note: To help avoid pipeline stalls, ChangeCipherSpec is an
independent TLS Protocol content type, and is not actually a TLS
handshake message.
When the client and server decide to resume a previous session or
duplicate an existing session (instead of negotiating new security
parameters)
parameters), the message flow is as follows:
The client sends a ClientHello using the Session ID of the session to
be resumed. The server then checks its session cache for a match. If
a match is found, and the server is willing to re-establish the
connection under the specified session state, it will send a
ServerHello with the same Session ID value. At this point, both
client and server MUST send change cipher spec messages and proceed
directly to finished messages. Once the re-establishment is complete,
the client and server MAY begin to exchange application layer data.
(See flow chart below.) If a Session ID match is not found, the
server generates a new session ID and the TLS client and server
perform a full handshake.
Dierks & Rescorla Standards Track [Page 34] draft-ietf-tls-rfc4346-bis-02.txt 33] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006 March 2007
perform a full handshake.
Client Server
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
Finished -------->
Application Data <-------> Application Data
Fig. 2 - 2. Message flow for an abbreviated handshake
The contents and significance of each message will be presented in
detail in the following sections.
7.4. Handshake protocol Protocol
The TLS Handshake Protocol is one of the defined higher level higher-level clients
of the TLS Record Protocol. This protocol is used to negotiate the
secure attributes of a session. Handshake messages are supplied to
the TLS Record Layer, where they are encapsulated within one or more
TLSPlaintext structures, which are processed and transmitted as
specified by the current active session state.
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), certificate_url(21), certificate_status(22),
finished(20)
(255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
case certificate_url: CertificateURL;
Dierks & Rescorla Standards Track [Page 35] draft-ietf-tls-rfc4346-bis-02.txt 34] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006 March 2007
case certificate_status: CertificateStatus; finished: Finished;
} body;
} Handshake;
The handshake protocol messages are presented below in the order they
MUST be sent; sending handshake messages in an unexpected order
results in a fatal error. Unneeded handshake messages can be omitted,
however. Note one exception to the ordering: the Certificate message
is used twice in the handshake (from server to client, then from
client to server), but described only in its first position. The one
message which that is not bound by these ordering rules is the Hello
Request message, which can be sent at any time, but which should be
ignored by the client if it arrives in the middle of a handshake.
New Handshake message type values MUST be defined via RFC 2434
Standards Action. See Section 11 for types are assigned by IANA Considerations for these
values. as described in
Section 11.
7.4.1. Hello messages Messages
The hello phase messages are used to exchange security enhancement
capabilities between the client and server. When a new session
begins, the Record Layer's connection state encryption, hash, and
compression algorithms are initialized to null. The current
connection state is used for renegotiation messages.
7.4.1.1. Hello request Request
When this message will be sent:
The hello request message MAY be sent by the server at any time.
Meaning of this message:
Hello request is a simple notification that the client should
begin the negotiation process anew by sending a client hello
message when convenient. This message is not intended to
establish which side is the client or server but merely to
initiate a new negotiation. Servers SHOULD not send a
HelloRequest immediately upon the client's initial connection.
It is the client's job to send a ClientHello at that time.
This message will be ignored by the client if the client is
currently negotiating a session. This message may be ignored by
the client if it does not wish to renegotiate a session, or the
client may, if it wishes, respond with a no_renegotiation alert.
Since handshake messages are intended to have transmission
precedence over application data, it is expected that the
negotiation will begin before no more than a few records are
received from the client. If the server sends a hello request but
does not receive a client hello in response, it may close the
Dierks & Rescorla Standards Track [Page 35] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
connection with a fatal alert.
After sending a hello request, servers SHOULD not repeat the request
until the subsequent handshake negotiation is complete.
Dierks & Rescorla Standards Track [Page 36] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
Structure of this message:
struct { } HelloRequest;
Note: This message MUST NOT be included in the message hashes which that are
maintained throughout the handshake and used in the finished
messages and the certificate verify message.
7.4.1.2. Client hello Hello
When this message will be sent:
When a client first connects to a server it is required to send
the client hello as its first message. The client can also send a
client hello in response to a hello request or on its own
initiative in order to renegotiate the security parameters in an
existing connection.
Structure of this message:
The client hello message includes a random structure, which is
used later in the protocol.
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
gmt_unix_time
The current time and date in standard UNIX 32-bit format (seconds
since the midnight starting Jan 1, 1970, GMT, ignoring leap
seconds) according to the sender's internal clock. Clocks are not
required to be set correctly by the basic TLS Protocol; higher higher-
level or application protocols may define additional
requirements.
random_bytes
28 bytes generated by a secure random number generator.
The client hello message includes a variable length variable-length session
identifier. If not empty, the value identifies a session between the
same client and server whose security parameters the client wishes to
reuse. The session identifier MAY be from an earlier connection, this
connection, or from another currently active connection. The second
option is useful if the client only wishes to update the random
structures and derived values of a connection, while and the third option
Dierks & Rescorla Standards Track [Page 36] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
makes it possible to establish several independent secure connections
without repeating the full handshake protocol. These independent
connections may occur sequentially or simultaneously; a SessionID
becomes valid when the handshake negotiating it completes with the
exchange of Finished messages and persists until it is removed due to
aging or because
Dierks & Rescorla Standards Track [Page 37] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006 a fatal error was encountered on a connection
associated with the session. The actual contents of the SessionID are
defined by the server.
opaque SessionID<0..32>;
Warning:
Because the SessionID is transmitted without encryption or
immediate MAC protection, servers MUST not place confidential
information in session identifiers or let the contents of fake
session identifiers cause any breach of security. (Note that the
content of the handshake as a whole, including the SessionID, is
protected by the Finished messages exchanged at the end of the
handshake.)
The CipherSuite list, passed from the client to the server in the
client hello message, contains the combinations of cryptographic
algorithms supported by the client in order of the client's
preference (favorite choice first). Each CipherSuite defines a key
exchange algorithm, a bulk encryption algorithm (including secret key
length) and
length), a MAC algorithm. algorithm, and a PRF. The server will select a cipher
suite or, if no acceptable choices are presented, return a handshake
failure alert and close the connection.
uint8 CipherSuite[2]; /* Cryptographic suite selector */
The client hello includes a list of compression algorithms supported
by the client, ordered according to the client's preference.
enum { null(0), (255) } CompressionMethod;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
} ClientHello;
If the client wishes to use extensions (see Section XXX),
it may send an ExtendedClientHello:
struct
select (extensions_present) {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
}
Dierks & Rescorla Standards Track [Page 38] draft-ietf-tls-rfc4346-bis-02.txt 37] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
Extension client_hello_extension_list<0..2^16-1>; March 2007
} ExtendedClientHello;
These two messages ClientHello;
TLS allows extensions to follow the compression_methods field in an
extensions block. The presence of extensions can be distinguished detected by
determining whether there are bytes following what would be the compression_methods
at the end of the ClientHello. Note that this method of detecting
optional data differs from the normal TLS method of having a
variable-length field but is used for compatibility with TLS before
extensions were defined.
client_version
The version of the TLS protocol by which the client wishes to
communicate during this session. This SHOULD be the latest
(highest valued) version supported by the client. For this
version of the specification, the version will be 3.2 3.3 (See
Appendix E for details about backward compatibility).
random
A client-generated random structure.
session_id
The ID of a session the client wishes to use for this connection.
This field should be empty if no session_id is available available, or it
the client wishes to generate new security parameters.
cipher_suites
This is a list of the cryptographic options supported by the
client, with the client's first preference first. If the
session_id field is not empty (implying a session resumption
request) this vector MUST include at least the cipher_suite from
that session. Values are defined in Appendix A.5.
compression_methods
This is a list of the compression methods supported by the
client, sorted by client preference. If the session_id field is
not empty (implying a session resumption request) it must MUST include
the compression_method from that session. This vector must MUST
contain, and all implementations must MUST support,
CompressionMethod.null. Thus, a client and server will always be
able to agree on a compression method.
client_hello_extension_list
Clients MAY request extended functionality from servers by
sending data in the client_hello_extension_list. Here the new
"client_hello_extension_list" field contains a list of
extensions. The actual "Extension" format is defined in Section
XXX.
7.4.1.4.
Dierks & Rescorla Standards Track [Page 38] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
In the event that a client requests additional functionality using the extended client hello,
extensions, and this functionality is not supplied by the server, the
client MAY abort the handshake.
Dierks & Rescorla Standards Track [Page 39] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006 A server that supports the
extensions mechanism MUST accept only client hello messages in either
the original (TLS 1.0/TLS 1.1) ClientHello or the extended
ClientHello ormat, format defined in this document, and (as for all other
messages) MUST check that the amount of data in the message precisely
matches one of these formats; if not then it MUST send a fatal
"decode_error" alert.
After sending the client hello message, the client waits for a server
hello message. Any other handshake message returned by the server
except for a hello request is treated as a fatal error.
7.4.1.3. Server hello Hello
When this message will be sent:
The server will send this message in response to a client hello
message when it was able to find an acceptable set of algorithms.
If it cannot find such a match, it will respond with a handshake
failure alert.
Structure of this message:
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} ServerHello;
If the server is sending an extension, it should use the
ExtendedServerHello:
struct
select (extensions_present) {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
case false:
struct {};
case true:
Extension server_hello_extension_list<0..2^16-1>; extensions<0..2^16-1>;
} ExtendedServerHello;
These two messages
} ServerHello;
The presence of extensions can be distinguished detected by determining whether
there are bytes following what would be the compression_method field at the end of
the ServerHello.
Dierks & Rescorla Standards Track [Page 40] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
server_version
This field will contain the lower of that suggested by the client
in the client hello and the highest supported by the server. For
this version of the specification, the version is 3.2 3.2. (See
Appendix E for details about backward compatibility). compatibility.)
Dierks & Rescorla Standards Track [Page 39] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
random
This structure is generated by the server and MUST be
independently generated from the ClientHello.random.
session_id
This is the identity of the session corresponding to this
connection. If the ClientHello.session_id was non-empty, the
server will look in its session cache for a match. If a match is
found and the server is willing to establish the new connection
using the specified session state, the server will respond with
the same value as was supplied by the client. This indicates a
resumed session and dictates that the parties must proceed
directly to the finished messages. Otherwise this field will
contain a different value identifying the new session. The server
may return an empty session_id to indicate that the session will
not be cached and therefore cannot be resumed. If a session is
resumed, it must be resumed using the same cipher suite it was
originally negotiated with. Note that there is no requirement
that the server resume any session even if it had formerly
provided a session_id. Client MUST be prepared to do a full
negotiation -- including negotiating new cipher suites -- during
any handshake.
cipher_suite
The single cipher suite selected by the server from the list in
ClientHello.cipher_suites. For resumed sessions sessions, this field is
the value from the state of the session being resumed.
compression_method
The single compression algorithm selected by the server from the
list in ClientHello.compression_methods. For resumed sessions
this field is the value from the resumed session state.
server_hello_extension_list
A list of extensions. Note that only extensions offered by the
client can appear in the server's list.
7.4.1.4 Hello Extensions
The extension format for extended client hellos and extended server
hellos is:
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
enum {
cert_hash_types(TBD-BY-IANA), (65535)
Dierks & Rescorla Standards Track [Page 41] draft-ietf-tls-rfc4346-bis-02.txt 40] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006 March 2007
} ExtensionType;
Here:
- "extension_type" identifies the particular extension type.
- "extension_data" contains information specific to the particular
extension type.
The extension types defined in this document are:
enum {
server_name(0), max_fragment_length(1),
client_certificate_url(2), trusted_ca_keys(3),
truncated_hmac(4), status_request(5),
cert_hash_types(6), (65535)
} ExtensionType;
The list of defined extension types types, as defined in Section 2.3, is maintained
by the IANA. The
current list can Internet Assigned Numbers Authority (IANA). Thus an
application needs to be found at (http://www.iana.org/assignments/tls-
extensions). See sections 7.4.1.4.8 and 11.1 for more information on
how made to the IANA in order to obtain a new values are added.
Note that for all extension types (including those defined in
future), the
extension type MUST NOT appear value. Since there are subtle (and not so subtle)
interactions that may occur in the extended server
hello unless the same extension type appeared this protocol between new features and
existing features which may result in the corresponding
client hello. Thus clients MUST abort the handshake if they receive
an extension type a significant reduction in
overall security, new values SHALL be defined only through the extended server hello that they did not
request IETF
Consensus process specified in [IANA]. (This means that new
assignments can be made only via RFCs approved by the associated (extended) client hello.
Nonetheless "server oriented" IESG.) The
initial set of extensions may be provided is defined in the
future within this framework a companion document [TBD].
The following considerations should be taken into account when
designing new extensions:
- such an extension, say of type x,
would require the client Some cases where a server does not agree to first send an extension of type x are
error
conditions, and some simply a refusal to support a particular
feature. In general error alerts should be used for the former,
and a field in the
(extended) client hello with empty extension_data server extension response for the latter.
- Extensions should as far as possible be designed to indicate prevent any
attack that it
supports the extension type. In this case forces use (or non-use) of a particular feature by
manipulation of handshake messages. This principle should be
followed regardless of whether the client feature is offering the
capability believed to understand cause a
security problem.
Often the fact that the extension type, and fields are included in the server is taking
inputs to the client up on its offer.
Also note that Finished message hashes will be sufficient, but
extreme care is needed when multiple extensions of different types are
present in the extended client hello or the extended server hello, extension changes the extensions may appear meaning of
messages sent in any order. There MUST NOT the handshake phase. Designers and implementors
should be more than
one extension aware of the same type.
An extended client hello may be sent both when starting a new session
and when requesting session resumption. Indeed a client fact that
requests resumption of a session does not in general know whether until the
server will accept this request, handshake has been
authenticated, active attackers can modify messages and therefore it SHOULD send an
extended client hello if it insert,
remove, or replace extensions.
- It would normally do so for a new session.
In general the specification of each extension type must include a
discussion be technically possible to use extensions to change
major aspects of the effect design of TLS; for example the extension both during design of
cipher suite negotiation. This is not recommended; it would be
more appropriate to define a new sessions version of TLS - particularly
Dierks & Rescorla Standards Track [Page 42] draft-ietf-tls-rfc4346-bis-02.txt 41] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006 March 2007
since the TLS handshake algorithms have specific protection
against version rollback attacks based on the version number, and during resumed sessions.
Note also that all
the extensions defined in this document are
relevant only when a session is initiated. When a client includes one
or more possibility of the defined extension types version rollback should be a significant
consideration in an extended any major design change.
7.4.1.4.1 Cert Hash Types
The client hello
while requesting session resumption:
- If the resumption request is denied, the MAY use of the extensions
is negotiated as normal.
- If, on the other hand, the older session is resumed, then the
server MUST ignore the extensions and send a server hello
containing none of the extension types; in this case the
functionality of these extensions negotiated during the original
session initiation is applied "cert_hash_types" to the resumed session.
7.4.1.4.1 Server Name Indication
[TLS1.1] does not provide a mechanism for a client indicate to tell a server
the name of the
server it is contacting. It which hash functions may be desirable for
clients to provide this information to facilitate secure connections
to servers that host multiple 'virtual' servers at a single
underlying network address.
In order to provide the server name, clients MAY include an extension
of type "server_name" used in the (extended) client hello. signature on the
server's certificate. The "extension_data" field of this
extension SHALL contain
"ServerNameList" where:
struct {
NameType name_type;
select (name_type) {
case host_name: HostName;
} name;
} ServerName;
enum {
host_name(0), contains:
enum{
md5(0), sha1(1), sha256(2), sha384(3), sha512(4), (255)
} NameType;
opaque HostName<1..2^16-1>; HashType;
struct {
ServerName server_name_list<1..2^16-1>
HashType types<255>;
} ServerNameList;
Currently the only CertHashTypes;
These values indicate support for MD5 [MD5], SHA-1, SHA-256, SHA-384,
and SHA-512 [SHA] respectively. The server names supported are DNS hostnames, however MUST NOT send this does not imply
extension.
Clients SHOULD send this extension if they support any dependency of TLS on DNS, and algorithm
other name
Dierks & Rescorla Standards Track [Page 43] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
types may be added in the future (by an RFC than SHA-1. If this extension is not used, servers SHOULD
assume that Updates the client supports only SHA-1. Note: this
document). is a change
from TLS MAY treat provided server names 1.1 where there are no explicit rules but as opaque data and
pass a practical
matter one can assume that the names peer supports MD5 and types to the application.
"HostName" contains the fully qualified DNS hostname of the server,
as understood by the client. SHA-1.
7.4.2. Server Certificate
When this message will be sent:
The hostname is represented as a byte
string using UTF-8 encoding [UTF8], without server MUST send a trailing dot.
If certificate whenever the hostname labels contain only US-ASCII characters, then agreed-upon key
exchange method uses certificates for authentication (this
includes all key exchange methods defined in this document except
DH_anon). This message will always immediately follow the
client server
hello message.
Meaning of this message:
The certificate type MUST ensure that labels are separated only by be appropriate for the byte 0x2E,
representing selected cipher
suite's key exchange algorithm, and is generally an X.509v3
certificate. It MUST contain a key that matches the dot character U+002E (requirement 1 in section 3.1
of [IDNA] notwithstanding). If key exchange
method, as follows. Unless otherwise specified, the server needs to match signing
algorithm for the HostName
against names that contain non-US-ASCII characters, it certificate MUST perform
the conversion operation described in section 4 of [IDNA], treating be the HostName same as a "query string" (i.e. the AllowUnassigned flag algorithm
for the certificate key. Unless otherwise specified, the public
key MAY be of any length.
Dierks & Rescorla Standards Track [Page 42] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
Key Exchange Algorithm Certificate Key Type
RSA RSA public key; the certificate MUST
allow the key to be set). Note used for encryption.
DHE_DSS DSS public key.
DHE_RSA RSA public key that IDNA allows labels to can be separated by any of used for
signing.
DH_DSS Diffie-Hellman key. The algorithm used
to sign the
Unicode characters U+002E, U+3002, U+FF0E, and U+FF61, therefore
servers certificate MUST accept any of these characters as a label separator. If
the server only needs be DSS.
DH_RSA Diffie-Hellman key. The algorithm used
to match sign the HostName against names containing
exclusively ASCII characters, it certificate MUST compare ASCII names case-
insensitively.
Literal IPv4 be RSA.
All certificate profiles, and key and IPv6 addresses cryptographic formats are not permitted in "HostName". It
is RECOMMENDED that clients include an extension of type
"server_name" in the client hello whenever they locate a server
defined by the IETF PKIX working group [PKIX]. When a
supported name type.
A server that receives a client hello containing key usage
extension is present, the "server_name"
extension, MAY use digitalSignature bit MUST be set for the information contained in
key to be eligible for signing, as described above, and the extension
keyEncipherment bit MUST be present to
guide its selection of an appropriate allow encryption, as described
above. The keyAgreement bit must be set on Diffie-Hellman
certificates.
As CipherSuites that specify new key exchange methods are specified
for the TLS Protocol, they will imply certificate to return to format and the
client, and/or other aspects
required encoded keying information.
Structure of security policy. In this event, the
server SHALL include an extension message:
opaque ASN.1Cert<1..2^24-1>;
struct {
ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;
certificate_list
This is a sequence (chain) of type "server_name" X.509v3 certificates. The sender's
certificate must come first in the
(extended) server hello. The "extension_data" field of this
extension SHALL be empty.
If list. Each following
certificate must directly certify the server understood one preceding it. Because
certificate validation requires that root keys be distributed
independently, the client hello extension but does not
recognize self-signed certificate that specifies the server name, it SHOULD send an "unrecognized_name"
alert (which MAY
root certificate authority may optionally be fatal).
If an application negotiates a server name using an application
protocol, then upgrades to TLS, and a server_name extension is sent,
then omitted from the extension SHOULD contain
chain, under the same name assumption that was negotiated
in the application protocol. If the server_name is established remote end must already
possess it in order to validate it in any case.
The same message type and structure will be used for the TLS session handshake, the client SHOULD NOT attempt client's
response to a certificate request message. Note that a
different server name at the application layer.
7.4.1.4.2 Maximum Fragment Length Negotiation client MAY
send no certificates if it does not have an appropriate certificate
Dierks & Rescorla Standards Track [Page 44] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
By default, 43] draft-ietf-tls-rfc4346-bis-03.txt TLS uses fixed maximum plaintext fragment length of 2^14
bytes. It may be desirable for constrained clients to negotiate a
smaller maximum fragment length due to memory limitations or
bandwidth limitations.
In order March 2007
to negotiate smaller maximum fragment lengths, clients MAY
include an extension of type "max_fragment_length" send in response to the (extended)
client hello. The "extension_data" field of this extension SHALL
contain:
enum{
2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
} MaxFragmentLength;
whose value server's authentication request.
Note: PKCS #7 [PKCS7] is not used as the desired maximum fragment length. The allowed
values format for this field are: 2^9, 2^10, 2^11, and 2^12.
Servers that receive an the certificate
vector because PKCS #6 [PKCS6] extended client hello containing certificates are not
used. Also, PKCS #7 defines a
"max_fragment_length" extension, MAY accept SET rather than a SEQUENCE, making
the requested maximum
fragment length by including an extension task of type
"max_fragment_length" in parsing the list more difficult.
7.4.3. Server Key Exchange Message
When this message will be sent:
This message will be sent immediately after the (extended) server hello. The
"extension_data" field of
certificate message (or the server hello message, if this extension SHALL contain
"MaxFragmentLength" whose value is an
anonymous negotiation).
The server key exchange message is sent by the same as server only when
the requested maximum
fragment length.
If a server receives certificate message (if sent) does not contain enough
data to allow the client to exchange a maximum fragment length negotiation request premaster secret. This is
true for a value other than the allowed values, it MUST abort following key exchange methods:
DHE_DSS
DHE_RSA
DH_anon
It is not legal to send the
handshake with an "illegal_parameter" alert. Similarly, if server key exchange message for the
following key exchange methods:
RSA
DH_DSS
DH_RSA
Meaning of this message:
This message conveys cryptographic information to allow the
client to communicate the premaster secret: a Diffie-Hellman
public key with which the client
receives can complete a maximum fragment length negotiation response that differs
from key exchange
(with the length it requested, it MUST also abort result being the handshake with
an "illegal_parameter" alert.
Once premaster secret) or a maximum fragment length public key for
some other than 2^14 has been successfully
negotiated, the client and server MUST immediately begin fragmenting
messages (including handshake messages), to ensure algorithm.
As additional CipherSuites are defined for TLS that no fragment
larger than include new key
exchange algorithms, the negotiated length is sent. Note that TLS already
requires clients server key exchange message will be sent if
and servers to support fragmentation of handshake
messages.
The negotiated length applies only if the certificate type associated with the key exchange
algorithm does not provide enough information for the duration of client to
exchange a premaster secret.
If the session
including session resumptions.
The negotiated length limits SignatureAlgorithm being used to sign the input that ServerKeyExchange
message is DSA, the record layer may
process without fragmentation (that is, hash function used MUST be SHA-1. If the maximum value of
TLSPlaintext.length; see [TLS] section 6.2.1). Note that
SignatureAlgorithm it must be the output same hash function used in the
signature of the record layer may be larger. For example, if server's certificate (found in the negotiated
length Certificate)
message. This algorithm is 2^9=512, then for currently defined cipher suites and when
null compression denoted Hash below. Hash.length is used, the record layer output can be at most 793
Dierks & Rescorla Standards Track [Page 45] draft-ietf-tls-rfc4346-bis-02.txt 44] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
bytes: 5 bytes of headers, 512 bytes of application data, 256 bytes March 2007
length of padding, and 20 bytes the output of MAC. That means that in algorithm.
Structure of this event a TLS
record layer peer receiving a TLS record layer message larger than
793 bytes may discard the message and send a "record_overflow" alert,
without decrypting the message.
7.4.1.4.3 Client Certificate URLs
Ordinarily, when client authentication is performed, client
certificates are sent by clients to servers during message:
enum { diffie_hellman } KeyExchangeAlgorithm;
struct {
opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>;
} ServerDHParams; /* Ephemeral DH parameters */
dh_p
The prime modulus used for the TLS handshake.
It may be desirable Diffie-Hellman operation.
dh_g
The generator used for constrained clients to send certificate URLs
in place of certificates, so that they do not need to store their
certificates and can therefore save memory.
In order to negotiate to send certificate URLs to a server, clients
MAY include an extension of type "client_certificate_url" in the
(extended) client hello. Diffie-Hellman operation.
dh_Ys
The "extension_data" field of this
extension SHALL be empty.
(Note that it is necessary to negotiate use server's Diffie-Hellman public value (g^X mod p).
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
};
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
};
} ServerParams;
params
The server's key exchange parameters.
signed_params
For non-anonymous key exchanges, a hash of client certificate
URLs in order the corresponding
params value, with the signature appropriate to avoid "breaking" existing TLS 1.0 servers.)
Servers that receive an extended client hello containing a
"client_certificate_url" extension, MAY indicate that they are
willing to accept certificate URLs by including an extension of type
"client_certificate_url" in the (extended) server hello. The
"extension_data" field of this extension SHALL be empty.
After negotiation of the use of client certificate URLs has been
successfully completed (by exchanging hellos including
"client_certificate_url" extensions), clients MAY send a
"CertificateURL" message in place of a "Certificate" message. See
Section XXX.
7.4.1.4.4 Trusted CA Indication
Constrained clients that, due to memory limitations, possess only a
small number of CA root keys, may wish to indicate to servers which
root keys they possess, in order to avoid repeated handshake
failures.
In order to indicate which CA root keys they possess, clients MAY
include an extension of type "trusted_ca_keys" in the (extended)
client hello. The "extension_data" field of this extension SHALL
contain "TrustedAuthorities" where:
struct {
TrustedAuthority trusted_authorities_list<0..2^16-1>; hash
applied.
hash
Hash(ClientHello.random + ServerHello.random + ServerParams)
sha_hash
SHA1(ClientHello.random + ServerHello.random + ServerParams)
Dierks & Rescorla Standards Track [Page 46] draft-ietf-tls-rfc4346-bis-02.txt 45] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006 March 2007
enum { anonymous, rsa, dsa } TrustedAuthorities; SignatureAlgorithm;
struct {
IdentifierType identifier_type;
select (identifier_type) (SignatureAlgorithm) {
case pre_agreed: anonymous: struct {};
case key_sha1_hash: SHA1Hash; { };
case x509_name: DistinguishedName; rsa:
digitally-signed struct {
opaque hash[Hash.length];
};
case cert_sha1_hash: SHA1Hash;
} identifier; dsa:
digitally-signed struct {
opaque sha_hash[20];
};
};
};
} TrustedAuthority; Signature;
7.4.4. Certificate Request
When this message will be sent:
A non-anonymous server can optionally request a certificate from
the client, if appropriate for the selected cipher suite. This
message, if sent, will immediately follow the Server Key Exchange
message (if it is sent; otherwise, the Server Certificate
message).
Structure of this message:
enum {
pre_agreed(0), key_sha1_hash(1), x509_name(2),
cert_sha1_hash(3),
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20),
(255)
} IdentifierType; ClientCertificateType;
opaque DistinguishedName<1..2^16-1>;
Here "TrustedAuthorities" provides
struct {
ClientCertificateType certificate_types<1..2^8-1>;
HashType certificate_hash<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
certificate_types
This field is a list of CA root key identifiers
that the client possesses. Each CA root key is identified via
either:
- "pre_agreed" - no CA root key identity supplied.
- "key_sha1_hash" - contains the SHA-1 hash types of the CA root key.
For
DSA and ECDSA keys, this is the hash certificates requested,
sorted in order of the "subjectPublicKey"
value. For RSA keys, the hash is server's preference.
Dierks & Rescorla Standards Track [Page 46] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
certificate_types
A list of the big-endian byte string
representation types of certificate types which the modulus without any initial 0-valued bytes.
(This copies the client may
offer.
rsa_sign a certificate containing an RSA key hash formats deployed in other
environments.)
- "x509_name" - contains the DER-encoded X.509 DistinguishedName
of
the CA.
- "cert_sha1_hash" - contains the SHA-1 hash of
dss_sign a DER-encoded
Certificate certificate containing the CA root key.
Note that clients may include none, some, or all of the CA root keys
they possess in this extension.
Note also that it is possible that a DSS key hash or
rsa_fixed_dh a Distinguished Name
alone may not uniquely identify certificate signed with RSA and containing
a static DH key.
dss_fixed_dh a certificate issuer - for example if signed with DSS and containing
a particular CA has multiple static DH key pairs - however here we assume
Certificate types rsa_sign and dss_sign SHOULD contain
certificates signed with the same algorithm. However, this is the case following the use
not required. This is a holdover from TLS 1.0 and 1.1.
certificate_hash
A list of Distinguished Names acceptable hash algorithms to identify
certificate issuers be used in TLS.
Dierks & Rescorla Standards Track [Page 47] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
The option to include no CA root keys is included to allow the client
to indicate possession of some pre-defined set
certificate signatures.
certificate_authorities
A list of CA root keys.
Servers that receive a client hello containing the "trusted_ca_keys"
extension, MAY use the information contained in the extension to
guide their selection distinguished names of an appropriate acceptable certificate chain to return
to the client. In this event, the server SHALL include an extension
of type "trusted_ca_keys" in the (extended) server hello. The
"extension_data" field of
authorities. These distinguished names may specify a desired
distinguished name for a root CA or for a subordinate CA;
thus, this extension SHALL message can be empty.
7.4.1.4.5 Truncated HMAC
Currently defined TLS cipher suites use the MAC construction HMAC
with either MD5 or SHA-1 [HMAC] used both to authenticate record layer
communications. In TLS describe known roots
and a desired authorization space. If the entire output
certificate_authorities list is empty then the client MAY
send any certificate of the hash function appropriate
ClientCertificateType, unless there is
used as some external
arrangement to the MAC tag. However it contrary.
New ClientCertificateType values are assigned by IANA as described in
Section 11.
Note: Values listed as RESERVED may not be desirable used. They were
used in constrained
environments SSLv3.
Note: DistinguishedName is derived from [X501]. DistinguishedNames are
represented in DER-encoded format.
Note: It is a fatal handshake_failure alert for an anonymous server to save bandwidth
request client authentication.
7.4.5 Server hello done
When this message will be sent:
The server hello done message is sent by truncating the output of the hash
function to 80 bits when forming MAC tags.
In order server to negotiate indicate
the use of 80-bit truncated HMAC, clients MAY
include an extension end of type "truncated_hmac" in the extended server hello and associated messages. After
Dierks & Rescorla Standards Track [Page 47] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
sending this message, the server will wait for a client
hello. The "extension_data" field response.
Meaning of this extension SHALL be empty.
Servers that receive an extended hello containing a "truncated_hmac"
extension, MAY agree message:
This message means that the server is done sending messages to use a truncated HMAC by including an
extension of type "truncated_hmac",
support the key exchange, and the client can proceed with empty "extension_data", in its
phase of the key exchange.
Upon receipt of the extended server hello.
Note hello done message, the client SHOULD
verify that the server provided a valid certificate, if new cipher suites are added that do not use HMAC, required
and check that the session negotiates one server hello parameters are acceptable.
Structure of these cipher suites, this extension message:
struct { } ServerHelloDone;
7.4.6. Client Certificate
When this message will have no effect. It be sent:
This is strongly recommended that any new cipher
suites using other MACs consider the MAC size as an integral part of first message the cipher suite definition, taking into account both security and
bandwidth considerations.
If HMAC truncation has been successfully negotiated during client can send after receiving a TLS
handshake, and
server hello done message. This message is only sent if the negotiated cipher suite uses HMAC, both
server requests a certificate. If no suitable certificate is
available, the client
and SHOULD send a certificate message
containing no certificates. That is, the certificate_list
structure has a length of zero. If client authentication is
required by the server pass this fact to for the TLS record layer along handshake to continue, it may
respond with a fatal handshake failure alert. Client certificates
are sent using the
other negotiated security parameters. Subsequently during Certificate structure defined in Section
7.4.2.
Note: When using a static Diffie-Hellman based key exchange method
(DH_DSS or DH_RSA), if client authentication is requested, the
session, clients
Diffie-Hellman group and servers generator encoded in the client's
certificate MUST use truncated HMACs, calculated as match the server specified in [HMAC]. That is, CipherSpec.hash_size Diffie-Hellman
parameters if the client's parameters are to be used for the key
exchange.
7.4.7. Client Key Exchange Message
When this message will be sent:
This message is 10 bytes, and
only always sent by the client. It MUST immediately
follow the client certificate message, if it is sent. Otherwise
it MUST be the first 10 bytes of message sent by the HMAC output are transmitted and
checked. Note that this extension does not affect client after it receives
the calculation server hello done message.
Meaning of this message:
With this message, the PRF as part premaster secret is set, either though
direct transmission of handshaking the RSA-encrypted secret, or key derivation.
The negotiated HMAC truncation size applies for by the duration
transmission of the
session including session resumptions. Diffie-Hellman parameters that will allow each
Dierks & Rescorla Standards Track [Page 48] draft-ietf-tls-rfc4346-bis-02.txt draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
7.4.1.4.6 Certificate Status Request
Constrained clients may wish to use a certificate-status protocol
such as OCSP [OCSP] March 2007
side to check agree upon the validity of server certificates, in
order to avoid transmission of CRLs and therefore save bandwidth on
constrained networks. This extension allows for such information to
be sent in same premaster secret. When the TLS handshake, saving roundtrips key
exchange method is DH_RSA or DH_DSS, client certification has
been requested, and resources.
In order to indicate their desire the client was able to receive respond with a
certificate status
information, clients MAY include an extension of type
"status_request" in that contained a Diffie-Hellman public key whose
parameters (group and generator) matched those specified by the (extended) client hello. The
"extension_data" field of
server in its certificate, this extension SHALL message MUST not contain
"CertificateStatusRequest" where:
struct {
CertificateStatusType status_type;
select (status_type) {
case ocsp: OCSPStatusRequest;
} request;
} CertificateStatusRequest;
enum { ocsp(1), (255) } CertificateStatusType; any
data.
Structure of this message:
The choice of messages depends on which key exchange method has
been selected. See Section 7.4.3 for the KeyExchangeAlgorithm
definition.
struct {
ResponderID responder_id_list<0..2^16-1>;
Extensions request_extensions;
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} OCSPStatusRequest;
opaque ResponderID<1..2^16-1>;
In the OCSPStatusRequest, the "ResponderIDs" provides a list exchange_keys;
} ClientKeyExchange;
7.4.7.1. RSA Encrypted Premaster Secret Message
Meaning of OCSP
responders that this message:
If RSA is being used for key agreement and authentication, the
client trusts. A zero-length "responder_id_list"
sequence has generates a 48-byte premaster secret, encrypts it using
the special meaning that public key from the responders are implicitly
known to server's certificate and sends the server - e.g., by prior arrangement. "Extensions" result
in an encrypted premaster secret message. This structure is a
DER encoding
variant of OCSP request extensions.
Both "ResponderID" the client key exchange message and "Extensions" are DER-encoded ASN.1 types as
defined in [OCSP]. "Extensions" is imported from [PKIX]. A zero-
length "request_extensions" value means that there are no extensions
(as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for
the "Extensions" type).
In the case a message
in itself.
Structure of this message:
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
client_version
The latest (newest) version supported by the "id-pkix-ocsp-nonce" OCSP extension, [OCSP] client. This is
unclear about its encoding; for clarification,
used to detect version roll-back attacks. Upon receiving the nonce MUST be a
DER-encoded OCTET STRING, which is encapsulated as another OCTET
STRING (note
premaster secret, the server SHOULD check that implementations based on an existing OCSP client
will need to be checked for conformance to this requirement). value
matches the value transmitted by the client in the client
hello message.
random
46 securely-generated random bytes.
struct {
public-key-encrypted PreMasterSecret pre_master_secret;
Dierks & Rescorla Standards Track [Page 49] draft-ietf-tls-rfc4346-bis-02.txt draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
Servers that receive a client hello containing the "status_request"
extension, MAY return a suitable certificate status response to March 2007
} EncryptedPreMasterSecret;
pre_master_secret
This random value is generated by the client along with their certificate. If OCSP and is requested, they
SHOULD use the information contained in used to
generate the extension when selecting
an OCSP responder, and SHOULD include request_extensions master secret, as specified in the OCSP
request.
Servers return a certificate response along with their certificate by
sending a "CertificateStatus" message immediately after the
"Certificate" message (and before any "ServerKeyExchange" or
"CertificateRequest" messages). Section XXX describes the
CertificateStatus message.
7.4.1.4.7 Cert Hash Types
The client MAY use the "cert_hash_types" to indicate 8.1.
An attack discovered by Daniel Bleichenbacher [BLEI] can be used to the
attack a TLS server which hash functions may be used in the signature on the server's
certificate. is using PKCS#1 v 1.5 encoded RSA. The "extension_data" field
attack takes advantage of this extension contains:
enum{
md5(0), sha1(1), sha256(2), sha384(3), sha512(4), (255)
} HashType;
struct {
HashType<255> types;
} CertHashTypes;
These values indicate support for MD5 [MD5], SHA-1, SHA-256, SHA-384,
and SHA-512 [SHA] respectively. The the fact that by failing in different ways,
a TLS server MUST NOT send this
extension.
Clients SHOULD send this extension if they support any algorithm
other than SHA-1. If this extension can be coerced into revealing whether a particular
message, when decrypted, is not used, servers SHOULD
assume that the client supports only SHA-1. Note: properly PKCS#1 v1.5 formatted or not.
In order to avoid this is vulnerability, implementations MUST treat
incorrectly formatted messages in a change manner indistinguishable from TLS 1.1 where there are no explicit rules but as
correctly formatted RSA blocks. Thus, when it receives an incorrectly
formatted RSA block, a practical
matter one can assume that the peer supports MD5 server should generate a random 48-byte value
and SHA-1.
HashType values are divided into three groups:
1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
reserved for IETF Standards Track protocols.
2. Values from 64 decimal (0x40) through 223 decimal (0xDF) inclusive
are reserved for assignment for non-Standards Track methods.
3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
inclusive are reserved for private use.
Dierks & Rescorla Standards Track [Page 50] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
Additional information describing proceed using it as the role of IANA in premaster secret. Thus, the
allocation server will
act identically whether the received RSA block is correctly encoded
or not.
[PKCS1B] defines a newer version of HashType code points PKCS#1 encoding that is described
in Section 11.
7.4.1.4.8 Procedure more
secure against the Bleichenbacher attack. However, for Defining New Extensions
The list maximal
compatibility with TLS 1.0, TLS 1.1 retains the original encoding. No
variants of extension types, as defined in Section 2.3, is
maintained by the Internet Assigned Numbers Authority (IANA). Thus
an application needs to be made Bleichenbacher attack are known to exist provided
that the IANA in order to obtain a new
extension type value. Since there above recommendations are subtle (and not so subtle)
interactions that may occur in this protocol between new features and
existing features which may result followed.
Implementation Note: Public-key-encrypted data is represented as an
opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted
PreMasterSecret in a significant reduction ClientKeyExchange is preceded by two length
bytes. These bytes are redundant in
overall security, new values SHALL be defined only through the IETF
Consensus process specified case of RSA because the
EncryptedPreMasterSecret is the only data in [IANA].
(This means that new assignments the ClientKeyExchange
and its length can therefore be made only via RFCs approved
by the IESG.) unambiguously determined. The following considerations should be taken into account when
designing new extensions:
- All SSLv3
specification was not clear about the encoding of public-key-
encrypted data, and therefore many SSLv3 implementations do not
include the extensions defined in this document follow the
convention that for each extension that a client requests and that length bytes, encoding the server understands, RSA encrypted data
directly in the server replies with an extension ClientKeyExchange message.
This specification requires correct encoding of the same type.
- Some cases where a server does not agree
EncryptedPreMasterSecret complete with length bytes. The resulting
PDU is incompatible with many SSLv3 implementations. Implementors
upgrading from SSLv3 MUST modify their implementations to an extension are error
conditions, generate
and some simply a refusal accept the correct encoding. Implementors who wish to support a particular
feature. In general error alerts should be used for the former,
compatible with both SSLv3 and a field in the server extension response for the latter.
- Extensions should as far as possible be designed to prevent any
attack that forces use (or non-use) of a particular feature by
manipulation of handshake messages. This principle TLS should be
followed regardless of whether make their implementation's
behavior dependent on the feature protocol version.
Implementation Note: It is believed to cause a
security problem.
Often the fact now known that the extension fields remote timing-based attacks
on SSL are included in the
inputs to the Finished message hashes will be sufficient, but
extreme care is needed possible, at least when the extension changes the meaning of
messages sent in the handshake phase. Designers client and implementors
should be aware of server are on the fact
same LAN. Accordingly, implementations that until the handshake has been
authenticated, active attackers can modify messages and insert,
remove, or replace extensions.
- It would be technically possible to use extensions to change major
aspects of the design of TLS; for example the design of cipher static RSA keys MUST
Dierks & Rescorla Standards Track [Page 51] draft-ietf-tls-rfc4346-bis-02.txt 50] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
suite negotiation. March 2007
use RSA blinding or some other anti-timing technique, as described in
[TIMING].
Note: The version number in the PreMasterSecret MUST be the version
offered by the client in the ClientHello.version, not the version
negotiated for the connection. This feature is not recommended; it would be more
appropriate designed to define a new prevent
rollback attacks. Unfortunately, many implementations use the
negotiated version of TLS - particularly instead and therefore checking the version number
may lead to failure to interoperate with such incorrect client
implementations. Client implementations MUST and Server
implementations MAY check the version number. In practice, since the
TLS handshake algorithms have specific protection against
version rollback MACs prevent downgrade and no good attacks based are known on
those MACs, ambiguity is not considered a serious security risk.
Note that if servers choose to to check the version number, and the
possibility of version rollback should be a significant
consideration in any major design change.
7.4.2. Server certificate
When this message will be sent:
The server they MUST send a certificate whenever
randomize the agreed-upon key
exchange method is not PreMasterSecret in case of error, rather than generate
an anonymous one. This message will
always immediately follow alert, in order to avoid variants on the server hello message. Bleichenbacher attack.
[KPR03]
7.4.7.1. Client Diffie-Hellman Public Value
Meaning of this message:
The certificate type MUST be appropriate
This structure conveys the client's Diffie-Hellman public value
(Yc) if it was not already included in the client's certificate.
The encoding used for Yc is determined by the selected cipher
suite's key exchange algorithm, and enumerated
PublicValueEncoding. This structure is generally an X.509v3
certificate. It MUST contain a key which matches variant of the client
key exchange method, as follows. Unless otherwise specified, the
signing
algorithm for message, and not a message in itself.
Structure of this message:
enum { implicit, explicit } PublicValueEncoding;
implicit
If the client certificate MUST already contains a suitable Diffie-
Hellman key, then Yc is implicit and does not need to be sent
again. In this case, the same as the
algorithm for the certificate key. Unless otherwise specified,
the public client key MAY exchange message will be of any length.
Key Exchange Algorithm Certificate Key Type
RSA RSA public key; the certificate
sent, but it MUST
allow the key be empty.
explicit
Yc needs to be used for encryption.
DHE_DSS DSS public key.
DHE_RSA RSA sent.
struct {
select (PublicValueEncoding) {
case implicit: struct { };
case explicit: opaque dh_Yc<1..2^16-1>;
} dh_public;
} ClientDiffieHellmanPublic;
dh_Yc
The client's Diffie-Hellman public key which can value (Yc).
Dierks & Rescorla Standards Track [Page 51] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
7.4.8. Certificate verify
When this message will be used for
signing.
DH_DSS Diffie-Hellman key. The algorithm sent:
This message is used to sign the provide explicit verification of a client
certificate. This message is only sent following a client
certificate MUST be DSS.
DH_RSA that has signing capability (i.e. all certificates
except those containing fixed Diffie-Hellman key. The algorithm used
to sign the certificate MUST be RSA.
All certificate profiles, key and cryptographic formats are defined
by the IETF PKIX working group [PKIX]. parameters). When a key usage extension is
present, the digitalSignature bit
sent, it MUST be set for the key to be
eligible for signing, as described above, and immediately follow the keyEncipherment bit
MUST be present to allow encryption, as described above. The
keyAgreement bit must be set on Diffie-Hellman certificates.
Dierks & Rescorla Standards Track [Page 52] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
As CipherSuites which specify new client key exchange methods are specified
for the TLS Protocol, they will imply certificate format and the
required encoded keying information. message.
Structure of this message:
opaque ASN.1Cert<1..2^24-1>;
struct {
ASN.1Cert certificate_list<0..2^24-1>;
Signature signature;
} Certificate;
certificate_list
This is a sequence (chain) of X.509v3 certificates. CertificateVerify;
The sender's
certificate must come first Signature type is defined in 7.4.3. If the list. Each following
certificate must directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate which specifies the
root certificate authority may optionally be omitted from the
chain, under the assumption that SignatureAlgorithm
is DSA, then the remote end sha_hash value must already
possess it in order to validate be used. If it in any case.
The is RSA,
the same message type and structure will function (denoted Hash) must be used as was used to
create the signature for the client's
response certificate.
CertificateVerify.signature.hash
Hash(handshake_messages);
CertificateVerify.signature.sha_hash
SHA(handshake_messages);
Here handshake_messages refers to a certificate request message. Note that a all handshake messages sent or
received starting at client MAY
send no certificates if it does not have an appropriate certificate
to send in response hello up to the server's authentication request.
Note: PKCS #7 [PKCS7] is but not used as including this
message, including the format for type and length fields of the certificate
vector because PKCS #6 [PKCS6] extended certificates are not
used. Also PKCS #7 defines a SET rather than a SEQUENCE, making handshake
messages. This is the task concatenation of parsing all the list more difficult.
7.4.3. Server key exchange message Handshake structures
as defined in 7.4 exchanged thus far.
7.4.9. Finished
When this message will be sent:
This
A finished message will be is always sent immediately after a change
cipher spec message to verify that the server
certificate key exchange and
authentication processes were successful. It is essential that a
change cipher spec message (or be received between the server hello message, if other
handshake messages and the Finished message.
Meaning of this is an
anonymous negotiation). message:
The server key exchange finished message is sent by the server only when first protected with the server certificate message (if sent) does not contain enough
data to allow just-
negotiated algorithms, keys, and secrets. Recipients of finished
messages MUST verify that the client to exchange contents are correct. Once a premaster secret. This is
true for side
has sent its Finished message and received and validated the following key exchange methods:
DHE_DSS
DHE_RSA
DH_anon
It is not legal
Finished message from its peer, it may begin to send and receive
application data over the server key exchange message for the connection.
Dierks & Rescorla Standards Track [Page 53] draft-ietf-tls-rfc4346-bis-02.txt 52] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
following key exchange methods:
RSA
DH_DSS
DH_RSA
Meaning of this message:
This message conveys cryptographic information to allow March 2007
struct {
opaque verify_data[12];
} Finished;
verify_data
PRF(master_secret, finished_label, Hash(handshake_messages))[0..11];
finished_label
For Finished messages sent by the
client to communicate client, the premaster secret: either an RSA public
key to encrypt the premaster secret with, or a Diffie-Hellman
public key with which string "client
finished". For Finished messages sent by the client can complete a key exchange
(with server, the result being
string "server finished".
Hash denotes the premaster secret.)
As additional CipherSuites are defined negotiated hash used for TLS which include new key
exchange algorithms, the server key exchange message will PRF. If a new
PRF is defined, then this hash MUST be sent if
and only if specified.
handshake_messages
All of the certificate type associated with data from all messages in this handshake (not
including any HelloRequest messages) up to but not including
this message. This is only data visible at the key exchange
algorithm handshake
layer and does not provide enough information for the client to
exchange a premaster secret.
If include record layer headers. This is the SignatureAlgorithm being used to sign
concatenation of all the ServerKeyExchange Handshake structures as defined in
7.4, exchanged thus far.
It is a fatal error if a finished message is DSA, not preceded by a change
cipher spec message at the hash function used MUST be SHA-1. If appropriate point in the
SignatureAlgorithm it must handshake.
The value handshake_messages includes all handshake messages starting
at client hello up to, but not including, this finished message. This
may be the same hash function used different from handshake_messages in Section 7.4.9 because it
would include the
signature of the server's certificate (found in verify message (if sent). Also, the Certificate)
message. This algorithm is denoted Hash below. Hash.length is
handshake_messages for the
length of finished message sent by the output of client will
be different from that algorithm.
Structure of this message:
enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
struct {
opaque rsa_modulus<1..2^16-1>;
opaque rsa_exponent<1..2^16-1>;
} ServerRSAParams;
rsa_modulus
The modulus for the finished message sent by the server,
because the one that is sent second will include the prior one.
Note: Change cipher spec messages, alerts and, any other record types
are not handshake messages and are not included in the hash
computations. Also, Hello Request messages are omitted from
handshake hashes.
8. Cryptographic Computations
In order to begin connection protection, the TLS Record Protocol
requires specification of a suite of algorithms, a master secret, and
the server's temporary RSA key.
rsa_exponent client and server random values. The public exponent of authentication, encryption,
and MAC algorithms are determined by the server's temporary RSA key.
struct {
opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>;
} ServerDHParams; /* Ephemeral DH parameters */
dh_p cipher_suite selected by the
server and revealed in the server hello message. The prime modulus used for compression
algorithm is negotiated in the Diffie-Hellman operation. hello messages, and the random values
are exchanged in the hello messages. All that remains is to calculate
Dierks & Rescorla Standards Track [Page 54] draft-ietf-tls-rfc4346-bis-02.txt 53] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
dh_g
The generator used for March 2007
the Diffie-Hellman operation.
dh_Ys
The server's Diffie-Hellman public value (g^X mod p).
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
};
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
case rsa:
ServerRSAParams params;
};
} ServerParams;
params
The server's key exchange parameters.
signed_params master secret.
8.1. Computing the Master Secret
For non-anonymous all key exchanges, a hash of the corresponding
params value, with exchange methods, the signature appropriate same algorithm is used to that hash
applied.
hash
Hash(ClientHello.random + ServerHello.random + ServerParams)
sha_hash
SHA1(ClientHello.random + ServerHello.random + ServerParams)
enum { anonymous, rsa, dsa } SignatureAlgorithm;
struct {
select (SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
digitally-signed struct {
Dierks & Rescorla Standards Track [Page 55] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
opaque hash[Hash.length];
};
case dsa:
digitally-signed struct {
opaque sha_hash[20];
};
};
};
} Signature;
7.4.4. CertificateStatus
If a server returns a
"CertificateStatus" message, then the server MUST have included an
extension of type "status_request" with empty "extension_data" in convert
the
extended server hello.
struct {
CertificateStatusType status_type;
select (status_type) {
case ocsp: OCSPResponse;
} response;
} CertificateStatus;
opaque OCSPResponse<1..2^24-1>;
An "ocsp_response" contains a complete, DER-encoded OCSP response
(using pre_master_secret into the ASN.1 type OCSPResponse defined in [OCSP]). Note that
only one OCSP response may master_secret. The pre_master_secret
should be sent. deleted from memory once the master_secret has been
computed.
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
[0..47];
The "CertificateStatus" message master secret is conveyed using the handshake
message type "certificate_status".
Note that a server MAY also choose not to send a "CertificateStatus"
message, even if it receives a "status_request" extension in the
client hello message.
Note in addition that servers MUST NOT send the "CertificateStatus"
message unless it received a "status_request" extension always exactly 48 bytes in length. The length of
the client
hello message.
Clients requesting an OCSP response, premaster secret will vary depending on key exchange method.
8.1.1. RSA
When RSA is used for server authentication and receiving an OCSP response
in key exchange, a "CertificateStatus" message MUST check
48-byte pre_master_secret is generated by the OCSP response client, encrypted under
the server's public key, and
abort sent to the handshake if server. The server uses its
private key to decrypt the response is not satisfactory.
7.4.5. Certificate request
Dierks & Rescorla Standards Track [Page 56] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
When this message will be sent:
A non-anonymous server can optionally request a certificate from pre_master_secret. Both parties then
convert the client, if appropriate for pre_master_secret into the selected cipher suite. This
message, if sent, will immediately follow master_secret, as specified
above.
8.1.2. Diffie-Hellman
A conventional Diffie-Hellman computation is performed. The
negotiated key (Z) is used as the Server Key Exchange
message (if it pre_master_secret, and is sent; otherwise, converted
into the Server Certificate
message).
Structure master_secret, as specified above. Leading bytes of this message:
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20),
(255)
} ClientCertificateType;
opaque DistinguishedName<1..2^16-1>;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
HashType certificate_hash<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
certificate_types
This field Z that
contain all zero bits are stripped before it is a list of used as the types of certificates requested,
sorted in order of
pre_master_secret.
Note: Diffie-Hellman parameters are specified by the server and may
be either ephemeral or contained within the server's preference.
certificate_types
A list of certificate.
9. Mandatory Cipher Suites
In the types absence of certificate types which the client may
offer.
rsa_sign a certificate containing an RSA key
dss_sign a certificate containing a DSS key
rsa_fixed_dh a certificate signed with RSA and containing
a static DH key.
dss_fixed_dh application profile standard specifying
otherwise, a certificate signed with DSS TLS compliant application MUST implement the cipher
suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
10. Application Data Protocol
Application data messages are carried by the Record Layer and containing
a static DH key
Certificate types rsa_sign are
fragmented, compressed and dss_sign SHOULD contain
certificates signed with encrypted based on the same algorithm. However, this is
not required. This is a holdover from TLS 1.0 and 1.1.
certificate_hash
A list of acceptable hash algorithms current connection
state. The messages are treated as transparent data to be used in
certificate signatures.
certificate_authorities the record
layer.
Dierks & Rescorla Standards Track [Page 57] draft-ietf-tls-rfc4346-bis-02.txt 54] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
A list of the distinguished names of acceptable certificate
authorities. These distinguished names may specify a desired
distinguished name for a root CA or for a subordinate CA;
thus, this message can be used both to describe known roots March 2007
11. Security Considerations
Security issues are discussed throughoutthis memo, especially in
Appendices D, E, and a desired authorization space. If the
certificate_authorities list is empty then the client MAY
send any certificate of the appropriate
ClientCertificateType, unless there F.
12. IANA Considerations
This document uses several registries that were originally created in
[RFC4346]. IANA is some external
arrangement requested to the contrary. update (has updated) these to
reference this document. The registries and their allocation policies
(unchanged from [RFC4346]) are listed below.
o TLS ClientCertificateType Identifiers Registry: Future
values are divided into three groups:
1. Values from 0 (zero) through 63 decimal (0x3F) in the range 0-63 (decimal) inclusive are
reserved for IETF assigned via
Standards Track protocols.
2. Action [RFC2434]. Values from 64 decimal (0x40) through 223 decimal (0xDF) in the range 64-223
(decimal) inclusive are reserved for assignment for non-Standards
Track methods.
3. assigned Specification Required
[RFC2434]. Values from 224 decimal (0xE0) through 255 decimal (0xFF) 224-255 (decimal) inclusive are
reserved for private use.
Additional information describing Private Use [RFC2434].
o TLS Cipher Suite Registry: Future values with the role of IANA first byte
in the
allocation of ClientCertificateType code points is described
in Section 11.
Note: range 0-191 (decimal) inclusive are assigned via
Standards Action [RFC2434]. Values listed as RESERVED may not be used. They were used in
SSLv3.
Note: DistinguishedName is derived from [X501]. DistinguishedNames with the first byte in
the range 192-254 (decimal) are
represented assigned via Specification
Required [RFC2434]. Values with the first byte 255 (decimal)
are reserved for Private Use [RFC2434].
o TLS ContentType Registry: Future values are allocated via
Standards Action [RFC2434].
o TLS Alert Registry: Future values are allocated via
Standards Action [RFC2434].
o TLS HandshakeType Registry: Future values are allocated via
Standards Action [RFC2434].
This document also uses a registry originally created in DER-encoded format.
Note: It [RFC4366].
IANA is a fatal handshake_failure alert for an anonymous server requested to
request client authentication.
7.4.6. Server hello done
When update (has updated) it to reference this message will be sent:
document. The server hello done message is sent by the server to indicate
the end of the server hello registry and associated messages. After
sending this message the server will wait for a client response.
Meaning of this message:
This message means that the server its allocation policy (unchanged from
[RFC4366]) is done sending messages listed below:.
o TLS ExtensionType Registry: Future values are allocated
via IETF Consensus [RFC2434]
In addition, this document defines one new registry to
support the key exchange, and the client can proceed be maintained
by IANA:
o TLS HashType Registry: The registry will be initially
populated with its
phase of the key exchange. values described in Section 7.4.1.4.7.
Dierks & Rescorla Standards Track [Page 58] draft-ietf-tls-rfc4346-bis-02.txt 55] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
Upon receipt of the server hello done message the client SHOULD
verify that March 2007
Future values in the server provided a valid certificate if required
and check that range 0-63 (decimal) inclusive are
assigned via Standards Action [RFC2434]. Values in the server hello parameters
range 64-223 (decimal) inclusive are acceptable.
Structure of this message:
struct { } ServerHelloDone;
7.4.7. Client certificate
When this message will be sent:
This is the first message the client can send after receiving a
server hello done message. assigned via
Specification Required [RFC2434]. Values from 224-255
(decimal) inclusive are reserved for Private Use [RFC2434].
This message document defines one new TLS extension, cert_hash_type, which is only sent if
to be (has been) allocated value TBD-BY-IANA in the
server requests TLS ExtensionType
registry.
12.1 Extensions
Section 11 describes a certificate. If no suitable certificate is
available, registry of ExtensionType values to be
maintained by the client SHOULD send a certificate message
containing no certificates. That is, IANA. ExtensionType values are to be assigned via
IETF Consensus as defined in RFC 2434 [IANA]. The initial registry
corresponds to the certificate_list
structure has a length definition of zero. If client authentication is
required "ExtensionType" in Section 2.3.
The MIME type "application/pkix-pkipath" has been registered by the server for the handshake to continue, it may
respond
IANA with the following template:
To: ietf-types@iana.org Subject: Registration of MIME media type
application/pkix-pkipath
MIME media type name: application
MIME subtype name: pkix-pkipath
Optional parameters: version (default value is "1")
Encoding considerations:
This MIME type is a fatal handshake failure alert. Client certificates
are sent using DER encoding of the Certificate structure ASN.1 type PkiPath,
defined in Section
7.4.2.
Note: When using as follows:
PkiPath ::= SEQUENCE OF Certificate
PkiPath is used to represent a static Diffie-Hellman based key exchange method
(DH_DSS or DH_RSA), if client authentication certification path. Within the
sequence, the order of certificates is requested, such that the
Diffie-Hellman group and generator encoded in subject of
the client's first certificate MUST match is the server specified Diffie-Hellman
parameters if issuer of the client's parameters are second certificate,
etc.
This is identical to be used for the key
exchange.
7.4.8. Client Certificate URLs
After negotiation of the use of client certificate URLs has been
successfully completed (by exchanging hellos including
"client_certificate_url" extensions), clients MAY send a
"CertificateURL" message definition published in place of [X509-4th-TC1];
note that it is different from that in [X509-4th].
All Certificates MUST conform to [PKIX]. (This should be
interpreted as a "Certificate" message.
enum {
individual_certs(0), pkipath(1), (255)
} CertChainType;
enum {
false(0), true(1)
} Boolean;
struct {
CertChainType type;
URLAndOptionalHash url_and_hash_list<1..2^16-1>;
} CertificateURL; requirement to encode only PKIX-conformant
certificates using this type. It does not necessarily require
that all certificates that are not strictly PKIX-conformant must
be rejected by relying parties, although the security consequences
of accepting any such certificates should be considered
carefully.)
Dierks & Rescorla Standards Track [Page 59] draft-ietf-tls-rfc4346-bis-02.txt 56] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
struct {
opaque url<1..2^16-1>;
Boolean hash_present;
select (hash_present) {
case false: struct {};
case true: SHA1Hash;
} hash;
} URLAndOptionalHash;
opaque SHA1Hash[20];
Here "url_and_hash_list" contains March 2007
DER (as opposed to BER) encoding MUST be used. If this type is
sent over a sequence 7-bit transport, base64 encoding SHOULD be used.
Security considerations:
The security considerations of URLs [X509-4th] and optional
hashes.
When X.509 certificates are used, there are two possibilities:
- if CertificateURL.type is "individual_certs", each URL refers [PKIX] (or any
updates to them) apply, as well as those of any protocol that uses
this type (e.g., TLS).
Note that this type only specifies a single DER-encoded X.509v3 certificate, with the URL for the
client's certificate first, or
- if CertificateURL.type is "pkipath", the list contains a single
URL referring chain that can be
assessed for validity according to a DER-encoded certificate chain, using the type
PkiPath described in Section 8.
When any other certificate format relying party's existing
configuration of trusted CAs; it is used, the specification that
describes use of that format in TLS should define the encoding format
of certificates or certificate chains, and not intended to be used to
specify any constraint on their
ordering.
The hash corresponding change to each URL at the client's discretion is
either not present or is the SHA-1 hash of the certificate or
certificate chain (in the case of X.509 certificates, the DER-encoded
certificate or the DER-encoded PkiPath).
Note that when a list of URLs for X.509 certificates is used, the
ordering of URLs is the same as that used in the TLS Certificate
message (see [TLS] Section 7.4.2), configuration.
Interoperability considerations:
No specific interoperability problems are known with this type,
but opposite for recommendations relating to the order in which X.509 certificates are encoded in PkiPath. In either case, the self-signed
root certificate MAY be omitted from the chain, under the assumption
that the server must already possess it in order to validate it.
Servers receiving "CertificateURL" SHALL attempt to retrieve the
client's certificate chain from the URLs, general,
see [PKIX].
Published specification: this memo, and then process the
certificate chain as usual. A cached copy of the content of any URL
in the chain MAY [PKIX].
Applications which use this media type: TLS. It may also be used, provided that a SHA-1 hash is present used by
other protocols, or for
that URL and it matches the hash general interchange of the cached copy.
Servers that support this extension MUST support the http: URL scheme
Dierks & Rescorla Standards Track [Page 60] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
for PKIX certificate URLs, and MAY support other schemes. Use of
Additional information:
Magic number(s): DER-encoded ASN.1 can be easily recognized.
Further parsing is required to distinguish from other
schemes than "http", "https", or "ftp" may create unexpected
problems.
If the protocol used is HTTP, then the HTTP server can be configured
to use the Cache-Control and Expires directives described in [HTTP] ASN.1
types.
File extension(s): .pkipath
Macintosh File Type Code(s): not specified
Person & email address to specify whether and contact for how long certificates or certificate
chains should be cached.
The further information:
Magnus Nystrom <magnus@rsasecurity.com>
Intended usage: COMMON
Change controller:
IESG <iesg@ietf.org>
Dierks & Rescorla Standards Track [Page 57] draft-ietf-tls-rfc4346-bis-03.txt TLS server is not required to follow HTTP redirects when
retrieving the certificates or certificate chain. The URLs used in
this extension SHOULD therefore be chosen not to depend on such
redirects.
If the March 2007
Appendix A. Protocol Constant Values
This section describes protocol used to retrieve certificates or certificate chains
returns a MIME formatted response (as HTTP does), then the following
MIME Content-Types SHALL be used: when a single X.509v3 certificate
is returned, the Content-Type is "application/pkix-cert" [PKIOP], and
when a chain of X.509v3 certificates is returned, the Content-Type is
"application/pkix-pkipath" (see Section XXX).
If a SHA-1 hash is present for an URL, then the server MUST check
that the SHA-1 hash of the contents of the object retrieved from that
URL (after decoding any MIME Content-Transfer-Encoding) matches the
given hash. If any retrieved object does not have the correct SHA-1
hash, the server MUST abort the handshake with a
"bad_certificate_hash_value" alert.
Note that clients may choose to send either "Certificate" or
"CertificateURL" after successfully negotiating the option to send
certificate URLs. The option to send a certificate is included to
provide flexibility to clients possessing multiple certificates.
If a server encounters an unreasonable delay in obtaining
certificates in a given CertificateURL, it SHOULD time out types and signal
a "certificate_unobtainable" error alert.
7.4.9. Client key exchange message
When this message will be sent:
This message is always sent by the client. It MUST immediately follow
the client certificate message, if it is sent. Otherwise it MUST be
the first message sent by the client after it receives the server
hello done message.
Meaning of this message:
With this message, the premaster secret is set, either though direct
transmission of the RSA-encrypted secret, or by the transmission of
Dierks & Rescorla Standards Track [Page 61] draft-ietf-tls-rfc4346-bis-02.txt constants.
A.1. Record Layer
struct {
uint8 major, minor;
} ProtocolVersion;
ProtocolVersion version = { 3, 3 }; /* TLS October 2006
Diffie-Hellman parameters which will allow each side to agree upon
the same premaster secret. When the key exchange method is DH_RSA or
DH_DSS, client certification has been requested, and the client was
able to respond with a certificate which contained a Diffie-Hellman
public key whose parameters (group and generator) matched those
specified by the server in its certificate, this message MUST not
contain any data.
Structure of this message:
The choice of messages depends on which key exchange method has been
selected. See Section 7.4.3 for the KeyExchangeAlgorithm definition. v1.2*/
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSCompressed.length];
} TLSCompressed;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (KeyExchangeAlgorithm) (SecurityParameters.cipher_type) {
case rsa: EncryptedPreMasterSecret; stream: GenericStreamCipher;
case diffie_hellman: ClientDiffieHellmanPublic; block: GenericBlockCipher;
case aead: GenericAEADCipher;
} exchange_keys; fragment;
} ClientKeyExchange;
7.4.9.1. RSA encrypted premaster secret message
Meaning of this message:
If RSA is being used for key agreement and authentication, the client
generates a 48-byte premaster secret, encrypts it using the public
key from the server's certificate or the temporary RSA key provided
in a server key exchange message, and sends the result in an
encrypted premaster secret message. This structure is a variant of
the client key exchange message, not a message in itself.
Structure of this message: TLSCiphertext;
stream-ciphered struct {
ProtocolVersion client_version;
opaque random[46]; content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length];
} PreMasterSecret;
client_version
The latest (newest) version supported by the client. This is
used to detect version roll-back attacks. Upon receiving the
premaster secret, the server SHOULD check that this value
matches the value transmitted by the client in the client
hello message.
random
46 securely-generated random bytes. GenericStreamCipher;
block-ciphered struct {
public-key-encrypted PreMasterSecret pre_master_secret;
Dierks & Rescorla Standards Track [Page 58] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
opaque IV[SecurityParameters.block_length];
opaque content[TLSCompressed.length];
opaque MAC[SecurityParameters.mac_length];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} EncryptedPreMasterSecret; GenericBlockCipher;
aead-ciphered struct {
opaque IV[SecurityParameters.iv_length];
opaque aead_output[AEADEncrypted.length];
} GenericAEADCipher;
A.2. Change Cipher Specs Message
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
A.3. Alert Messages
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
no_certificate_RESERVED (41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110), /* new */
Dierks & Rescorla Standards Track [Page 62] draft-ietf-tls-rfc4346-bis-02.txt 59] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
pre_master_secret
This random value is generated by the client and is used to
generate the master secret, as specified in Section 8.1.
Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used
to attack a March 2007
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
Dierks & Rescorla Standards Track [Page 60] draft-ietf-tls-rfc4346-bis-03.txt TLS server which is using PKCS#1 v 1.5 encoded RSA.
The attack takes advantage of the fact that by failing in
different ways, a TLS server can be coerced into revealing
whether a particular message, when decrypted, is properly PKCS#1
v1.5 formatted or not.
The best way to avoid vulnerability to this attack is to treat
incorrectly formatted messages in a manner indistinguishable from
correctly formatted RSA blocks. Thus, when it receives an
incorrectly formatted RSA block, a server should generate a
random 48-byte value and proceed using it as the premaster
secret. Thus, the server will act identically whether the
received RSA block is correctly encoded or not.
[PKCS1B] defines a newer version of PKCS#1 encoding that is more
secure against the Bleichenbacher attack. However, for maximal
compatibility with TLS 1.0, TLS 1.1 retains the original
encoding. No variants of the Bleichenbacher attack are known to
exist provided that the above recommendations are followed.
Implementation Note: public-key-encrypted data is represented as an
opaque vector <0..2^16-1> (see section 4.7). Thus the RSA-
encrypted PreMasterSecret in a ClientKeyExchange is preceded by
two length bytes. These bytes are redundant in the March 2007
A.4. Handshake Protocol
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20)
(255)
} HandshakeType;
struct {
HandshakeType msg_type;
uint24 length;
select (HandshakeType) {
case of RSA
because the EncryptedPreMasterSecret is the only data in the
ClientKeyExchange and its length can therefore be unambiguously
determined. The SSLv3 specification was not clear about the
encoding of public-key-encrypted data and therefore many SSLv3
implementations do not include the the length bytes, encoding the
RSA encrypted data directly in the ClientKeyExchange message.
This specification requires correct encoding of the
EncryptedPreMasterSecret complete with length bytes. The
resulting PDU is incompatible with many SSLv3 implementations.
Implementors upgrading from SSLv3 must modify their
implementations to generate and accept the correct encoding.
Implementors who wish to be compatible with both SSLv3 and TLS
should make their implementation's behavior dependent on the
protocol version.
Implementation Note: It is now known that remote timing-based attacks
on SSL are possible, at least when the client and server are on
the same LAN. Accordingly, implementations which use static RSA
Dierks & Rescorla Standards Track [Page 63] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
keys SHOULD use RSA blinding or some other anti-timing technique,
as described in [TIMING].
Note: The version number in the PreMasterSecret MUST be the version
offered by the client in the ClientHello.version, not the version
negotiated for the connection. This feature is designed to
prevent rollback attacks. Unfortunately, many implementations use
the negotiated version instead and therefore checking the version
number may lead to failure to interoperate with such incorrect
client implementations. Client implementations MUST and Server
implementations MAY check the version number. In practice, since
the TLS handshake MACs prevent downgrade and no good attacks are
known on those MACs, ambiguity is not considered a serious
security risk. Note that if servers choose to to check the
version number, they should randomize the PreMasterSecret in hello_request: HelloRequest;
case
of error, rather than generate an alert, in order to avoid
variants on the Bleichenbacher attack. [KPR03]
7.4.9.2. Client Diffie-Hellman public value
Meaning of this message:
This structure conveys the client's Diffie-Hellman public value
(Yc) if it was not already included in the client's certificate.
The encoding used for Yc is determined by the enumerated
PublicValueEncoding. This structure is a variant of the client
key exchange message, not a message in itself.
Structure of this message:
enum { implicit, explicit } PublicValueEncoding;
implicit
If the client certificate already contains a suitable Diffie-
Hellman key, then Yc is implicit and does not need to be sent
again. In this case, the client key exchange message will be
sent, but MUST be empty.
explicit
Yc needs to be sent.
struct {
select (PublicValueEncoding) { client_hello: ClientHello;
case implicit: struct { }; server_hello: ServerHello;
case explicit: opaque dh_Yc<1..2^16-1>; certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
} dh_public; body;
} ClientDiffieHellmanPublic;
dh_Yc
The client's Diffie-Hellman public value (Yc).
Dierks & Rescorla Standards Track [Page 64] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
7.4.10. Certificate verify
When this message will be sent:
This message is used to provide explicit verification of a client
certificate. This message is only sent following a client
certificate that has signing capability (i.e. all certificates
except those containing fixed Diffie-Hellman parameters). When
sent, it MUST immediately follow the client key exchange message.
Structure of this message: Handshake;
A.4.1. Hello Messages
struct {
Signature signature; } CertificateVerify;
The Signature type is defined in 7.4.3. If the SignatureAlgorithm
is DSA, then the sha_hash value must be used. If it is RSA,
the same function (denoted Hash) must be used as was used to
create the signature for the client's certificate.
CertificateVerify.signature.hash
Hash(handshake_messages);
CertificateVerify.signature.sha_hash
SHA(handshake_messages);
Here handshake_messages refers to all handshake messages sent or
received starting at client hello up to but not including this
message, including the type and length fields of the handshake
messages. This is the concatenation of all the Handshake structures
as defined in 7.4 exchanged thus far.
7.4.10. Finished
When this message will be sent:
A finished message is always sent immediately after a change
cipher spec message to verify that the key exchange and
authentication processes were successful. It is essential that a
change cipher spec message be received between the other
handshake messages and the Finished message.
Meaning of this message:
The finished message is the first protected with the just-
negotiated algorithms, keys, and secrets. Recipients of finished
messages MUST verify that the contents are correct. Once a side
has sent its Finished message and received and validated the
Finished message from its peer, it may begin to send and receive
application data over the connection.
Dierks & Rescorla Standards Track [Page 65] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006 HelloRequest;
struct {
uint32 gmt_unix_time;
opaque verify_data[12]; random_bytes[28];
} Finished;
verify_data
PRF(master_secret, finished_label, Hash(handshake_messages))[0..11];
finished_label
For Finished messages sent by the client, the string "client
finished". For Finished messages sent by the server, the
string "server finished".
Hash denotes the negotiated hash used for the PRF. If a new
PRF is defined, then this hash MUST be specified.
handshake_messages
All of the data from all messages in this handshake (not
including any HelloRequest messages) up to but not including
this message. This is only data visible at the handshake
layer and does not include record layer headers. This is the
concatenation of all the Handshake structures as defined in
7.4 exchanged thus far.
It is a fatal error if a finished message is not preceded by a change
cipher spec message at the appropriate point in the handshake.
The value handshake_messages includes all handshake messages starting
at client hello up to, but not including, this finished message. This
may be different from handshake_messages in Section 7.4.10 because it
would include the certificate verify message (if sent). Also, the
handshake_messages for the finished message sent by the client will
be different from that for the finished message sent by the server,
because the one which is sent second will include the prior one.
Note: Change cipher spec messages, alerts and any other record types
are not handshake messages and are not included in the hash
computations. Also, Hello Request messages are omitted from
handshake hashes.
8. Cryptographic computations
In order to begin connection protection, the TLS Record Protocol
requires specification of a suite of algorithms, a master secret, and
the client and server random values. The authentication, encryption,
and MAC algorithms are determined by the cipher_suite selected by the
server and revealed in the server hello message. The compression
algorithm is negotiated in the hello messages, and the random values
are exchanged in the hello messages. All that remains is to calculate
Dierks & Rescorla Standards Track [Page 66] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
the master secret.
8.1. Computing the master secret
For all key exchange methods, the same algorithm is used to convert
the pre_master_secret into the master_secret. The pre_master_secret
should be deleted from memory once the master_secret has been
computed.
master_secret = PRF(pre_master_secret, "master secret",
ClientHello.random + ServerHello.random)
[0..47];
The master secret is always exactly 48 bytes in length. The length of
the premaster secret will vary depending on key exchange method.
8.1.1. RSA
When RSA is used for server authentication and key exchange, a
48-byte pre_master_secret is generated by the client, encrypted under
the server's public key, and sent to the server. The server uses its
private key to decrypt the pre_master_secret. Both parties then
convert the pre_master_secret into the master_secret, as specified
above.
RSA digital signatures are performed using PKCS #1 [PKCS1] block type
1. RSA public key encryption is performed using PKCS #1 block type 2.
8.1.2. Diffie-Hellman
A conventional Diffie-Hellman computation is performed. The
negotiated key (Z) is used as the pre_master_secret, and is converted
into the master_secret, as specified above. Leading bytes of Z that
contain all zero bits are stripped before it is used as the
pre_master_secret.
Note: Diffie-Hellman parameters are specified by the server, and may
be either ephemeral or contained within the server's certificate.
9. Mandatory Cipher Suites
In the absence of an application profile standard specifying
otherwise, a TLS compliant application MUST implement the cipher
suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
10. Application data protocol
Application data messages are carried by the Record Layer and are
Dierks & Rescorla Standards Track [Page 67] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
fragmented, compressed and encrypted based on the current connection
state. The messages are treated as transparent data to the record
layer.
11. IANA Considerations
This document describes a number of new registries to be created by
IANA. We recommend that they be placed as individual registries items
under a common TLS category.
Section 7.4.5 describes a TLS HashType Registry to be maintained by
the IANA, as defining a number of such code point identifiers.
HashType identifiers with values in the range 0-63 (decimal)
inclusive are assigned via RFC 2434 Standards Action. Values from the
range 64-223 (decimal) inclusive are assigned via [RFC 2434]
Specification Required. Identifier values from 224-255 (decimal)
inclusive are reserved for RFC 2434 Private Use. The registry will be
initially populated with the values in this document, Section 7.4.5.
Section 7.4.5 describes a TLS ClientCertificateType Registry to be
maintained by the IANA, as defining a number of such code point
identifiers. ClientCertificateType identifiers with values in the
range 0-63 (decimal) inclusive are assigned via RFC 2434 Standards
Action. Values from the range 64-223 (decimal) inclusive are assigned
via [RFC 2434] Specification Required. Identifier values from
224-255 (decimal) inclusive are reserved for RFC 2434 Private Use.
The registry will be initially populated with the values in this
document, Section 7.4.5.
Section A.5 describes a TLS Cipher Suite Registry to be maintained by
the IANA, as well as defining a number of such cipher suite
identifiers. Cipher suite values with the first byte in the range
0-191 (decimal) inclusive are assigned via RFC 2434 Standards Action.
Values with the first byte in the range 192-254 (decimal) are
assigned via RFC 2434 Specification Required. Values with the first
byte 255 (decimal) are reserved for RFC 2434 Private Use. The
registry will be initially populated with the values from Section A.5
of this document, [TLSAES], and Section 3 of [TLSKRB].
Section 6 requires that all ContentType values be defined by RFC 2434
Standards Action. IANA SHOULD create a TLS ContentType registry,
initially populated with values from Section 6.2.1 of this document.
Future values MUST be allocated via Standards Action as described in
[RFC 2434].
Section 7.2.2 requires that all Alert values be defined by RFC 2434
Standards Action. IANA SHOULD create a TLS Alert registry, initially
populated with values from Section 7.2 of this document and Section 4
Dierks & Rescorla Standards Track [Page 68] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
of [TLSEXT]. Future values MUST be allocated via Standards Action as
described in [RFC 2434].
Section 7.4 requires that all HandshakeType values be defined by RFC
2434 Standards Action. IANA SHOULD create a TLS HandshakeType
registry, initially populated with values from Section 7.4 of this
document and Section 2.4 of [TLSEXT]. Future values MUST be
allocated via Standards Action as described in [RFC2434].
11.1 Extensions
Sections XXX and XXX describes a registry of ExtensionType values to
be maintained by the IANA. ExtensionType values are to be assigned
via IETF Consensus as defined in RFC 2434 [IANA]. The initial
registry corresponds to the definition of "ExtensionType" in Section
2.3.
The MIME type "application/pkix-pkipath" has been registered by the
IANA with the following template:
To: ietf-types@iana.org Subject: Registration of MIME media type
application/pkix-pkipath
MIME media type name: application
MIME subtype name: pkix-pkipath
Optional parameters: version (default value is "1")
Encoding considerations:
This MIME type is a DER encoding of the ASN.1 type PkiPath,
defined as follows:
PkiPath ::= SEQUENCE OF Certificate
PkiPath is used to represent a certification path. Within the
sequence, the order of certificates is such that the subject of
the first certificate is the issuer of the second certificate,
etc.
This is identical to the definition published in [X509-4th-TC1];
note that it is different from that in [X509-4th].
All Certificates MUST conform to [PKIX]. (This should be
interpreted as a requirement to encode only PKIX-conformant
certificates using this type. It does not necessarily require
that all certificates that are not strictly PKIX-conformant must
be rejected by relying parties, although the security consequences
of accepting any such certificates should be considered
carefully.)
Dierks & Rescorla Standards Track [Page 69] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
DER (as opposed to BER) encoding MUST be used. If this type is
sent over a 7-bit transport, base64 encoding SHOULD be used.
Security considerations:
The security considerations of [X509-4th] and [PKIX] (or any
updates to them) apply, as well as those of any protocol that uses
this type (e.g., TLS).
Note that this type only specifies a certificate chain that can be
assessed for validity according to the relying party's existing
configuration of trusted CAs; it is not intended to be used to
specify any change to that configuration.
Interoperability considerations:
No specific interoperability problems are known with this type,
but for recommendations relating to X.509 certificates in general,
see [PKIX].
Published specification: this memo, and [PKIX].
Applications which use this media type: TLS. It may also be used by
other protocols, or for general interchange of PKIX certificate
Additional information:
Magic number(s): DER-encoded ASN.1 can be easily recognized.
Further parsing is required to distinguish from other ASN.1
types.
File extension(s): .pkipath
Macintosh File Type Code(s): not specified
Person & email address to contact for further information:
Magnus Nystrom <magnus@rsasecurity.com>
Intended usage: COMMON
Change controller:
IESG <iesg@ietf.org>
Dierks & Rescorla Standards Track [Page 70] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
A. Protocol constant values
This section describes protocol types and constants.
A.1. Record layer
struct {
uint8 major, minor;
} ProtocolVersion;
ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/
enum {
change_cipher_spec(20), alert(21), handshake(22),
application_data(23), (255)
} ContentType;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSCompressed.length];
} TLSCompressed;
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
select (CipherSpec.cipher_type) {
case stream: GenericStreamCipher;
case block: GenericBlockCipher;
} fragment;
} TLSCiphertext;
stream-ciphered struct {
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;
block-ciphered struct {
opaque IV[CipherSpec.block_length];
Dierks & Rescorla Standards Track [Page 71] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
opaque content[TLSCompressed.length];
opaque MAC[CipherSpec.hash_size];
uint8 padding[GenericBlockCipher.padding_length];
uint8 padding_length;
} GenericBlockCipher;
aead-ciphered struct {
opaque IV[CipherSpec.iv_length];
opaque aead_output[AEADEncrypted.length];
} GenericAEADCipher;
A.2. Change cipher specs message
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
A.3. Alert messages
enum { warning(1), fatal(2), (255) } AlertLevel;
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
no_certificate_RESERVED (41),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction_RESERVED(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110), /* new */
certificate_unobtainable(111), /* new */
Dierks & Rescorla Standards Track [Page 72] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
unrecognized_name(112), /* new */
bad_certificate_status_response(113), /* new */
bad_certificate_hash_value(114), /* new */
(255)
} AlertDescription;
struct {
AlertLevel level;
AlertDescription description;
} Alert;
Dierks & Rescorla Standards Track [Page 73] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
A.4. Handshake protocol
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), certificate_url(21), certificate_status(22),
(255)
} HandshakeType;
struct {
HandshakeType msg_type;
uint24 length;
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
case certificate_url: CertificateURL;
case certificate_status: CertificateStatus;
} body;
} Handshake;
A.4.1. Hello messages
struct { } HelloRequest;
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
opaque SessionID<0..32>;
uint8 CipherSuite[2];
enum { null(0), (255) } CompressionMethod;
struct {
ProtocolVersion client_version;
Random random;
Dierks & Rescorla Standards Track [Page 74] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
Extension client_hello_extension_list<0..2^16-1>;
} ClientHello;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
Extension client_hello_extension_list<0..2^16-1>;
} ExtendedClientHello;
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} ServerHello;
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
Extension server_hello_extension_list<0..2^16-1>;
} ExtendedServerHello;
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
enum {
server_name(0), max_fragment_length(1),
client_certificate_url(2), trusted_ca_keys(3),
truncated_hmac(4), status_request(5),
cert_hash_types(6), (65535)
} ExtensionType;
struct {
NameType name_type;
select (name_type) {
case host_name: HostName;
Dierks & Rescorla Standards Track [Page 75] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
} name;
} ServerName;
enum {
host_name(0), (255)
} NameType;
opaque HostName<1..2^16-1>;
struct {
ServerName server_name_list<1..2^16-1>
} ServerNameList;
enum{
2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
} MaxFragmentLength;
struct {
TrustedAuthority trusted_authorities_list<0..2^16-1>;
} TrustedAuthorities;
struct {
IdentifierType identifier_type;
select (identifier_type) {
case pre_agreed: struct {};
case key_sha1_hash: SHA1Hash;
case x509_name: DistinguishedName;
case cert_sha1_hash: SHA1Hash;
} identifier;
} TrustedAuthority;
enum {
pre_agreed(0), key_sha1_hash(1), x509_name(2),
cert_sha1_hash(3), (255)
} IdentifierType;
struct {
CertificateStatusType status_type;
select (status_type) {
case ocsp: OCSPStatusRequest;
} request;
} CertificateStatusRequest;
enum { ocsp(1), (255) } CertificateStatusType;
struct {
ResponderID responder_id_list<0..2^16-1>;
Extensions request_extensions;
Dierks & Rescorla Standards Track [Page 76] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
} OCSPStatusRequest;
opaque ResponderID<1..2^16-1>;
A.4.2. Server authentication and key exchange messages
opaque ASN.1Cert<2^24-1>;
struct {
ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;
struct {
CertificateStatusType status_type;
select (status_type) {
case ocsp: OCSPResponse;
} response;
} CertificateStatus;
opaque OCSPResponse<1..2^24-1>;
enum { rsa, diffie_hellman } KeyExchangeAlgorithm;
struct {
opaque rsa_modulus<1..2^16-1>;
opaque rsa_exponent<1..2^16-1>;
} ServerRSAParams;
struct {
opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>;
} ServerDHParams;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
};
} ServerKeyExchange;
enum { anonymous, rsa, dsa } SignatureAlgorithm;
struct {
select (KeyExchangeAlgorithm) {
Dierks & Rescorla Standards Track [Page 77] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
case diffie_hellman:
ServerDHParams params;
case rsa:
ServerRSAParams params;
};
} ServerParams;
struct {
select (SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
digitally-signed struct {
opaque hash[Hash.length];
};
case dsa:
digitally-signed struct {
opaque sha_hash[20];
};
};
};
} Signature;
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20),
(255)
} ClientCertificateType;
opaque DistinguishedName<1..2^16-1>;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
struct { } ServerHelloDone;
A.4.3. Client authentication and key exchange messages
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
struct {
Dierks & Rescorla Standards Track [Page 78] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
struct {
public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret;
enum { implicit, explicit } PublicValueEncoding;
struct {
select (PublicValueEncoding) {
case implicit: struct {};
case explicit: opaque DH_Yc<1..2^16-1>;
} dh_public;
} ClientDiffieHellmanPublic;
enum {
individual_certs(0), pkipath(1), (255)
} CertChainType;
enum {
false(0), true(1)
} Boolean;
struct {
CertChainType type;
URLAndOptionalHash url_and_hash_list<1..2^16-1>;
} CertificateURL;
struct {
opaque url<1..2^16-1>;
Boolean hash_present;
select (hash_present) {
case false: struct {};
case true: SHA1Hash;
} hash;
} URLAndOptionalHash;
opaque SHA1Hash[20];
struct {
Signature signature;
} CertificateVerify;
A.4.4. Handshake finalization message
struct {
Dierks & Rescorla Standards Track [Page 79] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
opaque verify_data[12];
} Finished;
A.5. The CipherSuite
The following values define the CipherSuite codes used in the client
hello and server hello messages.
A CipherSuite defines a cipher specification supported in TLS Version
1.1.
TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a
TLS connection during the first handshake on that channel, but must
not be negotiated, as it provides no more protection than an
unsecured connection.
CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
The following CipherSuite definitions require that the server provide
an RSA certificate that can be used for key exchange. The server may
request either an RSA or a DSS signature-capable certificate in the
certificate request message.
CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x2F };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x35 };
The following CipherSuite definitions are used for server-
authenticated (and optionally client-authenticated) Diffie-Hellman.
DH denotes cipher suites in which the server's certificate contains
the Diffie-Hellman parameters signed by the certificate authority
(CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
parameters are signed by a DSS or RSA certificate, which has been
signed by the CA. The signing algorithm used is specified after the
DH or DHE parameter. The server can request an RSA or DSS signature-
capable certificate from the client for client authentication or it
may request a Diffie-Hellman certificate. Any Diffie-Hellman
certificate provided by the client must use the parameters (group and
generator) described by the server.
CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
Dierks & Rescorla Standards Track [Page 80] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x30 };
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x31 };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x32 };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x33 };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 };
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x36 };
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x37 };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x38 };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x39 };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A };
The following cipher suites are used for completely anonymous Diffie-
Hellman communications in which neither party is authenticated. Note
that this mode is vulnerable to man-in-the-middle attacks and is
therefore deprecated.
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B };
When SSLv3 and TLS 1.0 were designed, the United States restricted
the export of cryptographic software containing certain strong
encryption algorithms. A series of cipher suites were designed to
operate at reduced key lengths in order to comply with those
regulations. Due to advances in computer performance, these
algorithms are now unacceptably weak and export restrictions have
since been loosened. TLS 1.1 implementations MUST NOT negotiate these
cipher suites in TLS 1.1 mode. However, for backward compatibility
they may be offered in the ClientHello for use with TLS 1.0 or SSLv3
only servers. TLS 1.1 clients MUST check that the server did not
choose one of these cipher suites during the handshake. These
ciphersuites are listed below for informational purposes and to
reserve the numbers.
CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 };
CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
Dierks & Rescorla Standards Track [Page 81] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
The following cipher suites were defined in [TLSKRB] and are included
here for completeness. See [TLSKRB] for details:
CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F };
CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 };
CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 };
CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 };
The following exportable cipher suites were defined in [TLSKRB] and
are included here for completeness. TLS 1.1 implementations MUST NOT
negotiate these cipher suites.
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26
};
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27
};
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28
};
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29
};
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A
};
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B
};
The cipher suite space is divided into three regions:
1. Cipher suite values with first byte 0x00 (zero)
through decimal 191 (0xBF) inclusive are reserved for the IETF
Standards Track protocols.
2. Cipher suite values with first byte decimal 192 (0xC0)
through decimal 254 (0xFE) inclusive are reserved
for assignment for non-Standards Track methods.
3. Cipher suite values with first byte 0xFF are
reserved for private use.
Additional information describing the role of IANA in the allocation
of cipher suite code points is described in Section 11.
Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
reserved to avoid collision with Fortezza-based cipher suites in SSL
3.
Dierks & Rescorla Standards Track [Page 82] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
A.6. The Security Parameters
These security parameters are determined by the TLS Handshake
Protocol and provided as parameters to the TLS Record Layer in order
to initialize a connection state. SecurityParameters includes:
enum { null(0), (255) } CompressionMethod;
enum { server, client } ConnectionEnd;
enum { null, rc4, rc2, des, 3des, des40, aes, idea }
BulkCipherAlgorithm;
enum { stream, block } CipherType;
enum { null, md5, sha } MACAlgorithm;
/* The algorithms specified in CompressionMethod,
BulkCipherAlgorithm, and MACAlgorithm may be added to. */
struct {
ConnectionEnd entity;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 key_size;
uint8 key_material_length;
MACAlgorithm mac_algorithm;
uint8 hash_size;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
Dierks & Rescorla Standards Track [Page 83] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
B. Glossary
Advanced Encryption Standard (AES)
AES is a widely used symmetric encryption algorithm.
AES is
a block cipher with a 128, 192, or 256 bit keys and a 16 byte
block size. [AES] TLS currently only supports the 128 and 256
bit key sizes.
application protocol
An application protocol is a protocol that normally layers
directly on top of the transport layer (e.g., TCP/IP). Examples
include HTTP, TELNET, FTP, and SMTP.
asymmetric cipher
See public key cryptography.
authentication
Authentication is the ability of one entity to determine the
identity of another entity.
block cipher
A block cipher is an algorithm that operates on plaintext in
groups of bits, called blocks. 64 bits is a common block size.
bulk cipher
A symmetric encryption algorithm used to encrypt large quantities
of data.
cipher block chaining (CBC)
CBC is a mode in which every plaintext block encrypted with a
block cipher is first exclusive-ORed with the previous ciphertext
block (or, in the case of the first block, with the
initialization vector). For decryption, every block is first
decrypted, then exclusive-ORed with the previous ciphertext block
(or IV).
certificate
As part of the X.509 protocol (a.k.a. ISO Authentication
framework), certificates are assigned by a trusted Certificate
Authority and provide a strong binding between a party's identity
or some other attributes and its public key.
client
The application entity that initiates a TLS connection to a
server. This may or may not imply that the client initiated the
underlying transport connection. The primary operational
difference between the server and client is that the server is
Dierks & Rescorla Standards Track [Page 84] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
generally authenticated, while the client is only optionally
authenticated.
client write key
The key used to encrypt data written by the client.
client write MAC secret
The secret data used to authenticate data written by the client.
connection
A connection is a transport (in the OSI layering model
definition) that provides a suitable type of service. For TLS,
such connections are peer to peer relationships. The connections
are transient. Every connection is associated with one session.
Data Encryption Standard
DES is a very widely used symmetric encryption algorithm. DES is
a block cipher with a 56 bit key and an 8 byte block size. Note
that in TLS, for key generation purposes, DES is treated as
having an 8 byte key length (64 bits), but it still only provides
56 bits of protection. (The low bit of each key byte is presumed
to be set to produce odd parity in that key byte.) DES can also
be operated in a mode where three independent keys and three
encryptions are used for each block of data; this uses 168 bits
of key (24 bytes in the Random;
opaque SessionID<0..32>;
uint8 CipherSuite[2];
enum { null(0), (255) } CompressionMethod;
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
Dierks & Rescorla Standards Track [Page 61] draft-ietf-tls-rfc4346-bis-03.txt TLS key generation method) March 2007
CompressionMethod compression_methods<1..2^8-1>;
Extension client_hello_extension_list<0..2^16-1>;
} ClientHello;
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} ServerHello;
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
enum {
cert_hash_types(TBD-BY-IANA), (65535)
} ExtensionType;
A.4.2. Server Authentication and provides
the equivalent of 112 bits of security. [DES], [3DES]
Digital Signature Standard (DSS)
A standard for digital signing, including the Digital Signing
Algorithm, approved by the National Institute of Key Exchange Messages
opaque ASN.1Cert<2^24-1>;
struct {
ASN.1Cert certificate_list<0..2^24-1>;
} Certificate;
struct {
CertificateStatusType status_type;
select (status_type) {
case ocsp: OCSPResponse;
} response;
} CertificateStatus;
opaque OCSPResponse<1..2^24-1>;
enum { diffie_hellman } KeyExchangeAlgorithm;
struct {
opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>;
} ServerDHParams;
struct {
select (KeyExchangeAlgorithm) {
Dierks & Rescorla Standards and
Technology, defined in NIST FIPS PUB 186, "Digital Track [Page 62] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
case diffie_hellman:
ServerDHParams params;
Signature
Standard," published May, 1994 by the U.S. Dept. of Commerce.
[DSS]
digital signatures
Digital signatures utilize public key cryptography and one-way
hash functions to produce a signature of the data that can be
authenticated, and is difficult to forge or repudiate.
handshake
An initial negotiation between client signed_params;
} ServerKeyExchange;
enum { anonymous, rsa, dsa } SignatureAlgorithm;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
};
} ServerParams;
struct {
select (SignatureAlgorithm) {
case anonymous: struct { };
case rsa:
digitally-signed struct {
opaque hash[Hash.length];
};
case dsa:
digitally-signed struct {
opaque sha_hash[20];
};
};
};
} Signature;
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
fortezza_dms_RESERVED(20),
(255)
} ClientCertificateType;
opaque DistinguishedName<1..2^16-1>;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>;
} CertificateRequest;
struct { } ServerHelloDone;
A.4.3. Client Authentication and server that establishes
the parameters of their transactions.
Initialization Vector (IV)
When a block cipher is used in CBC mode, the initialization
vector is exclusive-ORed with the first plaintext block prior to
encryption. Key Exchange Messages
struct {
Dierks & Rescorla Standards Track [Page 85] draft-ietf-tls-rfc4346-bis-02.txt 63] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
IDEA
A 64-bit block cipher designed by Xuejia Lai and James Massey.
[IDEA]
Message Authentication Code (MAC)
A March 2007
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
struct {
public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret;
enum { implicit, explicit } PublicValueEncoding;
struct {
select (PublicValueEncoding) {
case implicit: struct {};
case explicit: opaque DH_Yc<1..2^16-1>;
} dh_public;
} ClientDiffieHellmanPublic;
struct {
Signature signature;
} CertificateVerify;
A.4.4. Handshake Finalization Message Authentication Code is a one-way hash computed from a
message and some secret data. It is difficult to forge without
knowing the secret data. Its purpose is to detect if
struct {
opaque verify_data[12];
} Finished;
A.5. The CipherSuite
The following values define the message
has been altered.
master secret
Secure secret data CipherSuite codes used for generating encryption keys, MAC
secrets, in the client
hello and IVs.
MD5
MD5 is a secure hashing function that converts an arbitrarily
long data stream into a digest of fixed size (16 bytes). [MD5]
public key cryptography server hello messages.
A class CipherSuite defines a cipher specification supported in TLS Version
1.1.
TLS_NULL_WITH_NULL_NULL is specified and is the initial state of cryptographic techniques employing two-key ciphers.
Messages encrypted with a
TLS connection during the public key can only first handshake on that channel, but MUST
not be decrypted with
the associated private key. Conversely, messages signed with negotiated, as it provides no more protection than an
unsecured connection.
CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 };
Dierks & Rescorla Standards Track [Page 64] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
The following CipherSuite definitions require that the
private key server provide
an RSA certificate that can be verified with the public key.
one-way hash function
A one-way transformation that converts used for key exchange. The server may
request either an arbitrary amount of
data into RSA or a fixed-length hash. It is computationally hard to
reverse DSS signature-capable certificate in the transformation or to find collisions. MD5 and SHA
certificate request message.
CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 };
CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 };
CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 };
CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 };
CipherSuite TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 };
CipherSuite TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 };
CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A };
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x2F };
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x35 };
The following CipherSuite definitions are
examples of one-way hash functions.
RC2
A block used for server-
authenticated (and optionally client-authenticated) Diffie-Hellman.
DH denotes cipher developed by Ron Rivest at RSA Data Security, Inc.
[RSADSI] described suites in [RC2].
RC4
A stream cipher invented which the server's certificate contains
the Diffie-Hellman parameters signed by the certificate authority
(CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman
parameters are signed by Ron Rivest. A compatible cipher is
described in [SCH]. a DSS or RSA
A very widely used public-key certificate, which has been
signed by the CA. The signing algorithm that can be used for
either encryption is specified after the
DH or digital signing. [RSA]
server DHE parameter. The server is can request an RSA or DSS signature-
capable certificate from the application entity that responds to requests client for connections from clients. See also under client.
Dierks & Rescorla Standards Track [Page 86] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
session
A TLS session is an association between a client and authentication or it
may request a server.
Sessions are created Diffie-Hellman certificate. Any Diffie-Hellman
certificate provided by the handshake protocol. Sessions define a
set of cryptographic security parameters, which can be shared
among multiple connections. Sessions are used to avoid client must use the
expensive negotiation of new security parameters for each
connection.
session identifier
A session identifier is a value generated by a server that
identifies a particular session.
server write key
The key used to encrypt data written (group and
generator) described by the server.
server write MAC secret
CipherSuite TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C };
CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D };
CipherSuite TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F };
CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 };
CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 };
CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 };
CipherSuite TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 };
CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 };
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x30 };
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x31 };
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x32 };
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x33 };
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x36 };
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x37 };
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x38 };
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x39 };
The secret data following cipher suites are used to authenticate data written by the server.
SHA
The Secure Hash Algorithm is defined for completely anonymous Diffie-
Hellman communications in FIPS PUB 180-2. It
produces a 20-byte output. Note that all references to SHA
actually use the modified SHA-1 algorithm. [SHA]
SSL
Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
SSL Version 3.0
stream cipher
An encryption algorithm that converts a key into a
cryptographically-strong keystream, which neither party is then exclusive-ORed
with the plaintext.
symmetric cipher
See bulk cipher.
Transport Layer Security (TLS)
This protocol; also, the Transport Layer Security working group
of the Internet Engineering Task Force (IETF). See "Comments" at
the end of authenticated. Note
that this document. mode is vulnerable to man-in-the-middle attacks. Using
Dierks & Rescorla Standards Track [Page 87] draft-ietf-tls-rfc4346-bis-02.txt 65] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
C. CipherSuite definitions
CipherSuite Key Cipher Hash
Exchange
TLS_NULL_WITH_NULL_NULL NULL NULL NULL
TLS_RSA_WITH_NULL_MD5 RSA NULL MD5
TLS_RSA_WITH_NULL_SHA RSA NULL SHA
TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA
TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA
TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA
TLS_RSA_WITH_AES_256_SHA RSA AES_256_CBC SHA
TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA
TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA March 2007
this mode therefore is of limited use: These ciphersuites MUST NOT be
used by TLS 1.2 implementations unless the application layer has
specifically requested to allow anonymous key exchange. (Anonymous
key exchange may sometimes be acceptable, for example, to support
opportunistic encryption when no set-up for authentication is in
place, or when TLS is used as part of more complex security protocols
that have other means to ensure authentication.)
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 = { 0x00, 0x18 };
CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA = { 0x00, 0x1A };
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA = { 0x00, 0x1B };
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA = { 0x00, 0x34 };
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA
Key
Exchange
Algorithm Description Key size limit
DHE_DSS Ephemeral DH with DSS signatures None
DHE_RSA Ephemeral DH with RSA signatures None
DH_anon Anonymous DH, no signatures None
DH_DSS DH = { 0x00, 0x3A };
Note that using non-anonymous key exchange without actually verifying
the key exchange is essentially equivalent to anonymous key exchange,
and the same precautions apply. While non-anonymous key exchange
will generally involve a higher computational and communicational
cost than anonymous key exchange, it may be in the interest of
interoperability not to disable non-anonymous key exchange when the
application layer is allowing anonymous key exchange.
When SSLv3 and TLS 1.0 were designed, the United States restricted
the export of cryptographic software containing certain strong
encryption algorithms. A series of cipher suites were designed to
operate at reduced key lengths in order to comply with DSS-based certificates None
DH_RSA DH those
regulations. Due to advances in computer performance, these
algorithms are now unacceptably weak and export restrictions have
since been loosened. TLS 1.2 implementations MUST NOT negotiate these
cipher suites in TLS 1.2 mode. However, for backward compatibility
they may be offered in the ClientHello for use with RSA-based certificates None
RSA TLS 1.0 or SSLv3
only servers. TLS 1.2 clients MUST check that the server did not
choose one of these cipher suites during the handshake. These
ciphersuites are listed below for informational purposes and to
reserve the numbers.
CipherSuite TLS_RSA_EXPORT_WITH_RC4_40_MD5 = none
NULL No key exchange N/A { 0x00,0x03 };
CipherSuite TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 };
CipherSuite TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 };
CipherSuite TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B };
CipherSuite TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E };
CipherSuite TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 };
CipherSuite TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 };
CipherSuite TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 };
CipherSuite TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 };
The following cipher suites were defined in [TLSKRB] and are included
here for completeness. See [TLSKRB] for details:
Dierks & Rescorla Standards Track [Page 88] draft-ietf-tls-rfc4346-bis-02.txt 66] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
RSA RSA key exchange None
Key Expanded IV Block
Cipher Type Material Key Material Size Size
NULL Stream 0 0 0 N/A
IDEA_CBC Block 16 16 8 8
RC2_CBC_40 Block 5 16 8 8
RC4_40 Stream 5 16 0 N/A
RC4_128 Stream 16 16 0 N/A
DES40_CBC Block 5 8 8 8
DES_CBC Block 8 8 8 8
3DES_EDE_CBC Block 24 24 8 8
Type
Indicates whether this is a stream cipher or a block March 2007
CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F };
CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 };
CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 };
CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 };
The following exportable cipher
running suites were defined in CBC mode.
Key Material
The number of bytes from the key_block that [TLSKRB] and
are used included here for
generating the write keys.
Expanded Key Material completeness. TLS 1.2 implementations MUST NOT
negotiate these cipher suites.
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26
};
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27
};
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28
};
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29
};
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A
};
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B
};
New cipher suite values are assigned by IANA as described in Section
11.
Note: The number of bytes actually fed into the encryption algorithm
IV Size
How much data needs cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
reserved to be generated for avoid collision with Fortezza-based cipher suites in SSL
3.
A.6. The Security Parameters
These security parameters are determined by the initialization
vector. Zero for stream ciphers; equal TLS Handshake
Protocol and provided as parameters to the block size for
block ciphers.
Block Size
The amount of data a block cipher enciphers TLS Record Layer in one chunk; order
to initialize a connection state. SecurityParameters includes:
enum { null(0), (255) } CompressionMethod;
enum { server, client } ConnectionEnd;
enum { null, rc4, rc2, des, 3des, des40, aes, idea }
BulkCipherAlgorithm;
enum { stream, block cipher running in CBC mode can only encrypt an even
multiple of its block size.
Hash Hash Padding
function Size Size
NULL 0 0
MD5 16 48
SHA 20 40 } CipherType;
Dierks & Rescorla Standards Track [Page 89] draft-ietf-tls-rfc4346-bis-02.txt 67] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
D. Implementation Notes March 2007
enum { null, md5, sha } MACAlgorithm;
/* The TLS protocol cannot prevent many common security mistakes. This
section provides several recommendations to assist implementors.
D.1 Random Number Generation algorithms specified in CompressionMethod,
BulkCipherAlgorithm, and Seeding MACAlgorithm may be added to. */
struct {
ConnectionEnd entity;
BulkCipherAlgorithm bulk_cipher_algorithm;
CipherType cipher_type;
uint8 enc_key_length;
uint8 block_length;
uint8 iv_length;
MACAlgorithm mac_algorithm;
uint8 mac_length;
uint8 mac_key_length;
CompressionMethod compression_algorithm;
opaque master_secret[48];
opaque client_random[32];
opaque server_random[32];
} SecurityParameters;
Dierks & Rescorla Standards Track [Page 68] draft-ietf-tls-rfc4346-bis-03.txt TLS requires March 2007
Appendix B. Glossary
Advanced Encryption Standard (AES)
AES is a cryptographically-secure pseudorandom number generator
(PRNG). Care must be taken in designing widely used symmetric encryption algorithm. AES is a
block cipher with a 128, 192, or 256 bit keys and seeding PRNGs. PRNGs
based on secure hash operations, most notably MD5 and/or SHA, are
acceptable, but cannot provide more security than the size of a 16 byte block
size. [AES] TLS currently only supports the
random number generator state. (For example, MD5-based PRNGs usually
provide 128 bits and 256 bit key
sizes.
application protocol
An application protocol is a protocol that normally layers
directly on top of state.)
To estimate the amount transport layer (e.g., TCP/IP). Examples
include HTTP, TELNET, FTP, and SMTP.
asymmetric cipher
See public key cryptography.
authenticated encryption with additional data (AEAD)
A symmetric encryption algorithm that simultaneously provides
confidentiality and message integrity.
authentication
Authentication is the ability of seed material being produced, add one entity to determine the
number
identity of another entity.
block cipher
A block cipher is an algorithm that operates on plaintext in
groups of bits, called blocks. 64 bits is a common block size.
bulk cipher
A symmetric encryption algorithm used to encrypt large quantities
of unpredictable information data.
cipher block chaining (CBC)
CBC is a mode in each seed byte. For
example, keystroke timing values taken from which every plaintext block encrypted with a PC compatible's 18.2 Hz
timer provide 1 or 2 secure bits each, even though
block cipher is first exclusive-ORed with the total size previous ciphertext
block (or, in the case of the counter value first block, with the
initialization vector). For decryption, every block is 16 bits or more. To seed a 128-bit PRNG, one
would thus require approximately 100 such timer values.
[RANDOM] provides guidance on first
decrypted, then exclusive-ORed with the generation previous ciphertext block
(or IV).
certificate
As part of random values.
D.2 Certificates and authentication
Implementations are responsible for verifying the integrity of X.509 protocol (a.k.a. ISO Authentication
framework), certificates and should generally support certificate revocation
messages. Certificates should always be verified to ensure proper
signing are assigned by a trusted Certificate
Authority (CA). The selection and
addition of trusted CAs should be done very carefully. Users should
be able to view information about the certificate and root CA.
D.3 CipherSuites
TLS supports a range of key sizes and security levels, including some
which provide no or minimal security. A proper implementation will
probably not support many cipher suites. For example, 40-bit
encryption is easily broken, so implementations requiring a strong
security should not allow 40-bit keys. Similarly, anonymous Diffie-
Hellman is strongly discouraged because it cannot prevent man-in-the-
middle attacks. Applications should also enforce minimum and maximum
key sizes. For example, certificate chains containing 512-bit RSA
keys binding between a party's identity
or signatures are not appropriate for high-security
applications. some other attributes and its public key.
client
The application entity that initiates a TLS connection to a
Dierks & Rescorla Standards Track [Page 90] draft-ietf-tls-rfc4346-bis-02.txt 69] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
E. Backward Compatibility
For historical reasons and in order to avoid a profligate consumption
of reserved port numbers, application protocols which are secured by
TLS, SSL 3.0, and SSL 2.0 all frequently share the same connection
port: for example, the https protocol (HTTP secured by SSL March 2007
server. This may or TLS)
uses port 443 regardless of which security protocol it is using.
Thus, some mechanism must be determined to distinguish and negotiate
among the various protocols.
TLS versions 1.2, 1.1, 1.0, and SSL 3.0 are very similar; thus,
supporting them all at may not imply that the same time is relatively easy. TLS clients
who wish to negotiate with such older servers SHOULD send client
hello messages using initiated the SSL 3.0 record format and client hello
structure, sending {3, 3} for
underlying transport connection. The primary operational
difference between the server and client version field to note is that
they support TLS 1.2 and {3, 0} for the record version field (because the SSLv3 record format server is being used--although
generally authenticated, while the cleartext record
format client is only optionally
authenticated.
client write key
The key used to encrypt data written by the same for all versions). If client.
client write MAC secret
The secret data used to authenticate data written by the server supports only client.
connection
A connection is a
downrev version it will respond with transport (in the OSI layering model
definition) that provides a downrev 3.0 server hello; if
it supports TLS 1.2 it will respond suitable type of service. For TLS,
such connections are peer-to-peer relationships. The connections
are transient. Every connection is associated with one session.
Data Encryption Standard
DES is a TLS 1.2 server hello. The
negotiation then proceeds as appropriate for the negotiated protocol.
Similarly, very widely used symmetric encryption algorithm. DES is
a TLS 1.2 server which wishes to interoperate block cipher with
downrev clients SHOULD accept downrev client hello messages a 56 bit key and
respond with appropriate version fields. an 8 byte block size. Note
that the version in the
server hello message and in the record header are the same.
Whenever a client already knows the highest protocol known to a
server (for example, when resuming a session), TLS, for key generation purposes, DES is treated as
having an 8 byte key length (64 bits), but it SHOULD initiate the
connection still only provides
56 bits of protection. (The low bit of each key byte is presumed
to be set to produce odd parity in that native protocol.
TLS 1.1 clients that support SSL Version 2.0 servers MUST send SSL
Version 2.0 client hello messages [SSL2]. key byte.) DES can also
be operated in a mode where three independent keys and three
encryptions are used for each block of data; this uses 168 bits
of key (24 bytes in the TLS servers SHOULD accept
either client hello format if they wish to support SSL 2.0 clients on key generation method) and provides
the same connection port. The only deviations from equivalent of 112 bits of security. [DES], [3DES]
Digital Signature Standard (DSS)
A standard for digital signing, including the Version 2.0
specification are Digital Signing
Algorithm, approved by the ability to specify a version with a value National Institute of
three Standards and the support for more ciphering types
Technology, defined in NIST FIPS PUB 186, "Digital Signature
Standard", published May, 1994 by the CipherSpec.
Warning: The ability U.S. Dept. of Commerce.
[DSS]
digital signatures
Digital signatures utilize public key cryptography and one-way
hash functions to send Version 2.0 client hello messages will produce a signature of the data that can be
phased out with all due haste. Implementors SHOULD make every
effort to move forward as quickly as possible. Version 3.0
provides better mechanisms for moving to newer versions.
The following cipher specifications are carryovers from SSL Version
2.0. These are assumed
authenticated, and is difficult to use RSA for key exchange forge or repudiate.
handshake
An initial negotiation between client and
authentication.
V2CipherSpec TLS_RC4_128_WITH_MD5 = { 0x01,0x00,0x80 }; server that establishes
the parameters of their transactions.
Initialization Vector (IV)
When a block cipher is used in CBC mode, the initialization
Dierks & Rescorla Standards Track [Page 91] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
V2CipherSpec TLS_RC4_128_EXPORT40_WITH_MD5 = { 0x02,0x00,0x80 };
V2CipherSpec TLS_RC2_CBC_128_CBC_WITH_MD5 = { 0x03,0x00,0x80 };
V2CipherSpec TLS_RC2_CBC_128_CBC_EXPORT40_WITH_MD5
= { 0x04,0x00,0x80 };
V2CipherSpec TLS_IDEA_128_CBC_WITH_MD5 = { 0x05,0x00,0x80 };
V2CipherSpec TLS_DES_64_CBC_WITH_MD5 = { 0x06,0x00,0x40 };
V2CipherSpec TLS_DES_192_EDE3_CBC_WITH_MD5 = { 0x07,0x00,0xC0 };
Cipher specifications native to 70] draft-ietf-tls-rfc4346-bis-03.txt TLS can be included in Version 2.0
client hello messages using the syntax below. Any V2CipherSpec
element March 2007
vector is exclusive-ORed with its first byte equal to zero will be ignored by Version
2.0 servers. Clients sending any of the above V2CipherSpecs SHOULD
also include the TLS equivalent (see Appendix A.5):
V2CipherSpec (see TLS name) = { 0x00, CipherSuite };
Note: TLS 1.2 clients may generate the SSLv2 EXPORT cipher suites in
handshakes for backward compatibility but MUST NOT negotiate them in
TLS 1.2 mode.
E.1. Version 2 client hello
The Version 2.0 client hello the first plaintext block prior to
encryption.
IDEA
A 64-bit block cipher designed by Xuejia Lai and James Massey.
[IDEA]
Message Authentication Code (MAC)
A Message Authentication Code is a one-way hash computed from a
message and some secret data. It is presented below using this
document's presentation model. The true definition difficult to forge without
knowing the secret data. Its purpose is still assumed to be detect if the SSL Version 2.0 specification. Note that this message MUST
has been altered.
master secret
Secure secret data used for generating encryption keys, MAC
secrets, and IVs.
MD5
MD5 is a secure hashing function that converts an arbitrarily
long data stream into a digest of fixed size (16 bytes). [MD5]
public key cryptography
A class of cryptographic techniques employing two-key ciphers.
Messages encrypted with the public key can only be sent directly on decrypted with
the wire, not wrapped as associated private key. Conversely, messages signed with the
private key can be verified with the public key.
one-way hash function
A one-way transformation that converts an SSLv3 record
uint8 V2CipherSpec[3];
struct {
uint16 msg_length;
uint8 msg_type;
Version version;
uint16 cipher_spec_length;
uint16 session_id_length;
uint16 challenge_length;
V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
opaque session_id[V2ClientHello.session_id_length];
opaque challenge[V2ClientHello.challenge_length;
} V2ClientHello;
msg_length
This field arbitrary amount of
data into a fixed-length hash. It is computationally hard to
reverse the length transformation or to find collisions. MD5 and SHA are
examples of the following data one-way hash functions.
RC2
A block cipher developed by Ron Rivest at RSA Data Security, Inc.
[RSADSI] described in bytes. The high
bit MUST be 1 and [RC2].
RC4
A stream cipher invented by Ron Rivest. A compatible cipher is not part of the length.
msg_type
This field,
described in conjunction with the version field, identifies a
version 2 client hello message. The value SHOULD [SCH].
RSA
A very widely used public-key algorithm that can be one (1). used for
either encryption or digital signing. [RSA]
server
The server is the application entity that responds to requests
for connections from clients. See also under client.
Dierks & Rescorla Standards Track [Page 92] draft-ietf-tls-rfc4346-bis-02.txt 71] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
version
The highest version of the protocol supported by the client
(equals ProtocolVersion.version, see Appendix A.1).
cipher_spec_length
This field March 2007
session
A TLS session is an association between a client and a server.
Sessions are created by the total length handshake protocol. Sessions define a
set of the field cipher_specs. It
cannot be zero and MUST cryptographic security parameters that can be a shared among
multiple of connections. Sessions are used to avoid the V2CipherSpec length
(3).
session_id_length
This field MUST have expensive
negotiation of new security parameters for each connection.
session identifier
A session identifier is a value of zero.
challenge_length generated by a server that
identifies a particular session.
server write key
The length in bytes of the client's challenge key used to encrypt data written by the server.
server write MAC secret
The secret data used to authenticate itself. When using the SSLv2 backward compatible
handshake data written by the client MUST server.
SHA
The Secure Hash Algorithm is defined in FIPS PUB 180-2. It
produces a 20-byte output. Note that all references to SHA
actually use the modified SHA-1 algorithm. [SHA]
SSL
Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on
SSL Version 3.0
stream cipher
An encryption algorithm that converts a 32-byte challenge.
cipher_specs
This is key into a list of all CipherSpecs the client
cryptographically strong keystream, which is willing and able
to use. There MUST be at least one CipherSpec acceptable to then exclusive-ORed
with the
server.
session_id plaintext.
symmetric cipher
See bulk cipher.
Transport Layer Security (TLS)
This field MUST be empty.
challenge
The client challenge to the server for protocol; also, the server to identify
itself is a (nearly) arbitrary length random. The TLS server will
right justify Transport Layer Security working group
of the challenge data to become Internet Engineering Task Force (IETF). See "Comments" at
the ClientHello.random
data (padded end of this document.
Dierks & Rescorla Standards Track [Page 72] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
Appendix C. CipherSuite Definitions
CipherSuite Key Cipher Hash
Exchange
TLS_NULL_WITH_NULL_NULL NULL NULL NULL
TLS_RSA_WITH_NULL_MD5 RSA NULL MD5
TLS_RSA_WITH_NULL_SHA RSA NULL SHA
TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5
TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA
TLS_RSA_WITH_IDEA_CBC_SHA RSA IDEA_CBC SHA
TLS_RSA_WITH_DES_CBC_SHA RSA DES_CBC SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA
TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA
TLS_RSA_WITH_AES_256_SHA RSA AES_256_CBC SHA
TLS_DH_DSS_WITH_DES_CBC_SHA DH_DSS DES_CBC SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA
TLS_DH_RSA_WITH_DES_CBC_SHA DH_RSA DES_CBC SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA DHE_DSS DES_CBC SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA DHE_RSA DES_CBC SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA
TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5
TLS_DH_anon_WITH_DES_CBC_SHA DH_anon DES_CBC SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA
TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA
TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA
TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA
TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA
TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA
TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA
Key
Exchange
Algorithm Description Key size limit
DHE_DSS Ephemeral DH with DSS signatures None
DHE_RSA Ephemeral DH with RSA signatures None
DH_anon Anonymous DH, no signatures None
DH_DSS DH with leading zeroes, if necessary), as specified in DSS-based certificates None
DH_RSA DH with RSA-based certificates None
RSA = none
NULL No key exchange N/A
Dierks & Rescorla Standards Track [Page 73] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
RSA RSA key exchange None
Key Expanded IV Block
Cipher Type Material Key Material Size Size
NULL Stream 0 0 0 N/A
IDEA_CBC Block 16 16 8 8
RC2_CBC_40 Block 5 16 8 8
RC4_40 Stream 5 16 0 N/A
RC4_128 Stream 16 16 0 N/A
DES40_CBC Block 5 8 8 8
DES_CBC Block 8 8 8 8
3DES_EDE_CBC Block 24 24 8 8
Type
Indicates whether this protocol specification. If the length of the challenge is
greater than 32 bytes, only the last 32 bytes are used. It is
legitimate (but not necessary) for a V3 server to reject a V2
ClientHello that has fewer than 16 bytes of challenge data.
Note: Requests to resume a TLS session MUST use stream cipher or a TLS client hello.
E.2. Avoiding man-in-the-middle version rollback
When TLS clients fall back to Version 2.0 compatibility mode, they
SHOULD use special PKCS #1 block formatting. This is done so that TLS
servers will reject Version 2.0 sessions with TLS-capable clients.
When TLS clients are cipher
running in Version 2.0 compatibility mode, they set the
right-hand (least-significant) 8 random bytes of the PKCS padding
(not including the terminal null CBC mode.
Key Material
The number of bytes from the padding) key_block that are used for
generating the RSA
encryption write keys.
Expanded Key Material
The number of bytes actually fed into the ENCRYPTED-KEY-DATA field encryption algorithm.
IV Size
The amount of data needed to be generated for the CLIENT-MASTER-KEY initialization
vector. Zero for stream ciphers; equal to 0x03 (the other padding bytes are random). After decrypting the
Dierks & Rescorla Standards Track [Page 93] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
error if these eight padding bytes are 0x03. Version 2.0 servers
receiving blocks padded block size for
block ciphers.
Block Size
The amount of data a block cipher enciphers in this manner will proceed normally. one chunk; a
block cipher running in CBC mode can only encrypt an even
multiple of its block size.
Hash Hash Padding
function Size Size
NULL 0 0
MD5 16 48
SHA 20 40
Dierks & Rescorla Standards Track [Page 94] draft-ietf-tls-rfc4346-bis-02.txt 74] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
F. Security analysis March 2007
Appendix D. Implementation Notes
The TLS protocol is designed to establish a secure connection between
a client and a server communicating over an insecure channel. This
document makes several traditional assumptions, including that
attackers have substantial computational resources and cannot obtain
secret information from sources outside the protocol. Attackers are
assumed to have the ability to capture, modify, delete, replay, and
otherwise tamper with messages sent over the communication channel. prevent many common security mistakes. This appendix outlines how TLS has been designed
section provides several recommendations to resist a variety
of attacks.
F.1. Handshake protocol
The handshake protocol is responsible for selecting a CipherSpec and
generating a Master Secret, which together comprise the primary
cryptographic parameters associated with a secure session. The
handshake protocol can also optionally authenticate parties who have
certificates signed by a trusted certificate authority.
F.1.1. Authentication assist implementors.
D.1 Random Number Generation and key exchange Seeding
TLS supports three authentication modes: authentication of both
parties, server authentication with an unauthenticated client, requires a cryptographically secure pseudorandom number generator
(PRNG). Care must be taken in designing and
total anonymity. Whenever the server is authenticated, the channel is seeding PRNGs. PRNGs
based on secure against man-in-the-middle attacks, but completely anonymous
sessions hash operations, most notably MD5 and/or SHA, are inherently vulnerable to such attacks. Anonymous
servers
acceptable, but cannot authenticate clients. If provide more security than the server is authenticated,
its certificate message must size of the
random number generator state. (For example, MD5-based PRNGs usually
provide a valid certificate chain
leading to an acceptable certificate authority. Similarly,
authenticated clients must supply an acceptable certificate to 128 bits of state.)
To estimate the
server. Each party is responsible for verifying that amount of seed material being produced, add the other's
certificate is valid and has not expired
number of bits of unpredictable information in each seed byte. For
example, keystroke timing values taken from a PC compatible's 18.2 Hz
timer provide 1 or been revoked.
The general goal 2 secure bits each, even though the total size of
the key exchange process counter value is to create 16 bits or more. Seeding a
pre_master_secret known to 128-bit PRNG, one
would thus require approximately 100 such timer values.
[RANDOM] provides guidance on the communicating parties generation of random values.
D.2 Certificates and not Authentication
Implementations are responsible for verifying the integrity of
certificates and should generally support certificate revocation
messages. Certificates should always be verified to
attackers. ensure proper
signing by a trusted Certificate Authority (CA). The pre_master_secret will selection and
addition of trusted CAs should be used to generate the
master_secret (see Section 8.1). The master_secret is required done very carefully. Users should
be able to
generate view information about the finished messages, encryption keys, and MAC secrets (see
Sections 7.4.10, 7.4.11 certificate and 6.3). By sending root CA.
D.3 CipherSuites
TLS supports a correct finished
message, parties thus prove that they know the correct
pre_master_secret.
F.1.1.1. Anonymous range of key exchange
Completely sizes and security levels, including some
that provide no or minimal security. A proper implementation will
probably not support many cipher suites. For instance, anonymous sessions can be established using
Diffie-Hellman is strongly discouraged because it cannot prevent man-
in-the-middle attacks. Applications should also enforce minimum and
maximum key sizes. For example, certificate chains containing 512-bit
RSA keys or Diffie-
Hellman signatures are not appropriate for key exchange. With anonymous RSA, the client encrypts a
pre_master_secret with the server's uncertified public key extracted high-security
applications.
Dierks & Rescorla Standards Track [Page 95] draft-ietf-tls-rfc4346-bis-02.txt 75] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
from March 2007
Appendix E. Backward Compatibility
E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0
Since there are various versions of TLS (1.0, 1.1, 1.2, and any
future versions) and SSL (2.0 and 3.0), means are needed to negotiate
the server key exchange message. specific protocol version to use. The result is sent in TLS protocol provides a client
key exchange message. Since eavesdroppers do not know the server's
private key, it will be infeasible
built-in mechanism for them version negotiation so as not to decode the
pre_master_secret.
Note: No anonymous RSA Cipher Suites are defined in this document.
With Diffie-Hellman, bother other
protocol components with the server's public parameters complexities of version selection.
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are contained in very similar, and use
compatible ClientHello messages; thus, supporting all of them is
relatively easy. Similarly, servers can easily handle clients trying
to use future versions of TLS as long as the server key exchange message ClientHello format
remains compatible, and the client's are sent client support the highest protocol
version available in the server.
A TLS 1.2 client key exchange message. Eavesdroppers who do not know the
private values should not be able to find the Diffie-Hellman result
(i.e. the pre_master_secret).
Warning: Completely anonymous connections only provide protection
against passive eavesdropping. Unless an independent tamper-
proof channel is used wishes to verify that the finished messages
were not replaced by an attacker, server authentication is
required in environments where active man-in-the-middle
attacks are negotiate with such older servers will
send a concern.
F.1.1.2. RSA key exchange and authentication
With RSA, key exchange and server authentication are combined. The
public key may be either contained normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in
ClientHello.client_version. If the server's certificate or may
be a temporary RSA key sent in a server key exchange message. When
temporary RSA keys are used, they are signed by the server's RSA
certificate. The signature includes does not support this
version, it will respond with ServerHello containing an older version
number. If the current ClientHello.random,
so old signatures and temporary keys cannot be replayed. Servers may client agrees to use a single temporary RSA key for multiple this version, the negotiation sessions.
Note: The temporary RSA key option is useful if servers need large
certificates but must comply with government-imposed size limits
on keys used for key exchange.
Note that if ephemeral RSA
will proceed as appropriate for the negotiated protocol.
If the version chosen by the server is not used, compromise of supported by the server's
static RSA key results in client
(or not acceptable), the client MUST send a "protocol_version" alert
message and close the connection.
If a loss of confidentiality for all sessions
protected under that static key. TLS users desiring Perfect Forward
Secrecy should use DHE cipher suites. The damage done by exposure of server receives a private key can be limited ClientHello containing a version number
greater than the highest version supported by changing one's private key (and
certificate) frequently.
After verifying the server's certificate, server, it MUST
reply according to the client encrypts highest version supported by the server.
A TLS server can also receive a
pre_master_secret ClientHello containing version number
smaller than the highest supported version. If the server wishes to
negotiate with old clients, it will proceed as appropriate for the server's public key. By successfully
decoding
highest version supported by the pre_master_secret server that is not greater than
ClientHello.client_version. For example, if the server supports TLS
1.0, 1.1, and producing a correct finished
message, 1.2, and client_version is TLS 1.0, the server demonstrates that will
proceed with a TLS 1.0 ServerHello. If server supports (or is willing
to use) only versions greater than client_version, it MUST send a
"protocol_version" alert message and close the connection.
Whenever a client already knows the private key
corresponding highest protocol known to a
server (for example, when resuming a session), it SHOULD initiate the
connection in that native protocol.
Note: some server certificate.
When RSA is used for key exchange, clients implementations are authenticated using known to implement version
negotiation incorrectly. For example, there are buggy TLS 1.0 servers
Dierks & Rescorla Standards Track [Page 96] draft-ietf-tls-rfc4346-bis-02.txt 76] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006 March 2007
that simply close the connection when the certificate verify message (see Section 7.4.10). The client signs offers a value derived from version
newer than TLS 1.0. Also, it is known that some servers will refuse
connection if any TLS extensions are included in ClientHello.
Interoperability with such buggy servers is a complex topic beyond
the master_secret scope of this document, and all preceding handshake
messages. These handshake messages include may require multiple connection
attempts by the server certificate,
which binds client.
Earlier versions of the signature to TLS specification were not fully clear on
what the server, and ServerHello.random, record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which binds
version of the signature protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.
TLS clients that wish to negotiate with older servers MAY send any
value {03,XX} as the current handshake process.
F.1.1.3. Diffie-Hellman key exchange record layer version number. Typical values
would be {03,00}, the lowest version number supported by the client,
and the value of ClientHello.client_version. No single value will
guarantee interoperability with authentication
When Diffie-Hellman key exchange all old servers, but this is used, the server can either
supply a certificate containing fixed Diffie-Hellman parameters or
can use
complex topic beyond the server key exchange scope of this document.
E.2 Compatibility with SSL 2.0
TLS 1.2 clients that wish to support SSL 2.0 servers MUST send
version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST
contain the same version number as would be used for ordinary
ClientHello, and MUST encode the supported TLS ciphersuites in the
CIPHER-SPECS-DATA field as described below.
Warning: The ability to send a set of temporary
Diffie-Hellman parameters signed with a DSS or RSA certificate.
Temporary parameters are hashed version 2.0 CLIENT-HELLO messages will be
phased out with all due haste, since the hello.random values before
signing newer ClientHello format
provides better mechanisms for moving to ensure newer versions and
negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0.
However, even TLS servers that attackers do not replay old parameters. In
either case, the client can verify the certificate or signature to
ensure that support SSL 2.0 SHOULD accept
version 2.0 CLIENT-HELLO messages. The message is presented below in
sufficient detail for TLS server implementors; the parameters belong true definition is
still assumed to be [SSL2].
For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the server.
If the client has same
way as a certificate containing fixed Diffie-Hellman
parameters, its certificate contains the information required to
complete the key exchange. ClientHello with a "null" compression method and no
extensions. Note that in this case the client and
server will generate the same Diffie-Hellman result (i.e.,
pre_master_secret) every time they communicate. To prevent the
pre_master_secret from staying in memory any longer than necessary,
it should message MUST be converted into sent directly on the master_secret as soon wire,
not wrapped as possible.
Client Diffie-Hellman parameters must a TLS record. For the purposes of calculating Finished
and CertificateVerify, the msg_length field is not considered to be compatible with those
supplied by a
part of the server for handshake message.
uint8 V2CipherSpec[3];
Dierks & Rescorla Standards Track [Page 77] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
struct {
uint16 msg_length;
uint8 msg_type;
Version version;
uint16 cipher_spec_length;
uint16 session_id_length;
uint16 challenge_length;
V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length];
opaque session_id[V2ClientHello.session_id_length];
opaque challenge[V2ClientHello.challenge_length;
} V2ClientHello;
msg_length
The highest bit MUST be 1; the key exchange to work.
If remaining bits contain the client has a standard DSS or RSA certificate or is
unauthenticated, it sends a set
length of temporary parameters to the server following data in bytes.
msg_type
This field, in conjunction with the client key exchange message, then optionally uses version field, identifies a
certificate verify message
version 2 client hello message. The value SHOULD be one (1).
version
Equal to authenticate itself.
If the same DH keypair ClientHello.client_version.
cipher_spec_length
This field is to the total length of the field cipher_specs. It
cannot be used for zero and MUST be a multiple handshakes, either
because of the client or server has V2CipherSpec length
(3).
session_id_length
This field MUST have a certificate containing value of zero. MUST be zero for a fixed DH
keypair or because client
that claims to support TLS 1.2.
challenge_length
The length in bytes of the server is reusing DH keys, care must be taken client's challenge to prevent small subgroup attacks. Implementations SHOULD follow the
guidelines found in [SUBGROUP].
Small subgroup attacks server to
authenticate itself. Historically, permissible values are most easily avoided by between
16 and 32 bytes inclusive. When using one of the
DHE ciphersuites and generating a fresh DH private key (X) for each
handshake. If SSLv2 backward
compatible handshake the client MUST use a suitable base (such as 2) 32-byte challenge.
cipher_specs
This is chosen, g^X mod p can be
computed very quickly so a list of all CipherSpecs the performance cost client is minimized.
Additionally, using a fresh key for each handshake provides Perfect
Forward Secrecy. Implementations SHOULD generate a new X for willing and able
to use. In addition to the 2.0 cipher specs defined in [SSL2],
this includes the TLS cipher suites normally sent in
ClientHello.cipher_suites, each
handshake when using DHE ciphersuites.
F.1.2. Version rollback attacks cipher suite prefixed by a zero
byte. For example, TLS ciphersuite {0x00,0x0A} would be sent as
{0x00,0x00,0x0A}.
session_id
This field MUST be empty.
Dierks & Rescorla Standards Track [Page 97] draft-ietf-tls-rfc4346-bis-02.txt 78] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
Because March 2007
challenge
Corresponds to ClientHello.random. If the challenge length is
less than 32, the TLS includes substantial improvements over SSL Version 2.0,
attackers may try server will pad the data with leading
(note: not trailing) zero bytes to make TLS-capable it 32 bytes long.
Note: Requests to resume a TLS session MUST use a TLS client hello.
E.2. Avoiding Man-in-the-Middle Version Rollback
When TLS clients and servers fall back to Version 2.0. This attack can occur if (and only if) two TLS-
capable parties use an SSL 2.0 handshake.
Although the solution using non-random compatibility mode, they
SHOULD use special PKCS #1 block type 2 message
padding formatting. This is inelegant, it provides a reasonably secure way for Version
3.0 done so that TLS
servers to detect will reject Version 2.0 sessions with TLS-capable clients.
When TLS clients are in Version 2.0 compatibility mode, they set the attack. This solution is not secure against
attackers who can brute force
right-hand (least-significant) 8 random bytes of the key and substitute a new ENCRYPTED-
KEY-DATA message containing PKCS padding
(not including the terminal null of the same key (but with normal padding)
before for the application specified wait threshold has expired. Parties
concerned about attacks of this scale should not be using 40-bit RSA
encryption keys anyway. Altering of the padding ENCRYPTED-KEY-DATA field of the least-significant
8 CLIENT-MASTER-KEY
to 0x03 (the other padding bytes of are random). After decrypting the PKCS
ENCRYPTED-KEY-DATA field, servers that support TLS SHOULD issue an
error if these eight padding does not impact security for the size of
the signed hashes and RSA key lengths used bytes are 0x03. Version 2.0 servers
receiving blocks padded in the protocol, since this manner will proceed normally.
Dierks & Rescorla Standards Track [Page 79] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
Appendix F. Security Analysis
The TLS protocol is essentially equivalent designed to increasing the input block size by
8 bytes.
F.1.3. Detecting attacks against establish a secure connection between
a client and a server communicating over an insecure channel. This
document makes several traditional assumptions, including that
attackers have substantial computational resources and cannot obtain
secret information from sources outside the handshake protocol
An attacker might try protocol. Attackers are
assumed to influence have the handshake exchange ability to make the
parties select different encryption algorithms than they would
normally chooses.
For this attack, an attacker must actively change one or more
handshake messages. If this occurs, the client capture, modify, delete, replay, and server will
compute different values for
otherwise tamper with messages sent over the communication channel.
This appendix outlines how TLS has been designed to resist a variety
of attacks.
F.1. Handshake Protocol
The handshake message hashes. As protocol is responsible for selecting a
result, CipherSpec and
generating a Master Secret, which together comprise the primary
cryptographic parameters associated with a secure session. The
handshake protocol can also optionally authenticate parties will not accept each others' finished messages.
Without the master_secret, the attacker cannot repair who have
certificates signed by a trusted certificate authority.
F.1.1. Authentication and Key Exchange
TLS supports three authentication modes: authentication of both
parties, server authentication with an unauthenticated client, and
total anonymity. Whenever the finished
messages, so server is authenticated, the attack will be discovered.
F.1.4. Resuming channel is
secure against man-in-the-middle attacks, but completely anonymous
sessions
When a connection are inherently vulnerable to such attacks. Anonymous
servers cannot authenticate clients. If the server is established by resuming authenticated,
its certificate message must provide a session, new
ClientHello.random and ServerHello.random values are hashed with valid certificate chain
leading to an acceptable certificate authority. Similarly,
authenticated clients must supply an acceptable certificate to the
session's master_secret. Provided
server. Each party is responsible for verifying that the master_secret other's
certificate is valid and has not expired or been
compromised and that revoked.
The general goal of the secure hash operations used key exchange process is to create a
pre_master_secret known to produce the
encryption keys communicating parties and MAC secrets are secure, the connection should not to
attackers. The pre_master_secret will be
secure and effectively independent from previous connections.
Attackers cannot use known encryption keys or MAC secrets used to
compromise generate the
master_secret without breaking (see Section 8.1). The master_secret is required to
generate the secure hash
operations (which use both SHA finished messages, encryption keys, and MD5).
Sessions cannot be resumed unless both the client MAC secrets (see
Sections 7.4.9 and server agree.
If either party suspects 6.3). By sending a correct finished message,
parties thus prove that they know the session may have been compromised,
or that certificates may have expired correct pre_master_secret.
F.1.1.1. Anonymous Key Exchange
Completely anonymous sessions can be established using RSA or been revoked, it should
force Diffie-
Hellman for key exchange. With anonymous RSA, the client encrypts a full handshake. An upper limit of 24 hours
pre_master_secret with the server's uncertified public key extracted
from the server key exchange message. The result is suggested for
session ID lifetimes, since an attacker who obtains sent in a master_secret client
Dierks & Rescorla Standards Track [Page 98] draft-ietf-tls-rfc4346-bis-02.txt 80] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
may March 2007
key exchange message. Since eavesdroppers do not know the server's
private key, it will be able infeasible for them to impersonate decode the compromised party until
pre_master_secret.
Note: No anonymous RSA Cipher Suites are defined in this document.
With Diffie-Hellman, the
corresponding session ID is retired. Applications that may be run server's public parameters are contained in
relatively insecure environments
the server key exchange message and the client's are sent in the
client key exchange message. Eavesdroppers who do not know the
private values should not write session IDs be able to
stable storage.
F.1.5 Extensions
Security considerations for find the extension mechanism Diffie-Hellman result
(i.e. the pre_master_secret).
Warning: Completely anonymous connections only provide protection
against passive eavesdropping. Unless an independent tamper-
proof channel is used to verify that the finished messages
were not replaced by an attacker, server authentication is
required in general, environments where active man-in-the-middle
attacks are a concern.
F.1.1.2. RSA Key Exchange and Authentication
With RSA, key exchange and server authentication are combined. The
public key is contained in the design server's certificate. Note that
compromise of new extensions, are described the server's static RSA key results in a loss of
confidentiality for all sessions protected under that static key. TLS
users desiring Perfect Forward Secrecy should use DHE cipher suites.
The damage done by exposure of a private key can be limited by
changing one's private key (and certificate) frequently.
After verifying the previous section.
A security analysis of each of server's certificate, the extensions defined in this
document is given below.
In general, implementers should continue to monitor client encrypts a
pre_master_secret with the state of server's public key. By successfully
decoding the
art, pre_master_secret and address any weaknesses identified.
F.1.5.1 Security of server_name
If producing a single server hosts several domains, then clearly it is
necessary for correct finished
message, the owners of each domain to ensure that this satisfies
their security needs. Apart from this, server_name does not appear
to introduce significant security issues.
Implementations MUST ensure server demonstrates that a buffer overflow does not occur
whatever the values of the length fields in server_name.
Although this document specifies an encoding for internationalized
hostnames in the server_name extension, it does not address any
security issues associated with knows the use of internationalized
hostnames in TLS - in particular, private key
corresponding to the consequences of "spoofed" names
that are indistinguishable from another name when displayed or
printed. It is recommended that server certificates not be issued certificate.
When RSA is used for internationalized hostnames unless procedures key exchange, clients are in place to
mitigate authenticated using
the risk of spoofed hostnames.
6.2. Security of max_fragment_length certificate verify message (see Section 7.4.9). The maximum fragment length takes effect immediately, including for client signs
a value derived from the master_secret and all preceding handshake
messages. However, that does not introduce any security
complications that are not already present in TLS, since [TLS]
requires implementations to be able to handle fragmented These handshake
messages.
Note that as described in section XXX, once a non-null cipher suite
has been activated, messages include the effective maximum fragment length depends on server certificate,
which binds the cipher suite signature to the server, and compression method, as well as on ServerHello.random,
which binds the signature to the current handshake process.
F.1.1.3. Diffie-Hellman Key Exchange with Authentication
When Diffie-Hellman key exchange is used, the negotiated
max_fragment_length. This must be taken into account when sizing
buffers, and checking for buffer overflow. server can either
supply a certificate containing fixed Diffie-Hellman parameters or
use the server key exchange message to send a set of temporary
Diffie-Hellman parameters signed with a DSS or RSA certificate.
Dierks & Rescorla Standards Track [Page 99] draft-ietf-tls-rfc4346-bis-02.txt 81] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
F.1.5.2 Security of client_certificate_url
There March 2007
Temporary parameters are two major issues hashed with this extension.
The first major issue is whether or not clients should include
certificate hashes when they send certificate URLs.
When client authentication is used *without* the
client_certificate_url extension, hello.random values before
signing to ensure that attackers do not replay old parameters. In
either case, the client certificate chain is
covered by the Finished message hashes. The purpose of including
hashes and checking them against can verify the retrieved certificate chain, is or signature to
ensure that the same property holds when this extension is used -
i.e., that all of parameters belong to the information in server.
If the client has a certificate chain retrieved
by containing fixed Diffie-Hellman
parameters, its certificate contains the server is as information required to
complete the key exchange. Note that in this case the client intended.
On and
server will generate the other hand, omitting certificate hashes enables functionality
that is desirable same Diffie-Hellman result (i.e.,
pre_master_secret) every time they communicate. To prevent the
pre_master_secret from staying in some circumstances - for example clients can memory any longer than necessary,
it should be
issued daily certificates that are stored at a fixed URL and need not converted into the master_secret as soon as possible.
Client Diffie-Hellman parameters must be provided to compatible with those
supplied by the client. Clients that choose server for the key exchange to omit work.
If the client has a standard DSS or RSA certificate
hashes should be aware or is
unauthenticated, it sends a set of temporary parameters to the possibility of an attack server
in which the
attacker obtains client key exchange message, then optionally uses a valid
certificate on verify message to authenticate itself.
If the client's key that same DH keypair is
different from the certificate the client intended to provide.
Although TLS uses both MD5 and SHA-1 hashes in several other places,
this was not believed to be necessary here. The property required of
SHA-1 is second pre-image resistance.
The second major issue is that support used for client_certificate_url
involves multiple handshakes, either
because the client or server acting as has a client in another URL protocol. The certificate containing a fixed DH
keypair or because the server therefore becomes subject is reusing DH keys, care must be taken
to many of the same security
concerns that clients of prevent small subgroup attacks. Implementations SHOULD follow the URL scheme
guidelines found in [SUBGROUP].
Small subgroup attacks are subject to, with the
added concern that most easily avoided by using one of the client
DHE ciphersuites and generating a fresh DH private key (X) for each
handshake. If a suitable base (such as 2) is chosen, g^X mod p can attempt to prompt the server to
connect to some, possibly weird-looking URL.
In general this issue means that an attacker might use be
computed very quickly, therefore the server to
indirectly attack another host that performance cost is vulnerable minimized.
Additionally, using a fresh key for each handshake provides Perfect
Forward Secrecy. Implementations SHOULD generate a new X for each
handshake when using DHE ciphersuites.
F.1.2. Version Rollback Attacks
Because TLS includes substantial improvements over SSL Version 2.0,
attackers may try to make TLS-capable clients and servers fall back
to some security
flaw. It also introduces the possibility of denial of service
attacks in which Version 2.0. This attack can occur if (and only if) two TLS-
capable parties use an attacker makes many connections to the server,
each of which results in SSL 2.0 handshake.
Although the server attempting solution using non-random PKCS #1 block type 2 message
padding is inelegant, it provides a connection reasonably secure way for Version
3.0 servers to the
target of detect the attack.
Note that the server may be behind a firewall or otherwise able to
access hosts that would This solution is not be directly accessible from the public
Internet; this could exacerbate secure against
attackers who can brute force the potential security key and denial of
service problems described above, as well as allowing the existence
of internal hosts to be confirmed when they would otherwise be
hidden.
The detailed security concerns involved will depend on the URL
Dierks & Rescorla Standards Track [Page 100] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
schemes supported by the server. In the case of HTTP, the concerns
are similar to those that apply to substitute a publicly accessible HTTP proxy
server. In new ENCRYPTED-
KEY-DATA message containing the case of HTTPS, same key (but with normal padding)
before the possibility for loops and
deadlocks to be created exists and should be addressed. In application specified wait threshold has expired. Altering
the case
of FTP, attacks similar to FTP bounce attacks arise.
As a result padding of this issue, it is RECOMMENDED that the
client_certificate_url extension should have to be specifically
enabled by a server administrator, rather than being enabled by
default. It is also RECOMMENDED that URI protocols be enabled by the
administrator individually, and only a minimal set least significant 8 bytes of protocols be
enabled, with unusual protocols offering limited security or whose
security is the PKCS padding does
Dierks & Rescorla Standards Track [Page 82] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
not well-understood being avoided.
As discussed impact security for the size of the signed hashes and RSA key
lengths used in [URI], URLs that specify ports other than the default
may cause problems, as may very long URLs (which are more likely protocol, since this is essentially equivalent to
be useful in exploiting buffer overflow bugs).
Also note that HTTP caching proxies are common on
increasing the Internet, and
some proxies do not check for input block size by 8 bytes.
F.1.3. Detecting Attacks Against the latest version of Handshake Protocol
An attacker might try to influence the handshake exchange to make the
parties select different encryption algorithms than they would
normally chooses.
For this attack, an object
correctly. If a request using HTTP (or another caching protocol)
goes through a misconfigured attacker must actively change one or otherwise broken proxy, more
handshake messages. If this occurs, the proxy may
return an out-of-date response.
F.1.5.4. Security of trusted_ca_keys
It is possible that which CA root keys a client possesses could be
regarded as confidential information. and server will
compute different values for the handshake message hashes. As a
result, the CA root key
indication extension should be used with care.
The use of the SHA-1 certificate hash alternative ensures that parties will not accept each
certificate is specified unambiguously. As for others' finished messages.
Without the previous
extension, it was not believed necessary to use both MD5 and SHA-1
hashes.
F.1.5.5. Security of truncated_hmac
It master_secret, the attacker cannot repair the finished
messages, so the attack will be discovered.
F.1.4. Resuming Sessions
When a connection is possible that truncated MACs are weaker than "un-truncated"
MACs. However, no significant weaknesses are currently known or
expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.
Note established by resuming a session, new
ClientHello.random and ServerHello.random values are hashed with the
session's master_secret. Provided that the output length of a MAC need master_secret has not be as long as been
compromised and that the
length of a symmetric cipher key, since forging of secure hash operations used to produce the
encryption keys and MAC values cannot secrets are secure, the connection should be done off-line: in TLS, a single failed
secure and effectively independent from previous connections.
Attackers cannot use known encryption keys or MAC guess will cause secrets to
compromise the
immediate termination of master_secret without breaking the TLS session.
Since secure hash
operations (which use both SHA and MD5).
Sessions cannot be resumed unless both the MAC algorithm only takes effect after client and server agree.
If either party suspects that the handshake
messages session may have been authenticated by the hashes in the Finished
Dierks & Rescorla Standards Track [Page 101] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
messages, compromised,
or that certificates may have expired or been revoked, it should
force a full handshake. An upper limit of 24 hours is not possible suggested for
session ID lifetimes, since an active attacker to force
negotiation of the truncated HMAC extension where it would not
otherwise who obtains a master_secret
may be used (to able to impersonate the extent that compromised party until the handshake authentication
corresponding session ID is
secure). Therefore, in the event retired. Applications that any security problem were
found with truncated HMAC in future, if either the client or the
server for a given session were updated to take into account the
problem, they would may be able to veto use of this extension.
F.1.5.6. Security of status_request
If a client requests an OCSP response, it must take into account that
an attacker's server using a compromised key could (and probably
would) pretend run in
relatively insecure environments should not write session IDs to support
stable storage.
F.1.5 Extensions
Security considerations for the extension. extension mechanism in general, and
the design of new extensions, are described in the previous section.
A client that requires
OCSP validation security analysis of each of certificates SHOULD either contact the OCSP server
directly extensions defined in this case, or abort
document is given below.
In general, implementers should continue to monitor the handshake.
Use state of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
improve security against attacks that attempt to replay OCSP
responses; see section 4.4.1 of [OCSP] for further details.
art, and address any weaknesses identified.
Dierks & Rescorla Standards Track [Page 83] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
F.2. Protecting application data Application Data
The master_secret is hashed with the ClientHello.random and
ServerHello.random to produce unique data encryption keys and MAC
secrets for each connection.
Outgoing data is protected with a MAC before transmission. To prevent
message replay or modification attacks, the MAC is computed from the
MAC secret, the sequence number, the message length, the message
contents, and two fixed character strings. The message type field is
necessary to ensure that messages intended for one TLS Record Layer
client are not redirected to another. The sequence number ensures
that attempts to delete or reorder messages will be detected. Since
sequence numbers are 64-bits 64 bits long, they should never overflow.
Messages from one party cannot be inserted into the other's output,
since they use independent MAC secrets. Similarly, the server-write
and client-write keys are independent independent, so stream cipher keys are used
only once.
If an attacker does break an encryption key, all messages encrypted
with it can be read. Similarly, compromise of a MAC key can make
message modification attacks possible. Because MACs are also
encrypted, message-alteration attacks generally require breaking the
encryption algorithm as well as the MAC.
Note: MAC secrets may be larger than encryption keys, so messages can
remain tamper resistant even if encryption keys are broken.
Dierks & Rescorla Standards Track [Page 102] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
F.3. Explicit IVs
[CBCATT] describes a chosen plaintext attack on TLS that depends
on knowing the IV for a record. Previous versions of TLS [TLS1.0]
used the CBC residue of the previous record as the IV and
therefore enabled this attack. This version uses an explicit IV
in order to protect against this attack.
F.4
F.4. Security of Composite Cipher Modes
TLS secures transmitted application data via the use of symmetric
encryption and authentication functions defined in the negotiated
ciphersuite. The objective is to protect both the integrity and
confidentiality of the transmitted data from malicious actions by
active attackers in the network. It turns out that the order in
which encryption and authentication functions are applied to the
data plays an important role for achieving this goal [ENCAUTH].
The most robust method, called encrypt-then-authenticate, first
applies encryption to the data and then applies a MAC to the
Dierks & Rescorla Standards Track [Page 84] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
ciphertext. This method ensures that the integrity and
confidentiality goals are obtained with ANY pair of encryption
and MAC functions functions, provided that the former is secure against
chosen plaintext attacks and the MAC is secure against chosen-
message attacks. TLS uses another method, called authenticate-
then-encrypt, in which first a MAC is computed on the plaintext
and then the concatenation of plaintext and MAC is encrypted.
This method has been proven secure for CERTAIN combinations of
encryption functions and MAC functions, but is not guaranteed to
be secure in general. In particular, it has been shown that there
exist perfectly secure encryption functions (secure even in the
information theoretic
information-theoretic sense) that combined with any secure MAC
function
function, fail to provide the confidentiality goal against an
active attack. Therefore, new ciphersuites and operation modes
adopted into TLS need to be analyzed under the authenticate-then-
encrypt method to verify that they achieve the stated integrity
and confidentiality goals.
Currently, the security of the authenticate-then-encrypt method
has been proven for some important cases. One is the case of
stream ciphers in which a computationally unpredictable pad of
the length of the message message, plus the length of the MAC tag tag, is
produced using a pseudo-random generator and this pad is xor-ed
with the concatenation of plaintext and MAC tag. The other is
the case of CBC mode using a secure block cipher. In this case,
security can be shown if one applies one CBC encryption pass to
the concatenation of plaintext and MAC and uses a new,
independent
independent, and unpredictable, IV for each new pair of plaintext
Dierks & Rescorla Standards Track [Page 103] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
and MAC. In previous versions of SSL, CBC mode was used properly
EXCEPT that it used a predictable IV in the form of the last
block of the previous ciphertext. This made TLS open to chosen
plaintext attacks. This verson of the protocol is immune to
those attacks. For exact details in the encryption modes proven
secure see [ENCAUTH].
F.5 Denial of Service
TLS is susceptible to a number of denial of service (DoS) attacks.
In particular, an attacker who initiates a large number of TCP
connections can cause a server to consume large amounts of CPU doing
RSA decryption. However, because TLS is generally used over TCP, it
is difficult for the attacker to hide his point of origin if proper
TCP SYN randomization is used [SEQNUM] by the TCP stack.
Because TLS runs over TCP, it is also susceptible to a number of
denial of service attacks on individual connections. In particular,
attackers can forge RSTs, thereby terminating connections, or forge
partial TLS records, thereby causing the connection to stall. These
Dierks & Rescorla Standards Track [Page 85] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
attacks cannot in general be defended against by a TCP-
using TCP-using
protocol. Implementors or users who are concerned with this class of
attack should use IPsec AH [AH] or ESP [ESP].
F.6. Final notes Notes
For TLS to be able to provide a secure connection, both the client
and server systems, keys, and applications must be secure. In
addition, the implementation must be free of security errors.
The system is only as strong as the weakest key exchange and
authentication algorithm supported, and only trustworthy
cryptographic functions should be used. Short public keys, 40-bit
bulk encryption keys, keys and
anonymous servers should be used with great caution. Implementations
and users must be careful when deciding which certificates and
certificate authorities are acceptable; a dishonest certificate
authority can do tremendous damage.
Dierks & Rescorla Standards Track [Page 104] draft-ietf-tls-rfc4346-bis-02.txt 86] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
Security Considerations
Security issues are discussed throughout this memo, especially in
Appendices D, E, and F.
Changes in This Version
[RFC Editor: Please delete this]
- Forbid decryption_failed [issue 5]
- Fix CertHashTypes declaration [issue 20]
- Fix client_version in 7.4.1.2 [issue 19]
- Require Bleichenbacher and timing attack protection [issues 17
and
12].
- Merged RFC-editor changes back in.
- Editorial changes from NIST [issue 8]
- Clarified the meaning of HelloRequest [issue 39]
- Editorial nits from Peter Williams [issue 35]
- Made maximum fragment size a MUST [issue 9]
- Clarified that resumption is not mandatory and servers may
refuse [issue 37]
- Fixed identifier for cert_hash_types [issue 38]
- Forbid sending unknown record types [issue 11]
- Clarify that DH parameters and other integers are unsigned [issue
28]
- Clarify when a server Certificate is sent [isssue 29]
- Prohibit zero-length fragments [issue 10]
- Fix reference for DES/3DES [issue 18]
- Clean up some notes on deprecated alerts [issue 6]
Dierks & Rescorla Standards Track [Page 87] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006
Security Considerations
Security issues are discussed throughout this memo, especially in
Appendices D, E, March 2007
- Remove ephemeral RSA [issue 3]
- Stripped out discussion of how to generate the IV and F. replaced it
with a randomness/unpredictability requirement [issue 7]
- Replaced the PKCS#1 text with references to PKCS#1 v2. This also
includes DigestInfo encoding [issues 1 and 22]
- Removed extension definitions and merged the ExtendedHello
definitions [issues 31 and 32]
- Replaced CipherSpec references with SecurityParameters references
[issue 2]
- Cleaned up IANA text [issues 33 and 34]
- Cleaned up backward compatibility text [issue 25]
Normative References
[AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard (AES)"
FIPS 197. November 26, 2001.
[3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
[DES] ANSI X3.106, "American National Standard Institute of Standards and Tecnology,
"Recommendation for Information
Systems-Data Link Encryption," American the Triple Data Encryption Algorithm
(TDEA) Block Cipher", NIST Special Publication 800-67, May
2004.
[DES] National Institute of Standards
Institute, 1983. and Technology, "Data
Encryption Standard (DES)", FIPS PUB 46-3, October 1999.
[DSS] NIST FIPS PUB 186-2, "Digital Signature Standard," National
Institute of Standards and Technology, U.S. Department of
Commerce, 2000.
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication," Authentication", RFC 2104, February
1997.
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
Protocol -- HTTP/1.1", RFC 2616, June 1999.
[IDEA] X. Lai, "On the Design and Security of Block Ciphers," ETH
Series in Information Processing, v. 1, Konstanz: Hartung-
Gorre Verlag, 1992.
Dierks & Rescorla Standards Track [Page 88] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
[IDNA] Faltstrom, P., Hoffman, P. and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321,
April 1992.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
Adams, "Internet X.509 Public Key Infrastructure: Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[PKCS1A] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1:
RSA Cryptography Specifications Version 1.5", RFC 2313,
March 1998.
Dierks & Rescorla Standards Track [Page 105] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
[PKCS1B] J. Jonsson, B. Kaliski, "Public-Key Cryptography Standards
(PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC
3447, February 2003.
[PKIOP] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure - Operation Protocols: FTP and HTTP", RFC
2585, May 1999.
[PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
Public Key Infrastructure: Part I: X.509 Certificate and CRL
Profile", RFC 3280, April 2002.
[RC2] Rivest, R., "A Description of the RC2(r) Encryption
Algorithm", RFC 2268, January March 1998.
[SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms,
and Source Code in C, 2ed", Published by John Wiley & Sons,
Inc. 1996.
[SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National
Institute of Standards and Technology, U.S. Department of
Commerce., August 2001.
[REQ] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] T. Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 25, RFC 3434, 2434,
October 1998.
[TLSAES] Chown, P. P., "Advanced Encryption Standard (AES) Ciphersuites
for Transport Layer Security (TLS)", RFC 3268, June 2002.
[TLSEXT] Blake-Wilson, S., Nystrom, M, M., Hopwood, D., Mikkelsen, J.,
Wright, T., "Transport Layer Security (TLS) Extensions", RFC
3546, June 2003.
Dierks & Rescorla Standards Track [Page 89] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
[TLSKRB] A. Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712, October
1999.
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 3629, November 2003.
[X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- 8:2001,
Dierks & Rescorla Standards Track [Page 106] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
"Information Systems - Open Systems Interconnection - The
Directory: Public key and Attribute certificate
frameworks."
[X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to
ISO/IEC 9594:8:2001.
Informative References
[AEAD] Mcgrew, D., "Authenticated Encryption", July 2006, draft-
mcgrew-auth-enc-00.txt.
[AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC
2402, November 1998.
4302, December 2005.
[BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against
Protocols Based on RSA Encryption Standard PKCS #1" in
Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages:
1-12, 1998.
[CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS:
Problems and Countermeasures",
http://www.openssl.org/~bodo/tls-cbc.txt.
[CBCTIME] Canvel, B., "Password Interception in a SSL/TLS Channel",
http://lasecwww.epfl.ch/memo_ssl.shtml, 2003.
[CCM] "NIST Special Publication 800-38C: The CCM Mode for
Authentication and Confidentiality",
http://csrc.nist.gov/publications/nistpubs/SP800-38C.pdf.
[ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication
for Protecting Communications (Or: How Secure is SSL?)",
Crypto 2001.
Dierks & Rescorla Standards Track [Page 90] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
[ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998. 4303, December 2005.
[GCM] "NIST Special Publication 800-38C: The CCM Mode for
Authentication and Confidentiality",
http://csrc.nist.gov/publications/nistpubs/SP800-38C.pdf.
[KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based
Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/,
March 2003.
[PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax
Dierks & Rescorla Standards Track [Page 107] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
Standard," version 1.5, November 1993.
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax
Standard," version 1.5, November 1993.
[RANDOM] D. Eastlake Eastlake, D., 3rd, Schiller, J., and S. Crocker, J. Schiller. "Randomness
Recommendations
Requirements for Security", BCP 106, RFC 1750, December 1994. 4086, June 2005.
[RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Cryptosystems,"
Communications of the ACM, v. 21, n. 2, Feb 1978, pp.
120-126.
[SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996.
[SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications
Corp., Feb 9, 1995.
[SSL3] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
Netscape Communications Corp., Nov 18, 1996.
[SUBGROUP] R. Zuccherato, R., "Methods for Avoiding the Small-Subgroup "Small-Subgroup"
Attacks on the Diffie-Hellman Key Agreement Method for
S/MIME", RFC 2785, March 2000.
[TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793,
September 1981.
[TIMING] Boneh, D., Brumley, D., "Remote timing attacks are
practical", USENIX Security Symposium 2003.
[TLS1.0] Dierks, T., and C. Allen, C., "The TLS Protocol, Version 1.0",
RFC 2246, January 1999.
[TLS1.1] Dierks, T., and E. Rescorla, E., "The TLS Protocol, Version
Dierks & Rescorla Standards Track [Page 91] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
1.1", RFC 4346, April, 2006.
[X501] ITU-T Recommendation X.501: Information Technology - Open
Systems Interconnection - The Directory: Models, 1993.
[X509] ITU-T Recommendation X.509 (1997 E): Information Technology -
Open Systems Interconnection - "The Directory -
Authentication Framework". 1988.
[XDR] R. Srinivansan, R., Sun Microsystems, "XDR: External Data
Representation Standard", RFC 1832, August 1995.
Dierks & Rescorla Standards Track [Page 108] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
Credits
Working Group Chairs
Eric Rescorla
EMail: ekr@networkresonance.com
Pasi Eronen
pasi.eronen@nokia.com
Editors
Tim Dierks Eric Rescorla
Independent Network Resonance, Inc.
EMail: tim@dierks.org EMail: ekr@networkresonance.com
Other contributors
Christopher Allen (co-editor of TLS 1.0)
Alacrity Ventures
ChristopherA@AlacrityManagement.com
Martin Abadi
University of California, Santa Cruz
abadi@cs.ucsc.edu
Steven M. Bellovin
Columbia University
smb@cs.columbia.edu
Simon Blake-Wilson
BCI
Dierks & Rescorla Standards Track [Page 92] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
EMail: sblakewilson@bcisse.com
Ran Canetti
IBM
canetti@watson.ibm.com
Pete Chown
Skygate Technology Ltd
pc@skygate.co.uk
Taher Elgamal
taher@securify.com
Securify
Dierks & Rescorla Standards Track [Page 109] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
Anil Gangolli
anil@busybuddha.org
Kipp Hickman
David Hopwood
Independent Consultant
EMail: david.hopwood@blueyonder.co.uk
Phil Karlton (co-author of SSLv3)
Paul Kocher (co-author of SSLv3)
Cryptography Research
paul@cryptography.com
Hugo Krawczyk
Technion Israel Institute of Technology
hugo@ee.technion.ac.il
Jan Mikkelsen
Transactionware
EMail: janm@transactionware.com
Magnus Nystrom
RSA Security
EMail: magnus@rsasecurity.com
Robert Relyea
Netscape Communications
relyea@netscape.com
Jim Roskind
Netscape Communications
jar@netscape.com
Dierks & Rescorla Standards Track [Page 93] draft-ietf-tls-rfc4346-bis-03.txt TLS March 2007
Michael Sabin
Dan Simon
Microsoft, Inc.
dansimon@microsoft.com
Tom Weinstein
Tim Wright
Vodafone
EMail: timothy.wright@vodafone.com
Comments
Dierks & Rescorla Standards Track [Page 110] draft-ietf-tls-rfc4346-bis-02.txt TLS October 2006
The discussion list for the IETF TLS working group is located at the
e-mail address <tls@ietf.org>. Information on the group and
information on how to subscribe to the list is at
<https://www1.ietf.org/mailman/listinfo/tls>
Archives of the list can be found at:
<http://www.ietf.org/mail-archive/web/tls/current/index.html>
Dierks & Rescorla Standards Track [Page 111] draft-ietf-tls-rfc4346-bis-02.txt 94] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006 March 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society. IETF
Administrative Support Activity (IASA).
Dierks & Rescorla Standards Track [Page 112] draft-ietf-tls-rfc4346-bis-02.txt 95] draft-ietf-tls-rfc4346-bis-03.txt TLS October 2006 March 2007
Dierks & Rescorla Standards Track [Page 113] 96]
----