Hi Chris,
At 04:28 PM 4/30/2010, Chris Newman wrote:
I've been dealing with client certificate authentication lately and
realized we have an interoperability problem with our
standards. For SMTP submission, when an end-user wishes to
authenticate using a client certificate, the protocol sequence to do
so is unclear.
This sequence works assuming the server enables SASL EXTERNAL and
the client implements it (not true of all deployed software):
====
C: EHLO ...
S: ...
C: STARTTLS
S: 220 2.5.0 Go ahead with TLS negotiation.
<negotiate TLS with client certificate>
C: EHLO ...
S: ...
S: 250-AUTH EXTERNAL ...
S: ...
C: AUTH EXTERNAL =
S: 235 2.7.0 EXTERNAL authentication successful.
C: MAIL FROM:<[email protected]>
C: RCPT TO:<[email protected]>
<relay is allowed>
====
This sequence of commands may or may not work but RFC 4409 section
4.3 can be interpreted to permit it assuming a client certificate
via TLS counts as "independently established authentication":
====
C: EHLO ...
S: ...
C: STARTTLS
S: 220 2.5.0 Go ahead with TLS negotiation.
<negotiate TLS with client certificate>
C: EHLO ...
S: ...
C: MAIL FROM:<[email protected]>
C: RCPT TO:<[email protected]>
<relay may or may not be allowed>
====
An SMTP submission client that implements only the latter will not
interoperate with an SMTP submission server that implements only the
former (and possibly vice versa if the client is unwilling to "just
try it" when AUTH EXTERNAL isn't there). One of these two cases
must be interpreted or declared not valid by the standards to
resolve the interoperability problem.
Section 3.3 of RFC 4409 discusses about authorized submissions. The
user may be authenticated using several methods.
Option 1: relevant to YAM -- Clarify 4409 section 4.3 to state that
providing client authentication during TLS does not constitute
"independently established authentication" because there is no
indication in the TLS layer whether that authentication was deemed
acceptable for SMTP submission authentication. Perhaps note as an
informational reference that "AUTH EXTERNAL" can be used to
determine the validity for that purpose.
SMTP AUTH is a MUST according to Section 4.3 but other types of
authentication are allowed. Section 4.1 of RFC 3207 mentions
authentication. In the above example there has been some level of
authentication. Option 1 gets into what constitutes authentication
and it's not a good idea to get into a discussion about it in RFC 4409.
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.
Pros: Doesn't break any clients. Cons: Some previously complaint
SMTP STARTTLS server implementations are declared incompliant
(including the shipping product from my company ;-).
The better place to add that is in a RFC about AUTH EXTERNAL. Don't
break existing implementations unless you really have to. :-)
Option 3: Incompatible change to RFC 3207 (SMTP STARTTLS) to declare
that client authentication provided via STARTTLS is not considered
valid authentication at the SMTP layer until the client issues an
"AUTH EXTERNAL" command.
Pros: Consistent with IMAP+STARTTLS and POP+STARTTLS. Cons: Some
previously compliant SMTP STARTTLS client and server implementations
are declared incompliant.
Section 4.3 of RFC 3207 mentions that:
"In fact, since the submission port is by definition not a publicly
referenced SMTP server, the STARTTLS extension can be particularly
useful by providing security and authentication for this service."
To summarize, the question is where to solve the problem. I don't
think that should be done in RFC 4409.
Regards,
-sm
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
