[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 <simo@xxxxxxxxxx> 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.