imho Kim Cameron’s thoughts on messaging federation

All:

Pointer to Kim’s blogpost:
http://www.identityblog.com/2005/01/29.html#a110

Pointer to my original blogpost on this topic, which Kim commented on:
http://jkobielus.blogspot.com/2005/01/fyi-spammer-directory-harvest-attacks.html

Kobielus kommentary:
I enjoyed Kim’s kommentary on the pitfalls of traditional SMTP-based federated messaging, and the associated, app-specific federated identity infrastructure.

Specifically, I agree with Kim’s principal remarks:

• “[K]ey to [SMTP’s] early success seems in retrospect to have been that everyone chose a policy of ‘whatever’ - or ‘no policy.’ Who configured a security policy in SMTP back in the eighties or even the nineties?”
• “[W]e are only beginning to move toward email relationships based on proactive policies employing federated identity.”
• “An example of progress? Well, some corporate SPAM filters are now designed to accept mail from known partners and servers - those with whom there is an established pattern of communication. Meanwhile they may apply extremely stringent controls to mail from unknown parties. And more recently people have begun working on designing and deploying "edge servers" that use cryptography and more formal trust relations.”
• “[H]asn't SMTP messaging basically been a free-for-all with an identity system drastically weakened by its lack of authentication?”
• “I think the [mail-server directory harvest] attacks [Kobielus] enumerates result from the lack of authenticated federation, rather than being caused by it.”

SMTP-based Internet e-mail is the first universally interoperable, federated communication environment. The flip side of universal federation/interoperability is universal exposure/vulnerability to all the nasty beasties coming down the wire. When that happens, it becomes more critical than ever to authenticate the content originators (and every router, relay, or server in the delivery chain), and to authenticate the content objects themselves themselves. All of this supports what I said in a separate blog post (http://jkobielus.blogspot.com/2005/02/fyi-ciphertrust-mail-senders-guilty.html) :

• “[S]pam is an identity management problem. Spammers have obtained your authenticated identity (your e-mail address), which allows them to target you with messages, even though you don’t always have theirs (their current e-mail address, IP address, or originating mail domain). Consequently, you can’t effectively target them with filtering and blocking mechanisms. Until you’ve nailed them down to a stable, authentic, verified address. Until you have the evidence necessary to justify adding that address to a whitelist of trusted senders.”

Whitelisting is, in fact, the ultimate solution to the spam problem, and is supported in a growing range of commercial solutions. Note that whitelisting is equivalent to the “contact list” functionality underlying IM services, which only allow messages from a peer group of trusted senders. It’s very likely, as the spam problem intensifies, that e-mail and IM services will begin to merge in this fundamental way: Priority message delivery to a user’s e-mail inbox will be granted only to those senders who have previously been designated a “trusted” sender by the recipient.

Whitelisting depends on an identity infrastructure that can feed trusted senders’ e-mail addresses into anti-spam-enabled messaging environments. Increasingly, anti-spam solutions will retrieve trusted senders’ addresses from authoritative enterprise and e-business directories, using protocols such as LDAPv3 and DSMLv2. All other (untrusted) senders’ messages will be delivered to some other, lower priority drop box or folder on the user’s desktop (or simply blocked and deleted).

Whitelisting and quarantining approaches are not mutually exclusive—in fact, they’re potentially quite complementary. Whitelisting is the only way to ensure a continuously spam-free inbox. However, enterprises want to strike a balance between the desire for spam-free inboxes and the desire not to have any important inbound mail blocked or lost. Messages should be delivered to a point easily accessible to recipients and/or mail administrators. Consequently, administrators (and the vendors who supply them with anti-spam solutions) will need to migrate quarantine folders conceptually from what they are now—glorified trashcans—to something more powerful.

Fundamentally, quarantine folders function as drop boxes for inbound messages that have been filtered, ranked, and categorized by their “spamminess.” As the anti-spam industry develops, we see vendors increasingly implementing these drop boxes along a “trusted sender” continuum: from “off-white” (not from pre-trusted senders but not matching any spam rules or signatures) to “off-black” (not obvious spam but nevertheless matching several critical spam indicators). Inbound messages will, in the filtering process, be automatically scored, ranked, categorized, and placed in the appropriate drop boxes. Tool vendors will base their spam rankings on a weighted synthesis of criteria (identities, rules, and patterns) retrieved from various rulemaking authorities, both internal (mail users, mail administrators) and external (anti-spam blacklisting, whitelisting, and dynamic rulemaking communities).

Of course, whitelisting can only operate effectively if the message senders aren’t spoofed. Hence the need for digitally signed e-mail, trust marks, etc. That’s an important, but orthogonal, issue to the need for dynamic auto-whitelisting with intelligent quarantining mail infrastructures everywhere. All of these enabling infrastructures—messaging, whitelisting communities, blacklisting communities, anti-spam signature identification/distribution communities, PKI—depend on federation.

Federation is the core concept: “autonomous domains that choose to accept each others’ assertions and honor each others’ decisions, per trust relationships, interoperability agreements, and local policies.”

Oh…speaking of authenticated identities….my surname is spelled “Kobielus.” But you can call me…

Jim