Re: HTTP Unprompted Authentication

[Ilari Liusvaara <[e-mail]>]

On Fri, Feb 03, 2023 at 04:30:16PM -0800, David Schinazi wrote:
> Hi HTTP enthusiasts,
> 
> When I presented HTTP unprompted authentication at the last IETF,
> there appeared to be interest in the room but Ben raised some concerns.
> The chairs asked me to resolve those before asking about adoption.
> Ben and I met and were able to resolve them by changing the document
> to reuse the HTTP Authentication Schemes registry instead of defining
> a new one. This change is visible in revision -01:
> https://www.ietf.org/archive/id/draft-schinazi-httpbis-unprompted-auth-01.html
> and a diff is here:
> https://author-tools.ietf.org/iddiff?url2=draft-schinazi-httpbis-unprompted-auth-01
> 
> Chairs, I would now like to ask for an adoption call if you think that's a
> good idea.

- In section 2, I see this text:
------------------------------------------------------------------------
This includes any use of HTTP over TLS as typically used for HTTP/2
[HTTP/2], or HTTP/3 [HTTP/3] where the transport protocol uses TLS as
its authentication and key exchange mechanism [QUIC-TLS].

The user agent leverages a TLS keying material exporter [KEY-EXPORT] to
generate a nonce which can be signed using the user's key. 
------------------------------------------------------------------------

I think implying that it works for any TLS is rather bad, even if there
was security considerations narrowing the scope (which there do not seem
to be).

The problem is that the original TLS 1.2 keying material exporter is
flawed in a way that it can not be safely used for authentication. Now,
either TLS 1.3 or the Extended Master Secret extension fixes this flaw.

The TLS as used in HTTP/3 is TLS 1.3, so it will be okay. But TLS as
used in HTTP/2 can be TLS 1.2 without EMS, which is not okay. And
then there is HTTP/1.1, which has no TLS requirements at all.


- The "TLS SignatureAlgorithm" and "TLS HashAlgorithm" registeries
have been deprecated. A solution would be to just remove the h= and
s= parameters: The server could look those up from the key (precludes
variable-hash RSA keys, but I do not think those are actually
important).


- The signature/HMAC is taken over raw nonce, which I do think is a
good idea. A solution would be using the TLS 1.3 signature format
with some specific label.


- In section 6, it is said that intermediaries will validate the
authentication themselves. It would be possible for intermediary to
export the nonces (which are not sensitive), and send those to the
back-end (I have done PoC implementation of this).




-Ilari