SLIDE 1
March 17, 2003 IETF-56, San Francisco MSEC WG meeting 2
Introduction
Group key management architecture Group key management protocols
GDOI, GSAKMP, MIKEY
Group key management algorithms
LKH, OFT, OFC, MARKS, Subset diff etc.
Group key management algorithms (GKMA) Lakshminath R. Dondeti - - PowerPoint PPT Presentation
Group key management algorithms (GKMA) Lakshminath R. Dondeti - - PowerPoint PPT Presentation
Group key management algorithms (GKMA) Lakshminath R. Dondeti Brian Weis IE TF-56 MSEC WG meeting San Francisco, Mar 17 2003 Introduction Group key management architecture Group key management protocols GDOI, GSAKMP, MIKEY
SLIDE 2
SLIDE 3
March 17, 2003 IETF-56, San Francisco MSEC WG meeting 3
Group key management algorithms
LKH, OFT, OFC (stateful): expired I-Ds LKH is an informational RFC Subset difference (stateless): expired I-Ds MARKS: expired I-D GSAKMP and GDOI include support for LKH
Allow extensions to support other GKMAs
SLIDE 4
March 17, 2003 IETF-56, San Francisco MSEC WG meeting 4
GKMA standardization
LKH, OFT and OFC use similar logical trees
One RFC may cover this Consider immediate as well as batch rekeying Brian and Lakshminath working on an I-D ☺
Previous efforts by David McGrew and
Lakshminath
Group key transport protocol (GKTP)
Subset difference? MARKS?
Any known efforts to standardize these?
SLIDE 5
March 17, 2003 IETF-56, San Francisco MSEC WG meeting 5
Group key transport protocol
GKTP
Rekey and feedback messages
Rekey messages are part of GKM arch I-D Feedback messages are covered in a separate I-D
New I-D submitted by Lakshminath and Thomas Key tree management
Key tree encoding
SLIDE 6
March 17, 2003 IETF-56, San Francisco MSEC WG meeting 6
Key tree management
Key trees
may grow and shrink with membership changes Fixed-size trees
Do we need to include node ID changes?
Yes No (implicit in key changes)
Several known key tree encoding schemes
Binary number encoding Natural number encoding (works for d > 2)
SLIDE 7
March 17, 2003 IETF-56, San Francisco MSEC WG meeting 7
Binary encoding
1 00 10 01 11
SLIDE 8
March 17, 2003 IETF-56, San Francisco MSEC WG meeting 8
Natural number encoding of key trees
2 3 4 6 5 7 1
SLIDE 9
March 17, 2003 IETF-56, San Francisco MSEC WG meeting 9
After two joins and member 7’s departure
2 3 4 6 5 7 1 8 9
SLIDE 10
March 17, 2003 IETF-56, San Francisco MSEC WG meeting 10
Key tree management
In the previous schemes, tree grows
by splitting a leaf node split an internal node or the root node itself
Tree shrinking occurs
Only if the highest numbered node has departed
Next member to join receives position “7” Node number update messages may be sent in
- r along with rekey messages
SLIDE 11
March 17, 2003 IETF-56, San Francisco MSEC WG meeting 11
Encoding proposed by Zhang et. al.
Natural number encoding {kj}ki is identified with the ID of ki
Assuming kj is ki’s parent
Too simplistic for OFT
The key tree is always full and balanced
Null nodes are introduced to make it so
Joins and leaves may change the leaf-node IDs Members can determine their new ID using old
ID and the max internal key node ID.
SLIDE 12
March 17, 2003 IETF-56, San Francisco MSEC WG meeting 12
Rekey messages
Send the max. internal key node ID in rekey
messages
Works for immediate and batch rekeying Might not work for OFT?
SLIDE 13
March 17, 2003 IETF-56, San Francisco MSEC WG meeting 13
Next steps: Option 1
Standardized key tree encoding Try to design a scheme that works for
LKH/ OFT/ OFC etc.
Don’t send key node ID changes in rekey
messages
Keep the trees as efficient as possible
No static trees! Static trees inefficient if instantaneous membership
size is typically smaller than subscription base
SLIDE 14
March 17, 2003 IETF-56, San Francisco MSEC WG meeting 14
Next steps: Option 2
GCKS may advertise a standardized scheme
and use it
Tradeoffs in footprint, communication cost etc.,
This stems from different people having
different ideas in key tree management
But we will make them publish a standards RFC