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

[Alessandro Vesely <[e-mail]>]

On Mon 25/Mar/2013 19:54:25 +0100 Murray S. Kucherawy wrote:
> On Mon, Mar 25, 2013 at 5:19 AM, Alessandro Vesely <[e-mail]> 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.