Individual L. Dondeti Internet-Draft QUALCOMM Expires: April 26, 2006 October 23, 2005 Piggybacking Key Material with Security Encapsulated Data: Inband Key Updates draft-dondeti-msec-inband-key-updates-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 26, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract IPsec and SRTP use out-of-band key management. Synchronization of group security associations is an issue when out-of-band key management protocols are used. In case of rapid or unplanned rekeying, some members may not receive the key updates in time to decrypt the IPsec or SRTP traffic. To address that problem, this document describes a strawman proposal to carry group key updates as part of IPsec and SRTP. Dondeti Expires April 26, 2006 [Page 1] Internet-Draft Inband Key Updates October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Piggybacking key updates in encapsulated data packets . . . . . 3 3. Proposed modification to IPsec ESP encapsulation . . . . . . . 4 4. Proposed modification to SRTP encapsulation . . . . . . . . . . 6 5. Details on the GSA Update addition to the encapsulations . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 9. Informative References . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Dondeti Expires April 26, 2006 [Page 2] Internet-Draft Inband Key Updates October 2005 1. Introduction 1.1. Motivation Synchronization of group security associations (GSA) after rekeying is a difficult problem. Currently in the IETF MSEC protocols, repeated retransmission of rekey messages is suggested as a reliable transport mechanism. Other solutions such as forward error correction (FEC), feedback based mechanisms for reliable delivery of key updates are also proposed in the research literature. However, even with the use of reliable delivery mechanisms for sending group key updates, it is plausible that some members do not receive the updates in time to decrypt data packets encapsulated with the new GSA. To ensure that all members receive a GSA before it is used to encapsulate packets, it is plausible to plan SA updates so that all members receive the updates in time. However, in some rekeying scenarios, for instance in membership revocation and immediate rekeying (as opposed to say, batch rekeying), there is only a small window between delivering the new GSA and using it to protect data transmission. Members may also have been offline during a GSA update and may be forced to wait for the next update or request to receive the update via a secure unicast channel. A solution other than reliable delivery to ensure that all group members receive key updates in time is to piggyback key material on security encapsulated data packets. This is the case in 3GPP2 BCMCS specification, with an overloading of the master key identifier (MKI) field of SRTP packets. Incidentally, solutions along these lines -- MKI field reuse not withstanding -- are not uncommon: for example, SRTP-TESLA packets contain disclosed TESLA keys. Furthermore, there were some verbal proposals in the IETF MSEC WG on piggybacking key material with data packets to ensure reliable delivery of rekey messages. 2. Piggybacking key updates in encapsulated data packets We propose to include all or a portion of GSA update messages as part of encapsulated data packets as a mechanism to synchronize GSAs easily and efficiently. In the simplest case, an SA update fits within a single encapsulated packet and makes it convenient for a group member to first recover the SA update followed by decapsulating the data. More generally, the SA update is FEC encoded and pieces of the update are included with data packets so that receipt of np1 packets out of np successive packets will enable a group member to extract the GSA update required to decrypt those packets. Dondeti Expires April 26, 2006 [Page 3] Internet-Draft Inband Key Updates October 2005 The proposed solution has several use cases. In the simplest case, a small amount of data is included in every packet which when (cryptographically) combined with initial key material or SA material results in the current SA. In this case, note that the receiver can use any single encapsulated packet to recover the current SA and decapsulate the packet. In a more complex case, the sender encodes the GSA update using FEC and includes portions of the update in more than one encapsulated packet. The receiver needs only a subset of the packets containing a GSA update to recover the GSA. More formally, a receiver needs np1 packets out of np successive packets to acquire the GSA update message. It is easy to conceive use cases in between the above two examples. One immediate problem to think about is the protection afforded to the "key update" portion of the encapsulated data packets. Note that the assumption is that the data itself is protected by the new GSA, and that the key material cannot be protected with the new GSA. The key material might be protected with a combination of old and the new GSAs. Details TBD. 3. Proposed modification to IPsec ESP encapsulation Dondeti Expires April 26, 2006 [Page 4] Internet-Draft Inband Key Updates October 2005 IPsec ESP with a GSA update piggybacked: -------------------------------------------------------------------- | new IP hdr* | | orig IP hdr* | | | GSA | ESP | ESP| |(any options)| ESP | (any options) |TCP|Data| Upate | Trailer|Auth| -------------------------------------------------------------------- |<--------- encrypted ------------------->| |<----------- authenticated ------------------->| -------------------------------------------------------------------- | new* |new ext | | orig*|orig ext | | | GSA | ESP | ESP| |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Update |Trailer|Auth| -------------------------------------------------------------------- |<--------- encrypted ------------------->| |<---------- authenticated ------------------>| * = if present, construction of outer IP hdr/extensions and modification of inner IP hdr/extensions is discussed below. Figure 1: Proposed IPsec ESP modification Dondeti Expires April 26, 2006 [Page 5] Internet-Draft Inband Key Updates October 2005 4. Proposed modification to SRTP encapsulation SRTP with a GSA update piggybacked: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ |V=2|P|X| CC |M| PT | sequence number | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | timestamp | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | synchronization source (SSRC) identifier | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | contributing source (CSRC) identifiers | | | .... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | RTP extension (OPTIONAL) | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | payload ... | | | | +-------------------------------+ | | | | RTP padding | RTP pad count | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | GSA Update (OPTIONAL) | | +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ | ~ SRTP MKI (OPTIONAL) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : authentication tag (RECOMMENDED) : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +- Encrypted Portion* Authenticated Portion ---+ Figure 2: Proposed SRTP modification 5. Details on the GSA Update addition to the encapsulations This version of the document is short on details. But, in short, the GSA update might contain a identity payload (say 16 bits in length) for various different uses of the field. The new payload might contain a full GSA update or an FEC block of a GSA update. The new field needs integrity protection and typically encrypted independent of the encapsulated data packet. 6. Acknowledgments Dondeti Expires April 26, 2006 [Page 6] Internet-Draft Inband Key Updates October 2005 SRTP MKI overloading in 3GPP2 BCMCS specification was pointed out to me by Raymond Hsu, AC Mahendran, Jun Wang and others in QUALCOMM. 7. Security Considerations TBD. Integrity protection and encryption of key update payloads included in encapsulated data packets is tricky. 8. IANA Considerations 9. Informative References [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003. Dondeti Expires April 26, 2006 [Page 7] Internet-Draft Inband Key Updates October 2005 Author's Address Lakshminath Dondeti QUALCOMM 5775 Morehouse Dr. San Diego, CA 92121 USA Phone: +1 858-845-1267 Email: ldondeti@qualcomm.com Dondeti Expires April 26, 2006 [Page 8] Internet-Draft Inband Key Updates October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Dondeti Expires April 26, 2006 [Page 9]