Group key management architecture - - PowerPoint PPT Presentation

▶
group key management architecture
SMART_READER_LITE
LIVE PREVIEW

Group key management architecture - - PowerPoint PPT Presentation

Feb 16, 2023 374 likes •552 views

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

slide-1
SLIDE 1

December 14, 2001 GKM Architecture, IETF-52, Salt Lake City 1

Group key management architecture

<draft-ietf-msec-gkmarch-01.txt>

Mark Baugher, Cisco Ran Canetti, IBM Lakshminath Dondeti, Nortel Fredrik Lindholm, Ericsson

slide-2
SLIDE 2

December 14, 2001 GKM Architecture, IETF-52, Salt Lake City 2

Overview of this talk

  • Introduction to GKMArch

– Relative positioning in MSEC Ids – GKM protocols and SAs

  • Current revisions (0001)
  • Outstanding issues

– MIKEY – Rekey protocol

  • Conclusion
slide-3
SLIDE 3

December 14, 2001 GKM Architecture, IETF-52, Salt Lake City 3

GKM in MSEC architecture

Receiver Receiver 1-to-M 1-to-M Sender Centralized Designs Distributed Designs M-to-M M-to-M Policy GKM Policy GKM

slide-4
SLIDE 4

December 14, 2001 GKM Architecture, IETF-52, Salt Lake City 4

GKMArch as part of MSEC IDs

MSEC Requirements MSEC Architecture GKM Architecture Data security architecture Rekey protocol GSAKMP Light Group policy (GSPT) GDOI

slide-5
SLIDE 5

December 14, 2001 GKM Architecture, IETF-52, Salt Lake City 5

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

slide-6
SLIDE 6

December 14, 2001 GKM Architecture, IETF-52, Salt Lake City 6

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
slide-7
SLIDE 7

December 14, 2001 GKM Architecture, IETF-52, Salt Lake City 7

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)
slide-8
SLIDE 8

December 14, 2001 GKM Architecture, IETF-52, Salt Lake City 8

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

slide-9
SLIDE 9

December 14, 2001 GKM Architecture, IETF-52, Salt Lake City 9

GKM entities and protocols

Policy infrastructure Trust infrastructure KDC Receiver(s) Sender Registration protocol Registration protocol Rekey protocol

GKM plane

Data security protocol

slide-10
SLIDE 10

December 14, 2001 GKM Architecture, IETF-52, Salt Lake City 10

GKM entities and protocols

Policy infrastructure Trust infrastructure KDC Receiver(s) Sender Registration protocol Registration protocol

GKM plane

Data security protocol

slide-11
SLIDE 11

December 14, 2001 GKM Architecture, IETF-52, Salt Lake City 11

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
slide-12
SLIDE 12

December 14, 2001 GKM Architecture, IETF-52, Salt Lake City 12

Overview of this talk

  • Introduction to GKMArch

– Relative positioning in MSEC Ids – GKM protocols and SAs

  • Current revisions (0001)
  • Outstanding issues

– MIKEY – Rekey protocol

  • Conclusion
slide-13
SLIDE 13

December 14, 2001 GKM Architecture, IETF-52, Salt Lake City 13

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
slide-14
SLIDE 14

December 14, 2001 GKM Architecture, IETF-52, Salt Lake City 14

Overview of this talk

  • Introduction to GKMArch

– Relative positioning in MSEC Ids – GKM protocols and SAs

  • Current revisions (0001)
  • Outstanding issues

– MIKEY – Rekey protocol

  • Conclusion
slide-15
SLIDE 15

December 14, 2001 GKM Architecture, IETF-52, Salt Lake City 15

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

slide-16
SLIDE 16

December 14, 2001 GKM Architecture, IETF-52, Salt Lake City 16

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