[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
- [apps-discuss] APPS Area review of draft-ietf-geo… Tobias Gondrom