[16780] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: Kernel subset design issues

daemon@ATHENA.MIT.EDU (Nico Williams)
Tue Apr 26 04:39:15 2011

MIME-Version: 1.0
In-Reply-To: <tsl7hahqva1.fsf@mit.edu>
Date: Tue, 26 Apr 2011 03:39:05 -0500
Message-ID: <BANLkTimSU7Z5uiXZYo0RoYoxBdV_x8Q95Q@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Sam Hartman <hartmans@mit.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit

On Tue, Apr 26, 2011 at 3:19 AM, Sam Hartman <hartmans@mit.edu> wrote:>    Nico> I never understood why we need to distinguish between>    Nico> "exported sec context" and "exported lucid sec context",>    Nico> except as a way to avoid cleaning up the existing sec context>    Nico> export/import functions...  Here's your chance to make that>    Nico> distinction go away.>> At the time we didn't want to standardize  our export token format.>> In the lucid structure, the userspace code is responsible for making the> exported context right for what the kernel supports.> If we standardize something we'd need to standardize something> extensible and  the kernel would need to skip parts of it.>> Here, note that by standardize I mean write down, not something within> the IETF.
So you thought that the exported security context token format wasunstable, likely to be unstable, and at that too unstable tocoordinate with the one kernel-mode consumer that existed?
Well, whatever.  It is what it is.  But now is a good chance toactually change the exported context token format into something thatwould do.
Nico--
_______________________________________________krbdev mailing list             krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post