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

No Subject



Charlie, This is good news. So it seems that we are moving towards settling
for a 4-message protocol with built-in (non-optional) DOS protection.
This indeed seems like a sound design choice. In this case, we could be
down to two basic alternatives, the decision between which is primarily a
requirements decision to be made by the WG:

1. The WG decides that it wants a protocol that protects the initiator's
identity against active attacks (and is willing to pay the associated costs,
ie, extra sig and sending the responder's ID in the clear).
In this case JFK seems like a good choice.

2. The WG decides that it wants a protocol that protects the responder's ID
against active attacks (or that it doesnt care about ID protection against
active attacks one way or the other). In this case the protocol below seems
like a good choice. (Just to reiterate - this protocol is basically the
4-msg variant of SIGMA, as proposed by Hugo a few days ago, with the HMAC
being on the outside as done in IKEv2.)

This should make the decision in SLC a bit easier...

Ran


BTW, regarding the fields under the signatures. Both in JFK and in the
proposal below only the "cryptographically essential" fields were included.
Personally, I have no problem with including more fields under the
signature, if this helps implementation. Other people may feel differently
though.



> From Charlie_Kaufman@iris.com Fri Dec  7 10:34:06 2001
> 
> 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.
> 
> 
>