Subject: [Geopriv] Issue in HELD, confusing device ID with entity= attribute

From: "James M. Polk" <[email-masked]>
Date: Wed, 15 Jul 2009 23:08:55 -0500

Mary (and all)

Hannes just quoted text from the main HELD spec that happens to 
confuse two different identities, making them appear as if they are 
the same, when they are not.

    As noted in the "HTTP Enabled Location Delivery (HELD)"
    [I-D.ietf-geopriv-http-location-delivery] Section 6.6:

says:

       The LIS MUST NOT include any means of identifying the Device in
       the PIDF-LO unless it is able to verify that the identifier is
       correct and inclusion of identity is expressly permitted by a Rule
       Maker.  Therefore, PIDF parameters that contain identity are
       either omitted or contain unlinked pseudonyms [RFC3693].  A
       unique, unlinked presentity URI SHOULD be generated by the LIS for
       the mandatory presence "entity" attribute of the PIDF document.
       Optional parameters such as the "contact" element and the
       "deviceID" element [RFC4479] are not used.

RFC 4479 discusses device ID as probably the hardware device's MAC address.

The entity= attribute within the <presence> element is the presentity's URI.

The above paragraph from [I-D.ietf-geopriv-http-location-delivery] 
discusses the two as if these are the same identity, and they are not 
(they are not even at the same OSI layer, one is at layer 2, the 
other is at layer 7).

This paragraph needs to be fixed.

I apologize for not noticing this earlier.

BTW - I agree the device ID (i.e., the MAC address of the device the 
user is logged into) should not be included).  But the entity= 
attribute as the AOR of the presentity is probably going to be there 
more of the time -- and should not be "SHOULD NOT linkable".

James

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 16 Jul 2009 00:29:11 -0500

Hi James,

I can't see that there is anything wrong with this paragraph at all.

First sentence covers the topic generally without direct guidance; the second is more specific; the final statements are extremely specific.

Besides, they are the same thing in this context.  See Section 3, paragraph 2.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James M. Polk
> Sent: Thursday, 16 July 2009 2:09 PM
> To: [email-masked]
> Subject: [Geopriv] Issue in HELD, confusing device ID with entity=
> attribute
> 
> Mary (and all)
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
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: Wed, 15 Jul 2009 23:45:31 -0700

> more of the time -- and should not be "SHOULD NOT linkable".

I had raised this question in last call, so as to clarify the usage and the degree to which the entity attribute might be linked to other identities, such as the HELD identity and the identity in the SIP From: header.  IMHO, it is important to get clarity on this, if only to understand the security properties of the system.

---

From: Marc Linsner <[email-masked]>
Date: Thu, 16 Jul 2009 09:34:19 -0400

Martin,

My interpretation of James' concern relates not to the act of the LIS
providing an unlinked presentity to the target, but what the target does
with this in follow-on actions.

I wonder if there would be value in offering guidance (within HELD) to
targets explaining that during this 'LCP' process a fictitious presentity
was used and the 'entity' attribute needs changed/linked prior to use in a
presence/location application?

-Marc- 

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

> First sentence covers the topic generally without direct guidance; the second
> is more specific; the final statements are extremely specific.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 16 Jul 2009 09:33:34 -0400

James

In a significant number of cases, the identities known by the LIS are not
AoRs.

The LIS is operated by an access network.  That network has a "subscriber",
but the subscriber may or may not be the same as the entity sending the
PIDF.  Lots of examples of that:

* Broadband ISP with AOL or Vonage sending IM/SIP signaling with location
* Starbucks as the ISP with VPN to enterprise phone system
* Enterprise ISP which knows room numbers and jack wallplate numbers, but
not who 
  is in a conference room at any specific time
* Location from a commercial GPS system which has no real "identity" at all 
  other than a MAC address.

It's only in something like a cellphone network where the identity in the
PIDF and the identity in whatever is conveying the PIDF could reasonably be
the same thing.  And only in those cases could you have something we would
recognize as an AoR in the PIDF.  I'm not at all sure we will see that AoR
in the PIDF, but at least in that case it could be.

Brian

> Sent: Thursday, July 16, 2009 12:09 AM
> To: [email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 16 Jul 2009 23:01:24 -0700

> in the PIDF, but at least in that case it could be.

There is also the enterprise case.  There the NAI could indeed be an AoR.

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 17 Jul 2009 07:55:30 -0400

Not normally, but it's sometimes possible.

Location in enterprise maps switch ports to location.

In some circumstances, you know the switchport is in an office, and you can
associate it with the telephone system extension.  However, that doesn't
always work, because there are rooms with switch ports that don't have
extensions.  Rooms with more switch ports than extensions, more extensions
than switchports, and circumstances where you, for example, IM from a
conference room, and even though the conference room has an extension, that
would be the wrong identity.

Since all of those conditions exist, I think the enterprise LIS better not
put a telephone system identity on location.

Brian

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Friday, July 17, 2009 2:01 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [Geopriv] Issue in HELD, confusing device ID with entity=
attribute