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

[Ballot comment]
Thanks for your work on this and the other Weirds drafts and adding in my requested text on privacy options to the response draft (Alissa's in this draft) as well as addressing my other discuss points (TLS BCP, etc.).  The new sections are helpful to explain privacy and access control options (3.1) that have been added in this new protocol.



Section 3.1
As an FYI (not asking for anything to be done here except to participate in HTTPAuth last calls) - HTTP Digest and Basic just went through a revision and are just about done.  There are a few minor updates and the security considerations in the updated documents spell out the remaining issues.  Although these are the solutions for HTTP Auth, most people don't rely on it and use other methods, so we don't have implementations of better options.  There are a few other options in the HTTPAuth WG about to go to IETF last call or are WG drafts.  If you are going to rely on HTTPAuth methods, maybe there should be a push for the improved options from the WEIRDS WG - at least pitching in to review during last calls. 
https://datatracker.ietf.org/wg/httpauth/documents/

[Ballot comment]
Barry has pointed out that there is a way to trigger the clients to send credentials using a login link, so that addresses my concern.  I didn't actually see that explicitly mentioned in the document, but Pete says it's there so I'll take his word for it.

[Ballot comment]


- I strongly support Aliss's discuss on privacy. That would be
even more important should registrars/registries in future
require that personally identifying information be available
for all registrants, which I believe is a policy that at least
some are arguing for.

- Isn't it sad that HTTP basic and digest still have to be the
MTIs here for client auth. (I would suggest HOBA [1] but that's
not quite done, being just finished WGLC, and would be
self-serving, though it would be far better than basic or
digest;-)

  [1] https://tools.ietf.org/html/draft-ietf-httpauth-hoba-05

- Why not just say "TLS MUST be used" in all cases? Is there a
real need to not use TLS for weirds ever?

- TLS client auth - I think you could easily make this MTI (to
implement, not to use) as its basically there in most
codebases.

[Ballot comment]
I support Alissa's comments about privacy.  It would be good to clarify those considerations and provide some good recommendations about what not to send.

[Ballot discuss]
As far as I can tell, this specification effectively relies on HTTP authentication as its sole MTI mechanism, and leaves things like OAuth as sort of "you could do this, but we aren't saying how."  I am deeply uncomfortable with this, because HTTP authentication really sucks when you are trying to make it work in a context where authentication is optional.

I think if you want to rely on this mechanism, you need to give the reader more guidance on how to make this work.  What I mean is that in order to trigger the client to send authentication, you have to send back a 401 Unauthorized HTTP response.  But that assumes that authentication _is_ required, and it's not.  So how does the server know to send back the HTTP unauthorized response?  The answer is that it does not, and so you need to somehow signal to the client that it should send more authentication info if it wants better information, while still returning information in case the client has no credentials to offer.

This is probably doable, but simply relying on RFC 7235 without explaining how to make it work isn't sufficient.

[Ballot discuss]
Thanks for your work on this draft and improving security for the whois function in weirds.  There are a lot of options now and the work is appreciated.  I have a lot of comments and suggestions that should be pretty easy to resolve.  You may find a discuss and comment on the same section, so I've tried to label the start of each item with the draft section numbers.

Section 3.1
Could you also include a reference to RFC5280?  If the use of PKI and CAs is listed, a pointer to the security considerations would be very helpful to the reader.  The pointer should be to the full draft, not just the security consideration section as it covers important things like the need for path validation.  Path validation includes checking the certificate validity, the path/chain (root is trusted), etc.  I'm not looking for you to add much text, just to punt off to the existing documents if people are interested in the security behind these recommendations for federation, authentication, authorization, etc.

Section 3.2
Could you expand on the details here a bit?  Between this draft and the response draft, I don't see enough information or guidance on how one might leverage value settings on objects and what are the right actions to take based on those values.  My discuss on the response draft is specific to that draft, but the same concept applies here.  If the guidance belongs in the response draft, then recommended actions or a list of options if it varies from administrator to administrator would be helpful at the start of the sections that provide the lists of values that can be set on objects.

This section of the sec draft should then reference the response draft letting the reader know where to look for authorization and access control options and guidelines.

Section 3.4
Since the protocol allows for the use of values to mark objects as private, obscured, redacted, this should be mentioned in this section with a pointer to the response draft section 10.2.2 and the recommended actions in the (hopefully) updated Privacy Considerations section of that draft.  For confidentially, leaving out the data with the "redacted" value set if possible will do a lot more than trying to protect it with TLS, so I think it's important to note that in this section.  The "private" value should limit access (I'd like to see some mention of how that is accomplished, but probably in the Response draft).  The "obscured" value is interesting, but since it is only obscured, it may to be the best option for confidentially protection.

Possible new section for Access Controls -
Since user based access is possible, I'd like to see a section added to cover that as well.  Is access tied to the roles designated in 10.2.4 of the Response draft?  Should it be?  Having the combination of user roles and data object values gives a lot of flexibility, but that is talked about enough in the drafts (IMO).

Security consideration section:
It's good that you are recommending against use of the Null cipher, but could you add a reference to the UTA TLS best practices draft here as well?  That will cover quite a few bases with out having to repeat stuff here.
https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/

[Ballot comment]
I support Alissa's discuss for a privacy threat model.

Section 3.1
As an FYI (not asking for anything to be done here except to participate in HTTPAuth last calls) - HTTP Digest and Basic just went through a revision and are just about done.  There are a few minor updates and the security considerations in the updated documents spell out the remaining issues.  Although these are the solutions for HTTP Auth, most people don't rely on it and use other methods, so we don't have implementations of better options.  There are a few other options in the HTTPAuth WG about to go to IETF last call or are WG drafts.  If you are going to rely on HTTPAuth methods, maybe there should be a push for the improved options from the WEIRDS WG - at least pitching in to review during last calls. 
https://datatracker.ietf.org/wg/httpauth/documents/

Section 3.1
I'm a little uneasy with just having a pointer to TLS to fix everything in OAuth and OpenID.  Could you put in pointers to main framework documents like RFC6749 with a statement that says security considerations are included in those drafts?  The security considerations differ between token types (bearer vs. Holder of Key) and that is out-of scope for this draft, so punting to the OAuth drafts would be very helpful instead of just pointing to TLS (but please do leave that in).

This is just a comment the references do appear at end of the Security considerations section, & I'd recommend you move those up to section 3.1 as it will be a lot easier for the reader.

Section 3.1
Just a question, should SAML 2.0 be listed as an option since this is a RESTful interface and we are talking about client authentication via a federated identity scheme or is that not an option?  Thanks.

[Ballot comment]
-- Section 3.1 --

  This section describes security authentication mechanisms and their
  need for implementation by authorization policies.

It took me a few readings to get what I think you mean.  I think you mean this:
NEW
  This section describes security authentication mechanisms and the
  need for authorization policies to include them.
END

[Ballot discuss]
= General comment =
I'm not exactly sure which document this remark is directed at, but I'm putting it in a DISCUSS here and we can figure that out later.

I feel like the RDAP document suite is missing an overall explanation of the privacy threat model associated with registration data, the policy choices that are left up to registry providers, and the mechanisms included in RDAP to help protect registrant  and client/user privacy and facilitate those policy choices. There are mentions of some of this here and there, but even those are not necessarily consistent with each other (see my DISCUSS on draft-ietf-weirds-using-http). So I think it would be beneficial to capture this in one place and articulate it explicitly, rather than implicitly across the documents. Some of the salient points for starters:

* WHOIS data has historically included personal information about registrants, has been made public, and has not had the benefit of authentication or access control mechanisms to gate access to it. In part as a result of this, proxy and privacy services have arisen to shield the identities of registrants.

* The standardization of RDAP does not change or impact the data that registries may require to be collected from registrants. However, RDAP data structures allow servers to indicate when data returned to clients has been made private, redacted, obscured, or shielded by a proxy.

* RDAP uses the jCard standard format for entity representation, but many of the jCard fields are irrelevant for registry operation purposes and their use should be minimized.

* RDAP includes mechanisms that can be used to authenticate clients, allowing servers to support tiered access based on local policy. This means that all registration data need no longer be public, and personal data or data that may be considered more sensitive can have its access restricted to specifically privileged clients.

* [Something about confidentiality of requests and responses ... see my other DISCUSS point below.]

* etc.

= Section 3.4 =
"If the policy of the server operator
  requires encryption to protect client-server data exchanges (such as
  to protect non-public data that can not be accessed without client
  identification and authentication), HTTP Over TLS MUST be used to
  protect those exchanges."

It is unclear to me that a server policy that allows unencrypted access should be allowed, particularly in the cases of entity-related requests, but perhaps also in the case of other requests. The fact that the registry data may be public is orthogonal to the question of whether a particular query for that data should have confidentiality protection. I'd like to understand why RDAP does not require HTTP over TLS to be used in all cases and instead allows unsuspecting client users to send their queries in the clear in cases where server policy does not mandate use of TLS. I'm especially curious about this since clients are required to support HTTPS anyway.

[Ballot comment]
= Section 3.1 =
"RDAP's authentication framework needs to accommodate anonymous access
  as well as verification of identities"

I would suggest s/anonymous access/unauthenticated access/ since generally it can be pretty difficult to remain anonymous when accessing anything over IP.

Similar comment for 3.2, I would delete "or anonymous."

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-weirds-rdap-sec-09, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Security Services for the Registration Data Access Protocol) to Proposed Standard


The IESG has received a request from the Web Extensible Internet
Registration Data Service WG (weirds) to consider the following document:
- 'Security Services for the Registration Data Access Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-10-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Note that this is a second Last Call. During its initial IESG Evaluation,
the IESG had several issues to address. This document has addressed
those issues.

Abstract


  The Registration Data Access Protocol (RDAP) provides "RESTful" web
  services to retrieve registration metadata from domain name and
  regional internet registries.  This document describes information
  security services including authentication, authorization,
  availability, data confidentiality, and data integrity for RDAP.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Murray Kucherawy is the document shepherd.
Pete Resnick is the responsible Area Director.

  The Registration Data Access Protocol (RDAP) provides "RESTful" web
  services to retrieve registration metadata from domain name and
  regional internet registries.  This document describes information
  security services, specific requirements for RDAP, and approaches to
  provide RDAP security services.

The document is requesting Proposed Standard status as per the definition of a Technical Specification in RFC2026 Section 3.1.  It defines a set of protocol requirements and solutions for those, and as such is part of an overall protocol specification.

2. Review and Consensus

The document has received broad review and support of the participants of the WEIRDS working group.  Expert review of the Security Area Directorate will happen automatically, so such was not explicitly solicited to date.  No other external reviews from other directorates or expertise areas appear to be necessary as this merely discusses security requirements and does not touch directly on other services (e.g., DNS) or concepts (e.g., internationalization).

3. Intellectual Property

As of the first pass through the IESG:

Each author has so indicated.  The Working Group was reminded on the mailing list of participant obligations under BCPs 78 and 79, and no reports or discussion resulted.

As of this pass:

One author has re-confirmed.  Have not heard from the other (N. Kong).

4. Other Points

This is the second pass through IESG Evaluation for this document.  It was sent back on the first pass with some DISCUSSes (that have been addressed) and also because the IESG wanted to see all of the referenced documents together.  This time they're all coming at once.

The document contains a normative reference to a non-IETF document, identified as [OpenID].  It also contains downward references to RFC2818 and RFC4732; the latter of these does not appear in the Downref Registry.

Nothing else of interest.

1. Summary

Murray Kucherawy is the document shepherd.
Pete Resnick is the responsible Area Director.

  The Registration Data Access Protocol (RDAP) provides "RESTful" web
  services to retrieve registration metadata from domain name and
  regional internet registries.  This document describes information
  security services, specific requirements for RDAP, and approaches to
  provide RDAP security services.

The document is requesting Proposed Standard status as per the definition of a Technical Specification in RFC2026 Section 3.1.  It defines a set of protocol requirements and solutions for those, and as such is part of an overall protocol specification.

2. Review and Consensus

The document has received broad review and support of the participants of the WEIRDS working group.  Expert review of the Security Area Directorate will happen automatically, so such was not explicitly solicited to date.  No other external reviews from other directorates or expertise areas appear to be necessary as this merely discusses security requirements and does not touch directly on other services (e.g., DNS) or concepts (e.g., internationalization).

3. Intellectual Property

As of the first pass through the IESG:

Each author has so indicated.  The Working Group was reminded on the mailing list of participant obligations under BCPs 78 and 79, and no reports or discussion resulted.

As of this pass:

One author has re-confirmed.  Have not heard from the other (N. Kong).

4. Other Points

This is the second pass through IESG Evaluation for this document.  It was sent back on the first pass with some DISCUSSes (that have been addressed) and also because the IESG wanted to see all of the referenced documents together.  This time they're all coming at once.

The document contains a normative reference to a non-IETF document, identified as [OpenID].  It also contains downward references to RFC2818 and RFC4732; the latter of these does not appear in the Downref Registry.

Nothing else of interest.

IESG comments on this indicated that it would be better to wait until other WEIRDS documents before making the final call on this. Will put it back on the telechat at a later date.

[Ballot comment]
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!

[Ballot discuss]
(1) The Authentication section should be Client Authentication, since that's all it covers.  Shouldn't there be some discussion of Server Authentication as well?

(2) I don't see anything here or in draft-ietf-weirds-using-http that says that RDAP clients MUST support TLS.  Shouldn't that be the case, since HTTPS is the standard security mechanism?  You should probably also consider how this would impact requirements around URIs for RDAP services.

[Ballot discuss]
s3.1 contains the following:

To that end, RDAP clients and
  servers MUST implement the authentication framework specified in
  "HTTP Authentication: Basic and Digest Access Authentication"
  [RFC2617].

Does that mean the client and server need to support both basic and digest?

s3.1: I think the gist here that should maybe be made clearer is that servers need MUST implement TLS with server side certificates - no?  What I'm curious about here is whether there should be a SRV-ID or URI-ID is needed for RDAP and isn't some kind of reference to RFC 6125 warranted here?

[Ballot comment]

- 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.

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
In 3.1.  Authentication, this text:

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

Is a beautiful thing, 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, or say what kinds of things are likely to be problematic, then you could say that RDAP needs to be prepared to use that if necessar, 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?

[Ballot comment]
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.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-weirds-rdap-sec-04, which is currently in
Last Call, and has the following comment from the IANA reviewer
team:

We understand that, upon approval of this document, there are no IANA
Actions that need completion.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Security Services for the Registration Data Access Protocol) to Proposed Standard


The IESG has received a request from the Web Extensible Internet
Registration Data Service WG (weirds) to consider the following document:
- 'Security Services for the Registration Data Access Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-07-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Registration Data Access Protocol (RDAP) provides "RESTful" web
  services to retrieve registration metadata from domain name and
  regional internet registries.  This document describes information
  security services including authentication, authorization,
  availability, data confidentiality, and data integrity for RDAP.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-weirds-rdap-sec/ballot/


No IPR declarations have been submitted directly on this I-D.