[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