6.2 TLS Protocol


6.2    TLS Protocol

Early in 1996, the IETF chartered a TLSWGwithin the security and transport areas. The objective of the IETF TLSWGwas to write Internet standards track RFCs for a TLS protocol using the currently available specifications of SSL (2.0 and 3.0), PCT (1.0), and SSH version 2 as a basis. [16]

Shortly before the IETF meeting in December 1996, a first TLS 1.0 document was released as an Internet-Draft. The document was essentially the same as the SSL 3.0 specification. In fact, it was the explicit strategy of the IETF TLS WG to have the TLS 1.0 specification be based on SSL 3.0, as opposed to SSL 2.0, PCT 1.0, SSH version 2, or any other transport layer security protocol proposal. At least three major modifications were suggested for SSL 3.0 to be incorporated into TLS 1.0:

  1. The HMAC construction developed in the IETF IPsec WG should be adopted and consistently used in TLS 1.0.

  2. The FORTEZZA token-based KEA should be removed from TLS 1.0, since it refers to a proprietary and unpublished technology. Instead, a DSS-based key exchange mechanism should be included in TLS 1.0.

  3. The TLS Record Protocol and the TLS Handshake Protocol should be separated out and specified more clearly in related documents.

After having adopted these modifications, the resulting TLS protocol was specified in a series of Internet-Drafts. In January 1999, the TLS protocol version 1.0 was specified in RFC 2246 [12] and submitted to the Internet standards track (as a Proposed Standard). The differences between TLS 1.0 and SSL 3.0 are not huge, but they are significant enough that TLS 1.0 and SSL 3.0 do not easily interoperate . Nevertheless, TLS 1.0 does incorporate a mechanism by which a TLS implementation can back down to SSL 3.0.

Similar to the SSL protocol, the TLS protocol is a layered protocol that consists of a TLS Record Protocol and several TLS subprotocols layered on top of it:

  • On the lower layer, the TLS Record Protocol takes messages to be transmitted, fragments them into manageable data blocks (so-called TLS records), optionally compresses them, computes and appends a MAC to each record, encrypts the result, and transmits it. Again, similar to SSL, the resulting records are called TLSPlaintext, TLSCompressed, and TLSCiphertext. A received TLSCiphertext record, in turn , is decrypted, verified , decompressed, and reassembled before it is delivered to the appropriate application protocol. A TLS connection state is the operating environment of the TLS Record Protocol. It specifies compression, encryption, and message authentication algorithms, and determines parameters for these algorithms, such as encryption and MAC keys and IVs for a connection in both the read and write directions. There are always four connection states in memory: the current read and write states and the pending read and write states. All records are processed under the current read and write states. The security parameters for the pending states are set by the TLS Handshake Protocol, and the handshake protocol selectively makes either of the pending states current, in which case the appropriate current state is disposed of and replaced with the pending state; the pending state is then reinitialized to an empty state.

  • On the higher layer, there are several TLS subprotocols layered on top of the TLS Record Protocol. For example, the TLS Handshake Protocol is used to negotiate session and connection information elements that comprise a session identifier, a peer certificate, a compression method, a cipher spec, a master key, and a flag whether the session is resumable and can be used to initiate new connections. These items are used to create security parameters for use by the TLS Record Protocol when protecting application data. In addition, there are a TLS Change Cipher Spec Protocol and a TLS Alert Protocol . Both are similar to the corresponding SSL protocols (and are not further addressed in this book).

After a TLS handshake has been performed, the client and server can exchange application data messages. These messages are carried by the TLS Record Protocol and fragmented , compressed, authenticated, and encrypted accordingly . The messages are treated as transparent data to the TLS record layer.

The cipher suites that are specified for TLS 1.0 are summarized in Table 6.4. [17] The key exchange and encryption mechanisms, as well as the one-way hash function that are used in a particular cipher suite, are all encoded in its name . For example, the cipher suite TLS RSA WITH RC4 128 MD5 uses RSA public key encryption for key exchange, RC4 with 128 bit session keys for encryption, and MD5 for computing one-way hash function results. Similarly, the cipher suite TLS DH DSS WITH 3DES EDE CBC SHA uses the Diffie-Hellman key exchange algorithm (DH) for key exchange, the digital signature standard (DSS) to compute and verify digital signatures, Triple-DES in CBC mode for encryption, and SHA-1 for computing one-way hash function results. Consequently, a TLS cipher suite is always named TLS X WITH Y Z, where X refers to the key exchange algorithm, Y to the encryption algorithm, and Z to the one-way hash function that is being used.

Table 6.4: TLS 1.0 Cipher Suites As Specified in [12]

Cipher Suite

TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_WITH_IDEA_CBC_SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_WITH_DES_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_WITH_DES_CBC_SHA
TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_RSA_WITH_DES_CBC_SHA
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_WITH_DES_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_WITH_DES_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

The key exchange and encryption algorithms, as well as the one-way hash functions that are specified in TLS 1.0, are itemized and further explained in Tables 6.5 to 6.7. In Table 6.6, the type of a cipher indicates whether it is a stream cipher or a block cipher running in CBC mode. Similarly, the key length indicates the number of bytes that are used for generating the encryption keys, whereas the expanded key length indicates the number of bytes actually fed into the encryption algorithm. Finally, the effective key bits measure how much entropy is in the key material being fed into the encryption routine, and the IV size measures how much data needs to be generated for the IV. All numbers except the effective key size are given in bytes (i.e., 8 bits).

Table 6.5: TLS 1.0 Key Exchange Algorithms As Specified in [12]

Key Exchange Algorithm

Description

Key Size Limit

DHE_DSS

Ephemeral DH with DSS signatures

None

DHE_DSS_EXPORT

Ephemeral DH with DSS signatures

DH = 512 bits

DHE_RSA

Ephemeral DH with RSA signatures

None

DHE_RSA_EXPORT

Ephemeral DH with RSA signatures

DH = 512 bits

DH_anon

Anonymous DH, no signatures

None

DH_anon_EXPORT

Anonymous DH, no signatures

DH = 512 bits

DH_DSS

DH with DSS-based certificates

None

DH_DSS_EXPORT

DH with DSS-based certificates

DH = 512 bits

DH_RSA

DH with RSA-based certificates

None

DH_RSA_EXPORT

DH with RSA-based certificates

DH = 512 bits

NULL

No key exchange

N/A

RSA

RSA key exchange

None

RSA_EXPORT

RSA key exchange

RSA = 512 bits

Table 6.6: TLS 1.0 Encryption Algorithms As Specified in [12]

Cipher

Type

Key Length

Expanded Key Length

Effective Key Size [bits]

IV Size

Block Size

NULL

Stream

N/A

IDEA_CBC

Block

16

16

128

8

8

RC2_CBC_40

Block

5

16

40

8

8

RC4_40

Stream

5

16

40

N/A

RC4_128

Stream

16

16

128

N/A

DES40_CBC

Block

5

8

40

8

8

DES_CBC

Block

8

8

56

8

8

3DES_EDE_CBC

Block

24

24

168

8

8

Table 6.7: TLS 1.0 One-Way Hash Functions As Specified in [13]

Hash Function

Hash Size

Padding Size

NULL

MD5

16

48

SHA

20

40

TLS 1.0 as specified in RFC 2246 [12] was submitted to the IESG for consideration as a Proposed Standard for the Internet in January 1999. Meanwhile, two other standards track RFC documents and have been officially released by the IETF TLS WG:

  • RFC 2712 specifies the addition of Kerberos Cipher Suites to TLS [14].

  • RFC 2817 specifies how to upgrade to TLS Within HTTP/1.1 [15].

In addition, an informational RFC document specifies the use of HTTP over TLS (i.e., HTTPS) [16]. Finally, there are various Internet-Drafts specifying specific issues related to TLS or the use of TLS to secure TCP-based application protocols. Refer to the home page of the IETF TLS WG for an overview about the most recent developments and achievements.

[16] http://www. stunnel .org

[17] Note that at this point in time the SSH protocol had been investigated by the IETF TLS WG, and that the IETF later chartered a SECSH WG to update and standardize the SSH protocol independently of the TLS protocol. The SSH protocol is overviewed and discussed in Chapter 16.




Security Technologies for the World Wide Web
Security Technologies for the World Wide Web, Second Edition
ISBN: 1580533485
EAN: 2147483647
Year: 2003
Pages: 142
Authors: Rolf Oppliger

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net