[36326] in Kerberos
Re: revocation feature in Kerberos
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Jul 31 19:58:59 2014
MIME-Version: 1.0
In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E70CE7D@001FSN2MPN1-045.001f.mgd2.msft.net>
Date: Thu, 31 Jul 2014 18:58:38 -0500
Message-ID: <CAK3OfOg+GN_T489R1k8QFBx8vv3tYmkJJ3tRjG2ifV+4bgQT_A@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Nordgren, Bryce L -FS" <bnordgren@fs.fed.us>
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 Thu, Jul 31, 2014 at 6:49 PM, Nordgren, Bryce L -FS
<bnordgren@fs.fed.us> wrote:
>> No, the only way in which a revocation protocol for Kerberos makes any
>> sense to me is one that involves propagating notices to those services (TGSes
>> included) for which the principal in question got extant tickets.
>
> Good. :) Do that.
>
> Seems that the KDC would have to be upgraded with connection info for services (can't trust that instance name == dns; can't trust that the service is running on the standard port).
>
> Oh, and if the service is httpd, slapd, or nfs using principal "host/example.com", how does one figure out which service to contact?
The KDC would have to know how to contact them, or infer it from the
principal name. As for _how_ to communicate the revocation, one
possibility would be for their realm's revocation service to connect
and authenticate as anonymous (say) with a ticket bearing authz-data
listing the revoked principal (or not-before time, if revoking only
tickets issued before a password change).
(Revoking _many_ principals would be done by revoking an entire realm
with a not-before time.)
Nico
--
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
