Subject: [dhcwg] Re: [Geopriv] draft-ietf-geopriv-dhcp-civil-07

From: Andrew Newton <[email-masked]>
Date: Fri, 14 Oct 2005 10:15:57 -0400

On Sep 14, 2005, at 10:52 AM, Marc Linsner wrote:
> I'd like clarification on:
>
> 1) Since neither this document nor RFC 3825 defines the wiremap  
> database
> architecture, I don't understand this db security concern.  How can  
> the
> transport of a db record be a security risk to the effecting of  
> database
> change within the unknown database architecture?  Is this not a  
> concern for
> the database administration?  We should not disallow this function  
> solely
> based on the assumption of poor database administration design.

The text you quoted does not mention anything about a wiremap  
database.  But 3694 does specifically mention host database security  
issues.  And it is not uncommon for wire protocol specification to  
make requirements upon host databases for security reasons (see some  
of the SASL docs).

> 2) Since upstream communication of this LCI information would still  
> take
> place within the confines of the 'sighting' category, a trusted and
> controlled environment, what has happened that has made this upstream
> communication fall under issue #3 (above)?  This LCI option can  
> only contain
> information allowed by the draft, whether it's upstream or downstream.

As the text stated, the classic example of a sighter is a GPS unit  
wired directly to a node acting as a location generator.  Sending of  
location information to any node that is not the location generator  
is not the sighting function.

-andy

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: John Schnizlein <[email-masked]>
Date: Mon, 17 Oct 2005 13:03:41 -0400

> make requirements upon host databases for security reasons (see some 

The part of Marc's message that you (copied below) does, in fact 
include "security concerns related to using DHCP to update the 
database".  What database other than the one that maps DHCP relay-agent 
information options to location might this mean?

On Sep 14, 2005, at 10:52 AM, Marc Linsner wrote:
> Henning,
>
> Wrt:
>
> "This document only defines the delivery of location information from 
> the
> DHCP server to the client, due to security concerns related to using 
> DHCP to
> update the database.  Within the GEOPRIV architecture as defined by 
> RFC 3693
> [10], the defined mechanism in this document for conveying initial 
> location
> information is known as a "sighting" function.  Sighting functions are 
> not
> required to have security capabilities and are only intended to be
> configured in trusted and controlled environments.  (A classic example 
> of
> the sighting function is a Global Positioning System wired directly to 
> a
> network node.) After initial location information has been introduced, 
> it
> MUST be afforded the protections defined in RFC 3694 [11].  Therefore,
> location information MUST NOT be sent from a DHCP client to a DHCP 
> server as
> is normally allowed by DHCP."
>
> Correct me if I've interpreted this wrong.  I derived from this text 
> (at
> least) 3 issues:
>
> 1) Due to [wiremap] database security concerns, we must disallow 
> client to
> dhcp server [upstream] communication of this LCI.
>
> 2) This DHCP LCI mechanism falls under the 'sighting' category as 
> defined in
> the geopriv architecture used in trusted and controlled environments.
>
> 3) Communication of location information outside of this special 
> 'sighting'
> category must be afforded the protections defined in RFC 3694.

[end of deleted portion of Sept 14 email]

>> communication fall under issue #3 (above)?  This LCI option can only 
>> contain
> location information to any node that is not the location generator is 
> not the sighting function.

The parenthetical example of GPS as a sighting function is not the only 
possible sighting function.  The other examples on part 8 of RFC 3693 
are manually entered locations and locations configured through DHCP.   
In fact RFC 3825 specifies another sighting function, which uses DHCP.

I do not see in RFC 3693 any prohibition of sending location without 
the Location Object defined therein.  What I see is "A key goal of the 
protocol described in this document is to facilitate the protection of 
privacy", which is much less strident than the text proposed in 
draft-ietf-geopriv-dhcp-civil-07.

My impression is that Marc was attempting to find the justification for 
the statement: "location information MUST NOT be sent from a DHCP 
client to a DHCP server as is normally allowed by DHCP."  I still don't 
see just what the "security concerns are for one direction of transfer 
compared to the other.  There is, of course, no requirement that the 
database be changed by the receipt of location in a DHCP option.  The 
reason for prohibition is not the normal reason that violation of the 
MUST NOT impairs the operation of the protocol.

John