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

"Henry B. Hotz" <[email protected]> Tue, 5 Jun 2012 17:58:33 -0700
Newsgroups gmane.ietf.krb-wg
Message-ID <[email protected]>
On Jun 4, 2012, at 6:20 AM, Sam Hartman wrote:

>>>>>> "Simo" == Simo Sorce <[email protected]> writes:
> 
> 
>>>> However assuming that this scheme is really preferred, then I do
>>>> not understand how it can be implemented if 4.1.1.5 says that the
>>>> counter should not be reset. I think implementations need to reset
>>>> it when a successful authentication happens. I think that should be
>>>> explicitly said, rather than a blanket 'SHOULD NOT reset'.
>>>> 
>>> 
>>> This was discussed in the WG. I don't think we should go back on that
>>> decision wo clear consensus.
> 
>    Simo> Point is, I am trying to understand what that paragraph means. As is
>    Simo> written I can't see how to implement something that works and respects
>    Simo> the letter of the document, feel free to explain to me what I am reading
>    Simo> wrong.
> 
> I'd like to ask the WG whether we want to support lockouts depending on
> how many failed authentications there have been since last successful
> authentication.

I, for one, have a generic expectation that that should be supported, however. . .

> I cannot think of a way to implement that consistent with the current
> text.

I am less than convinced that such behavior is necessarily efficiently implementable across multiple kdc's, or even "best".  

As a thought experiment, consider a proposal made by Howard Chu:  instead of a lockout, how about a slow-down?  The real purpose of the lockout is to make it uneconomic for a cracker to use the KDC as an oracle for a systematic search.  The existence of an ongoing cracking attempt does not mean the valid user no longer exists or no longer deserves service.  If you slow down responses to that username sufficiently, then the real user can still authenticate, but the cracker has still been thwarted.

I'm not making any specific recommendations, just providing a viewpoint.

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

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email protected], or [email protected]

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