CONTEXT BINDING An Emerging Problem in Cryptographic Protocols

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

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

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

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

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

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

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

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. …

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 oneway 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

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?

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

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 Conversation Client Over link NAS key Backend Server

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

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

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

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

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

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)

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

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. 1. 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

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

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

HOW TO REASON ABOUT SECURE BINDING? Start with possibility that entities associated with the old context A and new context B could be different 1. Honest A, dishonest B Could B deceive third party into thinking B was A? 2. Honest B, dishonest A Could A deceive third party into thinking A was B? 3. 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

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