Revocation feature

[Zhanna Tsitkov]

BTW,  the relevant NIST document  can be found here: http://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7817.pdf

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
>