Internet Engineering Task Force Atul Sharma (Nokia, Inc) MSEC Working Group INTERNET-DRAFT EXPIRES: December 2004 June 2004 Recall Packet 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. The idea is to instead of digitally signing the data packets, a digitally signed recall packet on detection of an imposter transmission. The data packets are sent using symmetric MAC authentication. Sharma, A. Expires December 16, 2004 [Page 1] Internet-Draft Recall Packet Data Source Authentication June 2004 Table of Contents 1.0 Notational Conventions..........................................2 2.0 Introduction....................................................2 3.0 Scheme..........................................................3 4.0 Further Enhancements........................................... 5.0 Security Considerations........................................ 6.0 Acknowledgements............................................... 7.0 Author's Address............................................... 8.0 Intellectual Property Statement................................ 9.0 Copyrights Notice.............................................. 10.0 References..................................................... 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 December 16, 2004 [Page 2] Internet-Draft Recall Packet Data Source Authentication June 2004 2.0 Introduction The problem of data source authentication is a tricky one [1][10] [11]. 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[4][5][6][7][8]. TESLA[9] uses the concept of time synchronization with digital signature amortization. Our approach is a simple one, it does not involve digital signatures, unless there is a rogue group member spoofing packets for another group member. Basically there are N keys generated from the keying material formed at the end of N-way Diffie-Hellman exchange, for each of the N group key members. With every packet a member sends its index/identity and MAC using its key Ki for authentication or encrypts the packet with key Ki. Every member uses the correct key to authenticate/decrypt the packet. The problem is that member "j" could impersonate as member "i", as it also knows the Key Ki. One way to discourage member "j" to claim that it is member "i" is to make member "i" send a digitally signed recall packet, once it detects impersonation. The detection of impersonation can be achieved when member "i" receives a packet on the wire seemingly coming from member "i", but not sent by "i". Digitally signing the recall packet makes sure that member "j" does not send a recall packet to disrupt communication between member "i" and the group. This scheme is based on the premise that attempts to impersonate or spoof are expected to be small in comparision of legitimate traffic, so expensive public-key cryptography of digital signatures should be used only to prevent spoofed traffic rather to authenticate the legitimate traffic. Sharma, A. Expires December 16, 2004 [Page 3] Internet-Draft Recall Packet Data Source Authentication June 2004 3.0 Strategy The scheme is: * All members have a symmetric key known to every other group member, to be used to encrypt and authenticate the packet. This key could be derived from an N-way Diffie-Hellman exchange. Alternately, a group traffic encrypting key (GTEK) could be used to encrypt the packet, and member's symmetric key to authenticate the packet. * Each member has a public-private key pair, to be used to digitally sign the recall packets. * Each member when needs to send a packet, it encrypts it with the group traffic encrypting key (GTEK), or its (may be another) symmetric key. The member concatenates its identity with the encrypted packet, and calculates the MAC over the concatenated packet with its symmetric key. Then it multicasts this packet to the group. * Each receiving member looks at the identity in the packet; uses the symmetric key associated with the identity to authenticate the attached MAC. If authenticated, it puts the packet in the wait queue for wait period, the amount of time a recall packet could be sent. After expiry of the wait period, if no recall packet on this packet is received, the packet is accepted and decrypted with GTEK or its symmetric key. * If a member "i" receives a packet seemingly coming from member "i", but not transmitted by member "i", it digitally signs with its private key the recall packet and multicasts to the group. All members on receiving a digitally signed recall packet, drop the spoofed packet received earlier. Figure 1 shows the scenario for transmission of legitimate traffic. Figure 2 depicts the situation when traffic is being spoofed by some member of the group. Sharma, A. Expires December 16, 2004 [Page 4] Internet-Draft Recall Packet Data Source Authentication June 2004 +---+ /------------>| j | / +---+ Ki / | / +------+ \/ / |Wait | +--------+ / |Queue |-->|Enc. Pkt| / +------+ +--------+ / / / +----------+------+-------+ +---+ |Encrypted |Ident.|[MAC]Ki| +---+ | i |-->|Packet |= i | |----------------->| k | +---+ +----------+------+-------+ +---+ Ki \ | \ +------+ \/ \ |Wait | +--------+ \ |Queue |-->|Enc. Pkt| \ +------+ +--------+ \ \ \ \ +---+ \------------->| l | +---+ Ki | +------+ \/ |Wait | +--------+ |Queue |-->|Enc. Pkt| +------+ +--------+ | | \/ After Wait Period | +----+ GTEK ----------->+->|Pkt | +----+ Figure 1: Scenario for Legitimate traffic Sharma, A. Expires December 16, 2004 [Page 5] Internet-Draft Recall Packet Data Source Authentication June 2004 +---+ /------------>| j | / +---+ / / +------+ \ / |Wait | +---\----+ / |Queue |-->|Enc. Pkt| / +------+ +------\-+ / DROP \ / / +-------+----------+ +---+ |Recall |Digital | +---+ | i |-->|Packet |Signature |------------------------>| k | +---+ +-------+----------+ +---+ /\ \ | \ +------+ \ | \ |Wait | +---\----+ | \ |Queue |-->|Enc. Pkt| | \ +------+ +------\-+ +----------+------+-------+ \ DROP \ |Encrypted |Ident.|[MAC]Ki| \ |Packet |= i | | \ +----------+------+-------+ \ \ +---+ \----------->| l | +---+ +------+ \ |Wait | +---\----+ |Queue |-->|Enc. Pkt| +------+ +------\-+ DROP \ Figure 2: Scenario for spoofed traffic Sharma, A. Expires December 16, 2004 [Page 6] Internet-Draft Recall Packet Data Source Authentication June 2004 4.0 Enhancements The scheme is vulnerable to packet losses. What if the recall packet gets lost? Certain form of handshake between the members and/or the central group controller can be instituted for ensuring the delivery of the recall packet. This has to be discussed with the MSEC community. The scheme is vulnerable to DoS attacks from within the group. A rogue member could continuously send impersonated packets and the whole group shall be busy dealing with recall packets. Have to come up with a strategy, short of digitally signing each packet. If we can identify the rogue member that will be a start. A scheme to identify the rogue member is solicited from the MSEC community. 5.0 Security Considerations This internet-draft focuses on one of the security issue for multicast security, as presented in [10], 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 Authors' Address Atul Sharma Nokia, Inc 5 Wayside Road Burlington, Massachusetts 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 December 16, 2004 [Page 7] Internet-Draft Recall Packet Data Source Authentication June 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Sharma, A. Expires December 16, 2004 [Page 8] Internet-Draft Recall Packet Data Source Authentication June 2004 10.0 References Normative References [1] Canetti, R., Garay, J., Itkis, G., Micciancio, D., Naor, M., Pinkas, B., "Multicast Security: A Taxonomy and Some Efficient Constructions", Infocomm 99. [2] Baugher, M., Weis, B., Hardjono, T., Harney, H., "The group Domain of Interpretation", RFC3547, July 2003. [3] Harney, H., Schuett, A., Colegrove, A., "GSAKMP Light", Internet-draft, http://www.ietf.org/internet-drafts/draft-ietf-msec- gsakmp-light-sec-01.txt. Work in Progress. [4] Wong, C.K., Lam, S.S., "Digital Signatures for Flows and Multicasts", IEEE/ACM Transactions on Networking, Vol 7., No. 4, August 1999. [5] Merkle, R. C., "A Certified Digital Signature", Advances in Cryptology- Crypto, Berlin, Springer-Verlag, LNCS 435, August 1989. [6] Gennaro, R., and Rohatgi, P., "How to Sign Digital Streams", Advances in Cryptology-Crypto, Santa Barbara, Springer-Verlag, LNCS 1294, August 1997. [7] 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. [8] Miner, S., Staddon J., "Graph-based Authentication of Digital Streams", Proc. of IEEE Symposium on Security and Privacy, Oakland, CA, May 2001. [9] 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 [10] 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. [11] Boneh, D., Durfee, G., Franklin, M., "Lower Bounds for Multicast Message Authentication", Eurocrypt 2001, Lecture Notes in Computer Science, Vol 2045, Springer-Verlag, pp 437-452 Sharma, A. Expires December 16, 2004 [Page 9]