[16763] in Kerberos_V5_Development
Re: Fwd: Delegation and Moonshot
daemon@ATHENA.MIT.EDU (Tom Yu)
Wed Apr 6 16:11:25 2011
To: Nico Williams <nico@cryptonector.com>
From: Tom Yu <tlyu@mit.edu>
Date: Wed, 06 Apr 2011 15:42:16 -0400
In-Reply-To: <BANLkTimydoGFS+vwT7sPLxteY+FYbfJg=w@mail.gmail.com> (Nico
Williams's message of "Tue, 5 Apr 2011 13:58:11 -0500")
Message-ID: <ldvipurdv53.fsf@cathode-dark-space.mit.edu>
MIME-Version: 1.0
Cc: Luke Howard <lukeh@padl.com>, krbdev@mit.edu, g.w@hurderos.org
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Nico Williams <nico@cryptonector.com> writes:
> On Tue, Apr 5, 2011 at 1:44 PM, <g.w@hurderos.org> wrote:>> Very interesting work but I need to catch up a bit. I assume we as a>> community are no longer shouting down the thought of kerberos ticket>> mediated transmission of authorization information as the incarnation>> of evil....? :-)>>>> That seemed to be the case 8 years ago or so when we were working on>> the problem of identity linked service authorization assertions.>> Perhaps what you remember is Slashdot. The Kerberos community as I> joined it in 2001 didn't mind the use of Kerberos authz-data at all,> and I suspect it didn't mind it in 2000 either.
The specific situation where people disagreed with the originalMicrosoft Windows PAC (for "Windows NT 5" as some people referred toit back then) requires a large amount of context to understand, whichI won't try to convey here even if I believed I knew all the relevantfactors. I'll just say the objections were to the specifics, ratherthan to the idea of carrying of authorization information in tickets(which RFC 1510 had a designated place for, after all).
As originally envisioned, authorization data in a Kerberos ticketwould be used to convey restrictions that the services should apply tothe privileges that principal would normally have. (Thus, a ticketwith authorization data that a service does not understand must berefused by the service.) As I recall, the community eventuallydecided that it was OK to have authorization data that enhancedprivileges, provided that they were in an "if-relevant" container, forexample.
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
