[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