[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