TLS T. Petch Internet-Draft Engineering Networks Ltd Intended status: Standards Track March 29, 2010 Expires: September 30, 2010 TLS Terminology draft-tp-tls-terms-00.txt Abstract This document provides definitions of the terminology used for the elements of transport associated with TLS (Transport Level Security). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 30, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Petch Expires September 30, 2010 [Page 1] Internet-Draft TLS Terminology March 2010 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Petch Expires September 30, 2010 [Page 2] Internet-Draft TLS Terminology March 2010 1. Introduction TLS [RFC5246] provides a secure transport between two applications. It has evolved over the years from its initial specification as SSL and has gained facilities as it has done so. In 2009, a defect was found which allowed MITM attacks, a defect which was fixed by "Transport Layer Security (TLS) Renegotiation Indication Extension" [RFC5746]. In the lengthy discussions on the IETF TLS Working Group mailing list that led up to the publication of that document, it became apparent that while the concepts of TLS were clear, the terminology used to refer to them offered scope for improvement. This memo provides a summary of the clarity that was achieved during those discussions. Petch Expires September 30, 2010 [Page 3] Internet-Draft TLS Terminology March 2010 2. TLS TLS runs over a reliable transport - commonly TCP - and provides privacy and data integrity. The TLS handshake protocol negotiates security parameters which agree a CipherSuite, which in turn specifies methods for key exchange, bulk encryption, MAC and PRF. The key exchange generates a MasterSecret and the keys for the methods are derived from the MasterSecret in conjunction with random values provided by TLS client and server. Most key exchange methods require the server to provide an X.509 certificate and may require the client to provide one, at the behest of the server. A TLS handshake may omit the key exchange and reuse the MasterSecret from a previous handshake on the same or a different transport connection; a client requests this by specifying in the handshake the SessionID that the server provided as part of an earlier handshake, one that generated a MasterSecret. Petch Expires September 30, 2010 [Page 4] Internet-Draft TLS Terminology March 2010 3. Terminology o TLS CipherSuite: specifies a method for each of key exchange, bulk encryption, MAC and PRF. A method may be NULL. o TLS Handshake: a TLS protocol that negotiates security parameters for the subsequent transfer of data. o Full Handshake: a TLS Handshake that generates a new SessionID and MasterSecret; keys for encryption and MAC are derived from the latter. Where certificates are used as part of the CipherSuite, then their exchange forms part of a Full Handshake. o Abbreviated Handshake: a TLS Handshake that omits the key exchange and reuses an existing MasterSecret from which the keys for encryption and MAC are derived. An Abbreviated Handshake should change the client and server random values and may change TLS Version and client certificate. Note that a strict reading of Figure 2 of TLS [RFC5246] would preclude changes to the client certificate. o TLS Connection: a transport connection (eg TCP, UDP, DCCP, SCTP) over which a TLS Handshake has been successfully performed. The TLS Connection persists until terminated by closure alert messages or by termination of the underlying transport. o Initial Handshake: the first TLS Handshake on a TLS Connection. This may be a Full Handshake establishing a new SessionID and MasterSecret or it may be an Abbreviated Handshake reusing the MasterSecret from a Full Handshake on another TLS Connection. o TLS Session: the flow of data on one or more TLS Connections which either follows a TLS Handshake that establishes a SessionID and MasterSecret or reuses that specific SessionID and MasterSecret. The mapping of TLS Sessions to TLS Connections is many-to-many. A single TLS Connection may be serially reused by a number of TLS Sessions, each initiated by a TLS Handshake, or a single TLS Session may be in use on a number of TLS Connections in parallel, or any combination thereof. o TLS Connection States: the current operating parameters of a TLS Connection, as defined in TLS [RFC5246] section 6.1. These include the methods currently in use along with their associated keys for both read and write, and for both current and pending, a total of four states. The pending state becomes the current state with a ChangeCipherSpec message. Petch Expires September 30, 2010 [Page 5] Internet-Draft TLS Terminology March 2010 o Renegotiation: a TLS Handshake, Full or Abbreviated, that takes place on an existing TLS Connection and so takes place under the protection provided by the current security parameters of that TLS Connection. o TLS Connection Fragment: that part of a TLS Connection which starts with a TLS Handshake and ends either immediately prior to a further TLS Handshake or with the end of the TLS Connection. Note that this concept, more than most of those covered in this memo, does not have any currently accepted term. o Session Resumption: an Abbreviated Handshake. o Secure Channel: a packet, datagram, octet stream connection, or sequence of connections between two end-points that affords cryptographic integrity and, optionally, confidentiality to data exchanged over it. This definition is taken from "On the Use of Channel Bindings to Secure Channels" [RFC5056]. Note that implicit in this definition is the requirement that while the cryptographic parameters of the channel may change, they must be cryptographically bound to their predecessors in order to prevent a MITM attack. Historically, this has not been the case with TLS. Petch Expires September 30, 2010 [Page 6] Internet-Draft TLS Terminology March 2010 4. Security Considerations This memo introduced no additional security considerations beyond those covered in TLS [RFC5246]. Petch Expires September 30, 2010 [Page 7] Internet-Draft TLS Terminology March 2010 5. Acknowledgements Petch Expires September 30, 2010 [Page 8] Internet-Draft TLS Terminology March 2010 6. References 6.1. Normative References [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 6.2. Informative References [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, February 2010. Petch Expires September 30, 2010 [Page 9] Internet-Draft TLS Terminology March 2010 Author's Address Tom Petch Engineering Networks Ltd 18 Parkwood Close Lymm, Cheshire WA13 0NQ UK Email: tomSecurity@network-engineer.co.uk Petch Expires September 30, 2010 [Page 10]