(last updated 2008-06-26)

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
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).

(file created 2008-06-26)