Subject: Re: Gen-ART LC Review of draft-ietf-geopriv-http-location-delivery-14.txt

From: Bernard Aboba <[email-masked]>
Date: Mon, 8 Jun 2009 12:47:36 -0700

Mary Barnes said:

"It doesn't explicitly "forbid" the use of digest authn, but if it  
can't depend on client support, then it can't really base any decision on  
it."
 
The question isn't just about an authorization decision.  There is also the issue about what
the LIS is supposed to do with client authentication information if it is provided.  How is
this information reflected in the PIDF-LO that is returned in a HELD response? 
 
Ben Campbell said:

"The part I was trying to highlight was the lack of client device
authentication, not LIS authentication. If I read 9.1 right, it only
covers authentication of the LIS. I assume there is no expectation that
client devices present TLS certs to the LIS, right?"

There are multiple potential identities that a device (and a user of that 

device) could assert and authenticate against. 

Currently the document only talks about use of the IP address as an

identity, and says little about authentication. 

However, the PIDF-LO objects that are returned in HELD responses contain 

multiple identification fields.  Currently the document says very little about 

how these fields are filled in.  That leaves the protocol under-specified. 

Issues of protocol behavior that are this basic shouldn't be left to an

"extensions" document.

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 8 Jun 2009 23:58:48 -0500

Hi Bernard,

Regarding client authentication, there are a number of constraints on the solution that lead to the current choice.  The most relevant constraint is that there may be no prior relationship between LIS (network operator) and device.  In designing for arbitrary access networks, this constraint was considered important.  This prevents use of pre-shared keys such as would be required for digest/basic [1] [2].

Thus we come to the choice of IP address and return reachability.  I believe that the draft addresses the impact of this choice adequately; Section 9.3 seems most directly applicable here, but other places touch on this choice where it’s relevant.  If you do not believe that there are relevant points that are not brought up, I’d encourage you to send text.

Regarding alternative identifiers, there is an extension document that talks about use of alternative identifiers, and I do believe that this particular point CAN be addressed in an extension.  For those, authentication (other than return reachability, if you consider that to be a form of authentication) can be made a requirement.

I’ll address the other more substantive point regarding identity in PIDF-LO in another (longer) mail.

--Martin

[1] The document is clear on its use of digest/basic: the LIS MUST NOT rely on it being used.  That’s in recognition of the above constraint.  In other words, the LIS MUST NOT fail a request because the device did not provide authentication.  That doesn’t prevent it from being used in an extension to the protocol.

[2] Of course, there are networks where the constraint might not be applicable.  For instance, access to the network could be restricted using some form of authentication.  However, a device that accesses a LIS within those networks must also be aware that it needs to present this same authentication information when talking to a LIS.  We cannot guarantee that a device will do this, since compliance would need to be a prerequisite of network access; designers of future access networks might choose to add this to their network design.  

From: Bernard Aboba
Sent: Tuesday, 9 June 2009 5:48 AM
To: [email-masked]; [email-masked]
Subject: Re: Gen-ART LC Review ofdraft-ietf-geopriv-http-location-delivery-14.txt

Mary Barnes said:

it."

Ben Campbell said:

 

 

------------------------------------------------------------------------------------------------
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: Bernard Aboba <[email-masked]>
Date: Tue, 9 Jun 2009 11:38:18 -0700

Martin Thomson said: 
"Regarding client authentication, there are a number of
constraints on the solution that lead to the current choice.  The most relevant
constraint is that there may be no prior relationship between LIS (network
operator) and device.  In designing for arbitrary access networks, this constraint
was considered important.  This prevents use of pre-shared keys such as would
be required for digest/basic [1] [2].

Thus we come to the choice of IP address and return reachability. 
I believe that the draft addresses the impact of this choice adequately; Section
9.3 seems most directly applicable here, but other places touch on this choice where
it’s relevant.  If you do not believe that there are relevant points that are
not brought up, I’d encourage you to send text."[BA] I understand that the IP address is being used as an identifier.  With respect to the lack of no prior relationship between the access network and the device, presumably this is to acommodate situations of anonymous access and/or no authentication (e.g. non-authenticated Ethernet).  If so, it might be useful to add a sentence to that effect. 

Regarding alternative identifiers, there is an extension
document that talks about use of alternative identifiers, and I do believe that
this particular point CAN be addressed in an extension.  For those,
authentication (other than return reachability, if you consider that to be a
form of authentication) can be made a requirement.[BA] I'm trying to understand how the mechanics of authentication could be accomodated.  Since authentication
can't be required for authorization where an IP address is used for identification, does this imply that a "407" response is not
permissible in that situation?  Or is it just saying that if a 407 is returned in that situation, then authorization needs to be provided?  Does that imply that a 407 could be returned in other situations (e.g. an alternative identifier)?  Just trying to understand the scope of the prohibition and how implementations are expected to behave. 
I’ll address the other more substantive point regarding identity
in PIDF-LO in another (longer) mail.

--Martin

[1] The document is clear on its use of digest/basic: the LIS
MUST NOT rely on it being used.  That’s in recognition of the above constraint. 
In other words, the LIS MUST NOT fail a request because the device did not
provide authentication.  That doesn’t prevent it from being used in an
extension to the protocol.

[2] Of course, there are networks where the constraint might not
be applicable.  For instance, access to the network could be restricted using some
form of authentication.  However, a device that accesses a LIS within those
networks must also be aware that it needs to present this same authentication
information when talking to a LIS.  We cannot guarantee that a device will do
this, since compliance would need to be a prerequisite of network access; designers
of future access networks might choose to add this to their network design.  

From: Bernard Aboba

Subject: Re: Gen-ART LC Review
ofdraft-ietf-geopriv-http-location-delivery-14.txt

Mary
Barnes said:

"It
doesn't explicitly "forbid" the use of digest authn, but if it  

can't depend
on client support, then it can't really base any decision on  

it."

The question
isn't just about an authorization decision.  There is also the issue about
what

the
LIS is supposed to do with client authentication information if it is
provided.  How is

this
information reflected in the PIDF-LO that is returned in a HELD response? 

Ben
Campbell said:

multiple identification fields.  Currently the document says very
little about 

 

"extensions" document. 

 

[mf2]

---

From: Ben Campbell <[email-masked]>
Date: Tue, 9 Jun 2009 13:52:45 -0500

On Jun 8, 2009, at 11:58 PM, Thomson, Martin wrote:

> [1] The document is clear on its use of digest/basic: the LIS MUST  
> NOT rely on it being used.  That’s in recognition of the above  
> constraint.  In other words, the LIS MUST NOT fail a request because  
> the device did not provide authentication.  That doesn’t prevent it  
> from being used in an extension to the protocol.
>

That may have been the intent, but the wording is of the form "MUST  
NOT relay on [cookies] or _use_ Basic or Digest  
authentication." (emphasis mine).  So if you edit out the cookies  
phrase, it says you MUST NOT use basic or digest authentication.

Mary proposed in a separate email to relax that to a SHOULD NOT-but if  
I recall that was still SHOULD NOT rely on cookies or _use_ digest.

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 10 Jun 2009 00:16:13 -0500

Hi Bernard,

Reliance on discovery implies that there is no prior relationship, but the document does not go so far as to explicitly make this statement.  Since this is so fundamental, a mention couldn’t hurt (to Section 3 perhaps).

   This protocol does not assume any prior relationship between access 
   network and Device other than what is necessary for the Device to gain
   network access.

However, I need to point out that there is a distinction between network access authentication and the authentication that might be required for access to the location service.  If network access is granted, the LIS need not add further hoops.

Unless you can guarantee that all devices within the access network are able to authenticate consistently, then you cannot authorize HELD requests based on any authentication.  There are networks where this is possible, but this is a subset even of those “walled garden” networks.

Therefore, the only form of authentication that a LIS is permitted to use is the check that it performs to see whether the identifier it is using as a basis for location determination belongs to the entity making the request.  Of course, local policy can override, as long as the implications are considered (e.g. potentially denying emergency services access).

--Martin

p.s.  I’m assuming that you meant 403 rather than 407 here.  407 implies that you are using a proxy.  That tends to mess with the ability of the LIS to see your IP address and it is expressly forbidden (c.f. Section 4.1.1).  

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Wednesday, 10 June 2009 4:38 AM
To: Thomson, Martin; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Gen-ART LC Review ofdraft-ietf-geopriv-http-location-delivery-14.txt

Martin Thomson said: 

"Regarding client authentication, there are a number of constraints on the solution that lead to the current choice.  The most relevant constraint is that there may be no prior relationship between LIS (network operator) and device.  In designing for arbitrary access networks, this constraint was considered important.  This prevents use of pre-shared keys such as would be required for digest/basic [1] [2].

Thus we come to the choice of IP address and return reachability.  I believe that the draft addresses the impact of this choice adequately; Section 9.3 seems most directly applicable here, but other places touch on this choice where it’s relevant.  If you do not believe that there are relevant points that are not brought up, I’d encourage you to send text."

[BA] I understand that the IP address is being used as an identifier.  With respect to the lack of no prior relationship between the access network and the device, presumably this is to acommodate situations of anonymous access and/or no authentication (e.g. non-authenticated Ethernet).  If so, it might be useful to add a sentence to that effect. 

[BA] I'm trying to understand how the mechanics of authentication could be accomodated.  Since authentication can't be required for authorization where an IP address is used for identification, does this imply that a "407" response is not permissible in that situation?  Or is it just saying that if a 407 is returned in that situation, then authorization needs to be provided?  Does that imply that a 407 could be returned in other situations (e.g. an alternative identifier)?  Just trying to understand the scope of the prohibition and how implementations are expected to behave. 

--Martin

 

From: Bernard Aboba

Mary Barnes said:

it."

Ben Campbell said: