Re: Client-Cert Header draft

Apologies for the slow reply. And thanks for the support of the idea and
suggestions. At this point, while this is still just an unadopted
individual draft, I think I'd categorize the suggestion as another voice of
support for something more to be done directly with respect to protecting
the header from injection. Using the server certificate and an asymmetric
signature is an approach to that (which I admittedly hadn't thought much
about) which would have its pros and cons.



On Tue, Apr 21, 2020 at 4:17 PM Graham Leggett <minfrin@sharp.fm> wrote:

> On 15 Apr 2020, at 23:01, Brian Campbell <bcampbell@pingidentity.com>
> wrote:
>
> I've somewhat inadvertently found myself working on this draft
> https://datatracker.ietf.org/doc/draft-bdc-something-something-certificate/,
> which aspires to define a "Client-Cert" HTTP header field 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.
>
>
> Big +1 for this.
>
> I added JWT support to Apache httpd/apr in an effort to solve this
> problem, having one single header would be vastly simpler.
>
> I presented the concept
> <https://datatracker.ietf.org/meeting/107/materials/slides-107-secdispatch-client-cert-http-header-00>
> at the recent virtual IETF 107 secdispatch meeting
> <https://datatracker.ietf.org/meeting/107/materials/minutes-107-secdispatch-00>
> and the outcome from that was basically that there seems to be some
> interest in pursuing the work and the suggestion that the conversation be
> taken to the HTTPbis WG (and also keep TLS WG involved - presumably if the
> work progresses). And that's what brings me here. I also hope to get a
> little bit of time at one of the upcoming virtual interims to
> present/discuss the draft.
>
>
> Having read the draft, one thing I would suggest is that the ability
> exists for the contents of the Client-Cert header to be signed, so that
> anyone who cares can verify that the header came from where it said it came
> from.
>
> To simplify this even further, if the Client-Cert header was signed by the
> private key of the certificate of the server that terminated the request, a
> lot of complexity around figuring out the origin of the header evaporates.
> (I wouldn’t make this a MUST requirement, but maybe RECOMMENDED perhaps).
>
> As an optional one step further I personally would then connect the
> terminating reverse proxy and the backend with a client certificate
> connection using the TTRP reverse proxy’s certificate. The backend can then
> verify the client certificate (the TTRP cert) as being expected, then
> verify that the Client-Cert header was signed with the TTRP certificate. If
> this checks out, and we trust the TTRP as having not been tampered with, we
> have a strong path.
>
> "A certificate is represented in text as an "EncodedCertificate",
>    which is the base64-encoded (Section 4 of [RFC4648]) DER [ITU.X690]
>    PKIX certificate.”
>
> To do this the payload of the Client-Cert header would be a base64 of a
> DER encoded RFC5652 CMS/PKCS7. The payload would be the DER encoded X509
> client certificate, and the CMS would be the signed envelope.
>
> Regards,
> Graham
> —
>
>

-- 
_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._