Opened 8 years ago

Closed 7 years ago

#2 closed defect (fixed)

Use TLS Channel Binding for tls-key

Reported by: ynir@… Owned by: draft-ietf-httpauth-mutual@…
Priority: major Milestone:
Component: mutual Version:
Severity: Submitted WG Document Keywords: Channel Binding, tls-key


Reported by Ilari, Stephen, Yaron

Section 7,:

tls-key: TLS shared-key validation: The value v will be the

octet string of the shared master secret negotiated in
the underlying TLS (or SSL) connection.

Any reason to deviate from tls-unique of RFC 5929 (Channel Binding, Standards Track), which uses latest finished message instead?

Change History (3)

comment:1 Changed 8 years ago by nico@…

Absolutely. We discussed the use of TLS key material exporter when developing RFC5929 and we concluded that the Finished message construction was qualitatively stronger than the key material exporter as *channel binding*. Use of anything else as a channel binding (whether stated as such) should be justified.

comment:2 Changed 8 years ago by y.oiwa@…

Adopted two RFC5929 key binding mechanisms (tls-unique and tls-server-end-point) in -01 draft, replacing tls-key and tls-cert respectively.

One minor issue (checking/accepting strength of tls-server-end-point) is left to close this issue.

comment:3 Changed 7 years ago by mlepinski.ietf@…

  • Resolution set to fixed
  • Status changed from new to closed

Closing this issue. The latest version of the draft now includes support for RFC 5929 mechanisms.

Note: See TracTickets for help on using tickets.