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

Re: compare-jfk-sigma.txt

Ran Canetti wrote:

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

I apologize for the confusion. IKEv2 doesn't "run on top of ESP" or
anything
like that. I was merely trying to avoid spelling out how to do padding,
etc.
The ESP spec seemed to have a nice clean format for "integrity protect and
encrypt this blob", i.e., IV | data | padding | padding length | hmm |
integrity.
So rather than spelling that out, I meant "use the syntax from the ESP
spec".
So yes, it should be the way you say, and it should be specified that
way in the spec. (and that way we also don't inherit an unused byte
where ESP happens to put the "next header" field--where I marked "hmm".)
What I meant is exactly what you
wrote: First encrypt the message with Ke and then integrity protect it with
Ka using
HMAC.

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

The one remaining difference is the choice of bits being signed. The
protocol
above signs selected fields from the messages, while IKEv2 proposes
signing the entirety of messages 1 and 2 as they appear on the wire. (and
the entirety of all future messages are integrity protected, so all fields
in all messages are integrity protected.) The advantage of the
IKEv2 approach is that it captures all relevant fields in the messages
including
any extensions like vendor IDs. It's also easier to specify, since the SIG
above will have to specify exactly how the bits are encoded for signing
(TLV vs raw; payloads with or without headers, etc).

           --Charlie

This footnote confirms that either (1) this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including computer
viruses, (2) this email message was sent by a virus that appends this
footnote, or (3) (most likely) the sender of this message is trying to
raise awareness of how foolish it would be to place any confidence in
footnotes like this.
Follow-Ups: