idnits 2.17.00 (12 Aug 2021) /tmp/idnits13227/draft-irtf-smug-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 15 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 36 has weird spacing: '...amework and p...' == Line 107 has weird spacing: '...rypting and a...' -- 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.) -- The document date (March 2001) is 7730 days in the past. Is this intentional? 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: 'TLS' is mentioned on line 110, but not defined == Missing Reference: 'Har' is mentioned on line 160, but not defined == Unused Reference: 'HCD' is defined on line 858, but no explicit reference was found in the text == Unused Reference: 'Har1' is defined on line 863, but no explicit reference was found in the text == Unused Reference: 'Har2' is defined on line 866, but no explicit reference was found in the text == Unused Reference: 'IKEdraft' is defined on line 873, but no explicit reference was found in the text == Unused Reference: 'RFC2014' is defined on line 888, but no explicit reference was found in the text == Unused Reference: 'RFC2407' is defined on line 914, but no explicit reference was found in the text == Unused Reference: 'Schneier' is defined on line 931, but no explicit reference was found in the text == Unused Reference: 'SAPPK' is defined on line 938, but no explicit reference was found in the text == Unused Reference: 'WP96' is defined on line 946, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'BMS' -- Possible downref: Non-RFC (?) normative reference: ref. 'CP99' -- Possible downref: Non-RFC (?) normative reference: ref. 'Din' -- Possible downref: Non-RFC (?) normative reference: ref. 'HCD' ** Downref: Normative reference to an Experimental RFC: RFC 2093 (ref. 'Har1') ** Downref: Normative reference to an Experimental RFC: RFC 2094 (ref. 'Har2') -- Possible downref: Non-RFC (?) normative reference: ref. 'HH' -- Possible downref: Non-RFC (?) normative reference: ref. 'IKEdraft' -- Possible downref: Normative reference to a draft: ref. 'McCarthy' -- Possible downref: Non-RFC (?) normative reference: ref. 'McD' ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2327 (Obsoleted by RFC 4566) ** Downref: Normative reference to an Informational RFC: RFC 2367 ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 2627 -- Possible downref: Non-RFC (?) normative reference: ref. 'RMT' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' -- Possible downref: Non-RFC (?) normative reference: ref. 'SAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'SAPPK' -- Possible downref: Non-RFC (?) normative reference: ref. 'Wong' -- Duplicate reference: RFC2014, mentioned in 'WP96', was also mentioned in 'RFC2014'. Summary: 19 errors (**), 0 flaws (~~), 15 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Research Task Force Thomas Hardjono (Nortel) 2 INTERNET-DRAFT Ran Canetti (IBM Watson) 3 draft-irtf-smug-framework-01.txt Mark Baugher (PassEdge) 4 September 2000 Peter Dinsmore (NAI) 5 Expires March 2001 7 Secure IP Multicast: Problem areas, Framework, and Building Blocks 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as 25 "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document provides a foundation for the research work done as the Secure 35 Multicast Group (SMuG)of the IRTF. The document begins by introducing a 36 Reference Framework and problem areas, and proceeds to identify 37 functional building blocks for a secure multicast solution. 38 The identified building blocks, their definition and realization 39 will be the subject of future work of SmuG. 41 1. Introduction 43 Securing IP multicast communication is a complex task that involves 44 many aspects. Consequently, a secure IP multicast protocol suite must 45 have a number of components that address different aspects of the 46 problem. 48 This document proposes a reference framework for secure IP multicast 49 protocol suites and defines a breakdown to functional building-blocks 50 for such protocol suites. The proposal is a product of discussions at 51 the Secure Multicast Group (SmuG) of the IRTF, and is addressed at the 52 SmuG group as a basis for further discussion. In particular, this 53 document may serve as a basis for considering the issues that have been 54 addressed so far in the SMuG IRTF community, the issues that have yet 55 to be addressed, the issues that need further in-depth attention, and 56 technologies that may be ready for consideration by an IETF working 57 group. 59 Sections 2 and 3 present the problem areas, reference framework and briefly 60 discusses the functional entities, and interfaces, which are identified by 61 the framework. Section 4 presents the breakdown of the interfaces to 62 individual functional building blocks. Section 5 presents the conclusion. 64 2. Problem Areas in Secure Multicast 66 In order to begin to address the problems in securing IP multicast, we 67 identify three problem-areas and define a reference framework expressing 68 these problem areas. The three problem-areas are: 70 Problem-Area-1: Multicast data handling. This area covers problems 71 concerning the security-related treatments of multicast data by the 72 sender and the receiver. This problem-area is further discussed in 73 Section 2.1. 75 Problem-Area-2: Management of keying material. This area is concerned with 76 the secure distribution and refreshment of keying material. This 77 problem-area is further discussed in Section 2.2. 79 Problem-Area-3: Multicast security policies. This area covers aspects 80 of policy in the context of multicast security, taking into 81 consideration the fact that policies may be expressed in different ways, 82 that they may exist at different levels in a given multicast security 83 architecture and that they may be interpreted differently according to 84 the context in which they are specified and implemented. This problem area 85 is further discussed in Section 2.3. 87 2.1 Multicast Data Handling (Problem-Area-1) 89 In a secure multicast group the data typically needs to be: 91 1. Encrypted using the group key, mainly for access control and 92 possibly also for confidentiality. 94 2. Authenticated, for verifying the source and integrity of the 95 data. Authentication takes two flavors: 97 2.1 Source authentication and data integrity. 98 This functionality guarantees that the data originated with the 99 claimed source and was not modified en route (either by a group 100 member or an external attacker). 101 2.2 Group authentication. This type of authentication only guarantees 102 that the data was generated (or last modified) by some group 103 member. It does not guarantee data integrity unless all group 104 members are trusted. 106 While multicast encryption and group authentication are fairly standard and 107 similar to encrypting and authenticating 108 point-to-point communication, source authentication for multicast is 109 considerably more involved. Consequently, off-the-shelf solutions 110 (e.g., taken from IPSec [RFC2406], TLS [TLS]) may be sufficient for 111 encryption. For source authentication, however, special-purpose 112 transformations are necessary. See [CP99] for further elaboration on the 113 concerns regarding the data transforms, on present solutions and remaining 114 challenges. 116 2.2 Management of Keying Material (Problem-Area-2) 118 The term "keying material" refers to the cryptographic key belonging 119 to a group, the state associated with the keys and the other security 120 parameters related to the keys. Hence, the management of the 121 cryptographic keys belonging to a group necessarily requires the 122 management of their associated state and parameters. A number of 123 solutions for specific problems must be addressed. These may include 124 the following: 126 - Methods for member identification and authentication. 127 - Methods to verify the membership to groups. 128 - Methods to establish a secure channel between a KS+GC entity and the 129 member, for the purpose of delivery of shorter-term keying material 130 pertaining to a group. 131 - Methods to establish a long-term secure channel between one KS+GC 132 entity and another, for the purpose of distributing shorter-term 133 keying material pertaining to a group. 134 - Methods to effect the changing of keys and keying material 135 - Methods to detect and signal failures and perceived compromises to 136 keys and keying material 138 The needs related to the management of keying material must be seen in 139 the context of the policies that prevail within the given circumstance. 141 2.3 Multicast Security Policies (Problem-Area-3) 143 Multicast Security Policies must provide the rules for operation 144 for the other elements of the Reference Framework. While much of 145 the work for the Multicast Security Policy area is focused in the 146 Policy Controller, there are potential areas for work in the 147 application of policy at the Group Controller element and the 148 member (sender and receiver) elements. While there is already a 149 basis for security policy management in the IETF between the 150 Policy Working Group and the IP Security Policy Working Group, 151 multicast security policy management will extend the concepts 152 developed for unicast communication in the areas of: 154 - Policy creation, 155 - High-level policy translation, and 156 - Policy representation. 158 Examples of work in multicast security policies include the 159 Dynamic Cryptographic Context Management project [Din], Group Key 160 Management Protocol [Har], and Antigone[McD]. 162 Policy creation for secure multicast has several more dimensions 163 than the single administrator specified policy assumed in the 164 existing unicast policy frameworks. Secure multicast groups are 165 usually large and by their very nature extend over several 166 administrative domains, if not spanning a different domain for 167 each user. There are several methods that need to be explored 168 for the creation of a single, coherent group security policy. 169 They include a top-down specification of the group policy from 170 the group initiator and negotiation of the policy between the 171 group members (or prospective members). Negotiation can be as 172 simple as a strict intersection of the policies of the members or 173 extremely complicated using weighted voting systems. 175 High-level policy translation is much more difficult in a 176 multicast group environment, especially when group membership 177 spans multiple administrative domains. When policies are 178 specified at a high level with a Policy Management tool, they 179 must then be translated into more precise rules that the 180 available security mechanisms can both understand and implement. 181 When dealing with multicast communication and its multiple 182 participants, it is essential that the individual translation 183 performed for each participant result in the use of a mechanism 184 that is interoperable with the results of all of the other 185 translations. Typically, the translation from high-level policy 186 to implementation mechanisms must result in the same mechanism in 187 order to achieve communication between all of the group members. 188 The requirement that policy translation results in the same 189 mechanism places constraints on the use and representations in 190 the high-level policies. It is also important that policy 191 negotiation and translation be performed as an integral part of 192 joining a group. Adding a member to a group is meaningless if 193 they will not be able to participate in the group communications. 195 Multicast security policies must represent, or contain, more 196 information than a traditional peer-to-peer policy. In addition 197 to representing the security mechanisms for the group 198 communication, the policy must also represent the rules for the 199 governance of the secure group. Policy must be established for 200 the basic group operations of add and remove, as well as more 201 advanced operations such as leave, rejoin, or resync. 203 3. Problem Scope and Reference Framework 205 This section considers the complex problems of multicast security in the 206 context of a heuristic device, the Reference Framework diagram, shown in 207 Figure 1. The Reference Framework is used to classify problem areas, 208 functional elements, and interfaces. The Reference Framework defines 209 the building blocks and suggested program of work for research and 210 standardization, which is presented in a later section of this paper. 212 3.1 A Reference Framework 214 Based on the three broad problem-areas, a reference framework is 215 proposed (Figure 1). The reference framework attempts to incorporate 216 the main entities and functions relating to multicast security, and to 217 depict the inter-relations among them. At the same time it also tries 218 to express the complex multicast security question from the perspective 219 of problem classification (i.e., the three problem areas), from the 220 perspective of architectures (centralized and distributed), of 221 multicast types (1-to-M or M-to-N), and protocols (the exchanged 222 messages). 224 The aim of the reference framework is to provide some general context 225 within which problems can be identified and classified (as being under 226 a given problem-area) and the relationships among the problems can be 227 recognized. Note that some issues span more than one so-called problem- 228 area. In fact, the framework encourages the precise identification and 229 formulation of issues that involve more than one problem-area or those 230 which are difficult to express in terms of a single problem area. An 231 example of such a case is the expression of policies concerning group 232 keys, which involves both the problem-areas of group key management and 233 multicast policies. 235 When considering the reference framework (Figure 1) it is important to 236 realize that the singular "boxes" in the framework do not necessarily 237 imply a corresponding singular entity implementing a given function. 239 Rather, a box in the framework should be interpreted loosely as 240 pertaining to a given function related to a problem-area. Whether that 241 function is in reality implemented as one or more physical entities is 242 dependent on the particular solution. As an example, the box labelled 243 "Key Server" must be interpreted in broad terms as referring to the 244 functions of key management. Similarly, the Reference Framework 245 acknowledges that some implementations may in fact merge a number of 246 the "boxes" into a single physical entity. 248 The reference framework can be viewed horizontally and vertically. 249 Horizontally, it displays both the entities and functions as singular 250 boxes, expressing each of the three broad problem-areas. Vertically, 251 it expresses the basic architecture designs for solutions, namely a 252 centralized architecture and a distributed architecture. 254 The protocols to be standardized are depicted in Figure 1 by the arrows 255 that connect the various boxes. See more details in Section 4, below. 257 +------------------------------------------------------------------+ 258 | CENTRALIZED \ DISTRIBUTED | 259 | DESIGNS \ DESIGNS | 260 | \ | 261 | \ | 262 | +------+ \ +------+ | 263 | Problem |Policy|<-------\------------------------>|Policy| | 264 | Area 1 |Server| \ |Server| | 265 | +------+ \ +------+ | 266 | ^ \ ^ | 267 | | \ | | 268 | | \ | | 269 | v \ v | 270 | +------+ \ +------+ | 271 | |Group |<-------------- \---------------> |Group | | 272 | Problem |Ctrl/ |<---------+ \ |Ctlr/ | | 273 | Area 2 |Key | | \ |Key | | 274 | |Server| V \ |Server| | 275 | +------+ +--------+ \ +------+ | 276 | ^ | | \ ^ | 277 | | |Receiver| \ | | 278 | | | | | | | 279 | v +--------+ | | | 280 | +------+ ^ | V | 281 | | | | | +--------+ | 282 | Problem |Sender|<---------+ | | | | 283 | Area 1 | |<--------------------- |-------->|Receiver| | 284 | | | | | | | 285 | +------+ | +--------+ | 286 +------------------------------------------------------------------+ 287 FIGURE 1: PROPOSED REFERENCE FRAMEWORK FOR SECURE MULTICAST 289 3.2 Elements of the Reference Framework 291 The Reference Framework diagram of Figure 1 contains boxes and arrows. 292 The boxes are the functional entities and the arrows are the interfaces 293 between them. Standard protocols are needed for the interfaces, which 294 support the multicast services between the functional entities. There 295 are three sets of functional entities in both centralized and 296 distributed designs as discussed below. 298 3.2.1 Key Server and Group Controller 300 The Key Server and Group Controller (KS+GC) represent both the entity 301 and functions relating to the issuance and management of cryptographic 302 keys used by a multicast group, which is subject to the 303 user-authentication and authorization checks conducted on the 304 candidate member of the multicast group. 306 In a distributed architecture the KS+GC entity also interacts with 307 other KS+GC entities to achieve scalability in the key management 308 related services. In such a case, each member of a multicast group 309 may interact with one or more KS+GC entity (say, the "nearest" KS+GC 310 entity, measured in terms of a well-defined and consistent metric). 311 Similarly, in a distributed architecture a KS+GC entity may interact 312 with one or more Policy Servers, also arranged in a distributed 313 architecture. 315 We remark that the Key Server (KS) and the Group Controller (GC) have 316 somewhat different functionality and may in principle be regarded as 317 separate entities. Currently the framework regards the two entities as 318 one "box" in order to simplify the design, and in order not to mandate 319 standardization of the protocol between the KS and the GC. It is 320 stressed that the KS and GC need NOT be co-located. Furthermore, future 321 designs may choose to standardize the protocol between the GC and the 322 KS, without altering other components. 324 3.2.2 Sender and Receiver 326 The Sender is an entity that sends data to the multicast group. In a 327 1-to-N multicast group only a single sender is allowed to transmit data 328 to the group. In an M-to-N multicast group many (or even all) group 329 members can transmit data to the group. 331 Both Sender and Receiver must interact with the KS+GC entity for the 332 purpose of key management. This includes user-authentication, the 333 obtaining of keying material in accordance with some key management 334 policies for the group, obtaining new keys during key-updates, and 335 obtaining other messages relating to the management of keying material 336 and security parameters. 338 The influence of policies on both Senders and Receivers is seen as 339 coming indirectly through the KS+GC entities, since the event of 340 joining a multicast group is typically coupled with the Sender/Receiver 341 obtaining keying material from a KS+GC entity. This does not preclude 342 the direct interaction between the Sender/Receiver and the Policy 343 Server. 345 The reference framework displays two Receiver boxes corresponding to 346 the situation where both the Sender and Receiver employ the same KS+GC 347 entity (centralized architecture) and where the Sender and Receiver 348 employ different KS+GC entities (distributed architecture). 350 3.2.3 Policy Server 352 The Policy Server represents both the entity and functions used to 353 create and manage security policies specific to a multicast group. 354 The Policy Server interacts with the KS+GC entity in order to install 355 and manage the security policies related to the membership of a given 356 multicast group and those related to keying material for a multicast 357 group. 359 The interactions between the Policy Server and other entities in the 360 reference framework is dependent to a large extent on the security 361 circumstances being addressed by a given policy. 363 3.2.4 Centralized and Distributed Designs 365 The need for solutions to be scalable to large groups across wide 366 geographic regions of the Internet requires the elements of the 367 framework to also function as a distributed system. This implies that 368 a KS+GC entity must be able to interact securely with other KS+GC 369 entities in a different location. Similarly, Policy Servers must 370 interact with each other securely to allow the communication and 371 enforcement of policies across the Internet. 373 4. Building Blocks 375 This section breaks down the secure multicast problem to functional 376 building blocks. The breakdown uses the Reference Framework presented 377 in Section 2 to identify high-level building blocks. 379 A "multicast security building block" provides a multicast security 380 service, such as multicast data confidentiality, or it provides a 381 service to multicast security, such as an application programming 382 interface (API). Specifications for an API or multicast confidentiality 383 protocol, however, are building blocks that can be directly 384 implemented. This paper describes "functional building blocks," which 385 are at a higher level of abstraction than algorithm or protocol 386 specifications. Our goal is to identify functional building blocks 387 that will focus work on algorithms, protocols, and other specifications 388 that can be implemented to solve multicast security problems. In our 389 approach, a functional building block is mapped to specific boxes or 390 interfaces in the Reference Diagram of Figure 1. This section 391 identifies which functions are performed where in Figure 1 without 392 defining a specific realization of a functional building block. 394 As an example, an algorithm such as Diffie-Hellman key exchange is one 395 possible realization of a key management functional building block. An 396 algorithmic building block is at a lower level of abstraction than a 397 functional building block. Protocols or APIs that can be directly 398 implemented in computer hardware or software may in turn, realize 399 algorithms. The Internet Key Exchange [RFC2409], for example, realizes 400 Diffie-Hellman and ISAKMP [RFC2408]; the TLS Handshake Protocol 401 [RFC2246] realizes Diffie-Hellman and RSA. 403 Thus, our treatment of functional building blocks for multicast 404 security is relatively abstract and will only be of practical use when 405 functional building blocks are realized as algorithms and protocols. 406 We propose to focus the work on multicast security algorithms and 407 protocols along the lines of functional building blocks as a problem- 408 solving strategy. Section 4.1 motivates the building blocks approach 409 to multicast security by listing three reasons for using this approach 410 followed by three criteria by which to evaluate multicast security 411 building blocks. Section 4.2 considers some functional building blocks 412 for multicast security. 414 4.1. Motivation 416 A common approach to solving a complex problem is to subdivide the 417 problem into manageable "blocks". Here, each block must serve a well- 418 defined function and its relationship with other blocks must be clearly 419 defined. Besides being more manageable, the approach inherently has a 420 number of advantages including use and re-use of the functional block 421 independently of the whole, and the ability to combine different blocks 422 to satisfy multiple functions. There are a number of risks to the 423 building blocks approach [RMT]: 425 1. Delayed development, which results from the need for additional 426 work to develop ways to combine independent building blocks. 428 2. Increased complexity, which is caused by too many building 429 blocks having too many interfaces. 431 3. Reduced performance, which may be caused by too much 432 modularization. 434 4. Abandonment of prior work, which results from attempts to 435 develop robust, general solutions. 437 These risks were identified for the multicast file transfer work. The 438 fourth risk addresses an historic fact in the development of multicast 439 file transfer that is not true for multicast security. It may be true, 440 however, that an attempt to develop general solutions for diverse 441 requirements, such as IP multicast and application-layer multicast 442 security requirements, may retard the development of particular 443 solutions. Although we have restricted our attention to functional 444 building blocks in this paper, as described in section 4.0, there may 445 be algorithms that solve common problems in both application-layer 446 multicast and IP multicast. The IETF IPSec working group, moreover, has 447 already produced a key management protocol that aims to provide for 448 both application-layer multicast and IP multicast services, if properly 449 extended [RFC2408]. 451 Despite the above-mentioned risks, there are at least three important 452 benefits to multicast security in applying the building blocks approach. 454 1. Re-use of publicly-reviewed cryptographic protocols: Even the 455 best cryptographic mechanism can be effectively attacked at the 456 protocol level [Schneier p. 473], so we seek to benefit from the 457 re-use of proven technologies, which is inherent in a building- 458 blocks approach to cryptographic protocols. 460 2. Timely delivery of needed technology: Using multicast building 461 blocks, we hope to standardize specific technology, such as 462 multicast confidentiality, independently of other security 463 services that may take longer to specify for a great variety of 464 uses, such as multicast source and data authentication. 466 3. Robust support for a variety of application environments: Good 467 building block definitions will permit the combination of 468 individual building blocks to flexibly add security services to 469 IP multicast or application-layer multicast traffic. 471 4. Simplicity in the proof of correctness and working of each 472 building block as a separate block. 474 To make the notion of building blocks more concrete, consider the 475 example of the independence of protocols in the IPSec suite. Certain 476 IPSec protocols such as AH [RFC2402] and ESP [RFC2406] perform their 477 security functions independently of other protocols in the IPSec suite, 478 such as Internet Key Exchange (IKE), which provides security 479 association [RFC2401] and key management services to AH and ESP. As a 480 result of this independence, a compliant ESP implementation can be used 481 today to provide IP multicast confidentiality despite the fact that an 482 IKE security association (SA) is unique to a pair of communicating 483 endpoints and is unsuitable for managing multicast group keys. If ESP 484 uses an IPSec SA having a multicast address, however, it effectively 485 supports IP multicast confidentiality since there is no requirement 486 that an SA used by ESP be established by IKE (though this might be a 487 reasonable policy for some environments). Thus, other applications, 488 such as a future ISAKMP variant may be used to establish the keying 489 material needed for an IP multicast ESP service. For this to work, 490 however, an application-programming interface may be needed for updates 491 to the host security association database - an API such as PF_KEY 492 [RFC2367] may serve this purpose although the definition of an SA may 493 need to be extended for multicast [HH]. Taken together, ESP and PF_KEY 494 can provide a useful multicast security service - IP multicast 495 confidentiality. The capacity to provide a useful security service is 496 one important criterion for a multicast security building block, which 497 is realized in an algorithm, protocol, API, or by other means. In 498 cases where authentication of multicast packet sources is required, 499 however, ESP is probably unsuitable: ESP source and data authentication 500 use a symmetric key, which is a shared secret among all members of the 501 particular multicast group [RFC2403, RFC2404]. An alternative approach 502 of using an asymmetric signature algorithm [RFC2406] would generally be 503 too slow for real-time multicast flows. 505 The mechanisms used in ESP for authentication and integrity, therefore, 506 will not authenticate individual senders to a multicast group. Just as 507 some applications may need only a subset of multicast security 508 services, others will require a "Whole Protocol" [RMT]. A multicast 509 security building block should be able to be combined with other 510 building blocks to provide additional security services. Without this 511 property, the building block is little more than an incomplete solution 512 to the general problem. Thus a second criterion for a good multicast 513 security building block is that it can be combined with other building 514 blocks to provide additional security services. A good building block 515 for IP multicast confidentiality can be combined with other building 516 blocks for IP multicast source authentication, data authentication 517 (integrity), and additional security services. 519 A good example of the building blocks approach is the work being done 520 on multicast packet-level source and data authentication within the 521 SMuG community. One output of this effort is a draft specification on 522 multicast packet-level authentication for RTP applications [McCarthy], 523 which is a proposed RTP Profile [RFC1889]. The "RTP Profile for Source 524 Authentication and Non-Repudiation of Audio and Video Conferences," 525 proposes to efficiently authenticate the sender and verify the 526 integrity of multicast packets by applying a digital signature over 527 the hash of a sequence of packets [Wong, McCarthy]. Although practical 528 experience is needed to evaluate this protocol, it illustrates the use 529 of a multicast security building block. A successful multicast source 530 or data-packet authentication building block should be applicable to 531 other applications such as SDP/SAP [RFC2327, SAP]. Indeed, technology 532 that solves source and data-packet authentication for real-time 533 multicast application traffic should be considered for IP multicast 534 traffic as well - at least the algorithm, if not the protocol. Thus, 535 a third criterion for a multicast security building block is its 536 applicability to IP multicast and application-layer multicast security. 538 The preceding discussion has established a set of three criteria for 539 good multicast security building blocks. 541 1. A building block provides a flexible security service. A protocol 542 that realizes a building block should be 543 standardizable independently of other building blocks. 545 2. Building blocks can be combined in a framework to provide a set 546 of multicast security services that amount to a "Whole Protocol" for 547 multicast security. 549 3. Building blocks can be applied to both IP multicast and 550 application-layer multicast security; good multicast security 551 building blocks can be adapted for both protocol and data 552 security. 554 As discussed above, useful solutions may not satisfy all three 555 criteria, but we expect that the most promising proposals for 556 standardization would satisfy more than a single criterion. Thus, our 557 criteria are suggested as measures of goodness for a functional or 558 protocol building block. 560 In addition to the demands of productive use and standardization, the 561 building blocks approach allows the identification of certain problems 562 that are still ill understood and thus ill defined. In the context of 563 the SMuG IRTF group, we expect that the building blocks approach will 564 help focus our research mission and facilitate our standards 565 objectives. By adopting this approach early, SMuG can avoid the 566 near-impossible task of extracting building blocks from mature 567 protocols and can positively influence multicast standards work that 568 may occur in IETF working groups. 570 The building blocks approach also allows the sharing of standardized 571 technologies with working groups within the IRTF and the IETF. For 572 example, certain blocks developed with the SMuG IRTF group may be 573 useful and deployable by the Reliable Multicast Transport (RMT) 574 Working Group in their efforts to secure the RMT protocols. The same 575 blocks may also be used to secure other application protocols (e.g., 576 RTP), multicast routing protocols, and be applied to other areas where 577 both multicast and security services are needed. 579 4.2. Functional Building Blocks 581 Referring to our Reference Diagram, this section identifies functional 582 building blocks for designated interfaces of Figure 1. In this 583 section, distinct functional building blocks are assigned to specific 584 interfaces. For example, multicast source authentication, data 585 authentication, and confidentiality occur on the multicast data 586 interface between Senders and Receivers in Figure 1. Authentication 587 and confidentiality services may also be needed between the Key Server 588 and key clients (i.e., the Senders and Receivers of Figure 1), but the 589 services that are needed for multicast key management may be unicast 590 as well as multicast. Multicast Key Management is a separate 591 function and has a separate building block. A functional building 592 block for multicast security, therefore, identifies a specific function 593 along one or more Figure 1 interfaces. 595 This paper does not attempt to analyze the trust relationships, 596 detailed functional requirements, performance requirements, suitable 597 algorithms, and protocol specifications for IP multicast and 598 application-layer multicast security. Instead, we propose these tasks 599 as future work that will occur as the functional building blocks are 600 further defined and realized in algorithms and protocols. 602 We identify a set functional building blocks in the following sections. 603 This preliminary list of building blocks is intended to serve as a 604 basis for discussion at the SMuG working group. We anticipate that work 605 done on the several high-level, functional building blocks described 606 below will lead to the specification of lower-level building blocks 607 that can be implemented to provide needed multicast security services. 609 4.2.1 Multicast Data Confidentiality 611 This functional building block handles the encryption of multicast data 612 at the Sender's end and the decryption at the Receiver's end. This 613 building block presumably may apply the keying material that is 614 provided by Multicast Key Management in accordance with Multicast 615 Policy Management, but it is independent of both. 617 An important part of the future work on the Multicast Data 618 Confidentiality building block is in the identification of and 619 motivation for specific ciphers that should be used for multicast data. 620 Obviously, not all ciphers will be suitable for IP multicast and 621 application-layer multicast traffic. Since this traffic will usually 622 be connectionless UDP flows, stream ciphers may be unsuitable though 623 hybrid stream/block ciphers may have advantages over some block ciphers. 624 Those working on this functional building block will need to evaluate 625 the real-time and other requirements of multicast senders and 626 receivers, and recommend a small set of promising ciphers and data 627 protocols for IP multicast and application-layer multicast data 628 confidentiality. 630 Regarding application-layer multicast, some consideration is needed to 631 the effects of sending encrypted data in a multicast environment 632 lacking admission-control, where practically any application program 633 can join a multicast event independently of its participation in a 634 multicast security protocol. Thus, this building block is also 635 concerned with the effects of multicast confidentiality services, 636 intended and otherwise, on application programs in all senders and 637 receivers. 639 In Figure 1, the Multicast Data Confidentiality building block is 640 placed in Problem Area 1 along the interface between Senders and 641 Receivers. The algorithms and protocols that are realized from work 642 on this building block may be applied to other interfaces and Problem 643 Areas of Figure 1 when multicast data confidentiality is needed. 645 4.2.2 Multicast Source Authentication and Data Integrity 647 This building block handles source authentication and integrity 648 verification of multicast data. It includes the transforms to be made 649 both at the Sender's end and at the Receiver's end. It assumes that the 650 appropriate signature and verification keys are provided via Multicast 651 Key Management in accordance with Multicast Policy Management as 652 described below. Work done by members of the SMuG community suggests 653 that this is one of the harder areas of multicast security based on the 654 connectionless and real-time requirements of many IP multicast 655 applications. There are classes of application-layer multicast 656 security, however, where offline source and data authentication will 657 suffice. As discussed in section 4.1, not all multicast applications 658 require real-time authentication and data-packet integrity. A robust 659 solution to multicast source and data authentication, however, is 660 necessary for a Whole Protocol solution to multicast security. 662 In Figure 1, the Multicast Source and Data Authentication building 663 block is placed in Problem Area 1 along the interface between Senders 664 and Receivers. The algorithms and protocols that are produced for this 665 functional building block may have applicability to building blocks in 666 other Problem Areas that use multicast services such as Multicast Key 667 Management. 669 4.2.3. Multicast Group Authentication 671 This building block provides a limited amount of authenticity of the 672 transmitted data: It only guarantees that the data originated with (or 673 was last modified by) one of the group members. It does not guarantee 674 authenticity of the data in case that other group members are not 675 trusted. 677 The advantage of group authentication is that it is guaranteed via 678 relatively simple and efficient cryptographic transforms. Therefore, 679 when source authentication is not paramount group authentication 680 becomes useful. In addition, performing group authentication is useful 681 even when source authentication is later performed: it provides a 682 simple-to-verify weak integrity check that is useful as a measure 683 against denial-of -service attacks. 685 The Multicast Group Authentication building block is placed in Problem 686 Area 1 along the interface between Senders and Receivers. 688 4.2.4 Multicast Group Membership Management 690 This building-block describes the functionality of registration and de- 691 registration of members. Registration includes member authentication, 692 notification and negotiation of security parameters, and logging of 693 information according to the policies of the group controller and the 694 would-be member. (Typically, an out-of-band advertisement of group 695 information would occur before the registration takes place. The 696 registration process will typically be invoked by the would-be member.) 698 De-registration may occur either at the initiative of the member or at 699 the initiative of the group controller. It would result in logging of 700 the de-registration event by the group controller and an invocation of 701 the appropriate mechanism for terminating the membership of the de- 702 registering member (see Section 4.2.5). 704 This building block also describes the functionality of the 705 communication related to group membership among different 706 GC+KS servers in a distributed group design. 708 In Figure 1, the Multicast Group Membership building block is placed in 709 Problem Area 2 and has interfaces to Senders and Receivers. 711 4.2.5 Multicast Key Management 713 This building-block describes the functionality of distributing and 714 updating the cryptographic keying material throughout the life of the 715 group. Components of this building may include: 717 - GC+KS to Client (Sender or Receiver) notification regarding current 718 keying material (e.g. group encryption and authentication keys, 719 auxiliary keys used for group management, keys for source 720 authentication, etc). 722 - Updating of current keying material, depending on circumstances and 723 policies. 725 - Termination of groups in a secure manner, including the multicast 726 group itself and the associated keying material. 728 Among the problems to be solved by this building block is the secure 729 management of keys between Key Servers and Clients, the addressing 730 issues for the multicast distribution of keying material, and the 731 scalability or other performance requirements for multicast key 732 management [RFC2627, BMS]. 734 To allow for an interoperable and secure IP multicast security 735 protocol, this building block may need to specify host abstractions 736 such as a group security association database (GSAD) and a group 737 security policy database (GSPD) for IP multicast security. The degree 738 of overlap between IP multicast and application-layer multicast key 739 management needs to be considered. Thus, work on this functional 740 building block must take into account the key management requirements 741 for IP multicast, the key management requirements for application-layer 742 multicast, and to what degree specific realizations of a Multicast Key 743 Management building block can satisfy both. ISAKMP, moreover, has been 744 designed to be extensible to multicast key management for both IP 745 multicast and application-layer multicast security [RFC2408]. Thus, 746 multicast key management protocols may use the existing ISAKMP 747 standard's Phase 1 and Phase 2 protocols, possibly with needed 748 extensions (such as an ISAKMP Domain of Interpretation for IP multicast 749 or application-layer multicast security). 751 This building block also describes the functionality of the 752 communication related to key management among different 753 GC+KS servers in a distributed group design. 755 Multicast Key Management appears in both the centralized and distributed 756 designs as shown in Figure 1 and is placed in Problem Area 2. 758 4.2.6 Multicast Policy Management 760 This functional building block handles all matters related to multicast 761 group policy including membership policy and multicast key management 762 policy. Indeed, one of the first tasks in further defining this 763 functional building block is identifying the different areas of 764 multicast policy. Multicast Policy Management includes the design of 765 the policy server for multicast security, the particular policy 766 definitions that will be used for IP multicast and application-layer 767 multicast security, and the communication protocols between the Policy 768 Server and the Key Server. This functional building block may be 769 realized using a standard policy infrastructure such as a Policy 770 Decision Point (PDP) and Policy Enforcement Point (PEP) architecture. 771 Thus, it may not be necessary to re-invent a separate architecture for 772 multicast security policy; we expect that this work will evaluate use 773 of the products of IETF efforts in the areas of network and security 774 policy. At minimum, however, this functional building block will be 775 realized in a set of policy definitions, such as multicast security 776 conditions and actions. 778 The Multicast Policy Management building block describes the 779 functionality of the communication between an instance of a GC+KS to an 780 instance the Policy Server. The information transmitted may include 781 policies concerning groups, memberships, keying material definition and 782 their permissible uses, and other information. This building block also 783 describes communication between and among Policy Servers. Thus, the 784 Multicast Policy Management building block is placed in Problem 785 Area 3, along the interface between Key Servers and Policy Servers. 786 Group members are not expected to directly participate in this 787 building block. However, this option is not ruled out. 789 5. Conclusion 791 As stated in section 4, the ultimate goal of developing multicast 792 security building blocks is to produce better specifications that can 793 be standardized as expeditiously as possible. Section 2 classifies the 794 problems we seek to solve along the lines of Problem Areas. And Section 795 3 presents a heuristic device, the Reference Framework, to facilitate 796 investigation and standardization of multicast security building 797 blocks. Section 4.1 motivates this approach as having three distinct 798 advantages. Section 4.1 also advances some criteria for evaluating 799 algorithms, protocols, and other specifications for the six functional 800 building blocks that are proposed in section 4.2. We recommend that 801 work be undertaken to elucidate the requirements and functions of each 802 of the building blocks that are proposed in section 4.2. This work 803 should be closely followed by analysis of algorithms and the 804 specification of protocol building blocks. 806 We expect that the partitioning of multicast security services along 807 the lines of functional building blocks, as described in this document, 808 has a number of advantages: The building blocks approach should 809 encourage the development of particular technology for particular 810 problems and foster the development of individual pieces of a whole 811 multicast security protocol. Rather than delayed development, which 812 is the first problem identified by RMT [RMT} above, work on the 813 individual building blocks should proceed in parallel despite some 814 obvious dependencies. 816 For a given building block, one dependency exists between parts of the 817 building block that deal with a different building block (Centralized 818 Design) and parts that deal with different instances of the same 819 building block (Distributed Design). This dependency, however, does 820 not prevent work on the Centralized Design to proceed, while at the 821 same time the requirements and functions needed for distributed designs 822 are considered by others who are working on this problem independently 823 in SMuG. 825 A second dependency exists between the Multicast Confidentiality and 826 the Source and Data Authentication building blocks. The protocols and 827 packet formats for encrypted data transmission must accommodate the 828 needs of source authentication and data integrity. Cryptographic 829 protocols tend to be modular, however, and follow a building block 830 approach. To draw an example from IPSec, the AH and ESP protocols are 831 specified independently but are capable of being applied to any packet 832 flow. 834 We believe that de-coupling multicast security services such as 835 confidentiality and authentication/integrity can produce better 836 protocols more quickly. And we expect to draw on a large body of 837 experience of developing transport and network security protocols to 838 avoid the risks and pitfalls of the building block approach while 839 reaping its advantages for multicast security research and 840 standardization. 842 References 844 [BMS] D. Balenson, D. McGrew, A. Sherman, Key Management for Large 845 Dynamic Groups: One-Way Function Trees and Amortized Initialization, 846 http://www.ietf.org/internet-drafts/draft-balenson-groupkeymgmt-oft- 847 00.txt, February 1999, Work in Progress. 849 [CP99] R. Canetti and B. Pinkas, A taxonomy of multicast security 850 issues, http://search.ietf.org/internet-drafts/draft-irtf-smug-taxonomy- 851 01.txt, April 1999, Work in Progress. 853 [Din] Dinsmore, P., Balenson, D., Heyman, M., Kruus, P., Scace, C., and 854 Sherman, A., "Policy-Based Security Management for Large Dynamic 855 Groups: An Overview of the DCCM Project," DARPA Information 856 Survivability Conference and Exposition, To Be Published. 858 [HCD] T. Hardjono, B. Cain, N. Doraswamy, A framework for group key 859 management for multicast security, http://www.ietf.org/internet- 860 drafts/draft-ietf-ipsec-gkmframework-00.txt, July 1998, Work in 861 Progress. 863 [Har1] Harney, H., and Muckenhirn, C., "Group Key Management Protocol 864 (GKMP) Specification," RFC 2093, July 1997. 866 [Har2] Harney, H., and Muckenhirn, C., "Group Key Management Protocol 867 (GKMP) Architecture," RFC 2094, July 1997. 869 [HH] H. Harney, E. Harder, Group Secure Association Key Management 870 Protocol, http://search.ietf.org/internet-drafts/draft-harney-sparta- 871 gsakmp-sec-00.txt, April 1999, Work in Progress. 873 [IKEdraft] D. Harkins, D. Carrel, The Internet Key Exchange (IKE), 874 http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-01.txt, May 875 1999, Work in Progress. 877 [McCarthy] L. McCarthy, RTP Profile for Source Authentication and Non- 878 Repudiation of Audio and Video Conferences, draft-mccarthy-smug-rtp- 879 profile-src-auth-00.txt, May 1999, Work in Progress. 881 [McD] McDaniel, P., Honeyman, P., and Prakash, A., "Antigone: 882 A Flexible Framework for Secure Group Communication," Proceedings of the 883 Eight USENIX Security Symposium, pp 99-113, August, 1999. 885 [RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A 886 Transport Protocol for Real-Time Applications, January 1996. 888 [RFC2014] A. Weinrib and J. Postel, IRTF Research Group Guidelines and 889 Procedures, RFC 2014, October 1996. 891 [RFC2246] Dierks, T. and C. Allen, The TLS Protocol Version 1.0, 892 RFC 2246, January 1999. 894 [RFC2327] M. Handley, V. Jacobson, SDP: Session Description Protocol, 895 April 1998. 897 [RFC2367] D. McDonald, C. Metz, B. Phan, PF_KEY Key Management API, 898 Version 2, July 1998. 900 [RFC2401] S. Kent, R. Atkinson, Security Architecture for the Internet 901 Protocol, November 1998 903 [RFC2402] S. Kent, R. Atkinson, IP Authentication Header, November 1998 905 [RFC2403] C. Madson, R. Glenn, The Use of HMAC-MD5-96 within ESP and 906 AH, November 1998. 908 [RFC2404] C. Madson, R. Glenn, The Use of HMAC-SHA-1-96 within ESP and 909 AH, November 1998. 911 [RFC2406] S. Kent, R. Atkinson, IP Encapsulating Security Payload (ESP), 912 November 1998. 914 [RFC2407] D. Piper, The Internet IP Domain of Interpretation for ISAKMP, 915 November 1998. 917 [RFC2408] D. Maughan, M. Shertler, M. Schneider, J. Turner, Internet 918 Security Association and Key Management Protocol, November 1998. 920 [RFC2409] D. Harkins, D. Carrel, The Internet Key Exchange (IKE), 921 November, 1998. 923 [RFC2627] D. M. Wallner, E. Harder, R. C. Agee, Key Management for 924 Multicast: Issues and Architectures, September 1998. 926 [RMT] B.Whetten, L. Vicisano, R. Kermode, M. Handley, S. Floyd, 927 Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data 928 Transfer, http://www.ietf.org/internet-drafts/draft-ietf-rmt- 929 buildingblocks-00.txt, June 1999, Work in Progress. 931 [Schneier] B. Schneier, Applied Cryptography, Second Edition, John 932 Wiley, 1996. 934 [SAP] M. Handley, C. Perkins, E. Whelan, Session Announcement Protocol, 935 http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sap-v2-01.txt, 936 June 1999, Work in Progress. 938 [SAPPK] P. Kirstein, G. Montasser-Kohsari, E. Whelan, SAP Security 939 Using Public Key Algorithms, 940 http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sap-sec-04.txt, 941 September 1998, Work in Progress. 943 [Wong] C.K.Wong, S.S. Lam, Digital Signatures for Flows and Multicasts, 944 Proceedings of IEEE ICNP'98, October 14-16, 1998. 946 [WP96] A. Weinrib and J. Postel, IRTF Research Group Guidelines and 947 Procedures, RFC 2014, October 1996. 949 Authors' addresses: 951 Thomas Hardjono 952 Advanced Networks 953 Nortel Networks 954 600 Technology Park Dr. 955 Billerica, MA 01821 956 (978) 288-4538 957 thardjono@baynetworks.com 959 Ran Canetti 960 IBM Research 961 30 Saw Mill River Rd 962 Hawthorne, NY 10532 963 (914) 784-7076 964 canetti@watson.ibm.com 966 Mark Baugher 967 PassEdge 968 20400 NW Amberwood Drive 969 Beaverton, OR 97006, USA 970 (503) 466-8406 971 mbaugher@passedge.com 973 Peter Dinsmore 974 NAI Labs 975 3060 Washington Road, 976 Glenwood, MD 21738 977 (443) 259-2346 978 Pete_Dinsmore@NAI.com 980 Expires March 2001 982 -------------------------------------------------------------------- 983 ------------------------------------------------------------------------ 984 Thomas Hardjono email1: thardjono@yahoo.com 985 email2: hardjono@nortelnetworks.com 986 Tel: +1-978-288-4538 987 ------------------------------------------------------------------------