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

From: Sam Hartman <[email-masked]>
Date: Wed, 30 May 2012 14:29:48 -0400

[I'm going to forward Simo's original comments to the IETF list because
this doc is in IETF last call.
Here are my responses as chair.
]
>>>>> "Simo" == Simo Sorce <[email-masked]> writes:

    Simo> 4.1.1.5.  principalNumberOfFailedAuthenticationAttempts

    Simo>    This single-valued integer attribute contains a count of
    Simo> the number of times an authentication attempt was unsuccessful
    Simo> for this Principal.  Implementations SHOULD NOT allow this
    Simo> counter to be reset.

[. . .]

    Simo> They force a mechanism where you have a specific counter. It
    Simo> seems to prevent instead an implementation that may have a
    Simo> multi-valued attribute where all failed attempts are recorded
    Simo> in order to have an audit trail, and the number of failed
    Simo> attempts is computed by counting these values.

I think you'd also need to record last successful authentication.
However, given last successful authentication and  a set of failed
authentications I think it's  quite easy to give an algorithm for
producing count of failed authentications and  last failed
authentication.
It does mean that to increment the count of failed authentications you
need to decide on a time for the list of failed authentications.
I think  that's consistent with the information model though.

    Simo> However assuming that this scheme is really preferred, then I
    Simo> do not understand how it can be implemented if 4.1.1.5 says
    Simo> that the counter should not be reset. I think implementations
    Simo> need to reset it when a successful authentication happens. I
    Simo> think that should be explicitly said, rather than a blanket
    Simo> 'SHOULD NOT reset'.

There was WG discussion on this.
The text really means the count should be non-decreasing.
This  makes it impossible to implement a policy like 2 failed auths
since the last successful auth.

With my chair hat on, my reading of the discussion is that we really do
mean what the text says. However, I don't think the point about being
unable to track number of failed auths since last successful auth has
been brought up before and that point is sufficient to reopen the
discussion.