[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The remaining IKEv2 issues



On Tue, 19 Aug 2003, Yoav Nir wrote:

> Hi Tylor,
>
> The reason we can't make doing this a MUST NOT is that the IKEv2
> document is designed to be used by implementors, not administrators and
> definitely not users.  We can say "GTC is OK" or "MUST NOT use GTC".
> We can even say "GTC MUST NOT be used unless the passwords are local to
> the VPN endpoint".  We can't mandate user behavior like "you can't use
> the GTC server for IKE if you can also do GTC over unencrypted PPTP or
> over unauthenticated PEAP".  We can definitely not say "you should only
> authenticate with GTC if you verify the server's certificate correctly
> in PEAP"

This is all under the assumption that the IKEv2 server is talking to the
AAA server using EAP (GTC or otherwise).  The point I was trying to make is
that it seems that we are trying to force a requirement based on one
potential implementation choice for using non-kg EAP methods.  We needed a
mechanism to transmit user credentials in IKEv2; EAP was chosen.  This
doesn't mean that EAP must be used by the IKEv2 gateway to communicate with
a AAA server.  EAP-GTC in IKEv2 seems like a generic method for performing
various forms of auth, fulfilling customer requirements to allow non-kg to
be used.  If this method is not secure _WITHIN THE IKEv2 PROTOCOL_ (e.g.
susceptable to MITM or other attacks), then I would agree that it MUST NOT
be used.  If it is not secure outside of the IKEv2 protocol, then I think
it is really up to the vendors to choose whether or not to use it.... at
that point it is really outside the scope of IKEv2.

> In short, you can mandate things about IKE, but not about other users
> of the legacy authentication.  It would be up to the implementor to
> tell the user not to use insecure methods, perhaps by displaying a
> warning message in the GUI.  For the RFC, it's either in or out.
>
> On Tuesday, August 19, 2003, at 04:17 PM, Tylor Allison wrote:
>
> > So the MITM attack on non-kg methods is possible for EAP messages being
> > transmitted outside of IKEv2 (e.g. not between IPsec peers), and occurs
> > because either the EAP messages are being passed in the clear, or the
> > server in a protected EAP protocol (e.g. PEAP) is not being
> > authenticated
> > properly.
> >
> > Why not make doing this a MUST NOT?  Aren't there many ways to make
> > non-kg
> > EAP methods protected from MITM?  How about:

Tylor