Re: [yam] Interop problem: SMTP submission, STARTTLS, AUTH EXTERNAL

[Chris Newman <[e-mail]>]

--On May 6, 2010 10:44:37 -0400 "John R. Levine" <[e-mail]> wrote:
>> I think this is totally an issue with AUTH EXTERNAL and worth mention in
>> an  update to that spec. However, I don't think it directly affects
>> 4409bis.
>>
>> Any other people's thoughts?

I respectfully disagree that this is an AUTH-only problem.  It is a problem 
that impacts implementations of SMTP+Submission+STARTTLS (without AUTH), 
smtps (without AUTH), SMTP+Submission+AUTH+STARTTLS and smtps+AUTH. 
Unfortunately the only protocol specification we have that applies to all 
four problem scenarios is RFC 4409 (its application to smtps is by virtue 
of the fact smtps is only used for submission because it can't be an MX 
target).

> Agreed.  Honestly, I don't understand what problem AUTH EXTERNAL is
> supposed to solve.  In the software I'm familiar with, any auth-age that
> AUTH EXTERNAL might do happens automatically, whether the client asks for
> it or not.

AUTH EXTERNAL solves two problems.

First, for protocols with an explicit state model (e.g. POP3 and IMAP4), it 
causes a state change from the not-authenticated state where the protocol 
starts to the authenticated state.  The state model is actually very 
helpful when writing security-sensitive software as the threat-surface of 
the protocol can be significantly reduced when in the not-authenticated 
state.  Having as few protocol commands as possible actually trigger a 
state change makes it simpler to verify correct implementation.  SMTP 
doesn't get this benefit as long as we support legacy submission, but 
Submission port 587 can have this benefit.

Second, AUTH EXTERNAL (or more specifically the SASL authorization ID 
feature present in mulitple SASL mechanisms) allows a feature I like to 
call "administrative proxy authentication" where an administrator or more 
likely an automated tool will use administrative credentials to 
authenticate as a specific user.  For example, in a unified messaging 
system the voice mail system may wish to clear the "seen" flag for the 
voice mail in a user's INBOX after it has played that information to the 
user over a telephone interface.  Arguably, the AUTH= parameter in the SMTP 
AUTH spec provides an alternative and perhaps better mechanism to do this 
for SMTP, although I've seen implementations that (incorrectly) claimed to 
implement SMTP AUTH and failed to implement the AUTH= parameter.

So I will accept an argument that AUTH EXTERNAL provides little value 
specifically to SMTP (beyond and explicit protocol indication that the 
client certificate was acceptable for SMTP-level authentication to the 
server, something that helps the client to produce better end-user 
diagnostics), which is why I proposed option 2.  But I do consider AUTH 
EXTERNAL an important mechanism in general.

		- Chris