W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

TLS-HTTP channel binding

From: John Mattsson <john.mattsson@ericsson.com>
Date: Fri, 28 Feb 2014 00:21:00 +0000
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
CC: Peter Lepeska <bizzbyster@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <CF3586EC.D62B%john.mattsson@ericsson.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC