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

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

On Wed, Mar 27, 2013 at 1:15 PM, Alessandro Vesely <[e-mail]> wrote:

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

A quoted string is complicated?  They've been used in email header fields
for quite a long time now.


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

If consumers are already looking only for A-Rs that use an expected
authserv-id, and ignoring others, what's the harm in letting the other ones
through?

The document already goes as far as saying one can also remove all of them
if it chooses, just to be safe.  Renaming them is probably also fine, but
I'm skeptical about adding that here since you're renaming within a
registered namespace.


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

True, but the agent removing suspect header fields could also log or
otherwise record them as it does so.


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

Yeah, I don't know what that means either.  If I can't come up with a good
reason to keep it, I'll remove it in the next version.

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

Isn't that materially the same as what's already in Section 2.3?

-MSK