draft-ietf-ipsec-ike-ext-meth-01.txt
Tero Kivinen <kivinen@ssh.fi> Sun, 04 July 1999 05:11 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA14157; Sat, 3 Jul 1999 22:11:14 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA02000 Sat, 3 Jul 1999 23:11:56 -0400 (EDT)
Date: Sun, 04 Jul 1999 06:11:44 +0300
Message-Id: <199907040311.GAA19614@torni.ssh.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: Tero Kivinen <kivinen@ssh.fi>
To: Valery Smyslov <svan@trustworks.com>
Cc: ipsec@lists.tislabs.com
Subject: draft-ietf-ipsec-ike-ext-meth-01.txt
In-Reply-To: <199906281236.QAA03140@relay1.trustworks.com>
References: <199906281236.QAA03140@relay1.trustworks.com>
X-Mailer: VM 6.34 under Emacs 19.34.2
Organization: SSH Communications Security Oy
X-Edit-Time: 53 min
X-Total-Time: 86 min
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
Valery Smyslov writes: > > 5. Order of Checking > > The order of checks performed for IKE datagram SHOULD be following: > This is true not only for IKE datagrams, but for generic ISAKMP datagram > also. So, the wording should probably be: True, but the document is more concerned about the IKE extensibility than ISAKMP. Also I am not sure if the text is at all acceptable when somebody defines other key exchange method than IKE, and it is very hard to think about that before you see the other protocol. After somebody does that, this document propably needs to be updated anyways... > > There are no separate major and minor version numbers for ISAKMP and > > IKE, so they both share one major/minor version number. Because the > > ISAKMP document describes the generic packet formats etc, changes in the > > ISAKMP part will propably cause major version number to be incremented. > > On the other hand changes in the IKE part propably will keep the generic > > packet formats intact, thus only minor version number might need to be > > incremented. > > Tero, I've been still under impression, that mixing IKE and ISAKMP > versions number is not a good thing. Let us leave ISAKMP major and > minor versions for changes in ISAKMP and encode future IKE versions > as new transform identifiers. Perhaps I should be more clear to say that every time we change minor or major version it is really ISAKMP modification not IKE modifications. The end effect is same, the ISAKMP version number is going to go up every time we make bigger changes to IKE. The document isolates the modifications which need changes to the version numbers (flags, new use of reserved, and maybe new payload types), and they are strictly speaking ISAKMP modifications not IKE modifications. > Otherwise we will have difficulties in > case an alternative KE protocol will be defined within ISAKMP > framework. What meaning shall minor ISAKMP number have in this case? It still defines the packet format of the system. Even if the IKE has added some flags or new use for reserved fields (the criticality flag for payloads) thus causing the new minor version number (== new ISAKMP version), it does not necessary mean that other KE protocols must use that version they can be using the old 1.0 version if the want to. If the other KE protocol also wants to modify the ISAKMP packet structure (lets say they want to add another flag), then they have to take the latests version of ISAKMP, including the changes done because of the IKE update and update from there. Note, that there is no changes in the will bump up the ISAKMP version number without the packet format also changing at the same time. > What meaning shall it have if two (or more) different KE protocols > (different transform identifiers) are proposed by initiator? Good question. Currently I don't think you can do it, because for example the KE payload etc might be completely different depending on the KE protocol. So you cannot really do that in general case. For some limeted use you might be able to do it, for example if you are using the main mode you could do it (only SA payload in the first payload), but unfortunately IKE rfc says that you can have only "single proposal payload in a single SA payload", so if you offer two proposal the other end is propably going to fail immediately. I didn't like that restriction when it was added, and I still dont like it, but it is there. > Moreover, by mixing ISAKMP minor version number with IKE version you > seem to contradict with section 5 of your own draft (order of > checking), because you require to check minor version number before > you even get know that it is really an IKE datagram, not general > ISAKMP datagram. So, you implicitly assume that all ISAKMP datagrams > are IKE datagrams, that is not true (at least in theory). Yes, you are right that, that order of checking applies also for generic ISAKMP packets, but it also applies to IKE packets... The document is still named "IKE Extensions Methods", because that is where the intrest of this document really is. In most cases where there is a string "IKE" you can change to to say "ISAKMP" and you still get things right. > > Phase 1 and phase 2 negotiations are separate negotiations. So phase 1 > > negotiation that creates ISAKMP SA may use version X, and phase 2 > > negotiation done over that ISAKMP SA may use version Y. > > I don't think this is right, especially with your intention to use > minor ISAKMP version number as IKE version number. Future IKE > versions may completely redefine internal cryptographic variables, > so mixing old and new versions may become problematic (consider the > situation when future IKE version will use not SKEYID, but, say, two > variables). I think that negotiated during phase 1 IKE and ISAKMP > versions must be used for all subsequent negotiations under this > ISAKMP SA. There might be limitiations in mixing the version numbers, but in general I would say they it should be allowed. If we redefine SKEYID in phase 1, then that SKEYID is used for later exchanges also, and in that case mixing the versions is not allowed. When somebody makes that kind of modification then they have to disallow that in their document. BTW changing the SKEYID doesn't cause minor number to updated, but that is just one of those limited things you can do by changing the transform id. > > There may be a need to add a criticality flag in the generic payload > > header in the next version of IKE [RFC-2409]. This allows an old version > I think this is probably an ISAKMP issue, not IKE's. > > 13. Reserved Fields > > Lots of payloads in the IKE contain RESERVED fields that are defined to > They are defined in ISAKMP, not in the IKE. Thats why this two cases are the only ones that requires the ISAKMP minor version number to be updated. The current document is written mostly from the IKE standpoint, and it quite often considers IKE and ISAKMP same. It could be quite easily to be exanded it to generic ISAKMP extension method documents, but then I would have to use more time think cases which are not relevant for IKE (which I am not sure if it is going to be that usefull, because I will propably get them all wrong...) I could update it for the next version so that I change almost all instances of "IKE" to "ISAKMP" and add still some more text about IKE transform id, and remove that one paragraph talking about ISAKMP and IKE version numbers. -- kivinen@iki.fi Work : +358-9-4354 3218 SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
- draft-ietf-ipsec-ike-ext-meth-01.txt Valery Smyslov
- draft-ietf-ipsec-ike-ext-meth-01.txt Tero Kivinen
- Re: draft-ietf-ipsec-ike-ext-meth-01.txt Valery Smyslov
- Re: draft-ietf-ipsec-ike-ext-meth-01.txt Tero Kivinen
- Re: draft-ietf-ipsec-ike-ext-meth-01.txt Valery Smyslov
- Re: draft-ietf-ipsec-ike-ext-meth-01.txt Tero Kivinen