Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
revocation feature in Kerberos
720 views
Skip to first unread message
Zhanna Tsitkov
Jul 31, 2014, 4:13:39 PM7/31/14
to kerb...@mit.edu
Hello,
I was wondering if there is any interest in the full scale Violation-alarm/Revocation feature for the Kerberos-enabled environments?
There are several possible scenarios/approaches:
1. “Black list” on KDC: KDC stores information about jeopardized clients together with the timestamp when the accident was recorded (e. g. Client lost mobile phone with some active security-sensitive applications and informed KDC about it). The Application Server accesses this information (perhaps, through a special channel/protocol) and acts accordingly;
2. Application server observes some malicious activity (e.g.from audit log analysis) and reports it to KDC. KDC acts accordingly. Ideally, the Client (person or service) is also informed that his/her credentials are jeopardized;
3. KDC learns that client is jeopardized and dispatches warnings to all services that may be potentially affected by the accident. The warning is sent only if the ticket for the particular service was issued and it is still valid.
4. Forensics: Application server observes the malicious action. It informs KDC about the accident, but continues to serve the hacker to allow time to track down the originator of the attack.
All of these scenarios would require extensive design/developmental work. There is, however, a lightweight approach under CAMMAC umbrella (http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-07) when revocation information is incorporated into AD-CAMMAC container and is sent with every NEWLY issued ticket. Once ticket receiver processes AD-CAMMAC, it can “locally” revoke/filter all existing tickets for that particular user.
The relevant NIST document can be found here: http://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7817.pdf
Your input and comments are appreciated.
Thanks,
Zhanna
I was wondering if there is any interest in the full scale Violation-alarm/Revocation feature for the Kerberos-enabled environments?
There are several possible scenarios/approaches:
1. “Black list” on KDC: KDC stores information about jeopardized clients together with the timestamp when the accident was recorded (e. g. Client lost mobile phone with some active security-sensitive applications and informed KDC about it). The Application Server accesses this information (perhaps, through a special channel/protocol) and acts accordingly;
2. Application server observes some malicious activity (e.g.from audit log analysis) and reports it to KDC. KDC acts accordingly. Ideally, the Client (person or service) is also informed that his/her credentials are jeopardized;
3. KDC learns that client is jeopardized and dispatches warnings to all services that may be potentially affected by the accident. The warning is sent only if the ticket for the particular service was issued and it is still valid.
4. Forensics: Application server observes the malicious action. It informs KDC about the accident, but continues to serve the hacker to allow time to track down the originator of the attack.
All of these scenarios would require extensive design/developmental work. There is, however, a lightweight approach under CAMMAC umbrella (http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-07) when revocation information is incorporated into AD-CAMMAC container and is sent with every NEWLY issued ticket. Once ticket receiver processes AD-CAMMAC, it can “locally” revoke/filter all existing tickets for that particular user.
The relevant NIST document can be found here: http://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7817.pdf
Your input and comments are appreciated.
Thanks,
Zhanna
Nico Williams
Jul 31, 2014, 5:34:42 PM7/31/14
to Zhanna Tsitkov, kerb...@mit.edu
In general Kerberos doesn't need a revocation system because ticket
lifetimes should be short enough.
Within a realm it's often the case that other methods are used for
revocation (e.g., lock the _account_, which will generally replicate
with less latency than tickets will expire).
Across realms is where things get interesting. A TGS would have to
track the x-realm ticket vending it has done so that it could
selectively propagate revocation notifications to those realms that
ought to see them. Otherwise the system can't scale. In practice
cross-realm TGTs tend to be shorter lived than local TGTs, and for
this reason.
A not-before timestamp in tickets might be useful, but not sufficient.
A revocation system would have to involve an actual service sourcing
and propagating revocation notifications to all those services that
might need them, which in turn requires KDCs to keep track of all
extant (as yet not expired) tickets vended.
IMO it's worth exploring, but how worthwhile this is will depend on
how common it is for people to run with a) very long-lived local TGTs
and no other revocation scheme in place, and/or b) very long-lived
cross-realm TGTs. Assuming the worst, then it's worthwhile, of
course.
In a way such a system would scale better than revocation does for
PKI, where CRLs regularly go unchecked, and where OCSP responses have
Kerberos ticket-like lifetimes.
Nico
--
lifetimes should be short enough.
Within a realm it's often the case that other methods are used for
revocation (e.g., lock the _account_, which will generally replicate
with less latency than tickets will expire).
Across realms is where things get interesting. A TGS would have to
track the x-realm ticket vending it has done so that it could
selectively propagate revocation notifications to those realms that
ought to see them. Otherwise the system can't scale. In practice
cross-realm TGTs tend to be shorter lived than local TGTs, and for
this reason.
A not-before timestamp in tickets might be useful, but not sufficient.
A revocation system would have to involve an actual service sourcing
and propagating revocation notifications to all those services that
might need them, which in turn requires KDCs to keep track of all
extant (as yet not expired) tickets vended.
IMO it's worth exploring, but how worthwhile this is will depend on
how common it is for people to run with a) very long-lived local TGTs
and no other revocation scheme in place, and/or b) very long-lived
cross-realm TGTs. Assuming the worst, then it's worthwhile, of
course.
In a way such a system would scale better than revocation does for
PKI, where CRLs regularly go unchecked, and where OCSP responses have
Kerberos ticket-like lifetimes.
Nico
--
Roland C. Dowdeswell
Jul 31, 2014, 6:11:58 PM7/31/14
to Nico Williams, kerb...@mit.edu
On Thu, Jul 31, 2014 at 04:34:42PM -0500, Nico Williams wrote:
>
> In general Kerberos doesn't need a revocation system because ticket
> lifetimes should be short enough.
You can get many of the benefits of a revocation system by simply
>
> In general Kerberos doesn't need a revocation system because ticket
> lifetimes should be short enough.
vending service tickets with a shorter lifetime than the TGT used
to obtain them. If you, e.g. vend service tickets with a 15 minute
lifetime, then the client will need to contact the KDC once every
15 minutes to continue to connect to a service. The KDC, of course,
will validate that the client's account has not been locked at this
point.
> Within a realm it's often the case that other methods are used for
> revocation (e.g., lock the _account_, which will generally replicate
> with less latency than tickets will expire).
TGT, you can break apart the ``check that the user knows their
passwd'' check from the ``check that the account is still valid''
check.
> Across realms is where things get interesting. A TGS would have to
> track the x-realm ticket vending it has done so that it could
> selectively propagate revocation notifications to those realms that
> ought to see them. Otherwise the system can't scale. In practice
> cross-realm TGTs tend to be shorter lived than local TGTs, and for
> this reason.
> A not-before timestamp in tickets might be useful, but not sufficient.
> A revocation system would have to involve an actual service sourcing
> and propagating revocation notifications to all those services that
> might need them, which in turn requires KDCs to keep track of all
> extant (as yet not expired) tickets vended.
>
> IMO it's worth exploring, but how worthwhile this is will depend on
> how common it is for people to run with a) very long-lived local TGTs
> and no other revocation scheme in place, and/or b) very long-lived
> cross-realm TGTs. Assuming the worst, then it's worthwhile, of
> course.
>
> In a way such a system would scale better than revocation does for
> PKI, where CRLs regularly go unchecked, and where OCSP responses have
> Kerberos ticket-like lifetimes.
tickets puts the burden on the client to obtain new credentials
frequently whereas a revocation list places the burden on the server
to accept a feed of revocations. Each has its pros and cons. One
main pro of using short non-TGT ticket lifetimes is that it is
already possible without writing new code.
--
Roland Dowdeswell http://Imrryr.ORG/~elric/
Chris Hecker
Jul 31, 2014, 6:37:20 PM7/31/14
to Roland C. Dowdeswell, kerb...@mit.edu
Unless things have changed, the KDC doesn't check for account lock if the
tgt is valid. There's a thread from a couple years back where I asked
about this and then patched it, but I haven't submitted patches for the
current revision. I need to do this at some point. Or maybe it got fixed?
Chris
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
tgt is valid. There's a thread from a couple years back where I asked
about this and then patched it, but I haven't submitted patches for the
current revision. I need to do this at some point. Or maybe it got fixed?
Chris
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
Benjamin Kaduk
Jul 31, 2014, 6:47:05 PM7/31/14
to kerb...@mit.edu
On Thu, 31 Jul 2014, Chris Hecker wrote:
> Unless things have changed, the KDC doesn't check for account lock if the
> tgt is valid. There's a thread from a couple years back where I asked
> about this and then patched it, but I haven't submitted patches for the
> current revision. I need to do this at some point. Or maybe it got fixed?
Well, for the MIT KDC at least.
> Unless things have changed, the KDC doesn't check for account lock if the
> tgt is valid. There's a thread from a couple years back where I asked
> about this and then patched it, but I haven't submitted patches for the
> current revision. I need to do this at some point. Or maybe it got fixed?
There was a more recent thread a few months ago where this came up again:
http://mailman.mit.edu/pipermail/kerberos/2014-March/thread.html
(it looks like you did post your patch there)
> On Jul 31, 2014 3:15 PM, "Roland C. Dowdeswell" <el...@imrryr.org> wrote:
>
>> On Thu, Jul 31, 2014 at 04:34:42PM -0500, Nico Williams wrote:
>>>
>>
>>> In general Kerberos doesn't need a revocation system because ticket
>>> lifetimes should be short enough.
the initial authentication that generated it. That means that the only
revocation hammer available is a big one, to disallow all tickets for that
principal. (As Chris notes, the MIT KDC does not at present even enforce
that flag at renewal time.)
David Benjamin has an idea for how to work around this, and be able to
only "revoke" tickets issued with a compromised password, while still
allowing tickets issued from a newer password to be usable. I should
probably write this up and get some more eyes on it; it's been back-burner
for a while.
>> You can get many of the benefits of a revocation system by simply
>> vending service tickets with a shorter lifetime than the TGT used
>> to obtain them. If you, e.g. vend service tickets with a 15 minute
>> lifetime, then the client will need to contact the KDC once every
>> 15 minutes to continue to connect to a service. The KDC, of course,
>> will validate that the client's account has not been locked at this
>> point.
>>
>>> Within a realm it's often the case that other methods are used for
>>> revocation (e.g., lock the _account_, which will generally replicate
>>> with less latency than tickets will expire).
>>
>> Right and by using different lifetimes for service tickets as their
>> TGT, you can break apart the ``check that the user knows their
>> passwd'' check from the ``check that the account is still valid''
>> check.
may not be how you think it is or want it to be, at present.
-Ben
Nordgren, Bryce L -FS
Jul 31, 2014, 7:22:23 PM7/31/14
to Benjamin Kaduk, kerb...@mit.edu
Beware the asymmetry.
When considering schemes like this, please be on the lookout for new connectivity requirements. Consider an organization with a tightly guarded KDC on their intranet, to which all the employees authenticate. Outside their firewall is another KDC with "supplemental" external users and hosts. The normal connection pattern for employees would be to kinit inside the firewall, traverse a trust outside the firewall, and finally connect to the server.
The server outside the firewall cannot contact the KDC which manages the user principals.
Neither can the KDC which manages the public-facing, company managed network.
Revocation schemes must account for situations where parties other than the authenticated user cannot contact the user's home KDC.
Bryce
This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.
Nico Williams
Jul 31, 2014, 7:23:10 PM7/31/14
to Benjamin Kaduk, kerb...@mit.edu
On Thu, Jul 31, 2014 at 5:47 PM, Benjamin Kaduk <ka...@mit.edu> wrote:
>> On Jul 31, 2014 3:15 PM, "Roland C. Dowdeswell" <el...@imrryr.org> wrote:
>>
>>> On Thu, Jul 31, 2014 at 04:34:42PM -0500, Nico Williams wrote:
>>>>
>>>
>>>> In general Kerberos doesn't need a revocation system because ticket
>>>> lifetimes should be short enough.
>
> The structure of a kerberos ticket doesn't include what key was used for
> the initial authentication that generated it. That means that the only
> revocation hammer available is a big one, to disallow all tickets for that
> principal. (As Chris notes, the MIT KDC does not at present even enforce
> that flag at renewal time.)
Or all tickets prior to the revocation event (e.g., password change,
>> On Jul 31, 2014 3:15 PM, "Roland C. Dowdeswell" <el...@imrryr.org> wrote:
>>
>>> On Thu, Jul 31, 2014 at 04:34:42PM -0500, Nico Williams wrote:
>>>>
>>>
>>>> In general Kerberos doesn't need a revocation system because ticket
>>>> lifetimes should be short enough.
>
> The structure of a kerberos ticket doesn't include what key was used for
> the initial authentication that generated it. That means that the only
> revocation hammer available is a big one, to disallow all tickets for that
> principal. (As Chris notes, the MIT KDC does not at present even enforce
> that flag at renewal time.)
if you thought your password was compromised).
> David Benjamin has an idea for how to work around this, and be able to
> only "revoke" tickets issued with a compromised password, while still
> allowing tickets issued from a newer password to be usable. I should
> probably write this up and get some more eyes on it; it's been back-burner
> for a while.
and check it in the TGS.
For services it won't help you and you have to rely on ticket expiration.
>>>> Within a realm it's often the case that other methods are used for
>>>> revocation (e.g., lock the _account_, which will generally replicate
>>>> with less latency than tickets will expire).
>>>
>>> Right and by using different lifetimes for service tickets as their
>>> TGT, you can break apart the ``check that the user knows their
>>> passwd'' check from the ``check that the account is still valid''
>>> check.
>
> That requires all this checking to actually be done. Per the above, it
> may not be how you think it is or want it to be, at present.
login you need your tickets, yes, but also your account to not be
locked. In many environments the name service update and cache entry
expiration times are such that revocation by locking the _account_ has
lower latency than the typical service ticket lifetime.
Nico
--
Nico Williams
Jul 31, 2014, 7:30:40 PM7/31/14
to Nordgren, Bryce L -FS, kerb...@mit.edu
On Thu, Jul 31, 2014 at 6:22 PM, Nordgren, Bryce L -FS
<bnor...@fs.fed.us> wrote:
> Revocation schemes must account for situations where parties other than the authenticated user cannot contact the user's home KDC.
A revocation protocol that propagates revocation notices towards the
<bnor...@fs.fed.us> wrote:
> Revocation schemes must account for situations where parties other than the authenticated user cannot contact the user's home KDC.
services accessed by the user will not require connectivity in the
opposite direction, and it might not even involve any firewall
configuration changes. KDC->KDC revocation notices should be sent on
port 88, and KDC->service notices should be sent in realm- or
app-specific manner, so no problem there either.
A revocation protocol more like OCSP (not stapled, so it'd have the
problem you mention) would be silly: you might as well just turn
service ticket lifetimes down and be done!
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.
Nico
--
Nordgren, Bryce L -FS
Jul 31, 2014, 7:49:05 PM7/31/14
to Nico Williams, kerb...@mit.edu
> 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.
> sense to me is one that involves propagating notices to those services (TGSes
> included) for which the principal in question got extant tickets.
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?
Nico Williams
Jul 31, 2014, 7:58:38 PM7/31/14
to Nordgren, Bryce L -FS, kerb...@mit.edu
On Thu, Jul 31, 2014 at 6:49 PM, Nordgren, Bryce L -FS
<bnor...@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
<bnor...@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?
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
--
Nordgren, Bryce L -FS
Aug 2, 2014, 4:50:08 PM8/2/14
to Nico Williams, kerb...@mit.edu
> > 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).
What about services on mobile client workstations, such as an NFS client connecting from employee's home or a partner's institution? Trust that the server will revoke, or try and figure out how to traverse the home/other-organization's router+firewall? It seems that this a the use-case which would introduce a requirement for symmetric connectivity. It may not be important that revocation work for this case, tho.
Booker Bense
Aug 3, 2014, 2:33:58 PM8/3/14
to kerb...@mit.edu
This whole conversation seems misguided to me. Kerberos is an
authentication system, not an authorization one. Access to a service is an
authorization issue. Since there is no universal authorization scheme for
kerberos applications, any workable revocation system will have to
build that first. That would be a very useful tool, but I'm afraid it might
be about 20 years too late.
- Booker C. Bense
authentication system, not an authorization one. Access to a service is an
authorization issue. Since there is no universal authorization scheme for
kerberos applications, any workable revocation system will have to
build that first. That would be a very useful tool, but I'm afraid it might
be about 20 years too late.
- Booker C. Bense
Nico Williams
Aug 4, 2014, 1:06:28 PM8/4/14
to Booker Bense, kerb...@mit.edu
principal and/or its extant tickets.
Kerberos' design specifically obviates the need for a revocation system:
use short-lived tickets and you're mostly set.
That said, we've long ago stopped arguing about Kerberos as an
authentication system, and its relevance to authorization. Kerberos is
relevant even to the simplest authorization schemes just by dint of
delivering the key to those schemes: the authenticated identity
(principal name). Often Kerberos also carries authorization-specific
attributes (e.g., PAC, CAMMAC). Either way Kerberos is orthogonal to
authorization, but authentication is integral to authorization,
therefore it's hard to separate the two. Incidentally, the rest of the
world (e.g., SAML) long ago accepted that an attribute model of identity
(and therefore authentication) is more important than the more
traditional Kerberos model.
Nico
--
0 new messages