idnits 2.17.1 draft-altman-tls-channel-bindings-01.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 168. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 179. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 186. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 192. 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 (December 13, 2006) is 6343 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 125, 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: 3 errors (**), 0 flaws (~~), 4 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 Expires: June 16, 2007 N. Williams 5 Sun Microsystems 6 December 13, 2006 8 On the Use of Channel Bindings to Secure Channels 9 draft-altman-tls-channel-bindings-01 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 June 16, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (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 the concatenation 71 of the initial client and 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 MAY specify which of the two initial finished 79 messages, or combination of both of them, to use. If this is not 80 specified, the concatenation of the client and the server finished 81 TLS messages are used. (client finished message first.) 83 The process by which applications perform "channel binding," that is, 84 the process by which applications establish that the channel bindings 85 for a given TLS connection are observed to be the same at both 86 application ends of the TLS connection is not described here. 88 3. Recommended Application Programming Interfaces 90 TLS implementations supporting the use of initial TLS finished 91 messages as channel bindings should provide application programming 92 interfaces to enable higher level protocol implementations to obtain 93 the initial TLS finished messages for both the client and server 94 endpoints. 96 It is acceptable for the API to provide access to the most recent 97 finished messages although doing so will require that the application 98 be aware of TLS renegotiations in order to ensure that the correct 99 set of TLS finished messages are used. 101 4. IANA Considerations 103 There are no IANA considerations for this document. 105 5. Security Considerations 107 The TLS finished messages section7.4.9 [RFC4346] are known to both 108 TLS endpoints and can therefore be safely used as a channel binding 109 provided that the higher level protocol binding to the TLS channel 110 provides integrity protection for the TLS finished messages and only 111 communicates the TLS finished messages across the TLS channel that it 112 is binding to. 114 If there is an active man-in-the-middle attack, the attacker will 115 already possess knowledge of the TLS finished messages for both 116 inbound and outbound TLS channels. Therefore, there is no additional 117 information obtained by the attacker via the use of the TLS finished 118 messages as a channel binding 120 The Security Considerations section of 121 "draft-williams-on-channel-binding" applies to this document. 123 6. Normative References 125 [I-D.williams-on-channel-binding] 126 Williams, N., "On the Use of Channel Bindings to Secure 127 Channels", draft-williams-on-channel-binding-00 (work in 128 progress), August 2006. 130 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 131 Requirement Levels", BCP 14, RFC 2119, March 1997. 133 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 134 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 136 Authors' Addresses 138 Jeffrey Altman 139 Secure Endpoints Inc. 140 255 W 94TH ST PHB 141 NEW YORK, NY 10025 142 US 144 Email: jaltman@secure-endpoints.com 146 Nicolas Williams 147 Sun Microsystems Inc. 148 5300 Riata Trace Ct 149 Austin, TX 78727 150 US 152 Email: Nicolas.Williams@sun.com 154 Full Copyright Statement 156 Copyright (C) The IETF Trust (2006). 158 This document is subject to the rights, licenses and restrictions 159 contained in BCP 78, and except as set forth therein, the authors 160 retain all their rights. 162 This document and the information contained herein are provided on an 163 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 164 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 165 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 166 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 167 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 168 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 170 Intellectual Property 172 The IETF takes no position regarding the validity or scope of any 173 Intellectual Property Rights or other rights that might be claimed to 174 pertain to the implementation or use of the technology described in 175 this document or the extent to which any license under such rights 176 might or might not be available; nor does it represent that it has 177 made any independent effort to identify any such rights. Information 178 on the procedures with respect to rights in RFC documents can be 179 found in BCP 78 and BCP 79. 181 Copies of IPR disclosures made to the IETF Secretariat and any 182 assurances of licenses to be made available, or the result of an 183 attempt made to obtain a general license or permission for the use of 184 such proprietary rights by implementers or users of this 185 specification can be obtained from the IETF on-line IPR repository at 186 http://www.ietf.org/ipr. 188 The IETF invites any interested party to bring to its attention any 189 copyrights, patents or patent applications, or other proprietary 190 rights that may cover technology that may be required to implement 191 this standard. Please address the information to the IETF at 192 ietf-ipr@ietf.org. 194 Acknowledgment 196 Funding for the RFC Editor function is provided by the IETF 197 Administrative Support Activity (IASA).