Re: Comments: draft-siemborski-mupdate-04

[ned.freed@mrochek.com]

>    Turn off hyphenation.
>    In section 8.8, the protocol allows as list of authentication
> mechanisms, even if TLS is not in use.  Without the integrity provided by
> TLS, an adversary can reorder the list of mechanisms.  One solution would
> be to limit the list to a single item when TLS is not in use.
There's nothing in this draft, nor AFAIK in any other SASL-based protocol, that
says the order of the mechanism list is significant. The way SASL is supposed
to work is that the client examines the list of available and picks the most
appropriate one it supports. Authorization fails if that no appropriate
mechanisms are shared by the client and server.

Of course an active attacker can remove mechanisms from the list in an attempt
to trick the client into using inadequate security. This sort of downgrade
attack is dealt with either by using TLS (note that the capabilites must be
reacquired after TLS negotiation is done, and the draft, along with other
protocols that use SASL, specifies this) or by the client refusing to employ
inadequate mechanisms.

Attacks on the mechanism list are no different than in other application
protocols that employ SASL, including but not limited to IMAP4 itself. This
specific issue is described in the second paragraph of section 9 of RFC 2222,
the SASL specification.

I really don't see any problem here that needs to be addressed.

>    How was port 2004 assigned?
AFAIK it wasn't. The document requests that IANA assign a new port for MUPDATE
to use. Once that is done the reference to 2004 can be removed.

				Ned