Re: [OAUTH-WG] MTLS token endoint & discovery

[Brian Campbell <[e-mail]>]

Perhaps it's due to my own lack of imagination but I don't see any new
vectors or how the existing mitigations don't work here too. Please propose
some text though, if there's something that should be in the document.

On Tue, Feb 12, 2019 at 8:50 AM Justin Richer <[e-mail]> wrote:

> At the moment, I like this suggestion. It feels a little … funny … but
> that might be just because it’s different from what we had before.
>
> We’ll need to have a clear security considerations discussion about this
> though, as it does add another vector for a mix-up attack. I doubt that at
> this stage we want to say that there has to be any testable relationship
> between the values in token_endpoint and mtls_endpoints.token_endpoint, but
> splitting the authorization and token endpoints in the discovery document
> is exactly what lead to the mix-up attack pattern in the first place.
> Essentially, what happens when an attacker crafts a document that says the
> MTLS token endpoint is theirs and the regular token endpoint is legit, or
> vice versa?
>
> — Justin
>
> On Feb 11, 2019, at 7:26 AM, Brian Campbell <
> bcampbell=[e-mail]> wrote:
>
> It's been pointed out that the potential issue is not isolated to the just
> token endpoint but that revocation, introspection, etc. could be impacted
> as well. So,  at this point, the proposal on the table is to add a new
> optional AS metadata parameter named 'mtls_endpoints' that's value we be a
> JSON object which itself contains endpoints that, when present, a client
> doing MTLS would use rather than the regular endpoints.  A straw-man
> example might look like this
>
> {
>   "issuer":"https://server.example.com",
>   "authorization_endpoint":"https://server.example.com/authz",
>   "token_endpoint":"https://server.example.com/token",
>   "token_endpoint_auth_methods_supported":[
>  "client_secret_basic","tls_client_auth", "none"],
>   "userinfo_endpoint":"https://server.example.com/userinfo",
>   "revocation_endpoint":"https://server.example.com/revo",
>   "jwks_uri":"https://server.example.com/jwks.json",
>
>
>
>
> * "mtls_endpoints":{     "token_endpoint":"https://mtls.example.com/token
> <https://mtls.example.com/token>",
> "userinfo_endpoint":"https://mtls.example.com/userinfo
> <https://mtls.example.com/userinfo>",
> "revocation_endpoint":"https://mtls.example..com/revo
> <https://mtls.example.com/revo>"   }*
> }
>
>
> A client doing MTLS would look for and give precedence to an endpoint
> under "mtls_endpoints" while falling back to use the normal endpoint from
> the top level of metadata when/if its not in "mtls_endpoints".
>
> The idea being that "regular" clients (those not doing MTLS) will use the
> regular endpoints. And only the host/port of the endpoints listed in
> mtls_endpoints will be set up to request TLS client certificates during
> handshake. Thus any potential impact of the CertificateRequest message
> being sent in the TLS handshake can be avoided for all the other regular
> clients that are not going to do MTLS - including and most importantly
> in-browser javascript clients where there can be less than desirable UI
> presented to the end-user.
>
> I'm struggling, however, to adequately gauge whether or not there's
> sufficient consensus to go ahead with the update. There's been some support
> for it voiced. As well as talk of other approaches that could be
> alternatives or additional measures. And also some vocal opposition to it.
>
>
>
> On Sat, Feb 9, 2019 at 3:09 AM Dominick Baier <[e-mail]>
> wrote:
>
>> We are currently implementing MTLS in IdentityServer.
>>
>> Our approach will be that we’ll offer a separate token endpoint that
>> supports client certs. Are you planning on adding an official endpoint name
>> for discovery? Right now we are using “mtls_token_endpoint”.
>>
>> Thanks
>> ———
>> Dominick
>>
>> On 7. February 2019 at 22:36:55, Brian Campbell (
>> bcampbell=[e-mail]) wrote:
>>
>> Ah yes, that makes sense. Thanks for clarifying. And it is indeed a good
>> reminder that even a seemingly innocuous change that should be backwards
>> compatible can break things unexpectedly..
>>
>>
>>
>>
>>
>> On Thu, Feb 7, 2019 at 8:57 AM Richard Backman, Annabelle <
>> [e-mail]> wrote:
>>
>>> The case I’m referencing didn’t specifically involve AS metadata. We had
>>> clients in the wild that assumed that all the properties in the JSON object
>>> returned from our userinfo endpoint were scalar strings. This broke when we
>>> introduced a new property whose value was a JSON object. It was a good
>>> reminder that even a seemingly innocuous change that should be backwards
>>> compatible can force more work on clients than we expect.
>>>
>>>
>>> --
>>>
>>> Annabelle Richard Backman
>>>
>>> AWS Identity
>>>
>>>
>>>
>>> *From:* Brian Campbell <[e-mail]>
>>> *Date:* Wednesday, February 6, 2019 at 11:30 AM
>>> *To:* "Richard Backman, Annabelle" <richanna=[e-mail]
>>> >
>>> *Cc:* "Richard Backman, Annabelle" <[e-mail]>, oauth <
>>> [e-mail]>
>>> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser
>>> clients using the token endpoint
>>>
>>>
>>> And I'm honestly really struggling to see what could have gone wrong
>>> with or how token_endpoint_auth_methods broke something with the user info
>>> endpoint. If you have the time and/or it'd be informative to this here
>>> little discussion, please explain that one a bit more.
>>>
>>>
>>> On Wed, Feb 6, 2019 at 12:15 PM Brian Campbell <
>>> [e-mail]> wrote:
>>>
>>> "far" should have said "fair" in the previous message
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Feb 5, 2019 at 4:35 PM Brian Campbell <
>>> [e-mail]> wrote:
>>>
>>> It may well be due to my own intellectual shortcomings but these
>>> issues/questions/confusion-points are not resonating for me as being
>>> problematic.
>>>
>>>
>>> The more general stance of "this isn't needed or worth it in this
>>> document" (I think that's far?) is being heard though.
>>>
>>>
>>>
>>>
>>> On Tue, Feb 5, 2019 at 1:42 PM Richard Backman, Annabelle <richanna=
>>> [e-mail] <[e-mail]...org>> wrote:
>>>
>>> (TL;DR: punt AS metadata to a separate draft)
>>>
>>> AS points #1-3 are all questions I would have as an implementer:
>>>
>>>    1. Section 2 of RFC8414
>>>    <https://tools.ietf.org/html/rfc8414#section-2> says token_endpoint
>>>    “is REQUIRED unless only the implicit grant type is supported.” So what
>>>    does the mTLS-only AS put here?
>>>    2. The claims for these other endpoints are OPTIONAL, potentially
>>>    leading to inconsistency depending on how #1 gets decided.
>>>    3. The example usage of the token_endpoint_auth_methods property
>>>    given earlier is incompatible with RFC8414, since some of its contents are
>>>    only valid for the non-mTLS endpoints, and others are only valid for the
>>>    mTLS endpoints. Hence this question.
>>>    4. This introduces a new metadata property that could impact how
>>>    other specs should extend AS metadata. That needs to be addressed.
>>>
>>>
>>>
>>> I could go on for client points but you already get the point. Though
>>> I’ll share that #3 is real and once forced me to roll back an update to the
>>> Login with Amazon userinfo endpoint…good times. 😃
>>>
>>>
>>> I don’t necessarily think an AS metadata property is wrong per se, but
>>> understand that you’re bolting a layer of flexibility onto a standard that
>>> wasn’t designed for that, and I don’t think the metadata proposal as it’s
>>> been discussed here sufficiently deals with the fallout from that. In my
>>> view this is a complex enough issue and it’s for a nuanced enough use case
>>> (as far as I can tell from discussion? Please correct me if I’m wrong) that
>>> we should punt it to a separate draft (e.g., “Authorization Server Metadata
>>> Extensions for mTLS Hybrids”) and get mTLS out the door.
>>>
>>>
>>> --
>>>
>>> Annabelle Richard Backman
>>>
>>> AWS Identity
>>>
>>>
>>>
>>> *From:* OAuth <[e-mail]> on behalf of Brian Campbell
>>> <bcampbell=[e-mail]>
>>> *Date:* Monday, February 4, 2019 at 5:28 AM
>>> *To:* "Richard Backman, Annabelle" <richanna=[e-mail]
>>> >
>>> *Cc:* oauth <[e-mail]>
>>> *Subject:* Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: MTLS and in-browser
>>> clients using the token endpoint
>>>
>>>
>>> Those points of confusion strike me as somewhat hypothetical or
>>> hyperbolic. But your general point is taken and your position of being anti
>>> additional metadata on this issue is noted.
>>>
>>>
>>> All of which leaves me a bit uncertain about how to proceed. There seem
>>> to be a range of opinions on this point and gauging consensus is proving
>>> elusive for me. That's confounded by my own opinion on it being somewhat
>>> fluid.
>>>
>>>
>>> And I'd really like to post an update to this draft about a month or two
>>> ago.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Feb 1, 2019 at 5:03 PM Richard Backman, Annabelle <richanna=
>>> [e-mail] <[e-mail]...org>> wrote:
>>>
>>> Confusion from the AS’s perspective:
>>>
>>>    1. If I only support mTLS, do I need to include both
>>>    token_endpoint_uri and mtls_endpoints? Should I omit token_endpoint_uri? Or
>>>    set it to the empty string?
>>>    2. What if I only support mTLS for the token endpoint, but not
>>>    revocation or user info?
>>>    3. How do I specify authentication methods for the mTLS token
>>>    endpoint? Does token_endpoint_auth_methods apply to both the mTLS and
>>>    non-mTLS endpoints?
>>>    4. I’m using the OAuth 2.0 Device Flow. Do I include a mTLS-enabled
>>>    device_authorization_endpoint under mtls_endpoints?
>>>
>>>
>>>
>>> Confusion from the client’s perspective:
>>>
>>>    1. As far as I know, I’m a public client, and don’t know anything
>>>    about mTLS, but the IT admins installed client certs in their users’
>>>    browsers and the AS expects to use that to authenticate me.
>>>    2. My AS metadata parser crashed because the mTLS-only AS omitted
>>>    token_endpoint_uri.
>>>    3. My AS metadata parser crashed because it didn’t expect to
>>>    encounter a JSON object as a parameter value.
>>>    4. The mTLS-only AS didn’t provide a value for mtls_endpoints, what
>>>    do I do?
>>>    5. I don’t know what that “m” means, but they told me to use HTTPS,
>>>    so I should use the one with “tls” in its name, right?
>>>
>>>
>>>
>>> Yes, you can write normative text that answers most of these. But you’ll
>>> have to clearly cover a lot of similar-but-slightly-different scenarios and
>>> be very explicit. And implementers will still get it wrong. The metadata
>>> change introduces opportunities for confusion and failure that do not exist
>>> now, and forces them on everyone who supports mTLS. In contrast, the 307
>>> redirect is only required when an AS wants to support both, and is
>>> unambiguous in its behavior and meaning.
>>>
>>>
>>> --
>>>
>>> Annabelle Richard Backman
>>>
>>> AWS Identity
>>>
>>>
>>>
>>> *From:* Brian Campbell <bcampbell=[e-mail]>
>>> *Date:* Friday, February 1, 2019 at 3:17 PM
>>> *To:* "Richard Backman, Annabelle" <[e-mail]>
>>> *Cc:* George Fletcher <[e-mail]>, oauth <[e-mail]>
>>> *Subject:* [UNVERIFIED SENDER] Re: [OAUTH-WG] MTLS and in-browser
>>> clients using the token endpoint
>>>
>>>
>>> It doesn't seem like that confusing or large of a change to me - if the
>>> client is doing MTLS and the given endpoint is present in `mtls_endpoints`,
>>> then it uses that one.  Otherwise it uses the regular endpoint. It gives an
>>> AS a lot of flexibility in deployment options. I personally think getting a
>>> 307 approach deployed and working would be more complicated and error
>>> prone.
>>>
>>>
>>> It is a minority use case at the moment but there are forces in play,
>>> like the push for increased security in general and to have javascript
>>> clients use the code flow, that suggest it won't be terribly unusual to see
>>> an AS that wants to support MTLS clients and javascript/spa clients at the
>>> same time.
>>>
>>>
>>> I've personally wavered back and forth in this thread on whether or not
>>> to add the new metadata (or something like it). With my reasoning each way
>>> kinda explained somewhere back in the 40 or so messages that make up this
>>> thread.  But it seems like the rough consensus of the group here is in
>>> favor of it.
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Feb 1, 2019 at 3:18 PM Richard Backman, Annabelle <richanna=
>>> [e-mail] <[e-mail]...org>> wrote:
>>>
>>> This strikes me as a very prominent and confusing change to support what
>>> seems to be a minority use case. I’m getting a headache just thinking about
>>> the text needed to clarify when the AS should provide `mtls_endpoints` and
>>> when the client should use that versus using `token_endpoint.` Why is the
>>> 307 status code insufficient to cover the case where a single AS supports
>>> both mTLS and non-mTLS?
>>>
>>>
>>> --
>>>
>>> Annabelle Richard Backman
>>>
>>> AWS Identity
>>>
>>>
>>>
>>> *From:* OAuth <[e-mail]> on behalf of Brian Campbell
>>> <bcampbell=[e-mail]>
>>> *Date:* Friday, February 1, 2019 at 1:31 PM
>>> *To:* George Fletcher <gffletch=[e-mail]
>>> <40aol.com@dmarc......ietf.org>>
>>> *Cc:* oauth <[e-mail]>
>>> *Subject:* Re: [OAUTH-WG] MTLS and in-browser clients using the token
>>> endpoint
>>>
>>>
>>> Yes, that would work.
>>>
>>>
>>> On Fri, Feb 1, 2019 at 2:28 PM George Fletcher <gffletch=
>>> [e-mail]> wrote:
>>>
>>> What if the AS wants to ONLY support MTLS connections. Does it not
>>> specify the optional "mtls_endpoints" and just use the normal metadata
>>> values?
>>>
>>> On 1/15/19 8:48 AM, Brian Campbell wrote:
>>>
>>> It would definitely be optional, apologies if that wasn't made clear.
>>> It'd be something to the effect of optional for the AS to include and
>>> clients doing MTLS would use it when present in AS metadata.
>>>
>>>
>>> On Tue, Jan 15, 2019 at 2:04 AM Dave Tonge <[e-mail]>
>>> wrote:
>>>
>>> I'm in favour of the `mtls_endpoints` metadata parameter - although it
>>> should be optional.
>>>
>>>
>>> *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 <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.*
>>>
>>>
>>> *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.*
>>>
>>>
>>> *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
>>
>>
> *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
>
>
>

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