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

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



On Tue, 01 Jun 1999 09:42:47 EDT you wrote
> 
> 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.)

The abstract of this draft explicitly says that where there are conflicts
it will be supreme. 

> 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.

I was under the impression that this was confusing people and hence decided
to spell out what the term means to IKE. If DES in ESP is a protection
suite what about the lifetime of the ESP offer? Is that part of the protection
suite as defined by RFC2408? That's not explicitly spelled out and people
asked me about it. I happen to agree with them. That text doesn't really
capture the meaning of the term and is open to interpretation.

> 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.

The DOI defines what IKE negotiates in phase 2. Would it be better if I
called a protection suite "an collection of attributes that are negotiated 
as a single unit"? And then said that during phase one the components of 
such a suite is <blahblahblah> and leave it up to a DOI to define the term 
if it so chooses?
 
> 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.

This is a slippery slope. If I now state that a protection suite is a
subset of a bundle of SAs then what sort of subset? 3 offers out of the
5 in the bundle? Is that a protection suite? And I don't think that's the
correct meaning. Even if all 3 of the five were ANDed together, it's still
3 protection suites. Perhaps you can come up with another term to describe
a subset of a bundle.

> 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.

RFC2408 is confusing and I was asked about it many times. I'm addressing
that issue. 

At the last bakeoff someone was passing a message ID in the SPI field of
an notify message. This was justified by noting that nothing expressly 
prohibits such behavior. When things reach this state I think we've gotta 
spell everything out in gory detail and RFC2408 doesn't to the job.

Does my suggested modification come closer to what you think it should say?

> 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.

It's "state" as in "IKE is a state-ful protocol as opposed to SKIP which
is a state-less protocol" (or so they said). And it's more than just
keying material.

> 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.

I think Kivinen answered this, right?

> 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.

OK, good point.

> 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.

RFC2408 says it's the "sending entity's SPI". Is that not clear?

> 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.

OK,

> 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.

OK, you want that in ISAKMP or in IKE?

> 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.

I was spelling it out. I'm not even going to touch the issue of whether
CAST is stronger-than, weaker-than, or equal-to blowfish. This text deals
with attributes whose values are variable not with different attributes. 
It specifically says this in the text.

Is blowfish with a 80 bit key "weaker than" blowfish with a 448 bit key?
Is group 1 "weaker than" group 5? Or to put it another way, is there any
reason to refuse to do blowfish with a 448 bit key if you would've proposed
80 had you initiated?

I'm attempting to codify the behavior of certain implementations. Some
people will not accept group 1 if they have group 2 configured but will
happily accept group 5. That seems to be correct behavior. Similarly for
variable length ciphers. If you're configured for 128 bit blowfish and
someone asks you if you want to do 448 bit blowfish do you refuse? If so
why? If not then where in the RFCs does it say that you can do this? 

> 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.

Yes, thanks for catching that.

> 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?

Good point. What do other people think? Just prevent it from generating
any other IPSec SAs or should it be deleted immediately?

  Dan.



References: