Re: [Txauth] New Version Notification for draft-hardt-xauth-protocol-03.txt

[Justin Richer <[e-mail]>]

Working with that kind of setup, where you’ve got two different users at the client and the AS, is the driving goal behind CIBA and UMA, and in some instances, the device flow. All of these have a polling mechanism that allows an asynchronous update.

In XYZ, the client explicitly signals this kind of expectation by not sending a “callback” field in its request, indicating that it doesn’t expect the approving user to get returned through the front channel. It’s not just about signaling the client about when to poll next, it’s about signaling the intent to poll at all.

It’s a different security profile that both the AS and the Client need to know about, since it might not be appropriate for all different forms of access. 

XYZ (and to some extent XAuth) also allows the client to present information about the current user at the client so that the AS can figure out if it expects the same user or a different user during the interactive bits by allowing things to be passed in the “user” object of the request. It’s not just there as a login hint, at least in XYZ. There are some details from UMA and CIBA that we can import, like the user-displayed confirmation codes and the like, that can help security and usability of the overall protocol. But as is the case with just about everything in XYZ, I didn’t want to add it to the spec document until I’d implemented it to make sure that it made sense to carry that information through to the different parties.

 — Justin

> On Feb 28, 2020, at 5:56 PM, Dick Hardt <[e-mail]> wrote:
> 
> Thinking about this, the fixation attack is against the Client where the attacker is at the Client, and the victim is at the AS.
> 
> Does the AS need to know the attacker and victim are different? IE, if the client knows that the User at the Client is the same as the User that came from the AS, have we prevented the attack?
> ᐧ
> 
> On Tue, Feb 25, 2020 at 7:38 AM Justin Richer <[e-mail] <mailto:[e-mail]>> wrote:
> That’s good enough for the AS, but is it good enough for the client? The hash allows the client to make sure that the reference they’re getting back in the front channel is related to something they sent out in the first place. We originally had a “state” parameter like OAuth 2 for this purpose, but realized that since the client can push its callback URI we didn’t need that. But to get the kind of functionality that “nonce” and “c_hash” have in OIDC, we added this simple hash parameter that the client can check before it calls the TX endpoint again.
> 
>  — Justin
> 
>> On Feb 21, 2020, at 8:12 PM, Dick Hardt <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 
>> The Client presents the interact_ref to the AS with the transaction handle. The AS will be able to tell the Client if the interact_ref belongs to the transaction.
>> 
>> Why is that enough?
>> ᐧ
>> 
>> On Fri, Feb 21, 2020 at 1:51 PM Justin Richer <[e-mail] <mailto:[e-mail]>> wrote:
>> The hash offers the same kinds of protections to the client that the OIDC nonce does — it binds the front channel return to something you get from the back channel. 
>> 
>> In other words, the client can be sure that the return value that it’s getting is related to the request it made in the first place, and not another one. Clients using per-request redirect URIs can also help with this, but this is something that the server can provide directly.
>> 
>>  — Justin
>> 
>>> On Feb 21, 2020, at 4:14 PM, Dick Hardt <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> While I can see the value of the interact_ref (aka interaction_ref) in the return URI that allows the Client to ensure the user that started the transaction is the same one that interacted at the AS, I don't understand why a hash is required. Would you elaborate?
>>> ᐧ
>>> 
>>> On Fri, Feb 21, 2020 at 1:02 PM Justin Richer <[e-mail] <mailto:[e-mail]>> wrote:
>>> But that’s exactly the point — it helps in that case, which is a very common case. For cases where the client doesn’t expect the user to come back on the same channel, then they don’t use the callback mechanism. They might use the “finish message” URL that Annabelle mentioned in the other thread, or they might just print out “you’re done now!” at the AS, which is common today.
>>> 
>>> XYZ’s interaction structure allows the composition of these things, under the control of the client. This is exactly why it’s important to be able to specify how to get to the AS and how to get back as separate items, so that the client can compose the combination that makes the most sense for that client.
>>> 
>>>  — Justin
>>> 
>>> 
>>>> On Feb 21, 2020, at 3:52 PM, Dick Hardt <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> I got ahead of myself. A completion URI protects the User only if the User is sent back to the same channel the transaction started so the Client can confirm it is the same User that started the transaction.
>>>> 
>>>> so this does not help the security:
>>>> 
>>>> "Being able to provide a completion URI even if the user is starting on a device is a great insight on how to address the threat above."
>>>> 
>>>> ᐧ
>>>> 
>>>> On Fri, Feb 21, 2020 at 12:40 PM Dick Hardt <[e-mail] <mailto:[e-mail]>> wrote:
>>>> The lightbulb finally clicked on for me. Thanks for your patience.
>>>> 
>>>> The threat you are describing is where the attacker starts a transaction at the client, and gets the victim to complete it. Correct?
>>>> 
>>>> I still think the Client should be able to signal if it will be doing a redirect vs showing a QR code (or wants to do both).
>>>> 
>>>> Being able to provide a completion URI even if the user is starting on a device is a great insight on how to address the threat above. 
>>>> 
>>>> I'm going to ponder how to align XAuth more with these features of XYZ.
>>>> ᐧ
>>>> 
>>>> On Fri, Feb 21, 2020 at 11:31 AM Justin Richer <[e-mail] <mailto:[e-mail]>> wrote:
>>>> On Feb 21, 2020, at 1:54 PM, Dick Hardt <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> On Fri, Feb 21, 2020 at 8:38 AM Justin Richer <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> I’m in complete agreement with Annabelle. In XYZ we realized that both the QR Code and Authorization Code, and that the only difference is how the user gets back to the client. So instead of inventing a new type of interaction, we split them. In XYZ, we have:
>>>>> 
>>>>> This sentence looks to be missing something.
>>>> 
>>>> Apologies: We realized they both used AS-composed URLs to get the user to the AS in a web browser for interaction purposes.
>>>> 
>>>>>  
>>>>> 
>>>>>  - redirect: tells the AS that the client can send the user to an arbitrary URL (and the AS doesn’t care how the client gets that info to the user; could be a redirect or an image or send a push notification to a secondary device, we don’t care as long as the user shows up in a browser at the AS — so maybe this field can be renamed to be more universally accurate)
>>>>> 
>>>>> As stated in this thread, it may be useful for the AS to know if the URL will be in a QR code, or in a full redirect.
>>>>> 
>>>>> In XAuth, the GS(AS min XYA) closes the popup to minimize what a Client has to do, so it needs to know the difference between a popup, and a full browser redirect. This is targetted at SPAs, where an additional URL to redirect to is extra work.
>>>>>  
>>>>>  - code: tells the AS that the client can present a short code the user can type (along with a static URL the user can get to, maybe by typing the URL manually, but it’s not dynamic/arbitrary like the redirect method)
>>>>>  - callback: tells the AS that the client can receive the completion message from a front channel interaction through a redirect. Note that the client might have gotten to the AS through a redirect on-device, through a QR-code off device, or through some other magic, and this field isn’t concerned with that — it’s only concerned with how to get the user :back:.
>>>>> 
>>>>> In a full redirect, the Client wants the AS to send the user back so that it can continue.
>>>>> 
>>>>> The only parameter in the completion message is the nonce, which seems superfluous. See below.
>>>>>  
>>>>> 
>>>>> These three can be combined in different ways depending on what you want to do at the client. Let’s say you’re doing and OAuth2 style authorization code, you’d use “redirect” and “callback” together. If you’re doing a plain user code, you’d use “code”. If you’re doing just a QR code with polling, you use just “redirect” to get the long URL. If you’re doing a user code and a QR code together, you use “redirect” and “code” to get the long URL and the short code not he screen at the same time. 
>>>>> 
>>>>> On top of that, they can be combined with other methods. Maybe I can send the user to an arbitrary URL but also display a human-readable verification code (like CIBA), or send something in a push notification but also give them a message to type, or I’m getting claims from an agent but I want them redirected back through the browser. The client gets to decide what kinds of interaction it can do and how to use these pieces in ways that make the most sense.
>>>>> 
>>>>> Per my question later in this thread, why would the Client not know what interaction it wants prior to the request?
>>>> 
>>>> What do you mean? The client does know what it wants and that’s why it’s asking for what it wants. We’re debating different methods for the client to ask for what it wants. This question does not make sense to me.
>>>> 
>>>>> 
>>>>> If the AS is doing CIBA, that is not a decision just for the Client. Both the AS and the Client need to know they are doing CIBA. (FWIW: I think this work supersedes CIBA)
>>>> 
>>>> As I’ve stated previously, I believe the interaction methods here can supersede CIBA.
>>>> 
>>>>> 
>>>>> Additionally, different interactions have different risk profiles. Sophisticated ASes will use that signal in the risk assessment, and may do ask for additional authentication or verification.
>>>>>  
>>>> 
>>>> Yes, exactly my point. Because different interactions have different risks, the AS will need to be able to decide which interactions it’s OK with for a given request. This could vary based on what’s being requested, or who’s doing the requesting.
>>>> 
>>>>> 
>>>>> An interesting difference between XYZ and XAuth’s approaches is that XYZ keeps the concept of the “authorization code” in the callback response (which in turn is based on the OAuth 1 “oauth_verifier” field). In XYZ, you get an “interaction_ref” which is hashed along with a pair of nonces generated by the client and the AS in the back channel. This binds the front channel response to both the back channel request and the back channel response for a given transaction — and note that I’m really open to having a better way to generate and calculate such a binding, but I think this works. In any event, this protects the client from session fixation and injection on the return from the front channel that it’s susceptible to in a pure polling model, and the hashing approach basically combines the security parameters of the OAuth 2 authorization code and (to an extent) state, PKCE’s code_challenge, and OIDC’s nonce in one element. This is only applicable if you’re coming back to the client and you can validate the hash and present the reference parameter. If you’re doing just plain polling, you don’t have that protection — but the client and the AS are aware of that risk, and there’s an option to prevent it.
>>>>> 
>>>>> XAuth has removed the authorization code concept in its redirect return, and clients only do polling against the GS API in order to get tokens. While I obviously think it’s very valuable to remove things from the front channel, I don’t think this is something we can remove without opening up attack surfaces that have already been identified in previous protocols. I would like to understand why XAuth is not susceptible to the same kinds of attacks, or if it is, what mitigations there are for them. 
>>>>> 
>>>>> Unlike OAuth 2.0, there are no parameters in the front channel response to the Client. The redirect back to the Client is only needed to return the interaction back to the Client.
>>>> 
>>>> This argument rings tautologically hollow — there are no parameters because you’ve defined that there aren’t any in XAuth. XYZ does have parameters, to tie the front and back channel requests together when doing redirect back and forth.
>>>> 
>>>> If you’re not doing a redirect back (ie, not sending a “callback” interaction block), then it’s a polling mechanism like XAuth, the device flow, etc. There are very real risks to this.
>>>> 
>>>>> 
>>>>> XAuth (and XYZ) have a different flow than OAuth 2.0 (or OAuth 1.0)
>>>>> 
>>>>> In OAuth, the AS gives a code to the User to give to the Client that the Client then gives to the GS.
>>>>> 
>>>>> In XAuth, the AS gives a "code" to the Client that givers it to the User to give to the GS.
>>>>> 
>>>>> In XAuth, the "code" is either a user code, or something embedded in the URI the User is redirected to.
>>>>> 
>>>>> Therefore, there is nothing to protect in the redirect back to the Client.
>>>>> 
>>>>> If I'm missing an attack, please elaborate how it would happen.
>>>> 
>>>> One form of impersonation is well documented: https://hueniverse.com/explaining-the-oauth-session-fixation-attack-aa759250a0e7 <https://hueniverse.com/explaining-the-oauth-session-fixation-attack-aa759250a0e7>
>>>> 
>>>> OAuth 1.0’s “Request Token” is a similar request initiation step to what we see in XYZ, XAuth, PAR, FAPI/OBUK, etc, and it’s susceptible to the same kind of issue.
>>>> 
>>>>>  
>>>>> 
>>>>>  — Justin
>>>>> 
>>>>>> On Feb 20, 2020, at 3:21 PM, Richard Backman, Annabelle <richanna=[e-mail] <mailto:richanna=[e-mail]>> wrote:
>>>>>> 
>>>>>> Thanks for the update, Dick! I’m going to confine my comments here to interaction mode design, setting aside whether or not we need “popup”. :D
>>>>>>  
>>>>>> Once the GS hands that URI back to the Client, it has zero control over how the Client uses it. The Client could present any URI (of a reasonable size) into a QR code, or present it as a clickable link, or redirect to it, or open it in an external browser, or do any number of other as-yet-not-invented things with it. Moreover, the Client may not know yet what it wants to do with it. So what value is there in distinguishing between “I want a URI for a redirect” vs. “I want a URI for a QR code” vs. “I want a URI for <some other machine-driven interaction mode>”?
>>>>>>  
>>>>>> Even if we consider things like QR code data capacity, that’s really just a URI length limitation, which could apply to non-QR interaction modes, e.g., if the Client device wants to communicate the URI over an extremely bandwidth-constrained channel. And it’s not clear to me how including a URI length limitation in the request helps. If a GS is capable of generating a shorter URI, why wouldn’t it always return that? On the client side, it can look at the length of the URI provided and decide what to do with it (e.g., render a QR code or display it or do nothing with it).
>>>>>>  
>>>>>> So that really leaves us with two interaction modes that we need:
>>>>>> “uri”, which returns a full URI that may not be human friendly; and
>>>>>> “code”, which returns a code and URI for a code entry page, both of which are human-friendly.
>>>>>>  
>>>>>> Those could be combinable to get both, and even if we don’t go down the multiple interaction mode route we could add the full URI to the “code” interaction object. It wouldn’t hurt anything to do so.
>>>>>>  
>>>>>> –
>>>>>> Annabelle Backman (she/her)
>>>>>> AWS Identity
>>>>>> https://aws.amazon.com/identity/ <https://aws.amazon.com/identity/>
>>>>>>  
>>>>>>  
>>>>>> From: Txauth <[e-mail] <mailto:[e-mail]>> on behalf of Dick Hardt <[e-mail] <mailto:[e-mail]>>
>>>>>> Date: Tuesday, February 18, 2020 at 6:04 PM
>>>>>> To: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>>>>>> Subject: [Txauth] Fwd: New Version Notification for draft-hardt-xauth-protocol-03.txt
>>>>>>  
>>>>>> Added in user code interaction and aligned QR code to be a superset of user code.
>>>>>> Fixed descriptions.
>>>>>>  
>>>>>> 
>>>>>> ---------- Forwarded message ---------
>>>>>> From: <[e-mail] <mailto:[e-mail]>>
>>>>>> Date: Tue, Feb 18, 2020 at 6:00 PM
>>>>>> Subject: New Version Notification for draft-hardt-xauth-protocol-03.txt
>>>>>> To: Dick Hardt <[e-mail] <mailto:[e-mail]>>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> A new version of I-D, draft-hardt-xauth-protocol-03.txt
>>>>>> has been successfully submitted by Dick Hardt and posted to the
>>>>>> IETF repository.
>>>>>> 
>>>>>> Name:           draft-hardt-xauth-protocol
>>>>>> Revision:       03
>>>>>> Title:          The XAuth Protocol
>>>>>> Document date:  2020-02-18
>>>>>> Group:          Individual Submission
>>>>>> Pages:          53
>>>>>> URL:            https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt <https://www.ietf.org/internet-drafts/draft-hardt-xauth-protocol-03.txt>
>>>>>> Status:         https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/ <https://datatracker.ietf.org/doc/draft-hardt-xauth-protocol/>
>>>>>> Htmlized:       https://tools.ietf.org/html/draft-hardt-xauth-protocol-03 <https://tools.ietf.org/html/draft-hardt-xauth-protocol-03>
>>>>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol <https://datatracker.ietf.org/doc/html/draft-hardt-xauth-protocol>
>>>>>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-hardt-xauth-protocol-03 <https://www.ietf.org/rfcdiff?url2=draft-hardt-xauth-protocol-03>
>>>>>> 
>>>>>> Abstract:
>>>>>>    Client software often desires resources or identity claims that are
>>>>>>    independent of the client.  This protocol allows a user and/or
>>>>>>    resource owner to delegate resource authorization and/or release of
>>>>>>    identity claims to a server.  Client software can then request access
>>>>>>    to resources and/or identity claims by calling the server.  The
>>>>>>    server acquires consent and authorization from the user and/or
>>>>>>    resource owner if required, and then returns to the client software
>>>>>>    the authorization and identity claims that were approved.  This
>>>>>>    protocol can be extended to support alternative authorizations,
>>>>>>    claims, interactions, and client authentication mechanisms.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Please note that it may take a couple of minutes from the time of submission
>>>>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>>>>>> 
>>>>>> The IETF Secretariat
>>>>>> 
>>>>>> ᐧ
>>>>>> -- 
>>>>>> Txauth mailing list
>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>>>> 
>>> 
>> 
>