Transcript IPsec ESP Traffic Visibility

E2E Enterprise Security with
Traffic Visibility
Radia Perlman
Ken Grewal
4/6/2016
IETF 78 SAAG
1
Problem Description
• Suppose we have E2E security protocols using
encryption (IPsec ESP, TLS)
• Sometimes intermediate devices need to look
at more of the packet than IPsec/SSL exposes
•
•
•
•
•
•
4/6/2016
Firewalls
Traffic-shaping tools
Load Splitters
Network monitoring tools
Deep packet inspection and scanning (for
worms/viruses)
Intrusion Detection & Prevention Systems
(IDS/IPS)
IETF 78 SAAG
2
Derived Keys
• A server knows a secret S, from which it
derives a session key
• The session key has to be a function of S
and things visible in the encrypted packet
(e.g., IP address, ports, IPsec SPI)
• The server has to be able to push that key
to the client
• If the server wants intermediate boxes to
help it, the server gives them S
4/6/2016
IETF 78 SAAG
3
Pieces of the Puzzle
• Enough information in the unencrypted
header to uniquely determine this
session’s key (e.g., IPsec SPI, IP address)
• A way of pushing the key to the client
(e.g., a new method of doing rekeying)
• Modifying the TLS or IPsec header to
distinguish packets using derived keys
from legacy packets
4/6/2016
IETF 78 SAAG
4
Enterprise Security
Edge
Edge
Network
Traffic
Visibility
Preserved
for IT tools
Policy Server
(ACS/NPS/AD)
Corporate
Client A
Client B
IDS/IPS
Derivation key
used to compute
unique session key
for all authorized
clients
Client C
Server
Client_key=f (
Client D
4/6/2016
2. Policy + Key
Distribution by central
authority
3. Server exchanges auth
data and derives
session keys, per client
Data
???
Hacker
1. Credentials / health
check
No
Snooping /
Spoofing!
IETF 78 SAAG
, ID ),
4. Stateless security,
scaling with demand
5. Preserve session
independence / data
authenticity for each
client
6. Authorized devices
can inspect E2E traffic
flows by deriving key
5
Technology Components
1) Key Derivation
• Use a “Master Key” to create session keys that can be derived per-packet to
eliminate data plane cryptographic state maintenance
2) Secure Protocol Requirements
• Data Path
– Protocol identification for using derived key extensions
– Additional session context in each packet to allow on-the-fly key derivation
• Control Path
– Extending the handshake to ‘push’ a derived key from server to client
3) Bifurcated Keys
• Separates the trust boundaries for confidentiality and authenticity
• Provide for separate key material for encryption and integrity while preserving the
performance advantages of GCM combined mode operation (single pass
confidentiality and integrity)
• IETF draft
4/6/2016
IETF 78 SAAG
6
Protocol Requirements
• Identification
• Session context in the data packet to allow on-the-fly key derivation
IP (p=50)
ESP
IP (p=141?)
Context
Before:
After:
payload
ESP
Trailer
payload
Trailer
Record Hdr
Before:
IP/TCP/…
Content
= App
Version
payload
Length
Trailer
Record Hdr
After:
IP/TCP/…
Content =
App + 1
Context
Version
Length
payload
Trailer
• K_derived = f (K_derivation, ID)
• Where ID = session context
4/6/2016
IETF 78 SAAG
7
Key Distribution
Initiator / client
Responder / Server
 Message 1
Message 2
 Message 3
Message 4 HDR, SK {SA, Nr, [KEr], Ks, TSi, TSr}
…
[ChangeCipherSpec] 
 [ChangeCipherSpec (Ks)]
Finished 
 Finished
• Observations
• Key transport / verification happens in the last message(s)
• Session Key (Ks) is the derived key
• Other permutations possible
4/6/2016
IETF 78 SAAG
8
Bifurcated Key
•
•
•
•
Ak
Combined mode algorithm
Parallelizable
Highly efficient (10Gb+)
Two Keys
1. Encryption Key (Ek)
2. Integrity Key (Ak)
Packet before crypto
Header
Payload
Packet after crypto
Header
ciphertext
Authentication tag
Ciphertext and auth tag
generated using different keys
Enc-Key shared with TIs ; Auth-Key preserves E2E authenticity
4/6/2016
IETF 78 SAAG
9
Summary / Next Steps
• Traffic visibility is critical to Enterprise
environments
• Enterprises will trade security for
visibility, unless a solution is provided
---------------------------------------------------------• Community feedback / interest in solving
this problem
• Interested parties – please follow-up via
email for further discussion / next steps
4/6/2016
IETF 78 SAAG
10