logo_kerberos.gif

Difference between revisions of "Projects/Lockout"

From K5Wiki
Jump to: navigation, search
(Lockout policy)
Line 8: Line 8:
   
 
This project has nothing to do with password complexity or ageing.
 
This project has nothing to do with password complexity or ageing.
 
It is important that deploying this in a mixed environment of 1.8 and pre-1.8 KDCs does not create any security exposures.
 
   
 
==Design==
 
==Design==
Line 17: Line 15:
 
There are three attributes which will be associated with a Kerberos policy:
 
There are three attributes which will be associated with a Kerberos policy:
   
* lockout threshold (number of attempts)
+
* pw_max_fail (number of attempts)
* lockout observation window (period after which bad preauthentication count will be reset)
+
* pw_failcnt_interval (period after which bad preauthentication count will be reset)
* lockout duration (period in which lockout is enforced; a duration of zero means that the principal must be manually unlocked)
+
* pw_lockout_duration (period in which lockout is enforced; a duration of zero means that the principal must be manually unlocked)
   
TBD: is it possible to extend osa_policy_ent_rec with these variables (given the structure is versioned).
 
 
There are four attributes which will be associated with each principal:
   
There are three attributes which will be associated with each principal:
 
 
* last_success (time of last preauthentication success)
  +
* last_failed (time of last preauthentication failure)
 
* fail_auth_count (number of preauthentication failures)
 
* lockout time
   
* time of last preauthentication failure
 
  +
These are non-replicated attributes. The lockout time is stored in TL data; all other attributes reuse existing fields in the principal entry.
* number of preauthentication failures (within observation window)
 
* time the principal was locked out
 
 
These will be encoded in TL data for backwards compatibility with existing KDCs.
 
 
TBD: We might also set DISALLOW_ALL_TIX for backwards compatibility, although we will need to note whether this was already set so we can restore it (which has a race condition). Ultimately this will be difficult to do properly unless all KDCs are 1.8, so we will have to find the best compromise. I would prefer to distinguish between a principal with DISALLOW_ALL_TIX set and a locked out principal, because they are different things (and the latter can be computed purely from reading the time the principal was locked out).
 
 
TBD: in Active Directory, the preauthentication failure time and count are non-replicated attributes (for performance; only the fact an principal is locked out is replicated). Can we do this with the existing KDB replication architecture? How can we replication account lockout status without a multi-master replication architecture? Will we need replication protocol extensions?
 
   
 
====Mapping to LDAP password policy draft====
 
====Mapping to LDAP password policy draft====
   
* lockout threshold - pwdMaxFailure
+
* pw_max_fail - pwdMaxFailure
* lockout observation window - pwdFailureCountInterval
+
* pw_failcnt_interval - pwdFailureCountInterval
* lockout duration - pwdLockoutDuration
+
* pw_lockout_duration duration - pwdLockoutDuration
   
* time of last preauthentication failure - pwdFailureTime
+
* last_failed - pwdFailureTime
* number of preauthentication failures (within observation window) - n(pwdFailureTime)
+
* fail_auth_count - number of preauthentication failures (within observation window) - n(pwdFailureTime)
* time the principal was locked out - pwdAccountLockedTime
+
* KRB5_TL_LOCKED_TIME - pwdAccountLockedTime
   
 
===Before authentication===
 
===Before authentication===
Line 50: Line 43:
   
 
<pre>
 
<pre>
if ( lockout time + lockout duration < now )
 
  +
if (locked_time != 0 &&
principal is locked, return KDC_ERR_CLIENT_REVOKED or similar
 
  +
stamp < locked_time + lockout_duration)
  +
return kdc_err_client_revoked
 
</pre>
 
</pre>
   
 
===After authentication===
 
===After authentication===
 
====After preauthentication failure====
 
 
If last preauthentication failure was outside observation window, reset preauthentication failure count.
 
 
Then, set preauthentication failure time and count, and lock account out if necessary.
 
 
<pre>
 
if ( preauthentication failure time + lockout observation window > now )
 
preauthentication failure count ::= 0
 
 
preauthentication failure time ::= now
 
preauthentication failure count ::= preauthentication failure count + 1
 
 
if ( lockout threshold != 0 && preauthentication failure count >= lockout threshold )
 
{
 
lockout time ::= now /* account is now locked */
 
attributes ::= attributes | DISALLOW_ALL_TIX
 
}
 
</pre>
 
 
====After preauthentication success====
 
 
<pre>
 
preauthentication failure count ::= 0
 
/* note that AD does not reset preauthentication failure time here */
 
 
if ( lockout duration != 0 && lockout time + lockout duration > now )
 
lockout time ::= 0
 
</pre>
 
   
 
==Implementation details==
 
==Implementation details==
 
Plan to implement with the DB backend first, then LDAP. Code will be shared where possible, but the bulk of code will be within the backend, as I don't wish to enforce this lockout model on other backend implementers (such as Novell).
 
   
 
==Tools==
 
==Tools==
Line 95: Line 57:
   
 
==Status==
 
==Status==
 
No code written yet.
 

Revision as of 15:42, 13 September 2009

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.



Background

This project aims to provide principal lockout functionality similar to that of Active Directory. After a certain number of preauthentication failures (the theshold) with a given time limit (the observation window), a principal will be locked out from authenticating for a certain period of time (the lockout duration).

This project has nothing to do with password complexity or ageing.

Design

Lockout policy

There are three attributes which will be associated with a Kerberos policy:

  • pw_max_fail (number of attempts)
  • pw_failcnt_interval (period after which bad preauthentication count will be reset)
  • pw_lockout_duration (period in which lockout is enforced; a duration of zero means that the principal must be manually unlocked)

There are four attributes which will be associated with each principal:

  • last_success (time of last preauthentication success)
  • last_failed (time of last preauthentication failure)
  • fail_auth_count (number of preauthentication failures)
  • lockout time

These are non-replicated attributes. The lockout time is stored in TL data; all other attributes reuse existing fields in the principal entry.

Mapping to LDAP password policy draft

  • pw_max_fail - pwdMaxFailure
  • pw_failcnt_interval - pwdFailureCountInterval
  • pw_lockout_duration duration - pwdLockoutDuration
  • last_failed - pwdFailureTime
  • fail_auth_count - number of preauthentication failures (within observation window) - n(pwdFailureTime)
  • KRB5_TL_LOCKED_TIME - pwdAccountLockedTime

Before authentication

Check whether account is already locked out:

if (locked_time != 0 &&
     stamp < locked_time + lockout_duration)
    return kdc_err_client_revoked

After authentication

Implementation details

Tools

kadmin will be enhanced to manually unlock a principal.

Status