[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Secure legacy authentication for IKEv2
After seeing the SLA proposal I want to propose the (controversial
and not necessarily popular) idea that this mechanism is separated
to a different document. If possible I would also move the configuration
mechanism defined in Dukes document to be part of that separate document
whose subject would be "standarized support of remote user authentication
for IKEv2". (If there are significant applications of the configuration
mechanisms in more general situations than remote user access then one
may want to leave the configuration mechanisms as part of the basic IKEv2).
The reason for the separation (at least of SLA) are:
(1) the mechanisms add very significant complexity to the basic IKEv2 document
(complexity in terms of specifications, understanding, evaluation,
analysis, implementation and testing). This is particularly true with SLA
which (as I pointed out in a previous note) changes the basic IKEv2
exchange significantly (both its logic and processing).
(2) While there is a clear market demand for user legacy authentication support
in IKE it is not clear at all that all applications of IKE will require
such support. Thus, it is not clear that this mode (and all its inherent
complexity) needs to be mandated for all IKEv2 implementations.
Moreover, I can envision that many (future) implementations, even
if mandated to support legacy authentication, will opt to prevent
its use completely (this mode of authentication may easily become
the weakest link in the protocol).
(3) Separating SLA (and maybe config) into a separate document has does
not jeopardize standardization. There is no reason not to advance both
documents (IKEv2 and remote-access concurrently). The remote user
standard will be implemented by those that care about it. Since today's
ipsec market is dominated by VPN then we will see that most (probably
all) vendors that offer general implementations of ipsec/ike (and, in
particular, VPN) will include the remote access capability.
The advantage of developing IKEv2 and remote access together is that
this joint development may point out to extensibility mechanisms
that IKEv2 may need to provide in order for SLA to be able to support remote
access. But this does not mean that the added mechanisms need to
be part of the basic IKE (v2).
Just to illustrate the problems of making SLA part of IKEv2 let me point out to
an argument against using EAP in the context of SLA that was given in a
previous message. It was claimed that adding EAP to SLA would
require all implementations of IKE to implement EAP. But then why should ALL
implementation of IKE be required to implement all the remote-access
and legacy-authentication payloads and the sepcial authentication mode??
If, in contrast, SLA implementation would be required only for
those providing remote user access, then implementing EAP would be
a natural thing to require given that EAP is today's most general
IETF-standarized mechanissm for transporting user (and legacy) authentication
information.
Bottom line: I suggest to
(a) separate SLA to another document;
(b) develop IKEv2 and SLA at the same time (i.e. now);
(c) advance the separate documents for standardization concurrently;
(d) do NOT make SLA a mandatory mode of IKEv2.
Hugo