idnits 2.17.1 draft-josefsson-sasl-tls-cb-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 20, 2009) is 5360 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 (-07) exists of draft-ietf-tls-extractor-06 Summary: 2 errors (**), 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 August 20, 2009 5 Expires: February 21, 2010 7 Channel Bindings for TLS based on the PRF 8 draft-josefsson-sasl-tls-cb-02 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on February 21, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document specify how to compute data, "channel bindings", that 57 is cryptographically bound to a specific Transport Layer Security 58 (TLS) session. The intention is to use this data as a name of the 59 secure channel for the purpose of a channel binding. The channel 60 bindings can be used by authentication protocols to avoid tunneling 61 attacks and security layer re-use. The data is derived using the TLS 62 Pseudo-Random Function (PRF). 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions Used in this Document . . . . . . . . . . . . . . . 3 68 3. Channel Bindings Syntax . . . . . . . . . . . . . . . . . . . . 3 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 1. Introduction 79 Binding authentication to a specific encrypted session can protect 80 from certain attacks [mitm]. It can also help to improve performance 81 by having peers agree to re-use a secure channel rather than to set 82 up a new. 84 This document describe how to generate data that can be used by 85 application protocols to bind authentication to a specific TLS 86 [RFC5246] session. 88 2. Conventions Used in this Document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 3. Channel Bindings Syntax 96 The channel bindings is computed using the TLS Pseudo-Random Function 97 (PRF). The PRF takes three inputs, a secret, a fixed label, and a 98 seed. Here the label will be "EXPORTER Channel Binding". The key 99 will be the master secret in a TLS session. The seed is the 100 concatenation of the client/server random and finished messages as 101 described below. We will use the first 32 octets computed by the 102 PRF. 104 Using the terminology, conventions and and pseudo-language in TLS 105 [RFC5246] and [I-D.ietf-tls-extractor], the channel bindings is 106 computed as follows: 108 TLS_channel_bindings = PRF(SecurityParameters.master_secret, 109 "EXPORTER Channel Binding", 110 SecurityParameters.client_random + 111 SecurityParameters.server_random + 112 Finished) [0..31] 114 The seed will be the concatenation of the current TLS session's 115 client/server random with the client's TLS Finished message from the 116 first handshake of the connection. 118 The derived data MUST NOT be used for any other purpose than channel 119 bindings as described in [RFC5056]. 121 4. IANA Considerations 123 The IANA is requested to allocate a string "EXPORTER Channel Binding" 124 in the TLS Exporter Label registry as per [I-D.ietf-tls-extractor]. 126 The IANA is requested to register this channel binding using the 127 following templates and the process described in [RFC5056]. 129 Subject: Registration of channel binding TLS 131 Channel binding unique prefix (name): tls-unique-prf 133 Channel binding type: unique 135 Channel type: TLS 137 Published specification (recommended, optional): This document 139 Channel binding is secret (requires confidentiality protection): no 141 Description (optional if a specification is given; required if no 142 Published specification is specified): See earlier in this document. 144 Intended usage: COMMON 146 Person and email address to contact for further information: 147 simon@josefsson.org 149 Owner/Change controller name and email address: simon@josefsson.org 151 Expert reviewer name and contact information: 153 5. Security Considerations 155 For the intended use and other important considerations, see 156 [RFC5056]. 158 We claim that by appropriately using a channel binding an application 159 can protect itself from the attacks in [mitm]. To guarantee this 160 property, the derived data is only to be used for the intended 161 purpose. 163 The security considerations in TLS should be considered. In 164 particular, the TLS master secret must be protected. 166 6. Acknowledgements 168 Thanks to Eric Rescorla and Sam Hartman who pointed out a problem 169 with the construct used in earlier versions of this document when TLS 170 server authentication is not used or checked. 172 7. References 174 7.1. Normative References 176 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 177 Requirement Levels", BCP 14, RFC 2119, March 1997. 179 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 180 Channels", RFC 5056, November 2007. 182 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 183 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 185 [I-D.ietf-tls-extractor] 186 Rescorla, E., "Keying Material Exporters for Transport 187 Layer Security (TLS)", draft-ietf-tls-extractor-06 (work 188 in progress), July 2009. 190 7.2. Informative References 192 [mitm] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 193 in Tunneled Authentication", 194 WWW http://www.saunalahti.fi/~asokan/research/mitm.html. 196 Author's Address 198 Simon Josefsson 199 SJD AB 201 Email: simon@josefsson.org