idnits 2.17.1 draft-josefsson-sasl-tls-cb-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2015) is 3314 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-06) exists of draft-ietf-tls-session-hash-03 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Josefsson 3 Internet-Draft SJD AB 4 Intended status: Standards Track March 2, 2015 5 Expires: September 3, 2015 7 Channel Bindings for TLS based on the PRF 8 draft-josefsson-sasl-tls-cb-03 10 Abstract 12 This document specify how to compute the 'tls-unique-prf' data that 13 is cryptographically bound to a specific Transport Layer Security 14 (TLS) session. The intention is to use this data as a name of the 15 secure channel for the purpose of a channel binding. The channel 16 bindings can be used by authentication protocols to avoid tunneling 17 attacks and security layer re-use. The data is derived using the TLS 18 Pseudo-Random Function (PRF). Applications of this include SASL- 19 based protocols like IMAP, SMTP and XMPP. The channel binding 'tls- 20 unique-prf' defined in this document is an alternative to 'tls- 21 unique' as described by RFC 5929 and used by SCRAM and GS2. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 3, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Channel Bindings Syntax . . . . . . . . . . . . . . . . . . . 2 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 64 6.2. Informative References . . . . . . . . . . . . . . . . . 5 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 67 1. Introduction 69 Binding authentication to a specific encrypted session can protect 70 from certain attacks [MITM]. It can also help to improve performance 71 by having peers agree to re-use a secure channel rather than to set 72 up a new. After publication of SCRAM [RFC5802] and GS2 [RFC5801], it 73 was discovered that the mandatory-to-implement and non-negotiable 74 channel binding 'tls-unique' [RFC5929] does not meet the required 75 properties [TRIPLE-HANDSHAKE]. 77 This document describe how to generate data that can be used by 78 application protocols to bind authentication to a specific TLS 79 [RFC5246] session, in the same way as 'tls-unique' was intended to 80 work. 82 There exists a TLS extension [I-D.ietf-tls-session-hash] that modify 83 TLS so that the definition of 'tls-unique' [RFC5929] has the intended 84 properties. If widely implemented and deployed, the channel binding 85 type in this document would not offer any additional protection. The 86 purpose of this document is to provide an alternative channel binding 87 that offers the intended properties without requiring TLS protocol 88 changes. However, keep in mind that TLS implementations needs to 89 offer the appropriate APIs necessary to be able to implement the 90 channel binding described in this document. 92 2. Channel Bindings Syntax 94 Inspired by [I-D.ietf-tls-session-hash] we introduce some 95 definitions. When a full TLS handshake takes place, let session_hash 96 be defined as follows. 98 session_hash = Hash(handshake_messages) 100 Here "handshake_messages" refers to all handshake messages sent or 101 received, starting at the ClientHello up to and including the 102 ClientKeyExchange message, including the type and length fields of 103 the handshake messages. This is the concatenation of all the 104 exchanged Handshake structures, as defined in Section 7.4 of 105 [RFC5246]. 107 For TLS 1.2, the "Hash" function is the one defined in Section 7.4.9 108 of [RFC5246] for the Finished message computation. For all previous 109 versions of TLS, the "Hash" function computes the concatenation of 110 MD5 and SHA1. 112 There is no "session_hash" for resumed handshakes, as they do not 113 lead to the creation of a new session. 115 The channel bindings is then computed using the TLS Pseudorandom 116 Function (PRF), see section 5 of [RFC5246]. The PRF takes three 117 inputs, a secret, a fixed label, and a seed. Here the label will be 118 "EXPORTER Channel Binding". The key will be the master secret in a 119 TLS session. The seed is will be the session_hash as described 120 above. We will use the first 32 octets computed by the PRF. 122 Using the terminology, conventions and and pseudo-language in TLS 123 [RFC5246] and [RFC5705], the channel bindings is computed as follows: 125 TLS_channel_bindings = PRF(master_secret, 126 "EXPORTER Channel Binding", 127 session_hash) [0..31] 129 The 32 byte TLS_channel_bindings data is used as the 'tls-unique-prf' 130 channel binding data. 132 3. IANA Considerations 134 The IANA is requested to allocate a string "EXPORTER Channel Binding" 135 in the TLS Exporter Label registry as per [RFC5705]. 137 The IANA is requested to register this channel binding using the 138 following templates and the process described in [RFC5056]. 140 Subject: Registration of channel binding TLS 142 Channel binding unique prefix (name): tls-unique-prf 144 Channel binding type: unique 145 Channel type: TLS 147 Published specification (recommended, optional): This document 149 Channel binding is secret (requires confidentiality protection): no 151 Description (optional if a specification is given; required if no 152 Published specification is specified): See earlier in this document. 154 Intended usage: COMMON 156 Person and email address to contact for further information: 157 simon@josefsson.org 159 Owner/Change controller name and email address: simon@josefsson.org 161 Expert reviewer name and contact information: 163 4. Security Considerations 165 For the intended use and other important considerations, see 166 [RFC5056]. 168 We claim that by appropriately using a channel binding an application 169 can protect itself from the attacks in [MITM] and [TRIPLE-HANDSHAKE]. 170 To guarantee this property, the derived data is only to be used for 171 the intended purpose. 173 The security considerations of TLS [RFC5246] are inherited by this 174 document. In particular, the TLS master secret must be protected. 176 5. Acknowledgements 178 Thanks to Eric Rescorla and Sam Hartman who pointed out a problem 179 with the construct used in earlier versions of this document when TLS 180 server authentication is not used or checked. 182 The construct used starting from the -03 version of this document is 183 inspired by (and some text were copied from) 184 [I-D.ietf-tls-session-hash]. 186 6. References 188 6.1. Normative References 190 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 191 Channels", RFC 5056, November 2007. 193 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 194 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 196 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 197 Layer Security (TLS)", RFC 5705, March 2010. 199 6.2. Informative References 201 [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security 202 Service Application Program Interface (GSS-API) Mechanisms 203 in Simple Authentication and Security Layer (SASL): The 204 GS2 Mechanism Family", RFC 5801, July 2010. 206 [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, 207 "Salted Challenge Response Authentication Mechanism 208 (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. 210 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 211 for TLS", RFC 5929, July 2010. 213 [I-D.ietf-tls-session-hash] 214 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 215 A., and M. Ray, "Transport Layer Security (TLS) Session 216 Hash and Extended Master Secret Extension", draft-ietf- 217 tls-session-hash-03 (work in progress), November 2014. 219 [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 220 in Tunneled Authentication", WWW 221 http://eprint.iacr.org/2002/163.pdf, November 2002. 223 [TRIPLE-HANDSHAKE] 224 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 225 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 226 Breaking and Fixing Authentication over TLS", WWW 227 https://www.secure-resumption.com/, March 2014. 229 Author's Address 231 Simon Josefsson 232 SJD AB 234 Email: simon@josefsson.org