Revocation feature

Zhanna Tsitkov tsitkova at MIT.EDU
Tue Jul 22 19:21:08 EDT 2014

BTW,  the relevant NIST document  can be found here:

On Jul 22, 2014, at 6:44 PM, Zhanna Tsitkov <tsitkova at MIT.EDU> wrote:

> Hello,
> I was wondering if there is any interest in the full scale 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 receives access to this information (perhaps, through a special channel/protocol)  and acts accordingly;
> 2. Application server observes some malicious activity (e.g. after 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 service is still valid.
> 4. Forensics:  AppServer observes the malicious action. It informs KDC about the accident, but continues to  serve “the client” to track down the originator of the attack. 
> Almost (?) all of these scenarios would require extensive design/developmental work.  There is, however, a lightweight approach under CAMMAC umbrella when revocation information is incorporated into AD container and is sent with every newly issued ticket.  
> As always, your input and comments are welcome and appreciated.
> Thanks,
> Zhanna

More information about the krbdev mailing list