Re: [Secdispatch] Request for secdispatch time slot in Vancouver IETF: Client-Cert HTTP Header

[Benjamin Kaduk <[e-mail]>]

On Fri, Mar 27, 2020 at 10:21:17AM -0700, Eric Rescorla wrote:
> Overall, I agree that something like this is needed. However,
> I have two concerns about the mechanism described here.
> 
> First, as you note in S B.1., if the header is not properly
> sanitized, there is a trivial attack and there are stronger
> mechanism that do not require sanitization:
> 
>    "Client-Cert" header that would appear to the backend to have come
>    from the reverse proxy.  Although numerous other methods of
>    detecting/preventing header injection are possible; such as the use
>    of a unique secret value as part of the header name or value or the
>    application of a signature, HMAC, or AEAD, there is no common general
>    standardized mechanism.  The potential problem of client header
>    injection is not at all unique to the functionality of this draft and
>    it would therefor be inappropriate for this draft to define a one-off
>    solution.  In the absence of a generic standardized solution existing
>    currently, stripping/sanitizing the headers is the de facto means of
>    protecting against header injection in practice today.  Sanitizing
> 
> This seems like an odd argument to make: if a strong mechanism is
> in order, we should design one and make it generic, not just throw
> and continue to use weaker mechanisms.
> 
> 
> Second, I think it's quite unwise to only pass the EE cert. This
> means that the server will be unable to independently evaluate
> the cert chain, which (1) is unduly restrictive on the architecture
> because it forces the proxy to do it and (2) means that there
> is no backstop in the case where the proxy makes errors or
> has a not-very-good validator. You should pass the whole chain.
> This also implies that you should have a way to pass extensions
> such as SCTs and stapled OCSP responses.
> 
> 
> Finally, two points about TLS integration.
> 
> 1. You should define how this works in the case of resumption
> of a connection that had client auth. Should the proxy attach the
> chain from the original connection?

Hmm, that requires the proxy to keep that state around (either locally or
in the resumption ticket).  Brainstorming, in TLS 1.3 one could also have
the application manage the authentication state by having the proxy not
issue tickets right at the handshake completion, and instead wait for the
application to return a blob to include in the ticket.  This would provide
a convenient excuse for adding a way to secure the proxy/backend channel,
with the proxy adding a header with a key fingerprint, and the backend
encrypting its response to that key, only if the key is whitelisted in the
application's configuration.  On the other hand, it's more moving parts,
it's TLS 1.3-only (since you can't wait to issue the ticket in 1.2), and
you'd have to have a way to distinguish whether the client cert (chain) or
the application's blob are being passed.  That might mean two or three
header fields going from proxy to backend, and more consistency
checking/error handling to match.

> 
> 2. How do you handle post-handshake client authentication? Specifically:
> (a) How do you handle the situation in which part of the HTTP
> request is covered by the client cert?

HTTP footers come to mind as the obvious channel from proxy to backend
that's available in HTTP and can be used for data that arrives "later".
But it induces perhaps even negative excitement to think of the prospect...

> (b) Post-handshake client authentication allows for the client
> to authenticate with multiple certificates one after the other.
> How is this propagated to the server?

Also, do we care only about the list of what certificates were presented,
the order as well, and/or at what point in the bytestream each occurred?

-Ben

> On Mon, Mar 2, 2020 at 1:51 PM Brian Campbell <bcampbell=
> [e-mail]> wrote:
> 
> > Hello SecDispatchers and Chairs thereof,
> >
> > I'd like to request some time on the agenda in Vancouver to present on
> > https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/
> > in an effort to gauge interest and potentially find an appropriate venue
> > for the work to proceed (or just put it and its ridiculously long title out
> > of its misery).
> >
> > Client-Cert HTTP Header: Conveying Client Certificate Information from
> >      TLS Terminating Reverse Proxies to Origin Server Applications
> >
> > Abstract
> >
> >    This document defines the HTTP header field "Client-Cert" that allows
> >    a TLS terminating reverse proxy to convey information about the
> >    client certificate of a mutually-authenticated TLS connection to an
> >    origin server in a common and predictable manner.
> >
> > Discussion around the value of having something like this defined happened
> > in the OAuth WG a bit before the Singapore meeting (no doubt that's not the
> > only time but it's the one in which I was involved recently) and an AD
> > nudged me to secdispatch -
> > https://mailarchive.ietf.org/arch/msg/oauth/jQ5MAZ1XCvxWbHwqlT3ITEEQoKo/
> > falls somewhere in the middle of that long and sometimes contentious
> > thread. I was unable to get a draft published prior to the I-D submission
> > cut-off for Singapore and got a short "if time allows" presentation slot at
> > the meeting. The judgment coming out of that meeting was "needs draft".
> >
> > I did get an actual draft published a bit after Singapore (the one with
> > the ridiculously long title previously mentioned) and there's been some, if
> > not exactly an overwhelming amount of, discussion and support of it on this
> > very list:
> > https://mailarchive.ietf.org/arch/search/?q=%22draft-bdc-something-something-certificate%22
> >
> > Thanks.
> > Brian Campbell
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > *CONFIDENTIALITY NOTICE: This email may contain confidential and
> > privileged material for the sole use of the intended recipient(s). Any
> > review, use, distribution or disclosure by others is strictly prohibited..
> > If you have received this communication in error, please notify the sender
> > immediately by e-mail and delete the message and any file attachments from
> > your computer. Thank you.*_______________________________________________
> > Secdispatch mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/secdispatch
> >

> _______________________________________________
> Secdispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secdispatch