Re: [tram] Benjamin Kaduk's No Record on draft-ietf-tram-stunbis-16: (with COMMENT)

[Rohan Mahy <[e-mail]>]

I had a quick question about your comment on stale nonce error handling
(below).

If I were implementing, I would check if the nonce was fresh before
checking if the password was valid. Would this potential attack be
prevented if a stale nonce MUST return a 438 response whether or not the
password is correct?

Thanks,
-rohan
​

> The Stale Nonce behavior seems potentially worrisome, in that it
> opens up a side channel for a distinguishing attack,
> between a 401 and 438 response.  (That is, "password correct" vs.
> "password incorrect".)  The impact seems rather muted, though, since
> the gain to the attacker is to be able to precompute a bunch of
> requests using a nonce of the attacker's choosing and blindly replay
> the precomputed object against (possibly multiple) servers looking
> for a guess.  The realm and username are still in play, so the scope
> for the attacker to gain from the precomputation seems limited.
> (The same level of brute-force guessing can be obtained "live" just
> by computing the trial responses against a live server, using a
> valid nonce.)  So, while it might be nice to give guidance that 438
> should only be used when the server can validate that it did
> generate the nonce and the nonce was valid "recently", and to treat
> other cases as authentication failures, it's not clear to me that
> there's enough of a benefit from the change to make it worth doing.
>