EMail Sender Authentication

1
E-Mail Sender Authentication

• Julian Mehnlejulian_at_mehnle.net
• 2007-05-09

2
Road Map
SPFSender ID
CSV
TheProblem
How SMTPworks
E-Mail Identities
Sender Reputation
The GoodThe BadThe Ugly
DomainKeysDKIM
PGPS/MIME
3
Road Map
SPFSender ID
CSV
TheProblem
How SMTPworks
E-Mail Identities
Sender Reputation
The GoodThe BadThe Ugly
DomainKeysDKIM
PGPS/MIME
4
The Problem Identity Forgery

• Nearly all of e-mail abuse is accompanied by
  identity forgery
• ?Spammers want to avoid non-delivery
  notifications (bounces) to their real addresses.
• ?Fraudsters want to cover their tracks.
• ?Phishers (password fishers) want to impersonate
  well-known, trusted identities in order to steal
  passwords from users.
• ?Computer viruses want to cause confusion or just
  dont care about which sender addresses they use.

5
Effects of Identity Forgery

• Victims get tricked into disclosing sensitive
  information or losing money.
• Innocent bystanders...
• get hit by tons of misdirected bounces,
• gain a bad reputation,
• ?have to disclaim liability for the abuse!
• These effects might even be intended by the
  abuser? "joe jobs"!

6
Why is Forgery possible?

• So how could this happen in the first place?
• SMTP (RFC 821) designed in 1981/1982. Everybody
  on the Internet was a nice guy and trustworthy
  back then.
• Thus Lack of security and traceability in
  SMTPAlso Lack of prosecution (bad laws, foreign
  countries)

7
Road Map
SPFSender ID
CSV
TheProblem
How SMTPworks
E-Mail Identities
Sender Reputation
The GoodThe BadThe Ugly
DomainKeysDKIM
PGPS/MIME
8
How E-Mail Transport works

• SMTP transaction-based, hop-to-hop

9
An SMTP Transaction Example

• Server 220 io.link-m.de ESMTP
• Client HELO gray.home.mehnle.net
• S 250 io.link-m.de Ok.
• C MAIL FROMltjulian_at_mehnle.netgt
• S 250 Ok.
• C RCPT TOltalice_at_aol.comgt
• S 250 Ok.
• C DATA
• S 354 Ok.
• C From Julian ltjulian_at_mehnle.netgt
  To Alice ltalice_at_aol.comgt Subject Did
  you this?
• Look http//...
• .
• S 250 Ok. 4640A8D2.00003764
• C QUIT
• S 221 Bye.

10
Road Map
SPFSender ID
CSV
TheProblem
How SMTPworks
E-Mail Identities
Sender Reputation
The GoodThe BadThe Ugly
DomainKeysDKIM
PGPS/MIME
11
Envelope Identities

• 220 io.link-m.de ESMTP
• HELO gray.home.mehnle.net
• 250 io.link-m.de Ok.
• MAIL FROMltjulian_at_mehnle.netgt
• 250 Ok.
• RCPT TOltalice_at_aol.comgt
• 250 Ok.
• ...

12
Header Identities
Identities in the message header serve display
purposes only!

• From Julian ltjulian_at_mehnle.netgtSender
  Julian (Home) ltjulian_at_home.mehnle.netgtTo
  Alice ltalice_at_aol.comgtSubject
  Did you see this?
• Look http//...

13
Header Identities (2)
When re-sending a message

• Resent-From Alice ltalice_at_aol.comgtResent-Sender
  Alice (Work) ltjane_at_corp.comgtResent-To
  Jane ltjane_at_yahoo.comgt From Julian
  ltjulian_at_mehnle.netgtSender Julian (Home)
  ltjulian_at_home.mehnle.netgtTo Alice
  ltalice_at_aol.comgtSubject Did you see this?
• Look http//...

14
Envelope vs. Header Identities
15
Road Map
SPFSender ID
CSV
TheProblem
How SMTPworks
E-Mail Identities
Sender Reputation
The GoodThe BadThe Ugly
DomainKeysDKIM
PGPS/MIME
16
Sender Authentication

• The identity owner is the authority over what
  constitutes "authenticity" with regard to their
  identity, publishes information for recipients to
  determine.
• Newer methods authenticate domain names, thus
  publish declarations in DNS, which has
  appropriate semantics (hierarchical control,
  caching/TTLs), is omnipresent (behind firewalls,
  ...), light-weight (but also inherent
  reliability, security issues).

17
Road Map
SPFSender ID
CSV
TheProblem
How SMTPworks
E-Mail Identities
Sender Reputation
The GoodThe BadThe Ugly
DomainKeysDKIM
PGPS/MIME
18
Client SMTP Validation (CSV)

• InitiativeDave Crocker et al. (2003-2004),
  http//www.bbiw.net/CSV/
• ScopeAuthorize hosts to act as responsible MTAs
  for a given HELO domain name (? protects
  HELO,applies at SMTP transaction time)
• Form of declaration1..n SRV records for
  "_client._smtp.ltnamegt" (name to protect),listing
  names of authorized hosts

19
CSV Example

• example.com. A 192.168.0.1mta.example.com. A 192.
  168.0.2_client._smtp.example.com. SRV 1 2 0
  example.com._client._smtp.example.com. SRV 1 2 0
  mta.example.com._client._smtp.mta.example.com. SR
  V 1 2 0 mta.example.com.
• Only 192.168.0.1, 192.168.0.2 may say "HELO
  example.com".Only 192.168.0.2 may say "HELO
  mta.example.com".

20
Road Map
SPFSender ID
CSV
TheProblem
How SMTPworks
E-Mail Identities
Sender Reputation
The GoodThe BadThe Ugly
DomainKeysDKIM
PGPS/MIME
21
Sender Policy Framework (SPF)

• InitiativeMeng Weng Wong et al. (2003-2006),
  http//www.openspf.org(initially based on
  Reverse MX, 2002-2004)
• ScopeAuthorize hosts to act as responsible MTAs
  for a given HELO domain name, or to use a given
  domain name in the envelope sender (? protects
  HELO, MAIL FROM, applies at SMTP transaction
  time)
• Form of declarationTXT (or SPF) record for
  "ltnamegt" (name to protect),specifying authorized
  hosts

22
SPF Example

• example.com. A 192.168.0.1mta.example.com. A 192.
  168.0.2example.com. MX 1 mta.example.com.exampl
  e.com. TXT "vspf1 a mx -all"mta.example.com. TXT
  "vspf1 a -all"
• Only 192.168.0.1, 192.168.0.2 may say "HELO
  example.com" or "MAIL FROMlt..._at_example.comgt".
• Only 192.168.0.2 may say "HELO mta.example.com"or
  "MAIL FROMlt..._at_mta.example.comgt".

23
SPF Record Anatomy

• vspf1 -ip410.0.1.1 amail.example.org mx ?all

vspf1 existsl._spf.d all
expir.v.e.d
24
SPF Result Codes
25
SPF Mechanisms
26
SPF Odds Ends

• ?Specifies only sender policy, not receiver
  policy
• ?Localpart granularity possible via l macro
• Currently 7 of all domains, 35 of all
  messages covered
• Spammers have been among the earliest adopters
  due to receivers' bad understanding("SPF Pass" ?
  "message is not spam"!)

27
Sender ID

• InitiativeMicrosoft (2004-2005),
  http//www.microsoft.com/senderid(embrace
  extend mutation of SPF)
• ScopeAuthorize hosts to use a given domain name
  in the envelope sender or header identities (?
  protects MAIL FROM, PRA, applies at SMTP
  transaction or delivery time)
• Form of declarationTXT (or SPF) record for
  "ltnamegt" (name to protect),specifying authorized
  hosts

28
Sender ID "spf2.0/pra"

• Sender ID mutates version tag "spf2.0", followed
  by list of scopes ("mfrom", "pra"), e.g.
  spf2.0/mfrom,pra
• Drops SPF's implicit HELO scope.
• Introduces PRA identity (patented!)
• Rough algorithm choose first existing header
  field of
• ?Resent-Sender
• ?Resent-From
• ?Sender
• ?From
• Aims at protecting display header fields,but
  really only protects Resent-Sender.
• Otherwise identical to SPF.

29
Road Map
SPFSender ID
CSV
TheProblem
How SMTPworks
E-Mail Identities
Sender Reputation
The GoodThe BadThe Ugly
DomainKeysDKIM
PGPS/MIME
30
DomainKeys / DKIM

• InitiativeDK Yahoo (2005-2007),
  http//antispam.yahoo.com/domainkeysDKIM Yahoo,
  Cisco, IETF (merger of DK IIM),
  http//www.dkim.org
• ScopeAuthenticate messages originating from a
  given header identity domain via cryptographic
  signatures (? protects From/Sender headers,
  applies at SMTP transaction, delivery, or MUA
  time)
• Form of declaration
• ?DomainKey-Signature/DKIM-Signature message
  headers
• TXT record for "ltselectorgt._domainkey.ltnamegt"
  (selector from message, name to protect),
  containing public signing key

31
DKIM Example

• DKIM-Signature arsa-sha256 dexample.net
  sbrisbane
• csimple qdns/txt i_at_eng.example.net
  t1117574938 x1118006938
• hfromtosubjectdate
• bhMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI
  
• bdzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbavyuU4zGeer
  uD00lszZVoG4ZHRNiYzR

brisbane._domainkey.example.net. TXT (
"vDKIM1 pMIGfMA0GCSqGSIb3DQEBAQUAA
4GNADCBiQ"
"KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt"
"IxN2SnFCjxOCKG9v3b4jYfcTNh5i
jSsq631uBItLa7odv"
"/RtdC2UzJ1lWT947qRRcac2gbto/NMqJ0fzfVjH4OuKhi"
"tdY9tf6mcwGjaNBcWToIMmPSPDdQ
PNUYckcQ2QIDAQAB" )
32
DK/DKIM Protocol

• Domain owner...
• ?publishes public key in TXT DNS record,
• ?canonicalizes outgoing messages
  (headers/body)(simple, relaxed algorithms)
• ?signs messages with private key, adds signature
  header.
• Recipient...
• ?reads domain and selector from message's
  signature header,
• ?fetches public key from DNS,
• ?reproduces message canonicalization hash,
• ?verifies signature.

33
DK/DKIM Odds Ends

• Currently no sender policy (nor receiver
  policy)(however, Sender Signing Policy (SSP)
  under debate)
• ?User-level granularity possible
• Signature headers transparent to old MUAs(cf.
  S/MIME, PGP/MIME)
• ?Patented, but liberal license (supposedly
  GPL-compatible)
• No deployment statistics ? (but significantly
  less than SPF)

34
Road Map
SPFSender ID
CSV
TheProblem
How SMTPworks
E-Mail Identities
Sender Reputation
The GoodThe BadThe Ugly
DomainKeysDKIM
PGPS/MIME
35
PGP S/MIME

• InitiativePGP Philip Zimmermann
  (1991-1998)S/MIME IETF (1998-present)http//www
  .imc.org/smime-pgpmime.html
• ScopeAuthenticate messages originating from a
  given author via cryptographic signatures (?
  protect individuals/organizations, apply at MUA
  time)
• Form of declaration
• Signatures in the message body or as MIME
  attachments
• PGP manual immediate key exchange, key servers
• S/MIME (X.509) CAs (hierarchical PKI), CA
  certificates distributed with client software

36
PGP S/MIME (2)

• ?Full message cryptography (also encryption)
• ?Very strict but powerful canonicalization
  (understands MIME structure)
• ?Individual/org-level granularity(though
  domain-level possible, see HTTPS)
• Public key distribution difficult, not
  standardized, howeverRFC 4398 Storing
  Certificates in the Domain Name System (DNS)
• ?Not fully transparent to old MUAs (MIME
  attachments)
• ?Not widely deployed (just yet, hopefully)

37
(No Transcript)
38
The Good, the Bad, and the Ugly
Who gets to the gold treasure first?

• SPF...
• "breaks" on alias-style forwarding
• requires continued survey of sending
  infrastructure
• protects only the envelope identities
• DK/DKIM, PGP, S/MIME...
• "break" on message mutilation (e.g. mailing
  lists)
• requires cryptography ? higher CPU load
• does not protect the envelope identities

Path Authentication-vs-Payload Authentication
39
The Good, the Bad, and the Ugly (2)
Well... OK, let's collaborate!(as long as I
benefit)

• SPF...
• is light-weight (no cryptography)
• tolerates message mutilation
• protects the envelope identities
• DK/DKIM...
• protects displayed identities
• tolerates forwarding
• PGP S/MIME...
• protects individual/org (real) identities
  regardless of domain and e-mail address
  (artificial) ones.
• tolerates forwarding

40
A Ring to Bind Them

• Problems
• Overcome notion of "single final solution"
• Coordination protocol required!
• Thus
• Identity owner is the authority, must be able to
  specify various auth methods! ? SPFv3?
• Receivers should implement all (most) methods,
  plus forwarder white-listing (configuration
  protocol?)
• Forwarders should learn how not to mutilate
  messages! "Mutilation best practices"?

41
Road Map
SPFSender ID
CSV
TheProblem
How SMTPworks
E-Mail Identities
Sender Reputation
The GoodThe BadThe Ugly
DomainKeysDKIM
PGPS/MIME
42
Sender Reputation

• Sender authentication is nice,but how do we
  solve the spam problem?
• Reputation!
• (already exists with IP address granularity)
• Authenticated identities lift reputation to
  domain or individual granularity.
• From the abuser's PoV, IP addresses are cheaper
  than domains? Domain/individual reputation
  reduces efficacy of zombie nets (maybe even
  reduces incentive to mass-hack PCs?)

43
Sender Reputation (2)

• Beware
• rep("domain.org") ? rep("domain.org") (in
  general)The identity type matters!
• Throw-away domains are still cheap and quick to
  register? highly dynamic (shared) reputation
  systems required
• Abuse characteristics of domains/individuals
  differs from that of IP addresses, so new lessons
  need to be learned!

44
!?You can't stop the signal! -)"vspf1
ip609F911029D74E35BD84156C5635688C0 -all"