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

On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell <[e-mail]>
wrote:

> Few thoughts, comments, & questions.
>
> I've always kind of assumed that the ship had already sailed on doing
> anything standards related with this because implementations out in the
> wild like Apache, NGNIX, IIS, etc. were already providing ad hoc
> solutions and had been doing so for a long time. But this thread at least
> hints that there may yet be an appetite for such a standardization effort?
>
> I'll be in Singapore but my (long) flight is scheduled to land about the
> time when HotRFC starts. I could perhaps do something for secdispatch
> though. Ben, is a draft needed for that or can secdispatch be engaged with
> some slides amounting to a problem statement? I'm just not confident a
> draft could be published in the next week or so before the cut off.
>
> I did put it some work on a conceptually similar issue around token
> binding with "HTTPS Token Binding with TLS Terminating Reverse Proxies" -
> https://datatracker.ietf.org/doc/draft-ietf-tokbind-ttrp/ not too long
> ago. It was a WG item that had gone through WGLC but kinda stalled out
> waiting on the chair(s) for the shepard writeup when adoption questions
> around token binding came up.
>
> There are lots of ways to approach the problem and solution but I think
> perhaps a lot could be taken from that document and applied to the similar
> client cert situation.
>
> 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?

Regards,
 Rifaat




>
>
> On Fri, Oct 25, 2019 at 8:02 AM Rifaat Shekh-Yusef <[e-mail]>
> wrote:
>
>> You might want to look at RFC7239, which is trying to address the issue
>> of the loss of information by proxies.
>> https://tools.ietf.org/html/rfc7239
>>
>> The document does not have a parameter to carry the client certificate
>> information, but it allows for new parameters to be defined.
>>
>> Would that help in this case?
>>
>> Regards,
>>  Rifaat
>>
>>
>> On Thu, Oct 24, 2019 at 1:03 PM Benjamin Kaduk <[e-mail]> wrote:
>>
>>> On Wed, Oct 23, 2019 at 10:13:04AM -0400, Justin Richer wrote:
>>> >    I also agree. Would it be possible to get this pushed to http or
>>> tls? It
>>> >    would be more appropriate there, and very helpful to have a general
>>> spec
>>> >    for this.
>>>
>>> I think it's possible to get such work done in one of those places, but
>>> first someone has to actually write a draft.  Barring that, a HotRFC or
>>> secdispatch slot in Singapore would probably be good for drumming up
>>> interest.  In related news, I am told that draft-duke-quic-load-balancers
>>> had some time in the QUIC interim this month, and may be moving towards
>>> adoption, so time may be short if we want to have a fully general
>>> solution.
>>>
>>> -Ben
>>>
>>> _______________________________________________
>>> 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.*