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

["Murray S. Kucherawy" <[e-mail]>]

On Tue, Mar 26, 2013 at 5:41 AM, Alessandro Vesely <[e-mail]> wrote:

> >> 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.
>

My point is that RFC6650 Section 5.3 says nothing about allowing POP3 MUAs
to extract a reporting address from the Authentication-Results header
field's authserv-id, so I don't understand why you used it as a reference.
Such was never the intent.  It's fine to talk about it in ASRG or anywhere
else, of course, but that's not in my view a good impetus for now adding
that possible meaning here.


> >> 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?
>

That logic presupposes that queue IDs have a known syntax, but they don't.
I know of one that uses slashes and hyphens in its queue IDs, for example.

But to answer your question directly, any software inside an ADMD seeking
to use this field would be configured to look for a particular string right
after the header field name and up to the first semicolon, and if that
string matches the string it's looking for, then the field can (presumably)
be trusted.


>
> >> 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".
>

"domain-name" isn't in the new document except as part of a pvalue.



>
> > 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.
>

There is no obvious reason to preclude the possibility of not using a
domain-name there either.


>
>
> 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.
>

Indeed.  And there's no reason to constrain such masquerading to
"domain-name", is there?


> > 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.
>

Isn't that the point of publishing a standard, i.e., this entire exercise?


>
> >> 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.
>

You seem to be advocating for giving the queue ID its own token in the
header field different from the authserv-id in a normative sense.  What for?


>
> >> 5. version identification,
> >
> > That's not part of the authserv-id itself.
>
> Right, it's similar to #4 in this respect.
>

Then I don't understand you claimed it as a separate requirement.


> >> 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.
>

I don't understand.


> > 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:
>
>
I don't see how the additional grammar you proposed previously (which was
half a page long on my screen) simplifies anything.



>    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.
>

I'm fine with extending the convoluted example to show this possibility.


>
> >> 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.
>

Attaching the queue ID as part of the authserv-id means you're effectively
using a new authserv-id for every message, which is clearly not the
intent.  It's incumbent on the consumers to figure out what that means.  I
don't think that (or any hack) should be encoded into the document.

But to give you a counter-hack, append the queue ID after a ":" instead of
a "/".

-MSK