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

[Brian Campbell <[e-mail]>]

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.



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