[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: combining SA proposals in IKE [was: Some questions]
> -----Original Message-----
> From: D. Hugh Redelmeier [SMTP:hugh@mimosa.com]
> Sent: Sunday, May 17, 1998 11:19 AM
> To: ipsec@tis.com
> Subject: 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)?
[Sumit] The order in which the proposal payloads appear in an
ISAKMP exchange does not determin the order in which the resulting SAs are
applied to data packets.
The Security Architecture document describes the acceptable AH and
ESP combinations. Section 4.5 describes the MUST to support combinations.
Besides, if AH and ESP are negotiated together as a single protection suite,
always apply ESP first, then AH. For example, in tunnel mode, with both AH
and ESP in use, the order should be
IP(outer) AH ESP IP(inner).
IP(outer) ESP AH IP(inner) is not going to work since AH covers the
outer IP header also.
>
> [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?
[Sumit] If one SA in a protection suite times out, you cannot
simply re-negotiate that one SA because the protection suite must always be
negotiated as a whole and not in parts. However, the other SAs are still
valid. What you do with them is an implementation detail. Maybe you want
to receive data on them till they timout, but start sending on the new SAs,
or maybe you want to send out deletes for the older SAs, etc.
> 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.
[Sumit] I'm not sure I understand what you're trying to say, but if
someone wants to come up with a new ESP transform draft, they are perfectly
free to do so. The IETF is an open forum. Anyone can propose their ideas.
If you are asking whether a proposal payload in a phase 2 exchange
can have multiple transform payloads, the answer is absolutely. See the
example in section 7.2 of IKE. The proposal payload there has two transform
payloads.
> ================
>
> 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.
[Sumit] I couldn't find the reference in IKE, but yes, you are
correct. Multiple sets of SAs can be negotiated during quick mode to allow
for fast re-keying, and to reduce the number of roundtrips per SA. Except
for the SPIs, the SA payloads (and the various proposal and transform
payloads within the SA payload) must be identical. So you will end up with
identical SAs but different SPIs and hence keys. Once you get a set of
inbound and outbound SAs, pick one SA to send packets on. It won't matter
which one. The packets that you receive will have enough information on
them (SPI, protocol, dest. addr) to allow you to find the proper inbound SA.
> 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.
[Sumit] The Id payload ordering restriction is that if the payloads
are present, there must be two of them, and they must contain the Ids of the
parties for which the phase 2 SA is being negotiated, and the order of the
Ids must be the Id on the initiator side followed by the Id on the responder
side.
It isn't written down anwhere, but going by the diagram there, it
seems that all SA payloads must happen before any other payloads (except the
hash payload, ofcourse).
> 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?
[Sumit] First do a New group exchange. That will give you a
non-standard DH group. Then, use that group's Id in the phase 2 exchange.
> 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.
[Sumit] The group description is a data attribute and data
attributes always go inside of payloads. Hence the group description
attribute has to be present in every transform.
> ================
>
> 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?
[Sumit] That's an implementation issue. The SPI has local
significance only and it is upto the implementation to decide how it will
generate SPIs. Instead of starting at the same SPI value, maybe you want
your implementation to start with a value that depends on some local
parameters that are unique to each device. Maybe you want to use
pseudo-random SPIs. I don't think that the protocol should be changed to
ensure distinct SPIs. If you look at the definition of SPI in the Security
Association, all it says is that it is an opaque bit string that simply
enables the receiving system to find the correct SA to process the packet
with. It does not mention using the SPI in deriving keys or doing anything
else.
Sumit A. Vakil
VPNet Technologies, Inc.