Re: The remaining IKEv2 issues

[Charlie_Kaufman@notesdev.ibm.com]

Michael Richardson <mcr@sandelman.ottawa.on.ca> wrote on 08/19/2003
10:58:08 AM:
>   If we accept non-kg EAP methods, then we must make a strong statement
to
> the effect that the credentials MUST not be used to authenticate to
parties
> of differing trust.
>   I.e. maybe it is okay for the corporate "extranet" web server to use
the
> employees EAP credentials to form an IPsec tunnel to the employee's
desktop
> to retrieve that file. It just isn't okay for company A's web server to
> use credentials from company B for things they weren't intended for.
(noting
> that B's web server must already have some radius-like relationship with
A's
> authentication server in order to perform the legitimate authentication)

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.

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.

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

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