Re: Secure legacy authentication for IKEv2

[Hugo Krawczyk <hugo@ee.technion.ac.il>]

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