[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

Network Working Group                                         J. Solinas
Internet-Draft                                  National Security Agency
Intended status: Informational                                P. Hoffman
Expires: April 8, 2010                                    VPN Consortium
                                                         October 5, 2009

                     Additional PRF Inputs for TLS

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on April 8, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Solinas & Hoffman         Expires April 8, 2010                 [Page 1]

Internet-Draft               Additional PRF                 October 2009

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


   This document describes a mechanism for using additional PRF inputs
   with Transport Layer Security (TLS) and Datagram TLS (DTLS).

1.  Introduction

   TLS [RFC5246] and DTLS [RFC4347] use a 32-byte "Random" value
   consisting of a 32-bit time value 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.

   In a number of United States Government applications, it is desirable
   to have some material that is contributed both by client and server,
   has an arbitrary length, is possibly structured, and is mixed into
   the eventual keying material.  These requirements are incompatible
   with the current Random mechanism, which supports a short, fixed-
   length value.

   This document describes a mechanism that meets these requirements.
   It provides a means for a client and server to exchange data early in
   the handshake; this data is then concatenated to the ClientHello and
   ServerHello Randoms during the derivation of the master_secret.  This
   additional data may be encoded with information that is useful to
   some implementations.  The mechanism also allows the use of random
   nonce values that are longer than the fixed size of 224 bits.

   The mechanism described here has several desirable features which may
   prove useful beyond the requirements of the US Government
   applications.  It is easy to implement, and using it adds little to
   the overall computation of the TLS handshake.  Further,
   interoperability is preserved between clients that implement the
   extension and servers that do not, and between clients that do not
   implement the extension and servers that do.

Solinas & Hoffman         Expires April 8, 2010                 [Page 2]

Internet-Draft               Additional PRF                 October 2009

1.1.  Example Usages

   Several recommendations for key derivation call for the concatenation
   of additional information fields into the key derivation function
   when producing a shared key.  For example, the specification of
   Alternative 1 in NIST Special Publication 800-56A ([SP800-56A]) calls
   for the inclusion of "OtherInfo" fields.  In this case, OtherInfo
   contains the concatenation of a variety of mandatory and optional
   sub-fields.  The extension described in this document provides a
   simple mechanism both for supplying the public information to the
   peer and for the inclusion of the information in the key derivation.
   Many other application environments require or allow similar fields.

   TLS servers may arrange for their clients to provide authentication
   data early in the protocol (such as an HMAC value computed over a
   fresh random value using a shared secret as the key) in order to
   authenticate the client as a member of a private network or as an
   additional means of mitigating the impact of a denial-of-service

   Implementors may want to provide a mechanism for relaying identity
   and version information similar to the "Vendor ID Payload" used in
   ISAKMP [RFC2408].

1.2.  Conventions Used In This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

2.  The AdditionalPRFInput Extension

   The additional PRF input is carried in a new TLS extension called

     struct {
         opaque  additional_prf_input_value<0..2^16-1>;
     } AdditionalPRFInput;

   The additional_prf_input_value is a byte-string which is generated in
   an implementation-dependent fashion.

2.1.  Negotiating the AdditionalPRFInput Extension

   The client requests support for the additional PRF input feature by
   sending an additional_prf_input extension in its ClientHello.  The
   "extension_data" field contains an AdditionalPRFInput.

Solinas & Hoffman         Expires April 8, 2010                 [Page 3]

Internet-Draft               Additional PRF                 October 2009

   When a server that does not recognize the additional_prf_input
   extension receives that extension, [RFC4366] requires that the server
   will ignore it.  A server that recognizes the extension MAY ignore
   the extension; in such a case, the server MUST continue with the
   exchange as if it had not received the extension.

   If the server wishes to use the additional PRF input feature, it MUST
   send its own additional_prf_input extension with a non-null

   Because RFC 4366 does not permit servers to request extensions that
   the client did not offer, the client might not offer the
   additional_prf_input extension even if the server requires it for
   operation.  In this case, the server would need to generate a fatal
   "handshake_failure" alert to stop the connection.  Similarly, because
   there is no way to mark extensions as critical, the server might
   ignore the additional_prf_input extension even though the client
   requires it for operation.  In this case, the client would need to
   generate a fatal "handshake_failure" alert to stop the connection.
   In either case, the peer will not know why the handshake failed (this
   is true for all TLS extensions that one side requires but cannot
   communicate that requirement to the other side).

2.2.  PRF Modifications

   When the additional PRF input feature is in use, the additional PRF
   input values are mixed into the PRF along with the client and server
   random values during the conversion of the pre_master_secret to the
   master_secret.  Thus, the PRF becomes:

     master_secret = PRF(pre_master_secret, "master secret",
                         ClientHello.random +
                         ClientHello.additional_prf_input_value +
                         ServerHello.random +

   If the additional_prf_input extension is agreed to, the above
   derivation for the PRF MUST be used.

   Because new extensions may not be introduced in resumed handshakes,
   mixing in the additional PRF inputs during the session resumption PRF
   invocation would simply involve mixing in the same material twice.
   Therefore, the additional PRF inputs are only used when the
   pre_master_secret is converted into the master_secret.

Solinas & Hoffman         Expires April 8, 2010                 [Page 4]

Internet-Draft               Additional PRF                 October 2009

3.  Security Considerations

   This extension increases the amount of data that an attacker can
   inject into the PRF.  This potentially would allow an attacker who
   had partially compromised the inputs to 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 additional PRF input may have no entropy; in fact, it might be
   completely predictable to an attacker.  TLS is designed to function
   correctly even when the PRF has a great deal of predictable material
   because the PRF is used to generate distinct keying material for each
   connection.  Thus, even in the face of completely predictable
   additional PRF input values, no harm is done to the resulting PRF
   output.  When there is entropy in these values, that entropy is
   reflected in the PRF output.

   It is anticipated that applications may want to have access to the
   additional PRF input values and that they may contain data that is
   meaningful at a higher layer.  Because the values are covered by the
   TLS Finished message, they are integrity-protected by TLS.  However,
   the application must independently provide any confidentiality
   necessary for those values.

4.  IANA Considerations

   This document defines an extension to TLS, in accordance with RFC

     enum { additional_prf_input (TBD) } ExtensionType;

5.  Acknowledgements

   This work was supported by the US Department of Defense.

6.  References

6.1.  Normative References

   [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.

Solinas & Hoffman         Expires April 8, 2010                 [Page 5]

Internet-Draft               Additional PRF                 October 2009

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

6.2.  Informative References

   [RFC2408]  Maughan, D., Schneider, M., and M. Schertler, "Internet
              Security Association and Key Management Protocol
              (ISAKMP)", RFC 2408, November 1998.

              National Institute of Standards and Technology, U.S.
              Department of Commerce, "Recommendation for Pair-Wise Key
              Establishment Schemes  Using Discrete Logarithm
              Cryptography (Revised)", NIST SP 800-56A, March 2007.

Authors' Addresses

   Jerome A. Solinas
   National Security Agency

   Email: jasolin@orion.ncsc.mil

   Paul Hoffman
   VPN Consortium

   Email: paul.hoffman@vpnc.org

Solinas & Hoffman         Expires April 8, 2010                 [Page 6]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/