[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Auth]some more thoughts
Re: [Auth]some more thoughts
17 Jul 2001 14:03:51 -0400
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 22.214.171.124 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
> Find the best deals on the web at AltaVista Shopping!
> Auth mailing list
GnuPG Public Key:
Description: PGP signature