Internet DRAFT - draft-dondeti-msec-inband-key-updates
draft-dondeti-msec-inband-key-updates
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]
