[CHANNEL-BINDING] registration for channel binding unique prefix "tls-unique-for-telnet"

Larry Zhu <lzhu@windows.microsoft.com> Wed, 11 June 2008 15:11 UTC

Return-Path: <channel-binding-bounces@ietf.org>
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 <channel-binding@core3.amsl.com>; 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 <channel-binding@core3.amsl.com>; 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 <channel-binding@ietf.org>; 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 <lzhu@windows.microsoft.com>
To: "channel-binding@ietf.org" <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: <AB1E5627D2489D45BD01B84BD5B900460618301EF9@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
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" <iana@iana.org>, "Nicolas.Williams@sun.com" <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 <channel-binding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/channel-binding>, <mailto:channel-binding-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/channel-binding>
List-Post: <mailto:channel-binding@ietf.org>
List-Help: <mailto:channel-binding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/channel-binding>, <mailto:channel-binding-request@ietf.org?subject=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 <jaltman@secure-endpoints.com>
Owner/Change controller name and email address: Jeff Altman <jaltman@secure-endpoints.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