[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)