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

[Alessandro Vesely <[e-mail]>]

On Tue 26/Mar/2013 22:33:17 +0100 Murray S. Kucherawy wrote:
>>> 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.
>>
>> It has better be careful to exclude the queue id from the comparison.
> 
> If an ADMD chooses to use the authserv-id to encode details apart from an
> ADMD identifier, contrary to its stated purpose, then you're absolutely
> correct.  RFC5451 already talks about that.

Ok, that is starting to make some sense.  Maybe it's me, but reading
RFC 5451 as well as its bis I had the false impression that the spec
not only allows but even encourages such practice.  I'll try and
suggest an alternative text at the bottom.

>>>> 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?
>>
>> There are pros and cons.  Similar arguments hold for the choice of
>> domain that an ADMD uses as d= to sign messages...
> 
> Quite right.  Should this document be making that call?

No.  However I'd like a discourse on virtual domains, I don't think
this I-D is the right place to develop it.

>>> What [would transport tracing data and such be useful] for?
>>
>> Anything that it might be useful for.  If we think it isn't useful,
>> then the spec should not allow it.
> 
> So why doesn't making authserv-id a "value" accommodate that case?

It would overkill, considering that we'd tend to discourage
complicated stuff.  A "dot-atom" can have a slash, but perhaps we can
live with that.  Otherwise, a "token" can be fit.

>> It is quite complicated to let trusted domain's A-R pass through.
> 
> Why is it quite complicated?  Trusted authserv-ids is merely a set of
> strings.  If you're looking at an A-R header field whose authserv-id is in
> that list, you've decided explicitly that its content can be trusted.
> Anything else should either be ignored or removed (depending on which agent
> is looking at it).

IMHO, the first paragraph of Section 5 is too mild.  It could be
hardened like so:

OLD
 For security reasons, any MTA conforming to this specification MUST
 delete any discovered instance of this header field that claims, by
 virtue of its authentication service identifier, to have been added
 within its trust boundary and that did not come directly from another
 trusted MTA.

NEW
 For security reasons, any MTA conforming to this specification MUST
 remove or rename any instance of this header field that was not added
 within its trust boundary.  The authentication service identifier
 (authserv-id) is used to identify the agent which added the header
 field, with the limits described in Section 7.1.

If an MTA kills only the A-Rs that it can clearly identify as
forgeries, it would let thru any A-R field bearing some unknown
identifier.  Those identifiers may be forged.  If they match a trusted
id at the next ADMD (MTA or MUA), then if the latter trusts the
former, it has no obvious reason to suspect.  It gets complicated if
one tries to derive trustworthiness from routing considerations.

Renaming rather than removing solves some issues with debugging and
signature verification, so I'd consider it anyway.

I don't understand the "(border or otherwise)", still in the first
paragraph.  If it is an internal MTA it shouldn't delete fields added
by the border MTA of example.com.  The rest of the section becomes
more stringent, which seems to be correct.

> It only gets complicated if you choose to overload that field with your own
> purposes by encoding other data in it.  If some people find that useful,
> then great, but I don't think this specification should describe how to do
> that beyond not explicitly blocking it.

Fine!

>>> I don't think that (or any hack) should be encoded into the
>>> document.
>>
>> But then why do you write:
>>
>>                                               Moreover, some
>>  implementations have considered appending a delimiter such as "/" and
>>  following it with useful transport tracing data such as the [SMTP]
>>  queue ID or a timestamp.
>> ?
>>
>> You can allow or prohibit that, but not both at the same time.
> 
> Keep reading; the remainder of that section actively discourages the
> practice.

Here's the alternative text I promised above:

                                              Consistently with the
 scope limit outlined in Section 1.2, the grammar does not constrain
 the authentication identifier to be a domain name.  Improper use
 could thus consider appending a delimiter such as "#" and following
 it with useful transport tracing data such as the [SMTP] queue ID or
 a timestamp.

> There are a lot of things that standards enable but also say "You could do
> this, but there are costs involved."  This is one of them.