[apps-discuss] APPS Area review of draft-ietf-geopriv-policy-uri-04

Tobias Gondrom <tobias.gondrom@gondrom.org> Sat, 10 December 2011 05:18 UTC

Return-Path: <tobias.gondrom@gondrom.org>
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 19B0821F8510 for <apps-discuss@ietfa.amsl.com>; Fri, 9 Dec 2011 21:18:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.227
X-Spam-Level:
X-Spam-Status: No, score=-95.227 tagged_above=-999 required=5 tests=[AWL=1.550, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, 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 1uazrhtAgfLt for <apps-discuss@ietfa.amsl.com>; Fri, 9 Dec 2011 21:18:06 -0800 (PST)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (www.gondrom.org [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 939CF21F8508 for <apps-discuss@ietf.org>; Fri, 9 Dec 2011 21:18:05 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=b0fVTB4KlAWOozASr0RbfexRSUE3jObe6pOYRgFrCa1qwgiQSaIgEZ5L9ijwz1jIQWuXb9gF/pZA3LgElxErsXtpk1jjMLnGNjxOnrw2NqJt7Gxz5cxeE+3msMSo/ajw; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type;
Received: (qmail 24212 invoked from network); 10 Dec 2011 06:18:02 +0100
Received: from unknown (HELO ?10.5.8.213?) (61.8.220.69) by www.gondrom.org with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Dec 2011 06:18:01 +0100
Message-ID: <4EE2EB83.5000800@gondrom.org>
Date: Sat, 10 Dec 2011 05:17:55 +0000
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111110 Thunderbird/8.0
MIME-Version: 1.0
To: apps-discuss@ietf.org, draft-ietf-geopriv-policy-uri.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------030803050209090600050403"
Cc: iesg@ietf.org
Subject: [apps-discuss] APPS Area review of draft-ietf-geopriv-policy-uri-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: Sat, 10 Dec 2011 05:18:07 -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-geopriv-policy-uri-04
Title: Location Configuration Extensions for Policy Management
Reviewer: Tobias Gondrom
Review Date: 10.12.11

Summary:
"This draft is almost ready for publication as an RFC but has a few 
issues around access control and data leakage (allowed use of http) that 
should be fixed before publication."


Major Issues:

1. Section 3.1
"Knowledge of the policy URI can be considered adequate evidence of 
authorization"
As far as I understand that would imply that there is no further access 
control for GET/PUT/DELETE intended?
I am not sure I would agree with that. Using that paradigm possible 
attackers could indeed try to ping for a variety of URI addresses and 
will either receive a "does not exist" or the policy resource (in which 
case they would automatically be granted with the right to delete or 
update the policy)?
Furthermore if more than one device/service shares the same policy URI, 
they will have both full read/write access to the policy?
Therefore I would strongly suggest to add notes that update and delete 
request MUST/SHOULD be authorised/authenticated by other means beyond 
pure knowledge or URI.

2. The creation criteria in section 3.2 are nice but appear to be 
insufficient/too weak:
"A policy URI is effectively a shared secret between Location Server
    and its clients.  Knowledge of a policy URI is all that is required
    to perform any operations allowed on the policy.  Thus, a policy URI
    should be constructed so that it is hard to predict and
    confidentiality-protected when transmitted (see Section 7).  To avoid
    re-using these shared secrets, the Location Server MUST generate a
    new policy URI whenever it generates a new location URI set."

Please consider that a server defending against brute force scanning 
with the current model will only reply with 404 (not found) to 
non-existant resources (which in general is no indication for a server 
that an attack is under way, e.g. there could equally be a search engine 
or site mapping scanner be at work). While when using a form of 
authentication the server can distinguish failed access attempts as it 
will result in 401/403 errors access denied / forbidden - errors that 
can more easily used to identify failed attempts to gain access to 
policy URIs.

3. Also consider that with "A policy URI is effectively a shared secret 
between Location Server and its clients." and the above section on 
access rights all involved parties have equal access rights for 
GET/PUT/DELETE, although they may not always be intended to be symmetric?

4. Section 4.1.
" A policy URI MUST
    use the "http:" or "https:" scheme, and the Location Server MUST
    support the specified operations on the URI."
Considering the confidential nature of the URI and the shared secret 
aspects, you should amend this by at least strongly suggesting that the 
"https scheme SHOULD be used whenever possible".

the same in section 4.2.


Minor Issues:
some of the abstract and introduction are particularly hard to read 
(even for RFCs). It might be useful to let a native speaker read over 
them and make them smoother / easier to understand.


Best regards, Tobias