dr david macquigg research associate autonomic computing laboratory n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Autonomic Trust System – Verify Identity and Assess Reputation PowerPoint Presentation
Download Presentation
Autonomic Trust System – Verify Identity and Assess Reputation

Loading in 2 Seconds...

play fullscreen
1 / 20

Autonomic Trust System – Verify Identity and Assess Reputation - PowerPoint PPT Presentation


  • 89 Views
  • Uploaded on

Dr. David MacQuigg Research Associate Autonomic Computing Laboratory. Autonomic Trust System – Verify Identity and Assess Reputation. University of Arizona ECE 509 November 2008. The Problem with Trust on the Internet Spam problem, $20B/year, “intractable”

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Autonomic Trust System – Verify Identity and Assess Reputation' - carnig


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
dr david macquigg research associate autonomic computing laboratory
Dr. David MacQuigg

Research Associate

Autonomic Computing Laboratory

Autonomic Trust System – Verify Identity and Assess Reputation

University of Arizona

ECE 509

November 2008

slide2
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
economics of email abuse
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)

textbook model of a mail handling system
Textbook Model of a Mail Handling System

Figure 9.1 Sequence of mail relays store and forward email messages

{Peterson & Davie, Computer Networks, 4th ed.}

real mail handling system
Real Mail Handling System

P. Faltstrom, mail-flows-0.4, Jan 6, 2004,http://www.ripe.net/ripe/meetings/ripe-47/mailflows.pdf

relay level model
Relay-Level Model

Function Modules and the Protocols used between them

D. Crocker, "Internet Mail Architecture", 2008,

http://tools.ietf.org/html/draft-crocker-email-arch-10

administrative level model
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)

typical mail handling system a better textbook model
Typical Mail Handling System ( a better textbook model )

  |--- Sender's Network ---|           |-- Recipient's Network -|                                  /  Author ==> MSA/Transmitter --> / --> Receiver/MDA ==> Recipient                                /                             Border

proposed model for mail handling systems
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

other common setups
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

roles and responsibilities
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

roles and responsibilities continued
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

identity authenticating the sender
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

authentication methods
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.

reputation the other half of trust
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.

so why isn t it happening
So why isn’t it happening?

Hurdles that trust systems must avoid or overcome,

in order of decreasing severity:

  • Required simultaneous upgrades in software or setup (Flag Day)
  • Required widespread adoption by Agents before any benefit is realized by Recipients (By June 30th, all senders will ...)
  • Required widespread adoption of one company's method or service (Microsoft patent)
  • Changes that cause a temporary degradation in service

( loss of mail due to misconfigurations on the Receiver side )

5) Changes in current practicesa) 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

analysis of spf using our models
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.

bibliography
Bibliography

A short list of the most useful books and articles on the technology underlying email.

  • TCP/IP Illustrated, vol. I, The Protocols, W. Richard Stevens, 1994. Very thorough, yet readable. Good illustrations.
  • Computer Networks, Peterson & Davie, 4th 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.
  • 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.

Project Links

  • https://www.open-mail.org – current status of our Identity and Reputation System
  • http://purl.net/macquigg/email – articles and notes from early development.
identities in an email session
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:<macquigg@box67.com>

250 2.1.0 <macquigg@box67.com>... Sender ok

RCPT TO:<jman@box67.com>

250 2.1.5 <jman@box67.com>... 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

1

2

6 Network Owner

3

4

RFC-2821

Helo Name

Envelope Addresses: Return Address Recipient Addresses

RFC-2822

Header Addresses: From Address Reply-To Address

1

4

2

5

3