From channel-binding-bounces@ietf.org Wed Jun 11 08:11:31 2008 Return-Path: X-Original-To: channel-binding-archive@optimus.ietf.org Delivered-To: ietfarch-channel-binding-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3E33A699A; Wed, 11 Jun 2008 08:11:31 -0700 (PDT) X-Original-To: channel-binding@core3.amsl.com Delivered-To: channel-binding@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19203A6A56 for ; Tue, 10 Jun 2008 13:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00Z3PuDi8ofS for ; Tue, 10 Jun 2008 13:41:11 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 59BA33A6943 for ; Tue, 10 Jun 2008 13:41:11 -0700 (PDT) Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.54.46.185) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.1.251.2; Tue, 10 Jun 2008 13:41:34 -0700 Received: from tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com (157.54.18.33) by tk1-exhub-c101.redmond.corp.microsoft.com (157.54.46.185) with Microsoft SMTP Server id 8.1.240.5; Tue, 10 Jun 2008 13:41:34 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by tk5-exmlt-w602.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.33]) with mapi; Tue, 10 Jun 2008 13:41:33 -0700 From: Larry Zhu To: "channel-binding@ietf.org" Date: Tue, 10 Jun 2008 13:41:32 -0700 Thread-Topic: registration for channel binding unique prefix "tls-unique" Thread-Index: AcjLOl2tKQQcwQ5iTrqreWGZZZ5Hkw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 11 Jun 2008 08:11:30 -0700 Cc: "iana@iana.org" , "Nicolas.Williams@sun.com" Subject: [CHANNEL-BINDING] registration for channel binding unique prefix "tls-unique" X-BeenThere: channel-binding@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of channel binding IANA registry requests and specifications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: channel-binding-bounces@ietf.org Errors-To: channel-binding-bounces@ietf.org Subject: Registration of TLS unique channel binding (generic) Channel binding unique prefix: tls-unique Channel binding type: unique Channel type: TLS Published specification: none Channel binding is secret: no Description: The client's TLS Finished messages from the first handshake of the connection (note: connection, not session, so that the channel binding is specific to each connection regardless of whether session resumption is used). Intended usage: COMMON Person and email address to contact for further information: Larry Zhu(lzhu@microsoft.com) Owner/Change controller name and email address: Larry Zhu(lzhu@microsoft.com) Expert reviewer name and contact information: Nicolas Williams (Nicolas.Williams@sun.com) Note: This channel binding construction is thought to not require confidentiality protection. We think this is so because the TLS PRF() should be resistant to key recovery attacks given that it is a simple construction based on HMAC and given the fact that the PRF key used in the Finished message computation is secret. In any event, the most common deployments of TLS always provide for session encryption, and when they don't then Finished messages are sent in clear text. Thus the fact that most authentication mechanisms that support channel binding do not send the original channel binding in clear text over the wire is not even relevant (but if it were then it would be a mitigation should it turn out that TLS Finished messages require confidentiality protection). Note: This registration was initially authored by Nicolas Williams (Nicolas.Williams@sun.com). _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Wed Jun 11 08:11:31 2008 Return-Path: X-Original-To: channel-binding-archive@optimus.ietf.org Delivered-To: ietfarch-channel-binding-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD0D3A6A69; Wed, 11 Jun 2008 08:11:31 -0700 (PDT) X-Original-To: channel-binding@core3.amsl.com Delivered-To: channel-binding@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C4CF3A6AEA for ; Tue, 10 Jun 2008 13:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hs-4SWy9MS8Q for ; Tue, 10 Jun 2008 13:43:52 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 4C0F53A6AB3 for ; Tue, 10 Jun 2008 13:43:49 -0700 (PDT) Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.251.2; Tue, 10 Jun 2008 13:44:12 -0700 Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.88.96) with Microsoft SMTP Server id 8.1.240.5; Tue, 10 Jun 2008 13:44:07 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.79]) with mapi; Tue, 10 Jun 2008 13:44:02 -0700 From: Larry Zhu To: "channel-binding@ietf.org" Date: Tue, 10 Jun 2008 13:44:01 -0700 Thread-Topic: registration for channel binding unique prefix "tls-server-end-point" Thread-Index: AcjLOraEMvTjzXJ1QFyjLKdOIoAVyQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 11 Jun 2008 08:11:30 -0700 Cc: "iana@iana.org" , "Nicolas.Williams@sun.com" Subject: [CHANNEL-BINDING] registration for channel binding unique prefix "tls-server-end-point" X-BeenThere: channel-binding@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of channel binding IANA registry requests and specifications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: channel-binding-bounces@ietf.org Errors-To: channel-binding-bounces@ietf.org Subject: Registration of TLS server end-point channel bindings Channel binding unique prefix: tls-server-end-point Channel binding type: end-point Channel type: TLS Published specification: none Channel binding is secret: no Description: The hash of the TLS server's end entity certificate as it appears, octet for octet, in the server's Certificate message (note that the Certificate message contains a certificate_list, the first element of which is the server's end entity certificate. The hash function to be used is as follows: if the certificate's signature hash algorithm is either MD5 or SHA-1, then use SHA-256, otherwise use the certificate's signature hash algorithm. The reason for using a hash of the certificate is that some implementations need to track the channel binding of a TLS session in kernel-mode memory, which is often at a premium. Intended usage: COMMON Person and email address to contact for further information: Larry Zhu(lzhu@microsoft.com) Owner/Change controller name and email address: Larry Zhu(lzhu@microsoft.com) Expert reviewer name and contact information: Nicolas Williams (Nicolas.Williams@sun.com) Note: This registration was initially authored by Nicolas Williams (Nicolas.Williams@sun.com). _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www.ietf.org/mailman/listinfo/channel-binding From channel-binding-bounces@ietf.org Wed Jun 11 08:11:32 2008 Return-Path: X-Original-To: channel-binding-archive@optimus.ietf.org Delivered-To: ietfarch-channel-binding-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055A13A6A85; Wed, 11 Jun 2008 08:11:32 -0700 (PDT) X-Original-To: channel-binding@core3.amsl.com Delivered-To: channel-binding@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF42B3A6AB3 for ; Tue, 10 Jun 2008 13:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAVX1yoEsdbA for ; Tue, 10 Jun 2008 13:45:17 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 83D803A68A9 for ; Tue, 10 Jun 2008 13:45:16 -0700 (PDT) Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.1.251.2; Tue, 10 Jun 2008 13:45:39 -0700 Received: from TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com (157.54.18.79) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.18.48) with Microsoft SMTP Server id 8.1.240.5; Tue, 10 Jun 2008 13:45:38 -0700 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::8de9:51a2:cd62:f122]) by TK5-EXMLT-W605V.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.79]) with mapi; Tue, 10 Jun 2008 13:45:31 -0700 From: Larry Zhu To: "channel-binding@ietf.org" Date: Tue, 10 Jun 2008 13:45:29 -0700 Thread-Topic: registration for channel binding unique prefix "tls-unique-for-telnet" Thread-Index: AcjLOusThhwZ8s8MRjKebg8VaZH2GQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 11 Jun 2008 08:11:30 -0700 Cc: "iana@iana.org" , "Nicolas.Williams@sun.com" Subject: [CHANNEL-BINDING] registration for channel binding unique prefix "tls-unique-for-telnet" X-BeenThere: channel-binding@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of channel binding IANA registry requests and specifications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: channel-binding-bounces@ietf.org Errors-To: channel-binding-bounces@ietf.org Subject: Registration of TLS unique channel binding (specific to TELNET) Channel binding unique prefix: tls-unique-for-telnet Channel binding type: unique Channel type: TLS Published specification: none Channel binding is secret: no Description: There is a proposal for adding a "StartTLS" extension to TELNET, and a channel binding extension for the various TELNET AUTH mechanisms whereby each side sends the other a "checksum" (MAC) of their view of the channel's bindings. The client uses the first TLS Finished messages from the client and server each are concatenated in that order and in their clear text form. The server does the same but in the opposite concatenation order (server, then client). Intended usage: COMMON Person and email address to contact for further information: Jeff Altman Owner/Change controller name and email address: Jeff Altman Expert reviewer name and contact information: Nicolas Williams (Nicolas.Williams@sun.com) Note: This channel binding construction is thought to not require confidentiality protection. We think this is so because the TLS PRF() should be resistant to key recovery attacks given that it is a simple construction based on HMAC and given the fact that the PRF key used in the Finished message computation is secret. In any event, the most common deployments of TLS always provide for session encryption, and when they don't then Finished messages are sent in clear text. Thus the fact that most authentication mechanisms that support channel binding do not send the original channel binding in clear text over the wire is not even relevant (but if it were then it would be a mitigation should it turn out that TLS Finished messages require confidentiality protection). Note: This registration was initially authored by Nicolas Williams (Nicolas.Williams@sun.com). _______________________________________________ CHANNEL-BINDING mailing list CHANNEL-BINDING@ietf.org https://www.ietf.org/mailman/listinfo/channel-binding