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

Tony Hansen <tony@att.com> Sun, 28 July 2013 11:02 UTC

Return-Path: <tony@att.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B3D21F9E12 for <apps-discuss@ietfa.amsl.com>; Sun, 28 Jul 2013 04:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRH7qnErWXhK for <apps-discuss@ietfa.amsl.com>; Sun, 28 Jul 2013 04:02:15 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id B24E121F9D7C for <apps-discuss@ietf.org>; Sun, 28 Jul 2013 04:02:09 -0700 (PDT)
Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 13af4f15.0.4599388.00-286.12677992.nbfkord-smmo05.seg.att.com (envelope-from <tony@att.com>); Sun, 28 Jul 2013 11:02:09 +0000 (UTC)
X-MXL-Hash: 51f4fa310086602a-b0ac119d39dc7eeb0a5d97b654e4dae3d3ef0cd3
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6SB29Yo009932 for <apps-discuss@ietf.org>; Sun, 28 Jul 2013 07:02:09 -0400
Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r6SB21IJ009785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <apps-discuss@ietf.org>; Sun, 28 Jul 2013 07:02:01 -0400
Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for <apps-discuss@ietf.org>; Sun, 28 Jul 2013 11:01:54 GMT
Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r6SB1sPb003891 for <apps-discuss@ietf.org>; Sun, 28 Jul 2013 07:01:54 -0400
Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r6SB1m0f003697 for <apps-discuss@ietf.org>; Sun, 28 Jul 2013 07:01:48 -0400
Received: from [135.70.211.112] (vpn-135-70-211-112.vpn.east.att.com[135.70.211.112]) by maillennium.att.com (mailgw1) with ESMTP id <20130728110147gw100bhhqje> (Authid: tony); Sun, 28 Jul 2013 11:01:47 +0000
X-Originating-IP: [135.70.211.112]
Message-ID: <51F4FA18.3070900@att.com>
Date: Sun, 28 Jul 2013 07:01:44 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: General discussion of application-layer protocols <apps-discuss@ietf.org>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <tony@att.com>
X-SOURCE-IP: [144.160.20.145]
X-AnalysisOut: [v=2.0 cv=Sa5AgItu c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a]
X-AnalysisOut: [=VqjyMmk8zjQA:10 a=3ukmKKXcZEAA:10 a=AU4YzUH8exEA:10 a=ofM]
X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK]
X-AnalysisOut: [OAAAA:8 a=019WWEsUgd0A:10 a=48vgC7mUAAAA:8 a=XnzZ4a7KPFAC0]
X-AnalysisOut: [EnsmLMA:9 a=wPNLvfGTeEIA:10]
Subject: [apps-discuss] AppsDir review of draft-ietf-weirds-rdap-sec-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jul 2013 11:02:21 -0000

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