[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on ISAKMP/Oakley
Naganand,
Conversation guide:
>>> and > == Naganand Doraswamy
>> == Mark Schneider
>>>
>>> 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.
Ok.
>>>
>>> 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.
Now that I've had more time to think about this and have been (gently)
reminded about the purpose of a *basic* proposal format, I don't think
it should be changed. The basic proposal format provides the foundation
from which other proposal formats can be derived. So, ESP and AH and ISAKMP
proposals are derived from the basic format and happen to include transform
ids. It's possible in the future (for possibly other protocols) that the
things we're negotiating don't have transform ids.
>>> 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?
I really blew this one! Section A.7.4 is intended to describe the
confidentiality and authentication mechanisms that are internal to ISAKMP
and used to provide security *in* Phase I to protect Phase II negotiations.
So, its intended to describe the mechanisms that ISAKMP uses to protect
ISAKMP-ISAKMP communications. My loose use of terminology concerning ESP
transforms is also a problem. I didn't intend to imply that we are letting
IPsec handle Phase I confidentiality. All I'm saying is we can leverage
off the work done for IPsec ESP and use the algorithms defined there in
ISAKMP. Yes, I understand that the ESP transforms are tied to processing
IP packets and adding an ESP header. We'll have to define how to apply the
algorithms in ISAKMP.
So, then the keys are obtained in the Phase I negotiation by using the
Oakley key exchange. It is not until after the key exchange that
confidentiality can be provided. I hope this is a little clearer.
You raise some interesting points regarding Modifying SAs. Since I'm leaving
early today :) I hope you don't mind if I address these issues next week.
Regards,
Mark Schneider