On 12/01/2012 16:14, John C Klensin wrote:
--On Thursday, January 12, 2012 10:12 +0000 Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:
For example, is there an unofficial SMTP AUTH mechanism that
allows unencoded binary data in the challenges or responses?
A vendor controlling both the client and the server could
get away with something like that, but something
standards-based analyzing that traffic might be confused by
it.
All SASL exchange data in SMTP must be base64 encoded, so no
unencoded binary data can ever occur if IETF standards are
followed.
Alexey,
Hi John,
Yes, but I don't think that was Murray's question. SMTP AUTH
was originally designed in the absence of SASL. We hope all
non-SASL applications/implementations have disappeared, but I
wouldn't count on it. When we designed CRAM-MD5, we were at
least vaguely aware of an assortment of cookie/ shared
not-very-secret approaches floating around, some of which relied
on binary data. I hope those have disappeared too, but I have
no way to verify that they have.
What people forget as they quibble about the security properties
of CRAM-MD5 was that it was specified precisely to illustrate
that something was possible that would not require much more
server effort and support than plain-text passwords (a
requirement that Kerberos and assorted digital signature plans
could not satisfy) and that would be at least a tad more secure
against eavesdropping than either those passwords or [other]
cleartext shared secrets. Our goal wasn't "high security
mechanism" (we knew how to do those), but "significantly better
than clear text" and that largely to prove a point in the IETF.
But security by obscurity always has some appeal, especially
when eavesdropping in the transmission channel are not believed
to be issues, and old SMTP implementations tend to linger around
as long as they are still perceived as working (e.g., no new
feature appears that they don't have and that is considered
important). So I don't have much confidence that all of those
old cases have been eliminated and Murray's question, at least
as I understood it, starts me muttering about proving universal
negatives.
While what you say is possible (AUTH= hack is a proof), the requirement
for base64 encoding AUTH exchange comes from
draft-myers-smtp-auth-00.txt dated April 1995 (which later became RFC
2554). So it looks like binary data was never allowed in SMTP AUTH.
(In general SASL mechanisms can exchange arbitrary binary data. How such
data is transfered on the wire is defined by protocols that use SASL.)