draft-ietf-perc-double-02.txt   draft-ietf-perc-double-03.txt 
Network Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft P. Jones Internet-Draft P. Jones
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: May 4, 2017 A. Roach Expires: September 14, 2017 A. Roach
Mozilla Mozilla
October 31, 2016 March 13, 2017
SRTP Double Encryption Procedures SRTP Double Encryption Procedures
draft-ietf-perc-double-02 draft-ietf-perc-double-03
Abstract Abstract
In some conferencing scenarios, it is desirable for an intermediary In some conferencing scenarios, it is desirable for an intermediary
to be able to manipulate some RTP parameters, while still providing to be able to manipulate some RTP parameters, while still providing
strong end-to-end security guarantees. This document defines SRTP strong end-to-end security guarantees. This document defines SRTP
procedures that use two separate but related cryptographic contexts procedures that use two separate but related cryptographic contexts
to provide "hop-by-hop" and "end-to-end" security guarantees. Both to provide "hop-by-hop" and "end-to-end" security guarantees. Both
the end-to-end and hop-by-hop cryptographic transforms can utilize an the end-to-end and hop-by-hop cryptographic transforms can utilize an
authenticated encryption with associated data scheme or take authenticated encryption with associated data scheme or take
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 27 skipping to change at page 2, line 27
5.1. Encrypting a Packet . . . . . . . . . . . . . . . . . . . 5 5.1. Encrypting a Packet . . . . . . . . . . . . . . . . . . . 5
5.2. Relaying a Packet . . . . . . . . . . . . . . . . . . . . 6 5.2. Relaying a Packet . . . . . . . . . . . . . . . . . . . . 6
5.3. Decrypting a Packet . . . . . . . . . . . . . . . . . . . 7 5.3. Decrypting a Packet . . . . . . . . . . . . . . . . . . . 7
6. RTCP Operations . . . . . . . . . . . . . . . . . . . . . . . 8 6. RTCP Operations . . . . . . . . . . . . . . . . . . . . . . . 8
7. Recommended Inner and Outer Cryptographic Transforms . . . . 8 7. Recommended Inner and Outer Cryptographic Transforms . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9.1. RTP Header Extension . . . . . . . . . . . . . . . . . . 10 9.1. RTP Header Extension . . . . . . . . . . . . . . . . . . 10
9.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Cloud conferencing systems that are based on switched conferencing Cloud conferencing systems that are based on switched conferencing
have a central Media Distributor device that receives media from have a central Media Distributor device that receives media from
endpoints and distributes it to other endpoints, but does not need to endpoints and distributes it to other endpoints, but does not need to
interpret or change the media content. For these systems, it is interpret or change the media content. For these systems, it is
desirable to have one cryptographic context from the sending endpoint desirable to have one cryptographic context from the sending endpoint
to the receiving endpoint that can encrypt and authenticate the media to the receiving endpoint that can encrypt and authenticate the media
end-to-end while still allowing certain RTP header information to be end-to-end while still allowing certain RTP header information to be
changed by the Media Distributor. At the same time, a separate changed by the Media Distributor. At the same time, a separate
cryptographic context provides integrity and optional confidentiality cryptographic context provides integrity and optional confidentiality
for the media flowing between the Media Distributor and the for the media flowing between the Media Distributor and the
endpoints. See the framework document that describes this concept in endpoints. See the framework document that describes this concept in
more detail in more detail in more detail in more detail in
[I-D.jones-perc-private-media-framework]. [I-D.ietf-perc-private-media-framework].
This specification RECOMMENDS the SRTP AES-GCM transform [RFC7714] to This specification RECOMMENDS the SRTP AES-GCM transform [RFC7714] to
encrypt an RTP packet for the end-to-end cryptographic context. The encrypt an RTP packet for the end-to-end cryptographic context. The
output of this is treated as an RTP packet and again encrypted with output of this is treated as an RTP packet and again encrypted with
an SRTP transform used in the hop-by-hop cryptographic context an SRTP transform used in the hop-by-hop cryptographic context
between the endpoint and the Media Distributor. The Media between the endpoint and the Media Distributor. The Media
Distributor decrypts and checks integrity of the hop-by-hop security. Distributor decrypts and checks integrity of the hop-by-hop security.
The Media Distributor MAY change some of the RTP header information The Media Distributor MAY change some of the RTP header information
that would impact the end-to-end integrity. The original value of that would impact the end-to-end integrity. The original value of
any RTP header field that is changed is included in a new RTP header any RTP header field that is changed is included in a new RTP header
skipping to change at page 4, line 20 skipping to change at page 4, line 20
o Assign the key and salt values for the outer (hop-by-hop) o Assign the key and salt values for the outer (hop-by-hop)
transform. transform.
Obviously, if the Media Distributor is to be able to modify header Obviously, if the Media Distributor is to be able to modify header
fields but not decrypt the payload, then it must have cryptographic fields but not decrypt the payload, then it must have cryptographic
context for the outer transform, but not the inner transform. This context for the outer transform, but not the inner transform. This
document does not define how the Media Distributor should be document does not define how the Media Distributor should be
provisioned with this information. One possible way to provide provisioned with this information. One possible way to provide
keying material for the outer ("hop-by-hop") transform is to use keying material for the outer ("hop-by-hop") transform is to use
[I-D.jones-perc-dtls-tunnel]. [I-D.ietf-perc-dtls-tunnel].
4. Original Header Block 4. Original Header Block
Any SRTP packet processed following these procedures MAY contain an Any SRTP packet processed following these procedures MAY contain an
Original Header Block (OHB) RTP header extension. Original Header Block (OHB) RTP header extension.
The OHB contains the original values of any modified header fields The OHB contains the original values of any modified header fields
and MUST be placed after any already-existing RTP header extensions. and MUST be placed after any already-existing RTP header extensions.
Placement of the OHB after any original header extensions is Placement of the OHB after any original header extensions is
important so that the receiving endpoint can properly authenticate important so that the receiving endpoint can properly authenticate
skipping to change at page 4, line 48 skipping to change at page 4, line 48
The Media Distributor is only permitted to modify the extension (X) The Media Distributor is only permitted to modify the extension (X)
bit, payload type (PT) field, and the RTP sequence number field. bit, payload type (PT) field, and the RTP sequence number field.
The OHB extension is either one octet in length, two octets in The OHB extension is either one octet in length, two octets in
length, or three octets in length. The length of the OHB indicates length, or three octets in length. The length of the OHB indicates
what data is contained in the extension. what data is contained in the extension.
If the OHB is one octet in length, it contains the original PT field If the OHB is one octet in length, it contains the original PT field
value. In this case, the OHB has this form: value. In this case, the OHB has this form:
0 0 1
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+ +-+-+-+-+-+-+-+-+---------------+
|R| PT | | ID | len=0 |R| PT |
+---------------+ +-+-+-+-+-+-+-+-+---------------+
Note that "R" indicates a reserved bit that MUST be set to zero when Note that "R" indicates a reserved bit that MUST be set to zero when
sending a packet and ignored upon receipt. sending a packet and ignored upon receipt. ID is the RTP Header
Extension identifier negotiated in the SDP.
If the OHB is two octets in length, it contains the original RTP If the OHB is two octets in length, it contains the original RTP
packet sequence number. In this case, the OHB has this form: packet sequence number. In this case, the OHB has this form:
0 1 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-------------------------------+ +-+-+-+-+-+-+-+-+-------------------------------+
| Sequence Number | | ID | len=1 | Sequence Number |
+-------------------------------+ +-+-+-+-+-+-+-+-+-------------------------------+
If the OHB is three octets in length, it contains the original PT If the OHB is three octets in length, it contains the original PT
field value and RTP packet sequence number. In this case, the OHB field value and RTP packet sequence number. In this case, the OHB
has this form: has this form:
0 1 2 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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 6 4 5 6 7 8 9 1
+---------------+-------------------------------+ +-+-+-+-+-+-+-+-+---------------+-------------------------------+
|R| PT | Sequence Number | | ID | len=2 |R| PT | Sequence Number |
+---------------+-------------------------------+ +-+-+-+-+-+-+-+-+---------------+-------------------------------+
If a Media Distributor modifies an original RTP header value, the If a Media Distributor modifies an original RTP header value, the
Media Distributor MUST include the OHB extension to reflect the Media Distributor MUST include the OHB extension to reflect the
changed value, setting the X bit in the RTP header to 1 if no header changed value, setting the X bit in the RTP header to 1 if no header
extensions were originally present. If another Media Distributor extensions were originally present. If another Media Distributor
along the media path makes additional changes to the RTP header and along the media path makes additional changes to the RTP header and
any original value is already present in the OHB, the Media any original value is already present in the OHB, the Media
Distributor must extend the OHB by adding the changed value to the Distributor must extend the OHB by adding the changed value to the
OHB. To properly preserve original RTP header values, a Media OHB. To properly preserve original RTP header values, a Media
Distributor MUST NOT change a value already present in the OHB Distributor MUST NOT change a value already present in the OHB
skipping to change at page 6, line 19 skipping to change at page 6, line 21
extensions. The OHB MUST replicate the information found in the extensions. The OHB MUST replicate the information found in the
RTP header following the application of the inner cryptographic RTP header following the application of the inner cryptographic
transform. If not already set, the endpoint MUST set the X bit in transform. If not already set, the endpoint MUST set the X bit in
the RTP header to 1 when introducing the OHB extension. the RTP header to 1 when introducing the OHB extension.
o Apply the outer cryptographic transform to the RTP packet. If o Apply the outer cryptographic transform to the RTP packet. If
encrypting RTP header extensions hop-by-hop, then [RFC6904] MUST encrypting RTP header extensions hop-by-hop, then [RFC6904] MUST
be used when encrypting the RTP packet using the outer be used when encrypting the RTP packet using the outer
cryptographic context. cryptographic context.
When using EKT [I-D.ietf-perc-srtp-ekt-diet], the EKT Field comes
after the SRTP packet exactly like using EKT with any other SRTP
transform.
5.2. Relaying a Packet 5.2. Relaying a Packet
The Media Distributor does not have a notion of outer or inner The Media Distributor does not have a notion of outer or inner
cryptographic contexts. Rather, the Media Distributor has a single cryptographic contexts. Rather, the Media Distributor has a single
cryptographic context. The cryptographic transform and key used to cryptographic context. The cryptographic transform and key used to
decrypt a packet and any encrypted RTP header extensions would be the decrypt a packet and any encrypted RTP header extensions would be the
same as those used in the endpoint's outer cryptographic context. same as those used in the endpoint's outer cryptographic context.
In order to modify a packet, the Media Distributor decrypts the In order to modify a packet, the Media Distributor decrypts the
packet, modifies the packet, updates the OHB with any modifications packet, modifies the packet, updates the OHB with any modifications
skipping to change at page 11, line 37 skipping to change at page 11, line 44
auth_key_length: N/A auth_key_length: N/A
auth_tag_length: N/A auth_tag_length: N/A
maximum lifetime: at most 2^31 SRTCP packets and maximum lifetime: at most 2^31 SRTCP packets and
at most 2^48 SRTP packets at most 2^48 SRTP packets
The first half of the key and salt is used for the inner (E2E) The first half of the key and salt is used for the inner (E2E)
transform and the second half is used for the outer (HBH) transform. transform and the second half is used for the outer (HBH) transform.
10. Acknowledgments 10. Acknowledgments
Many thanks to review from Suhas Nandakumar, David Benham, Magnus Many thanks to Richard Barnes for sending significant text for this
Westerlund and significant text from Richard Barnes. specification. Thank you for reviews and improvements from David
Benham, Paul Jones, Suhas Nandakumar, Nils Ohlmeier, and Magnus
Westerlund.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<http://www.rfc-editor.org/info/rfc3711>. <http://www.rfc-editor.org/info/rfc3711>.
[RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP
Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July Header Extensions", RFC 5285, DOI 10.17487/RFC5285, July
2008, <http://www.rfc-editor.org/info/rfc5285>. 2008, <http://www.rfc-editor.org/info/rfc5285>.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, Real-time Transport Protocol (SRTP)", RFC 5764, DOI
DOI 10.17487/RFC5764, May 2010, 10.17487/RFC5764, May 2010,
<http://www.rfc-editor.org/info/rfc5764>. <http://www.rfc-editor.org/info/rfc5764>.
[RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure [RFC6904] Lennox, J., "Encryption of Header Extensions in the Secure
Real-time Transport Protocol (SRTP)", RFC 6904, Real-time Transport Protocol (SRTP)", RFC 6904, DOI
DOI 10.17487/RFC6904, April 2013, 10.17487/RFC6904, April 2013,
<http://www.rfc-editor.org/info/rfc6904>. <http://www.rfc-editor.org/info/rfc6904>.
[RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption [RFC7714] McGrew, D. and K. Igoe, "AES-GCM Authenticated Encryption
in the Secure Real-time Transport Protocol (SRTP)", in the Secure Real-time Transport Protocol (SRTP)", RFC
RFC 7714, DOI 10.17487/RFC7714, December 2015, 7714, DOI 10.17487/RFC7714, December 2015,
<http://www.rfc-editor.org/info/rfc7714>. <http://www.rfc-editor.org/info/rfc7714>.
11.2. Informative References 11.2. Informative References
[I-D.jones-perc-dtls-tunnel] [I-D.ietf-perc-dtls-tunnel]
Jones, P., "A DTLS Tunnel between Media Distributor and Jones, P., Ellenbogen, P., and N. Ohlmeier, "DTLS Tunnel
Key Distributor to Facilitate Key Exchange", draft-jones- between a Media Distributor and Key Distributor to
perc-dtls-tunnel-03 (work in progress), July 2016. Facilitate Key Exchange", March 2017.
[I-D.jones-perc-private-media-framework] [I-D.ietf-perc-private-media-framework]
Jones, P. and D. Benham, "A Solution Framework for Private Jones, P., Benham, D., and C. Groves, "A Solution
Media in Privacy Enhanced RTP Conferencing", draft-jones- Framework for Private Media in Privacy Enhanced RTP
perc-private-media-framework-02 (work in progress), March Conferencing", draft-ietf-perc-private-media-framework-02
2016. (work in progress), October 2016.
[I-D.ietf-perc-srtp-ekt-diet]
Jennings, C., Mattsson, J., McGrew, D., and D. Wing,
"Encrypted Key Transport for Secure RTP", draft-ietf-perc-
srtp-ekt-diet-02 (work in progress), October 2016.
[RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real- [RFC6465] Ivov, E., Ed., Marocco, E., Ed., and J. Lennox, "A Real-
time Transport Protocol (RTP) Header Extension for Mixer- time Transport Protocol (RTP) Header Extension for Mixer-
to-Client Audio Level Indication", RFC 6465, to-Client Audio Level Indication", RFC 6465, DOI 10.17487/
DOI 10.17487/RFC6465, December 2011, RFC6465, December 2011,
<http://www.rfc-editor.org/info/rfc6465>. <http://www.rfc-editor.org/info/rfc6465>.
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
Email: fluffy@iii.ca Email: fluffy@iii.ca
Paul E. Jones Paul E. Jones
Cisco Systems Cisco Systems
Email: paulej@packetizer.com Email: paulej@packetizer.com
Adam Roach Adam Roach
Mozilla Mozilla
Email: adam@nostrum.com Email: adam@nostrum.com
 End of changes. 23 change blocks. 
47 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/