draft-ietf-tls-protocol-04.txt   draft-ietf-tls-protocol-05.txt 
Transport Layer Security Working Group Tim Dierks Transport Layer Security Working Group Tim Dierks
INTERNET-DRAFT Consensus Development INTERNET-DRAFT Consensus Development
Expires April 28, 1998 Christopher Allen Expires May 12, 1998 Christopher Allen
Consensus Development Consensus Development
October 28, 1997 November 12, 1997
The TLS Protocol The TLS Protocol
Version 1.0 Version 1.0
<draft-ietf-tls-protocol-04.txt> <draft-ietf-tls-protocol-05.txt>
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or made obsolete by other months and may be updated, replaced, or made obsolete by other
skipping to change at page 2, line 27 skipping to change at page 2, line 27
4.4. Numbers 7 4.4. Numbers 7
4.5. Enumerateds 7 4.5. Enumerateds 7
4.6. Constructed types 8 4.6. Constructed types 8
4.6.1. Variants 8 4.6.1. Variants 8
4.7. Cryptographic attributes 9 4.7. Cryptographic attributes 9
4.8. Constants 10 4.8. Constants 10
5. HMAC and the pseudorandom function 11 5. HMAC and the pseudorandom function 11
6. The TLS Record Protocol 12 6. The TLS Record Protocol 12
6.1. Connection states 13 6.1. Connection states 13
6.2. Record layer 15 6.2. Record layer 15
6.2.1. Fragmentation 16 6.2.1. Fragmentation 15
6.2.2. Record compression and decompression 16 6.2.2. Record compression and decompression 16
6.2.3. Record payload protection 17 6.2.3. Record payload protection 17
6.2.3.1. Null or standard stream cipher 18 6.2.3.1. Null or standard stream cipher 18
6.2.3.2. CBC block cipher 18 6.2.3.2. CBC block cipher 18
6.3. Key calculation 19 6.3. Key calculation 19
6.3.1. Export key generation example 21 6.3.1. Export key generation example 21
7. The TLS Handshake Protocol 21 7. The TLS Handshake Protocol 21
7.1. Change cipher spec protocol 22 7.1. Change cipher spec protocol 22
7.2. Alert protocol 23 7.2. Alert protocol 23
7.2.1. Closure alerts 24 7.2.1. Closure alerts 24
skipping to change at page 5, line 10 skipping to change at page 5, line 10
The goals of TLS Protocol, in order of their priority, are: The goals of TLS Protocol, in order of their priority, are:
1. Cryptographic security: TLS should be used to establish a secure 1. Cryptographic security: TLS should be used to establish a secure
connection between two parties. connection between two parties.
2. Interoperability: Independent programmers should be able to 2. Interoperability: Independent programmers should be able to
develop applications utilizing TLS that will then be able to develop applications utilizing TLS that will then be able to
successfully exchange cryptographic parameters without knowledge successfully exchange cryptographic parameters without knowledge
of one another's code. of one another's code.
Note: It is not the case that all instances of TLS (even in the same
application domain) will be able to successfully connect. For
instance, if the server supports a particular hardware token,
and the client does not have access to such a token, then the
connection will not succeed. There is no required set of ciphers
for minimal compliance, so some implementations may be unable to
communicate.
3. Extensibility: TLS seeks to provide a framework into which new 3. Extensibility: TLS seeks to provide a framework into which new
public key and bulk encryption methods can be incorporated as public key and bulk encryption methods can be incorporated as
necessary. This will also accomplish two sub-goals: to prevent necessary. This will also accomplish two sub-goals: to prevent
the need to create a new protocol (and risking the introduction the need to create a new protocol (and risking the introduction
of possible new weaknesses) and to avoid the need to implement of possible new weaknesses) and to avoid the need to implement
an entire new security library. an entire new security library.
4. Relative efficiency: Cryptographic operations tend to be highly 4. Relative efficiency: Cryptographic operations tend to be highly
CPU intensive, particularly public key operations. For this CPU intensive, particularly public key operations. For this
reason, the TLS protocol has incorporated an optional session reason, the TLS protocol has incorporated an optional session
skipping to change at page 11, line 11 skipping to change at page 11, line 4
Under-specified types (opaque, variable length vectors, and Under-specified types (opaque, variable length vectors, and
structures that contain opaque) cannot be assigned values. No fields structures that contain opaque) cannot be assigned values. No fields
of a multi-element structure or vector may be elided. of a multi-element structure or vector may be elided.
For example, For example,
struct { struct {
uint8 f1; uint8 f1;
uint8 f2; uint8 f2;
} Example1; } Example1;
Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */ Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */
5. HMAC and the pseudorandom function 5. HMAC and the pseudorandom function
A number of operations in the TLS record and handshake layer A number of operations in the TLS record and handshake layer
required a keyed MAC; this is a secure digest of some data protected required a keyed MAC; this is a secure digest of some data protected
by a secret. Forging the MAC is infeasible without knowledge of the by a secret. Forging the MAC is infeasible without knowledge of the
MAC secret. Finding two data messages which have the same MAC is MAC secret. The construction we use for this operation is known as
also cryptographically infeasible. The construction we use for this HMAC, described in [HMAC].
operation is known as HMAC, described in [HMAC].
HMAC can be used with a variety of different hash algorithms. TLS HMAC can be used with a variety of different hash algorithms. TLS
uses it in the handshake with two different algorithms: MD5 and uses it in the handshake with two different algorithms: MD5 and
SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret, SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret,
data). Additional hash algorithms can be defined by cipher suites data). Additional hash algorithms can be defined by cipher suites
and used to protect record data, but MD5 and SHA-1 are hard coded and used to protect record data, but MD5 and SHA-1 are hard coded
into the description of the handshaking for this version of the into the description of the handshaking for this version of the
protocol. protocol.
In addition, a construction is required to do expansion of secrets In addition, a construction is required to do expansion of secrets
skipping to change at page 53, line 50 skipping to change at page 53, line 50
vector is exclusive-ORed with the first plaintext block prior to vector is exclusive-ORed with the first plaintext block prior to
encryption. encryption.
IDEA IDEA
A 64-bit block cipher designed by Xuejia Lai and James Massey. A 64-bit block cipher designed by Xuejia Lai and James Massey.
[IDEA] [IDEA]
Message Authentication Code (MAC) Message Authentication Code (MAC)
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 and it is difficult to find messages knowing the secret data. Its purpose is to detect if the message
which hash to the same MAC. Its purpose is to detect if the has been altered.
message 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 MD5 is a secure hashing function that converts an arbitrarily
long data stream into a digest of fixed size (16 bytes). [MD5] long data stream into a digest of fixed size (16 bytes). [MD5]
public key cryptography public key cryptography
skipping to change at page 66, line 24 skipping to change at page 66, line 24
bulk encryption keys, and anonymous servers should be used with bulk encryption keys, and anonymous servers should be used with
great caution. Implementations and users must be careful when great caution. Implementations and users must be careful when
deciding which certificates and certificate authorities are deciding which certificates and certificate authorities are
acceptable; a dishonest certificate authority can do tremendous acceptable; a dishonest certificate authority can do tremendous
damage. damage.
Appendix G Appendix G
G. Patent Statement G. Patent Statement
This version of the TLS protocol relies on the use of patented Some of the cryptographic algorithms proposed for use in this
public key encryption technology for authentication and encryption. protocol have patent claims on them. In addition Netscape
The Internet Standards Process as defined in RFC 1310 requires a Communications Corporation has a patent claim on the Secure Sockets
written statement from the Patent holder that a license will be made Layer (SSL) work that this standard is based on. The Internet
Standards Process as defined in RFC 1310 requires a written
statement from the Patent holder that a license will be made
available to applicants under reasonable terms and conditions prior available to applicants under reasonable terms and conditions prior
to approving a specification as a Proposed, Draft or Internet to approving a specification as a Proposed, Draft or Internet
Standard. Standard.
The Massachusetts Institute of Technology has granted RSA Data The Massachusetts Institute of Technology has granted RSA Data
Security, Inc., exclusive sub-licensing rights to the following Security, Inc., exclusive sub-licensing rights to the following
patent issued in the United States: patent issued in the United States:
Cryptographic Communications System and Method ("RSA"), No. Cryptographic Communications System and Method ("RSA"), No.
4,405,829 4,405,829
skipping to change at page 70, line 43 skipping to change at page 70, line 43
ma@pa.dec.com relyea@netscape.com ma@pa.dec.com relyea@netscape.com
Ran Canetti Jim Roskind Ran Canetti Jim Roskind
IBM Watson Research Center Netscape Communications IBM Watson Research Center Netscape Communications
canetti@watson.ibm.com jar@netscape.com canetti@watson.ibm.com jar@netscape.com
Taher Elgamal Micheal J. Sabin, Ph. D. Taher Elgamal Micheal J. Sabin, Ph. D.
Netscape Communications Consulting Engineer Netscape Communications Consulting Engineer
elgamal@netscape.com msabin@netcom.com elgamal@netscape.com msabin@netcom.com
Anil Gangolli Dan Simon Anil R. Gangolli Dan Simon
Netscape Communications Microsoft Structured Arts Computing Corp. Microsoft
gangolli@netscape.com dansimon@microsoft.com gangolli@structuredarts.com dansimon@microsoft.com
Kipp E.B. Hickman Tom Weinstein Kipp E.B. Hickman Tom Weinstein
Netscape Communications Netscape Communications Netscape Communications Netscape Communications
kipp@netscape.com tomw@netscape.com kipp@netscape.com tomw@netscape.com
Hugo Krawczyk Hugo Krawczyk
IBM Watson Research Center IBM Watson Research Center
hugo@watson.ibm.com hugo@watson.ibm.com
Comments Comments
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/