[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
combining SA proposals in IKE [was: Some questions]
Valery Smyslov asked a question that is very timely for me. I'm
writing code to encode and decode IKE SA Payloads, and haven't yet
been able to figure out the semantics of combining Proposal Payloads
with the same proposal number.
At the end of this message, I'll quote the relevant parts of the
thread. I feel that my questions are still not resolved, so I'll ask
them here. This message was actually prepared before the thread
started. BTW, I fully expect that some of these answers are in the
drafts but that I've missed them or misunderstood them.
In Phase 2 / Quick Mode, IKE SA Payloads are for specifying IPsec SAs
(as opposed to ISAKMP SAs, which are the subject of Phase 1 / Main
Mode). Actually, Phase 2 can be used for DOIs other than IPsec, but
that does not concern me at the moment.
The SA Payload contains nested sub-payloads that are combined as
disjunctions and conjunctions:
An SA Payload contains Proposal Payloads. These are given
monotonically non-decreasing numbers. All proposals with the same
number are taken together ("AND"). Those with different numbers
are alternatives ("OR").
Within a Proposal Payload, Transform Payloads are taken as
alternatives.
I don't understand how the AND is to work. I understand that the
intent is to allow AH and ESP (and IPcomp?) to be combined. With
tunneling, more than just one of each can be combined. I don't see
any specification of the order of their combination. There are two
obvious ones (reflecting the order of their proposals), but any
permutation would not violate anything I've read.
(draft-ietf-ipsec-isakmp-09.txt section 4.2)
==> How are ANDed proposals to be composed (in the mathematical sense
of the word)?
[My code parses these things. I've gotten stuck trying to ascribe a
meaning (action) to what has been parsed.]
If ANDed proposals have different durations, what will happen? I
assume the SA becomes useless as soon as any of its components
expires. Is this right?
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.
================
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.
==> How do multiple SAs negotiated in one exchange relate?
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.
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.
I'm guessing that the multiple simultaneous proposal technique is the
only way to compose transforms. I don't think I should be guessing.
================
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?
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.
================
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.
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?
Partial answers, or even additional questions are welcome!
Hugh Redelmeier
hugh@mimosa.com voice: +1 416 482-8253
| From: "Valery Smyslov" <svan@elvis.ru>
| 2. Regarding previous question: when protection suite (e.g. sequence
| of SAs) is negotiated, what should be the order of appliance of those
| SAs when processing an outgoing packet? Should it be the same as the
| order in which their proposals appear in the ISAKMP SA Payload? It is
| very natural, but it seems that IPsec drafts doesn't state this
| explicitly.
| From: Daniel Harkins <dharkins@cisco.com>
| For situations where you negotiate AH and ESP you apply ESP first.
| Applying multiple AH or multiple ESP transforms to a single packet is not
| defined.
| From: "Valery Smyslov" <svan@elvis.ru>
| Well, let's imagine situation when responder receives SA payload that
| proposes protection suite containing AH and ESP both in transport
| mode in the order (I mean order of Proposal payloads) AH, ESP. What
| should it do? Should it reject this suite or accept it, but apply SAs
| in correct order: ESP, AH (assuming, that peer will do the same,
| because the other order is prohibited)?
|
| > Applying multiple AH or multiple ESP transforms to a single packet is not
| > defined.
|
| Sorry, but it is defined if you use tunnel mode (Architecture
| document, section 4.3, first case of iterated tunnelling), although
| marked as "unlikely to be used". But this case isn't prohibited.
| Moreover, the order of applying SAs (first ESP, then AH) is defined
| only for transport mode SA bundles (as far, as I understand). Tunnel
| mode SAs can be applied in any order, so, my second question is still
| valid
Follow-Ups:
References: