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

Re: compare-jfk-sigma.txt


I actually like that suggestion, and agree that it would nicely merge the
good properties of all three protocols.

(Note: This is so only if the WG decides that providing ID protection to
the initiator against active attacks  is not worth the extra signature).

I would make one modification though: In messages 3 and 4, I would do
the MAC{Ka} on the "outside", instead of doing it
under the signature. This way, in one blow you get both the authentication
needed for the core security of the protocol, and  you protect the
encryption against active attacks that can compromise the ID protection
(as you pointed out).

Remark: Indeed, this is the way IKEv2 does the authentication. But, unlike
IKEv2, I would make this an integral part of the protocol rather than
invoking ESP.

In other words, do:

Message 1, I->R: Ni,g^r

Message 2, R->I: Ni, Nr, g^r, GRPINFOr, HMAC{HKe}(Ni, Nr, g^i, g^r)

Message 3, I->R: Ni, Nr, g^i, g^r, HMAC{HKe}(Ni, Nr, g^i, g^r),
                 E{Ke}(IDi,sa,SIG{i}(Ni,Nr,g^i,g^r,sa,GRPINFOr)),
                 HMAC{ka}(E{Ke}(IDi,sa,SIG{i}(Ni,Nr,g^i,g^r,sa,GRPINFOr)))

Message 4, R->I: E{Ke}(IDr,sa',SIG{i}(Ni,Nr,g^i,g^r,sa,sa')),
                 HMAC{ka}(E{Ke}(IDr,sa',SIG{i}(Ni,Nr,g^i,g^r,sa,sa')))

(Ka is a key derived from g^ir in the same way as Ke.)

BTW, Notice that in the above I included in the signature in message 3.
This is needed to prevent an attacker from changing GRPINFOr in msg 2 without
this being noticed. (Thanks to Dave Wagner for pointing the problem to us.)


Regarding what's included in the cookie and whether to mandate HMAC
I agree that this can be more flexible. This is less important for
interoperability though so it can be decided later.


Ran



> 
> From hugo@ee.technion.ac.il Tue Dec  4 10:25:34 2001
> 
...
> 
> If keeping a 4-msg protocol that includes DoS is important to you, I would
> recommend the following protocol that combines the JFK structure with
> the SIGMA ("Sign-and-MAC") authentication and avoids all the problems 
> that I pointed out in part B of compare-jfk-sigma.txt, except for the long
> input to HMAC (see below).
> 
> Its main accomplishment regarding JFK is the elimination of the
> (irritating) SIG(g^r) and its pfs-limitation consequences,
> providing R with active protection (as opposed to no protection
> in JFK), and providing I with passive protection (as opposed to active
> protection in JFK; well, there is no free lunch...)
> This id protection is the same as provided by IKEv2.
> 
> The protocol (with some details/optimization to be discussed) goes:
> 
> 1.  I->R: Ni, g^i
> 
> 2.  R->I: Ni, Nr, g^r, GRPINFOr, HMAC{HKr}(Ni, Nr, g^r)
> 
> 3.  I->R: Ni, Nr, g^i, g^r, HMAC{HKr}(Ni, Nr, g^r)
>           E{Ke}(IDi, sa, SIG{i}(MAC{Ka}(0, Nr, Ni, IDi, g^i, g^r, sa))
> 
> 4.  R->I: E{Ke}(IDr, sa', SIG{r}(MAC{Ka}(1, Ni, Nr, IDr, g^r, g^i, sa'))
> 
> All notation is as in JFK, with the key Ka being derived from g^ir in 
> a similar way to Ke.
> 
> There are some possible optimizations, like not sending g^i in first
> message (maybe only a group identifier), but then this is less good 
> for responders that do not care about DoS. Another one is making the DoS
> protection optional for R (just avoids the generation and sending of the
> cookie and related stuff). 
> 
> One thing that I still do not like here is putting g^r under the cookie
> computation: it's long. One could include HASH(g^r) under the
> cookie, but this helps performance only when you keep same r for
> several sessions. In any case this is "nothing" compared to the
> need to compute SIG(g^r)...
> 
> And please, with all my respect to HMAC :), do not specify HMAC as the
> ONLY cookie mechansim. You can suggest it, or make it a "SHOULD", but why
> mandate something that is a local implementation issue, and for
> which other MAC mechansims may work better (e.g. faster)? 
> 
> Hugo
> 
> PS: Note that the above protocol is the "ultimate merge" between JFK,
> IKEv2, and SIGMA.
> Negotiation, phase 2, etc are independent matters and can be dealt with 
> separately.
> 
> 
> On Tue, 4 Dec 2001, Ran Canetti wrote:
> 
> > 
> > Hugo,
> > 
> > I agree with most of the facts in your assessment of JFK vs. SIGMA.
> > To sum up, the main technical points seem to be:
> > 
> > In terms of security:
> > 
> > * The "basic security" of both protocols is sound.
> > 
> > * Both protocols allow reuse of the DH exponents in times of high load
> >   with a similar price in PFS.
> > 
> > * Both protocols offer comparable DOS protection. (What gets included in
> >   the cookies can be decided upon independently of the rest of the protocol.)
> > 
> > * Both protocols offer identity protection for the initiator against active
> >   attackers.
> > 
> > * SIGMA offers ID protection for the the receiver against eavesdroppers.
> >   JFK does not.
> > 
> > 
> > In terms of performance:
> > 
> > * SIGMA is either 3/5 messages, depending on whether DOS protection is
> >   turned on. JFK is 4 messages period. 
> > 
> > * JFK has an additional signature that, in times of high load, can be
> >   amotized over many sessions.
> > 
> > 
> > Now that the main technical differences are clear, it should be easier for 
> > people to decide which properties are preferable to them.
> > 
> > 
> > Ran
> > 
> > 
> > 
> 
> 
>
Follow-Ups: