Thanks for the review, Roman. I'll reply below. > -----Original Message----- > From: Roman Danyliw via Datatracker <nore...@ietf.org> > Sent: Tuesday, October 3, 2023 10:06 PM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-regext-rdap-ope...@ietf.org; regext-cha...@ietf.org; > regext@ietf.org; AlBanna, Zaid <zalba...@verisign.com>; AlBanna, Zaid > <zalba...@verisign.com> > Subject: [EXTERNAL] Roman Danyliw's Discuss on draft-ietf-regext-rdap- > openid-25: (with DISCUSS and COMMENT) > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content > is safe. > > Roman Danyliw has entered the following ballot position for > draft-ietf-regext-rdap-openid-25: Discuss > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this > introductory > paragraph, however.)
[SAH] [snip] > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > ** Section 3.1.3. Lining up flow in Figure 2 and the associated text, it > appears that the RDAP client passes the access token to the RDAP server > (Step > #10) which the RDAP server then passes it to the OpenID provider (Step > #11). > My understanding is that it is not considered good practice to pass access > tokens to external parties. Is there a reason that RFC7667 (OAuth Token > Introspection) could not be used to allow the RS to query the AS about the > various claims? [SAH] Looking at RFC 7662, I don't see anything in the token introspection response that includes the claims needed by the RDAP server to authorize the end user for access to protected resources. Perhaps the combined text and graph are misleading. What I'm attempting to describe is the RDAP Server contacting the OpenID Connect UserInfo Endpoint as described in Section 5.3 of the OpenID Connect Core specification. I can make that clear by noting which endpoints are contacted in the sequence of steps that precede the two diagrams. > ** Section 3.1.5.2. By design, this section seems to be defining a > mechanism > outside of normal any audit capabilities which seems like it could have > security and operational implications. Being able to track who is making > queries seems fundamental to operating the RDAP system. Please > document the > associated risks of being blind to certain queries. [SAH] I can do that in the Security Considerations section. > ** Section 5.1.2. This workflow and even the fields in the farv1_deviceInfo > data structure seem to be very similar to the RFC8628/OAuth Device > Authorization Grant. Did the WG consider using this flow instead of this > custom one? Could it be used instead? [SAH] Section 5.2.4 of the document does, in fact, note that the workflow is defined in RFC 8628. The data structure defined in Section 5.1.2 is a clone of the "Device Authorization Response" described in Section 3.2 of RFC 8628, minus the two OPTIONAL fields. The 8628 structure could be used. > ** Section 5.2.4.2. The polling behavior described here is said to confirm > to > the “polling function described in RFC 8628 [RFC8628]”. However, this > section > seems to specify normative behavior around query strings, that is, using an > HTTP GET method. Section 3.1 of RFC8628 states that the protocol flow > needs to > use a POST method. [SAH] Yes, I missed that. I need to update the text to use the HTTP GET method for consistency with 8628. > ** Section 11 > Additionally, the practices described in RFC > 8996 [RFC8996] MUST be followed when the Transport Layer Security > (TLS) protocol is used. > > Not using TLS 1.0 and 1.1 seems to narrow in scope. Please use RFC 9325/BCP > 195. [SAH] OK, will do. > ** Section 11. > An RDAP server > operator SHOULD develop policies for information disclosure to ensure > that personally identifiable information is disclosed only to clients > that are authorized to process that information. > > Why is this not a MUST? What are the circumstances where PII should be > disclosed without authorization? [SAH] The SHOULD is about policy development, not information disclosure. I don't think a protocol specification like this can mandate development of an operational policy. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you to the authors for reaching out to the OAuth WG when this > document > was first being drafted. > > Thank you to Justin Richer for providing a timely review of this work from > the > OAuth WG perspective. See > https://secure- > web.cisco.com/1ysCwgjIvLEvjoKpl641CU2RMOS9D0CeW8BHhPoTbLzaKIhGw > -zEM3YJ_0j- > YUolk_luzK_OkiB_nS4LH7Zl94I0OQx7Q8VaHDAYyipI_mY_keLb7hQj- > z_gYb3oIDOYtfIDyvcYVTn-cLHSEVZhpzfGhJLiytzmzI3RgRnPsmbbNpv2- > f3I4Q1e5oBzxTSfSyCDDcDi8Kv9KQSb2PIdzHb8X6AxXtPgffk1JFVWi0o4j54AyjK > vLZSAozdyfU9y4T3CUKT- > gQO9AzysrRx5zBKGGxliwXHQ3y1t1OfLjVr6h95F7UBwk6BRmhceeHKuA/https > %3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Foauth%2F33Ci5v7EHDLR > C7pvvK85uarXutY%2F > Please review and respond to his feedback. A number of ballot positions > presented here are due to his analysis. > > I appreciate the patience of the WG given my deferral of this document to > this > telechat. [SAH] I will! I still haven't heard back from the two WG contributors who helped develop much of the token-oriented client text, so I'll do my best to respond absent their input. > ** Section 3.1.3 > The RDAP server can then make identification, authorization, and > access control decisions based on End-User identity information and > local policies. Note that OpenID Connect describes different process > flows for other types of clients, such as script-based or command > line clients. > > Is RDAP intended to support additional flows beyond those described here? [SAH] No. > ** Section 3.1.3 > 10. The RDAP client sends queries that require user identification, > authentication, and authorization to an RDAP server that include > an Access Token in an HTTP "Authorization" header using the > "Bearer" authentication scheme. > > Please provide a normative reference to this authentication scheme. [SAH] That's RFC 6750. Can do. > ** Section 3.1.5.1 > Communities of RDAP users and operators may wish to make and validate > claims about a user's "need to know" when it comes to requesting > access to a protected resource. > I don’t fully understand who will know what in the RDAP ecosystem. Will the > identity provider be able to validate all of the allowable behaviors to > validate the values of the “rdap_allowed_purposes” claim? [SAH] The IdP will know what the users to whom they issue credentials are authorized to request and receive. For example, an IdP operated by a law enforcement agency like the FBI or Interpol will know that their employees are authorized to use the "criminalInvestigationAndDNSAbuseMitigation" query purpose. So yes, the intention is that the IdP will be responsible for associating appropriate query purposes with the identity credentials they issue. The RDAP server will receive the claims that include the valid query purposes, and it will make an access control decision based on those query purposes and the other claims associated with end user's credential. > ** Section 3.1.5.1. Editorial. Move all of the guidance on registry > management to Section 9.3 [SAH] 3.1.5.1 and 3.1.5.2 don't describe registry management. They describe the values that will appear in the registry. Nonetheless, I can move these sections to 9.3 if that makes things clearer. > ** Section 3.1.5.2. Not understanding the RDAP ecosystem and responding > to the > example, this section seems to be providing a privileged mechanism for law > enforcement. Are there other users? Is this notion of “do not track” > intended > (or currently implemented) as a general-purpose mechanism? [SAH] It's intended to be used by any end user community for which disclosure of the fact that they're submitting queries could compromise their efforts. Law enforcement users are one possible user of this claim. I don't currently know of any others. > ** Section 5.1.1. Per the UserID value, is that created in some > standardized > way for the RDAP ecosystem to allow interoperability? OpenID uses a tuple > of > issuer and subject. [SAH] Yes. It could be something like an email address; Google, Yahoo, and Microsoft do that. We don't really need the subject value for RDAP. > ** Section 11. > OpenID > Connect defines optional mechanisms for robust signing and encryption > that can be used to provide data integrity and data confidentiality > services as needed. > > How would these services be used and for what purpose? [SAH] I'd prefer to strike that sentence since that paragraph already contains a normative reference to the OpenID Connect Core specification. > ** Section 11 > As described in Section 3.1.4.2, the OAuth 2.0 Implicit Flow > [RFC6749] is considered insecure and efforts are being made to > deprecate the flow. It SHOULD NOT be used. > > Since this is “green field” design, why not “MUST NOT”? [SAH] It should be. I'll make that change. > ** Section 11. Would referencing draft-ietf-oauth-security-topics-23 for > additional SecCon be useful? [SAH] Only if it's far enough along to not hold this one up. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
