IETF Logo Mail Archive

Re: [Geopriv] Q2 about draft-ietf-geopriv-lbyr-requirements-01

Richard Barnes <rbarnes@bbn.com> Tue, 26 February 2008 20:43 UTC

Return-Path: <geopriv-bounces@ietf.org>
X-Original-To: ietfarch-geopriv-archive@core3.amsl.com
Delivered-To: ietfarch-geopriv-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEDE63A6B70; Tue, 26 Feb 2008 12:43:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.882
X-Spam-Level:
X-Spam-Status: No, score=-0.882 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZ4lZTIFadwx; Tue, 26 Feb 2008 12:43:23 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3B6B28C205; Tue, 26 Feb 2008 12:43:23 -0800 (PST)
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3A83A6B70 for <geopriv@core3.amsl.com>; Tue, 26 Feb 2008 12:43:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAARtSPBGxP7 for <geopriv@core3.amsl.com>; Tue, 26 Feb 2008 12:43:22 -0800 (PST)
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 5CDC73A6808 for <geopriv@ietf.org>; Tue, 26 Feb 2008 12:43:22 -0800 (PST)
Received: from col-dhcp33-244-155.bbn.com ([128.33.244.155] helo=localhost.localdomain) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <rbarnes@bbn.com>) id 1JU6dv-0001Zl-5r; Tue, 26 Feb 2008 15:43:15 -0500
Message-ID: <47C479DD.7000803@bbn.com>
Date: Tue, 26 Feb 2008 15:43:09 -0500
From: Richard Barnes <rbarnes@bbn.com>
User-Agent: Thunderbird 2.0.0.9 (X11/20071115)
MIME-Version: 1.0
To: "James M. Polk" <jmpolk@cisco.com>
References: <47B860C1.4070305@gmx.net> <E51D5B15BFDEFD448F90BDD17D41CFF103F3EDB6@AHQEX1.andrew.com> <XFE-SJC-211xHwMQFLc000042ec@xfe-sjc-211.amer.cisco.com> <47B8EC4A.6000809@bbn.com> <8C837214C95C864C9F34F3635C2A6575093E0A5F@SEA-EXCHVS-2.telecomsys.com> <XFE-SJC-211ogqY5b300000523a@xfe-sjc-211.amer.cisco.com> <47C36FC7.4030601@bbn.com> <XFE-SJC-211RZlz8OO7000054f8@xfe-sjc-211.amer.cisco.com>
In-Reply-To: <XFE-SJC-211RZlz8OO7000054f8@xfe-sjc-211.amer.cisco.com>
Cc: GEOPRIV <geopriv@ietf.org>
Subject: Re: [Geopriv] Q2 about draft-ietf-geopriv-lbyr-requirements-01
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: geopriv-bounces@ietf.org
Errors-To: geopriv-bounces@ietf.org

James,

> see, I don't believe merely having the URI means the LIS will answer a 
> query for the location.  This means there is no purpose in the rulemaker 
> in setting up role based rules and black lists.

This is the crux of the disagreement: Others in the group do believe 
that such URIs without Rule Makers or any access controls are useful. 
If you have a HELD LIS that will give a URI to any host on its network, 
that LIS may or may not have any way to authenticated dereferences to 
the URIs it issues.

My previous emails have been addressing this use case, and only this use 
case.  If access controls are being applied, then there is no 
requirement for randomization or anonymity.  If you have a close enough 
relationship with your LIS that you can tell it what policy to apply, 
then you don't need a randomized URI.

Look again at R*:

R*: The dereference protocol MUST define an anonymized format for 
location URIs.  This format MUST identify the desired LO  by a random 
token with at least 128 bits of entropy (rather than an explicit 
identifier, such as an IP address).  Any URI whose dereference will not 
subject to authentication and access control MUST be anonymized.

First, it says that there MUST be a format that includes sufficient 
entropy -- not that anyone has to use it.  The only cases where it does 
mandate usage is when the LS isn't applying policy to the dereference.

There are two separate use cases here, access-controlled (with RM) and 
non-access-controlled (without RM).  The requirements for randomization 
and anonymization apply *only* to the latter.

--Richard
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
http://www.ietf.org/mailman/listinfo/geopriv

v2.23.0 | Report a Bug | By Email