idnits 2.17.1 draft-harney-gkmp-arch-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 13) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'STEK' on line 208 looks like a reference -- Missing reference section? 'SKEK' on line 208 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Hugh Harney, Carl Muckenhirn 3 INTERNET DRAFT SPARTA, Inc. 4 6/18/96 Secure Systems Engineering Division 5 Expires in six months 7 Group Key Management Protocol (GKMP) Architecture 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as 21 ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the Internet- 25 Drafts Shadow Directories on ftp.is.co.za (Africa), 26 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 27 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 29 Table of Contents 31 Abstract 1 32 1. Introduction 2 33 2. Multicast Key Management Architectures 4 34 3. GKMP Protocol Overview 11 35 4. Issues 21 36 Author's Address 23 38 Abstract 40 This specification proposes a protocol to create grouped 41 symmetric keys and distribute them amongst communicating 42 peers. This protocol has the following advantages: 1) vir- 43 tually invisible to operator, 2) no central key distribution 44 site is needed, 3) only group members have the key, 4) 45 sender or receiver oriented operation, 5) can make use of 46 multicast communications protocols. 48 1 Introduction 50 This document describes an architecture for the management of 51 cryptographic keys for multicast communications. We identify the roles 52 and responsibilities of communications system elements in accomplishing 53 multicast key management, define security and functional requirements of 54 each, and provide a detailed introduction to the Group Key Management 55 Protocol (GKMP) which provides the ability to create and distribute 56 keys within arbitrary-sized groups without the intervention of a 57 global/centralized key manager. The GKMP combines techniques developed 58 for creation of pairwise keys with techniques used to distribute keys 59 from a KDC (i.e., symmetric encryption of keys) to distribute symmetric 60 key to a group of hosts. 62 1.1 Multicast Communications Environments 64 The work leading to this report was primarily concerned with military 65 command and control and weapons control systems, these systems tend 66 to have top--down, commander--commanded, communications flows. The 67 choice of what parties will be members of a particular communication 68 (a multicast group for example) is at the discretion of the ``higher'' 69 level party(ies). This ``sender-initiated'' (assuming the higher-level 70 party is sending) model maps well to broadcast (as in electromagnetic, 71 free-space, transmission) and circuit switched communications media 72 (e.g., video teleconferencing, ATM multicast). 74 In looking to apply this technology to the Internet, a somewhat 75 different model appears to be at work (at least for some portion of 76 Internet multicast traffic). IDRP and Distance Vector Multicast 77 Routing Protocol (DVMRP) use multicast as a mechanism for parties 78 to relay common information to their peers. Each party both sends 79 and receives information in the multicast channel. As appropriate, 80 a party may choose to leave or join the communication without the 81 express permission of any of the other parties (this begs the question 82 of meta-authorizations which allow the parties to cooperate). More 83 interestingly, the multicast IP model has the receiver telling the 84 network to add it to the distribution for a particular multicast 85 address, whether it exists yet or not, and the transmitter not being 86 consulted as to the addition of the receiver. 88 Other applications of multicast communications in the Internet, for 89 example NASA Select broadcasts, can be viewed as implementing the sender 90 model since the sender selects the broadcast time, channel, and content, 91 though not the destinations. 93 It is our intention to provide key management services which support 94 both communications (and implied access control) models and operate in 95 either a circuit switched or packet switched environment. 97 1.2 Security for Multicast 99 Multicast communications, as with unicast, may require any of 100 the security services defined in ISO 7498, access control, data 101 confidentiality, traffic confidentiality, integrity/data authentication, 102 source authentication, sender and receiver non-repudiation and service 103 assurance. From the perspective of key management processes, only 104 data confidentiality, data authentication, and source authentication 105 can be supported. The other services, traffic confidentiality, 106 non-repudiation, and service assurance must be provided by the 107 communications protocol, they may rely on cryptographic services but are 108 not guaranteed by them. 110 2 Multicast Key Management Architectures 112 2.1 Current Operations 114 There are several electronic mechanisms for generating and distributing 115 symmetric keys to several computers (i.e., communications groups). 116 These techniques, generally, rely on a key distribution center (KDC) to 117 act as a go between in setting up the symmetric key groups. Military 118 systems, such as BLACKER, STU-II/BELLFIELD, and EKMS, and commercial 119 systems, such as X9.17 and Kerberos, all operate using dedicated 120 KDCs. A group key request is sent to the KDC via various means (on- 121 or off-line) The KDC acting as an access controller decides whether 122 or not the request is proper (i.e., all members of a group are cleared 123 to receive all the data on a group). The KDC would then call up each 124 individual member of the group and down load the symmetric key. When 125 each member had the key the KDC would notify the requester. Then secure 126 group communication could begin. While this was certainly faster then 127 anything that requires human intervention. It still requires quite a 128 bit of set-up time. Also, a third party, whose primary interest isn't 129 the communication, needs to get involved. 131 Pairwise keys can be created autonomously by the host on a network by 132 using any number of key generation protocols (FireFly, Diffe-Hellman, 133 RSA). These protocols all rely on cooperative key generation algorithms 134 to create a cryptographic key. These algorithms rely on random 135 information generated by each host. These algorithms also rely on peer 136 review of permissions to ensure that the communication partners are who 137 they claim to be and have authorization to receive the information being 138 transmitted. This peer review process relies on a trusted authority 139 assigning permissions to each host in the network that wants the ability 140 to create these keys. The real beauty of these pairwise key management 141 protocols is that they can be integrated into the communication 142 protocol or the application. This means that the key management becomes 143 relatively invisible to the people in the system. 145 2.2 GKMP-Based Operations 147 The GKMP described below, delegates the access control, key generation, 148 and distribution functions to the communicating entities themselves 149 rather than relying on a third party (KDC) for these functions. As 150 prelude to actually distributing key, a few things must be assumed 151 (for purposes of this document): there exists a ``security manager'' 152 responsible for creating and distributing to parties authentic 153 identification and security permission information(1); communicating 154 parties are online for the keys formed and distributed by the GKMP 156 2.2.1 Sender Initiated Operations 158 This section describes the basic operational concept for multicast 159 key management for sender initiated multicast support. This model 160 of multicast communications was the basis for our original work on 161 multicast key management. From a security viewpoint the sending 162 application is able to control access to the transmission through 163 both key distribution and communications distribution (not sending the 164 transmission to some addresses). 166 Identification of Group Key Controller -- The originator of the 167 multicast group creates or obtains a group management certificate from 168 its certification hierarchy. The certificate identifies the holder as 169 responsible for generation and distribution of the group key(2). The 170 originator relays the membership list to the Group Key Management (GKM) 171 application. 173 Group Key Creation -- The GKM application, operating on behalf of the 174 originator, selects one member of the group, contacts it, and creates 175 a Group Key Packet (GKP). A GKP contains the current group traffic 176 ---------------------------- 177 1. The security manager function may be accomplished through a strictly 178 hierarchical system (a la STU-III) or a more ad hoc system of 179 cooperating peer ``domain managers,'' the implementation of the 180 certification hierarchy is not addressed in this document. 182 2. Naming standards are not addressed here, the name should reflect the 183 naming structures appropriate for the supported cryptographic service. 184 For example, IP-level encryptors should use 185 naming reflecting ``host'' identities (IP addresses, or DNS host names), 186 RTP encryptor would use session names. 188 encrypting key (GTEK) and future group key encrypting key (GKEK). The 189 GKM application then identifies itself as the group key controller, 190 which the member validates, under cover of the GTEK. 192 Group Key Packet (GKP) = [GTEKn,GKEKn+1] 194 As part of group key packet formation, usage parameters, appropriate 195 for the underlying crypto-system, are selected. Unlike normal parameter 196 negotiation, where common security-level/range, and services are arrived 197 at, the originator's GKM application selects these parameters and the 198 member must comply. 200 Group Key Distribution -- After creation of the GKP, the group 201 controller contacts each member of the group, creates a Session Key 202 Package (SKP), validates their permissions (check member's certificate 203 against group parameters), and create a Group Rekey Package for that 204 member. A SKP contains a session TEK and a session KEK for a particular 205 member. A GRP contains the GKP encrypted in a KEK and signed using the 206 originator's certificate. 208 Session Key Package (SKP) = [STEK, SKEK] 210 Group Rekey Package (GRP) = {[GKP]KEK} SignatureController 212 Group Rekey -- When the group needs to be rekeyed, the originating 213 GKM application selects a member, creates a new GKP, creates a new 214 GRP (which is encrypted in the previously distributed next GKEK) and 215 broadcasts it to the group. 217 This procedure is fairly complex, but other than for the distribution of 218 site-specific certificates, no centralized key management resources are 219 needed. The only parties to the key management communications are the 220 same parties which will be participating in the group. 222 2.2.2 Receiver Initiated Operations 224 This section describes key management operational concept for receiver 225 initiated multicast communication support. The receiver initiated 226 model presents some interesting problems from a security view point 227 since the end-participants are not known a priori. Also, in a purely 228 receiver initiated application (such as DVMRP), there is no concept of 229 an ``originator'' and the participants in the group may be quite dynamic 230 with participants changing on a minute by minute basis. 232 For secure group communications to take place, all members must obtain 233 the same key. This may be achieved by either using deterministic key 234 generation techniques (using a secret, shared seed) or by making one 235 member of the group responsible for creation of the key. The use of 236 a deterministic key generator presents security problems, particularly 237 regarding loss of the seed (it compromises both past and future 238 traffic). The assignment of a member to the role of key ``controller'' 239 also presents drawbacks, but these relate to determining which one 240 should be the controller and the need for each member to contact him. 241 The remainder of this discussion will look at how the ``controller'' 242 concept from above could work in the receiver initiated case. 244 Selection of Group Key Controller -- A group member will be made 245 responsible for initial group establishment and periodic generation 246 and dissemination of new GRPs. There is no need for the selected 247 controller to be the controller for all time, but at any one time only 248 one controller may be active for each group. Selection of controller 249 may be made through a voting system, by a simple default (the first to 250 transmit to the group is the controller), or configuration. 252 The current controller's identity must be made available to all members, 253 and potential members, for initial group key load and error recovery. 254 The information may be relayed by broacast on a key management 255 ``channel,'' or through a directory service. 257 Group Key Creation -- The GKP is created and distributed in much the 258 same way as in sender initiated operations. The controller creates 259 a GKP with the first group member to initiate contact. The GKM 260 application then identifies itself as the group key controller, which 261 the member validates, under cover of the GTEK. Parameter negotiation is 262 performed and the first group member is keyed. 264 Group Key Distribution -- After creation of the GKP, as other members 265 contact the controller, a SKP is created, member permissions are 266 validated and a GRP is loaded to the member. 268 For widely distributed groups, a form of distributed dissemination may 269 be used. Some number of regional GKM applications are enabled with the 270 ability to validate the permissions of new members and upon validation 271 send to them the current GKP.(3) These regional key distributors perform 272 the same functions as the controller, except that they do not create the 273 GKP. This concept can be expanded to the point where all current members 274 are capable of downloading the GKP, and passing on that capability. 276 ---------------------------- 277 3. Access control is not defined in this document, but it is assumed 278 that both hierarchical and discretionaly (rule-based and identity-based) 279 access control will be supported. 281 Group Rekey -- When the group need rekeying the procedure would be 282 identical to the sender initiated case. The controlling GKM application 283 selects a member, creates a new GKP, creates a new GRP (which is 284 encrypted in the previously distributed next GKEK) and broadcasts it to 285 the group. 287 2.3 GKMP Features 289 This section highlights areas which we believe the GKMP approach has 290 advantages over the ``traditional'' KDC based approaches. 292 2.3.1 Multicast 294 Multicast protocols are a growing area of interest for the Internet. 295 The largest benefit of a multicast protocol is the ability of several 296 receivers to simultaneously get the same transmission. If the 297 transmission is of a sensitive nature, it should be encrypted. This 298 means that the all members of the group must share the same encryption 299 key to take benefit of the multicast transmission. 301 To date the only way of setting up a group of symmetric keys is with 302 the assistance of a centralized key management facility. This facility 303 would act as a key broker creating a distributing key to qualified group 304 members. There are several problems with this centralized concept. 305 These problems give rise to many of the following motivations for 306 creating a distributed key management protocol. 308 2.3.2 Increase the autonomy of key groups 310 The GKMP proposes to extend the pairwise key paradigm to grouped keys. 311 This protocol can be integrated into the communication protocols or 312 applications and can become invisible to the host's operator. We will 313 use peer review to enforce our security policy. 315 The GKMP allows any host on a network to create and manage a secure 316 group. Maintenance of these group keys can be performed by the hosts 317 interested in the group. The groups themselves will be relatively 318 autonomous. This simplifies the installation of this technology 319 allowing more host to use secure multicast communications. 321 2.3.3 Latency 323 Latency refers to the time to set-up or tear down or to re-key a group. 324 In short this corresponds to the length of time it would take to set-up 325 a multicast address. 327 The GKMP can allow delegation of group creation authority to any host 328 in the network. In essence, when a host needs a group it will have the 329 tools needed to create that group and manage it. Additionally, since 330 the host only needs to create a single group it can concentrate on that 331 particular group. 333 In the current centralized key distribution approach. The group must 334 be requested from the central site. The central site would process 335 that request in accordance with it's priority and current workload. 336 Latencies would develop if the workload of the central site gets 337 unwieldy or if the communications to the site become overloaded. 339 2.3.4 Extendibility 341 One of the problems with a centralized key distribution system is the 342 concentration of key management workload at a single site. The process 343 of creating key groups -- key creation, access review, communication to 344 group members takes time and effort. As the number of groups on the 345 network grows and the number of group members group. The workload at 346 that central sight quickly reaches capacity. 348 GKMP should allow a great number of groups to exist on the Internet 349 without overloading any particular host. Delegation of the net wide 350 group creation and management workload places the burden of maintaining 351 groups on the hosts interested in using those groups. Not only is this 352 more efficient, but it places the burden in an appropriate location. 354 The GKMP distributes the communication requirements to manage groups 355 across the network. Each group manages the group using the same 356 communication resources needed to pass traffic. It is likely that if a 357 communication group can support the traffic of a group, it will be able 358 to support the minimal traffic needed to management the keys for that 359 group. 361 GKMP provides it's own access control, based on signed netwide 362 permission certificates. This partially disseminates the burden of 363 access control and permission management. A system wide authority 364 must assign the permission certificates, but day to day access control 365 decisions are a GKMP responsibility. 367 2.3.5 Operating expense 369 A centralized key distribution site contains, at one time or another, 370 the keys for the net. This is a valuable target for someone to 371 compromise. To protect this site physical and procedural security 372 mechanisms are employed (e.g., guards, fences, intrusion alarms, two 373 person safes, no-alone zones). These mechanisms do not come cheap. 375 Allowing the hosts to create and manage their keys eliminates the need 376 for an on-line centralized key distribution site. The protocol approach 377 restricts access to the keys to the hosts using them (the minimal set). 378 Since, the encryption mechanisms will have already incurred the cost to 379 be physically secured there is no additional cost levied on the system 380 by the key management system. 382 2.3.6 Communication Resources 384 Because a centralized site is involved in creating, distributing, 385 rekeying, and providing access control for every group, it is frequently 386 accessed. The communication resources available to this site often 387 become a bottle neck for the groups. Therefore a big pipe is usually 388 installed to this facility. 390 The GKMP proposes delegating most of the key creation, distribution, 391 rekey and access control mission to the hosts that need the secure 392 communication. There no longer is a single third party that must be 393 consulted prior to every group key management action. Hence, the 394 communications requirements to manage the keys have shifted to the 395 groups themselves. The need for special high capacity communications 396 has been eliminated. 398 2.3.7 Reliability 400 Delegating key management responsibility to the groups eliminates 401 the centralized key management site as a single point of failure. 402 The groups that will use the key are responsible for it. If the 403 communications system fails for the key management it is also down for 404 the communications. 406 The GKMP will attempt to delegate as many functions to the group as 407 possible. There will be some functions which still need to be performed 408 outside of the group (granting of privileges). These functions can 409 still fail. The GKMP will operate on the old set of permissions. These 410 functions need not be in-line. They are performed separate from the key 411 management actions and are not crucial to day-to-day operation. 413 2.3.8 Security 415 People are the most risky element for security. A distributed protocol 416 eliminates many people from the key distribution chain. This limits 417 ``exposure'' of the key. 419 3 GKMP Protocol Overview 421 3.1 Supporting functions 423 A secure key management protocol needs a number of supporting functions, 424 especially in a military environment. The two major support functions 425 are security management and network group management. In the commercial 426 world a company could provide these support functions. 428 The issue of Security Management is permission management, in a military 429 environment separation of data occurs along classical classification 430 lines (i.e., TOP SECRET to UNCLASSIFIED). In the commercial world these 431 levels are proprietary or need to know access. 433 Network group management provides an interface to the communications 434 system and control of network resources. Some entity either a 435 commercial or military system, the host or network operations center, 436 must provide the key management protocol with a list of the group 437 members. Also, if the network resources, bandwidth and processing, are 438 considered scarce a management structure must allocate them. 440 3.1.1 Security management 442 Security management is a role performed for the entire network. It 443 involves netwide issues of permission management, initialization 444 of software, and compromise recovery. The GKMP relies on security 445 management to operate. Refer to figure 1: Security management view. 447 The GKMP must assume trusted handling of the protocol software prior 448 and during installation. If the GKMP is to use peer to peer access 449 control the system must control the assignment of permissions. These 450 permissions must be monitored and updated as needed. Finally, overview 451 of these permissions must include the maintenance of a Certificate 452 Revocation List. 454 Secure start-up We need to control the process of loading GKMP software 455 onto a host and initializing it. The protocol needs keys, public and 456 Figure 1: Security Management View 458 private, to operate. It also must have identify information of the host 459 on whose behalf it will act. 461 There are some life cycle and security concerns with the software while 462 in transit, stored, distributed, and installed. A one time start-up 463 procedure must verify the identity of the host. Procedural and physical 464 identification techniques will verify the identity of the host (i.e., 465 the Armed Forces Courier Service (ARFCS) accounting, or registered 466 mail). Upon key delivery the security manager logs it's receipt and 467 assumes responsibility for the key. 469 After proper installation of the software a paper trail verifies the 470 recipient. The computer would initiate an association with the security 471 management function to initialize the protocol software (create a unique 472 public and private key pair for network operation and receive network 473 permissions). This activation process uses keys distributed with the 474 software (good only for initialization) to secure an exchange with the 475 security manager. The host then creates a unique public and private 476 pair and sends the public key to the security manager. The security 477 manager creates a credential that uniquely identifies the host and it 478 permissions. This credential is signed by the security management with 479 its private key and can be verified by all net members with the public 480 key. 482 Permission management Each host on the network is given a permissions 483 certificate signed by the security management which uniquely identify 484 that host and identifies the access permissions it is allowed. These 485 permission certificates are used by the network hosts to assign 486 permissions to other hosts. 488 This process assigns permissions to equipment or human beings in 489 accordance with their duties. This process involves security clearances 490 and human judgment therefore it is outside the scope of this protocol. 492 The security management function, especially in military operations, 493 would be responsible for managing permissions and classifications at 494 each host. In the commercial world, permission management corresponds 495 to projects or duties. 497 Compromise recovery management If a group member is found compromised, 498 the protocol must facilitate the exclusion of the compromised member 499 and return to secure operations. The security management function will 500 provide control of compromise recovery. 502 Usually, physical inspections or accounting techniques find compromises. 503 These separate systems report the compromise to the key management 504 system. We must assume the loss of all key resident at that host. The 505 security management function will rescind the permission allocated 506 to this compromised host. We create a list of all know compromised 507 hosts and distribution that list across the network. Each host is 508 then responsible for reviewing the propriety of each association and 509 enforcing access control to data. 511 3.1.2 Group management 513 The group manager interacts with other management functions in the 514 network to provide the GKMP with group membership lists and group 515 relevant commands. The GKMP deals strictly with cryptographic key. 516 It relies on external communication and network management services to 517 supply network related information. Primarily, it relies on the network 518 management service to provide it with the addresses of group members (if 519 the group is sender initiated). 521 The GKMP allows an external entity to determine the controller of 522 a group. The controller of the group should be able to handle the 523 additional processing and communication requirements associated with 524 the role. If this is not a necessary function given the implementation, 525 this assignment of controller duties can be set to some automated 526 default. However, even if defaulted some external management entity 527 determines how the role of controller is allocated. 529 The group manager can receive group progress reports from the group 530 controller. The GKMP provides a service for the network. It makes 531 sense that someone in the network is interested in the progress of 532 this service. The GKMP can provide progress reports. It is up to the 533 network management to determine the manner and recipient of the reports. 534 Reference figure 2: Network manager interaction. 536 Figure 2: Network Manager Interaction 538 Group to member mapping When the GKMP is implemented in sender 539 initiated group establishment mode, a list of group member addresses 540 must be provided as part of the group establishment command. The GKMP 541 will use these addresses to contact the group members and create the 542 group. 544 The creation of groups involves the assignment of a group address, 545 update of router databases, and distribution of this group address to 546 the group members. This is a classic function of network management. 547 The GKMP group controller would be another recipient of this 548 information. 550 Protocol role allocation The Group Management Protocol assigns roles 551 to members of a particular group. These roles are binary one is either 552 the control over the group or a member of a group. Some external entity 553 will allocate the identity of the group controller and group receiver. 554 This is a desirable aspect because some computers are more capable 555 (i.e., central site, great deal of process power available to control 556 a group). We allow some external entity to allocate these roles to 557 individual group members, this is important in the military application 558 do to the fact that in a commercial application the allocating authority 559 and group controller may very well always be the same. 561 Group key progress reporting The Group Key Management Protocol has 562 to be able to report to somebody. If we create a group, we should 563 report it to group requester. Contrarily if we are not able to create 564 Figure 3: Distributed Group Management 566 a group we should report that especially since failure to create a 567 group at least as a first study will highly correlate with a failure 568 of the underlying communications. The Group Key Management Protocol 569 does not have an ability to fix the underlying communications so the 570 communication management function must deal with these failures. 572 3.2 Protocol Roles 574 Creation and distribution of grouped key require assignment of roles. 575 These identify what functions the individual hosts perform in the 576 protocol. The two primary roles are those of controller and receiver. 577 The controller initiates the creation of the key, forms the key 578 distribution messages, and collects acknowledgment of key receipt from 579 the receivers. The receivers wait for a distribution message, decrypt, 580 validate, and acknowledge the receipt of new key. 582 One of the essential concepts behind the GKMP is delegation of group 583 control. Since each host in the network has the capability to act 584 as a group controller, the processing and communication requirements 585 of controlling the groups in the network can be distributed equitably 586 throughout the network. This avoids potential single points of failure, 587 communication congestion, and processor overloading. Refer to figure 3: 588 Distributed group management. 590 3.2.1 Group controller 592 The group controller is the a group member with authority to perform 593 critical protocol actions (i.e., create key, distribute key, create 594 group rekey messages, and report on the progress of these actions). All 595 group members have the capability to be a group controller and could 596 assume this duty upon assignment. 598 The group controller helps the cryptographic group reach and maintain 599 key synchronization. A group must operate on the same symmetric 600 cryptographic key. If part of the group loses or inappropriately 601 changes it's key, it will not be able to send or receive data to another 602 host operating on the correct key. Therefor, it is important that those 603 operations that create or change key are unambiguous and controlled 604 (i.e., it would not be appropriate for multiple hosts to try to rekey 605 a net simultaneously). 607 3.2.2 Group receiver 609 Simply stated a group receiver is any group member who is not acting 610 as the controller. The group receivers will: assist the controller in 611 creating key, validate the controller authorization to perform actions, 612 accept key from the controller, request key from the controller, 613 maintain local CRL lists, perform peer review of key management actions, 614 and manage local key. 616 3.3 Scenarios 618 3.3.1 Group establishment 620 The protocol to establish a group of host that share a cryptographic 621 key must create a high quality key, verify that all intended recipients 622 have permission to join the group, distribute the key to all qualified 623 members, and report on the progress. This process consists of two 624 phases: creation of the key and distribution of the key. Refer to 625 figure 4: Group Establishment. 627 The group establishment process is proceeds in the following manner. 628 First, a ``create group'' command is issued to the group commander. 629 The group controller validates the command to ensure it came from an 630 authorized commander and the group is within the controller's permission 631 range. Next, the controller creates a key. Then that key is passed to 632 the group members, after they pass the peer to peer review process. 634 Figure 4: Group Establishment 636 Validate command The create group command is signed by the group 637 commander ( they may be the same device). This signature should be 638 asymmetric in nature. The public key to validate this command can be 639 sent with the command itself, if the public bound to the identity of the 640 commander. 642 The group controller receives the command. It verifies that the 643 signature, thereby ensuring the message was sent by the claimed source 644 and the message has not been modified in transit. 646 Creation of group keys The controller initiates the creation of two 647 keys for use in the group. The creation of a cryptographic key requires 648 that the key be sufficiently random. Randomizers, capable of creating 649 high grade cryptographic key, tend to be hardware based and are not 650 likely to be practical for this protocol. There are several established 651 key creation protocols based in software (e.g., Diffe-Hellman, FireFly, 652 RSA). All these software based algorithms involve two hosts cooperating 653 to create a cryptographic key. These software algorithms are more 654 appropriate for this protocol. 656 Also important, in the creation of these keys, is verification of the 657 authorization of the key creation partner. Authorization to posses 658 the keys include permissions that equal or exceed the group traffic and 659 identity verification. 661 Distribution of group keys The controller distributes the group 662 keys to the net members. The controller must verify the identity 663 and permissions of each member prior to the key being distributed. 665 Figure 5: Group Rekey 667 Likewise, the net member must verify the controller's identity, 668 authorization to perform this action, and permissions. 670 The key being distributed is the same level as the data that it will 671 encrypt. Hence, we must encrypt the key during distribution. If no 672 suitable key exists between the controller and member, a new key must be 673 created. This new key is cooperatively created between the controller 674 and net member in a similar manner as the net keys. 676 The controller creates a message for encryption in the key held between 677 the controller and member. This message will include key management 678 information and the keys. 680 3.3.2 Group rekey 682 Cryptographic key has a life span. New key must replace ``old'' key 683 prior to the end of its cryptographic life. This process is rekey. 685 Rekey has the advantage of using an existing cryptographic association 686 to distribute key. Also, there is no requirement to verify the identity 687 and authorization for the other members. Identify and authorization are 688 assumed. 690 A group rekey consists of two stages. First the Group Controller 691 creates new group keys. Second these ``new'' keys are sent to the Group 692 Members in a multicast message. Refer to figure 5: Group Rekey. 694 Creation of group keys The controller of the rekey will create the new 695 keys in exactly the same manner as used during group establishment. 697 Distribution of group keys The GKMP creates a message for the group 698 address. This message uses one of the keys distributed during 699 group establishment to encrypt the new keys. It also contains an 700 authorization token identifying the controller as the rekey agent 701 and new management data. All members of the group using a multicast 702 protocol (if one exists) accept this message. 704 The message which rekeys the group encrypts the new keys in the existing 705 KEK. Since all group members possess the KEK the entire group can 706 decrypt this message. 708 The token authorizing the group controller to perform this rekey is also 709 included. This token is asymmetrically signed by the group commander. 710 It uniquely identifies the group controller's authority to rekey this 711 group. It also identifies the group the level of traffic and rekey 712 interval. 714 3.3.3 Deletion 716 It is desirable to be able to delete group members for either 717 administrative purposes or security reasons. Administrative deletion is 718 the deletion of a trusted group member. It is possible to confirm the 719 deletion of trusted group members. Security relevant deletion is the 720 deletion of an untrusted member. It assumes that the member is ignore 721 all deletion commands. 723 Administrative delete Administrative deletion removes the group keys 724 from trusted group members. This deletion consists of two messages 725 the first sends a command to the group encrypted in the groups TEK. 726 The command essentially says: acknowledge receipt and then delete 727 group keys. This command is signed by the group controller to prevent 728 unauthorized deletions. 730 The acknowledgment message is also encrypted under the group TEK and 731 is sent to acknowledge receipt of the command. We could acknowledge 732 accomplishment of the command if the net is willing to accept the burden 733 of creating pairwise keys between the exiting group members and the 734 group controller. 736 Compromise recovery Compromise recovery is the deletion of untrusted 737 group members. This actually involves the creation of an entirely new 738 group, without the untrusted member. Once the new group is created, 739 net operations can be shifted to the new group, effectively denying the 740 untrusted member access to the data. 742 There is always a trade-off between security and continued net 743 operations when a member is found to be compromised. The security 744 first position states that if a member is compromised, the group must 745 be destroyed and then a new secure group created. However, operational 746 concerns sometimes out weigh the security concerns. The operational 747 position is that the group will continue to operate with the compromised 748 member and will shift to a new secure group when it becomes available. 750 The GKMP does not mandate either position. However, the speed 751 and flexibility of the GKMP does allow a new secure group to be 752 created quickly. Thereby, restricting the potential damage done by a 753 compromised member. 755 Once a member is found to be compromised, that members certificate 756 is added to a Certificate Revocation List (CRL). The CRL is an 757 asymmetrically signed piece of data, signed by a security manager. The 758 list is made up of compromised resource ID's, a version of the CRL, and 759 perhaps an identifier of the security manager. The CRL is accessed 760 every time a new key is negotiated. If one of the key creators is on 761 the CRL the key is destroyed and interaction terminated. 763 The idea behind a CRL is each host would keep records of all open 764 associations and compromised resources. The host would then make 765 sure that it does not have and will not create a secure association 766 open with anyone who is on the CRL. The CRL concept of becomes more 767 complicated in the case of groups. This is because it is not necessary 768 for every member in the group to know who the other group members are. 769 Hence, a group member does not have sufficient information to identify 770 compromised group associations. The GKMP proposes that the group 771 controllers be responsible for reviewing the CRL and taking appropriate 772 actions should a group member be compromised. 774 Another issue with CRLs is the speed that they can be distributed across 775 a network. Every time a key is created the cooperating hosts exchange 776 the version number of their current CRL. If the versions do not match. 777 The most current version is passed to the host with the old version. 778 Hence, CRLs propagate when keys are created. If this is infrequently 779 and there is a single CRL insertion point, the list may take a few days 780 to move across the net. The GKMP allows a speedier distribution of the 781 CRL. 783 The GKMP delegates control of groups to specific group controllers 784 (a subset of the network). These controllers are responsible for 785 maintaining the security of the group. If quicker distribution of 786 the CRL were desired, the CRL generator ( security management function 787 could seed the CRL at these controllers. Controllers are points of key 788 management activity and are logical CRL staging areas. 790 4 Issues 792 What are the unresolved issues with this protocol? 794 4.1 Access Control 796 One interesting issue with a grouped key protocol is access control. 797 This is because we are moving away from having humans in the loop or 798 having a central authority to check the propriety of the group. 800 The group protocol must police itself. It must ensure that each member 801 of a group meets the classic military access control policy ( i.e., 802 a group member `s classification level must be higher or equal to the 803 classification of the group that it's in). 805 Is allocation of permissions by a higher authority sufficient to provide 806 access control? Or is a more discretionary mechanism necessary? 808 4.2 MLS 810 A GKMP must be capable of operating in a multi-level secure environment. 811 The integration of a key management protocol capable of creating keys 812 of several different classifications with an operating system capable of 813 operating with multiple classifications in non -trivial. 815 Classified label standards needed to be incorporated. The 816 classification labels used by the key management protocol should 817 coincide with the labels used by the MLS operating system. These 818 interoperability issues need to be addressed. 820 4.3 Error Conditions 822 A group protocol is more complex than a pairwise protocol hence there 823 are more possible error conditions. In a pairwise protocol you have 824 two parties; they must communicate between themselves. It is relatively 825 simple to define an take care of all the potential error conditions. 827 One assumption with any group protocol is the underlying internet is, 828 to some degree, always broken. The protocol designer has to assume that 829 messages will be delayed or destroyed in transit, all member will not 830 receive all multicast messages, and acknowledgment of actions may not 831 be delivered. This assumption is important if a protocol uses multicast 832 functions to speed-up actions. 834 The protocol must provide recovery mechanisms to allow group members 835 to recover from loss of messages. It must recover in a way that is 836 transparent to the host and underlying communications network. 838 For example, there is an issue whether or not we can create an 839 application layer acknowledgment of multi-cast actions. The issue deals 840 with the required bandwidth that acknowledgment would take up. It may 841 be much more friendly to the underlying communications systems to have 842 each member identify potential errors and correct them in a pairwise 843 manner. The task of handling error conditions in a key management 844 protocol is double difficult because many error conditions can be 845 induced error condition (invoked by a third party trying to break the 846 security of that system) to retrieve there key that is in transit or to 847 block the successful dissemination of a key thereby attacking the system 848 security mechanism. 850 4.4 Commercial vs. Military 852 Commercial and military key management differ in many ways. Commercial 853 Key management protocols tend to emphasize inter-operability, freedom 854 of action, and performance. Military systems tend to emphasize security 855 and control of operations. 857 There will be a difference in cryptographic algorithms. The military 858 protocol would certainly use high grade encryption because of protecting 859 classified information. The commercial system would probably using 860 algorithms. and techniques certified for unclassified communication 861 systems. The main difference is in the algorithms length and type. 863 A military protocol would require more management and structure than 864 a commercial one. The military has always adopted a hierarchical 865 communication structure and the commercial system, especially if you 866 look at the internet, work mainly by anarchist style. 868 4.4.1 Algorithm Type 870 Another difference between military and commercial key management 871 is the type of cryptographic algorithms. The commercial world uses 872 encryption algorithms like DES and in the future Skipjack. The military 873 uses other cryptographic algorithms that differ in key length and have 874 more restrictions. An example of this would be the identification of 875 ACCORDION, as a military key encryption algorithm as used in the EKMS 876 program run by NSA. 878 Any experiments with a grouped key management protocol must consider the 879 differences between military and commercial algorithms. The commercial 880 algorithms tend to be quicker to implement, run faster, involve less 881 processing time, and allows an unclassified experiment. However, we 882 must be careful not paint an unrealistic picture of the performance of 883 the protocol based on these commercial algorithms. A military algorithm 884 tends to be more cumbersome to process, slow to process, require more 885 bandwidth, a lot of unpleasant characteristics from the commercial 886 stand point, but allow for a higher grade of cryptographic security. 887 One way of dealing with the disparity between algorithms is to use 888 the commercial cryptographic algorithms and leave the fields the size 889 used by a comparative DOD cryptographic algorithms and insert delays to 890 simulate DOD algorithm processing times. 892 4.4.2 Management Philosophy 894 Management for a military network is far more structured than a 895 commercial network. A military network would restrict the creation of 896 network groups, the rekeying of those groups, and access to the data 897 contained in those groups. In contrast the commercial world would 898 enable any member in the network to create a group and allow any other 899 member of the net to join that group. 901 The group Key Management Protocol must allow for both these 902 architectures i.e., all for very structure command control hierarchy and 903 another free form group creation. 905 4.5 Receiver Initiated Operations 907 How do they actually work, what are the performance trades, 908 experimentation needed. 910 Who is the group leader? 912 How do we elect a new leader? 914 Will multiple leaders be created? 916 Will rule based access control allow fine enough access disgression? 918 Methods for distributed GKP/GRP dissemination need to be examined. This 919 includes: 921 o resolving group identification issues, such as how to notify 922 potential members of membership requirements without compromising 923 any security-relevant information about the group; 925 o approaches for rapidly identifying GKP/GRP sources must be 926 developed, such as a ``Key ARP'' whereby a new member broadcasts 927 into the group a request for key service and existing members 928 resolve which will provide service; and, 930 o Security effects of distributing access control decisions must also 931 be reviewed. 933 5 Addresses of Authors 935 Hugh Harney 936 SPARTA, Inc. 937 Secure Systems Engineering Division 938 9861 Broken Land Parkway, Suite 300 939 Columbia, MD 21046-1170 940 United States 941 telephone: +1 410 381 9400 (ext. 203) 942 electronic mail: hh@columbia.sparta.com 944 Carl Muckenhirn 945 SPARTA, Inc. 946 Secure Systems Engineering Division 947 9861 Broken Land Parkway, Suite 300 948 Columbia, MD 21046-1170 949 United States 950 telephone: +1 410 381 9400 (ext. 208) 951 electronic mail: cfm@columbia.sparta.com