Group key management architecture - PowerPoint PPT Presentation

Group key management architecture <draft-ietf-msec-gkmarch-01.txt> Mark Baugher, Cisco Ran Canetti, IBM Lakshminath Dondeti, Nortel Fredrik Lindholm, Ericsson GKM Architecture, IETF-52, December 14, 2001 1 Salt Lake City

Overview of this talk • Introduction to GKMArch – Relative positioning in MSEC Ids – GKM protocols and SAs • Current revisions (00 � 01) • Outstanding issues – MIKEY – Rekey protocol • Conclusion GKM Architecture, IETF-52, December 14, 2001 2 Salt Lake City

GKM in MSEC architecture Centralized Designs Distributed Designs Policy Policy GKM GKM Receiver 1-to-M M-to-M Sender 1-to-M Receiver M-to-M GKM Architecture, IETF-52, December 14, 2001 3 Salt Lake City

GKMArch as part of MSEC IDs MSEC Requirements MSEC Architecture Group policy GKM Data security (GSPT) Architecture architecture Rekey protocol GDOI GSAKMP Light GKM Architecture, IETF-52, December 14, 2001 4 Salt Lake City

Purpose of GKMArch • Download SAs to members, securely – Data security SA, mainly – Rekey SA, to facilitate efficient updates to SAs • Update SAs via unicast or multicast • Manage membership – Joins and leaves – Support optional PFC and/or PBC in doing so • Download and/or update KM/SA policy to members GKM Architecture, IETF-52, December 14, 2001 5 Salt Lake City

GKMArch requirements • Allow reuse of existing protocols for data transmission – e.g. IPsec AH or ESP, AMESP, SRTP • Support diverse authentication, authorization and trust mechanisms • Support large single sender groups • Support small multi-sender groups GKM Architecture, IETF-52, December 14, 2001 6 Salt Lake City

SAs in GKMArch • GSA comprised of three SAs – Registration SA • Established via one-one bidirectional secure channels – e.g. IKE phase1, TLS, IPsec – Rekey SA (optional) • Initialized during registration • Initialized/updated during rekey (uni-directional) – Data security SA • Initialized during registration • Initialized/updated during rekey (uni-directional) GKM Architecture, IETF-52, December 14, 2001 7 Salt Lake City

Protocols in GKMArch • Registration protocol – Protected by registration SA • Rekey protocol ( optional ) – Protected by rekey SA • Data security protocol ( external to GKM ) – Protected by data security SA GKM Architecture, IETF-52, December 14, 2001 8 Salt Lake City

GKM entities and protocols Policy Trust infrastructure infrastructure KDC Registration Registration protocol Rekey protocol GKM plane protocol Sender Receiver(s) Data security protocol GKM Architecture, IETF-52, December 14, 2001 9 Salt Lake City

GKM entities and protocols Policy Trust infrastructure infrastructure KDC Registration Registration protocol protocol GKM plane Sender Receiver(s) Data security protocol GKM Architecture, IETF-52, December 14, 2001 10 Salt Lake City

Scalability of GKMArch • Registration could be done off-line • Delegation of registration “service” • Loose coupling of registration and rekey protocols • Rekey protocol with key revocation algms – LKH, OFT, OFC, SDR (subset diff), STR – Multicast of rekey messages • Delegation of rekey service GKM Architecture, IETF-52, December 14, 2001 11 Salt Lake City

Overview of this talk • Introduction to GKMArch – Relative positioning in MSEC Ids – GKM protocols and SAs • Current revisions (00 � 01) • Outstanding issues – MIKEY – Rekey protocol • Conclusion GKM Architecture, IETF-52, December 14, 2001 12 Salt Lake City

Revisions (00 � 01) • Addressed issues raised in mailing list – Have not heard any complaints! • Did we do such a good job of that? ☺ • Notes about de-registration protocol – De-registration is not supported! • KDC � GCKS – (what were we thinking?) • SHOULD, MUST etc in IETF sense GKM Architecture, IETF-52, December 14, 2001 13 Salt Lake City

Overview of this talk • Introduction to GKMArch – Relative positioning in MSEC Ids – GKM protocols and SAs • Current revisions (00 � 01) • Outstanding issues – MIKEY – Rekey protocol • Conclusion GKM Architecture, IETF-52, December 14, 2001 14 Salt Lake City

Outstanding issues • Fold MIKEY requirements into GKMArch I-D – Small interactive group security reqs. • Rekey protocol description back in GKMArch – Yet to be resolved! – Looking for WG consensus – Details in another presentation GKM Architecture, IETF-52, December 14, 2001 15 Salt Lake City

Conclusion • A scalable architecture for GKM – Supports large single sender groups and – Small interactive multi-sender groups • Scalability by – Delegation – Multicast of GSA updates • Incorporate MIKEY reqs in –02- • Discussion on rekey protocol to follow GKM Architecture, IETF-52, December 14, 2001 16 Salt Lake City