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

Comments on draft-ietf-ipsec-ike-01.txt (long)



Dan and Dave,

Overall, I think it's a great improvement over RFC2409, and will go along
way in helping reduce confusion. However, I have a number of comments on
this document. 

There are three slightly larger concerns, and bunch of minor ones (mainly
typo corrections).

1) Use of the term "protection suite"

I am both concerned and confused by the use of the term "protection suite"
in this document. As it turns out, this term has been re-defined from that
in ISAKMP (RFC2408) to refer to only the services provided by a phase 1 SA.
(See section 3.1 of draft-ietf-ipsec-ike-01.txt.)

On this issue, what is the purpose of adding any new definition of these
services? If that is necessary, why change the existing definition of
protection suite? Why not find a term that won't result in ambiguity and
confusion.

To clarify the existing definition of "protection suite", see section 2.1 of
RFC2408:

   Protection Suite: A protection suite is a list of the security
   services that must be applied by various security protocols.  For
   example, a protection suite may consist of DES encryption in IP ESP,
   and keyed MD5 in IP AH. All of the protections in a suite must be
   treated as a single unit.  This is necessary because security
   services in different security protocols can have subtle
   interactions, and the effects of a suite must be analyzed and
   verified as a whole.

Also see the discussion in section 4.2 of RFC2408 and the example in section
4.2.1 of RFC2408. All of these quite clearly indicate that the term
"protection suite" applies to phase 2 SA establishment.

While I agree that it does not necessarily preclude phase 1 SA
establishment, I do not see the need to apply it to that case only, as
draft-ietf-ipsec-ike-01.txt appears to do.

Also, the use of the term "protection suite" is a very good way to refer to
a subset of SA bundles where the SAs in the bundle are negotiated using a
single SA payload. This allows them to be differentiated from SA bundles
that are negotiated by the effective recursion of policy to packets that are
IPSec processed.

As such, I think the use of "protection suite" in this document is confusing
and should be changed to align with RFC2408, or it should be removed
altogether.

2) Use of the term "state"

Normally, "state" implies a state machine. Obviously, there are state
machines involved in SA negotiation, especially since ISAKMP packets can
only be identified by context (after parsing cookies and message IDs).
However, this document uses the term "state" to describe the collection of
keying material values that are generated or created at SA negotiation.

Normally, I wouldn't be too concerned about the use of the term state,
however, it would have been nice if the states during SA negotiation had
been defined. This sentiment was stated to me by the co-author of the MIBs,
since he felt it would nice to put that in the MIBs. If that ever became
defined, then the meaning of the term state would be overloaded and
ambiguous. In any case, during development/testing of SA negotiators, one
might say "what state is it in" expecting a response of "it's in the
'proposals sent' state" yet get a response of "there isn't any state yet"...

Wouldn't a term like "keying material" or "calculation value" or some other
term than "state" be more appropriate?

3) Acknowledged Information Exchange

I'm glad to see this was added. The use of an acknowledged delete mechanism
will go a long way to improve SA management.

How does an implementation know when a peer supports this exchange? It seems
to me that instead of giving it its own exchange number, all that's been
done is the addition of a Nonce payload to the existing informational
exchange.

Is this a backwards compatibility attempt? For example, I send an
acknowledged delete three times and get no response (since the peer ignores
the nonce) and assume the peer doesn't understand, and from then on I use
the unacknowledged informational exchanges?

If this is the case, this should be spelled out in the document.

Also, it is noted in the security considerations section that "The
acknowledged Informational exchange is open to replay attacks." Is it any
more susceptible than the unacknowledged informational exchange? If not,
then a similar warning about the unacknowledged exchange should be added.

One question that seems to be asked a lot is what SPIs are specified in the
delete payload. Since IKE specifically creates two phase 2 SAs, it is
appropriate that it explicitly state that the delete payload contains the
SPI (and protocol) of the inbound SA of the sender, and that the receiver of
a delete should delete his outbound SA and his corresponding inbound SA
without sending a delete.

Further, for "protection suites" as defined by RFC2408, it should be stated
explicitly that the deletion of any one of the SAs in the suite means the
entire suite is being deleted.

Other Comments
==============

(Changes I would make related to the protection suite issue described above
are not added here.)

1) In section 2.4, the explanation of how cookies stay constant is better,
but still confusing. Specifically,
                                       "...cookie order does
   not swap even if the direction of the Phase 1 SA switches."
is confusing since a phase 1 SA is bi-directional once established. Perhaps
                                       "...cookie order does
   not swap even when the original responder initiates an
   exchange within the phase 1 SA."
or something like that would be clearer.

2) In section 3.2, I'd like to see an explicit statement (first paragraph)
that payload order within the SA payload may be changed by the responder. We
saw a lot of this at interoperability workshops when it came to protection
suite negotiation (IPCOMP and ESP and AH). Here, the proposal payloads that
had the same proposal number were frequently re-ordered by the responder.

3) Also in section 3.2, there are comments related to automatic range
selection of attributes. While I think this is a good idea under many
circumstances, I'm concerned that if this isn't explicitly spelled out where
it is possible, there will be problems.

For example, is SHA-1 considered stronger than MD5? Some papers suggest that
it is. So should I allow SHA if the peer proposes it but my local policy
says MD5? What if I have hardware acceleration for MD5 but not SHA? Then the
peers will start using more and more of my resources.

Similar examples could be made for Blowfish versus CAST, especially when key
sized can be specified. How does an implementation decide what is more
secure?

Bottom line: Where it's possible, if it's part of the standard, spell it
out. Otherwise leave it up to local policy to allow it or not.

4) Section 4.2, paragraph 2. Should "Phase 1 exchange" on the second line of
that paragraph not be "Phase 1 SA"?

5) Section 6.1, paragraph 3. Should "...and encapsulating them in the single
SA payload." not be "...and encapsulating them in the single proposal
payload."? Otherwise, there's a contradiction in that paragraph.

6) Section 6.2, paragraph 7 appears to be missing a word in the first line.

7) Section 6.2, paragraph 10, second line "send" should be "sent".

8) Section 6.4, paragraph 2, third line "the the" should be "to the".

9) Section 8, paragraph 4 describes identity PFS and states that the phase 1
SA should be deleted after generating the phase 2 SA. Would it not be
permissible to keep the phase 1 as long as it is used for management of
itself and the phase 2 SA it generated, such as sending deletes?

Tim

---
Tim Jenkins                       TimeStep Corporation
tjenkins@timestep.com          http://www.timestep.com
(613) 599-3610 x4304               Fax: (613) 599-3617

Unrecognized Data: application/ms-tnef


Follow-Ups: