Secure Objects for Media over QUIC
draft-jennings-moq-secure-objects-00
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Cullen Fluffy Jennings , Suhas Nandakumar | ||
| Last updated | 2024-03-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jennings-moq-secure-objects-00
Network Working Group C. Jennings
Internet-Draft S. Nandakumar
Intended status: Standards Track Cisco
Expires: 5 September 2024 4 March 2024
Secure Objects for Media over QUIC
draft-jennings-moq-secure-objects-00
Abstract
This document describes end-to-end encryption and authentication
mechanism for application objects intended to be delivered over Media
over QUIC Transport (MOQT).
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://suhashere.github.io/moq-secure-objects/#go.draft-jennings-
moq-secure-objects.html. Status information for this document may be
found at https://datatracker.ietf.org/doc/draft-jennings-moq-secure-
objects/.
Discussion of this document takes place on the Media over QUIC
Working Group mailing list (mailto:moq@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/moq/. Subscribe at
https://www.ietf.org/mailman/listinfo/moq/.
Source for this draft and an issue tracker can be found at
https://github.com/suhasHere/moq-secure-objects.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on 5 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction
2. Terminology
3. MOQT Object Model Recap
4. Secure Object
5. Keys, Salts, and Nonces
5.1. Key Derivation
5.2. Nonce Creation
5.3. Additional Authenticated Data
6. Encryption
7. Decryption
8. Security Considerations
9. IANA Considerations
9.1. SecObj Cipher Suites
10. Normative References
Appendix A. Acknowledgements
Authors' Addresses
1. Introduction
Media Over QUIC Transport (MOQT) is a protocol that is optimized for
the QUIC protocol, either directly or via WebTransport, for the
dissemination of delivery of low latency media. MOQT defines a
publish/subscribe media delivery layer across set of participating
relays for supporting wide range of use-cases with different
resiliency and latency (live, interactive) needs without compromising
the scalability and cost effectiveness associated with content
delivery networks. It supports sending media objects through sets of
relays nodes.
Typically a MOQ Relay doesn't need to access the media content, thus
allowing for the media to be "end-to-end" encrypted so that it cannot
be decrypted by the relays. However for the relays to participate
effectively in the media delivery, it needs to able to access naming
information of a MOQT object to carryout the required store and
forward functions.
As such, two layers of encryption and authentication are required:
* Hop-by-hop (HBH) encryption achieved through QUIC connection per
hop and
* End-to-end (E2E) encryption (E2EE) of media between the endpoints.
The HBH security is provided by TLS in the QUIC connection that MoQT
runs over. MoQT support different E2EE protection as well as
allowing for E2EE security.
A goal of the design is to minimize the amount of additional data the
encryptions requires for each object. This is particularly important
for very low bit rate audio applications where the encryption
overhead can become a significant portion of the total bandwidth.
This document defines an E2EE protection scheme known as Secure
Object.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
IV: Initialization Vector
MAC: Message Authentication Code
E2EE: End to End Encryption
HBH: Hop By Hop
Producer: Software that creates and encrypts MoQ Objects.
Consumer: Software that decrypts MoQ Objects.
3. MOQT Object Model Recap
MOQT defines a publish/subscribe based media delivery protocol, where
in endpoints, called producers, publish objects which are delivered
via participating relays to receiving endpoints, called consumers.
Section 2 of MoQ Transport defines hierarchical object model for
application data, comprised of objects, groups and tracks.
Objects defines the basic data element, an addressable unit whose
payload is sequence of bytes. All objects belong to a group,
indicating ordering and potential dependencies. A track contains a
sequence of groups and serves as the entity against which a consumer
issues a subscription request.
Media Over QUIC Application
| time
|
TrackA +-+---------+-----+---------+--------------+---------+---->
| | Group1 | | Group2 | . . . . . . | GroupN |
| +----+----+ +----+----+ +---------+
| | |
| | |
| +----+----+ +----+----+
| | Object0 | | Object0 |
| +---------+ +---------+
| | Object1 | | Object1 |
| +---------+ +---------+
| | Object2 | | Object2 |
| +---------+ +---------+
| .
| .
| .
| +---------+
| | ObjectN |
| +---------+
|
|
|
| time
|
TrackB +-+---------+-----+---------+--------------+---------+---->
| | Group1 | | Group2 | . . .. .. .. | GroupN |
| +---+-----+ +----+----+ +----+----+
| | | |
| | | |
|+----+----+ +----+----+ +----+----+
|| Object0 | | Object0 | | Object0 |
|+---------+ +---------+ +---------+
|
v
Objects are comprised of two parts: envelope and a payload. The
envelope is never end to end encrypted and is always visible to
relays. The payload portion may be end to end encrypted, in which
case it is only visible to the producer and consumer. The
application is solely responsible for the content of the object
payload.
Tracks are identified by a combination of its TrackNamespace and
TrackName. TrackNamespace and TrackName are treated as a sequence of
binary bytes. Group and Objects are represented as variable length
integers called GroupId and ObjectId respectively.
For purposes of this specification, we define FullTrackName as :
FullTrackName = TrackNamespace | TrackName
where '|' representations concatenation of byte strings,
and ObjectName is combination of following properties:
ObjectName = (FullTrackName, GroupId, ObjectId)
Two important properties of objects are:
1. ObjectNames are globally unique in a given relay network.
2. The data inside an object ( and it's size) can never change after
the object is first published. There can never be two objects
with the same name but different data.
One of the ways system keep the object names unique is by using a
fully qualified domain names or UUIDs as part of the TrackNamespace.
4. Secure Object
This document defines an protection mechanism, called Secure
Object(SecObj), that provides effective E2EE protection with a
minimal encryption bandwidth overhead.
SecObj encryption uses an AEAD function [RFC5116] defined by the
cipher suite in use (see Section 9.1).
We will refer to the following aspects of the AEAD algorithm below:
AEAD.Encrypt and AEAD.Decrypt - The encryption and decryption
functions for the AEAD.
AEAD_KEY_SIZE: The size in bytes of a key for the encryption
algorithm
AEAD_NONCE_SIZE: The size in bytes of a nonce for the encryption
algorithm
AEAD_TAG_SIZE: The overhead in bytes of the encryption algorithm
(typically the size of a "tag" that is added to the plaintext)
An SecObj cipher text comprises an header, followed by output of an
AEAD encryption of the plaintext [RFC5116] corresponding to the MOQT
Object. The header consists of a variable length encoded integer
called KID.
5. Keys, Salts, and Nonces
When encrypting objects within a MOQT Track, there is one secret
called track_base_key per FullTrackName on which is premised the
encryption or decryption operations for the objects within that
track.
In MoQ, for some use cases, like streaming a video clip, all the
objects in a track will often be encrypted with the same base key for
that track. However in other uses cases, like a conference call, the
keys may change as the participants of the conference come and go.
For this type of scenario, different object in the same track will
end up being protected with different base keys. Each encrypted
object also carries an unencrypted "Key Identifier (KID)" which is a
small integer that identifies, within the scope of this track, the
base key being used to encrypt the object. The actual keys for each
KID and FullTrackName are exchanged between the devices encrypting
and decrypting in ways that are out of scope of this specification.
The producers and consumers need to agree on which key should be used
for a given KID and the purpose of the key, encryption or decryption
only. A given key MUST NOT be used for encryption by multiple
senders unless it can be ensured that nonce isn't reused. Sine such
reuse would result in multiple encrypted objects being generated with
the same (key, nonce) pair, which harms the protections provided by
many AEAD algorithms. MoQ does not allow two different objects to
have the same FullObjectName, so the way the nonce is generated ( see
section Section 5.2 ) protects against nonce reuse. Implementations
SHOULD mark each key as usable for encryption or decryption.
5.1. Key Derivation
Secobj encryption and decryption use a key and salt derived from the
track_base_key associated to a KID. Given a track_base_key value for
a FullTrackName the key and salt are derived using HKDF [RFC5869] as
follows:
secobj_label = "SecObj 1.0"
secobj_secret = HKDF-Extract(secobj_label, track_base_key)
secobj_key_label = "SecObj 1.0 Secret key" | KID | cipher_suite | FullTrackName
secobj_key = HKDF-Expand(secobj_secret, secobj_key_label, AEAD_KEY_SIZE)
secobj_salt_label = "SecObj 1.0 Secret salt" | KID | cipher_suite
secobj_salt = HKDF-Expand(secobj_secret, secobj_salt_label, AEAD_NONCE_SIZE)
In the above derivation :
* The | operator represents concatenation of byte strings.
* The cipher_suite value is a 16 bit big-endian integer representing
the cipher suite in use (see cipher-suites).
* The KID is a 64 bit big-endian integer.
The hash function used for HKDF is determined by the cipher suite in
use.
5.2. Nonce Creation
The Nonce is formed by XORing the secobj_salt Section 5.1 with bits
from the concatenating the GroupId and ObjectId, where both the
GroupId and ObjectId are treated as 48 bit big-endian integer. Both
the ObjectID and GroupID MUST be less than 2^48-1. The N_MIN from
the AEAD cipher MUST be at least 12 to have space for the object and
group IDs to fit in the nonce. Note that the size of the nonce is
defined by the underlying AEAD algorithm in use but for the algorithm
referenced here, it is 12 octets.
5.3. Additional Authenticated Data
The additional authenticated data (AAD) is formed by concatinating
the KID, GroupID, and ObjectID where each of these is encoded as a
big-endian 64 bit integer.
6. Encryption
The key for encrypting MOQT objects from a given track is the
secobj_key derived from the track_base_key Section 5.1 corresponding
to the track.
The payload field from the MOQT object is used by the AEAD algorithm
for the plaintext.
The encryptor forms an SecObj header using the KID value provided.
The encryption procedure is as follows:
1. From the MOQT Object obtain MOQT object payload as the plaintext
to encrypt. Get the GroupId and ObjectId from the MOQT object
envelope.
2. Retrieve the secobj_key and secobj_salt matching the KID.
3. Form the nonce by as described in Section 5.2.
4. Form the aad input as described in Section 5.3.
5. Apply the AEAD encryption function with secobj_key, nonce, aad
and ciphertext as inputs.
The final SecureObject is formed from the MOQT transport headers,
then the KID encdoded as QUIC variale length integer[RFC9000],
followed by the output of the encryption
+-----------------+------------------+-----------------+
| MOQT Object | SecObj Header | SecObj |
| Header | (KID) | Ciphertext |
+-----------------+------------------+-----------------+
Below figure depicts the encryption process described
+----------------+
| |
+-------------------------| MOQT |
| +------| Object |
| | | |
| | +--------+-------+
| | |
| | |
| | |
| | |
| | FullTrackName |
+----------------+ | (from |
| GroupId | | track_alias) |
+----------------+ | |
| Object ID | | |
+----------------+ | |
| | +------------+ |
|<-------|----------- | KID | | Object
| |<------------| | | Payload
| | +------------+ |
| | secobj_salt | |
| | | |
| | | |
| v | secobj_key |
| +-----------+ | |
| | NONCE | | |
| +-----------+ | |
| | | |
| | v |
| | +--------------+ |
| | | | |
| +---------->| AEAD.Encrypt |<------+
+------------------->| |
AAD +-------+------+
|
|
v
+--------------+
| KID |
+--------------+
| |
| CipherText |
| |
+--------------+
SecObj CipherText
Figure 1: Encrypting a MOQT Object Ciphertext
7. Decryption
For decrypting, the KID field in the received data is used to find
the right key and salt for the encrypted object, and the nonce field
is obtained from the GroupId and ObjectId fields of the MOQT object
envelope.
The decryption procedure is as follows:
1. Parse the SecureObject to obtain KID, the ciphertext
corresponding to MOQT object payload and the GroupID and ObjectId
from the MOQT object envelope.
2. Retrieve the secobj_key and secobj_salt matching the KID.
3. Form the nonce by as described in Section 5.2.
4. Form the aad input as described in Section 5.3.
5. Apply the AEAD decryption function with secobj_key, nonce, aad
and ciphertext as inputs.
If a ciphertext fails to decrypt because there is no key available
for the KID in the SecObj header, the client MAY buffer the
ciphertext and retry decryption once a key with that KID is received.
If a ciphertext fails to decrypt for any other reason, the client
MUST discard the ciphertext. Invalid ciphertext SHOULD be discarded
in a way that is indistinguishable (to an external observer) from
having processed a valid ciphertext.
Below figure depicts the decryption process:
SecObj CipherText
+--------------+
+-----------------------------------| KID |
| +--------------+
| | |
| +------------------------| CipherText |
| | +-----| |
| | | +--------------+
| | | |
| | | |
| | | |
| | | |
| | | |
| v | |
| +----------------+ | KID |
| | GroupId | | |
| +----------------+ | |
| | Object ID | | |
| +----------------+ | |
| | | v |
| | | +------------+ |
| | |<--------------| KeyStore | | ciphertext
| | | +------------+ |
| | | secobj_salt | |
| | | | |
| | | | |
| | v | secobj_key |
| | +-----------+ | |
| | | NONCE | | |
| | +-----------+ | |
| | | | |
| | | v |
| | | +--------------+ |
| | | | | |
| | +------------>| AEAD.Decrypt |<------+
| +------------------->| |
| ^ AAD | |
| | +-------+------+
+----------+ |
|
|
v
+----------------+
| |
| MOQ |
| Object |
| |
+----------------+
Figure 2: Decrypting an MOQT Object Ciphertext
8. Security Considerations
TODO
9. IANA Considerations
9.1. SecObj Cipher Suites
This registry lists identifiers for SecObj cipher suites, as defined
in cipher-suites. The cipher suite field is two bytes wide, so the
valid cipher suites are in the range 0x0000 to 0xFFFF. Values less
that 128 are allocated by "IESG Approval" (ref rfc8126) while others
values are "First Come First Served".
Template:
* Value: The numeric value of the cipher suite
* Name: The name of the cipher suite
* Tag Length: Length of tag in bits
* Usage: Optional, Recommended, or Prohibited
* Reference: The document where this wire format is defined
Initial contents:
+========+========================+=====+=============+===========+
| Value | Name | Tag | Usage | Reference |
+========+========================+=====+=============+===========+
| 0x0001 | AES_128_GCM_SHA256_128 | 128 | Recommended | RFC XXXX |
+--------+------------------------+-----+-------------+-----------+
| 0x0002 | AES_256_GCM_SHA512_128 | 128 | Optional | RFC XXXX |
+--------+------------------------+-----+-------------+-----------+
Table 1: SecObj cipher suites
10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/rfc/rfc5116>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/rfc/rfc5869>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
Appendix A. Acknowledgements
TODO
Authors' Addresses
Cullen Jennings
Cisco
Email: fluffy@cisco.com
Suhas Nandakumar
Cisco
Email: snandaku@cisco.com