[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compare-jfk-sigma.txt
Tero Kivinen wrote:
>
> canetti@watson.ibm.com (Ran Canetti) writes:
> > 1. The WG decides that it wants a protocol that protects the initiator's
> > identity against active attacks (and is willing to pay the associated costs,
> > ie, extra sig and sending the responder's ID in the clear).
> > In this case JFK seems like a good choice.
>
> You forget one big thing associated with that also. If we want to
> protect initiator's identity against active attacks, it means that we
> can NEVER reverse the initiator and responder. I.e the original
> responder CANNOT EVER initiate to the initiator.
That is true. However, this can be fully enforced by the CLIENT
implementation, and only if it wishes to do so. It is sufficient for SOI
to acknowledge that some initiators MAY choose to not to respond, ever.
I haven't thought this through, like would the initiator need to signal
this somehow, and how.
>
> We don't have initiator and responder we have server (whose identity
> is public and who always acts as a responder) and client (whose
> identity is always protected and who always acts as an initiator).
>
> If we allow changing the roles the attacker can fake to be a original
> responder trying to do rekey and then grab the original initiator's
> identity.
I think we should acknowledge that there are different scenarios, both
peer2peer and client2server. The reality is like that, and if the protocol
models the reality, it's more likely to succeed.
I do think that protecting a CLIENT's identity against active attacks
is a worthy goal. Not all initiators' identities, only those that wish
to do so.
Ari
--
"They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety." - Benjamin Franklin
Ari Huttunen phone: +358 9 2520 0700
Software Architect fax : +358 9 2520 5001
F-Secure Corporation http://www.F-Secure.com
F(ully)-Secure products: Securing the Mobile Enterprise
References: