RE: Authentication Mechanism Matrix (was L2TP vs IPSEC)

["CHINNA N.R. PELLACURU" <pcn@xxxxxxxxx>]

On Wed, 21 Jun 2000, Hugo Krawczyk wrote:

> 
> 
> On Tue, 20 Jun 2000, CHINNA N.R. PELLACURU wrote:
> 
> [.....]
> 
> > 
> > I don't think there is any real cryptographic benefit of "bootstrapping"
> > IKE credentials (that are capable of several magnitudes stronger
> > cryptographic authentication) using legacy authentication. Bootstrapping a
> > cryptographically very very strong authentication using legacy
> > authencition is useless, because the weakest link in this system is still
> > the legacy authentication.
> 
> The benefit of "bootstrapping" IKE credentials using legacy authentication
> (which is the approach predicated by getcert and adopted by PIC)
> is that it provides the "glue" between legacy authentication and IKE,
> without changing the legacy authentication or IKE, and provides for the
> best possible deployment path for strong user-based credentials (such as 
> smart cards). Indeed, whoever upgrades his own system from legacy
> authentication to public-key cryptography just throws away the PIC code
> and goes ahead with pure IKE.

The best possible deployment path would be to use the legacy
authentication secret as the IKE pre-shared secret, and in this scheme,
the customer doesn't have to even write a new protocol, and then remove it
later on.

> 
> (As an aside note and in contrast to the above it seems to me that
> l2tp/ppp-based solutions create the "next generation legacy systems";
> we will hear in a few years "we already invested in l2tp so let's keep it
> even when it is less than the sub-optimal solution). 
> 

There is no such thing as perfect crypto. Even RSA and DSS or DH are not
mathematically provable to be secure. So, lets not say that if you do RSA
or DH then you are set forever, and you will never need to reconsider your
security. All these systems are based on problems that are beleived to be
hard, with our current understanding of the problem.

If the security provided by a password bases system is good enough for a
customer, then he can possibly use if forever. I don't think we have set a
high standard for all customer reagardless of their requirements. You
don't need a costly PKI based system to protect against say some service
that you charge to the customer in pennies.


> > 
> > And I don't think this scheme could provide "machine authentication"
> > because the credentials that would be used to do any kind of further
> > authentication is predicated on the "user authentication" that is done
> > first. So, it would still be "user authentication".
> 
> No. If I am roaming with my company's laptop I can do a PIC authentication
> in a way that the authentication server learns/verifies two things: the
> remote entity to whom I am talking is "user Hugo" working from 
> "machine Warrior".
> 


Yes, you tell the server that the machine is Warrior, but how will the
server authenticate the machine, and know that the machine is infact
Warrior, and not Dog.


> That is, you have both user authentication (e.g. via a password-based
> legacy authentication scheme ) and machine authentication (e.g. via a
> 1024-bit RSA signature key for which the authentication server knows the
> public verification key).
> 
> Hugo

OK, let me try another example, If I have a smartcard that has my key
pair, and my certificate, and I carry it around, and plug it into a
computer in an Internet Cafe, does that mean that now we are
authenticating the machine in the Internet Cafe!

If cryptograpy doesn't bother about "user" or "machine" there is no reason
why we even need to try and provide a cryptographic definition of "user
authentication" Vs "machine authentication"

    chinna


> 
> > 
> >     chinna
> > 
> > > 
> > > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > chinna narasimha reddy pellacuru
> > s/w engineer
> > 
> > 
> 
> 

chinna narasimha reddy pellacuru
s/w engineer