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

Re: combining SA proposals in IKE [was: Some questions]

> It has been stated that there is no need to compose multiple ESP
> transforms.  The justification is that we believe that there are
> reasonable ESP choices that are computationally hard enough so that
> composing would just be overkill.  But we don't know if there are back
> doors or gross flaws in some of the transforms: by composing ESP
> transforms, we can be betting that at least one has no back door known
> to our adversaries.  A similar argument holds for authentication.  I
> think that this justifies allowing more compositions of transforms.

I don't know where that's been stated but it hasn't been in the IKE
draft. No justification for allowing more compositions of transforms is
necessary because there is nothing prohibiting them.

> There may be several SA Payloads, each negotiating a separate SA.  The
> rules for how they relate are not clear to me (I didn't even see
> them).  There is an expressed intent which might help one guess:
> multiple SAs can be the same in all ways except SPI; the extras can be
> kept in reserve for when the first expires.  I guess it is up to the
> sender of a packet to have a policy to choose amongst these SAs (a
> packet would only go through one, but which one?).  The receiver has
> no problem because the SPI set by the sender does the selection.

You seem to be mixing "how are they negotiated" with "how are they
used once they're negotiated". I don't know the answer to the 2nd.

> ==> How do multiple SAs negotiated in one exchange relate?

Multiple SA payloads when negotiated in phase 2 are not necessarily related.
The components of each SA payload-- proposals and their component transforms--
are all related-- are related but there is no relation between SA payloads
themselves. If ID and/or KE payloads are present they must apply to all
SA payloads (and all proposals or all SA payloads).

> If multiple SA Payloads occur, how are they matched up in the
> Initiator's and Responder's messages?  SPI won't work -- the
> Initiator's and Responder's SPI's need not match.  Are they presumed
> to be in the same order (I haven't noticed this as an ordering
> constraint)?  I think that this should be nailed down.

Yes, it's order. That should be nailed down better.

> Speaking of ordering constraints, the IKE draft (-07) says in 5.5
> "With the exception of HASH, SA, and the optional ID payloads, there
> are no payload ordering restrictions on Quick Mode."  I did not notice
> a constraint on ID Payloads, and I only noticed a restriction on "a
> (sic) SA Payload", not every SA Payload.

The constraint on ID payloads is that they must be passed as IDci followed
by IDcr. This is described in the document.

> There is another puzzling thing about IPsec Transform Payloads in
> Phase 2.  One attribute specifies an Oakley (i.e. ISAKMP) group for
> purposes of rekeying to achieve PFS.  I don't see how the full panoply
> of ISAKMP groups can be specified with this single attribute.  Since
> some feel that the canned groups provide too little entropy, I am
> concerned.  (All the more reason to get the new larger MODP accepted
> as a standard group.)
> 
> ==> How is a non-standard Oakley group specified for Phase 2 DH
>     exponentiation?

You have to do a New Group Mode to agree on that one attribute. 

> Every transform of every proposal of every SA in a Phase 2 message
> MUST specify the same group if a KE Payload is supplied (or all must
> not specify a group if there is no KE).  This feels like bad design.
> The group has nothing to do with the characteristics of the SA, so it
> should not be part of the SA Payload.  I realize that it is too late
> to change something like this.

On the contrary. Since the group is used to generate the key which is part 
of the SA I think it does have something to do with the SA. 

Not only is it too late, your change is bad design. If the group identifier 
was removed from the negotiated payloads how would you decide how to generate 
keys for the various negotiated SAs in the presence of a KE payload? In
what context would you take the KE payload?

I'm sorry you don't like the design but the alternative is worse.

> When testing our IKE daemon, I've noticed that the keying material is
> often the same in both directions.  This strikes me as unfortunate (it
> worries me, but I'm not absolutely sure that it matters).  The IKE
> document section 5.5 says that this won't happen because the keying
> material depends on the SPI number (it is part of the hash), and the
> two SPIs will be different.  Well, fresh copies of our daemon pick the
> same SPI number, so this logic doesn't work.

The logic works just fine, it's your daemon that doesn't work. KEYMAT is
dependant on the nonces as well as the SPI and protocol. If you're generating
identical KEYMAT for each direction that means that not only are the SPIs
identical, the nonces are too. That calls into question your whole pseudo-
random number generation. Are your Diffie-Hellman exponentials identical
as well? Do fresh copies of your daemon produce identical Diffie-Hellman
public values?

Given the important use of nonces in phase 1 authentication I'd be very
worried.

> Perhaps we should go to some trouble to ensure that these SPIs are
> distinct (or just probably distinct?).  Perhaps they should even have
> non-trivial Hamming distance (I don't imagine that this is needed, but
> I'm not a cryptographer).
> 
> I see nothing in the standards that specifies that SPIs should be
> unpredictable or different.  Is this a weakness of the standards?

I'm not so sure I see a need for requiring that the SPIs be unpredictable.
But I really see a need for the nonces to be. I guess the Security 
Considerations of IKE should strongly state this.

  Dan.
Follow-Ups: References: