1 / 32

Just Fast Keying

Just Fast Keying. Application to a “real-world” protocol. 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

emota
Télécharger la présentation

Just Fast Keying

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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. • 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-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 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 • 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 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 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 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 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 xi=gdi Ni, xi R I 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 check integrity before decrypting “hint” to responder which identity to use 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 9798-3 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

  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

  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 Doesn’t quite work: B must remember his DH exponential b for every connection “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?

  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 • “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

More Related