--On May 6, 2010 10:44:37 -0400 "John R. Levine" <[email protected]> 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
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
