Subject: Re: [saag] Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols (Fwd: New Version Notification for draft-gont-predictable-numeric-ids-00.txt)

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 1 Mar 2016 08:20:22 -0700

Hi, here are some comments from our -- CDT's Joe Hall and Greg Norcie
-- review of this document:

* General: thanks for taking this on, it's a great resource and
needed, in our opinion.

* Do you have thoughts where you might go with this next? It seems
like a BCP for "Guidelines on the use of identifiers in protocols"
could be a very good thing. I know the IAB would be engaged as would
folks on this list in ensuring that it resulted in good, flexible
guidance.

* There are a number of places in the ID where you state some
assumptions about what the attacker can and cannot know. Maybe I
missed this but are you adopting a specific threat model/attacker
model from another RFC or publication? If so, it would be good to
point to it (I may have missed this). If not, it would be good to add
a paragraph that states you're considering a network attacker with no
local physical or logical access to the device, etc.

* I was expecting to see at some point a list of common
vulnerabilities or bad design patterns with unique identifiers. E.g.,
"predictable identifiers", "predictable offsets in identifier
sequences", "embedding IDs from one context into another" (see:
https://tools.ietf.org/html/draft-huitema-dhc-anonymity-profile ). I'm
not sure if section 8 lists vulnerabilities or something else (or if
what I'm thinking of are not vulnerabilities). For example, where does
the reuse of an identifier -- like that described across layers in
draft-huitema-dhc-anonymity-profile -- fit in your scheme?

* typos:

   * heading of 8.2 should capitalize "uniqueness" for consistency
with other subsections around it.

   * p. 4, misspelling: "speification" should be "specification"

   * Section 7.4.1, "Predictable Linear Identifiers Algorithm" has a
typo in the pseudocode, "next_ifd" should be "next_id".

   * p. 16: "does nto exist" should be "does not exist"

   * Section 7.4.5: remove "Sections" from "described in Sections
Section 1.1.1 and Section 7.1.2" and one other instance later in that
same paragraph.

   * Section 7.4.5 has a typo in pseudocode: "id_increment" should be "id_inc"

Thanks!

On Thu, Feb 4, 2016 at 9:55 AM, Fernando Gont <[email-masked]> wrote:
> Folks,
>
> We have published a new IETF I-D entitled "Security and Privacy
> Implications of Numeric Identifiers Employed in Network Protocols".
>
> It sheds light on the security and privacy implications of predictable
> numeric identifiers, which have affected (and still affect) several IETF
> protocols for ages, and that in some cases (such as IPv6 IIDs) can be
> leveraged for pervasive monitoring.
>
> The I-D is available here:
> <https://www.ietf.org/internet-drafts/draft-gont-predictable-numeric-ids-00.txt>
>
> Your feedback will be appreciated.
>
> Thanks!
>
> Best regards,
> Fernando
>
>
>
>
> -------- Forwarded Message --------
> Subject: New Version Notification for
> draft-gont-predictable-numeric-ids-00.txt
> Date: Thu, 04 Feb 2016 08:29:45 -0800
> From: [email-masked]
> To: Ivan Arce <[email-masked]>, Fernando Gont
> <[email-masked]>
>
>
> A new version of I-D, draft-gont-predictable-numeric-ids-00.txt
> has been successfully submitted by Fernando Gont and posted to the
> IETF repository.
>
> Name:           draft-gont-predictable-numeric-ids
> Revision:       00
> Title:          Security and Privacy Implications of Numeric Identifiers
> Employed in Network Protocols
> Document date:  2016-02-04
> Group:          Individual Submission
> Pages:          32
> URL:
> https://www.ietf.org/internet-drafts/draft-gont-predictable-numeric-ids-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-gont-predictable-numeric-ids/
> Htmlized:
> https://tools.ietf.org/html/draft-gont-predictable-numeric-ids-00
>
>
> Abstract:
>    This document performs an analysis of the security and privacy
>    implications of different types of "numeric identifiers" used in IETF
>    protocols, and tries to categorize them based on their
>    interoperability requirements and the assoiated failure severity when
>    such requirements are not met.  It describes a number of algorithms
>    that have been employed in real implementations to meet such
>    requirements and analyzes their security and privacy properties.
>    Additionally, it provides advice on possible algorithms that could be
>    employed to satisfy the interoperability requirements of each
>    identifier type, while minimizing the security and privacy
>    implications, thus providing guidance to protocol designers and
>    protocol implementers.  Finally, it provides recommendations for
>    future protocol specifications regarding the specification of the
>    aforementioned numeric identifiers.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

CDT's annual dinner, Tech Prom, is April 6, 2016! https://cdt.org/annual-dinner

---

From: Fernando Gont <[email-masked]>
Date: Tue, 1 Mar 2016 20:54:47 -0300

Hi, Joseph!

Thanks so much for your feedback! -- Please find my comments in-line....

> folks on this list in ensuring that it resulted in good, flexible

Yes, that's the intent: a BCP of similar nature to BCP 106/RFC 4086
which should be applied everytime a new numeric identifier is specified
in a new protocol. And could b applied to existing protocols were the
corresponding spec still allows or suggest the use of numeric
identifiers that have negative security/privacy implications.

> local physical or logical access to the device, etc.

Yep, we assume that in many places. Will clarify this.

> sequences",

This is discussed throughout the document for each algorithm that
results in predictable identifiers. For example, Section 7.4.1 (page
15), states:

   If a global counter is used (such as "next_id" in the example above),
   a node that learns one protocol identifier can also learn or guess
   values employed by past and future protocol instances.  On the other
   hand, when the value of increments is known (such as "1" in this
   case), an attacker can sample two values, and learn the number of
   identifiers that were generated in-between.

The consequences of an attacker learning "values employed by past and
future protocol instances" or "the number of identifiers that were
generated in-between" varies from one protocol to another. e.g., in the
case of TCP ephemeral ports, predicting ephemeral ports would be of help
for the attacker to perform e.g. TCP reset attacks, whereas "learning
the number of ephemeral pots generated between two outgoing connections"
would  be an information leakage about the number of outgoing
connections established by the victim (which might be of use in certain
scenarios).

OTOH, Sections 4.1 and 4.2 illustrate how predictable numeric IDs were
found to be useful for performing different kinds of attacks.

mmm.. were you expecting, in all of the sections that discuss specific
algorithms, references/links to how such vulnerable algorithms result in
specific vulnerabilities when applied to different protocols? (i.e.,
kind of a cross-reference), or something else?

> "embedding IDs from one context into another" (see:
> https://tools.ietf.org/html/draft-huitema-dhc-anonymity-profile ). 

We didn't cover "embedding IDs from one context into another". In
principle, you just shouldn't do this, since this is kind of what we
refer to as "Protocol specifications that over-specify their
identifiers", in the sense that, when you employ a numeric identifier in
a different context, you're implicitly enforcing requirements that you
usually don't really need in the new context. -- e.g., using a MAC
address to generate a DHCP DUID leaks information that you don't eally
need to leak for complying with the corresponding *interoperability*
requirements (uniqueness).

> I'm

As noted above, this one is not explicitly noted -- maybe we could say
what I mentioned above ("this results in over-specification of the
numeric id") in Section 3 of the document?

> * typos:
[....]

We will fix all of these typos in the next rev of the document (that we
plan to submit before the cutoff).

Thanks so much!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 4 Mar 2016 09:40:12 -0500

> identifiers that have negative security/privacy implications.

Superb!

> kind of a cross-reference), or something else?

I guess I found the discussion of specific vulnerabilities to be a bit
abstract, but that could just be me with lower brain power than you
authors. ::)  If you feel it would be a good addition, links to
examples of these kinds of vulnerabilities (either theoretical or in
attacks in the field) would help make it a bit more concrete. Happy to
try and help find some of these if you decide it would be a good
addition.

> requirements (uniqueness).

That sounds reasonable...

> numeric id") in Section 3 of the document?

Yes, it would be good to have a "don't do this, it's so stupid we
don't even cover it here" section about these kinds of cross-protocol
or over-specification examples.

Again, thanks for taking this on. best, Joe

---

From: Fernando Gont <[email-masked]>
Date: Mon, 7 Mar 2016 03:59:33 -0300

Hi, Joseph,>>> * I was expecting to see at some point a list of common
> attacks in the field) would help make it a bit more concrete.

We'll do that!

> or over-specification examples.

We'll add this to the next rev. Plan is to rev this doc next week or so
(before the I-D submission cutoff).

Thanks!

Best regards,