Protection suite response not included here... --- Tim Jenkins TimeStep Corporation tjenkins@timestep.com http://www.timestep.com (613) 599-3610 x4304 Fax: (613) 599-3617 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@Network-Alchemy.COM] > Sent: June 1, 1999 8:08 PM > To: Tim Jenkins > Cc: ipsec@lists.tislabs.com > Subject: Re: Comments on draft-ietf-ipsec-ike-01.txt (long) > > > On Tue, 01 Jun 1999 09:42:47 EDT you wrote > > > ... > > > 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? Based on questions I get, it's not clear enough. It also doesn't say anything about the deletion of both SAs, since that's part of IKE. Or is it??? > > > 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. > > This comment still stands, assuming a protection suite remains what I think it is. > > Other Comments > > ============== ... > > > 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? Well, it came to mind when I read the first paragraph in section 3.2. It looks to me like you're trying to clarify ISAKMP. If there's no new ISAKMP document, I'll take it in IKE. Otherwise, this and the paragraph in your draft should probably be in the new ISAKMP. > > > 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? > I understand what you're trying to do. However, my point is this: If it becomes part of the specification, then the specific cases where it should be done should be explicitly stated. You kind of make my point when you ask about the relative strength of different algorithms. And you weren't really spelling it out. You were saying that where you think the offer is stronger than your local policy requires, you should accept it. Charles Kunzinger's points are very good ones on this issue, also. If we can't make explicit non-debatable rules about this behaviour, we shouldn't specify it all. Here's a couple attempts at spelling it out (in part that illustrate the problems): When a proposal contains the same encryption algorithm as local policy requires, but differs only in the length, the proposal SHOULD be accepted if the offered key length is greater than that required by local policy. For the purposes of this rule, the DES series of algorithms are considered to have key lengths (from smaller to longer): DES40, DES, DESX, 2DES, 3DES (Is that even correct?) When a proposal contains a different group than that required by local policy, the proposal SHOULD be accepted if the offered group is stronger than that required by local policy. The strength of the currently defined groups (from weakest to strongest) is: Group 1, Group 2, .... (and it might get slippery here...) You know, the more I think about this, the less I like it. Also on this issue, I still don't understand why I would reject a proposal that proposes a longer lifetime than I allow, because I think you're adding that. If my policy says max 1 hour, and you propose 2 hours and I accept, why is there a problem as long I use my own lifetime and delete the SA after 1 hour? To you it looks like it expired prematurely. Even if you don't delete it and I do, is there still exposure? ... > > Dan. > Tim
Unrecognized Data: application/ms-tnef