Subject: [Ietf-krb-wg] KDC model and atomicity (was Re: Add. comments on Kdc model, WAS[Re: I-D Action: draft-ietf-krb-wg-kdc-model-12.txt])

From: Nico Williams <[email-masked]>
Date: Sun, 10 Jun 2012 12:52:43 -0500

I'm quite concerned about the failed authentication count and last
failed authentication timestamp fields.  Their purpose is, clearly, to
implement N-strikes-you're-locked.  Setting aside the wisdom of such
policies, I have a fundamental objection to the prescriptive nature of
the I-D regarding implementation: the prescribed implementation design
requires atomic increment operations on the KDB, something that is
rather difficult to obtain, has far reaching design and operational
considerations, and is unnecessary to the implementation of
N-strikes-you're-locked.

Specifically I object to any requirement, particularly any implied
requirement, that a KDC support atomic operations on principal
records.  We have never before had such a requirement, and to add it
now for a controversial feature (a DoS, for goodness' sake) is... not
acceptable.

I also object to the idea that the only correct  (required to
implement) response to password guessing attacks is to lock the
principal.  Other possibilities include: delay replies to AS-REQs for
principals under attack (Hank's suggestion, IIRC), bring forward
password expiration for the principal, or inform the affected user /
ask them if the failed login attempts are theirs or not.

I understand that LDAP is supposed to support such operations, but we
all know of at least one major implementation that does not implement
such atomicity.  Moreover, just because LDAP is supposed to provide
for atomic modify operations does not mean that it's a good idea to
rely on that feature, or that it's easy to implement it....  LDAP
atomic modifies imply either single mastering (possibly with
elections), single mastering individual objects, a distributed locking
mechanism, or other such designs, most or all of which have obnoxious
operational considerations.

Besides, an implementor should not be forced to use LDAP or develop a
KDB backend with similar semantics, not for this obnoxious feature,
not if there are alternative designs that don't require it, such as:

 - Analyze logs/audit trails in real-time to decide when to
[temporarily, one hopes] lock a principal.

 - Replicate failed login attempt information in such a way that a
deterministic merge of this data is possible, allowing each KDC to
independently decide when to lock a principal.  Sam's proposal to me
(on the phone) for this is to keep a list of failed login attempt
{timestamp, id}, where the ID identifies a KDC or an AS-REQ, or is,
perhaps, just a UUID.  Such a list can clearly be merged and each KDC
can clearly use it to deterministically decide (though the timing will
depend on replication latency) when to apply a defense against
password guessing.

I'm not sure what text to propose to address this, but let's take it
one step at a time: first let's seek consensus as to my objections,
then let us write new text.

Nico
--
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Sun, 10 Jun 2012 21:39:23 +0200

> records.  We have never before had such a requirement, and to add
> it now for a controversial feature (a DoS, for goodness' sake)
> is... not acceptable.

I hadn't thought of this aspect. FTR I agree with your objection.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Sun, 10 Jun 2012 16:25:43 -0400

I agree that N-strikes lockout, implemented through counters in the KDB, 
is not the final word on how one should respond to a password-guessing 
attack, and we don't want to carve it in stone.

The simplest, and possibly best, thing to say about lockout in the 
information model is nothing.  Of course, that doesn't help us get to 
the point of interoperating on administrative operations related to 
lockout (policy-setting and administrative unlock)--but that can always 
be the subject of future revisions to the model (or schema, or admin 
protocol).

---

From: Leif Johansson <[email-masked]>
Date: Mon, 11 Jun 2012 00:08:36 +0200

On 06/10/2012 10:25 PM, Greg Hudson wrote:
> I agree that N-strikes lockout, implemented through counters in the
> KDB, is not the final word on how one should respond to a
> password-guessing attack, and we don't want to carve it in stone.
> 
> information model is nothing.  Of course, that doesn't help us get
> to the point of interoperating on administrative operations related
> to lockout (policy-setting and administrative unlock)--but that can
> always be the subject of future revisions to the model (or schema,
> or admin protocol).

Well I think Nicos point was that you can't even implement the attribute
in question wo transactions across all KDCs in a realm.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Sun, 10 Jun 2012 19:47:59 -0500

> in question wo transactions across all KDCs in a realm.

But Greg's is that our concern here should be about interop w.r.t.
administration.  I think that's clarifying.  I think we want to say
that there should be a way to set a policy indicating what action to
take when password guessing attacks are detected, and roughly how to
detect them while not being prescriptive about implementation.  In
other words, maybe we need a max number of failed password pre-auth
attempts as a *policy*, and we should refrain from specifying any
attributes regarding how the KDCs keep track of that number.  I'd be
happy with that.

Nico

---

From: Leif Johansson <[email-masked]>
Date: Mon, 11 Jun 2012 11:52:12 +0200

On 06/11/2012 02:47 AM, Nico Williams wrote:
>>> I agree that N-strikes lockout, implemented through counters in
>>> the KDB, is not the final word on how one should respond to a 
>>> The simplest, and possibly best, thing to say about lockout in
>>> the information model is nothing.  Of course, that doesn't help
>>> us get to the point of interoperating on administrative
>>> operations related to lockout (policy-setting and
>>> administrative unlock)--but that can always be the subject of
>>> future revisions to the model (or schema, or admin protocol).
>> 
>> Well I think Nicos point was that you can't even implement the
>> attribute in question wo transactions across all KDCs in a
>> realm.
> 
> administration.  I think that's clarifying.  I think we want to
> say that there should be a way to set a policy indicating what
> action to take when password guessing attacks are detected, and
> roughly how to detect them while not being prescriptive about
> implementation.  In other words, maybe we need a max number of
> failed password pre-auth attempts as a *policy*, and we should
> refrain from specifying any attributes regarding how the KDCs keep
> track of that number.  I'd be happy with that.

Could somebody propose text?

---

From: Sam Hartman <[email-masked]>
Date: Mon, 11 Jun 2012 09:44:37 -0400

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    >> it now for a controversial feature (a DoS, for goodness' sake)

    Leif> I hadn't thought of this aspect. FTR I agree with your objection.
    Leif> _______________________________________________

Leif, I'm confused because I'd like to understand what in the current
text leads to a requirement for atomicity.
The current text has a failed authentications count (and we're adding
one that can be reset).

To me, that means a schema must be able to map to/from that attribute in
the data model.
It's entirely reasonable for a schema to store more information so long
as the mapping exists.
Nico has proposed an excellent mapping of this attribute to LDAP: a list
of failed authentications.
What in the current text prohibits that?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Jun 2012 15:41:56 -0500

> text leads to a requirement for atomicity.

The failed authentication count attribute.  I suppose we could say
that it's a virtual attribute whose value may be computed from other
sources, then there'd be no atomicity implication.

> To me, that means a schema must be able to map to/from that attribute in

Resetting a virtual failed auth count attribute sounds more like an
operation in LDAP speak than like a modify.  I suppose nothing in the
LDAP specs forbids this, but note that it may not be possible to
explicitly assign any value other than zero to this attribute.

> It's entirely reasonable for a schema to store more information so long

That's a fair point.

Nico

---

From: Sam Hartman <[email-masked]>
Date: Mon, 11 Jun 2012 17:08:36 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    >> text leads to a requirement for atomicity.

    Nico> The failed authentication count attribute.  I suppose we could say
    Nico> that it's a virtual attribute whose value may be computed from other
    Nico> sources, then there'd be no atomicity implication.

Hmm.  I thought the difference between a schema and data model implied
this.  If there is ambiguity I'd prefer to clarify that so long as the
data is representend in the schema, how it is done is up to the
schema. I think even calling out issues like avoiding atomicity would be
reasonable. But I'd prefer for it to be global not just focused on this
one issue.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Mon, 11 Jun 2012 16:41:28 -0500

> reasonable. But I'd prefer for it to be global not just focused on this

Well, LDAP's meta-schema is limited to the needs of LDAP as an access
protocol.  It doesn't address all sorts of things, such as computed
attributes, referential integrity, triggers, and so on.  This document
isn't specific to LDAP, I know, but LDAP might be foremost in readers'
minds.

Perhaps we can just add a minor amount of text saying something to the
effect that some/all schema elements from the model may well be
computed and/or mapped not only to another schema's elements, but also
to operations.

Nico

---

From: Leif Johansson <[email-masked]>
Date: Wed, 13 Jun 2012 14:57:38 +0200

> To me, that means a schema must be able to map to/from that
> attribute in the data model. It's entirely reasonable for a schema
> to store more information so long as the mapping exists. Nico has
> proposed an excellent mapping of this attribute to LDAP: a list of
> failed authentications. What in the current text prohibits that?

Because if you need it to be reset at each successful authn then
if C(lient) talks to K1 and first fails n-1 times, then succeeds
once and fails once and if K2 receives status updates from K1 then
if the message about the success arrives after the message about
the last failure then a mgmt client talking to K2 could lock
the user before the success message arrived at K2 to reset the
counter. I'm not sure how mapping the attribute helps there...

	Cheers Leif

---

From: Simo Sorce <[email-masked]>
Date: Wed, 13 Jun 2012 09:41:09 -0400

On Wed, 2012-06-13 at 14:57 +0200, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 

FWIW we currently do note replicate the account lock/success status in
our LDAP setups, because it completely kills replication infrastructure.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Jun 2012 17:55:56 -0400

> our LDAP setups, because it completely kills replication infrastructure.

As it turns out, regardless of whether failed-auth status is fully
replicated, fully independent, or propagated only from the master to the
slaves, it is possible for a given set of policy parameters to compute
an upper bound on the number of tries an attacker gets before the
lockout or throttling mechanism prevents any further tries.

It is certainly possible to apply a hand-wavy "three strikes" policy, in
which case replication might become a problem.  However, for those being
more careful, the goal is generally to satisfy a set of constraints that
relate required password strength to the number guesses an attacker gets
over the life of the password.  The latter of course is controlled by
lockout and throttling mechanisms as well as by maximum password
lifetimes and related parameters.  In such cases it is totally possible
to take into account the effects of replication, and even 15 tries
(worst case for 3 tries and 2 slaves) is not impossible to overcome with
appropriate password lifetime and strength policies.

In any case, what we're talking about right now is a data model.  It's
supposed to provide a _model_ of the data the KDC needs to do its job,
or rather the subset of that data which we might want to observe and
manage in a standardized way.  It does not need to be all-inclusive; a
KDC can and should store whatever data it needs to implement whatever
lockout policies it supports.  It also does not need to contain only
fields which every KDC must support.  And, it's _only a model_; it does
not require that values be stored or computed in a particular way, only
that they behave according to the specified semantics.

I think it is entirely reasonable for the data model to include a failed
authentication count for a principal.  If it does, it must be specific
about the semantics of such a value, including details like whether it
is reset on successful authentication, when the keys are changed, or
never.  Without that information, it is useless to standardize the
value, because people and especially code looking at it won't know what
it means.  Because of this, it may turn out to be useful to specify
several different values with different semantics.  Probably none of
those should be required.

Remember, the goal here is not to nail down the contents of the KDB or
require implementations to work in a particular way.  It's to produce a
_model_ of what's in the KDB, to serve as the basis for interfaces to
view and manipulate that data.

-- Jeff

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Jun 2012 17:43:33 -0500

> lockout or throttling mechanism prevents any further tries.

However, the user experience may not be as deterministic.  I'm
referring here not to lockout but to unlock upon successful
authentication.  Failed auth counts might accumulate on some KDCs but
not others and sometimes the user may get lockout errors and other
times it just works.  I want the user experience not to suck.

> manage in a standardized way.  It does not need to be all-inclusive; a

The key here being about what we want to observe and manage.  We only
need to manage:

 - policy (value of N)

 - unlock a principal

We do not need to manage the count of failed authentication attempts.
That's an implementation detail.  We may need to observe it.

Given that I think it'd be good to leave this attribute in place but
describe it as read-only.

We need to describe how to unlock a principal though.

> never.  Without that information, it is useless to standardize the

Or manually (by an admin).

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 13 Jun 2012 19:41:40 -0400

> describe it as read-only.

Right.  However, note that the present attribute as described may not be
the one that a KDC can provide, depending on how its policy works.  I'd
suggest three attributes:

- failed auths since last successful auth
- failed auths since last key/pw change
- failed auths since "forever"

... where "forever" does not necessarily extend past deleting and
recreating the principal, or administratively resetting the counter, or
whatever.

All three attributes should be both read-only and optional, with the
expectation that most KDCs will implement at most one.

Same deal with timestamp of last successful/unsuccessful/attempt.

> We need to describe how to unlock a principal though.

Yup.  For this I'd suggest a boolean attribute indicating the principal
is locked out, which MAY be write-only, and in fact MAY support only
writing a value of "false".

-- Jeff

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Jun 2012 18:55:14 -0500

> recreating the principal, or administratively resetting the counter, or

I see no point for the third one unless forever means [effectively]
"since unlock".

> expectation that most KDCs will implement at most one.

At most?  As long as it isn't "at least".

> Same deal with timestamp of last successful/unsuccessful/attempt.

I'd rather not have that attribute at all.  Because why not list all
times of unsuccessful attempts since some point in time?

But also, none of this really says anything at all about password
guessing attacks.

A smart attacker will try a safe number of passwords < N for each
principal in whatever period of time the attacker can expect the users
to successfully authenticate.  This way the attacker can mount a slow
attack, but if there's lots of users the attacker can still make
progress fairly quickly.  Which really goes to my second objection: I
object to N-strikes-you're-locked.  It's not a good feature; it's a
_DoS_ attack vector where none need exist; it's hard to implement
correctly; it doesn't actually protect against password guessing
attacks, and it protects less well as the number of users in a realm
goes up.

I'd be much happier just ripping this out.  If it must stay in I want
all of it to be optional, and I want the security considerations
section to discuss the DoS issue and the low effectiveness of this
feature in stopping password guessing attacks.

> writing a value of "false".

As long as it's clear that this can be a virtual attribute such that
modifying it is possibly equivalent to an operation.  But see above.

Nico

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 13 Jun 2012 17:31:40 -0700

> feature in stopping password guessing attacks.

The Kerberos admin may not get a choice.  There are lots of N-strikes--- requirements out there.  If you can't support the requirement maybe you have to use a different technology.

In other words, maybe slow-down is the right solution, but maybe N-strikes--- is the required solution.  At least the data model, if not all implementations, should support both solutions, and hopefully others as well.

There appears to be consensus for defining some generic statistics the model could expose, and leaving the actual interpretation and resulting actions to the specific implementations?  (Except that an unlock action is clearly needed.  I'd generalize that to something that can clear an intentional slow-down as well.)
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Jun 2012 20:29:16 -0500

> The Kerberos admin may not get a choice.  There are lots of N-strikes--- requirements out there.  If you can't support the requirement maybe you have to use a different technology.

As a reputable standards development organization we get a say, and as
a result we get to influence the situation and perhaps improve the
admin's ability to resist this bit of cargo cult.

(I know of several places where log/audit analysis is used to
heuristically detect and respond to password guessing attacks in
better ways than locking the hapless user.  And they do this *in
spite* of putative requirements to implement N-strikes-you're-locked.
When you dig you find that either what's required is a mitigation of
password guessing attempts, or that alternative solutions are
acceptable.)

> There appears to be consensus for defining some generic statistics the model could expose, and leaving the actual interpretation and resulting actions to the specific implementations?  (Except that…

It's not yet clear to me that there's a consensus that we should do
anything in particular regarding N-strikes-you're-locked.

I'd be happy with any of these results, in order of preference:

 - We say no to N-strikes-you're-locked, but possibly list some
   things that implementations might do to detect and respond
   to password guessing attacks.

 - We discourage N-strikes-you're-locked, but ...

 - We specify OPTIONAL interfaces for dealing with
   N-strikes-you're-locked and explain why they are optional.

 - We say nothing at all about N-strikes-you're-locked, but
   possibly specify a locked attribute.

We are making progress on my objection to atomicity requirements, at
least, but I'd like us to also address my objection to
N-strikes-you're-locked.

Nico

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 13 Jun 2012 19:35:17 -0700

> admin's ability to resist this bit of cargo cult.

To some extent anyway.

> anything in particular regarding N-strikes-you're-locked.

I think there is at least consensus that it isn't the only solution.  Possibly I'm reading too much into lack of objection to alternatives.

>   N-strikes-you're-locked and explain why they are optional.

I think I'm voting for something between this and the next.

Define several optional statistics.  If the right ones are implemented, then you can do N-strikes---.  If you choose a different (hopefully overlapping) set, you can do something else.

Also provide an unlock/un-slow operation.  Our operations folk expect to be able to inspect if a user is locked (slowed?), so I'd vote for that to be readable, not only writable.

Question:  Should the "slowed" attribute be a number instead of a boolean like "locked"?  Should it be defined to be something different at all?

Another question:  Can anyone think of some other behavior that deserves discussion?  "Send warning notice if used" maybe?

Just asking.  I think I'm getting a bit too speculative.  I think I vote for just a reset operation that clears the response to the statistics, and clears (some of?) the statistics.  I think what we should worry about is what kind of statistics make sense, which includes what can be reliably exposed without requiring global KDB synchronization.

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Jun 2012 21:56:09 -0500

> Define several optional statistics.  If the right ones are implemented, then you can do N-strikes---.  If you choose a different (hopefully overlapping) set, you can do something else.

The problem with this is that there's a lot of stats that an
implementation could produce, but the KDC data model barely touches on
that, and if all it covers is a failed auth count with limited
semantics, well, then it's rather lame.  I'd much rather think about
what we want generically for stats out of a KDC.  I've been wanting
(and developed) some schemas based on aggregations of log data and
having that replicated so all log entries are properly aggregated and
made available at least on a master KDC.  This is a much saner
architecture that, among other things, might make it much easier to
heuristically detect password guessing attacks.  But so far we've not
even broached that subject (just did!).

> Also provide an unlock/un-slow operation.  Our operations folk expect to be able to inspect if a user is locked (slowed?), so I'd vote for that to be readable, not only writable.

Yes, of course.

> Question:  Should the "slowed" attribute be a number instead of a boolean like "locked"?  Should it be defined to be something different at all?

It should probably be a rate expressed in pre-auth attempts per unit
of time.  (This should not be locally adjusted for number of KDCs
because that presumes knowing how many KDCs there are, which may not
always be easy to determine.)

> Another question:  Can anyone think of some other behavior that deserves discussion?  "Send warning notice if used" maybe?

That's the main alternative I've seen used.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 14 Jun 2012 00:50:10 -0700

It occurs to me that in the process of dealing with Nico's global atomicity issue, that we've invented another KDB characteristic that's just as alien to current implementations: a partitioning between some as-yet hypothetical local statistics data, and the ordinary global data.  I don't think we intended to diverge from existing practice that far.

One resolution would be to simply declare that global usage statistics are out of scope for this document.  They're probably collected by some external log-watcher system anyway.

On Jun 13, 2012, at 7:56 PM, Nico Williams wrote:

> what we want generically for stats out of a KDC.  

Agreed.

> I've been wanting

Multi-KDC aggregations of log data sounds like something that's out-of-scope.  (Useful, but out-of-scope.)  The question is what kinds of things make sense inside a KDC.

Or are you arguing that *all* the useful statistics are in that category?  In which case the only thing that goes in the model are the lock/rate-limit control knobs?  (Hence the comment I just added at the top.)

> always be easy to determine.)

So that's an allowed rate (which nobody implements yet) and separately a locked boolean.  A KDC must provide at least one of the two?  (Anything else?)

> That's the main alternative I've seen used.

Make it a boolean named "honeypot".  ;-)

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Jun 2012 12:40:39 -0500

> One resolution would be to simply declare that global usage statistics are out of scope for this document.  They're probably collected by some external log-watcher system anyway.

I'm OK with just this one small set of stats (for N-strikes) provided
they are OPTIONAL.

> Or are you arguing that *all* the useful statistics are in that category?  In which case the only thing that goes in the model are the lock/rate-limit control knobs?  (Hence the comment I just adde…

Well, I am, but I'm willing to have just the failed login attempts
stats in this I-D as OPTIONAL.  But really I think what we're asking
KDC implementors to do is exactly that: to implement an architecture
for statistics collection and aggregation.  I think that's a very
desirable thing (unlike atomicity!) but I do not like merely implying
this.

> So that's an allowed rate (which nobody implements yet) and separately a locked boolean.  A KDC must provide at least one of the two?  (Anything else?)

Yes.  But I'll note that there are difficulties in implementing an
allowed rate knob, as that requires some keeping state on each KDC
(and it has to be available in a synchronized way if the KDC is
multi-processed/threaded).  And the naive approach of delaying AS-REPs
doesn't work -- the KDC has to respond with KRB-ERROR or drop the
AS-REQ when the rate of requests goes up.  A client might want to get
an error telling it to slow down.

Nico

---

From: Luke Howard <[email-masked]>
Date: Fri, 15 Jun 2012 16:51:41 +1000

> It occurs to me that in the process of dealing with Nico's global atomicity issue, that we've invented another KDB characteristic that's just as alien to current implementations: a partitioning bet…

Well, the MIT account lockout implementation uses non-replicated attributes for failed login attempts, etc, similar to AD.

-- Luke

---

From: Leif Johansson <[email-masked]>
Date: Fri, 15 Jun 2012 09:58:56 +0200

Interesting discussion. I'm not sure where this leaves us though.

Does anyone have text or at least a semi-concrete proposal?

	MVH leifj

---

From: "Henry B. Hotz" <[email-masked]>
Date: Sat, 16 Jun 2012 01:15:17 -0700

I think the concrete proposal is that 1) we not define any statistics in the model.  2) We define a locked flag.  3) We define a read and a reset operation for it.

Fuzzier:  We also define some kind of rate-limit as an optional alternative to the locked flag?

Maybe a sentence or two summarizing this discussion and why we left the statistics data out?

On Jun 15, 2012, at 12:58 AM, Leif Johansson wrote:

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk/a60AACgkQ8Jx8FtbMZnfR8wCeLX9g9ewfkJKAcEsvVeUqDTlx
> QAYAnRre4kMqCbfHbG6WN3gVet70T+iu
> =l1/s
> -----END PGP SIGNATURE-----

---

From: Sam Hartman <[email-masked]>
Date: Fri, 22 Jun 2012 12:36:00 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> At most?  As long as it isn't "at least".

    >> Same deal with timestamp of last successful/unsuccessful/attempt.

<hat role="individual">
I'm actually quite uncomfortable standardizing three sets of semantics
here.
That doesn't provide a very reasonable management experience. Given the
number of KDC implementations out there, it effectively means that there
will be no interoperability.
If we can't narrow beyond that, why not drop the feature  as something
where we cannot agree on standard behavior?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Fri, 22 Jun 2012 13:23:46 -0500

I care for the minimum interop we can get here without being too
prescriptive w.r.t. implementation.  I don't mind saying that there must be
a read-write lock attribute that can be used to unlock principals locked by
N-strikes.  I don't mind saying that there may be (MAY, not SHOULD, and
certainly not MUST, implement on the server side) a read-only strike-count
attribute (clients can be required to implement, but not servers, or if
they can be required to  then they must explicitly be allowed to not
support N-strikes.  I'm also OK with a variety of other optional attributes
(again ,perhaps must implement for clients, but not servers) for the
alternative policies that we discussed.

Nico

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 22 Jun 2012 14:36:07 -0400

On Fri, 2012-06-22 at 13:23 -0500, Nico Williams wrote:
> prescriptive w.r.t. implementation.  I don't mind saying that there
> must be a read-write lock attribute that can be used to unlock
> principals locked by N-strikes.

That's too strong.  It presumes that such a policy is implemented and in
use.  Also, the reason I suggested that such an attribute might be
write-only is that in an implementation where lockout is done
independently by each KDC, it may not be possible for any one entity to
tell you whether a principal has been locked out.

>   I don't mind saying that there may be (MAY, not SHOULD, and
> certainly not MUST, implement on the server side) a read-only
> strike-count attribute (clients can be required to implement, but not
> servers, or if they can be required to  then they must explicitly be
> allowed to not support N-strikes.  I'm also OK with a variety of other
> optional attributes (again ,perhaps must implement for clients, but
> not servers) for the alternative policies that we discussed.

I suggested three specific attributes, with specific semantics.  In my
proposal, each of these would be read-only and optional.  The idea here
is that KDCs would implement the attributes corresponding to the
counters they actually have, which probably means at most one of the
three counters I described.  Clients, of course, would have to support
all three, so as to be able to report this information.  The reason for
having three separate attributes is so that clients can tell, based on
which attribute is reported, what the value means.

Note again that this is about management.  Nothing should be required
here unless it is something that actually needs to exist and be exposed
for management and monitoring _for every KDC_.  So, don't require an
attribute that makes sense only if the KDC implements some particular
policy.

-- Jeff

---

From: Nico Williams <[email-masked]>
Date: Fri, 22 Jun 2012 13:57:48 -0500

Jeff, I re-read your proposal and I agree with it, except that I think
it's desirable to be able to lock users, so the lock attribute may be
read-write in my view.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 22 Jun 2012 15:20:57 -0400

> it's desirable to be able to lock users, so the lock attribute may be

MAY be read-write or write-only
MAY only support writing 'false'

Depending on what the server supports, that might be all that is
possible.

---

From: Leif Johansson <[email-masked]>
Date: Sun, 24 Jun 2012 09:41:23 +0200

On 06/22/2012 06:36 PM, Sam Hartman wrote:

I agree. It seems clear to me (as an editor) that we don't have clear
consensus to add this feature.

---

From: Leif Johansson <[email-masked]>
Date: Sun, 24 Jun 2012 09:41:23 +0200

On 06/22/2012 06:36 PM, Sam Hartman wrote:
> <hat role="individual"> I'm actually quite uncomfortable 
> standardizing three sets of semantics here. That doesn't provide a 
> very reasonable management experience. Given the number of KDC 
> implementations out there, it effectively means that there will be 
> no interoperability. If we can't narrow beyond that, why not drop 
> the feature  as something where we cannot agree on standard 
> behavior?

---

From: Nico Williams <[email-masked]>
Date: Sun, 24 Jun 2012 13:42:32 -0500

What's wrong with Jeff's proposal?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Mon, 25 Jun 2012 12:52:51 +0200

> What's wrong with Jeff's proposal?

The lack of a clearly formulated change proposal for which there
is clear consensus.

I'm not saying we can't get to consensus on this point!

I'm saying we're not there yet and I couldn't see that Jeffs
proposal had much more support than any of the other ideas that
have been floated in this tread.

	Cheers Leif

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Jun 2012 08:25:52 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> What's wrong with Jeff's proposal?
    Nico> _______________________________________________

With my chair hat on, I don't think we have consensus.
I think I see you and Jeff supporting; myself with concerns and don't
think I've seen any other comments expressing support or lack.

With my individual hat on, I'm concerned because it does not promote
interoperability.
Jeff proposes to have  about as many standardized attributes as there
are likely to be implementations in an ideal world, all of them
optional.
How likely are people to implement enough of the various options that we
get value from standardization?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Sun, 24 Jun 2012 13:35:41 -0500

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 25 Jun 2012 11:41:06 -0400

> With my chair hat on, I don't think we have consensus.

FWIW, at this point, I agree.

> get value from standardization?

That's a valid point.  What I _don't_ want to see is a single attribute
with vaguely-defined semantics, such that every KDC implementation
includes the attribute but they all mean something different with no way
to tell what is meant.  I'd rather not have a standardized attribute at
all then end up in that situation.

I think we have agreement that we don't expect attributes exposing the
state of a lockout or throttling mechanism to be writeable (with the
possible exception of a "locked" attribute that could be used to reset
the entire state).  So, any such attributes...

1) are for information only
2) are not needed to manage the lockout/throttling mechanism
3) are not needed to implement any part of the Kerberos specifications.

Thus, I would not object to dropping them entirely.

I do think this discussion has uncovered a need for a means to tell
whether a principal has been locked out, and to reset such a lockout.  I
feel like those would not be unreasonable things to include in a
standard data model, though they should of course be optional, since a
KDC might not implement a lockout mechanism.

-- Jeff

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Jun 2012 10:48:40 -0500

> With my chair hat on, I don't think we have consensus.

Who's against?

> think I've seen any other comments expressing support or lack.

Sure, let's ask.

> With my individual hat on, I'm concerned because it does not promote

Not so.  It requires that clients implement multiple approaches, but
they're all trivial for clients to implement as it's all plain
attributes.  The servers can which which if any to implement.  Interop
is guaranteed.

> are likely to be implementations in an ideal world, all of them

No, all required for the client to implement, but all optional for the
server to implement.

Nico

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Jun 2012 11:21:04 -0500

> Thus, I would not object to dropping them entirely.

I'd rather have at least an attribute by which to force unlock.
Otherwise we'll not be able to have a standard administration client
that can take care of this very important task of unlocking users
(which, of course, can only happen if the KDC implementation supports
N-strikes and, for whatever silly reason, has it enabled).

But I agree with you that we do not want a single attribute with
vaguely-defined semantics.  If we can't get consensus at all then by
all means, let's drop the feature.

Nico

---

From: Sam Hartman <[email-masked]>
Date: Mon, 25 Jun 2012 12:39:48 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> That's a valid point.  What I _don't_ want to see is a single attribute
    Jeffrey> with vaguely-defined semantics, such that every KDC implementation
    Jeffrey> includes the attribute but they all mean something different with no way
    Jeffrey> to tell what is meant.  I'd rather not have a standardized attribute at
    Jeffrey> all then end up in that situation.

I agree with the above.

    Jeffrey> I think we have agreement that we don't expect attributes exposing the
    Jeffrey> state of a lockout or throttling mechanism to be writeable (with the
    Jeffrey> possible exception of a "locked" attribute that could be used to reset
    Jeffrey> the entire state).  So, any such attributes...

Hmm.  Another concern I have mostly about process is that this seems
like a very late point in the process to be introducing the concept of
read-only attributes into the information model.
It seems like working through the semantics of that could be tricky. 

In another message, Nico said that it seems important to have a way to
unlock a principal.
I agree with that; that seems fairly important functionality to have
standardized admin clients.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 26 Jun 2012 00:48:13 -0400

> It seems like working through the semantics of that could be tricky. 

Actually, the more I think about that, the more I agree.  So far, we've
stuck more or less to modeling data the KDC actually has and maintains
and that one would reasonably expect to be able to modify via some sort
of administrative interface.  Adding what are essentially counters and
statistics might be useful for various purposes, but it is semantically
very different from what we've done so far.

I think perhaps it might be best to leave such properties for later.

> standardized admin clients.

I agree.

-- Jeff

---

From: Leif Johansson <[email-masked]>
Date: Tue, 26 Jun 2012 11:57:56 +0200

On 06/25/2012 06:39 PM, Sam Hartman wrote:
> Jeffrey> That's a valid point.  What I _don't_ want to see is a
> single attribute Jeffrey> with vaguely-defined semantics, such that
> every KDC implementation Jeffrey> includes the attribute but they
> all mean something different with no way Jeffrey> to tell what is
> meant.  I'd rather not have a standardized attribute at Jeffrey>
> Jeffrey> I think we have agreement that we don't expect attributes
> exposing the Jeffrey> state of a lockout or throttling mechanism to
> be writeable (with the Jeffrey> possible exception of a "locked"
> attribute that could be used to reset Jeffrey> the entire state).
> So, any such attributes...
> 
> 
> Hmm.  Another concern I have mostly about process is that this
> seems like a very late point in the process to be introducing the
> concept of read-only attributes into the information model. It
> seems like working through the semantics of that could be tricky.
> 
> In another message, Nico said that it seems important to have a way
> to unlock a principal. I agree with that; that seems fairly
> important functionality to have standardized admin clients.

I agree with all of the above. It seems to me that one way to proceed
is to bake 1.0 now and start work on a next revision where we work out
the details of access-levels on attributes, atomicity etc assuming
there is enough comitment to do so from the WG.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Tue, 26 Jun 2012 11:59:34 +0200

>> I think I see you and Jeff supporting; myself with concerns and
>> don't think I've seen any other comments expressing support or
>> lack.
> 
> Sure, let's ask.

Fair enough. Why don't you propose text and ask the WG for support?

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 Jun 2012 06:57:03 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

Given that, a minimalist approach would be to:

Mark 4.1.1.5 through 4.1.1.8 as OPTIONAL.

* Add a note to 4.1.1.4 indicating that schemas MUST have a mechanism
  for re-enabling a principal that has been disabled through operational
  mechanisms such as account lock out.

Rationale: Nothing in 4.1.1.5-8 actually talks about account lock
out. This discussion has actually made it clear that these attributes
are kind of useless for account lock out mechanisms.  We could remove
them; I don't object to that, but doing so is unnecessary given anything
in this discussion.  A schema might decide they are useless or too hard
to implement.

Specifying how you re-enable a principal is tricky and schema-dependent
so we should leave it to schemas but mandate that it must be possible.

I'm not particularly attached to this proposal. It's simply intended to
be something that minimally changes the document and responds to
comments made here. I certainly have no objection to it, but would be
happy with other options to.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Tue, 26 Jun 2012 13:16:50 +0200

On 06/26/2012 12:57 PM, Sam Hartman wrote:
> * Add a note to 4.1.1.4 indicating that schemas MUST have a
> mechanism for re-enabling a principal that has been disabled
> through operational mechanisms such as account lock out.

ftr I'm fine with this

---

From: Greg Hudson <[email-masked]>
Date: Tue, 26 Jun 2012 10:51:30 -0400

> Mark 4.1.1.5 through 4.1.1.8 as OPTIONAL.

I would rather remove them than have text which we expect most people to
ignore.  But if there isn't consensus for that, I'm minimally okay with
marking them as optional.

>   mechanisms such as account lock out.

Do we need to be prescriptive about this here?  I don't understand this
draft to be a general requirements document for an admin protocol.  If
we still believe we want an unlock operation when we're writing a
schema, we can put it in.

At the moment I'm against this part.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 Jun 2012 11:15:59 -0400

>>>>> "Greg" == Greg Hudson <[email-masked]> writes:

    >> Mark 4.1.1.5 through 4.1.1.8 as OPTIONAL.

    Greg> I would rather remove them than have text which we expect most people to
    Greg> ignore.  But if there isn't consensus for that, I'm minimally okay with
    Greg> marking them as optional.

Can I get comments on this?

    >> mechanisms such as account lock out.

    Greg> Do we need to be prescriptive about this here?  I don't understand this
    Greg> draft to be a general requirements document for an admin protocol.  If
    Greg> we still believe we want an unlock operation when we're writing a
    Greg> schema, we can put it in.

This was intended to be responsive to a concern raised by Nico supported
by Jeff and myself.
I'll let Nico and Jeff speak and am fine as an individual if the WG
decides not to address this but would prefer it be addressed.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Tue, 26 Jun 2012 10:32:20 -0500

> marking them as optional.

What text would get ignored?

> At the moment I'm against this part.

This is a good point.  This document does not set out requirements for
an admin protocol.  Of course, it's possible to do quite a bit of
administration through just a schema (see, for example, Windows, and
also Heimdal's kadmin client, which can talk to AD via LDAP).  But
some operations are beyond the reach of a schema.  I'm willing to
consider principal unlock to be such an operation, but then I think
I'd really like to just remove all attributes related to failed
authentication attempts as those too imply more semantics than just
reading some data in a directory.

Nico

---

From: Leif Johansson <[email-masked]>
Date: Tue, 26 Jun 2012 17:34:27 +0200

On 06/26/2012 05:15 PM, Sam Hartman wrote:
> Greg> I would rather remove them than have text which we expect
> most people to Greg> ignore.  But if there isn't consensus for
> that, I'm minimally okay with Greg> marking them as optional.
> 

I disagree. Optional attributes are perfectly reasonable and they
serve as important advise on how to implement an attribute should
you choose to do so.

---

From: Greg Hudson <[email-masked]>
Date: Tue, 26 Jun 2012 12:12:55 -0400

> What text would get ignored?

I expect 4.1.1.5 in its current form wouldn't be interesting to any
schema or KDC implementations.  I expect 4.1.1.6 and 4.1.1.7 to be
ignored by any schema or implementation not trying to do AD-style
n-strikes lockout.

(I'm not sure why Sam included 4.1.1.8 in his proposal.  Last key change
time seems unrelated to lockout.)

If we think a schema document is likely to include attributes designed
to allow n-strikes lockout, then we should modify 4.1.1.5 (perhaps just
removing the last sentence) and leave in 4.1.1.6 and 4.1.1.7.  But the
recent conversation suggests that we are not especially likely to do
that, in which case the text of 4.1.1.5-7 serves no purpose.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Tue, 26 Jun 2012 11:21:49 -0500

> ignored by any schema or implementation not trying to do AD-style

I agree about 4.1.1.5.  Just remove it.  I don't mind specifying
attributes that only some server implementors will implement.

> that, in which case the text of 4.1.1.5-7 serves no purpose.

I'm OK with removing these.  And if there's objections to a
principalLocked attribute, then I definitely want these attributes
gone.

Nico

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 26 Jun 2012 15:54:57 -0700

I'm in favor of a "locked" attribute, and a reset operation.  There's clearly no consensus for anything beyond that.

---

From: Nico Williams <[email-masked]>
Date: Tue, 26 Jun 2012 18:31:42 -0500

> I'm in favor of a "locked" attribute, and a reset operation.  There's clearly no consensus for anything beyond that.

This I-D does not specify operations though.  That's Greg's point.  So
we can't specify an operation.  A locked attribute that can be cleared
is close enough to not an operation, except for the possible need to
clear counters (which I'm willing to swallow).

Note though that no consensus for anything in this case means
consensus to remove all traces of N-strikes in this I-D.  I can very
much live with that.  (Nay, I want the RFC to say that N-strikes is
really not what you want, ever, but I'm willing to settle for a
picture of the moon.)

Nico

---

From: Leif Johansson <[email-masked]>
Date: Wed, 27 Jun 2012 11:42:11 +0200

On 06/26/2012 06:21 PM, Nico Williams wrote:
>> I expect 4.1.1.5 in its current form wouldn't be interesting to
>> any schema or KDC implementations.  I expect 4.1.1.6 and 4.1.1.7
>> to be ignored by any schema or implementation not trying to do
>> AD-style n-strikes lockout.
> 
>> If we think a schema document is likely to include attributes
>> designed to allow n-strikes lockout, then we should modify
>> 4.1.1.5 (perhaps just removing the last sentence) and leave in
>> 4.1.1.6 and 4.1.1.7.  But the recent conversation suggests that
>> we are not especially likely to do that, in which case the text
>> of 4.1.1.5-7 serves no purpose.
> 

Now I'm confused. Detecting that a principal is locked (remember that
the spec is silent on ro vs rw) is not in any way related to n-strikes.

I still argue that the simplest change is to make 4.1.1.5-7 OPTIONAL.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 27 Jun 2012 09:27:38 -0400

>>>>> "Henry" == Henry B Hotz <[email-masked]> writes:

    Henry> I'm in favor of a "locked" attribute, and a reset operation.  There's clearly no consensus for anything beyond that.
    Henry> On Jun 26, 2012, at 9:21 AM, Nico Williams wrote:

I'm much more comfortable saying that schemas must have a way to unlock
than I am introducing a locked attribute.  My rationale is that it ducks
the attribute vs operation question to the schema where it belongs.

I am OK with a locked attribute.
I'm OK removing all mention of this stuff.
I'm OK making stuff optional.