File: rfc2093.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1291 lines) | stat: -rw-r--r-- 48,678 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291






Network Working Group                                          H. Harney
Request for Comments: 2093                                 C. Muckenhirn
Category: Experimental                                      SPARTA, Inc.
                                                               July 1997


           Group Key Management Protocol (GKMP) Specification

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Table of Contents

   1. Background..................................................... 1
   2. Overview:  GKMP Roles.......................................... 3
   3. Data Item primitives........................................... 4
   4. Message definitions............................................ 6
   5. State definitions.............................................. 9
   6. Functional Definitions--Group Key Management Protocol.......... 13
   7. Security Considerations........................................ 23
   8. Author's Address............................................... 23

Abstract

   This specification proposes a protocol to create grouped symmetric
   keys and distribute them amongst communicating peers. This protocol
   has the following advantages: 1) virtually invisible to operator, 2)
   no central key distribution site is needed, 3) only group members
   have the key, 4) sender or receiver oriented operation, 5) can make
   use of multicast communications protocols.

1 Background

   Traditional key management distribution has mimicked the military
   paper based key accounting system.  Key was distributed, ordered, and
   accounted physically leading to large lead times and expensive
   operations.

   Cooperative key management algorithms exist that allow pairwise keys
   to be generated between two equipment's.  This gives the a quicker
   more reliable key management structure capable of supporting large
   numbers of secure communications.  Unfortunately, only pairwise keys
   are supported using these methods today.




Harney & Muckenhirn           Experimental                      [Page 1]

RFC 2093                   GKMP Specification                  July 1997


   This document describes a protocol for establishing and rekeying
   groups of cryptographic keys (more than two) on the internet.  We
   refer to the approach as the Group Key Management Protocol (GKMP).

1.1 Protocol Overview

   The GKMP creates key for cryptographic groups, distributes key to the
   group members, ensures (via peer to peer reviews) rule based access
   control of keys, denies access to known compromised hosts, and allow
   hierarchical control of group actions.

   The key generation concept used by the GKMP is cooperative generation
   between two protocol entities.  There are several key generation
   algorithms viable for use in the GKMP (i.e., RSA, Diffe-Hellman,
   elliptic curves).  All these algorithms use asymmetric key technology
   to pass information between two entities to create a single
   cryptographic key.

   The GKMP then distributes the group keys to qualified GKMP entities.
   This distribution process is a mutually suspicious process (all
   actions and identities must be verified).

   The GKMP provides a peer to peer review process.  Protocol entities
   pass permission certificates (PC) as part of the group key
   distribution process.  The PCs contain access control information
   about a particular site.  This access control information is assigned
   by a higher authority which then signs the PC. Therefor each entity
   can verify the permissions of any other GKMP entity but can modify
   none.  Each protocol entity checks the permissions and compares them
   the level of service requested.  If the permissions do not exceed or
   equal the request, the service is denied.

   The GKMP supports compromise recovery.  A list of compromised GKMP
   entities is distributed to group members during key management
   actions.  In essence, a Compromise Recovery List (CRL) allows group
   members to drop connections with compromised entities.  The GKMP
   delegates control of groups to specific group controllers so it will
   be somewhat easier to distribute the CRL to the most important GKMP
   entities.  During each key management action the CRL version number
   is passed, when a CRL update is detected it is downloaded and
   verified (it is signed by a higher authority).

   The GKMP allows control of group actions.  In certain networks it is
   desirable for a higher authority to strictly control the generation
   of groups.  These networks usually have a central network operations
   authority.  The GKMP allows these authorities to remotely order group
   actions.  These orders are signed by that authority and verified by
   all entities involved with the group.



Harney & Muckenhirn           Experimental                      [Page 2]

RFC 2093                   GKMP Specification                  July 1997


   The GKMP is an application layer protocol.  It's independent of the
   underlying communication protocol.  However, if multicast service is
   available it will speed the rekey of the cryptographic groups.
   Hence, the GKMP does use multicast services if they are available.

2 Overview:  GKMP Roles

   Creation and distribution of grouped key require assignment of roles.
   These identify what functions the individual hosts perform in the
   protocol.  The two primary roles are those of key distributor and
   member.  The controller initiates the creation of the key, forms the
   key distribution messages, and collects acknowledgment of key receipt
   from the receivers.  The members wait for a distribution message,
   decrypt, validate, and acknowledge the receipt of new key.

2.1 Group controller

   The group controller (GC) is the a group member with authority to
   perform critical protocol actions (i.e., create key, distribute key,
   create group rekey messages, and report on the progress of these
   actions).  All group members have the capability to be a GC and could
   assume this duty upon assignment.

   The GC helps the cryptographic group reach and maintain key
   synchronization.  A group must operate on the same symmetric
   cryptographic key.  If part of the group loses or inappropriately
   changes it's key, it will not be able to send or receive data to
   another host operating on the correct key.  Therefor, it is important
   that those operations that create or change key are unambiguous and
   controlled (i.e., it would not be appropriate for multiple hosts to
   try to rekey a net simultaneously).  Hence, someone has to be in
   charge -- that is the controller.

2.2 Group member

   Simply stated a group member is any group host who is not acting as
   the controller.  The group members will:  assist the controller in
   creating key, validate the controller authorization to perform
   actions, accept key from the controller, request key from the
   controller, maintain local CRL lists, perform peer review of key
   management actions, and manage local key.










Harney & Muckenhirn           Experimental                      [Page 3]

RFC 2093                   GKMP Specification                  July 1997


3 Data Item primitives

3.1 Group members list:

   In a sender oriented group, the GC must be given a list of net
   members.  The controller will then initiate contact with these net
   members and create the group.

3.2 Group Token:

   The group token is created by the authority which commands a group.
   The Token contains information the net members need to ensure a
   controller is authorized to create a group and exactly what
   constrains are intended to be places on the group.  The group token
   contains the following fields:  Group identification,

   o  GC ID,

   o  Group action (create, rekey, delete),

   o  Group permissions (rules to guide access control),

   o  Rekey interval (life span of group key),

   o  Token version (identifier to identify current token),

   o  Token signature (asymmetric signature using the group
      commanders private key),

   o  Group commanders public key (this public key is itself signed by
      the network security manager to bind the public to a specific net
      member ID).

3.3 Grp ID:

   The group must be uniquely identified to allow for several different
   groups to coexist on a network.

3.4 GTEK ID:

   Unique identifier of GTEK (can include state information).

3.5 GKEK ID:

   Unique identifier of GKEK (can include state information).






Harney & Muckenhirn           Experimental                      [Page 4]

RFC 2093                   GKMP Specification                  July 1997


3.6 GTEK creation field:

   In a cooperative key creation protocol each party contributes some
   field used to create the key.

3.7 GKEK creation field:

   In a cooperative key creation protocol each party contributes some
   field used to create the key.

3.8 Distributor signature:

   Asymmetric signature using the GCs private key.

3.9 Distributor public key:

   Public half of the GCs signature key pair.  (this public key is
   itself signed by the network security manager to bind the public to a
   specific net member ID.

3.10 Member signature:

   Asymmetric signature using the selected members private key.

3.11 Member public:

   Public half of the selected members signature key pair.  (this public
   key is itself signed by the network security manager to bind the
   public to a specific net member ID.

3.12 Controller permissions:

   Controller permissions are assigned by the security manager.  The
   security managers signature will bind the permissions to the
   controller ID.

3.13 SKEK ID:

   This field identifies exactly which SKEK is being created.  This
   allows multiple groups to interoperate on a net simultaneously.

3.14 SKEK creation field:

   This field contains the information contributed for use in the KEK
   creation process.






Harney & Muckenhirn           Experimental                      [Page 5]

RFC 2093                   GKMP Specification                  July 1997


3.15 Member permissions:

   Member permissions are assigned by the security manager.  The
   security managers signature will bind the permissions to the
   controller ID.

3.16 Encrypted Grp Keys:

   This data item is encrypted in the KEK (session or group) created for
   the download of keys.  It is the GTEK and GKEK created for a group.
   A checksum is also encrypted.  This ensures the confidentiality and
   data integrity of the GTEK and GKEK.

3.17 Confirmation of decryption:

   This is a short (byte) field indicating decryption of the message and
   exactly what type of message was decrypted.

3.18 Request:

   A request field contains the specific request one net member may make
   to another.  The requests range from (group join, CRL update,
   pairwise TEK generation, detection, group creation, status).

   Member delete list:

   A list of group members being administratively deleted from the
   group.

4 Message definitions

4.1 Command_Create Group:

   This message contains the following data item primitives (Group
   members, Grp ID, Grp controller ID, Grp action, Grp permissions,
   Rekey interval, Token version, Token signature, Token public key).
   This message may be confidential due to the group permissions field.
   In sensitive systems it will need encryption prior to transmission.

4.2 Create Grp Keys_1:

   This message passes the information needed to create the group keys
   from the GC to the selected net member.  This message contains (Grp
   ID, Request, GTEK ID, GKEK ID, GTEK creation field, GKEK creation
   field, Grp token, Controller signature, Controller public)






Harney & Muckenhirn           Experimental                      [Page 6]

RFC 2093                   GKMP Specification                  July 1997


4.3 Create Grp Keys_2:

   This message passes the information needed to create the group keys
   from the selected net member to the GC. This message contains:  (Grp
   ID, GTEK ID, GKEK ID, GTEK creation field, GKEK creation field,
   member signature, member public)

4.4 Negotiate Grp Keys_1:

   This message passes the group token and GCs permissions to the
   selected net member.  This information can be sensitive and needs to
   be protected.  Therefor, this message is encrypted in the GTEK just
   created.  This encryption includes the appropriate data integrity
   checks.  This message1 contains:  (Grp ID, TEK ID, KEK ID, Group
   token, Controller permissions)

4.5 Negotiate Grp Keys_2:

   This message passes the selected net members permissions to the GC.
   This message1 contains:  (Grp ID, GTEK ID, GKEK ID, Member
   permissions).  This information can be sensitive and needs to be
   protected.  Therefor, this message is encrypted in the GTEK just
   created.  This encryption includes the appropriate data integrity
   checks.

4.6 Create Session KEK_1:

   This message sends information to create a KEK for one time use
   between the GC and selected net member.

4.7 Create Session KEK_2:

   This message sends information to create a KEK for one time use
   between the selected net member and GC.

4.8 Negotiate Session Keys_1:

   This message passes the group ID, SKEK ID, CRL version number, Group
   token and GCs permissions to the selected net member.  This
   information can be sensitive and needs to be protected.  Therefor,
   this message is encrypted.  If an appropriate pairwise key is
   available then that key should be used.  If not the KEK just created
   could be used to encrypt the message.








Harney & Muckenhirn           Experimental                      [Page 7]

RFC 2093                   GKMP Specification                  July 1997


4.9 Negotiate Session Keys_2:

   This message identifies the group, SKEK, CRL version number and the
   member permissions.  This information can also be sensitive and needs
   protection.

4.10 Download Grp Keys:

   This message includes a GRP ID and Encrypted Grp Keys data items.

4.11 Key download ack:

   This message contains the GRP ID and Confirmation_decryption data
   items.  It confirms the receipt and verified decryption of the GTEK
   and GKEK.

4.12 Rekey _Multicast:

   This message contains:  Grp ID, GTEK ID, GKEK ID, Group token,
   Controller permissions.  The rekey message is encrypted in the GKEK
   already resident in all the group member sites.  This leads to a
   single message capable of being accepted by all group members.

4.13 Request_Group_Join:

   This message contains Request, Grp ID, Member Signature, Member
   Public.

4.14 Delete_Group_Keys:

   This message contains:  grp ID, Request, Member delete list,
   Controller signature, Controllers public.

4.15 Grp_Keys_Deleted_Ack:

   This message contains (grp ID, member ID, member signature, member
   public.

4.16 Delete_Group_Keys:

   This message contains (grp ID, request, member delete list,
   controller signature, controller public).

4.17 Grp_Keys_Deleted_Ack:

   This message contains (grp ID, member ID, member signature, member
   public)




Harney & Muckenhirn           Experimental                      [Page 8]

RFC 2093                   GKMP Specification                  July 1997


5 State definitions

   There are thirteen separate states the in the protocol.  They are
   described below:

5.1 State 1:

   The source address is checked to ensure it is not on the CRL.

   The token field is validated with the public key of the source.

   The token version number is checked to ensure this token is current.

   The group ID is checked to see if this group exists.

   The controller ID field is then read.  If the receiver is listed as
   the GC, the receiver assumes the role of controller.  If not, the
   role assumed is that of receiver.

   The GC reads the group permission field in the group token.  It then
   verifies that its' personnel permissions exceed or equal those of the
   group.

   The GC will creates its' portion of the key creation message.

   The Create Grp Keys_1 message is completed and transmitted.

5.2 State 2:

   The source signature field is validated using the public key of the
   source.

   The source ID field is compared against the local CRL. If the source
   is on the CRL the association is terminated.

   The request field is read.  The local contributions to the group keys
   are created.

   The Group keys are created and stored pending negotiation.

   The key table is updated to show the group key pending negotiation.

5.3 State 3:

   The permission certificate is retrieved and validated using the
   security managers public key.  The permissions of the message source
   are checked to verify they meet or exceed those of the group.




Harney & Muckenhirn           Experimental                      [Page 9]

RFC 2093                   GKMP Specification                  July 1997


   The group token is retrieved and validated using the appropriate
   public key.

   The token version number is checked to ensure the token is current.

   The group ID specified in the token is compared with the actual group
   ID. If they are different the exchange is terminated.

   The controller ID specified in the token is compared with the GC ID.
   If they do not match the exchange is terminated.

   The local permissions are compared to the permissions specified for
   the group.  If they do not meet or exceed the group permissions the
   exchange is terminated and a report is generated.

   The rekey interval specified in the token is stored locally.

   The key table is updated to reflect the key permissions, rekey
   interval, group ID and current time.

5.4 State 4:

   The permission certificate is retrieved and validated using the
   security members public key.  The permissions of the message source
   are checked to verify they meet or exceed those of the group.

   The key table is updated to reflect the key permissions, rekey
   interval, group ID and current time.

5.5 State 5:

   The source signature field is validated using the public key of the
   source.

   The source ID field is compared against the local CRL. If the source
   is on the CRL, the association is terminated.

   The request field is read.  The local contribution to the SKEK are
   created.  The SKEK is created and stored pending negotiation.

   The key table is updated to show the SKEK pending negotiation.

5.6 State 6:

   The permission certificate is retrieved and validated using the
   security managers public key.  The permissions of the message source
   are checked to verify they meet or exceed those of the group.




Harney & Muckenhirn           Experimental                     [Page 10]

RFC 2093                   GKMP Specification                  July 1997


   The group token is retrieved and validated using the appropriate
   public key.

   The token version number is checked to ensure the token is current.

   The group ID specified in the token is stored.

   The controller ID specified in the token is compared with the GC ID.
   If they do not match the exchange is terminated.

   The local permissions are compared to the permissions specified for
   the group.  If they do not meet or exceed the group permissions the
   exchange is terminated and a report is generated.

   The rekey interval specified in the token is stored locally.

   The key table is updated to reflect the key permissions, rekey
   interval, group ID and current time.

5.7 State 7:

   The permission certificate is retrieved and validated using the
   security managers public key.  The permissions of the message source
   are checked to verify they meet or exceed those of the group.

   The key table is updated.

5.8 State 8:

   The group ID is checked.

   The group keys are decrypted using the SKEK. Data integrity checks
   are validated to ensure proper decryption.

   The key table is updated to reflect the new group keys, key
   permissions, rekey interval, group ID and current time.

5.9 State 9:

   Update group management log.

5.10 State 10:

   The permission certificate is retrieved and validated using the
   security managers public key.  The permissions of the message source
   are checked to verify they meet or exceed those of the group.





Harney & Muckenhirn           Experimental                     [Page 11]

RFC 2093                   GKMP Specification                  July 1997


   The group token is retrieved and validated using the appropriate
   public key.

   The token version number is checked to ensure the token is current.

   The group ID specified in the token is checked.

   The controller ID specified in the token is compared with the GC ID.
   If they do not match the exchange is terminated.

   The local permissions are compared to the permissions specified for
   the group.  If they do not meet or exceed the group permissions the
   exchange is terminated and a report is generated.

   The rekey interval specified in the token is stored locally.

   The new group keys are decrypted with the current GKEK. The data
   integrity field is checked to ensure proper decryption.

   The key table is updated to reflect the key permissions, rekey
   interval, group ID and current time.

5.11 State 11:

   Validate signature using sources public key.

   Check to see if member initiated group join is available.  If not,
   ignore.  If so begin distribution of group keys.

5.12 State 12:

   Validate signature using GCs public.

   Retrieve delete list.  Check to see if on delete list, if so
   continue.

   Create Grp_Keys_Deleted_Ack

   Delete group keys

5.13 State 13:

   Validate signature using GCs public.

   Retrieve delete list.  If list is global delete, verify alternative
   key.

   Switch group operations to alternative key.



Harney & Muckenhirn           Experimental                     [Page 12]

RFC 2093                   GKMP Specification                  July 1997


   Create Grp_Keys_Deleted_Ack.

   Delete group keys.

6 Functional Definitions--Group Key Management Protocol

   The GKMP consists of multiple functions necessary to create,
   distribute, rekey and manage groups of symmetric keys.  These
   functions are:

   o  Group creation (sender initiated group)


       --  Create Group keys

       --  Distribute Group keys

   o  Group rekey


       --  Create Group keys

       --  Rekey Group


   o  Member initiated join

   o  Group member delete

   The following sections will describe each function, including data
   primitives and message constructs.  The associated diagrams will
   represent the specifics (sequence, location and communications
   sources and destinations) of the messages and processes necessary.

6.1 Group creation

   Member initialization is a three-step function that involves
   commanding the creation of the group, creation of the group keys and
   then distribution of those keys to "other" group members.  Messages
   between the GC and the first member generate two keys for future
   group actions:  the group traffic encryption key (GTEK) and the group
   key encryption key (GKEK). Messages between the GC and the other
   members are for the purpose of distributing the keys.  These
   functions are described in the following sections.







Harney & Muckenhirn           Experimental                     [Page 13]

RFC 2093                   GKMP Specification                  July 1997


6.1.1 Group command

   The very first action is for some entity to command the group.  This
   command is sent to the GC.

6.1.2 Create group keys

   The first member must cooperate with the GC to create future group
   keys.  Reliance on two separate hosts to create group keys maximizes
   the probability that the resulting key will have the appropriate
   cryptographic properties.  A single host could create the key if the
   randomization function were robust and trusted.  Unfortunately this
   usually requires specialized hardware not available at most host
   sites.  The intent of this protocol was to utilize generic hardware
   to enhance the extendibility of the GKMP. Hence, cooperative key
   generation mechanisms are used.

   To facilitate a well ordered group creation, management information
   must be passed between the controller and the group members.  This
   information uniquely identifies the GC identity, it's permissions,
   authorization to create keys, the future groups permissions, current
   state of the compromise list, and management information pertaining
   to the keys being created.  All this information is protected from
   forgery by asymmetric signature technologies.  The public key used to
   verify net wide parameters (e.g., individual host permissions) are
   widely held.  The public key to verify locally generated information,
   like peer identity, is sent with the messages.  This alleviates the
   hosts public key storage requirements.

   The goals of the key creation process are:

   o  cooperatively generate a GTEK and GKEK,

   o  allow the key creators to verify the identity of the key
      creation partner by verifying the messages signatures.

   o  share public keys

   o  allow validation of the GC, by signing the group
      identification, GC identification, and group permissions.

   o  send the group identity, GC identity, group member identities,
      group permissions, and group rekey interval to the first member,
      signed by the group commander (when the group was remotely
      commanded).






Harney & Muckenhirn           Experimental                     [Page 14]

RFC 2093                   GKMP Specification                  July 1997


   This function consists of four messages between the GC and the first
   member.  The initial messages are for the establishment of the GTEK
   and GKEK. This is accomplished by the GC sending a signed
   Create_Group_Keys_1 message to the first member.  This message
   contains two random values necessary to generate the GTEK and GKEK.
   This message also contains the public key of the GC.

   The first member validates the signed Create_Group_Keys_1 message,
   builds and sends a signed Create_Group_Keys_2 message to the GC. He
   generates the GTEK and GKEK, and stores the received public key.  The
   Create_Group_Keys_2 message contains the random values necessary for
   the GC to generate the GTEK and GKEK. This message also contains the
   public key of the first member.

   The GC validates the signed Create_Group_Keys_2 message, generates
   the GTEK and GKEK, builds the Negotiate_Group_Keys_1 message for
   transmission to the first member, and stores the received public key.

   The GC sends the Negotiate_Group_Keys_1 message to the first member
   encrypted in the GTEK that was just generated.

|___Net_Controller___|__________Messages__________|____Net_Member_B____|
|The Create Group    |<---- Command-Create Group  |                    |
|command is          |                            |                    |
|received by net     |                            |                    |
|member A.           |                            |                    |
|State 1             |                            |                    |
|                    |Create Grp Keys_1---->      |                    |
|                    |                            |State 2             |
|                    |<-----Create Grp Keys_2     |                    |
|State 2             |                            |                    |
|                    |Negotiate Grp Keys_1------> |                    |
|                    |                            |State 3             |
|                    |<-----Negotiate Grp Keys_2  |                    |
|State 4             |                            |                    |
              Figure 1:  State Diagram:  Create Group Keys


   The first member decrypts the Negotiate_Group_Keys_1 message and
   extracts the group identification, GC identification, group members,
   group permissions, key rekey interval, CRL version number, and
   certifying authority signature.  The group identification, GC
   identification, and group permissions fields are validated based on
   the extracted group commanders signature (if this is a remotely
   commanded group this signature identifies the remote host).  If these
   fields validate, the first members internal structures are updated.





Harney & Muckenhirn           Experimental                     [Page 15]

RFC 2093                   GKMP Specification                  July 1997


6.1.3 Distributing Group Keys to Other Members

   The other group members must get the group keys before the group is
   fully operational.  The purpose of other group member initialization
   is as follows:

   o  cooperatively generate a session key encryption key (SKEK) for the
      transmission of the GTEK and GKEK from the GC,

   o  allow each member to verify the identify of the controller and
      visa versa,

   o  allow each member to verify the controllers authorization to
      create the group,

   o  send the key packet (KP) (consisting of the GTEK, GKEK), group
      identity, GC identity, group member identities, group permissions,
      and group rekey interval to the other members,

   This function consists of six messages between the GC and the other
   members.  The initial messages are for the establishment of a SKEK.
   This is accomplished by the GC sending a signed Create_Session_KEK_1
   message to the other member.  This message contains the random value
   necessary for the other member to generate the SKEK. This message
   also contains the public key of the GC.

   The other member validates the Create_Session_KEK_1 message, builds
   and sends a Create_Session_KEK_2 message to the GC, generates the
   SKEK, and stores the received public key.  The Create_Session_KEK_2
   message contains the random value necessary for the GC to generate
   the SKEK.  This message also contains the public key of the other
   member.

   The GC validates the Create_Session_KEK_2 message, generates the
   SKEK, builds the Negotiate_Session_ KEK_1 message for transmission to
   the other member, and stores the received public key.

   The GC sends the Negotiate_Session_KEK_1 message to the other member
   encrypted in the SKEK that was just generated.  The
   Negotiate_Session_KEK_1 message includes the group ID, group token,
   controller permissions, and CRL version number.

   The other member decrypts the Negotiate_Session_KEK_1 message,
   verifies the authority and identification of the controller, ensures
   the local CRL is up to date, and builds a Negotiate_Session_KEK_2
   message for transmission to the GC.





Harney & Muckenhirn           Experimental                     [Page 16]

RFC 2093                   GKMP Specification                  July 1997


   The GC receives the Negotiate_Session_KEK_2 message and builds a
   Download_Grp_Keys message for transmission to the other member.

   The GC sends the Download_Grp_Keys message to the other member
   encrypted in the SKEK that was just generated.  (note:  the key used
   to encrypt the negotiation messages can be combined differently to
   create the KEK.)

   The other members decrypts the Download_Grp_Keys message and extracts
   the KP, group identification, GC identification, group members, group
   permissions, key rekey interval, and group commanders signature.  The
   group identification, GC identification, and group permissions fields
   are validated based on the signature.  If these fields validate, the
   other members internal key storage tables are updated with the new
   keys.

6.2 Group Rekey

   Rekey is a two-step function that involves message exchange between
   the GC and a "first member" and "other members." Messages between the
   GC and the first member are exactly as described for group creation.
   Messages between the GC and the other members are for the purpose of
   distributing the new GTEK and the new GKEK. These functions are

|___Net_Controller___|__________Messages________|Net_members,individual|
|                    |Create Session KEK_1---->  |                     |
|                    |                           |State 5              |
|                    |<-----Create Session KEK_2 |                     |
|State 5             |                           |                     |
|                    |Negotiate ess. Keys_1----->|                     |
|                    |                           |State 6              |
|                    |<-----NegotiateSess. Keys_2|                     |
|State 7             |                           |                     |
|                    |Download Grp Keys--------> |                     |
|                    |                           |State 8              |
|                    |<----- Key download ack    |                     |
|State 9             |                           |                     |
               Figure 2:  State Diagram:  Distribute Keys

   described in the following sections.

6.2.1 Create Group Keys

   The first member function for a rekey operation is the same as that
   for key initialization.  Please refer to the group creation section
   entitled "2.1 Create group keys".





Harney & Muckenhirn           Experimental                     [Page 17]

RFC 2093                   GKMP Specification                  July 1997


6.2.2 Rekey

   The purpose of rekey is as follows:

   o  send the new GTEK and new GKEK to the other members,

   o  allow each member to verify the identify of the controller,

   o  allow each member to verify the controllers authorization to
      rekey the group, group identification, and GC identification,

   o  send the group identity, GC identity, group member identities,
      group permissions, and group rekey interval to the other members,

   The messages to create and negotiate the group keys are the same as
   stated during group creation.  As such they have been omitted here.

   The rekey portion of this function consists of one message between
   the GC and the other members.  The GC builds a signed Rekey_Multicast
   message for transmission to the other member.  As the name implies
   this

|___Net_Controller___|__________Messages________|Net_members,individual|
|The Create Group    |<---- Command-Create Group |                     |
|command is          |                           |                     |
|received by net     |                           |                     |
|member A.           |                           |                     |
|State 1             |                           |                     |
|                    |Create Grp Keys_1---->     |                     |
|                    |                           |State 2              |
|                    |<-----Create Grp Keys_2    |                     |
|State 2             |                           |                     |
|                    |Negotiate Grp Keys_1------>|                     |
|                    |                           |State 3              |
|                    |<-----Negotiate Grp Keys_2 |                     |
|State 4             |                           |                     |
|                    |Rekey _Multicast------->   |                     |
|                    |                           |State 10             |
                    Figure 3:  State Diagram:  Rekey

   message can be multicast to the entire group.  The GC sends the
   signed Rekey_Multicast message to the other members encrypted in the
   current GKEK.

   The other members decrypt and validate the signed Rekey_Multicast
   message and extract the new KP, group identification, GC
   identification, group members, group permissions, key rekey interval,
   and rekey command signature.  The group identification, GC



Harney & Muckenhirn           Experimental                     [Page 18]

RFC 2093                   GKMP Specification                  July 1997


   identification, and group permissions fields are validated based on
   the extracted rekey command signature.  If these fields validate, the
   key database tables are updated.

6.3 Member Initiated Join

   The GKMP will support member initiated joins to the group.  This type
   of service is most attractive when the group initiator does not need
   to control group membership other than to verify that all members of
   the group conform to some previously agreed upon rules.

   One example of this type of group is corporations job vacancies.  A
   corporation may want to keep its job vacancies confidential and may
   decide to encrypt the announcements.  The group creator doesn't care
   who gets the announcements as long as they are in the corporation.
   When an employee tries to access the information the GC looks at the
   employees permissions (signed by some higher authority).  If they
   indicate the employee is part of the corporation the controller
   allows access to the group.

   Before a potential group member can join group operations, they must
   request the key from the GC, unambiguously identify themselves, pass
   their permissions, and receive the keys.  These require several
   messages to pass between GC and the joining member.  The purpose of
   these messages are as follows:

   o  Request group join from controller

   o  cooperatively generate a SKEK for the transmission of the group
      traffic encryption and GKEK from the GC,

   o  allow each member to verify the identify of the controller and
      visa versa,

   o  allow each member to verify the controllers authorization to
      create the group,

   o  send the KP, group identity, GC identity, group member identities,
      group permissions, and group rekey interval to the other members,

   The series of messages for a member initiated join is very similar to
   the series of messages to distribute group keys during group
   creation.  In fact, the series are identical except for the addition
   of a request to join message sent from the joining member to the
   controller when the join is member initiated.  This message should
   not require encryption since it probably does not contain sensitive
   information.  However, in some military systems the fact that a
   member wants to join a group maybe sensitive from a traffic analysis



Harney & Muckenhirn           Experimental                     [Page 19]

RFC 2093                   GKMP Specification                  July 1997


   viewpoint.  In these specialized instances, a pairwise TEK may be
   created, if one does not already exist, to hide the service request.

   This function consists of seven messages between the GC and the
   joining member.  The first message is created by the joining member
   and sent to the GC. It simply request membership in the group from
   the controller.  The controller makes the decision whether to respond
   to the request based on the group parameters - membership limits,
   membership lists.

   The next messages are for the establishment of a SKEK. This is
   accomplished by the GC sending a signed Create_Session_KEK_1 message
   to the other member.  This message contains the random value
   necessary for the other member to generate the SKEK. This message
   also contains the public key of the GC.

   The other member validates the Create_Session_KEK_1 message, builds
   and sends a Create_Session_KEK_2 message to the GC, generates the
   SKEK, and stores the received public key.  The Create_Session_KEK_2
   message contains the random value necessary for the GC to generate
   the SKEK.  This message also contains the public key of the other
   member.

   The GC validates the Create_Session_KEK_2 message, generates the
   SKEK,

|___Net_Controller___|__________Messages________|Net_Members,individual|
|                    |<------ Request_Group_Join |                     |
|State 11            |                           |                     |
|                    |Create Session KEK_1---->  |                     |
|                    |                           |State 5              |
|                    |<-----Create Session KEK_2 |                     |
|State 5             |                           |                     |
|                    |NegotiateSess. Keys_1----->|                     |
|                    |                           |State 6              |
|                    |<-----NegotiateSess. Keys_2|                     |
|State 7             |                           |                     |
|                    |Download Grp Keys--------> |                     |
|                    |                           |State 8              |
|                    |<----- Key download ack    |                     |
|State 9             |                           |                     |
                 Figure 4:  State Diagram:  Member Join

   builds the Negotiate_Session_ KEK_1 message for transmission to the
   other member, and stores the received public key.

   The GC sends the Negotiate_Session_KEK_1 message to the other member
   encrypted in the SKEK that was just generated.



Harney & Muckenhirn           Experimental                     [Page 20]

RFC 2093                   GKMP Specification                  July 1997


   The other member decrypts the Negotiate_Session_KEK_1 message and
   builds a Negotiate_Session_KEK_2 message for transmission to the GC.

   The GC receives the Negotiate_Session_KEK_2 message and builds a
   Download_Grp_Keys message for transmission to the other member.

   The GC sends theDownload_Grp_Keys message to the other member
   encrypted in the SKEK that was just generated.  (note:  the key used
   to encrypt the negotiation messages can be combined differently to
   create the KEK.)

   The other members decrypts theDownload_Grp_Keys message and extracts
   the KP, group identification, GC identification, group members, group
   permissions, key rekey interval, and group commanders signature.  The
   group identification, GC identification, and group permissions fields
   are validated based on the signature.  If these fields validate, the
   other members internal key storage tables are updated with the new
   keys.

6.4 Member Deletion

   There are two types of member deletion scenarios - cooperative and
   hostile.  The cooperative deletion scenarios is the removal of a
   trusted group member for some management reason (i.e., reduce group
   size, prepare the member for a move).  The hostile deletion usually
   results in

|___Net_Controller___|__________Messages__________|_____Net_Members_____|
|                    |Delete_Group_Keys ------>   |                    |
|                    |                            |State 12            |
|                    |<------ Grp_Keys_Deleted_Ack|                    |
|State 9             |                            |                    |
             Figure 5:  State Diagram:  Cooperative Delete

   a loss of secure state at the members site (i.e., compromise,
   equipment breakage).

   The two scenarios present different challenges to the network.
   Minimization of network impact is paramount in the cooperative
   scenario.  We would like to leave the key group intact and have
   confidence that removing the cooperative group member will have no
   impact on the security of future group operations.  In the case of a
   hostile deletion, the goal is to return to a secure operating state
   as fast as possible.  In fact there is a trade-off.  We could
   eliminate the compromised group as soon as the compromise is
   discovered, but this may cripple an important asset.  So security
   concerns need to be balanced with operational concerns.




Harney & Muckenhirn           Experimental                     [Page 21]

RFC 2093                   GKMP Specification                  July 1997


6.4.1 Cooperative Deletion

   The cooperative deletion function occurs between a trusted member and
   the GC. It results in a reliable deletion of the group key encryption
   and GTEKs at the deleted member.  This deletion is intended to be an
   administrative function.

   This function consists of two messages between the GC and the member.
   The GC sends the Delete_Group_ Keys message to the group, encrypted
   in the GTEK. The message identifies the member(s) that need to delete
   the group keys.  The member(s) decrypt the Delete_Group_Keys message,
   extract the group identification, check the deleted member list,
   deletes the group traffic and key encryption keys for that group, and
   build the Group_Keys_Deleted_Ack message for transmission to the GC.

   The Grp_Keys_Deleted_Ack message is encrypted in the group traffic
   key.  The GC receives the Grp_Keys_Deleted_Ack message, decrypts it,
   and updates the group definition.

|___Net_Controller___|__________Messages____________|_____Net_Members__|
|                    |Delete_Group_Keys ------>     |                  |
|                    |                              |State 13          |
               Figure 6:  State Diagram:  Hostile Delete

6.4.2 Hostile Deletion (Compromise)

   Hostile deletion occurs when a the group losses trust in a member.
   We assume that all keys resident at the members site have been lost.
   We also assume the member will not cooperate.  Therefor, we must
   essentially create another group, minus the untrusted member, and
   transfer group operations to that new group.  When the group losses
   trust in the controller, another controller must be appointed and
   then the hostile deletion process can proceed.

   There are some security and operational management issues surrounding
   compromise recovery.  The essence of the issues involve a tradeoff
   between operational continuity and security vulnerability.  If a
   member is found to be bad, from a security point of view all traffic
   on the network should stop.  However, if that traffic is supporting a
   critical operation, the group may prefer to live with the security
   leak rather than interrupt the group communication.










Harney & Muckenhirn           Experimental                     [Page 22]

RFC 2093                   GKMP Specification                  July 1997


   The GKMP provides two mechanisms to help restrict access of
   compromised members.  First, it implements a Certificate Revocation
   List (CRL) which is checked during the group creation process.  Thus
   it will not allow a compromised member to be included in a new group.
   Second, the GKMP facilitates the creation of another group (minus the
   compromised member(s)).  However, it does not dictate whether or not
   the group may continue to operate with a compromised member.

   The mechanism the GKMP uses to remove a compromised member is to key
   that member out.  This entails creating a new group, without the
   compromised member, and switching group operations.  The old group is
   canceled by several multicasts of a group delete message.

   This function consists of one message from the GC to all members.
   The GC sends the Delete_Group message to all members encrypted in the
   GTEK. This results in the deletion of the group traffic and key
   encryption keys in all group members.  All members decrypt the
   received Delete_Group message, validate the authorization, extracts
   the group identification, and delete the group traffic and key
   encryption keys.


7 Security Conditions

   This document, in entirety, concerns security.

8 Addresses of Authors

   Hugh Harney
   SPARTA, Inc.
   Secure Systems Engineering Division
   9861 Broken Land Parkway, Suite 300
   Columbia, MD 21046-1170
   United States
   Phone:        +1 410 381 9400 (ext.  203)
   EMail:  hh@columbia.sparta.com

   Carl Muckenhirn
   SPARTA, Inc.
   Secure Systems Engineering Division
   9861 Broken Land Parkway, Suite 300
   Columbia, MD 21046-1170
   United States
   Phone:        +1 410 381 9400 (ext.  208)
   EMail:  cfm@columbia.sparta.com






Harney & Muckenhirn           Experimental                     [Page 23]