logo_kerberos.gif

Difference between revisions of "Projects/Lockout"

From K5Wiki
Jump to: navigation, search
(New page: {{project-early}})
 
Line 1: Line 1:
 
{{project-early}}
  
{{project-early}}
  +
  +
<includeonly>[[Category: early stage projects]]</includeonly>
  +
  +
==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.
  +
  +
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==
  +
  +
===Lockout policy===
  +
  +
There are three attributes which will be associated with a Kerberos policy:
  +
  +
* lockout threshold (number of attempts)
  +
* lockout observation window (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)
  +
  +
TBD: is it possible to extend osa_policy_ent_rec with these variables (given the structure is versioned).
  +
  +
There are three attributes which will be associated with each principal:
  +
  +
* time of last preauthentication failure
  +
* 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 Dircetory, 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?
  +
  +
===Before authentication===
  +
  +
Check whether account is already locked out:
  +
  +
<pre>
  +
if ( lockout time + lockout duration < now )
  +
principal is locked, return error (probably KDC_ERR_CLIENT_REVOKED)
  +
</pre>
  +
  +
===After authentication===
  +
  +
Check whether lockout observation window has closed:
  +
  +
<pre>
  +
if ( preauthentication failure time + lockout observation window > now )
  +
preauthentication failure count ::= 0
  +
</pre>
  +
  +
====After preauthentication failure====
  +
  +
Record authentication failure and possibly lock account out:
  +
  +
<pre>
  +
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====
  +
  +
preauthentication failure count ::= 0
  +
  +
<pre>
  +
if ( lockout duration != 0 && lockout time != 0 )
  +
lockout time ::= 0
  +
</pre>
  +
  +
==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==
  +
  +
kadmin will be enhanced to manually unlock a principal.
  +
  +
==Status==
  +
  +
No code written yet.

Revision as of 15:13, 20 August 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.

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

Lockout policy

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

  • lockout threshold (number of attempts)
  • lockout observation window (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)

TBD: is it possible to extend osa_policy_ent_rec with these variables (given the structure is versioned).

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

  • time of last preauthentication failure
  • 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 Dircetory, 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?

Before authentication

Check whether account is already locked out: 

if ( lockout time + lockout duration < now )
    principal is locked, return error (probably KDC_ERR_CLIENT_REVOKED)

After authentication

Check whether lockout observation window has closed: 

if ( preauthentication failure time + lockout observation window > now )
    preauthentication failure count ::= 0

After preauthentication failure

Record authentication failure and possibly lock account out: 

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
}

After preauthentication success

preauthentication failure count ::= 0 

if ( lockout duration != 0 && lockout time != 0 )
    lockout time ::= 0

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

kadmin will be enhanced to manually unlock a principal.

Status

No code written yet.

Retrieved from "https://k5wiki.kerberos.org./wiki?title=Projects/Lockout&oldid=2138"