IETF Last Call Review of draft-ietf-oauth-cross-device-security-13
review-ietf-oauth-cross-device-security-13-artart-lc-fenton-2025-12-16-00

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.

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

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

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.

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.

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.

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.

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.

Section 6.1.7, device types seem easily spoofable.

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.

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

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.

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

There were a few typos and grammatical errors. I can provide the ones I saw to
the authors on request.