[35783] in Kerberos
Re: ACL for Constrained Delegation?
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Feb 20 14:00:57 2014
MIME-Version: 1.0
In-Reply-To: <5305958F.70009@fifthhorseman.net>
Date: Thu, 20 Feb 2014 13:00:38 -0600
Message-ID: <CAK3OfOjK6pFU4-eNXQETUv6=tT_3pvxKSo33CCe8+WshtJ_daQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Wed, Feb 19, 2014 at 11:41 PM, Daniel Kahn Gillmor
<dkg@fifthhorseman.net> wrote:
> This arrangement seems to suggest that the delegation constraint is
> something that will be managed for all principals by the KDC explicitly,
> rather than the end user being able to decide (or even know?) what
> explicit delegations are being offered. Am i understanding this right?
That's exactly right.
> Is there any mechanism for user-controllable delegation? (or perhaps
> more fundamentally, does this question even make sense, given the power
> held by the KDC already?)
The question very much makes sense. The original Kerberos design
required that the applications have the final say on policy as to,
e.g., cross-realm transit path policy and authorization in general.
KDCs get to reject things (e.g., if there's no cross-realm trust
relationship they must reject), and they get to indicate approval
(e.g., TRANSIT-POLICY-CHECKED), but in principle they leave policy to
the service application.
I missed the cut-off for -00 Internet-Drafts for IETF89, so the
following is as-yet not submitted, but it will be submitted soon, and
its goal is to address this problem:
https://raw.github.com/nicowilliams/kitten/master/gss-authzid.txt
Nico
--
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
