[16759] in Kerberos_V5_Development
Re: Fwd: Delegation and Moonshot
daemon@ATHENA.MIT.EDU (Nico Williams)
Tue Apr 5 14:58:16 2011
MIME-Version: 1.0
In-Reply-To: <201104051844.p35Iifkq032067@wind.enjellic.com>
Date: Tue, 5 Apr 2011 13:58:11 -0500
Message-ID: <BANLkTimydoGFS+vwT7sPLxteY+FYbfJg=w@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: g.w@hurderos.org
Cc: Luke Howard <lukeh@padl.com>, krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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 Ijoined 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.
> There seemed to be a plethora of issues raised surrounding the> inability of anything in the ecosystem to handle kerberos tickets> which enclosed auth_data encoded payloads. If I remember correctly> the thought of loading any type of XML data as authorization> information was voiced as profoundly repugnant.
As a colleague just wrote to me, you could just shorten that last to"XML is repugnant" (mind you, I only think it is repugnant forencoding messages, not for documents, though I realize that thatdistinction can be quite subtle. However, it is too late for that.Or you might insist on using FastInfoSet. Whatever. The choice ofencoding is really not that important, and in this case gets dictatedby external issues that Luke et. al. have no control over.
> >From the last pair of quoted paragraphs above it would seem the KDC> will now be involved in what amounts to authorization policy> decisions. I'm assuming the KDC will simply issue a naked ticket if> any aspect of the assertion verification fails?
I don't agree (well, except in the case of credential delegation, butthat was already true anyways). The KDC doesn't make access controldecisions so much as enable the making of access control decisionsbased on ticket authz-data.
> We had the KDC involved in the authorization process and I distinctly> remember Sam Hartman's objection that this was a serious security> problem as it was the KDC's intrinsic duty to always issue a properly> formed ticket based only on the presentation of an authentication> credential. I noted with interest when I read all the Moonshot> documentation that Sam's Painless was engaged for Moonshot's> feasibility analysis.
See above.
> I found it interesting that we now have, potentially, a Shibboleth> server, an LDAP directory server, a radius server and a KDC involved> in the authorization decision process. It seems, as an industry, we> are still fighting complexity problems arising from not having a> sufficiently refined definition for identity.
This approach allows identity to be scaled to just a set of attributevalues. This is quite useful from a privacy protection point of view.
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
