There are some really good points here that I think we'd do well to
adopt. Nonetheless, I still see one issue that seems to keep coming
back in every discussion that I've had in every context of spam prevention:
There are multiple entities being authenticated and multiple decisions
made to authorize. Let me see if I can try to put this into an example:
I (Edwin Aoki, aoki(_at_)aol(_dot_)net) try to send a piece of mail to (for
example) Dave Crocker.
In my mind, here are the various sender assertions that could be made
(without reference to any specific proposal):
* I, Edwin Aoki, authored (created) this message
* I, Edwin Aoki, sent (caused to be injected into the mail stream) this
message
* A machine at 1.2.3.4 is authorized to send mail
* A machine at 1.2.3.4 is authorized to send mail on behalf of AOL (aol.net)
And at the receiver, I can use the information asserted by the sender to
make assertions such as:
* I can verify that Edwin Aoki authored this message (or not)
* The MTA from which my MTA received this message is listed as being
allowed to send mail (or not)
* The MTA from which my MTA received this message is listed as being
allowed to send mail on behalf of the domain listed in the message (or not).
I think one of the things that hangs us up is the notion that
authorization is built into any of these proposals. They aren't. They
provide a mechanism for the sending domains to list various assertions
("Policy" below, which I think is a fine term), that receiving MTAs can
then use to make authorization decisions. But also note that there are
two different "senders" here. The individual who created the message
(author) and the MTA from which any given MTA receives a message.
I don't want to get into a semantic argument either, but we need to get
some clarification on the terms we're using, or we're never going to be
able to communicate this out to the world. We need to have a way to
tell people, "In order to implement a policy x, you must do these steps
y." And receiving MTAs can make a statement that says, "we will only
accept mail from senders with policy z." Further, authors and receiving
users can make other assertions/decisions (such as "I, Dave Crocker,
will only accept mail that has a verifiable signature,") but that's out
of scope for this group.
-Edwin
Hallam-Baker, Phillip wrote:
I agree with Hadmut, we have to use these terms in the same way the security
field does.
In the security world we have an established nomenclature where:
Authentication = Determining that "Alice" is really Alice
Attributes = Information that describes Alice
Access Policy = The rules that decide who is allowed access to a resource
Authorization = The decision to allow "Alice" access to a resource
I don't think that an attributes service is very descriptive which is why I
invented the term accreditation to replace attributes in the context of
information provided by a third party about a subject. since then most
people seem to have started using it and we are starting to get it used in
other security contexts. So even though the term comes after the Menzies
book I think it is now valid.
Let us see how these apply to our problem:
Sender - originator of the mail transaction
Receiver - recipient of the message
The Sender is not providing any authorization information in the sense that
we normally use the term. It is not even an access policy. What the sender
is doing here is to specify the set of credentials (IP address, public key)
which SHOULD be presented by any legitimate sender from the domain.
We normally use the term 'policy' for that type of information. That is
exactly what we are doing in the WS-Policy spec.
As for 'accountable' and 'trusted'. These terms have an important place in
the description here but not as given. The objective here is to be able to
identify an accountable sender. We do that by determining that the sender is
authenticated (meets sender policy of the domain), that the domain is
accredited and that the accreditation ensures that the sender will face
significant consequences if they spam.
We establish trust by demonstrating that we accept responsibility.
Phill
Security Blog: http://hallambakersecurity.blogspot.com/atom.xml