Get documents about "Key Management in IP Multicast
Document Sample
Key Management in IP Multicast
17.11.2006
Petri Jokela
petri.jokela@nomadiclab.com
IP multicast
- Receiver joins a group
- Data transmission tree is built
Receiver Join (G, S)
- Source Specific
- S = source, G = group
Router
Receiver
Router Source
Router
Receiver
IP multicast
Data is multiplied at routers
Receiver If data is encrypted, how to
distribute keys?
Router
Receiver
Router Source
Router
Receiver
Multicast Security
●
IETF Multicast Security (MSEC) WG
●
Initial target:
– Security for one source, large number of
receivers
●
Currently:
– Finish current work before next summer
– Rechartering?
Multicast Security issues
●
Integrity of data
– Receiver: data is not modified
●
Secrecy
– Data cannot be seen by non-group members
●
Source authentication
– The data is coming from the correct source
– With shared traffic encryption keys, requires
other functions in IP multicast
– Not considered in Key Management
Keying
●
Keys
– Shared: Traffic Enc. Key (TEK), Key Enc. Keys
(KEK)
– Point-to-Point: Registration association
●
Problem: How to distribute shared keys?
– Currently we have centralized server
●
Use point-to-point link to deliver the KEK
– Use a KEK to encrypt TEK; deliver e.g. using
multicast data path
●
Re-key: member joins or leaves a group
Security Architecture
Multicast
Security Policy Server Policy Server
Policies
Group Group
Group Key Controller / Controller /
Management Key Server Key Server
Multicast Receiver
Data
Handling Sender Receiver
Group Security Association
Registration association Group
- point-to-point Controller /
Key Server
Re-key association
- Shared keys
o (Key Encryption Keys)
- Re-key message e.g.
using multicast
Data association
- Shared key
- Data transmission Sender Receiver
Logical Key Hierarchy
Logical Key Hierarchy
Keys and hierarchy
Server
u1 u2 u3 u4 u5 u6
●
Change in group (originally n users)
– Only TEK + Kun
●
join: n+1 encryptions (TEK with Ku)
●
leave: n-1 encryptions (TEK with Ku)
– TEK + 1 KEK + Kun
●
join: 1 encr. (TEK with KEK), n encr. (TEK with Ku)
●
leave: n-1 encr. (KEK with Ku), 1 encr (TEK with KEK)
Logical Key Hierarchy
●
RFC2627
●
Key Encryption Keys hierarchically
– Less encryption operations
– Less transmitted messages
●
GSAKMP and GDOI define this as optional
●
Defined but is it used?
– E.g. not in 3GPP
Logical Key Hierarchy
Keys and hierarchy
Server
K1 K2
K11 K12 K21 K22
u1 u2 u3 u4 u5 u6
K1 K1 K1 K1 K2 K2
K11 K11 K12 K12 K21 K22
Ku1 Ku2 Ku3 Ku4 Ku5 Ku6
KD KD KD KD KD KD
Key Encryption Key Array
Host's key (registration association)
Data Encryption key
Logical Key Hierarchy
Node leaving, keys that have to be renewed
Server
K1 K2
K11 K12 K21 K22
u1 u2 u3 u4 u5 u6
K1 K1 K1 K1 K2 K2
K11 K11 K12 K12 K21 K22
Ku1 Ku2 Ku3 Ku4 Ku5 Ku6
KD KD KD KD KD KD
Logical Key Hierarchy
New keys New keys: K'1, K'12,K'D
Server
K1 K2
K11 K12 K21 K22
u1 u2 u4 u5 u6
K1 K1 K1 K2 K2
K11 K11 K12 K21 K22
Ku1 Ku2 Ku4 Ku5 Ku6
KD KD KD KD KD
Logical Key Hierarchy
Keys and hierarchy
E(K11){K'1,K'D}
E(K2){K'D}
Server
E(Ku4){K'1, K'12,K'D}
K'1 K2
K11 K'12 K21 K22
u1 u2 u4 u5 u6
K1
K'1 K1
K'1 K1
K'1 K2 K2
K11 K11 K12
K'12 K21 K22
Ku1 Ku2 Ku4 Ku5 Ku6
KD
K'D KD
K'D KD
K'D K
K'D KD
K'D
D
Logical Key Hierarchy
Table of required storage and re-key transmissions
Storage Rekey transmissions
Users Degree per User (single key) (multi key)
8 2 4 5 3
9 3 3 5 4
16 2 5 7 4
2048 2 12 21 11
2187 3 8 20 14
131072 2 18 33 17
177147 3 12 32 22
Key Exchange Protocols
●
Protocols defined in the IETF
– Group Security Association Key Management
Protocol (GSAKMP)
– Multimedia Internet Keying (MIKEY)
– Group Domain of Interpretation (GDOI)
●
All define only multicast keying
– Re-key SA, Data SA
●
Registration not defined
– E.g. IKE used for creating registration SA
Group Security Association Key
Management Protocol (GSAKMP)
GSAKMP Trust Model
Group Owner
GCKS
S-GCKS S-GCKS
GM GM GM
(receiver) (receiver) (source)
GSAKMP Trust Model
Group Owner
GCKS
Group Owner (GO)
- Known and trusted party
- Creates the Policy Token (PT)
- PT contains
S-GCKS S-GCKS
- Identification of the group
- Access Control rules
- Authorization rules
- SA, Security Policy information
- PT verification information
GM GM GM
(receiver) (receiver) (source)
GSAKMP Trust Model
Group Owner
GCKS
GCKS
S-GCKS S-GCKS
- Responsible for
- key generation
- traffic and key encryption keys
- key distribution
- re-keying
- group membership management
GM GM GM
(receiver) (receiver) (source)
GSAKMP Trust Model
Subordinate GCKS
functions
- Support for distributed GCKSGroup Owner
- Same responsibilities as GCKS
- BUT: TEK only from GCKS
- Register to the GCKS
GCKS
- Verify GCKS's authority
S-GCKS S-GCKS
GM GM GM
(receiver) (receiver) (source)
GSAKMP Trust Model
Group Member (GM) Group Owner
GM has to:
- Verify that all security related actions are
GCKS
authorized
- Use group keys properly
GSAKMP cannot control who sends data to the group
-> Multicast protocol and application issue
Senders authorized in PT
S-GCKS S-GCKS
Sender configurations: 1, subset of GMs, or all
GM GM GM
(receiver) (receiver) (source)
GSAKMP Assumptions
●
GCKS or GO never compromized
●
PKI is trustworthy (for cert validation)
●
Compromized GM reported to GO
●
No precise time dependency (in security
related actions)
●
Compromized GM cannot decrypt further
traffic
●
Confidentiality, integrity, multicast source
authentication, and anti-replay protection
for GSAKMP messages
GSAKMP
Message Exchange
GM GCKS
(source) (or S-GCKS)
Create “Registration SA” Use e.g. IKEv1
Request to Join Only when the GM is
a source node
Key Download
Download the required
Key Download, Ack key information from
the GCKS
Shared Keyed Group Session
Acknowledge the
key download
GSAKMP
Message Exchange
GM GCKS
(source) (or S-GCKS)
Request to Join: {Key Creation; Nonce_I;} Signature
[; Certificate]
Key Download: {Member ID; Key Generation; PT;
Key Download} Signature [; certificate] )
Key Download, Ack: {Notification Ack} Signature
GSAKMP
●
Diffie-Hellman used for key generation
– protecting further downloads from the GCKS
●
GM leaves the group
– LKH MAY be used for re-keying
– “Many times it is best to rebuild the group”
●
Problem: This doesn't work with large groups
Multimedia Internet Keying
MIKEY
Multimedia Internet Key Exchange
●
Originally designed for real-time
applications
– Secure RTP
●
Issues
– Lower latency
– heterogeneous networks
– better performance for small, interactive
groups
MIKEY
Multimedia Internet Key Exchange
●
Source handles GCKS functions (usually)
●
No actual re-keying
– Changes in groups handled by setting up a
new connection
– Cannot efficiently support big and unstable
groups
– MBMS (3GPP) defines re-keying
MIKEY - scenarios
Host B Host A Host B
Host A
Host C
Host D
Host C
peer-to-peer / many-to-many
one-to-many p-2-p: e.g. SIP(distributed)
call
-(mutual security agreement or each
party for own outgoing)
Host A Host B
1-2-n:
- sender responsible for setting up
security parameters
Server
Host C
many-to-many
(centralized)
MIKEY - scenarios
Host B Host A Host B
Host A
Host C
Host D
Host C
peer-to-peer / many-to-many
one-to-many (distributed)
Small size group
Host A
1) Initiator acts as a GC (MIKEY) Host B
2) Authorization information is
delegated to other participants (not
Server
defined in MIKEY)
Host C
many-to-many
(centralized)
MIKEY - scenarios
Host B Host A Host B
Host A
Larger groupsHost C
Host setting up
- GCKS responsible forD
security parameters Host C
- Not main focus in MIKEY
peer-to-peer / many-to-many
one-to-many (distributed)
Host A Host B
Server
Host C
many-to-many
(centralized)
MIKEY – Generating a TGK
●
TGK = TEK Generation Key
●
Three methods
– Pre-shared key
●
TGK transferred using the pre-shared key
●
Efficient but not scalable
– Public-key based method
●
PKI needed for distributing public keys
– Diffie-Hellman key exchange
●
For peer-to-peer case
MIKEY: pre-shared key
Host A Host B
(initiator) (responder)
Pre-shared key exchange
E(encr_key, IDi || {TGK}
|| MAC )
pre-shared key is used HDR, T, RAND, [Idi], [Idr], {SP}, KEMAC
to generate encr_key
and auth_key
Optional response: HDR, T, [Idr], V
MIKEY: public keys
Host A Host B
(initiator) (responder)
Public-key exchange / Retrieval
E(encr_key, IDi || {TGK}
|| MAC )
HDR, T, RAND, [Idi|CERTi], [Idr], {SP},
KEMAC, [CHASH], PKE, SIGNi
E(pub.key R, env_key)
env_key is used to Optional response: HDR, T, [Idr], V
generate encr_key
and auth_key
MIKEY: Diffie-Hellman
Host A Host B
(initiator) (responder)
Public-key exchange / Retrieval
HDR, T, RAND, [Idi|CERTi], [Idr], {SP},
DHi, SIGNi
TGK is the shared
secret calculated
from DH values HDR, T, [Idr|CERTr], Idi, Dhr, Dhi, SIGNr
Group Domain Of Interpretation
GDOI
The Group Domain of Interpretation
●
Registration association with ISAKMP
phase 1
●
GDOI defines
– Re-key association setup
– Data association setup
●
TEK & KEK key transfer
– GROUPKEY_PULL: initiated by the member
– GROUPKEY_PUSH: initiated by the GCKS
GDOI: GROUPKEY_PULL
Member GCKS
Authentication Use e.g. IKEv1
HDR*, HASH(1), Ni, ID
HDR*, HASH(2), Nr, SA
HDR*, HASH(3), [KE_I], [CERT], [POP_I]
Liveliness check:
If Nr in HASH(3),
HDR*, HASH(4), [KE_R], [SEQ], calculate DH, install SA
KD, [CERT], [POP_R]
GDOI: GROUPKEY_PULL
Member GCKS
Authentication Use e.g. IKEv1
HDR*, HASH(1), Ni, ID
HDR*, HASH(2), Nr, SA
HDR: ISAKMP header
HDR*, HASH(3), M-ID | [CERT],
HASH: prf(SKEYID_a, [KE_I], Ni | ID ) [POP_I] Liveliness check:
Ni: Initiator Nonce If Nr in HASH(3),
Group ID to join
ID: HDR*, HASH(4), [KE_R], [SEQ], calculate DH, create SA
KD, [CERT], [POP_R]
GDOI: GROUPKEY_PULL
Member GCKS
Authentication Use e.g. IKEv1
HDR*, HASH(1), Ni, ID
HDR*, HASH(2), Nr, SA
HDR*, HASH(3), [KE_I], [CERT], [POP_I]
Liveliness check:
HDR: ISAKMP header If Nr in HASH(3),
HASH: prf(SKEYID_a, M-ID | Ni_b | Nr |calculate DH, create SA
HDR*, HASH(4), [KE_R], [SEQ], SA )
KD, [CERT], [POP_R]
Nr: Responder Nonce
SA: Security Association Policy Payload
e.g. SPI, traffic/re-key, POP algo, ...
GDOI: GROUPKEY_PULL
Member GCKS
HDR: ISAKMP header
HASH: prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ] [ | CERT ] [ |POP_I ] )
Authentication Use e.g. IKEv1
KE_I: Diffie-Hellman value for key generation
CERT: Certificate, if some other identity is used (than in Phase 1)
POP_I: Proof of Possession (signature)
HDR*, HASH(1), Ni, ID
HDR*, HASH(2), Nr, SA
HDR*, HASH(3), [KE_I], [CERT], [POP_I]
Liveliness check:
If Nr in HASH(3),
HDR*, HASH(4), [KE_R], [SEQ], calculate DH, create SA
KD, [CERT], [POP_R]
GDOI: GROUPKEY_PULL
Member GCKS
HDR: ISAKMP header
| SEQ ] KD [
HASH: prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [Use e.g. |IKEv1 |
Authentication
CERT ] [ | POP_R ] )
KE_R: Diffie-Hellman value for key generation
SEQ: HDR*, HASH(1), (PULL
Sequence numberNi, ID key exchange)
KD: TEK, KEK (depending on definitions in SA)
CERT: Certificate, authorization for providing keys
HDR*, HASH(2), Nr, SA
POP_R: Proof of Possession (signature)
HDR*, HASH(3), [KE_I], [CERT], [POP_I]
Liveliness check:
If Nr in HASH(3),
HDR*, HASH(4), [KE_R], [SEQ], calculate DH, create SA
KD, [CERT], [POP_R]
GDOI: GROUPKEY_PUSH
Member GCKS
Authentication Use e.g. IKEv1
HDR*, SEQ, SA, KD, [CERT,] SIG
HDR: ISAKMP header
SEQ: Sequence number (PUSH key exchange)
SA: Security Association Policy Payload
KD: TEK, KEK (depending on definitions in SA)
CERT: Certificate, authorization for providing keys
SIG: Proof of Possession (signature)
Host Identity Protocol
Host Identity Protocol
●
IP address roles currently
– Locator: describes the host's topological
location in the network
– Identifier: identifies the host
●
Problems
– How to know who is at the other end – IP
address is not enough
– Mobility difficult
HIP: Host Identities
●
Host Identity (HI): public key of a key pair
– Hosts can authenticate each other
●
Secure binding between HI and IP address
●
Locator is used only for data routing
– IP address not needed once the packet
arrives
– ESP mandatory (currently)
●
SPI used to find a correct ESP SA
●
HITs are mapped to the SA
●
Checksums using HITs
A new layer
●
New layer Process
●
IP <-> HI mapping
Transport Host ID
< , port>
IP address
●
Sockets bound to
HIs, not IPs
Host identity Host ID
●
Transparent to
applications
IP layer IP address
Link layer
HIP: negotiation
●
4-way message exchange
– Base Exchange (BEX)
– Host authentication: public and private keys
– Diffie-Hellman: common keying material
– Creates HIP association
●
Data traffic protection
– ESP currently mandatory
– ESP SA setup during BEX
– Other protocols may be defined later
Other HIP features
●
HI long => HIT (IPv6), LSI (IPv4)
●
IPv4/v6 interoperability
– mobility between v4 and v6 networks
– v4 and v6 applications can communicate
●
Some limitations due to applications
●
Easy mobility
– Dynamic IP – HIT mapping
– invisible to applications
●
Multihoming support (based on mobility)
– Independent of access technology
HIP Base Exchange
Initiator Responder
I1 <HITI, (HITR or NULL)>
ESP SA
established
R1 <HITI, HITR, ESP_TR, Challenge>
I2 <HITI, HITR, ESP_TR, SPI, Response, Authentication>
R2 <HITI, HITR, SPI, Authentication> ESP SA
established
Security Context Established
Data over ESP SA
HIP: v4 and v6 interoperability
v4 app v6 app v4 app v6 app
TCPv4 TCPv6 TCPv4 TCPv6
HI
HIT / LSI Host identity Host identity
IP
IPv4 IPv6 IPv4 IPv6
Link layer Link layer
HIP and current solutions
●
IPsec: considered ~hard to configure
●
Mobile IP large and complex
●
Mobile IPv4 and IPv6 do not work
together
●
No simple solution for multihoming
●
LOC: >100.000 vs. ~20.000
HIP Registration Protocol
Initiator Responder
I1 <...>
Select Inform about
service, services
R1 <... REG_INFO>
register
I2 <... REG_REQ>
Inform about
R2 <... REG_RESP> services
Merging HIP and GDOI
GDOI and HIP
●
GDOI: two phases
●
1) replace phase 1 with HIP
– Registration association
– New “service” needed (GCKS)
●
2) Group Key Exchange
– For now, use the GDOI phase 2
●
SKEYID_a (for hashes) from the negotiated keying
material
– In the future; HIP has UPDATE mechanism,
define multicast key transfer in UPDATE
HIP “Phase 1: registration”
Member GCKS
I1 <...> Inform about GCKS,
challenge,
D-H parameters,
R1 <... REG_INFO (GCKS)> GCKS authentication
Member authentication,
I2 <... CERT, REG_REQ (GCKS)>
Authorization (cert),
D-H params, challenge
R2 <... REG_RESP> solution, SPI
GCKS Authorization (cert),
SPI (registration SA),
HIP “Phase 2: group keys (PULL)”
UPDATE messages are not encrypted, key information
has to be inside ENCRYPTED parameter.
Member GCKS
UPDATE <SEQ, GK_REQ, HMAC, SIGN>
UPDATE <SEQ, ACK, ENCRYPTED (Kmember, {SA, KD})>
UPDATE <ACK>
HIP “Phase 2: group keys (PUSH)”
UPDATE messages are not encrypted, key information
has to be inside ENCRYPTED parameter.
Member GCKS
UPDATE <SEQ, ACK, ENCRYPTED (KEK, {SA, KD},
HMAC, SIGN)>
UPDATE <ACK> (?)
Advantages / disadvantages
●
For HIP hosts
– Small updates to existing HIP
implementations
– No need for other types of security
negotiations
●
Mobility management
– Mobile Member updates location to the GCKS
– Does not solve the IP multicast (“data
connection”) mobility
●
Future work
– Further optimization: Group UPDATE
