Re: The remaining IKEv2 issues

[Tylor Allison <allison@securecomputing.com>]

On Tue, 19 Aug 2003 Charlie_Kaufman@notesdev.ibm.com wrote:

> You can tell people not to write their PIN number on their ATM cards all you
> want. They will do it anyway.
>
> non-kg EAP methods are inherently weak. If they are used carefully, they may
> be acceptably safe in some environments, but users and administrators *will*
> screw it up.

As defined and used within IKEv2, these methods are secure, though, aren't
they?  (OK, not as secure as kg methods...) To mount the MITM attack on
IKEv2, you have to have the Initiator not verify the responder/gateway's
identity... that sounds like a broken client implementation.  There's been
quite a bit of discussion about using MITM attacks on the AAA server which
is listening for the EAP-GTC (or otherwise plaintext EAP messages) that
could occur between the IKEv2 server and the AAA server.  But this assumes
that EAP is being used to communicate with the AAA server... other
protocols may be used by the IKEv2 gateway instead.

Administrators can and will screw anything up... it's scary some of the
shared-secret policies or private key distribution methods I've seen
customers actually use.  The question is, is it reasonable to expect that a
security-aware administrator can setup a policy that will be secure?  Or
atleast are they no worse off then if they were setting up any other type
of policy (cert-based, pre-shared key, etc.)?

> 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.

> 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.

> The following warning already appears in the Security Considerations
> section:
>
> > When using an EAP authentication method that does not generate a shared
> > key for protecting a subsequent AUTH payload, certain man-in-the-middle
> > and server impersonation attacks are possible. Use of such methods should
> > be avoided where possible and where they are used, it is particularly
> > important that the initiator validate the responder's certificate before
> > initiating the EAP exchange.
>
> We could add a stronger warning. But is there really any point?
>
>       --Charlie

Tylor Allison