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

Ned Freed <ned.freed@mrochek.com> Thu, 06 May 2010 21:38 UTC

Return-Path: <ned.freed@mrochek.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 648B03A6934 for <yam@core3.amsl.com>; Thu, 6 May 2010 14:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.068
X-Spam-Level:
X-Spam-Status: No, score=-0.068 tagged_above=-999 required=5 tests=[AWL=-0.669, BAYES_50=0.001, J_CHICKENPOX_54=0.6]
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 shSGh5pmWWMJ for <yam@core3.amsl.com>; Thu, 6 May 2010 14:38:02 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 057CF3A6A35 for <yam@ietf.org>; Thu, 6 May 2010 14:37:54 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NMSSITBZHC00D4F8@mauve.mrochek.com> for yam@ietf.org; Thu, 6 May 2010 14:37:31 -0700 (PDT)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01NMSKWG951S0000BI@mauve.mrochek.com>; Thu, 06 May 2010 14:37:26 -0700 (PDT)
Message-id: <01NMSSIQ6LTO0000BI@mauve.mrochek.com>
Date: Thu, 06 May 2010 13:20:36 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Thu, 06 May 2010 08:45:41 -0700" <4BD612FD062FFBA59BA683A8@96B2F16665FF96BAE59E9B90>
MIME-version: 1.0
Content-type: TEXT/PLAIN; Format=flowed
References: <4DE3D88239911A6791730051@96B2F16665FF96BAE59E9B90> <4BDD762E.5020606@tana.it> <4BE2B8EC.8030201@att.com> <alpine.BSF.2.00.1005061043150.26027@joyce.lan> <4BD612FD062FFBA59BA683A8@96B2F16665FF96BAE59E9B90>
To: Chris Newman <chris.newman@oracle.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1273181433; bh=OfiBIQlyI+RHPDJJM3ji2ZhoYMc3Y4+Oy6H6XeozjOw=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=QPc4C0EzAMJhQwT0d0BxOwTkg+lOyP7cUxE5x2sxLF9l727xvhfScRrdEzWIhZLXs HLVdN1JNTp+8JBFpyUvfRn45SFd3OtrrTvN0PJdA528qFWFxQNrEa46vIVRlxUyuJp W09j5SkCi2tTj+x4lios8jvQolDgDqyyv3bi+epY=
Cc: yam@ietf.org
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: Thu, 06 May 2010 21:38:03 -0000

> --On May 6, 2010 10:44:37 -0400 "John R. Levine" <johnl@iecc.com> wrote:
> >> 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?

> I respectfully disagree that this is an AUTH-only problem.  It is a problem
> that impacts implementations of SMTP+Submission+STARTTLS (without AUTH),
> smtps (without AUTH), SMTP+Submission+AUTH+STARTTLS and smtps+AUTH.
> Unfortunately the only protocol specification we have that applies to all
> four problem scenarios is RFC 4409 (its application to smtps is by virtue
> of the fact smtps is only used for submission because it can't be an MX
> target).

While it would be a lot more convenient if this weren't the case, I have
to agree with Chris here.

> > Agreed.  Honestly, I don't understand what problem AUTH EXTERNAL is
> > supposed to solve.  In the software I'm familiar with, any auth-age that
> > AUTH EXTERNAL might do happens automatically, whether the client asks for
> > it or not.

> AUTH EXTERNAL solves two problems.

> First, for protocols with an explicit state model (e.g. POP3 and IMAP4), it
> causes a state change from the not-authenticated state where the protocol
> starts to the authenticated state.  The state model is actually very
> helpful when writing security-sensitive software as the threat-surface of
> the protocol can be significantly reduced when in the not-authenticated
> state.  Having as few protocol commands as possible actually trigger a
> state change makes it simpler to verify correct implementation.  SMTP
> doesn't get this benefit as long as we support legacy submission, but
> Submission port 587 can have this benefit.

Agreed that this is a real and tangible benefit.

> Second, AUTH EXTERNAL (or more specifically the SASL authorization ID
> feature present in mulitple SASL mechanisms) allows a feature I like to
> call "administrative proxy authentication" where an administrator or more
> likely an automated tool will use administrative credentials to
> authenticate as a specific user.  For example, in a unified messaging
> system the voice mail system may wish to clear the "seen" flag for the
> voice mail in a user's INBOX after it has played that information to the
> user over a telephone interface.  Arguably, the AUTH= parameter in the SMTP
> AUTH spec provides an alternative and perhaps better mechanism to do this
> for SMTP, although I've seen implementations that (incorrectly) claimed to
> implement SMTP AUTH and failed to implement the AUTH= parameter.

The main problem with AUTH= seems to be that people don't have a clue how or
when to use it. I'd like to be able to blame this on the text in RFC 4954, but
when I read it I find very little to criticize. Perhaps an example in the
document showing how to use AUTH= for proxy authentication would help, but
regardless of the cause, deployment of this approach has been problematic,
whereas authorization IDs have been more successful.

I will say that any update to RFC 4954 needs to specifically address the
distinction between SMTP submission and relay.

> So I will accept an argument that AUTH EXTERNAL provides little value
> specifically to SMTP (beyond and explicit protocol indication that the
> client certificate was acceptable for SMTP-level authentication to the
> server, something that helps the client to produce better end-user
> diagnostics), which is why I proposed option 2.  But I do consider AUTH
> EXTERNAL an important mechanism in general.

Agreed. I personally prefer to have a consistent approach across protocols,
which would argue for option 1 or 3, not 2, but I don't think the "it can all
be dealt with in an AUTH EXTERNAL update" idea passes technical muster.

				Ned