The primary aim of this chapter has been to subdivide the complex problem of multicast and group security into manageable pieces; each of which will be addressed or discussed in subsequent chapters.
The broadest division was the categorization into fundamental issues as the first subgroup of problems, and transport and application issues as the second. The first covered problems pertain to routing infrastructure protection, controlled access to the multicast distribution tree, and the management of keying material. The latter include (but are not limited to) the security of RM protocols and other applications requirements.
Alhough these are not the only issues at hand, the first set of problems are referred to as fundamental, since they are a necessary first step toward securing IP multicast, and they lead to building blocks that may be used to solve other needs, such as security in RM protocols.
Efforts in the IETF focused initially on the management of keying material. Within this space, one significant development was the develop- ment of a Reference Framework as shown in Figure 2.3. The Reference Framework attempts to incorporate the main entities and functions relating to multicast security, and to depict the interrelations among them. At the same time it also tries to express the complex multicast security question from the perspectives of problem classification (i.e., the three problem areas) architectures (centralized and distributed), multicast types (one-to-many or many-to-many), and protocols (the exchanged messages).
The Reference Framework paved the way for the definition of three problem areas that would be immediately addressed by the SMuG research group (see Section 2.5). The three are multicast data handling (problem area 1), the management of keying material (problem area 2), and multicast security policies (problem area 3).
Using the Reference Framework as the basis, an approach was adopted based on the notion of building blocks, as a way for SMuG to work forward (see Section 2.6). This approach presents several advantages as well as risks. The resulting functional building blocks are: multicast data confidentiality, source authentication and data integrity, group authentication, group
membership management, key management, and multicast policy manage- ment. These building blocks have recently been the focus of the MSEC working group in the IETF.
References
[1] Deering, S., et al., ‘‘The PIM Architecture for Wide-Area Multicast Routing,’’
IEEE/ACM Trans. on Networking, Vol. 4, No. 2, 1996, pp. 153–162.
[2] Estrin, D., et. al., ‘‘Protocol Independent Multicast-Sparse Mode (PIM-SM),’’ protocol specification, RFC 2362 (experimental), IETF, June 1998.
[3] Waitzman, D., C. Partridge, and S. E. Deering, ‘‘Distance Vector Multicast Routing Protocol,’’ RFC 1075 (experimental), IETF, Nov. 1988.
[4] Moy, J., ‘‘Multicast Extensions to OSPF,’’ RFC 1584 (proposed standard), IETF, March 1994.
[5] Deering, S. E., ‘‘Host Extensions for IP Multicasting,’’ RFC 1112 (standard), IETF, August 1989.
[6] Cain, B., et al., ‘‘Internet Group Management Protocol, Version 3,’’ draft-ietf- idmr-igmp-v3-09.txt, IETF, January 2002, work in progress.
[7] Fenner, W., ‘‘Internet Group Management Protocol,’’ RFC 2236 (proposed standard), IETF, November 1997.
[8] Hardjono, T., B. Cain, and N. Doraswamy, ‘‘A Framework for Group Key Management for Multicast Security,’’ draft-ietf-ipsec-gkmframework-03.txt, IETF, August 2000, work in progress.
[9] Chaum, D., ‘‘Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms,’’Communications of the ACM, Vol. 24, No. 2, Feb. 1981.
[10] Chaum, D., ‘‘Showing Credentials Without Identification: Transferring Signatures Between Unconditionally Unlinkable Pseudonyms,’’ In Advances in Cryptology—AUSCRYPT, Sydney, Australia: Springer-Verlag Inc., LNCS 453, January 1990.
[11] Hardjono, T., and B. Cain, ‘‘Simple Key Management Protocol for PIM,’’ draft- ietf-pim-simplekmp-01.txt, IETF, February 2000, work in progress.
[12] Wei, L., ‘‘Authenticating PIM Version 2 Messages,’’ draft-ietf-pim-v2-auth- 01.txt, IETF, May 1999, work in progress.
[13] Dinsmore, P. T., et al., ‘‘Policy-Based Security Management for Large Dynamic Groups: An Overview of the DCCM Project,’’ inProc. of the DARPA Information Survivability Conference & Exposition Volume I of II (DISCEX), Hilton Head, SC, January 2000, pp. 64–73.
[14] Harney, H., and C. Muckenhirn, ‘‘Group Key Management Protocol (GKMP) Architecture,’’ RFC 2094 (experimental), July 1997.
[15] McDaniel, P., A. Prakash, and P. Honeyman, ‘‘Antigone: A Flexible Frame- work for Secure Group Communication,’’ inProc. of the 8th USENIX Security Symposium, Washington, D.C., August 1999, pp. 99–114.
[16] Whetten, B., et al., ‘‘Reliable Multicast Transport Building Blocks for One-to- Many Bulk-Data Transfer,’’ RFC 3048 (informational), IETF, January 2001. [17] Kent, S., and R. Atkinson, ‘‘IP Authentication Header (AH),’’ RFC 2402
(proposed standard), IETF, November 1998.
[18] Kent, S., and R. Atkinson, ‘‘IP Encapsulating Security Payload (ESP),’’ RFC 2406 (proposed standard), IETF, November 1998.
[19] Kent, S., and R. Atkinson, ‘‘Security Architecture for the Internet Protocol,’’ RFC 2401 (proposed standard), IETF, November 1998.
[20] McCarthy, L., ‘‘RTP Profile for Source Authentication and Non-Repudiation of Audio and Video Conferences,’’ draft-mccarthy-smug-rtp-profile-src-auth- 00.txt, IETF, May 1999, work in progress.
[21] Schulzrinne, H., et al., ‘‘RTP: A Transport Protocol for Real-Time Applica- tions,’’ RFC 1889 (proposed standard), IETF, January 1996.
[22] Wong, C. K., and S. S. Lam, ‘‘Digital Signatures for Flows and Multicasts,’’
IEEE/ACM Trans. on Networking, Vol. 7, No. 4, August 1999, pp. 502–513. [23] Handley, M., and V. Jacobson, ‘‘SDP: Session Description Protocol,’’ RFC 2327
(proposed standard), IETF, April 1998.
[24] Handley, M., C. Perkins, and E. Whelan, ‘‘Session Announcement Protocol,’’ RFC 2974 (experimental), IETF, October 2000.
[25] Yavatkar, R., D. Pendarakis, and R. Guerin, ‘‘A Framework for Policy-Based Admission Control,’’ RFC 2753 (informational), IETF, January 2000.
Multicast data authentication
S
ecure multicast data handling is one of the three problem areas (problem area 1; see Section 2.5) identified by the SMuG Research group and adopted by the IETF MSEC working group. Different applications have different requirements for secure data transmission. For example, in some cases, data source authentication and integrity protection may be suffi- cient (e.g., in news distribution), whereas other applications might need confidentiality (e.g., news distribution with access control) as well. Confidentiality of group communications is discussed in detail in Chapters 4, 5, and 6. Data source authentication of group communications is a challenging problem, and is the focus of this chapter.Different applications may need different levels of authen- tication for secure group communication. For example, in some applications it may be sufficient to know that a data packet originated within the secure group and has not been modified in transit by nonmembers. This property is known as group authentication. In other applications, members (or receivers) might need to verify to themselves that a data packet was sent by the claimed (or the authorized) source. This property is known as source authentication. Finally, in some cases a neutral third party should also be able to independently determine the data source. In other words, a sender should not be able to repudiate having ever sent the data.
There is another dimension to the challenges in source authentication of multicast data, presented by the nature of the applications. While there are some applications that involve
45
C H A P T E R
3
Contents
3.1 Issues in multicast data