Re: User-level Authentication Mechanisms for IPsec

[Roy Pereira <royp@xxxxxxxxx>]

> 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. 

I think we all need to take a deep breath and relax.  We are all here to
solve a specific problem and this kind of bashing isn't going to help us
come to a single standard solution.  Which is exactly what our task is. 
Take your personal feelings home and beat up your cat instead.

I would also like to point out that that IKECFG and XAUTH were never
brought out like you stated.  The history of this topic goes as such; 

1) During the Sep 97 (Ottawa) bakeoff, the problem of getting an
internal private IP address for a remote user came up.  IKECFG was the
result of conversations with several people.  It was published in Oct
1997 by TimeStep and Microsoft.

2) During the winter of 1997, the problem of supporting SecurID and
other existing authentication systems was brought up by several
customers to several vendors.  XAUTH was published in November 1997.  At
first it didn't use IKECFG, it modified phase 1.

3) Hybrid was first published in June 1998 mostly because XAUTH didn't
handle the case where only the gateway had a certificate.  

4) TimeStep, SSH, IRE, and Xedia came out with IKECFG support around the
spring/summer of 1998.  Others have followed including Cisco.

5) I'm not sure who has released XAUTH, but I think SSH, CheckPoint and
TimeStep may have.


Let's face it; we are all competitors here.  But we shouldn't confuse
competitive reasons for technical ones.  Just because a vendor released
a feature early based on some IETF work doesn't mean that they are
evil.  Its business!  But this is the IETF; so lets concentrate on
technology to solve our industry's remote access problems.



"Scott G. Kelly" wrote:
> 
> 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

-- 
Roy Pereira
Product Line Manager, VPN
Security Internet Services Unit
Cisco Systems