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

Alessandro Vesely <vesely@tana.it> Sun, 02 May 2010 12:54 UTC

Return-Path: <vesely@tana.it>
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 969343A698E for <yam@core3.amsl.com>; Sun, 2 May 2010 05:54:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.759
X-Spam-Level:
X-Spam-Status: No, score=-3.759 tagged_above=-999 required=5 tests=[AWL=-2.840, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, 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 ZnpZ8U5OYDXa for <yam@core3.amsl.com>; Sun, 2 May 2010 05:54:45 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 4E5363A69E9 for <yam@ietf.org>; Sun, 2 May 2010 05:54:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1272804864; bh=jYajmKcNLHYeUGldWTc5BiLZoj4tUuutvN+SI4LWM6M=; l=2155; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=DLYPfNRQx9uBDXA5xGultzoGkbUJ6evHkQta+1BbsT6qth11zXmGkPEXZSODEMu/c tw/hv56uJl6du1eMdI32/d48UksNW5dQqQUIB1PlCB6M85a9+0Z8U9hY23Sr08VQ6r xlRwO5p1j0Y2vTDAro4EgOAJtO7atm2NEAPR2dUo=
Received: from mach-4.local (93-32-132-43.ip33.fastwebnet.it [93.32.132.43]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 02 May 2010 14:54:24 +0200 id 00000000005DC035.000000004BDD7600.00001D6B
Message-ID: <4BDD762E.5020606@tana.it>
Date: Sun, 02 May 2010 14:55:10 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: yam@ietf.org
References: <4DE3D88239911A6791730051@96B2F16665FF96BAE59E9B90>
In-Reply-To: <4DE3D88239911A6791730051@96B2F16665FF96BAE59E9B90>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [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: Sun, 02 May 2010 12:54:46 -0000

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?