[OAUTH-WG] Re: draft-ietf-oauth-cross-device-security-13 ietf last call Artart review

[Pieter Kasselman <[e-mail]>]

Thanks for the careful read and feedback Jim, much appreciated.

I have opened issues for most of the comments. See responses below:

On Tue, Dec 16, 2025 at 6:34 PM Jim Fenton via Datatracker <[e-mail]>
wrote:

> Document: draft-ietf-oauth-cross-device-security
> Title: Cross-Device Flows: Security Best Current Practice
> Reviewer: Jim Fenton
> Review result: Almost Ready
>
> Document: draft-ietf-oauth-cross-device-security-13
> Title: Cross-Device Flows: Security Best Current Practice
> Reviewer: Jim Fenton
> Review result: Almost ready
>
> I am the designated ARTART reviewer for
> draft-ietf-oauth-cross-device-security.
>
> I found the document to be clearly written and generally well organized.
>
> Some specific comments:
>
> In the context of authentication, so-called "authentication fatigue"
> attacks
> have become very common where the attacker pesters the victim with many
> requests to approve an authentication request until they get tired and
> approve
> one of them to make the annoyance go away. I would expect that to be at
> least
> as prevalent for some of the cross-device authorization flows because the
> push
> request is not always preceded by single-factor authentication. I didn't
> see
> much discussion of this attack except perhaps in 4.3.4. On the other hand,
> Section 1.1 paragraph 2 refers to "[the user] accept[ing] an authorization
> request pushed to their Authorization Device", which makes it seem like all
> they need to do is press "accept" rather than transfer a user code.
> Example A4
> (Section 3.3.4) also seems particularly vulnerable to fatigue attacks.
>

Yes, the Backchannel-Transferred Session Pattern is particulalrly
vulnerable - to this style of attack as is also described in Example B9
also references an authentication fatigue style attack:
https://www.ietf.org/archive/id/draft-ietf-oauth-cross-device-security-13.html#name-example-b9-illicit-access-t
. The document also proposes mitigations (rate limiting) - I will add a
cross link for Example B9 from the mitigation as well.

Opened GitHub Issue 221:
https://github.com/oauth-wg/oauth-cross-device-security/issues/211


> Section 3 deals with both authorization and session transfer, but the
> introductory paragraph specifically describes session transfer.


We will clarify this.

Opened GitHub Issue 222:
https://github.com/oauth-wg/oauth-cross-device-security/issues/212


>
>
Section 3.1 has two references to an Authentication Device, while elsewhere
> the
> term Authorization Device is used everywhere.
>

I believe this is a left over from a previous version - thanks for catching
it:

Opened GitHub Issue 223:
https://github.com/oauth-wg/oauth-cross-device-security/issues/213



> I didn't dig into the underlying specifications to see if it's described
> there,
> but I'm not clear on how the Authorization Server is located. For example,
> if I
> want to authorize the TV in my hotel room to display some content from my
> tablet, how do I find that server? Download the <hotel chain> app,
> perhaps, and
> enter my "6 digit" code there? It's probably clearer for QR codes that
> might
> have a URL.
>

Therearedifferent. Implementations: Sometimes the URL is displayed and the
user must type it in. This is in part why QR codes get used - it avoids the
user having to type the URL. Thisis specific to protocols and
implementations so we didn't want to get into that detail here.


> On a related note, the specification leans heavily on the user code being 6
> digits or so. Whether that's sufficient depends heavily on the scope of the
> authorization server. You need enough digits not to authorize the wrong
> thing
> by mistake, especially in the absence of a proximity check. I didn't see
> this
> discussed. There is also probably a related attack where attackers guess
> user
> codes.
>

This BCP does not give advice on the length of things like user codes and
exhaustive search attacks on them, rather, it focuses on the cross device
flows and how consent phishing/social engineering makes the code length or
authentication strength irrelevant. The 6 digit codes are all used as
illustrative examples, not normative. It was chosen in part to make the
draft relatable as most implementations I am familiar with use 6 digits. I
will add a note upon the first mention of 6 digits stating that the length
may exceed this if the risk profile requires it, reminding readers that
more digits might be necessary.

GitHub Issue:
https://github.com/oauth-wg/oauth-cross-device-security/issues/214


> Several of the flow diagrams have bidirectional arrows for steps that are
> logically unidirectional. For example, the diagram in Sections 3.1.2 and
> 3.1.3
> have bidirectional arrows for (E) Grant Authorization, while it really goes
> from the Authorization Server to the Consumption Device, not the other way.
> There are a number of similar instances.
>

Added this to the existing issue on diagram updates needed:

GitHun Issue:
https://github.com/oauth-wg/oauth-cross-device-security/issues/208


> Section 4.1, talking about the ability of the attacker to chance the
> context of
> the authorization request, perhaps note that this is possible also because
> the
> request is unsigned.
>

I don't think signing the QR code helps (it may make it worse as the user
may mistakenly believe it is secure). The context changes are inside the QR
code, but rather how and where it is displayed as described in step D:


   -

   (D) The attacker changes the context in which the QR code or user code
   is displayed in such a way that the user is likely to scan the QR code or
   use the user code when completing the authorization. For example, the
   attacker could craft an e-mail that includes the user code or QR code and
   send it to the user. The e-mail might encourage the user to scan the QR
   code or enter the user code by suggesting that doing so would grant them a
   reward through a loyalty program or prevent the loss of their data.



> In Section 6, some of the mitigations (e.g., Shared network) "bury the
> lede" by
> describing a possible mitigation in detail with only a brief mention of the
> problems associated with it. Some of the mitigations have definite
> deployment
> or effectiveness limitations.
>

Most of the mitigations have shortcomings, this is why we added the
"Limitations" for each one. I can add a sentence to the opening paragraph
to highlight their limitations.

GitHub Issue:
https://github.com/oauth-wg/oauth-cross-device-security/issues/215


> Section 6.1.7, device types seem easily spoofable.
>
I think that depends on how the device type is determined which becomes an
implementation detail (e.g. it may be asserted through a signed attestation
statement etc). I will add some clarification and perhaps additional text
on limitations to suggest that not all mechanisms for device type
determination are created equally.


> Section 6.1.15, many phishing-resistant authenticators (e.g., FIDO) require
> registration prior to use. It's not clear how authenticating first would be
> accomplished for many of the use cases described.
>

Thanks for this comment Jim. This needs to be clarified further:
https://github.com/oauth-wg/oauth-cross-device-security/issues/219


>
> A forward reference from 6.1.1 "Wireless proximity" to Section 6.2.3 might
> be
> helpful.
>

Good point, I will add it

GitHub issue:
https://github.com/oauth-wg/oauth-cross-device-security/issues/217


> In Section 6.2.3, FIDO2/WebAuthn is an authentication protocol that
> requires
> advance registration to authenticate, and therefore would not fit many of
> the
> example scenarios. What's perhaps needed is a subset of the hybrid
> authentication protocol that uses BLE to establish proximity in conjunction
> with a user code or QR code. I don't think that's spelled out anywhere,
> however.
>

FIDO2/WebAuthn with Passkeys supports these bootstrap scenarios. I agree
that the hybrid protocol would be very useful on its own, but out of scope
for this draft to try and either define or recommend its use outside the
supported FIDO2/WebAuthn implementations.


> Security Considerations seems a little thin for a document focused
> primarily on
> security.
>

We took. a simialr approach as the Oauth Security BCP in terms of the
security cosniderations section:
https://datatracker.ietf.org/doc/html/rfc9700#name-security-considerations


>
> There were a few typos and grammatical errors. I can provide the ones I
> saw to
> the authors on request.
>
> Thanks Jim, if you paste them into this GitHub isssue and we will make the
updates:

GitHub Issue:
https://github.com/oauth-wg/oauth-cross-device-security/issues/218


>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>