Security Services for the Registration Data Access Protocol (RDAP)
draft-ietf-weirds-rdap-sec-12

Just a few points in Section 3.1.1 -- nothing blocking, but I ask you to consider addressing these, please:

   The OAuth authorization framework [RFC6749] describes a method for
   users to access protected web resources without having to hand out
   their credentials.  Instead, clients supply access tokens issued by
   an authorization server with the permission of the resource owner.
   Using OAuth, multiple RDAP servers can form a federation and the
   clients can access any server in the same federation by providing one
   credential registered in any server in that federation.  The OAuth
   authorization framework is designed for use with HTTP and thus can be
   used with RDAP.

One small point in the middle of that: the clients have nothing to do with supplying access tokens.  The clients use access tokens that are given to them.

OLD
   Instead, clients supply access tokens issued by
   an authorization server with the permission of the resource owner.
NEW
   Instead, clients are issued access tokens by
   authorization servers with the permission of the resource owners.
OR
   Instead, a client is issued an access token by
   an authorization server with the permission of the resource owner.
END

   OpenID [OpenID] is a decentralized single sign-on authentication
   system that allows users to log in at web sites with one ID instead
   of having to create multiple unique accounts.  An end user can freely
   choose which OpenID provider to use, and can preserve their
   Identifier if they switch OpenID providers.

I would say "at multiple web sites with one ID".

   certificate authentication method can be used to achieve federated
   authentication in which multiple RDAP servers all trust the same CAs
   and then any client with a certificate issued by a trusted CA can
   access any RDAP server in the federation.

It's important to note that there are problems with client authentication through this mechanism, which have interfered with widespread deployment.  For example, there are issues with too-promiscuous, or even rogue, CAs that get themselves into trusted-CA lists.  There are also proposals to address that.  Fully getting into the issues is well beyond the scope of this document, but I think it's important for this document to warn of the problem and point readers in the right direction to find more information.  There's nothing in the Security Considerations about this now.

I agree with Spencer's comment about the mis-use of SHOULD when referring to future security features.

Am a little disappointed that this didn't take on the integrity of the objects  themselves. but it looks fine as far as recommendations go.

In 3.1.  Authentication, this text:

   RDAP SHOULD be capable of supporting future authentication methods
   defined for use with HTTP.

is a great idea, but I don't think it's a 2119 SHOULD ("SHOULD unless" what? and how would you know you'd achieved that?).

If you could point to work in progress that RDAP might consider, or say what kinds of things in RDAP would likely be problematic, then you could say that RDAP needs to be prepared to use new methods if necessary, and I would be happier with that language.

But if you mean:

   Work on HTTP authentication methods continues. RDAP ought to be 
   agile enough to support additional methods as they are defined.

or something like that, I'd encourage you to say what you mean :-)

In a companion document, http://tools.ietf.org/html/draft-ietf-weirds-using-http-07#section-5.5 ends with this paragraph:

   Note that this is not a defense against denial-of-service attacks,
   since a malicious client could ignore the code and continue to send
   queries at a high rate.  A server might use another response code if
   it did not wish to reveal to a client that rate limiting is the
   reason for the denial of a reply.

I found that very helpful. Would it be helpful for this paragraph to appear in http://tools.ietf.org/html/draft-ietf-weirds-rdap-sec-04#section-3.3?

- I don't get what the "Document quality" section of
the write up is saying about secdir review.

- I somewhat disagree with the last part of Barry's
comments. The issues we've experienced with trusted-CA
lists have all related to TLS server authentication, and
afiak, not to client-auth, which is what's at issue here.
So, if a warning is to be added, it'd relate to the list
of CAs that RDAP servers trust for client-auth and not to
the (large and sometimes problematic) list of CAs that
browsers ship with in the current web pki.

In 3.1, the section reference to RFC 5246, section 7.4.6 is broken, and actually links to section 7.4.6 in this document.   If you are using xml2rfc, this is easy to fix, and worth fixing.

It would be nice if this section linked to some document that described authentication based on CA signature; this is an interesting technique that I think is very applicable here, but I've never heard of it being used before, and it's sufficiently similar to server key signing that it's easy to imagine someone getting it wrong.

The concern is that they will think that "CA" means a regular CA, rather than a CA operated jointly by the federation of RIRs.   For example, if they imagined that Thawte was a CA in the sense that this document means, then anybody who got their client key signed by Thawte would get access, but I'm pretty sure that's not what you intend.

Otherwise, looks great.   Thanks for writing it!