TLS-HTTP channel binding

On 12/02/2013 20:30 PM, Stephen Farrell wrote:
> On 12/02/2013 08:00 PM, Peter Lepeska wrote:
>> Stated more generally, by integrating some TLS logic into the HTTP
>>layer,
>> we can guarantee message integrity and auth and so prevent MITM proxies
>> from operating in stealth mode.
>
>Anyone know if RFC 5705 support made it into the W3C WebCrypto
>API spec and/or implementations?
>
>S.

I cannot find any further discussion on this topic. I think this should be
discussed more. This is also in line with several suggestions in the
position papers to the STRINT workshop
(https://www.w3.org/2014/strint/report.html).

As far as I can see RFC 5705 is only in the informative references of
http://www.w3.org/2012/webcrypto/ Anyone know if its still possible to
change that?

I think it would be good if HTTP 2.0 profiled a secure way to do TLS
channel binding and mandated implementation of that.

This could then be used when doing authentication on the HTTP layer
similar to:

3GPP TS 33.220 (which uses RFC5705)

   "RESP shall be computed as a Digest-response according to RFC 2617 [3]
(HTTP Digest) from the most recent GBA_Digest challenge and a password
'passwd' that is generated as follows:
   passwd = KDF (H(A1), "GBA_Digest_RESP", TLS_MK_Extr)"

   "TLS_MK_Extr is extracted from the TLS master key according to RFC5705"

And 3GPP TS 33.823 (which uses both RFC5705 and RFC5929)

   "After receiving the Ks_(ext)_NAF key from the GBA Function the GBA API
obtains the TLS_MK_Extr, which is extracted from the TLS master key using
the exporter function as specified in RFC 5705 [4]. The label for the
exporter function shall be " TLS_MK_Extr ". The GBA API obtains the
tls-server-endpoint as specified in RFC 5929 [7]. The Ks_js_NAF shall be
derived from Ks_(ext)_NAF as follows:
 Ks_js_NAF = KDF ( Ks_(ext)_NAF, TLS_MK_Extr, tls-server-endpoint )"

John

Received on Friday, 28 February 2014 00:21:25 UTC