RE: [dhcwg] DUID on a Virtual Host

Thanks Markus,

I won't pretend to have a deep knowledge of this space, but I
am also being told that public key is considered as a unique
identifier for the SPKI/SDSI framework:

  http://en.wikipedia.org/wiki/Simple_public_key_infrastructure

Fred
fred.l.templin@boeing.com 

> -----Original Message-----
> From: Markus Stenberg [mailto:mstenber@cisco.com] 
> Sent: Tuesday, February 20, 2007 6:29 PM
> To: Templin, Fred L
> Cc: rbrabson@us.ibm.com; narten@us.ibm.com; dhcwg@ietf.org; 
> volz@cisco.com; Ted.Lemon@nominum.com
> Subject: Re: [dhcwg] DUID on a Virtual Host
> 
> On 21.2.2007, at 6.23, Templin, Fred L wrote:
> >> But, stepping back for a second, are public keys considered unique,
> >> anyway?  I'm not a security expert, but I  thought public keys were
> >> generated by the end user, and there is nothing that prevents
> >> two users
> >> from generating the same public key.  If so, how  does a a DHCP  
> >> server
> >> differentiate between two hosts that choose to use the same
> >> public key.
> > Yes, I wondered about that too and that was why I suggested
> > earlier that additional information (e.g., a L2 address, a
> > timestamp, etc.) might also be needed.
> 
> The answer is, it depends.. If you use a public key as-is, 
> then, yes,  
> collisions are possible but not probable  (probability of all say,  
> 1024 or 2048 bits being the same is roughly nil - think 1 in 2^1024  
> and you find that it is very unlikely). Even intentionally creating  
> same public key is insanely hard, equivalent in terms of effort to  
> breaking the encryption itself.
> 
> Of course, lacking/broken sources of randomness (think: boxes with  
> time that starts at 0, creating their first public keys at 
> first boot  
> with clock unset, and so forth) are different beast entirely.  With  
> that sort of environment timestamp won't save you either.
> 
> I think the correct approach is just to promote semi-reasonable  
> sources of randomness, and if that fails, initializing RNG with  
> hardware parameters and then using the public keys as-is.
> 
> There is of course the question of what we want to accomplish with  
> this scheme; raw public keys used like in SSH provide mostly 
> just way  
> of making sure that the users cannot easily pretend to be each other  
> based on sniffed traffic (assuming you add signature option to the  
> packets sent to the server, or alternatively receive encrypted  
> subblocks from the server), and provide some protection of the  
> content; however, are those desirable characteristics for DHCPv6?
> 
> Cheers,
> 
> -Markus
> 
> 

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg