Re: [Auth]some more thoughts

[Keith Geffert]

On 17 Jul 2001 09:37:53 -0700, Jeremy Petzold wrote:
> I think that that is the general direction the project is 
> taking, however, I belive that it will turn into somthing that anyone
> could build and run, minus the Auth servers, I don't see how you could
> have an auth server that is run by the guy trying to get access, but >
> the databank can be run on a homegrown server or a leased space from a
> web host, then the person just needs to register with the Auth system
> so that he can start tuse his information. as long as the auth system
> and the Data system are seperate we can retain the freedom of the > >
> people who use it, passport bundles both the auth and Databank servers
> together and that is where the lack of freedom is.


I could see in the future where that "guy" could be trusted and what I
was proposing itself doesn't preculde that extension from happening.

I do think the virutal identity server will have to be linked to the
auth server in such a way that keeps it in the same zone of trust. I
would also hope we compartmentalize the system to the exent that the
acutal data stores can be behind a firewall and even on a private
network.  Thereby making it that much more difficult to breach security.

As far as freedom and passport.  I think you made an understatement.


> 
> On Tue, 17 July 2001, Keith Geffert wrote:
> 
> > 
> > Hello all,
> > 
> > I know were trying to minimize this kind of banter, but I haven't gotten my 
> > 1.252 cents in yet.
> > 
> > 
> > My thoughts on dotGNU
> > 
> > 
> > I've been reading all the comments and suggestions from the list and have 
> > formulated some of my own ideas that I think should be discussed.
> > 
> > 1)  Basic dotGNU auth system should be as small as possible.  Why?  So that 
> > it is suitable to be implemented on small devices: Pda's, cell phones, and 
> > other things that haven't been introduced into the consumer market that 
> > will eventually be connected to the internet.  You may not be shopping from 
> > your cell phone, but I could imagine a dotGNU address book that you may 
> > want to access from your phone.  You could also "surf" wap sites with your 
> > cell based websystem (cellphone/webpad) and have access to all the 
> > compliment of sites you have access with your primary device.
> > 
> > 2)  Hooks for various authentication systems like a password secret, smart 
> > card, digital certificates, and biometrics.  This allows a user to have 
> > multiple ways of accessing their profile(s) from various devices with 
> > varying degrees of access.  You may need a strong cert to update your 
> > credit card info, or give a website access to your credit card info, but 
> > only a password for your email address.  This should also be configurable 
> > by the user.  The user gets to choose how strong of an authentication is 
> > required for various items in thier profile(s).
> > 
> > 3)  After reading all the arguments back and forth, I think storing your 
> > profile on a 24/7 connection is the best choice for a few basic reasons.
> >   a)  providing info from a client system requires a trust relationship to 
> > be built from the client to the dotGNU application your trying to give info 
> > to.
> > 
> >   b)  Having your virtual identitie(s) stored on a service provider allows 
> > you to give permission to sites to have access to information.  They now do 
> > not need to that information (indefinitely).  They merely need to store the 
> > pointer to your profile (and cache the actual data to increase optimization 
> > -- which actually could happen in the dotGNU api).
> > 
> >   c)  Using (b) above, if you change information in your profile it changes 
> > for everyone that has rights to view that information.
> > 
> >   d)  As an extention, an address book could be created in your profile as 
> > well as bookmarks/hotlists.  These merely being pointers to the acutal 
> > URI's (don't know if that's the right term).
> > 
> >   e) Small devices could use a technique like (d) to give you access to 
> > your stored address book. This would obliterate the need to syncronize or 
> > download your local database to devices that may not have enough storage 
> > space to hold it anyway.  The devices uses only the parts that it would 
> > need.
> > 
> >   f)  Transferring your profile from device to device becomes irrelevant.  
> > You could use a system at say the public library to authenticate to your 
> > dotGNU service provider and have access to the same information as you 
> > would have your primary system.
> > 
> > 4)  LDAP might be a good choice for storing profiles.  Using some type of 
> > trustee relationship on each property and value could be used to proivde 
> > much granularity, while providing security to your personal information.  
> > If you don't want your data mined, make sure your not giving any rigts to 
> > the world.  Trustee's would have a TTL. Allowing you to give certain 
> > systems access to information for only a short while.  You can then revoke 
> > these rights as you see fit.
> > 
> > 5) Authentication might be accomplished using something simliar to how dns 
> > is now constructed.
> > 
> >      root trust ring
> >             +
> > +-----------+---------------+
> > |   |   |   |   |   |   |   |   -- registered auth servers
> > A   A   A   A   A   A   A   A      (probably every isp)
> > 
> > 
> > All root servers trust each other.  Each contain a DB of the authoritative 
> > servers for different partitions of the internet.  Any auth server will 
> > eventually trust any ohter auth server because they both trust the root 
> > trust ring, and that ring trusts each server indivually. (using PKI)
> > 
> > Auth servers can "trust" other servers to auth sections of its own slice.  
> > 10.0.0.42 is a trusted auth server, which serves (*.mydomain.com.).  It can 
> > trust 207.174.32.15 to serve (*.somegroup.mydomain.com.) by configuration.  
> > Every dotGNU device would require access to a trusted auth server.
> > 
> > We then do mutual authentication via pki.  I trust the webserver because my 
> > dotGNU app was able to verify the identity of the service running on a 
> > particular server.  The webserver trusts me because I provided it with 
> > credentials that were verified by my auth server (the 3rd party).  The 
> > webserver passed these off to its auth server which eventually says Yes or 
> > no.  The auth servers do a tree walk until the correct server can be 
> > located that stores your profile.
> > 
> > For quick dirty and simple?  All this is compacted to a single server. Auth 
> > servers can manage as many slices as needed.
> > 
> > 
> > 
> > My thoughts,
> > 
> > No matter what direction is taken, we need to remember what we do today, if 
> > successful, will probably be the basis for most identity verfication on the 
> > internet.  This system will have to last and be flexible enough to handle 
> > the innovations in auth technology for years to come.  Once the true auth 
> > system is implemented it will be very difficult to make radical changes.  
> > We all need to keep that in mind.
> > 
> > I could see this becomming a basis for any type of identity authentication, 
> > and eventually be embedded into our basic communication protocols (dotGNU 
> > enabled ftp, smtp, pop3, imap).  Allowing the authentication token to 
> > passed in the TCP syn packet for services that require identity 
> > verification before your even allowed to initiate a TCP session ( imagine 
> > tcp wrappers with this ability ).
> > 
> > As far as legacy services (those converting to .something or not even 
> > .something enabled) this could be handled by the basic service that it 
> > provides.  Http forms might require a small XML document (inline or 
> > pointer) that describes the form fields and how they relate to dotGNU 
> > profile properties.  Your dotGNU enabled app could then properly fill in 
> > the form.
> > 
> > Anyway I've written out everything I got so far.
> > 
> > Thanks...
> > 
> > 
> > --
> > Keith Geffert
> > http://www.penguingurus.com/
> > GnuPG Public Key: 
> > http://www.penguingurus.com/public_key.txt
> 
> Regards,
> 
> Jeremy
> Find the best deals on the web at AltaVista Shopping!
> http://www.shopping.altavista.com
> _______________________________________________
> Auth mailing list
> address@hidden
> http://dotgnu.org/mailman/listinfo/auth
--
Keith Geffert
http://www.penguingurus.com/
GnuPG Public Key: 
http://www.penguingurus.com/public_key.txt

pgpjH4Z3_F10y.pgp
Description: PGP signature