Subject: Re: [Geopriv] HELD-04 comments: LO-Sec draft reference

From: "Mary Barnes" <[email-masked]>
Date: Tue, 12 Feb 2008 15:56:55 -0600

To address James' concern about the reference to the LO-Sec draft,
Richard Barnes graciously put together a proposal for an updated
security section that would obviate the need to reference the LO-Sec
draft.  I made a few tweaks to Richard's proposed text and would like to
provide the proposal to the WG for review prior to making that large
update in the document.  To avoid the problem with attachments for some
folks, the text is inline below (this is intended to replace the
entirety of the current section 9)

Mary.

========================================================================
==================

9. Security Considerations

HELD is a location acquisition protocol whereby the a client requests
its location from a LIS.  Specific requirements and security
considerations for location
acquisition protocols are provided in [11].  An in-depth discussion of
the security considerations applicable to the use of Location URIs and
by-reference provision of LI is included in [15]. 

By using the HELD protocol, the client and the LIS expose themselves to
two types of risk:

Accuracy: Client receives incorrect location information
Privacy: An unauthorized entity receives location information

These two risks are addressed in the two sections below, followed by a
summary of the security considerations for implementations of the HELD
protocol.

9.1 Accuracy

The provision of an accurate location to the requestor depends on the
success of four steps: 

1. The client must determine the proper LIS
2. The client must connect to the proper LIS
3. The LIS must be able to return the desired location
4. HELD messages must be transmitted unmodified between the LIS and the
client

Of these, only the second and the fourth are within the scope of this
document.  The first step is based on either manual configuration or on
the LIS discovery defined in [14, in which appropriate security
considerations are already discussed.  The third step is dependent on
the specific positioning capabilities of the LIS, and is thus outside
the scope of this document.  

9.1.1 Assuring that the proper LIS has been contacted
After the client has initiated a connection to a LIS, it can receive
different levels of assurance that this LIS is the proper LIS based on
whether the proper LIS is identified by a domain name or an IP address.

When the LIS is identified by a domain name and the HELD transaction is
conducted using TLS, the LIS can authenticate itself to the client using
the standard mechanism of presenting a certificate binding that domain
name to the public key used in TLS.  Therefore, any binding of HELD MUST
be capable of being transacted over TLS so that the client can request
the above authentication, and a LIS implementation for a binding MUST
include this feature.  Note that in order for the presented certificate
to be valid at the client, the client must be able to validate the
certificate; in particular, the validation path of the certificate must
end in one of the client's trust anchors (even if that trust anchor is
the LIS certificate itself).  

When the proper LIS is identified by an IP address, there is a risk that
a malicious LIS could mimic the proper LIS by spoofing that IP address.
If the client deems this risk unacceptable, it is recommended that the
client perform a DNS lookup on the corresponding domain name in the
in-addr.arpa domain to determine a domain name for the LIS.  If a domain
name is available, then the standard TLS authentication mechanism can
then be used to authenticate the identity of the LIS.  If not, then the
client can obtain no further assurance about the authenticity of the
contacted LIS.  In order to minize the probability of such spoofing
attacks, administrative domains that offer a LIS SHOULD take measures to
prevent IP address spoofing [ref:BCP38][ref:BCP84].

9.1.2 Protecting responses from modification
In order to prevent that response from being modified en route, messages
must be transmitted over an integrity-protected channel.  When the
transaction is being conducted over TLS (a required feature per Section
9.1.1), the channel will be integrity protected by appropriate
ciphersuites.  When TLS is not used, this protection will vary depending
on the binding; in most cases, without protection from TLS, the response
will not be protected from modification en route.  

9.2 Privacy and Confidentiality
Location information returned by the LIS must be protected from access
by unauthorized parties, whether those parties request the location from
the LIS or intercept it en route. As in section 9.1.2, transactions
conducted over TLS with appropriate ciphersuites are protected from
access by unauthorized parties en route.  Conversely, in most cases,
when not conducted over TLS, the response will be accessible while en
route from the LIS to the requestor.

Because HELD is an LCP and identifies clients and targets by IP
addresses, a requestor is authorized to access location for an IP
address only if it is the holder of that IP address.  The LIS MUST
verify that the client is the target of the returned location, i.e., the
LIS MUST NOT provide location to other entities than the target.  (Note
that this is a necessary, but not sufficient criterion for
authorization.  A LIS MAY deny requests according to any local policy.)

A prerequisite for meeting this requirement is that the LIS must have
some assurance of the identity of the client.  Since the target of the
returned location is identified by an IP address, simply sending the
response to this IP address will provide sufficient assurance in many
cases.  This is the default mechanism in HELD for assuring that location
is given only authorized clients; LIS implementations MUST support a
mode of operation in which this is the only client authentication.

Using IP return routability as an authenticator means that location
information is vulnerable to exposure through IP address spoofing
attacks.  A temporary spoofing of IP address could mean that a device
could request a Location URI that would result in another Device's
location.  One or more of the following approaches are RECOMMENDED to
limit this exposure:
   o  Location URIs SHOULD have a limited lifetime, as reflected by the
      value for the expires element (Section 6.5.1).
   o  The network SHOULD have mechanisms that protect against IP address
      spoofing, e.g., [ref:BCP38].
   o  The LIS and network SHOULD be configured so that the LIS is made
      aware of Device movement within the network and addressing
      changes.  If the LIS detects a change in the network, then all
      location URIs SHOULD be invalidated.

The above measures are dependent on network configuration, which SHOULD
be considered.  For instance, in a fixed internet access, providers may
be able to restrict the allocation of IP addresses to a single physical
line, ensuring that spoofing is not possible; in such an environment,
other measures may not be necessary.

When there are further mechanisms available to authenticate ownership of
the IP address, the LIS SHOULD use them to authenticate that the client
is the owner of the target IP address.  For example, in a TLS
transaction, the client could present a certificate with a public key
bound to an IPv6 Cryptographically Generated Address, and the LIS could
verify this binding.  

9.3 Summary of Security Considerations
The following summarizes the security considerations for implementations
of the HELD protocol:
o All bindings MUST provide the following security services:
   - Authentication of a LIS domain name
   - Integrity of messages between the client and the LIS
   - Confidentiality of messages between the client and the LIS
o It is RECOMMENDED that all bindings use TLS [2].  
o For the HTTP binding, TLS MUST be implemented.  The server
authentication methods
  described in HTTP on TLS [4] MUST be implemented.
o A LIS implementation for a binding MUST support the specified security

  features
o A LIS MUST verify that the requestor is the target of the returned
location
o A LIS MUST support operation when the only client authentication
available is
  via IP return routability
o A LIS SHOULD set expiration times for location URIs it issues
o Administrative domains SHOULD take measures to prevent IP address
spoofing

========================================================================
==================

_______________________________________________
Geopriv mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 12 Feb 2008 17:11:12 -0600

This looks good to me.  Thanks to Richard and Mary for their effort on
this.

Can we make the requirement for an expiry time on location URIs a MUST
please?

Regarding:
> If the LIS detects a change in the network, then all

The definition of "change" needs expansion.  A change of access point
doesn't necessarily imply that the location URI is no longer valid.
Perhaps "If the LIS detects a change in the network that results in it
no longer being able to determine the location of the Device, then all
location URIs for that Device SHOULD be invalidated."  Sure, that's more
words, but if I were being perverse, I could read this to mean that a
Device changing access points causes location URIs for all devices in
the access network to be invalidated.

Cheers,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Mary Barnes
> Sent: Wednesday, 13 February 2008 8:57 AM
> To: Winterbottom, James
> Cc: [email-masked]
> Subject: Re: [Geopriv] HELD-04 comments: LO-Sec draft reference
> 
=======================================================================
> =
=======================================================================
> =

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 13 Feb 2008 11:26:10 -0600

Martin,

The suggestion for the rewording of your second point is fine. 

As far as changing the SHOULD to a MUST, my concern would be whether
this gets into us trying to define behavior on the LIS that is
un-enforceable and not directly related to the protocol, which is why it
is a SHOULD, per previous discussions. This is also consistent, for
example with section 6.5.1 "Expires", where we just say that the URIs
will expire at that point in time and not that the "LIS MUST invalidate
the URIs".

Mary. 

-----Original Message-----
From: Thomson, Martin [mailto:[email-masked]] 
Sent: Tuesday, February 12, 2008 5:11 PM
To: Barnes, Mary (RICH2:AR00); Winterbottom, James
Cc: [email-masked]
Subject: RE: [Geopriv] HELD-04 comments: LO-Sec draft reference

Cheers,
Martin

> draft.  I made a few tweaks to Richard's proposed text and would like 
> to provide the proposal to the WG for review prior to making that 
> large update in the document.  To avoid the problem with attachments 
> for
some
> considerations for location acquisition protocols are provided in 
> [11].  An in-depth discussion of the security considerations 
> applicable to the use of Location URIs and by-reference provision of 
> LI is included in [15].
> 

> 1. The client must determine the proper LIS 2. The client must connect

> to the proper LIS 3. The LIS must be able to return the desired 
> location 4. HELD messages must be transmitted unmodified between the 
> LIS and
the
> 9.1.1 Assuring that the proper LIS has been contacted After the client

> has initiated a connection to a LIS, it can receive different levels 
> of assurance that this LIS is the proper LIS based on whether the 
> proper LIS is identified by a domain name or an IP
address.
> conducted using TLS, the LIS can authenticate itself to the client 
> using the standard mechanism of presenting a certificate binding that 
> domain name to the public key used in TLS.  Therefore, any binding of 
> HELD MUST be capable of being transacted over TLS so that the client 
> can request the above authentication, and a LIS implementation for a 
> binding MUST include this feature.  Note that in order for the 
> presented
certificate

> When the proper LIS is identified by an IP address, there is a risk 
> that a malicious LIS could mimic the proper LIS by spoofing that IP
address.

> in-addr.arpa domain to determine a domain name for the LIS.  If a 
> domain name is available, then the standard TLS authentication 
> mechanism can then be used to authenticate the identity of the LIS.  
> If not, then
the
> attacks, administrative domains that offer a LIS SHOULD take measures 
> to prevent IP address spoofing [ref:BCP38][ref:BCP84].
> 
> 9.1.2 Protecting responses from modification In order to prevent that 
> response from being modified en route, messages must be transmitted 
> over an integrity-protected channel.  When the transaction is being 
> conducted over TLS (a required feature per
Section
> ciphersuites.  When TLS is not used, this protection will vary 
> depending on the binding; in most cases, without protection from TLS, 
> the response will not be protected from modification en route.
> 

> by unauthorized parties, whether those parties request the location 
> from the LIS or intercept it en route. As in section 9.1.2, 
> transactions conducted over TLS with appropriate ciphersuites are 
> protected from access by unauthorized parties en route.  Conversely, 
> in most cases, when not conducted over TLS, the response will be 
> accessible while en route from the LIS to the requestor.
> 
> verify that the client is the target of the returned location, i.e., 
> the LIS MUST NOT provide location to other entities than the target.
(Note

> cases.  This is the default mechanism in HELD for assuring that 
> location is given only authorized clients; LIS implementations MUST 
> support a mode of operation in which this is the only client 
> authentication.
> 
> When there are further mechanisms available to authenticate ownership 
> of the IP address, the LIS SHOULD use them to authenticate that the
client
> 9.3 Summary of Security Considerations The following summarizes the 
> security considerations for implementations of the HELD protocol:
>    - Confidentiality of messages between the client and the LIS o It 
> is RECOMMENDED that all bindings use TLS [2].
> location o A LIS MUST support operation when the only client 
> authentication available is
> o A LIS SHOULD set expiration times for location URIs it issues o 
> Administrative domains SHOULD take measures to prevent IP address 
> spoofing
> 
> 
>

------------------------------------------------------------------------
------------------------
This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender immediately
and delete the original.  Any unauthorized use of this email is
prohibited.
------------------------------------------------------------------------
------------------------
[mf2]

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 13 Feb 2008 15:32:45 -0600

This begs the question of what an "expired" URI means if it is still
able to yield the location of the Target. I think that if it doesn't
mean that LIS MUST NOT provide the Target's location, then we need to be
very clear about what it does mean, and what the user can expect.

Cheers
James

> From: Mary Barnes [mailto:[email-masked]]
> Sent: Thursday, 14 February 2008 4:26 AM
> To: Thomson, Martin; Winterbottom, James
> Cc: [email-masked]

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 13 Feb 2008 16:13:17 -0600

I think that you are reading more into my comment than I intended.

All I meant to point out was that the "expires" attribute is mandatory.
The LIS MUST provide this:

>   Responses to Location requests for Location URIs MUST include the
>   expiry time of the Location URI.  

Discussions about whether the expiry actually takes place or not are
almost irrelevant.  I'm of the opinion that the LIS should be true to
its "word", but that would be the prerogative of the LIS.  These issues
fall into the same category as whether or not Location Recipients honour
the retention-expiry and retransmission-allowed attributes of the
PIDF-LO.

Ta,
Martin

> From: Winterbottom, James
> Sent: Thursday, 14 February 2008 8:33 AM
> To: Mary Barnes; Thomson, Martin
> Cc: [email-masked]
> mean that LIS MUST NOT provide the Target's location, then we need to
> be very clear about what it does mean, and what the user can expect.
> 
> Cheers
> James
> 
> 
> 
> > un-enforceable and not directly related to the protocol, which is
why
> it
> > > By using the HELD protocol, the client and the LIS expose
> themselves
> > to
> > > two types of risk:
> > >
> > > document.  The first step is based on either manual configuration
> or
> > on
> > > When the LIS is identified by a domain name and the HELD
> transaction
> > is
> > > end in one of the client's trust anchors (even if that trust
anchor
> is
> > >    o  Location URIs SHOULD have a limited lifetime, as reflected
by
> > > be considered.  For instance, in a fixed internet access,
providers
> > may
---------------------------------------------------------------------
> ---
> immediately
---------------------------------------------------------------------
> ---

---

From: "Stark, Barbara" <[email-masked]>
Date: Thu, 14 Feb 2008 07:39:11 -0500

Given that it's possible for Location URIs to exist that do not have or
need expiry (e.g., the SIP PUID can be used as a location URI), I
disagree that expiry needs to be mandatory. I don't think it's necessary
for IETF to unnecessarily limit the types of location URIs that can be
returned by a LIS. I also think that it's ok to place the onus of
intelligent implementation on LIS operators. 
Barbara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Thomson, Martin
Sent: Wednesday, February 13, 2008 5:13 PM
To: Winterbottom, James; Mary Barnes
Cc: [email-masked]
Subject: Re: [Geopriv] HELD-04 comments: LO-Sec draft reference

Ta,
Martin

why
anchor
by
providers

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621

---

From: "Mary Barnes" <[email-masked]>
Date: Fri, 22 Feb 2008 17:29:44 -0600

Hi all,

This is one of the comments which has not been addressed in the HELD-05.
The  concern I had with Barbara's suggestion as I was addressing all the
comments is that it seemed to change the general context of that
paragraph, so I would suggest something slightly different.  My
understanding was that the LIS was using HELD so that it could then
provide the LI for the other protocols, so that's the context of my
proposal. If that's not the case, I might agree with James' suggestion
to remove that paragraph altogether : 

OLD:
   It could also be useful for a VPN device to serve as a LIS for other
   location configuration options such as Dynamic Host Configuration
   Protocol (DHCP)[23] or Link Layer Discovery Protocol - Media Endpoint
   Discovery (LLDP-MED) [27].  VPN devices that serve as a LIS may
   acquire their own location using HELD.

NEW:
   It could also be useful for a VPN device to acquire its location
using HELD 
   in order to server as a LIS for other
   location configuration options such as Dynamic Host Configuration
   Protocol (DHCP)[23] or Link Layer Discovery Protocol - Media Endpoint
   Discovery (LLDP-MED) [27].  
   In this case, it is undesirable for the VPN device that 
   receives its location in a PIDF-LO document, to convert the location 
   into a format that conveys less information when sending the 
   location to other devices. 

Mary. 

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Monday, January 21, 2008 2:07 PM
To: Ted Hardie; Stark, Barbara; Barnes, Mary (RICH2:AR00)
Cc: [email-masked]
Subject: RE: [Geopriv] HELD-04 comments: VPN device serving as a LIS

My concern is still that this is a HELD specification, and that we do
not need to, and in my opinion should not be discussing, how one might
acquire location using HELD and then convert it another LCP format. LCPs
are orthogonal, you use one or the other. This paragraph blends them and
it is still unclear to me why you would do it except to accommodate end
points that don't comply with other IETF specifications.

Cheers
James

> From: Ted Hardie [mailto:[email-masked]]
> Sent: Tuesday, 22 January 2008 5:27 AM
> To: Stark, Barbara; Winterbottom, James; Mary Barnes
> Cc: [email-masked]
> Subject: RE: [Geopriv] HELD-04 comments: VPN device serving as a LIS
> 
> At 1:17 PM -0500 1/21/08, Stark, Barbara wrote:
> >Perhaps if we change the last paragraph of 4.3.1 to:
> >
> >   VPN devices that serve as a LIS may acquire their own location
using
> >HELD, or another configuration options such as Dynamic Host 
> >Configuration Protocol (DHCP)[21] or Link Layer Discovery Protocol - 
> >Media Endpoint Discovery (LLDP-MED) [25]. When acting as a LIS,
however,
> >it is undesirable for a device that receives or has location in a 
> >PIDF-LO format, to convert that PIDF-LO into a format that conveys
less
> >information, in order to send the location to other devices.
> >
> >I think this covers both the shape and civic complaint, as well as
loss
> >of other information.
> >Barbara
> 
> I think this looks good; James, does it cover the issue from your 
> perspective?
> 
> 					Ted
> 
> 
> 
> >From: Ted Hardie [mailto:[email-masked]]
> >Sent: Monday, January 21, 2008 12:40 PM
> >To: Stark, Barbara; Winterbottom, James; Mary Barnes
> >Cc: [email-masked]
> >Subject: RE: [Geopriv] HELD-04 comments: VPN device serving as a LIS
> >
> >At 12:30 PM -0500 1/21/08, Stark, Barbara wrote:
> >>It's not just a problem related to shapes. Converting a civic
PIDF-LO
> >to
> >>DHCP or LLDP-MED format would also lose info. In a civic PIDF-LO,
it's
> >>possible to convey much more information than it is in the other
two.
> >>Barbara
> >
> >Can you draft language for 4.3 that captures that?
> >			regards,
> >				Ted
> >
> >
> >
> >>From: Ted Hardie [mailto:[email-masked]]
> >>Sent: Monday, January 21, 2008 12:22 PM
> >>Subject: Re: [Geopriv] HELD-04 comments: VPN device serving as a LIS
> >>
> >>At 6:42 PM -0600 1/20/08, Winterbottom, James wrote:
> >>>[AJW] To be really clear, the last paragraph of section 4.3.1 says:
> >>>
> >>>"It could also be useful for a VPN device to serve as a LIS for
other
> >>>   location configuration options such as Dynamic Host
Configuration
> >>>   Protocol (DHCP)[21] or Link Layer Discovery Protocol - Media
> >>Endpoint
> >>>   Discovery (LLDP-MED) [25].  VPN devices that serve as a LIS may
> >>>   acquire their own location using HELD."
> >>>
> >>>I read this as saying, that the VPN device can get its location
using
> >>>HELD, and then distribute this to terminals inside the VPN using
DHCP
> >>or
> >>>LLDP-MED.
> >>>
> >>>This is not a good idea, particularly if locations are going to be 
> >>>provided a geodetic shapes.
> >>
> >>Would it be useful to add this data to the paragraph, rather than 
> >>removing the paragraph?  That is "VPN devices that serve as a LIS 
> >>may acquire their own location using configuration, HELD, or other 
> >>methods.  If the location the LIS is provided is a
> >point,
> >>there
> >>is, however, a risk of information loss in cases where the devices 
> >>they serve are not at that same point"?
> >>
> >>I think the aim in 4.3 is to try to give folks a general
understanding
> >>of how NATs, VPNs,  and Location information servers will interact.
> >>Adding data which clarifies the interaction seems more useful to me
> >than
> >>cutting it;  someone will come up with the idea of co-locating a VPN

> >>and LIS without this working group putting the idea in their head, 
> >>and it would be better if the upsides and downsides were clear.
> >>	my two cents,
> >>				Ted
> >>
> >>
> >>
> >>
> >>>As currently defined, the only shapes I can represent in DHCP and 
> >>>LLDP-MED is a point, which require my HELD intermediary to convert 
> >>>location from one form to another. I am
> >>strongly
> >>>opposed this proposal as it results in the loss of information with
no
> >>>arguments being presented as to why it should be done. According to

> >>>phone BCP DHCP, LLDP-MED and HELD must all be implemented by 
> >>>end-devices, so there is no benefit to these devices of the VPN
device
> >>>performing this conversion.
> >>>
> >>>
> >>>Cheers
> >>>James
>
-
> >-
> >>-------------------------
> >>>immediately and delete the original.  Any unauthorized use of this 
> >>>email is prohibited.
>
-
> >-
> >>-------------------------
> >>>[mf2]
> >>>
> >>>
> >>>
> >>>https://www1.ietf.org/mailman/listinfo/geopriv
> >>
> >>
> >>
> >>https://www1.ietf.org/mailman/listinfo/geopriv
> >>
> >>*****
> >>
> >>The information transmitted is intended only for the person or
entity
> >to which it is addressed and may contain confidential, proprietary, 
> >and/or privileged material. Any review, retransmission, dissemination
or
> >other use of, or taking of any action in reliance upon this
information
> >by persons or entities other than the intended recipient is
prohibited.
> >If you received this in error, please contact the sender and delete
the
> >material from all computers. GA621
> >>
> >>
> >>
> >>
> >>https://www1.ietf.org/mailman/listinfo/geopriv
> >
> >
> >*****
> >
> >The information transmitted is intended only for the person or entity
to
> which it is addressed and may contain confidential, proprietary,
and/or
> privileged material. Any review, retransmission, dissemination or
other
> use of, or taking of any action in reliance upon this information by 
> persons or entities other than the intended recipient is prohibited.
If
> you received this in error, please contact the sender and delete the 
> material from all computers. GA623
>

---

From: "Winterbottom, James" <[email-masked]>
Date: Fri, 22 Feb 2008 19:03:34 -0600

Hi Mary,

It is okay if it HELD to HELD, becuase the VPN is essentially acting a relay.
It is absolutely not okay for the VPN device to be HELD to the serving LIS and then be DHCP to end-device.
As I pointed out previously this latter case is also totally unnecessary if we follow what phone BCP is saying, because all devices MUST support all methods anyway.

Cheers
James

-----Original Message-----
From: Mary Barnes [mailto:[email-masked]]
Sent: Fri 2/22/2008 5:29 PM
To: Winterbottom, James; Ted Hardie; Stark, Barbara
Cc: [email-masked]
Subject: RE: [Geopriv] HELD-04 comments: VPN device serving as a LIS
 
Hi all,

OLD:

NEW:

Mary. 

-----Original Message-----
From: Winterbottom, James [mailto:[email-masked]] 
Sent: Monday, January 21, 2008 2:07 PM
To: Ted Hardie; Stark, Barbara; Barnes, Mary (RICH2:AR00)
Cc: [email-masked]
Subject: RE: [Geopriv] HELD-04 comments: VPN device serving as a LIS

Cheers
James

using
however,
less
loss
PIDF-LO
it's
two.
other
Configuration
using
DHCP
understanding

no

device
-
-
entity
or
information
prohibited.
the
to
and/or
other
If