Just Fast Keying

1
Just Fast Keying

• Application to a real-world protocol

2
Outline

• Introduction
• Motivation (IKE Shortcomings)
• Design Goals
• Abstract View
• Protocol Definitions
• Building A Better Protocol
• Additional Features
• Related Work
• JFK in PI Calculus
• JFK vs. Oakley
• IKE v2 (RFC 4306)
• Conclusions
• Questions

3
Introduction

• We will look at the current IPSEC standard for
  key exchange protocols, IKE, which is short for
  internet key exchange.
• IKEs shortcomings
• Some ideal design goals
• How JFK realizes these goals
• How IKEv2 became the standard

4
Motivation IKE and its Successors

• IKE (Internet Key Exchange)
• Session management for IPSEC
• Quite secure
• Some concerns
• Too complicated
• Inefficient
• Poor resistance against denial of service
• A successor for IKE, IKEv2 developed in parallel
  and adopted standard over JFK
• Just Fast Keying (JFK) is a simple,
  state-of-the-artproposal with several
  interesting improvements

5
A Classic Setting for Protocols

• Two parties want to open a secure session
• IP tunnel (IPSEC, VPN)
• Telnet (SSH)
• Web connection (SSL, TLS)
• Web Services
• They need to
• Generate a shared secret (or session key)
• Verify each others identity
• Agree on many parameters
• Attackers might eavesdrop, delete, and insert
  messages, may impersonate principals, to
• Gain information
• Confuse or hinder the participants

6
Complications

• Configuration
• Different security needs according to the
  application
• Many cryptographic algorithms to choose from
• Many flavours of authentication (PKIs)
• Concurrency
• Parallel sessions
• Various principals using several shared proxies
• Efficiency concerns
• Round-trips are expensive
• Cryptography can be expensive
• Session management
• Key derivation
• Rekeying
• Dead peer detection

7
Design Goals for JFK

• Secure
• The key should be cryptographically secure,
  according to standard measures of cryptographic
  security for key exchange
• Efficient
• Message roundtrips are expensive
• Cryptography can be expensive
• Flexible perfect forward secrecy
• With potential reuse of exponentials
• Simple no negotiation, no rekeying
• Resistant to Memory- and CPU-bound denials of
  service
• Private
• Some identity protection and plausible
  deniability
• These goals are (sometimes) contradictory.

8
An Overview of JFK

• First, a Diffie-Hellman exchange creates a shared
  secretover a public network, using long modular
  exponentials
• JFK refines the Diffie-Hellman exchange with
• Fresh nonces
• An anti-DOS authenticator
• Shared-key encryption MACs
• Identities and public-key signatures

9
Two-round Diffie-Hellman
responder
initiator
IP
Diffie-Hellman exponentialscreate a fresh
shared secret
protected signatures and IDsverify each others
identity
protected session messages
10
Just Fast Keying (JFKr)
responder
initiator
IP
fresh nonces to reuse
Diffie-Hellman exponentialscreate a fresh
shared secret
anti-DOS authenticator
protected signatures and IDsverify each others
identity
protected session messages
11
Just Fast Keying, IETF style
12
Just Fast Keying Flexible PFS
The pair of nonces is unique for this session
Many keys can be derivedfrom the same
exponentialsfor different usages
13
Just Fast Keying DoS Resistance
The first message is small
The responder uses an authenticator against DoS
The responder can check thatthe contents of
message 3 matches the contents of messages 1 and 2
14
Just Fast Keying Privacy
Identities are always encrypted
Identities are never signed
15
Identity protection

• Two flavours
• JFKi protects id_i against active attacks
• JFKr protects id_r against active attacksand
  protects id_i against passive attacks
• What is guaranteed? Does it make sense for the
  responder?This depends on relations between
  principals and roles
• Various leaks
• An active attacker can get the initiators hint
• A passive attacker can perform traffic analysis
• A passive attacker can observe shared
  exponentials
• if exponentials are re-used by a single
  principal,all these sessions involve the same
  principal
• an active attacker (or an insider) may obtainthe
  identity for one of these sessions

16
Identity protection (2)

• An attack on identity protection in JFKr
• An active attacker can test the equality of
  authenticator keys to test whether a pair of
  principals are communicating

17
JFKr Protocol Aiello et al.
If initiator knows group g in advance
xigdi
Ni, xi
R
I
xrgdr
trhashKr(xr,Nr,Ni,IPi)
DH group
Same dr for every connection
Ni, Nr, xr, gr, tr
xidrxrdix Ka,e,vhashx(Ni,Nr,a,e,v)
derive a set of keys from shared secret and nonces
Ni, Nr, xi, xr, tr, ei, hi
eiencKe(IDi,IDr,sai,sigKi(Nr,Ni,xr,xi,gr))
hihashKa(i,ei)
er, hr
check integrity before decrypting
hint to responder which identity to use
erencKe(IDr,sar,sigKr(xr,Nr,xi,Ni))
hrhashKa(r,er)
real identity of the responder
18
OK So How Do They Build All That?(A Simplified
Look)

• The ingredients that work together to produce JFK
• Diffie-Hellman
• Challenge-Response
• Encryption
• Anti-DoS Cookie

19
Ingredient 1 Diffie-Hellman

• A ? B ga
• B ? A gb
• Shared secret gab
• Diffie-Hellman guarantees perfect forward secrecy
• Authentication
• Identity protection
• DoS protection

20
Ingredient 2 Challenge-Response

• A ? B m, A
• B ? A n, sigBm, n, A
• A ? B sigAm, n, B
• Shared secret
• Authentication
• A receives his own number m signed by Bs private
  key and deduces that B is on the other end
  similar for B
• Identity protection
• DoS protection

21
DH Challenge-Response

• ISO 9798-3 protocol
• A ? B ga, A
• B ? A gb, sigBga, gb, A
• A ? B sigAga, gb, B
• Shared secret gab
• Authentication
• Identity protection
• DoS protection

m ga n gb
22
Ingredient 3 Encryption

• Encrypt signatures to protect identities
• A ? B ga, A
• B ? A gb, EKsigBga, gb, A
• A ? B EKsigAga, gb, B
• Shared secret gab
• Authentication
• Identity protection (for responder only!)
• DoS protection

23
Refresher Anti-DoS Cookie

• Typical protocol
• Client sends request (message 1) to server
• Server sets up connection, responds with message
  2
• Client may complete session or not (potential
  DoS)
• Cookie version
• Client sends request to server
• Server sends hashed connection data back
• Send message 2 later, after client confirms
• Client confirms by returning hashed data
• Need extra step to send postponed message

24
Ingredient 4 Anti-DoS Cookie

• Almost-JFK protocol
• A ? B ga, A
• B ? A gb, hashKbgb, ga
• A ? B ga, gb, hashKbgb, ga
• EKsigAga, gb, B
• B ? A gb, EKsigBga, gb, A
• Shared secret gab
• Authentication
• Identity protection
• DoS protection?

Doesnt quite work B must remember his DH
exponential b for every connection
25
Non-negotiated?

• Usually, the cryptographic algorithms are
  negotiatedhash, encryption, certificates,
  compression, Some algorithms are weak (legacy,
  legal), or even nil.
• The protocol must (at least) authenticate the
  negotiation, and also relies on these operations
  for authentication! -SSL
• JFK is non-negotiated the responder demands
  specific algorithms, the initiator takes it or
  leaves it. Still
• If the responder demands weak algorithms, no
  guarantees at all.
• What if the attacker modifies the responders
  demands?
• The session will fail, either immediately (the
  initiator rejects the demand) or after message 3
  (the server detects the mismatch). Bad denial of
  service.
• If the initiator accepts a bad demand, her
  message 3 is not protected, and may reveal her
  identity. Thus, bad identity protection (in JFKi)
• Fix for JFKi sign the algorithm demand

26
Additional Features of JFK

• Keep ga, gb values medium-term, use (ga,nonce)
• Use same Diffie-Hellman value for every
  connection (helps against DoS), update every 10
  minutes or so
• Nonce guarantees freshness
• More efficient, because computing ga, gb, gab is
  costly
• Two variants JFKr and JFKi
• JFKr protects identity of responder against
  active attacks and of initiator against passive
  attacks
• JFKi protects only initiators identity from
  active attack
• Responder may keep an authorization list
• May reject connection after learning initiators
  identity

27
Related Work

• Rational derivation of the JFK protocol
• Combine known techniques for shared secret
  creation, authentication, identity and anti-DoS
  protection
• Datta, Mitchell, Pavlovic Tech report 2002
• Just Fast Keying (JFK) protocol
• State-of-the-art key establishment protocol
• Aiello, Bellovin, Blaze, Canetti,
• Ioannidis, Keromytis, Reingold CCS 2002
• Modeling JFK in applied pi calculus
• Specification of security properties as
  equivalences
• Abadi,Fournet POPL 2001
• Abadi, Blanchet, Fournet ESOP 2004

28
Related Work

• JFK in PI Calculus
• Formalized applied pi calculus analysis of one
  JFK variant, JFKr
• Focus of analysis
• DoS resistance
• Core security concerns
• Secrecy
• Authenticity for complete sessions
• Identity protection (responder)
• Conclusion Formal analysis of these types of
  protocols is crucial in developing comprehensive
  solutions. IKE v2 has benefited from this papers
  analysis of some of the similar components it
  employs.

29
Related Work

• JFK vs Oakley Key Determination Protocol
• In Oakley the peer authentication is guaranteed
  by having each party explicitly sign the peer
  identity. In contrast, JFK guarantees peer
  authentication by having each party MAC its own
  identity using a key derived from the agreed
  Diffie-Hellman secret. This method of peer
  authentication is based on the Sign-and-Mac
  design

30
Related Work

• IKE v2 accepted standard differences from JFK
• IKEv2 Dos Protection
• Optional reply by responder with a cookie
• DoS detected, responder requires one extra round
  trip
• JFKr, this is not optional
• IKEv2 supports creating subsequent IPsec SAs with
  a single roundtrip
• IKEv2 can combine security services and options
  in arbitrary tailorable ways, where JFK uses more
  regimented options
• IKEv2 supports legacy authentication mechanisms,
  i.e. pre-shared keys, where JFK by design, does
  not support them
• IKEv2 has undergone less formal modeling and
  evaluation as JFK has withstood

31
Conclusion

• While IKEv2 has been adopted as the standard for
  internet key exchange, it is very apparent that
  the designers and evaluators of JFK have
  certainly made great impacts on recognizing the
  shortcomings of IKE as well as some interesting
  impacts on IKEv2 implementations addressing these
  shortcomings.

32
Questions