[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: L2TP+IPsec and IKE authentication

My take is that it is important for the Corporation being accessed
whether or not the access device used is secure or not. A cybercafe
is not secure enough to access your corporate confidential secrets.
I also see certificates and smartcards being readily available in the near future.

The obvious result of this line of thinking is that you should be
able to use TWO CERTIFICATES per one IKE negotiation. Certificate A
is a user-certificate stored in a smartcard. Certificate B is a device
certificate stored on a device, and *not* on the smartcard.

Then based on the Corporation policy, either/both certificates A or B
would be demanded by the SGW. The effect of this is that the probability
of using an untrusted access device is less. This would not completely
prohibit it, because you can under proper conditions (depending
on the HW and stuff) steal either or both of the certificates and the private keys.

I see two ways to do this. You create a new IKE phase 1 mode that requires
two certificates by one side, maybe both sides (Yikes!?). Or you take the X-Auth draft
and put in there a possibility to use further certificate-based authentication.
I don't see how PPP/L2TP would be able to help in this scenario.

Ari

"Waters, Stephen" wrote:
> 
> My take on this is that secondary authentication is needed, be it at the PPP
> level, XAUTH or other (e.g. CRACK proposal) to allow for a 'challenge'.
> 
> If we relied solely on a device-loaded certificate or pre-shared secret to
> authenticate the user, that is not a 'secure' situation in the event of the
> device being 'borrowed'.
> 
> In time, when certificate smartcards and native laptop smartcard readers are
> readily available (smartcards that request a user challenge -
> pin/signature/biometrics), then we may be able to dispense with
> 'device+user' authentication.
> 
> On the up-side, having a root trust in a device, as well as a user of that
> device does provide extra security.  On the down-side, it is restrictive -
> e.g. connecting from shared/public equipment such as from a cyber cafe.
> 
> Steve.
> 
> -----Original Message-----
> From: Yael Dayan [ mailto:yael@radguard.com <mailto:yael@radguard.com> ]
> Sent: Wednesday, May 24, 2000 9:51 AM
> To: ipsra
> Cc: ipsec@lists.tislabs.com
> Subject: L2TP+IPsec and IKE authentication
> 
> It seems as though no one is paying attention to an issue that dominated
> these mailing lists in the not so far past, concerning the validity of
> the authentication procedure imposed by XAUTH.
> 
> L2TP+IPsec requires IKE. IKE is an authenticated key exchange and yet
> people clearly state that the user authentication will take place in the
> PPP authentication.
> This means one of these is true:
> 1. Users have certificates. In this case why do we need the PPP
> authentication?
> 2. Each user has a pre-shared secret with the SGW. Again, why do we need
> the PPP authentication?
> 3. The user does not authenticate to the SGW and Phase I, Phase II and
> IPsec traffic happen prior to authentication of the user. To support
> this, IKE requires changes and the architecture in "security
> architecture" becomes somewhat questionable.
> 
> Yael

-- 
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

F-Secure Corporation       http://www.F-Secure.com 

F-Secure products: Integrated Solutions for Enterprise Security
References: