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
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
Backend
Server 1
Client
MitM
(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)
-----------------HDR*, HASH(1), Ni, ID
HDR*, HASH(3) [, KE_I]
[,CERT] [,POP_I]
Responder (GCKS)
----------------->
<-HDR*, HASH(2), Nr, SA
-->
<--
HDR*, HASH(4), [KE_R,] SEQ,
KD [,CERT] [,POP_R]
Hashes are computed as follows:
HASH(1) = prf(SKEYID_a,
HASH(2) = prf(SKEYID_a,
HASH(3) = prf(SKEYID_a,
HASH(4) = prf(SKEYID_a,
POP_R)
POP_I = S_I(Ni,Nr)
POP_R = S_R(Ni,Nr)
M-ID
M-ID
M-ID
M-ID
|
|
|
|
Ni |
Ni_b
Ni_b
Ni_b
ID)
| Nr | SA)
| Nr_b [ | KE_I ] | POP_I)
| Nr_b [ | KE_R ] | SEQ | KD |
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
• 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 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