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

Re: draft-kivinen-ike-ext-meth-00.txt

Tero Kivinen writes:


>> Or, even worse, when ISAKMP SA contains multiple transforms with
>> different KE protocols in each? To which of them will you apply
>> minor version number?
>
>Can you give me example how that can be done? The SA payload contains
>only one DOI, so I think you have to use it for only one KE protocol
>at a time. So if you want to support multiple KE protocols you
>propably have to allocate DOI numbers for each of them, thus you can
>only use one of the in one negotiation. 

RFC2407explicitly states (section 4.4.2): 

   Within the ISAKMP and IPSEC DOI framework it is possible to define
   key establishment protocols other than IKE (Oakley).  Previous
   versions of this document defined types both for manual keying and
   for schemes based on use of a generic Key Distribution Center (KDC).
   These identifiers have been removed from the current document.

   The IPSEC DOI can still be extended later to include values for
   additional non-Oakley key establishment protocols for ISAKMP and
   IPSEC, such as Kerberos [RFC-1510] or the Group Key Management
   Protocol (GKMP) [RFC-2093].

So, I think, that while SA contains only one DOI, it's fully legal to include multiple
transforms with different Transform Identifiers (e.g. KE protocols for this DOI) in it. 

Of course, there could be some restrictions on combinations of proposed
KE protocols in one SA due to possible logical inconsistence of message,
especially in Aggressive mode (the same thing as we have with different
Auth methods in IKE, where negotiation is limited in Aggressive mode),
but, in general, nothing prevents from putting multiple KE protocols in one SA.
At least, I couldn't find any explicit prohibition in the RFCs.

>> I think that new IKE versions should be encoded as a totally new transform
>> identifiers. Now we have only KEY_IKE; when new version appear we will
>> have, say, KEY_IKE and KEY_IKE_v2.
>
>The problem is that if we redefine some fields in the generic payload
>structure (like adding the criticality flag) for IKE, then we cannot
>parse the SA payload to find out that transform identifier. But you

I think that redefining general payload structure is more of an ISAKMP's
issue, not IKE's. In my opinion ISAKMP defines a "syntax", while IKE
defines a "semantics" of KE process. In other words, nothing prevents
from using IKE with some other "syntax" (providing the same functionality as
ISAKMP), or from using ISAKMP with different "semantics" (another KE
protocol). Adding criticality flag, I think, belongs to a "syntax", it doesn't
change payload designation.

>are right in any case that, I should add something about that KEY_IKE
>transform number also in the draft. I completely forgot it...
>


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