On Sun, 30 Dec 2001 kpneal@pobox.com wrote:

> On Sun, Dec 30, 2001 at 01:51:54PM -0800, Bill Studenmund wrote:
> > On Sat, 29 Dec 2001 kpneal@pobox.com wrote:
> Um, what data would be needed? How much can be hidden in a library?

We hide all of it in libraries now, so I expect we will be able to hide
all of it in the future. :-)

I'm going to shuffle around your resposne some..

> The API for clients would be in a library I'm sure. It would be a lot
> easier if a statically linked program could be brought up to current
> authentication methods by simply relinking.

Uhm, the point of this exersize is so that you don't have to link things
to get access to new methods. :-)

> To authenticate a user you would need some of these things:
> 1) username
> 2) password
> 3) some form of domain or other name
> 4) ???
>
> In return applications could get back:
> 1) valid/invalid, expired password, expired account, etc etc.
> 2) other data, like being instructed to set an environmental variable to
>    some specific value.
> 3) perhaps an opaque cookie
> 4) ???

The ??? are the sticking point. The problem is that we fundamentally don't
know now what will be needed. And not all sites will need all the things
we can think of now. So if we add in support for everything we can think
of, we are bloating everyone. But if we don't, someone looses.

That's why we want to do things with dynamic linking.

Dynamic linking means that company X can produce security dongle Y and
auth module Y.so, and ship it. A customer can follow the simple HOW_TO and
install it (put Y.so somewhere sane, tell nsswitch how to find it, and set
which lookups use it).

> Also useful would be a way to destroy any cached authentication data,
> like when a user logs out. Perhaps an opaque cookie would be useful
> here.
>
> What other data would be necessary? That's a serious question. Or,
> is there a way to put other data into a format that can be handed
> back to applications without them having to have too-specific knowledge
> of that data?

And a serious answer is that we don't know. :-) For instance, if we do AFS
authentication, we have to put the tokens (kerberos tickets essentially)
in the kernel. That's a system call. Do we really want to build a protocol
that accepts commands to fire off random system calls in the client
process environment, with opaque systemcall arguements? I don't. :-)

[snip]

> (Secret hidden desire of mine: I don't like having Kerberos tickets
> sitting around in /tmp. I'd rather they be someplace inaccessible
> to an attacker.)

<subject change>

Funny you should mention that one. :-) I don't like it either. I'd love it
if we did something like AFS's tokens. Shove the tickets in the kernel.
Then when a process is inherited, it gains a reference to the parent's
ticket stash. If you want your tickets, you ask the kernel, and it gives
them to you. If you want someone else's tickets, the kernel tells you no.
Even if you're root.

</subject change>

Take care,

Bill