On Thu, 2004-08-26 at 15:56, Jim Lyon wrote:
On Thursday, August 26, 2004 at 1:35 PM, Doug Otis wrote about the
authentication and authorization aspects of SenderID, compared to
schemes involving EHLO.
After much thinking, I realized that our disagreements have to do with
confusions about how the two schemes treat identity, authentication and
authorization.
Sender-ID:
Identity: The identity of a sending MTA is its IP address.
Authentication: There is no authentication other than that implicit in
the TCP/IP stack. Because in practice you can't perform an SMTP
transaction without being able to receive packets destined to the IP
address, this works well. (Yes, I know about TCP/IP spoofing attacks,
but they're impractical for sending bulk e-mail.)
Authorization: The SenderID test determines whether the sending MTA is
authorized to send mail that claims to come from a particular domain.
This authorization can only be bestowed by the domain that the mail
claims to come from.
The Identity being authorized is the PRA Mailbox Domain by way of
reference to a Mail Channel prescription of IP addresses. This PRA
Mailbox is the Identity the draft hopes exposed to the user. The
Mailbox Domain has not been authenticated, only authorized as the Mail
Channel will not safely permit such conclusion. The domain
administratively accountable for the MTA remains anonymous beyond the IP
address. There is no identity authenticated through this relationship
unless you wish to claim some significance with the MTA IP address. If
there is a problem, what identity will the user report? If there is a
problem, what identity will the MTA/MUA filter or reject? In each case,
the PRA Mailbox Domain is the identity affected. The problem is that
this identity has not been authenticated, but the authenticated MTA IP
address is ignored.
EHLO-based schemes:
Identity: The identity of a sending MTA is its EHLO name.
Authentication: Various scheme to determine whether the EHLO name that
an SMTP client sent is true.
The goal of CSV is to ensure a consistent and simple scheme
authenticates and verifies MTA authorization. The identity is the EHLO
domain as the message broker. This authenticated identity can be held
accountable. The Sender-ID identity as represented by the PRA Mailbox
Domain has not been authenticated as this requires unverifiable
assumptions made with respect to Mail Channel. Bug.
Authorization: Depending on the scheme, there might be none.
Otherwise, there might be a scheme to determine whether the sending MTA
is authorized by its domain owner to be an SMTP client. There is no
authorization of individual messages.
As I said, CSV provides both MTA authentication and authorization. This
was the goal of the MARID charter. : )
The SenderID series of documents is based on an explicit decision to
pursue the first world-view; the fact that it doesn't do the second is
not a bug.
Not authenticating the identity you wish everyone to hold accountable is
a bug in this logic. By allowing an "open-ended" record to exist, this
process becomes an exercise in futility, as not even the IP address of
the otherwise anonymous MTA is checked. Such "open-ended" records leave
open the door for endless spoofing. Sender-ID's false assumptions of
identity trustworthiness will ensure great potential for harm. : (
-Doug