idnits 2.17.1 draft-altman-tls-channel-bindings-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 161. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 172. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 179. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 185. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (November 8, 2007) is 6012 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) -- No information found for draft-williams-on-channel-bindings - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.williams-on-channel-bindings' ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP J. Altman 3 Internet-Draft Secure Endpoints 4 Expires: May 11, 2008 N. Williams 5 Sun 6 November 8, 2007 8 Unique Channel Bindings for TLS 9 draft-altman-tls-channel-bindings-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 11, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document defines a form of channel bindings for TLS (Transport 43 Layer Security), namely the concatenation of the initial client and 44 server "finished" messages for a TLS connection. 46 Table of Contents 48 1. Conventions used in this document . . . . . . . . . . . . . . 3 49 2. Naming TLS Connections . . . . . . . . . . . . . . . . . . . . 4 50 3. Recommended Application Programming Interfaces . . . . . . . . 5 51 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 52 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 53 6. Normative References . . . . . . . . . . . . . . . . . . . . . 8 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 55 Intellectual Property and Copyright Statements . . . . . . . . . . 10 57 1. Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in [RFC2119]. 63 2. Naming TLS Connections 65 Whenever a "name" is needed for a TLS connection such that the "name" 66 is cryptographically bound to the said TLS [RFC4346]connection (its 67 pre-master secret, negotiation, messages, etc...) such a name may be 68 constructed as described below; we term this a "channel binding." 70 The channel bindings for TLS connections consist of one, the other or 71 both of the initial client or server "finished" TLS messages section 72 7.4.9 [RFC4346] (note: the unencrypted messages). The initial TLS 73 finished messages are the first pair of TLS finished messages 74 exchanged after TLS channel establishment. It is irrelevant whether 75 the TLS channel was established with a previous SessionID section 76 7.4.1.2 [RFC4346] or not. 78 Application protocols MUST specify which of the two initial finished 79 messages, or combination of both of them, to use. 81 The process by which applications perform "channel binding," that is, 82 the process by which applications establish that the channel bindings 83 for a given TLS connection are observed to be the same at both 84 application ends of the TLS connection is not described here. 86 3. Recommended Application Programming Interfaces 88 TLS implementations supporting the use of initial TLS finished 89 messages as channel bindings should provide application programming 90 interfaces to enable higher level protocol implementations to obtain 91 the initial TLS finished messages for both the client and server 92 endpoints. 94 4. IANA Considerations 96 There are no IANA considerations for this document. 98 5. Security Considerations 100 The TLS finished messages section7.4.9 [RFC4346] are known to both 101 TLS endpoints and can therefore be safely used as a channel binding 102 provided that the higher level protocol binding to the TLS channel 103 provides integrity protection for the TLS finished messages and only 104 communicates the TLS finished messages across the TLS channel that it 105 is binding to. 107 If there is an active man-in-the-middle attack, the attacker will 108 already possess knowledge of the TLS finished messages for both 109 inbound and outbound TLS channels. Therefore, there is no additional 110 information obtained by the attacker via the use of the TLS finished 111 messages as a channel binding 113 The Security Considerations section of 114 [I-D.williams-on-channel-bindings] applies to this document. 116 6. Normative References 118 [I-D.williams-on-channel-bindings] 119 Williams, N., "On Channel Binding", 120 draft-williams-on-channel-bindings-00 (work in progress), 121 July 2006. 123 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 124 Requirement Levels", BCP 14, RFC 2119, March 1997. 126 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 127 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 129 Authors' Addresses 131 Jeff Altman 132 Secure Endpoints 133 255 W 94TH ST PHB 134 New York, NY 10025 135 US 137 Email: jaltman@secure-endpoints.com 139 Nicolas Williams 140 Sun Microsystems 141 5300 Riata Trace Ct 142 Austin, TX 78727 143 US 145 Email: Nicolas.Williams@sun.com 147 Full Copyright Statement 149 Copyright (C) The IETF Trust (2007). 151 This document is subject to the rights, licenses and restrictions 152 contained in BCP 78, and except as set forth therein, the authors 153 retain all their rights. 155 This document and the information contained herein are provided on an 156 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 157 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 158 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 159 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 160 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 161 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 163 Intellectual Property 165 The IETF takes no position regarding the validity or scope of any 166 Intellectual Property Rights or other rights that might be claimed to 167 pertain to the implementation or use of the technology described in 168 this document or the extent to which any license under such rights 169 might or might not be available; nor does it represent that it has 170 made any independent effort to identify any such rights. Information 171 on the procedures with respect to rights in RFC documents can be 172 found in BCP 78 and BCP 79. 174 Copies of IPR disclosures made to the IETF Secretariat and any 175 assurances of licenses to be made available, or the result of an 176 attempt made to obtain a general license or permission for the use of 177 such proprietary rights by implementers or users of this 178 specification can be obtained from the IETF on-line IPR repository at 179 http://www.ietf.org/ipr. 181 The IETF invites any interested party to bring to its attention any 182 copyrights, patents or patent applications, or other proprietary 183 rights that may cover technology that may be required to implement 184 this standard. Please address the information to the IETF at 185 ietf-ipr@ietf.org. 187 Acknowledgment 189 Funding for the RFC Editor function is provided by the IETF 190 Administrative Support Activity (IASA).