Re: [apps-discuss] The authentication server id, was rfc5451bis

Alessandro Vesely <vesely@tana.it> Tue, 26 March 2013 12:41 UTC

Return-Path: <vesely@tana.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F143721F8AE3 for <apps-discuss@ietfa.amsl.com>; Tue, 26 Mar 2013 05:41:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level:
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eADN3ejvB+q for <apps-discuss@ietfa.amsl.com>; Tue, 26 Mar 2013 05:41:14 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 841E521F8ACE for <apps-discuss@ietf.org>; Tue, 26 Mar 2013 05:41:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1364301671; bh=91H1aya8cVLAY3euL7gmY4zL9oulYLUjzl0JczwMvjo=; l=6961; h=Date:From:To:References:In-Reply-To; b=RgZTdpQp2dEydF2mPlJfS01WHM+59lKEfA4BWhSjF4AYDOlPdbBRpacDrW73TvW4x bFI+YGaA92fnkl29zYHPmLYIIY54CCRv4p6PetYW109ahZlcbujtC0pTeVEib8wqO5 X5128HP37xkU+BEabewNLfWnz35kde1UeLjReY8w=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Tue, 26 Mar 2013 13:41:11 +0100 id 00000000005DC047.0000000051519767.00005AF9
Message-ID: <51519767.4060808@tana.it>
Date: Tue, 26 Mar 2013 13:41:11 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <CAL0qLwbgjnt8Msofok3ExKBmChtQPfMEFgrrZBimEzU5CYgSjA@mail.gmail.com> <CAKHUCzxfBtLTt3p3moGgEQx+p5kr=-e2Mn58xaqNvWFGiW=Lpw@mail.gmail.com> <514432BC.1010805@tana.it> <51443483.9030805@tana.it> <CAKHUCzwBrEPSVc4VtJMKZLm+5it3h7dLiW+YZ=_xO2OwP_rLoA@mail.gmail.com> <51458A59.8040206@tana.it> <CAL0qLwYEe9Wmvr-+eZL_yqChRf+a+11zRXCmW2Md9PGvH9PK-g@mail.gmail.com> <514DFAC8.7040406@tana.it> <CAL0qLwbqNUbPOYbXQEzM6X4=RLiqCQG2TbsO9A8PaE+a3Z3oNQ@mail.gmail.com> <514EEBB7.40205@tana.it> <CAL0qLwZZ3iB1BwtfK6TxooEzbTwSxm-KZYgcMMdPUp3OyMpMag@mail.gmail.com> <515040D2.1080409@tana.it> <CAL0qLwa4+na-bAauXN1cySyxLxrKWETONcVLc-Ncf5tdyhY+4w@mail.gmail.com>
In-Reply-To: <CAL0qLwa4+na-bAauXN1cySyxLxrKWETONcVLc-Ncf5tdyhY+4w@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] The authentication server id, was rfc5451bis
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2013 12:41:15 -0000

On Mon 25/Mar/2013 19:54:25 +0100 Murray S. Kucherawy wrote:
> On Mon, Mar 25, 2013 at 5:19 AM, Alessandro Vesely <vesely@tana.it> wrote:
>> On Sun 24/Mar/2013 22:06:41 +0100 Murray S. Kucherawy wrote:
>>
>>> Since in the prose we talk about authserv-id being a domain
>>> name in the typical case but basically also say it could be
>>> anything the operator wants to use, I think "value" is the 
>>> right thing there.
>> 
>> Besides the parsability point (quotes), the intended use of this piece
>> of data is rather overloaded.  Let me recap some requirements:
>> 
>> 1. Identification of the ADMD for assessing trust relationships
>>    (and possibly also for POP3 MUAs to send back complaints,
>>    per Section 5.3 of RFC 6650),
> 
> I don't see a reference to this work there.

That possibility was voiced in the ASRG and elsewhere, but never
formalized --which is why I put it in parentheses.  AIUI, the
authentication server identifies the ADMD responsible for receiving a
message.  The means of identification, usually a registered domain
name, is consistent with the way each method identifies the ADMD(s)
responsible for /sending/ the message.

>> 2. uniqueness of the identifier,
> 
> This is key for identifying your own, but it doesn't speak to a
> necessary syntax.

I'm dumbfounded by that statement.  How can a piece of software be
configured by an ADMD so as to determine whether A-Rs "have been added
within its trust boundary"[Section 5] if that software is unable to
distinguish the server id from, say, the queue id?

>> 3. similar in syntax to a fully-qualified domain name,
> 
> There's nothing saying an ADMD can't use a simple word or even a
> single punctuation here (so long as it fits the grammar).  Ideally
> it's most useful when it's in this form, but an ADMD could use "---"
> as an authserv-id and still get results useful to it.

"---" doesn't match "domain-name".

> A complete sentence would also be valid.

If you use "value", yes.  However, the methods to determine whether
two sentences identify the same ADMD are not part of the common practices.

> I can't think of a good reason to restrict this to look like a domain
> name if it doesn't actually represent a single DNS domain entity.

Well, one could use, e.g, verifier-X.host-Y.my-ADMD.example.  In that
case, those common practices might suggest that Z.my-ADMD.example
belongs to the same ADMD.  RFC 5451 does not impose such method,
presumably to allow implementers to experiment different ways.

> One ADMD could be doing authentication service for lots of domains,
> but it's still one ADMD.

It's their choice whether to masquerade or not.

> If I run a service that does email authentication for tons of
> domains, why could I not use "Murray's Authentication Service" for
> an authserv-id?  Or even the empty string?  As long as the producer
> and consumer are consistent in their uses of it, all of your stated
> requirements are met.

In principle, I agree.  However, producers and consumers can consist
of software developed by several independent programmers.  Those
agents can interoperate only if programmers agree on a common syntax,
so that agents can be configured in ways compatible with one another.

>> 4. transport tracing data such as the SMTP queue ID or a timestamp
>>    (semantic hints would also go here, e.g. "all signatures checked
>>    but failures not reported" vs "checking stops on first success"),
> 
> This also doesn't appear to me to demand a specific format (as above).

It is unspecified how a consumer would use a queue id or a verifier's
configuration version.  Consonant producers and consumers can carve
out a space where to pass useful data from one to the other.  The
important point is that they don't step on another agent's toes by
invading the id proper.

>> 5. version identification,
> 
> That's not part of the authserv-id itself.

Right, it's similar to #4 in this respect.

>> 6. examples of valid authentication identifiers are "example.com"
>>    "mail.example.org", "ms1.newyork.example.com", and "example-auth".
> 
> The last string in that list is not what most people think of as a
> fully-qualified domain name, but as you point out, it's perfectly
> acceptable.

Yes, albeit that may preclude A-Rs produced that way to cross domain
boundaries.

>> Bullets #3 and #6 are compatible with "domain-name".  By using domain
>> names in the traditional ways, even though they are not required to be
>> in the DNS, operators can easily implement #1 and #2.  Conversely,
>> we'd need production rules to parse a "domain-name" inside the rest of
>> the "value" if the grammar were relaxed that way.
>>
>> Alternatively, we can meet #4 and #5 by relaxing or extending the
>> "version".  [example omitted]
> 
> I think we're wandering off into some bikeshedding here.  I'm curious
> to know if anyone else supports this more complicated notion.  I
> certainly don't agree with making the "separator" be anything other
> than "/".

The text is not stringent:

   appending a delimiter such as "/" and following it with useful
   transport tracing data

I'd prefer a fixed separator too.  How about this:

   "Authentication-Results:" [CFWS] domain-name
              [ [CFWS] "/" [CFWS] dot-atom ]
?

> The overall grammar is pretty clean right now: break on unescaped
> semicolons and you get paragraphs of useful information; the first
> paragraph is the authserv-id stuff, and everything else is
> "method=result" followed by relevant method parameters; any unescaped
> "/" followed by a number is a version.  Is there a reason to
> complicate that?

My attempt is for simplifying, not complicating.  The "value" syntax
would allow:

   Authentication-Results: "Murray's Authentication Service;
      used with permission since version /1. ;-)" / 2;
      dkim = pass header . d = example.com (...)

You'd have to extend the acid test in C.7 to account for that.

>> Semantically, allowing "anything the operator wants to use" conflicts
>> with the requirement that a parser explicitly knows it, in the new
>> Section 2.4.  IMHO, unrecognized ex-versions could just be ignored, as
>> the format is determined by the field name.
> 
> How does it conflict?

For example, assume my MTA is set up such that I can tell from the
queue id whether a message arrived to port 25 rather than 587, and I'd
like to use that info downstream, e.g. for logging something.  It is a
hack, admittedly, but the A-R producer I use happens to let me
configure it for appending the queue id, so I use that and roll my A-R
consumer hack.  Now, I also run another A-R consumer, for example
spamassassin, which is --will be, hopefully-- able to use existing
results rather than computing them from scratch.  What should it do
when it finds A-R-producer.my-host.my-ADMD/12345?  If that is a
version number that it knows nothing about, it should discard the field.