Subject: Re: Last Call: <draft-atarius-dispatch-meid-urn-as-instanceid-05.txt> (Using the Mobile Equipment Identity (MEID) Uniform Resource Name (URN) as an Instance ID) to Informational RFC

From: Stephen Farrell <[email-masked]>
Date: Fri, 3 Nov 2017 01:17:45 +0000

Hiya,

I don't claim to fully understand the usage of this ID,
but I'm quite sure that I have no clue what this text
is supposed to mean (as a piece of specification):

  "In particular, the "sip.instance" media feature tag
   containing the 3GPP2 MEID URN MUST NOT be included in requests or
   responses intended to convey any level of anonymity, as this could
   violate the users privacy."

I guess this is either an existing problem with whatever
a "'sip.instance' media feature tag" really is or else this
draft creates a new problem, but the quoted text seems to
me to be non-deterministic impossible-to-program-for words
seemingly about (but not actually helping with) privacy.

Am I confused?

Cheers,
S.

On 02/11/17 22:43, The IESG wrote:
> 
> The IESG has received a request from an individual submitter to consider the
> following document: - 'Using the Mobile Equipment Identity (MEID) Uniform
> Resource Name (URN)
>    as an Instance ID'
>   <draft-atarius-dispatch-meid-urn-as-instanceid-05.txt> as Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2017-12-08. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    This specification specifies how the Uniform Resource Name (URN)
>    namespace reserved for the Third Generation Partnership Project 2
>    (3GPP2) identities and its Namespace Specific String (NSS) for the
>    Mobile Equipment Identity (MEID) can be used as an instance-id.  Its
>    purpose is to fulfill the requirements for defining how a specific
>    URN needs to be constructed and used in the "+sip.instance" Contact
>    header field parameter for outbound behavior.
> 
> 
> 
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-atarius-dispatch-meid-urn-as-instanceid/
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/doc/draft-atarius-dispatch-meid-urn-as-instanceid/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
>

---

From: S Moonesamy <[email-masked]>
Date: Thu, 02 Nov 2017 22:04:52 -0700

Hi Stephen,
>seemingly about (but not actually helping with) privacy.

The text which you quoted above is similar to text which is found in 
RFC 7255.  Several years ago, there was a controversy about that document.

Regards,
S. Moonesamy

---

From: Ben Campbell <[email-masked]>
Date: Fri, 3 Nov 2017 00:56:25 -0500

> On Nov 2, 2017, at 8:17 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

Possibly, but only because it’s confusing :-)

As S. Moonesamy pointed out separately, this draft borrows quite a bit of language from RFC 7255, which was pretty much the same things for IMEIs.

RFC 3261 (SIP) and a few related RFCs (especially 3323) talk about placing anonymous calls. The point here is that, when a user is trying to place an anonymous call, don’t screw up and stick identifying information somewhere else in the request.  I suspect (but do not know) that the language “any level of anonymity” originally came from the distinction between  “user-provided privacy” vs “network-provided privacy” discussed in RFC 3323.

The “sip.instance” media feature tag is defined in RFC 5626. It carries a URL to persistently identify a specific SIP user agent. That RFC contains guidance to not use the sip.instance tag for anonymous requests or responses, i.e. when you don’t want to the UA to reveal its identity.

Would citations help?

(Authors, feel free to jump in).

Thanks!

Ben.

---

From: R Atarius <[email-masked]>
Date: Fri, 3 Nov 2017 20:35:21 +0000 (UTC)

Hi
Just agreeing with Ben. RFC 5626 highlights that the UA could omit the instance ID for private or anonymous calls. So this is the problem with instance ID and not UUID, MEID, IMEI which have been employed to create the instance ID.
ThanksRoozbeh

      From: Ben Campbell <[email-masked]>
 To: Stephen Farrell <[email-masked]> 
Cc: [email-masked]; [email-masked]; [email-masked]
 Sent: Thursday, November 2, 2017 10:57 PM
 Subject: Re: Last Call: <draft-atarius-dispatch-meid-urn-as-instanceid-05.txt> (Using the Mobile Equipment Identity (MEID) Uniform Resource Name (URN) as an Instance ID) to Informational RFC

Would citations help?

Thanks!

Ben.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 03 Nov 2017 18:10:17 -0700

Hi Roozbeh, Ben,
At 01:35 PM 03-11-2017, R Atarius wrote:
>Just agreeing with Ben. RFC 5626 highlights that the UA could omit 
>the instance ID for private or anonymous calls. So this is the 
>problem with instance ID and not UUID, MEID, IMEI which have been 
>employed to create the instance ID.

RFC 5626 was published in 2009.  RFC 7258 was published in 2014.  Are 
the Security Considerations the same as in 2009?

The Document Shepherd write-up mentioned "his affiliation".  There 
isn't any information about affiliation in the write-up or in 
draft-atarius-dispatch-meid-urn-as-instanceid-05.

Regards,
S. Moonesamy

---

From: Ben Campbell <[email-masked]>
Date: Fri, 3 Nov 2017 23:32:17 -0500

> On Nov 3, 2017, at 8:10 PM, S Moonesamy <[email-masked]> wrote:
> 
> Hi Roozbeh, Ben,
> RFC 5626 was published in 2009.  RFC 7258 was published in 2014.  Are the Security Considerations the same as in 2009?
> 

The draft says the UAC MUST NOT include a sip.instance tag with the MEID in a request intended to be anonymous, and that the service provider MUST NOT forward it towards the UAS.  That seems as relevant today as in 2009 or 2014. It may well be that the guidance in 5626 is not sufficient to guarantee anonymity, but I don’t see how that would change the guidance in this draft. Is there something in particular you would like to see?

> The Document Shepherd write-up mentioned "his affiliation".  There isn't any information about affiliation in the write-up or in draft-atarius-dispatch-meid-urn-as-instanceid-05.

I’m guessing that is because the affiliation change since the shepherd did the writeup. Is there a specific concern there? The writeup does say that the author stated that he was not aware of any IPR, which is our usual standard.

Thanks,

Ben.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 06 Nov 2017 05:51:30 -0800

Hi Ben,
At 08:32 PM 03-11-2017, Ben Campbell wrote:
>The draft says the UAC MUST NOT include a sip.instance tag with the 
>MEID in a request intended to be anonymous, and that the service 
>provider MUST NOT forward it towards the UAS.  That seems as 
>relevant today as in 2009 or 2014. It may well be that the guidance 
>in 5626 is not sufficient to guarantee anonymity, but I don't see 
>how that would change the guidance in this draft. Is there something 
>in particular you would like to see?

 From the draft:

  "MEID a globally unique identifier that identifies mobile devices
   used in the 3GPP2 networks."

The BCP states that "It is therefore timely to revisit the security 
and privacy properties of our standards".  This draft is about using 
the MEID in the in the "+sip.instance".  Shouldn't the properties be 
revisited instead of relying on what was written in 2009?

>I'm guessing that is because the affiliation change since the 
>shepherd did the writeup. Is there a specific concern there? The 
>writeup does say that the author stated that he was not aware of any 
>IPR, which is our usual standard.

I found it unusual that the write-up included a comment about 
"affiliation".  It seems better to provide clear information about 
that instead of leaving the reader guessing or, as in this case, to 
ask whether there is a specific concern about IPR.

Regards,
S. Moonesamy

---

From: Dean Willis <[email-masked]>
Date: Tue, 7 Nov 2017 23:47:48 -0600

> seemingly about (but not actually helping with) privacy.
Given that the MEID is a long-lived (permanent) identifier for the 
specific mobile equipment, it can be correlated with user identity (and 
it has cryptographic identity support at the SIM level). Thus it is 
potentially leaky. If you do NOT wish your message to give away your 
identity, don't send an MEID in it.

Of course this security consideration is patently bogus, as they're no 
doubt planning to send it all the time. Don't do this at home, kids.

Why use it? Because when a user simultaneously has multiple devices and 
one might be moving call legs betwixt them, having a persistent label 
for each of these devices (instances) is terribly handy. There are more 
reasonable ways of doing this, such as using OAuth to transiently 
instance-identify/authorize  the device. But the mobile folks (and most 
explicitly, the SIM folks) have a lot already invested in MEID, so 
that's what they want to do, even if it is probably long-term 
self-defeating because it builds them into the sort of silo that 
WhatsApp and others live to tear down. But hey, they live in a world of 
government wire taps and cheap APIs for tracking users, so why should 
they care? They're "only going to use it on a secure and trusted 
network", as usual. Right...

--
Dean Willis