RE: Authentication Mechanism Matrix (was L2TP vs IPSEC)

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

On Wed, 21 Jun 2000, David Jablon wrote:

> At 10:43 AM 6/21/00 -0700, CHINNA N.R. PELLACURU wrote:
> > ... 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.
> 
> No, IKE pre-shared was not designed to tolerate small legacy-style shared secrets.
> It's broken in that scenario.  Wasn't this discussed already?

It probably wasn't designed, but to make it secure in this scenario is
just a matter of implementation (IE. no change to bits on the wire).

> 
> > ... If the security provided by a password base[d] system is good enough for a
> > customer, then he can possibly use if forever. 
> 
> For applications where users don't care about security on the Internet,
> we don't have to do any work, since he'll have no problem using his old system
> without IPSRA or IPSEC.  Why talk about this case at all?
> 

That is my point. Why are we concerned about people who are using a very
insecure legacy authentication system, and trying to raise the bar for
them, by using PIC?


> > 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!
> 
> No.  Here the machine is trusted implicitly.  Any kiosk that I control
> (I'm a hypothetical evil entity) can abuse your card to secretly buy
> my Mom some flowers, in addition to completing your transaction.
> No crypto protocol helps here.  This problem is out of our scope.
> 

Let's assume that, before I stick my smartcard into the machine, I make
sure that all the software running on the machine is cryptographically
singed by the vendor (provided we can trust the vendor, or some third
party who we trust, has gone through the sources, and signed it), and I
can verify the signature, and thus make sure that there are no trojan
software in there. If I find a discrepancy, I can always walk across the
street to another cafe, that is hopefully better.

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

> You've paraphrased Hugo out of context.  "Cryptography" doesn't
> usually label the entities, but the acceptable size of an
> authentication key is a BIG concern. This is why we use one set of
> crypto methods for machine keys, and a more specialized set of methods
> to deal specifically with user-memorized passwords.

> 
> Public/private keys and IKE shared secret authentication work just fine
> with large secret keys.  But for passwords, you need to use either:
> 
> 	(1) an authenticated tunnel secured by *something else*,
> or
> 	(2) a zero-knowledge password method which tolerates small keys directly.
> 
> Or better still, use both. :-)

And so what is your cryptographic definition of "user authentication" Vs
"machine authentication". I don't think you have provided any.

    chinna

> 
> ---------------------------------------------------
> David P. Jablon
> Integrity Sciences, Inc.
> dpj@xxxxxxxxxxxxxxxxxxxxx
> www.IntegritySciences.com
> 
> 

chinna narasimha reddy pellacuru
s/w engineer