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

RE: IKEv2 and SIGMA


My personal opinion on non-repudiation is that this should be a requireent
only from applications where the semantics of what is signed are explicit
and clear to the signer (and where all the legal implications of signing
are also explicit and clear). This is not the case with IKE (or ipsec in
general) where one is signing all type of formatted and un-formatted
information (such as IDs and nonces). Signatures in a key exchange
protocol are used for two-party authentication, not for leaving provable
traces for use by third parties.

And apropos not leaving provable traces of communications, I see this as a
good property of a key-exchange protocol, but NOT an essential
requirement. In particular SIGMA is not designed specifically to meet this
requirement. You get it as a free bonus since the protocol (for other GOOD
reasons) does not sign the peer's id.

Hugo

On Tue, 11 Dec 2001, Stephen Kent wrote:

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