idnits 2.17.1 draft-altman-tls-channel-bindings-00.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 on line 166. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 177. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 184. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 190. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (August 16, 2006) is 6456 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) == Unused Reference: 'I-D.williams-on-channel-binding' is defined on line 123, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-williams-on-channel-binding-00 ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 Intended status: Proposed Standard N. Williams 5 Expires: February 17, 2007 Sun 6 August 16, 2006 8 On the Use of Channel Bindings to Secure Channels 9 draft-altman-tls-channel-bindings-00 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 February 17, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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 It is acceptable for the API to provide access to the most recent 95 finished messages although doing so will require that the application 96 be aware of TLS renegotiations in order to ensure that the correct 97 set of TLS finished messages are used. 99 4. IANA Considerations 101 There are no IANA considerations for this document. 103 5. Security Considerations 105 The TLS finished messages section7.4.9 [RFC4346] are known to both 106 TLS endpoints and can therefore be safely used as a channel binding 107 provided that the higher level protocol binding to the TLS channel 108 provides integrity protection for the TLS finished messages and only 109 communicates the TLS finished messages across the TLS channel that it 110 is binding to. 112 If there is an active man-in-the-middle attack, the attacker will 113 already possess knowledge of the TLS finished messages for both 114 inbound and outbound TLS channels. Therefore, there is no additional 115 information obtained by the attacker via the use of the TLS finished 116 messages as a channel binding 118 The Security Considerations section of 119 "draft-williams-on-channel-binding" applies to this document. 121 6. Normative References 123 [I-D.williams-on-channel-binding] 124 Williams, N., "On the Use of Channel Bindings to Secure 125 Channels", draft-williams-on-channel-binding-00 (work in 126 progress), August 2006. 128 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 129 Requirement Levels", BCP 14, RFC 2119, March 1997. 131 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 132 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 134 Authors' Addresses 136 Jeffrey Altman 137 Secure Endpoints Inc. 138 255 W 94TH ST PHB 139 NEW YORK, NY 10025 140 US 142 Email: jaltman@secure-endpoints.com 144 Nicolas Williams 145 Sun Microsystems 146 5300 Riata Trace Ct 147 Austin, TX 78727 148 US 150 Email: Nicolas.Williams@sun.com 152 Full Copyright Statement 154 Copyright (C) The Internet Society (2006). 156 This document is subject to the rights, licenses and restrictions 157 contained in BCP 78, and except as set forth therein, the authors 158 retain all their rights. 160 This document and the information contained herein are provided on an 161 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 162 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 163 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 164 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 165 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 166 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 168 Intellectual Property 170 The IETF takes no position regarding the validity or scope of any 171 Intellectual Property Rights or other rights that might be claimed to 172 pertain to the implementation or use of the technology described in 173 this document or the extent to which any license under such rights 174 might or might not be available; nor does it represent that it has 175 made any independent effort to identify any such rights. Information 176 on the procedures with respect to rights in RFC documents can be 177 found in BCP 78 and BCP 79. 179 Copies of IPR disclosures made to the IETF Secretariat and any 180 assurances of licenses to be made available, or the result of an 181 attempt made to obtain a general license or permission for the use of 182 such proprietary rights by implementers or users of this 183 specification can be obtained from the IETF on-line IPR repository at 184 http://www.ietf.org/ipr. 186 The IETF invites any interested party to bring to its attention any 187 copyrights, patents or patent applications, or other proprietary 188 rights that may cover technology that may be required to implement 189 this standard. Please address the information to the IETF at 190 ietf-ipr@ietf.org. 192 Acknowledgment 194 Funding for the RFC Editor function is provided by the IETF 195 Administrative Support Activity (IASA).