draft-ietf-tls-rfc4346-bis-09.txt | draft-ietf-tls-rfc4346-bis-10.txt | |||
---|---|---|---|---|
INTERNET-DRAFT Tim Dierks | INTERNET-DRAFT Tim Dierks | |||
Obsoletes (if approved): RFC 3268, 4346, 4366 Independent | Obsoletes (if approved): RFC 3268, 4346, 4366 Independent | |||
Updates (if approved): RFC 4492 Eric Rescorla | Updates (if approved): RFC 4492 Eric Rescorla | |||
Intended status: Proposed Standard Network Resonance, Inc. | Intended status: Proposed Standard Network Resonance, Inc. | |||
<draft-ietf-tls-rfc4346-bis-09.txt> February 2008 (Expires August 2008) | <draft-ietf-tls-rfc4346-bis-10.txt> March 2008 (Expires September 2008) | |||
The Transport Layer Security (TLS) Protocol | The Transport Layer Security (TLS) Protocol | |||
Version 1.2 | Version 1.2 | |||
Status of this Memo | Status of this Memo | |||
By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
applicable patent or other IPR claims of which he or she is aware | 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 | 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. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
skipping to change at page 2, line 39 ¶ | skipping to change at page 2, line 39 ¶ | |||
6.2.3.1. Null or Standard Stream Cipher 21 | 6.2.3.1. Null or Standard Stream Cipher 21 | |||
6.2.3.2. CBC Block Cipher 22 | 6.2.3.2. CBC Block Cipher 22 | |||
6.2.3.3. AEAD ciphers 24 | 6.2.3.3. AEAD ciphers 24 | |||
6.3. Key Calculation 25 | 6.3. Key Calculation 25 | |||
7. The TLS Handshaking Protocols 26 | 7. The TLS Handshaking Protocols 26 | |||
7.1. Change Cipher Spec Protocol 27 | 7.1. Change Cipher Spec Protocol 27 | |||
7.2. Alert Protocol 27 | 7.2. Alert Protocol 27 | |||
7.2.1. Closure Alerts 28 | 7.2.1. Closure Alerts 28 | |||
7.2.2. Error Alerts 29 | 7.2.2. Error Alerts 29 | |||
7.3. Handshake Protocol Overview 33 | 7.3. Handshake Protocol Overview 33 | |||
7.4. Handshake Protocol 36 | 7.4. Handshake Protocol 37 | |||
7.4.1. Hello Messages 37 | 7.4.1. Hello Messages 38 | |||
7.4.1.1. Hello Request 37 | 7.4.1.1. Hello Request 38 | |||
7.4.1.2. Client Hello 38 | 7.4.1.2. Client Hello 39 | |||
7.4.1.3. Server Hello 41 | 7.4.1.3. Server Hello 42 | |||
7.4.1.4 Hello Extensions 42 | 7.4.1.4 Hello Extensions 43 | |||
7.4.1.4.1 Signature Algorithms 43 | 7.4.1.4.1 Signature Algorithms 45 | |||
7.4.2. Server Certificate 45 | 7.4.2. Server Certificate 46 | |||
7.4.3. Server Key Exchange Message 47 | 7.4.3. Server Key Exchange Message 49 | |||
7.4.4. Certificate Request 50 | 7.4.4. Certificate Request 51 | |||
7.4.5 Server hello done 51 | 7.4.5 Server Hello Done 53 | |||
7.4.6. Client Certificate 52 | 7.4.6. Client Certificate 53 | |||
7.4.7. Client Key Exchange Message 54 | 7.4.7. Client Key Exchange Message 55 | |||
7.4.7.1. RSA Encrypted Premaster Secret Message 54 | 7.4.7.1. RSA Encrypted Premaster Secret Message 56 | |||
7.4.7.2. Client Diffie-Hellman Public Value 57 | 7.4.7.2. Client Diffie-Hellman Public Value 58 | |||
7.4.8. Certificate verify 58 | 7.4.8. Certificate verify 59 | |||
7.4.9. Finished 58 | 7.4.9. Finished 60 | |||
8. Cryptographic Computations 60 | 8. Cryptographic Computations 62 | |||
8.1. Computing the Master Secret 60 | 8.1. Computing the Master Secret 62 | |||
8.1.1. RSA 61 | 8.1.1. RSA 62 | |||
8.1.2. Diffie-Hellman 61 | 8.1.2. Diffie-Hellman 62 | |||
9. Mandatory Cipher Suites 61 | 9. Mandatory Cipher Suites 63 | |||
10. Application Data Protocol 61 | 10. Application Data Protocol 63 | |||
11. Security Considerations 61 | 11. Security Considerations 63 | |||
12. IANA Considerations 61 | 12. IANA Considerations 63 | |||
A. Protocol Constant Values 64 | A. Protocol Data Structures and Constant Values 65 | |||
A.1. Record Layer 64 | A.1. Record Layer 65 | |||
A.2. Change Cipher Specs Message 65 | A.2. Change Cipher Specs Message 66 | |||
A.3. Alert Messages 65 | A.3. Alert Messages 66 | |||
A.4. Handshake Protocol 66 | A.4. Handshake Protocol 67 | |||
A.4.1. Hello Messages 66 | A.4.1. Hello Messages 67 | |||
A.4.2. Server Authentication and Key Exchange Messages 68 | A.4.2. Server Authentication and Key Exchange Messages 69 | |||
A.4.3. Client Authentication and Key Exchange Messages 69 | A.4.3. Client Authentication and Key Exchange Messages 70 | |||
A.4.4. Handshake Finalization Message 70 | A.4.4. Handshake Finalization Message 71 | |||
A.5. The Cipher Suite 70 | A.5. The Cipher Suite 71 | |||
A.6. The Security Parameters 72 | A.6. The Security Parameters 73 | |||
A.7. Changes to RFC 4492 73 | A.7. Changes to RFC 4492 74 | |||
B. Glossary 73 | B. Glossary 74 | |||
C. Cipher Suite Definitions 78 | C. Cipher Suite Definitions 79 | |||
D. Implementation Notes 80 | D. Implementation Notes 81 | |||
D.1 Random Number Generation and Seeding 80 | D.1 Random Number Generation and Seeding 81 | |||
D.2 Certificates and Authentication 80 | D.2 Certificates and Authentication 81 | |||
D.3 Cipher Suites 80 | D.3 Cipher Suites 81 | |||
D.4 Implementation Pitfalls 80 | D.4 Implementation Pitfalls 81 | |||
E. Backward Compatibility 83 | E. Backward Compatibility 84 | |||
E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 83 | E.1 Compatibility with TLS 1.0/1.1 and SSL 3.0 84 | |||
E.2 Compatibility with SSL 2.0 84 | E.2 Compatibility with SSL 2.0 85 | |||
E.3. Avoiding Man-in-the-Middle Version Rollback 86 | E.3. Avoiding Man-in-the-Middle Version Rollback 87 | |||
F. Security Analysis 87 | F. Security Analysis 88 | |||
F.1. Handshake Protocol 87 | F.1. Handshake Protocol 88 | |||
F.1.1. Authentication and Key Exchange 87 | F.1.1. Authentication and Key Exchange 88 | |||
F.1.1.1. Anonymous Key Exchange 87 | F.1.1.1. Anonymous Key Exchange 88 | |||
F.1.1.2. RSA Key Exchange and Authentication 88 | F.1.1.2. RSA Key Exchange and Authentication 89 | |||
F.1.1.3. Diffie-Hellman Key Exchange with Authentication 88 | F.1.1.3. Diffie-Hellman Key Exchange with Authentication 89 | |||
F.1.2. Version Rollback Attacks 89 | F.1.2. Version Rollback Attacks 90 | |||
F.1.3. Detecting Attacks Against the Handshake Protocol 90 | F.1.3. Detecting Attacks Against the Handshake Protocol 91 | |||
F.1.4. Resuming Sessions 90 | F.1.4. Resuming Sessions 91 | |||
F.2. Protecting Application Data 90 | F.2. Protecting Application Data 91 | |||
F.3. Explicit IVs 91 | F.3. Explicit IVs 92 | |||
F.4. Security of Composite Cipher Modes 91 | F.4. Security of Composite Cipher Modes 92 | |||
F.5 Denial of Service 92 | F.5 Denial of Service 93 | |||
F.6 Final Notes 92 | F.6 Final Notes 93 | |||
1. Introduction | 1. Introduction | |||
The primary goal of the TLS Protocol is to provide privacy and data | The primary goal of the TLS Protocol is to provide privacy and data | |||
integrity between two communicating applications. The protocol is | integrity between two communicating applications. The protocol is | |||
composed of two layers: the TLS Record Protocol and the TLS Handshake | composed of two layers: the TLS Record Protocol and the TLS Handshake | |||
Protocol. At the lowest level, layered on top of some reliable | Protocol. At the lowest level, layered on top of some reliable | |||
transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The | transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol. The | |||
TLS Record Protocol provides connection security that has two basic | TLS Record Protocol provides connection security that has two basic | |||
properties: | properties: | |||
- The connection is private. Symmetric cryptography is used for | - The connection is private. Symmetric cryptography is used for | |||
data encryption (e.g., DES [DES], RC4 [SCH] etc.). The keys for | data encryption (e.g., AES [AES], RC4 [SCH] etc.). The keys for | |||
this symmetric encryption are generated uniquely for each | this symmetric encryption are generated uniquely for each | |||
connection and are based on a secret negotiated by another | connection and are based on a secret negotiated by another | |||
protocol (such as the TLS Handshake Protocol). The Record Protocol | protocol (such as the TLS Handshake Protocol). The Record Protocol | |||
can also be used without encryption. | can also be used without encryption. | |||
- The connection is reliable. Message transport includes a message | - The connection is reliable. Message transport includes a message | |||
integrity check using a keyed MAC. Secure hash functions (e.g., | integrity check using a keyed MAC. Secure hash functions (e.g., | |||
SHA, MD5, etc.) are used for MAC computations. The Record Protocol | SHA-1, etc.) are used for MAC computations. The Record Protocol | |||
can operate without a MAC, but is generally only used in this mode | can operate without a MAC, but is generally only used in this mode | |||
while another protocol is using the Record Protocol as a transport | while another protocol is using the Record Protocol as a transport | |||
for negotiating security parameters. | for negotiating security parameters. | |||
The TLS Record Protocol is used for encapsulation of various higher- | The TLS Record Protocol is used for encapsulation of various higher- | |||
level protocols. One such encapsulated protocol, the TLS Handshake | level protocols. One such encapsulated protocol, the TLS Handshake | |||
Protocol, allows the server and client to authenticate each other and | Protocol, allows the server and client to authenticate each other and | |||
to negotiate an encryption algorithm and cryptographic keys before | to negotiate an encryption algorithm and cryptographic keys before | |||
the application protocol transmits or receives its first byte of | the application protocol transmits or receives its first byte of | |||
data. The TLS Handshake Protocol provides connection security that | data. The TLS Handshake Protocol provides connection security that | |||
has three basic properties: | has three basic properties: | |||
- The peer's identity can be authenticated using asymmetric, or | - The peer's identity can be authenticated using asymmetric, or | |||
public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This | public key, cryptography (e.g., RSA [RSA], DSA [DSS], etc.). This | |||
authentication can be made optional, but is generally required for | authentication can be made optional, but is generally required for | |||
at least one of the peers. | at least one of the peers. | |||
- The negotiation of a shared secret is secure: the negotiated | - The negotiation of a shared secret is secure: the negotiated | |||
secret is unavailable to eavesdroppers, and for any authenticated | secret is unavailable to eavesdroppers, and for any authenticated | |||
connection the secret cannot be obtained, even by an attacker who | connection the secret cannot be obtained, even by an attacker who | |||
can place himself in the middle of the connection. | can place himself in the middle of the connection. | |||
- The negotiation is reliable: no attacker can modify the | - The negotiation is reliable: no attacker can modify the | |||
negotiation communication without being detected by the parties to | negotiation communication without being detected by the parties to | |||
skipping to change at page 5, line 22 ¶ | skipping to change at page 5, line 22 ¶ | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in RFC 2119 [REQ]. | document are to be interpreted as described in RFC 2119 [REQ]. | |||
1.2. Major Differences from TLS 1.1 | 1.2. Major Differences from TLS 1.1 | |||
This document is a revision of the TLS 1.1 [TLS1.1] protocol which | This document is a revision of the TLS 1.1 [TLS1.1] protocol which | |||
contains improved flexibility, particularly for negotiation of | contains improved flexibility, particularly for negotiation of | |||
cryptographic algorithms. The major changes are: | cryptographic algorithms. The major changes are: | |||
- The MD5/SHA-1 combination in the PRF has been replaced with cipher | - The MD5/SHA-1 combination in the pseudorandom function (PRF) has | |||
suite specified PRFs. All cipher suites in this document use | been replaced with cipher suite specified PRFs. All cipher suites | |||
P_SHA256. | in this document use P_SHA256. | |||
- The MD5/SHA-1 combination in the digitally-signed element has been | - The MD5/SHA-1 combination in the digitally-signed element has been | |||
replaced with a single hash. Signed elements now include a field | replaced with a single hash. Signed elements now include a field | |||
that explicitly specifies the hash algorithm used. | that explicitly specifies the hash algorithm used. | |||
- Substantial cleanup to the clients and servers ability to specify | - Substantial cleanup to the client's and server's ability to | |||
which hash and signature algorithms they will accept. Note that | specify which hash and signature algorithms they will accept. Note | |||
this also relaxes some of the constraints on signature and hash | that this also relaxes some of the constraints on signature and | |||
algorithms from previous versions of TLS. | hash algorithms from previous versions of TLS. | |||
- Addition of support for authenticated encryption with additional | - Addition of support for authenticated encryption with additional | |||
data modes. | data modes. | |||
- TLS Extensions definition and AES Cipher Suites were merged in | - TLS Extensions definition and AES Cipher Suites were merged in | |||
from external [TLSEXT] and [TLSAES]. | from external [TLSEXT] and [TLSAES]. | |||
- Tighter checking of EncryptedPreMasterSecret version numbers. | - Tighter checking of EncryptedPreMasterSecret version numbers. | |||
- Tightened up a number of requirements. | - Tightened up a number of requirements. | |||
skipping to change at page 6, line 17 ¶ | skipping to change at page 6, line 17 ¶ | |||
- TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement | - TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement | |||
cipher suite. | cipher suite. | |||
- Added HMAC-SHA256 cipher suites | - Added HMAC-SHA256 cipher suites | |||
- Removed IDEA and DES cipher suites. They are now deprecated and | - Removed IDEA and DES cipher suites. They are now deprecated and | |||
will be documented in a separate document. | will be documented in a separate document. | |||
- Support for the SSLv2 backward-compatible hello is now a MAY, not | - Support for the SSLv2 backward-compatible hello is now a MAY, not | |||
a SHOULD, with sending it a SHOULD not. Support will probably | a SHOULD, with sending it a SHOULD NOT. Support will probably | |||
become a SHOULD NOT in the future. | become a SHOULD NOT in the future. | |||
- Added limited "fall-through" to the presentation language to allow | - Added limited "fall-through" to the presentation language to allow | |||
multiple case arms to have the same encoding. | multiple case arms to have the same encoding. | |||
- Added an Implementation Pitfalls sections | - Added an Implementation Pitfalls sections | |||
- The usual clarifications and editorial work. | - The usual clarifications and editorial work. | |||
2. Goals | 2. Goals | |||
skipping to change at page 11, line 42 ¶ | skipping to change at page 11, line 42 ¶ | |||
struct { | struct { | |||
uint32 number; | uint32 number; | |||
opaque string[10]; /* fixed length */ | opaque string[10]; /* fixed length */ | |||
} V2; | } V2; | |||
struct { | struct { | |||
select (VariantTag) { /* value of selector is implicit */ | select (VariantTag) { /* value of selector is implicit */ | |||
case apple: | case apple: | |||
V1; /* VariantBody, tag = apple */ | V1; /* VariantBody, tag = apple */ | |||
case orange: | case orange: | |||
case banana: | case banana: | |||
V2; /* VariantBody, tag = orange or banana */ | V2; /* VariantBody, tag = orange or banana */ | |||
} variant_body; /* optional label on variant */ | } variant_body; /* optional label on variant */ | |||
} VariantRecord; | } VariantRecord; | |||
4.7. Cryptographic Attributes | 4.7. Cryptographic Attributes | |||
The five cryptographic operations digital signing, stream cipher | The five cryptographic operations digital signing, stream cipher | |||
encryption, block cipher encryption, authenticated encryption with | encryption, block cipher encryption, authenticated encryption with | |||
additional data (AEAD) encryption and public key encryption are | additional data (AEAD) encryption and public key encryption are | |||
designated digitally-signed, stream-ciphered, block-ciphered, aead- | designated digitally-signed, stream-ciphered, block-ciphered, aead- | |||
skipping to change at page 12, line 28 ¶ | skipping to change at page 12, line 28 ¶ | |||
The algorithm field specifies the algorithm used (see Section | The algorithm field specifies the algorithm used (see Section | |||
7.4.1.4.1 for the definition of this field.) Note that the | 7.4.1.4.1 for the definition of this field.) Note that the | |||
introduction of the algorithm field is a change from previous | introduction of the algorithm field is a change from previous | |||
versions. The signature is a digital signature using those | versions. The signature is a digital signature using those | |||
algorithms over the contents of the element. The contents themselves | algorithms over the contents of the element. The contents themselves | |||
do not appear on the wire but are simply calculated. The length of | do not appear on the wire but are simply calculated. The length of | |||
the signature is specified by the signing algorithm and key. | the signature is specified by the signing algorithm and key. | |||
In RSA signing, the opaque vector contains the signature generated | In RSA signing, the opaque vector contains the signature generated | |||
using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As | using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As | |||
discussed in [PKCS1], the DigestInfo MUST be DER encoded and for hash | discussed in [PKCS1], the DigestInfo MUST be DER [X680] [X690] | |||
algorithms without parameters (which include SHA-1) the | encoded and for hash algorithms without parameters (which include | |||
DigestInfo.AlgorithmIdentifier.parameters field MUST be NULL but | SHA-1) the DigestInfo.AlgorithmIdentifier.parameters field MUST be | |||
implementations MUST accept both without parameters and with NULL | NULL but implementations MUST accept both without parameters and with | |||
parameters. Note that earlier versions of TLS used a different RSA | NULL parameters. Note that earlier versions of TLS used a different | |||
signature scheme which did not include a DigestInfo encoding. | 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 | In DSA, the 20 bytes of the SHA-1 hash are run directly through the | |||
Digital Signing Algorithm with no additional hashing. This produces | Digital Signing Algorithm with no additional hashing. This produces | |||
two values, r and s. The DSS signature is an opaque vector, as above, | two values, r and s. The DSA signature is an opaque vector, as above, | |||
the contents of which are the DER encoding of: | the contents of which are the DER encoding of: | |||
Dss-Sig-Value ::= SEQUENCE { | Dss-Sig-Value ::= SEQUENCE { | |||
r INTEGER, | r INTEGER, | |||
s INTEGER | s INTEGER | |||
} | } | |||
Note: In current terminology, DSA refers to the Digital Signature | Note: In current terminology, DSA refers to the Digital Signature | |||
Algorithm and DSS refers to the NIST standard. For historical | Algorithm and DSS refers to the NIST standard. In the original | |||
reasons, this document uses DSS and DSA interchangeably | SSL and TLS specs, "DSS" was used universally. This document | |||
to refer to the DSA algorithm, as was done in SSLv3. | uses "DSA" to refer to the algorithm, "DSS" to refer to the | |||
standard, and uses "DSS" in the code point definitions for | ||||
historical continuity. | ||||
In stream cipher encryption, the plaintext is exclusive-ORed with an | In stream cipher encryption, the plaintext is exclusive-ORed with an | |||
identical amount of output generated from a cryptographically secure | identical amount of output generated from a cryptographically secure | |||
keyed pseudorandom number generator. | keyed pseudorandom number generator. | |||
In block cipher encryption, every block of plaintext encrypts to a | In block cipher encryption, every block of plaintext encrypts to a | |||
block of ciphertext. All block cipher encryption is done in CBC | block of ciphertext. All block cipher encryption is done in CBC | |||
(Cipher Block Chaining) mode, and all items that are block-ciphered | (Cipher Block Chaining) mode, and all items that are block-ciphered | |||
will be an exact multiple of the cipher block length. | will be an exact multiple of the cipher block length. | |||
skipping to change at page 15, line 31 ¶ | skipping to change at page 15, line 33 ¶ | |||
6. The TLS Record Protocol | 6. The TLS Record Protocol | |||
The TLS Record Protocol is a layered protocol. At each layer, | The TLS Record Protocol is a layered protocol. At each layer, | |||
messages may include fields for length, description, and content. | messages may include fields for length, description, and content. | |||
The Record Protocol takes messages to be transmitted, fragments the | The Record Protocol takes messages to be transmitted, fragments the | |||
data into manageable blocks, optionally compresses the data, applies | data into manageable blocks, optionally compresses the data, applies | |||
a MAC, encrypts, and transmits the result. Received data is | a MAC, encrypts, and transmits the result. Received data is | |||
decrypted, verified, decompressed, reassembled, and then delivered to | decrypted, verified, decompressed, reassembled, and then delivered to | |||
higher-level clients. | higher-level clients. | |||
Four record protocol clients are described in this document: the | Four protocols that use the record protocol are described in this | |||
handshake protocol, the alert protocol, the change cipher spec | document: the handshake protocol, the alert protocol, the change | |||
protocol, and the application data protocol. In order to allow | cipher spec protocol, and the application data protocol. In order to | |||
extension of the TLS protocol, additional record types can be | allow extension of the TLS protocol, additional record content types | |||
supported by the record protocol. New record type values are assigned | can be supported by the record protocol. New record content type | |||
by IANA as described in Section 12. | values are assigned by IANA in the TLS Content Type Registry as | |||
described in Section 12. | ||||
Implementations MUST NOT send record types not defined in this | Implementations MUST NOT send record types not defined in this | |||
document unless negotiated by some extension. If a TLS | document unless negotiated by some extension. If a TLS | |||
implementation receives an unexpected record type, it MUST send an | implementation receives an unexpected record type, it MUST send an | |||
unexpected_message alert. | unexpected_message alert. | |||
Any protocol designed for use over TLS MUST be carefully designed to | Any protocol designed for use over TLS must be carefully designed to | |||
deal with all possible attacks against it. Note that because the | deal with all possible attacks against it. As a practical matter, | |||
type and length of a record are not protected by encryption, care | this means that the protocol designer must be aware of what security | |||
SHOULD be taken to minimize the value of traffic analysis of these | properties TLS does and does not provide and cannot safely rely on | |||
values. | the latter. | |||
Note in particular that type and length of a record are not protected | ||||
by encryption. If this information is itself sensitive, application | ||||
designers may wish to take steps (padding, cover traffic) to minimize | ||||
information leakage. | ||||
6.1. Connection States | 6.1. Connection States | |||
A TLS connection state is the operating environment of the TLS Record | A TLS connection state is the operating environment of the TLS Record | |||
Protocol. It specifies a compression algorithm, an encryption | Protocol. It specifies a compression algorithm, an encryption | |||
algorithm, and a MAC algorithm. In addition, the parameters for these | algorithm, and a MAC algorithm. In addition, the parameters for these | |||
algorithms are known: the MAC key and the bulk encryption keys for | algorithms are known: the MAC key and the bulk encryption keys for | |||
the connection in both the read and the write directions. Logically, | the connection in both the read and the write directions. Logically, | |||
there are always four connection states outstanding: the current read | there are always four connection states outstanding: the current read | |||
and write states, and the pending read and write states. All records | and write states, and the pending read and write states. All records | |||
are processed under the current read and write states. The security | are processed under the current read and write states. The security | |||
parameters for the pending states can be set by the TLS Handshake | parameters for the pending states can be set by the TLS Handshake | |||
Protocol, and the Change Cipher Spec can selectively make either of | Protocol, and the ChangeCipherSpec can selectively make either of the | |||
the pending states current, in which case the appropriate current | pending states current, in which case the appropriate current state | |||
state is disposed of and replaced with the pending state; the pending | is disposed of and replaced with the pending state; the pending state | |||
state is then reinitialized to an empty state. It is illegal to make | is then reinitialized to an empty state. It is illegal to make a | |||
a state that has not been initialized with security parameters a | state that has not been initialized with security parameters a | |||
current state. The initial current state always specifies that no | current state. The initial current state always specifies that no | |||
encryption, compression, or MAC will be used. | encryption, compression, or MAC will be used. | |||
The security parameters for a TLS Connection read and write state are | The security parameters for a TLS Connection read and write state are | |||
set by providing the following values: | set by providing the following values: | |||
connection end | connection end | |||
Whether this entity is considered the "client" or the "server" in | Whether this entity is considered the "client" or the "server" in | |||
this connection. | this connection. | |||
skipping to change at page 17, line 23 ¶ | skipping to change at page 17, line 28 ¶ | |||
enum { server, client } ConnectionEnd; | enum { server, client } ConnectionEnd; | |||
enum { tls_prf_sha256 } PRFAlgorithm; | enum { tls_prf_sha256 } PRFAlgorithm; | |||
enum { null, rc4, 3des, aes } | enum { null, rc4, 3des, aes } | |||
BulkCipherAlgorithm; | BulkCipherAlgorithm; | |||
enum { stream, block, aead } CipherType; | enum { stream, block, aead } CipherType; | |||
enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384, | enum { null, hmac_md5, hmac_sha1, hmac_sha256, | |||
hmac_sha512} MACAlgorithm; | hmac_sha384, hmac_sha512} MACAlgorithm; | |||
/* The use of "sha" above is historical and denotes SHA-1 */ | ||||
enum { null(0), (255) } CompressionMethod; | enum { null(0), (255) } CompressionMethod; | |||
/* The algorithms specified in CompressionMethod, | /* The algorithms specified in CompressionMethod, PRFAlgorithm | |||
BulkCipherAlgorithm, and MACAlgorithm may be added to. */ | BulkCipherAlgorithm, and MACAlgorithm may be added to. */ | |||
struct { | struct { | |||
ConnectionEnd entity; | ConnectionEnd entity; | |||
PRFAlgorithm prf_algorithm; | PRFAlgorithm prf_algorithm; | |||
BulkCipherAlgorithm bulk_cipher_algorithm; | BulkCipherAlgorithm bulk_cipher_algorithm; | |||
CipherType cipher_type; | CipherType cipher_type; | |||
uint8 enc_key_length; | uint8 enc_key_length; | |||
uint8 block_length; | uint8 block_length; | |||
uint8 fixed_iv_length; | uint8 fixed_iv_length; | |||
skipping to change at page 19, line 37 ¶ | skipping to change at page 19, line 39 ¶ | |||
uint16 length; | uint16 length; | |||
opaque fragment[TLSPlaintext.length]; | opaque fragment[TLSPlaintext.length]; | |||
} TLSPlaintext; | } TLSPlaintext; | |||
type | type | |||
The higher-level protocol used to process the enclosed fragment. | The higher-level protocol used to process the enclosed fragment. | |||
version | version | |||
The version of the protocol being employed. This document | The version of the protocol being employed. This document | |||
describes TLS Version 1.2, which uses the version { 3, 3 }. The | 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 | version value 3.3 is historical, deriving from the use of {3, 1} | |||
TLS 1.0. (See Appendix A.1). Note that a client that supports | 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 | multiple versions of TLS may not know what version will be | |||
employed before it receives the ServerHello. See Appendix E for | employed before it receives the ServerHello. See Appendix E for | |||
discussion about what record layer version number should be | discussion about what record layer version number should be | |||
employed for ClientHello. | employed for ClientHello. | |||
length | length | |||
The length (in bytes) of the following TLSPlaintext.fragment. The | The length (in bytes) of the following TLSPlaintext.fragment. The | |||
length MUST NOT exceed 2^14. | length MUST NOT exceed 2^14. | |||
fragment | fragment | |||
The application data. This data is transparent and treated as an | The application data. This data is transparent and treated as an | |||
independent block to be dealt with by the higher-level protocol | independent block to be dealt with by the higher-level protocol | |||
specified by the type field. | specified by the type field. | |||
Implementations MUST NOT send zero-length fragments of Handshake, | Implementations MUST NOT send zero-length fragments of Handshake, | |||
Alert, or Change Cipher Spec content types. Zero-length fragments of | Alert, or ChangeCipherSpec content types. Zero-length fragments of | |||
Application data MAY be sent as they are potentially useful as a | Application data MAY be sent as they are potentially useful as a | |||
traffic analysis countermeasure. | traffic analysis countermeasure. | |||
Note: Data of different TLS Record layer content types MAY be | Note: Data of different TLS Record layer content types MAY be | |||
interleaved. Application data is generally of lower precedence for | interleaved. Application data is generally of lower precedence for | |||
transmission than other content types. However, records MUST be | transmission than other content types. However, records MUST be | |||
delivered to the network in the same order as they are protected by | delivered to the network in the same order as they are protected by | |||
the record layer. Recipients MUST receive and process interleaved | the record layer. Recipients MUST receive and process interleaved | |||
application layer traffic during handshakes subsequent to the first | application layer traffic during handshakes subsequent to the first | |||
one on a connection. | one on a connection. | |||
6.2.2. Record Compression and Decompression | 6.2.2. Record Compression and Decompression | |||
All records are compressed using the compression algorithm defined in | All records are compressed using the compression algorithm defined in | |||
the current session state. There is always an active compression | the current session state. There is always an active compression | |||
algorithm; however, initially it is defined as | algorithm; however, initially it is defined as | |||
CompressionMethod.null. The compression algorithm translates a | CompressionMethod.null. The compression algorithm translates a | |||
TLSPlaintext structure into a TLSCompressed structure. Compression | TLSPlaintext structure into a TLSCompressed structure. Compression | |||
functions are initialized with default state information whenever a | functions are initialized with default state information whenever a | |||
connection state is made active. | connection state is made active. [RFC3749] describes compression | |||
algorithms for TLS. | ||||
Compression must be lossless and may not increase the content length | Compression must be lossless and may not increase the content length | |||
by more than 1024 bytes. If the decompression function encounters a | by more than 1024 bytes. If the decompression function encounters a | |||
TLSCompressed.fragment that would decompress to a length in excess of | TLSCompressed.fragment that would decompress to a length in excess of | |||
2^14 bytes, it MUST report a fatal decompression failure error. | 2^14 bytes, it MUST report a fatal decompression failure error. | |||
struct { | struct { | |||
ContentType type; /* same as TLSPlaintext.type */ | ContentType type; /* same as TLSPlaintext.type */ | |||
ProtocolVersion version;/* same as TLSPlaintext.version */ | ProtocolVersion version;/* same as TLSPlaintext.version */ | |||
uint16 length; | uint16 length; | |||
skipping to change at page 22, line 20 ¶ | skipping to change at page 22, line 23 ¶ | |||
MAC | MAC | |||
The MAC algorithm specified by SecurityParameters.mac_algorithm. | The MAC algorithm specified by SecurityParameters.mac_algorithm. | |||
Note that the MAC is computed before encryption. The stream cipher | Note that the MAC is computed before encryption. The stream cipher | |||
encrypts the entire block, including the MAC. For stream ciphers that | encrypts the entire block, including the MAC. For stream ciphers that | |||
do not use a synchronization vector (such as RC4), the stream cipher | 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 | state from the end of one record is simply used on the subsequent | |||
packet. If the cipher suite is TLS_NULL_WITH_NULL_NULL, encryption | packet. If the cipher suite is TLS_NULL_WITH_NULL_NULL, encryption | |||
consists of the identity operation (i.e., the data is not encrypted, | consists of the identity operation (i.e., the data is not encrypted, | |||
and the MAC size is zero, implying that no MAC is used). | and the MAC size is zero, implying that no MAC is used). For both | |||
TLSCiphertext.length is TLSCompressed.length plus | null and stream ciphers, TLSCiphertext.length is TLSCompressed.length | |||
SecurityParameters.mac_length. | plus SecurityParameters.mac_length. | |||
6.2.3.2. CBC Block Cipher | 6.2.3.2. CBC Block Cipher | |||
For block ciphers (such as 3DES, or AES), the encryption and MAC | For block ciphers (such as 3DES, or AES), the encryption and MAC | |||
functions convert TLSCompressed.fragment structures to and from block | functions convert TLSCompressed.fragment structures to and from block | |||
TLSCiphertext.fragment structures. | TLSCiphertext.fragment structures. | |||
struct { | struct { | |||
opaque IV[SecurityParameters.record_iv_length]; | opaque IV[SecurityParameters.record_iv_length]; | |||
block-ciphered struct { | block-ciphered struct { | |||
skipping to change at page 25, line 4 ¶ | skipping to change at page 25, line 7 ¶ | |||
TLSCompressed.version + TLSCompressed.length; | TLSCompressed.version + TLSCompressed.length; | |||
Where "+" denotes concatenation. | Where "+" denotes concatenation. | |||
The aead_output consists of the ciphertext output by the AEAD | The aead_output consists of the ciphertext output by the AEAD | |||
encryption operation. The length will generally be larger than | encryption operation. The length will generally be larger than | |||
TLSCompressed.length, but by an amount that varies with the AEAD | TLSCompressed.length, but by an amount that varies with the AEAD | |||
cipher. Since the ciphers might incorporate padding, the amount of | cipher. Since the ciphers might incorporate padding, the amount of | |||
overhead could vary with different TLSCompressed.length values. Each | overhead could vary with different TLSCompressed.length values. Each | |||
AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. | AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. | |||
Symbolically, | Symbolically, | |||
AEADEncrypted = AEAD-Encrypt(key, nonce, plaintext, | AEADEncrypted = AEAD-Encrypt(key, nonce, plaintext, | |||
additional_data) | additional_data) | |||
In order to decrypt and verify, the cipher takes as input the key, | In order to decrypt and verify, the cipher takes as input the key, | |||
nonce, the "additional_data", and the AEADEncrypted value. The output | nonce, the "additional_data", and the AEADEncrypted value. The output | |||
is either the plaintext or an error indicating that the decryption | is either the plaintext or an error indicating that the decryption | |||
failed. There is no separate integrity check. I.e., | failed. There is no separate integrity check. I.e., | |||
TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce, | TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce, | |||
AEADEncrypted, | AEADEncrypted, | |||
additional_data) | additional_data) | |||
If the decryption fails, a fatal bad_record_mac alert MUST be | If the decryption fails, a fatal bad_record_mac alert MUST be | |||
generated. | generated. | |||
6.3. Key Calculation | 6.3. Key Calculation | |||
The Record Protocol requires an algorithm to generates keys required | The Record Protocol requires an algorithm to generate keys required | |||
by the current connection state (see Appendix A.6) from the security | by the current connection state (see Appendix A.6) from the security | |||
parameters provided by the handshake protocol. | parameters provided by the handshake protocol. | |||
The master secret is expanded into a sequence of secure bytes, which | The master secret is expanded into a sequence of secure bytes, which | |||
is then split to a client write MAC key, a server write MAC key, a | is then split to a client write MAC key, a server write MAC key, a | |||
client write encryption key, and a server write encryption key. Each | client write encryption key, and a server write encryption key. Each | |||
of these is generated from the byte sequence in that order. Unused | of these is generated from the byte sequence in that order. Unused | |||
values are empty. Some AEAD ciphers may additionally require a | values are empty. Some AEAD ciphers may additionally require a | |||
client write IV and a server write IV (see Section 6.2.3.3). | client write IV and a server write IV (see Section 6.2.3.3). | |||
skipping to change at page 26, line 38 ¶ | skipping to change at page 26, line 41 ¶ | |||
active or resumable session state. | active or resumable session state. | |||
peer certificate | peer certificate | |||
X509v3 [PKIX] certificate of the peer. This element of the state | X509v3 [PKIX] certificate of the peer. This element of the state | |||
may be null. | may be null. | |||
compression method | compression method | |||
The algorithm used to compress data prior to encryption. | The algorithm used to compress data prior to encryption. | |||
cipher spec | cipher spec | |||
Specifies the bulk data encryption algorithm (such as null, DES, | Specifies the pseudorandom function (PRF) used to generate keying | |||
etc.) and a MAC algorithm (such as MD5 or SHA). It also defines | material, the bulk data encryption algorithm (such as null, AES, | |||
etc.) and a MAC algorithm (such as HMAC-SHA1). It also defines | ||||
cryptographic attributes such as the mac_length. (See Appendix A.6 | cryptographic attributes such as the mac_length. (See Appendix A.6 | |||
for formal definition.) | for formal definition.) | |||
master secret | master secret | |||
48-byte secret shared between the client and server. | 48-byte secret shared between the client and server. | |||
is resumable | is resumable | |||
A flag indicating whether the session can be used to initiate new | A flag indicating whether the session can be used to initiate new | |||
connections. | connections. | |||
skipping to change at page 27, line 18 ¶ | skipping to change at page 27, line 22 ¶ | |||
The change cipher spec protocol exists to signal transitions in | The change cipher spec protocol exists to signal transitions in | |||
ciphering strategies. The protocol consists of a single message, | ciphering strategies. The protocol consists of a single message, | |||
which is encrypted and compressed under the current (not the pending) | which is encrypted and compressed under the current (not the pending) | |||
connection state. The message consists of a single byte of value 1. | connection state. The message consists of a single byte of value 1. | |||
struct { | struct { | |||
enum { change_cipher_spec(1), (255) } type; | enum { change_cipher_spec(1), (255) } type; | |||
} ChangeCipherSpec; | } ChangeCipherSpec; | |||
The change cipher spec message is sent by both the client and the | The ChangeCipherSpec message is sent by both the client and the | |||
server to notify the receiving party that subsequent records will be | server to notify the receiving party that subsequent records will be | |||
protected under the newly negotiated CipherSpec and keys. Reception | protected under the newly negotiated CipherSpec and keys. Reception | |||
of this message causes the receiver to instruct the Record Layer to | of this message causes the receiver to instruct the Record Layer to | |||
immediately copy the read pending state into the read current state. | immediately copy the read pending state into the read current state. | |||
Immediately after sending this message, the sender MUST instruct the | Immediately after sending this message, the sender MUST instruct the | |||
record layer to make the write pending state the write active state. | record layer to make the write pending state the write active state. | |||
(See Section 6.1.) The change cipher spec message is sent during the | (See Section 6.1.) The change cipher spec message is sent during the | |||
handshake after the security parameters have been agreed upon, but | handshake after the security parameters have been agreed upon, but | |||
before the verifying finished message is sent. | before the verifying finished message is sent. | |||
skipping to change at page 27, line 42 ¶ | skipping to change at page 27, line 46 ¶ | |||
CipherSpec MUST be used. The first side to send the ChangeCipherSpec | CipherSpec MUST be used. The first side to send the ChangeCipherSpec | |||
does not know that the other side has finished computing the new | does not know that the other side has finished computing the new | |||
keying material (e.g., if it has to perform a time consuming public | keying material (e.g., if it has to perform a time consuming public | |||
key operation). Thus, a small window of time, during which the | key operation). Thus, a small window of time, during which the | |||
recipient must buffer the data, MAY exist. In practice, with modern | recipient must buffer the data, MAY exist. In practice, with modern | |||
machines this interval is likely to be fairly short. | machines this interval is likely to be fairly short. | |||
7.2. Alert Protocol | 7.2. Alert Protocol | |||
One of the content types supported by the TLS Record layer is the | 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 | alert type. Alert messages convey the severity of the message | |||
description of the alert. Alert messages with a level of fatal result | (warning or fatal) and a description of the alert. Alert messages | |||
in the immediate termination of the connection. In this case, other | with a level of fatal result in the immediate termination of the | |||
connections corresponding to the session may continue, but the | connection. In this case, other connections corresponding to the | |||
session identifier MUST be invalidated, preventing the failed session | session may continue, but the session identifier MUST be invalidated, | |||
from being used to establish new connections. Like other messages, | preventing the failed session from being used to establish new | |||
alert messages are encrypted and compressed, as specified by the | connections. Like other messages, alert messages are encrypted and | |||
current connection state. | compressed, as specified by the current connection state. | |||
enum { warning(1), fatal(2), (255) } AlertLevel; | enum { warning(1), fatal(2), (255) } AlertLevel; | |||
enum { | enum { | |||
close_notify(0), | close_notify(0), | |||
unexpected_message(10), | unexpected_message(10), | |||
bad_record_mac(20), | bad_record_mac(20), | |||
decryption_failed_RESERVED(21), | decryption_failed_RESERVED(21), | |||
record_overflow(22), | record_overflow(22), | |||
decompression_failure(30), | decompression_failure(30), | |||
handshake_failure(40), | handshake_failure(40), | |||
no_certificate_RESERVED(41), | no_certificate_RESERVED(41), | |||
bad_certificate(42), | bad_certificate(42), | |||
skipping to change at page 34, line 13 ¶ | skipping to change at page 34, line 18 ¶ | |||
which the server must respond with a server hello message, or else a | 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 | fatal error will occur and the connection will fail. The client hello | |||
and server hello are used to establish security enhancement | and server hello are used to establish security enhancement | |||
capabilities between client and server. The client hello and server | capabilities between client and server. The client hello and server | |||
hello establish the following attributes: Protocol Version, Session | hello establish the following attributes: Protocol Version, Session | |||
ID, Cipher Suite, and Compression Method. Additionally, two random | ID, Cipher Suite, and Compression Method. Additionally, two random | |||
values are generated and exchanged: ClientHello.random and | values are generated and exchanged: ClientHello.random and | |||
ServerHello.random. | ServerHello.random. | |||
The actual key exchange uses up to four messages: the server | The actual key exchange uses up to four messages: the server | |||
certificate, the server key exchange, the client certificate, and the | Certificate, the ServerKeyExchange, the client Certificate, and the | |||
client key exchange. New key exchange methods can be created by | ClientKeyExchange. New key exchange methods can be created by | |||
specifying a format for these messages and by defining the use of the | 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 | messages to allow the client and server to agree upon a shared | |||
secret. This secret MUST be quite long; currently defined key | secret. This secret MUST be quite long; currently defined key | |||
exchange methods exchange secrets that range from 46 bytes upwards. | exchange methods exchange secrets that range from 46 bytes upwards. | |||
Following the hello messages, the server will send its certificate, | Following the hello messages, the server will send its certificate in | |||
if it is to be authenticated. Additionally, a server key exchange | a Certificate message if it is to be authenticated. Additionally, a | |||
message may be sent, if it is required (e.g., if their server has no | ServerKeyExchange message may be sent, if it is required (e.g., if | |||
certificate, or if its certificate is for signing only). If the | the server has no certificate, or if its certificate is for signing | |||
server is authenticated, it may request a certificate from the | only). If the server is authenticated, it may request a certificate | |||
client, if that is appropriate to the cipher suite selected. Next, | from the client, if that is appropriate to the cipher suite selected. | |||
the server will send the server hello done message, indicating that | Next, the server will send the ServerHelloDone message, indicating | |||
the hello-message phase of the handshake is complete. The server will | that the hello-message phase of the handshake is complete. The server | |||
then wait for a client response. If the server has sent a certificate | will then wait for a client response. If the server has sent a | |||
request message, the client MUST send the certificate message. The | CertificateRequest message, the client MUST send the Certificate | |||
client key exchange message is now sent, and the content of that | message. The ClientKeyExchange message is now sent, and the content | |||
message will depend on the public key algorithm selected between the | of that message will depend on the public key algorithm selected | |||
client hello and the server hello. If the client has sent a | between the client hello and the server hello. If the client has sent | |||
certificate with signing ability, a digitally-signed certificate | a certificate with signing ability, a digitally-signed | |||
verify message is sent to explicitly verify possession of the private | CertificateVerify message is sent to explicitly verify possession of | |||
key in the certificate. | the private key in the certificate. | |||
At this point, a change cipher spec message is sent by the client, | At this point, a ChangeCipherSpec message is sent by the client, and | |||
and the client copies the pending Cipher Spec into the current Cipher | the client copies the pending Cipher Spec into the current Cipher | |||
Spec. The client then immediately sends the finished message under | Spec. The client then immediately sends the Finished message under | |||
the new algorithms, keys, and secrets. In response, the server will | the new algorithms, keys, and secrets. In response, the server will | |||
send its own change cipher spec message, transfer the pending to the | send its own ChangeCipherSpec message, transfer the pending to the | |||
current Cipher Spec, and send its finished message under the new | current Cipher Spec, and send its Finished message under the new | |||
Cipher Spec. At this point, the handshake is complete, and the client | Cipher Spec. At this point, the handshake is complete, and the client | |||
and server may begin to exchange application layer data. (See flow | and server may begin to exchange application layer data. (See flow | |||
chart below.) Application data MUST NOT be sent prior to the | chart below.) Application data MUST NOT be sent prior to the | |||
completion of the first handshake (before a cipher suite other than | completion of the first handshake (before a cipher suite other than | |||
TLS_NULL_WITH_NULL_NULL is established). | TLS_NULL_WITH_NULL_NULL is established). | |||
Client Server | Client Server | |||
ClientHello --------> | ClientHello --------> | |||
ServerHello | ServerHello | |||
skipping to change at page 35, line 36 ¶ | skipping to change at page 36, line 40 ¶ | |||
When the client and server decide to resume a previous session or | When the client and server decide to resume a previous session or | |||
duplicate an existing session (instead of negotiating new security | duplicate an existing session (instead of negotiating new security | |||
parameters), the message flow is as follows: | parameters), the message flow is as follows: | |||
The client sends a ClientHello using the Session ID of the session to | 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 | 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 | a match is found, and the server is willing to re-establish the | |||
connection under the specified session state, it will send a | connection under the specified session state, it will send a | |||
ServerHello with the same Session ID value. At this point, both | ServerHello with the same Session ID value. At this point, both | |||
client and server MUST send change cipher spec messages and proceed | client and server MUST send ChangeCipherSpec messages and proceed | |||
directly to finished messages. Once the re-establishment is complete, | directly to Finished messages. Once the re-establishment is complete, | |||
the client and server MAY begin to exchange application layer data. | the client and server MAY begin to exchange application layer data. | |||
(See flow chart below.) If a Session ID match is not found, the | (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 | server generates a new session ID and the TLS client and server | |||
perform a full handshake. | perform a full handshake. | |||
Client Server | Client Server | |||
ClientHello --------> | ClientHello --------> | |||
ServerHello | ServerHello | |||
[ChangeCipherSpec] | [ChangeCipherSpec] | |||
skipping to change at page 36, line 49 ¶ | skipping to change at page 38, line 11 ¶ | |||
case finished: Finished; | case finished: Finished; | |||
} body; | } body; | |||
} Handshake; | } Handshake; | |||
The handshake protocol messages are presented below in the order they | The handshake protocol messages are presented below in the order they | |||
MUST be sent; sending handshake messages in an unexpected order | MUST be sent; sending handshake messages in an unexpected order | |||
results in a fatal error. Unneeded handshake messages can be omitted, | results in a fatal error. Unneeded handshake messages can be omitted, | |||
however. Note one exception to the ordering: the Certificate message | however. Note one exception to the ordering: the Certificate message | |||
is used twice in the handshake (from server to client, then from | is used twice in the handshake (from server to client, then from | |||
client to server), but described only in its first position. The one | client to server), but described only in its first position. The one | |||
message that is not bound by these ordering rules is the Hello | message that is not bound by these ordering rules is the HelloRequest | |||
Request message, which can be sent at any time, but which SHOULD be | message, which can be sent at any time, but which SHOULD be ignored | |||
ignored by the client if it arrives in the middle of a handshake. | by the client if it arrives in the middle of a handshake. | |||
New Handshake message types are assigned by IANA as described in | New Handshake message types are assigned by IANA as described in | |||
Section 12. | Section 12. | |||
7.4.1. Hello Messages | 7.4.1. Hello Messages | |||
The hello phase messages are used to exchange security enhancement | The hello phase messages are used to exchange security enhancement | |||
capabilities between the client and server. When a new session | capabilities between the client and server. When a new session | |||
begins, the Record Layer's connection state encryption, hash, and | begins, the Record Layer's connection state encryption, hash, and | |||
compression algorithms are initialized to null. The current | compression algorithms are initialized to null. The current | |||
connection state is used for renegotiation messages. | connection state is used for renegotiation messages. | |||
7.4.1.1. Hello Request | 7.4.1.1. Hello Request | |||
When this message will be sent: | When this message will be sent: | |||
The hello request message MAY be sent by the server at any time. | The HelloRequest message MAY be sent by the server at any time. | |||
Meaning of this message: | Meaning of this message: | |||
Hello request is a simple notification that the client should | HelloRequest is a simple notification that the client should begin | |||
begin the negotiation process anew by sending a client hello | the negotiation process anew. In response, the client should a | |||
message when convenient. This message is not intended to establish | ClientHello message when convenient. This message is not intended | |||
which side is the client or server but merely to initiate a new | to establish which side is the client or server but merely to | |||
negotiation. Servers SHOULD NOT send a HelloRequest immediately | initiate a new negotiation. Servers SHOULD NOT send a HelloRequest | |||
upon the client's initial connection. It is the client's job to | immediately upon the client's initial connection. It is the | |||
send a ClientHello at that time. | client's job to send a ClientHello at that time. | |||
This message will be ignored by the client if the client is | This message will be ignored by the client if the client is | |||
currently negotiating a session. This message may be ignored by | currently negotiating a session. This message MAY be ignored by | |||
the client if it does not wish to renegotiate a session, or the | the client if it does not wish to renegotiate a session, or the | |||
client may, if it wishes, respond with a no_renegotiation alert. | client may, if it wishes, respond with a no_renegotiation alert. | |||
Since handshake messages are intended to have transmission | Since handshake messages are intended to have transmission | |||
precedence over application data, it is expected that the | precedence over application data, it is expected that the | |||
negotiation will begin before no more than a few records are | negotiation will begin before no more than a few records are | |||
received from the client. If the server sends a hello request but | received from the client. If the server sends a HelloRequest but | |||
does not receive a client hello in response, it may close the | does not receive a ClientHello in response, it may close the | |||
connection with a fatal alert. | connection with a fatal alert. | |||
After sending a hello request, servers SHOULD NOT repeat the | After sending a HelloRequest, servers SHOULD NOT repeat the | |||
request until the subsequent handshake negotiation is complete. | request until the subsequent handshake negotiation is complete. | |||
Structure of this message: | Structure of this message: | |||
struct { } HelloRequest; | struct { } HelloRequest; | |||
Note: This message MUST NOT be included in the message hashes that | This message MUST NOT be included in the message hashes that are | |||
are maintained throughout the handshake and used in the finished | maintained throughout the handshake and used in the finished messages | |||
messages and the certificate verify message. | and the certificate verify message. | |||
7.4.1.2. Client Hello | 7.4.1.2. Client Hello | |||
When this message will be sent: | When this message will be sent: | |||
When a client first connects to a server it is required to send | 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 | the ClientHello as its first message. The client can also send a | |||
client hello in response to a hello request or on its own | ClientHello in response to a HelloRequest or on its own initiative | |||
initiative in order to renegotiate the security parameters in an | in order to renegotiate the security parameters in an existing | |||
existing connection. | connection. | |||
Structure of this message: | Structure of this message: | |||
The client hello message includes a random structure, which is | The ClientHello message includes a random structure, which is used | |||
used later in the protocol. | later in the protocol. | |||
struct { | struct { | |||
uint32 gmt_unix_time; | uint32 gmt_unix_time; | |||
opaque random_bytes[28]; | opaque random_bytes[28]; | |||
} Random; | } Random; | |||
gmt_unix_time | gmt_unix_time | |||
The current time and date in standard UNIX 32-bit format | The current time and date in standard UNIX 32-bit format | |||
(seconds since the midnight starting Jan 1, 1970, GMT, ignoring | (seconds since the midnight starting Jan 1, 1970, UTC, ignoring | |||
leap seconds) according to the sender's internal clock. Clocks | leap seconds) according to the sender's internal clock. Clocks | |||
are not required to be set correctly by the basic TLS Protocol; | are not required to be set correctly by the basic TLS Protocol; | |||
higher-level or application protocols may define additional | higher-level or application protocols may define additional | |||
requirements. | requirements. Note that, for historical reasons, the data | |||
element is named using GMT, the predecessor of the current | ||||
worldwide time base, UTC. | ||||
random_bytes | random_bytes | |||
28 bytes generated by a secure random number generator. | 28 bytes generated by a secure random number generator. | |||
The client hello message includes a variable-length session | The ClientHello message includes a variable-length session | |||
identifier. If not empty, the value identifies a session between the | identifier. If not empty, the value identifies a session between the | |||
same client and server whose security parameters the client wishes to | same client and server whose security parameters the client wishes to | |||
reuse. The session identifier MAY be from an earlier connection, this | reuse. The session identifier MAY be from an earlier connection, this | |||
connection, or from another currently active connection. The second | connection, or from another currently active connection. The second | |||
option is useful if the client only wishes to update the random | option is useful if the client only wishes to update the random | |||
structures and derived values of a connection, and the third option | structures and derived values of a connection, and the third option | |||
makes it possible to establish several independent secure connections | makes it possible to establish several independent secure connections | |||
without repeating the full handshake protocol. These independent | without repeating the full handshake protocol. These independent | |||
connections may occur sequentially or simultaneously; a SessionID | connections may occur sequentially or simultaneously; a SessionID | |||
becomes valid when the handshake negotiating it completes with the | becomes valid when the handshake negotiating it completes with the | |||
skipping to change at page 39, line 14 ¶ | skipping to change at page 40, line 27 ¶ | |||
Warning: Because the SessionID is transmitted without encryption or | Warning: Because the SessionID is transmitted without encryption or | |||
immediate MAC protection, servers MUST NOT place confidential | immediate MAC protection, servers MUST NOT place confidential | |||
information in session identifiers or let the contents of fake | information in session identifiers or let the contents of fake | |||
session identifiers cause any breach of security. (Note that the | session identifiers cause any breach of security. (Note that the | |||
content of the handshake as a whole, including the SessionID, is | content of the handshake as a whole, including the SessionID, is | |||
protected by the Finished messages exchanged at the end of the | protected by the Finished messages exchanged at the end of the | |||
handshake.) | handshake.) | |||
The cipher suite list, passed from the client to the server in the | The cipher suite list, passed from the client to the server in the | |||
client hello message, contains the combinations of cryptographic | ClientHello message, contains the combinations of cryptographic | |||
algorithms supported by the client in order of the client's | algorithms supported by the client in order of the client's | |||
preference (favorite choice first). Each cipher suite defines a key | preference (favorite choice first). Each cipher suite defines a key | |||
exchange algorithm, a bulk encryption algorithm (including secret key | exchange algorithm, a bulk encryption algorithm (including secret key | |||
length), a MAC algorithm, and a PRF. The server will select a cipher | length), a MAC algorithm, and a PRF. The server will select a cipher | |||
suite or, if no acceptable choices are presented, return a handshake | suite or, if no acceptable choices are presented, return a handshake | |||
failure alert and close the connection. If the list contains cipher | failure alert and close the connection. If the list contains cipher | |||
suites the server does not recognize, support, or wish to use, the | suites the server does not recognize, support, or wish to use, the | |||
server MUST ignore those cipher suites, and process the remaining | server MUST ignore those cipher suites, and process the remaining | |||
ones as usual. | ones as usual. | |||
uint8 CipherSuite[2]; /* Cryptographic suite selector */ | uint8 CipherSuite[2]; /* Cryptographic suite selector */ | |||
The client hello includes a list of compression algorithms supported | The ClientHello includes a list of compression algorithms supported | |||
by the client, ordered according to the client's preference. | by the client, ordered according to the client's preference. | |||
enum { null(0), (255) } CompressionMethod; | enum { null(0), (255) } CompressionMethod; | |||
struct { | struct { | |||
ProtocolVersion client_version; | ProtocolVersion client_version; | |||
Random random; | Random random; | |||
SessionID session_id; | SessionID session_id; | |||
CipherSuite cipher_suites<2..2^16-2>; | CipherSuite cipher_suites<2..2^16-2>; | |||
CompressionMethod compression_methods<1..2^8-1>; | CompressionMethod compression_methods<1..2^8-1>; | |||
skipping to change at page 40, line 17 ¶ | skipping to change at page 41, line 31 ¶ | |||
communicate during this session. This SHOULD be the latest | communicate during this session. This SHOULD be the latest | |||
(highest valued) version supported by the client. For this version | (highest valued) version supported by the client. For this version | |||
of the specification, the version will be 3.3 (See Appendix E for | of the specification, the version will be 3.3 (See Appendix E for | |||
details about backward compatibility). | details about backward compatibility). | |||
random | random | |||
A client-generated random structure. | A client-generated random structure. | |||
session_id | session_id | |||
The ID of a session the client wishes to use for this connection. | The ID of a session the client wishes to use for this connection. | |||
This field is empty if no session_id is available, or it the | This field is empty if no session_id is available, or if the | |||
client wishes to generate new security parameters. | client wishes to generate new security parameters. | |||
cipher_suites | cipher_suites | |||
This is a list of the cryptographic options supported by the | This is a list of the cryptographic options supported by the | |||
client, with the client's first preference first. If the | client, with the client's first preference first. If the | |||
session_id field is not empty (implying a session resumption | session_id field is not empty (implying a session resumption | |||
request) this vector MUST include at least the cipher_suite from | request), this vector MUST include at least the cipher_suite from | |||
that session. Values are defined in Appendix A.5. | that session. Values are defined in Appendix A.5. | |||
compression_methods | compression_methods | |||
This is a list of the compression methods supported by the client, | This is a list of the compression methods supported by the client, | |||
sorted by client preference. If the session_id field is not empty | sorted by client preference. If the session_id field is not empty | |||
(implying a session resumption request) it MUST include the | (implying a session resumption request), it MUST include the | |||
compression_method from that session. This vector MUST contain, | compression_method from that session. This vector MUST contain, | |||
and all implementations MUST support, CompressionMethod.null. | and all implementations MUST support, CompressionMethod.null. | |||
Thus, a client and server will always be able to agree on a | Thus, a client and server will always be able to agree on a | |||
compression method. | compression method. | |||
extensions | extensions | |||
Clients MAY request extended functionality from servers by sending | Clients MAY request extended functionality from servers by sending | |||
data in the extensions Here the new "extensions" field contains a | data in the extensions field. The actual "Extension" format is | |||
list of extensions. The actual "Extension" format is defined in | defined in Section 7.4.1.4. | |||
Section 7.4.1.4. | ||||
In the event that a client requests additional functionality using | In the event that a client requests additional functionality using | |||
extensions, and this functionality is not supplied by the server, the | extensions, and this functionality is not supplied by the server, the | |||
client MAY abort the handshake. A server MUST accept client hello | client MAY abort the handshake. A server MUST accept client hello | |||
messages both with and without the extensions field, and (as for all | messages both with and without the extensions field, and (as for all | |||
other messages) MUST check that the amount of data in the message | 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 | precisely matches one of these formats; if not, then it MUST send a | |||
fatal "decode_error" alert. | fatal "decode_error" alert. | |||
After sending the client hello message, the client waits for a server | After sending the client hello message, the client waits for a | |||
hello message. Any other handshake message returned by the server | ServerHello message. Any other handshake message returned by the | |||
except for a hello request is treated as a fatal error. | server except for a HelloRequest is treated as a fatal error. | |||
7.4.1.3. Server Hello | 7.4.1.3. Server Hello | |||
When this message will be sent: | When this message will be sent: | |||
The server will send this message in response to a client hello | The server will send this message in response to a ClientHello | |||
message when it was able to find an acceptable set of algorithms. | 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 | If it cannot find such a match, it will respond with a handshake | |||
failure alert. | failure alert. | |||
Structure of this message: | Structure of this message: | |||
struct { | struct { | |||
ProtocolVersion server_version; | ProtocolVersion server_version; | |||
Random random; | Random random; | |||
SessionID session_id; | SessionID session_id; | |||
skipping to change at page 42, line 10 ¶ | skipping to change at page 43, line 25 ¶ | |||
using the specified session state, the server will respond with | using the specified session state, the server will respond with | |||
the same value as was supplied by the client. This indicates a | the same value as was supplied by the client. This indicates a | |||
resumed session and dictates that the parties must proceed | resumed session and dictates that the parties must proceed | |||
directly to the finished messages. Otherwise this field will | directly to the finished messages. Otherwise this field will | |||
contain a different value identifying the new session. The server | contain a different value identifying the new session. The server | |||
may return an empty session_id to indicate that the session will | may return an empty session_id to indicate that the session will | |||
not be cached and therefore cannot be resumed. If a session is | not be cached and therefore cannot be resumed. If a session is | |||
resumed, it must be resumed using the same cipher suite it was | resumed, it must be resumed using the same cipher suite it was | |||
originally negotiated with. Note that there is no requirement that | originally negotiated with. Note that there is no requirement that | |||
the server resume any session even if it had formerly provided a | the server resume any session even if it had formerly provided a | |||
session_id. Client MUST be prepared to do a full negotiation -- | session_id. Clients MUST be prepared to do a full negotiation -- | |||
including negotiating new cipher suites -- during any handshake. | including negotiating new cipher suites -- during any handshake. | |||
cipher_suite | cipher_suite | |||
The single cipher suite selected by the server from the list in | The single cipher suite selected by the server from the list in | |||
ClientHello.cipher_suites. For resumed sessions, this field is the | ClientHello.cipher_suites. For resumed sessions, this field is the | |||
value from the state of the session being resumed. | value from the state of the session being resumed. | |||
compression_method | compression_method | |||
The single compression algorithm selected by the server from the | The single compression algorithm selected by the server from the | |||
list in ClientHello.compression_methods. For resumed sessions this | list in ClientHello.compression_methods. For resumed sessions this | |||
skipping to change at page 43, line 5 ¶ | skipping to change at page 44, line 20 ¶ | |||
- "extension_data" contains information specific to the particular | - "extension_data" contains information specific to the particular | |||
extension type. | extension type. | |||
The initial set of extensions is defined in a companion document | The initial set of extensions is defined in a companion document | |||
[TLSEXT]. The list of extension types is maintained by IANA as | [TLSEXT]. The list of extension types is maintained by IANA as | |||
described in Section 12. | described in Section 12. | |||
There are subtle (and not so subtle) interactions that may occur in | There are subtle (and not so subtle) interactions that may occur in | |||
this protocol between new features and existing features which may | this protocol between new features and existing features which may | |||
result in a significant reduction in overall security, The following | result in a significant reduction in overall security. The following | |||
considerations should be taken into account when designing new | considerations should be taken into account when designing new | |||
extensions: | extensions: | |||
- Some cases where a server does not agree to an extension are error | - Some cases where a server does not agree to an extension are error | |||
conditions, and some simply a refusal to support a particular | conditions, and some simply a refusal to support a particular | |||
feature. In general error alerts should be used for the former, | feature. In general error alerts should be used for the former, | |||
and a field in the server extension response for the latter. | and a field in the server extension response for the latter. | |||
- Extensions should as far as possible be designed to prevent any | - Extensions should as far as possible be designed to prevent any | |||
attack that forces use (or non-use) of a particular feature by | attack that forces use (or non-use) of a particular feature by | |||
skipping to change at page 43, line 45 ¶ | skipping to change at page 45, line 13 ¶ | |||
consideration in any major design change. | consideration in any major design change. | |||
7.4.1.4.1 Signature Algorithms | 7.4.1.4.1 Signature Algorithms | |||
The client uses the "signature_algorithms" extension to indicate to | The client uses the "signature_algorithms" extension to indicate to | |||
the server which signature/hash algorithm pairs may be used in | the server which signature/hash algorithm pairs may be used in | |||
digital signatures. The "extension_data" field of this extension | digital signatures. The "extension_data" field of this extension | |||
contains a "supported_signature_algorithms" value. | contains a "supported_signature_algorithms" value. | |||
enum { | enum { | |||
none(0), md5(1), sha1(2), sha256(3), sha384(4), | none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), | |||
sha512(5), (255) | sha512(6), (255) | |||
} HashAlgorithm; | } HashAlgorithm; | |||
enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } | enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } | |||
SignatureAlgorithm; | SignatureAlgorithm; | |||
struct { | struct { | |||
HashAlgorithm hash; | HashAlgorithm hash; | |||
SignatureAlgorithm signature; | SignatureAlgorithm signature; | |||
} SignatureAndHashAlgorithm; | } SignatureAndHashAlgorithm; | |||
skipping to change at page 44, line 24 ¶ | skipping to change at page 45, line 39 ¶ | |||
pair which the client is willing to verify. The values are indicated | pair which the client is willing to verify. The values are indicated | |||
in descending order of preference. | in descending order of preference. | |||
Note: Because not all signature algorithms and hash algorithms may be | Note: Because not all signature algorithms and hash algorithms may be | |||
accepted by an implementation (e.g., DSA with SHA-1, but not | accepted by an implementation (e.g., DSA with SHA-1, but not | |||
SHA-256), algorithms here are listed in pairs. | SHA-256), algorithms here are listed in pairs. | |||
hash | hash | |||
This field indicates the hash algorithm which may be used. The | This field indicates the hash algorithm which may be used. The | |||
values indicate support for unhashed data, MD5 [MD5], SHA-1, | values indicate support for unhashed data, MD5 [MD5], SHA-1, | |||
SHA-256, SHA-384, and SHA-512 [SHA] respectively. The "none" value | SHA-224, SHA-256, SHA-384, and SHA-512 [SHS] respectively. The | |||
is provided for future extensibility, in case of a signature | "none" value is provided for future extensibility, in case of a | |||
algorithm which does not require hashing before signing. | signature algorithm which does not require hashing before signing. | |||
signature | signature | |||
This field indicates the signature algorithm which may be used. | This field indicates the signature algorithm which may be used. | |||
The values indicate anonymous signatures, RSASSA-PKCS1-v1_5 | The values indicate anonymous signatures, RSASSA-PKCS1-v1_5 | |||
[PKCS1] and DSA [DSS] respectively. The "anonymous" value is | [PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively. The | |||
meaningless in this context but used in Section 7.4.3. It MUST NOT | "anonymous" value is meaningless in this context but used in | |||
appear in this extension. | Section 7.4.3. It MUST NOT appear in this extension. | |||
The semantics of this extension are somewhat complicated because the | The semantics of this extension are somewhat complicated because the | |||
cipher suite indicates permissible signature algorithms but not hash | cipher suite indicates permissible signature algorithms but not hash | |||
algorithm. Sections 7.4.2 and 7.4.3 describe the appropriate rules. | algorithms. Sections 7.4.2 and 7.4.3 describe the appropriate rules. | |||
If the client supports only the default hash and signature algorithms | If the client supports only the default hash and signature algorithms | |||
(listed in this section), it MAY omit the signature_algorithms | (listed in this section), it MAY omit the signature_algorithms | |||
extension. If the client does not support the default algorithms, or | extension. If the client does not support the default algorithms, or | |||
supports other hash and signature algorithms (and it is willing to | supports other hash and signature algorithms (and it is willing to | |||
use them for verifying messages sent by server; server certificates | use them for verifying messages sent by the server, i.e., server | |||
and server key exchange), it MUST send the signature_algorithms | certificates and server key exchange), it MUST send the | |||
extension listing the algorithms it is willing to accept. | signature_algorithms extension, listing the algorithms it is willing | |||
to accept. | ||||
If the client does not send the signature_algorithms extension, the | If the client does not send the signature_algorithms extension, the | |||
server MUST assume the following: | server MUST assume the following: | |||
- If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, | - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, | |||
DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent | DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had sent | |||
the value (sha1,rsa). | the value {sha1,rsa}. | |||
- If the negotiated key exchange algorithm is one of (DHE_DSS, | - If the negotiated key exchange algorithm is one of (DHE_DSS, | |||
DH_DSS), behave as if the client had sent the value (sha1,dsa). | DH_DSS), behave as if the client had sent the value {sha1,dsa}. | |||
- If the negotiated key exchange algorithm is one of (ECDH_ECDSA, | - If the negotiated key exchange algorithm is one of (ECDH_ECDSA, | |||
ECDHE_ECDSA), behave as if the client had sent value (sha1,ecdsa). | ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}. | |||
Note: this is a change from TLS 1.1 where there are no explicit rules | Note: this is a change from TLS 1.1 where there are no explicit rules | |||
but as a practical matter one can assume that the peer supports MD5 | but as a practical matter one can assume that the peer supports MD5 | |||
and SHA-1. | and SHA-1. | |||
Note: this extension is not meaningful for TLS versions prior to 1.2. | Note: this extension is not meaningful for TLS versions prior to 1.2. | |||
Clients MUST NOT offer it if they are offering prior versions. | Clients MUST NOT offer it if they are offering prior versions. | |||
However, even if clients do offer it, the rules specified in [TLSEXT] | However, even if clients do offer it, the rules specified in [TLSEXT] | |||
require servers to ignore extensions they do not understand. | require servers to ignore extensions they do not understand. | |||
Servers MUST NOT send this extension. TLS servers MUST support | Servers MUST NOT send this extension. TLS servers MUST support | |||
receiving this extension. | receiving this extension. | |||
7.4.2. Server Certificate | 7.4.2. Server Certificate | |||
When this message will be sent: | When this message will be sent: | |||
The server MUST send a certificate whenever the agreed-upon key | The server MUST send a Certificate message whenever the agreed- | |||
exchange method uses certificates for authentication (this | upon key exchange method uses certificates for authentication | |||
includes all key exchange methods defined in this document except | (this includes all key exchange methods defined in this document | |||
DH_anon). This message will always immediately follow the server | except DH_anon). This message will always immediately follow the | |||
hello message. | server hello message. | |||
Meaning of this message: | Meaning of this message: | |||
This message conveys the server's certificate chain to the client. | This message conveys the server's certificate chain to the client. | |||
The certificate MUST be appropriate for the negotiated cipher | The certificate MUST be appropriate for the negotiated cipher | |||
suite's key exchange algorithm, and any negotiated extensions. | suite's key exchange algorithm, and any negotiated extensions. | |||
Structure of this message: | Structure of this message: | |||
opaque ASN.1Cert<1..2^24-1>; | opaque ASN.1Cert<1..2^24-1>; | |||
struct { | struct { | |||
ASN.1Cert certificate_list<0..2^24-1>; | ASN.1Cert certificate_list<0..2^24-1>; | |||
} Certificate; | } Certificate; | |||
certificate_list | certificate_list | |||
This is a sequence (chain) of certificates. The sender's | This is a sequence (chain) of certificates. The sender's | |||
certificate MUST come first in the list. Each following | certificate MUST come first in the list. Each following | |||
certificate MUST directly certify the one preceding it. Because | certificate MUST directly certify the one preceding it. Because | |||
certificate validation requires that root keys be distributed | certificate validation requires that root keys be distributed | |||
independently, the self-signed certificate that specifies the root | independently, the self-signed certificate that specifies the root | |||
certificate authority MAY optionally be omitted from the chain, | certificate authority MAY be omitted from the chain, under the | |||
under the assumption that the remote end must already possess it | assumption that the remote end must already possess it in order to | |||
in order to validate it in any case. | validate it in any case. | |||
The same message type and structure will be used for the client's | The same message type and structure will be used for the client's | |||
response to a certificate request message. Note that a client MAY | response to a certificate request message. Note that a client MAY | |||
send no certificates if it does not have an appropriate certificate | send no certificates if it does not have an appropriate certificate | |||
to send in response to the server's authentication request. | to send in response to the server's authentication request. | |||
Note: PKCS #7 [PKCS7] is not used as the format for the certificate | Note: PKCS #7 [PKCS7] is not used as the format for the certificate | |||
vector because PKCS #6 [PKCS6] extended certificates are not used. | vector because PKCS #6 [PKCS6] extended certificates are not used. | |||
Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task | Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task | |||
of parsing the list more difficult. | of parsing the list more difficult. | |||
skipping to change at page 46, line 43 ¶ | skipping to change at page 48, line 12 ¶ | |||
if the key usage extension is present). | if the key usage extension is present). | |||
Note: RSA_PSK is defined in [TLSPSK]. | Note: RSA_PSK is defined in [TLSPSK]. | |||
DHE_RSA RSA public key; the certificate MUST | DHE_RSA RSA public key; the certificate MUST | |||
ECDHE_RSA allow the key to be used for signing | ECDHE_RSA allow the key to be used for signing | |||
(the digitalSignature bit MUST be set | (the digitalSignature bit MUST be set | |||
if the key usage extension is present) | if the key usage extension is present) | |||
with the signature scheme and hash | with the signature scheme and hash | |||
algorithm that will be employed in the | algorithm that will be employed in the | |||
server key exchange message. | server key exchange message. | |||
Note: ECDHE_RSA is defined in [TLSECC]. | ||||
DHE_DSS DSA public key; the certificate MUST | DHE_DSS DSA public key; the certificate MUST | |||
allow the key to be used for signing with | allow the key to be used for signing with | |||
the hash algorithm that will be employed | the hash algorithm that will be employed | |||
in the server key exchange message. | in the server key exchange message. | |||
DH_DSS Diffie-Hellman public key; the | DH_DSS Diffie-Hellman public key; the | |||
DH_RSA keyAgreement bit MUST be set if the | DH_RSA keyAgreement bit MUST be set if the | |||
key usage extension is present. | key usage extension is present. | |||
skipping to change at page 47, line 31 ¶ | skipping to change at page 48, line 49 ¶ | |||
certificates provided by the server MUST be signed by a | certificates provided by the server MUST be signed by a | |||
hash/signature algorithm pair that appears in that extension. Note | hash/signature algorithm pair that appears in that extension. Note | |||
that this implies that a certificate containing a key for one | that this implies that a certificate containing a key for one | |||
signature algorithm MAY be signed using a different signature | signature algorithm MAY be signed using a different signature | |||
algorithm (for instance, an RSA key signed with a DSA key.) This is a | algorithm (for instance, an RSA key signed with a DSA key.) This is a | |||
departure from TLS 1.1, which required that the algorithms be the | departure from TLS 1.1, which required that the algorithms be the | |||
same. Note that this also implies that the DH_DSS, DH_RSA, | same. Note that this also implies that the DH_DSS, DH_RSA, | |||
ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the | ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the | |||
algorithm used to sign the certificate. Fixed DH certificates MAY be | algorithm used to sign the certificate. Fixed DH certificates MAY be | |||
signed with any hash/signature algorithm pair appearing in the | signed with any hash/signature algorithm pair appearing in the | |||
extension. The naming is historical. | extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are | |||
historical. | ||||
If the server has multiple certificates, it chooses one of them based | If the server has multiple certificates, it chooses one of them based | |||
on the above-mentioned criteria (in addition to other criteria, such | on the above-mentioned criteria (in addition to other criteria, such | |||
as transport layer endpoint, local configuration and preferences, | as transport layer endpoint, local configuration and preferences, | |||
etc.). If the server has a single certificate it SHOULD attempt to | etc.). If the server has a single certificate it SHOULD attempt to | |||
validate that it meets these criteria. | validate that it meets these criteria. | |||
Note that there are certificates that use algorithms and/or algorithm | Note that there are certificates that use algorithms and/or algorithm | |||
combinations that cannot be currently used with TLS. For example, a | combinations that cannot be currently used with TLS. For example, a | |||
certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in | certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in | |||
SubjectPublicKeyInfo) cannot be used because TLS defines no | SubjectPublicKeyInfo) cannot be used because TLS defines no | |||
corresponding signature algorithm. | corresponding signature algorithm. | |||
As cipher suites that specify new key exchange methods are specified | As cipher suites that specify new key exchange methods are specified | |||
for the TLS Protocol, they will imply certificate format and the | for the TLS Protocol, they will the imply certificate format and the | |||
required encoded keying information. | required encoded keying information. | |||
7.4.3. Server Key Exchange Message | 7.4.3. Server Key Exchange Message | |||
When this message will be sent: | When this message will be sent: | |||
This message will be sent immediately after the server certificate | This message will be sent immediately after the server Certificate | |||
message (or the server hello message, if this is an anonymous | message (or the ServerHello message, if this is an anonymous | |||
negotiation). | negotiation). | |||
The server key exchange message is sent by the server only when | The ServerKeyExchange message is sent by the server only when the | |||
the server certificate message (if sent) does not contain enough | server Certificate message (if sent) does not contain enough data | |||
data to allow the client to exchange a premaster secret. This is | to allow the client to exchange a premaster secret. This is true | |||
true for the following key exchange methods: | for the following key exchange methods: | |||
DHE_DSS | DHE_DSS | |||
DHE_RSA | DHE_RSA | |||
DH_anon | DH_anon | |||
It is not legal to send the server key exchange message for the | It is not legal to send the ServerKeyExchange message for the | |||
following key exchange methods: | following key exchange methods: | |||
RSA | RSA | |||
DH_DSS | DH_DSS | |||
DH_RSA | DH_RSA | |||
Other key exchange algorithms, such as those defined in | ||||
[TLSECC], MUST specify whether the ServerKeyExchange message is | ||||
sent or not; and if the message is sent, its contents. | ||||
Meaning of this message: | Meaning of this message: | |||
This message conveys cryptographic information to allow the client | This message conveys cryptographic information to allow the client | |||
to communicate the premaster secret: a Diffie-Hellman public key | to communicate the premaster secret: a Diffie-Hellman public key | |||
with which the client can complete a key exchange (with the result | with which the client can complete a key exchange (with the result | |||
being the premaster secret) or a public key for some other | being the premaster secret) or a public key for some other | |||
algorithm. | algorithm. | |||
Structure of this message: | Structure of this message: | |||
enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa } | enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa | |||
KeyExchangeAlgorithm; | /* may be extended, e.g. for ECDH -- see [TLSECC] */ | |||
} KeyExchangeAlgorithm; | ||||
struct { | struct { | |||
opaque dh_p<1..2^16-1>; | opaque dh_p<1..2^16-1>; | |||
opaque dh_g<1..2^16-1>; | opaque dh_g<1..2^16-1>; | |||
opaque dh_Ys<1..2^16-1>; | opaque dh_Ys<1..2^16-1>; | |||
} ServerDHParams; /* Ephemeral DH parameters */ | } ServerDHParams; /* Ephemeral DH parameters */ | |||
dh_p | dh_p | |||
The prime modulus used for the Diffie-Hellman operation. | The prime modulus used for the Diffie-Hellman operation. | |||
skipping to change at page 49, line 22 ¶ | skipping to change at page 50, line 45 ¶ | |||
digitally-signed struct { | digitally-signed struct { | |||
opaque client_random[32]; | opaque client_random[32]; | |||
opaque server_random[32]; | opaque server_random[32]; | |||
ServerDHParams params; | ServerDHParams params; | |||
} signed_params; | } signed_params; | |||
case rsa: | case rsa: | |||
case dh_dss: | case dh_dss: | |||
case dh_rsa: | case dh_rsa: | |||
struct {} ; | struct {} ; | |||
/* message is omitted for rsa, dh_dss, and dh_rsa */ | /* message is omitted for rsa, dh_dss, and dh_rsa */ | |||
/* may be extended, e.g. for ECDH -- see [TLSECC] */ | ||||
}; | }; | |||
} ServerKeyExchange; | } ServerKeyExchange; | |||
params | params | |||
The server's key exchange parameters. | The server's key exchange parameters. | |||
signed_params | signed_params | |||
For non-anonymous key exchanges, a signature over the | For non-anonymous key exchanges, a signature over the | |||
server's key exchange parameters. | server's key exchange parameters. | |||
If the client has offered the "signature_algorithms" extension, the | If the client has offered the "signature_algorithms" extension, the | |||
signature algorithm and hash algorithm MUST be a pair listed in that | signature algorithm and hash algorithm MUST be a pair listed in that | |||
extension. Note that there is a possibility for inconsistencies here. | extension. Note that there is a possibility for inconsistencies here. | |||
For instance, the client might offer DHE_DSS key exchange but omit | For instance, the client might offer DHE_DSS key exchange but omit | |||
any DSS pairs from its "signature_algorithms" extension. In order to | any DSA pairs from its "signature_algorithms" extension. In order to | |||
negotiate correctly, the server MUST check any candidate cipher | negotiate correctly, the server MUST check any candidate cipher | |||
suites against the "signature_algorithms" extension before selecting | suites against the "signature_algorithms" extension before selecting | |||
them. This is somewhat inelegant but is a compromise designed to | them. This is somewhat inelegant but is a compromise designed to | |||
minimize changes to the original cipher suite design. | minimize changes to the original cipher suite design. | |||
In addition, the hash and signature algorithms MUST be compatible | In addition, the hash and signature algorithms MUST be compatible | |||
with the key in the server's end-entity certificate. RSA keys MAY be | with the key in the server's end-entity certificate. RSA keys MAY be | |||
used with any permitted hash algorithm, subject to restrictions in | used with any permitted hash algorithm, subject to restrictions in | |||
the certificate, if any. | the certificate, if any. | |||
Because DSA signatures do not contain any secure indication of hash | Because DSA signatures do not contain any secure indication of hash | |||
algorithm, there is a risk of hash substitution if multiple hashes | algorithm, there is a risk of hash substitution if multiple hashes | |||
may be used with any key. Currently, DSS [DSS] may only be used with | may be used with any key. Currently, DSA [DSS] may only be used with | |||
SHA-1. Future revisions of DSS [DSS-3] are expected to allow other | SHA-1. Future revisions of DSS [DSS-3] are expected to allow the use | |||
digest algorithms, as well as guidance as to which digest algorithms | of other digest algorithms with DSA, as well as guidance as to which | |||
should be used with each key size. In addition, future revisions of | digest algorithms should be used with each key size. In addition, | |||
future revisions of [PKIX] may specify mechanisms for certificates to | ||||
[PKIX] may specify mechanisms for certificates to indicate which | indicate which digest algorithms are to be used with DSA. | |||
digest algorithms are to be used with DSA. | ||||
As additional cipher suites are defined for TLS that include new key | As additional cipher suites are defined for TLS that include new key | |||
exchange algorithms, the server key exchange message will be sent if | exchange algorithms, the server key exchange message will be sent if | |||
and only if the certificate type associated with the key exchange | and only if the certificate type associated with the key exchange | |||
algorithm does not provide enough information for the client to | algorithm does not provide enough information for the client to | |||
exchange a premaster secret. | exchange a premaster secret. | |||
7.4.4. Certificate Request | 7.4.4. Certificate Request | |||
When this message will be sent: | When this message will be sent: | |||
A non-anonymous server can optionally request a certificate from | A non-anonymous server can optionally request a certificate from | |||
the client, if appropriate for the selected cipher suite. This | the client, if appropriate for the selected cipher suite. This | |||
message, if sent, will immediately follow the Server Key Exchange | message, if sent, will immediately follow the ServerKeyExchange | |||
message (if it is sent; otherwise, the Server Certificate | message (if it is sent; otherwise, the server's Certificate | |||
message). | message). | |||
Structure of this message: | Structure of this message: | |||
enum { | enum { | |||
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | |||
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), | rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), | |||
fortezza_dms_RESERVED(20), (255) | fortezza_dms_RESERVED(20), (255) | |||
} ClientCertificateType; | } ClientCertificateType; | |||
skipping to change at page 50, line 46 ¶ | skipping to change at page 52, line 22 ¶ | |||
SignatureAndHashAlgorithm | SignatureAndHashAlgorithm | |||
supported_signature_algorithms<2^16-1>; | supported_signature_algorithms<2^16-1>; | |||
DistinguishedName certificate_authorities<0..2^16-1>; | DistinguishedName certificate_authorities<0..2^16-1>; | |||
} CertificateRequest; | } CertificateRequest; | |||
certificate_types | certificate_types | |||
A list of the types of certificate types which the client may | A list of the types of certificate types which the client may | |||
offer. | offer. | |||
rsa_sign a certificate containing an RSA key | rsa_sign a certificate containing an RSA key | |||
dss_sign a certificate containing a DSS key | dss_sign a certificate containing a DSA key | |||
rsa_fixed_dh a certificate containing a static DH key. | rsa_fixed_dh a certificate containing a static DH key. | |||
dss_fixed_dh a certificate containing a static DH key | dss_fixed_dh a certificate containing a static DH key | |||
supported_signature_algorithms | supported_signature_algorithms | |||
A list of the hash/signature algorithm pairs that the server is | A list of the hash/signature algorithm pairs that the server is | |||
able to verify, listed in descending order of preference. | able to verify, listed in descending order of preference. | |||
certificate_authorities | certificate_authorities | |||
A list of the distinguished names [X501] of acceptable | A list of the distinguished names [X501] of acceptable | |||
certificate_authorities, represented in DER-encoded format. These | certificate_authorities, represented in DER-encoded format. These | |||
skipping to change at page 51, line 51 ¶ | skipping to change at page 53, line 28 ¶ | |||
New ClientCertificateType values are assigned by IANA as described in | New ClientCertificateType values are assigned by IANA as described in | |||
Section 12. | Section 12. | |||
Note: Values listed as RESERVED may not be used. They were used in | Note: Values listed as RESERVED may not be used. They were used in | |||
SSLv3. | SSLv3. | |||
Note: It is a fatal handshake_failure alert for an anonymous server | Note: It is a fatal handshake_failure alert for an anonymous server | |||
to request client authentication. | to request client authentication. | |||
7.4.5 Server hello done | 7.4.5 Server Hello Done | |||
When this message will be sent: | When this message will be sent: | |||
The server hello done message is sent by the server to indicate | The ServerHelloDone message is sent by the server to indicate the | |||
the end of the server hello and associated messages. After sending | end of the ServerHello and associated messages. After sending this | |||
this message, the server will wait for a client response. | message, the server will wait for a client response. | |||
Meaning of this message: | Meaning of this message: | |||
This message means that the server is done sending messages to | This message means that the server is done sending messages to | |||
support the key exchange, and the client can proceed with its | support the key exchange, and the client can proceed with its | |||
phase of the key exchange. | phase of the key exchange. | |||
Upon receipt of the server hello done message, the client SHOULD | Upon receipt of the ServerHelloDone message, the client SHOULD | |||
verify that the server provided a valid certificate, if required | verify that the server provided a valid certificate, if required, | |||
and check that the server hello parameters are acceptable. | and check that the server hello parameters are acceptable. | |||
Structure of this message: | Structure of this message: | |||
struct { } ServerHelloDone; | struct { } ServerHelloDone; | |||
7.4.6. Client Certificate | 7.4.6. Client Certificate | |||
When this message will be sent: | When this message will be sent: | |||
This is the first message the client can send after receiving a | This is the first message the client can send after receiving a | |||
server hello done message. This message is only sent if the server | server hello done message. This message is only sent if the server | |||
requests a certificate. If no suitable certificate is available, | requests a certificate. If no suitable certificate is available, | |||
the client MUST send a certificate message containing no | the client MUST send a certificate message containing no | |||
certificates. That is, the certificate_list structure has a length | certificates. That is, the certificate_list structure has a length | |||
of zero. If the client does not send any certificates, the server | of zero. If the client does not send any certificates, the server | |||
MAY at its discretion either continue the handshake without client | MAY at its discretion either continue the handshake without client | |||
authentication, or respond with a fatal handshake_failure alert. | authentication, or respond with a fatal handshake_failure alert. | |||
skipping to change at page 52, line 47 ¶ | skipping to change at page 54, line 25 ¶ | |||
(e.g., it was not signed by a known, trusted CA), the server MAY | (e.g., it was not signed by a known, trusted CA), the server MAY | |||
at its discretion either continue the handshake (considering the | at its discretion either continue the handshake (considering the | |||
client unauthenticated) or send a fatal alert. | client unauthenticated) or send a fatal alert. | |||
Client certificates are sent using the Certificate structure | Client certificates are sent using the Certificate structure | |||
defined in Section 7.4.2. | defined in Section 7.4.2. | |||
Meaning of this message: | Meaning of this message: | |||
This message conveys the client's certificate chain to the server; | This message conveys the client's certificate chain to the server; | |||
the server will use it when verifying the certificate verify | the server will use it when verifying the CertificateVerify | |||
message (when the client authentication is based on signing), or | message (when the client authentication is based on signing) or | |||
calculate the premaster secret (for non-ephemeral Diffie-Hellman). | calculating the premaster secret (for non-ephemeral Diffie- | |||
The certificate MUST be appropriate for the negotiated cipher | Hellman). The certificate MUST be appropriate for the negotiated | |||
suite's key exchange algorithm, and any negotiated extensions. | cipher suite's key exchange algorithm, and any negotiated | |||
extensions. | ||||
In particular: | In particular: | |||
- The certificate type MUST be X.509v3, unless explicitly negotiated | - The certificate type MUST be X.509v3, unless explicitly negotiated | |||
otherwise (e.g. [TLSPGP]). | otherwise (e.g. [TLSPGP]). | |||
- The end-entity certificate's public key (and associated | - The end-entity certificate's public key (and associated | |||
restrictions) has to be compatible with the certificate types | restrictions) has to be compatible with the certificate types | |||
listed in CertificateRequest: | listed in CertificateRequest: | |||
skipping to change at page 53, line 38 ¶ | skipping to change at page 55, line 17 ¶ | |||
MUST allow the key to be used for signing | MUST allow the key to be used for signing | |||
with the hash algorithm that will be | with the hash algorithm that will be | |||
employed in the certificate verify | employed in the certificate verify | |||
message; the public key MUST use a | message; the public key MUST use a | |||
curve and point format supported by the | curve and point format supported by the | |||
server. | server. | |||
rsa_fixed_dh Diffie-Hellman public key; MUST use | rsa_fixed_dh Diffie-Hellman public key; MUST use | |||
dss_fixed_dh the same parameters as server's key. | dss_fixed_dh the same parameters as server's key. | |||
rsa_fixed_ecdh ECDH-capable public key; MUST use | rsa_fixed_ecdh ECDH-capable public key; MUST use the | |||
ecdsa_fixed_ecdh the same curve as server's key, and | ecdsa_fixed_ecdh same curve as the server's key, and | |||
MUST use a point format supported by | MUST use a point format supported by | |||
the server. | the server. | |||
- If the certificate_authorities list in the certificate request | - If the certificate_authorities list in the certificate request | |||
message was non-empty, one of the certificates in the certificate | message was non-empty, one of the certificates in the certificate | |||
chain SHOULD be issued by one of the listed CAs. | chain SHOULD be issued by one of the listed CAs. | |||
- The certificates MUST be signed using an acceptable hash/ | - The certificates MUST be signed using an acceptable hash/ | |||
signature algorithm pair, as described in Section 7.4.4. Note that | signature algorithm pair, as described in Section 7.4.4. Note that | |||
this relaxes the constraints on certificate signing algorithms | this relaxes the constraints on certificate signing algorithms | |||
skipping to change at page 54, line 18 ¶ | skipping to change at page 55, line 46 ¶ | |||
When this message will be sent: | When this message will be sent: | |||
This message is always sent by the client. It MUST immediately | This message is always sent by the client. It MUST immediately | |||
follow the client certificate message, if it is sent. Otherwise it | follow the client certificate message, if it is sent. Otherwise it | |||
MUST be the first message sent by the client after it receives the | MUST be the first message sent by the client after it receives the | |||
server hello done message. | server hello done message. | |||
Meaning of this message: | Meaning of this message: | |||
With this message, the premaster secret is set, either though | With this message, the premaster secret is set, either through | |||
direct transmission of the RSA-encrypted secret, or by the | direct transmission of the RSA-encrypted secret, or by the | |||
transmission of Diffie-Hellman parameters that will allow each | transmission of Diffie-Hellman parameters that will allow each | |||
side to agree upon the same premaster secret. | side to agree upon the same premaster secret. | |||
When the client is using an ephemeral Diffie-Hellman exponent, | When the client is using an ephemeral Diffie-Hellman exponent, | |||
then this message contains the client's Diffie-Hellman public | then this message contains the client's Diffie-Hellman public | |||
value. If the client is sending a certificate containing a static | value. If the client is sending a certificate containing a static | |||
DH exponent (i.e., it is doing fixed_dh client authentication) | DH exponent (i.e., it is doing fixed_dh client authentication) | |||
then this message MUST be sent but MUST be empty. | then this message MUST be sent but MUST be empty. | |||
skipping to change at page 55, line 9 ¶ | skipping to change at page 56, line 36 ¶ | |||
} ClientKeyExchange; | } ClientKeyExchange; | |||
7.4.7.1. RSA Encrypted Premaster Secret Message | 7.4.7.1. RSA Encrypted Premaster Secret Message | |||
Meaning of this message: | Meaning of this message: | |||
If RSA is being used for key agreement and authentication, the | If RSA is being used for key agreement and authentication, the | |||
client generates a 48-byte premaster secret, encrypts it using the | client generates a 48-byte premaster secret, encrypts it using the | |||
public key from the server's certificate and sends the result in | public key from the server's certificate and sends the result in | |||
an encrypted premaster secret message. This structure is a variant | an encrypted premaster secret message. This structure is a variant | |||
of the client key exchange message and is not a message in itself. | of the ClientKeyExchange message and is not a message in itself. | |||
Structure of this message: | Structure of this message: | |||
struct { | struct { | |||
ProtocolVersion client_version; | ProtocolVersion client_version; | |||
opaque random[46]; | opaque random[46]; | |||
} PreMasterSecret; | } PreMasterSecret; | |||
client_version | client_version | |||
The latest (newest) version supported by the client. This is | The latest (newest) version supported by the client. This is | |||
skipping to change at page 55, line 44 ¶ | skipping to change at page 57, line 24 ¶ | |||
offered by the client in the ClientHello.client_version, not the | offered by the client in the ClientHello.client_version, not the | |||
version negotiated for the connection. This feature is designed to | version negotiated for the connection. This feature is designed to | |||
prevent rollback attacks. Unfortunately, some old implementations | prevent rollback attacks. Unfortunately, some old implementations | |||
use the negotiated version instead and therefore checking the version | use the negotiated version instead and therefore checking the version | |||
number may lead to failure to interoperate with such incorrect client | number may lead to failure to interoperate with such incorrect client | |||
implementations. | implementations. | |||
Client implementations MUST always send the correct version number in | Client implementations MUST always send the correct version number in | |||
PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher, | PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher, | |||
server implementations MUST check the version number as described in | server implementations MUST check the version number as described in | |||
the note below. If the version number is 1.0 or earlier, server | the note below. If the version number is TLS 1.0 or earlier, server | |||
implementations SHOULD check the version number, but MAY have a | implementations SHOULD check the version number, but MAY have a | |||
configuration option to disable the check. Note that if the check | configuration option to disable the check. Note that if the check | |||
fails, the PreMasterSecret SHOULD be randomized as described below. | fails, the PreMasterSecret SHOULD be randomized as described below. | |||
Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. | Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. | |||
[KPR03] can be used to attack a TLS server that reveals whether a | [KPR03] can be used to attack a TLS server that reveals whether a | |||
particular message, when decrypted, is properly PKCS#1 formatted, | particular message, when decrypted, is properly PKCS#1 formatted, | |||
contains a valid PreMasterSecret structure, or has the correct | contains a valid PreMasterSecret structure, or has the correct | |||
version number. | version number. | |||
The best way to avoid these vulnerabilities is to treat incorrectly | The best way to avoid these vulnerabilities is to treat incorrectly | |||
formatted messages in a manner indistinguishable from correctly | formatted messages in a manner indistinguishable from correctly | |||
formatted RSA blocks. In other words: | formatted RSA blocks. In other words: | |||
1. Generate a string R of 46 random bytes | 1. Generate a string R of 46 random bytes | |||
2. Decrypt the message M | 2. Decrypt the message to recover the plaintext M | |||
3. If the PKCS#1 padding is not correct, or the length of | 3. If the PKCS#1 padding is not correct, or the length of | |||
message M is not exactly 48 bytes: | message M is not exactly 48 bytes: | |||
premaster secret = ClientHello.client_version || R | premaster secret = ClientHello.client_version || R | |||
else If ClientHello.client_version <= TLS 1.0, and | else If ClientHello.client_version <= TLS 1.0, and | |||
version number check is explicitly disabled: | version number check is explicitly disabled: | |||
premaster secret = M | premaster secret = M | |||
else: | else: | |||
premaster secret = ClientHello.client_version || M[2..47] | premaster secret = ClientHello.client_version || M[2..47] | |||
skipping to change at page 56, line 49 ¶ | skipping to change at page 58, line 29 ¶ | |||
to exist provided that the above recommendations are followed. | to exist provided that the above recommendations are followed. | |||
Implementation Note: Public-key-encrypted data is represented as an | Implementation Note: Public-key-encrypted data is represented as an | |||
opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted | opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted | |||
PreMasterSecret in a ClientKeyExchange is preceded by two length | PreMasterSecret in a ClientKeyExchange is preceded by two length | |||
bytes. These bytes are redundant in the case of RSA because the | bytes. These bytes are redundant in the case of RSA because the | |||
EncryptedPreMasterSecret is the only data in the ClientKeyExchange | EncryptedPreMasterSecret is the only data in the ClientKeyExchange | |||
and its length can therefore be unambiguously determined. The SSLv3 | and its length can therefore be unambiguously determined. The SSLv3 | |||
specification was not clear about the encoding of public-key- | specification was not clear about the encoding of public-key- | |||
encrypted data, and therefore many SSLv3 implementations do not | encrypted data, and therefore many SSLv3 implementations do not | |||
include the the length bytes, encoding the RSA encrypted data | include the length bytes, encoding the RSA encrypted data directly in | |||
directly in the ClientKeyExchange message. | the ClientKeyExchange message. | |||
This specification requires correct encoding of the | This specification requires correct encoding of the | |||
EncryptedPreMasterSecret complete with length bytes. The resulting | EncryptedPreMasterSecret complete with length bytes. The resulting | |||
PDU is incompatible with many SSLv3 implementations. Implementors | PDU is incompatible with many SSLv3 implementations. Implementors | |||
upgrading from SSLv3 MUST modify their implementations to generate | upgrading from SSLv3 MUST modify their implementations to generate | |||
and accept the correct encoding. Implementors who wish to be | and accept the correct encoding. Implementors who wish to be | |||
compatible with both SSLv3 and TLS should make their implementation's | compatible with both SSLv3 and TLS should make their implementation's | |||
behavior dependent on the protocol version. | behavior dependent on the protocol version. | |||
Implementation Note: It is now known that remote timing-based attacks | Implementation Note: It is now known that remote timing-based attacks | |||
skipping to change at page 58, line 39 ¶ | skipping to change at page 60, line 19 ¶ | |||
running hashes for all potential hash algorithms up to the time of | running hashes for all potential hash algorithms up to the time of | |||
the CertificateVerify computation. Servers can minimize this | the CertificateVerify computation. Servers can minimize this | |||
computation cost by offering a restricted set of digest algorithms | computation cost by offering a restricted set of digest algorithms | |||
in the CertificateRequest message. | in the CertificateRequest message. | |||
The hash and signature algorithms used in the signature MUST be | The hash and signature algorithms used in the signature MUST be | |||
one of those present in the supported_signature_algorithms field | one of those present in the supported_signature_algorithms field | |||
of the CertificateRequest message. In addition, the hash and | of the CertificateRequest message. In addition, the hash and | |||
signature algorithms MUST be compatible with the key in the | signature algorithms MUST be compatible with the key in the | |||
client's end-entity certificate. RSA keys MAY be used with any | client's end-entity certificate. RSA keys MAY be used with any | |||
permitted hash algorith, subject to restrictions in the | permitted hash algorithm, subject to restrictions in the | |||
certificate, if any. | certificate, if any. | |||
Because DSA signatures do not contain any secure indication of | Because DSA signatures do not contain any secure indication of | |||
hash algorithm, there is a risk of hash substitution if multiple | hash algorithm, there is a risk of hash substitution if multiple | |||
hashes may be used with any key. Currently, DSS [DSS] may only be | hashes may be used with any key. Currently, DSA [DSS] may only be | |||
used with SHA-1. Future revisions of DSS [DSS-3] are expected to | used with SHA-1. Future revisions of DSS [DSS-3] are expected to | |||
allow other digest algorithms, as well as guidance as to which | allow the use of other digest algorithms with DSA, as well as | |||
digest algorithms should be used with each key size. In addition, | guidance as to which digest algorithms should be used with each | |||
future revisions of [PKIX] may specify mechanisms for certificates | key size. In addition, future revisions of [PKIX] may specify | |||
to indicate which digest algorithms are to be used with DSA. | mechanisms for certificates to indicate which digest algorithms | |||
are to be used with DSA. | ||||
7.4.9. Finished | 7.4.9. Finished | |||
When this message will be sent: | When this message will be sent: | |||
A finished message is always sent immediately after a change | A Finished message is always sent immediately after a change | |||
cipher spec message to verify that the key exchange and | cipher spec message to verify that the key exchange and | |||
authentication processes were successful. It is essential that a | authentication processes were successful. It is essential that a | |||
change cipher spec message be received between the other handshake | change cipher spec message be received between the other handshake | |||
messages and the Finished message. | messages and the Finished message. | |||
Meaning of this message: | Meaning of this message: | |||
The finished message is the first protected with the just- | The finished message is the first one protected with the just | |||
negotiated algorithms, keys, and secrets. Recipients of finished | negotiated algorithms, keys, and secrets. Recipients of finished | |||
messages MUST verify that the contents are correct. Once a side | messages MUST verify that the contents are correct. Once a side | |||
has sent its Finished message and received and validated the | has sent its Finished message and received and validated the | |||
Finished message from its peer, it may begin to send and receive | Finished message from its peer, it may begin to send and receive | |||
application data over the connection. | application data over the connection. | |||
Structure of this message: | Structure of this message: | |||
struct { | struct { | |||
opaque verify_data[verify_data_length]; | opaque verify_data[verify_data_length]; | |||
skipping to change at page 60, line 10 ¶ | skipping to change at page 61, line 42 ¶ | |||
MUST be at least 12 bytes. | MUST be at least 12 bytes. | |||
handshake_messages | handshake_messages | |||
All of the data from all messages in this handshake (not | All of the data from all messages in this handshake (not | |||
including any HelloRequest messages) up to but not including | including any HelloRequest messages) up to but not including | |||
this message. This is only data visible at the handshake layer | this message. This is only data visible at the handshake layer | |||
and does not include record layer headers. This is the | and does not include record layer headers. This is the | |||
concatenation of all the Handshake structures as defined in | concatenation of all the Handshake structures as defined in | |||
7.4, exchanged thus far. | 7.4, exchanged thus far. | |||
It is a fatal error if a finished message is not preceded by a change | It is a fatal error if a finished message is not preceded by a | |||
cipher spec message at the appropriate point in the handshake. | ChangeCipherSpec message at the appropriate point in the handshake. | |||
The value handshake_messages includes all handshake messages starting | The value handshake_messages includes all handshake messages starting | |||
at client hello up to, but not including, this finished message. This | at ClientHello up to, but not including, this Finished message. This | |||
may be different from handshake_messages in Section 7.4.8 because it | may be different from handshake_messages in Section 7.4.8 because it | |||
would include the certificate verify message (if sent). Also, the | would include the CertificateVerify message (if sent). Also, the | |||
handshake_messages for the finished message sent by the client will | handshake_messages for the Finished message sent by the client will | |||
be different from that for the finished message sent by the server, | be different from that for the Finished message sent by the server, | |||
because the one that is sent second will include the prior one. | because the one that is sent second will include the prior one. | |||
Note: Change cipher spec messages, alerts, and any other record types | Note: ChangeCipherSpec messages, alerts, and any other record types | |||
are not handshake messages and are not included in the hash | are not handshake messages and are not included in the hash | |||
computations. Also, Hello Request messages are omitted from handshake | computations. Also, HelloRequest messages are omitted from handshake | |||
hashes. | hashes. | |||
8. Cryptographic Computations | 8. Cryptographic Computations | |||
In order to begin connection protection, the TLS Record Protocol | In order to begin connection protection, the TLS Record Protocol | |||
requires specification of a suite of algorithms, a master secret, and | requires specification of a suite of algorithms, a master secret, and | |||
the client and server random values. The authentication, encryption, | the client and server random values. The authentication, encryption, | |||
and MAC algorithms are determined by the cipher_suite selected by the | and MAC algorithms are determined by the cipher_suite selected by the | |||
server and revealed in the server hello message. The compression | server and revealed in the server hello message. The compression | |||
algorithm is negotiated in the hello messages, and the random values | algorithm is negotiated in the hello messages, and the random values | |||
skipping to change at page 61, line 29 ¶ | skipping to change at page 63, line 10 ¶ | |||
contain all zero bits are stripped before it is used as the | contain all zero bits are stripped before it is used as the | |||
pre_master_secret. | pre_master_secret. | |||
Note: Diffie-Hellman parameters are specified by the server and may | Note: Diffie-Hellman parameters are specified by the server and may | |||
be either ephemeral or contained within the server's certificate. | be either ephemeral or contained within the server's certificate. | |||
9. Mandatory Cipher Suites | 9. Mandatory Cipher Suites | |||
In the absence of an application profile standard specifying | In the absence of an application profile standard specifying | |||
otherwise, a TLS compliant application MUST implement the cipher | otherwise, a TLS compliant application MUST implement the cipher | |||
suite TLS_RSA_WITH_AES_128_CBC_SHA. | suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the | |||
definition). | ||||
10. Application Data Protocol | 10. Application Data Protocol | |||
Application data messages are carried by the Record Layer and are | Application data messages are carried by the Record Layer and are | |||
fragmented, compressed, and encrypted based on the current connection | fragmented, compressed, and encrypted based on the current connection | |||
state. The messages are treated as transparent data to the record | state. The messages are treated as transparent data to the record | |||
layer. | layer. | |||
11. Security Considerations | 11. Security Considerations | |||
skipping to change at page 62, line 33 ¶ | skipping to change at page 64, line 17 ¶ | |||
- TLS HandshakeType Registry: Future values are allocated via | - TLS HandshakeType Registry: Future values are allocated via | |||
Standards Action [RFC2434]. | Standards Action [RFC2434]. | |||
This document also uses a registry originally created in [RFC4366]. | This document also uses a registry originally created in [RFC4366]. | |||
IANA is requested to update (has updated) it to reference this | IANA is requested to update (has updated) it to reference this | |||
document. The registry and its allocation policy (unchanged from | document. The registry and its allocation policy (unchanged from | |||
[RFC4366]) is listed below: | [RFC4366]) is listed below: | |||
- TLS ExtensionType Registry: Future values are allocated via IETF | - TLS ExtensionType Registry: Future values are allocated via IETF | |||
Consensus [RFC2434] | Consensus [RFC2434]. IANA is requested to update this registry to | |||
include the signature_algorithms extension and fill in the | ||||
appropriate value in Section 7.4.1.4. | ||||
In addition, this document defines two new registries to be | In addition, this document defines two new registries to be | |||
maintained by IANA: | maintained by IANA: | |||
- TLS SignatureAlgorithm Registry: The registry will be initially | - TLS SignatureAlgorithm Registry: The registry will be initially | |||
populated with the values described in Section 7.4.1.4.1. Future | populated with the values described in Section 7.4.1.4.1. Future | |||
values in the range 0-63 (decimal) inclusive are assigned via | values in the range 0-63 (decimal) inclusive are assigned via | |||
Standards Action [RFC2434]. Values in the range 64-223 (decimal) | Standards Action [RFC2434]. Values in the range 64-223 (decimal) | |||
inclusive are assigned via Specification Required [RFC2434]. | inclusive are assigned via Specification Required [RFC2434]. | |||
Values from 224-255 (decimal) inclusive are reserved for Private | Values from 224-255 (decimal) inclusive are reserved for Private | |||
Use [RFC2434]. | Use [RFC2434]. | |||
- TLS HashAlgorithm Registry: The registry will be initially | - TLS HashAlgorithm Registry: The registry will be initially | |||
populated with the values described in Section 7.4.1.4.1. Future | populated with the values described in Section 7.4.1.4.1. Future | |||
values in the range 0-63 (decimal) inclusive are assigned via | values in the range 0-63 (decimal) inclusive are assigned via | |||
Standards Action [RFC2434]. Values in the range 64-223 (decimal) | Standards Action [RFC2434]. Values in the range 64-223 (decimal) | |||
inclusive are assigned via Specification Required [RFC2434]. | inclusive are assigned via Specification Required [RFC2434]. | |||
Values from 224-255 (decimal) inclusive are reserved for Private | Values from 224-255 (decimal) inclusive are reserved for Private | |||
Use [RFC2434]. | Use [RFC2434]. | |||
This document defines one new TLS extension, signature_algorithms, | This document also uses the TLS Compression Method Identifiers | |||
which is to be (has been) allocated value TBD-BY-IANA in the TLS | Registry, defined in [RFC3749]. IANA is requested to allocate | |||
ExtensionType registry. | value 0 for the "null" compression method. | |||
This document also uses the TLS Compression Method Identifiers | ||||
Registry, defined in [RFC3749]. IANA is requested to allocate value | ||||
0 for the "null" compression method. | ||||
Appendix A. Protocol Constant Values | Appendix A. Protocol Data Structures and Constant Values | |||
This section describes protocol types and constants. | This section describes protocol types and constants. | |||
A.1. Record Layer | A.1. Record Layer | |||
struct { | struct { | |||
uint8 major; | uint8 major; | |||
uint8 minor; | uint8 minor; | |||
} ProtocolVersion; | } ProtocolVersion; | |||
ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/ | ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/ | |||
skipping to change at page 65, line 14 ¶ | skipping to change at page 66, line 14 ¶ | |||
struct { | struct { | |||
opaque IV[SecurityParameters.record_iv_length]; | opaque IV[SecurityParameters.record_iv_length]; | |||
block-ciphered struct { | block-ciphered struct { | |||
opaque content[TLSCompressed.length]; | opaque content[TLSCompressed.length]; | |||
opaque MAC[SecurityParameters.mac_length]; | opaque MAC[SecurityParameters.mac_length]; | |||
uint8 padding[GenericBlockCipher.padding_length]; | uint8 padding[GenericBlockCipher.padding_length]; | |||
uint8 padding_length; | uint8 padding_length; | |||
}; | }; | |||
} GenericBlockCipher; | } GenericBlockCipher; | |||
aead-ciphered struct { | struct { | |||
opaque IV[SecurityParameters.record_iv_length]; | opaque nonce_explicit[SecurityParameters.record_iv_length]; | |||
opaque aead_output[AEADEncrypted.length]; | aead-ciphered struct { | |||
opaque content[TLSCompressed.length]; | ||||
}; | ||||
} GenericAEADCipher; | } GenericAEADCipher; | |||
A.2. Change Cipher Specs Message | A.2. Change Cipher Specs Message | |||
struct { | struct { | |||
enum { change_cipher_spec(1), (255) } type; | enum { change_cipher_spec(1), (255) } type; | |||
} ChangeCipherSpec; | } ChangeCipherSpec; | |||
A.3. Alert Messages | A.3. Alert Messages | |||
enum { warning(1), fatal(2), (255) } AlertLevel; | enum { warning(1), fatal(2), (255) } AlertLevel; | |||
skipping to change at page 67, line 48 ¶ | skipping to change at page 68, line 48 ¶ | |||
struct { | struct { | |||
ExtensionType extension_type; | ExtensionType extension_type; | |||
opaque extension_data<0..2^16-1>; | opaque extension_data<0..2^16-1>; | |||
} Extension; | } Extension; | |||
enum { | enum { | |||
signature_algorithms(TBD-BY-IANA), (65535) | signature_algorithms(TBD-BY-IANA), (65535) | |||
} ExtensionType; | } ExtensionType; | |||
enum{ | enum{ | |||
none(0), md5(1), sha1(2), sha256(3), sha384(4), | none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), | |||
sha512(5), (255) | sha512(6), (255) | |||
} HashAlgorithm; | } HashAlgorithm; | |||
enum { anonymous(0), rsa(1), dsa(2), (255) } SignatureAlgorithm; | enum { | |||
anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) | ||||
} SignatureAlgorithm; | ||||
struct { | struct { | |||
HashAlgorithm hash; | HashAlgorithm hash; | |||
SignatureAlgorithm signature; | SignatureAlgorithm signature; | |||
} SignatureAndHashAlgorithm; | } SignatureAndHashAlgorithm; | |||
SignatureAndHashAlgorithm | SignatureAndHashAlgorithm | |||
supported_signature_algorithms<2..2^16-1>; | supported_signature_algorithms<2..2^16-1>; | |||
A.4.2. Server Authentication and Key Exchange Messages | A.4.2. Server Authentication and Key Exchange Messages | |||
opaque ASN.1Cert<2^24-1>; | opaque ASN.1Cert<2^24-1>; | |||
struct { | struct { | |||
ASN.1Cert certificate_list<0..2^24-1>; | ASN.1Cert certificate_list<0..2^24-1>; | |||
} Certificate; | } Certificate; | |||
enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa} | enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa | |||
KeyExchangeAlgorithm; | /* may be extended, e.g. for ECDH -- see [TLSECC] */ | |||
} KeyExchangeAlgorithm; | ||||
struct { | struct { | |||
opaque dh_p<1..2^16-1>; | opaque dh_p<1..2^16-1>; | |||
opaque dh_g<1..2^16-1>; | opaque dh_g<1..2^16-1>; | |||
opaque dh_Ys<1..2^16-1>; | opaque dh_Ys<1..2^16-1>; | |||
} ServerDHParams; /* Ephemeral DH parameters */ | } ServerDHParams; /* Ephemeral DH parameters */ | |||
struct { | struct { | |||
select (KeyExchangeAlgorithm) { | select (KeyExchangeAlgorithm) { | |||
case dh_anon: | case dh_anon: | |||
skipping to change at page 68, line 48 ¶ | skipping to change at page 69, line 51 ¶ | |||
digitally-signed struct { | digitally-signed struct { | |||
opaque client_random[32]; | opaque client_random[32]; | |||
opaque server_random[32]; | opaque server_random[32]; | |||
ServerDHParams params; | ServerDHParams params; | |||
} signed_params; | } signed_params; | |||
case rsa: | case rsa: | |||
case dh_dss: | case dh_dss: | |||
case dh_rsa: | case dh_rsa: | |||
struct {} ; | struct {} ; | |||
/* message is omitted for rsa, dh_dss, and dh_rsa */ | /* message is omitted for rsa, dh_dss, and dh_rsa */ | |||
}; | /* may be extended, e.g. for ECDH -- see [TLSECC] */ | |||
} ServerKeyExchange; | } ServerKeyExchange; | |||
enum { | enum { | |||
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | |||
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), | rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), | |||
fortezza_dms_RESERVED(20), | fortezza_dms_RESERVED(20), | |||
(255) | (255) | |||
} ClientCertificateType; | } ClientCertificateType; | |||
opaque DistinguishedName<1..2^16-1>; | opaque DistinguishedName<1..2^16-1>; | |||
struct { | struct { | |||
skipping to change at page 71, line 5 ¶ | skipping to change at page 72, line 10 ¶ | |||
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F }; | CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F }; | |||
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 }; | CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 }; | |||
CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD2 }; | CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD2 }; | |||
CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBD3 }; | CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBD3 }; | |||
The following cipher suite definitions are used for server- | The following cipher suite definitions are used for server- | |||
authenticated (and optionally client-authenticated) Diffie-Hellman. | authenticated (and optionally client-authenticated) Diffie-Hellman. | |||
DH denotes cipher suites in which the server's certificate contains | DH denotes cipher suites in which the server's certificate contains | |||
the Diffie-Hellman parameters signed by the certificate authority | the Diffie-Hellman parameters signed by the certificate authority | |||
(CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman | (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman | |||
parameters are signed by a a signature-capable certificate, which has | parameters are signed by a signature-capable certificate, which has | |||
been signed by the CA. The signing algorithm used by the server is | been signed by the CA. The signing algorithm used by the server is | |||
specified after the DHE parameter. The server can request any | specified after the DHE component of the CipherSuite name. The server | |||
signature-capable certificate from the client for client | can request any signature-capable certificate from the client for | |||
authentication or it may request a Diffie-Hellman certificate. Any | client authentication or it may request a Diffie-Hellman certificate. | |||
Diffie-Hellman certificate provided by the client must use the | Any Diffie-Hellman certificate provided by the client must use the | |||
parameters (group and generator) described by the server. | parameters (group and generator) described by the server. | |||
CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; | CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; | |||
CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; | CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; | |||
CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; | CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; | |||
CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; | 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_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 }; | |||
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 }; | 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_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 }; | |||
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 }; | 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_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 }; | |||
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 }; | 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_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 }; | |||
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 }; | CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 }; | |||
CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00, TBD4}; | CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,TBD4 }; | |||
CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00, TBD5}; | CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD5 }; | |||
CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00, TBD6}; | CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,TBD6 }; | |||
CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00, TBD7}; | CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,TBD7 }; | |||
CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00, TBD8}; | CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,TBD8 }; | |||
CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00, TBD9}; | CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBD9 }; | |||
CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00, TBDA}; | CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,TBDA }; | |||
CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00, TBDB}; | CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,TBDB }; | |||
The following cipher suites are used for completely anonymous Diffie- | The following cipher suites are used for completely anonymous Diffie- | |||
Hellman communications in which neither party is authenticated. Note | Hellman communications in which neither party is authenticated. Note | |||
that this mode is vulnerable to man-in-the-middle attacks. Using | that this mode is vulnerable to man-in-the-middle attacks. Using | |||
this mode therefore is of limited use: These cipher suites MUST NOT | this mode therefore is of limited use: These cipher suites MUST NOT | |||
be used by TLS 1.2 implementations unless the application layer has | be used by TLS 1.2 implementations unless the application layer has | |||
specifically requested to allow anonymous key exchange. (Anonymous | specifically requested to allow anonymous key exchange. (Anonymous | |||
key exchange may sometimes be acceptable, for example, to support | key exchange may sometimes be acceptable, for example, to support | |||
opportunistic encryption when no set-up for authentication is in | opportunistic encryption when no set-up for authentication is in | |||
place, or when TLS is used as part of more complex security protocols | place, or when TLS is used as part of more complex security protocols | |||
that have other means to ensure authentication.) | that have other means to ensure authentication.) | |||
CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; | CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; | |||
CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; | CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; | |||
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 }; | CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 }; | |||
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A }; | CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A }; | |||
CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00, TBDC}; | CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,TBDC}; | |||
CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00, TBDD}; | CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,TBDD}; | |||
Note that using non-anonymous key exchange without actually verifying | Note that using non-anonymous key exchange without actually verifying | |||
the key exchange is essentially equivalent to anonymous key exchange, | the key exchange is essentially equivalent to anonymous key exchange, | |||
and the same precautions apply. While non-anonymous key exchange | and the same precautions apply. While non-anonymous key exchange | |||
will generally involve a higher computational and communicational | will generally involve a higher computational and communicational | |||
cost than anonymous key exchange, it may be in the interest of | cost than anonymous key exchange, it may be in the interest of | |||
interoperability not to disable non-anonymous key exchange when the | interoperability not to disable non-anonymous key exchange when the | |||
application layer is allowing anonymous key exchange. | application layer is allowing anonymous key exchange. | |||
New cipher suite values are assigned by IANA as described in Section | New cipher suite values are assigned by IANA as described in Section | |||
skipping to change at page 72, line 37 ¶ | skipping to change at page 73, line 41 ¶ | |||
enum { server, client } ConnectionEnd; | enum { server, client } ConnectionEnd; | |||
enum { tls_prf_sha256 } PRFAlgorithm; | enum { tls_prf_sha256 } PRFAlgorithm; | |||
enum { null, rc4, 3des, aes } | enum { null, rc4, 3des, aes } | |||
BulkCipherAlgorithm; | BulkCipherAlgorithm; | |||
enum { stream, block, aead } CipherType; | enum { stream, block, aead } CipherType; | |||
enum { null, hmac_md5, hmac_sha, hmac_sha256, hmac_sha384, | enum { null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384, | |||
hmac_sha512} MACAlgorithm; | hmac_sha512} MACAlgorithm; | |||
/* The algorithms specified in CompressionMethod, | /* The algorithms specified in CompressionMethod, PRFAlgorithm | |||
BulkCipherAlgorithm, and MACAlgorithm may be added to. */ | BulkCipherAlgorithm, and MACAlgorithm may be added to. */ | |||
struct { | struct { | |||
ConnectionEnd entity; | ConnectionEnd entity; | |||
PRFAlgorithm prf_algorithm; | PRFAlgorithm prf_algorithm; | |||
BulkCipherAlgorithm bulk_cipher_algorithm; | BulkCipherAlgorithm bulk_cipher_algorithm; | |||
CipherType cipher_type; | CipherType cipher_type; | |||
uint8 enc_key_length; | uint8 enc_key_length; | |||
uint8 block_length; | uint8 block_length; | |||
uint8 fixed_iv_length; | uint8 fixed_iv_length; | |||
skipping to change at page 73, line 24 ¶ | skipping to change at page 74, line 29 ¶ | |||
RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This | RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This | |||
document changes some of the structures used in that document. This | document changes some of the structures used in that document. This | |||
section details the required changes for implementors of both RFC | section details the required changes for implementors of both RFC | |||
4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing | 4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing | |||
RFC 4492 do not need to read this section. | RFC 4492 do not need to read this section. | |||
This document adds a "signature_algorithm" field to the digitally- | This document adds a "signature_algorithm" field to the digitally- | |||
signed element in order to identify the signature and digest | signed element in order to identify the signature and digest | |||
algorithms used to create a signature. This change applies to digital | algorithms used to create a signature. This change applies to digital | |||
signatures formed using ECDSA as well, thus allowing ECDSA signatures | signatures formed using ECDSA as well, thus allowing ECDSA signatures | |||
to be used and digest algorithms other than SHA-1, provided such use | to be used with digest algorithms other than SHA-1, provided such use | |||
is compatible with the certificate and any restrictions imposed by | is compatible with the certificate and any restrictions imposed by | |||
future revisions of [PKIX]. | future revisions of [PKIX]. | |||
As described in Sections 7.4.2 and 7.4.6, the restrictions on the | As described in Sections 7.4.2 and 7.4.6, the restrictions on the | |||
signature algorithms used to sign certificates are no longer tied to | signature algorithms used to sign certificates are no longer tied to | |||
the cipher suite (when used by the server) or the | the cipher suite (when used by the server) or the | |||
ClientCertificateType (when used by the client). Thus, the | ClientCertificateType (when used by the client). Thus, the | |||
restrictions on the algorithm used to sign certificates specified in | restrictions on the algorithm used to sign certificates specified in | |||
Sections 2 and 3 of RFC 4492 are also relaxed. As in this document | Sections 2 and 3 of RFC 4492 are also relaxed. As in this document | |||
the restrictions on the keys in the end-entity certificate remain. | the restrictions on the keys in the end-entity certificate remain. | |||
Appendix B. Glossary | Appendix B. Glossary | |||
Advanced Encryption Standard (AES) | Advanced Encryption Standard (AES) | |||
AES is a widely used symmetric encryption algorithm. AES is a | AES [AES] is a widely used symmetric encryption algorithm. AES is | |||
block cipher with a 128, 192, or 256 bit keys and a 16 byte block | a block cipher with a 128, 192, or 256 bit keys and a 16 byte | |||
size. [AES] TLS currently only supports the 128 and 256 bit key | block size. TLS currently only supports the 128 and 256 bit key | |||
sizes. | sizes. | |||
application protocol | application protocol | |||
An application protocol is a protocol that normally layers | An application protocol is a protocol that normally layers | |||
directly on top of the transport layer (e.g., TCP/IP). Examples | directly on top of the transport layer (e.g., TCP/IP). Examples | |||
include HTTP, TELNET, FTP, and SMTP. | include HTTP, TELNET, FTP, and SMTP. | |||
asymmetric cipher | asymmetric cipher | |||
See public key cryptography. | See public key cryptography. | |||
authenticated encryption with additional data (AEAD) | authenticated encryption with additional data (AEAD) | |||
A symmetric encryption algorithm that simultaneously provides | A symmetric encryption algorithm that simultaneously provides | |||
confidentiality and message integrity. | confidentiality and message integrity. | |||
authentication | authentication | |||
Authentication is the ability of one entity to determine the | Authentication is the ability of one entity to determine the | |||
identity of another entity. | identity of another entity. | |||
block cipher | block cipher | |||
A block cipher is an algorithm that operates on plaintext in | A block cipher is an algorithm that operates on plaintext in | |||
groups of bits, called blocks. 64 bits is a common block size. | groups of bits, called blocks. 64 bits was, and 128 bits, is a | |||
common block size. | ||||
bulk cipher | bulk cipher | |||
A symmetric encryption algorithm used to encrypt large quantities | A symmetric encryption algorithm used to encrypt large quantities | |||
of data. | of data. | |||
cipher block chaining (CBC) | cipher block chaining (CBC) | |||
CBC is a mode in which every plaintext block encrypted with a | CBC is a mode in which every plaintext block encrypted with a | |||
block cipher is first exclusive-ORed with the previous ciphertext | block cipher is first exclusive-ORed with the previous ciphertext | |||
block (or, in the case of the first block, with the initialization | block (or, in the case of the first block, with the initialization | |||
vector). For decryption, every block is first decrypted, then | vector). For decryption, every block is first decrypted, then | |||
skipping to change at page 75, line 6 ¶ | skipping to change at page 76, line 12 ¶ | |||
client write MAC key | client write MAC key | |||
The secret data used to authenticate data written by the client. | The secret data used to authenticate data written by the client. | |||
connection | connection | |||
A connection is a transport (in the OSI layering model definition) | A connection is a transport (in the OSI layering model definition) | |||
that provides a suitable type of service. For TLS, such | that provides a suitable type of service. For TLS, such | |||
connections are peer-to-peer relationships. The connections are | connections are peer-to-peer relationships. The connections are | |||
transient. Every connection is associated with one session. | transient. Every connection is associated with one session. | |||
Data Encryption Standard | Data Encryption Standard | |||
DES is a very widely used symmetric encryption algorithm. DES is a | DES [DES] still is a very widely used symmetric encryption | |||
block cipher with a 56 bit key and an 8 byte block size. Note that | algorithm although it is considered as rather weak now. DES is a | |||
in TLS, for key generation purposes, DES is treated as having an 8 | block cipher with a 56-bit key and an 8-byte block size. Note that | |||
byte key length (64 bits), but it still only provides 56 bits of | 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 | 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 | produce odd parity in that key byte.) DES can also be operated in | |||
a mode where three independent keys and three encryptions are used | a mode [3DES] where three independent keys and three encryptions | |||
for each block of data; this uses 168 bits of key (24 bytes in the | are used for each block of data; this uses 168 bits of key (24 | |||
TLS key generation method) and provides the equivalent of 112 bits | bytes in the TLS key generation method) and provides the | |||
of security. [DES], [3DES] | equivalent of 112 bits of security. | |||
Digital Signature Standard (DSS) | Digital Signature Standard (DSS) | |||
A standard for digital signing, including the Digital Signing | A standard for digital signing, including the Digital Signing | |||
Algorithm, approved by the National Institute of Standards and | Algorithm, approved by the National Institute of Standards and | |||
Technology, defined in NIST FIPS PUB 186, "Digital Signature | Technology, defined in NIST FIPS PUB 186-2, "Digital Signature | |||
Standard", published May, 1994 by the U.S. Dept. of Commerce. | Standard", published January 2000 by the U.S. Dept. of Commerce | |||
[DSS] | [DSS]. A significant update [DSS-3] has been drafted and | |||
published in March 2006. | ||||
digital signatures | digital signatures | |||
Digital signatures utilize public key cryptography and one-way | Digital signatures utilize public key cryptography and one-way | |||
hash functions to produce a signature of the data that can be | hash functions to produce a signature of the data that can be | |||
authenticated, and is difficult to forge or repudiate. | authenticated, and is difficult to forge or repudiate. | |||
handshake | handshake | |||
An initial negotiation between client and server that establishes | An initial negotiation between client and server that establishes | |||
the parameters of their transactions. | the parameters of their transactions. | |||
skipping to change at page 75, line 49 ¶ | skipping to change at page 77, line 10 ¶ | |||
A Message Authentication Code is a one-way hash computed from a | A Message Authentication Code is a one-way hash computed from a | |||
message and some secret data. It is difficult to forge without | message and some secret data. It is difficult to forge without | |||
knowing the secret data. Its purpose is to detect if the message | knowing the secret data. Its purpose is to detect if the message | |||
has been altered. | has been altered. | |||
master secret | master secret | |||
Secure secret data used for generating encryption keys, MAC | Secure secret data used for generating encryption keys, MAC | |||
secrets, and IVs. | secrets, and IVs. | |||
MD5 | MD5 | |||
MD5 is a secure hashing function that converts an arbitrarily long | MD5 [MD5] is a hashing function that converts an arbitrarily long | |||
data stream into a hash of fixed size (16 bytes). [MD5] | data stream into a hash of fixed size (16 bytes). Due to | |||
significant progresses in cryptanalysis, at the time of | ||||
publication of this document, MD5 no longer can be considered a | ||||
'secure' hashing function. | ||||
public key cryptography | public key cryptography | |||
A class of cryptographic techniques employing two-key ciphers. | A class of cryptographic techniques employing two-key ciphers. | |||
Messages encrypted with the public key can only be decrypted with | Messages encrypted with the public key can only be decrypted with | |||
the associated private key. Conversely, messages signed with the | the associated private key. Conversely, messages signed with the | |||
private key can be verified with the public key. | private key can be verified with the public key. | |||
one-way hash function | one-way hash function | |||
A one-way transformation that converts an arbitrary amount of data | A one-way transformation that converts an arbitrary amount of data | |||
into a fixed-length hash. It is computationally hard to reverse | into a fixed-length hash. It is computationally hard to reverse | |||
skipping to change at page 76, line 45 ¶ | skipping to change at page 78, line 9 ¶ | |||
A session identifier is a value generated by a server that | A session identifier is a value generated by a server that | |||
identifies a particular session. | identifies a particular session. | |||
server write key | server write key | |||
The key used to encrypt data written by the server. | The key used to encrypt data written by the server. | |||
server write MAC key | server write MAC key | |||
The secret data used to authenticate data written by the server. | The secret data used to authenticate data written by the server. | |||
SHA | SHA | |||
The Secure Hash Algorithm is defined in FIPS PUB 180-2. It | The Secure Hash Algorithm [SHS] is defined in FIPS PUB 180-2. It | |||
produces a 20-byte output. Note that all references to SHA | produces a 20-byte output. Note that all references to SHA | |||
actually use the modified SHA-1 algorithm. [SHA] | (without a numerical suffix) actually use the modified SHA-1 | |||
algorithm. | ||||
SHA-256 | SHA-256 | |||
The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2. It | The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2. It | |||
produces a 32-byte output. | produces a 32-byte output. | |||
SSL | SSL | |||
Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on | Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on | |||
SSL Version 3.0 | SSL Version 3.0 | |||
stream cipher | stream cipher | |||
skipping to change at page 78, line 48 ¶ | skipping to change at page 79, line 48 ¶ | |||
TLS_DH_RSA_WITH_AES_128_CBC_SHA256 DH_RSA AES_128_CBC SHA256 | TLS_DH_RSA_WITH_AES_128_CBC_SHA256 DH_RSA AES_128_CBC SHA256 | |||
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE_DSS AES_128_CBC SHA256 | TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE_DSS AES_128_CBC SHA256 | |||
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256 | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256 | |||
TLS_DH_anon_WITH_AES_128_CBC_SHA256 DH_anon AES_128_CBC SHA256 | TLS_DH_anon_WITH_AES_128_CBC_SHA256 DH_anon AES_128_CBC SHA256 | |||
TLS_DH_DSS_WITH_AES_256_CBC_SHA256 DH_DSS AES_256_CBC SHA256 | TLS_DH_DSS_WITH_AES_256_CBC_SHA256 DH_DSS AES_256_CBC SHA256 | |||
TLS_DH_RSA_WITH_AES_256_CBC_SHA256 DH_RSA AES_256_CBC SHA256 | TLS_DH_RSA_WITH_AES_256_CBC_SHA256 DH_RSA AES_256_CBC SHA256 | |||
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE_DSS AES_256_CBC SHA256 | TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE_DSS AES_256_CBC SHA256 | |||
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE_RSA AES_256_CBC SHA256 | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE_RSA AES_256_CBC SHA256 | |||
TLS_DH_anon_WITH_AES_256_CBC_SHA256 DH_anon AES_256_CBC SHA256 | TLS_DH_anon_WITH_AES_256_CBC_SHA256 DH_anon AES_256_CBC SHA256 | |||
Key Expanded IV Block | Key IV Block | |||
Cipher Type Material Key Material Size Size | Cipher Type Material Size Size | |||
------------ ------ -------- ---- ----- | ||||
NULL Stream 0 0 0 N/A | NULL Stream 0 0 N/A | |||
RC4_128 Stream 16 16 0 N/A | RC4_128 Stream 16 0 N/A | |||
3DES_EDE_CBC Block 24 24 8 8 | 3DES_EDE_CBC Block 24 8 8 | |||
AES_128_CBC Block 16 16 16 16 | AES_128_CBC Block 16 16 16 | |||
AES_256_CBC Block 32 32 16 16 | AES_256_CBC Block 32 16 16 | |||
MAC Algorithm mac_length mac_key_length | MAC Algorithm mac_length mac_key_length | |||
-------- ----------- ---------- -------------- | ||||
NULL N/A 0 0 | NULL N/A 0 0 | |||
MD5 HMAC-MD5 16 16 | MD5 HMAC-MD5 16 16 | |||
SHA HMAC-SHA1 20 20 | SHA HMAC-SHA1 20 20 | |||
SHA256 HMAC-SHA256 32 32 | SHA256 HMAC-SHA256 32 32 | |||
Type | Type | |||
Indicates whether this is a stream cipher or a block cipher | Indicates whether this is a stream cipher or a block cipher | |||
running in CBC mode. | running in CBC mode. | |||
Key Material | Key Material | |||
The number of bytes from the key_block that are used for | The number of bytes from the key_block that are used for | |||
generating the write keys. | generating the write keys. | |||
Expanded Key Material | Expanded Key Material | |||
skipping to change at page 83, line 19 ¶ | skipping to change at page 84, line 19 ¶ | |||
Since there are various versions of TLS (1.0, 1.1, 1.2, and any | 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 | future versions) and SSL (2.0 and 3.0), means are needed to negotiate | |||
the specific protocol version to use. The TLS protocol provides a | the specific protocol version to use. The TLS protocol provides a | |||
built-in mechanism for version negotiation so as not to bother other | built-in mechanism for version negotiation so as not to bother other | |||
protocol components with the complexities of version selection. | protocol components with the complexities of version selection. | |||
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use | TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use | |||
compatible ClientHello messages; thus, supporting all of them is | compatible ClientHello messages; thus, supporting all of them is | |||
relatively easy. Similarly, servers can easily handle clients trying | relatively easy. Similarly, servers can easily handle clients trying | |||
to use future versions of TLS as long as the ClientHello format | to use future versions of TLS as long as the ClientHello format | |||
remains compatible, and the client support the highest protocol | remains compatible, and the client supports the highest protocol | |||
version available in the server. | version available in the server. | |||
A TLS 1.2 client who wishes to negotiate with such older servers will | A TLS 1.2 client who wishes to negotiate with such older servers will | |||
send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in | send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in | |||
ClientHello.client_version. If the server does not support this | ClientHello.client_version. If the server does not support this | |||
version, it will respond with ServerHello containing an older version | version, it will respond with ServerHello containing an older version | |||
number. If the client agrees to use this version, the negotiation | number. If the client agrees to use this version, the negotiation | |||
will proceed as appropriate for the negotiated protocol. | will proceed as appropriate for the negotiated protocol. | |||
If the version chosen by the server is not supported by the client | If the version chosen by the server is not supported by the client | |||
(or not acceptable), the client MUST send a "protocol_version" alert | (or not acceptable), the client MUST send a "protocol_version" alert | |||
message and close the connection. | message and close the connection. | |||
If a TLS server receives a ClientHello containing a version number | If a TLS server receives a ClientHello containing a version number | |||
greater than the highest version supported by the server, it MUST | greater than the highest version supported by the server, it MUST | |||
reply according to the highest version supported by the server. | reply according to the highest version supported by the server. | |||
A TLS server can also receive a ClientHello containing version number | A TLS server can also receive a ClientHello containing a version | |||
smaller than the highest supported version. If the server wishes to | number smaller than the highest supported version. If the server | |||
negotiate with old clients, it will proceed as appropriate for the | wishes to negotiate with old clients, it will proceed as appropriate | |||
highest version supported by the server that is not greater than | for the highest version supported by the server that is not greater | |||
ClientHello.client_version. For example, if the server supports TLS | than ClientHello.client_version. For example, if the server supports | |||
1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will | TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will | |||
proceed with a TLS 1.0 ServerHello. If server supports (or is willing | 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 | to use) only versions greater than client_version, it MUST send a | |||
"protocol_version" alert message and close the connection. | "protocol_version" alert message and close the connection. | |||
Whenever a client already knows the highest protocol known to a | Whenever a client already knows the highest protocol version known to | |||
server (for example, when resuming a session), it SHOULD initiate the | a server (for example, when resuming a session), it SHOULD initiate | |||
connection in that native protocol. | the connection in that native protocol. | |||
Note: some server implementations are known to implement version | Note: some server implementations are known to implement version | |||
negotiation incorrectly. For example, there are buggy TLS 1.0 servers | negotiation incorrectly. For example, there are buggy TLS 1.0 servers | |||
that simply close the connection when the client offers a version | that simply close the connection when the client offers a version | |||
newer than TLS 1.0. Also, it is known that some servers will refuse | newer than TLS 1.0. Also, it is known that some servers will refuse | |||
connection if any TLS extensions are included in ClientHello. | the connection if any TLS extensions are included in ClientHello. | |||
Interoperability with such buggy servers is a complex topic beyond | Interoperability with such buggy servers is a complex topic beyond | |||
the scope of this document, and may require multiple connection | the scope of this document, and may require multiple connection | |||
attempts by the client. | attempts by the client. | |||
Earlier versions of the TLS specification were not fully clear on | Earlier versions of the TLS specification were not fully clear on | |||
what the record layer version number (TLSPlaintext.version) should | what the record layer version number (TLSPlaintext.version) should | |||
contain when sending ClientHello (i.e., before it is known which | contain when sending ClientHello (i.e., before it is known which | |||
version of the protocol will be employed). Thus, TLS servers | version of the protocol will be employed). Thus, TLS servers | |||
compliant with this specification MUST accept any value {03,XX} as | compliant with this specification MUST accept any value {03,XX} as | |||
the record layer version number for ClientHello. | the record layer version number for ClientHello. | |||
skipping to change at page 88, line 41 ¶ | skipping to change at page 89, line 41 ¶ | |||
a value derived from all preceding handshake messages. These | a value derived from all preceding handshake messages. These | |||
handshake messages include the server certificate, which binds the | handshake messages include the server certificate, which binds the | |||
signature to the server, and ServerHello.random, which binds the | signature to the server, and ServerHello.random, which binds the | |||
signature to the current handshake process. | signature to the current handshake process. | |||
F.1.1.3. Diffie-Hellman Key Exchange with Authentication | F.1.1.3. Diffie-Hellman Key Exchange with Authentication | |||
When Diffie-Hellman key exchange is used, the server can either | When Diffie-Hellman key exchange is used, the server can either | |||
supply a certificate containing fixed Diffie-Hellman parameters or | supply a certificate containing fixed Diffie-Hellman parameters or | |||
use the server key exchange message to send a set of temporary | use the server key exchange message to send a set of temporary | |||
Diffie-Hellman parameters signed with a DSS or RSA certificate. | Diffie-Hellman parameters signed with a DSA or RSA certificate. | |||
Temporary parameters are hashed with the hello.random values before | Temporary parameters are hashed with the hello.random values before | |||
signing to ensure that attackers do not replay old parameters. In | signing to ensure that attackers do not replay old parameters. In | |||
either case, the client can verify the certificate or signature to | either case, the client can verify the certificate or signature to | |||
ensure that the parameters belong to the server. | ensure that the parameters belong to the server. | |||
If the client has a certificate containing fixed Diffie-Hellman | If the client has a certificate containing fixed Diffie-Hellman | |||
parameters, its certificate contains the information required to | parameters, its certificate contains the information required to | |||
complete the key exchange. Note that in this case the client and | complete the key exchange. Note that in this case the client and | |||
server will generate the same Diffie-Hellman result (i.e., | server will generate the same Diffie-Hellman result (i.e., | |||
pre_master_secret) every time they communicate. To prevent the | pre_master_secret) every time they communicate. To prevent the | |||
pre_master_secret from staying in memory any longer than necessary, | pre_master_secret from staying in memory any longer than necessary, | |||
it should be converted into the master_secret as soon as possible. | it should be converted into the master_secret as soon as possible. | |||
Client Diffie-Hellman parameters must be compatible with those | Client Diffie-Hellman parameters must be compatible with those | |||
supplied by the server for the key exchange to work. | supplied by the server for the key exchange to work. | |||
If the client has a standard DSS or RSA certificate or is | If the client has a standard DSA or RSA certificate or is | |||
unauthenticated, it sends a set of temporary parameters to the server | unauthenticated, it sends a set of temporary parameters to the server | |||
in the client key exchange message, then optionally uses a | in the client key exchange message, then optionally uses a | |||
certificate verify message to authenticate itself. | certificate verify message to authenticate itself. | |||
If the same DH keypair is to be used for multiple handshakes, either | If the same DH keypair is to be used for multiple handshakes, either | |||
because the client or server has a certificate containing a fixed DH | because the client or server has a certificate containing a fixed DH | |||
keypair or because the server is reusing DH keys, care must be taken | keypair or because the server is reusing DH keys, care must be taken | |||
to prevent small subgroup attacks. Implementations SHOULD follow the | to prevent small subgroup attacks. Implementations SHOULD follow the | |||
guidelines found in [SUBGROUP]. | guidelines found in [SUBGROUP]. | |||
skipping to change at page 93, line 13 ¶ | skipping to change at page 94, line 13 ¶ | |||
authentication algorithm supported, and only trustworthy | authentication algorithm supported, and only trustworthy | |||
cryptographic functions should be used. Short public keys and | cryptographic functions should be used. Short public keys and | |||
anonymous servers should be used with great caution. Implementations | anonymous servers should be used with great caution. Implementations | |||
and users must be careful when deciding which certificates and | and users must be careful when deciding which certificates and | |||
certificate authorities are acceptable; a dishonest certificate | certificate authorities are acceptable; a dishonest certificate | |||
authority can do tremendous damage. | authority can do tremendous damage. | |||
Changes in This Version | Changes in This Version | |||
[RFC Editor: Please delete this] | [RFC Editor: Please delete this] | |||
- Added a new pitfall about fragmenting messages when necessary | Clarified traffic analysis considerations | |||
[Issue #71] | ||||
- Added Updates: RFC 4492 [Issue #83] | ||||
- Long CBC padding pitfall [Issue #73] | ||||
- Fixed ProtocolVersion structure [Issue #79] | ||||
- Cleaned up extensions text [Issue #78] | ||||
- Clarified alerts some [Issue #85] | ||||
- Added AES to the table in Appendix C [Issue #72] | ||||
- Tightened up when signature_algorithms is used | ||||
(it is now a MUST if you support other than SHA-1) | ||||
and the interpretation when it is absent is also a MUST | ||||
[Issue #67] | ||||
- Cleaned up "cipher suite" so it's always two words outside | ||||
of when it refers to the syntactic type [Issue #68] | ||||
- Misc editorial. | ||||
- Added support for SHA256 cipher suites | ||||
- Clarified warning alert behavior and client certificate omission | ||||
behavior [Issue #84] | ||||
- Removed IDEA and DES entirely for documentation in a separate doc | ||||
[Issue #64] | ||||
- Changed the presentation language to allow fall-through to simplify | Added support for SHA-224 for signatures (though not for HMAC). | |||
some of the PDUs. | ||||
- Cleaned up KeyExchangeAlgorithm ClientKeyExchange to use values | Consistent use of camelback style for references to messages (e.g., | |||
that match Appendix C. | ServerHelloDone) in the text. | |||
- Changed digitally-signed to include SignatureAndHashAlgorithm | Changed "DSS" to "DSA" where we are referring to the algorithm. | |||
(another simplification) | ||||
- Considerations for RFC 4492 | Extensive editorial revisions from Alfred Hoenes. | |||
Normative References | Normative References | |||
[AES] National Institute of Standards and Technology, | [AES] National Institute of Standards and Technology, | |||
"Specification for the Advanced Encryption Standard (AES)" | "Specification for the Advanced Encryption Standard (AES)" | |||
FIPS 197. November 26, 2001. | FIPS 197. November 26, 2001. | |||
[3DES] National Institute of Standards and Technology, | [3DES] National Institute of Standards and Technology, | |||
"Recommendation for the Triple Data Encryption Algorithm | "Recommendation for the Triple Data Encryption Algorithm | |||
(TDEA) Block Cipher", NIST Special Publication 800-67, May | (TDEA) Block Cipher", NIST Special Publication 800-67, May | |||
2004. | 2004. | |||
[DES] National Institute of Standards and Technology, "Data | [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard", National | |||
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 | Institute of Standards and Technology, U.S. Department of | |||
Commerce, 2000. | Commerce, 2000. | |||
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |||
Hashing for Message Authentication", RFC 2104, February | Hashing for Message Authentication", RFC 2104, February | |||
1997. | 1997. | |||
[MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, | [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, | |||
April 1992. | April 1992. | |||
skipping to change at page 94, line 47 ¶ | skipping to change at page 95, line 10 ¶ | |||
3447, February 2003. | 3447, February 2003. | |||
[PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 | [PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 | |||
Public Key Infrastructure Certificate and Certificate | Public Key Infrastructure Certificate and Certificate | |||
Revocation List (CRL) Profile", RFC 3280, April 2002. | Revocation List (CRL) Profile", RFC 3280, April 2002. | |||
[SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms, | [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms, | |||
and Source Code in C, 2nd ed.", Published by John Wiley & | and Source Code in C, 2nd ed.", Published by John Wiley & | |||
Sons, Inc. 1996. | Sons, Inc. 1996. | |||
[SHA] NIST FIPS PUB 180-2, "Secure Hash Standard," National | [SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National | |||
Institute of Standards and Technology, U.S. Department of | Institute of Standards and Technology, U.S. Department of | |||
Commerce., August 2001. | Commerce, August 2002. | |||
[REQ] Bradner, S., "Key words for use in RFCs to Indicate | [REQ] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", BCP 25, RFC 2434, | IANA Considerations Section in RFCs", BCP 25, RFC 2434, | |||
October 1998. | October 1998. | |||
[X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, | ||||
Information technology - Abstract Syntax Notation One | ||||
(ASN.1): Specification of basic notation. | ||||
[X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, | ||||
Information technology - ASN.1 encoding Rules: Specification | ||||
of Basic Encoding Rules (BER), Canonical Encoding Rules | ||||
(CER) and Distinguished Encoding Rules (DER). | ||||
Informative References | Informative References | |||
[AEAD] Mcgrew, D., "Authenticated Encryption", July 2007, draft- | [AEAD] Mcgrew, D., "An Interface and Algorithms for Authenticated | |||
mcgrew-auth-enc-05.txt. | Encryption", RFC 5116, January 2008. | |||
[AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC | [AH] Kent, S., and Atkinson, R., "IP Authentication Header", RFC | |||
4302, December 2005. | 4302, December 2005. | |||
[BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against | [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against | |||
Protocols Based on RSA Encryption Standard PKCS #1" in | Protocols Based on RSA Encryption Standard PKCS #1" in | |||
Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: | Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, pages: | |||
1-12, 1998. | 1-12, 1998. | |||
[CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: | [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: | |||
skipping to change at page 95, line 36 ¶ | skipping to change at page 96, line 10 ¶ | |||
[CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux, | [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux, | |||
"Password Interception in a SSL/TLS Channel", Advances in | "Password Interception in a SSL/TLS Channel", Advances in | |||
Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003. | Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003. | |||
[CCM] "NIST Special Publication 800-38C: The CCM Mode for | [CCM] "NIST Special Publication 800-38C: The CCM Mode for | |||
Authentication and Confidentiality", | Authentication and Confidentiality", | |||
http://csrc.nist.gov/publications/nistpubs/800-38C/ | http://csrc.nist.gov/publications/nistpubs/800-38C/ | |||
SP800-38C.pdf | SP800-38C.pdf | |||
[DSS-3] NIST FIPS PUB 186-3 Draft, "Digital Signature Standard," | [DES] National Institute of Standards and Technology, "Data | |||
Encryption Standard (DES)", FIPS PUB 46-3, October 1999. | ||||
[DSS-3] NIST FIPS PUB 186-3 Draft, "Digital Signature Standard", | ||||
National Institute of Standards and Technology, U.S. | National Institute of Standards and Technology, U.S. | |||
Department of Commerce, 2006. | Department of Commerce, 2006. | |||
[ECSDSA] American National Standards Institute, "Public Key | ||||
Cryptography for the Financial Services Industry: The | ||||
Elliptic Curve Digital Signature Algorithm (ECDSA)", ANS | ||||
X9.62-2005, November 2005. | ||||
[ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication | [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication | |||
for Protecting Communications (Or: How Secure is SSL?)", | for Protecting Communications (Or: How Secure is SSL?)", | |||
Crypto 2001. | Crypto 2001. | |||
[ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security | [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security | |||
Payload (ESP)", RFC 4303, December 2005. | Payload (ESP)", RFC 4303, December 2005. | |||
[FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on | [FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based on | |||
implementation error", ietf-openpgp@imc.org mailing list, 27 | implementation error", ietf-openpgp@imc.org mailing list, 27 | |||
August 2006, http://www.imc.org/ietf-openpgp/mail- | August 2006, http://www.imc.org/ietf-openpgp/mail- | |||
skipping to change at page 96, line 26 ¶ | skipping to change at page 97, line 6 ¶ | |||
[KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based | [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based | |||
Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, | Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, | |||
March 2003. | March 2003. | |||
[MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) | [MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) | |||
Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC | Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC | |||
3526, May 2003. | 3526, May 2003. | |||
[PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax | [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate Syntax | |||
Standard," version 1.5, November 1993. | Standard", version 1.5, November 1993. | |||
[PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax | [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message Syntax | |||
Standard," version 1.5, November 1993. | Standard", version 1.5, November 1993. | |||
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness | [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness | |||
Requirements for Security", BCP 106, RFC 4086, June 2005. | Requirements for Security", BCP 106, RFC 4086, June 2005. | |||
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol | [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol | |||
Compression Methods", RFC 3749, May 2004. | Compression Methods", RFC 3749, May 2004. | |||
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., | [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., | |||
Wright, T., "Transport Layer Security (TLS) Extensions", RFC | Wright, T., "Transport Layer Security (TLS) Extensions", RFC | |||
4366, April 2006. | 4366, April 2006. | |||
[RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for | [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for | |||
Obtaining Digital Signatures and Public-Key Cryptosystems," | Obtaining Digital Signatures and Public-Key Cryptosystems", | |||
Communications of the ACM, v. 21, n. 2, Feb 1978, pp. | Communications of the ACM, v. 21, n. 2, Feb 1978, pp. | |||
120-126. | 120-126. | |||
[SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks", | [SEQNUM] Bellovin. S., "Defending Against Sequence Number Attacks", | |||
RFC 1948, May 1996. | RFC 1948, May 1996. | |||
[SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications | [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications | |||
Corp., Feb 9, 1995. | Corp., Feb 9, 1995. | |||
[SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0 | [SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0 | |||
Protocol", Netscape Communications Corp., Nov 18, 1996. | Protocol", Netscape Communications Corp., Nov 18, 1996. | |||
[SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" | [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" | |||
Attacks on the Diffie-Hellman Key Agreement Method for | Attacks on the Diffie-Hellman Key Agreement Method for | |||
S/MIME", RFC 2785, March 2000. | S/MIME", RFC 2785, March 2000. | |||
[TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, | [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, | |||
September 1981. | September 1981. | |||
[TIMING] Boneh, D., Brumley, D., "Remote timing attacks are | [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are | |||
practical", USENIX Security Symposium 2003. | practical", USENIX Security Symposium 2003. | |||
[TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites | [TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites | |||
for Transport Layer Security (TLS)", RFC 3268, June 2002. | for Transport Layer Security (TLS)", RFC 3268, June 2002. | |||
[TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and | [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and | |||
Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher | Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher | |||
skipping to change at page 97, line 43 ¶ | skipping to change at page 98, line 24 ¶ | |||
[TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0", | [TLS1.0] Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0", | |||
RFC 2246, January 1999. | RFC 2246, January 1999. | |||
[TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version | [TLS1.1] Dierks, T., and E. Rescorla, "The TLS Protocol, Version | |||
1.1", RFC 4346, April, 2006. | 1.1", RFC 4346, April, 2006. | |||
[X501] ITU-T Recommendation X.501: Information Technology - Open | [X501] ITU-T Recommendation X.501: Information Technology - Open | |||
Systems Interconnection - The Directory: Models, 1993. | Systems Interconnection - The Directory: Models, 1993. | |||
[XDR] Eisler, M., "External Data Representation Standard", RFC | [XDR] Eisler, M., "External Data Representation Standard", STD 67, | |||
4506, May 2006. | RFC 4506, May 2006. | |||
Credits | Credits | |||
Working Group Chairs | Working Group Chairs | |||
Eric Rescorla | Eric Rescorla | |||
EMail: ekr@networkresonance.com | EMail: ekr@networkresonance.com | |||
Pasi Eronen | Pasi Eronen | |||
pasi.eronen@nokia.com | pasi.eronen@nokia.com | |||
End of changes. 154 change blocks. | ||||
412 lines changed or deleted | 427 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |