Re: [OAUTH-WG] client certs and TLS Terminating Reverse Proxies (was Re: I-D Action: draft-ietf-oauth-jwt-introspection-response-08.txt)

[Hans Zandbelt <[e-mail]>]

+1 to Justin's and Brian's comments, I am interested to contribute and I
will try and be there in person as well

Hans.

On Tue, Oct 29, 2019, 22:56 Brian Campbell <bcampbell=
[e-mail]> wrote:

> +1 to pretty much everything Justin said there.
>
> With some facilitating assistance from Ben it looks like there's now an
> agenda slot for this in the upcoming secdispatch meeting in Singapore. I'll
> attempt to articulate the situation and see if there's interest in finding
> a home for the perspective work. Folks that'll be in Singapore and
> interested in the topic would be encouraged to attend to the secdispatch
> meeting during the Afternoon Session III 1710-1840 on Tuesday.
>
>
> On Tue, Oct 29, 2019 at 1:13 PM Justin Richer <[e-mail]> wrote:
>
>> I would argue that making this standard would actually increase the
>> likelihood of developers getting this right, as now instead of following
>> some copy-pasted recipe for NGINX or Apache that they found on the web,
>> they could turn on a standard setting that would take care of both
>> stripping out incoming headers and injecting the appropriate values. And
>> all of that can be covered in the security considerations with a bunch of
>> normative text on top to make sure inbound headers are stripped. What
>> you’re describing below is clever, but ultimately it’s just a small bit of
>> obscurity more than anything real.
>>
>> The way things are today, you’ve got to not only pick a header and figure
>> out its format, but also do the injection protection step yourself. Since
>> all of these are disconnected, there are a lot more places that it could
>> fall over. Even a typo where you throw out incoming “CLIENT_CERT” but
>> inject “CLIENT_CERTS” or something like that would be disastrous.
>>
>> All in all, I am in favor of this being defined in one standard way, in
>> addition to secure communication between proxies and backends being
>> standardized — but this latter bit really seems like a separate problem.
>>
>>  — Justin
>>
>> On Oct 28, 2019, at 12:32 PM, Neil Madden <[e-mail]>
>> wrote:
>>
>> While there are some benefits to standardizing headers for this kind of
>> communication, there are some significant downsides - particularly when
>> using headers to communicate critical security information like certs. It
>> is *very* easy to misconfigure a reverse proxy to not strip Forwarded (or
>> whatever) headers from incoming requests, allowing a client to simply
>> supply a certificate as a header without authenticating the TLS connection
>> with the corresponding private key. One good practice to prevent this is to
>> pick a random and unguessable header name (configurable per installation)
>> to be used for communicating the certificate, rather than using something
>> fixed and standard. That way even if you misconfigure the proxy an attacker
>> still has to try and guess the correct header name.
>>
>> I suppose the same thing could be accomplished by having an extension for
>> including a shared secret (or HMAC tag) in the header to authenticate it.
>>
>> -- Neil
>>
>> On 28 Oct 2019, at 15:32, Brian Campbell <
>> bcampbell=[e-mail]> wrote:
>>
>> I don't think there's anything beyond defining something to carry the
>> client certificate information (including the format and encoding). And it
>> could well be a new RFC7239 parameter. Or it might just be a new HTTP
>> header on its own.
>>
>> On Mon, Oct 28, 2019 at 9:05 AM Rifaat Shekh-Yusef <[e-mail]>
>> wrote:
>>
>>> Thanks Brian,
>>>
>>> I guess my question is: given RFC7239 and the fact that it is
>>> straightforward to secure the channel between the terminating reverse proxy
>>> and the backend service in a cluster, is there anything, from a standard
>>> perspective, that we need to do beyond defining a new parameter to carry
>>> the client certificate information?
>>> You seem suggest that the answer is yes. If so, can you please elaborate
>>> on why is that?
>>>
>>> Regards,
>>>  Rifaat
>>>
>>>
>>>
>>> On Mon, Oct 28, 2019 at 8:42 AM Brian Campbell <
>>> [e-mail]> wrote:
>>>
>>>>
>>>>
>>>> On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef <
>>>> [e-mail]> wrote:
>>>>
>>>>>
>>>>> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>>
>>>>>> I did look at RFC7239 when doing that and it could have been made to
>>>>>> work but felt the fit wasn't quite right and would have been more
>>>>>> cumbersome to use than not.
>>>>>>
>>>>>>
>>>>> Can you elaborate on this?
>>>>> These days, with the zero trust model in mind, there are orchestration
>>>>> tools, e.g. Istio, that easily allows you to establish an MTLS channel
>>>>> between the reverse proxy/load balancer/API GW and the backend servers.
>>>>> Why is that not sufficient?
>>>>> Which part is cumbersome?
>>>>>
>>>>
>>>> What I meant was only that in the course of writing
>>>> https://tools.ietf.org/html/draft-ietf-tokbind-ttrp-09, which aims to
>>>> define HTTP header fields that enable a TLS terminating reverse proxy to
>>>> convey information to a backend server about the validated Token Binding
>>>> Message received from a client, it seemed more straightforward and
>>>> sufficient for the use-case to use new HTTP headers to carry the
>>>> information rather than to use new fields in the Forwarded header framework
>>>> from RFC7239.
>>>>
>>>>
>>>> *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.*
>>>
>>>
>> *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.*_______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
> *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.*_______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>