[Auth]Re: Auth digest, Vol 1 #38 - 7 msgs

[David E. Raccah]

Hello,

This is also my first listing on this list.  I looked at your Single Logon 
Proposal, and it looks great.  However, I have some issues, which with a bit of 
tweaking could be fixed.

Here are my issues:
1) Do not want to have a client software package on the client machine, as this 
will not allow me to do single logon when I am using a kiosk, library, or 
friend's machine.
2) Do not want to have my data stored locally, or with me via a disk.  Yes, 
your proposal stresses the fact that it does not care where the data is, but I 
do not want to think about it, rather I want it available to me no matter where 
I am, or what I am doing!

So what about this addition to your idea?
Instead of having some software on your machine that holds the password etc, 
why not have a server that holds that data for you?  The data on the server 
would be encrypted with you public key, and you would pass your username and 
private key to the server to un-encrypt your SIML file.  So the steps are the 
following:

(*NOTE* This step is extra, but I have no way around it, may need to think more 
about it) 

1) When you go to the first web site after starting your browser, click on the 
link "Login Using SIML" (This is the extra step that I cannot get around).

2) This will re-direct you to the data server using an SSL connection and 
prompt you with the authenticate login box.  This will be your username and 
private key.  

3) The data server will then authenticate you.

4) If you are successful, it will encrypt your SIML with your favorite 
website's public key and send it to your favorite web site, hashed with your 
session id.  Then you get redirected to your favorite website and from now on, 
you will never have to retype in your private key, until you close your broswer.

5) If you are not successful in your authentication, then you will be notified 
by your favorite web site.

Again from now as long as you have not closed your browser), you will only need 
to click on the "Logon Using SIML" link at your favorite web site and you will 
magically be entered into your favorite website.  Because behind the scene you 
are being redirected to the data server and the data server will ask your 
browser for that private key which it has in memory and it will repackage your 
SIML file encrypted with the next favorite web site's public key, so all is 
secure.  You the user see nothing after the first authentication except for 
some redirects and the fact that you must do the extra step of clicking on the 
"Use SIML Logon" link.

Note, this can be used when the user does not have the client installed, either 
because the user does not want the software, or because the user cannot install 
the software on this machine.

This way if the data server is attacked, the data would not be useful without 
your private key.  The data server would be managed by a private organization 
(like MIT's Public Key database), which would be funded by the web sites that 
want the users that have signed up for SIML access.  The price would be just 
enough to stay afloat, not to be profitable.

One more note, there is a way to use certificates when the certificate is not 
on the machine.  Verisign was working on accessing non-local certificates using 
chaining, need to look at where that is again.

David

Original Message
------------------
Fernando Ipar wrote:
> 
> This is my first post to the list, i've been meaning to ask this and now that 
> > the subject has been brought up i'll take the chance. How hard would it be 
> to
> implement the auth system using digital certificates along with username &
> password ?. I know pgp signatures can be used as an alternative, but i'm
> interested in using a PKI, giving any provider the ability to use it's users
> certificates for authentication (for it's own services and other dotgnu
> services).
> I have experience in financial institutions providing some services on the
> internet (account operations such as balances and transfers, credit card
> balance check, etc) and the use of digital certificates proved to be very
> usefull more than once (if you base your authentication solely on
> username/password, an internal leak could easly lead into a disaster, if you
> use digital certificates and your CA has reasonable levels of security it is
> much harder for any potential attacker to exploit your system).
> 
> I would like to hear other's opinion on this matter, i know this probably
> isn't an important issue for the first release but it could be taken into
> account in the desing anyway.
> 
> best regards,
> Fernando Ipar.

I agree, we should try and limit the complexity for a first
release.  Can you see how the current framework can be
extended to support your ideas?  If so, can you provide a
quick description. If not, how do we need to change the
framework to support your ideas.

Regards,
-- 
Albert Scherbinsky
Drop by at: http://members.home.net/alberts/

Convenient control of our personal information:
Single Login:
http://members.home.net/alberts/single.htm
Simple Interface Markup Language:
http://members.home.net/alberts/siml.htm
Personal Information Base XML
http://members.home.net/alberts/PIB.htm