563.10.1 - Sender Authentication for SPAM Control
Document Sample
563.10.1 Sender
Authentication for SPAM Control
Presented by: Marc Gagnon
SPAM Group (Auth) – Marc Gagnon, Sari Louis, Steve White
University of Illinois
Spring 2006
Definition of Spam (e-mail)
• Many definitions, but usually:
– Unsolicited messages
– Sent in bulk either by one sender or distributed via compromised
systems (zombies)
– May or may not be done for commercial or illegal purposes
• Origin
– First known commercial occurrence in 1978 (Arpanet)
– Early 90‟s saw commercial spamming really take off
Questions (challenges): Content vs. Consent. What
constitutes bulk? Is unsolicited sufficient? Can solutions
be put in place yet maintain the aspects that make e-mail
and Internet so appealing?
1st SPAM on Arpanet 2
Forms of Spam
• Types
– Commercial: pornography, unlicensed
software, medical (Viagra), etc…
– Harassment
– DoS
– Viruses
– Chain e-mail
– Fraud (e.g. Phishing Attacks, Nigerian Spam)
Spam Types 3
Fighting Spam
• Non-Technical
– Legislative
– SpamCop (spam reporting)
– Cost-based
– User education (especially for fraud prevention)
• Technical
– Challenge/Response
– Blacklists/Whitelists
– Content-based filtering
– Statistical filtering (e.g. Bayesian classifier)
– Checksum-based
– Authentication (e.g. DomainKeys, SPF)
CAN-SPAM Act of 2003 4
Problem: E-mail Spoofing
• Spam technique to forge the origin of the message
• Nature of SMTP makes it possible to forge From,
Return-Path, or Reply-To fields in header.
• Goal of e-mail spoofing is to conceal sender‟s
identity.
• In more nefarious cases it is also used to gain
recipient‟s trust to obtain confidential information
such as account logins and credit card information
(a.k.a. “Phishing Attacks”)
• Many studies suggest that financial costs or losses
due to spoofing in the U.S. alone is in the millions $.
Phishing Article #1 Phishing Article #2 Phishing Article #3 5
Solution #1: DomainKeys Identified Mail (DKIM)
• Joint effort by Yahoo! And Cisco to defend against forging of
sender information
• Key differentiator with other solutions is the signature
calculation on all or part of the message (message integrity)
• Tolerant to *some* mangling of the message (header +
body) as it passes through gateways and relays.
• E-mail forwarded through external relays or forwarding
services (e.g. alumni association) can be verified. Other
solutions such as SPF cannot.
• Backwards compatible with existing e-mail infrastructure.
Use of optional headers and DNS records allow current
systems to process e-mail as usual.
DomainKeys Identified Mail (DKIM) 6
DomainKeys Concept
• Verification of source and contents using public-key
cryptography
• Canonicalization of the header and body is performed based
on the signers tolerance of modification to message.
• All or parts of the message header fields and body are
signed using some algorithm (default is SHA-1 hash)
• Resulting hash is then encrypted by the signing entity using
RSA algorithm (asymmetric key)
• A DKIM-Signature header field is pre-pended to the
message.
• Verifier uses DNS to obtain public key and verify received
message against enclosed signature
7
DomainKeys Process Flow
Signer (MUA, MSA, MTA) SHA-1 Signature
Signature field
1 5 added to header
User of original
2 Chosen header fields
(Sender) 3 message 7
canonicalized
Private
Part or all of message Key
body canonicalized (encrypt)
8
Message Normalized 6
to Avoid Conversion at 4
User Transmit
(Recipient) Internet
Success Verifier (MTA, MDA, MUA)
13
9
Failure
Message
Normalized
14 12
Query using domain and
11 selector specified in tags
Signature field
Signature compared
extracted and
Public Key against decrypted
tags parsed 10
(decrypt) signature data
DNS
8
DomainKeys Example
Submitted to signer After signing
From: John Doe <jdoe@anydomain.com> DKIM-Signature: a=rsa-sha1; s=newyork; d=anydomain.com;
To: Jane Doe <jane@otherdomain.com> c=simple; q=dns; i=jdoe@anydomain.com; h=Received : From
Subject: Test message : To : Subject : Date : Message-ID;
b=r6YHkli98DSew12OPjIkd43SDeru78PI9iOu30wQdfE398KjHtGYJhB
Date: Tue, 28 Feb 2006 18:00:20 -0700 (PDT) vCx65Mkl9
Message-ID: <20060228010020.32345.5F7J@anydomain.com> Received: from mail.anydomain.com [10.2.3.4]
by submitserver.anydomain.com with SUBMISSION;
This is a test. Tue, 28 Feb 2006 18:01:34 -0700 (PDT)
From: John Doe <jdoe@anydomain.com>
Please reply to this message to confirm you have in fact To: Jane Doe <jane@otherdomain.com>
received it.
Subject: Test message
Date: Tue, 28 Feb 2006 18:00:20 -0700 (PDT)
Thanks.
Message-ID: <20060228010020.32345.5F7J@anydomain.com>
This is a test.
Please reply to this message to confirm you have in fact
received it.
Thanks.
Signature header added. Contains tags specifying various
signing and key selection info (e.g. signing algorithm, signed
header field info, key)
9
DomainKeys Limitations
• Mailing lists will often add content to
messages before sending them out – this
will invalidate signature. („l‟ tag can be
used to limit part of message signed)
• Does not prevent user spoofing another
user from within a signed domain.
• Unclear what computational impact
adoption of DKIM will bring.
10
DomainKeys Security Considerations
• Limiting signature to only part of the message
body can expose it to attacks (e.g. adding HTML
content past signed portion of message)
• Misappropriated private key
• DoS attacks on key or DNS servers (e.g. e-mail
with bogus signatures)
• Replay attacks (once signed a message can
then be resent as spam)
• Malformed key records or signature fields
exploiting poor verifier implementation.
DKIM Threats Analysis 11
Solution #2: Sender Policy Framework (SPF)
• Early form introduced in 1998
• Special DNS records specify IP addresses of
machines authorized to send mail for a particular
domain (reverse MX)
• Designed to protect the envelope sender (return
path)
• Minimizes bandwidth and processing
requirements as the message body data does
not need to be transmitted to do verification
• More than 1.7 million domains had published
SPF records as of November 2005
Sender Policy Framework (SPF) 12
SPF Process Flow
Client MTA MTA obtains domain info
from message envelope
(joe@example.com) MAIL FROM (*use domain
Client at IP 152.130.20.20 from HELO if null). IP-based authentication for
initiates an SMTP domain using DNS (e.g. query
connection with MTA SPF record of example.com)
PASS
SPF record returned with parameters
to determine allowed sender IP‟s for
SOFTFAIL domain (use best-guess default if no
published SPF record) DNS
FAIL
Tagged
Recipient
Rejected
13
SPF Record Example
Domain RR DNS Field
example.com IN TXT “v=spf1 a mx ptr include:isp.com -all”
Version
Match /w domain’s A RR
Match /w domain’s MX RR
Reverse map query on
source’s PTR RR
Restart test /w supplied domain
Terminate processing
HOWTO – Define SPF Record 14
SPF Limitations
• Does not prevent forging of From: and
Sender: header fields.
• Forwarding services won‟t work unless
they rewrite return-path info (client IP
won‟t match with original sender)
• Requires that mail senders for domain
have static IP‟s (some are dynamically
assigned)
• Problematic for road warriors that change
SMTP servers based on ISP being used
15
Conclusion
• Not a be-all solution to eliminate spam
• Both techniques are not mutually exclusive
– they approach the problem from different
angles (crypto vs. IP)
• Hybrid approach may be more effective
(perform low computational SPF followed
by DKIM if necessary)
• 1st step towards use of reputation and
accreditation techniques
16
End
THANK YOU
Send questions/comments to:
gagnon at uiuc dot edu
(no spam please )
17
