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 <[email protected]> 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 <[email protected]> > 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 < >> [email protected]> wrote: >> >>> >>> >>> On Sat, Oct 26, 2019 at 3:55 PM Rifaat Shekh-Yusef < >>> [email protected]> wrote: >>> >>>> >>>> On Fri, Oct 25, 2019 at 3:47 PM Brian Campbell < >>>> [email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
