[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: compare-jfk-sigma.txt



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.

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.

 > 2. The WG decides that it wants a protocol that protects the responder's ID
 > against active attacks (or that it doesnt care about ID protection against
 > active attacks one way or the other). In this case the protocol below seems
 > like a good choice. (Just to reiterate - this protocol is basically the
 > 4-msg variant of SIGMA, as proposed by Hugo a few days ago, with the HMAC
 > being on the outside as done in IKEv2.)

Actually it really does not matter which ends identity is protected
against active attacks unless we disallow changing of the direction of
the negotiation.

I myself think it is best to protect against passive attacks (and in
this case I want protection to both ends identities). For active
attacks you always have time to run when you notice that someone got
your identity by active attack :-) Or you use double authentication,
i.e authenticate machine first and then the user. 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/



Follow-Ups: References: