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

[Rifaat Shekh-Yusef <[e-mail]>]

Ok, then we are on the same page.
The reason I am asking is that I have a use case where I need such a
mechanism.

What is the advantage you see for defining a new HTTP header over extending
RFC7239?

Regards,
 Rifaat



On Mon, Oct 28, 2019 at 11:32 AM Brian Campbell <[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.*