Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 Dr. David MacQuigg Research Associate Autonomic Computing Laboratory Autonomic Trust System – Verify Identity and Assess Reputation University of Arizona.

Similar presentations


Presentation on theme: "1 Dr. David MacQuigg Research Associate Autonomic Computing Laboratory Autonomic Trust System – Verify Identity and Assess Reputation University of Arizona."— Presentation transcript:

1 1 Dr. David MacQuigg Research Associate Autonomic Computing Laboratory Autonomic Trust System – Verify Identity and Assess Reputation University of Arizona ECE 509 November 2008

2 June 13, 20152 The Problem with Trust on the Internet –Spam problem, $20B/year, “intractable” –Fraud and other serious crimes –Non-technical factors are critical Modeling of Mail Handling Systems –Actors, Agents, Terminology –Roles and Responsibilites Trust = Identity + Reputation Identity (Authentication) –IP-based (CSV, SPF, SenderID) –Signatures (DKIM) Reputation –Reputation/Accreditation Systems –Registry of Internet Transmitters

3 June 13, 20153 Economics of Email Abuse $200B annual benefit of email $20B cost of abuse 100M users x ($.25/day deleting spam + $100/yr lost emails) $2B benefit to anti-spam industry 100 companies x $20M/yr $0.2B benefit to spammers 10K spammers x $20K/yr $0.02B cost of an effective authentication/reputation system 10M users x $2/yr 100K companies x $200/yr (90% internal, 10% external services)

4 June 13, 20154 Textbook Model of a Mail Handling System Figure 9.1 Sequence of mail relays store and forward email messages {Peterson & Davie, Computer Networks, 4 th ed.}

5 June 13, 20155 Real Mail Handling System P. Faltstrom, mail-flows-0.4, Jan 6, 2004, http://www.ripe.net/ripe/meetings/ripe-47/mailflows.pdfhttp://www.ripe.net/ripe/meetings/ripe-47/mailflows.pdf

6 June 13, 20156 D. Crocker, "Internet Mail Architecture", 2008, http://tools.ietf.org/html/draft-crocker-email-arch-10 Function Modules and the Protocols used between them Relay-Level Model

7 June 13, 20157 Administrative-Level Model +-------+ +-------+ +-------+ | ADMD1 | | ADMD3 | | ADMD4 | | ----- | | ----- | | ----- | | | +---------------------->| | | | | User | | |-Edge--+--->|-User | | | | | +---------+ +--->| | | | | V | | | ADMD2 | | +-------+ +-------+ | Edge--+---+ | ----- | | | | | | | | +-------+ +----|-Transit-+---+ | | +---------+ D. Crocker, "Internet Mail Architecture", 2008, http://tools.ietf.org/html/draft-crocker-email-arch-10 Administrative Management Domains (ADMD)

8 June 13, 20158 The Internet Today Our Domain Trusted Forwarders The Swamp 3

9 June 13, 20159 Typical Mail Handling System ( a better textbook model ) |--- Sender's Network ---| |-- Recipient's Network -| / Author ==> MSA/Transmitter --> / --> Receiver/MDA ==> Recipient / Border

10 June 13, 201510 Proposed Model for Mail Handling Systems Simple Setup with four Actors |--- Sender's Network ---| |-- Recipient's Network -| / Author ==> MSA/Transmitter --> / --> Receiver/MDA ==> Recipient / Border Actors, Roles and Notation Actors include Users and Agents. Agents may play more than one role, but no role has more than one Actor. Typical roles include Transmitting, Receiving, Forwarding, and Delivery. A Border occurs when there is no prior relationship between Agents. --> Direction of mail flow (no statement as to relationship) ~~> Indirect relationship (e.g. both directly related to Recipient) ==> Direct relationship between Actors (e.g. a contract) A/B Roles A and B both played by the same Actor

11 June 13, 201511 Other Common Setups Simple Forwarding is quite common |-------- Recipient's Network ---------| / --> / --> Receiver/Forwarder ~~> MDA ==> Recipient / Border Chain Forwarding should be discouraged |------------ Recipient's Network ------------| / --> / --> Receiver ~~> Forwarder(s) ~~> MDA ==> Recipient / Border Open Forwarding must be banned / / |-- Recipient's Network -| --> / --> Forwarder --> / --> Receiver/MDA ==> Recipient / / Border Border

12 June 13, 201512 Roles and Responsibilities Author - Originate messages - Provide a password or other means of authentication MSA - Mail Submission Agent - Authenticate the Author - Manage Author accounts Transmitter - Spam Prevention - rate limits, content analysis, alerts - respond to spam reports - maintain reputation - Authentication - RFC compliance - IP authorization (SPF, SID, CSV,...) - signatures & key management (DKIM...) Receiver - Block DoS - Authenticate Sender - HELO, Return Address, Headers, Signature - reject forgeries - Assess reputation - whitelists - Filter spam - Add authentication headers - Manage Recipient accounts/options - whitelisting, blacklisting, filtering, blocking, forwarding - Process spam reports

13 June 13, 201513 Roles and Responsibilities (continued) Forwarder - Authenticate upstream Agent - Set up forwarding to downstream Agent - check RFC compliance - set up authentication records - submit forwarding request, wait for approval - Manage Recipient accounts - maintain database of forwarding addresses - suspend account when a message is rejected - communicate w Recipient re " " - Maintain reputation as a trusted Forwarder - certifications MDA - Mail Delivery Agent - Authenticate upstream Agent - Sort and store messages - Provide access for Recipients - POP3, IMAP, Webmail - Manage Recipient accounts/options - Relay spam reports to Receiver (or don't accept them) Recipient - Set up accounts with each Agent - Select options in each account - Report spam to Receiver

14 June 13, 201514 Identity – Authenticating the Sender SMTP makes Forgery Easy Forger -------> / / Author ==> MSA/Transmitter --> / --> Receiver/MDA ==> Recipient / / / / Border / / / -- Secure Channel -- TCP makes IP addresses (relatively) secure The source address is real, but it may be only a zombie! DNS offers a (relatively) secure channel Domain owners can publish their authorized addresses Or they can publish a public key

15 June 13, 201515 Authentication Methods Author ==> MSA/Transmitter --> / --> Receiver/MDA ==> Recipient / / / / Border / / / -- Secure Channel -- IP-based Authentication (SPF, SenderID, CSV): Sender provides a list of authorized transmitter addresses. Can be very efficient (no data transfer). Signature-based Authentication (DKIM): Sender provides a Public Key via a secure channel. Messages are signed with the related Private Key. End-to-end protocol can be very secure, even with an un-trusted Forwarder in the middle.

16 June 13, 201516 Reputation – the other half of trust Millions of legitimate senders are simply unknown Aggregation of data is essential Ground Up: Gossip Top Down: Proprietary Systems Registry of Internet Transmitters Some legitimate senders are not qualified to operate a transmitter Make outsourcing the Transmitter role easy. Accountability is essential – no excuses.

17 June 13, 201517 So why isn’t it happening? Hurdles that trust systems must avoid or overcome, in order of decreasing severity: 1)Required simultaneous upgrades in software or setup (Flag Day) 2)Required widespread adoption by Agents before any benefit is realized by Recipients (By June 30th, all senders will...) 3)Required widespread adoption of one company's method or service (Microsoft patent) 4)Changes that cause a temporary degradation in service ( loss of mail due to misconfigurations on the Receiver side ) 5) Changes in current practices a) A well-established and standards-compliant practice. b) A widespread but non-standardized practice. ("Misuse" of Return Address) c) A widespread but non-compliant practice. (bad HELO name) d) An already unacceptable practice. (open relays) 6) Lack of motivation a) Can’t keep track of all their transmitter addresses b) Reversed incentives – more spam = more money

18 June 13, 201518 Suggested Receiver Setup

19 June 13, 201519 Analysis of SPF using our models Simple Forwarding |-------- Recipient's Network ---------| / --> / --> Receiver/Forwarder ~~> MDA ==> Recipient / Border SPF correlates the Return Address to the incoming IP address. Forwarders are expected to re-write the Return Address. Very few forwarders are doing that. A misconfigured MDA sees the forwarded message as forgery. The message is quarantined, and possibly lost. Senders are avoiding the loss by publishing “neutral” SPF records. Forwarders will not change until senders demand it. SPF is stuck.

20 June 13, 201520 Bibliography TCP/IP Illustrated, vol. I, The Protocols, W. Richard Stevens, 1994. Very thorough, yet readable. Good illustrations. Computer Networks, Peterson & Davie, 4 th ed. – good on all relevant technologies except email. "Internet Mail Architecture", D. Crocker, http://www.ietf.org/internet-drafts/draft- crocker-email-arch-11.txt (work in progress) - best overview with references to all the relevant RFC standards.http://www.ietf.org/internet-drafts/draft- crocker-email-arch-11.txt Pro DNS and BIND, Ron Aitchison, Apress 2005. – Very readable book on the Domain Name System. "CircleID", http://www.circleid.com – a "Collaborative Intelligence Hub for the Internet's Core Infrastructure & Policies" – current articles by top industry experts.http://www.circleid.com Project Links https://www.open-mail.org – current status of our Identity and Reputation Systemhttps://www.open-mail.org http://purl.net/macquigg/email – articles and notes from early development.http://purl.net/macquigg/email A short list of the most useful books and articles on the technology underlying email.

21 June 13, 201521 Identities in an Email Session $ telnet open-mail.org 25 220 open-mail.org ESMTP Sendmail 8.13.1/8.13.1; Wed, 30 Aug 2006 07:36:42 -0400 HELO mailout1.phrednet.com 250 open-mail.org Hello ip068.subnet71.gci-net.com [216.183.71.68], pleased to meet you MAIL FROM: 250 2.1.0... Sender ok RCPT TO: 250 2.1.5... Recipient ok DATA 354 Enter mail, end with "." on a line by itself From: Dave\r\nTo: Test Recipient\r\nSubject: SPAM SPAM SPAM\r\n\r\nThis is message 1 from our test script.\r\n.\r\n 250 2.0.0 k7TKIBYb024731 Message accepted for delivery QUIT 221 2.0.0 open-mail.org closing connection RFC-2821 Helo Name Envelope Addresses: Return Address Recipient Addresses RFC-2822 Header Addresses: From Address Reply-To Address 1 1 2 2 3 3 4 4 5 6 Network Owner


Download ppt "1 Dr. David MacQuigg Research Associate Autonomic Computing Laboratory Autonomic Trust System – Verify Identity and Assess Reputation University of Arizona."

Similar presentations


Ads by Google