1. Application to a “real-world” protocol
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.
IKE’s 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-art proposal 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 other’s 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 Different security needs according to the application
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 Fresh nonces An anti-DOS authenticator
First, a Diffie-Hellman exchange creates a shared secret over 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
initiator IP
responder
Diffie-Hellman exponentials: create a fresh shared secret
protected signatures and IDs: verify each other’s identity
protected session messages

10. Just Fast Keying (JFKr)
initiator IP
responder
fresh nonces to reuse
Diffie-Hellman exponentials: create a fresh shared secret
anti-DOS authenticator
protected signatures and IDs: verify each other’s 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 derived from the same exponentials for different usages

13. Just Fast Keying: DoS Resistance
The first message is small
The responder uses an authenticator against DoS
The responder can check that the 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 attacks and 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 initiator’s 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 obtain the 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.]
Ni, xi
xi=gdi
If initiator knows
group g in advance I R
xr=gdr
DH group
tr=hashKr(xr,Nr,Ni,IPi)
Same dr for
every connection
Ni, Nr, xr, gr, tr
xidr=xrdi=x Ka,e,v=hashx(Ni,Nr,{a,e,v})
derive a set of keys from shared secret and nonces
Ni, Nr, xi, xr, tr, ei, hi
ei=encKe(IDi,ID’r,sai,sigKi(Nr,Ni,xr,xi,gr))
hi=hashKa(“i”,ei)
er, hr
“hint” to responder which identity to use
check integrity before decrypting
er=encKe(IDr,sar,sigKr(xr,Nr,xi,Ni))
hr=hashKa(“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, sigB{m, n, A}
A  B: sigA{m, n, B}
Shared secret
Authentication
A receives his own number m signed by B’s private key and deduces that B is on the other end; similar for B
Identity protection
DoS protection

21. DH + Challenge-Response
ISO protocol:
A  B: ga, A
B  A: gb, sigB{ga, gb, A}
A  B: sigA{ga, gb, B}
Shared secret: gab
Authentication
Identity protection
DoS protection
m := ga
n := gb
Obtained by substituting Diffie-Hellman exponentials for the fresh terms m and n in the challenge-response protocol.

22. Ingredient 3: Encryption
Encrypt signatures to protect identities:
A  B: ga, A
B  A: gb, EK{sigB{ga, gb, A}}
A  B: EK{sigA{ga, gb, B}}
Shared secret: gab
Authentication
Identity protection (for responder only!)
DoS protection
B’s identity is protected against passive adversaries.

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, hashKb{gb, ga}
A  B: ga, gb, hashKb{gb, ga}
EK{sigA{ga, gb, B}}
B  A: gb, EK{sigB{ga, gb, A}}
Shared secret: gab
Authentication
Identity protection
DoS protection?
Doesn’t quite work: B must
remember his DH exponential b
for every connection
A cookie mechanism is a standard way of preventing blind denial-of-service attacks. B returns a keyed hash of the Diffie-Hellman exponential that he receives in the first message from A. Only after A returns the cookie in the third message does B create state and perform expensive public key operations. Cookie transformation
Typical protocol
• Client sends request to server
• Server sets up connection, responds
• Client may complete session or not (DOS)
Cookie version
• Server sends hashed data back
– Send message #2 later after client confirms
• Client confirms by returning hashed data
• Need extra step to send postponed message

25. Non-negotiated?
Usually, the cryptographic algorithms are negotiated: hash, 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 responder’s 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 initiator’s identity from active attack
Responder may keep an authorization list
May reject connection after learning initiator’s identity

27. Related Work [Datta, Mitchell, Pavlovic Tech report 2002]
“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
IKEv2 implements DoS protection by optionally allowing
the responder to respond to a Message (1) with a cookie,
which the sender has to include in a new Message (1). Under
normal conditions, the exchange would consist of the 4 messages
shown; however, if the responder detects a DoS attack,
it can start requiring the extra roundtrip. One claimed benefit
of this extra roundtrip is the ability to avoid memory-based
DoS attacks against the fragmentation/reassembly part of the
networking stack. (Briefly, the idea behind such an attack is
that an attacker can send many incomplete fragments that fill
out the reassembly queue of the responder, denying service
to other legitimate initiators. In IKEv2, because the “large”
messages are the last two in the exchange, it is possible for
the implementation to instruct the operating system to place
fragments received from peers that completed a roundtrip to
a separate, reserved reassembly queue.)
IKEv2 supports a Phase II exchange, similar to the Phase
I/Phase II separation in the original IKE protocol. It supports
creating subsequent IPsec SAs with a single roundtrip,
as well as SA-teardown using this Phase II.
IKEv2 proposals contain multiple options that can be combined
in arbitrary ways; JFK, in contrast, takes the approach
of using ciphersuites, similar to the SSL/TLS protocols[10].
IKEv2 supports legacy authentication mechanisms (in particular,
pre-shared keys). JFK does not, by design, support
other authentication mechanisms, as discussed in Section 3;
while it is easy to do so (and we have a variant of JFKr that
can do this without loss of security), we feel that the added
value compared to the incurred complexity does not justify
the inclusion of this feature in JFK.

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