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

Chris Newman <chris.newman@oracle.com> Fri, 30 April 2010 23:28 UTC

Return-Path: <chris.newman@oracle.com>
X-Original-To: yam@core3.amsl.com
Delivered-To: yam@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D1CD3A690B for <yam@core3.amsl.com>; Fri, 30 Apr 2010 16:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.146
X-Spam-Level:
X-Spam-Status: No, score=-4.146 tagged_above=-999 required=5 tests=[AWL=-1.900, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_38=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQ5XKTbfrNAw for <yam@core3.amsl.com>; Fri, 30 Apr 2010 16:28:49 -0700 (PDT)
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id A41CC3A6874 for <yam@ietf.org>; Fri, 30 Apr 2010 16:28:49 -0700 (PDT)
Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id o3UNSYdw025099 for <yam@ietf.org>; Fri, 30 Apr 2010 23:28:34 GMT
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-disposition: inline
Content-type: text/plain; CHARSET="US-ASCII"; format="flowed"
Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L1P00E00P93Z900@mail-amer.sun.com> for yam@ietf.org; Fri, 30 Apr 2010 17:28:34 -0600 (MDT)
Received: from [10.1.110.5] ([unknown] [10.1.110.5]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L1P000SFQJKAG90@mail-amer.sun.com> for yam@ietf.org; Fri, 30 Apr 2010 17:28:34 -0600 (MDT)
Date: Fri, 30 Apr 2010 16:28:32 -0700
From: Chris Newman <chris.newman@oracle.com>
Sender: Chris.Newman@Sun.COM
To: yam@ietf.org
Message-id: <4DE3D88239911A6791730051@96B2F16665FF96BAE59E9B90>
X-Mailer: Mulberry/4.0.8 (Mac OS X)
Subject: [yam] Interop problem: SMTP submission, STARTTLS, AUTH EXTERNAL
X-BeenThere: yam@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Yet Another Mail working group discussion list <yam.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/yam>
List-Post: <mailto:yam@ietf.org>
List-Help: <mailto:yam-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Apr 2010 23:28:50 -0000

Speaking as a technical participant, not a co-chair:

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:<cnewman@mydomain.example>
C: RCPT TO:<somebody@relaydomain.example>
<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:<cnewman@mydomain.example>
C: RCPT TO:<somebody@relaydomain.example>
<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.

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.

Pros: Doesn't alter the way SMTP relay authentication works (probably good 
since relay authentication is typically manually configured trusted peers). 
It's a clarification of a vague sentence.  Consistent with IMAP+STARTTLS 
and POP+STARTTLS.  Cons: some SMTP submission clients and servers that 
could be interpreted as compliant are now considered incompliant.  This 
change would occur in YAM and some could argue it should derail 4409 moving 
to full standard.

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 ;-).

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.

Comments?

		- Chris