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

Re: Comments on ISAKMP/Oakley




>> 
>>    Where is "Multiple Precision Integer" specified?
>>
>
>  It's defined in draft-ietf-ipsec-oakley-01.txt, Appendix D.
>

For completeness, I suggest that you atleast mention where to look for the
definition of multiple precision integer, or just add it in appendix in the
draft.

>> 
>> A.7.1 The basic proposal format does has the following fields defined in the
>> header:
>>    - Proposal #, Proposal Len, Protocol # and Attribute TLV's
>>    However, the ESP, AH, and ISAKMP proposals have defined the 
>>    Transforms ID's and a reserved field. Shouldnt the basic proposal 
>>    format take care of this as well?
>
>  Yes.  I guess we intended that the TLV could be used for the Transform
>  ID. Granted, that would take 8 octets.  Are you suggesting adding a
>  Transform ID field to the Proposal #, Proposal Len, and Protocol #
>  fields?  If so, how do you think this should be done?  Reducing the
>  size of the Protocol # field?  Your thoughts are appreciated.
>> 

I think we could reduce the protocol field size to one octet. Almost all the
protocols I have seen have only one octet allocated for protocol ID and I
feel it is safe to allocate one byte and use the other octet for transform
ID, unless other people feel strongly against this.

>> A.7.4. Proposal Formats, ISAKMP: ???
>> 
>
>Section A.7.4. is intended to describe the confidentiality and authentication
>mechanisms that are internal to ISAKMP and used to provide Phase I security.
>Confidentiality will be provided by applying the IPsec ESP transform(s) to
>ISAKMP messages. Authentication can also use IPsec AH transforms, only if
>keys have been preplaced. This means we have to determine a public key
>mechanism for authentication.  We're working on this.
>
> 
How does one obtain the keys for ESP transform on Phase I ISAKMP messages?
Is it an out of band mechanism or are the keys derived based on some public
key mechanism?
 


>  We see ISAKMP as a framework that permits negotiation of many security
>  features, including the key exchange mechanism.  The exchange types
>  defined by the ISAKMP/Oakley resolution draft all have a defined key
>  exchange.  In this case the key exchange is not negotiable. To support
>  negotiation of key exchange mechanisms, the three exchange types defined
>  in ISAKMP are *required*.  If they didn't exist, then it would be  
>  impossible to negotiatiate key exchange mechanisms.
>
>  Actually, upon looking closer at the ISAKMP exchanges and Oakley exchanges,
>  a generalization of the Oakley modes can be made in the ISAKMP draft. Since,
>  as you note below, Oakley Main Mode is equivalent to ISAKMP's ID Protect
>  exchange, then it seems that Oakley Aggressive, Quick, and New Group
>  modes (maybe) can be generalized to ISAKMP Aggressive, Quick, and SA Only
>  exchanges. The proposal could then include Oakley as the key exchange
>  mechanism along with the specific Oakley group that should be used. 
>  Thoughts on this??
>
>
This will help a lot as the number of protocol formats one needs to
implement will be fewer. Also, as ISAKMP is a general mechanism, as it is
already doing, there should be more protocol exhance modes defined so that
it can support various key exchange mechanisms. That is the reason why I
like the idea of trying to fit Oakley key exchange mechanisms within the
available ISAKMP modes rahter than defining new modes for the basic modes.
This way we a new key exchange mechanism is added we dont end up adding
another "n" xchg types to the ISAKMP headers and we may soon run out of
these 4 bits!

I have a few questions on Modify payload.

- How does one send a Modify payload. Do I use the reserved XCHG to send
this message? Is so, dont I need some kind of verfication? The same argument
is true even for the Delete payload.

- When I send a modify message do I create a new SPI or modify the
attributes of the existing SA? For example, say between two machines A and B
I have an SA established. On A I want B to use a different transform, then I
will send a Modify message to B with the SPI B was using to send secure
messages to A in the SPI field of the Modify payload. In addition to that I
will also send a SA payload. Does the auxillary SPI field in the SA payload
point to a new SPI or can I reuse the old one? If I reuse the old one, how
will I handle the packets that are sent from B to A in the window where the
Modify message that A sent has still not reached B and A has already modify
it's SA?

--Naganand
----------------------------------------------------------------
naganand@ftp.com
Tel #: (508)684-6743 (O)