I am not sure if you have understood the purpose of a PAG correctly.
The PAG is _not_ meant as a session key management system. By its very
nature it is a kernel mechanism used to convey the authentication identity
of a process context -- our target is to allow an incoming system call to
have an authentication tag when it reaches a "handler" of some kind.
The precise key management should be left to the agent receiving the PAG,
in _our_ case the Coda cache manager. Multiple session keys etc should be
under its control, and a user with a PAG will still be able to control
her/his keys.
I do agree with you that proper management of switching keys etc should be
present and that using a PAG for it, by naively logging in again is not a
good way to do it. However, there is absolutely no need to handle
multiple keys in that way.
- Peter -
>
> ---------- Forwarded message ----------
> Date: 19 Feb 1998 19:21:27 -0500
> From: Marc Horowitz <marc@cygnus.com>
> To: Robert Watson <robert@cyrus.watson.org>
> Cc: Darren Reed <avalon@coombs.anu.edu.au>, linux-kernel@vger.rutgers.edu,
> tytso@mit.edu, yale-pag-project <david.caputo@yale.edu>,
> john.hartman@yale.edu, matthew.hiller@yale.edu,
> Michael Callahan <mjc@stelias.com>
> Subject: Re: PROPOSAL: Process Authentication Groups (PAGs) (fwd)
>
> IMHO, PAGs are a poor model for what you are trying to do. I
> understand the idea here, but I believe they are flawed in a few ways.
> First, I like that with kerberos or ssh, the user can choose which of
> the available ticket files/agents/whatever to use. I often switch
> between kerberos tickets in a single shell. Retyping the password
> each time would be inconvenient, at best. If there is no way to truly
> "set" the PAG, but only to create a new PAG, then substantial
> functionality which I used on a daily basis is lost. Second, I don't
> believe the kernel is the right place to store this data. Certainly,
> the kernel may need access to it, but this is inherently user data,
> not system data. Kernel storage makes certain useful techniques, such
> as credential forwarding or smartcards, difficult. I'd rather not see
> smartcard interaction code in my kernel.
>
> Feel free to forward this to other appropriate forums.
>
> Marc
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu