[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKEv2 and SIGMA
On Tue, 11 Dec 2001, Andrew Krywaniuk wrote:
[....]
>
> The issue here is that one of the protocols (SIGMA) has been specifically
> designed to have repudiation in the phase 1. For JFK and IKEv2, I don't
SIGMA was NOT specifically designed for this. Every bit in SIGMA has
a role in the provability of the core security properties.
The non-transferable proofs are a nice side-effect and, as you pointed
out, it cannot always be guaranteed if the peer is malicious.
> think either repudiation or non-repudiation were design constraints. JFK
> always provides non-repudiation, but that is most likely by convenience
> rather than by design. IKEv2 has repudiation in the normal case, but this
> can be thwarted by the responder (the attack I mentioned below).
>
> SIGMA has a more elaborate hash calculation in order to avoid the
> possibility of signing anything that the peer generated. However, the device
> still signs the peer's cookie (and it should be just as easy to lauch the
> attack with a cookie as with a nonce) so SIGMA doesn't actually prevent this
> attack either. Therefore, I think the more generic hash calculation from
> IKEv2 is preferable.
The hash calculation of SIGMA is to make sure you MAC (or prf)
the ID. This same MAC can go outside the signature; it just saves
space if you put it inside. Again, the fundamental issue is that you
make absolutely sure to include the sender's ID under the MAC.
>
> I don't personally care whether we design for repudiation or non-repudiation
> or neither. However, I would like to know that if we are adding special
> constraints to the protocol then we are at least getting something for it.
> How many WG members would need to require a repudiatable exchange before
> this became a Son-of-IKE design requirement?
>
> BTW, Hugo, you never explained why it was essential for IKEv2 to sign the
> identity and I can't see any justification for this requirement. Is this
> because:
>
> a) It has not been proven secure not to sign the identity?
> b) It has been proven insecure not to sign the identity?
It has been proven INSECURE not to MAC the identity. If you sign the
identity but do not include a MAC the protocol is insecure. This uses a
10+ year (simple but non-obvious) attack discovered by Diffie, van
Oorschot and Wiener, and a main motivation behind SIGMA's (and IKE)
design.
Sara Bitan will be making a presentation at the ipsec meeting
where hopefully some of these crypto issues will be clarified.
Hugo
>
> Andrew
> -------------------------------------------
> There are no rules, only regulations. Luckily,
> history has shown that with time, hard work,
> and lots of love, anyone can be a technocrat.
>
>
>
> > -----Original Message-----
> > From: owner-ipsec@lists.tislabs.com
> > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Stephen Kent
> > Sent: Tuesday, December 11, 2001 9:49 AM
> > To: andrew.krywaniuk@alcatel.com
> > Cc: 'Hugo Krawczyk'; 'IPsec WG'
> > Subject: RE: IKEv2 and SIGMA
> >
> >
> > At 5:49 PM -0500 12/5/01, Andrew Krywaniuk wrote:
> > >Hugo, you have talked about the importance of carefully
> > choosing the inputs
> > >to the authentication hash. I envision a situation where:
> > >
> > >Responder chooses Nr = SIG_r(Ni, g^xi, IDr, ...)
> > >Initiator creates AUTHi = SIG_i(Ni, g^xy, Nr, ...)
> > >
> > >So now the initiator has been tricked into signing something
> > which binds a
> > >derivative of the responder's identity to the nonce and DH
> > values from the
> > >exchange. And the result is that the initiator can no longer
> > repudiate the
> > >exchange.
> > >
> > >Is this the kind of attack you are talking about?
> > >
> > >Andrew
> > >-------------------------------------------
> > >There are no rules, only regulations. Luckily,
> > >history has shown that with time, hard work,
> > >and lots of love, anyone can be a technocrat.
> >
> > Excuse me for this belated comment, as I am still working my way
> > through the 1K+ messages that arrived last week while I was away on
> > vacation.
> >
> > I think the term "repudiate" may be inappropriate in this context.
> > IPsec does not offer NR as a security service for the traffic sent on
> > an SA, so the opportunity to offer NR with regard to an IKE exchange
> > may not be all that important. Is there general agreement that NR is
> > a concern here?
> >
> > Steve
> >
>
>
Follow-Ups:
References: