I'm not really sure that it is impossible to make authorization decisions
about identity assertions without understanding (through something implicit
or explicit in the message, or some legal construct) the local domain's
policy for authenticating the senders of outbound messages.
What an identity assertion must prove is: a) the namespace of the originator
exists (like, the domain has been allocated in the DNS), and b) the owner of
the namespace of the originator of the message established, in the manner of
its choosing, that it is acceptable for this message to be sent from this
identity. Communicating separately in the message or assertion that this
user was authenticated, say, by an MSA via RFC2554 using DIGEST-PGP, or by
source IP ACLs, or not authenticated at all, is pretty useless in my
opinion. As you point out, domains acting in bad faith could just lie if
they wanted to, and domains acting in good faith will be as good as they
practically can be. Legal constructs, aside from other difficulties,
introduce n-squared scalability issues, and are furthermore incompatible
with the fundamental idea that just anyone can deploy an email domain if
they want to. Granting assertions any sort of legal status is unwise, in my
opinion. Ultimately, we don't need to provide non-repudiation in order to
defeat impersonation.
However, I still think there are useful authorization policies that could be
implemented by verifiers even if an assertion proves nothing more than a)
and b) above. Practically, I think an assertion can and will prove more than
that. One major difference between the MASS approach and the MARID approach
is that MASS is gravitating (no pun intended) towards an architecture where
assertions appear in messages. In order for assertions to appear in
messages, it must be possible to protect against replay of these assertions.
In order to protect against replay, the assertion will need to contain a
signature over some set of further elements in the message, beyond just the
originating domain. These elements in turn can help verifiers to make
authorization decisions. Beyond just the sender's domain (the host portion
of the addr-spec of RFC2822.From), these elements might include the sender's
username in that domain (local-portion of that addr-spec). The narrower the
scope of the asessertion, the broader the circumstances are in which the
assertion can be replayed. If it doesn't include the sender's username, then
especially for huge domains, replay of the assertion can be a material
concern. Particularly nasty for large, free email services, for example, if
any attacker can acquire an account in that domain.
The question of whether the assertion is domain-based or user-based (i.e.,
whether the identity provider's credentials prove authority over a domain or
a username in a domain) is related to but separate from the question of what
constraints appear in the assertion (i.e., what data is signed with the
identity provider's credentials to constitute an assertion).
Jon Peterson
NeuStar, Inc.
-----Original Message-----
From: Seth Goodman [mailto:sethg(_at_)GoodmanAssociates(_dot_)com]
Sent: Sunday, October 17, 2004 10:45 AM
To: Peterson, Jon; Michael Thomas
Cc: 'George Gross'; ietf-mailsig(_at_)imc(_dot_)org
Subject: RE: a draft on messaging, impersonation and identity
From: Peterson, Jon
Sent: Sunday, October 17, 2004 3:35 AM
<...>
Those sorts of nits aside, I think I futhermore agree with the
substance of your mail: that if there is a question in MASS that
has not been addressed before, it is how a messaging system can
answer your second question above. I also agree that using
domain-based assertions rather than user-based assertions is
reasonable (it's what we decided to do for SIP, eventually).
Yes, I believe we are in agreement. Even though the assertion is
domain-based, a domain still _could_ assert somewhere,
perhaps in their
published sender policy, that they _do_ control the use of
user identities
within their domain and a positive verification validates
both the domain
and the local-part. Since most domains don't do this today,
that would be
useful information for a recipient. Unfortunately, it is
hard to imagine
how a reputation system could deal with this in a meaningful
way. Many
domains would like to make this assertion, even if it isn't
true, to appear
to be well-run and to give recipients more confidence in the
communication.
For example, when you get a message from a company's
purchasing department
giving you a purchase order number for a previous quote, you
can have some
confidence it is really from people within the corporation
who appear to
have the authority to give you this authorization.
The one mechanism that might stop domains from falsely making
that claim
might be legal liability. We would need the opinion of a
lawyer on this,
but here's a scenario that might get a corporate counsel's
attention. A
company publishes a sending policy that stated they control
the use of user
identities within the domain but doesn't actually do this. A
disgruntled
employee writes an email forging the CEO's user name and
makes a substantial
financial commitment on behalf of the company. The recipient
of such a
message would seem to have pretty reasonable grounds to trust
that message,
act on it and hold the company to specific performance
according to the
email. This is a liability that not many companies would
want, if it is
actionable.
At least in the American legal system, _anything_ is
actionable, whether
justified or not, and the other party has to defend itself with little
chance of recovering its legal fees, even if they win.
Hence, the endless
chain of suits and counter-suits to give people something to
bargain with
(I'll drop my frivolous claim if you'll drop yours). Still,
getting sued
under our system normally means you are out some money,
whether you have
done anything wrong or not, and defendants are often pragmatically
encouraged to settle though an action may be groundless. I
do know that in
the American system,
If an assertion that a domain controls user names actually
implies any real
liability, companies would only make that assertion if they
really could
accomplish it. Either that or no-one would make the
assertion, since the
counsel's job is to minimize liability, even if it affects
business. As I
said, it would be nice to hear from a lawyer or two on this,
or anyone on
the list who has knowledge of the legal status of email in
any particular
jurisdictions, before considering that as a possible sender assertion.
I do think it is worth documenting and analyzing the
varieties of more
specific assertions of identity as well, because, if
nothing else, it
exposes elements of the problem space that help us to make design
decisions.
Yes, some discussion about the tradeoffs of making and
validating different
levels of identity assertion would be useful.
--
Seth Goodman