[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Re[2]: IKE Public Key Encryption
Obviously, there is no perfect solution to this problem. What I suggested
was merely a way to make the task more difficult for the adversary. In this
case, the responder would actually have to test the hash for each
connection, rather than doing a simple memcmp.
Information theory basically prevents identity protection and authentication
from co-existing in a stateless protocol. If you really wanted to have true
identity protection, you would have to keep a per-connection state, such as
a shared secret or a user token.
Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.
> -----Original Message-----
> From: Jim Tiller [mailto:jtiller@lucent.com]
> Sent: Thursday, March 23, 2000 9:05 AM
> To: Andrew Krywaniuk
> Cc: 'IP Security List'
> Subject: Re[2]: IKE Public Key Encryption
>
>
> Hello Andrew,
>
> Wednesday, March 22, 2000, 6:04:54 PM, you wrote:
> anc> As a general comment on including the hash of the
> certificate/public key in
> anc> the message, this doesn't really provide true identity
> protection, since an
> anc> attacker could generate the same hash.
>
> To accomplish this the attacker would have to hash all possible
> certificates and or public keys that he thinks are relative. BUT - you
> have a good point, nonetheless.
>
> anc> Wouldn't it be better to use a hash of the certificate
> plus some session
> anc> info (e.g. the cookies), which would at least protect
> against identity
> anc> tracking attacks.
>
> I would actually like to see the verbiage modified slightly to hash
> the public 'value' used (certificate or key) and always
> provide that to the
> responder. Therefore, if your going to hash it, you should include an
> identifier. As far as using a cookie, wouldn't that be available to
> the attacker as well? Unfortunately, I cannot think of a better idea
> right now....it can't be Ne or ID in standard mode, or Ne,
> ID, or KE in
> revised mode.
> So, the point of including an identifier to protect the hash to avoid
> an attacker producing the same, may simply be moot. To fully protect
> the identity, you have to use something only known by the peers, which
> is usually encrypted for transit, or generated independently, such as
> g^xy, (but that wouldn't work for revised mode).
>
> Basically, you have a good point, but I don't know a good direction.
> Nonetheless, I do think the inclusion of the public value in the
> initiators message should be included - for scalability.
>
> -jim
>
> anc> Andrew
> anc> --------------------------------------
> anc> Beauty with out truth is insubstantial.
> anc> Truth without beauty is unbearable.
>
>
>