Subject: Re: [Geopriv] IETF74 Consensus Calls

From: Cullen Jennings <[email-masked]>
Date: Sat, 9 May 2009 08:24:14 -0600

The security can basically summarized as

    All HELD requests MUST be authenticated by the LIS.  How
    authentication is accomplished and what assurances are desired is a
    matter for policy.

To paraphrase, how to secure this to meet the BCPs and RFC that this  
working group has published is left as exercise to the reader. That's  
unlikely to get approved by the IESG. If it came up today, it would  
get a discuss along the lines of "This is a key part of the security  
and it is not implementable based on the draft". This is a hard topic  
for people implementing and deploying to know what reasonable options  
they might choose from and how to implement them. Now the WG may be  
very clear on how this is all going to work but 'm proceeding  
cautiously, which translated to slowly, until I have a slightly better  
understanding.

On Mar 31, 2009, at 9:32 PM, Glen Zorn wrote:

> Martin Thomson [mailto://[email-masked]] writes:
>
>> Hi Cullen,
>>
>> As far as I am aware, all security considerations relating to this
>> document have been addressed.
>>
>> If you know of other concerns, don't be shy.
>>
>> On a matter of process: can we not - as a working group - accept work
>> before that work is finished?
>
> Can & should.  The recent practice of accepting drafts as WG items  
> for the
> sole purpose of issuing WGLC is an abominable practice, IMHO.
>
>>
>> --Martin
>
> ...
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 9 May 2009 13:46:53 -0700

Changing the subject to reflect the topic. 

Cullen Jennings said: 

>     All HELD requests MUST be authenticated by the LIS.  How authentication is accomplished and what assurances are desired is a > matter for policy.

There are several different identities that are relevant here:

1. The device identifier used to retrieve location.  This identity could be implicit (e.g. the source IP address of the location request) or explicit (an additional identity defined in HELD extensions), and could conceivably be verified without authentication, topology permitting.  This has been the identity that has most been under discussion recently. 

2.  An identity that is asserted and cryptographically verified during the LCP protocol exchange (e.g. via HTTP Digest).  This identity need not necessarily be related to the device identity in #1.  Support of cryptographic authentication between the client and the LIS assumes a pre-established relationship, either between the client & LIS or between the client and a third party (e.g. a home server via RFC 5090) that the LIS trusts.  

3. The SIP identity asserted in a subsequent INVITE message which conveys the PIDF-LO either by value or by reference.   This identity need not necessarily have a relationship to identities #1 or #2.

The HELD extensions document only introduces new issues with respect to Identity #1.  Concerns relating to the overall "trustworthiness" of the location system would need to address issues #1, 2 and 3, but those concerns are present with any LCP.  In fact, one could argue that the issues relating to authentication of identity #2 are more tractable in HELD than in other approaches (e.g. LCPs such as IEEE 802.11k provide no authentication at all).  Issues relating to authentication of identity #3 exist with *any* LCP. 

Given that generic concerns about the "trusthworthiness" of the location system haven't previously been grounds for holding up advancement of an LCP, I'd suggest that concerns #2 and #3 are probably best addressed in a more general document such as 
draft-tschofenig-ecrit-trusthworthy-location.  

That would leave only concern #1 as within scope for the HELD extensions document.  We've already discussed example topologies where "verification" of extended identities would be possible.  For example, IEEE 802.21 assumes a topology in which an emergency services VLAN is provisioned, so that the LIS is within the same broadcast domain as the client, enabling use of the MAC address as an explicit or implicit identity.