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?
Tony Hansen
[email protected]
On 5/2/2010 8:55 AM, Alessandro Vesely wrote:
Chris Newman wrote:
Option 1: relevant to YAM -- Clarify 4409 section 4.3 to state that
providing client authentication during TLS does not constitute
"independently established authentication" [...]
Pros: [...] Consistent with IMAP+STARTTLS and POP+STARTTLS.
Even if SUBMIT mandates authentication, it inherits the SMTP trust
model, which is different from that of IMAP and POP. Section 4.3 just
allows such compatibility. An historical trait.
Option 2: Incompatible change to RFC 3207 (SMTP STARTTLS) when an
SMTP client provides a client certificate the server deems valid for
authentication purposes, the server MUST enable the SASL EXTERNAL
mechanism (advertising it in EHLO and allowing it in AUTH). If the
client issues "MAIL FROM" without issuing an AUTH command in this
situation, the server MUST behave as if an implicit "AUTH EXTERNAL ="
was issued by the client.
This option may cause difficulties with the paragraph in rfc 4954 that
says
Restrictions:
After an AUTH command has been successfully completed, no more
AUTH commands may be issued in the same session. After a
successful AUTH command completes, a server MUST reject any
further AUTH commands with a 503 reply.
In case an implicit "AUTH EXTERNAL =" had been assumed by the server
when a previous transaction started, the client cannot repeat it for
the whole session. For an MTA, non-authenticated transactions are
allowed, so it may be unclear whether the server should assume it in
any case.
I note that SMTP-AUTH does not allow a client to query its current
authentication state, nor to learn what authorizations such state
implies (e.g. relaying, specifying trusted AUTH parameters.) I think
the problem you describe results from that design.
I'd agree if rfc4409bis will informatively mention that "AUTH EXTERNAL
=" may be used by a client to check the status of an independently
established authentication --in case the server has such mechanism.
Additionally, section 3.3 may want to mention client TLS certificates.
Would that bring any good?
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
