Subject: [Geopriv] Security considerations for draft-winterbottom-geopriv-held-identity-extensions

From: Bernard Aboba <[email-masked]>
Date: Mon, 26 Jan 2009 17:21:58 -0800

Section 5.1 includes advise to address the authorization issue:
 
"  For location configuration, the LIS MUST ensure that claimed identity    information belongs to the requester before relying upon it.  If this   verification cannot be performed, the LIS MUST treat the request as   if it were a third party request."
 
Unfortunately, the text does not include a description of what theMUST entails in a practical sense, or what information would berequired to assure that a claimed identity "belongs" to therequester.  
 
This issue seems critical to me if we are to avoid leakage oflocation information which could have tragic consequences. 
 
For example, absent the use of DNSSEC, I do not believe that DNScan be used to check authorization to acquire location information. As we know, DNS servers are easily poisoned, and if DNS cachepoisoning could be leveraged to obtain user location information,then that would be quite scary. 
 
Similarly, we need to be careful about how to check a MAC addressassertion.  Mechanisms such as IEEE 802.1AR or the WiMAX certificateprofile can include the MAC address within a certificate, and via
EAP-TLS, can prove possession of the associated private key.  This is
probably a reasonable level of assurance.   
 
On the other hand, unauthenticated mechanisms such as DHCP 
or ARP do not provide a secure binding between the MAC address 
and an IP address.
 
We even need to be careful about the level of proof providedby different mechanisms.  For example, the following levelscome to mind: 
 
1. Return reachability.  The use of HELD without an identityextension provides evidence that the source IP address haspassed the "return reachability" test.  Some L2 mechanisms(e.g. IEEE 802.11 4-way handshake) provide an equivalentlevel of assurance.  Note that this claim does not necessarilyenable verification of "belonging" in a global sense.  Forexample, there could be many valid owners of a 192.168/16 address in various parts of the world. 
 
2. Authenticated identity.  Authenticationmechanisms typically only enable validation of asingle identity claim.  Other information may beassociated with the authentication exchange, butis not cryptographically verified.  For example,multiple users on a WLAN could utilize the sameMAC address to authentication successfully.  Ifthe users were assigned address on differentVLANs, then the effects of this might not be obvious.  
 
Given these considerations,  the paragraph below is notvery convincing:
"  For example, a MAC address provided by a target device can be   verified by performing a DHCP lease-query ([RFC4388]).  Identity   extensions such as tel: URIs and hostnames can be validated using   network services such as the DNS, ENUM, LDAP and SIP registrars."
 
I'd suggest that Section 5.1 needs to be more clear about exactlywhat kind of "verification" is provided by the cited mechanisms,
and what specific procedures need to be followed to guard against
leakage. 

 EMAILING FOR THE GREATER GOODJoin me

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 26 Jan 2009 21:58:47 -0600

Hi Bernard,

The document purposefully does not describe what the authentication “MUST” entails for a few reasons:

1.       What degree of surety that is needed will necessarily depend on circumstances and policy.

2.       Enumerating the measures that might be taken in a range of different network deployments would be futile.

3.       Laziness: this is an aspect that I’ve thought about, but not explored in the kind of detail that you seem to be seeking.  To be fair, this aspect has not been a major concern to date.

On the first, this sort of guidance is something that can always be improved.  I hope that this is what you are looking for.  As far as I’m concerned, the others are understandable.

Your characterisation of return reachability is a good starting point.  This is a pretty good mechanism in some networks, and marginal in others.  But the next option from here isn’t direct authentication as you suggest, as hinted in the second cited paragraph, independent verification might be possible.  If I was to require proof that you owned a particular identifier, I could ask you to prove that you owned it directly through a reachability test, but that goes against what this draft is attempting to achieve.  After all, this is for the case where the LIS wants[1] this information; if the LIS could acquire the identifier itself so easily, there would scarcely be a point to the use case. 

Certainly, there are means by which a host is able to prove ownership of an identifier using crypto, but these direct methods are not necessarily always an option.  Such methods will probably need more work in the “solution” aspect of the document, which is still open[2].

What if the LIS asked you to prove that you have a given IP address though a reachability test, then acquired proof by some other means that the identifier and IP address were coincident.  Would it be unreasonable to attribute a similar degree of surety to the identifier as the surety derived from the reachability test?  Of course it can only be weaker, but whether that additional step embodies an unbearable risk I’ll leave to the person whose neck is on the line.

As for the throwaway paragraph cited, your email has prompted me to think it through.  I’ll rip it out and provide more like what I’ve described above in the next revision, in the absence of strenuous objections (or stunningly superior alternatives).

Cheers,

Martin

[1] “want” is preferred over “need” since “need” implies that the LIS is entirely reliant on the information.  The opportunity for falsification becomes much worse if the LIS properly needs  the information.

[2] http://www.ietf.org/mail-archive/web/geopriv/current/msg06679.html

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Tuesday, 27 January 2009 12:22 PM
To: [email-masked]
Subject: [Geopriv] Security considerations for draft-winterbottom-geopriv-held-identity-extensions

"  For location configuration, the LIS MUST ensure that claimed identity 
   information belongs to the requester before relying upon it.  If this
   verification cannot be performed, the LIS MUST treat the request as
   if it were a third party request."
 
Unfortunately, the text does not include a description of what the
MUST entails in a practical sense, or what information would be
required to assure that a claimed identity "belongs" to the
requester.  
 
This issue seems critical to me if we are to avoid leakage of
location information which could have tragic consequences. 
 
For example, absent the use of DNSSEC, I do not believe that DNS
can be used to check authorization to acquire location information. 
As we know, DNS servers are easily poisoned, and if DNS cache
poisoning could be leveraged to obtain user location information,
then that would be quite scary. 
 
Similarly, we need to be careful about how to check a MAC address
assertion.  Mechanisms such as IEEE 802.1AR or the WiMAX certificate
profile can include the MAC address within a certificate, and via
EAP-TLS, can prove possession of the associated private key.  This is
probably a reasonable level of assurance.   

We even need to be careful about the level of proof provided
by different mechanisms.  For example, the following levels
come to mind: 
 
1. Return reachability.  The use of HELD without an identity
extension provides evidence that the source IP address has
passed the "return reachability" test.  Some L2 mechanisms
(e.g. IEEE 802.11 4-way handshake) provide an equivalent
level of assurance.  Note that this claim does not necessarily
enable verification of "belonging" in a global sense.  For
example, there could be many valid owners of a 192.168/16 
address in various parts of the world. 
 
2. Authenticated identity.  Authentication
mechanisms typically only enable validation of a
single identity claim.  Other information may be
associated with the authentication exchange, but
is not cryptographically verified.  For example,
multiple users on a WLAN could utilize the same
MAC address to authentication successfully.  If
the users were assigned address on different
VLANs, then the effects of this might not 
be obvious.  
 
Given these considerations,  the paragraph below is not
very convincing:

"  For example, a MAC address provided by a target device can be
   verified by performing a DHCP lease-query ([RFC4388]).  Identity
   extensions such as tel: URIs and hostnames can be validated using
   network services such as the DNS, ENUM, LDAP and SIP registrars.
"
 
I'd suggest that Section 5.1 needs to be more clear about exactly
what kind of "verification" is provided by the cited mechanisms,
and what specific procedures need to be followed to guard against
leakage. 

------------------------------------------------------------------------------------------------
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]
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 28 Jan 2009 15:36:21 -0800

Martin Thomson said:

"What if the LIS asked you to prove that you have a given IP
address though a reachability test, then acquired proof by some other means
that the identifier and IP address were coincident.  Would it be unreasonable
to attribute a similar degree of surety to the identifier as the surety derived
from the reachability test?  Of course it can only be weaker, but whether that
additional step embodies an unbearable risk I’ll leave to the person whose neck
is on the line.

"

The LIS can obtain the IP address of the requester from the source address in the HELD request. 

The source IP address has implicitly passed a "return reachability" test, since a TCP 3-way handshake had to

be completed in order for a HELD request to be received by the LIS.  Given this, if a different

IP address is included in the HELD extension, then the LIS knows that this represents a "third party"

request.  

Knowing whether the IP address argument is "first party" or "third party" is useful, but that's
only a first step.  Unfortunately, confirming IP address reachability doesn't help to determine
the validity of other identifiers such as the MAC address, network access NAI, etc. 

If the LIS is not on the same LAN as the requester, the original source MAC address will have
been replaced by the MAC address of the router, so that the LIS won't have a way of 

determining whether the MAC address in the extended HELD request was also used as the
original source MAC address of the frame sent by the requester. 

"if the LIS could acquire the identifier itself so easily, there
would scarcely be a point to the use case. "

The issue is really whether the identifier represents Personally Identifiable Information (PII) or not,
and whether the LIS can determine whether the requester is authorized to obtain the location
of the device associated with that PII.   

The MAC address case is perhaps the most tricky, since a MAC address could represent the
location of network infrastructure not associated with a person (e.g. the BSSID of a 
stationary AP installed and owned by the enterprise).  In such a case, one might argue that 
such a MAC address would not represent PII.  However, if the MAC address were associated 
with a mobile device owned by an employee and likely to be in close proximity to them, then
we might come to a different conclusion. 

In determining whether to answer a request made with a MAC address as a parameter, the
LIS could first attempt to determine whether a MAC address in a HELD extended request
was an infrastructure or personal address.   If it was determined to be an infrastructure
address, then different guidelines might apply.  

If the MAC address was determined to be person, then several approaches might be
used for the LIS to determine if the assertion was "third party" or "first party":

1.  In WiMAX or IEEE 802.1ar with IEEE 802.1X-REV, then the requester might have previously

presented a certificate which included the MAC address as a parameter, and the AAA server

may have been required to verify that the MAC address in use matched the one authorized

in the supplicant certificate.  In that case, the MAC address in the request could be mapped
to an NAI, and then it could be determined whether the authenticated identity utilized in the
HELD request was authorized to query information on that NAI, and if so, whether the
request was considered "first party" (e.g. the NAI and authenticated identity were closely
related) or "third party".  

2. By looking at existing  IP adress/MAC address bindings, such as those provided by 
MIB II, LLDP-MED notifications,  DHCP lease data, etc.   If the MAC address provided in 
the HELD request has a 1-1 binding  to the source IP address, this implies that the MAC 
address has been asserted by  the sender at the IP layer as well as in HELD.   

This isn't really an indication of "ownership" or "authorization" -- just a confirmation of 
consistency.  If the same MAC address also shows bindings to other IP addresses (perhaps 
on other LANs), then the binding is no longer "1-1" and it may not be possible for the 
LIS to confirm whether the MAC address is "first party" -- and in such a situation it may
be wisest to fail authorization or raise an alarm. 

Subject: RE: [Geopriv] Security considerations for draft-winterbottom-geopriv-held-identity-extensions
Date: Mon, 26 Jan 2009 21:58:47 -0600
From: [email-masked]
To: [email-masked]; [email-masked]

Hi Bernard,

The document purposefully does not describe what the authentication
“MUST” entails for a few reasons:

1.       What degree
of surety that is needed will necessarily depend on circumstances and policy.

2.       Enumerating
the measures that might be taken in a range of different network deployments would
be futile.

3.       Laziness:
this is an aspect that I’ve thought about, but not explored in the kind of
detail that you seem to be seeking.  To be fair, this aspect has not been a
major concern to date.

On the first, this sort of guidance is something that can always
be improved.  I hope that this is what you are looking for.  As far as I’m
concerned, the others are understandable.

Your characterisation of return reachability is a good starting
point.  This is a pretty good mechanism in some networks, and marginal in
others.  But the next option from here isn’t direct authentication as you
suggest, as hinted in the second cited paragraph, independent verification
might be possible.  If I was to require proof that you owned a particular
identifier, I could ask you to prove that you owned it directly through a
reachability test, but that goes against what this draft is attempting to
achieve.  After all, this is for the case where the LIS wants[1] this
information; if the LIS could acquire the identifier itself so easily, there
would scarcely be a point to the use case. 

Certainly, there are means by which a host is able to prove
ownership of an identifier using crypto, but these direct methods are not
necessarily always an option.  Such methods will probably need more work in the
“solution” aspect of the document, which is still open[2].

What if the LIS asked you to prove that you have a given IP
address though a reachability test, then acquired proof by some other means
that the identifier and IP address were coincident.  Would it be unreasonable
to attribute a similar degree of surety to the identifier as the surety derived
from the reachability test?  Of course it can only be weaker, but whether that
additional step embodies an unbearable risk I’ll leave to the person whose neck
is on the line.

As for the throwaway paragraph cited, your email has prompted me
to think it through.  I’ll rip it out and provide more like what I’ve described
above in the next revision, in the absence of strenuous objections (or
stunningly superior alternatives).

Cheers,

Martin

[1] “want” is preferred over “need” since “need” implies that
the LIS is entirely reliant on the information.  The opportunity for
falsification becomes much worse if the LIS properly needs  the information.

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard Aboba

To: [email-masked]

Subject: [Geopriv] Security considerations for
draft-winterbottom-geopriv-held-identity-extensions

Section 5.1 includes advise to address the
authorization issue:

   information belongs to the requester before relying upon it. 
If this

   verification cannot be performed, the LIS MUST treat the request
as

requester.  

and an IP address.

come to mind: 

be obvious.  

very convincing:

   verified by performing a DHCP lease-query ([RFC4388]). 
Identity

"

leakage. 

[mf2]

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 28 Jan 2009 17:42:29 -0800

Yes, it would help if some of this were included in the draft. 

I agree that the difference between infrastructure and personal authorization differs largely in the policy applied. 

As part of Step 3 the requesters authorized to ask the question "where is AP X?" may be different one from 
those authorized to ask "where is Frank's laptop?"  

Not that the answers to those two questions also might have very different security implications. 
If I ask "where is AP X?" this doesn't imply that I'm near AP X; I could just be interested in the answer.  
Is there anything in the response to the question that makes it clear what question the response was 
responding to? 

For example, if I send you a location (could be a reference) that represents a response to the question 
"where is AP X?", are you aware that this location represents an answer to that question as opposed to 
the question "where am I?"?  The distinction seems quite important, since the former question isn't
asserting my location, whereas the latter question is. 

Subject: RE: [Geopriv] Security considerations for draft-winterbottom-geopriv-held-identity-extensions
Date: Wed, 28 Jan 2009 19:00:28 -0600
From: [email-masked]
To: [email-masked]; [email-masked]

I totally agree with all that you’ve said here.  I’m just not
sure that this level of detail is warranted.  Let me see if I can abstract the
process a little.

Step 1:  Determine who is asking (the requester).  Client
authentication might have been used*, which will accomplish this. 
Alternatively, if the requester is not authenticated in any way, we use the source
IP address as their identity.

Step 2:  Determine who they are asking about (the target).   If
there is no identity parameter, they are asking about themselves.

Step 3:  Make an authorization decision.  We assume a default
rule that says that hosts are automatically authorized to request information
for themselves**.  The policy that is applied might extend this to include a set
of targets that a requester is authorized to request location for.

However, this doesn’t allow
for the case where the requester is asking about their own location where the
link isn’t immediately apparent.  It makes sense to check to see if they really
are asking for their own location.  So check for a link between the requester
identity and the target identity.

If a link can be established,
then the requester becomes authorized under the default rule.  As you point out,
there are range of options for establishing this link; however, I don’t see the
value in attempting to enumerate these.  What would be helpful is making it clear
that the link needs to be strong; any weakness in the method used to establish
the linkage could be exploited.

The link MUST be unequivocal—the
same identifier (or set thereof) cannot also potentially identify another
requester.  For instance, if the IP is not unique within the given context,
then it alone is not sufficient basis for establishing this link.

[[Note that within certain
constrained contexts duplicate identifiers can be used successfully.  If a
requester provides a MAC address that could also indicate another device, as
long as the information provided to the requester pertains only to them,
authorization by the default rule is still possible.  The concern only arises
if the LIS is unable to adequately distinguish between the two potential targets
based on the available identifiers.  Note also that the LIS can use other information,
such as the ingress network interface to help here.]]

Would it help if the above were included in the draft?

I see no need for a distinction between infrastructure and
personal equipment, except in the policy that is applied.  A fairly simple
means of establishing this distinction is through the policy.  Some requesters
might be authorized to request for certain target identities.  If the target
identifiers were easily distinguished, maybe by OUI, then the policy could
indicate this.

Cheers,

Martin

*It might be that there is an unstated assumption that the means
of authentication is out of scope.  The use cases presented so far concentrate
purely on pre-arrangement, which allows for advance negotiation of
authentication methods and the like.  Based on these, I don’t see a strong need
to provide a great deal more information on this mechanism.  On the contrary, I
think that more experience might be necessary before we can go there.

** This isn’t entirely true.  The work on location hiding doesn’t
assume that targets are completely authorized to retrieve their own location. 
Nonetheless, it still retains a watered-down version of this basic rule.

From: Bernard Aboba
[mailto:[email-masked]] 

Sent: Thursday, 29 January 2009 10:36 AM

To: Thomson, Martin; [email-masked]

Subject: RE: [Geopriv] Security considerations for
draft-winterbottom-geopriv-held-identity-extensions

Martin Thomson said:

"What if the LIS asked you to prove that you have a given IP
address though a reachability test, then acquired proof by some other means
that the identifier and IP address were coincident.  Would it be
unreasonable to attribute a similar degree of surety to the identifier as the
surety derived from the reachability test?  Of course it can only be
weaker, but whether that additional step embodies an unbearable risk I’ll leave
to the person whose neck is on the line. "

The LIS can obtain the IP address of the requester from the source address in
the HELD request. 

The source IP address has implicitly passed a "return reachability"
test, since a TCP 3-way handshake had to

be completed in order for a HELD request to be received by the LIS.  Given
this, if a different

IP address is included in the HELD extension, then the LIS knows that this
represents a "third party"

request.  

Knowing whether the IP address argument is "first party" or
"third party" is useful, but that's

only a first step.  Unfortunately, confirming IP address reachability
doesn't help to determine

the validity of other identifiers such as the MAC address, network access NAI,
etc. 

If the LIS is not on the same LAN as the requester, the original source MAC
address will have

been replaced by the MAC address of the router, so that the LIS won't have a
way of 

determining whether the MAC address in the extended HELD request was also used
as the

The issue is really whether the identifier represents Personally Identifiable
Information (PII) or not,

and whether the LIS can determine whether the requester is authorized to obtain
the location

The MAC address case is perhaps the most tricky, since a MAC address could
represent the

location of network infrastructure not associated with a person (e.g. the BSSID
of a 

stationary AP installed and owned by the enterprise).  In such a case, one
might argue that 

such a MAC address would not represent PII.  However, if the MAC address
were associated 

with a mobile device owned by an employee and likely to be in close proximity
to them, then

In determining whether to answer a request made with a MAC address as a
parameter, the

LIS could first attempt to determine whether a MAC address in a HELD extended
request

was an infrastructure or personal address.   If it was determined to
be an infrastructure

If the MAC address was determined to be person, then several approaches might
be

used for the LIS to determine if the assertion was "third party" or
"first party":

1.  In WiMAX or IEEE 802.1ar with IEEE 802.1X-REV, then the requester
might have previously

presented a certificate which included the MAC address as a parameter, and the
AAA server

may have been required to verify that the MAC address in use matched the one
authorized

in the supplicant certificate.  In that case, the MAC address in the
request could be mapped

to an NAI, and then it could be determined whether the authenticated identity
utilized in the

HELD request was authorized to query information on that NAI, and if so,
whether the

request was considered "first party" (e.g. the NAI and authenticated
identity were closely

2. By looking at existing  IP adress/MAC address bindings, such as those
provided by 

MIB II, LLDP-MED notifications,  DHCP lease data, etc.   If the
MAC address provided in 

the HELD request has a 1-1 binding  to the source IP address, this implies
that the MAC 

address has been asserted by  the sender at the IP layer as well as in
HELD.   

This isn't really an indication of "ownership" or
"authorization" -- just a confirmation of 

consistency.  If the same MAC address also shows bindings to other IP
addresses (perhaps 

on other LANs), then the binding is no longer "1-1" and it may not be
possible for the 

LIS to confirm whether the MAC address is "first party" -- and in
such a situation it may

Subject: RE: [Geopriv] Security
considerations for draft-winterbottom-geopriv-held-identity-extensions

Hi Bernard,

The document purposefully does not describe what the
authentication “MUST” entails for a few reasons:

1.       What
degree of surety that is needed will necessarily depend on circumstances and
policy.

2.       Enumerating
the measures that might be taken in a range of different network deployments
would be futile.

3.       Laziness:
this is an aspect that I’ve thought about, but not explored in the kind of
detail that you seem to be seeking.  To be fair, this aspect has not been
a major concern to date.

On the first, this sort of guidance is something that can always
be improved.  I hope that this is what you are looking for.  As far
as I’m concerned, the others are understandable.

Certainly, there are means by which a host is able to prove
ownership of an identifier using crypto, but these direct methods are not necessarily
always an option.  Such methods will probably need more work in the
“solution” aspect of the document, which is still open[2].

What if the LIS asked you to prove that you have a given IP
address though a reachability test, then acquired proof by some other means
that the identifier and IP address were coincident.  Would it be
unreasonable to attribute a similar degree of surety to the identifier as the
surety derived from the reachability test?  Of course it can only be
weaker, but whether that additional step embodies an unbearable risk I’ll leave
to the person whose neck is on the line.

As for the throwaway paragraph cited, your email has prompted me
to think it through.  I’ll rip it out and provide more like what I’ve
described above in the next revision, in the absence of strenuous objections
(or stunningly superior alternatives).

Cheers,

Martin

[1] “want” is preferred over “need” since “need” implies that
the LIS is entirely reliant on the information.  The opportunity for
falsification becomes much worse if the LIS properly needs  the
information.

[2]
http://www.ietf.org/mail-archive/web/geopriv/current/msg06679.html

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba

To: [email-masked]

 

"  For location configuration, the LIS MUST ensure that claimed
identity 

requester.  

and an IP address.

come to mind: 

be obvious.  

very convincing:

"

leakage. 

 

  [mf2]

[mf2]

---

From: Marc Linsner <[email-masked]>
Date: Thu, 29 Jan 2009 10:15:19 -0500

Martin, Bernard,

I¹m still perplexed about the verification process applied to determine
whether the request is LCP or third party.  If in fact, the proposed
verification process exonerates the request as LCP, what¹s the point of
identity extensions for LCP?  The LIS can simply gather the required
extended identity information via the same process.  The draft states that
if the verification check fails, the LCP request fails and it¹s treated as
third party.

I¹m not convinced by:

³ Note:  This might seem to negate much of the advantage provided by
      the inclusion of identity parameters for the LCP case.  However,
      checking that the identity information is correct is generally
      more feasible than acquiring the information in the first place²

Simply treating all requests with identity extensions as third party seems
easier. Hence, a host requesting it¹s own location doesn¹t have to worry
about identity extensions (ala less code), it¹s up to the LIS to figure out
what is needed and where to get it.

-Marc-

On 1/28/09 8:42 PM, "Bernard Aboba" <[email-masked]> wrote:

> I totally agree with all that you¹ve said here.  I¹m just not sure that this
> level of detail is warranted.  Let me see if I can abstract the process a
> little.
> 
> Step 1:  Determine who is asking (the requester).  Client authentication might
> have been used*, which will accomplish this. Alternatively, if the requester
> is not authenticated in any way, we use the source IP address as their
> identity.
> 
>                 
> 
> Step 2:  Determine who they are asking about (the target).   If there is no
> identity parameter, they are asking about themselves.
> 
>  
> 
> Step 3:  Make an authorization decision.  We assume a default rule that says
> that hosts are automatically authorized to request information for
> themselves**.  The policy that is applied might extend this to include a set
> However, this doesn¹t allow for the case where the requester is asking about
> their own location where the link isn¹t immediately apparent.  It makes sense
> to check to see if they really are asking for their own location.  So check
> for a link between the requester identity and the target identity.
> 
>  
> 
> If a link can be established, then the requester becomes authorized under the
> default rule.  As you point out, there are range of options for establishing
> this link; however, I don¹t see the value in attempting to enumerate these.
> What would be helpful is making it clear that the link needs to be strong; any
> weakness in the method used to establish the linkage could be exploited.
> 
>  
> 
> The link MUST be unequivocal‹the same identifier (or set thereof) cannot also
> potentially identify another requester.  For instance, if the IP is not unique
> within the given context, then it alone is not sufficient basis for
> establishing this link.
> 
> [[Note that within certain constrained contexts duplicate identifiers can be
> used successfully.  If a requester provides a MAC address that could also
> indicate another device, as long as the information provided to the requester
> pertains only to them, authorization by the default rule is still possible.
> The concern only arises if the LIS is unable to adequately distinguish between
> the two potential targets based on the available identifiers.  Note also that
> the LIS can use other information, such as the ingress network interface to
> help here.]]
> 
>  
> 
>  
> 
> I see no need for a distinction between infrastructure and personal equipment,
> except in the policy that is applied.  A fairly simple means of establishing
> this distinction is through the policy.  Some requesters might be authorized
> to request for certain target identities.  If the target identifiers were
> easily distinguished, maybe by OUI, then the policy could indicate this.
> 
>  
> 
> Cheers,
> 
> Martin
> 
>  
> 
> *It might be that there is an unstated assumption that the means of
> authentication is out of scope.  The use cases presented so far concentrate
> authentication methods and the like.  Based on these, I don¹t see a strong
> need to provide a great deal more information on this mechanism.  On the
> contrary, I think that more experience might be necessary before we can go
> there.
> 
>  
> 
> ** This isn¹t entirely true.  The work on location hiding doesn¹t assume that
> targets are completely authorized to retrieve their own location. Nonetheless,
> it still retains a watered-down version of this basic rule.
> 
>  
> 
> From: Bernard Aboba [mailto:[email-masked]]
> "What if the LIS asked you to prove that you have a given IP address though a
> reachability test, then acquired proof by some other means that the identifier
> and IP address were coincident.  Would it be unreasonable to attribute a
> similar degree of surety to the identifier as the surety derived from the
> reachability test?  Of course it can only be weaker, but whether that
> additional step embodies an unbearable risk I¹ll leave to the person whose
> neck is on the line. "
> 
> "if the LIS could acquire the identifier itself so easily, there would
> scarcely be a point to the use case. "
> 
> The document purposefully does not describe what the authentication ³MUST²
> entails for a few reasons:
> 
> 3.       Laziness: this is an aspect that I¹ve thought about, but not explored
> in the kind of detail that you seem to be seeking.  To be fair, this aspect
> has not been a major concern to date.
> 
>  
> 
> On the first, this sort of guidance is something that can always be improved.
> I hope that this is what you are looking for.  As far as I¹m concerned, the
> others are understandable.
> 
>  
> 
> Your characterisation of return reachability is a good starting point.  This
> is a pretty good mechanism in some networks, and marginal in others.  But the
> next option from here isn¹t direct authentication as you suggest, as hinted in
> the second cited paragraph, independent verification might be possible.  If I
> was to require proof that you owned a particular identifier, I could ask you
> to prove that you owned it directly through a reachability test, but that goes
> against what this draft is attempting to achieve.  After all, this is for the
> case where the LIS wants[1] this information; if the LIS could acquire the
> identifier itself so easily, there would scarcely be a point to the use case.
> 
>  
> 
> Certainly, there are means by which a host is able to prove ownership of an
> identifier using crypto, but these direct methods are not necessarily always
> an option.  Such methods will probably need more work in the ³solution² aspect
> of the document, which is still open[2].
> 
>  
> 
> What if the LIS asked you to prove that you have a given IP address though a
> reachability test, then acquired proof by some other means that the identifier
> and IP address were coincident.  Would it be unreasonable to attribute a
> similar degree of surety to the identifier as the surety derived from the
> reachability test?  Of course it can only be weaker, but whether that
> additional step embodies an unbearable risk I¹ll leave to the person whose
> neck is on the line.
> 
>  
> 
> As for the throwaway paragraph cited, your email has prompted me to think it
> through.  I¹ll rip it out and provide more like what I¹ve described above in
> the next revision, in the absence of strenuous objections (or stunningly
> superior alternatives).
> 
>  
> 
> Cheers,
> 
> Martin
> 
>  
> 
> [1] ³want² is preferred over ³need² since ³need² implies that the LIS is
> entirely reliant on the information.  The opportunity for falsification
> becomes much worse if the LIS properly needs  the information.
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 29 Jan 2009 16:44:05 -0600

Hi Marc,

I wont deny that the particular use case seems unnecessary on face value.  So you ask a reasonable question.

On the point of necessity, I have to admit that I’m not aware of a case where an identifier is necessary.  That doesn’t mean one doesn’t exist—I certainly remember that there was one, even if the details elude me.  For this case, verification must be achieved by authenticating the identity parameter – obviating the “go off and check” option.

I also cannot deny that choosing to include (and then use) the parameter in the LCP case implies a non-trivial amount of effort.  So unless there is a need, I doubt that this option will be used.

People do all sorts of crazy things to save even the most insignificant amount of time.  This is a fairly typical case.  A LIS might choose to verify in parallel to location determination, thereby shaving precious seconds from the time needed to produce an answer.

When presented with an option like this in a specification, there are only two ways to deal with such an option: forbid it outright, or give it proper treatment.  Since I believe that this method will be used, forbiddance is somewhat futile.  At least this way, people are aware of the consequences of their choice when they choose to do this.

Cheers,

Martin

From: Marc Linsner [mailto:[email-masked]] 
Sent: Friday, 30 January 2009 2:15 AM
To: Bernard Aboba; Thomson, Martin; [email-masked]
Subject: Re: [Geopriv] Security considerations for draft-winterbottom-geopriv-held-identity-extensions

Martin, Bernard,

I’m still perplexed about the verification process applied to determine whether the request is LCP or third party.  If in fact, the proposed verification process exonerates the request as LCP, what’s the point of identity extensions for LCP?  The LIS can simply gather the required extended identity information via the same process.  The draft states that if the verification check fails, the LCP request fails and it’s treated as third party.

I’m not convinced by:

“ Note:  This might seem to negate much of the advantage provided by
      the inclusion of identity parameters for the LCP case.  However,
      checking that the identity information is correct is generally
      more feasible than acquiring the information in the first place”

Simply treating all requests with identity extensions as third party seems easier. Hence, a host requesting it’s own location doesn’t have to worry about identity extensions (ala less code), it’s up to the LIS to figure out what is needed and where to get it.

-Marc-

…

---

From: Marc Linsner <[email-masked]>
Date: Thu, 29 Jan 2009 18:38:31 -0500

Martin,

What I hear you saying:

³We can¹t think of a use case, or where an identifier is necessary for LCP,
but I think I remember a need for one.  So, we should support such to assist
the crazy people who think they need that function.²

I¹m not convinced the workgroup needs to spend cycles with this as
justification.

I actually went back and reread the LCP-PS draft.  Yes, it talks about the
need for identity extension for the LCP use case.  But it also paints a
security/privacy requirement, in support of RFC3693/4, that doesn¹t allow a
feasible solution.  Not all requirements have a solution.  I think this may
be the case with LCP identity extensions.

-Marc-

On 1/29/09 5:44 PM, "Thomson, Martin" <[email-masked]> wrote:

> On the point of necessity, I have to admit that I¹m not aware of a case where
> an identifier is necessary.  That doesn¹t mean one doesn¹t exist‹I certainly
> remember that there was one, even if the details elude me.  For this case,
> verification must be achieved by authenticating the identity parameter 
> obviating the ³go off and check² option.
>  
> I also cannot deny that choosing to include (and then use) the parameter in
> the LCP case implies a non-trivial amount of effort.  So unless there is a
> need, I doubt that this option will be used.
>  
> People do all sorts of crazy things to save even the most insignificant amount
> of time.  This is a fairly typical case.  A LIS might choose to verify in
> parallel to location determination, thereby shaving precious seconds from the
> time needed to produce an answer.
>  
> When presented with an option like this in a specification, there are only two
> ways to deal with such an option: forbid it outright, or give it proper
> treatment.  Since I believe that this method will be used, forbiddance is
> somewhat futile.  At least this way, people are aware of the consequences of
> their choice when they choose to do this.
>  
> Cheers,
> Martin
>  
> 
> Subject: Re: [Geopriv] Security considerations for
> identity extensions for LCP?  The LIS can simply gather the required extended
> identity information via the same process.  The draft states that if the
> verification check fails, the LCP request fails and it¹s treated as third
> party.
> 
> I¹m not convinced by:
> 
> easier. Hence, a host requesting it¹s own location doesn¹t have to worry about
> identity extensions (ala less code), it¹s up to the LIS to figure out what is
> needed and where to get it.
> 
> -Marc-
> 
> Š
> 
> 
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 29 Jan 2009 15:43:20 -0800

The issue is that in many access networks, IP address assignment is handled separately from network access authentication.  As a result, a LIS may not keep track of location by IP address at all, but may be better prepared to return a location in response to an alternative identifier such as a MAC address or username. 
 
For such systems, being forced to treat all alternate identies as "third party" would prevent support for location from being deployed at all.  This seems silly particularly if the location request is authenticated with an identity that maps easily to the username used for network access.   Such a scheme will both readily allow the differentiation of "first party" and "third party" requests as well as fitting very well with the majority of backend AAA systems deployed today, with a high level of security and location privacy. 

From: Marc Linsner [mailto:[email-masked]] Sent: Friday, 30 January 2009 2:15 AMTo: Bernard Aboba; Thomson, Martin; [email-masked]: Re: [Geopriv] Security considerations for draft-winterbottom-geopriv-held-identity-extensions
 
Martin, Bernard,I’m still perplexed about the verification process applied to determine whether the request is LCP or third party.  If in fact, the proposed verification process exonerates the request as LCP, what’s the point of identity extensions for LCP?  The LIS can simply gather the required extended identity information via the same process.  The draft states that if the verification check fails, the LCP request fails and it’s treated as third party.I’m not convinced by:“ Note:  This might seem to negate much of the advantage provided by      the inclusion of identity parameters for the LCP case.  However,      checking that the identity information is correct is generally      more feasible than acquiring the information in the first place”Simply treating all requests with identity extensions as third party seems easier. Hence, a host requesting it’s own location doesn’t have to worry about identity extensions (ala less code), it’s up to the LIS to figure out what is needed and where to get it.-Marc-…

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

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 29 Jan 2009 16:05:23 -0800

Mark Linsner said:
"Yes, it talks about the need for identity extension for the LCP use case.  But it also paints a security/privacy requirement, in support of RFC3693/4, that doesn’t allow a feasible solution."
 
I would agree with you that there are some issues with the LCP-PS document.  Section 5 has some gaps with respect to the description of the information available to the LIS within existing access technologies.  However, the requirements outlined in Section 6 seems somewhat generic and largely harmless. 
 
Is this the requirement you are objecting to? 
   Requirement L7-1: Identifier Choice      The L7 LCP MUST be able to carry different identifiers or MUST      define an identifier that is mandatory to implement.  Regarding      the latter aspect, such an identifier is only appropriate if it is      from the same realm as the one for which the location information      service maintains identifier to location mapping.

Date: Thu, 29 Jan 2009 18:38:31 -0500From: [email-masked]: [email-masked]; [email-masked]: Re: [Geopriv] Security considerations for draft-winterbottom-geopriv-held-identity-extensionsMartin,What I hear you saying:“We can’t think of a use case, or where an identifier is necessary for LCP, but I think I remember a need for one.  So, we should support such to assist the crazy people who think they need that function.”I’m not convinced the workgroup needs to spend cycles with this as justification.I actually went back and reread the LCP-PS draft.  Yes, it talks about the need for identity extension for the LCP use case.  But it also paints a security/privacy requirement, in support of RFC3693/4, that doesn’t allow a feasible solution.  Not all requirements have a solution.  I think this may be the case with LCP identity extensions.-Marc-On 1/29/09 5:44 PM, "Thomson, Martin" <[email-masked]> wrote:
Hi Marc, I wont deny that the particular use case seems unnecessary on face value.  So you ask a reasonable question. On the point of necessity, I have to admit that I’m not aware of a case where an identifier is necessary.  That doesn’t mean one doesn’t exist—I certainly remember that there was one, even if the details elude me.  For this case, verification must be achieved by authenticating the identity parameter – obviating the “go off and check” option. I also cannot deny that choosing to include (and then use) the parameter in the LCP case implies a non-trivial amount of effort.  So unless there is a need, I doubt that this option will be used. People do all sorts of crazy things to save even the most insignificant amount of time.  This is a fairly typical case.  A LIS might choose to verify in parallel to location determination, thereby shaving precious seconds from the time needed to produce an answer. When presented with an option like this in a specification, there are only two ways to deal with such an option: forbid it outright, or give it proper treatment.  Since I believe that this method will be used, forbiddance is somewhat futile.  At least this way, people are aware of the consequences of their choice when they choose to do this. Cheers,Martin From: Marc Linsner [mailto:[email-masked]] Sent: Friday, 30 January 2009 2:15 AMTo: Bernard Aboba; Thomson, Martin; [email-masked]: Re: [Geopriv] Security considerations for draft-winterbottom-geopriv-held-identity-extensionsMartin, Bernard,I’m still perplexed about the verification process applied to determine whether the request is LCP or third party.  If in fact, the proposed verification process exonerates the request as LCP, what’s the point of identity extensions for LCP?  The LIS can simply gather the required extended identity information via the same process.  The draft states that if the verification check fails, the LCP request fails and it’s treated as third party.I’m not convinced by:“ Note:  This might seem to negate much of the advantage provided by      the inclusion of identity parameters for the LCP case.  However,      checking that the identity information is correct is generally      more feasible than acquiring the information in the first place”Simply treating all requests with identity extensions as third party seems easier. Hence, a host requesting it’s own location doesn’t have to worry about identity extensions (ala less code), it’s up to the LIS to figure out what is needed and where to get it.-Marc-…------------------------------------------------------------------------------------------------This message is for the designated recipient only and maycontain privileged, proprietary, or otherwise private information.  If you have received it in error, please notify the senderimmediately and delete the original.  Any unauthorized use ofthis email is prohibited.------------------------------------------------------------------------------------------------[mf2]

_______________________________________________Geopriv mailing [email-masked]://www.ietf.org/mailman/listinfo/geopriv

---

From: Marc Linsner <[email-masked]>
Date: Thu, 29 Jan 2009 19:44:00 -0500

OK, I¹ll retract the idea that all requests with identity extensions be
treated as third party, but only while you read the next paragraph.

I¹m not arguing about the usefulness of alternate identifiers in the pursuit
of location determination.  I¹m simply stating that since an alternate
identifier supplied by a LCP requestor MUST be validated prior to releasing
location information to such requestor, having that requestor supply such
alternate identifier is a useless step. The LIS can simply discover the
alternate identifier via the same mechanism used by the proposed identifier
extension validation process.  This enables the requestor to utilize the LCP
mechanism described in draft-ietf-geopriv-http-location-delivery-12.txt
without having to play the guessing game called Œalternate identifiers¹.

Hence, having a requestor supply the identity extension in the pursuit of
the LCP request is not necessary and should not be supported.  Therefore, if
a request is submitted with an identity extension embedded, it must be a
third party request.  Now, I¹m back to my assertion that all requests
containing identity extension MUST be considered a third party request.

-Marc-

On 1/29/09 6:43 PM, "Bernard Aboba" <[email-masked]> wrote:

> 
> The issue is that in many access networks, IP address assignment is handled
> separately from network access authentication.  As a result, a LIS may not
> keep track of location by IP address at all, but may be better prepared to
> return a location in response to an alternative identifier such as a MAC
> address or username.
> 
>  
> 
> For such systems, being forced to treat all alternate identies as "third
> party" would prevent support for location from being deployed at all.  This
> seems silly particularly if the location request is authenticated with an
> identity that maps easily to the username used for network access.   Such a
> scheme will both readily allow the differentiation of "first party" and "third
> party" requests as well as fitting very well with the majority of backend AAA
> systems deployed today, with a high level of security and location privacy.
> 
>  
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 29 Jan 2009 18:49:21 -0600

Hi Marc,

Did you miss the bit where I mentioned that validation doesn’t necessarily involve checking that: owner-of-IP == owner-of-alternative?  If the requester can prove that they own the identifier (I hear that PKI helps here), then the validation consists of a certificate check.

Cheers,

Martin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Linsner
Sent: Friday, 30 January 2009 11:44 AM
To: Bernard Aboba; [email-masked]
Subject: Re: [Geopriv] Security considerations for draft-winterbottom-geopriv-held-identity-extensions

OK, I’ll retract the idea that all requests with identity extensions be treated as third party, but only while you read the next paragraph.

I’m not arguing about the usefulness of alternate identifiers in the pursuit of location determination.  I’m simply stating that since an alternate identifier supplied by a LCP requestor MUST be validated prior to releasing location information to such requestor, having that requestor supply such alternate identifier is a useless step. The LIS can simply discover the alternate identifier via the same mechanism used by the proposed identifier extension validation process.  This enables the requestor to utilize the LCP mechanism described in draft-ietf-geopriv-http-location-delivery-12.txt without having to play the guessing game called ‘alternate identifiers’.

Hence, having a requestor supply the identity extension in the pursuit of the LCP request is not necessary and should not be supported.  Therefore, if a request is submitted with an identity extension embedded, it must be a third party request.  Now, I’m back to my assertion that all requests containing identity extension MUST be considered a third party request.

-Marc-

Martin, Bernard,

I’m not convinced by:

-Marc-

…

________________________________

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 29 Jan 2009 17:24:14 -0800

I would agree that an alternate identifier is of little use unless the LIS can map that identifier to location.  I would also agree that the LIS needs to validate the alternate identifier to determine whether it represents a first party or third party request.  

However, there may be situations in which there may not be an IP address to location mapping.  For example, switch ports typically do not have a unique IP address associated with them.  As a result, it is not possible to ask the question "where is port X?" based on an IP address. 

In such situations, alternate identifiers don't represent redundant overhead above and beyond what the LIS already is required to support; instead, they enable requests to be sent that could not otherwise be expressed. 

Relevant scenarios include IEEE 802 technologies (wired and wireless, LAN and MAN).  

Date: Thu, 29 Jan 2009 19:44:00 -0500
Subject: Re: [Geopriv] Security considerations for draft-winterbottom-geopriv-held-identity-extensions
From: [email-masked]
To: [email-masked]; [email-masked]

Re: [Geopriv] Security considerations for draft-winterbottom-geopriv-held-identity-extensions

-Marc-

 

 

 

Martin, Bernard,

I’m not convinced by:

-Marc-

…

[mf2]

Geopriv mailing list

[email-masked]

---

From: Marc Linsner <[email-masked]>
Date: Fri, 30 Jan 2009 13:30:27 -0500

Bernard,

We are in agreement.  A LIS may require identifiers other than IP address in
order to perform location determination.

-Marc-

On 1/29/09 8:24 PM, "Bernard Aboba" <[email-masked]> wrote:

> I would agree that an alternate identifier is of little use unless the LIS can
> map that identifier to location.  I would also agree that the LIS needs to
> validate the alternate identifier to determine whether it represents a first
> party or third party request.
> 
> However, there may be situations in which there may not be an IP address to
> location mapping.  For example, switch ports typically do not have a unique IP
> address associated with them.  As a result, it is not possible to ask the
> question "where is port X?" based on an IP address.
> 
> In such situations, alternate identifiers don't represent redundant overhead
> above and beyond what the LIS already is required to support; instead, they
> enable requests to be sent that could not otherwise be expressed.
> 
> Re: [Geopriv] Security considerations for
> draft-winterbottom-geopriv-held-identity-extensions OK, I¹ll retract the idea
> that all requests with identity extensions be treated as third party, but only
> while you read the next paragraph.
> 
> Hence, having a requestor supply the identity extension in the pursuit of the
> LCP request is not necessary and should not be supported.  Therefore, if a
> request is submitted with an identity extension embedded, it must be a third
> party request.  Now, I¹m back to my assertion that all requests containing
> identity extension MUST be considered a third party request.
> 
> -Marc-
> 
> 
> On 1/29/09 6:43 PM, "Bernard Aboba" <[email-masked]
> <http://hotmail.com> > wrote:
> 
>> 
>> scheme will both readily allow the differentiation of "first party" and
>> "third party" requests as well as fitting very well with the majority of
>> backend AAA systems deployed today, with a high level of security and
>> location privacy.
>> 
>>  
>> 
>> To: Bernard Aboba; Thomson, Martin; [email-masked] <http://ietf.org>
>> [email-masked] <http://ietf.org>

---

From: Marc Linsner <[email-masked]>
Date: Fri, 30 Jan 2009 13:38:44 -0500

Martin,

I don¹t understand the role of PKI in the LCP use case.  The LIS doesn¹t
know John Doe.  The LIS doesn¹t care that John Doe owns mac address x.y.z.
The LIS cares that IP address a.b.c. belongs to mac address x.y.z.  Any
other usage is not LCP, it¹s third party which falls under the policy set by
the rulemaker.

-Marc-

On 1/29/09 7:49 PM, "Thomson, Martin" <[email-masked]> wrote:

> Hi Marc,
>  
> Did you miss the bit where I mentioned that validation doesn¹t necessarily
> involve checking that: owner-of-IP == owner-of-alternative?  If the requester
> can prove that they own the identifier (I hear that PKI helps here), then the
> validation consists of a certificate check.
>  
> Cheers,
> Martin
>  
>

---

From: "Stark, Barbara" <[email-masked]>
Date: Fri, 30 Jan 2009 14:11:34 -0500

I tend to agree with Marc on this.

In the generic case, for any identity that a LIS is able to provide
location for, you would want to have a privacy policy. That policy would
state who is authorized to request location (and maybe some can only
request city while others get exact). In creating this policy, it would
make sense in most cases (but not all) to include the authentication
information (certificate, shared secret, whatever) of the Target as an
entity that can request location. But in doing it this way, the Target
looks just like any other party requesting location. 

An entity requesting location info provides authentication info which is
matched up against privacy policy of whatever they're asking location
for. Whether that authenticated identity belongs to the target itself or
someone else isn't relevant, because what they can get access to is
defined by the authorizations associated with the authenticated ID
within the policy. There is no need to further associate authentication
info as somehow belonging to the same device whose location is being
requested. That provides no additional info. Either the authenticated ID
is authorized or it isn't.

Barbara

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Marc Linsner
Sent: Friday, January 30, 2009 1:39 PM
To: Thomson, Martin; [email-masked]
Subject: Re: [Geopriv] Security considerations for
draft-winterbottom-geopriv-held-identity-extensions

Martin,

I don't understand the role of PKI in the LCP use case.  The LIS doesn't
know John Doe.  The LIS doesn't care that John Doe owns mac address
x.y.z.   The LIS cares that IP address a.b.c. belongs to mac address
x.y.z.  Any other usage is not LCP, it's third party which falls under
the policy set by the rulemaker.

-Marc-

Hi Marc,
 
Did you miss the bit where I mentioned that validation doesn't
necessarily involve checking that: owner-of-IP == owner-of-alternative?
If the requester can prove that they own the identifier (I hear that PKI
helps here), then the validation consists of a certificate check.
 
Cheers,
Martin

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Marc Linsner

OK, I'll retract the idea that all requests with identity extensions be
treated as third party, but only while you read the next paragraph.

I'm not arguing about the usefulness of alternate identifiers in the
pursuit of location determination.  I'm simply stating that since an
alternate identifier supplied by a LCP requestor MUST be validated prior
to releasing location information to such requestor, having that
requestor supply such alternate identifier is a useless step. The LIS
can simply discover the alternate identifier via the same mechanism used
by the proposed identifier extension validation process.  This enables
the requestor to utilize the LCP mechanism described in
draft-ietf-geopriv-http-location-delivery-12.txt without having to play
the guessing game called 'alternate identifiers'.

Hence, having a requestor supply the identity extension in the pursuit
of the LCP request is not necessary and should not be supported.
Therefore, if a request is submitted with an identity extension
embedded, it must be a third party request.  Now, I'm back to my
assertion that all requests containing identity extension MUST be
considered a third party request.

-Marc-

The issue is that in many access networks, IP address assignment is
handled separately from network access authentication.  As a result, a
LIS may not keep track of location by IP address at all, but may be
better prepared to return a location in response to an alternative
identifier such as a MAC address or username. 

For such systems, being forced to treat all alternate identies as "third
party" would prevent support for location from being deployed at all.
This seems silly particularly if the location request is authenticated
with an identity that maps easily to the username used for network
access.   Such a scheme will both readily allow the differentiation of
"first party" and "third party" requests as well as fitting very well
with the majority of backend AAA systems deployed today, with a high
level of security and location privacy. 

Martin, Bernard,

I'm still perplexed about the verification process applied to determine
whether the request is LCP or third party.  If in fact, the proposed
verification process exonerates the request as LCP, what's the point of
identity extensions for LCP?  The LIS can simply gather the required
extended identity information via the same process.  The draft states
that if the verification check fails, the LCP request fails and it's
treated as third party.

I'm not convinced by:

" Note:  This might seem to negate much of the advantage provided by
      the inclusion of identity parameters for the LCP case.  However,
      checking that the identity information is correct is generally
      more feasible than acquiring the information in the first place"

Simply treating all requests with identity extensions as third party
seems easier. Hence, a host requesting it's own location doesn't have to
worry about identity extensions (ala less code), it's up to the LIS to
figure out what is needed and where to get it.

-Marc-

...

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2] 

------------------------------------------------------------------------
------------------------
------------------------------------------------------------------------
------------------------
[mf2]

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 30 Jan 2009 15:51:55 -0500

I also agree with Marc

Confining the discussion to just the LCP case:

Identity of the requester is not particularly interesting.  If I deployed
PKI for example, I could tell that Martin Thomson was asking for his
location, but that doesn’t tell me what identifier I use to map to his
location.  Just because I know  it’s Martin asking doesn’t mean, for an LCP,
that I trust any identifier he happens to give me, other than the IP address
that I got from his packet.  You could stash an identifier in the cert, but
I'm guessing that isn't interesting.

All I get to use to derive the identifier is what is delivered in the
request.  For an L7 LCP, that is, precisely, the IP address.  If the LIS was
on the same L2 as the requester, then you might have another identifier. 

Bernard supposes that there are cases where the LIS can’t lookup the
identifier actually associated with location using the IP address.  I claim
that since you must validate the identifier you use against the IP address,
that the only circumstance where sending the identifier makes any sense is
if the lookup from identifier to IP address is one way.  I find that pretty
hard to fathom.  Even in an enterprise, you would use the DHCP server to go
from IP address to mac address, and then use mac address to switch port.  I
think you HAVE to do that, you can’t just have the LCP client send MAC
address at L7.  You MUST verify that the client’s IP address matches the MAC
address he sent you.  If you can verify, you can do the lookups from the IP
address without using the identity extension.

Again, all of this is LCP only.  With third party, we have trust
arrangements that work without this backchecking.

Brian

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stark, Barbara
Sent: Friday, January 30, 2009 2:12 PM
To: Marc Linsner; Thomson, Martin; [email-masked]
Subject: Re: [Geopriv] Security considerations for
draft-winterbottom-geopriv-held-identity-extensions

I tend to agree with Marc on this.
In the generic case, for any identity that a LIS is able to provide location
for, you would want to have a privacy policy. That policy would state who is
authorized to request location (and maybe some can only request city while
others get exact). In creating this policy, it would make sense in most
cases (but not all) to include the authentication information (certificate,
shared secret, whatever) of the Target as an entity that can request
location. But in doing it this way, the Target looks just like any other
party requesting location. 

An entity requesting location info provides authentication info which is
matched up against privacy policy of whatever they’re asking location for.
Whether that authenticated identity belongs to the target itself or someone
else isn’t relevant, because what they can get access to is defined by the
authorizations associated with the authenticated ID within the policy. There
is no need to further associate authentication info as somehow belonging to
the same device whose location is being requested. That provides no
additional info. Either the authenticated ID is authorized or it isn’t.
Barbara

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marc Linsner

Martin,

I don’t understand the role of PKI in the LCP use case.  The LIS doesn’t
know John Doe.  The LIS doesn’t care that John Doe owns mac address x.y.z.
  The LIS cares that IP address a.b.c. belongs to mac address x.y.z.  Any
other usage is not LCP, it’s third party which falls under the policy set by
the rulemaker.

-Marc-

Did you miss the bit where I mentioned that validation doesn’t necessarily
involve checking that: owner-of-IP == owner-of-alternative?  If the
requester can prove that they own the identifier (I hear that PKI helps
here), then the validation consists of a certificate check.
 
Cheers,
Martin

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Marc Linsner

OK, I’ll retract the idea that all requests with identity extensions be
treated as third party, but only while you read the next paragraph.

I’m not arguing about the usefulness of alternate identifiers in the pursuit
of location determination.  I’m simply stating that since an alternate
identifier supplied by a LCP requestor MUST be validated prior to releasing
location information to such requestor, having that requestor supply such
alternate identifier is a useless step. The LIS can simply discover the
alternate identifier via the same mechanism used by the proposed identifier
extension validation process.  This enables the requestor to utilize the LCP
mechanism described in draft-ietf-geopriv-http-location-delivery-12.txt
without having to play the guessing game called ‘alternate identifiers’.

third party request.  Now, I’m back to my assertion that all requests

-Marc-

Martin, Bernard,

I’m still perplexed about the verification process applied to determine
whether the request is LCP or third party.  If in fact, the proposed
verification process exonerates the request as LCP, what’s the point of
identity extensions for LCP?  The LIS can simply gather the required
extended identity information via the same process.  The draft states that
if the verification check fails, the LCP request fails and it’s treated as
third party.

I’m not convinced by:

Simply treating all requests with identity extensions as third party seems
easier. Hence, a host requesting it’s own location doesn’t have to worry
about identity extensions (ala less code), it’s up to the LIS to figure out
what is needed and where to get it.

-Marc-

…

----------------------------------------------------------------------------
--------------------
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] 
________________________________________

----------------------------------------------------------------------------
--------------------
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]
________________________________________
_______________________________________________
Geopriv mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 30 Jan 2009 19:02:38 -0600

What are the presumptions around what constitutes policy?

If I have a private enterprise network and the querying device only
knows how to say "Give me my location - I'm 'Polywoggle23'" then the LIS
in that network is implemented to support that identifier; the
implementation is a reflection of the policy in that enterprise. If it
wasn't OK, they wouldn't do it. The fact that the LIS in that enterprise
can accept an identifier in the form 'Polywoggle23' in no way dictates
that every LIS in every other network is going to do that.

All that's being asked for is a protocol mechanism that supports this
kind of flexibility in the request arguments - and the appropriate
guidance around the fact that you obviously shouldn't deploy LIS that
let any arbitrary third party find out the location of another party
unless that's actually OK in the context of the network in which it's
operating. Implementers are obviously going to do this sort of thing if
it's necessary anyway - and equally obviously it would be better if
there was a standards defined way of doing it.

Cheers,

Martin

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stark, Barbara
Sent: Saturday, 31 January 2009 6:12 AM
To: Marc Linsner; Thomson, Martin; [email-masked]
Subject: Re: [Geopriv] Security considerations
fordraft-winterbottom-geopriv-held-identity-extensions

Barbara

Martin,

-Marc-

Hi Marc,

Cheers,
Martin

-Marc-

Martin, Bernard,

I'm not convinced by:

-Marc-

...

---

From: Marc Linsner <[email-masked]>
Date: Fri, 30 Jan 2009 22:53:13 -0500

Martin,

Section 4 of the draft pretty much covers it.

-Marc-

On 1/30/09 8:02 PM, "Dawson, Martin" <[email-masked]> wrote:

> If I have a private enterprise network and the querying device only knows how
> to say ³Give me my location  I¹m ŒPolywoggle23¹² then the LIS in that network
> is implemented to support that identifier; the implementation is a reflection
> of the policy in that enterprise. If it wasn¹t OK, they wouldn¹t do it. The
> fact that the LIS in that enterprise can accept an identifier in the form
> ŒPolywoggle23¹ in no way dictates that every LIS in every other network is
> going to do that.
>  
> All that¹s being asked for is a protocol mechanism that supports this kind of
> flexibility in the request arguments  and the appropriate guidance around the
> fact that you obviously shouldn¹t deploy LIS that let any arbitrary third
> party find out the location of another party unless that¹s actually OK in the
> context of the network in which it¹s operating. Implementers are obviously
> going to do this sort of thing if it¹s necessary anyway  and equally
> obviously it would be better if there was a standards defined way of doing it.
>  
> Cheers,
> Martin
>  
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stark, Barbara
> others get exact). In creating this policy, it would make sense in most cases
> (but not all) to include the authentication information (certificate, shared
> secret, whatever) of the Target as an entity that can request location. But in
> doing it this way, the Target looks just like any other party requesting
> location. 
>  
> matched up against privacy policy of whatever they¹re asking location for.
> else isn¹t relevant, because what they can get access to is defined by the
> the same device whose location is being requested. That provides no additional
> info. Either the authenticated ID is authorized or it isn¹t.
> Barbara
>  
> 
> I don¹t understand the role of PKI in the LCP use case.  The LIS doesn¹t know
> John Doe.  The LIS doesn¹t care that John Doe owns mac address x.y.z.   The
> LIS cares that IP address a.b.c. belongs to mac address x.y.z.  Any other
> usage is not LCP, it¹s third party which falls under the policy set by the
> rulemaker.
> 
> -Marc-
> 
> 
> 
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 30 Jan 2009 22:32:24 -0600

Glad you agree.

When the request is coming from the target device, the LIS is acting
according to LCP - and is providing the location of the requestor to the
requestor according to the policy of the rule maker (the enterprise in
my example). If the LIS is providing the location to a third party -
then it's acting as an LS according to the definition and still
according to its policy.

Any attempt to say an enterprise isn't allowed to do this is simply
motherhood.

Cheers,

Martin

From: Marc Linsner [mailto:[email-masked]] 
Sent: Saturday, 31 January 2009 2:53 PM
To: Dawson, Martin; [email-masked]
Subject: Re: [Geopriv] Security considerations
fordraft-winterbottom-geopriv-held-identity-extensions

Martin,

-Marc-

 

Cheers,
Martin

 

Martin,

-Marc-

 
Cheers,
Martin

-Marc-

Martin, Bernard,

I'm not convinced by:

-Marc-

...

---

From: Marc Linsner <[email-masked]>
Date: Fri, 30 Jan 2009 23:41:08 -0500

Martin,

No I don¹t agree with what you wrote.  There is no rulemaker in the LCP use
case.  LCP policy is simple, location is given only to the target.  And it¹s
up to the LIS to enforce.  If the LIS cannot validate the identifier as
belonging to the target, the request is handled as third party and rulemaker
policy is applied.

-Marc-

On 1/30/09 11:32 PM, "Dawson, Martin" <[email-masked]> wrote:

> Glad you agree.
>  
> When the request is coming from the target device, the LIS is acting according
> to LCP  and is providing the location of the requestor to the requestor
> according to the policy of the rule maker (the enterprise in my example). If
> the LIS is providing the location to a third party  then it¹s acting as an LS
> according to the definition and still according to its policy.
>  
> Any attempt to say an enterprise isn¹t allowed to do this is simply
> motherhood.
>  
> Cheers,
> Martin
>  
> 
> 
> Marc Linsner
> Marc Linsner

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 30 Jan 2009 22:52:42 -0600

That's what I said.

Or let me ask this. Are you saying there is any arrangement that
provides 100% certainty that the requester is the target? Even
return-routability is subject to reasonable judgement .

IRL, all methods of validation are subject to pragmatic certainty. To
claim that the special case of a particular arrangement of technology
that correlates the identifier with the source IP address is the be all
and end all of this judgement is - again - motherhood. It is up to the
implementer of the LIS, in the context of their own network, to make
that judgement. This includes the quite simple judgement that requester
must be deviceX because in my network only deviceX would ask for its
location.

Cheers,

Martin

Sent: Saturday, 31 January 2009 3:41 PM

Martin,

No I don't agree with what you wrote.  There is no rulemaker in the LCP
use case.  LCP policy is simple, location is given only to the target.
And it's up to the LIS to enforce.  If the LIS cannot validate the
identifier as belonging to the target, the request is handled as third
party and rulemaker policy is applied.

-Marc-

Glad you agree.

 
Cheers,
Martin

Martin,

-Marc-

 
 
Cheers,
Martin

 

Martin,

-Marc-

 
Cheers,
Martin

-Marc-

Martin, Bernard,

I'm not convinced by:

-Marc-

...

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 31 Jan 2009 07:33:57 -0800

> Even in an enterprise, you would use the DHCP server to go
> from IP address to mac address, and then use mac address to switch port.

I'm familiar with at least one situation in which this approach was attempted,
but turned out to not be satisfactory. 

The DHCP server only holds information on addresses it assigns.  Addresses can
also be assigned by other mechanisms (stateless autoconfig, PPP, static).  Since
IPv6 connectivity is preferred in a number of current implementations, and IPv6
autoconfig is popular, if the LIS receives a request over IPv6, DHCP (either v4
or v6) may not be of much help in determining location. 

The alternative is to pull down the ARP/ND tables from routers to achieve a more
universal IP:MAC address mapping.  Doing this on an enterprise network of any
scale is not simple. 

On the other hand, if network access were authenticated (as it would be for
WiMAX, IEEE 802.11 and IEEE 802.1X wired), then there already exists a
mapping between User-Name and location (e.g. NAS-Identifier/NAS-IP-Address/NAS-IPv6-Address)
via RADIUS accounting.  This is widely deployed already, since almost every
shipping AAA server makes this information accessible in some form.