Subject: [apps-discuss] AppsDir review of draft-ietf-weirds-rdap-sec-04

From: Tony Hansen <[email-masked]>
Date: Sun, 28 Jul 2013 07:01:44 -0400

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document:  draft-ietf-weirds-rdap-sec-04

Title: Security Services for the Registration Data Access Protocol (RDAP)

Reviewer: Tony Hansen
Review Date: 2013-07-28
IESG Telechat Date: unknown
IETF Last Call Expires: 2013-07-31

* Summary: The document is almost ready for publication. Minor notes follow.

The document describes the topics of authentication, authorization, 
availability, data confidentiality and data integrety for RDAP. Since
RDAP  is built on top of HTTP/S, this document is often able to do this
task by pointing to and deferring to another documents.

A series of suggestions are made below. None are blocking.

* Major:

none

* Minor

Section 3.1.1, paragraphs 3 and 4:

Should HTTP Over TLS be mandated when using bearer-token-based 
authentication methods?

Section 3.2, paragraph 2:

Are there any RDAP servers that *only* allow one level of access to
data,  such as anonymous access to a limited set of attributes? If so,
add the  caveat, or the MUST probably should be a SHOULD.  On the flip
side, I'm  wondering if "Server operators will offer" should instead say
"Server  operators SHOULD offer". Would it be better to swap the order
of the first two sentences in this paragraph? (The following also
incorporates both of the above comments.)

OLD:   An RDAP server MUST provide granular access controls (that is, on a
OLD:   per registration data object basis) in order to implement
OLD:   authorization policies.  Server operators will offer varying degrees
OLD:   of access depending on policy and need in conjunction with the
OLD:   authentication methods described in Section 3.1.  Some examples:

NEW:   Server operators SHOULD offer varying degrees of access depending
NEW:   on policy and need in conjunction with the authentication methods
NEW:   described in Section 3.1.  If such varying degrees of access are
NEW:   supported, an RDAP server MUST provide granular access controls
NEW:   (that is, on a per registration data object basis) in order to
NEW:   implement authorization policies.  Some examples:

Section 5:

Should there be mention that a NULL encryption layer MUST NOT be used 
when HTTP Over TLS is used?

Should mention be made about always checking the server credentials to 
help alleviate possible man in the middle (MITM) attacks?

Should there be a reference to the Security Considerations sections of
the other documents referenced within this document, such as HTTP and OAuth?

* Nits

Section 3.1.1, paragraph 5:
OLD: entity called "Certification
NEW: entity called a "Certification

Section 3.1.1, paragraph 5:
OLD: and can be introduced into RDAP.
NEW: and can be used with RDAP.

Section 5, paragraph 2:
OLD: and html script
NEW: and HTML script