[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-ike-ext-meth-01.txt
On 4 Jul 99 at 6:11, Tero Kivinen wrote:
> > 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
That's what I'm talking about. ISAKMP defines packet format, so its
version must reflect only this. IKE (or any other KE protocol)
defines how the information contained in that packet is to be used.
IKE should't redefine packet format - when such needs arise it must
be done within ISAKMP spec. If IKE redefines the way information is
used, it must be accompanied by new KE protocol ID (Transform ID
within ISAKMP). If that new IKE requires some particular packet
format (e.g. ISAKMP version), it must be reflected in its spec and
implementations must reject proposals with that Transform ID and
lower ISAKMP version. Apart from that IKE versions (encoded in
Transform ID) and ISAKMP versions (encoded in ISAKMP header) are
independent from each other.
> > 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.
Currently only aggressive exchange might not allow to do that. All
the others defined in RFC2408 allow that.
> 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.
Yes, but KE protocol is currently encoded not in Proposal ID (that,
right, must be only one within SA payload and must be equal
PROTO_ISAKMP), but in Transform ID. It is absolutely legal to have
multiple transforms with (possibly) different IDs within that single
proposal payload. Currently only KEY_IKE is defined, but things might
change in future. So, my question is still here - what ISAKMP version
will mean in that case? I'd prefer it won't be tied with IKE in any
case...
> > > 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.
Doesn't this complicates processing a lot? Sometimes you allow
different versions, sometimes - not. What are the reasons for mixing
versions in phase 1 and 2? I'd prefer that once we negotiate some
version in the very first contact (phase 1), we continue using it.
> 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.
Yes, because it's the real IKE issue - how keys are being determined.
> 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 think it would be valuable.
> 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/
Regards,
Valery.
Follow-Ups:
References: