rfc2246.txt

RFC 的详细文档！

Dierks & Allen              Standards Track                    [Page 17]

RFC 2246              The TLS Protocol Version 1.0          January 1999


   Compression must be lossless and may not increase the content length
   by more than 1024 bytes. If the decompression function encounters a
   TLSCompressed.fragment that would decompress to a length in excess of
   2^14 bytes, it should report a fatal decompression failure error.

       struct {
           ContentType type;       /* same as TLSPlaintext.type */
           ProtocolVersion version;/* same as TLSPlaintext.version */
           uint16 length;
           opaque fragment[TLSCompressed.length];
       } TLSCompressed;

   length
       The length (in bytes) of the following TLSCompressed.fragment.
       The length should not exceed 2^14 + 1024.

   fragment
       The compressed form of TLSPlaintext.fragment.

 Note: A CompressionMethod.null operation is an identity operation; no
       fields are altered.

   Implementation note:
       Decompression functions are responsible for ensuring that
       messages cannot cause internal buffer overflows.

6.2.3. Record payload protection

   The encryption and MAC functions translate a TLSCompressed structure
   into a TLSCiphertext. The decryption functions reverse the process.
   The MAC of the record also includes a sequence number so that
   missing, extra or repeated messages are detectable.

       struct {
           ContentType type;
           ProtocolVersion version;
           uint16 length;
           select (CipherSpec.cipher_type) {
               case stream: GenericStreamCipher;
               case block: GenericBlockCipher;
           } fragment;
       } TLSCiphertext;

   type
       The type field is identical to TLSCompressed.type.

   version
       The version field is identical to TLSCompressed.version.



Dierks & Allen              Standards Track                    [Page 18]

RFC 2246              The TLS Protocol Version 1.0          January 1999


   length
       The length (in bytes) of the following TLSCiphertext.fragment.
       The length may not exceed 2^14 + 2048.

   fragment
       The encrypted form of TLSCompressed.fragment, with the MAC.

6.2.3.1. Null or standard stream cipher

   Stream ciphers (including BulkCipherAlgorithm.null - see Appendix
   A.6) convert TLSCompressed.fragment structures to and from stream
   TLSCiphertext.fragment structures.

       stream-ciphered struct {
           opaque content[TLSCompressed.length];
           opaque MAC[CipherSpec.hash_size];
       } GenericStreamCipher;

   The MAC is generated as:

       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
                     TLSCompressed.version + TLSCompressed.length +
                     TLSCompressed.fragment));

   where "+" denotes concatenation.

   seq_num
       The sequence number for this record.

   hash
       The hashing algorithm specified by
       SecurityParameters.mac_algorithm.

   Note that the MAC is computed before encryption. The stream cipher
   encrypts the entire block, including the MAC. For stream ciphers that
   do not use a synchronization vector (such as RC4), the stream cipher
   state from the end of one record is simply used on the subsequent
   packet. If the CipherSuite is TLS_NULL_WITH_NULL_NULL, encryption
   consists of the identity operation (i.e., the data is not encrypted
   and the MAC size is zero implying that no MAC is used).
   TLSCiphertext.length is TLSCompressed.length plus
   CipherSpec.hash_size.

6.2.3.2. CBC block cipher

   For block ciphers (such as RC2 or DES), the encryption and MAC
   functions convert TLSCompressed.fragment structures to and from block
   TLSCiphertext.fragment structures.



Dierks & Allen              Standards Track                    [Page 19]

RFC 2246              The TLS Protocol Version 1.0          January 1999


       block-ciphered struct {
           opaque content[TLSCompressed.length];
           opaque MAC[CipherSpec.hash_size];
           uint8 padding[GenericBlockCipher.padding_length];
           uint8 padding_length;
       } GenericBlockCipher;

   The MAC is generated as described in Section 6.2.3.1.

   padding
       Padding that is added to force the length of the plaintext to be
       an integral multiple of the block cipher's block length. The
       padding may be any length up to 255 bytes long, as long as it
       results in the TLSCiphertext.length being an integral multiple of
       the block length. Lengths longer than necessary might be
       desirable to frustrate attacks on a protocol based on analysis of
       the lengths of exchanged messages. Each uint8 in the padding data
       vector must be filled with the padding length value.

   padding_length
       The padding length should be such that the total size of the
       GenericBlockCipher structure is a multiple of the cipher's block
       length. Legal values range from zero to 255, inclusive. This
       length specifies the length of the padding field exclusive of the
       padding_length field itself.

   The encrypted data length (TLSCiphertext.length) is one more than the
   sum of TLSCompressed.length, CipherSpec.hash_size, and
   padding_length.

 Example: If the block length is 8 bytes, the content length
          (TLSCompressed.length) is 61 bytes, and the MAC length is 20
          bytes, the length before padding is 82 bytes. Thus, the
          padding length modulo 8 must be equal to 6 in order to make
          the total length an even multiple of 8 bytes (the block
          length). The padding length can be 6, 14, 22, and so on,
          through 254. If the padding length were the minimum necessary,
          6, the padding would be 6 bytes, each containing the value 6.
          Thus, the last 8 octets of the GenericBlockCipher before block
          encryption would be xx 06 06 06 06 06 06 06, where xx is the
          last octet of the MAC.

 Note: With block ciphers in CBC mode (Cipher Block Chaining) the
       initialization vector (IV) for the first record is generated with
       the other keys and secrets when the security parameters are set.
       The IV for subsequent records is the last ciphertext block from
       the previous record.




Dierks & Allen              Standards Track                    [Page 20]

RFC 2246              The TLS Protocol Version 1.0          January 1999


6.3. Key calculation

   The Record Protocol requires an algorithm to generate keys, IVs, and
   MAC secrets from the security parameters provided by the handshake
   protocol.

   The master secret is hashed into a sequence of secure bytes, which
   are assigned to the MAC secrets, keys, and non-export IVs required by
   the current connection state (see Appendix A.6). CipherSpecs require
   a client write MAC secret, a server write MAC secret, a client write
   key, a server write key, a client write IV, and a server write IV,
   which are generated from the master secret in that order. Unused
   values are empty.

   When generating keys and MAC secrets, the master secret is used as an
   entropy source, and the random values provide unencrypted salt
   material and IVs for exportable ciphers.

   To generate the key material, compute

       key_block = PRF(SecurityParameters.master_secret,
                          "key expansion",
                          SecurityParameters.server_random +
                          SecurityParameters.client_random);

   until enough output has been generated. Then the key_block is
   partitioned as follows:

       client_write_MAC_secret[SecurityParameters.hash_size]
       server_write_MAC_secret[SecurityParameters.hash_size]
       client_write_key[SecurityParameters.key_material_length]
       server_write_key[SecurityParameters.key_material_length]
       client_write_IV[SecurityParameters.IV_size]
       server_write_IV[SecurityParameters.IV_size]

   The client_write_IV and server_write_IV are only generated for non-
   export block ciphers. For exportable block ciphers, the
   initialization vectors are generated later, as described below. Any
   extra key_block material is discarded.

   Implementation note:
       The cipher spec which is defined in this document which requires
       the most material is 3DES_EDE_CBC_SHA: it requires 2 x 24 byte
       keys, 2 x 20 byte MAC secrets, and 2 x 8 byte IVs, for a total of
       104 bytes of key material.






Dierks & Allen              Standards Track                    [Page 21]

RFC 2246              The TLS Protocol Version 1.0          January 1999


   Exportable encryption algorithms (for which CipherSpec.is_exportable
   is true) require additional processing as follows to derive their
   final write keys:

       final_client_write_key =
       PRF(SecurityParameters.client_write_key,
                                  "client write key",
                                  SecurityParameters.client_random +
                                  SecurityParameters.server_random);
       final_server_write_key =
       PRF(SecurityParameters.server_write_key,
                                  "server write key",
                                  SecurityParameters.client_random +
                                  SecurityParameters.server_random);

   Exportable encryption algorithms derive their IVs solely from the
   random values from the hello messages:

       iv_block = PRF("", "IV block", SecurityParameters.client_random +
                      SecurityParameters.server_random);

   The iv_block is partitioned into two initialization vectors as the
   key_block was above:

       client_write_IV[SecurityParameters.IV_size]
       server_write_IV[SecurityParameters.IV_size]

   Note that the PRF is used without a secret in this case: this just
   means that the secret has a length of zero bytes and contributes
   nothing to the hashing in the PRF.

6.3.1. Export key generation example

   TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 requires five random bytes for
   each of the two encryption keys and 16 bytes for each of the MAC
   keys, for a total of 42 bytes of key material. The PRF output is
   stored in the key_block. The key_block is partitioned, and the write
   keys are salted because this is an exportable encryption algorithm.

       key_block               = PRF(master_secret,
                                     "key expansion",
                                     server_random +
                                     client_random)[0..41]
       client_write_MAC_secret = key_block[0..15]
       server_write_MAC_secret = key_block[16..31]
       client_write_key        = key_block[32..36]
       server_write_key        = key_block[37..41]




Dierks & Allen              Standards Track                    [Page 22]

RFC 2246              The TLS Protocol Version 1.0          January 1999


       final_client_write_key  = PRF(client_write_key,
                                     "client write key",
                                     client_random +
                                     server_random)[0..15]
       final_server_write_key  = PRF(server_write_key,
                                     "server write key",
                                     client_random +
                                     server_random)[0..15]

       iv_block                = PRF("", "IV block", client_random +
                                     server_random)[0..15]
       client_write_IV = iv_block[0..7]
       server_write_IV = iv_block[8..15]

7. The TLS Handshake Protocol

   The TLS Handshake Protocol consists of a suite of three sub-protocols
   which are used to allow peers to agree upon security parameters for
   the record layer, authenticate themselves, instantiate negotiated
   security parameters, and report error conditions to each other.

   The Handshake Protocol is responsible for negotiating a session,
   which consists of the following items:

   session identifier
       An arbitrary byte sequence chosen by the server to identify an
       active or resumable session state.

   peer certificate
       X509v3 [X509] certificate of the peer. This element of the state