Tech-invite3GPPspecsSIPRFCs
898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100

in Index   Prev   Next

RFC 5246

The Transport Layer Security (TLS) Protocol Version 1.2

Pages: 104
Obsoletes:  326843464366
Obsoleted by:  8446
Updates:  4492
Updated by:  57465878617674657507756876277685790579198447
Part 4 of 5 – Pages 64 to 84
First   Prev   Next

ToP   noToC   RFC5246 - Page 64   prevText

8. Cryptographic Computations

In order to begin connection protection, the TLS Record Protocol requires specification of a suite of algorithms, a master secret, and the client and server random values. The authentication, encryption, and MAC algorithms are determined by the cipher_suite selected by the server and revealed in the ServerHello message. The compression algorithm is negotiated in the hello messages, and the random values are exchanged in the hello messages. All that remains is to calculate the master secret.

8.1. Computing the Master Secret

For all key exchange methods, the same algorithm is used to convert the pre_master_secret into the master_secret. The pre_master_secret should be deleted from memory once the master_secret has been computed. master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47]; The master secret is always exactly 48 bytes in length. The length of the premaster secret will vary depending on key exchange method.
ToP   noToC   RFC5246 - Page 65

8.1.1. RSA

When RSA is used for server authentication and key exchange, a 48- byte pre_master_secret is generated by the client, encrypted under the server's public key, and sent to the server. The server uses its private key to decrypt the pre_master_secret. Both parties then convert the pre_master_secret into the master_secret, as specified above.

8.1.2. Diffie-Hellman

A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above. Leading bytes of Z that contain all zero bits are stripped before it is used as the pre_master_secret. Note: Diffie-Hellman parameters are specified by the server and may be either ephemeral or contained within the server's certificate.

9. Mandatory Cipher Suites

In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition).

10. Application Data Protocol

Application data messages are carried by the record layer and are fragmented, compressed, and encrypted based on the current connection state. The messages are treated as transparent data to the record layer.

11. Security Considerations

Security issues are discussed throughout this memo, especially in Appendices D, E, and F.

12. IANA Considerations

This document uses several registries that were originally created in [TLS1.1]. IANA has updated these to reference this document. The registries and their allocation policies (unchanged from [TLS1.1]) are listed below.
ToP   noToC   RFC5246 - Page 66
   -  TLS ClientCertificateType Identifiers Registry: Future values in
      the range 0-63 (decimal) inclusive are assigned via Standards
      Action [RFC2434].  Values in the range 64-223 (decimal) inclusive
      are assigned via Specification Required [RFC2434].  Values from
      224-255 (decimal) inclusive are reserved for Private Use
      [RFC2434].

   -  TLS Cipher Suite Registry: Future values with the first byte in
      the range 0-191 (decimal) inclusive are assigned via Standards
      Action [RFC2434].  Values with the first byte in the range 192-254
      (decimal) are assigned via Specification Required [RFC2434].
      Values with the first byte 255 (decimal) are reserved for Private
      Use [RFC2434].

   -  This document defines several new HMAC-SHA256-based cipher suites,
      whose values (in Appendix A.5) have been allocated from the TLS
      Cipher Suite registry.

   -  TLS ContentType Registry: Future values are allocated via
      Standards Action [RFC2434].

   -  TLS Alert Registry: Future values are allocated via Standards
      Action [RFC2434].

   -  TLS HandshakeType Registry: Future values are allocated via
      Standards Action [RFC2434].

   This document also uses a registry originally created in [RFC4366].
   IANA has updated it to reference this document.  The registry and its
   allocation policy (unchanged from [RFC4366]) is listed below:

   -  TLS ExtensionType Registry: Future values are allocated via IETF
      Consensus [RFC2434].  IANA has updated this registry to include
      the signature_algorithms extension and its corresponding value
      (see Section 7.4.1.4).

   In addition, this document defines two new registries to be
   maintained by IANA:

   -  TLS SignatureAlgorithm Registry: The registry has been initially
      populated with the values described in Section 7.4.1.4.1.  Future
      values in the range 0-63 (decimal) inclusive are assigned via
      Standards Action [RFC2434].  Values in the range 64-223 (decimal)
      inclusive are assigned via Specification Required [RFC2434].
      Values from 224-255 (decimal) inclusive are reserved for Private
      Use [RFC2434].
ToP   noToC   RFC5246 - Page 67
   -  TLS HashAlgorithm Registry: The registry has been initially
      populated with the values described in Section 7.4.1.4.1.  Future
      values in the range 0-63 (decimal) inclusive are assigned via
      Standards Action [RFC2434].  Values in the range 64-223 (decimal)
      inclusive are assigned via Specification Required [RFC2434].
      Values from 224-255 (decimal) inclusive are reserved for Private
      Use [RFC2434].

      This document also uses the TLS Compression Method Identifiers
      Registry, defined in [RFC3749].  IANA has allocated value 0 for
      the "null" compression method.
ToP   noToC   RFC5246 - Page 68

Appendix A. Protocol Data Structures and Constant Values

This section describes protocol types and constants.

A.1. Record Layer

struct { uint8 major; uint8 minor; } ProtocolVersion; ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/ enum { change_cipher_spec(20), alert(21), handshake(22), application_data(23), (255) } ContentType; struct { ContentType type; ProtocolVersion version; uint16 length; opaque fragment[TLSPlaintext.length]; } TLSPlaintext; struct { ContentType type; ProtocolVersion version; uint16 length; opaque fragment[TLSCompressed.length]; } TLSCompressed; struct { ContentType type; ProtocolVersion version; uint16 length; select (SecurityParameters.cipher_type) { case stream: GenericStreamCipher; case block: GenericBlockCipher; case aead: GenericAEADCipher; } fragment; } TLSCiphertext; stream-ciphered struct { opaque content[TLSCompressed.length]; opaque MAC[SecurityParameters.mac_length]; } GenericStreamCipher;
ToP   noToC   RFC5246 - Page 69
   struct {
       opaque IV[SecurityParameters.record_iv_length];
       block-ciphered struct {
           opaque content[TLSCompressed.length];
           opaque MAC[SecurityParameters.mac_length];
           uint8 padding[GenericBlockCipher.padding_length];
           uint8 padding_length;
       };
   } GenericBlockCipher;

   struct {
      opaque nonce_explicit[SecurityParameters.record_iv_length];
      aead-ciphered struct {
          opaque content[TLSCompressed.length];
      };
   } GenericAEADCipher;

A.2. Change Cipher Specs Message

struct { enum { change_cipher_spec(1), (255) } type; } ChangeCipherSpec;

A.3. Alert Messages

enum { warning(1), fatal(2), (255) } AlertLevel; enum { close_notify(0), unexpected_message(10), bad_record_mac(20), decryption_failed_RESERVED(21), record_overflow(22), decompression_failure(30), handshake_failure(40), no_certificate_RESERVED(41), bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(45), certificate_unknown(46), illegal_parameter(47), unknown_ca(48), access_denied(49), decode_error(50), decrypt_error(51), export_restriction_RESERVED(60), protocol_version(70),
ToP   noToC   RFC5246 - Page 70
       insufficient_security(71),
       internal_error(80),
       user_canceled(90),
       no_renegotiation(100),
       unsupported_extension(110),           /* new */
       (255)
   } AlertDescription;

   struct {
       AlertLevel level;
       AlertDescription description;
   } Alert;

A.4. Handshake Protocol

enum { hello_request(0), client_hello(1), server_hello(2), certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20) (255) } HandshakeType; struct { HandshakeType msg_type; uint24 length; select (HandshakeType) { case hello_request: HelloRequest; case client_hello: ClientHello; case server_hello: ServerHello; case certificate: Certificate; case server_key_exchange: ServerKeyExchange; case certificate_request: CertificateRequest; case server_hello_done: ServerHelloDone; case certificate_verify: CertificateVerify; case client_key_exchange: ClientKeyExchange; case finished: Finished; } body; } Handshake;
ToP   noToC   RFC5246 - Page 71

A.4.1. Hello Messages

struct { } HelloRequest; struct { uint32 gmt_unix_time; opaque random_bytes[28]; } Random; opaque SessionID<0..32>; uint8 CipherSuite[2]; enum { null(0), (255) } CompressionMethod; struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-2>; CompressionMethod compression_methods<1..2^8-1>; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ClientHello; struct { ProtocolVersion server_version; Random random; SessionID session_id; CipherSuite cipher_suite; CompressionMethod compression_method; select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; } ServerHello; struct { ExtensionType extension_type; opaque extension_data<0..2^16-1>; } Extension;
ToP   noToC   RFC5246 - Page 72
   enum {
       signature_algorithms(13), (65535)
   } ExtensionType;

   enum{
       none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5),
       sha512(6), (255)
   } HashAlgorithm;
   enum {
      anonymous(0), rsa(1), dsa(2), ecdsa(3), (255)
   } SignatureAlgorithm;

   struct {
         HashAlgorithm hash;
         SignatureAlgorithm signature;
   } SignatureAndHashAlgorithm;

   SignatureAndHashAlgorithm
    supported_signature_algorithms<2..2^16-1>;

A.4.2. Server Authentication and Key Exchange Messages

opaque ASN.1Cert<2^24-1>; struct { ASN.1Cert certificate_list<0..2^24-1>; } Certificate; enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa /* may be extended, e.g., for ECDH -- see [TLSECC] */ } KeyExchangeAlgorithm; struct { opaque dh_p<1..2^16-1>; opaque dh_g<1..2^16-1>; opaque dh_Ys<1..2^16-1>; } ServerDHParams; /* Ephemeral DH parameters */
ToP   noToC   RFC5246 - Page 73
   struct {
       select (KeyExchangeAlgorithm) {
           case dh_anon:
               ServerDHParams params;
           case dhe_dss:
           case dhe_rsa:
               ServerDHParams params;
               digitally-signed struct {
                   opaque client_random[32];
                   opaque server_random[32];
                   ServerDHParams params;
               } signed_params;
           case rsa:
           case dh_dss:
           case dh_rsa:
               struct {} ;
              /* message is omitted for rsa, dh_dss, and dh_rsa */
           /* may be extended, e.g., for ECDH -- see [TLSECC] */
   } ServerKeyExchange;

   enum {
       rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
       rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
       fortezza_dms_RESERVED(20),
       (255)
   } ClientCertificateType;

   opaque DistinguishedName<1..2^16-1>;

   struct {
       ClientCertificateType certificate_types<1..2^8-1>;
       DistinguishedName certificate_authorities<0..2^16-1>;
   } CertificateRequest;

   struct { } ServerHelloDone;
ToP   noToC   RFC5246 - Page 74

A.4.3. Client Authentication and Key Exchange Messages

struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret; case dhe_dss: case dhe_rsa: case dh_dss: case dh_rsa: case dh_anon: ClientDiffieHellmanPublic; } exchange_keys; } ClientKeyExchange; struct { ProtocolVersion client_version; opaque random[46]; } PreMasterSecret; struct { public-key-encrypted PreMasterSecret pre_master_secret; } EncryptedPreMasterSecret; enum { implicit, explicit } PublicValueEncoding; struct { select (PublicValueEncoding) { case implicit: struct {}; case explicit: opaque DH_Yc<1..2^16-1>; } dh_public; } ClientDiffieHellmanPublic; struct { digitally-signed struct { opaque handshake_messages[handshake_messages_length]; } } CertificateVerify;

A.4.4. Handshake Finalization Message

struct { opaque verify_data[verify_data_length]; } Finished;
ToP   noToC   RFC5246 - Page 75

A.5. The Cipher Suite

The following values define the cipher suite codes used in the ClientHello and ServerHello messages. A cipher suite defines a cipher specification supported in TLS Version 1.2. TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a TLS connection during the first handshake on that channel, but MUST NOT be negotiated, as it provides no more protection than an unsecured connection. CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; The following CipherSuite definitions require that the server provide an RSA certificate that can be used for key exchange. The server may request any signature-capable certificate in the certificate request message. CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; CipherSuite TLS_RSA_WITH_NULL_SHA256 = { 0x00,0x3B }; CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F }; CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 }; CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3C }; CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D }; The following cipher suite definitions are used for server- authenticated (and optionally client-authenticated) Diffie-Hellman. DH denotes cipher suites in which the server's certificate contains the Diffie-Hellman parameters signed by the certificate authority (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman parameters are signed by a signature-capable certificate, which has been signed by the CA. The signing algorithm used by the server is specified after the DHE component of the CipherSuite name. The server can request any signature-capable certificate from the client for client authentication, or it may request a Diffie-Hellman certificate. Any Diffie-Hellman certificate provided by the client must use the parameters (group and generator) described by the server.
ToP   noToC   RFC5246 - Page 76
      CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA      = { 0x00,0x0D };
      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_RSA_WITH_3DES_EDE_CBC_SHA     = { 0x00,0x16 };
      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA       = { 0x00,0x30 };
      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA       = { 0x00,0x31 };
      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA      = { 0x00,0x32 };
      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA      = { 0x00,0x33 };
      CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA       = { 0x00,0x36 };
      CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA       = { 0x00,0x37 };
      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA      = { 0x00,0x38 };
      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA      = { 0x00,0x39 };
      CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256    = { 0x00,0x3E };
      CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256    = { 0x00,0x3F };
      CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256   = { 0x00,0x40 };
      CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256   = { 0x00,0x67 };
      CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256    = { 0x00,0x68 };
      CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256    = { 0x00,0x69 };
      CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256   = { 0x00,0x6A };
      CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256   = { 0x00,0x6B };

   The following cipher suites are used for completely anonymous
   Diffie-Hellman communications in which neither party is
   authenticated.  Note that this mode is vulnerable to man-in-the-
   middle attacks.  Using this mode therefore is of limited use: These
   cipher suites MUST NOT be used by TLS 1.2 implementations unless the
   application layer has specifically requested to allow anonymous key
   exchange.  (Anonymous key exchange may sometimes be acceptable, for
   example, to support opportunistic encryption when no set-up for
   authentication is in place, or when TLS is used as part of more
   complex security protocols that have other means to ensure
   authentication.)

      CipherSuite TLS_DH_anon_WITH_RC4_128_MD5          = { 0x00,0x18 };
      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_256_CBC_SHA      = { 0x00,0x3A };
      CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256   = { 0x00,0x6C };
      CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256   = { 0x00,0x6D };

   Note that using non-anonymous key exchange without actually verifying
   the key exchange is essentially equivalent to anonymous key exchange,
   and the same precautions apply.  While non-anonymous key exchange
   will generally involve a higher computational and communicational
   cost than anonymous key exchange, it may be in the interest of
   interoperability not to disable non-anonymous key exchange when the
   application layer is allowing anonymous key exchange.
ToP   noToC   RFC5246 - Page 77
   New cipher suite values have been assigned by IANA as described in
   Section 12.

   Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are
   reserved to avoid collision with Fortezza-based cipher suites in
   SSL 3.

A.6. The Security Parameters

These security parameters are determined by the TLS Handshake Protocol and provided as parameters to the TLS record layer in order to initialize a connection state. SecurityParameters includes: enum { null(0), (255) } CompressionMethod; enum { server, client } ConnectionEnd; enum { tls_prf_sha256 } PRFAlgorithm; enum { null, rc4, 3des, aes } BulkCipherAlgorithm; enum { stream, block, aead } CipherType; enum { null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384, hmac_sha512} MACAlgorithm; /* Other values may be added to the algorithms specified in CompressionMethod, PRFAlgorithm, BulkCipherAlgorithm, and MACAlgorithm. */ struct { ConnectionEnd entity; PRFAlgorithm prf_algorithm; BulkCipherAlgorithm bulk_cipher_algorithm; CipherType cipher_type; uint8 enc_key_length; uint8 block_length; uint8 fixed_iv_length; uint8 record_iv_length; MACAlgorithm mac_algorithm; uint8 mac_length; uint8 mac_key_length; CompressionMethod compression_algorithm; opaque master_secret[48]; opaque client_random[32]; opaque server_random[32]; } SecurityParameters;
ToP   noToC   RFC5246 - Page 78

A.7. Changes to RFC 4492

RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This document changes some of the structures used in that document. This section details the required changes for implementors of both RFC 4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing RFC 4492 do not need to read this section. This document adds a "signature_algorithm" field to the digitally- signed element in order to identify the signature and digest algorithms used to create a signature. This change applies to digital signatures formed using ECDSA as well, thus allowing ECDSA signatures to be used with digest algorithms other than SHA-1, provided such use is compatible with the certificate and any restrictions imposed by future revisions of [PKIX]. 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 the cipher suite (when used by the server) or the ClientCertificateType (when used by the client). Thus, the restrictions on the algorithm used to sign certificates specified in 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.

Appendix B. Glossary

Advanced Encryption Standard (AES) AES [AES] is a widely used symmetric encryption algorithm. AES is a block cipher with a 128-, 192-, or 256-bit keys and a 16-byte block size. TLS currently only supports the 128- and 256-bit key sizes. application protocol An application protocol is a protocol that normally layers directly on top of the transport layer (e.g., TCP/IP). Examples include HTTP, TELNET, FTP, and SMTP. asymmetric cipher See public key cryptography. authenticated encryption with additional data (AEAD) A symmetric encryption algorithm that simultaneously provides confidentiality and message integrity. authentication Authentication is the ability of one entity to determine the identity of another entity.
ToP   noToC   RFC5246 - Page 79
   block cipher
      A block cipher is an algorithm that operates on plaintext in
      groups of bits, called blocks.  64 bits was, and 128 bits is, a
      common block size.

   bulk cipher
      A symmetric encryption algorithm used to encrypt large quantities
      of data.

   cipher block chaining (CBC)
      CBC is a mode in which every plaintext block encrypted with a
      block cipher is first exclusive-ORed with the previous ciphertext
      block (or, in the case of the first block, with the initialization
      vector).  For decryption, every block is first decrypted, then
      exclusive-ORed with the previous ciphertext block (or IV).

   certificate
      As part of the X.509 protocol (a.k.a. ISO Authentication
      framework), certificates are assigned by a trusted Certificate
      Authority and provide a strong binding between a party's identity
      or some other attributes and its public key.

   client
      The application entity that initiates a TLS connection to a
      server.  This may or may not imply that the client initiated the
      underlying transport connection.  The primary operational
      difference between the server and client is that the server is
      generally authenticated, while the client is only optionally
      authenticated.

   client write key
      The key used to encrypt data written by the client.

   client write MAC key
      The secret data used to authenticate data written by the client.

   connection
      A connection is a transport (in the OSI layering model definition)
      that provides a suitable type of service.  For TLS, such
      connections are peer-to-peer relationships.  The connections are
      transient.  Every connection is associated with one session.

   Data Encryption Standard
      DES [DES] still is a very widely used symmetric encryption
      algorithm although it is considered as rather weak now.  DES is a
      block cipher with a 56-bit key and an 8-byte block size.  Note
      that in TLS, for key generation purposes, DES is treated as having
      an 8-byte key length (64 bits), but it still only provides 56 bits
ToP   noToC   RFC5246 - Page 80
      of protection.  (The low bit of each key byte is presumed to be
      set to produce odd parity in that key byte.)  DES can also be
      operated in a mode [3DES] where three independent keys and three
      encryptions are used for each block of data; this uses 168 bits of
      key (24 bytes in the TLS key generation method) and provides the
      equivalent of 112 bits of security.

   Digital Signature Standard (DSS)
      A standard for digital signing, including the Digital Signing
      Algorithm, approved by the National Institute of Standards and
      Technology, defined in NIST FIPS PUB 186-2, "Digital Signature
      Standard", published January 2000 by the U.S. Department of
      Commerce [DSS].  A significant update [DSS-3] has been drafted and
      was published in March 2006.

   digital signatures
      Digital signatures utilize public key cryptography and one-way
      hash functions to produce a signature of the data that can be
      authenticated, and is difficult to forge or repudiate.

   handshake An initial negotiation between client and server that
      establishes the parameters of their transactions.

   Initialization Vector (IV)
      When a block cipher is used in CBC mode, the initialization vector
      is exclusive-ORed with the first plaintext block prior to
      encryption.

   Message Authentication Code (MAC)
      A Message Authentication Code is a one-way hash computed from a
      message and some secret data.  It is difficult to forge without
      knowing the secret data.  Its purpose is to detect if the message
      has been altered.

   master secret
      Secure secret data used for generating encryption keys, MAC
      secrets, and IVs.

   MD5
      MD5 [MD5] is a hashing function that converts an arbitrarily long
      data stream into a hash of fixed size (16 bytes).  Due to
      significant progress in cryptanalysis, at the time of publication
      of this document, MD5 no longer can be considered a 'secure'
      hashing function.
ToP   noToC   RFC5246 - Page 81
   public key cryptography
      A class of cryptographic techniques employing two-key ciphers.
      Messages encrypted with the public key can only be decrypted with
      the associated private key.  Conversely, messages signed with the
      private key can be verified with the public key.

   one-way hash function
      A one-way transformation that converts an arbitrary amount of data
      into a fixed-length hash.  It is computationally hard to reverse
      the transformation or to find collisions.  MD5 and SHA are
      examples of one-way hash functions.

   RC4
      A stream cipher invented by Ron Rivest.  A compatible cipher is
      described in [SCH].

   RSA
      A very widely used public key algorithm that can be used for
      either encryption or digital signing.  [RSA]

   server
      The server is the application entity that responds to requests for
      connections from clients.  See also "client".

   session
      A TLS session is an association between a client and a server.
      Sessions are created by the handshake protocol.  Sessions define a
      set of cryptographic security parameters that can be shared among
      multiple connections.  Sessions are used to avoid the expensive
      negotiation of new security parameters for each connection.

   session identifier
      A session identifier is a value generated by a server that
      identifies a particular session.

   server write key
      The key used to encrypt data written by the server.

   server write MAC key
      The secret data used to authenticate data written by the server.

   SHA
      The Secure Hash Algorithm [SHS] is defined in FIPS PUB 180-2.  It
      produces a 20-byte output.  Note that all references to SHA
      (without a numerical suffix) actually use the modified SHA-1
      algorithm.
ToP   noToC   RFC5246 - Page 82
   SHA-256
      The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2.
      It produces a 32-byte output.

   SSL
      Netscape's Secure Socket Layer protocol [SSL3].  TLS is based on
      SSL Version 3.0.

   stream cipher
      An encryption algorithm that converts a key into a
      cryptographically strong keystream, which is then exclusive-ORed
      with the plaintext.

   symmetric cipher
      See bulk cipher.

   Transport Layer Security (TLS)
      This protocol; also, the Transport Layer Security working group of
      the Internet Engineering Task Force (IETF).  See "Working Group
      Information" at the end of this document (see page 99).
ToP   noToC   RFC5246 - Page 83

Appendix C. Cipher Suite Definitions

Cipher Suite Key Cipher Mac Exchange TLS_NULL_WITH_NULL_NULL NULL NULL NULL TLS_RSA_WITH_NULL_MD5 RSA NULL MD5 TLS_RSA_WITH_NULL_SHA RSA NULL SHA TLS_RSA_WITH_NULL_SHA256 RSA NULL SHA256 TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA TLS_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA TLS_RSA_WITH_AES_128_CBC_SHA256 RSA AES_128_CBC SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 RSA AES_256_CBC SHA256 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA TLS_DH_DSS_WITH_AES_128_CBC_SHA256 DH_DSS 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_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_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_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_DH_anon_WITH_AES_256_CBC_SHA256 DH_anon AES_256_CBC SHA256
ToP   noToC   RFC5246 - Page 84
                        Key      IV   Block
Cipher        Type    Material  Size  Size
------------  ------  --------  ----  -----
NULL          Stream      0       0    N/A
RC4_128       Stream     16       0    N/A
3DES_EDE_CBC  Block      24       8      8
AES_128_CBC   Block      16      16     16
AES_256_CBC   Block      32      16     16


MAC       Algorithm    mac_length  mac_key_length
--------  -----------  ----------  --------------
NULL      N/A              0             0
MD5       HMAC-MD5        16            16
SHA       HMAC-SHA1       20            20
SHA256    HMAC-SHA256     32            32

   Type
      Indicates whether this is a stream cipher or a block cipher
      running in CBC mode.

   Key Material
      The number of bytes from the key_block that are used for
      generating the write keys.

   IV Size
      The amount of data needed to be generated for the initialization
      vector.  Zero for stream ciphers; equal to the block size for
      block ciphers (this is equal to
      SecurityParameters.record_iv_length).

   Block Size
      The amount of data a block cipher enciphers in one chunk; a block
      cipher running in CBC mode can only encrypt an even multiple of
      its block size.


(next page on part 5)

Next Section