This page (revision-1) was last changed on 29-Nov-2024 16:16 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Page revision history

Version Date Modified Size Author Changes ... Change note

Page References

Incoming links Outgoing links

Version management

Difference between version and

At line 1 added 27 lines
!!! Overview
[{$pagename}] ([RFC 5929]) defines three [Channel Binding Types] ([RFC 5056]) for Transport Layer Security (TLS)
!! tls-server-end-point Channel Binding Type
The [hash] of the [TLS] server's [certificate] [RFC 5280] as it appears, octet for octet, in the server's [Certificate] [message].
Note that the Certificate message contains a certificate_list, in which the first element is the server's certificate.
The [hash] function is to be selected as follows:
* if the certificate's [signatureAlgorithm] uses a single [Hash Function], and that hash function is either [MD5] [RFC 1321] or [SHA-1] [RFC 3174], then use [SHA-256] [FIPS 180]-3;
* if the certificate's [signatureAlgorithm] uses a single __hash function__ and that hash function neither [MD5] nor [SHA-1], then use the [Hash Function] associated with the certificate's [signatureAlgorithm];
* if the certificate's [signatureAlgorithm] uses no [Hash Function] or uses multiple hash functions, then this channel binding type's [Channel Binding] are undefined at this time (updates to is channel binding type may occur to address this issue if it ever arises).
!! tls-unique Channel Binding Type
The first [TLS-Finished] message sent (note: the [TLS-Finished] struct, not the [TLS] [Record Protocol] [message] containing it) in the most recent [TLS Handshake] of the TLS connection being bound to (note: TLS connection, not session, so that the channel binding is specific to each connection regardless of whether session resumption is used).
!! tls-unique-for-telnet Channel Binding Type
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] ([Message Authentication Code]) of their view of the channel's bindings.
The [client] uses the [TLS Finished] messages (note: the Finished struct) sent by the [client] and [server], each concatenated in that order and in their [cleartext] form, of the first [TLS handshake] to which the connection is being bound. The [server] does the same but in the opposite concatenation order (server, then client).
!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]