[yam] #22: RFC 4409 Interop problem: SMTP submission, STARTTLS, AUTH EXTERNAL

"yam issue tracker" <trac@tools.ietf.org> Thu, 06 May 2010 13:02 UTC

Return-Path: <trac@tools.ietf.org>
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 C0D633A6BBE for <yam@core3.amsl.com>; Thu, 6 May 2010 06:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.547
X-Spam-Level:
X-Spam-Status: No, score=-100.547 tagged_above=-999 required=5 tests=[AWL=-1.747, BAYES_50=0.001, J_CHICKENPOX_38=0.6, J_CHICKENPOX_48=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 7x2wmgbp3VDO for <yam@core3.amsl.com>; Thu, 6 May 2010 06:02:51 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 493BE3A6A73 for <yam@ietf.org>; Thu, 6 May 2010 06:01:17 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from <trac@tools.ietf.org>) id 1OA0hL-0002ho-V6; Thu, 06 May 2010 06:01:04 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: "yam issue tracker" <trac@tools.ietf.org>
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: sm+ietf@elandsys.com
X-Trac-Project: yam
Date: Thu, 06 May 2010 13:01:03 -0000
X-URL: http://tools.ietf.org/yam/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/yam/trac/ticket/22
Message-ID: <058.f5c198be4534e3786233e94af130b179@tools.ietf.org>
X-Trac-Ticket-ID: 22
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: sm+ietf@elandsys.com, yam@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: yam@ietf.org
Subject: [yam] #22: RFC 4409 Interop problem: SMTP submission, STARTTLS, AUTH EXTERNAL
X-BeenThere: yam@ietf.org
X-Mailman-Version: 2.1.9
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: Thu, 06 May 2010 13:02:52 -0000

#22: RFC 4409 Interop problem: SMTP submission, STARTTLS, AUTH EXTERNAL
-------------------------------------+--------------------------------------
 Reporter:  sm+ietf@…                |       Owner:     
     Type:  defect                   |      Status:  new
 Priority:  major                    |   Milestone:     
Component:  pre-evaluation-template  |     Version:     
 Severity:  -                        |    Keywords:     
-------------------------------------+--------------------------------------
 Interop issue posted by Chris Newman on April 30.

 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.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/yam/trac/ticket/22>
yam <http://tools.ietf.org/yam/>