Internet Engineering Task Force Atul Sharma (Nokia, Inc) MSEC Working Group INTERNET-DRAFT EXPIRES: November 2004 May 2004 A Simple Approach to Data Source Authentication for Multicast Security Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Data source authentication is an important requirement to provide multicast security. Data source authentication assures that the member claiming to send the data is the actual sender. An imposter member should not be able to claim to be the sender of the data. This document proposes a scheme by which data source authentication can be acheived. This approach does not use digital signatures or assume any time synchronization between the sender and the receivers. Instead of directly authenticating a multicast communication, it is split into a 1-to-1 authenticated unicast to GCKS followed by an authenticated multicast by GCKS. Message Authentication Codes (MACs) are used instead of digital signatures in both the authenticated unicast and the authenticated multicast. Sharma, A. Expires November 2004 [Page 1] INTERNET-DRAFT Simple Multicast Data Source Authentication May 2004 Table of Contents Status of This Memo.................................................1 Abstract............................................................1 1.0 Notational Conventions..........................................2 2.0 Introduction....................................................3 3.0 Scheme..........................................................3 4.0 Further Enhancements............................................4 5.0 Security Considerations.........................................5 6.0 Acknowledgements................................................5 7.0 Author's Address................................................5 8.0 Intellectual Property Notices...................................5 9.0 Copyright Notice................................................6 10.0 References.....................................................7 1.0 Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terminology conforms to [RFC2828]. Sharma, A. Expires November 2004 [Page 2] INTERNET-DRAFT Simple Multicast Data Source Authentication May 2004 2.0 Introduction The problem of data source authentication is a tricky one[9]. In the case of two parties data source authentication is automatic, even with symmetric key cryptography, as only those two parties possess the symmetric shared key and nobody else. But when we do multicast between more than two parties, data source authentication is not automatic with symmetric key cryptography. All the members of the multicast group possess the shared symmetric key. All we can say is that some member of the group who posseses the group key sent the data. This is group authentication rather than individual data source authentication. Data source authentication can be most simply be solved by digital signatures. But digital signatures are expensive on a per packet basis, given that it involves public key cryptographic operations. There have been schemes where cost of digital signatures is amortized over several packets[3][4][5][6][7]. TESLA[8] uses the concept of time synchronization with digital signature amortization. This approach is a simple one, it does not involve digital signatures and does not need time synchronization between the sender and the receivers. Though there is an added cost of extra routing hops to achieve data source authentication. But these extra hops may be assimilated by regular routing hops taken by packets anyway. Basically the idea is to split 1-to-(N-1) multicast to a 1-to-1 unicast and a 1-to-N multicast communications. There is an assumption of a central entity, a Group Owner or a Group Controller Key Server (GCKS) like in Group Domain of Interpretation (GDOI)[1] and Group Security Association Key Management Protocol (GSAKMP)[2], which all the group members trust. The sending group member performs authenticated 2-party transmission with GCKS. GCKS in turn performs authenticated multicast on behalf of the sending member. Instead of digital signatures, Message Authentication Codes (MACs) are used for both transmissions. 3.0 Scheme By this scheme, every group member shares a unique shared secret (symmetric key) with GCKS like Phase-1 of GDOI. Every time a group member "i" needs to send a secure multicast to the group, it prepends the packet with its index "i"; encrypts this packet with one of the symmetric keys it shares with GCKS; calculates and attaches the MAC using its one of the symmetric keys with GCKS. Since only member "i" and the GCKS know their set of symmetric keys, the data source authentication with the GCKS is immediate because of encryption and the attached MAC. That is no other member "j" could impersonate as Sharma, A. Expires November 2004 [Page 3] INTERNET-DRAFT Simple Multicast Data Source Authentication May 2004 this member "i". Even man-in-the middle attack is not possible, since the packet is encrypted with the symmetric key of member "i". Group owner/GCKS authenticates by decrypting and verifying the attached MAC from the member "i". Now the group owner/GCKS encrypts the packet+index of the sender with GTEK (Group Traffic Encrypting Key); calculates N MACs for every member of the group with their respective shared secrets. These N MACs are attached to the encrypted packets and multicasted to the whole group. MACs are performed after the encryption of the packet with GTEK. When a group member receives the packet, based on its index which can be communicated under Phase-1 of GDOI, it picks up the MAC calculated with its shared secret with GCKS. It verifies its MAC; decrypts the packet with GTEK; and convinces that packet is authentic. Who sent the packet can be found by looking at the index of the sender gotten after decryption of the packet. Since index of the sender is part of the MAC calculation, no other member (who also has the GTEK can decrypt and put some other index than "i") can perform man-in-the-middle attack, as then MAC verification shall fail. So the GCKS authenticates that member "i" sent the packet and all other members authenticate that GCKS routed the packet from the member "i". +----+ --->| Mx | +---------+ / +----+ |Enc. w/i | / +----+ |Symm. Key| +--------+ ------>| My | +-+-------+----+ |Enc. w/i| / +----+ |i|Packet |MACi| +-------+ |GTEK | / . +----+ +-+-------+----+ |Group | +-+------+----+---+----+ | Mi |------------------>|Owner/ |-->|i|Packet|MAC1|...|MACn| +----+ <------|GCKS | +-+------+----+---+----+ +-------+ \ . \ . \ +----+ ---->| Mn | +----+ Figure 1: New Approach to Multicast Data Source Authentication 4.0 Enhancements It still needs to be worked on how to alleviate the shortfalls of the new approach. Sharma, A. Expires November 2004 [Page 4] INTERNET-DRAFT Simple Multicast Data Source Authentication May 2004 Though there are other schemes where multiple MACs are attached to the packet, calculating and attaching N MACs can be expensive depending on the size N. It is expected that there shall be a break point of the group size M, whereby for groups smaller than M, it is better to do symmetric key cryptography for data source authentication. And for groups bigger than M, it shall make more sense to do public key digital signatures for data source authentication. Given that MACs are about 1000 times faster than digital signatures, M is going to be a big number. It will be good if we could some how reduce the number of MACs attached, though we do not see how that could be done. Another issue is the Group Owner/GCKS can be the bottleneck and single point of failure. Having subordinate GCKS's can alleviate this disadvantage. 5.0 Security Considerations This internet-draft focuses on one of the security issue for multicast security, as presented in [9], viz: data source authentication. 6.0 Achnowledgements Author gratefully acknowledges efforts put in by Dr. Jon Graff, Maureen Stillman, Dr. Heikki Riitinen, Michael Williams, in reviewing and providing comments. 7.0 Author's Address Atul Sharma Nokia, Inc 5 Wayside Road Burlington, MA 01886 atul.sharma@nokia.com 1(781)993-3881 8.0 Intellectual Property Statement The IETF takes no position regarding the valifdity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in Sharma, A. Expires November 2004 [Page 5] INTERNET-DRAFT Simple Multicast Data Source Authentication May 2004 this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 9.0 Copyrights Notice Copyright (c) The internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwisw explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF Sharma, A. Expires November 2004 [Page 6] INTERNET-DRAFT Simple Multicast Data Source Authentication May 2004 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 10.0 References Normative References [1] Baugher, M., Weis, B., Hardjono, T., Harney, H., "The group Domain of Interpretation", RFC3547, July 2003. [2] Harney, H., Schuett, A., Colegrove, A., "GSAKMP Light", Internet-draft, http://www.ietf.org/internet-drafts/draft-ietf-msec- gsakmp-light-sec-01.txt. [3] Wong, C.K., Lam, S.S., "Digital Signatures for Flows and Multicasts", IEEE/ACM Transactions on Networking, Vol 7., No. 4, August 1999. [4] Merkle, R. C., "A Certified Digital Signature", Advances in Cryptology- Crypto, Berlin, Springer-Verlag, LNCS 435, August 1989. [5] Gennaro, R., and Rohatgi, P., "How to Sign Digital Streams", Advances in Cryptology-Crypto, Santa Barbara, Springer-Verlag, LNCS 1294, August 1997. [6] Golle, P., Modaddugu, N., "Authenticating Streamed Data in Presence of Random Packet Loss", Proc. of Network and Distributed System Security Symposium (NDSS), San Diego, CA, February 2001. [7] Miner, S., Staddon J., "Graph-based Authentication of Digital Streams", Proc. of IEEE Symposium on Security and Privacy, Oakland, CA, May 2001. [8] Perrig, A., Canetti, R., Whillock, "TESLA: Multicast Source Authentication Transform Specification", Internet-draft, http://www. ietf.org/internt-drafts/draft-ietf-msec-tesla-spec-00.txt", April 2003, Work in Progress. Informative References [9] Hardjono, T., Canetti, R., Baugher, M., Dinsmore, P., "Secure IP Multicast Problem areas, Framework, and Building Blocks", Internet-draft, "draft-irtf-smug-framework-01.txt", Sepember 2000, Work in Progress. Sharma, A. Expires November 2004 [Page 7]