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:
There are different perspectives on the same data. I may authorize
a party to send, but I cannot make a decision to you the receiver.
Therefore any information published in the DNS that describes the
result of my authorization decision is IN YOUR CONTEXT policy
or accreditation information.
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
This would be a policy statement.
Actually I think it is really bad to think of any statement about the
IP address as an authorization or even a policy statement. If the
IP address is not authorized to send mail the packets should never
have left the network - PERIOD END OF STORY.
If a machine at 1.2.3.4 can connect to port 25 on machines outside
its own network it has empirically been authorized to do so. The
packets have crossed the firewall (and please, do not try to bring
up the end-to-end crock, perimeter security is not a bogus artifact
that will go away some day). The only reason the perimeter security
will receive less emphasis in the future is that the controls will
migrate down to the level of ethernet hubs.
I would prefer here to have a descriptive statement.
"1.2.3.4 is a statically allocated IP address for which the
accountable domain is AOL.NET."
"1.2.3.4 is allocated to a dialup modem pool"
"1.2.3.4 is allocated to a pool of addresses allocated on request
to broadband residential customers of an ISP"
This is accreditation information that the recipient can feed into
their decision process. If one of those residential users
decides that they are going to run their own mail server, sets
up the correct SPF configs and gets themselves accredited there
is no reason to drop email from this source.
* A machine at 1.2.3.4 is authorized to send mail on behalf
of AOL (aol.net)
The email sending policy of AOL.net is that the machines must have
an IP address of (..., 1.2.3.4, ... )
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