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

[Michael Richardson <[e-mail]>]

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

compliment.

    bc> It was meant as a nod to the header name chosen in the example on slide 4
    bc> of

Ah!

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

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

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

My point is to
  a) point to de-facto names which are currently being used to demonstrate
     the need for a standard.
  b) indicate if the contents are the same or different.

    mcr> ** 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.
    >>

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

good, we agree.
Isn't httpbis the obvious WG here?

It could be that we should have two headers.
One for the EE, and one (or many?) for the chain.

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

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

Sure. I'm saying no normative language about another entity.
The normative language should say that reverse proxies MUST remove the header
when coming in.

    >> 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?
    >>

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

It seems like a request that arrives with Client-Cert in it is at best
misconfiguration, and at worse an attack.  It can't be legitimate.
I think that being tolerant here does not benefit anyone.

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