RE: Authentication Mechanism Matrix (was L2TP vs IPSEC)

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

On Wed, 21 Jun 2000, CHINNA N.R. PELLACURU wrote:

> On Thu, 22 Jun 2000, David Jablon wrote:
> 
> > Some banter on what kind of authentication method can handle a
> > small legacy-style shared secret password ...
> > 
> > At 04:44 PM 6/21/00 -0700, CHINNA N.R. PELLACURU wrote:
> > > [IKE (?)] 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).
> > 
> > Guess again.  My secret is "HRW#54".  That's all I can remember.
> > I dare you to show me how to use IKE securely with this as the secret key.
> 
> 
> HOW?! It is simple, however any good password based system would protect
> such a low entropy secret, to the maximum possible extent. And however
> that is done, can be done without any change to the IKE protocol. If you
> still feel that this is not possible, then I can give you the gory
> details.
> 

I think the basic point is that whatever security a protocol like PIC can
acheive, with a low entropy "human memorisable password", can be achieved
within the scope of the current IKE standard. Obviously, we can't acheive
more than what is cryptographically possible, with a low entropy password.

If your secret is "HRW#54", then the amount of security you can achieve
using a protocol like PIC, can be achieved within the context of IKE as it
exists today, and thus there is no real value to having anohter protocol
like PIC.

    chinna

> 
> > 
> > ... then a diversion into smart-card-enabled kiosks ...
> > 
> > CHINNA:
> > >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 [...] and I 
> > >can verify the signature, and thus make sure that there are no trojan
> > >software in there. ... 
> > 
> > David:
> > Amusing, but still irrelevant.
> > 
> > How do you get the SHA-1 hash of the software?
> > Were you thinking of just asking the software to hand it over?
> > What if it hands you the signed hash that was computed before the BIG
> > EVIL PATCH?  As you should guess, I'm not looking for an answer.
> 
> You can't achive prefect security in anything without sacrificing an awful
> amount of functionality, and resources. You can build a system that is
> extremely restricted, and perfectly secure in this scenario. The way it is
> dealt with in real life is by compensating reasonable security that could
> be tampered with(with very less propability), by grave consequenses.
> Everybody knows that the encryption used in cell phones is not very
> secure, but how many acutally exploit it.
> 
> I guess you are looking for perfect security. None of the security
> protocols/primitives that are widely used, have provable security, and so,
> do you say that they are not perfect, and hence useless?!
> 
> > 
> > ... and finally, a "definition" ...
> > 
> > David:
> > >> 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. :-)
> > 
> > CHINNA:
> > >And so what is your cryptographic definition of "user authentication" Vs
> > >"machine authentication". I don't think you have provided any.
> > 
> > Fine.  Here's my formal definition:
> > 
> > 	User authentication needs a secret.
> > 	Machines can remember big ones,
> > 	but people can't.
> > 	Deal with it.
> > 
> > OK, so it's not formal, and not exactly Haiku, but it gets to the point.
> > 
> 
> And this is the formal cryptographic definition?! I hope it is your own,
> not accepted academically. Do you have any reference even vaguely hinting
> in this direction.
> 
>     chinna
> 
> 
> > ---------------------------------------------------
> > David P. Jablon
> > Integrity Sciences, Inc.
> > dpj@xxxxxxxxxxxxxxxxxxxxx
> > www.IntegritySciences.com
> > 
> > 
> 
> chinna narasimha reddy pellacuru
> s/w engineer
> 
> 

chinna narasimha reddy pellacuru
s/w engineer