[Standards] LAST CALL: XEP-0205 (Best Practices to Discourage Denial of Service Attacks)
stpeter at stpeter.im
Thu Jan 22 19:15:25 UTC 2009
Proposed text at the bottom.
Peter Saint-Andre wrote:
> Alexey Melnikov wrote:
>> In Section 3, bullet 3 says:
>>> Limiting the number of authentication attempts for a given Jabber ID in a given time period.
>>> While such a limit may seem beneficial, in fact it might result in locking out the legitimate
>>> owner of a Jabber ID if a malicious entity attempts a large number of illegitimate
>>> authentication attempts for the Jabber ID; therefore such a limit is not recommended
>>> and it is instead recommended to limit the number of connections and connection
>>> attempts on a per-IP basis.
>> I think this text is also arguing against counting the number of
>> failed authentication attempts on a single connection, which is wrong.
>> Limiting the number of authentications on a single connection doesn't
>> result in lockout (the client can disconnect and reconnect) and it
>> only punishes malicious (or broken) clients. This is also much easier
>> to implement than a counter across multiple connections.
> If you have forgotten your password you might try to authenticate 3 or 4
> times before giving up.
> If I'm trying to hack your password (dictionary attack) I might try to
> authenticate 1000 times or whatever over some period of time.
> Therefore, allowing a reasonably number of authentication retries is a
> good idea but allowing an unreasonable number is a bad idea. For SASL,
> rfc3920bis says at least 2 and no more than 5 authentication retries per
> connection / stream:
> If one hits the SASL limit, the server would terminate the stream (SASL
> failure) and one would need to reconnect. Therefore, for a given
> connection or stream one would be allowed 3 to 6 auth attempts. If I
> want to hack your password, I'd need to "lather, rinse, repeat" (new
> stream, ~5 auth attempts, failure; new stream, ~5 auth attempts,
> failure; etc.). Therefore I would quickly accumulate connection attempts
> to hack your account, whereas if you forget your password then you might
> connect once or twice (~5 to ~10 auth attempts) then give up.
> I think we have consensu that such an approach is appropriate.
> Now, if I'm trying to DoS you then I could repeatedly do the
> connect+auth+retry dance until your account gets locked down.
> The question is, how does a server determine when to lock down an
> account? You seem to envision that lockout might happen based on
> exceeding some limit per time period for any of the following options:
> 1. authentication attempts per account
> 2. authentication attempts per IP address
> 3. connection attempts per account
> 4. connection attempts per IP address
> 5. simultaneous connections per account
> 6. simultaneous connections per account
> Currently XEP-0205 says a server could do #1 but the consequences might
> be a DoS against the legitimate user, so instead it recommends #4 or #6
> because the spec assumes that the attacker will come from a different IP
> address than the one used by the legitimate user. But #4 and #6 don't
> solve the problem that Waqas mentions (a DoS attack launched by someone
> from your same IP address, e.g. from behind the same NAT).
> I hope that clarifies the options, even if it doesn't describe a full
So I chatted about this with Alexey using a real-time communications
We concluded that we need to refer to Section 7.3.5 of rfc3920bis:
Therefore I would propose the following adjustment:
Limiting the number of authentication attempts for a given Jabber ID in
a given time period. While such a limit may seem beneficial, in fact it
might result in locking out the legitimate owner of a Jabber ID if a
malicious entity attempts a large number of illegitimate authentication
attempts for the Jabber ID; therefore such a limit is not recommended
*except as described in Section 7.3.5 of rfc3920bis*, and it is instead
recommended to limit the number of connections and connection attempts
on a per-IP basis.
This does not address the issue of whole countries behind NATs, for
which we might want to add a note in Section 4.2 of XEP-0205.
More information about the Standards