[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The remaining IKEv2 issues
At 10:15 AM -0500 8/20/03, Tylor Allison wrote:
>On Tue, 19 Aug 2003 Charlie_Kaufman@notesdev.ibm.com wrote:
> > If we want to insert warnings as to the dangers into the IKE
>spec, I'd rather
>> do it by referencing some other document, but if we could agree on text in
>> less than negative 3 months, I'd be happy with that too.
>
>I think the warning already present is sufficient.
Fully agree. When Bernard et. al.'s document comes out later, it will
apply to lots of protocols, not just IKEv2. We should not delay IKEv2
waiting for that document. We already explain the problem in the
Security Considerations section, which is the proper place to do so.
> > Our real choice is whether to say non-kg methods MUST NOT be used
>or not. If
>> we say they MUST NOT be used, people will implement them anyway
>>but they won't
>> get the same degree of interoperability testing at the bakeoffs. People want
>> to use SecureID cards and challenge response cards and they don't want to
>> depend on some future enhancements to those devices in order to make IPsec
>> work. There are no kg methods for generic challenge response cards
>>(though one
>> could invent them for specific challenge response cards).
>
>If we are expecting that people are going to implement these methods and
>customer are going to make use of these methods, I would much rather see a
>standards-based way of doing so, and have this method be tested at bakeoffs.
Fully agree. One of the main goals of IKEv2 was to avoid re-creating
the XAUTH fiasco. Saying "'MUST NOT' or 'SHOULD NOT' do the things
that your customers are demanding" is a really good way to cripple
IKEv2 deployment.
--Paul Hoffman, Director
--VPN Consortium