[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IKEv2 and SIGMA
Steve,
I suspect that most people on this list don't have a requirement for either
repudiation or non-repudation. A financial institution would want
non-repudation, but of the IPsec traffic as well, so I would agree with you
that non-repudiation in IKE is not a very important property. However, some
of the hardcore privacy advocates would probably not want to leave a trail
of who they've been talking to, so repudiation could be an important
property for them.
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
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.
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?
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: