Subject: [rrg] ILNP Mobility & local-scope IDs

From: Ran Atkinson <[email-masked]>
Date: Thu, 15 Jul 2010 12:32:54 -0400

Folks,

  I think that it is not necessarily the case that one
must choose either a local-scope ID xor workable mobility
with ILNP.

[Here is one example:]

  As I hope everyone now understands, the IETF SEND work can be 
used with ILNP.  With SEND, the ID value is a function of the 
cryptographic key used by the legitimate node using that ID value.  
SEND uses that cryptographic key to generate unique authentication 
data that is cryptographically bound to the ID.  Unless the 
underlying cryptographic algorithm (i.e. RSA, SHA) has been 
broken [1], an adversary will not be able to infer the 
cryptographic key from knowledge of the ID.  So, if one chooses 
to deploy the SEND mechanism, this prevents an adversary 
from stealing the ID.

  In turn, this means that a node using a CGA (e.g. with SEND)
can fully participate in ILNP mobility.  If some other node
tries to use the same local-scope ID on any link using SEND,
that other node will not possess the required cryptographic 
key material, so that other node won't be able to successfully 
complete the Secure ND (SEND) process.

  Note further that nothing prevents a node from having 
multiple valid CGAs at the same time, each with its own 
key material.  So folks who wish to vary their ID values 
over time for perceived privacy reasons aren't locked out 
from mobility either.

[End of example]

  One could devise multiple examples to illustrate the main 
point above.  Due to extremely scarce time, I'm only providing 
one example.  I'm sure others on this list could come up with 
other examples, and will leave generating a more comprehensive 
list to others.

Yours,

Ran
[email-masked]

PS:  Nothing above is new.  It has all been clearly documented
     before now, in various papers, including draft-rja-ilnp-intro.
     All that this note is doing is repeating what Steve Blake 
     and others have pointed out, and what the existing IETF 
     standards-track RFCs on CGAs and SEND have specified.  

[1] Note that an ordinary "collision attack" on SHA-1 would not 
    be sufficient to compromise SEND.  An adversary has to find
    the precise key value used for authentication, which is a
    significantly harder problem than an ordinary "collision
    attack".  A quick web check of the published literature 
    reveals no reason to believe that any significant progress 
    has been made on attacking either of these algorithms in a
    manner that would be relevant for SEND.