Network Working Group J. Solinas Internet-Draft National Security Agency Intended status: Informational P. Hoffman Expires: April 27, 2010 VPN Consortium October 24, 2009 Additional PRF Inputs for TLS draft-solinas-tls-additional-prf-input-01 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- 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 April 27, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Solinas & Hoffman Expires April 27, 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. Abstract 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 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 27, 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. 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 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 "AdditionalPRFInput". The extension is basically a concatenated list of items that will be added into the PRF. struct { uint16 AdditionalPRFInputType; opaque AdditionalPRFInputValue<0..2^16-4>; } AdditionalPRFItem; struct { AdditionalPRFItem item_list<0..2^16> } AdditionalPRFInput; The AdditionalPRFInputType is a value assigned by IANA. The AdditionalPRFInputValue is a byte-string which is generated in an implementation-dependent fashion based on the AdditionalPRFInputType. 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 27, 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 does not recognize one or more of the AdditionalPRFInputType values, 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 AdditionalPRFInput. The AdditionalPRFInput from the server MUST contain the same structure as was received from the client, with each AdditionalPRFInputType included, in the same order as was sent from the client. 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_item + ServerHello.random + ServerHello.additional_prf_input_item)[0..47]; 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. Solinas & Hoffman Expires April 27, 2010 [Page 4] Internet-Draft Additional PRF October 2009 Therefore, the additional PRF inputs are only used when the pre_master_secret is converted into the master_secret. 3. Defined Types A registry for types of additional PRF input will be maintained by IANA. Types are added to that registry only based on published RFCs. The value in the registry are used in the AdditionalPRFInputType field. Two types of additional PRF input are defined in this document: AdditionalRandom and OtherInfo. 3.1. AdditionalRandom Type The AdditionalRandom type, whose AdditionalPRFInputType value is {TBD1}, is used to add additional random values from the client and/or the server to the PRF. The size and the contents of the AdditionalPRFInputValue are undefined (other than it must be between 0 and 2^16-4 bytes). The size of the AdditionalPRFInputValue provided by the client does not indicate anything about the expected size of the AdditionalPRFInputValue from the server. 3.2. OtherInfo Type The OtherInfo type, whose AdditionalPRFInputType value is {TBD2}, is used to add additional information from the client and/or the server to the PRF. The size and the contents of the AdditionalPRFInputValue are undefined (other than it must be between 0 and 2^16-4 bytes). This type can be used for meeting the requirements in [SP800-56A] and similar documents. 4. 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 Solinas & Hoffman Expires April 27, 2010 [Page 5] Internet-Draft Additional PRF October 2009 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. 5. IANA Considerations This document defines an extension to TLS, in accordance with RFC 4366: enum { additional_prf_input (TBD) } ExtensionType; IANA will set up a new registry, "Additional PRF Input Types" which will refer to this document. Entries in that registry are added only based on published RFCs. The entries in that registry have three fields: type name, type value, and reference. The type name is free text. The type value is an integer between 0 and 65536. The reference is the RFC that defines the type. The two initial values for the registry are: Type name Type value Reference ----------------------------------------------- AdditionalRandom {TBD1} [This document] OtherInfo {TBD2} [This document] 6. Acknowledgements This work was supported by the US Department of Defense. 7. References 7.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 27, 2010 [Page 6] 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. 7.2. Informative References [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [SP800-56A] 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. Appendix A. Version History [[ RFC Editor: this entire section is to be removed before final publication. ]] A.1. Changes from draft-solinas-tls-additional-prf-input-00 to -01 Removed "The mechanism also allows the use of random nonce values that are longer than the fixed size of 224 bits" from section 1.1. Also removed the example of TLS servers arranging for their clients to provide authentication data early in the protocol because it was confusing. Completely changed the structure of the extension in section 2 from being a single blob to being a concatenated list of typed blobs. In section 2.1, added "If the server does not recognize one or more of the AdditionalPRFInputType values, the server MUST continue with the exchange as if it had not received the extension." Also added "The AdditionalPRFInput from the server MUST contain the same structure as was received from the client, with each AdditionalPRFInputType included, in the same order as was sent from the client.". In section 2.2, change the PRF calculation to use additional_prf_input_item. All of section 3 is new. Solinas & Hoffman Expires April 27, 2010 [Page 7] Internet-Draft Additional PRF October 2009 The registry in the IANA Considerations is new. 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 27, 2010 [Page 8]