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

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

Correct. It takes the proven cryptographic design of SIGMA, 
the active responder's protection from IKEv2, and the 4-message 
built-in DoS protection from JFK.

> 
> (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).

If you are referring to the extra signature of JFK, then please 
add to that cost the exposure of the responder's id, the per-exchange 
signature verification by the initiator, and reduced-pfs for 
signature-generation amortization.
Anyway, if you want to have active initiator's protection you 
can still avoid all these costs by using adaptive DoS protection
(yes it is one more round trip but only when R is under attack).

As for WG preferences regarding who should be better protected 
(against active attacks): it seems that some do not care at 
all about ID protection, some would prefer to have it adaptive 
(as happened in both Photuris and IKEv1), other prefer the initiator 
(especially the client-to-gateway applications), and other prefer 
the responder (which in my view makes the most sense in a truly 
peer-to-peer scenario -- as Radia once explained).  But overall 
no one seems totally attached to one of the two approaches.

Actually, when I wrote my SIGMA draft I was under the impression that most
people would prefer to protect the initiator (especially, Radia in her
paper and ipsec presentation in July was very explicit about 
this and it seemed to have many buyers).
So I decided to present the version of SIGMA that protects the initiator
(without any "extra signature"). Then it turned out that IKEv2
adopted the responder's protection and no one seemed to care much;
this is why I was willing to present this 4-message version of SIGMA
(SIGMA-4), as we are discussing now, and which protects the responder
from active attacks and the initiator only under passive attackers.

> 
> 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).

This is correct from an analytical point of view, but makes 
the security of the protocol (and analysis) less robust to changes.  
For example, one day the encryption may be changed to one that 
is secure against active attackers but does not use the MAC at all 
(our proof of security is not "robust" enough to make sure that ALL 
possible future changes to the encryption specifications 
will still keep SIGMA's security if you tie its core authentication to
the encryption's integrity specification).

Therefore, I still prefer two separate MAC's with clearly separated
functionalities: one (under the signature) to provide the core 
key-identities binding, the other (on the ciphertext) for protecting the 
identities ciphertext from active attacks. For the later functionality,
identity protection, using an ESP definition as sugested in IKEv2 makes 
a lot of sense (but then we need directional Ke/Ka keys).

It is important to note that the "cost" of having two MACs is just
one extra application of a hash function (such as SHA-1) on a single block.
(I can explain this exactly but I prefer not to make this note even longer).

In any case, if for any reason the one-MAC approach is adopted,
I would still make a change to your description below:

In message 3 you send
C_i, HMAC{ka}(C_i) 
where C_i=E{Ke}(IDi,sa,SIG{i}(Ni,Nr,g^i,g^r,sa,GRPINFOr))

I would recommend sending
C_i, HMAC{ka}('0',Nr,IDi,C_i).

Here '0' represents the fact that the authentication is from I to R
(in the other direction it will be a '1') and helps against reflexion
attacks ('0' is not needed if one uses directional Ka keys).
IDi is EXPLICITLY included since it is the MOST IMPORTANT piece of
information to be included under the MAC; I do NOT want to depend on whether
IDi is transported or not in the third message, or whether or not it is
encrypted.
Putting Nr is to make the freshness guarantee for the MAC explicit.
(This is not strictly needed if Ka uses Ni in its derivation,
but again I prefer this more conservative and robust approach;
it also makes the analysis cleaner.)

For the fourth message you will send
C_r, HMAC{ka}('0',Ni,IDr,C_r).

BTW, if the protocol tranports any addditional information (such as IKE's
notifies, etc) they must be authenticated too.

> 
> 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.

You are absolutely right in not relying in ESP for the key-exchange 
authenticity; but if you have the MAC under the signature (as I still
prefer) then you can use ESP for the sake of id protection only.

Hugo

PS: there is a "cut-and-paste" typo in message 4 in your
description: sig{i} instead of sig{r}
(IKE suffers to this date from such a "cut-and-paste" typo :)

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