Re: [Geopriv] [geopriv] #37: Section 3

"geopriv issue tracker" <trac@tools.ietf.org> Tue, 24 August 2010 21:15 UTC

Return-Path: <trac@tools.ietf.org>
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 AA4F83A6952 for <geopriv@core3.amsl.com>; Tue, 24 Aug 2010 14:15:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.571
X-Spam-Level:
X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 DYGDcDsuYX2x for <geopriv@core3.amsl.com>; Tue, 24 Aug 2010 14:15:56 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id A9CA53A690F for <geopriv@ietf.org>; Tue, 24 Aug 2010 14:15:56 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from <trac@tools.ietf.org>) id 1Oo0r6-0006XS-Mv; Tue, 24 Aug 2010 14:16:28 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: geopriv issue tracker <trac@tools.ietf.org>
X-Trac-Version: 0.11.7
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.7, by Edgewall Software
To: bernard_aboba@hotmail.com, martin.thomson@andrew.com
X-Trac-Project: geopriv
Date: Tue, 24 Aug 2010 21:16:28 -0000
X-URL: http://tools.ietf.org/geopriv/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/geopriv/trac/ticket/37#comment:2
Message-ID: <076.67733666628b3be15b2c9016bc2fe240@tools.ietf.org>
References: <067.9168665e27c42ab3edfebb880650885b@tools.ietf.org>
X-Trac-Ticket-ID: 37
In-Reply-To: <067.9168665e27c42ab3edfebb880650885b@tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, martin.thomson@andrew.com, geopriv@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: geopriv@ietf.org
Subject: Re: [Geopriv] [geopriv] #37: Section 3
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/geopriv>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Aug 2010 21:15:57 -0000

#37: Section 3
------------------------------------------+---------------------------------
 Reporter:  bernard_aboba@…               |        Owner:  bernard_aboba@…           
     Type:  defect                        |       Status:  closed                    
 Priority:  major                         |    Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                    |      Version:  1.0                       
 Severity:  Waiting for Shepherd Writeup  |   Resolution:  fixed                     
 Keywords:                                |  
------------------------------------------+---------------------------------
Changes (by bernard_aboba@…):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Here is a potential change to Section 3 to include references to RFC 3693
 and 3694, as well as to address the tampering as well as confidentiality
 issues:

 Geopriv requirements (including security requirements) are discussed in
 "Geopriv Requirements" [RFC3693].
 A threat analysis is provided in "Threat Analysis of the Geopriv Protocol"
 [RFC3694].

 Since there is no privacy protection for DHCP messages, an
 eavesdropper who can monitor the link between the DHCP server and
 requesting client can discover this LCI.

 To minimize the unintended exposure of location information, the LCI
 option SHOULD be returned by DHCP servers only when the DHCP client
 has included this option in its 'parameter request list' (section 3.5
 [RFC2131]).

 Where critical decisions might be based on the value of this
 option, DHCP authentication as defined in
 "Authentication for DHCP Messages" [RFC3118] and "Dynamic Host
 Configuration
 Protocol for IPv6 (DHCPv6)" [RFC3315] SHOULD be used to protect the
 integrity of the DHCP options.

 Link layer confidentiality and integrity protection may also be employed
 to reduce the
 risk of location disclosure and tampering.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/37#comment:2>
geopriv <http://tools.ietf.org/geopriv/>