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

Re: compare-jfk-sigma.txt

On Tue, 4 Dec 2001, Ran Canetti wrote:

>
> Hugo,
>
> I agree with most of the facts in your assessment of JFK vs. SIGMA.

Ran,

I'm happy we agree.
Now the question is what we do about it.

It seems to me that you (and maybe the other JFK designers)
do not consider the extra signature SIG(g^r) to  be AS BAD
as I think. I see it as a real computational burden and/or
a push to limit PFS (at the responder's side). It also calls
for "outlawing" signatures like DSA (or ECDSA) where the
verification complexity is significant. 
(Is this an idea coming from RSA Inc.? :)
Note that the poor initiator cannot amortize the costs of this 
signature verification!

The drawbacks are clear. So, what are the benefits?
Only keeping the initiator's id protected from active attackers,
something I appreciate as a good thing, but not at the expense of
generation/verification of this signature AND forcing responder's id
diclosure.

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: References: