Re: [regext] Feedback on draft-ietf-regext-rdap-openid from OAuth WG

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: regext <[e-mail]> On Behalf Of Roman Danyliw
> Sent: Friday, September 29, 2023 6:06 PM
> To: [e-mail]
> Cc: Justin Richer <[e-mail]>; Roman Danyliw <[e-mail]>
> Subject: [EXTERNAL] [regext] Feedback on draft-ietf-regext-rdap-openid
> from OAuth WG
>
> Hi!
>
> I noted that in the shepherd report
> (https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/shephe
> rdwriteup/) that there were pointers to requests made in 2015 and 2016
> for a review from the OAUTH WG.  Following the threads, nothing came
> back 7 - 8 years ago.  I don't remember the circumstances of the OAUTH
> WG so long ago, so I ask again earlier this week.  With great
> appreciate to him, I wanted to share a pointer to Justin Richer's review:
> https://mailarchive.ietf.org/arch/msg/oauth/33Ci5v7EHDLRC7pvvK85uarXut
> Y/

[SAH] I'm no longer subscribed to the oauth mailing list, so I can't reply 
directly to Justin's note. I'll copy it and reply here.

Hi Roman,

The concerns of this document are largely specific to OpenID Connect, and not 
vanilla OAuth, but of course many of us in the community overlap and I'm happy 
to help provide some feedback here. I'm not familiar with RDAP, so if any of 
my concerns are addressed by other aspects of the RDAP ecosystem, I would be 
happy to be corrected.

[SAH] That may be the case. More below.

That said, I believe parts of the approach are fundamentally flawed as it 
conflates the RS and client roles in a potentially dangers and certainly 
confusing way.

Some thoughts as I read through this:


§3.2.1:

 - there seems to be some conflation of the RP and RS roles here in the RDAP 
server; it seems more proper that the RDAP server is the RS, and the RDAP 
client is the RP (the same as the OAuth client); this seems to stem from a 
problem with how the RDAP server actually gets user claims, see paragraph 
below for more

[SAH] The RDAP server is intended to serve both roles. It's the Resource 
Server (RS) because the data resides there. RDAP clients aren't trusted, and 
the RDAP server needs direct access to the identity information associated 
with the end user in order to make authorization and access control decisions 
to release data in response to a query, so it's also serving in the Relying 
Party (RP) role. For the most part, an RDAP client is just a conduit through 
which information is shared with the end user.

§3.1.3:

 - this seems to assume the authorization code grant type; though this is 
explained a little bit more in 3.1.4.2, it's not clear that other grant types 
are supported here within this protocol

[SAH] This section is a summary of the steps described later in the document. 
The Authorization Grant type is explicitly identified in Section 3.1.4.5.

 - the first section on "session-oriented clients" conflates the end-user with 
the client (to wit: "An RDAP client (acting as an OpenID End-User)");

[SAH] I agree, that "acting as" part is confusing. I can strike it.

consequently it's unclear who is getting "redirected" or interacting at any 
step; more properly, it seems that the end-user is interacting with the RDAP 
client to initiate the flow, which is borne out in the diagram

[SAH] That's correct, the user interacts with the client. It's the client that 
gets redirected.

More importantly, in this section it becomes clear that the core of the 
specification's "token-oriented" approach relies on the RDAP client passing 
the access token to the RDAP server and then having the RDAP server replay 
that same token to the OpenID IdP in order to get user claims. It is not 
considered good practice to have the RS replay the access tokens it receives 
to an external party, and on the surface this could potentially be exploited 
by an attacker. This also fails under sender-constrained token usage, wherein 
the RDAP client would need to also share key material with the RDAP server in 
order for the latter to use the token.

A better pattern would be a profile of OAuth Token Introspection (RFC7667) 
wherein user information could be specified. This would also allow the RDAP 
server to authenticate its call to the OpenID IdP. Introspection was designed 
specifically to allow the RS to call back to the AS to determine what (and
who) a token is for, and it provides an extensible mechanism for doing so. An 
alternative would be to profile the access token itself to contain user 
information in a format readable by the RDAP server. More on this in the note 
for §6.3 below.

[SAH] The RDAP server needs the claims associated with the end user's 
credential. I don't see claims returned in a Token Introspection response. 
That being the case, it needs the token to contact the Userinfo Endpoint.

§3.1.5.1

- The registry information here should be in a separate IANA section that is 
forward-referenced from here

[SAH] what's described here is protocol, not registry management, but as I 
said in my reply to Roman's IESG review feedback I can move this text if it 
helps provide clarity.

- which parties are responsible for validating the allowed purposes claims?
Does the IdP need to know the list of allowed purposes applicable to the RS 
(RDAP server)?

[SAH] Validation of applicability to a user's credential is the responsibility 
of the IdP, just as the IdP is responsible for associating other claims with 
the credential. The RDAP server receives and processes those claims in order 
to make an authorization and access control decision regarding the information 
to be returned in a query response.

§4.1

 - I appreciate that the fav1 data structure separates the applicable flags 
into a clear substructure, which will be easier to process as an extension to 
existing code

§4.2

- RFC3986 doesn't actually specify the key=value format normatively; these 
days, that belongs to the HTML URL specification from WHATWG and so I would 
recommend that this reference be used instead:
https://url.spec.whatwg.org/#application/x-www-form-urlencoded<https://url.spec.whatwg.org/>

[SAH] OK, I'll look at that.

§4.2.1

 - is it really the case that a client can only request a single purpose, but 
multiple can be authorized? I'm not an expert in the RDAP world, but this 
would seem to be quickly turn insufficient as purposes are not required to be 
completely separate and distinct from each other in the registration section

[SAH] As described in Section 3.1.5.1, multiple purposes can be specified.

§4.3

- I think this section was probably meant to be a subsection of 4.2?

[SAH] No, but it could be if that would help add clarity.

§5.1.1

 - OpenID Connect does not define a single global string value for a user 
identifier; instead only the tuple of issuer and subject are considered 
suitably unique; ergo, the UserID value in the data structure would need to 
have either a construction method or some other specification, or to have this 
declared as RDAP-server-specific explicitly

[SAH] It *is* described as an RDAP-specific thing. That's why it's in a data 
structure that's explicitly identified as an RDAP extension.

§5.1.2

 - this seems to replicate RFC8628, OAuth Device Flow, without any of the 
implementation detail or security considerations of that specification; 
furthermore, the device flow isn't specified in OpenID Connect (which is being 
profiled here) though its use is far from unheard of in practice; this use is 
further expanded in §5.2.4, but it's unclear that that's why this is here

[SAH] Right, as I noted in my reply to Roman's discuss, I could import the 
"Device Authorization Response" data structure described in Section 3.2 of RFC 
8628 by reference.

§5.2.1

 - I'm unclear when reading this whether the identifier in question is an 
OAuth client_id or a user identifier, as the text seems to indicate it can be 
either; these represent drastically different things, and one could argue that 
separating the identity of the client software from the identity of the 
end-user is the entire point of OAuth and protocols like it
 - Ultimately this seems to be a discovery step for RDAP, and so I would 
expect to see more types of identifiers that could be used for discovery 
purposes, such as user-facing identifiers like email addresses or phone 
numbers if that's the goal

[SAH] It's a user identifier issued by an IdP. It's described in Section 1.2, 
3.1, 3.1.1, and elsewhere.

 - Significant effort is currently being proposed in the OAuth WG for dealing 
with the inherent security issues of multi-device authorization issues like 
this; this draft would do well to incorporate some of that

[SAH] Such as? I don't mind including a reference in the Security 
Considerations section as long as the reference won't hold this draft up.

§5.2.4.2

 - the device code is included here as a query parameter instead of a body 
parameter, what's the purpose of that? As written it's incompatible with 
RFC8628, which is claims to be a profile of (eg, "This request performs the 
polling function described in...")

[SAH] Yes, that needs to be fixed.

§6.3

 - if the token is intended to be used in proxy as stated in §6.2, then the 
validation here is redundant as an invalid token would not return claims 
listed in this step; I would suggest that the pattern in §6.2 be removed 
entirely and instead the validation patterns in §6.3 be expanded into a full 
profile

[SAH] Reading both sections again, I do think they can be combined.

§6.4

 - Token exchange is generally targeted for access tokens, not ID tokens; it 
seems that this is part of the conflation between RS and RP in this mode

[SAH] Section 3 of RFC 8693 specifically notes that ID tokens are one of the 
supported token types. The reasons why this type of exchange might be needed 
are described in the text of the draft.

§11

 - The security considerations section is remarkably thin for a protocol of 
this nature, and I would especially expect more discussion on how to select 
which mode of operation and for which purposes

[SAH] There isn't really any mode selection happening here. Clients exist as 
one type or the other, and they operate accordingly. As such, I'm unsure of 
what else needs to be added.

In closing, I think the "token-oriented" approach has major problems in that 
it seems to be encoding an anti-pattern without a lot of guidance for why it 
would be applied. But to reiterate, I am not an expert in the RDAP ecosystem, 
so if any of these concerns are addressed by that ecosystem I am ignorant of 
those considerations.

[SAH] We discovered the need to support this type of client when testing 
session-oriented clients with my experimental RDAP test server. If the RDAP 
client is running on a web server, and working with an RDAP server that's 
itself running on another web server, we found it impossible to manage 
sessions associated with the end user. Pawel Kowalik did the experimental 
client implementation. Perhaps he can add more info here.

 - Justin