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)

[Fernando Gont <[e-mail]>]

Hi, Joseph!

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

On 03/01/2016 12:20 PM, Joseph Lorenzo Hall wrote:
> 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.

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.



> * 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.

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



> * 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",

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
> 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?

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492