[standards-jig] A late security comment on JEP-0020
iainshigeoka at yahoo.com
Wed May 15 17:50:48 UTC 2002
On 5/15/02 10:27 AM, "Paul Lloyd" <paul_lloyd at hp.com> wrote:
> I'd like to make on comment on the negotiation feature presented in JEP-0020.
> The examples are interesting because they present the negotiation of
> various security related algorithms/properties. Unfortunately, the
> protocol is at odds with current accepted practices for the
> negotiation of such items because the values are not protected
> in any way, cryptographically or otherwise; one result of this lack
> of protection is that an active attacker can launch a downgrade attack.
I agree completely. The tension is between security and ease of use.
Ideally security shouldn't even be negotiated as such. Just knowing what
types of security is available on the server or the client can tell an
attacker a lot about how to break in. I had proposed that the client just
start authenticating using some arbitrarily high security method. The
server returns an error either if the security method is unsupported or if
the authentication failed (but without giving information which was the
cause). The client, either "knows" it has the right credentials and
downgrades its security method to try again, or the client has bad
This is like the issue of OS login screens presenting a list of valid user
names so the end user can just select it from the dropdown box and enter a
password. It obviously is very convenient but severely weakens the security
by eliminating a huge portion of the search space for potential attackers.
(that's why in unix they don't tell you if you entered an invalid password
or username... They just tell you one or both of them is wrong). In the same
manner, allowing negotiation of security protocols in the clear like this
In this case though, the server or client must simply be willing to accept
the lowest security option they allow to be negotiated. In other words, if
the server needs to be secure, it should only offer its secure auth
protocols so that any downgrade attacks simply aren't possible (at least
they won't degrade the security of the connection). If this isn't
acceptable, then the server should not support 0020 (its optional as is
everything in Jabber) and refuse to negotiate.
Despite my above comments (sounds like I like 0020 in auth), I am a _very_
staunch advocate of disallowing negotiation in security (perhaps a different
example should be used in the spec to discourage its use in auth). IMO, its
a bad idea...but I can see why people would want it.
More information about the Standards