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]
|