Re: [Secdispatch] [saag] SECDISPATCH WG Summary from IETF 106

[Brian Campbell <[e-mail]>]

Thanks Michael for the read of the document and feedback. Some responses
are inline.

On Sun, Jan 19, 2020 at 9:52 AM Michael Richardson <[e-mail]>
wrote:

>
> Thanks for this document.
> I think it is useful and important work.
> {"something-something" sounds like something that Winnie the Pooh would
> ask to
> eat for lunch}
>

Via email exchange it's not entirely clear whether that's a compliment or a
criticism or just an observation.

It was meant as a nod to the header name chosen in the example on slide 4
of
https://datatracker.ietf.org/meeting/106/materials/slides-106-secdispatch-securing-protocols-between-proxies-and-backend-http-servers-00
which was there as a semi-humorous placeholder of a name to indicate that
the name is both important and unimportant at the same time.


> draft-ietf-anima-bootstraping-keyinfra (aka BRSKI) makes use of TLS Client
> Certificates in the Registrar.
> I have a document on operational considerations for Registrars,
>   draft-richardson-anima-registrar-considerations
> and I've added your document as reference.
>
> In section 1, you may wish to reference:
>    https://en.wikipedia.org/wiki/Web_Server_Gateway_Interface
>
> although I can't find a section in
> https://www.python.org/dev/peps/pep-3333/
> that describes the Client Certificate variable.  I use "SSL_CLIENT_CERT"
> and more recently, "rack.peer_cert" in my code.
>

AFAIK, those are de facto names originating out of defaults or
documentation from reverse proxy implementations that allow for similar
behaviour with respect to the client cert. Apache mod_ssl and Ruby thin
respectively I think.

For better or worse, I tried to choose a name that's meaningful and
shortish. And one that doesn't look like it came from the default
documentation of some popular web server.


** I would like to have access to the entire client certificate *chain* **
> Not just the End-Entity certificate.
>
> If any internal trust anchors were used to validate the chain, I also would
> prefer to receive them as well.
>
> Finally, I need to be able to configure the reverse proxy to do the TLS
> operation on the assumption that the certificate validates, even if the
> reverse proxy does not know how to validate the certificate chain itself.
>
> I need, therefore, to know if the certificate chain was validated, or not.
>

In writing up this initial draft, I waffled about whether or not to include
intermediate signers and/or the whole chain. Although I landed on only
passing the leaf certificate, this is certainly something that's up for
discussion should this document find a home where it can be worked on and
progressed.



> You write:
>   Forward proxies and other intermediaries MUST NOT add the Client-Cert
> header to requests.
>
> but, the reverse proxy can not control what is sent to it, and you
> shouldn't
> try to write normative language there.
>

True, the reverse proxy can not control what is sent to it. But it's meant
to be normative language towards other forward proxies and other
intermediaries to say that they can't/shouldn't be adding this thing. Which
seems legit (and something I'm told is supposed to be covered for registry
requests on header fields). Perhaps that text can be moved or adjusted in a
way that makes the distinction more clear.



>
> You already handle this:
>   2) Any occurrence of the Client-Cert header in the original incoming
>      request MUST be removed or overwritten before forwarding the request.
>
> and leave it like that, maybe emphasis this.
> Maybe reverse proxies SHOULD reject requests that have a Client-Cert header
> in them, period?
>

That's certainly an option. I suppose there are tradeoffs between rejecting
vs. cleaning such requests. Maybe a MAY would be appropriate for something
like that so as to give the proxy the option. Again, that's something that
could be fleshed out in discussions if this thing finds a home.



>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>

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