ietf
[Top] [All Lists]

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

2009-06-09 01:00:58
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: ben(_at_)estacado(_dot_)net; ietf(_at_)ietf(_dot_)org
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:

 
"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. 
 
 

 

 

 

------------------------------------------------------------------------------------------------
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]
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf