Subject: [dispatch] New Versions of draft-montemurro-gsma-imei-urn and, draft-allen-dispatch-imei-urn-as-instanceid submitted

From: Tom Taylor <[email-masked]>
Date: Tue, 20 Nov 2012 12:16:06 -0500

Andrew's original note appeared to me at least as a brief message: 
"WARNING: contains banned part", with attachments. As a public service, 
I have extracted and reproduced the text of his message. Hope this isn't 
a duplicate from others' point of view.

Tom Taylor

Andrew's message:
==========================
New versions of draft-montemurro-gsma-imei-urn and 
draft-allen-dispatch-imei-urn-as-instanceid were submitted at the 
beginning of October.

http://www.ietf.org/internet-drafts/draft-allen-dispatch-imei-urn-as-instanceid-06.txt

http://www.ietf.org/internet-drafts/draft-montemurro-gsma-imei-urn-11.txt

There are not many major changes since the previous versions which were 
submitted in March and July which themselves were submitted after the 
conference call held between 3GPP and IETF interested parties in early 
January on the topic. Basically editorial updates and some strengthening 
of the normative language.

The main change in draft-montemurro-gsma-imei-urn since the previous 
version is to address the ABNF comment from Dale and it was decided we 
do not need parameters to have multiple values so Dale's proposed 
resolution has been adopted. The January version of 
draft-montemurro-gsma-imei-urn (09 version) added the following to the 
Security Considerations section to address the privacy concerns:

    Further, because IMEIs can be loosely correlated to a user, they
    need to be treated as any other personally identifiable
    information. In particular, the IMEI SHOULD NOT be included in
    messages intended to convey any level of anonymity.

In the latest (11 version) this has been strengthened from a SHOULD NOT 
to a MUST NOT.

The draft-allen-dispatch-imei-urn-as-instanceid 05 version that was 
submitted in March incorporated a number of significant changes including:

1.    Additional text was added to the abstract stating:

[The purpose of the draft] is to fulfil the requirements in RFC 5626 [1] 
that state "If a URN scheme other than UUID is used, the UA MUST only 
use URNs for which an RFC (from the IETF stream) defines how the 
specific URN needs to be constructed and used in the "+sip.instance" 
Contact header field parameter for outbound behavior."

2.    A new section was added describing the three 3GPP use cases

3.    A new section was added for 3GPP Registrar Procedures with the 
following text:

In 3GPP IMS when the Registrar receives in the Contact header field a 
"sip.instance" media feature tag containing the GSMA IMEI URN according 
to the syntax defined in draft-montemurro-gsma-imei-urn-09[3] the 
registrar follows the procedures defined in RFC 5626 [1] and RFC 5627 
[2] if those extensions are supported and indicated as supported by the 
UA.  If the Registrar allocates a public GRUU according to the 
procedures defined in RFC 5627 [2] the the instance-id MUST be 
obfuscated when creating the "gr" parameter in order not to reveal the 
IMEI to other UAs when the public GRUU is included in non register 
requests. 3GPP TS 24.229 [6] subcluase 5.4.7A.2 defines the mechanism 
for obfuscating the IMEI when creating the "gr" parameter.

4.    The security section was beefed up as follows:

Because IMEIs like other formats of instance IDs can be loosely 
correlated to a user, they need to be treated as any other personally 
identifiable information.  In particular, the "sip.instance" media 
feature tag containing the GSMA IMEI URN MUST NOT be included in 
requests or responses intended to convey any level of anonymity.  RFC 
5626 [1] states "One case where a UA could prefer to omit the 
"sip.instance" media feature tag is when it is making an anonymous 
request or some other privacy concern requires that the UA not reveal 
its identity".  The same concerns apply when using the GSMA IMEI URN as 
an instance ID.  Publication of the GSMA IMEI URN to networks that the 
UA is not attached to or the UA does not have a service relationship 
with is a security breach and the "sip.instance" media feature tag MUST 
NOT be forwarded by the service provider's network elements when 
forwarding requests or responses towards the destination UA.

In order to protect from tampering the REGISTER requests containing the 
GSMA IMEI URN MUST be sent using a security mechanism such as TLS [12] 
(or another security mechanism that provides equivalent levels of 
protection).

There do not seem to be any comments made against the 
draft-allen-dispatch-imei-urn-as-instanceid-05 version that was 
submitted in March. Not sure if this was because everyone was Ok with it 
or because it was overlooked.

At the conference call held between 3GPP and IETF interested 
participants in January at which privacy concerns about the use of the 
IMEI as an instance ID by 3GPP were raised. It was proposed during the 
conference call that the authors submit a new revision of the draft 
clarifying the use of the mechanism and explaining how the 3GPP 
architecture addresses the privacy issues that were discussed.

There was a further discussion at a following 3GPP meeting on these 
privacy concerns. During the 3GPP discussion it was pointed out that RFC 
5626 already previously considered and addressed privacy concerns  with 
instance ID in section 4.1 which only states the "UA could prefer to 
omit the "sip.instance" media feature tag":

4.1.  Instance ID Creation

    To convey its instance-id in both requests and responses, the UA
    includes a "sip.instance" media feature tag as a UA characteristic
    [RFC3840].  This media feature tag is encoded in the Contact header
    field as the "+sip.instance" Contact header field parameter.  One
    case where a UA could prefer to omit the "sip.instance" media feature
    tag is when it is making an anonymous request or some other privacy
    concern requires that the UA not reveal its identity.

draft-montemurro-gsma-imei-urn and 
draft-allen-dispatch-imei-urn-as-instanceid and the 3GPP specified usage 
of the IMEI already go considerably further than RFC 5626 does in this 
regard. Regardless of whether a UUID URN or the IMEI URN is used as an 
instance ID the privacy issues are the same since an instance ID based 
on a UUID is static once generated and therefore like the IMEI 
potentially reveals the identity of the caller if it can be correlated 
with the identity of that caller from a previous call.

The view in 3GPP was that the IMEI should not be of any greater concern 
when used as an instance ID than using a UUID. Asking 3GPP to go 
considerably further in addressing privacy concerns with use of IMEI as 
an instance ID than RFC 5626 already does was considered by many in 3GPP 
to be unwarranted. Describing fully all the potential uses with 3GPP IMS 
of instance ID and documenting all the security mechanisms in all 
scenarios is a really non-trivial task considering that many 
organizations outside 3GPP specify access networks for IMS and 
applications using IMS (OMA, GSMA, Cablelabs, 3GPP2, TISPAN, WIMAX 
Forum...) and outside the capability of the authors of the draft alone. 
In basic summary most if not all accesses to IMS provide for at least 
basic levels of transport security such as use of IPsec or TLS tunnels 
and/or access layer security (although there is no guarantee these will 
be always enabled by the every carrier). This goes beyond what is 
required by RFC 5626 which only recommends use of TLS even though the 
general internet is probably more open to attack than a managed carrier 
network.

Those that think privacy issues are insufficiently addressed need to 
explain why the IMEI is of significantly greater concern in terms of 
revealing privacy than the UUID when used as an instance ID.

In our view the security concerns raised have now been sufficiently 
addressed in the drafts and to a much higher bar than that of UUID in 
RFC 5626.

The 3GPP use cases have now been described in 
draft-allen-dispatch-imei-urn-as-instanceid. It is my view that 
describing these uses as an instance ID also in 
draft-montemurro-gsma-imei-urn is both redundant and inappropriate since 
this draft does not define use of the IMEI as an instance ID.

Attached are diffs between the 04 and 06 versions of 
draft-allen-dispatch-imei-urn-as-instanceid and between the 09 and 11 
versions of draft-montemurro-gsma-imei-urn.

So I would like to ask for review of these two latest drafts and to 
provide any comments. 3GPP urgently needs to progress these drafts which 
are needed to complete 3GPP Release 8.

Andrew

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 27 Nov 2012 13:00:52 +0200

All,

as you can see in the email below, Andrew believes that the current
versions of these drafts address all concerns that were previously
discussed on this list. Those concerns mostly related to
interoperability (what happens with UAs that do not have an IMEI) and
privacy (whether a UA can choose not to send its IMEI in order to
preserve its user's privacy).

With respect to the URN definition (in the montemurro draft), it needs
to also be discussed on the [email-masked] list, per RFC 3406.

The SIP usage (specified in the allen draft), needs to be reviewed on
this list. So, please, have a look at the current versions of these
drafts and send your comments to the list.

I have already talked with the editors of these drafts so that they are
responsive. Getting people to reload the state related to these drafts
into the heads is a lot of work for everyone. So, I would like to
discuss these drafts one last time and make a *final* decision (whatever
it is) shortly.

Cheers,

Gonzalo

On 20/11/2012 7:16 PM, Tom Taylor wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 27 Nov 2012 16:53:18 -0500 (EST)

In regard to the privacy issue, I agree with the authors that privacy
has been addressed more vigorously than it is in regular SIP networks
(where it is often handled very sloppily), and that (as regarding
standards), and that is sufficient.

Below I have noted some specific comments, only two of which have
technical content:  (1) What is the permitted character set of the
"gsma-*" symbols in the generic syntax?  (2) What is the intended
lexical equivalence algorithm?

Resolving these comments should be straightforward, after which I
think these documents should progress to RFCs.

Good work!

Dale

*** Comments on draft-montemurro-gsma-imei-urn-11

Technical issues:

   3.1.  GSMA

      The <gsma-specifier>, <gsma-specifier-defined-string>, <gsma-
      specifier-defined-substring>, <gsma-specifier-defined-param-name>
      and <gsma-specifier-defined-param-val> can comprise any ASCII
      characters compliant with URN syntax and must not contain the ":"
      character or ";" character or "=" character(see STD 66, RFC 2141
      [5]).

This contradicts the ABNF in the same section, as there are quite a
number of "unreserved" characters for URNs (see RFC 2141, section 2.2,
symbol <other>) that are not included in this document's <unreserved>.
What is the intended generic syntax of these symbols?

Within this text, "can comprise any ASCII characters ... and must not
..." would be better phrased "can comprise any ASCII characters
except/but it must not ...".

   Rules for Lexical Equivalence:
      Consider each field of the IMEI gsma-defined substring to be a
      sequence of decimial digits.  Then, to compare a pair of IMEIs,
      arithmetically compare the corresponding fields of the gsma-
      defined substring from each IMEI in order of significance and
      according to their data type.  Two IMEIs are equal if and only if
      all the corresponding fields are equal.

      The lexical equivalence of the GSMA namespace-specific strings
      (NSSs) is defined as an exact, but not case-sensitive, string
      match.

      Any identifier in GSMA namespaces can be compared using the normal
      mechanisms for percent-encoded UTF-8 strings.

I think this passage has not been updated to match the symbols in the
ABNF.  For instance, there isn't a "gsma-defined substring" in the
grammar.  But it's not clear to me what the comparison process is.
E.g., how are parameters compared?  What is a "field"?

(What is the informal description of the equality test?  I assume
we've already agreed on that and it's just a matter of specifying it
formally.  draft-allen-dispatch-imei-urn-as-instanceid-06 section 5
gives "any optional or variable components of the URN (e.g., the
"vers" parameter) MUST be presented with the same values and in the
same order)".  Is that correct?)

Editorial:

   1.  Introduction

   GSMA is an identifier for a namespace for identities used by Mobile
   ^^^^

I think this would be more clearly written as '"gsma"', that is,
lower-case (as the actual namespace ID is), and in quotes (as the
subject of the sentence is the name of the namespace, not the GSMA.

Perhaps a less syntactically awkward way to write it would be "The
namespace "gsma" is a namespace for ...".

"sub namespace" should probably be hyphenated, as "sub" is not
generally used as a separate word.

      3.1.  GSMA

      A IMEI is an identifier under the GSMA namespace that uniquely
      ^

This should be "An".

      The formal definition of the IMEI string representation for the
      gsma-specifier-defined-substring for the "imei" gsma-specifier is
      provided by the following ABNF [8]:

The BNF and text do not explicitly state that URNs in the "imei"
sub-namespace use exactly one gsma-specifier-defined-substring,
whereas that requirement is intended but the generic syntax allows
zero or more gsma-specifier-defined-substrings.  This wording would
correct that:

      A URN with the "imei" gsma-specifier contains exactly one
      gsma-specifier-defined-substring, and its formal definition is
      provided by the following ABNF [8]:

      The GSMA will take responsibility for the gsma-specifier "imei"
      and manage the sub level.
                     ^^^^^^^^^

This seems awkward, as "sub-level" is not commonly a word.  Perhaps
this expresses the intended meaning:

      The GSMA will take responsibility for the gsma-specifier "imei"
      and will manage the URNs in its sub-namespace.

   4.1.3.  Spare

   The Spare is a single decimal digit that is used as a security check
   digit to combat potential spoofing.  The Spare is always set to zero
   when transmitted by the Mobile Equipment. 

There are repeated uses of the phrase "the spare is always set to zero
when transmitted by the mobile equipment".  I suspect this also means
that "spare" is always "0" in IMEI URNs, but the text doesn't say that
directly.  Since other forms of "transmission by the Mobile Equipment"
are out of scope for this document, perhaps the second sentence could
be changed to:

   The Spare is always set to zero in an IMEI URN.

Is there a security concern if the "actual" check digit is
accidentally used as the "spare" field in an IMEI URN?  If so, a
sentence to that effect should be added to "Security considerations".

   8.  Security considerations

   It is therefore RECOMMENDED that the IMEISV is not delivered to
   devices that are not trusted.

In the document, there is no explicit statement that IMEISV is
logically interchangeable with "IMEI URN with svn parameter", which
might cause an implementer to overlook the implications of the above
sentence.  So I would suggest augmenting it:

   It is therefore RECOMMENDED that the IMEISV (that is, the IMEI URN
   with svn parameter) is not delivered to devices that are not
   trusted.

Similarly, for thoroughness:

   In particular, the IMEI URN MUST NOT be included in messages
   intended to convey any level of anonymity.

*** Comments on draft-allen-dispatch-imei-urn-as-instanceid-06

Editorial:

   Abstract

   This specification defines how the Uniform Resource Name namespace
   reserved for GSMA (Global Sstandard for Mobiles Association) ...

The expansion of the acronym GSMA provided here is different from the
one in draft-montemurro-gsma-imei-urn-11, and does not agree with the
expansion of "GSM" provided by Wikipedia ("Global System for Mobile
Communications, originally Groupe SpC)cial Mobile").

   ... identities and its sub namespace for the IMEI (International Mobile

"sub namespace" should probably be hyphenated or made one word.

   station Equipment Identity) can be used as an instance-id as
   specified in RFC 5626 [1] and also as used by RFC 5627 [2].

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Background  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  3GPP Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  User Agent Client Procedures  . . . . . . . . . . . . . . . . . 5
   6.  User Agent Server Procedures  . . . . . . . . . . . . . . . . . 6
   7.  3GPP Registrar Procedures . . . . . . . . . . . . . . . . . . . 7
   8.  Security considerations . . . . . . . . . . . . . . . . . . . . 7
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1.  Normative references . . . . . . . . . . . . . . . . . . . 8
     10.2.  Informative references . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

The capitalization of the section titles is inconsistent.  (But you
can probably leave fixing that to the RFC Editor.)

   1.  Introduction

   meets this requirement by specifying how the GSMA IEMEI URN is used
                                                     ^^^^^

Should be "IMEI".

   3.  Background

   Amongst other things in some
   regulatory jurisdictions the IMEI is used to identify a stolen mobile
                                                        ^
Adding "that" here makes this easier to read.  Otherwise, one tends to
read "identify a stolen mobile".
   is being used and help to identify the subscription that is using it
                ^^^^

There are three clauses here, so there should be only one "and", and
the second clause should start "to help".

   and to prevent its use.  Whilst GSM was originally a circuit switched
   system enhancements such as GPRS (General Packet Radio Service) and
         ^
Adding a comma makes this easier to read.  Otherwise, one tends to
read "a circuit switched system enhancements".

   UMTS have added IP data capabilities which along with the definition
   of the IP Multimedia Subsystem (IMS) has made SIP based calls and IP
   multimedia sessions from mobile devices possible.

   Center) server enhanced for ICS which controls mobile voice call
   setup over the circuit switched radio access while establishing the
   corresponding voice session in the core network using SIP/IMS.  To
   enable this the MSC server enhanced for ICS (IMS centralized
   services) performs SIP registration on behalf of the mobile device

Move the expansion of "ICS" to its first use.

The phrase "MSC server enhanced for ICS" is used several times.  I
assume that this is a specific technical term.  Is there a shorter
form?

   Additionally in order to meet the regulatory requirements to use the
   IMEI to identify a stolen mobile is being used and help to identify
   the subscription that is using it and to prevent its use the same
   IMEI that is obtained from the circuit switched signaling needs to be
   obtainable from SIP signaling.

Much of this duplicates the first sentences of the section.  Perhaps
it could be shortened to:

   Additionally, in order to meet the above regulatory requirements,
   the IMEI that is obtained from the circuit switched signaling needs
   to be obtainable from SIP signaling.

   4.  3GPP Use Cases

   call as from the same mobile device that was in the emergency session
        ^^

This probably should be "is".

   5.  User Agent Client Procedures

   When registering with a non 3GPP IMS network ...

There are a number of instances where "non" is presented as a
stand-alone word.

[END]