Re: User-level Authentication Mechanisms for IPsec

["Scott G. Kelly" <skelly@xxxxxxxxxxxx>]

Ari Huttunen wrote:

<trimmed...>
 
> I fail to see why your draft would be needed if something like CRACK
> is being used. Could you enlighten me?
> 

I was hoping someone would ask that. Ultimately, this is a question
before the group, and I haven't fully decided yet myself. However, I've
given the matter some thought, and I'll share what I've come up with so
far. Before I go on, let me say that I think the crack proposal is
*vastly* superior to xauth, and in fact, I think crack is essentially
hybrid sans xauth. I'm not sure why the hybrid authors are so opposed to
this new proposal, and think a more expedient response might be to join
together with the crack authors to iron out the wrinkles. But that's
another argument.

Regarding why I think there might still be justification for the ULA
proposal, there are a few reasons. First, there is the question as to
whether this authentication should be within IKE at all, and I think
that is a valid question. Among other things, this seems to be a bit of
layering ugliness to me. User-level authentication is an application to
session layer activity, but IPsec is several layers removed. Pushing
this down below the transport layer has implications which should be
considered. As I said, I've just begun to really think about this, so
I'm giving my as yet incomplete thoughts here.

One of the issues I perceive pertains to flexibility. The ula draft
discusses the probability that such user authentication will continue to
be required even after PKIs are widely deployed. In such cases, a
machine may be authenticated by a certificate (in IKE), after which time
the user may authenticate (authorize?) for various levels of access to
different resources using password(s), token(s), and so on. This is not
currently possible with CRACK, unless the remote client negotiates
separate IKE/protocol SAs for each authentication level. Also,
reauthorization requires an IKE rekey. In contrast, the ULA mechanism
allows the user to be reauthenticated independently of IKE (through the
protocol SA) - while not to be overstated, this is an advantage.

Another of the issues pertains to complexity within IKE. While I think
Dan et al did a nice job of integrating the user authentication into
IKE, there remains the issue of how the credentials get into IKE to
begin with. Again, I don't want to overstate this API issue, but it adds
complexity to the key exchange process to some extent, and hence cannot
be ignored.

Another issue pertains to the need for a PKI transition, assuming that
we agree that such a need exists. I fear that placing this functionality
in IKE in this manner (i.e. where password-based authentication is *all*
that is required) will tend to encourage network admins to not migrate
to stronger, more appropriate technologies. I don't think this is what
we really want.

All that said, I think that a smooth transition requires a mechanism
like crack/hybrid, and the ula draft says as much. The draft discusses 3
steps in the transition, and in the first step, only the security
gateway has a certificate, and in this case, the only way the client may
take advantage of the server cert (and thereby avoid vulnerability to
MiM attack) is by using a hybrid scheme of some sort.  This presents a
bit of a quandary, in my view.

So to summarize, I think we all need to think about this and discuss it.
I'm not opposed to good solutions, but I am opposed to cobbling up vpn
market grabbers and then standardizing them. That's why I've squawked so
loud about xauth. Vpn and network security may be related, but they are
not the same thing. I think we should be very careful about modifying
security protocols to meet vpn requirements. 

Scott