CONTEXT BINDING: An Emerging Problem in Cryptographic Protocols

1. CONTEXT BINDING:An Emerging Problem in Cryptographic Protocols Catherine Meadows Naval Research Laboratory Code 5543 Washington, DC 20375 meadows@itd.nrl.navy.mil

2. WHAT I DO A LOT OF • Apply formal methods to analysis of cryptographic protocol analysis • Over the years, specific type of model of crypto protocols has become accepted • Each principal has a name • Each principal has a master key or set of master keys associated with that name • Master keys used to exchange temporary session keys and other short-term information • Names/master keys unlikely to change, at least during execution of the protocol

3. SITUATIONS IN WHICH IDENTITIES CAN CHANGE • Mobile computing • Entity migrates from one address to another • Secure group protocols • Entity joins a group, gets new identity as member of group • Composition of protocols • E.g., running a legacy protocol on top of, or inside of, another protocol • Different keys may be associated with different protocols, even when same principal involved

4. Contexts and Context Binding • Context: a set of attributes that distinguishes a principal • Examples • Address (e.g. IP address) • Long-term keys • Names • Etc. • Context often used to decide what privileges a principal has • In a mobile computing environment, contexts can often change • How can we ensure that they change securely • Context binding: the problem of ensuring the integrity of a context switch

5. WHAT I’LL TALK ABOUT TODAY • Three examples of flawed context binding • Multihoming “Effects of Mobility and Multihoming on Transport-Protocol Security”, Aura, Nikander, and Camarrillo • Tunneled Authentication Protocols “Man-in-the-Middle in Tunneled Authentication Protocols”, Asokan, Niemi, and Nyberg • Group key distribution Protocols “Deriving, Attacking, and Defending the GDOI Protocol,” Meadows and Pavlovic • Lessons learned in terms of assuring correct context binding

6. Multihoming • Stream Control Transmission Protocol (SCTP) • Allows endpoints to have multiple IP address for fault tolerance • Currently being extended to allow for multihoming and dynamic address change

7. Will Concentrate on a Particular Feature: Verification Tags • Verification tags used to identify association • Randomly generated nonces issued by initiator and responder • Random means harder to forge • Provides some protection against spoofing and denial of service attacks • However, anyone who sees them can spoof association • As it turns out, multihoming makes it easier to sniff verification tags

8. NEW VULNERABILITIES • Multiple addresses means tags can be sent along multiple paths • Easier to sniff and easier to spoof • What happens when an old address is abandoned? • Packets may be still be sent to it and may be received by new owner of address • State cookie used in second message of handshake contains verification tag of any existing association with same endpoints • If attacker gains control of an IP address, can get verification tags by initiating handshake • Etc. …

9. SOLUTIONS • Can’t use strong cryptography (digital signatures, encryption); too much of an impact on performance • That’s why verification tags introduced in first place • However, can use weaker but more efficient mechanisms such as one-way hashes to limit exposure of verification tags • Some suggestions: • Cryptographically generated address: some address bits encode secure hash of address owner’s public signature key • Public signature key becomes “master context” • Don’t reuse addresses • Send one-way hashes of tags instead of tags themselves in cookies • Verify that peer addresses are active • Use more sophisticated secure acknowledgement schemes • Every packet contains a nonce • Ack is XOR of all nonces in packets received so far

10. MORAL • Multiplication of addresses not only creates new vulnerabilities but magnifies old ones • Defenses, such as randomly generated verification tags, that were once “good enough” are no longer • However, not feasible to develop full-scale cryptographic defenses • Need to develop a new version of “good enough” • Question: is it possible to quantify “good enough”, or to devise general strategies for arriving at it?

11. TUNNELED AUTHENTICATION PROTOCOLS • Want to run legacy application (e.g. ftp) inside a server-authenticated tunnel (e.g. tls) • Vulnerability arises when legacy protocol runs in both legacy environment as well as tunneled environment • Example: Extensible Authentication Protocol

12. Protected EAP • Three parties: client, back-end server, and network access server (NAS) • Client & back-end server set up TLS tunnel over EAP • NAS does not know TLS master secret • Back-end server derives master session keys from TLS master secret • Conveys them to NAS • NAS and client use keys to communicate over link layer Client Conversation Backend Server Over link NAS key

13. WHAT CAN GO WRONG? • Suppose that: • Legacy client authentication protocol used in other environments • Plain EAP without tunneling • No EAP encapsulation • Client fails to verify server certificate properly • Whether or not using tunnel • Then it’s possible to construct a man-in-the-middle attack

14. MitM ATTACK • Mitm waits for legitimate device to start untunneled legacy remote authentication protocol (or tricks it into doing so) • MitM sets up tunneled authentication protocol with authentication agent • After tunnel set up, MitM starts forwarding legitimate client’s authentication protocol messages through the tunnel • After remote authentication ended successfully, MitM derives session keys from same keys it is using for tunnel • MitM can now impersonate legitimate device Client Backend Server 1 MitM (as client) Conversation Backend Server 2 NAS key Over link

15. Recommended fixes • If inner protocol also uses cryptography, perform cryptographic binding between inner and outer protocols • Have inner and outer protocol both create key, and use both as input to session key • Creates some issues with layering • IETF now working out this • For some protocols, this not sufficient • Protocols based on weak passwords • There, stuck with forbidding use outside of secure tunnels

16. MORAL HERE • When faced with context migration, can achieve security by introducing cryptographic binding between old context and new • This comes at a cost, and may not always be applicable • Layering may be an issue

17. GDOI PROTOCOL • Stands for “Group Domain of Interpretation” • Two types of principals • Group members • Group Controller/Key server • Includes handshake protocol (groupkey pull protocol) in which member requests to join group and receive current group key

18. GROUPKEY PULL PROTOCOL Initiator (Member)                   Responder (GCKS)         ------------------                   ----------------         HDR*, HASH(1), Ni, ID    -->                                   <--     HDR*, HASH(2), Nr, SA         HDR*, HASH(3) [, KE_I]    --> [,CERT] [,POP_I]                                   <--     HDR*, HASH(4), [KE_R,] SEQ, KD [,CERT] [,POP_R] Hashes are computed as follows:     HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)     HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)     HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ] | POP_I)     HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] | SEQ | KD | POP_R) POP_I = S_I(Ni,Nr) POP_R = S_R(Ni,Nr)

19. OPTIONAL PROOF OF POSSESSION • Member can introduce certificate in third message • Certificate may give member certain privileges • Member has to prove possession of identity in the certificate • Does this by signing own nonce and GCKS’s nonce • Intended to give cryptographic binding to new identity • Similar optional proof-of-possession for GCKS

20. ATTACK ON POP Suppose that I is a GCKS that wants to join a group managed by another GCKS, B. Suppose that I doesn’t have the proper credentials to join B’s group. Then I can trick a member A who does into supplying them, as follows. • A --> I : HDR*, HASH(1), Ni, ID A requests to join I's group, sending a nonce Ni 1.' I_member --> B : HDR*, HASH(1)', Ni, ID’ I requests to join B's group, forwarding A's nonce Ni 2.' B --> I_member : HDR*, HASH(2), Nr', SA’ B responds to I with its nonce Nr' 2. I --> A : HDR*, HASH(2)', Nr', SA I responds to member A, but using B's nonce Nr' 3. A --> I: HDR*, HASH(3), CERT(for A's ID in group), POP = S_A(hash(Ni,Nr')) A responds to I with a POP taken over A's and B's nonce 3.' I_member --> B: HDR*, HASH(3), CERT(for A's ID in group), POP = S_A(hash(Ni,Nr)) I as a member responds to B, using A's CERT and POP 4. B --> I_member : HDR*, HASH(4), KD B sends keying information to I under impression the identity in A's certificate belongs to I

21. WHAT WAS THE PROBLEM? • Cryptographic binding went only one way • PoP appears in message authenticated with member’s key, attests to member’s statement that it is owner of PoP identity • Not much use if member lies • No corresponding statement that PoP identity is also owner of member identity • Solve this problem by having signature taken over member identity as well as the two nonces

22. MORAL • Not enough to provide cryptographic binding • Need to say what is being bound, and how

23. HOW TO REASON ABOUT SECURE BINDING? Start with possibility that entities associated with the old context A and new context B could be different • Honest A, dishonest B Could B deceive third party into thinking B was A? • Honest B, dishonest A Could A deceive third party into thinking A was B? • Colluding B and A Possible if A and B share all information If want to avoid this, best can show is that A and B can’t collude without sharing information that they would rather not or could not share

24. LESSONS LEARNED • Need to deal with/mitigate multiplication of contexts • Especially, need to retire expired contexts • Avoid reusing contexts • Need to reexamine partial solutions • What was “good enough” for single-context environment may not no longer be so when context migration introduced • Cryptographic binding can provide a solution • Need to work out carefully how it’s done and what is being bound