Re: Proprietary or non-standard SMTP AUTH mechanisms
Alexey Melnikov <alexey.melnikov <at> isode.com>
2012-01-12 17:31:19 GMT
On 12/01/2012 16:14, John C Klensin wrote:
> --On Thursday, January 12, 2012 10:12 +0000 Alexey Melnikov
> <alexey.melnikov <at> isode.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.)
RSS Feed