Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-03.txt

From: [email-masked]
Date: Mon, 09 Mar 2015 14:32:41 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : Message Header Field for Indicating Message Authentication Status
        Author          : Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rfc7001bis-03.txt
	Pages           : 46
	Date            : 2015-03-09

Abstract:
   This document specifies a message header field called Authentication-
   Results for use with electronic mail messages to indicate the results
   of message authentication efforts.  Any receiver-side software, such
   as mail filters or Mail User Agents (MUAs), can use this header field
   to relay that information in a convenient and meaningful way to users
   or to make sorting and filtering decisions.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc7001bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-rfc7001bis-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rfc7001bis-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Mar 2015 14:34:38 -0700

>    or to make sorting and filtering decisions.

This is an attempt to address the concerns expressed, especially by John
Levine and Tom Petch.  John has seen it and says it resolves his concerns.
Everyone, and Tom in particular, do you agree that this is how it should
look?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 09 Mar 2015 18:31:39 -0400

On Monday, March 09, 2015 02:34:38 PM Murray S. Kucherawy wrote:
> >  This draft is a work item of the Applications Area Working Group Working
> > 
> > Group of the IETF.
> > 
> >         Title           : Message Header Field for Indicating Message
> > 
> > Authentication Status
> > 

Should RFC 6008 - https://tools.ietf.org/html/rfc6008 - also be listed in 
2.7.5?

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 09 Mar 2015 18:50:57 -0400

> Everyone, and Tom in particular, do you agree that this is how it should

I've either missed or forgotten the discussion that led to the proposal to 
change property for the "auth" Email Authentication Method to mailfrom.  SMTP 
auth doesn't authenticate the mail from, so I'm confused about the purpose of 
this change.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Mar 2015 16:01:59 -0700

> auth doesn't authenticate the mail from, so I'm confused about the purpose

It's a bit of a mistake, showing an incomplete review of SMTP AUTH on my
part.  I've never implemented SMTP AUTH, so I'm happy to yield to someone
who has, but here's what I ran into:

As I read RFC4954, SMTP AUTH can produce an authenticated author identifier
via either the MAIL FROM parameter or through the AUTH command itself.
Shouldn't A-R be able to report either or both?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Mar 2015 16:03:26 -0700

> Should RFC 6008 - https://tools.ietf.org/html/rfc6008 - also be listed in
Yes, it should be referenced.  I'll tidy that up for -04.  Thanks.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 09 Mar 2015 19:22:02 -0400

> Shouldn't A-R be able to report either or both?

I've never implemented SMTP AUTH either.  My reading of the RFC is that even 
when the AUTH value is tied to Mail From there's still an AUTH parameter the 
the authenticated identifier is tied to.  Here's the two examples in 4954:

5.1. Examples

   An example where the original identity of the sender is trusted and
   known:

   C: MAIL FROM:<e=[email-masked]> AUTH=[email-masked]
   S: 250 OK

   One example where the identity of the sender is not trusted or is
   otherwise being suppressed by the client:

   C: MAIL FROM:<[email-masked]> AUTH=<>
   S: 250 OK

I think the registry is correct as is, but I'd be interested to hear from 
people with actual implementation experience.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Mar 2015 16:41:29 -0700

> people with actual implementation experience.

RFC4954 says this about the MAIL FROM parameter you're referencing:

        If the AUTH parameter to the MAIL FROM command is not supplied,
        the client has authenticated, and the server believes the
        message is an original submission, the server MAY generate a
        <mailbox> from the user's authenticated identity for use in an
        AUTH parameter when relaying the message to any server which
        supports the AUTH extension.  The generated <mailbox> is
        implementation specific, but it MUST conform to the syntax of
        [SMTP <http://tools.ietf.org/html/rfc4954#ref-SMTP>].

To me that says if MAIL FROM doesn't include AUTH, then the server falls
back to using the client's authorization name (established by the earlier
AUTH command).  So it seems to me A-R might want to relay one or both of
those identities, since in theory at east the first is defined, and
possibly both, and they may not be the same.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 09 Mar 2015 21:49:40 -0400

On Monday, March 09, 2015 04:41:29 PM Murray S. Kucherawy wrote:
> > > As I read RFC4954, SMTP AUTH can produce an authenticated author
> > 
> > identifier
> > 

Except they are both auth and neither are the mail from identity.  I still 
don't see the need for a registry change.  Also, since that paragraph starts 
out "If the AUTH parameter to the MAIL FROM command is not supplied ..." I 
don't think you can have both.  It's either one you were provided or one you 
generated.

Scott K

Scott K

---

From: "John Levine" <[email-masked]>
Date: 10 Mar 2015 02:09:28 -0000

>> > change property for the "auth" Email Authentication Method to mailfrom.SMTP
>I've never implemented SMTP AUTH either.

I have, and I should have caught this.  Everyone who implements SMTP
AUTH implements the AUTH command with username and password
credentials, but I don't know anyone who implements the mailfrom auth=
parameter beyond perhaps ignoring it.

The interesting bit to record is smtp.auth with the username as the
value.  I think the official name for the username is the
authentication identity.

SASL allows much fancier credentials with certificates and such, but I
don't know anyone who implements that, either.  I believe that the few
people who do SUBMIT authentication with certs do it with a client cert
in the STARTTLS handshake.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Tue, 10 Mar 2015 09:58:24 -0700 (PDT)

> parameter beyond perhaps ignoring it.

We do. We provide a number of options for generating, consuming, and using this
information. And we have customers using it. Not a huge number, and not on the
open Internet where it's meaningless, but within an ADMD, absolutely.

OTOH, I can't recall a single instance of anyone wanting to generate an
Authentication-Results field from this information. Or any other information
internal to our MTA, for that matter. The only time we run into
Authentication-Results is when some other piece of software generates it and
Sieve scripts or whatever need to process it.

I'll also note that in this regard, the field has some fairly significant
semantic issues, such as there being no way to reliably tie it to a specific
DKIM result.

> value.  I think the official name for the username is the

But if you want to pass that information along from an ingress system
to another system along a trusted path, the MAIL FROM AUTH parameter is
the obvous way to do it.

> don't know anyone who implements that, either.

We do. And we have lots of customers using it. AUTH EXTERNAL in particular is a
requirement in quite a few places.

> I believe that the few

Which is then supposed to be bound to the session using AUTH EXTERNAL. Although
there's sufficient wiggle room in the specifications for this not to be a
requirement, which means you also need to support implicit binding.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 10 Mar 2015 13:34:15 -0400

> to another system along a trusted path, the MAIL FROM AUTH parameter is

I'd have no objection to allowing both smtp.auth and smtp.mailfrom ptypes. 
It'd be at worst harmless.

> requirement in quite a few places.

When someone uses AUTH EXTERNAL, is the authorized identity anything that 
couldn't be recorded in the smtp.auth clause?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Mar 2015 10:51:33 -0700

> semantic issues, such as there being no way to reliably tie it to a

That was fixed in RFC6008, I believe.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 10 Mar 2015 17:37:10 -0400

>It'd be at worst harmless.

Except the auth value in mail from auth isn't necessarily the same as the actual mail from. Reporting something as smtp.mailfrom that's not the actual mail from seems wrong to me.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 10 Mar 2015 15:19:27 -0700

On Tue, Mar 10, 2015 at 2:37 PM, Scott Kitterman <[email-masked]>
wrote:

> Except the auth value in mail from auth isn't necessarily the same as the
> actual mail from. Reporting something as smtp.mailfrom that's not the
> actual mail from seems wrong to me.
>

I think a result of "auth=pass smtp.mailfrom=foo@bar" resulting from MAIL
FROM:<x@y> AUTH=<foo@bar>" is unambiguous.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 10 Mar 2015 21:53:11 -0400

> FROM:<x@y> AUTH=<foo@bar>" is unambiguous.

I agree it's unambiguous.  I think it's ugly, but I can't find anything in the 
ABNF that strictly precludes it.  Please add an example to show this because I 
don't think it's at all obvious.

Scott K

---

From: Ned Freed <[email-masked]>
Date: Wed, 11 Mar 2015 18:21:05 -0700 (PDT)

> It'd be at worst harmless.

Seems reasonable.

> couldn't be recorded in the smtp.auth clause?

It's certainly possible in theory, but as a practical matter, there's usually
an identifier of some sort attached to the identity.

A better question, in the case of AUTH EXTERNAL, is whether there's a need
to log additional information. A fingerprint for the certificate that
was used comes to mind as a possibility.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 11 Mar 2015 21:48:06 -0400

> was used comes to mind as a possibility.

Since this is an expert review registry, how about just leaving it as is, 
and if someone actually starts logging fingerprints or whatever, encourage 
them to write in and we'll add it to the registry.

Regards,

---

From: t.petch <[email-masked]>
Date: Thu, 12 Mar 2015 11:42:35 +0000

Um

s 6.2 contains a lot of good information but I struggle to see an IANA
Consideration in there.  Is the intention that the reference for "Email
Authentication Methods" be updated to this I-D?   If so, I think that
that needs saying.
Also, if that is the only action, then again worth saying to stop IANA
ploughing through this lengthy section to try and find another action.
Also, registries can be very hard to find if you do not know the group
so again worth saying.

So I would start with

NEW
The "Email Authentication Methods" Registry  is part of the "Email
Authentication Parameters" group.  IANA is requested to update the
reference for that registry to point to this I-D.  That is the only
change requested by this section.

Tom Petch

----- Original Message -----
From: "Murray S. Kucherawy" <[email-masked]>
To: "IETF Apps Discuss" <[email-masked]>
Sent: Monday, March 09, 2015 9:34 PM
Subject: Re: [apps-discuss] I-D Action:
draft-ietf-appsawg-rfc7001bis-03.txt

> Everyone, and Tom in particular, do you agree that this is how it
should

------------------------------------------------------------------------
--------

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 12 Mar 2015 14:53:12 -0700

> change requested by this section.

That isn't quite the only change, but it's worth being explicit that this
is the new reference document.  I'll do that in -04.

Among other minor changes, this document now says explicitly that each
entry has to cover a unique method/ptype/property tuple (i.e., duplicates
aren't allowed).

-MSK

---

From: Ned Freed <[email-masked]>
Date: Thu, 12 Mar 2015 17:05:57 -0700 (PDT)

> them to write in and we'll add it to the registry.

That seems reasonable.

				Ned

---

From: Hector Santos <[email-masked]>
Date: Sat, 14 Mar 2015 18:53:36 -0400

Some comments

>     or to make sorting and filtering decisions.

For sentence #1,

      .... indicate the results
      of different message authentication efforts.

or

      .... indicate the results of any internal message
      authorization and authentication efforts.

I was under the impression that this header can only be "trusted" 
internally, essentially by the creator to be used by the backend 
"receiver-side" software or even at the UI hosted presentation?

The DKIM/ADSP/DMARC/SPF/OTHER machine domain host name creating this 
header needs to be trusted.

The main reason I say this is because the first time I began to use 
this for DKIM, I also used it for ADSP, Not SPF, nor ATPS.  SPF 
already had an internally produced and most importantly trusted result 
header (Received-SPF) and AUTH-RES wasn't quite ready to pass all the 
essential, different A/A protocol process parameters information being 
done, including SPF and ATPS.

So I created the fields I needed.   Since it would intended for 
internal consumption, other consumers like RFC-based Offline Mail 
Readers/Writers, these offline MUAs should not rely on it.

Is this still true?   If so, what are the rules for this?  How about 
different AUTH-RES from different processing host?

As a related tech note,  does the latest work reflect all the 
essential information needed for?

   DKIM
   DMARC
   SPF

Is it ready for indicating 3rd party results?

Does it still support ADSP or its obsolete in the new AUTH-RES as well?

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 14 Mar 2015 22:25:12 -0700

>      authorization and authentication efforts.

They're not necessarily internal checks (where "internal", I assume, means
"done by my ADMD").  You could decide to trust an upstream check from your
ISP, for example.

> "receiver-side" software or even at the UI hosted presentation?

No, that's never been the case.  Going back as far as RFC5451 Section 5,
we've always allowed for the possibility of trusting information from
outside.  You just have to decide you believe whatever the outside source
is telling you.

> header needs to be trusted.

Yes, that's the point, not that it has to be internal.

> The main reason I say this is because the first time I began to use this
> for DKIM, I also used it for ADSP, Not SPF, nor ATPS.  SPF already had an
> internally produced and most importantly trusted result header
> (Received-SPF) and AUTH-RES wasn't quite ready to pass all the essential,
> different A/A protocol process parameters information being done, including
> SPF and ATPS.
>

A-R predated ATPS, so they've always been compatible.  As for Received-SPF,
the whole reason this was introduced is because SPF created a header field
for recording its results, and DomainKeys proposed one as well.  Rather
than having a different one for every method, it made sense to create one
extensible one for this purpose.

> So I created the fields I needed.   Since it would intended for internal
> consumption, other consumers like RFC-based Offline Mail Readers/Writers,
> these offline MUAs should not rely on it.
>
> Is this still true?
>

If by "this" you mean internal consumption, then yes, mostly; it's intended
for consumption by downstream agents (filters and MUAs, mainly) that are
able to figure out which ones they believe.

> If so, what are the rules for this?
>

Several sections of RFC5451, such as 2.3, 4.1, and 7, talk about when and
how to consume the header field.  All of this is carried forward into
RFC7001 and now this document.

> How about different AUTH-RES from different processing host?
>

Same answer.

> As a related tech note,  does the latest work reflect all the essential
> information needed for?
>
>   DKIM
>   DMARC
>   SPF
>

Yes.

The only supported third-party reporting scheme is ATPS, but it hasn't seen
much in the way of real world deployment.  None of the others have
documents attaching them to Authentication-Results.

This draft doesn't cover them because ADSP was declared Historic.  However,
previous versions did, so "dkim-adsp" is still a registered method (though
it's marked "obsolete").  I think this draft should actually change their
entries to "deprecated".

-MSK