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

Re: legacy authentication support



Michael Richardson wrote:
>     Uri> I don't find that suggestion practical enough to justify following it
>     Uri> now. The TODAY's reality is -  non-PK auth systems are wide-spread and
>     Uri> are NOT going away. Not to support it natively simply complicates both
>     Uri> the protocol and the implementations.
> 
>   If you had said this in 1996, I'd have bought this line of thought.
> 
> EVERY SINGLE legacy auth vendor has some set of web CGIs that let you
> authenticate web pages. An authenticated POST operation is just a couple
> of lines in some scripting language. Even VirusBuilder could do it.

I don't know what you mean by "legacy auth VENDOR". All I know
is that legacy auth SYSTEMS AS DEPLOYED NOW do NOT do that Web 
CGI. For example, try Lucent, AT&T, IBM. 

I saw the system that you described - but it's (a) rather unreliable
[I myself helped one person to get through - that's how I know of it],
and (b) NOT widely deployed - just exists. Oh, and (c) - it's even more
pain in the butt than the "normal" say, SecureID card.



>   I'm saying that RSA should be MUST, and should be the interop algorithm.
>   If there is shared secret, make it MAY.

I agree with RSA-MUST. I require shared-secret MUST also.
 
>     Uri> This was not just a patent issue!!  Practically all the remote access
>     Uri> is based on some kind of non-PK approach.
> 
> Well, the only legacy systems that can directly use shared-secret instead
> of are time based systems like SecurID. All of the X9.9 stuff (which I've
> done lots of work with in various guises) is challenge/response based.

Yeah - so...?   It usually *is* either time-based or
challenge-response...

> {It also uses 1DES}

(:-)


> 
>     Uri> Technically it is simpler to support non-PK natively, than to have TWO
>     Uri> interoperable protocols - one to retrieve the "credentials" and the
>     Uri> other one to actually use them (and then to worry to scramble those
>     Uri> retrieved credentials - lest somebody else "borrows" 'em later on)...
> 
> Debugging two simple protocols is a lot easier than debugging one
> complicated protocol.

1. They both aren't THAT simple.
2. Debugging COOPERATION of "simple" protocols suddenly stops beg
simple.
3. Now you need to deploy/administer/etc two (at least :-) protocols.
4. There's no point in it tobegin with, as the extra complexity of
non-PK
   is nil cryptographically, and close to nil implementation-wise (and
if
   you consider that if you don't put it in this protocol, it will have
to
   be put in in some other more complicated shape or form - I don't see
the
   arguing point).

>     >> We MUST define the ASCII format of the raw RSA keys, and mandate
>     >> that they be loadable to the trusted store.
> 
>     Uri> What if there is no trusted store?  Look outside your concept box.
> 
>   Then I guess you'll get a blank screen when you turn stuff on :-)

Thank you so much! (:-)

> I understand that you mean that all authentication is provided by the
> user on a detached device. No GSM cell phone has this problem, no iPAQ
> or PDA. I doubt that even water meters will have this problem.

It's worse than just a "detached" device - it may be a public device.
It may be a device with (a) no secure store worth of talking about, (b)
not
owned by the user...

And again, the complexity of doing it the proposed way is nil. The whole
argument is pure political. Why are we debating it?!
-- 
Regards,
Uri-David
-=-=-<>-=-=-
<Disclaimer>