Individual L. Dondeti Internet-Draft QUALCOMM Expires: January 12, 2006 July 11, 2005 Piggybacking Key Material with Security Encapsulated Data: Inband Key Updates draft-dondeti-msec-inband-key-updates-00 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 January 12, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract IPsec and SRTP use out-of-band key management. Consequently, synchronization of group security association after rekeying is an issue. Several reliable SA update mechanisms have been proposed in the research literature -- none of them are perfect and none of them have been standardized. This document describes a strawman proposal to carry group key updates as part of IPsec and SRTP. Dondeti Expires January 12, 2006 [Page 1] Internet-Draft Inband Key Updates July 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 . . . . . . . . . 5 5. Details on the GSA Update addition to the encapsulations . . . 5 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. Informative References . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . 7 Dondeti Expires January 12, 2006 [Page 2] Internet-Draft Inband Key Updates July 2005 1. Introduction 1.1 Motivation Synchronization of group security associations (GSA) after rekeying is a difficult problem. Currently in 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, it is still plausible for some group members to not receive key updates in time to decrypt (some) data packets encapsulated with a new SA. 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 several rekeying scenarios -- membership revocation and immediate rekeying (as opposed to say, batch rekeying) is one such example. Another solution that is being used to ensure that all members receive key updates in time is to piggyback key material on encapsulated data packets (this is the case in 3GPP2 BCMCS specification, with an overloading of the MKI field of SRTP packets). Incidentally, solutions along these lines -- MKI field reuse not withstanding -- are not uncommon: SRTP-TESLA packets contain disclosed TESLA keys. Furthermore, there were some verbal proposals in the 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. In the simplest case, an SA update easily fits within a single encapsulated packet and makes it easy for a group member to first recover the SA update followed by decapsulating the data. 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. It is easy to conceive use cases in Dondeti Expires January 12, 2006 [Page 3] Internet-Draft Inband Key Updates July 2005 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 integrity protected with the combination of old and the new GSAs, or simpler yet, afforded protection using asymmetric key. 3. Proposed modification to IPsec ESP encapsulation 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 January 12, 2006 [Page 4] Internet-Draft Inband Key Updates July 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 SRTP MKI overloading in 3GPP2 BCMCS specification was pointed out to Dondeti Expires January 12, 2006 [Page 5] Internet-Draft Inband Key Updates July 2005 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 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. 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 January 12, 2006 [Page 6] Internet-Draft Inband Key Updates July 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 January 12, 2006 [Page 7]