Earlier, Tony Li wrote (in part): % ... % This has obvious security implications which will, in effect, require a % security association between hosts. That security association effectively % requires some security token (e.g., a public-private key pair used to % compute a session key) so that the correspondent host can be assured % that the component connections are indeed related.
It is unclear to me that one needs to have a cryptographic security association in all cases, or indeed even in common deployments. For example, an unpredictable nonce present in control traffic (rather than in every packet) could provide security protection against off-path attackers that is entirely equivalent to the security provided by ordinary IPv4 or IPv6 for sessions not using IP Security. In such a model, the nonce would be the "security token", but it would not be derived from any session key, from any public/private key, or from any public/private key pair). % This security token is, for all intents and purposes, a host identifier. % ... It isn't obvious to me that the claim above is necessarily true. Using the example of a nonce, the nonce might be very short-lived (e.g. for the duration of a single IP session or flow) and hence not be suitable for use as a node identifier. Further, if there were significant potential for a nonce collision between different flows/sessions, then one might want to have some method to differentiate among the sundry sessions using a given nonce value. HIP makes the identity of a node a function of the public key of the node. A corollary to that practice seems to be that if a node's public key were compromised, and in my experience all cryptographic keys are eventually compromised, then the node necessarily would lose its identity. So it seems distinctly undesirable (to me) for the identity of a node to be derived (directly or indirectly) from any cryptographic key used by that node. Instead, I'd prefer to have the cryptographic keys used by a node (if any) bound to the identity of the node using some other method. One example might be some sort of X.509v3 (PKIX) certificate, but other examples can be imagined. If one wants to use an identity that is derived from a cryptographic key, then looking at the HIP RG's architectural work might be very relevant. Cheers, Ran [EMAIL PROTECTED] -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
