> -----Original Message----- > From: regext <regext-boun...@ietf.org> On Behalf Of Roman Danyliw > Sent: Friday, September 29, 2023 6:06 PM > To: regext@ietf.org > Cc: Justin Richer <jric...@mit.edu>; Roman Danyliw <r...@cert.org> > 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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
