summaryrefslogtreecommitdiff
path: root/doc/protocol/draft-rescorla-tls-extended-random-00.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/protocol/draft-rescorla-tls-extended-random-00.txt')
-rw-r--r--doc/protocol/draft-rescorla-tls-extended-random-00.txt448
1 files changed, 448 insertions, 0 deletions
diff --git a/doc/protocol/draft-rescorla-tls-extended-random-00.txt b/doc/protocol/draft-rescorla-tls-extended-random-00.txt
new file mode 100644
index 0000000000..5b33f74178
--- /dev/null
+++ b/doc/protocol/draft-rescorla-tls-extended-random-00.txt
@@ -0,0 +1,448 @@
+
+
+
+Network Working Group E. Rescorla
+Internet-Draft RTFM, Inc.
+Intended status: Informational M. Salter
+Expires: October 31, 2008 National Security Agency
+ April 29, 2008
+
+
+ Extended Random Values for TLS
+ draft-rescorla-tls-extended-random-00.txt
+
+Status of this Memo
+
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of 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 October 31, 2008.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (2008).
+
+Abstract
+
+ This document describes an extension for using larger client and
+ server Random values with Transport Layer Security (TLS) and Datagram
+ TLS (DTLS).
+
+
+
+
+
+
+
+Rescorla & Salter Expires October 31, 2008 [Page 1]
+
+Internet-Draft Extended TLS Random April 2008
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions Used In This Document . . . . . . . . . . . . . . . 3
+ 3. The ExtendedRandom Extension . . . . . . . . . . . . . . . . . 3
+ 3.1. Negotiating the ExtendedRandom Extension . . . . . . . . . 4
+ 3.2. PRF Modifications . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+ 4.1. Threats to TLS . . . . . . . . . . . . . . . . . . . . . . 5
+ 4.2. Scope of Randomness . . . . . . . . . . . . . . . . . . . . 5
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+ 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 6
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6
+ Intellectual Property and Copyright Statements . . . . . . . . . . 8
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla & Salter Expires October 31, 2008 [Page 2]
+
+Internet-Draft Extended TLS Random April 2008
+
+
+1. Introduction
+
+ TLS [I-D.ietf-tls-rfc4346-bis] and DTLS [RFC4347] use a 32-byte
+ "Random" value consisting of a 32-bit time value time and 28 randomly
+ generated bytes:
+
+ struct {
+ uint32 gmt_unix_time;
+ opaque random_bytes[28];
+ } Random;
+
+ The client and server each contribute a Random value which is then
+ mixed with secret keying material to produce the final per-
+ association keying material.
+
+ The United States Department of Defense has requested a TLS mode
+ which allows the use of longer public randomness values for use with
+ high security level cipher suites like those specified in Suite B
+ [I-D.rescorla-tls-suiteb]. The rationale for this as stated by DoD
+ is that the public randomness for each side should be at least twice
+ as long as the security level for cryptographic parity, which makes
+ the 224 bits of randomness provided by the current TLS random values
+ insufficient.
+
+ This document specifies an extension which allows for additional
+ randomness to be exchanged in the Hello messages.
+
+
+2. Conventions Used In This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+
+3. The ExtendedRandom Extension
+
+ This document defines a new TLS extension called "extended_random".
+
+ The "extended_random" extension carried in a new TLS extension called
+ "ExtendedRandom".
+
+ struct {
+ opaque extended_random_value<0..2^16-1>;
+ } ExtendedRandom;
+
+ The extended_random_value MUST be a randomly generated byte string.
+ A cryptographically secure PRNG [RFC4086] SHOULD be used.
+
+
+
+Rescorla & Salter Expires October 31, 2008 [Page 3]
+
+Internet-Draft Extended TLS Random April 2008
+
+
+3.1. Negotiating the ExtendedRandom Extension
+
+ The client requests support for the extended randomness feature by
+ sending an "extended_random" extension in its ClientHello. The
+ "extension_data" field contains an ExtendedRandom value.
+
+ When a server which does not recognize the "extended_random"
+ extension receives one, it will ignore it as required. A server
+ which recognizes the extension MAY choose to ignore it, in which case
+ it SHOULD continue with the exchange as if it had not received the
+ extension.
+
+ If the server wishes to use the extended randomness feature, it MUST
+ send its own "extended_random" extension with an
+ extended_random_value equal in length to the client's
+ extended_random_value. Clients SHOULD check the length of the
+ server's extended_random_value and generate a fatal
+ "illegal_parameter" error if it is present but does does not match
+ the length that was transmitted in the ClientHello.
+
+ Because TLS does not permit servers to request extensions which the
+ client did not offer, the client may not offer the "extended_random"
+ extension even if the server requires it. In this case, the server
+ should generate a fatal "handshake_failure" alert.
+
+ Because there is no way to mark extensions as critical, the server
+ may ignore the "extended_random" extension even though the client
+ requires it. If a client requires the extended randomness input
+ feature but the server does not negotiate it, the client SHOULD
+ generate a fatal "handshake_failure" alert.
+
+3.2. PRF Modifications
+
+ When the extended randomness feature is in use, the extended random
+ values MUST be mixed into the PRF along with the client and server
+ random values during the PMS->MS conversion. Thus, the PRF becomes:
+
+ master_secret = PRF(pre_master_secret, "master secret",
+ ClientHello.random +
+ ClientHello.extended_random_value +
+ ServerHello.random +
+ ServerHello.extended_random_value)[0..47];
+
+ Because new extensions may not be introduced in resumed handshakes,
+ mixing in the extended inputs during the MS->keying material
+ conversion would simply involve mixing in the same material twice.
+ Therefore, the extended random inputs are only used when the PMS is
+ converted into the MS.
+
+
+
+Rescorla & Salter Expires October 31, 2008 [Page 4]
+
+Internet-Draft Extended TLS Random April 2008
+
+
+4. Security Considerations
+
+4.1. Threats to TLS
+
+ When this extension is in use it increases the amount of data that an
+ attacker can inject into the PRF. This potentially would allow an
+ attacker who had partially compromised the PRF greater scope for
+ influencing the output. Hash-based PRFs like the one in TLS are
+ designed to be fairly indifferent to the input size (the input is
+ already greater than the block size of most hash functions), however
+ there is currently no proof that a larger input space would not make
+ attacks easier.
+
+ Another concern is that bad implementations might generate low
+ entropy extented random values. TLS is designed to function
+ correctly even when fed low-entropy random values because they are
+ primarily used to generate distinct keying material for each
+ connection.
+
+4.2. Scope of Randomness
+
+ TLS specifies that when a session is resumed the extensions from the
+ original connection are used:
+
+ If, on the other hand, the older session is resumed, then the
+ server MUST ignore the extensions and send a server hello
+ containing none of the extension types. In this case, the
+ functionality of these extensions negotiated during the original
+ session initiation is applied to the resumed session.
+
+ This motivates why the the extended randomness does not get mixed
+ into the PRF when generating the keying material from the master
+ secret. Because the same values would be used for every connection
+ in a session, they would not provide any differentiation in the
+ keying material between the connections.
+
+
+5. IANA Considerations
+
+ This document defines an extension to TLS, in accordance with
+ [I-D.ietf-tls-rfc4366-bis]:
+
+ enum { extended_random (??) } ExtensionType;
+
+ [[ NOTE: These values need to be assigned by IANA ]]
+
+
+
+
+
+
+Rescorla & Salter Expires October 31, 2008 [Page 5]
+
+Internet-Draft Extended TLS Random April 2008
+
+
+6. Acknowledgements
+
+ This work was supported by the US Department of Defense.
+
+
+7. References
+
+7.1. Normative References
+
+ [I-D.ietf-tls-rfc4346-bis]
+ Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-10
+ (work in progress), March 2008.
+
+ [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+ Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+7.2. Informative References
+
+ [I-D.ietf-tls-rfc4366-bis]
+ 3rd, D., "Transport Layer Security (TLS) Extensions:
+ Extension Definitions", draft-ietf-tls-rfc4366-bis-02
+ (work in progress), February 2008.
+
+ [I-D.rescorla-tls-suiteb]
+ Salter, M. and E. Rescorla, "Suite B Cipher Suites for
+ TLS", draft-rescorla-tls-suiteb-02 (work in progress),
+ April 2008.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
+ Security", RFC 4347, April 2006.
+
+
+Authors' Addresses
+
+ Eric Rescorla
+ RTFM, Inc.
+ 2064 Edgewood Drive
+ Palo Alto, CA 94303
+ USA
+
+ Email: ekr@rtfm.com
+
+
+
+
+
+
+Rescorla & Salter Expires October 31, 2008 [Page 6]
+
+Internet-Draft Extended TLS Random April 2008
+
+
+ Margaret Salter
+ National Security Agency
+ 9800 Savage Rd.
+ Fort Meade 20755-6709
+ USA
+
+ Email: msalter@restarea.ncsc.mil
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rescorla & Salter Expires October 31, 2008 [Page 7]
+
+Internet-Draft Extended TLS Random April 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+ THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+ OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+ THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+
+Acknowledgment
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+Rescorla & Salter Expires October 31, 2008 [Page 8]
+
View Lorry Controller Status