Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

Distributed Authentication Schemes

By jonnyfantastik in Technology
Wed Jul 18, 2001 at 05:39:47 PM EST
Tags: Internet (all tags)

A quick and dirty analysis of the future of the Internet platform, .NET, and distributed authentication. This is in form of an email sent to Dave Winer of DaveNet. What I'm looking for is information. What do people think of one-stop authentication like passport.com? Do people realize what's really at stake? And where are the people in the community out there doing work on it?

Dear Dave,

As I'm sure you are well aware, .NET represents a blatant attempt by Microsoft to move its dominance from the desktop to the Internet. While MS cannot stress enough that .NET is an "open standard," anybody familiar with Microsoft's history concerning standards should know that Microsoft will do anything and everything to assure that only it reaps the massive profit potential of a .NET like system. The FSF and Ximian seem to have recognized the incredible threat of .NET but have responded foolishly by attempting to simply copy the system. This might not be such a mistake if .NET was not riddled with technical flaws. Nobody completely understands Web Services and the gigantic ramifications of moving data (XML documents) as opposed to code. Microsoft's attempt to build a complete Internet platform with corresponding object model and garbage collection, etc, is a land grab, plain and simple.

That being said I was extremely excited to see your July 17th column at davenet.userland.com. Right now there is little need for an Internet platform, but there is an extreme demand for a decentralized authentication scheme. After carefully reading your article and reviewing the XMLStorageSystem spec I'd like to offer a few suggestions.

1. Do not assume that there is a human at the keyboard. This is one of the core principals of the Unix Philosophy: avoid captive user interfaces (those interfaces that require human input). If services like eBay and the many online brokerage systems had not designed their interfaces so that human input was required, the entire need for Web Services today would not exist. To maximize convenience for the user, the user should be able to authenticate a computer or an account on a computer. Once the user has authenticated a computer, that computer should be able to stand-in for the user at any place in the authentication chain. What this means is that it is very important exactly how you retrieve login information such as username and password from the user and the URI to an authentication server. The obvious solution is to give the user the option of storing login information in an XML document with a standard interface at some location on her computer. The problem is, how do you retrieve that XML document? One solution is to let the user run a specialized webserver that serves up XML documents. When given the URI 'xml:http:///personal/login' the server might respond with the XML document containing the user's authentication information.

Of course, this is not a complete solution because it would allow anybody with a browser to view your login information. Therefore some redundant authentication scheme must be built in. Using digital certificate technology this would require that the machine requesting the special URI on the user's personal webserver present a digital certificate which the user has cached and validated herself. If such a system were employed this would allow for maximum flexibility. For example, let us take the canonical example of a user who wants to retrieve his calendar information for a given week. When the user is on the road the user might use a client website to do this. He would present the website with a username, password, and an authentication server. The client website would contact the login server, running a system very much like xmlStorageSystem, and ask for the XML document containing the user's calendar information. The user would then edit the information and save it. But, when the user is at home synching a wireless device she should be able to press a button on the device and forget about it. The device should then be able to do exactly what the client website did - contact the login server, authenticate itself, and retrieve the Calendar XML document - with one key difference. Because the wireless device is connecting from the user's home computer it should be able to retrieve the locally stored XML document containing the user's login name, password, and the address of the authentication server.

The above is a somewhat trivial example. To understand the real need for allowing passive authentication (as opposed to active authentication where the user must be at the keyboard to type in a login name, password, and the URI of an login server), you must peek farther ahead into the future. As time progresses, users will want full automation of many of the trivial tasks they must accomplish. For example, if somebody goes shopping every Friday to purchase the same exact thing, there is no reason that their computer should not be able to do this for them during the night by connecting to a HomeRuns.com like website and placing the delivery order. The user should not even have to think about this, let alone type in a password. Another very important aspect is the inevitable rise of agent-software. Agent software, as you might know, is just intelligent software that does stuff for you without you explicitly telling it to. It is much like the idea of a personal secretary. Consider the following scenario. The user has a toothache but he does not have the time to make an appointment with the dentist. For two weeks in a row, he instructs his computer to purchase oral pain-relief gel. At this point, his local Health Agent might contact the computers of his dentist and request an appointment for him. The dentist office eventually contacts the user to confirm the appointment and the user, pleasantly surprised because this is the first time he's hearing about the appointment, agrees. This example is not far fetched. It may be a while before we see interoperability on this scale, but all of the technology exists today or will exist soon. This is why we must not make the assumption that it is always the user authentication herself and not some trusted device.

(In addition to increasing convience, this technology does open up a whole new can of worms. One could imagine a naive user making his laptop a trusted device without securing it. Then, if that laptop is stolen, in addition to getting a nice piece of hardware, the theif has complete access to the user's identity. But that's the way technology works and these problems can be solved by technology.)

2. Do not assume that the user will store all of his information on a single server and maintain a single identity. This should be obvious, but many Internet authentication schemes (such as .NET) assume the user will only want to place all of their information at one site (passport.com). For what should be obvious reasons, this is a bad idea. Many people need or desire the ability to maintain multiple identities. This is evident from the fact that many people have multiple email addresses. You do not want the email address you use to register at a disreputable website to be your email address at work where recieving certain kinds of email can resolve in disciplinary action. As you wisely note, it must be very easy for a user to migrate his personal information from one login server to another, but it must be equally easy for the user to rely on multiple login servers so he is not locked into a single server. Some believe that giving users the ability to create multiple identities and even fake identities is irresponsible but these are often the people who have a vested interest in potentially violating the user's privacy. Users must have the option of not only separating work from home, but if they feel they require it, they should be able to create wholly fake identities. The anonymity of the Internet should be preserved at all costs even if it means inconveniencing the user. This means when a service requires that the user authenticate herself it must not simply ask for a name and a password it must also ask for the address of the authentication server the user wants to use.

3. Not all clients can be trusted. Everybody seems to be making the assumption that once we have a distributed authentication scheme then all authentication problems will magically go away. In fact, all that will happen is that authentication will become more difficult and more complex. The reason for this is that not all clients can be trusted. For example, return to the earlier situation where a user wants to create an account on another website or use a service on a website. Ideally, the user should be able to simply type in a login name, a password, and an authentication server. The website should then contact the authentication server and attempt to retrieve the user's personal information. Unfortunately, there are two very weak links in this chain. First, there is the website/client program. The possibility of a hostile website is very real. For example, a website hosted by a user's employer offering the user the ability to edit/retrieve his health information online may decide to forward that information to his employers. This occurs without the user explicitly allowing the website to transfer this information. Or consider the worst case scenario: a website offering the user access to his financial information may be a pure front-end. Once the user types in his name and password the website appears to offer the user the ability to buy and sell stocks but in reality it is stealing large amounts of money.

In order to protect against these two technologies, authentication servers will have to offer coarse grained access to the user's personal information through permissions. This means if a calendaring website contacts the authentication server and attempts to retrieve the user's health records then something is wrong. There is no need to retrieve a user's blood pressure and his todo-list. In order to retrieve certain ultra-sensitive information the authentication must allow the user to trust only specific websites and clients. By the simple fact that the user typed in his password is not enough display of trust, the user must explicitly tell the authentication server that a certain client can retrieve certain information. But even this is not enough, because the user might still be tricked into unwittingly granting a criminal client strong permissions. The ultimate solution is to establish a network of trust and a powerful system of trust-metrics, literally measuring trust. When a user grants a certain client, be it a website, a software program, or a device or even an IP address, permission to receive certain information the authentication server must be able to go to a trusted authority and ask that trusted authority if the client can be trusted with these permissions. For example, the user may give his new Palm Pilot permission to view his todo-list and calendar data. When this occurs the user might type in the serial number of his new Palm. At this point the authentication server must do everything possible to verify that this serial number is a Palm Pilot, is the Palm Pilot the user purchased, and is a Palm Pilot that can be trusted with this information. In this case the authentication server would most likely contact Palm Inc. and ask them to verify all of this information. In this case, Palm Inc. would be the trusted authority.

When it comes to security, too much is never enough. A distributed authentication scheme would be a welcome and powerful tool guranteed to increase human productivity even if it means we spend less time typing in redudant information like our address and credit card number. But a distributed authentication scheme does not solve the security problem, it merely makes things more complex. Even with a complex system using trusted authorities and trust metrics, questions still arise. How does the authentication server know that a trusted authority can indeed be trusted? Even if a trusted authority is run by a national government, it cannot be completely trusted. Furthermore, what happens if the authentication server itself is compromised? What happens if a client is compromised? Even if the chain between a user, a client program, an authentication server, and a trusted authority is completely secure, what happens when the user's physical access point has been compromised? If you are using a computer in an Internet Cafe and logging onto clients that require a name, password, and authentication server URI in order to offer their complete services to you, how do you know you are not 1. being filmed 2. having your keypresses recorded? What if the user is threatened with physical violence and forced to relinquish this information? I offer all of these "What ifs" to drive home a point: NOTHING AND NOBODY CAN BE TRUSTED. Not the user, not the authentication server, not even the trusted authority. Everybody and everything can and will be compromised by a determined and intelligent criminal.

Even if it is impossible to build a completely secure distributed authentication scheme, that does not mean it should not be done. The fact is, it will be done because there is a demand for it to happen. This demand will arise because it offers powerful productivity enhancements such as the potential of agent-based software and its offers of great convenience. But, as always, if you don't want to end up living in a world where you have absolutely no control over your private information then now, as we attempt to build these systems, we must tread very very carefully and be aware of the implications of what we're doing. I do firmly believe that the problems technology causes can be solved by technology.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o DaveNet
o July 17th column
o davenet.us erland.com
o Also by jonnyfantastik

Display: Sort:
Distributed Authentication Schemes | 13 comments (11 topical, 2 editorial, 0 hidden)
AAAAAHH! My EYES! (3.50 / 4) (#3)
by Hubris Boy on Wed Jul 18, 2001 at 05:42:23 PM EST

A couple of thoughts:
  1. You might want to try explaining who Dave Winer is, and why we should care what he thinks about distributed authentication.
  2. Creative use of basic HTML text-formatting tags would make this a LOT easier
      to read

automation (2.33 / 3) (#4)
by kubalaa on Wed Jul 18, 2001 at 06:33:22 PM EST

I think your idea for automating authentication by querying the user's computer is ridiculous. Something must be sent to the computer to tell it to ask the user for the authentication; the computer is capable of recognizing this message, even if it's in HTML, and responding accordingly. That's essentially what IE's smart form-filling is.

HTML not good for this (none / 0) (#11)
by Steeltoe on Sun Jul 22, 2001 at 02:56:46 PM EST

HTML-source change over time. HTML includes a lot of redundant tags not suited for data-transmissions or automation. Smart form-filling can be seen as a huge client-side security hole in IE.

He didn't say authentication should happen on the user's computer, but on a trusted third party server they can agree on. He also pointed out that you can never make it 100% secure.

- Steeltoe
Explore the Art of Living

[ Parent ]
The protocol work has already been done - but (3.80 / 5) (#5)
by pjc50 on Wed Jul 18, 2001 at 06:37:37 PM EST

...if it's not supported by IE, it's not going to happen.

Kerberos exists. It works. You can use it on a LAN to cross-authenticate between UNIX and Windows systems. It's pretty secure, although a correctly-implemented Wide-Mouthed Frog protocol would be both simpler and more secure.

The problems in a distributed authentication system are:
- Why use it? -> needs a killer app
- Who uses it? -> "early adopters" or Joe Average?
- User experience? -> MUST be as transparent and simple as possible. Preferably simpler.
- How does the software get installed?

The last is where Microsoft have an enourmous lead. They can install any software they like on people's systems regularly.

People thinking about this stuff MUST look at Kerberos before considering homebrew hackery ...

Problems with kerberos (3.00 / 1) (#8)
by treetops on Fri Jul 20, 2001 at 06:06:21 PM EST

Because Microsoft didn't fully implement the Kerberos spec, we have a lot of work ahead of us for real authentication in the distributed .NET/UNIX environment.

Does anyone know of an open source project that needs a Kerberos architect?
[ Parent ]

Huh? (none / 0) (#10)
by Xenophon Fenderson, the Carbon(d)ated on Sun Jul 22, 2001 at 10:56:50 AM EST

Would you clarify your statement? I have had zero interoperability problems (over four different platforms and two different Krb5 clients), so I'd love to know where Microsoft hasn't implemented the complete protocol. I do know that they hacked a reserved field to add authorization data, but aside from that, where are they not standard?

Rev. Dr. Xenophon Fenderson, the Carbon(d)ated, KSC, mhm21x16, and the Patron Saint of All Things Plastic fnord
I'm proud of my Northern Tibetian heritage!
[ Parent ]
Kerberos has more issues than that... (none / 0) (#12)
by Slothrop on Mon Jul 23, 2001 at 01:14:51 AM EST

I really think that if Kerberos was a good solution for internet authentication, then it would be used. It has many problems, first and foremost, scalability. It's secure, but it isn't great. This isn't a solved problem at all. But then, I've never even seen a proposed spec for one of these systems that I felt was really good and workable, so I'm not the best person to ask.
Provide, provide!
[ Parent ]
OT: I forget who said this .. (none / 0) (#13)
by painelf on Thu Jul 26, 2001 at 06:20:32 AM EST

"Make things as simple as possible, but not simpler."

[ Parent ]
Nice writeup (3.00 / 2) (#6)
by mcherm on Thu Jul 19, 2001 at 08:53:38 AM EST

It's long, but it's a nice writeup with careful consideration of several important issues.

I particularly value the comments you make about the importance of PERMITTING multiple identities.

-- Michael Chermside

identd? (2.66 / 3) (#7)
by dlc on Thu Jul 19, 2001 at 01:24:57 PM EST

This sounds suspiciously like a user-oriented version of the Identification Protocol (RFC 1413; see, e.g., http://rfc1413.x42.com/), but imlpemented using one of the groovy new faddish protocols.

The Identification Protocol (a.k.a., "ident", a.k.a., "the Ident Protocol") provides a means to determine the identity of a user of a particular TCP connection. Given a TCP port number pair, it returns a character string which identifies the owner of that connection on the server's system.
The Identification Protocol was formerly called the Authentication Server Protocol. It has been renamed to better reflect its function. This document is a product of the TCP Client Identity Protocol Working Group of the Internet Engineering Task Force (IETF).


It is wrong always, everywhere and for everyone, to believe anything upon insufficient evidence.
W. K. Clifford

identd/auth (4.50 / 2) (#9)
by fluffy grue on Sat Jul 21, 2001 at 08:31:26 PM EST

auth is hardly a secure protocol. Anyone can spoof it in any way they like. These days it's so meaningless I have no idea why any servers even bother to use it.
"Is not a quine" is not a quine.
I have a master's degree in science!

[ Hug Your Trikuare ]
[ Parent ]

Distributed Authentication Schemes | 13 comments (11 topical, 2 editorial, 0 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!