--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).
While it would be a lot more convenient if this weren't the case, I have
to agree with Chris here.
> 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.
Agreed that this is a real and tangible 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.
The main problem with AUTH= seems to be that people don't have a clue how or
when to use it. I'd like to be able to blame this on the text in RFC 4954, but
when I read it I find very little to criticize. Perhaps an example in the
document showing how to use AUTH= for proxy authentication would help, but
regardless of the cause, deployment of this approach has been problematic,
whereas authorization IDs have been more successful.
I will say that any update to RFC 4954 needs to specifically address the
distinction between SMTP submission and relay.
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.
Agreed. I personally prefer to have a consistent approach across protocols,
which would argue for option 1 or 3, not 2, but I don't think the "it can all
be dealt with in an AUTH EXTERNAL update" idea passes technical muster.
Ned
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
