CONTEXT BINDING:An Emerging Problem in Cryptographic Protocols

Catherine MeadowsNaval Research Laboratory

Code 5543Washington, 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 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

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 layerClient

BackendServerNAS

Conversation

keyOver link

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

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

MitM(as client)

BackendServer 2NAS

Conversation

keyOver link

ClientBackendServer 1

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), KDB sends keying information to I under impression the identity in A's certificatebelongs to I

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

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 BCould B deceive third party into thinking B was A?

2. Honest B, dishonest ACould A deceive third party into thinking A was B?

3. Colluding B and APossible if A and B share all informationIf 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