Projects/Revocation - Revision history

Tsitkova at 02:00, 2 August 2014

2014-08-02T02:00:24Z

Tsitkova at 18:53, 30 July 2014

2014-07-30T18:53:37Z

Tsitkova at 15:57, 23 July 2014

2014-07-23T15:57:46Z

Tsitkova: Initial statement of purpose and possible solutions

2014-07-23T15:55:42Z

Initial statement of purpose and possible solutions

New page

== Purpose ==

Introduce a Revocation functionality into Kerberos eco-system.

== Possible scenarios and approaches ==

# Support “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). If desired, the Application Server may get an access to this information (perhaps, through a special channel/protocol) and acts accordingly;
# Application server observes some malicious activity (e.g. through audit log analysis) and reports it to KDC. KDC acts accordingly. Ideally, the Client (person or service) is also informed (via email or some other communication channel) that his/her credentials are jeopardized;
# KDC learns that client is jeopardized or his/her credentials are changed or revoked, and dispatches warnings to all services that expressed interest in this functionality and may be potentially affected by the accident. The warning is sent only if the ticket for the particular service exists and is still valid.
# Forensics: Application server observes the malicious action. It informs KDC about the accident, but continues to serve the intruder to allow some time to track down the originator of the attack.

===Lightweight approach under CAMMAC umbrella ===

KDC learns that client is jeopardized or his/her credentials are changed or revoked, and incorporates the revocation information into AD-CAMMAC container for every newly issued ticket.

== References ==

# http://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7817.pdf
# http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-07

← Older revision		Revision as of 18:53, 30 July 2014
Line 20:		Line 20:
	# http://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7817.pdf		# http://nvlpubs.nist.gov/nistpubs/ir/2012/NIST.IR.7817.pdf
	# http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-07		# http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-07
		+	# http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R4.pdf (Class FAU_ARP)

← Older revision		Revision as of 15:57, 23 July 2014
Line 1:		Line 1:
		+	{{project-early}}
		+
	== Purpose ==		== Purpose ==

@@ Line 7: / Line 7: @@
 == Possible scenarios and approaches ==
-# Support “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).  If desired, the Application Server may get an access to this information (perhaps, through a special channel/protocol)  and acts accordingly;
+# “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;
-# Application server observes some malicious activity (e.g. through audit log analysis) and reports it to KDC. KDC acts accordingly.  Ideally, the Client (person or service) is also informed (via email or some other communication channel) that his/her credentials are jeopardized;
+# 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;
-# KDC learns that client is jeopardized or his/her credentials are changed or revoked, and dispatches warnings to all services that expressed interest in this functionality and  may be potentially affected by the accident. The warning is sent only if the ticket for the particular service exists and is still valid.
+# 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.
-# Forensics:  Application server observes the malicious action. It informs KDC about the accident, but continues to  serve the intruder to allow some time to track down the originator of the attack.
+# 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.
 ===Lightweight approach under CAMMAC umbrella ===
-KDC learns that client is jeopardized or his/her credentials are changed or revoked, and  incorporates the revocation information into AD-CAMMAC container for every newly issued ticket.
+KDC learns that client is jeopardized or his/her credentials are changed or revoked, and  incorporates the revocation information into AD-CAMMAC container for every NEWLY issued ticket.   Once ticket receiver processes AD-CAMMAC, it can “locally” revoke/filter all existing tickets for that particular user.
 == References ==