diff --git a/artart-iana/draft-ietf-sframe-enc.html b/artart-iana/draft-ietf-sframe-enc.html deleted file mode 100644 index f133ff3..0000000 --- a/artart-iana/draft-ietf-sframe-enc.html +++ /dev/null @@ -1,6285 +0,0 @@ - - - - - - -Secure Frame (SFrame) - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Internet-DraftSFrameFebruary 2024
Omara, et al.Expires 17 August 2024[Page]
-
-
-
-
Workgroup:
-
Network Working Group
-
Internet-Draft:
-
draft-ietf-sframe-enc-latest
-
Published:
-
- -
-
Intended Status:
-
Standards Track
-
Expires:
-
-
Authors:
-
-
-
E. Omara
-
Apple
-
-
-
J. Uberti
-
Google
-
-
-
S. Murillo
-
CoSMo Software
-
-
-
R. L. Barnes, Ed. -
-
Cisco
-
-
-
Y. Fablet
-
Apple
-
-
-
-
-

Secure Frame (SFrame)

-
-

Abstract

-

This document describes the Secure Frame (SFrame) end-to-end encryption and -authentication mechanism for media frames in a multiparty conference call, in -which central media servers (selective forwarding units or SFUs) can access the -media metadata needed to make forwarding decisions without having access to the -actual media.

-

The proposed mechanism differs from the Secure Real-Time Protocol (SRTP) in that -it is independent of RTP (thus compatible with non-RTP media transport) and can -be applied to whole media frames in order to be more bandwidth efficient.

-
-
-

-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://sframe-wg.github.io/sframe/draft-ietf-sframe-enc.html. - Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-sframe-enc/.

-

- Discussion of this document takes place on the - Secure Media Frames Working Group mailing list (mailto:sframe@ietf.org), - which is archived at https://mailarchive.ietf.org/arch/browse/sframe/. - Subscribe at https://www.ietf.org/mailman/listinfo/sframe/.

-

Source for this draft and an issue tracker can be found at - https://github.com/sframe-wg/sframe.

-
-
-
-

-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 17 August 2024.

-
-
- -
-
- ▲

-Table of Contents -

- -
-
-
-
-

-1. Introduction -

-

Modern multi-party video call systems use Selective Forwarding Unit (SFU) -servers to efficiently route media streams to call endpoints based on factors such -as available bandwidth, desired video size, codec support, and other factors. An -SFU typically does not need access to the media content of the conference, -allowing for the media to be "end-to-end" encrypted so that it cannot be -decrypted by the SFU. In order for the SFU to work properly, though, it usually -needs to be able to access RTP metadata and RTCP feedback messages, which is not -possible if all RTP/RTCP traffic is end-to-end encrypted.

-

As such, two layers of encryption and authentication are required:

-
    -
  1. -

    Hop-by-hop (HBH) encryption of media, metadata, and feedback messages -between the the endpoints and SFU

    -
    2. -
  2. -

    End-to-end (E2E) encryption (E2EE) of media between the endpoints

    -
    3. -
-

The Secure Real-Time Protocol (SRTP) is already widely used for HBH encryption -[RFC3711]. The SRTP "double encryption" scheme defines a way to do E2E -encryption in SRTP [RFC8723]. Unfortunately, this scheme has poor efficiency -and high complexity, and its entanglement with RTP makes it unworkable in -several realistic SFU scenarios.

-

This document proposes a new E2EE protection scheme known as SFrame, -specifically designed to work in group conference calls with SFUs. SFrame is a -general encryption framing that can be used to protect media payloads, agnostic -of transport.

-
-
-
-
-

-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.

-
-
MAC:
-
-

Message Authentication Code

-
-
-
E2EE:
-
-

End to End Encryption

-
-
-
HBH:
-
-

Hop By Hop

-
-
-
-

We use "Selective Forwarding Unit (SFU)" and "media stream" in a less formal sense -than in [RFC7656]. An SFU is a selective switching function for media -payloads, and a media stream a sequence of media payloads, in both cases -regardless of whether those media payloads are transported over RTP or some -other protocol.

-
-
-
-
-

-3. Goals -

-

SFrame is designed to be a suitable E2EE protection scheme for conference call -media in a broad range of scenarios, as outlined by the following goals:

-
    -
  1. -

    Provide a secure E2EE mechanism for audio and video in conference calls -that can be used with arbitrary SFU servers.

    -
    2. -
  2. -

    Decouple media encryption from key management to allow SFrame to be used -with an arbitrary key management system.

    -
    3. -
  3. -

    Minimize packet expansion to allow successful conferencing in as many -network conditions as possible.

    -
    4. -
  4. -

    Independence from the underlying transport, including use in non-RTP -transports, e.g., WebTransport [I-D.ietf-webtrans-overview].

    -
    5. -
  5. -

    When used with RTP and its associated error resilience mechanisms, i.e., RTX -and FEC, require no special handling for RTX and FEC packets.

    -
    6. -
  6. -

    Minimize the changes needed in SFU servers.

    -
    7. -
  7. -

    Minimize the changes needed in endpoints.

    -
    8. -
  8. -

    Work with the most popular audio and video codecs used in conferencing -scenarios.

    -
    9. -
-
-
-
-
-

-4. SFrame -

-

This document defines an encryption mechanism that provides effective E2EE, -is simple to implement, has no dependencies on RTP, and minimizes -encryption bandwidth overhead. This section describes how the mechanism -works, including details of how applications utilize SFrame for media protection, -as well as the actual mechanics of E2EE for protecting media.

-
-
-

-4.1. Application Context -

-

SFrame is a general encryption framing, intended to be used as an E2EE -layer over an underlying HBH-encrypted transport such as SRTP or QUIC -[RFC3711][I-D.ietf-moq-transport].

-

The scale at which SFrame encryption is applied to media determines the overall -amount of overhead that SFrame adds to the media stream, as well as the -engineering complexity involved in integrating SFrame into a particular -environment. Two patterns are common: Either using SFrame to encrypt whole -media frames (per-frame) or individual transport-level media payloads -(per-packet).

-

For example, Figure 1 shows a typical media sender stack that takes media -from some source, encodes it into frames, divides those frames into media -packets, and then sends those payloads in SRTP packets. The receiver stack -performs the reverse operations, reassembling frames from SRTP packets and -decoding. Arrows indicate two different ways that SFrame protection could be -integrated into this media stack, to encrypt whole frames or individual media -packets.

-

Applying SFrame per-frame in this system offers higher efficiency, but may -require a more complex integration in environments where depacketization relies -on the content of media packets. Applying SFrame per-packet avoids this -complexity, at the cost of higher bandwidth consumption. Some quantitative -discussion of these trade-offs is provided in Appendix C.

-

As noted above, however, SFrame is a general media encapsulation, and can be -applied in other scenarios. The important thing is that the sender and -receivers of an SFrame-encrypted object agree on that object's semantics. -SFrame does not provide this agreement; it must be arranged by the application.

-
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - HBH - Encode - Packetize - Protect - SFrame - SFrame - Protect - Protect - Alice - (per-frame) - (per-packet) - E2E - Key - HBH - Key - Media - Management - Management - Server - SFrame - SFrame - Unprotect - Unprotect - (per-frame) - (per-packet) - HBH - Decode - Depacketize - Unprotect - Bob - - -
-
-
Figure 1
-
-

Like SRTP, SFrame does not define how the keys used for SFrame are exchanged by -the parties in the conference. Keys for SFrame might be distributed over an -existing E2E-secure channel (see Section 5.1), or derived from an E2E-secure -shared secret (see Section 5.2). The key management system MUST ensure that each -key used for encrypting media is used by exactly one media sender, in order to -avoid reuse of nonces.

-
-
-
-
-

-4.2. SFrame Ciphertext -

-

An SFrame ciphertext comprises an SFrame header followed by the output of an -AEAD encryption of the plaintext [RFC5116], with the header provided as additional -authenticated data (AAD).

-

The SFrame header is a variable-length structure described in detail in -Section 4.3. The structure of the encrypted data and authentication tag -are determined by the AEAD algorithm in use.

-
-
- - - - - - - - - - - - - - - - - - - - - - K - KLEN - C - CLEN - Key - ID - Counter - Encrypted - Data - Authentication - Tag - Encrypted - Portion - Authenticated - Portion - - -
-
-

When SFrame is applied per-packet, the payload of each packet will be an SFrame -ciphertext. When SFrame is applied per-frame, the SFrame ciphertext -representing an encrypted frame will span several packets, with the header -appearing in the first packet and the authentication tag in the last packet. -It is the responsibility of the application to reassemble an encrypted frame from -individual packets, accounting for packet loss and reordering as necessary.

-
-
-
-
-

-4.3. SFrame Header -

-

The SFrame header specifies two values from which encryption parameters are -derived:

-
    -
  • -

    A Key ID (KID) that determines which encryption key should be used

    -
    • -
  • -

    A counter (CTR) that is used to construct the nonce for the encryption

    -
    • -
-

Applications MUST ensure that each (KID, CTR) combination is used for exactly -one SFrame encryption operation. A typical approach to achieving this guarantee is -outlined in Section 9.1.

-
-
-
-
- - - - - - - - - - - - - - - - - - Config - Byte - 0 - 1 - 2 - 3 - 4 - 5 - 6 - 7 - X - K - Y - C - KID... - CTR... - - -
-
-
Figure 2: -SFrame header -
-
-

The SFrame Header has the overall structure shown in Figure 2. The -first byte is a "config byte", with the following fields:

-
-
Extended Key Id Flag (X, 1 bit):
-
-

Indicates if the K field contains the key id or the Key ID length.

-
-
-
Key or Key Length (K, 3 bits):
-
-

This field contains the Key ID (KID) if the X flag is set to 0, or the key id -length, minus one, if set to 1.

-
-
-
Extended Counter Flag (Y, 1 bit):
-
-

Indicates if the C field contains the counter or the counter length.

-
-
-
Counter or Counter Length (C, 3 bits):
-
-

This field contains the counter (CTR) if the Y flag is set to 0, or the counter -length, minus one, if set to 1.

-
-
-
-

The Key ID and Counter fields are encoded as compact unsigned integers in -network (big-endian) byte order. If the value of one of these fields is in the -range 0-7, then the value is carried in the corresponding bits of the config -byte (K or C) and the corresponding flag (X or Y) is set to zero. Otherwise, -the value MUST be encoded with the minimum number of bytes required and -appended after the configuration byte, with the Key ID first and Counter second. -The header field (K or C) is set to the number of bytes in the encoded value, -minus one. The value 000 represents a length of 1, 001 a length of 2, etc. -This allows a 3-bit length field to represent the value lengths 1-8.

-

The SFrame header can thus take one of the four forms shown in -Figure 3, depending on which of the X and Y flags are set.

-
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - KID - < - 8, - CTR - < - 8: - 0 - KID - 0 - CTR - KID - < - 8, - CTR - >= - 8: - 0 - KID - 1 - CLEN - CTR... - (length=CLEN) - KID - >= - 8 - CTR - < - 8: - 1 - KLEN - 0 - CTR - KID... - (length=KLEN) - KID - >= - 8 - CTR - >= - 8: - 1 - KLEN - 1 - CLEN - KID... - (length=KLEN) - CTR... - (length=CLEN) - - -
-
-
Figure 3: -Forms of Encoded SFrame Header -
-
-
-
-
-
-

-4.4. Encryption Schema -

-

SFrame encryption uses an AEAD encryption algorithm and hash function defined by -the cipher suite in use (see Section 4.5). We will refer to the following -aspects of the AEAD and the hash algorithm below:

-
    -
  • -

    AEAD.Encrypt and AEAD.Decrypt - The encryption and decryption functions -for the AEAD. We follow the convention of RFC 5116 [RFC5116] and consider -the authentication tag part of the ciphertext produced by AEAD.Encrypt (as -opposed to a separate field as in SRTP [RFC3711]).

    -
    • -
  • -

    AEAD.Nk - The size in bytes of a key for the encryption algorithm

    -
    • -
  • -

    AEAD.Nn - The size in bytes of a nonce for the encryption algorithm

    -
    • -
  • -

    AEAD.Nt - The overhead in bytes of the encryption algorithm (typically the -size of a "tag" that is added to the plaintext)

    -
    • -
  • -

    AEAD.Nka - For cipher suites using the compound AEAD described in -Section 4.5.1, the size in bytes of a key for the underlying AES-CTR -algorithm

    -
    • -
  • -

    Hash.Nh - The size in bytes of the output of the hash function

    -
    • -
-
-
-

-4.4.1. Key Selection -

-

Each SFrame encryption or decryption operation is premised on a single secret -base_key, which is labeled with an integer KID value signaled in the SFrame -header.

-

The sender and receivers need to agree on which key should be used for a given -KID. Moreover, senders and receivers need to agree on whether keys will be used -for encryption or decryption only. The process for provisioning keys and their KID -values is beyond the scope of this specification, but its security properties will -bound the assurances that SFrame provides. For example, if SFrame is used to -provide E2E security against intermediary media nodes, then SFrame keys need to -be negotiated in a way that does not make them accessible to these intermediaries.

-

For each known KID value, the client stores the corresponding symmetric key -base_key. For keys that can be used for encryption, the client also stores -the next counter value CTR to be used when encrypting (initially 0).

-

When encrypting a plaintext, the application specifies which KID is to be used, -and the counter is incremented after successful encryption. When decrypting, -the base_key for decryption is selected from the available keys using the KID -value in the SFrame Header.

-

A given key MUST NOT be used for encryption by multiple senders. Such reuse -would result in multiple encrypted frames being generated with the same (key, -nonce) pair, which harms the protections provided by many AEAD algorithms. -Implementations SHOULD mark each key as usable for encryption or decryption, -never both.

-

Note that the set of available keys might change over the lifetime of a -real-time session. In such cases, the client will need to manage key usage to -avoid media loss due to a key being used to encrypt before all receivers are -able to use it to decrypt. For example, an application may make decryption-only -keys available immediately, but delay the use of keys for encryption until (a) -all receivers have acknowledged receipt of the new key or (b) a timeout expires.

-
-
-
-
-

-4.4.2. Key Derivation -

-

SFrame encrytion and decryption use a key and salt derived from the base_key -associated to a KID. Given a base_key value, the key and salt are derived -using HKDF [RFC5869] as follows:

-
-
-def derive_key_salt(KID, base_key):
-  sframe_secret = HKDF-Extract("", base_key)
-
-  sframe_key_label = "SFrame 1.0 Secret key " + KID + cipher_suite
-  sframe_key = HKDF-Expand(sframe_secret, info, AEAD.Nk)
-
-  sframe_salt_label = "SFrame 1.0 Secret salt " + KID + cipher_suite
-  sframe_salt = HKDF-Expand(sframe_secret, info, AEAD.Nn)
-
-  return sframe_key, sframe_salt
-
-
-

In the derivation of sframe_secret:

-
    -
  • -

    The + operator represents concatenation of byte strings.

    -
    • -
  • -

    The KID value is encoded as an 8-byte big-endian integer, not the compressed -form used in the SFrame header.

    -
    • -
  • -

    The cipher_suite value is a 2-byte big-endian integer representing the -cipher suite in use (see Section 8.1).

    -
    • -
-

The hash function used for HKDF is determined by the cipher suite in use.

-
-
-
-
-

-4.4.3. Encryption -

-

SFrame encryption uses the AEAD encryption algorithm for the cipher suite in use. -The key for the encryption is the sframe_key and the nonce is formed by XORing -the sframe_salt with the current counter, encoded as a big-endian integer of -length AEAD.Nn.

-

The encryptor forms an SFrame header using the CTR, and KID values provided. -The encoded header is provided as AAD to the AEAD encryption operation, together -with application-provided metadata about the encrypted media (see Section 9.4).

-
-
-def encrypt(CTR, KID, metadata, plaintext):
-  sframe_key, sframe_salt = key_store[KID]
-
-  ctr = encode_big_endian(CTR, AEAD.Nn)
-  nonce = xor(sframe_salt, CTR)
-
-  header = encode_sframe_header(CTR, KID)
-  aad = header + metadata
-
-  ciphertext = AEAD.Encrypt(sframe_key, nonce, aad, plaintext)
-  return header + ciphertext
-
-
-

For example, the metadata input to encryption allows for frame metadata to be -authenticated when SFrame is applied per-frame. After encoding the frame and -before packetizing it, the necessary media metadata will be moved out of the -encoded frame buffer, to be sent in some channel visible to the SFU (e.g., an -RTP header extension).

-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - plaintext - sframe_key - Key - Header - KID - sframe_salt - Nonce - CTR - metadata - AAD - AEAD.Encrypt - SFrame - Ciphertext - SFrame - Header - ciphertext - - -
-
-
Figure 4: -Encrypting an SFrame Ciphertext -
-
-
-
-
-

-4.4.4. Decryption -

-

Before decrypting, a receiver needs to assemble a full SFrame ciphertext. When -an SFrame ciphertext may be fragmented into multiple parts for transport (e.g., -a whole encrypted frame sent in multiple SRTP packets), the receiving client -collects all the fragments of the ciphertext, using an appropriate sequencing -and start/end markers in the transport. Once all of the required fragments are -available, the client reassembles them into the SFrame ciphertext, then passes -the ciphertext to SFrame for decryption.

-

The KID field in the SFrame header is used to find the right key and salt for -the encrypted frame, and the CTR field is used to construct the nonce. The SFrame -decryption procedure is as follows:

-
-
-def decrypt(metadata, sframe_ciphertext):
-  KID, CTR, header, ciphertext = parse_ciphertext(sframe_ciphertext)
-
-  sframe_key, sframe_salt = key_store[KID]
-
-  ctr = encode_big_endian(CTR, AEAD.Nn)
-  nonce = xor(sframe_salt, ctr)
-  aad = header + metadata
-
-  return AEAD.Decrypt(sframe_key, nonce, aad, ciphertext)
-
-
-

If a ciphertext fails to decrypt because there is no key available for the KID -in the SFrame 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 ciphertexts SHOULD be -discarded in a way that is indistinguishable (to an external observer) from having -processed a valid ciphertext.

-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - SFrame - Ciphertext - SFrame - Header - ciphertext - sframe_key - Key - KID - sframe_salt - Nonce - CTR - metadata - AAD - AEAD.Decrypt - | - plaintext - - -
-
-
Figure 5: -Decrypting an SFrame Ciphertext -
-
-
-
-
-
-
-

-4.5. Cipher Suites -

-

Each SFrame session uses a single cipher suite that specifies the following -primitives:

-
    -
  • -

    A hash function used for key derivation

    -
    • -
  • -

    An AEAD encryption algorithm [RFC5116] used for frame encryption, optionally -with a truncated authentication tag

    -
    • -
-

This document defines the following cipher suites, with the constants defined in -Section 4.4:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 1: -SFrame cipher suite constants -
NameNhNkaNkNnNt
- AES_128_CTR_HMAC_SHA256_80 -3216481210
- AES_128_CTR_HMAC_SHA256_64 -321648128
- AES_128_CTR_HMAC_SHA256_32 -321648124
- AES_128_GCM_SHA256_128 -32n/a161216
- AES_256_GCM_SHA512_128 -64n/a321216
-
-

Numeric identifiers for these cipher suites are defined in the IANA registry -created in Section 8.1.

-

In the suite names, the length of the authentication tag is indicated by -the last value: "_128" indicates a hundred-twenty-eight-bit tag, "_80" indicates -a eighty-bit tag, "_64" indicates a sixty-four-bit tag and "_32" indicates a -thirty-two-bit tag.

-

In a session that uses multiple media streams, different cipher suites might be -configured for different media streams. For example, in order to conserve -bandwidth, a session might use a cipher suite with eighty-bit tags for video frames -and another cipher suite with thirty-two-bit tags for audio frames.

-
-
-

-4.5.1. AES-CTR with SHA2 -

-

In order to allow very short tag sizes, we define a synthetic AEAD function -using the authenticated counter mode of AES together with HMAC for -authentication. We use an encrypt-then-MAC approach, as in SRTP [RFC3711].

-

Before encryption or decryption, encryption and authentication subkeys are -derived from the single AEAD key. The overall length of the AEAD key is Nka + -Nh, where Nka represents the key size for the AES block cipher in use and Nh -represents the output size of the hash function (as in Table 2). -The encryption subkey comprises the first Nka bytes and the authentication -subkey comprises the remaining Nh bytes.

-
-
-def derive_subkeys(sframe_key):
-  enc_key = sframe_key[..Nka]
-  auth_key = sframe_key[Nka..]
-  return enc_key, auth_key
-
-
-

The AEAD encryption and decryption functions are then composed of individual -calls to the CTR encrypt function and HMAC. The resulting MAC value is truncated -to a number of bytes Nt fixed by the cipher suite.

-
-
-def truncate(tag, n):
-  # Take the first `n` bytes of `tag`
-  return tag[..n]
-
-def compute_tag(auth_key, nonce, aad, ct):
-  aad_len = encode_big_endian(len(aad), 8)
-  ct_len = encode_big_endian(len(ct), 8)
-  tag_len = encode_big_endian(Nt, 8)
-  auth_data = aad_len + ct_len + tag_len + nonce + aad + ct
-  tag = HMAC(auth_key, auth_data)
-  return truncate(tag, Nt)
-
-def AEAD.Encrypt(key, nonce, aad, pt):
-  enc_key, auth_key = derive_subkeys(key)
-  initial_counter = nonce + 0x00000000 # append four zero bytes
-  ct = AES-CTR.Encrypt(enc_key, initial_counter, pt)
-  tag = compute_tag(auth_key, nonce, aad, ct)
-  return ct + tag
-
-def AEAD.Decrypt(key, nonce, aad, ct):
-  inner_ct, tag = split_ct(ct, tag_len)
-
-  enc_key, auth_key = derive_subkeys(key)
-  candidate_tag = compute_tag(auth_key, nonce, aad, inner_ct)
-  if !constant_time_equal(tag, candidate_tag):
-    raise Exception("Authentication Failure")
-
-  initial_counter = nonce + 0x00000000 # append four zero bytes
-  return AES-CTR.Decrypt(enc_key, initial_counter, inner_ct)
-
-
-
-
-
-
-
-
-
-
-

-5. Key Management -

-

SFrame must be integrated with an E2E key management framework to exchange and -rotate the keys used for SFrame encryption. The key management -framework provides the following functions:

- -

It is the responsibility of the application to provide the key management -framework, as described in Section 9.2.

-
-
-

-5.1. Sender Keys -

-

If the participants in a call have a pre-existing E2E-secure channel, they can -use it to distribute SFrame keys. Each client participating in a call generates -a fresh base_key value that it will use to encrypt media. The client then uses -the E2E-secure channel to send their encryption key to the other participants.

-

In this scheme, it is assumed that receivers have a signal outside of SFrame for -which client has sent a given frame (e.g., an RTP SSRC). SFrame KID -values are then used to distinguish between versions of the sender's base_key.

-

Key IDs in this scheme have two parts, a "key generation" and a "ratchet step". -Both are unsigned integers that begin at zero. The key generation increments -each time the sender distributes a new key to receivers. The "ratchet step" is -incremented each time the sender ratchets their key forward for forward secrecy:

-
-
-base_key[i+1] = HKDF-Expand(
-                  HKDF-Extract("", base_key[i]),
-                  "SFrame 1.0 Ratchet", CipherSuite.Nh)
-
-
-

For compactness, we do not send the whole ratchet step. Instead, we send only -its low-order R bits, where R is a value set by the application. Different -senders may use different values of R, but each receiver of a given sender -needs to know what value of R is used by the sender so that they can recognize -when they need to ratchet (vs. expecting a new key). R effectively defines a -re-ordering window, since no more than 2R ratchet steps can be -active at a given time. The key generation is sent in the remaining 64 - R -bits of the key ID.

-
-
-KID = (key_generation << R) + (ratchet_step % (1 << R))
-
-
-
-
-
-
- - - - - - - - - - - - - - 64-R - bits - R - bits - Key - Generation - Ratchet - Step - - -
-
-
Figure 6: -Structure of a KID in the Sender Keys scheme -
-
-

The sender signals such a ratchet step update by sending with a KID value in -which the ratchet step has been incremented. A receiver who receives from a -sender with a new KID computes the new key as above. The old key may be kept -for some time to allow for out-of-order delivery, but should be deleted -promptly.

-

If a new participant joins in the middle of a session, they will need to receive -from each sender (a) the current sender key for that sender and (b) the current -KID value for the sender. Evicting a participant requires each sender to send -a fresh sender key to all receivers.

-

It is up to the application to decide when sender keys are updated. A sender -key may be updated by sending a new base_key (updating the key generation) or -by hashing the current base_key (updating the ratchet step). Ratcheting the -key forward is useful when adding new receivers to an SFrame-based interaction, -since it assures that the new receivers can't decrypt any media encrypted before -they were added. If a sender wishes to assure the opposite property when -removing a receiver (i.e., ensuring that the receiver can't decrypt media after -they are removed), then the sender will need to distribute a new sender key.

-
-
-
-
-

-5.2. MLS -

-

The Messaging Layer Security (MLS) protocol provides group authenticated key -exchange [MLS-ARCH] [MLS-PROTO]. In -principle, it could be used to instantiate the sender key scheme above, but it -can also be used more efficiently directly.

-

MLS creates a linear sequence of keys, each of which is shared among the members -of a group at a given point in time. When a member joins or leaves the group, a -new key is produced that is known only to the augmented or reduced group. Each -step in the lifetime of the group is known as an "epoch", and each member of the -group is assigned an "index" that is constant for the time they are in the -group.

-

To generate keys and nonces for SFrame, we use the MLS exporter function to -generate a base_key value for each MLS epoch. Each member of the group is -assigned a set of KID values, so that each member has a unique sframe_key and -sframe_salt that it uses to encrypt with. Senders may choose any KID value -within their assigned set of KID values, e.g., to allow a single sender to send -multiple uncoordinated outbound media streams.

-
-
-base_key = MLS-Exporter("SFrame 1.0 Base Key", "", AEAD.Nk)
-
-
-

For compactness, we do not send the whole epoch number. Instead, we send only -its low-order E bits, where E is a value set by the application. E -effectively defines a re-ordering window, since no more than 2E -epochs can be active at a given time. Receivers MUST be prepared for the epoch -counter to roll over, removing an old epoch when a new epoch with the same E -lower bits is introduced.

-

Let S be the number of bits required to encode a member index in the group, -i.e., the smallest value such that group_size <= (1 << S). The sender index -is encoded in the S bits above the epoch. The remaining 64 - S - E bits of -the KID value are a context value chosen by the sender (context value 0 will -produce the shortest encoded KID).

-
-
-KID = (context << (S + E)) + (sender_index << E) + (epoch % (1 << E))
-
-
-
-
-
-
- - - - - - - - - - - - - - - - - - 64-S-E - bits - S - bits - E - bits - Context - ID - Index - Epoch - - -
-
-
Figure 7: -Structure of a KID for an MLS Sender -
-
-

Once an SFrame stack has been provisioned with the sframe_epoch_secret for an -epoch, it can compute the required KID values on demand (as well as the -resulting SFrame keys/nonces derived from the base_key and KID), as it needs -to encrypt or decrypt for a given member.

-
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ... - Epoch - 14 - index=3 - KID - = - 0x3e - index=7 - KID - = - 0x7e - index=20 - KID - = - 0x14e - Epoch - 15 - index=3 - KID - = - 0x3f - index=5 - KID - = - 0x5f - Epoch - 16 - index=2 - context - = - 2 - KID - = - 0x820 - context - = - 3 - KID - = - 0xc20 - Epoch - 17 - index=33 - KID - = - 0x211 - index=51 - KID - = - 0x331 - ... - - -
-
-
Figure 8: -An example sequence of KIDs for an MLS-based SFrame session (E=4; S=6, allowing for 64 group members) -
-
-
-
-
-
-
-
-

-6. Media Considerations -

-
-
-

-6.1. Selective Forwarding Units -

-

Selective Forwarding Units (SFUs) (e.g., those described in Section 3.7 of [RFC7667]) receive the media streams from each participant and select which -ones should be forwarded to each of the other participants. There are several -approaches for stream selection, but in general, the SFU needs to access -metadata associated to each frame and modify the RTP information of the incoming -packets when they are transmitted to the received participants.

-

This section describes how this normal SFU modes of operation interact with the -E2EE provided by SFrame.

-
-
-

-6.1.1. LastN and RTP stream reuse -

-

The SFU may choose to send only a certain number of streams based on the voice -activity of the participants. To avoid the overhead involved in establishing new -transport streams, the SFU may decide to reuse previously existing streams or -even pre-allocate a predefined number of streams and choose in each moment in -time which participant media will be sent through it.

-

This means that in the same transport-level stream (e.g., an RTP stream defined -by either SSRC or MID) may carry media from different streams of different -participants. As different keys are used by each participant for encoding their -media, the receiver will be able to verify which is the sender of the media -coming within the RTP stream at any given point in time, preventing the SFU -trying to impersonate any of the participants with another participant's media.

-

Note that in order to prevent impersonation by a malicious participant (not the -SFU), a mechanism based on digital signature would be required. SFrame does not -protect against such attacks.

-
-
-
-
-

-6.1.2. Simulcast -

-

When using simulcast, the same input image will produce N different encoded -frames (one per simulcast layer) which would be processed independently by the -frame encryptor and assigned an unique counter for each.

-
-
-
-
-

-6.1.3. SVC -

-

In both temporal and spatial scalability, the SFU may choose to drop layers in -order to match a certain bitrate or forward specific media sizes or frames per -second. In order to support the SFU selectively removing layers, the sender MUST -encapsulate each layer in a different SFrame ciphertext.

-
-
-
-
-
-
-

-6.2. Video Key Frames -

-

Forward Security and Post-Compromise Security require that the E2EE keys (base keys) -are updated any time a participant joins or leaves the call.

-

The key exchange happens asynchronously and on a different path than the SFU signaling -and media. So it may happen that when a new participant joins the call and the -SFU side requests a key frame, the sender generates the E2EE frame -with a key not known by the receiver, so it will be discarded. When the sender -updates his sending key with the new key, it will send it in a non-key frame, so -the receiver will be able to decrypt it, but not decode it.

-

The new Receiver will then re-request a key frame, but due to sender and SFU -policies, that new key frame could take some time to be generated.

-

If the sender sends a key frame after the new E2EE key is in use, the time -required for the new participant to display the video is minimized.

-

Note that this issue does not arise for media streams that do not have -dependencies among frames, e.g., audio streams. In these streams, each frame is -independently decodeable, so there is never a need to process two frames -together which might be on two sides of a key rotation.

-
-
-
-
-

-6.3. Partial Decoding -

-

Some codecs support partial decoding, where individual packets can be decoded -without waiting for the full frame to arrive. When SFrame is applied per-frame, -this won't be possible because the decoder cannot access data until an entire -frame has arrived and has been decrypted.

-
-
-
-
-
-
-

-7. Security Considerations -

-
-
-

-7.1. No Header Confidentiality -

-

SFrame provides integrity protection to the SFrame Header (the key ID and -counter values), but does not provide confidentiality protection. Parties that -can observe the SFrame header may learn, for example, which parties are sending -SFrame payloads (from KID values) and at what rates (from CTR values). In cases -where SFrame is used for end-to-end security on top of hop-by-hop protections -(e.g., running over SRTP as described in Appendix C.5), the hop-by-hop security -mechanisms provide confidentiality protection of the SFrame header between hops.

-
-
-
-
-

-7.2. No Per-Sender Authentication -

-

SFrame does not provide per-sender authentication of media data. Any sender in -a session can send media that will be associated with any other sender. This is -because SFrame uses symmetric encryption to protect media data, so that any -receiver also has the keys required to encrypt packets for the sender.

-
-
-
-
-

-7.3. Key Management -

-

Key exchange mechanism is out of scope of this document, however every client -SHOULD change their keys when new clients joins or leaves the call for forward -secrecy and post compromise security.

-
-
-
-
-

-7.4. Replay -

-

The handling of replay is out of the scope of this document. However, senders -MUST reject requests to encrypt multiple times with the same key and nonce, -since several AEAD algorithms fail badly in such cases (see, e.g., Section 5.1.1 of [RFC5116]).

-
-
-
-
-

-7.5. Risks due to Short Tags -

-

The SFrame ciphersuites based on AES-CTR allow for the use of short -authentication tags, which bring a higher risk that an attacker will be -able to cause an SFrame receiver to accept an SFrame ciphertext of the -attacker's choosing.

-

Assuming that the authentication properties of the ciphersuite are robust, the -only attack that an attacker can mount is an attempt to find an acceptable -(ciphertext, tag) combination through brute force. Such a brute-force attack -will have an expected sucess rate of the following form:

-

-attacker_success_rate = attempts_per_second / 2^(8*Nt) -

-

For example, a gigabit ethernet connection is able to transmit roughly 2^20 -packets per second. If an attacker saturated such a link with guesses against a -32-bit authentication tag (Nt=4), then the attacker would succeed on average -roughly once every 2^12 seconds, or about once an hour.

-

In a typical SFrame usage in a real-time media application, there are a few -approaches to mitigating this risk:

-
    -
  • -

    Receivers only accept SFrame ciphertexts over HBH-secure channels (e.g., SRTP -security associations or QUIC connections). So only an entity that is part of -such a channel can mount the above attack.

    -
    • -
  • -

    The expected packet rate for a media stream is very predictable (and typically -far lower than the above example). On the one hand, attacks at this rate will -succeed even less often than the high-rate attack described above. On the -other hand, the application may use an elevated packet arrival rate as a -signal of a brute-force attack. This latter approach is common in other -settings, e.g., mitigating brute-force attacks on passwords.

    -
    • -
  • -

    Media applications typically do not provide feedback to media senders as to -which media packets failed to decrypt. When media quality feedback -mechanisms are used, decryption failures will typically appear as packet -losses, but only at an aggregate level.

    -
    • -
  • -

    Anti-replay mechanisms (see Section 7.4) prevent the attacker from re-using -valid ciphertexts (either observed or guessed by the attacker). A receiver -applying anti-replay controls will only accept one valid plaintext per CTR -value. Since the CTR value is covered by SFrame authentication, an attacker -has to do a fresh search for a valid tag for every forged ciphertext, even if -the encrypted content is unchanged. In other words, when the above brute -force attack succeeds, it only allows the attacker to send a single SFrame -ciphertext; the ciphertext cannot be reused because either it will have the -same CTR value and be discarded as a replay, or else it will have a different -CTR value its tag will no longer be valid.

    -
    • -
-

Nonetheless, without these mitigations, an application that makes use of short -tags will be at heightened risk of forgery attacks. In many cases, it is -simpler to use full-size tags and tolerate slightly higher bandwidth usage -rather than add the additional defenses necessary to safely use short tags.

-
-
-
-
-
-
-

-8. IANA Considerations -

-

This document requests the creation of the following new IANA registries:

- -

This registries should be under a heading of "SFrame", -and assignments are made via the Specification Required policy [RFC8126].

-

RFC EDITOR: Please replace XXXX throughout with the RFC number assigned to -this document

-
-
-

-8.1. SFrame Cipher Suites -

-

This registry lists identifiers for SFrame cipher suites, as defined in -Section 4.5. The cipher suite field is two bytes wide, so the valid cipher -suites are in the range 0x0000 to 0xFFFF.

-

Template:

-
    -
  • -

    Value: The numeric value of the cipher suite

    -
    • -
  • -

    Name: The name of the cipher suite

    -
    • -
  • -

    Reference: The document where this wire format is defined

    -
    • -
-

Initial contents:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 2: -SFrame cipher suites -
ValueNameReference
0x0000ReservedRFC XXXX
0x0001 - AES_128_CTR_HMAC_SHA256_80 -RFC XXXX
0x0002 - AES_128_CTR_HMAC_SHA256_64 -RFC XXXX
0x0003 - AES_128_CTR_HMAC_SHA256_32 -RFC XXXX
0x0004 - AES_128_GCM_SHA256_128 -RFC XXXX
0x0005 - AES_256_GCM_SHA512_128 -RFC XXXX
0xF000 - 0xFFFFReserved for private useRFC XXXX
-
-
-
-
-
-
-
-

-9. Application Responsibilities -

-

To use SFrame, an application needs to define the inputs to the SFrame -encryption and decryption operations, and how SFrame ciphertexts are delivered -from sender to receiver (including any fragmentation and reassembly). In this -section, we lay out additional requirements that an integration must meet in -order for SFrame to operate securely.

-

In general, an application using SFrame is responsible for configuring SFrame. -The application must first define when SFrame is applied at all. When SFrame is -applied, the application must define which cipher suite is to be used. If new -versions of SFrame are defined in the future, it will be up to the application -to determine which version should be used.

-

This division of responsibilities is similar to the way other media parameters -(e.g., codecs) are typically handled in media applications, in the sense that -they are set up in some signaling protocol, and then not described in the media. -Applications might find it useful to extend the protocols used for negotiating -other media parameters (e.g., SDP [RFC4566]) to also negotiate parameters for -SFrame.

-
-
-

-9.1. Header Value Uniqueness -

-

Applications MUST ensure that each (base_key, KID, CTR) combination is used -for at most one SFrame encryption operation. This ensures that the (key, nonce) -pairs used by the underlying AEAD algorithm are never reused. Typically this is -done by assigning each sender a KID or set of KIDs, then having each sender use -the CTR field as a monotonic counter, incrementing for each plaintext that is -encrypted. In addition to its simplicity, this scheme minimizes overhead by -keeping CTR values as small as possible.

-
-
-
-
-

-9.2. Key Management Framework -

-

It is up to the application to provision SFrame with a mapping of KID values to -base_key values and the resulting keys and salts. More importantly, the -application specifies which KID values are used for which purposes (e.g., by -which senders). An application's KID assignment strategy MUST be structured to -assure the non-reuse properties discussed in Section 9.1.

-

It is also up to the application to define a rotation schedule for keys. For -example, one application might have an ephemeral group for every call and keep -rotating keys when end points join or leave the call, while another application -could have a persistent group that can be used for multiple calls and simply -derives ephemeral symmetric keys for a specific call.

-

It should be noted that KID values are not encrypted by SFrame, and are thus -visible to any application-layer intermediaries that might handle an SFrame -ciphertext. If there are application semantics included in KID values, then -this information would be exposed to intermediaries. For example, in the scheme -of Section 5.1, the number of ratchet steps per sender is exposed, and in -the scheme of Section 5.2, the number of epochs and the MLS sender ID of the SFrame -sender are exposed.

-
-
-
-
-

-9.3. Anti-Replay -

-

It is the responsibility of the application to handle anti-replay. Replay by network -attackers is assumed to be prevented by network-layer facilities (e.g., TLS, SRTP). -As mentioned in Section 7.4, senders MUST reject requests to encrypt multiple times -with the same key and nonce.

-

It is not mandatory to implement anti-replay on the receiver side. Receivers MAY -apply time or counter based anti-replay mitigations.

-
-
-
-
-

-9.4. Metadata -

-

The metadata input to SFrame operations is pure application-specified data. As -such, it is up to the application to define what information should go in the -metadata input and ensure that it is provided to the encryption and decryption -functions at the appropriate points. A receiver MUST NOT use SFrame-authenticated -metadata until after the SFrame decrypt function has authenticated it, unless -the purpose of such usage is to prepare an SFrame ciphertext for SFrame -decryption. Essentially, metadata may be used "upstream of SFrame" in a -processing pipeline, but only to prepare for SFrame decryption.

-

For example, consider an application where SFrame is used to encrypt audio -frames that are sent over SRTP, with some application data included in the RTP -header extension. Suppose the application also includes this application data in -the SFrame metadata, so that the SFU is allowed to read, but not modify the -application data. A receiver can use the application data in the RTP header -extension as part of the standard SRTP decryption process, since this is -required to recover the SFrame ciphertext carried in the SRTP payload. However, -the receiver MUST NOT use the application data for other purposes before SFrame -decryption has authenticated the application data.

-
-
-
-
-
-

-10. References -

-
-
-

-10.1. Normative References -

-
-
[MLS-PROTO]
-
-Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, , <https://www.rfc-editor.org/rfc/rfc9420>.
-
-
[RFC2119]
-
-Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
-
-
[RFC5116]
-
-McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, , <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, , <https://www.rfc-editor.org/rfc/rfc5869>.
-
-
[RFC8126]
-
-Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/rfc/rfc8126>.
-
-
[RFC8174]
-
-Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
-
-
-
-
-
-
-

-10.2. Informative References -

-
-
[I-D.codec-agnostic-rtp-payload-format]
-
-Murillo, S. G. and A. Gouaillard, "Codec agnostic RTP payload format for video", Work in Progress, Internet-Draft, draft-codec-agnostic-rtp-payload-format-00, , <https://datatracker.ietf.org/doc/html/draft-codec-agnostic-rtp-payload-format-00>.
-
-
[I-D.ietf-moq-transport]
-
-Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and I. Swett, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-02>.
-
-
[I-D.ietf-webtrans-overview]
-
-Vasiliev, V., "The WebTransport Protocol Framework", Work in Progress, Internet-Draft, draft-ietf-webtrans-overview-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-overview-06>.
-
-
[MLS-ARCH]
-
-Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., and A. Duric, "The Messaging Layer Security (MLS) Architecture", Work in Progress, Internet-Draft, draft-ietf-mls-architecture-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture-11>.
-
-
[RFC3711]
-
-Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, , <https://www.rfc-editor.org/rfc/rfc3711>.
-
-
[RFC4566]
-
-Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, , <https://www.rfc-editor.org/rfc/rfc4566>.
-
-
[RFC6716]
-
-Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, , <https://www.rfc-editor.org/rfc/rfc6716>.
-
-
[RFC7656]
-
-Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, , <https://www.rfc-editor.org/rfc/rfc7656>.
-
-
[RFC7667]
-
-Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, , <https://www.rfc-editor.org/rfc/rfc7667>.
-
-
[RFC8723]
-
-Jennings, C., Jones, P., Barnes, R., and A.B. Roach, "Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)", RFC 8723, DOI 10.17487/RFC8723, , <https://www.rfc-editor.org/rfc/rfc8723>.
-
-
[TestVectors]
-
-"SFrame Test Vectors", , <https://github.com/eomara/sframe/blob/master/test-vectors.json>.
-
-
-
-
-
-
-
-

-Appendix A. Acknowledgements -

-

The authors wish to specially thank Dr. Alex Gouaillard as one of the early -contributors to the document. His passion and energy were key to the design and -development of SFrame.

-
-
-
-
-

-Appendix B. Example API -

-

This section is not normative.

-

This section describes a notional API that an SFrame implementation might -expose. The core concept is an "SFrame context", within which KID values are -meaningful. In the key management scheme described in Section 5.1, each -sender has a different context; in the scheme described in Section 5.2, all senders -share the same context.

-

An SFrame context stores mappings from KID values to "key contexts", which are -different depending on whether the KID is to be used for sending or receiving -(an SFrame key should never be used for both operations). A key context tracks -the key and salt associated to the KID, and the current CTR value. A key -context to be used for sending also tracks the next CTR value to be used.

-

The primary operations on an SFrame context are as follows:

- -

Figure 9 shows an example of the types of structures and methods that could -be used to create an SFrame API in Rust.

-
-
-
-
-type KeyId = u64;
-type Counter = u64;
-type CipherSuite = u16;
-
-struct SendKeyContext {
-  key: Vec<u8>,
-  salt: Vec<u8>,
-  next_counter: Counter,
-}
-
-struct RecvKeyContext {
-  key: Vec<u8>,
-  salt: Vec<u8>,
-}
-
-struct SFrameContext {
-  cipher_suite: CipherSuite,
-  send_keys: HashMap<KeyId, SendKeyContext>,
-  recv_keys: HashMap<KeyId, RecvKeyContext>,
-}
-
-trait SFrameContextMethods {
-  fn create(cipher_suite: CipherSuite) -> Self;
-  fn add_send_key(&self, kid: KeyId, base_key: &[u8]);
-  fn add_recv_key(&self, kid: KeyId, base_key: &[u8]);
-  fn encrypt(&mut self, kid: KeyId, metadata: &[u8],
-             plaintext: &[u8]) -> Vec<u8>;
-  fn decrypt(&self, metadata: &[u8], ciphertext: &[u8]) -> Vec<u8>;
-}
-
-
-
Figure 9: -An Example SFrame API -
-
-
-
-
-
-

-Appendix C. Overhead Analysis -

-

Any use of SFrame will impose overhead in terms of the amount of bandwidth -necessary to transmit a given media stream. Exactly how much overhead will be added -depends on several factors:

- -

Overall, the overhead rate in kilobits per second can be estimated as:

-

-OverheadKbps = (1 + |CTR| + |KID| + |TAG|) * 8 * CTPerSecond / 1024 -

-

Here the constant value 1 reflects the fixed SFrame header; |CTR| and -|KID| reflect the lengths of those fields; |TAG| reflects the cipher -overhead; and CTPerSecond reflects the number of SFrame ciphertexts -sent per second (e.g., packets or frames per second).

-

In the remainder of this secton, we compute overhead estimates for a collection -of common scenarios.

-
-
-

-C.1. Assumptions -

-

In the below calculations, we make conservative assumptions about SFrame -overhead, so that the overhead amounts we compute here are likely to be an upper -bound on those seen in practice.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 3
FieldBytesExplanation
Fixed header1Fixed
Key ID (KID)2>255 senders; or MLS epoch (E=4) and >16 senders
Counter (CTR)3More than 24 hours of media in common cases
Cipher overhead16Full GCM tag (longest defined here)
-

In total, then, we assume that each SFrame encryption will add 22 bytes of -overhead.

-

We consider two scenarios, applying SFrame per-frame and per-packet. In each -scenario, we compute the SFrame overhead in absolute terms (Kbps) and as a -percentage of the base bandwidth.

-
-
-
-
-

-C.2. Audio -

-

In audio streams, there is typically a one-to-one relationship between frames -and packets, so the overhead is the same whether one uses SFrame at a per-packet -or per-frame level.

-

The below table considers three scenarios, based on recommended configurations -of the Opus codec [RFC6716]:

-
    -
  • -

    Narrow-band speech: 120ms packets, 8Kbps

    -
    • -
  • -

    Full-band speech: 20ms packets, 32Kbps

    -
    • -
  • -

    Full-band stereo music: 10ms packets, 128Kbps

    -
    • -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 4: -SFrame overhead for audio streams -
ScenariofpsBase KbpsOverhead KbpsOverhead %
NB speech, 120ms packets8.381.417.9%
FB speech, 20ms packets50328.626.9%
FB stereo, 10ms packets10012817.213.4%
-
-
-
-
-
-

-C.3. Video -

-

Video frames can be larger than an MTU and thus are commonly split across -multiple frames. Table 5 and Table 6 -show the estimated overhead of encrypting a video stream, where SFrame is -applied per-frame and per-packet, respectively. The choices of resolution, -frames per second, and bandwidth are chosen to roughly reflect the capabilities of -modern video codecs across a range from very low to very high quality.

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 5: -SFrame overhead for a video stream encrypted per-frame -
ScenariofpsBase KbpsOverhead KbpsOverhead %
426 x 2407.5451.32.9%
640 x 360152002.61.3%
640 x 360304005.21.3%
1280 x 7203015005.20.3%
1920 x 108060720010.30.1%
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 6: -SFrame overhead for a video stream encrypted per-packet -
ScenariofpsppsBase KbpsOverhead KbpsOverhead %
426 x 2407.57.5451.32.9%
640 x 36015302005.22.6%
640 x 360306040010.32.6%
1280 x 72030180150030.92.1%
1920 x 1080607807200134.11.9%
-
-

In the per-frame case, the SFrame percentage overhead approaches zero as the -quality of the video goes up, since bandwidth is driven more by picture size -than frame rate. In the per-packet case, the SFrame percentage overhead -approaches the ratio between the SFrame overhead per packet and the MTU (here 22 -bytes of SFrame overhead divided by an assumed 1200-byte MTU, or about 1.8%).

-
-
-
-
-

-C.4. Conferences -

-

Real conferences usually involve several audio and video streams. The overhead -of SFrame in such a conference is the aggregate of the overhead over all the -individual streams. Thus, while SFrame incurs a large percentage overhead on an -audio stream, if the conference also involves a video stream, then the audio -overhead is likely negligible relative to the overall bandwidth of the -conference.

-

For example, Table 7 shows the overhead estimates for a two -person conference where one person is sending low-quality media and the other -sending high-quality. (And we assume that SFrame is applied per-frame.) The -video streams dominate the bandwidth at the SFU, so the total bandwidth overhead -is only around 1%.

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 7: -SFrame overhead for a two-person conference -
StreamBase KbpsOverhead KbpsOverhead %
Participant 1 audio81.417.9%
Participant 1 video451.32.9%
Participant 2 audio32926.9%
Participant 2 video150050.3%
Total at SFU158516.51.0%
-
-
-
-
-
-

-C.5. SFrame over RTP -

-

SFrame is a generic encapsulation format, but many of the applications in which -it is likely to be integrated are based on RTP. This section discusses how an -integration between SFrame and RTP could be done, and some of the challenges -that would need to be overcome.

-

As discussed in Section 4.1, there are two natural patterns for -integrating SFrame into an application: applying SFrame per-frame or per-packet. -In RTP-based applications, applying SFrame per-packet means that the payload of -each RTP packet will be an SFrame ciphertext, starting with an SFrame Header, as -shown in Figure 10. Applying SFrame per-frame means that different -RTP payloads will have different formats: The first payload of a frame will -contain the SFrame headers, and subsequent payloads will contain further chunks -of the ciphertext, as shown in Figure 11.

-

In order for these media payloads to be properly interpreted by receivers, -receivers will need to be configured to know which of the above schemes the -sender has applied to a given sequence of RTP packets. SFrame does not provide -a mechanism for distributing this configuration information. In applications -that use SDP for negotiating RTP media streams [RFC4566], an appropriate -extension to SDP could provide this function.

-

Applying SFrame per-frame also requires that packetization and depacketization -be done in a generic manner that does not depend on the media content of the -packets, since the content being packetized / depacketized will be opaque -ciphertext (except for the SFrame header). In order for such a generic -packetization scheme to work interoperably one would have to be defined, e.g., -as proposed in [I-D.codec-agnostic-rtp-payload-format].

-
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - V=2 - P - X - CC - M - PT - sequence - number - timestamp - synchronization - source - (SSRC) - identifier - contributing - source - (CSRC) - identifiers - .... - RTP - extension(s) - (OPTIONAL) - SFrame - header - SFrame - encrypted - and - authenticated - payload - SRTP - authentication - tag - SRTP - Encrypted - Portion - SRTP - Authenticated - Portion - - -
-
-
Figure 10: -SRTP packet with SFrame-protected payload -
-
-
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - frame - metadata - frame - SFrame - Encrypt - encrypted - frame - generic - RTP - packetize - ... - SFrame - header - payload - 2/N - ... - payload - N/N - payload - 1/N - - -
-
-
Figure 11: -Encryption flow with per-frame encryption for RTP -
-
-
-
-
-
-
-
-

-Appendix D. Test Vectors -

-

This section provides a set of test vectors that implementations can use to -verify that they correctly implement SFrame encryption and decryption. In -addition to test vectors for the overall process of SFrame -encryption/decryption, we also provide test vectors for header -encoding/decoding, and for AEAD encryption/decryption using the AES-CTR -construction defined in Section 4.5.1.

-

All values are either numeric or byte strings. Numeric values are represented -as hex values, prefixed with 0x. Byte strings are represented in hex -encoding.

-

Line breaks and whitespace within values are inserted to conform to the width -requirements of the RFC format. They should be removed before use.

-

These test vectors are also available in JSON format at [TestVectors]. In the -JSON test vectors, numeric values are JSON numbers and byte string values are -JSON strings containing the hex encoding of the byte strings.

-
-
-

-D.1. Header encoding/decoding -

-

For each case, we provide:

-
    -
  • -

    kid: A KID value

    -
    • -
  • -

    ctr: A CTR value

    -
    • -
  • -

    header: An encoded SFrame header

    -
    • -
-

An implementation should verify that:

-
    -
  • -

    Encoding a header with the KID and CTR results in the provided header value

    -
    • -
  • -

    Decoding the provided header value results in the provided KID and CTR values

    -
    • -
-
-
-kid: 0x0000000000000000
-ctr: 0x0000000000000000
-header: 00
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0000000000000001
-header: 01
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x00000000000000ff
-header: 08ff
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0000000000000100
-header: 090100
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x000000000000ffff
-header: 09ffff
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0000000000010000
-header: 0a010000
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0000000000ffffff
-header: 0affffff
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0000000001000000
-header: 0b01000000
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x00000000ffffffff
-header: 0bffffffff
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0000000100000000
-header: 0c0100000000
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x000000ffffffffff
-header: 0cffffffffff
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0000010000000000
-header: 0d010000000000
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0000ffffffffffff
-header: 0dffffffffffff
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0001000000000000
-header: 0e01000000000000
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x00ffffffffffffff
-header: 0effffffffffffff
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0100000000000000
-header: 0f0100000000000000
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0xffffffffffffffff
-header: 0fffffffffffffffff
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000000000000000
-header: 10
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000000000000001
-header: 11
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x00000000000000ff
-header: 18ff
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000000000000100
-header: 190100
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x000000000000ffff
-header: 19ffff
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000000000010000
-header: 1a010000
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000000000ffffff
-header: 1affffff
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000000001000000
-header: 1b01000000
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x00000000ffffffff
-header: 1bffffffff
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000000100000000
-header: 1c0100000000
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x000000ffffffffff
-header: 1cffffffffff
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000010000000000
-header: 1d010000000000
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000ffffffffffff
-header: 1dffffffffffff
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0001000000000000
-header: 1e01000000000000
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x00ffffffffffffff
-header: 1effffffffffffff
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0100000000000000
-header: 1f0100000000000000
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0xffffffffffffffff
-header: 1fffffffffffffffff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000000000000000
-header: 80ff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000000000000001
-header: 81ff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x00000000000000ff
-header: 88ffff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000000000000100
-header: 89ff0100
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x000000000000ffff
-header: 89ffffff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000000000010000
-header: 8aff010000
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000000000ffffff
-header: 8affffffff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000000001000000
-header: 8bff01000000
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x00000000ffffffff
-header: 8bffffffffff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000000100000000
-header: 8cff0100000000
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x000000ffffffffff
-header: 8cffffffffffff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000010000000000
-header: 8dff010000000000
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000ffffffffffff
-header: 8dffffffffffffff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0001000000000000
-header: 8eff01000000000000
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x00ffffffffffffff
-header: 8effffffffffffffff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0100000000000000
-header: 8fff0100000000000000
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0xffffffffffffffff
-header: 8fffffffffffffffffff
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000000000000000
-header: 900100
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000000000000001
-header: 910100
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x00000000000000ff
-header: 980100ff
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000000000000100
-header: 9901000100
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x000000000000ffff
-header: 990100ffff
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000000000010000
-header: 9a0100010000
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000000000ffffff
-header: 9a0100ffffff
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000000001000000
-header: 9b010001000000
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x00000000ffffffff
-header: 9b0100ffffffff
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000000100000000
-header: 9c01000100000000
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x000000ffffffffff
-header: 9c0100ffffffffff
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000010000000000
-header: 9d0100010000000000
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000ffffffffffff
-header: 9d0100ffffffffffff
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0001000000000000
-header: 9e010001000000000000
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x00ffffffffffffff
-header: 9e0100ffffffffffffff
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0100000000000000
-header: 9f01000100000000000000
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0xffffffffffffffff
-header: 9f0100ffffffffffffffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000000000000000
-header: 90ffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000000000000001
-header: 91ffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x00000000000000ff
-header: 98ffffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000000000000100
-header: 99ffff0100
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x000000000000ffff
-header: 99ffffffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000000000010000
-header: 9affff010000
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000000000ffffff
-header: 9affffffffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000000001000000
-header: 9bffff01000000
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x00000000ffffffff
-header: 9bffffffffffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000000100000000
-header: 9cffff0100000000
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x000000ffffffffff
-header: 9cffffffffffffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000010000000000
-header: 9dffff010000000000
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000ffffffffffff
-header: 9dffffffffffffffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0001000000000000
-header: 9effff01000000000000
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x00ffffffffffffff
-header: 9effffffffffffffffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0100000000000000
-header: 9fffff0100000000000000
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0xffffffffffffffff
-header: 9fffffffffffffffffffff
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000000000000000
-header: a0010000
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000000000000001
-header: a1010000
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x00000000000000ff
-header: a8010000ff
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000000000000100
-header: a90100000100
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x000000000000ffff
-header: a9010000ffff
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000000000010000
-header: aa010000010000
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000000000ffffff
-header: aa010000ffffff
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000000001000000
-header: ab01000001000000
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x00000000ffffffff
-header: ab010000ffffffff
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000000100000000
-header: ac0100000100000000
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x000000ffffffffff
-header: ac010000ffffffffff
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000010000000000
-header: ad010000010000000000
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000ffffffffffff
-header: ad010000ffffffffffff
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0001000000000000
-header: ae01000001000000000000
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x00ffffffffffffff
-header: ae010000ffffffffffffff
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0100000000000000
-header: af0100000100000000000000
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0xffffffffffffffff
-header: af010000ffffffffffffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000000000000000
-header: a0ffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000000000000001
-header: a1ffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x00000000000000ff
-header: a8ffffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000000000000100
-header: a9ffffff0100
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x000000000000ffff
-header: a9ffffffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000000000010000
-header: aaffffff010000
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000000000ffffff
-header: aaffffffffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000000001000000
-header: abffffff01000000
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x00000000ffffffff
-header: abffffffffffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000000100000000
-header: acffffff0100000000
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x000000ffffffffff
-header: acffffffffffffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000010000000000
-header: adffffff010000000000
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000ffffffffffff
-header: adffffffffffffffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0001000000000000
-header: aeffffff01000000000000
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x00ffffffffffffff
-header: aeffffffffffffffffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0100000000000000
-header: afffffff0100000000000000
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0xffffffffffffffff
-header: afffffffffffffffffffffff
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000000000000000
-header: b001000000
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000000000000001
-header: b101000000
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x00000000000000ff
-header: b801000000ff
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000000000000100
-header: b9010000000100
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x000000000000ffff
-header: b901000000ffff
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000000000010000
-header: ba01000000010000
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000000000ffffff
-header: ba01000000ffffff
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000000001000000
-header: bb0100000001000000
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x00000000ffffffff
-header: bb01000000ffffffff
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000000100000000
-header: bc010000000100000000
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x000000ffffffffff
-header: bc01000000ffffffffff
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000010000000000
-header: bd01000000010000000000
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000ffffffffffff
-header: bd01000000ffffffffffff
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0001000000000000
-header: be0100000001000000000000
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x00ffffffffffffff
-header: be01000000ffffffffffffff
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0100000000000000
-header: bf010000000100000000000000
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0xffffffffffffffff
-header: bf01000000ffffffffffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000000000000000
-header: b0ffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000000000000001
-header: b1ffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x00000000000000ff
-header: b8ffffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000000000000100
-header: b9ffffffff0100
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x000000000000ffff
-header: b9ffffffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000000000010000
-header: baffffffff010000
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000000000ffffff
-header: baffffffffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000000001000000
-header: bbffffffff01000000
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x00000000ffffffff
-header: bbffffffffffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000000100000000
-header: bcffffffff0100000000
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x000000ffffffffff
-header: bcffffffffffffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000010000000000
-header: bdffffffff010000000000
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000ffffffffffff
-header: bdffffffffffffffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0001000000000000
-header: beffffffff01000000000000
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x00ffffffffffffff
-header: beffffffffffffffffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0100000000000000
-header: bfffffffff0100000000000000
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0xffffffffffffffff
-header: bfffffffffffffffffffffffff
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000000000000000
-header: c00100000000
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000000000000001
-header: c10100000000
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x00000000000000ff
-header: c80100000000ff
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000000000000100
-header: c901000000000100
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x000000000000ffff
-header: c90100000000ffff
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000000000010000
-header: ca0100000000010000
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000000000ffffff
-header: ca0100000000ffffff
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000000001000000
-header: cb010000000001000000
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x00000000ffffffff
-header: cb0100000000ffffffff
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000000100000000
-header: cc01000000000100000000
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x000000ffffffffff
-header: cc0100000000ffffffffff
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000010000000000
-header: cd0100000000010000000000
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000ffffffffffff
-header: cd0100000000ffffffffffff
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0001000000000000
-header: ce010000000001000000000000
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x00ffffffffffffff
-header: ce0100000000ffffffffffffff
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0100000000000000
-header: cf01000000000100000000000000
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0xffffffffffffffff
-header: cf0100000000ffffffffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000000000000000
-header: c0ffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000000000000001
-header: c1ffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x00000000000000ff
-header: c8ffffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000000000000100
-header: c9ffffffffff0100
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x000000000000ffff
-header: c9ffffffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000000000010000
-header: caffffffffff010000
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000000000ffffff
-header: caffffffffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000000001000000
-header: cbffffffffff01000000
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x00000000ffffffff
-header: cbffffffffffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000000100000000
-header: ccffffffffff0100000000
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x000000ffffffffff
-header: ccffffffffffffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000010000000000
-header: cdffffffffff010000000000
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000ffffffffffff
-header: cdffffffffffffffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0001000000000000
-header: ceffffffffff01000000000000
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x00ffffffffffffff
-header: ceffffffffffffffffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0100000000000000
-header: cfffffffffff0100000000000000
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0xffffffffffffffff
-header: cfffffffffffffffffffffffffff
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000000000000000
-header: d0010000000000
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000000000000001
-header: d1010000000000
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x00000000000000ff
-header: d8010000000000ff
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000000000000100
-header: d90100000000000100
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x000000000000ffff
-header: d9010000000000ffff
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000000000010000
-header: da010000000000010000
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000000000ffffff
-header: da010000000000ffffff
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000000001000000
-header: db01000000000001000000
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x00000000ffffffff
-header: db010000000000ffffffff
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000000100000000
-header: dc0100000000000100000000
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x000000ffffffffff
-header: dc010000000000ffffffffff
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000010000000000
-header: dd010000000000010000000000
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000ffffffffffff
-header: dd010000000000ffffffffffff
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0001000000000000
-header: de01000000000001000000000000
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x00ffffffffffffff
-header: de010000000000ffffffffffffff
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0100000000000000
-header: df0100000000000100000000000000
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0xffffffffffffffff
-header: df010000000000ffffffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000000000000000
-header: d0ffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000000000000001
-header: d1ffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x00000000000000ff
-header: d8ffffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000000000000100
-header: d9ffffffffffff0100
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x000000000000ffff
-header: d9ffffffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000000000010000
-header: daffffffffffff010000
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000000000ffffff
-header: daffffffffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000000001000000
-header: dbffffffffffff01000000
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x00000000ffffffff
-header: dbffffffffffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000000100000000
-header: dcffffffffffff0100000000
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x000000ffffffffff
-header: dcffffffffffffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000010000000000
-header: ddffffffffffff010000000000
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000ffffffffffff
-header: ddffffffffffffffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0001000000000000
-header: deffffffffffff01000000000000
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x00ffffffffffffff
-header: deffffffffffffffffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0100000000000000
-header: dfffffffffffff0100000000000000
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0xffffffffffffffff
-header: dfffffffffffffffffffffffffffff
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000000000000000
-header: e001000000000000
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000000000000001
-header: e101000000000000
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x00000000000000ff
-header: e801000000000000ff
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000000000000100
-header: e9010000000000000100
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x000000000000ffff
-header: e901000000000000ffff
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000000000010000
-header: ea01000000000000010000
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000000000ffffff
-header: ea01000000000000ffffff
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000000001000000
-header: eb0100000000000001000000
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x00000000ffffffff
-header: eb01000000000000ffffffff
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000000100000000
-header: ec010000000000000100000000
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x000000ffffffffff
-header: ec01000000000000ffffffffff
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000010000000000
-header: ed01000000000000010000000000
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000ffffffffffff
-header: ed01000000000000ffffffffffff
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0001000000000000
-header: ee0100000000000001000000000000
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x00ffffffffffffff
-header: ee01000000000000ffffffffffffff
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0100000000000000
-header: ef010000000000000100000000000000
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0xffffffffffffffff
-header: ef01000000000000ffffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000000000000000
-header: e0ffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000000000000001
-header: e1ffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x00000000000000ff
-header: e8ffffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000000000000100
-header: e9ffffffffffffff0100
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x000000000000ffff
-header: e9ffffffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000000000010000
-header: eaffffffffffffff010000
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000000000ffffff
-header: eaffffffffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000000001000000
-header: ebffffffffffffff01000000
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x00000000ffffffff
-header: ebffffffffffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000000100000000
-header: ecffffffffffffff0100000000
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x000000ffffffffff
-header: ecffffffffffffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000010000000000
-header: edffffffffffffff010000000000
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000ffffffffffff
-header: edffffffffffffffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0001000000000000
-header: eeffffffffffffff01000000000000
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x00ffffffffffffff
-header: eeffffffffffffffffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0100000000000000
-header: efffffffffffffff0100000000000000
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0xffffffffffffffff
-header: efffffffffffffffffffffffffffffff
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000000000000000
-header: f00100000000000000
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000000000000001
-header: f10100000000000000
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x00000000000000ff
-header: f80100000000000000ff
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000000000000100
-header: f901000000000000000100
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x000000000000ffff
-header: f90100000000000000ffff
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000000000010000
-header: fa0100000000000000010000
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000000000ffffff
-header: fa0100000000000000ffffff
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000000001000000
-header: fb010000000000000001000000
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x00000000ffffffff
-header: fb0100000000000000ffffffff
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000000100000000
-header: fc01000000000000000100000000
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x000000ffffffffff
-header: fc0100000000000000ffffffffff
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000010000000000
-header: fd0100000000000000010000000000
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000ffffffffffff
-header: fd0100000000000000ffffffffffff
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0001000000000000
-header: fe010000000000000001000000000000
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x00ffffffffffffff
-header: fe0100000000000000ffffffffffffff
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0100000000000000
-header: ff010000000000000001000000000000
-        00
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0xffffffffffffffff
-header: ff0100000000000000ffffffffffffff
-        ff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000000000000000
-header: f0ffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000000000000001
-header: f1ffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x00000000000000ff
-header: f8ffffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000000000000100
-header: f9ffffffffffffffff0100
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x000000000000ffff
-header: f9ffffffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000000000010000
-header: faffffffffffffffff010000
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000000000ffffff
-header: faffffffffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000000001000000
-header: fbffffffffffffffff01000000
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x00000000ffffffff
-header: fbffffffffffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000000100000000
-header: fcffffffffffffffff0100000000
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x000000ffffffffff
-header: fcffffffffffffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000010000000000
-header: fdffffffffffffffff010000000000
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000ffffffffffff
-header: fdffffffffffffffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0001000000000000
-header: feffffffffffffffff01000000000000
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x00ffffffffffffff
-header: feffffffffffffffffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0100000000000000
-header: ffffffffffffffffff01000000000000
-        00
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0xffffffffffffffff
-header: ffffffffffffffffffffffffffffffff
-        ff
-
-
-
-
-
-
-

-D.2. AEAD encryption/decryption using AES-CTR and HMAC -

-

For each case, we provide:

-
    -
  • -

    cipher_suite: The index of the cipher suite in use (see -Section 8.1)

    -
    • -
  • -

    key: The key input to encryption/decryption

    -
    • -
  • -

    enc_key: The encryption subkey produced by the derive_subkeys() algorithm

    -
    • -
  • -

    auth_key: The encryption subkey produced by the derive_subkeys() algorithm

    -
    • -
  • -

    nonce: The nonce input to encryption/decryption

    -
    • -
  • -

    aad: The aad input to encryption/decryption

    -
    • -
  • -

    pt: The plaintext

    -
    • -
  • -

    ct: The ciphertext

    -
    • -
-

An implementation should verify that the following are true, where -AEAD.Encrypt and AEAD.Decrypt are as defined in Section 4.5.1:

-
    -
  • -

    AEAD.Encrypt(key, nonce, aad, pt) == ct

    -
    • -
  • -

    AEAD.Decrypt(key, nonce, aad, ct) == pt

    -
    • -
-

The other values in the test vector are intermediate values provided to -facilitate debugging of test failures.

-
-
-cipher_suite: 0x0001
-key: 000102030405060708090a0b0c0d0e0f
-     101112131415161718191a1b1c1d1e1f
-     202122232425262728292a2b2c2d2e2f
-enc_key: 000102030405060708090a0b0c0d0e0f
-auth_key: 101112131415161718191a1b1c1d1e1f
-          202122232425262728292a2b2c2d2e2f
-nonce: 101112131415161718191a1b
-aad: 4945544620534672616d65205747
-pt: 64726166742d696574662d736672616d
-    652d656e63
-ct: 6339af04ada1d064688a442b8dc69d5b
-    6bfa40f4bef0583e8081069cc60705
-
-
-
-
-cipher_suite: 0x0002
-key: 000102030405060708090a0b0c0d0e0f
-     101112131415161718191a1b1c1d1e1f
-     202122232425262728292a2b2c2d2e2f
-enc_key: 000102030405060708090a0b0c0d0e0f
-auth_key: 101112131415161718191a1b1c1d1e1f
-          202122232425262728292a2b2c2d2e2f
-nonce: 101112131415161718191a1b
-aad: 4945544620534672616d65205747
-pt: 64726166742d696574662d736672616d
-    652d656e63
-ct: 6339af04ada1d064688a442b8dc69d5b
-    6bfa40f4be6e93b7da076927bb
-
-
-
-
-cipher_suite: 0x0003
-key: 000102030405060708090a0b0c0d0e0f
-     101112131415161718191a1b1c1d1e1f
-     202122232425262728292a2b2c2d2e2f
-enc_key: 000102030405060708090a0b0c0d0e0f
-auth_key: 101112131415161718191a1b1c1d1e1f
-          202122232425262728292a2b2c2d2e2f
-nonce: 101112131415161718191a1b
-aad: 4945544620534672616d65205747
-pt: 64726166742d696574662d736672616d
-    652d656e63
-ct: 6339af04ada1d064688a442b8dc69d5b
-    6bfa40f4be09480509
-
-
-
-
-
-
-

-D.3. SFrame encryption/decryption -

-

For each case, we provide:

-
    -
  • -

    cipher_suite: The index of the cipher suite in use (see -Section 8.1)

    -
    • -
  • -

    kid: A KID value

    -
    • -
  • -

    ctr: A CTR value

    -
    • -
  • -

    base_key: The base_key input to the derive_key_salt algorithm

    -
    • -
  • -

    sframe_key_label: The label used to derive sframe_key in the derive_key_salt algorithm

    -
    • -
  • -

    sframe_salt_label: The label used to derive sframe_salt in the derive_key_salt algorithm

    -
    • -
  • -

    sframe_secret: The sframe_secret variable in the derive_key_salt algorithm

    -
    • -
  • -

    sframe_key: The sframe_key value produced by the derive_key_salt algorithm

    -
    • -
  • -

    sframe_salt: The sframe_salt value produced by the derive_key_salt algorithm

    -
    • -
  • -

    metadata: The metadata input to the SFrame encrypt algorithm

    -
    • -
  • -

    pt: The plaintext

    -
    • -
  • -

    ct: The SFrame ciphertext

    -
    • -
-

An implementation should verify that the following are true, where -encrypt and decrypt are as defined in Section 4.4, using an SFrame -context initialized with base_key assigned to kid:

-
    -
  • -

    encrypt(ctr, kid, metadata, plaintext) == ct

    -
    • -
  • -

    decrypt(metadata, ct) == pt

    -
    • -
-

The other values in the test vector are intermediate values provided to -facilitate debugging of test failures.

-
-
-cipher_suite: 0x0001
-kid: 0x0000000000000123
-ctr: 0x0000000000004567
-base_key: 000102030405060708090a0b0c0d0e0f
-sframe_key_label: 534672616d6520312e30205365637265
-                  74206b65792000000000000001230001
-sframe_salt_label: 534672616d6520312e30205365637265
-                   742073616c7420000000000000012300
-                   01
-sframe_secret: d926952ca8b7ec4a95941d1ada3a5203
-               ceff8cceee34f574d23909eb314c40c0
-sframe_key: 3f7d9a7c83ae8e1c8a11ae695ab59314
-            b367e359fadac7b9c46b2bc6f81f46e1
-            6b96f0811868d59402b7e870102720b3
-sframe_salt: 50b29329a04dc0f184ac3168
-metadata: 4945544620534672616d65205747
-nonce: 50b29329a04dc0f184ac740f
-aad: 99012345674945544620534672616d65
-     205747
-pt: 64726166742d696574662d736672616d
-    652d656e63
-ct: 9901234567449408b6f490086165b9d6
-    f62b24ae1a59a56486b4ae8ed036b889
-    12e24f11
-
-
-
-
-cipher_suite: 0x0002
-kid: 0x0000000000000123
-ctr: 0x0000000000004567
-base_key: 000102030405060708090a0b0c0d0e0f
-sframe_key_label: 534672616d6520312e30205365637265
-                  74206b65792000000000000001230002
-sframe_salt_label: 534672616d6520312e30205365637265
-                   742073616c7420000000000000012300
-                   02
-sframe_secret: d926952ca8b7ec4a95941d1ada3a5203
-               ceff8cceee34f574d23909eb314c40c0
-sframe_key: e2ec5c797540310483b16bf6e7a570d2
-            a27d192fe869c7ccd8584a8d9dab9154
-            9fbe553f5113461ec6aa83bf3865553e
-sframe_salt: e68ac8dd3d02fbcd368c5577
-metadata: 4945544620534672616d65205747
-nonce: e68ac8dd3d02fbcd368c1010
-aad: 99012345674945544620534672616d65
-     205747
-pt: 64726166742d696574662d736672616d
-    652d656e63
-ct: 99012345673f31438db4d09434e43afa
-    0f8a2f00867a2be085046a9f5cb4f101
-    d607
-
-
-
-
-cipher_suite: 0x0003
-kid: 0x0000000000000123
-ctr: 0x0000000000004567
-base_key: 000102030405060708090a0b0c0d0e0f
-sframe_key_label: 534672616d6520312e30205365637265
-                  74206b65792000000000000001230003
-sframe_salt_label: 534672616d6520312e30205365637265
-                   742073616c7420000000000000012300
-                   03
-sframe_secret: d926952ca8b7ec4a95941d1ada3a5203
-               ceff8cceee34f574d23909eb314c40c0
-sframe_key: 2c5703089cbb8c583475e4fc461d97d1
-            8809df79b6d550f78eb6d50ffa80d892
-            11d57909934f46f5405e38cd583c69fe
-sframe_salt: 38c16e4f5159700c00c7f350
-metadata: 4945544620534672616d65205747
-nonce: 38c16e4f5159700c00c7b637
-aad: 99012345674945544620534672616d65
-     205747
-pt: 64726166742d696574662d736672616d
-    652d656e63
-ct: 990123456717fc8af28a5a695afcfc6c
-    8df6358a17e26b2fcb3bae32e443
-
-
-
-
-cipher_suite: 0x0004
-kid: 0x0000000000000123
-ctr: 0x0000000000004567
-base_key: 000102030405060708090a0b0c0d0e0f
-sframe_key_label: 534672616d6520312e30205365637265
-                  74206b65792000000000000001230004
-sframe_salt_label: 534672616d6520312e30205365637265
-                   742073616c7420000000000000012300
-                   04
-sframe_secret: d926952ca8b7ec4a95941d1ada3a5203
-               ceff8cceee34f574d23909eb314c40c0
-sframe_key: d34f547f4ca4f9a7447006fe7fcbf768
-sframe_salt: 75234edefe07819026751816
-metadata: 4945544620534672616d65205747
-nonce: 75234edefe07819026755d71
-aad: 99012345674945544620534672616d65
-     205747
-pt: 64726166742d696574662d736672616d
-    652d656e63
-ct: 9901234567b7412c2513a1b66dbb4884
-    1bbaf17f598751176ad847681a69c6d0
-    b091c07018ce4adb34eb
-
-
-
-
-cipher_suite: 0x0005
-kid: 0x0000000000000123
-ctr: 0x0000000000004567
-base_key: 000102030405060708090a0b0c0d0e0f
-sframe_key_label: 534672616d6520312e30205365637265
-                  74206b65792000000000000001230005
-sframe_salt_label: 534672616d6520312e30205365637265
-                   742073616c7420000000000000012300
-                   05
-sframe_secret: 0fc3ea6de6aac97a35f194cf9bed94d4
-               b5230f1cb45a785c9fe5dce9c188938a
-               b6ba005bc4c0a19181599e9d1bcf7b74
-               aca48b60bf5e254e546d809313e083a3
-sframe_key: d3e27b0d4a5ae9e55df01a70e6d4d28d
-            969b246e2936f4b7a5d9b494da6b9633
-sframe_salt: 84991c167b8cd23c93708ec7
-metadata: 4945544620534672616d65205747
-nonce: 84991c167b8cd23c9370cba0
-aad: 99012345674945544620534672616d65
-     205747
-pt: 64726166742d696574662d736672616d
-    652d656e63
-ct: 990123456794f509d36e9beacb0e261d
-    99c7d1e972f1fed787d4049f17ca2135
-    3c1cc24d56ceabced279
-
-
-
-
-
-
-
-
-

-Contributors -

-
-
Frederic Jacobs
-
Apple
- -
-
-
Marta Mularczyk
-
Amazon
- -
-
-
Suhas Nandakumar
-
Cisco
- -
-
-
Tomas Rigaux
-
Cisco
- -
-
-
Raphael Robert
-
Phoenix R&D
- -
-
-
-
-
-

-Authors' Addresses -

-
-
Emad Omara
-
Apple
- -
-
-
Justin Uberti
-
Google
- -
-
-
Sergio Garcia Murillo
-
CoSMo Software
- -
-
-
Richard L. Barnes (editor)
-
Cisco
- -
-
-
Youenn Fablet
-
Apple
- -
-
-
- - - diff --git a/artart-iana/draft-ietf-sframe-enc.txt b/artart-iana/draft-ietf-sframe-enc.txt deleted file mode 100644 index a3da983..0000000 --- a/artart-iana/draft-ietf-sframe-enc.txt +++ /dev/null @@ -1,3186 +0,0 @@ - - - - -Network Working Group E. Omara -Internet-Draft Apple -Intended status: Standards Track J. Uberti -Expires: 17 August 2024 Google - S. Murillo - CoSMo Software - R. L. Barnes, Ed. - Cisco - Y. Fablet - Apple - 14 February 2024 - - - Secure Frame (SFrame) - draft-ietf-sframe-enc-latest - -Abstract - - This document describes the Secure Frame (SFrame) end-to-end - encryption and authentication mechanism for media frames in a - multiparty conference call, in which central media servers (selective - forwarding units or SFUs) can access the media metadata needed to - make forwarding decisions without having access to the actual media. - - The proposed mechanism differs from the Secure Real-Time Protocol - (SRTP) in that it is independent of RTP (thus compatible with non-RTP - media transport) and can be applied to whole media frames in order to - be more bandwidth efficient. - -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://sframe- - wg.github.io/sframe/draft-ietf-sframe-enc.html. Status information - for this document may be found at https://datatracker.ietf.org/doc/ - draft-ietf-sframe-enc/. - - Discussion of this document takes place on the Secure Media Frames - Working Group mailing list (mailto:sframe@ietf.org), which is - archived at https://mailarchive.ietf.org/arch/browse/sframe/. - Subscribe at https://www.ietf.org/mailman/listinfo/sframe/. - - Source for this draft and an issue tracker can be found at - https://github.com/sframe-wg/sframe. - -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 17 August 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. Goals - 4. SFrame - 4.1. Application Context - 4.2. SFrame Ciphertext - 4.3. SFrame Header - 4.4. Encryption Schema - 4.4.1. Key Selection - 4.4.2. Key Derivation - 4.4.3. Encryption - 4.4.4. Decryption - 4.5. Cipher Suites - 4.5.1. AES-CTR with SHA2 - 5. Key Management - 5.1. Sender Keys - 5.2. MLS - 6. Media Considerations - 6.1. Selective Forwarding Units - 6.1.1. LastN and RTP stream reuse - 6.1.2. Simulcast - 6.1.3. SVC - 6.2. Video Key Frames - 6.3. Partial Decoding - 7. Security Considerations - 7.1. No Header Confidentiality - 7.2. No Per-Sender Authentication - 7.3. Key Management - 7.4. Replay - 7.5. Risks due to Short Tags - 8. IANA Considerations - 8.1. SFrame Cipher Suites - 9. Application Responsibilities - 9.1. Header Value Uniqueness - 9.2. Key Management Framework - 9.3. Anti-Replay - 9.4. Metadata - 10. References - 10.1. Normative References - 10.2. Informative References - Appendix A. Acknowledgements - Appendix B. Example API - Appendix C. Overhead Analysis - C.1. Assumptions - C.2. Audio - C.3. Video - C.4. Conferences - C.5. SFrame over RTP - Appendix D. Test Vectors - D.1. Header encoding/decoding - D.2. AEAD encryption/decryption using AES-CTR and HMAC - D.3. SFrame encryption/decryption - Contributors - Authors' Addresses - -1. Introduction - - Modern multi-party video call systems use Selective Forwarding Unit - (SFU) servers to efficiently route media streams to call endpoints - based on factors such as available bandwidth, desired video size, - codec support, and other factors. An SFU typically does not need - access to the media content of the conference, allowing for the media - to be "end-to-end" encrypted so that it cannot be decrypted by the - SFU. In order for the SFU to work properly, though, it usually needs - to be able to access RTP metadata and RTCP feedback messages, which - is not possible if all RTP/RTCP traffic is end-to-end encrypted. - - As such, two layers of encryption and authentication are required: - - 1. Hop-by-hop (HBH) encryption of media, metadata, and feedback - messages between the the endpoints and SFU - - 2. End-to-end (E2E) encryption (E2EE) of media between the endpoints - - The Secure Real-Time Protocol (SRTP) is already widely used for HBH - encryption [RFC3711]. The SRTP "double encryption" scheme defines a - way to do E2E encryption in SRTP [RFC8723]. Unfortunately, this - scheme has poor efficiency and high complexity, and its entanglement - with RTP makes it unworkable in several realistic SFU scenarios. - - This document proposes a new E2EE protection scheme known as SFrame, - specifically designed to work in group conference calls with SFUs. - SFrame is a general encryption framing that can be used to protect - media payloads, agnostic of transport. - -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. - - MAC: Message Authentication Code - - E2EE: End to End Encryption - - HBH: Hop By Hop - - We use "Selective Forwarding Unit (SFU)" and "media stream" in a less - formal sense than in [RFC7656]. An SFU is a selective switching - function for media payloads, and a media stream a sequence of media - payloads, in both cases regardless of whether those media payloads - are transported over RTP or some other protocol. - -3. Goals - - SFrame is designed to be a suitable E2EE protection scheme for - conference call media in a broad range of scenarios, as outlined by - the following goals: - - 1. Provide a secure E2EE mechanism for audio and video in conference - calls that can be used with arbitrary SFU servers. - - 2. Decouple media encryption from key management to allow SFrame to - be used with an arbitrary key management system. - - 3. Minimize packet expansion to allow successful conferencing in as - many network conditions as possible. - - 4. Independence from the underlying transport, including use in non- - RTP transports, e.g., WebTransport [I-D.ietf-webtrans-overview]. - - 5. When used with RTP and its associated error resilience - mechanisms, i.e., RTX and FEC, require no special handling for - RTX and FEC packets. - - 6. Minimize the changes needed in SFU servers. - - 7. Minimize the changes needed in endpoints. - - 8. Work with the most popular audio and video codecs used in - conferencing scenarios. - -4. SFrame - - This document defines an encryption mechanism that provides effective - E2EE, is simple to implement, has no dependencies on RTP, and - minimizes encryption bandwidth overhead. This section describes how - the mechanism works, including details of how applications utilize - SFrame for media protection, as well as the actual mechanics of E2EE - for protecting media. - -4.1. Application Context - - SFrame is a general encryption framing, intended to be used as an - E2EE layer over an underlying HBH-encrypted transport such as SRTP or - QUIC [RFC3711][I-D.ietf-moq-transport]. - - The scale at which SFrame encryption is applied to media determines - the overall amount of overhead that SFrame adds to the media stream, - as well as the engineering complexity involved in integrating SFrame - into a particular environment. Two patterns are common: Either using - SFrame to encrypt whole media frames (per-frame) or individual - transport-level media payloads (per-packet). - - For example, Figure 1 shows a typical media sender stack that takes - media from some source, encodes it into frames, divides those frames - into media packets, and then sends those payloads in SRTP packets. - The receiver stack performs the reverse operations, reassembling - frames from SRTP packets and decoding. Arrows indicate two different - ways that SFrame protection could be integrated into this media - stack, to encrypt whole frames or individual media packets. - - Applying SFrame per-frame in this system offers higher efficiency, - but may require a more complex integration in environments where - depacketization relies on the content of media packets. Applying - SFrame per-packet avoids this complexity, at the cost of higher - bandwidth consumption. Some quantitative discussion of these trade- - offs is provided in Appendix C. - - As noted above, however, SFrame is a general media encapsulation, and - can be applied in other scenarios. The important thing is that the - sender and receivers of an SFrame-encrypted object agree on that - object's semantics. SFrame does not provide this agreement; it must - be arranged by the application. - - +------------------------------------------------------+ - | | - | +--------+ +-------------+ +-----------+ | - .-. | | | | | | HBH | | -| | | | Encode |----->| Packetize |----->| Protect |----------+ - '+' | | | ^ | | ^ | | | | - /|\ | +--------+ | +-------------+ | +-----------+ | | -/ + \ | | | ^ | | - / \ | SFrame SFrame | | | -/ \ | Protect Protect | | | -Alice | (per-frame) (per-packet) | | | - | ^ ^ | | | - | | | | | | - +---------------|-------------------|---------|--------+ | - | | | v - | | | +------+-+ - | E2E Key | HBH Key | Media | - +---- Management ---+ Management | Server | - | | | +------+-+ - | | | | - +---------------|-------------------|---------|--------+ | - | | | | | | - | V V | | | - .-. | SFrame SFrame | | | -| | | Unprotect Unprotect | | | - '+' | (per-frame) (per-packet) | | | - /|\ | | | V | | -/ + \ | +--------+ | +-------------+ | +-----------+ | | - / \ | | | V | | V | HBH | | | -/ \ | | Decode |<-----| Depacketize |<-----| Unprotect |<---------+ - Bob | | | | | | | | - | +--------+ +-------------+ +-----------+ | - | | - +------------------------------------------------------+ - - Figure 1 - - Like SRTP, SFrame does not define how the keys used for SFrame are - exchanged by the parties in the conference. Keys for SFrame might be - distributed over an existing E2E-secure channel (see Section 5.1), or - derived from an E2E-secure shared secret (see Section 5.2). The key - management system MUST ensure that each key used for encrypting media - is used by exactly one media sender, in order to avoid reuse of - nonces. - -4.2. SFrame Ciphertext - - An SFrame ciphertext comprises an SFrame header followed by the - output of an AEAD encryption of the plaintext [RFC5116], with the - header provided as additional authenticated data (AAD). - - The SFrame header is a variable-length structure described in detail - in Section 4.3. The structure of the encrypted data and - authentication tag are determined by the AEAD algorithm in use. - - +-+----+-+----+--------------------+--------------------+<-+ - |K|KLEN|C|CLEN| Key ID | Counter | | - +->+-+----+-+----+--------------------+--------------------+ | - | | | | - | | | | - | | | | - | | | | - | | Encrypted Data | | - | | | | - | | | | - | | | | - | | | | - +->+-------------------------------------------------------+<-+ - | | Authentication Tag | | - | +-------------------------------------------------------+ | - | | - | | - +--- Encrypted Portion Authenticated Portion ---+ - - When SFrame is applied per-packet, the payload of each packet will be - an SFrame ciphertext. When SFrame is applied per-frame, the SFrame - ciphertext representing an encrypted frame will span several packets, - with the header appearing in the first packet and the authentication - tag in the last packet. It is the responsibility of the application - to reassemble an encrypted frame from individual packets, accounting - for packet loss and reordering as necessary. - -4.3. SFrame Header - - The SFrame header specifies two values from which encryption - parameters are derived: - - * A Key ID (KID) that determines which encryption key should be used - - * A counter (CTR) that is used to construct the nonce for the - encryption - - Applications MUST ensure that each (KID, CTR) combination is used for - exactly one SFrame encryption operation. A typical approach to - achieving this guarantee is outlined in Section 9.1. - - Config Byte - | - .-----' '-----. - | | - 0 1 2 3 4 5 6 7 - +-+-+-+-+-+-+-+-+------------+------------+ - |X| K |Y| C | KID... | CTR... | - +-+-+-+-+-+-+-+-+------------+------------+ - - Figure 2: SFrame header - - The SFrame Header has the overall structure shown in Figure 2. The - first byte is a "config byte", with the following fields: - - Extended Key Id Flag (X, 1 bit): Indicates if the K field contains - the key id or the Key ID length. - - Key or Key Length (K, 3 bits): This field contains the Key ID (KID) - if the X flag is set to 0, or the key id length, minus one, if set - to 1. - - Extended Counter Flag (Y, 1 bit): Indicates if the C field contains - the counter or the counter length. - - Counter or Counter Length (C, 3 bits): This field contains the - counter (CTR) if the Y flag is set to 0, or the counter length, - minus one, if set to 1. - - The Key ID and Counter fields are encoded as compact unsigned - integers in network (big-endian) byte order. If the value of one of - these fields is in the range 0-7, then the value is carried in the - corresponding bits of the config byte (K or C) and the corresponding - flag (X or Y) is set to zero. Otherwise, the value MUST be encoded - with the minimum number of bytes required and appended after the - configuration byte, with the Key ID first and Counter second. The - header field (K or C) is set to the number of bytes in the encoded - value, minus one. The value 000 represents a length of 1, 001 a - length of 2, etc. This allows a 3-bit length field to represent the - value lengths 1-8. - - The SFrame header can thus take one of the four forms shown in - Figure 3, depending on which of the X and Y flags are set. - - KID < 8, CTR < 8: - +-+-----+-+-----+ - |0| KID |0| CTR | - +-+-----+-+-----+ - - KID < 8, CTR >= 8: - +-+-----+-+-----+------------------------+ - |0| KID |1|CLEN | CTR... (length=CLEN) | - +-+-----+-+-----+------------------------+ - - KID >= 8, CTR < 8: - +-+-----+-+-----+------------------------+ - |1|KLEN |0| CTR | KID... (length=KLEN) | - +-+-----+-+-----+------------------------+ - - KID >= 8, CTR >= 8: - +-+-----+-+-----+------------------------+------------------------+ - |1|KLEN |1|CLEN | KID... (length=KLEN) | CTR... (length=CLEN) | - +-+-----+-+-----+------------------------+------------------------+ - - Figure 3: Forms of Encoded SFrame Header - -4.4. Encryption Schema - - SFrame encryption uses an AEAD encryption algorithm and hash function - defined by the cipher suite in use (see Section 4.5). We will refer - to the following aspects of the AEAD and the hash algorithm below: - - * AEAD.Encrypt and AEAD.Decrypt - The encryption and decryption - functions for the AEAD. We follow the convention of RFC 5116 - [RFC5116] and consider the authentication tag part of the - ciphertext produced by AEAD.Encrypt (as opposed to a separate - field as in SRTP [RFC3711]). - - * AEAD.Nk - The size in bytes of a key for the encryption algorithm - - * AEAD.Nn - The size in bytes of a nonce for the encryption - algorithm - - * AEAD.Nt - The overhead in bytes of the encryption algorithm - (typically the size of a "tag" that is added to the plaintext) - - * AEAD.Nka - For cipher suites using the compound AEAD described in - Section 4.5.1, the size in bytes of a key for the underlying AES- - CTR algorithm - - * Hash.Nh - The size in bytes of the output of the hash function - -4.4.1. Key Selection - - Each SFrame encryption or decryption operation is premised on a - single secret base_key, which is labeled with an integer KID value - signaled in the SFrame header. - - The sender and receivers need to agree on which key should be used - for a given KID. Moreover, senders and receivers need to agree on - whether keys will be used for encryption or decryption only. The - process for provisioning keys and their KID values is beyond the - scope of this specification, but its security properties will bound - the assurances that SFrame provides. For example, if SFrame is used - to provide E2E security against intermediary media nodes, then SFrame - keys need to be negotiated in a way that does not make them - accessible to these intermediaries. - - For each known KID value, the client stores the corresponding - symmetric key base_key. For keys that can be used for encryption, - the client also stores the next counter value CTR to be used when - encrypting (initially 0). - - When encrypting a plaintext, the application specifies which KID is - to be used, and the counter is incremented after successful - encryption. When decrypting, the base_key for decryption is selected - from the available keys using the KID value in the SFrame Header. - - A given key MUST NOT be used for encryption by multiple senders. - Such reuse would result in multiple encrypted frames being generated - with the same (key, nonce) pair, which harms the protections provided - by many AEAD algorithms. Implementations SHOULD mark each key as - usable for encryption or decryption, never both. - - Note that the set of available keys might change over the lifetime of - a real-time session. In such cases, the client will need to manage - key usage to avoid media loss due to a key being used to encrypt - before all receivers are able to use it to decrypt. For example, an - application may make decryption-only keys available immediately, but - delay the use of keys for encryption until (a) all receivers have - acknowledged receipt of the new key or (b) a timeout expires. - -4.4.2. Key Derivation - - SFrame encrytion and decryption use a key and salt derived from the - base_key associated to a KID. Given a base_key value, the key and - salt are derived using HKDF [RFC5869] as follows: - - def derive_key_salt(KID, base_key): - sframe_secret = HKDF-Extract("", base_key) - - sframe_key_label = "SFrame 1.0 Secret key " + KID + cipher_suite - sframe_key = HKDF-Expand(sframe_secret, info, AEAD.Nk) - - sframe_salt_label = "SFrame 1.0 Secret salt " + KID + cipher_suite - sframe_salt = HKDF-Expand(sframe_secret, info, AEAD.Nn) - - return sframe_key, sframe_salt - - In the derivation of sframe_secret: - - * The + operator represents concatenation of byte strings. - - * The KID value is encoded as an 8-byte big-endian integer, not the - compressed form used in the SFrame header. - - * The cipher_suite value is a 2-byte big-endian integer representing - the cipher suite in use (see Section 8.1). - - The hash function used for HKDF is determined by the cipher suite in - use. - -4.4.3. Encryption - - SFrame encryption uses the AEAD encryption algorithm for the cipher - suite in use. The key for the encryption is the sframe_key and the - nonce is formed by XORing the sframe_salt with the current counter, - encoded as a big-endian integer of length AEAD.Nn. - - The encryptor forms an SFrame header using the CTR, and KID values - provided. The encoded header is provided as AAD to the AEAD - encryption operation, together with application-provided metadata - about the encrypted media (see Section 9.4). - - def encrypt(CTR, KID, metadata, plaintext): - sframe_key, sframe_salt = key_store[KID] - - ctr = encode_big_endian(CTR, AEAD.Nn) - nonce = xor(sframe_salt, CTR) - - header = encode_sframe_header(CTR, KID) - aad = header + metadata - - ciphertext = AEAD.Encrypt(sframe_key, nonce, aad, plaintext) - return header + ciphertext - - For example, the metadata input to encryption allows for frame - metadata to be authenticated when SFrame is applied per-frame. After - encoding the frame and before packetizing it, the necessary media - metadata will be moved out of the encoded frame buffer, to be sent in - some channel visible to the SFU (e.g., an RTP header extension). - - +---------------+ - | | - | | - | plaintext | - | | - | | - +-------+-------+ - | - .- +-----+ | - | | +--+--> sframe_key ----->| Key - Header | | KID | | | - | | | +--> sframe_salt --+ | - +--+ +-----+ | | - | | | +---------------------+->| Nonce - | | | CTR | | - | | | | | - | '- +-----+ | - | | - | +----------------+ | - | | metadata | | - | +-------+--------+ | - | | | - +------------------+----------------->| AAD - | | - | AEAD.Encrypt - | | - | SFrame Ciphertext | - | +---------------+ | - +-------------->| SFrame Header | | - +---------------+ | - | | | - | |<----+ - | ciphertext | - | | - | | - +---------------+ - - Figure 4: Encrypting an SFrame Ciphertext - -4.4.4. Decryption - - Before decrypting, a receiver needs to assemble a full SFrame - ciphertext. When an SFrame ciphertext may be fragmented into - multiple parts for transport (e.g., a whole encrypted frame sent in - multiple SRTP packets), the receiving client collects all the - fragments of the ciphertext, using an appropriate sequencing and - start/end markers in the transport. Once all of the required - fragments are available, the client reassembles them into the SFrame - ciphertext, then passes the ciphertext to SFrame for decryption. - - The KID field in the SFrame header is used to find the right key and - salt for the encrypted frame, and the CTR field is used to construct - the nonce. The SFrame decryption procedure is as follows: - - def decrypt(metadata, sframe_ciphertext): - KID, CTR, header, ciphertext = parse_ciphertext(sframe_ciphertext) - - sframe_key, sframe_salt = key_store[KID] - - ctr = encode_big_endian(CTR, AEAD.Nn) - nonce = xor(sframe_salt, ctr) - aad = header + metadata - - return AEAD.Decrypt(sframe_key, nonce, aad, ciphertext) - - If a ciphertext fails to decrypt because there is no key available - for the KID in the SFrame 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 ciphertexts SHOULD be discarded - in a way that is indistinguishable (to an external observer) from - having processed a valid ciphertext. - - SFrame Ciphertext - +---------------+ - +---------------| SFrame Header | - | +---------------+ - | | | - | | |-----+ - | | ciphertext | | - | | | | - | | | | - | +---------------+ | - | | - | .- +-----+ | - | | | +--+--> sframe_key ----->| Key - | | | KID | | | - | | | | +--> sframe_salt --+ | - +->+ +-----+ | | - | | | +---------------------+->| Nonce - | | | CTR | | - | | | | | - | '- +-----+ | - | | - | +----------------+ | - | | metadata | | - | +-------+--------+ | - | | | - +------------------+----------------->| AAD - | - AEAD.Decrypt - | - V - +---------------+ - | | - | | - | plaintext | - | | - | | - +---------------+ - - Figure 5: Decrypting an SFrame Ciphertext - -4.5. Cipher Suites - - Each SFrame session uses a single cipher suite that specifies the - following primitives: - - * A hash function used for key derivation - - * An AEAD encryption algorithm [RFC5116] used for frame encryption, - optionally with a truncated authentication tag - - This document defines the following cipher suites, with the constants - defined in Section 4.4: - - +============================+====+=====+====+====+====+ - | Name | Nh | Nka | Nk | Nn | Nt | - +============================+====+=====+====+====+====+ - | AES_128_CTR_HMAC_SHA256_80 | 32 | 16 | 48 | 12 | 10 | - +----------------------------+----+-----+----+----+----+ - | AES_128_CTR_HMAC_SHA256_64 | 32 | 16 | 48 | 12 | 8 | - +----------------------------+----+-----+----+----+----+ - | AES_128_CTR_HMAC_SHA256_32 | 32 | 16 | 48 | 12 | 4 | - +----------------------------+----+-----+----+----+----+ - | AES_128_GCM_SHA256_128 | 32 | n/a | 16 | 12 | 16 | - +----------------------------+----+-----+----+----+----+ - | AES_256_GCM_SHA512_128 | 64 | n/a | 32 | 12 | 16 | - +----------------------------+----+-----+----+----+----+ - - Table 1: SFrame cipher suite constants - - Numeric identifiers for these cipher suites are defined in the IANA - registry created in Section 8.1. - - In the suite names, the length of the authentication tag is indicated - by the last value: "_128" indicates a hundred-twenty-eight-bit tag, - "_80" indicates a eighty-bit tag, "_64" indicates a sixty-four-bit - tag and "_32" indicates a thirty-two-bit tag. - - In a session that uses multiple media streams, different cipher - suites might be configured for different media streams. For example, - in order to conserve bandwidth, a session might use a cipher suite - with eighty-bit tags for video frames and another cipher suite with - thirty-two-bit tags for audio frames. - -4.5.1. AES-CTR with SHA2 - - In order to allow very short tag sizes, we define a synthetic AEAD - function using the authenticated counter mode of AES together with - HMAC for authentication. We use an encrypt-then-MAC approach, as in - SRTP [RFC3711]. - - Before encryption or decryption, encryption and authentication - subkeys are derived from the single AEAD key. The overall length of - the AEAD key is Nka + Nh, where Nka represents the key size for the - AES block cipher in use and Nh represents the output size of the hash - function (as in Table 2). The encryption subkey comprises the first - Nka bytes and the authentication subkey comprises the remaining Nh - bytes. - - def derive_subkeys(sframe_key): - enc_key = sframe_key[..Nka] - auth_key = sframe_key[Nka..] - return enc_key, auth_key - - The AEAD encryption and decryption functions are then composed of - individual calls to the CTR encrypt function and HMAC. The resulting - MAC value is truncated to a number of bytes Nt fixed by the cipher - suite. - - def truncate(tag, n): - # Take the first `n` bytes of `tag` - return tag[..n] - - def compute_tag(auth_key, nonce, aad, ct): - aad_len = encode_big_endian(len(aad), 8) - ct_len = encode_big_endian(len(ct), 8) - tag_len = encode_big_endian(Nt, 8) - auth_data = aad_len + ct_len + tag_len + nonce + aad + ct - tag = HMAC(auth_key, auth_data) - return truncate(tag, Nt) - - def AEAD.Encrypt(key, nonce, aad, pt): - enc_key, auth_key = derive_subkeys(key) - initial_counter = nonce + 0x00000000 # append four zero bytes - ct = AES-CTR.Encrypt(enc_key, initial_counter, pt) - tag = compute_tag(auth_key, nonce, aad, ct) - return ct + tag - - def AEAD.Decrypt(key, nonce, aad, ct): - inner_ct, tag = split_ct(ct, tag_len) - - enc_key, auth_key = derive_subkeys(key) - candidate_tag = compute_tag(auth_key, nonce, aad, inner_ct) - if !constant_time_equal(tag, candidate_tag): - raise Exception("Authentication Failure") - - initial_counter = nonce + 0x00000000 # append four zero bytes - return AES-CTR.Decrypt(enc_key, initial_counter, inner_ct) - -5. Key Management - - SFrame must be integrated with an E2E key management framework to - exchange and rotate the keys used for SFrame encryption. The key - management framework provides the following functions: - - * Provisioning KID / base_key mappings to participating clients - - * Updating the above data as clients join or leave - - It is the responsibility of the application to provide the key - management framework, as described in Section 9.2. - -5.1. Sender Keys - - If the participants in a call have a pre-existing E2E-secure channel, - they can use it to distribute SFrame keys. Each client participating - in a call generates a fresh base_key value that it will use to - encrypt media. The client then uses the E2E-secure channel to send - their encryption key to the other participants. - - In this scheme, it is assumed that receivers have a signal outside of - SFrame for which client has sent a given frame (e.g., an RTP SSRC). - SFrame KID values are then used to distinguish between versions of - the sender's base_key. - - Key IDs in this scheme have two parts, a "key generation" and a - "ratchet step". Both are unsigned integers that begin at zero. The - key generation increments each time the sender distributes a new key - to receivers. The "ratchet step" is incremented each time the sender - ratchets their key forward for forward secrecy: - - base_key[i+1] = HKDF-Expand( - HKDF-Extract("", base_key[i]), - "SFrame 1.0 Ratchet", CipherSuite.Nh) - - For compactness, we do not send the whole ratchet step. Instead, we - send only its low-order R bits, where R is a value set by the - application. Different senders may use different values of R, but - each receiver of a given sender needs to know what value of R is used - by the sender so that they can recognize when they need to ratchet - (vs. expecting a new key). R effectively defines a re-ordering - window, since no more than 2^R ratchet steps can be active at a given - time. The key generation is sent in the remaining 64 - R bits of the - key ID. - - KID = (key_generation << R) + (ratchet_step % (1 << R)) - - 64-R bits R bits - <---------------> <------------> - +-----------------+--------------+ - | Key Generation | Ratchet Step | - +-----------------+--------------+ - - Figure 6: Structure of a KID in the Sender Keys scheme - - The sender signals such a ratchet step update by sending with a KID - value in which the ratchet step has been incremented. A receiver who - receives from a sender with a new KID computes the new key as above. - The old key may be kept for some time to allow for out-of-order - delivery, but should be deleted promptly. - - If a new participant joins in the middle of a session, they will need - to receive from each sender (a) the current sender key for that - sender and (b) the current KID value for the sender. Evicting a - participant requires each sender to send a fresh sender key to all - receivers. - - It is up to the application to decide when sender keys are updated. - A sender key may be updated by sending a new base_key (updating the - key generation) or by hashing the current base_key (updating the - ratchet step). Ratcheting the key forward is useful when adding new - receivers to an SFrame-based interaction, since it assures that the - new receivers can't decrypt any media encrypted before they were - added. If a sender wishes to assure the opposite property when - removing a receiver (i.e., ensuring that the receiver can't decrypt - media after they are removed), then the sender will need to - distribute a new sender key. - -5.2. MLS - - The Messaging Layer Security (MLS) protocol provides group - authenticated key exchange [MLS-ARCH] [MLS-PROTO]. In principle, it - could be used to instantiate the sender key scheme above, but it can - also be used more efficiently directly. - - MLS creates a linear sequence of keys, each of which is shared among - the members of a group at a given point in time. When a member joins - or leaves the group, a new key is produced that is known only to the - augmented or reduced group. Each step in the lifetime of the group - is known as an "epoch", and each member of the group is assigned an - "index" that is constant for the time they are in the group. - - To generate keys and nonces for SFrame, we use the MLS exporter - function to generate a base_key value for each MLS epoch. Each - member of the group is assigned a set of KID values, so that each - member has a unique sframe_key and sframe_salt that it uses to - encrypt with. Senders may choose any KID value within their assigned - set of KID values, e.g., to allow a single sender to send multiple - uncoordinated outbound media streams. - - base_key = MLS-Exporter("SFrame 1.0 Base Key", "", AEAD.Nk) - - For compactness, we do not send the whole epoch number. Instead, we - send only its low-order E bits, where E is a value set by the - application. E effectively defines a re-ordering window, since no - more than 2^E epochs can be active at a given time. Receivers MUST - be prepared for the epoch counter to roll over, removing an old epoch - when a new epoch with the same E lower bits is introduced. - - Let S be the number of bits required to encode a member index in the - group, i.e., the smallest value such that group_size <= (1 << S). - The sender index is encoded in the S bits above the epoch. The - remaining 64 - S - E bits of the KID value are a context value chosen - by the sender (context value 0 will produce the shortest encoded - KID). - - KID = (context << (S + E)) + (sender_index << E) + (epoch % (1 << E)) - - 64-S-E bits S bits E bits - <-----------> <------> <------> - +-------------+--------+-------+ - | Context ID | Index | Epoch | - +-------------+--------+-------+ - - Figure 7: Structure of a KID for an MLS Sender - - Once an SFrame stack has been provisioned with the - sframe_epoch_secret for an epoch, it can compute the required KID - values on demand (as well as the resulting SFrame keys/nonces derived - from the base_key and KID), as it needs to encrypt or decrypt for a - given member. - - ... - | - | - Epoch 14 +--+-- index=3 ---> KID = 0x3e - | | - | +-- index=7 ---> KID = 0x7e - | | - | +-- index=20 --> KID = 0x14e - | - | - Epoch 15 +--+-- index=3 ---> KID = 0x3f - | | - | +-- index=5 ---> KID = 0x5f - | - | - Epoch 16 +----- index=2 --+--> context = 2 --> KID = 0x820 - | | - | +--> context = 3 --> KID = 0xc20 - | - | - Epoch 17 +--+-- index=33 --> KID = 0x211 - | | - | +-- index=51 --> KID = 0x331 - | - | - ... - - Figure 8: An example sequence of KIDs for an MLS-based SFrame - session (E=4; S=6, allowing for 64 group members) - -6. Media Considerations - -6.1. Selective Forwarding Units - - Selective Forwarding Units (SFUs) (e.g., those described in - Section 3.7 of [RFC7667]) receive the media streams from each - participant and select which ones should be forwarded to each of the - other participants. There are several approaches for stream - selection, but in general, the SFU needs to access metadata - associated to each frame and modify the RTP information of the - incoming packets when they are transmitted to the received - participants. - - This section describes how this normal SFU modes of operation - interact with the E2EE provided by SFrame. - -6.1.1. LastN and RTP stream reuse - - The SFU may choose to send only a certain number of streams based on - the voice activity of the participants. To avoid the overhead - involved in establishing new transport streams, the SFU may decide to - reuse previously existing streams or even pre-allocate a predefined - number of streams and choose in each moment in time which participant - media will be sent through it. - - This means that in the same transport-level stream (e.g., an RTP - stream defined by either SSRC or MID) may carry media from different - streams of different participants. As different keys are used by - each participant for encoding their media, the receiver will be able - to verify which is the sender of the media coming within the RTP - stream at any given point in time, preventing the SFU trying to - impersonate any of the participants with another participant's media. - - Note that in order to prevent impersonation by a malicious - participant (not the SFU), a mechanism based on digital signature - would be required. SFrame does not protect against such attacks. - -6.1.2. Simulcast - - When using simulcast, the same input image will produce N different - encoded frames (one per simulcast layer) which would be processed - independently by the frame encryptor and assigned an unique counter - for each. - -6.1.3. SVC - - In both temporal and spatial scalability, the SFU may choose to drop - layers in order to match a certain bitrate or forward specific media - sizes or frames per second. In order to support the SFU selectively - removing layers, the sender MUST encapsulate each layer in a - different SFrame ciphertext. - -6.2. Video Key Frames - - Forward Security and Post-Compromise Security require that the E2EE - keys (base keys) are updated any time a participant joins or leaves - the call. - - The key exchange happens asynchronously and on a different path than - the SFU signaling and media. So it may happen that when a new - participant joins the call and the SFU side requests a key frame, the - sender generates the E2EE frame with a key not known by the receiver, - so it will be discarded. When the sender updates his sending key - with the new key, it will send it in a non-key frame, so the receiver - will be able to decrypt it, but not decode it. - - The new Receiver will then re-request a key frame, but due to sender - and SFU policies, that new key frame could take some time to be - generated. - - If the sender sends a key frame after the new E2EE key is in use, the - time required for the new participant to display the video is - minimized. - - Note that this issue does not arise for media streams that do not - have dependencies among frames, e.g., audio streams. In these - streams, each frame is independently decodeable, so there is never a - need to process two frames together which might be on two sides of a - key rotation. - -6.3. Partial Decoding - - Some codecs support partial decoding, where individual packets can be - decoded without waiting for the full frame to arrive. When SFrame is - applied per-frame, this won't be possible because the decoder cannot - access data until an entire frame has arrived and has been decrypted. - -7. Security Considerations - -7.1. No Header Confidentiality - - SFrame provides integrity protection to the SFrame Header (the key ID - and counter values), but does not provide confidentiality protection. - Parties that can observe the SFrame header may learn, for example, - which parties are sending SFrame payloads (from KID values) and at - what rates (from CTR values). In cases where SFrame is used for end- - to-end security on top of hop-by-hop protections (e.g., running over - SRTP as described in Appendix C.5), the hop-by-hop security - mechanisms provide confidentiality protection of the SFrame header - between hops. - -7.2. No Per-Sender Authentication - - SFrame does not provide per-sender authentication of media data. Any - sender in a session can send media that will be associated with any - other sender. This is because SFrame uses symmetric encryption to - protect media data, so that any receiver also has the keys required - to encrypt packets for the sender. - -7.3. Key Management - - Key exchange mechanism is out of scope of this document, however - every client SHOULD change their keys when new clients joins or - leaves the call for forward secrecy and post compromise security. - -7.4. Replay - - The handling of replay is out of the scope of this document. - However, senders MUST reject requests to encrypt multiple times with - the same key and nonce, since several AEAD algorithms fail badly in - such cases (see, e.g., Section 5.1.1 of [RFC5116]). - -7.5. Risks due to Short Tags - - The SFrame ciphersuites based on AES-CTR allow for the use of short - authentication tags, which bring a higher risk that an attacker will - be able to cause an SFrame receiver to accept an SFrame ciphertext of - the attacker's choosing. - - Assuming that the authentication properties of the ciphersuite are - robust, the only attack that an attacker can mount is an attempt to - find an acceptable (ciphertext, tag) combination through brute force. - Such a brute-force attack will have an expected sucess rate of the - following form: - - attacker_success_rate = attempts_per_second / 2^(8*Nt) - - For example, a gigabit ethernet connection is able to transmit - roughly 2^20 packets per second. If an attacker saturated such a - link with guesses against a 32-bit authentication tag (Nt=4), then - the attacker would succeed on average roughly once every 2^12 - seconds, or about once an hour. - - In a typical SFrame usage in a real-time media application, there are - a few approaches to mitigating this risk: - - * Receivers only accept SFrame ciphertexts over HBH-secure channels - (e.g., SRTP security associations or QUIC connections). So only - an entity that is part of such a channel can mount the above - attack. - - * The expected packet rate for a media stream is very predictable - (and typically far lower than the above example). On the one - hand, attacks at this rate will succeed even less often than the - high-rate attack described above. On the other hand, the - application may use an elevated packet arrival rate as a signal of - a brute-force attack. This latter approach is common in other - settings, e.g., mitigating brute-force attacks on passwords. - - * Media applications typically do not provide feedback to media - senders as to which media packets failed to decrypt. When media - quality feedback mechanisms are used, decryption failures will - typically appear as packet losses, but only at an aggregate level. - - * Anti-replay mechanisms (see Section 7.4) prevent the attacker from - re-using valid ciphertexts (either observed or guessed by the - attacker). A receiver applying anti-replay controls will only - accept one valid plaintext per CTR value. Since the CTR value is - covered by SFrame authentication, an attacker has to do a fresh - search for a valid tag for every forged ciphertext, even if the - encrypted content is unchanged. In other words, when the above - brute force attack succeeds, it only allows the attacker to send a - single SFrame ciphertext; the ciphertext cannot be reused because - either it will have the same CTR value and be discarded as a - replay, or else it will have a different CTR value its tag will no - longer be valid. - - Nonetheless, without these mitigations, an application that makes use - of short tags will be at heightened risk of forgery attacks. In many - cases, it is simpler to use full-size tags and tolerate slightly - higher bandwidth usage rather than add the additional defenses - necessary to safely use short tags. - -8. IANA Considerations - - This document requests the creation of the following new IANA - registries: - - * SFrame Cipher Suites (Section 8.1) - - This registries should be under a heading of "SFrame", and - assignments are made via the Specification Required policy [RFC8126]. - - RFC EDITOR: Please replace XXXX throughout with the RFC number - assigned to this document - -8.1. SFrame Cipher Suites - - This registry lists identifiers for SFrame cipher suites, as defined - in Section 4.5. The cipher suite field is two bytes wide, so the - valid cipher suites are in the range 0x0000 to 0xFFFF. - - Template: - - * Value: The numeric value of the cipher suite - - * Name: The name of the cipher suite - - * Reference: The document where this wire format is defined - - Initial contents: - - +=================+============================+===========+ - | Value | Name | Reference | - +=================+============================+===========+ - | 0x0000 | Reserved | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0x0001 | AES_128_CTR_HMAC_SHA256_80 | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0x0002 | AES_128_CTR_HMAC_SHA256_64 | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0x0003 | AES_128_CTR_HMAC_SHA256_32 | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0x0004 | AES_128_GCM_SHA256_128 | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0x0005 | AES_256_GCM_SHA512_128 | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0xF000 - 0xFFFF | Reserved for private use | RFC XXXX | - +-----------------+----------------------------+-----------+ - - Table 2: SFrame cipher suites - -9. Application Responsibilities - - To use SFrame, an application needs to define the inputs to the - SFrame encryption and decryption operations, and how SFrame - ciphertexts are delivered from sender to receiver (including any - fragmentation and reassembly). In this section, we lay out - additional requirements that an integration must meet in order for - SFrame to operate securely. - - In general, an application using SFrame is responsible for - configuring SFrame. The application must first define when SFrame is - applied at all. When SFrame is applied, the application must define - which cipher suite is to be used. If new versions of SFrame are - defined in the future, it will be up to the application to determine - which version should be used. - - This division of responsibilities is similar to the way other media - parameters (e.g., codecs) are typically handled in media - applications, in the sense that they are set up in some signaling - protocol, and then not described in the media. Applications might - find it useful to extend the protocols used for negotiating other - media parameters (e.g., SDP [RFC4566]) to also negotiate parameters - for SFrame. - -9.1. Header Value Uniqueness - - Applications MUST ensure that each (base_key, KID, CTR) combination - is used for at most one SFrame encryption operation. This ensures - that the (key, nonce) pairs used by the underlying AEAD algorithm are - never reused. Typically this is done by assigning each sender a KID - or set of KIDs, then having each sender use the CTR field as a - monotonic counter, incrementing for each plaintext that is encrypted. - In addition to its simplicity, this scheme minimizes overhead by - keeping CTR values as small as possible. - -9.2. Key Management Framework - - It is up to the application to provision SFrame with a mapping of KID - values to base_key values and the resulting keys and salts. More - importantly, the application specifies which KID values are used for - which purposes (e.g., by which senders). An application's KID - assignment strategy MUST be structured to assure the non-reuse - properties discussed in Section 9.1. - - It is also up to the application to define a rotation schedule for - keys. For example, one application might have an ephemeral group for - every call and keep rotating keys when end points join or leave the - call, while another application could have a persistent group that - can be used for multiple calls and simply derives ephemeral symmetric - keys for a specific call. - - It should be noted that KID values are not encrypted by SFrame, and - are thus visible to any application-layer intermediaries that might - handle an SFrame ciphertext. If there are application semantics - included in KID values, then this information would be exposed to - intermediaries. For example, in the scheme of Section 5.1, the - number of ratchet steps per sender is exposed, and in the scheme of - Section 5.2, the number of epochs and the MLS sender ID of the SFrame - sender are exposed. - -9.3. Anti-Replay - - It is the responsibility of the application to handle anti-replay. - Replay by network attackers is assumed to be prevented by network- - layer facilities (e.g., TLS, SRTP). As mentioned in Section 7.4, - senders MUST reject requests to encrypt multiple times with the same - key and nonce. - - It is not mandatory to implement anti-replay on the receiver side. - Receivers MAY apply time or counter based anti-replay mitigations. - -9.4. Metadata - - The metadata input to SFrame operations is pure application-specified - data. As such, it is up to the application to define what - information should go in the metadata input and ensure that it is - provided to the encryption and decryption functions at the - appropriate points. A receiver MUST NOT use SFrame-authenticated - metadata until after the SFrame decrypt function has authenticated - it, unless the purpose of such usage is to prepare an SFrame - ciphertext for SFrame decryption. Essentially, metadata may be used - "upstream of SFrame" in a processing pipeline, but only to prepare - for SFrame decryption. - - For example, consider an application where SFrame is used to encrypt - audio frames that are sent over SRTP, with some application data - included in the RTP header extension. Suppose the application also - includes this application data in the SFrame metadata, so that the - SFU is allowed to read, but not modify the application data. A - receiver can use the application data in the RTP header extension as - part of the standard SRTP decryption process, since this is required - to recover the SFrame ciphertext carried in the SRTP payload. - However, the receiver MUST NOT use the application data for other - purposes before SFrame decryption has authenticated the application - data. - -10. References - -10.1. Normative References - - [MLS-PROTO] - Barnes, R., Beurdouche, B., Robert, R., Millican, J., - Omara, E., and K. Cohn-Gordon, "The Messaging Layer - Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, - July 2023, . - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated - Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, - . - - [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand - Key Derivation Function (HKDF)", RFC 5869, - DOI 10.17487/RFC5869, May 2010, - . - - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for - Writing an IANA Considerations Section in RFCs", BCP 26, - RFC 8126, DOI 10.17487/RFC8126, June 2017, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - -10.2. Informative References - - [I-D.codec-agnostic-rtp-payload-format] - Murillo, S. G. and A. Gouaillard, "Codec agnostic RTP - payload format for video", Work in Progress, Internet- - Draft, draft-codec-agnostic-rtp-payload-format-00, 19 - February 2021, . - - [I-D.ietf-moq-transport] - Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and - I. Swett, "Media over QUIC Transport", Work in Progress, - Internet-Draft, draft-ietf-moq-transport-02, 24 January - 2024, . - - [I-D.ietf-webtrans-overview] - Vasiliev, V., "The WebTransport Protocol Framework", Work - in Progress, Internet-Draft, draft-ietf-webtrans-overview- - 06, 6 September 2023, - . - - [MLS-ARCH] Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., and - A. Duric, "The Messaging Layer Security (MLS) - Architecture", Work in Progress, Internet-Draft, draft- - ietf-mls-architecture-11, 26 July 2023, - . - - [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. - Norrman, "The Secure Real-time Transport Protocol (SRTP)", - RFC 3711, DOI 10.17487/RFC3711, March 2004, - . - - [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session - Description Protocol", RFC 4566, DOI 10.17487/RFC4566, - July 2006, . - - [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the - Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, - September 2012, . - - [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and - B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms - for Real-Time Transport Protocol (RTP) Sources", RFC 7656, - DOI 10.17487/RFC7656, November 2015, - . - - [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, - DOI 10.17487/RFC7667, November 2015, - . - - [RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach, - "Double Encryption Procedures for the Secure Real-Time - Transport Protocol (SRTP)", RFC 8723, - DOI 10.17487/RFC8723, April 2020, - . - - [TestVectors] - "SFrame Test Vectors", 2023, - . - -Appendix A. Acknowledgements - - The authors wish to specially thank Dr. Alex Gouaillard as one of the - early contributors to the document. His passion and energy were key - to the design and development of SFrame. - -Appendix B. Example API - - *This section is not normative.* - - This section describes a notional API that an SFrame implementation - might expose. The core concept is an "SFrame context", within which - KID values are meaningful. In the key management scheme described in - Section 5.1, each sender has a different context; in the scheme - described in Section 5.2, all senders share the same context. - - An SFrame context stores mappings from KID values to "key contexts", - which are different depending on whether the KID is to be used for - sending or receiving (an SFrame key should never be used for both - operations). A key context tracks the key and salt associated to the - KID, and the current CTR value. A key context to be used for sending - also tracks the next CTR value to be used. - - The primary operations on an SFrame context are as follows: - - * *Create an SFrame context:* The context is initialized with a - ciphersuite and no KID mappings. - - * *Adding a key for sending:* The key and salt are derived from the - base key, and used to initialize a send context, together with a - zero counter value. - - * *Adding a key for receiving:* The key and salt are derived from - the base key, and used to initialize a send context. - - * *Encrypt a plaintext:* Encrypt a given plaintext using the key for - a given KID, including the specified metadata. - - * *Decrypt an SFrame ciphertext:* Decrypt an SFrame ciphertext with - the KID and CTR values specified in the SFrame Header, and the - provided metadata. - - Figure 9 shows an example of the types of structures and methods that - could be used to create an SFrame API in Rust. - - type KeyId = u64; - type Counter = u64; - type CipherSuite = u16; - - struct SendKeyContext { - key: Vec, - salt: Vec, - next_counter: Counter, - } - - struct RecvKeyContext { - key: Vec, - salt: Vec, - } - - struct SFrameContext { - cipher_suite: CipherSuite, - send_keys: HashMap, - recv_keys: HashMap, - } - - trait SFrameContextMethods { - fn create(cipher_suite: CipherSuite) -> Self; - fn add_send_key(&self, kid: KeyId, base_key: &[u8]); - fn add_recv_key(&self, kid: KeyId, base_key: &[u8]); - fn encrypt(&mut self, kid: KeyId, metadata: &[u8], - plaintext: &[u8]) -> Vec; - fn decrypt(&self, metadata: &[u8], ciphertext: &[u8]) -> Vec; - } - - Figure 9: An Example SFrame API - -Appendix C. Overhead Analysis - - Any use of SFrame will impose overhead in terms of the amount of - bandwidth necessary to transmit a given media stream. Exactly how - much overhead will be added depends on several factors: - - * How many senders are involved in a conference (length of KID) - - * How long the conference has been going on (length of CTR) - - * The cipher suite in use (length of authentication tag) - - * Whether SFrame is used to encrypt packets, whole frames, or some - other unit - - Overall, the overhead rate in kilobits per second can be estimated - as: - - OverheadKbps = (1 + |CTR| + |KID| + |TAG|) * 8 * CTPerSecond / 1024 - - Here the constant value 1 reflects the fixed SFrame header; |CTR| - and |KID| reflect the lengths of those fields; |TAG| reflects the - cipher overhead; and CTPerSecond reflects the number of SFrame - ciphertexts sent per second (e.g., packets or frames per second). - - In the remainder of this secton, we compute overhead estimates for a - collection of common scenarios. - -C.1. Assumptions - - In the below calculations, we make conservative assumptions about - SFrame overhead, so that the overhead amounts we compute here are - likely to be an upper bound on those seen in practice. - - +==============+=======+============================+ - | Field | Bytes | Explanation | - +==============+=======+============================+ - | Fixed header | 1 | Fixed | - +--------------+-------+----------------------------+ - | Key ID (KID) | 2 | >255 senders; or MLS epoch | - | | | (E=4) and >16 senders | - +--------------+-------+----------------------------+ - | Counter | 3 | More than 24 hours of | - | (CTR) | | media in common cases | - +--------------+-------+----------------------------+ - | Cipher | 16 | Full GCM tag (longest | - | overhead | | defined here) | - +--------------+-------+----------------------------+ - - Table 3 - - In total, then, we assume that each SFrame encryption will add 22 - bytes of overhead. - - We consider two scenarios, applying SFrame per-frame and per-packet. - In each scenario, we compute the SFrame overhead in absolute terms - (Kbps) and as a percentage of the base bandwidth. - -C.2. Audio - - In audio streams, there is typically a one-to-one relationship - between frames and packets, so the overhead is the same whether one - uses SFrame at a per-packet or per-frame level. - - The below table considers three scenarios, based on recommended - configurations of the Opus codec [RFC6716]: - - * Narrow-band speech: 120ms packets, 8Kbps - - * Full-band speech: 20ms packets, 32Kbps - - * Full-band stereo music: 10ms packets, 128Kbps - - +===============+=====+===========+===============+============+ - | Scenario | fps | Base Kbps | Overhead Kbps | Overhead % | - +===============+=====+===========+===============+============+ - | NB speech, | 8.3 | 8 | 1.4 | 17.9% | - | 120ms packets | | | | | - +---------------+-----+-----------+---------------+------------+ - | FB speech, | 50 | 32 | 8.6 | 26.9% | - | 20ms packets | | | | | - +---------------+-----+-----------+---------------+------------+ - | FB stereo, | 100 | 128 | 17.2 | 13.4% | - | 10ms packets | | | | | - +---------------+-----+-----------+---------------+------------+ - - Table 4: SFrame overhead for audio streams - -C.3. Video - - Video frames can be larger than an MTU and thus are commonly split - across multiple frames. Table 5 and Table 6 show the estimated - overhead of encrypting a video stream, where SFrame is applied per- - frame and per-packet, respectively. The choices of resolution, - frames per second, and bandwidth are chosen to roughly reflect the - capabilities of modern video codecs across a range from very low to - very high quality. - - +=============+=====+===========+===============+============+ - | Scenario | fps | Base Kbps | Overhead Kbps | Overhead % | - +=============+=====+===========+===============+============+ - | 426 x 240 | 7.5 | 45 | 1.3 | 2.9% | - +-------------+-----+-----------+---------------+------------+ - | 640 x 360 | 15 | 200 | 2.6 | 1.3% | - +-------------+-----+-----------+---------------+------------+ - | 640 x 360 | 30 | 400 | 5.2 | 1.3% | - +-------------+-----+-----------+---------------+------------+ - | 1280 x 720 | 30 | 1500 | 5.2 | 0.3% | - +-------------+-----+-----------+---------------+------------+ - | 1920 x 1080 | 60 | 7200 | 10.3 | 0.1% | - +-------------+-----+-----------+---------------+------------+ - - Table 5: SFrame overhead for a video stream encrypted per- - frame - - +=============+=====+=====+===========+===============+============+ - | Scenario | fps | pps | Base Kbps | Overhead Kbps | Overhead % | - +=============+=====+=====+===========+===============+============+ - | 426 x 240 | 7.5 | 7.5 | 45 | 1.3 | 2.9% | - +-------------+-----+-----+-----------+---------------+------------+ - | 640 x 360 | 15 | 30 | 200 | 5.2 | 2.6% | - +-------------+-----+-----+-----------+---------------+------------+ - | 640 x 360 | 30 | 60 | 400 | 10.3 | 2.6% | - +-------------+-----+-----+-----------+---------------+------------+ - | 1280 x 720 | 30 | 180 | 1500 | 30.9 | 2.1% | - +-------------+-----+-----+-----------+---------------+------------+ - | 1920 x 1080 | 60 | 780 | 7200 | 134.1 | 1.9% | - +-------------+-----+-----+-----------+---------------+------------+ - - Table 6: SFrame overhead for a video stream encrypted per-packet - - In the per-frame case, the SFrame percentage overhead approaches zero - as the quality of the video goes up, since bandwidth is driven more - by picture size than frame rate. In the per-packet case, the SFrame - percentage overhead approaches the ratio between the SFrame overhead - per packet and the MTU (here 22 bytes of SFrame overhead divided by - an assumed 1200-byte MTU, or about 1.8%). - -C.4. Conferences - - Real conferences usually involve several audio and video streams. - The overhead of SFrame in such a conference is the aggregate of the - overhead over all the individual streams. Thus, while SFrame incurs - a large percentage overhead on an audio stream, if the conference - also involves a video stream, then the audio overhead is likely - negligible relative to the overall bandwidth of the conference. - - For example, Table 7 shows the overhead estimates for a two person - conference where one person is sending low-quality media and the - other sending high-quality. (And we assume that SFrame is applied - per-frame.) The video streams dominate the bandwidth at the SFU, so - the total bandwidth overhead is only around 1%. - - +=====================+===========+===============+============+ - | Stream | Base Kbps | Overhead Kbps | Overhead % | - +=====================+===========+===============+============+ - | Participant 1 audio | 8 | 1.4 | 17.9% | - +---------------------+-----------+---------------+------------+ - | Participant 1 video | 45 | 1.3 | 2.9% | - +---------------------+-----------+---------------+------------+ - | Participant 2 audio | 32 | 9 | 26.9% | - +---------------------+-----------+---------------+------------+ - | Participant 2 video | 1500 | 5 | 0.3% | - +---------------------+-----------+---------------+------------+ - | Total at SFU | 1585 | 16.5 | 1.0% | - +---------------------+-----------+---------------+------------+ - - Table 7: SFrame overhead for a two-person conference - -C.5. SFrame over RTP - - SFrame is a generic encapsulation format, but many of the - applications in which it is likely to be integrated are based on RTP. - This section discusses how an integration between SFrame and RTP - could be done, and some of the challenges that would need to be - overcome. - - As discussed in Section 4.1, there are two natural patterns for - integrating SFrame into an application: applying SFrame per-frame or - per-packet. In RTP-based applications, applying SFrame per-packet - means that the payload of each RTP packet will be an SFrame - ciphertext, starting with an SFrame Header, as shown in Figure 10. - Applying SFrame per-frame means that different RTP payloads will have - different formats: The first payload of a frame will contain the - SFrame headers, and subsequent payloads will contain further chunks - of the ciphertext, as shown in Figure 11. - - In order for these media payloads to be properly interpreted by - receivers, receivers will need to be configured to know which of the - above schemes the sender has applied to a given sequence of RTP - packets. SFrame does not provide a mechanism for distributing this - configuration information. In applications that use SDP for - negotiating RTP media streams [RFC4566], an appropriate extension to - SDP could provide this function. - - Applying SFrame per-frame also requires that packetization and - depacketization be done in a generic manner that does not depend on - the media content of the packets, since the content being packetized - / depacketized will be opaque ciphertext (except for the SFrame - header). In order for such a generic packetization scheme to work - interoperably one would have to be defined, e.g., as proposed in - [I-D.codec-agnostic-rtp-payload-format]. - - +---+-+-+-------+-+-------------+-------------------------------+<-+ - |V=2|P|X| CC |M| PT | sequence number | | - +---+-+-+-------+-+-------------+-------------------------------+ | - | timestamp | | - +---------------------------------------------------------------+ | - | synchronization source (SSRC) identifier | | - +===============================================================+ | - | contributing source (CSRC) identifiers | | - | .... | | - +---------------------------------------------------------------+ | - | RTP extension(s) (OPTIONAL) | | - +->+--------------------+------------------------------------------+ | - | | SFrame header | | | - | +--------------------+ | | - | | | | - | | SFrame encrypted and authenticated payload | | - | | | | - +->+---------------------------------------------------------------+<-+ - | | SRTP authentication tag | | - | +---------------------------------------------------------------+ | - | | - +--- SRTP Encrypted Portion SRTP Authenticated Portion ---+ - - Figure 10: SRTP packet with SFrame-protected payload - - +----------------+ +---------------+ - | frame metadata | | | - +-------+--------+ | | - | | frame | - | | | - | | | - | +-------+-------+ - | | - | | - V V - +--------------------------------------+ - | SFrame Encrypt | - +--------------------------------------+ - | | - | | - | V - | +-------+-------+ - | | | - | | | - | | encrypted | - | | frame | - | | | - | | | - | +-------+-------+ - | | - | generic RTP packetize - | | - | +----------------------+--------.....--------+ - | | | | - V V V V - +---------------+ +---------------+ +---------------+ - | SFrame header | | | | | - +---------------+ | | | | - | | | payload 2/N | ... | payload N/N | - | payload 1/N | | | | | - | | | | | | - +---------------+ +---------------+ +---------------+ - - Figure 11: Encryption flow with per-frame encryption for RTP - -Appendix D. Test Vectors - - This section provides a set of test vectors that implementations can - use to verify that they correctly implement SFrame encryption and - decryption. In addition to test vectors for the overall process of - SFrame encryption/decryption, we also provide test vectors for header - encoding/decoding, and for AEAD encryption/decryption using the AES- - CTR construction defined in Section 4.5.1. - - All values are either numeric or byte strings. Numeric values are - represented as hex values, prefixed with 0x. Byte strings are - represented in hex encoding. - - Line breaks and whitespace within values are inserted to conform to - the width requirements of the RFC format. They should be removed - before use. - - These test vectors are also available in JSON format at - [TestVectors]. In the JSON test vectors, numeric values are JSON - numbers and byte string values are JSON strings containing the hex - encoding of the byte strings. - -D.1. Header encoding/decoding - - For each case, we provide: - - * kid: A KID value - - * ctr: A CTR value - - * header: An encoded SFrame header - - An implementation should verify that: - - * Encoding a header with the KID and CTR results in the provided - header value - - * Decoding the provided header value results in the provided KID and - CTR values - - kid: 0x0000000000000000 - ctr: 0x0000000000000000 - header: 00 - - kid: 0x0000000000000000 - ctr: 0x0000000000000001 - header: 01 - - kid: 0x0000000000000000 - ctr: 0x00000000000000ff - header: 08ff - - kid: 0x0000000000000000 - ctr: 0x0000000000000100 - header: 090100 - - kid: 0x0000000000000000 - ctr: 0x000000000000ffff - header: 09ffff - - kid: 0x0000000000000000 - ctr: 0x0000000000010000 - header: 0a010000 - - kid: 0x0000000000000000 - ctr: 0x0000000000ffffff - header: 0affffff - - kid: 0x0000000000000000 - ctr: 0x0000000001000000 - header: 0b01000000 - - kid: 0x0000000000000000 - ctr: 0x00000000ffffffff - header: 0bffffffff - - kid: 0x0000000000000000 - ctr: 0x0000000100000000 - header: 0c0100000000 - - kid: 0x0000000000000000 - ctr: 0x000000ffffffffff - header: 0cffffffffff - - kid: 0x0000000000000000 - ctr: 0x0000010000000000 - header: 0d010000000000 - - kid: 0x0000000000000000 - ctr: 0x0000ffffffffffff - header: 0dffffffffffff - - kid: 0x0000000000000000 - ctr: 0x0001000000000000 - header: 0e01000000000000 - - kid: 0x0000000000000000 - ctr: 0x00ffffffffffffff - header: 0effffffffffffff - - kid: 0x0000000000000000 - ctr: 0x0100000000000000 - header: 0f0100000000000000 - - kid: 0x0000000000000000 - ctr: 0xffffffffffffffff - header: 0fffffffffffffffff - - kid: 0x0000000000000001 - ctr: 0x0000000000000000 - header: 10 - - kid: 0x0000000000000001 - ctr: 0x0000000000000001 - header: 11 - - kid: 0x0000000000000001 - ctr: 0x00000000000000ff - header: 18ff - - kid: 0x0000000000000001 - ctr: 0x0000000000000100 - header: 190100 - - kid: 0x0000000000000001 - ctr: 0x000000000000ffff - header: 19ffff - - kid: 0x0000000000000001 - ctr: 0x0000000000010000 - header: 1a010000 - - kid: 0x0000000000000001 - ctr: 0x0000000000ffffff - header: 1affffff - - kid: 0x0000000000000001 - ctr: 0x0000000001000000 - header: 1b01000000 - - kid: 0x0000000000000001 - ctr: 0x00000000ffffffff - header: 1bffffffff - - kid: 0x0000000000000001 - ctr: 0x0000000100000000 - header: 1c0100000000 - - kid: 0x0000000000000001 - ctr: 0x000000ffffffffff - header: 1cffffffffff - - kid: 0x0000000000000001 - ctr: 0x0000010000000000 - header: 1d010000000000 - - kid: 0x0000000000000001 - ctr: 0x0000ffffffffffff - header: 1dffffffffffff - - kid: 0x0000000000000001 - ctr: 0x0001000000000000 - header: 1e01000000000000 - - kid: 0x0000000000000001 - ctr: 0x00ffffffffffffff - header: 1effffffffffffff - - kid: 0x0000000000000001 - ctr: 0x0100000000000000 - header: 1f0100000000000000 - - kid: 0x0000000000000001 - ctr: 0xffffffffffffffff - header: 1fffffffffffffffff - - kid: 0x00000000000000ff - ctr: 0x0000000000000000 - header: 80ff - - kid: 0x00000000000000ff - ctr: 0x0000000000000001 - header: 81ff - - kid: 0x00000000000000ff - ctr: 0x00000000000000ff - header: 88ffff - - kid: 0x00000000000000ff - ctr: 0x0000000000000100 - header: 89ff0100 - - kid: 0x00000000000000ff - ctr: 0x000000000000ffff - header: 89ffffff - - kid: 0x00000000000000ff - ctr: 0x0000000000010000 - header: 8aff010000 - - kid: 0x00000000000000ff - ctr: 0x0000000000ffffff - header: 8affffffff - - kid: 0x00000000000000ff - ctr: 0x0000000001000000 - header: 8bff01000000 - - kid: 0x00000000000000ff - ctr: 0x00000000ffffffff - header: 8bffffffffff - - kid: 0x00000000000000ff - ctr: 0x0000000100000000 - header: 8cff0100000000 - - kid: 0x00000000000000ff - ctr: 0x000000ffffffffff - header: 8cffffffffffff - - kid: 0x00000000000000ff - ctr: 0x0000010000000000 - header: 8dff010000000000 - - kid: 0x00000000000000ff - ctr: 0x0000ffffffffffff - header: 8dffffffffffffff - - kid: 0x00000000000000ff - ctr: 0x0001000000000000 - header: 8eff01000000000000 - - kid: 0x00000000000000ff - ctr: 0x00ffffffffffffff - header: 8effffffffffffffff - - kid: 0x00000000000000ff - ctr: 0x0100000000000000 - header: 8fff0100000000000000 - - kid: 0x00000000000000ff - ctr: 0xffffffffffffffff - header: 8fffffffffffffffffff - - kid: 0x0000000000000100 - ctr: 0x0000000000000000 - header: 900100 - - kid: 0x0000000000000100 - ctr: 0x0000000000000001 - header: 910100 - - kid: 0x0000000000000100 - ctr: 0x00000000000000ff - header: 980100ff - - kid: 0x0000000000000100 - ctr: 0x0000000000000100 - header: 9901000100 - - kid: 0x0000000000000100 - ctr: 0x000000000000ffff - header: 990100ffff - - kid: 0x0000000000000100 - ctr: 0x0000000000010000 - header: 9a0100010000 - - kid: 0x0000000000000100 - ctr: 0x0000000000ffffff - header: 9a0100ffffff - - kid: 0x0000000000000100 - ctr: 0x0000000001000000 - header: 9b010001000000 - - kid: 0x0000000000000100 - ctr: 0x00000000ffffffff - header: 9b0100ffffffff - - kid: 0x0000000000000100 - ctr: 0x0000000100000000 - header: 9c01000100000000 - - kid: 0x0000000000000100 - ctr: 0x000000ffffffffff - header: 9c0100ffffffffff - - kid: 0x0000000000000100 - ctr: 0x0000010000000000 - header: 9d0100010000000000 - - kid: 0x0000000000000100 - ctr: 0x0000ffffffffffff - header: 9d0100ffffffffffff - - kid: 0x0000000000000100 - ctr: 0x0001000000000000 - header: 9e010001000000000000 - - kid: 0x0000000000000100 - ctr: 0x00ffffffffffffff - header: 9e0100ffffffffffffff - - kid: 0x0000000000000100 - ctr: 0x0100000000000000 - header: 9f01000100000000000000 - - kid: 0x0000000000000100 - ctr: 0xffffffffffffffff - header: 9f0100ffffffffffffffff - - kid: 0x000000000000ffff - ctr: 0x0000000000000000 - header: 90ffff - - kid: 0x000000000000ffff - ctr: 0x0000000000000001 - header: 91ffff - - kid: 0x000000000000ffff - ctr: 0x00000000000000ff - header: 98ffffff - - kid: 0x000000000000ffff - ctr: 0x0000000000000100 - header: 99ffff0100 - - kid: 0x000000000000ffff - ctr: 0x000000000000ffff - header: 99ffffffff - - kid: 0x000000000000ffff - ctr: 0x0000000000010000 - header: 9affff010000 - - kid: 0x000000000000ffff - ctr: 0x0000000000ffffff - header: 9affffffffff - - kid: 0x000000000000ffff - ctr: 0x0000000001000000 - header: 9bffff01000000 - - kid: 0x000000000000ffff - ctr: 0x00000000ffffffff - header: 9bffffffffffff - - kid: 0x000000000000ffff - ctr: 0x0000000100000000 - header: 9cffff0100000000 - - kid: 0x000000000000ffff - ctr: 0x000000ffffffffff - header: 9cffffffffffffff - - kid: 0x000000000000ffff - ctr: 0x0000010000000000 - header: 9dffff010000000000 - - kid: 0x000000000000ffff - ctr: 0x0000ffffffffffff - header: 9dffffffffffffffff - - kid: 0x000000000000ffff - ctr: 0x0001000000000000 - header: 9effff01000000000000 - - kid: 0x000000000000ffff - ctr: 0x00ffffffffffffff - header: 9effffffffffffffffff - - kid: 0x000000000000ffff - ctr: 0x0100000000000000 - header: 9fffff0100000000000000 - - kid: 0x000000000000ffff - ctr: 0xffffffffffffffff - header: 9fffffffffffffffffffff - - kid: 0x0000000000010000 - ctr: 0x0000000000000000 - header: a0010000 - - kid: 0x0000000000010000 - ctr: 0x0000000000000001 - header: a1010000 - - kid: 0x0000000000010000 - ctr: 0x00000000000000ff - header: a8010000ff - - kid: 0x0000000000010000 - ctr: 0x0000000000000100 - header: a90100000100 - - kid: 0x0000000000010000 - ctr: 0x000000000000ffff - header: a9010000ffff - - kid: 0x0000000000010000 - ctr: 0x0000000000010000 - header: aa010000010000 - - kid: 0x0000000000010000 - ctr: 0x0000000000ffffff - header: aa010000ffffff - - kid: 0x0000000000010000 - ctr: 0x0000000001000000 - header: ab01000001000000 - - kid: 0x0000000000010000 - ctr: 0x00000000ffffffff - header: ab010000ffffffff - - kid: 0x0000000000010000 - ctr: 0x0000000100000000 - header: ac0100000100000000 - - kid: 0x0000000000010000 - ctr: 0x000000ffffffffff - header: ac010000ffffffffff - - kid: 0x0000000000010000 - ctr: 0x0000010000000000 - header: ad010000010000000000 - - kid: 0x0000000000010000 - ctr: 0x0000ffffffffffff - header: ad010000ffffffffffff - - kid: 0x0000000000010000 - ctr: 0x0001000000000000 - header: ae01000001000000000000 - - kid: 0x0000000000010000 - ctr: 0x00ffffffffffffff - header: ae010000ffffffffffffff - - kid: 0x0000000000010000 - ctr: 0x0100000000000000 - header: af0100000100000000000000 - - kid: 0x0000000000010000 - ctr: 0xffffffffffffffff - header: af010000ffffffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000000000000 - header: a0ffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000000000001 - header: a1ffffff - - kid: 0x0000000000ffffff - ctr: 0x00000000000000ff - header: a8ffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000000000100 - header: a9ffffff0100 - - kid: 0x0000000000ffffff - ctr: 0x000000000000ffff - header: a9ffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000000010000 - header: aaffffff010000 - - kid: 0x0000000000ffffff - ctr: 0x0000000000ffffff - header: aaffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000001000000 - header: abffffff01000000 - - kid: 0x0000000000ffffff - ctr: 0x00000000ffffffff - header: abffffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000100000000 - header: acffffff0100000000 - - kid: 0x0000000000ffffff - ctr: 0x000000ffffffffff - header: acffffffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000010000000000 - header: adffffff010000000000 - - kid: 0x0000000000ffffff - ctr: 0x0000ffffffffffff - header: adffffffffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0001000000000000 - header: aeffffff01000000000000 - - kid: 0x0000000000ffffff - ctr: 0x00ffffffffffffff - header: aeffffffffffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0100000000000000 - header: afffffff0100000000000000 - - kid: 0x0000000000ffffff - ctr: 0xffffffffffffffff - header: afffffffffffffffffffffff - - kid: 0x0000000001000000 - ctr: 0x0000000000000000 - header: b001000000 - - kid: 0x0000000001000000 - ctr: 0x0000000000000001 - header: b101000000 - - kid: 0x0000000001000000 - ctr: 0x00000000000000ff - header: b801000000ff - - kid: 0x0000000001000000 - ctr: 0x0000000000000100 - header: b9010000000100 - - kid: 0x0000000001000000 - ctr: 0x000000000000ffff - header: b901000000ffff - - kid: 0x0000000001000000 - ctr: 0x0000000000010000 - header: ba01000000010000 - - kid: 0x0000000001000000 - ctr: 0x0000000000ffffff - header: ba01000000ffffff - - kid: 0x0000000001000000 - ctr: 0x0000000001000000 - header: bb0100000001000000 - - kid: 0x0000000001000000 - ctr: 0x00000000ffffffff - header: bb01000000ffffffff - - kid: 0x0000000001000000 - ctr: 0x0000000100000000 - header: bc010000000100000000 - - kid: 0x0000000001000000 - ctr: 0x000000ffffffffff - header: bc01000000ffffffffff - - kid: 0x0000000001000000 - ctr: 0x0000010000000000 - header: bd01000000010000000000 - - kid: 0x0000000001000000 - ctr: 0x0000ffffffffffff - header: bd01000000ffffffffffff - - kid: 0x0000000001000000 - ctr: 0x0001000000000000 - header: be0100000001000000000000 - - kid: 0x0000000001000000 - ctr: 0x00ffffffffffffff - header: be01000000ffffffffffffff - - kid: 0x0000000001000000 - ctr: 0x0100000000000000 - header: bf010000000100000000000000 - - kid: 0x0000000001000000 - ctr: 0xffffffffffffffff - header: bf01000000ffffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000000000000 - header: b0ffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000000000001 - header: b1ffffffff - - kid: 0x00000000ffffffff - ctr: 0x00000000000000ff - header: b8ffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000000000100 - header: b9ffffffff0100 - - kid: 0x00000000ffffffff - ctr: 0x000000000000ffff - header: b9ffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000000010000 - header: baffffffff010000 - - kid: 0x00000000ffffffff - ctr: 0x0000000000ffffff - header: baffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000001000000 - header: bbffffffff01000000 - - kid: 0x00000000ffffffff - ctr: 0x00000000ffffffff - header: bbffffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000100000000 - header: bcffffffff0100000000 - - kid: 0x00000000ffffffff - ctr: 0x000000ffffffffff - header: bcffffffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000010000000000 - header: bdffffffff010000000000 - - kid: 0x00000000ffffffff - ctr: 0x0000ffffffffffff - header: bdffffffffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0001000000000000 - header: beffffffff01000000000000 - - kid: 0x00000000ffffffff - ctr: 0x00ffffffffffffff - header: beffffffffffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0100000000000000 - header: bfffffffff0100000000000000 - - kid: 0x00000000ffffffff - ctr: 0xffffffffffffffff - header: bfffffffffffffffffffffffff - - kid: 0x0000000100000000 - ctr: 0x0000000000000000 - header: c00100000000 - - kid: 0x0000000100000000 - ctr: 0x0000000000000001 - header: c10100000000 - - kid: 0x0000000100000000 - ctr: 0x00000000000000ff - header: c80100000000ff - - kid: 0x0000000100000000 - ctr: 0x0000000000000100 - header: c901000000000100 - - kid: 0x0000000100000000 - ctr: 0x000000000000ffff - header: c90100000000ffff - - kid: 0x0000000100000000 - ctr: 0x0000000000010000 - header: ca0100000000010000 - - kid: 0x0000000100000000 - ctr: 0x0000000000ffffff - header: ca0100000000ffffff - - kid: 0x0000000100000000 - ctr: 0x0000000001000000 - header: cb010000000001000000 - - kid: 0x0000000100000000 - ctr: 0x00000000ffffffff - header: cb0100000000ffffffff - - kid: 0x0000000100000000 - ctr: 0x0000000100000000 - header: cc01000000000100000000 - - kid: 0x0000000100000000 - ctr: 0x000000ffffffffff - header: cc0100000000ffffffffff - - kid: 0x0000000100000000 - ctr: 0x0000010000000000 - header: cd0100000000010000000000 - - kid: 0x0000000100000000 - ctr: 0x0000ffffffffffff - header: cd0100000000ffffffffffff - - kid: 0x0000000100000000 - ctr: 0x0001000000000000 - header: ce010000000001000000000000 - - kid: 0x0000000100000000 - ctr: 0x00ffffffffffffff - header: ce0100000000ffffffffffffff - - kid: 0x0000000100000000 - ctr: 0x0100000000000000 - header: cf01000000000100000000000000 - - kid: 0x0000000100000000 - ctr: 0xffffffffffffffff - header: cf0100000000ffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000000000000 - header: c0ffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000000000001 - header: c1ffffffffff - - kid: 0x000000ffffffffff - ctr: 0x00000000000000ff - header: c8ffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000000000100 - header: c9ffffffffff0100 - - kid: 0x000000ffffffffff - ctr: 0x000000000000ffff - header: c9ffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000000010000 - header: caffffffffff010000 - - kid: 0x000000ffffffffff - ctr: 0x0000000000ffffff - header: caffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000001000000 - header: cbffffffffff01000000 - - kid: 0x000000ffffffffff - ctr: 0x00000000ffffffff - header: cbffffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000100000000 - header: ccffffffffff0100000000 - - kid: 0x000000ffffffffff - ctr: 0x000000ffffffffff - header: ccffffffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000010000000000 - header: cdffffffffff010000000000 - - kid: 0x000000ffffffffff - ctr: 0x0000ffffffffffff - header: cdffffffffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0001000000000000 - header: ceffffffffff01000000000000 - - kid: 0x000000ffffffffff - ctr: 0x00ffffffffffffff - header: ceffffffffffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0100000000000000 - header: cfffffffffff0100000000000000 - - kid: 0x000000ffffffffff - ctr: 0xffffffffffffffff - header: cfffffffffffffffffffffffffff - - kid: 0x0000010000000000 - ctr: 0x0000000000000000 - header: d0010000000000 - - kid: 0x0000010000000000 - ctr: 0x0000000000000001 - header: d1010000000000 - - kid: 0x0000010000000000 - ctr: 0x00000000000000ff - header: d8010000000000ff - - kid: 0x0000010000000000 - ctr: 0x0000000000000100 - header: d90100000000000100 - - kid: 0x0000010000000000 - ctr: 0x000000000000ffff - header: d9010000000000ffff - - kid: 0x0000010000000000 - ctr: 0x0000000000010000 - header: da010000000000010000 - - kid: 0x0000010000000000 - ctr: 0x0000000000ffffff - header: da010000000000ffffff - - kid: 0x0000010000000000 - ctr: 0x0000000001000000 - header: db01000000000001000000 - - kid: 0x0000010000000000 - ctr: 0x00000000ffffffff - header: db010000000000ffffffff - - kid: 0x0000010000000000 - ctr: 0x0000000100000000 - header: dc0100000000000100000000 - - kid: 0x0000010000000000 - ctr: 0x000000ffffffffff - header: dc010000000000ffffffffff - - kid: 0x0000010000000000 - ctr: 0x0000010000000000 - header: dd010000000000010000000000 - - kid: 0x0000010000000000 - ctr: 0x0000ffffffffffff - header: dd010000000000ffffffffffff - - kid: 0x0000010000000000 - ctr: 0x0001000000000000 - header: de01000000000001000000000000 - - kid: 0x0000010000000000 - ctr: 0x00ffffffffffffff - header: de010000000000ffffffffffffff - - kid: 0x0000010000000000 - ctr: 0x0100000000000000 - header: df0100000000000100000000000000 - - kid: 0x0000010000000000 - ctr: 0xffffffffffffffff - header: df010000000000ffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000000000000 - header: d0ffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000000000001 - header: d1ffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x00000000000000ff - header: d8ffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000000000100 - header: d9ffffffffffff0100 - - kid: 0x0000ffffffffffff - ctr: 0x000000000000ffff - header: d9ffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000000010000 - header: daffffffffffff010000 - - kid: 0x0000ffffffffffff - ctr: 0x0000000000ffffff - header: daffffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000001000000 - header: dbffffffffffff01000000 - - kid: 0x0000ffffffffffff - ctr: 0x00000000ffffffff - header: dbffffffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000100000000 - header: dcffffffffffff0100000000 - - kid: 0x0000ffffffffffff - ctr: 0x000000ffffffffff - header: dcffffffffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000010000000000 - header: ddffffffffffff010000000000 - - kid: 0x0000ffffffffffff - ctr: 0x0000ffffffffffff - header: ddffffffffffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0001000000000000 - header: deffffffffffff01000000000000 - - kid: 0x0000ffffffffffff - ctr: 0x00ffffffffffffff - header: deffffffffffffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0100000000000000 - header: dfffffffffffff0100000000000000 - - kid: 0x0000ffffffffffff - ctr: 0xffffffffffffffff - header: dfffffffffffffffffffffffffffff - - kid: 0x0001000000000000 - ctr: 0x0000000000000000 - header: e001000000000000 - - kid: 0x0001000000000000 - ctr: 0x0000000000000001 - header: e101000000000000 - - kid: 0x0001000000000000 - ctr: 0x00000000000000ff - header: e801000000000000ff - - kid: 0x0001000000000000 - ctr: 0x0000000000000100 - header: e9010000000000000100 - - kid: 0x0001000000000000 - ctr: 0x000000000000ffff - header: e901000000000000ffff - - kid: 0x0001000000000000 - ctr: 0x0000000000010000 - header: ea01000000000000010000 - - kid: 0x0001000000000000 - ctr: 0x0000000000ffffff - header: ea01000000000000ffffff - - kid: 0x0001000000000000 - ctr: 0x0000000001000000 - header: eb0100000000000001000000 - - kid: 0x0001000000000000 - ctr: 0x00000000ffffffff - header: eb01000000000000ffffffff - - kid: 0x0001000000000000 - ctr: 0x0000000100000000 - header: ec010000000000000100000000 - - kid: 0x0001000000000000 - ctr: 0x000000ffffffffff - header: ec01000000000000ffffffffff - - kid: 0x0001000000000000 - ctr: 0x0000010000000000 - header: ed01000000000000010000000000 - - kid: 0x0001000000000000 - ctr: 0x0000ffffffffffff - header: ed01000000000000ffffffffffff - - kid: 0x0001000000000000 - ctr: 0x0001000000000000 - header: ee0100000000000001000000000000 - - kid: 0x0001000000000000 - ctr: 0x00ffffffffffffff - header: ee01000000000000ffffffffffffff - - kid: 0x0001000000000000 - ctr: 0x0100000000000000 - header: ef010000000000000100000000000000 - - kid: 0x0001000000000000 - ctr: 0xffffffffffffffff - header: ef01000000000000ffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000000000000 - header: e0ffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000000000001 - header: e1ffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x00000000000000ff - header: e8ffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000000000100 - header: e9ffffffffffffff0100 - - kid: 0x00ffffffffffffff - ctr: 0x000000000000ffff - header: e9ffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000000010000 - header: eaffffffffffffff010000 - - kid: 0x00ffffffffffffff - ctr: 0x0000000000ffffff - header: eaffffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000001000000 - header: ebffffffffffffff01000000 - - kid: 0x00ffffffffffffff - ctr: 0x00000000ffffffff - header: ebffffffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000100000000 - header: ecffffffffffffff0100000000 - - kid: 0x00ffffffffffffff - ctr: 0x000000ffffffffff - header: ecffffffffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000010000000000 - header: edffffffffffffff010000000000 - - kid: 0x00ffffffffffffff - ctr: 0x0000ffffffffffff - header: edffffffffffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0001000000000000 - header: eeffffffffffffff01000000000000 - - kid: 0x00ffffffffffffff - ctr: 0x00ffffffffffffff - header: eeffffffffffffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0100000000000000 - header: efffffffffffffff0100000000000000 - - kid: 0x00ffffffffffffff - ctr: 0xffffffffffffffff - header: efffffffffffffffffffffffffffffff - - kid: 0x0100000000000000 - ctr: 0x0000000000000000 - header: f00100000000000000 - - kid: 0x0100000000000000 - ctr: 0x0000000000000001 - header: f10100000000000000 - - kid: 0x0100000000000000 - ctr: 0x00000000000000ff - header: f80100000000000000ff - - kid: 0x0100000000000000 - ctr: 0x0000000000000100 - header: f901000000000000000100 - - kid: 0x0100000000000000 - ctr: 0x000000000000ffff - header: f90100000000000000ffff - - kid: 0x0100000000000000 - ctr: 0x0000000000010000 - header: fa0100000000000000010000 - - kid: 0x0100000000000000 - ctr: 0x0000000000ffffff - header: fa0100000000000000ffffff - - kid: 0x0100000000000000 - ctr: 0x0000000001000000 - header: fb010000000000000001000000 - - kid: 0x0100000000000000 - ctr: 0x00000000ffffffff - header: fb0100000000000000ffffffff - - kid: 0x0100000000000000 - ctr: 0x0000000100000000 - header: fc01000000000000000100000000 - - kid: 0x0100000000000000 - ctr: 0x000000ffffffffff - header: fc0100000000000000ffffffffff - - kid: 0x0100000000000000 - ctr: 0x0000010000000000 - header: fd0100000000000000010000000000 - - kid: 0x0100000000000000 - ctr: 0x0000ffffffffffff - header: fd0100000000000000ffffffffffff - - kid: 0x0100000000000000 - ctr: 0x0001000000000000 - header: fe010000000000000001000000000000 - - kid: 0x0100000000000000 - ctr: 0x00ffffffffffffff - header: fe0100000000000000ffffffffffffff - - kid: 0x0100000000000000 - ctr: 0x0100000000000000 - header: ff010000000000000001000000000000 - 00 - - kid: 0x0100000000000000 - ctr: 0xffffffffffffffff - header: ff0100000000000000ffffffffffffff - ff - - kid: 0xffffffffffffffff - ctr: 0x0000000000000000 - header: f0ffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000000000000001 - header: f1ffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x00000000000000ff - header: f8ffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000000000000100 - header: f9ffffffffffffffff0100 - - kid: 0xffffffffffffffff - ctr: 0x000000000000ffff - header: f9ffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000000000010000 - header: faffffffffffffffff010000 - - kid: 0xffffffffffffffff - ctr: 0x0000000000ffffff - header: faffffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000000001000000 - header: fbffffffffffffffff01000000 - - kid: 0xffffffffffffffff - ctr: 0x00000000ffffffff - header: fbffffffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000000100000000 - header: fcffffffffffffffff0100000000 - - kid: 0xffffffffffffffff - ctr: 0x000000ffffffffff - header: fcffffffffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000010000000000 - header: fdffffffffffffffff010000000000 - - kid: 0xffffffffffffffff - ctr: 0x0000ffffffffffff - header: fdffffffffffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0001000000000000 - header: feffffffffffffffff01000000000000 - - kid: 0xffffffffffffffff - ctr: 0x00ffffffffffffff - header: feffffffffffffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0100000000000000 - header: ffffffffffffffffff01000000000000 - 00 - - kid: 0xffffffffffffffff - ctr: 0xffffffffffffffff - header: ffffffffffffffffffffffffffffffff - ff - -D.2. AEAD encryption/decryption using AES-CTR and HMAC - - For each case, we provide: - - * cipher_suite: The index of the cipher suite in use (see - Section 8.1) - - * key: The key input to encryption/decryption - - * enc_key: The encryption subkey produced by the derive_subkeys() - algorithm - - * auth_key: The encryption subkey produced by the derive_subkeys() - algorithm - - * nonce: The nonce input to encryption/decryption - - * aad: The aad input to encryption/decryption - - * pt: The plaintext - - * ct: The ciphertext - - An implementation should verify that the following are true, where - AEAD.Encrypt and AEAD.Decrypt are as defined in Section 4.5.1: - - * AEAD.Encrypt(key, nonce, aad, pt) == ct - - * AEAD.Decrypt(key, nonce, aad, ct) == pt - - The other values in the test vector are intermediate values provided - to facilitate debugging of test failures. - - cipher_suite: 0x0001 - key: 000102030405060708090a0b0c0d0e0f - 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - enc_key: 000102030405060708090a0b0c0d0e0f - auth_key: 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - nonce: 101112131415161718191a1b - aad: 4945544620534672616d65205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 6339af04ada1d064688a442b8dc69d5b - 6bfa40f4bef0583e8081069cc60705 - - cipher_suite: 0x0002 - key: 000102030405060708090a0b0c0d0e0f - 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - enc_key: 000102030405060708090a0b0c0d0e0f - auth_key: 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - nonce: 101112131415161718191a1b - aad: 4945544620534672616d65205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 6339af04ada1d064688a442b8dc69d5b - 6bfa40f4be6e93b7da076927bb - - cipher_suite: 0x0003 - key: 000102030405060708090a0b0c0d0e0f - 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - enc_key: 000102030405060708090a0b0c0d0e0f - auth_key: 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - nonce: 101112131415161718191a1b - aad: 4945544620534672616d65205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 6339af04ada1d064688a442b8dc69d5b - 6bfa40f4be09480509 - -D.3. SFrame encryption/decryption - - For each case, we provide: - - * cipher_suite: The index of the cipher suite in use (see - Section 8.1) - - * kid: A KID value - - * ctr: A CTR value - - * base_key: The base_key input to the derive_key_salt algorithm - - * sframe_key_label: The label used to derive sframe_key in the - derive_key_salt algorithm - - * sframe_salt_label: The label used to derive sframe_salt in the - derive_key_salt algorithm - - * sframe_secret: The sframe_secret variable in the derive_key_salt - algorithm - - * sframe_key: The sframe_key value produced by the derive_key_salt - algorithm - - * sframe_salt: The sframe_salt value produced by the derive_key_salt - algorithm - - * metadata: The metadata input to the SFrame encrypt algorithm - - * pt: The plaintext - - * ct: The SFrame ciphertext - - An implementation should verify that the following are true, where - encrypt and decrypt are as defined in Section 4.4, using an SFrame - context initialized with base_key assigned to kid: - - * encrypt(ctr, kid, metadata, plaintext) == ct - - * decrypt(metadata, ct) == pt - - The other values in the test vector are intermediate values provided - to facilitate debugging of test failures. - - cipher_suite: 0x0001 - kid: 0x0000000000000123 - ctr: 0x0000000000004567 - base_key: 000102030405060708090a0b0c0d0e0f - sframe_key_label: 534672616d6520312e30205365637265 - 74206b65792000000000000001230001 - sframe_salt_label: 534672616d6520312e30205365637265 - 742073616c7420000000000000012300 - 01 - sframe_secret: d926952ca8b7ec4a95941d1ada3a5203 - ceff8cceee34f574d23909eb314c40c0 - sframe_key: 3f7d9a7c83ae8e1c8a11ae695ab59314 - b367e359fadac7b9c46b2bc6f81f46e1 - 6b96f0811868d59402b7e870102720b3 - sframe_salt: 50b29329a04dc0f184ac3168 - metadata: 4945544620534672616d65205747 - nonce: 50b29329a04dc0f184ac740f - aad: 99012345674945544620534672616d65 - 205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 9901234567449408b6f490086165b9d6 - f62b24ae1a59a56486b4ae8ed036b889 - 12e24f11 - - cipher_suite: 0x0002 - kid: 0x0000000000000123 - ctr: 0x0000000000004567 - base_key: 000102030405060708090a0b0c0d0e0f - sframe_key_label: 534672616d6520312e30205365637265 - 74206b65792000000000000001230002 - sframe_salt_label: 534672616d6520312e30205365637265 - 742073616c7420000000000000012300 - 02 - sframe_secret: d926952ca8b7ec4a95941d1ada3a5203 - ceff8cceee34f574d23909eb314c40c0 - sframe_key: e2ec5c797540310483b16bf6e7a570d2 - a27d192fe869c7ccd8584a8d9dab9154 - 9fbe553f5113461ec6aa83bf3865553e - sframe_salt: e68ac8dd3d02fbcd368c5577 - metadata: 4945544620534672616d65205747 - nonce: e68ac8dd3d02fbcd368c1010 - aad: 99012345674945544620534672616d65 - 205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 99012345673f31438db4d09434e43afa - 0f8a2f00867a2be085046a9f5cb4f101 - d607 - - cipher_suite: 0x0003 - kid: 0x0000000000000123 - ctr: 0x0000000000004567 - base_key: 000102030405060708090a0b0c0d0e0f - sframe_key_label: 534672616d6520312e30205365637265 - 74206b65792000000000000001230003 - sframe_salt_label: 534672616d6520312e30205365637265 - 742073616c7420000000000000012300 - 03 - sframe_secret: d926952ca8b7ec4a95941d1ada3a5203 - ceff8cceee34f574d23909eb314c40c0 - sframe_key: 2c5703089cbb8c583475e4fc461d97d1 - 8809df79b6d550f78eb6d50ffa80d892 - 11d57909934f46f5405e38cd583c69fe - sframe_salt: 38c16e4f5159700c00c7f350 - metadata: 4945544620534672616d65205747 - nonce: 38c16e4f5159700c00c7b637 - aad: 99012345674945544620534672616d65 - 205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 990123456717fc8af28a5a695afcfc6c - 8df6358a17e26b2fcb3bae32e443 - - cipher_suite: 0x0004 - kid: 0x0000000000000123 - ctr: 0x0000000000004567 - base_key: 000102030405060708090a0b0c0d0e0f - sframe_key_label: 534672616d6520312e30205365637265 - 74206b65792000000000000001230004 - sframe_salt_label: 534672616d6520312e30205365637265 - 742073616c7420000000000000012300 - 04 - sframe_secret: d926952ca8b7ec4a95941d1ada3a5203 - ceff8cceee34f574d23909eb314c40c0 - sframe_key: d34f547f4ca4f9a7447006fe7fcbf768 - sframe_salt: 75234edefe07819026751816 - metadata: 4945544620534672616d65205747 - nonce: 75234edefe07819026755d71 - aad: 99012345674945544620534672616d65 - 205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 9901234567b7412c2513a1b66dbb4884 - 1bbaf17f598751176ad847681a69c6d0 - b091c07018ce4adb34eb - - cipher_suite: 0x0005 - kid: 0x0000000000000123 - ctr: 0x0000000000004567 - base_key: 000102030405060708090a0b0c0d0e0f - sframe_key_label: 534672616d6520312e30205365637265 - 74206b65792000000000000001230005 - sframe_salt_label: 534672616d6520312e30205365637265 - 742073616c7420000000000000012300 - 05 - sframe_secret: 0fc3ea6de6aac97a35f194cf9bed94d4 - b5230f1cb45a785c9fe5dce9c188938a - b6ba005bc4c0a19181599e9d1bcf7b74 - aca48b60bf5e254e546d809313e083a3 - sframe_key: d3e27b0d4a5ae9e55df01a70e6d4d28d - 969b246e2936f4b7a5d9b494da6b9633 - sframe_salt: 84991c167b8cd23c93708ec7 - metadata: 4945544620534672616d65205747 - nonce: 84991c167b8cd23c9370cba0 - aad: 99012345674945544620534672616d65 - 205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 990123456794f509d36e9beacb0e261d - 99c7d1e972f1fed787d4049f17ca2135 - 3c1cc24d56ceabced279 - -Contributors - - Frederic Jacobs - Apple - Email: frederic.jacobs@apple.com - - - Marta Mularczyk - Amazon - Email: mulmarta@amazon.com - - - Suhas Nandakumar - Cisco - Email: snandaku@cisco.com - - - Tomas Rigaux - Cisco - Email: trigaux@cisco.com - - - Raphael Robert - Phoenix R&D - Email: ietf@raphaelrobert.com - - -Authors' Addresses - - Emad Omara - Apple - Email: eomara@apple.com - - - Justin Uberti - Google - Email: juberti@google.com - - - Sergio Garcia Murillo - CoSMo Software - Email: sergio.garcia.murillo@cosmosoftware.io - - - Richard L. Barnes (editor) - Cisco - Email: rlb@ipv.sx - - - Youenn Fablet - Apple - Email: youenn@apple.com diff --git a/artart-iana/index.html b/artart-iana/index.html deleted file mode 100644 index e0e6e81..0000000 --- a/artart-iana/index.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - sframe-wg/sframe artart-iana preview - - - - -

Editor's drafts for artart-iana branch of sframe-wg/sframe

- - - - - - -
SFrameplain textsame as main
- - - diff --git a/draft-ietf-sframe-enc-07/draft-ietf-sframe-enc.html b/draft-ietf-sframe-enc-07/draft-ietf-sframe-enc.html deleted file mode 100644 index 0e7da8e..0000000 --- a/draft-ietf-sframe-enc-07/draft-ietf-sframe-enc.html +++ /dev/null @@ -1,6290 +0,0 @@ - - - - - - -Secure Frame (SFrame) - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Internet-DraftSFrameFebruary 2024
Omara, et al.Expires 1 September 2024[Page]
-
-
-
-
Workgroup:
-
Network Working Group
-
Internet-Draft:
-
draft-ietf-sframe-enc-latest
-
Published:
-
- -
-
Intended Status:
-
Standards Track
-
Expires:
-
-
Authors:
-
-
-
E. Omara
-
Apple
-
-
-
J. Uberti
-
Google
-
-
-
S. Murillo
-
CoSMo Software
-
-
-
R. L. Barnes, Ed. -
-
Cisco
-
-
-
Y. Fablet
-
Apple
-
-
-
-
-

Secure Frame (SFrame)

-
-

Abstract

-

This document describes the Secure Frame (SFrame) end-to-end encryption and -authentication mechanism for media frames in a multiparty conference call, in -which central media servers (selective forwarding units or SFUs) can access the -media metadata needed to make forwarding decisions without having access to the -actual media.

-

The proposed mechanism differs from the Secure Real-Time Protocol (SRTP) in that -it is independent of RTP (thus compatible with non-RTP media transport) and can -be applied to whole media frames in order to be more bandwidth efficient.

-
-
-

-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://sframe-wg.github.io/sframe/draft-ietf-sframe-enc.html. - Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-sframe-enc/.

-

- Discussion of this document takes place on the - Secure Media Frames Working Group mailing list (mailto:sframe@ietf.org), - which is archived at https://mailarchive.ietf.org/arch/browse/sframe/. - Subscribe at https://www.ietf.org/mailman/listinfo/sframe/.

-

Source for this draft and an issue tracker can be found at - https://github.com/sframe-wg/sframe.

-
-
-
-

-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 1 September 2024.

-
-
- -
-
- ▲

-Table of Contents -

- -
-
-
-
-

-1. Introduction -

-

Modern multi-party video call systems use Selective Forwarding Unit (SFU) -servers to efficiently route media streams to call endpoints based on factors such -as available bandwidth, desired video size, codec support, and other factors. An -SFU typically does not need access to the media content of the conference, -allowing for the media to be "end-to-end" encrypted so that it cannot be -decrypted by the SFU. In order for the SFU to work properly, though, it usually -needs to be able to access RTP metadata and RTCP feedback messages, which is not -possible if all RTP/RTCP traffic is end-to-end encrypted.

-

As such, two layers of encryption and authentication are required:

-
    -
  1. -

    Hop-by-hop (HBH) encryption of media, metadata, and feedback messages -between the the endpoints and SFU

    -
    2. -
  2. -

    End-to-end (E2E) encryption (E2EE) of media between the endpoints

    -
    3. -
-

The Secure Real-Time Protocol (SRTP) is already widely used for HBH encryption -[RFC3711]. The SRTP "double encryption" scheme defines a way to do E2E -encryption in SRTP [RFC8723]. Unfortunately, this scheme has poor efficiency -and high complexity, and its entanglement with RTP makes it unworkable in -several realistic SFU scenarios.

-

This document proposes a new E2EE protection scheme known as SFrame, -specifically designed to work in group conference calls with SFUs. SFrame is a -general encryption framing that can be used to protect media payloads, agnostic -of transport.

-
-
-
-
-

-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.

-
-
MAC:
-
-

Message Authentication Code

-
-
-
E2EE:
-
-

End to End Encryption

-
-
-
HBH:
-
-

Hop By Hop

-
-
-
-

We use "Selective Forwarding Unit (SFU)" and "media stream" in a less formal sense -than in [RFC7656]. An SFU is a selective switching function for media -payloads, and a media stream a sequence of media payloads, in both cases -regardless of whether those media payloads are transported over RTP or some -other protocol.

-
-
-
-
-

-3. Goals -

-

SFrame is designed to be a suitable E2EE protection scheme for conference call -media in a broad range of scenarios, as outlined by the following goals:

-
    -
  1. -

    Provide a secure E2EE mechanism for audio and video in conference calls -that can be used with arbitrary SFU servers.

    -
    2. -
  2. -

    Decouple media encryption from key management to allow SFrame to be used -with an arbitrary key management system.

    -
    3. -
  3. -

    Minimize packet expansion to allow successful conferencing in as many -network conditions as possible.

    -
    4. -
  4. -

    Independence from the underlying transport, including use in non-RTP -transports, e.g., WebTransport [I-D.ietf-webtrans-overview].

    -
    5. -
  5. -

    When used with RTP and its associated error resilience mechanisms, i.e., RTX -and FEC, require no special handling for RTX and FEC packets.

    -
    6. -
  6. -

    Minimize the changes needed in SFU servers.

    -
    7. -
  7. -

    Minimize the changes needed in endpoints.

    -
    8. -
  8. -

    Work with the most popular audio and video codecs used in conferencing -scenarios.

    -
    9. -
-
-
-
-
-

-4. SFrame -

-

This document defines an encryption mechanism that provides effective E2EE, -is simple to implement, has no dependencies on RTP, and minimizes -encryption bandwidth overhead. This section describes how the mechanism -works, including details of how applications utilize SFrame for media protection, -as well as the actual mechanics of E2EE for protecting media.

-
-
-

-4.1. Application Context -

-

SFrame is a general encryption framing, intended to be used as an E2EE -layer over an underlying HBH-encrypted transport such as SRTP or QUIC -[RFC3711][I-D.ietf-moq-transport].

-

The scale at which SFrame encryption is applied to media determines the overall -amount of overhead that SFrame adds to the media stream, as well as the -engineering complexity involved in integrating SFrame into a particular -environment. Two patterns are common: Either using SFrame to encrypt whole -media frames (per-frame) or individual transport-level media payloads -(per-packet).

-

For example, Figure 1 shows a typical media sender stack that takes media -from some source, encodes it into frames, divides those frames into media -packets, and then sends those payloads in SRTP packets. The receiver stack -performs the reverse operations, reassembling frames from SRTP packets and -decoding. Arrows indicate two different ways that SFrame protection could be -integrated into this media stack, to encrypt whole frames or individual media -packets.

-

Applying SFrame per-frame in this system offers higher efficiency, but may -require a more complex integration in environments where depacketization relies -on the content of media packets. Applying SFrame per-packet avoids this -complexity, at the cost of higher bandwidth consumption. Some quantitative -discussion of these trade-offs is provided in Appendix C.

-

As noted above, however, SFrame is a general media encapsulation, and can be -applied in other scenarios. The important thing is that the sender and -receivers of an SFrame-encrypted object agree on that object's semantics. -SFrame does not provide this agreement; it must be arranged by the application.

-
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - HBH - Encode - Packetize - Protect - SFrame - SFrame - Protect - Protect - Alice - (per-frame) - (per-packet) - E2E - Key - HBH - Key - Media - Management - Management - Server - SFrame - SFrame - Unprotect - Unprotect - (per-frame) - (per-packet) - HBH - Decode - Depacketize - Unprotect - Bob - - -
-
-
Figure 1
-
-

Like SRTP, SFrame does not define how the keys used for SFrame are exchanged by -the parties in the conference. Keys for SFrame might be distributed over an -existing E2E-secure channel (see Section 5.1), or derived from an E2E-secure -shared secret (see Section 5.2). The key management system MUST ensure that each -key used for encrypting media is used by exactly one media sender, in order to -avoid reuse of nonces.

-
-
-
-
-

-4.2. SFrame Ciphertext -

-

An SFrame ciphertext comprises an SFrame header followed by the output of an -AEAD encryption of the plaintext [RFC5116], with the header provided as additional -authenticated data (AAD).

-

The SFrame header is a variable-length structure described in detail in -Section 4.3. The structure of the encrypted data and authentication tag -are determined by the AEAD algorithm in use.

-
-
- - - - - - - - - - - - - - - - - - - - - - K - KLEN - C - CLEN - Key - ID - Counter - Encrypted - Data - Authentication - Tag - Encrypted - Portion - Authenticated - Portion - - -
-
-

When SFrame is applied per-packet, the payload of each packet will be an SFrame -ciphertext. When SFrame is applied per-frame, the SFrame ciphertext -representing an encrypted frame will span several packets, with the header -appearing in the first packet and the authentication tag in the last packet. -It is the responsibility of the application to reassemble an encrypted frame from -individual packets, accounting for packet loss and reordering as necessary.

-
-
-
-
-

-4.3. SFrame Header -

-

The SFrame header specifies two values from which encryption parameters are -derived:

-
    -
  • -

    A Key ID (KID) that determines which encryption key should be used

    -
    • -
  • -

    A counter (CTR) that is used to construct the nonce for the encryption

    -
    • -
-

Applications MUST ensure that each (KID, CTR) combination is used for exactly -one SFrame encryption operation. A typical approach to achieving this guarantee is -outlined in Section 9.1.

-
-
-
-
- - - - - - - - - - - - - - - - - - Config - Byte - 0 - 1 - 2 - 3 - 4 - 5 - 6 - 7 - X - K - Y - C - KID... - CTR... - - -
-
-
Figure 2: -SFrame header -
-
-

The SFrame Header has the overall structure shown in Figure 2. The -first byte is a "config byte", with the following fields:

-
-
Extended Key Id Flag (X, 1 bit):
-
-

Indicates if the K field contains the key id or the Key ID length.

-
-
-
Key or Key Length (K, 3 bits):
-
-

If the X flag is set to 0, this field contains the Key ID. If the X flag is -set to 1, then it contains the length of the Key ID, minus one.

-
-
-
Extended Counter Flag (Y, 1 bit):
-
-

Indicates if the C field contains the counter or the counter length.

-
-
-
Counter or Counter Length (C, 3 bits):
-
-

This field contains the counter (CTR) if the Y flag is set to 0, or the counter -length, minus one, if set to 1.

-
-
-
-

The Key ID and Counter fields are encoded as compact unsigned integers in -network (big-endian) byte order. If the value of one of these fields is in the -range 0-7, then the value is carried in the corresponding bits of the config -byte (K or C) and the corresponding flag (X or Y) is set to zero. Otherwise, -the value MUST be encoded with the minimum number of bytes required and -appended after the configuration byte, with the Key ID first and Counter second. -The header field (K or C) is set to the number of bytes in the encoded value, -minus one. The value 000 represents a length of 1, 001 a length of 2, etc. -This allows a 3-bit length field to represent the value lengths 1-8.

-

The SFrame header can thus take one of the four forms shown in -Figure 3, depending on which of the X and Y flags are set.

-
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - KID - < - 8, - CTR - < - 8: - 0 - KID - 0 - CTR - KID - < - 8, - CTR - >= - 8: - 0 - KID - 1 - CLEN - CTR... - (length=CLEN) - KID - >= - 8 - CTR - < - 8: - 1 - KLEN - 0 - CTR - KID... - (length=KLEN) - KID - >= - 8 - CTR - >= - 8: - 1 - KLEN - 1 - CLEN - KID... - (length=KLEN) - CTR... - (length=CLEN) - - -
-
-
Figure 3: -Forms of Encoded SFrame Header -
-
-
-
-
-
-

-4.4. Encryption Schema -

-

SFrame encryption uses an AEAD encryption algorithm and hash function defined by -the cipher suite in use (see Section 4.5). We will refer to the following -aspects of the AEAD and the hash algorithm below:

-
    -
  • -

    AEAD.Encrypt and AEAD.Decrypt - The encryption and decryption functions -for the AEAD. We follow the convention of RFC 5116 [RFC5116] and consider -the authentication tag part of the ciphertext produced by AEAD.Encrypt (as -opposed to a separate field as in SRTP [RFC3711]).

    -
    • -
  • -

    AEAD.Nk - The size in bytes of a key for the encryption algorithm

    -
    • -
  • -

    AEAD.Nn - The size in bytes of a nonce for the encryption algorithm

    -
    • -
  • -

    AEAD.Nt - The overhead in bytes of the encryption algorithm (typically the -size of a "tag" that is added to the plaintext)

    -
    • -
  • -

    AEAD.Nka - For cipher suites using the compound AEAD described in -Section 4.5.1, the size in bytes of a key for the underlying AES-CTR -algorithm

    -
    • -
  • -

    Hash.Nh - The size in bytes of the output of the hash function

    -
    • -
-
-
-

-4.4.1. Key Selection -

-

Each SFrame encryption or decryption operation is premised on a single secret -base_key, which is labeled with an integer KID value signaled in the SFrame -header.

-

The sender and receivers need to agree on which base_key should be used for a given -KID. Moreover, senders and receivers need to agree on whether a base_key will be used -for encryption or decryption only. The process for provisioning base_key values and their KID -values is beyond the scope of this specification, but its security properties will -bound the assurances that SFrame provides. For example, if SFrame is used to -provide E2E security against intermediary media nodes, then SFrame keys need to -be negotiated in a way that does not make them accessible to these intermediaries.

-

For each known KID value, the client stores the corresponding symmetric key -base_key. For keys that can be used for encryption, the client also stores -the next counter value CTR to be used when encrypting (initially 0).

-

When encrypting a plaintext, the application specifies which KID is to be used, -and the counter is incremented after successful encryption. When decrypting, -the base_key for decryption is selected from the available keys using the KID -value in the SFrame Header.

-

A given base_key MUST NOT be used for encryption by multiple senders. Such reuse -would result in multiple encrypted frames being generated with the same (key, -nonce) pair, which harms the protections provided by many AEAD algorithms. -Implementations MUST mark each base_key as usable for encryption or decryption, -never both.

-

Note that the set of available keys might change over the lifetime of a -real-time session. In such cases, the client will need to manage key usage to -avoid media loss due to a key being used to encrypt before all receivers are -able to use it to decrypt. For example, an application may make decryption-only -keys available immediately, but delay the use of keys for encryption until (a) -all receivers have acknowledged receipt of the new key or (b) a timeout expires.

-
-
-
-
-

-4.4.2. Key Derivation -

-

SFrame encryption and decryption use a key and salt derived from the base_key -associated to a KID. Given a base_key value, the key and salt are derived -using HKDF [RFC5869] as follows:

-
-
-def derive_key_salt(KID, base_key):
-  sframe_secret = HKDF-Extract("", base_key)
-
-  sframe_key_label = "SFrame 1.0 Secret key " + KID + cipher_suite
-  sframe_key = HKDF-Expand(sframe_secret, info, AEAD.Nk)
-
-  sframe_salt_label = "SFrame 1.0 Secret salt " + KID + cipher_suite
-  sframe_salt = HKDF-Expand(sframe_secret, info, AEAD.Nn)
-
-  return sframe_key, sframe_salt
-
-
-

In the derivation of sframe_secret:

-
    -
  • -

    The + operator represents concatenation of byte strings.

    -
    • -
  • -

    The KID value is encoded as an 8-byte big-endian integer, not the compressed -form used in the SFrame header.

    -
    • -
  • -

    The cipher_suite value is a 2-byte big-endian integer representing the -cipher suite in use (see Section 8.1).

    -
    • -
-

The hash function used for HKDF is determined by the cipher suite in use.

-
-
-
-
-

-4.4.3. Encryption -

-

SFrame encryption uses the AEAD encryption algorithm for the cipher suite in use. -The key for the encryption is the sframe_key and the nonce is formed by XORing -the sframe_salt with the current counter, encoded as a big-endian integer of -length AEAD.Nn.

-

The encryptor forms an SFrame header using the CTR, and KID values provided. -The encoded header is provided as AAD to the AEAD encryption operation, together -with application-provided metadata about the encrypted media (see Section 9.4).

-
-
-def encrypt(CTR, KID, metadata, plaintext):
-  sframe_key, sframe_salt = key_store[KID]
-
-  # encode_big_endian(x, n) produces an n-byte string encoding the integer x in
-  # big-endian byte order.
-  ctr = encode_big_endian(CTR, AEAD.Nn)
-  nonce = xor(sframe_salt, CTR)
-
-  # encode_sframe_header produces a byte string encoding the provided KID and
-  # CTR values into an SFrame Header.
-  header = encode_sframe_header(CTR, KID)
-  aad = header + metadata
-
-  ciphertext = AEAD.Encrypt(sframe_key, nonce, aad, plaintext)
-  return header + ciphertext
-
-
-

For example, the metadata input to encryption allows for frame metadata to be -authenticated when SFrame is applied per-frame. After encoding the frame and -before packetizing it, the necessary media metadata will be moved out of the -encoded frame buffer, to be sent in some channel visible to the SFU (e.g., an -RTP header extension).

-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - plaintext - sframe_key - Key - Header - KID - sframe_salt - Nonce - CTR - metadata - AAD - AEAD.Encrypt - SFrame - Ciphertext - SFrame - Header - ciphertext - - -
-
-
Figure 4: -Encrypting an SFrame Ciphertext -
-
-
-
-
-

-4.4.4. Decryption -

-

Before decrypting, a receiver needs to assemble a full SFrame ciphertext. When -an SFrame ciphertext may be fragmented into multiple parts for transport (e.g., -a whole encrypted frame sent in multiple SRTP packets), the receiving client -collects all the fragments of the ciphertext, using an appropriate sequencing -and start/end markers in the transport. Once all of the required fragments are -available, the client reassembles them into the SFrame ciphertext, then passes -the ciphertext to SFrame for decryption.

-

The KID field in the SFrame header is used to find the right key and salt for -the encrypted frame, and the CTR field is used to construct the nonce. The SFrame -decryption procedure is as follows:

-
-
-def decrypt(metadata, sframe_ciphertext):
-  KID, CTR, header, ciphertext = parse_ciphertext(sframe_ciphertext)
-
-  sframe_key, sframe_salt = key_store[KID]
-
-  ctr = encode_big_endian(CTR, AEAD.Nn)
-  nonce = xor(sframe_salt, ctr)
-  aad = header + metadata
-
-  return AEAD.Decrypt(sframe_key, nonce, aad, ciphertext)
-
-
-

If a ciphertext fails to decrypt because there is no key available for the KID -in the SFrame 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 ciphertexts SHOULD be -discarded in a way that is indistinguishable (to an external observer) from having -processed a valid ciphertext.

-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - SFrame - Ciphertext - SFrame - Header - ciphertext - sframe_key - Key - KID - sframe_salt - Nonce - CTR - metadata - AAD - AEAD.Decrypt - | - plaintext - - -
-
-
Figure 5: -Decrypting an SFrame Ciphertext -
-
-
-
-
-
-
-

-4.5. Cipher Suites -

-

Each SFrame session uses a single cipher suite that specifies the following -primitives:

-
    -
  • -

    A hash function used for key derivation

    -
    • -
  • -

    An AEAD encryption algorithm [RFC5116] used for frame encryption, optionally -with a truncated authentication tag

    -
    • -
-

This document defines the following cipher suites, with the constants defined in -Section 4.4:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 1: -SFrame cipher suite constants -
NameNhNkaNkNnNt
- AES_128_CTR_HMAC_SHA256_80 -3216481210
- AES_128_CTR_HMAC_SHA256_64 -321648128
- AES_128_CTR_HMAC_SHA256_32 -321648124
- AES_128_GCM_SHA256_128 -32n/a161216
- AES_256_GCM_SHA512_128 -64n/a321216
-
-

Numeric identifiers for these cipher suites are defined in the IANA registry -created in Section 8.1.

-

In the suite names, the length of the authentication tag is indicated by -the last value: "_128" indicates a hundred-twenty-eight-bit tag, "_80" indicates -a eighty-bit tag, "_64" indicates a sixty-four-bit tag and "_32" indicates a -thirty-two-bit tag.

-

In a session that uses multiple media streams, different cipher suites might be -configured for different media streams. For example, in order to conserve -bandwidth, a session might use a cipher suite with eighty-bit tags for video frames -and another cipher suite with thirty-two-bit tags for audio frames.

-
-
-

-4.5.1. AES-CTR with SHA2 -

-

In order to allow very short tag sizes, we define a synthetic AEAD function -using the authenticated counter mode of AES together with HMAC for -authentication. We use an encrypt-then-MAC approach, as in SRTP [RFC3711].

-

Before encryption or decryption, encryption and authentication subkeys are -derived from the single AEAD key. The overall length of the AEAD key is Nka + -Nh, where Nka represents the key size for the AES block cipher in use and Nh -represents the output size of the hash function (as in Table 2). -The encryption subkey comprises the first Nka bytes and the authentication -subkey comprises the remaining Nh bytes.

-
-
-def derive_subkeys(sframe_key):
-  enc_key = sframe_key[..Nka]
-  auth_key = sframe_key[Nka..]
-  return enc_key, auth_key
-
-
-

The AEAD encryption and decryption functions are then composed of individual -calls to the CTR encrypt function and HMAC. The resulting MAC value is truncated -to a number of bytes Nt fixed by the cipher suite.

-
-
-def truncate(tag, n):
-  # Take the first `n` bytes of `tag`
-  return tag[..n]
-
-def compute_tag(auth_key, nonce, aad, ct):
-  aad_len = encode_big_endian(len(aad), 8)
-  ct_len = encode_big_endian(len(ct), 8)
-  tag_len = encode_big_endian(Nt, 8)
-  auth_data = aad_len + ct_len + tag_len + nonce + aad + ct
-  tag = HMAC(auth_key, auth_data)
-  return truncate(tag, Nt)
-
-def AEAD.Encrypt(key, nonce, aad, pt):
-  enc_key, auth_key = derive_subkeys(key)
-  initial_counter = nonce + 0x00000000 # append four zero bytes
-  ct = AES-CTR.Encrypt(enc_key, initial_counter, pt)
-  tag = compute_tag(auth_key, nonce, aad, ct)
-  return ct + tag
-
-def AEAD.Decrypt(key, nonce, aad, ct):
-  inner_ct, tag = split_ct(ct, tag_len)
-
-  enc_key, auth_key = derive_subkeys(key)
-  candidate_tag = compute_tag(auth_key, nonce, aad, inner_ct)
-  if !constant_time_equal(tag, candidate_tag):
-    raise Exception("Authentication Failure")
-
-  initial_counter = nonce + 0x00000000 # append four zero bytes
-  return AES-CTR.Decrypt(enc_key, initial_counter, inner_ct)
-
-
-
-
-
-
-
-
-
-
-

-5. Key Management -

-

SFrame must be integrated with an E2E key management framework to exchange and -rotate the keys used for SFrame encryption. The key management -framework provides the following functions:

-
    -
  • -

    Provisioning KID / base_key mappings to participating clients

    -
    • -
  • -

    Updating the above data as clients join or leave

    -
    • -
-

It is the responsibility of the application to provide the key management -framework, as described in Section 9.2.

-
-
-

-5.1. Sender Keys -

-

If the participants in a call have a pre-existing E2E-secure channel, they can -use it to distribute SFrame keys. Each client participating in a call generates -a fresh base_key value that it will use to encrypt media. The client then uses -the E2E-secure channel to send their encryption key to the other participants.

-

In this scheme, it is assumed that receivers have a signal outside of SFrame for -which client has sent a given frame (e.g., an RTP SSRC). SFrame KID -values are then used to distinguish between versions of the sender's base_key.

-

Key IDs in this scheme have two parts, a "key generation" and a "ratchet step". -Both are unsigned integers that begin at zero. The key generation increments -each time the sender distributes a new key to receivers. The "ratchet step" is -incremented each time the sender ratchets their key forward for forward secrecy:

-
-
-base_key[i+1] = HKDF-Expand(
-                  HKDF-Extract("", base_key[i]),
-                  "SFrame 1.0 Ratchet", CipherSuite.Nh)
-
-
-

For compactness, we do not send the whole ratchet step. Instead, we send only -its low-order R bits, where R is a value set by the application. Different -senders may use different values of R, but each receiver of a given sender -needs to know what value of R is used by the sender so that they can recognize -when they need to ratchet (vs. expecting a new key). R effectively defines a -re-ordering window, since no more than 2R ratchet steps can be -active at a given time. The key generation is sent in the remaining 64 - R -bits of the key ID.

-
-
-KID = (key_generation << R) + (ratchet_step % (1 << R))
-
-
-
-
-
-
- - - - - - - - - - - - - - 64-R - bits - R - bits - Key - Generation - Ratchet - Step - - -
-
-
Figure 6: -Structure of a KID in the Sender Keys scheme -
-
-

The sender signals such a ratchet step update by sending with a KID value in -which the ratchet step has been incremented. A receiver who receives from a -sender with a new KID computes the new key as above. The old key may be kept -for some time to allow for out-of-order delivery, but should be deleted -promptly.

-

If a new participant joins in the middle of a session, they will need to receive -from each sender (a) the current sender key for that sender and (b) the current -KID value for the sender. Evicting a participant requires each sender to send -a fresh sender key to all receivers.

-

It is up to the application to decide when sender keys are updated. A sender -key may be updated by sending a new base_key (updating the key generation) or -by hashing the current base_key (updating the ratchet step). Ratcheting the -key forward is useful when adding new receivers to an SFrame-based interaction, -since it assures that the new receivers can't decrypt any media encrypted before -they were added. If a sender wishes to assure the opposite property when -removing a receiver (i.e., ensuring that the receiver can't decrypt media after -they are removed), then the sender will need to distribute a new sender key.

-
-
-
-
-

-5.2. MLS -

-

The Messaging Layer Security (MLS) protocol provides group authenticated key -exchange [MLS-ARCH] [MLS-PROTO]. In -principle, it could be used to instantiate the sender key scheme above, but it -can also be used more efficiently directly.

-

MLS creates a linear sequence of keys, each of which is shared among the members -of a group at a given point in time. When a member joins or leaves the group, a -new key is produced that is known only to the augmented or reduced group. Each -step in the lifetime of the group is known as an "epoch", and each member of the -group is assigned an "index" that is constant for the time they are in the -group.

-

To generate keys and nonces for SFrame, we use the MLS exporter function to -generate a base_key value for each MLS epoch. Each member of the group is -assigned a set of KID values, so that each member has a unique sframe_key and -sframe_salt that it uses to encrypt with. Senders may choose any KID value -within their assigned set of KID values, e.g., to allow a single sender to send -multiple uncoordinated outbound media streams.

-
-
-base_key = MLS-Exporter("SFrame 1.0 Base Key", "", AEAD.Nk)
-
-
-

For compactness, we do not send the whole epoch number. Instead, we send only -its low-order E bits, where E is a value set by the application. E -effectively defines a re-ordering window, since no more than 2E -epochs can be active at a given time. Receivers MUST be prepared for the epoch -counter to roll over, removing an old epoch when a new epoch with the same E -lower bits is introduced.

-

Let S be the number of bits required to encode a member index in the group, -i.e., the smallest value such that group_size <= (1 << S). The sender index -is encoded in the S bits above the epoch. The remaining 64 - S - E bits of -the KID value are a context value chosen by the sender (context value 0 will -produce the shortest encoded KID).

-
-
-KID = (context << (S + E)) + (sender_index << E) + (epoch % (1 << E))
-
-
-
-
-
-
- - - - - - - - - - - - - - - - - - 64-S-E - bits - S - bits - E - bits - Context - ID - Index - Epoch - - -
-
-
Figure 7: -Structure of a KID for an MLS Sender -
-
-

Once an SFrame stack has been provisioned with the sframe_epoch_secret for an -epoch, it can compute the required KID values on demand (as well as the -resulting SFrame keys/nonces derived from the base_key and KID), as it needs -to encrypt or decrypt for a given member.

-
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ... - Epoch - 14 - index=3 - KID - = - 0x3e - index=7 - KID - = - 0x7e - index=20 - KID - = - 0x14e - Epoch - 15 - index=3 - KID - = - 0x3f - index=5 - KID - = - 0x5f - Epoch - 16 - index=2 - context - = - 2 - KID - = - 0x820 - context - = - 3 - KID - = - 0xc20 - Epoch - 17 - index=33 - KID - = - 0x211 - index=51 - KID - = - 0x331 - ... - - -
-
-
Figure 8: -An example sequence of KIDs for an MLS-based SFrame session (E=4; S=6, allowing for 64 group members) -
-
-
-
-
-
-
-
-

-6. Media Considerations -

-
-
-

-6.1. Selective Forwarding Units -

-

Selective Forwarding Units (SFUs) (e.g., those described in Section 3.7 of [RFC7667]) receive the media streams from each participant and select which -ones should be forwarded to each of the other participants. There are several -approaches for stream selection, but in general, the SFU needs to access -metadata associated to each frame and modify the RTP information of the incoming -packets when they are transmitted to the received participants.

-

This section describes how this normal SFU modes of operation interact with the -E2EE provided by SFrame.

-
-
-

-6.1.1. LastN and RTP stream reuse -

-

The SFU may choose to send only a certain number of streams based on the voice -activity of the participants. To avoid the overhead involved in establishing new -transport streams, the SFU may decide to reuse previously existing streams or -even pre-allocate a predefined number of streams and choose in each moment in -time which participant media will be sent through it.

-

This means that in the same transport-level stream (e.g., an RTP stream defined -by either SSRC or MID) may carry media from different streams of different -participants. As different keys are used by each participant for encoding their -media, the receiver will be able to verify which is the sender of the media -coming within the RTP stream at any given point in time, preventing the SFU -trying to impersonate any of the participants with another participant's media.

-

Note that in order to prevent impersonation by a malicious participant (not the -SFU), a mechanism based on digital signature would be required. SFrame does not -protect against such attacks.

-
-
-
-
-

-6.1.2. Simulcast -

-

When using simulcast, the same input image will produce N different encoded -frames (one per simulcast layer) which would be processed independently by the -frame encryptor and assigned an unique counter for each.

-
-
-
-
-

-6.1.3. SVC -

-

In both temporal and spatial scalability, the SFU may choose to drop layers in -order to match a certain bitrate or forward specific media sizes or frames per -second. In order to support the SFU selectively removing layers, the sender MUST -encapsulate each layer in a different SFrame ciphertext.

-
-
-
-
-
-
-

-6.2. Video Key Frames -

-

Forward Security and Post-Compromise Security require that the E2EE keys (base keys) -are updated any time a participant joins or leaves the call.

-

The key exchange happens asynchronously and on a different path than the SFU signaling -and media. So it may happen that when a new participant joins the call and the -SFU side requests a key frame, the sender generates the E2EE frame -with a key not known by the receiver, so it will be discarded. When the sender -updates his sending key with the new key, it will send it in a non-key frame, so -the receiver will be able to decrypt it, but not decode it.

-

The new Receiver will then re-request a key frame, but due to sender and SFU -policies, that new key frame could take some time to be generated.

-

If the sender sends a key frame after the new E2EE key is in use, the time -required for the new participant to display the video is minimized.

-

Note that this issue does not arise for media streams that do not have -dependencies among frames, e.g., audio streams. In these streams, each frame is -independently decodeable, so there is never a need to process two frames -together which might be on two sides of a key rotation.

-
-
-
-
-

-6.3. Partial Decoding -

-

Some codecs support partial decoding, where individual packets can be decoded -without waiting for the full frame to arrive. When SFrame is applied per-frame, -this won't be possible because the decoder cannot access data until an entire -frame has arrived and has been decrypted.

-
-
-
-
-
-
-

-7. Security Considerations -

-
-
-

-7.1. No Header Confidentiality -

-

SFrame provides integrity protection to the SFrame Header (the key ID and -counter values), but does not provide confidentiality protection. Parties that -can observe the SFrame header may learn, for example, which parties are sending -SFrame payloads (from KID values) and at what rates (from CTR values). In cases -where SFrame is used for end-to-end security on top of hop-by-hop protections -(e.g., running over SRTP as described in Appendix C.5), the hop-by-hop security -mechanisms provide confidentiality protection of the SFrame header between hops.

-
-
-
-
-

-7.2. No Per-Sender Authentication -

-

SFrame does not provide per-sender authentication of media data. Any sender in -a session can send media that will be associated with any other sender. This is -because SFrame uses symmetric encryption to protect media data, so that any -receiver also has the keys required to encrypt packets for the sender.

-
-
-
-
-

-7.3. Key Management -

-

Key exchange mechanism is out of scope of this document, however every client -SHOULD change their keys when new clients joins or leaves the call for forward -secrecy and post compromise security.

-
-
-
-
-

-7.4. Replay -

-

The handling of replay is out of the scope of this document. However, senders -MUST reject requests to encrypt multiple times with the same key and nonce, -since several AEAD algorithms fail badly in such cases (see, e.g., Section 5.1.1 of [RFC5116]).

-
-
-
-
-

-7.5. Risks due to Short Tags -

-

The SFrame ciphersuites based on AES-CTR allow for the use of short -authentication tags, which bring a higher risk that an attacker will be -able to cause an SFrame receiver to accept an SFrame ciphertext of the -attacker's choosing.

-

Assuming that the authentication properties of the ciphersuite are robust, the -only attack that an attacker can mount is an attempt to find an acceptable -(ciphertext, tag) combination through brute force. Such a brute-force attack -will have an expected sucess rate of the following form:

-

-attacker_success_rate = attempts_per_second / 2^(8*Nt) -

-

For example, a gigabit ethernet connection is able to transmit roughly 2^20 -packets per second. If an attacker saturated such a link with guesses against a -32-bit authentication tag (Nt=4), then the attacker would succeed on average -roughly once every 2^12 seconds, or about once an hour.

-

In a typical SFrame usage in a real-time media application, there are a few -approaches to mitigating this risk:

-
    -
  • -

    Receivers only accept SFrame ciphertexts over HBH-secure channels (e.g., SRTP -security associations or QUIC connections). If this is the case, only an -entity that is part of such a channel can mount the above attack.

    -
    • -
  • -

    The expected packet rate for a media stream is very predictable (and typically -far lower than the above example). On the one hand, attacks at this rate will -succeed even less often than the high-rate attack described above. On the -other hand, the application may use an elevated packet arrival rate as a -signal of a brute-force attack. This latter approach is common in other -settings, e.g., mitigating brute-force attacks on passwords.

    -
    • -
  • -

    Media applications typically do not provide feedback to media senders as to -which media packets failed to decrypt. When media quality feedback -mechanisms are used, decryption failures will typically appear as packet -losses, but only at an aggregate level.

    -
    • -
  • -

    Anti-replay mechanisms (see Section 7.4) prevent the attacker from re-using -valid ciphertexts (either observed or guessed by the attacker). A receiver -applying anti-replay controls will only accept one valid plaintext per CTR -value. Since the CTR value is covered by SFrame authentication, an attacker -has to do a fresh search for a valid tag for every forged ciphertext, even if -the encrypted content is unchanged. In other words, when the above brute -force attack succeeds, it only allows the attacker to send a single SFrame -ciphertext; the ciphertext cannot be reused because either it will have the -same CTR value and be discarded as a replay, or else it will have a different -CTR value its tag will no longer be valid.

    -
    • -
-

Nonetheless, without these mitigations, an application that makes use of short -tags will be at heightened risk of forgery attacks. In many cases, it is -simpler to use full-size tags and tolerate slightly higher bandwidth usage -rather than add the additional defenses necessary to safely use short tags.

-
-
-
-
-
-
-

-8. IANA Considerations -

-

This document requests the creation of the following new IANA registry:

- -

This registry should be under a heading of "SFrame", and assignments are made -via the Specification Required policy [RFC8126].

-

RFC EDITOR: Please replace XXXX throughout with the RFC number assigned to -this document

-
-
-

-8.1. SFrame Cipher Suites -

-

This registry lists identifiers for SFrame cipher suites, as defined in -Section 4.5. The cipher suite field is two bytes wide, so the valid cipher -suites are in the range 0x0000 to 0xFFFF.

-

Template:

-
    -
  • -

    Value: The numeric value of the cipher suite

    -
    • -
  • -

    Name: The name of the cipher suite

    -
    • -
  • -

    Reference: The document where this cipher suite is defined

    -
    • -
-

Initial contents:

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 2: -SFrame cipher suites -
ValueNameReference
0x0000ReservedRFC XXXX
0x0001 - AES_128_CTR_HMAC_SHA256_80 -RFC XXXX
0x0002 - AES_128_CTR_HMAC_SHA256_64 -RFC XXXX
0x0003 - AES_128_CTR_HMAC_SHA256_32 -RFC XXXX
0x0004 - AES_128_GCM_SHA256_128 -RFC XXXX
0x0005 - AES_256_GCM_SHA512_128 -RFC XXXX
0xF000 - 0xFFFFReserved for private useRFC XXXX
-
-
-
-
-
-
-
-

-9. Application Responsibilities -

-

To use SFrame, an application needs to define the inputs to the SFrame -encryption and decryption operations, and how SFrame ciphertexts are delivered -from sender to receiver (including any fragmentation and reassembly). In this -section, we lay out additional requirements that an integration must meet in -order for SFrame to operate securely.

-

In general, an application using SFrame is responsible for configuring SFrame. -The application must first define when SFrame is applied at all. When SFrame is -applied, the application must define which cipher suite is to be used. If new -versions of SFrame are defined in the future, it will be up to the application -to determine which version should be used.

-

This division of responsibilities is similar to the way other media parameters -(e.g., codecs) are typically handled in media applications, in the sense that -they are set up in some signaling protocol, and then not described in the media. -Applications might find it useful to extend the protocols used for negotiating -other media parameters (e.g., SDP [RFC4566]) to also negotiate parameters for -SFrame.

-
-
-

-9.1. Header Value Uniqueness -

-

Applications MUST ensure that each (base_key, KID, CTR) combination is used -for at most one SFrame encryption operation. This ensures that the (key, nonce) -pairs used by the underlying AEAD algorithm are never reused. Typically this is -done by assigning each sender a KID or set of KIDs, then having each sender use -the CTR field as a monotonic counter, incrementing for each plaintext that is -encrypted. In addition to its simplicity, this scheme minimizes overhead by -keeping CTR values as small as possible.

-
-
-
-
-

-9.2. Key Management Framework -

-

It is up to the application to provision SFrame with a mapping of KID values to -base_key values and the resulting keys and salts. More importantly, the -application specifies which KID values are used for which purposes (e.g., by -which senders). An application's KID assignment strategy MUST be structured to -assure the non-reuse properties discussed in Section 9.1.

-

It is also up to the application to define a rotation schedule for keys. For -example, one application might have an ephemeral group for every call and keep -rotating keys when end points join or leave the call, while another application -could have a persistent group that can be used for multiple calls and simply -derives ephemeral symmetric keys for a specific call.

-

It should be noted that KID values are not encrypted by SFrame, and are thus -visible to any application-layer intermediaries that might handle an SFrame -ciphertext. If there are application semantics included in KID values, then -this information would be exposed to intermediaries. For example, in the scheme -of Section 5.1, the number of ratchet steps per sender is exposed, and in -the scheme of Section 5.2, the number of epochs and the MLS sender ID of the SFrame -sender are exposed.

-
-
-
-
-

-9.3. Anti-Replay -

-

It is the responsibility of the application to handle anti-replay. Replay by network -attackers is assumed to be prevented by network-layer facilities (e.g., TLS, SRTP). -As mentioned in Section 7.4, senders MUST reject requests to encrypt multiple times -with the same key and nonce.

-

It is not mandatory to implement anti-replay on the receiver side. Receivers MAY -apply time or counter based anti-replay mitigations. For example, Section 3.3.2 of [RFC3711] specifies a counter-based anti-replay mitigation, which -could be adapted to use with SFrame, using the CTR field as the counter.

-
-
-
-
-

-9.4. Metadata -

-

The metadata input to SFrame operations is pure application-specified data. As -such, it is up to the application to define what information should go in the -metadata input and ensure that it is provided to the encryption and decryption -functions at the appropriate points. A receiver MUST NOT use SFrame-authenticated -metadata until after the SFrame decrypt function has authenticated it, unless -the purpose of such usage is to prepare an SFrame ciphertext for SFrame -decryption. Essentially, metadata may be used "upstream of SFrame" in a -processing pipeline, but only to prepare for SFrame decryption.

-

For example, consider an application where SFrame is used to encrypt audio -frames that are sent over SRTP, with some application data included in the RTP -header extension. Suppose the application also includes this application data in -the SFrame metadata, so that the SFU is allowed to read, but not modify the -application data. A receiver can use the application data in the RTP header -extension as part of the standard SRTP decryption process, since this is -required to recover the SFrame ciphertext carried in the SRTP payload. However, -the receiver MUST NOT use the application data for other purposes before SFrame -decryption has authenticated the application data.

-
-
-
-
-
-

-10. References -

-
-
-

-10.1. Normative References -

-
-
[MLS-PROTO]
-
-Barnes, R., Beurdouche, B., Robert, R., Millican, J., Omara, E., and K. Cohn-Gordon, "The Messaging Layer Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, , <https://www.rfc-editor.org/rfc/rfc9420>.
-
-
[RFC2119]
-
-Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
-
-
[RFC5116]
-
-McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, , <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, , <https://www.rfc-editor.org/rfc/rfc5869>.
-
-
[RFC8126]
-
-Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/rfc/rfc8126>.
-
-
[RFC8174]
-
-Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
-
-
-
-
-
-
-

-10.2. Informative References -

-
-
[I-D.codec-agnostic-rtp-payload-format]
-
-Murillo, S. G. and A. Gouaillard, "Codec agnostic RTP payload format for video", Work in Progress, Internet-Draft, draft-codec-agnostic-rtp-payload-format-00, , <https://datatracker.ietf.org/doc/html/draft-codec-agnostic-rtp-payload-format-00>.
-
-
[I-D.ietf-moq-transport]
-
-Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and I. Swett, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-02, , <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-02>.
-
-
[I-D.ietf-webtrans-overview]
-
-Vasiliev, V., "The WebTransport Protocol Framework", Work in Progress, Internet-Draft, draft-ietf-webtrans-overview-06, , <https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-overview-06>.
-
-
[MLS-ARCH]
-
-Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., and A. Duric, "The Messaging Layer Security (MLS) Architecture", Work in Progress, Internet-Draft, draft-ietf-mls-architecture-11, , <https://datatracker.ietf.org/doc/html/draft-ietf-mls-architecture-11>.
-
-
[RFC3711]
-
-Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, , <https://www.rfc-editor.org/rfc/rfc3711>.
-
-
[RFC4566]
-
-Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, , <https://www.rfc-editor.org/rfc/rfc4566>.
-
-
[RFC6716]
-
-Valin, JM., Vos, K., and T. Terriberry, "Definition of the Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, , <https://www.rfc-editor.org/rfc/rfc6716>.
-
-
[RFC7656]
-
-Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, , <https://www.rfc-editor.org/rfc/rfc7656>.
-
-
[RFC7667]
-
-Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, , <https://www.rfc-editor.org/rfc/rfc7667>.
-
-
[RFC8723]
-
-Jennings, C., Jones, P., Barnes, R., and A.B. Roach, "Double Encryption Procedures for the Secure Real-Time Transport Protocol (SRTP)", RFC 8723, DOI 10.17487/RFC8723, , <https://www.rfc-editor.org/rfc/rfc8723>.
-
-
[TestVectors]
-
-"SFrame Test Vectors", , <https://github.com/eomara/sframe/blob/master/test-vectors.json>.
-
-
-
-
-
-
-
-

-Appendix A. Acknowledgements -

-

The authors wish to specially thank Dr. Alex Gouaillard as one of the early -contributors to the document. His passion and energy were key to the design and -development of SFrame.

-
-
-
-
-

-Appendix B. Example API -

-

This section is not normative.

-

This section describes a notional API that an SFrame implementation might -expose. The core concept is an "SFrame context", within which KID values are -meaningful. In the key management scheme described in Section 5.1, each -sender has a different context; in the scheme described in Section 5.2, all senders -share the same context.

-

An SFrame context stores mappings from KID values to "key contexts", which are -different depending on whether the KID is to be used for sending or receiving -(an SFrame key should never be used for both operations). A key context tracks -the key and salt associated to the KID, and the current CTR value. A key -context to be used for sending also tracks the next CTR value to be used.

-

The primary operations on an SFrame context are as follows:

-
    -
  • -

    Create an SFrame context: The context is initialized with a ciphersuite and -no KID mappings.

    -
    • -
  • -

    Adding a key for sending: The key and salt are derived from the base key, and -used to initialize a send context, together with a zero counter value.

    -
    • -
  • -

    Adding a key for receiving: The key and salt are derived from the base key, and -used to initialize a send context.

    -
    • -
  • -

    Encrypt a plaintext: Encrypt a given plaintext using the key for a given KID, -including the specified metadata.

    -
    • -
  • -

    Decrypt an SFrame ciphertext: Decrypt an SFrame ciphertext with the KID -and CTR values specified in the SFrame Header, and the provided metadata.

    -
    • -
-

Figure 9 shows an example of the types of structures and methods that could -be used to create an SFrame API in Rust.

-
-
-
-
-type KeyId = u64;
-type Counter = u64;
-type CipherSuite = u16;
-
-struct SendKeyContext {
-  key: Vec<u8>,
-  salt: Vec<u8>,
-  next_counter: Counter,
-}
-
-struct RecvKeyContext {
-  key: Vec<u8>,
-  salt: Vec<u8>,
-}
-
-struct SFrameContext {
-  cipher_suite: CipherSuite,
-  send_keys: HashMap<KeyId, SendKeyContext>,
-  recv_keys: HashMap<KeyId, RecvKeyContext>,
-}
-
-trait SFrameContextMethods {
-  fn create(cipher_suite: CipherSuite) -> Self;
-  fn add_send_key(&self, kid: KeyId, base_key: &[u8]);
-  fn add_recv_key(&self, kid: KeyId, base_key: &[u8]);
-  fn encrypt(&mut self, kid: KeyId, metadata: &[u8],
-             plaintext: &[u8]) -> Vec<u8>;
-  fn decrypt(&self, metadata: &[u8], ciphertext: &[u8]) -> Vec<u8>;
-}
-
-
-
Figure 9: -An Example SFrame API -
-
-
-
-
-
-

-Appendix C. Overhead Analysis -

-

Any use of SFrame will impose overhead in terms of the amount of bandwidth -necessary to transmit a given media stream. Exactly how much overhead will be added -depends on several factors:

-
    -
  • -

    How many senders are involved in a conference (length of KID)

    -
    • -
  • -

    How long the conference has been going on (length of CTR)

    -
    • -
  • -

    The cipher suite in use (length of authentication tag)

    -
    • -
  • -

    Whether SFrame is used to encrypt packets, whole frames, or some other unit

    -
    • -
-

Overall, the overhead rate in kilobits per second can be estimated as:

-

-OverheadKbps = (1 + |CTR| + |KID| + |TAG|) * 8 * CTPerSecond / 1024 -

-

Here the constant value 1 reflects the fixed SFrame header; |CTR| and -|KID| reflect the lengths of those fields; |TAG| reflects the cipher -overhead; and CTPerSecond reflects the number of SFrame ciphertexts -sent per second (e.g., packets or frames per second).

-

In the remainder of this secton, we compute overhead estimates for a collection -of common scenarios.

-
-
-

-C.1. Assumptions -

-

In the below calculations, we make conservative assumptions about SFrame -overhead, so that the overhead amounts we compute here are likely to be an upper -bound on those seen in practice.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Table 3
FieldBytesExplanation
Fixed header1Fixed
Key ID (KID)2>255 senders; or MLS epoch (E=4) and >16 senders
Counter (CTR)3More than 24 hours of media in common cases
Cipher overhead16Full GCM tag (longest defined here)
-

In total, then, we assume that each SFrame encryption will add 22 bytes of -overhead.

-

We consider two scenarios, applying SFrame per-frame and per-packet. In each -scenario, we compute the SFrame overhead in absolute terms (Kbps) and as a -percentage of the base bandwidth.

-
-
-
-
-

-C.2. Audio -

-

In audio streams, there is typically a one-to-one relationship between frames -and packets, so the overhead is the same whether one uses SFrame at a per-packet -or per-frame level.

-

The below table considers three scenarios, based on recommended configurations -of the Opus codec [RFC6716]:

-
    -
  • -

    Narrow-band speech: 120ms packets, 8Kbps

    -
    • -
  • -

    Full-band speech: 20ms packets, 32Kbps

    -
    • -
  • -

    Full-band stereo music: 10ms packets, 128Kbps

    -
    • -
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 4: -SFrame overhead for audio streams -
ScenariofpsBase KbpsOverhead KbpsOverhead %
NB speech, 120ms packets8.381.417.9%
FB speech, 20ms packets50328.626.9%
FB stereo, 10ms packets10012817.213.4%
-
-
-
-
-
-

-C.3. Video -

-

Video frames can be larger than an MTU and thus are commonly split across -multiple frames. Table 5 and Table 6 -show the estimated overhead of encrypting a video stream, where SFrame is -applied per-frame and per-packet, respectively. The choices of resolution, -frames per second, and bandwidth are chosen to roughly reflect the capabilities of -modern video codecs across a range from very low to very high quality.

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 5: -SFrame overhead for a video stream encrypted per-frame -
ScenariofpsBase KbpsOverhead KbpsOverhead %
426 x 2407.5451.32.9%
640 x 360152002.61.3%
640 x 360304005.21.3%
1280 x 7203015005.20.3%
1920 x 108060720010.30.1%
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 6: -SFrame overhead for a video stream encrypted per-packet -
ScenariofpsppsBase KbpsOverhead KbpsOverhead %
426 x 2407.57.5451.32.9%
640 x 36015302005.22.6%
640 x 360306040010.32.6%
1280 x 72030180150030.92.1%
1920 x 1080607807200134.11.9%
-
-

In the per-frame case, the SFrame percentage overhead approaches zero as the -quality of the video goes up, since bandwidth is driven more by picture size -than frame rate. In the per-packet case, the SFrame percentage overhead -approaches the ratio between the SFrame overhead per packet and the MTU (here 22 -bytes of SFrame overhead divided by an assumed 1200-byte MTU, or about 1.8%).

-
-
-
-
-

-C.4. Conferences -

-

Real conferences usually involve several audio and video streams. The overhead -of SFrame in such a conference is the aggregate of the overhead over all the -individual streams. Thus, while SFrame incurs a large percentage overhead on an -audio stream, if the conference also involves a video stream, then the audio -overhead is likely negligible relative to the overall bandwidth of the -conference.

-

For example, Table 7 shows the overhead estimates for a two -person conference where one person is sending low-quality media and the other -sending high-quality. (And we assume that SFrame is applied per-frame.) The -video streams dominate the bandwidth at the SFU, so the total bandwidth overhead -is only around 1%.

-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Table 7: -SFrame overhead for a two-person conference -
StreamBase KbpsOverhead KbpsOverhead %
Participant 1 audio81.417.9%
Participant 1 video451.32.9%
Participant 2 audio32926.9%
Participant 2 video150050.3%
Total at SFU158516.51.0%
-
-
-
-
-
-

-C.5. SFrame over RTP -

-

SFrame is a generic encapsulation format, but many of the applications in which -it is likely to be integrated are based on RTP. This section discusses how an -integration between SFrame and RTP could be done, and some of the challenges -that would need to be overcome.

-

As discussed in Section 4.1, there are two natural patterns for -integrating SFrame into an application: applying SFrame per-frame or per-packet. -In RTP-based applications, applying SFrame per-packet means that the payload of -each RTP packet will be an SFrame ciphertext, starting with an SFrame Header, as -shown in Figure 10. Applying SFrame per-frame means that different -RTP payloads will have different formats: The first payload of a frame will -contain the SFrame headers, and subsequent payloads will contain further chunks -of the ciphertext, as shown in Figure 11.

-

In order for these media payloads to be properly interpreted by receivers, -receivers will need to be configured to know which of the above schemes the -sender has applied to a given sequence of RTP packets. SFrame does not provide -a mechanism for distributing this configuration information. In applications -that use SDP for negotiating RTP media streams [RFC4566], an appropriate -extension to SDP could provide this function.

-

Applying SFrame per-frame also requires that packetization and depacketization -be done in a generic manner that does not depend on the media content of the -packets, since the content being packetized / depacketized will be opaque -ciphertext (except for the SFrame header). In order for such a generic -packetization scheme to work interoperably one would have to be defined, e.g., -as proposed in [I-D.codec-agnostic-rtp-payload-format].

-
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - V=2 - P - X - CC - M - PT - sequence - number - timestamp - synchronization - source - (SSRC) - identifier - contributing - source - (CSRC) - identifiers - .... - RTP - extension(s) - (OPTIONAL) - SFrame - header - SFrame - encrypted - and - authenticated - payload - SRTP - authentication - tag - SRTP - Encrypted - Portion - SRTP - Authenticated - Portion - - -
-
-
Figure 10: -SRTP packet with SFrame-protected payload -
-
-
-
-
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - frame - metadata - frame - SFrame - Encrypt - encrypted - frame - generic - RTP - packetize - ... - SFrame - header - payload - 2/N - ... - payload - N/N - payload - 1/N - - -
-
-
Figure 11: -Encryption flow with per-frame encryption for RTP -
-
-
-
-
-
-
-
-

-Appendix D. Test Vectors -

-

This section provides a set of test vectors that implementations can use to -verify that they correctly implement SFrame encryption and decryption. In -addition to test vectors for the overall process of SFrame -encryption/decryption, we also provide test vectors for header -encoding/decoding, and for AEAD encryption/decryption using the AES-CTR -construction defined in Section 4.5.1.

-

All values are either numeric or byte strings. Numeric values are represented -as hex values, prefixed with 0x. Byte strings are represented in hex -encoding.

-

Line breaks and whitespace within values are inserted to conform to the width -requirements of the RFC format. They should be removed before use.

-

These test vectors are also available in JSON format at [TestVectors]. In the -JSON test vectors, numeric values are JSON numbers and byte string values are -JSON strings containing the hex encoding of the byte strings.

-
-
-

-D.1. Header encoding/decoding -

-

For each case, we provide:

-
    -
  • -

    kid: A KID value

    -
    • -
  • -

    ctr: A CTR value

    -
    • -
  • -

    header: An encoded SFrame header

    -
    • -
-

An implementation should verify that:

-
    -
  • -

    Encoding a header with the KID and CTR results in the provided header value

    -
    • -
  • -

    Decoding the provided header value results in the provided KID and CTR values

    -
    • -
-
-
-kid: 0x0000000000000000
-ctr: 0x0000000000000000
-header: 00
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0000000000000001
-header: 01
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x00000000000000ff
-header: 08ff
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0000000000000100
-header: 090100
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x000000000000ffff
-header: 09ffff
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0000000000010000
-header: 0a010000
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0000000000ffffff
-header: 0affffff
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0000000001000000
-header: 0b01000000
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x00000000ffffffff
-header: 0bffffffff
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0000000100000000
-header: 0c0100000000
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x000000ffffffffff
-header: 0cffffffffff
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0000010000000000
-header: 0d010000000000
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0000ffffffffffff
-header: 0dffffffffffff
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0001000000000000
-header: 0e01000000000000
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x00ffffffffffffff
-header: 0effffffffffffff
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0x0100000000000000
-header: 0f0100000000000000
-
-
-
-
-kid: 0x0000000000000000
-ctr: 0xffffffffffffffff
-header: 0fffffffffffffffff
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000000000000000
-header: 10
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000000000000001
-header: 11
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x00000000000000ff
-header: 18ff
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000000000000100
-header: 190100
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x000000000000ffff
-header: 19ffff
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000000000010000
-header: 1a010000
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000000000ffffff
-header: 1affffff
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000000001000000
-header: 1b01000000
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x00000000ffffffff
-header: 1bffffffff
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000000100000000
-header: 1c0100000000
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x000000ffffffffff
-header: 1cffffffffff
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000010000000000
-header: 1d010000000000
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0000ffffffffffff
-header: 1dffffffffffff
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0001000000000000
-header: 1e01000000000000
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x00ffffffffffffff
-header: 1effffffffffffff
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0x0100000000000000
-header: 1f0100000000000000
-
-
-
-
-kid: 0x0000000000000001
-ctr: 0xffffffffffffffff
-header: 1fffffffffffffffff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000000000000000
-header: 80ff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000000000000001
-header: 81ff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x00000000000000ff
-header: 88ffff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000000000000100
-header: 89ff0100
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x000000000000ffff
-header: 89ffffff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000000000010000
-header: 8aff010000
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000000000ffffff
-header: 8affffffff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000000001000000
-header: 8bff01000000
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x00000000ffffffff
-header: 8bffffffffff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000000100000000
-header: 8cff0100000000
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x000000ffffffffff
-header: 8cffffffffffff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000010000000000
-header: 8dff010000000000
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0000ffffffffffff
-header: 8dffffffffffffff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0001000000000000
-header: 8eff01000000000000
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x00ffffffffffffff
-header: 8effffffffffffffff
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0x0100000000000000
-header: 8fff0100000000000000
-
-
-
-
-kid: 0x00000000000000ff
-ctr: 0xffffffffffffffff
-header: 8fffffffffffffffffff
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000000000000000
-header: 900100
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000000000000001
-header: 910100
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x00000000000000ff
-header: 980100ff
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000000000000100
-header: 9901000100
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x000000000000ffff
-header: 990100ffff
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000000000010000
-header: 9a0100010000
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000000000ffffff
-header: 9a0100ffffff
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000000001000000
-header: 9b010001000000
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x00000000ffffffff
-header: 9b0100ffffffff
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000000100000000
-header: 9c01000100000000
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x000000ffffffffff
-header: 9c0100ffffffffff
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000010000000000
-header: 9d0100010000000000
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0000ffffffffffff
-header: 9d0100ffffffffffff
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0001000000000000
-header: 9e010001000000000000
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x00ffffffffffffff
-header: 9e0100ffffffffffffff
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0x0100000000000000
-header: 9f01000100000000000000
-
-
-
-
-kid: 0x0000000000000100
-ctr: 0xffffffffffffffff
-header: 9f0100ffffffffffffffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000000000000000
-header: 90ffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000000000000001
-header: 91ffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x00000000000000ff
-header: 98ffffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000000000000100
-header: 99ffff0100
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x000000000000ffff
-header: 99ffffffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000000000010000
-header: 9affff010000
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000000000ffffff
-header: 9affffffffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000000001000000
-header: 9bffff01000000
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x00000000ffffffff
-header: 9bffffffffffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000000100000000
-header: 9cffff0100000000
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x000000ffffffffff
-header: 9cffffffffffffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000010000000000
-header: 9dffff010000000000
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0000ffffffffffff
-header: 9dffffffffffffffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0001000000000000
-header: 9effff01000000000000
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x00ffffffffffffff
-header: 9effffffffffffffffff
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0x0100000000000000
-header: 9fffff0100000000000000
-
-
-
-
-kid: 0x000000000000ffff
-ctr: 0xffffffffffffffff
-header: 9fffffffffffffffffffff
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000000000000000
-header: a0010000
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000000000000001
-header: a1010000
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x00000000000000ff
-header: a8010000ff
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000000000000100
-header: a90100000100
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x000000000000ffff
-header: a9010000ffff
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000000000010000
-header: aa010000010000
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000000000ffffff
-header: aa010000ffffff
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000000001000000
-header: ab01000001000000
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x00000000ffffffff
-header: ab010000ffffffff
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000000100000000
-header: ac0100000100000000
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x000000ffffffffff
-header: ac010000ffffffffff
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000010000000000
-header: ad010000010000000000
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0000ffffffffffff
-header: ad010000ffffffffffff
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0001000000000000
-header: ae01000001000000000000
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x00ffffffffffffff
-header: ae010000ffffffffffffff
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0x0100000000000000
-header: af0100000100000000000000
-
-
-
-
-kid: 0x0000000000010000
-ctr: 0xffffffffffffffff
-header: af010000ffffffffffffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000000000000000
-header: a0ffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000000000000001
-header: a1ffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x00000000000000ff
-header: a8ffffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000000000000100
-header: a9ffffff0100
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x000000000000ffff
-header: a9ffffffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000000000010000
-header: aaffffff010000
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000000000ffffff
-header: aaffffffffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000000001000000
-header: abffffff01000000
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x00000000ffffffff
-header: abffffffffffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000000100000000
-header: acffffff0100000000
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x000000ffffffffff
-header: acffffffffffffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000010000000000
-header: adffffff010000000000
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0000ffffffffffff
-header: adffffffffffffffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0001000000000000
-header: aeffffff01000000000000
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x00ffffffffffffff
-header: aeffffffffffffffffffff
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0x0100000000000000
-header: afffffff0100000000000000
-
-
-
-
-kid: 0x0000000000ffffff
-ctr: 0xffffffffffffffff
-header: afffffffffffffffffffffff
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000000000000000
-header: b001000000
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000000000000001
-header: b101000000
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x00000000000000ff
-header: b801000000ff
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000000000000100
-header: b9010000000100
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x000000000000ffff
-header: b901000000ffff
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000000000010000
-header: ba01000000010000
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000000000ffffff
-header: ba01000000ffffff
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000000001000000
-header: bb0100000001000000
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x00000000ffffffff
-header: bb01000000ffffffff
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000000100000000
-header: bc010000000100000000
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x000000ffffffffff
-header: bc01000000ffffffffff
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000010000000000
-header: bd01000000010000000000
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0000ffffffffffff
-header: bd01000000ffffffffffff
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0001000000000000
-header: be0100000001000000000000
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x00ffffffffffffff
-header: be01000000ffffffffffffff
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0x0100000000000000
-header: bf010000000100000000000000
-
-
-
-
-kid: 0x0000000001000000
-ctr: 0xffffffffffffffff
-header: bf01000000ffffffffffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000000000000000
-header: b0ffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000000000000001
-header: b1ffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x00000000000000ff
-header: b8ffffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000000000000100
-header: b9ffffffff0100
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x000000000000ffff
-header: b9ffffffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000000000010000
-header: baffffffff010000
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000000000ffffff
-header: baffffffffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000000001000000
-header: bbffffffff01000000
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x00000000ffffffff
-header: bbffffffffffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000000100000000
-header: bcffffffff0100000000
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x000000ffffffffff
-header: bcffffffffffffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000010000000000
-header: bdffffffff010000000000
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0000ffffffffffff
-header: bdffffffffffffffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0001000000000000
-header: beffffffff01000000000000
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x00ffffffffffffff
-header: beffffffffffffffffffffff
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0x0100000000000000
-header: bfffffffff0100000000000000
-
-
-
-
-kid: 0x00000000ffffffff
-ctr: 0xffffffffffffffff
-header: bfffffffffffffffffffffffff
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000000000000000
-header: c00100000000
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000000000000001
-header: c10100000000
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x00000000000000ff
-header: c80100000000ff
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000000000000100
-header: c901000000000100
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x000000000000ffff
-header: c90100000000ffff
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000000000010000
-header: ca0100000000010000
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000000000ffffff
-header: ca0100000000ffffff
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000000001000000
-header: cb010000000001000000
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x00000000ffffffff
-header: cb0100000000ffffffff
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000000100000000
-header: cc01000000000100000000
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x000000ffffffffff
-header: cc0100000000ffffffffff
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000010000000000
-header: cd0100000000010000000000
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0000ffffffffffff
-header: cd0100000000ffffffffffff
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0001000000000000
-header: ce010000000001000000000000
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x00ffffffffffffff
-header: ce0100000000ffffffffffffff
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0x0100000000000000
-header: cf01000000000100000000000000
-
-
-
-
-kid: 0x0000000100000000
-ctr: 0xffffffffffffffff
-header: cf0100000000ffffffffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000000000000000
-header: c0ffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000000000000001
-header: c1ffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x00000000000000ff
-header: c8ffffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000000000000100
-header: c9ffffffffff0100
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x000000000000ffff
-header: c9ffffffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000000000010000
-header: caffffffffff010000
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000000000ffffff
-header: caffffffffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000000001000000
-header: cbffffffffff01000000
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x00000000ffffffff
-header: cbffffffffffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000000100000000
-header: ccffffffffff0100000000
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x000000ffffffffff
-header: ccffffffffffffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000010000000000
-header: cdffffffffff010000000000
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0000ffffffffffff
-header: cdffffffffffffffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0001000000000000
-header: ceffffffffff01000000000000
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x00ffffffffffffff
-header: ceffffffffffffffffffffffff
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0x0100000000000000
-header: cfffffffffff0100000000000000
-
-
-
-
-kid: 0x000000ffffffffff
-ctr: 0xffffffffffffffff
-header: cfffffffffffffffffffffffffff
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000000000000000
-header: d0010000000000
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000000000000001
-header: d1010000000000
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x00000000000000ff
-header: d8010000000000ff
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000000000000100
-header: d90100000000000100
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x000000000000ffff
-header: d9010000000000ffff
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000000000010000
-header: da010000000000010000
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000000000ffffff
-header: da010000000000ffffff
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000000001000000
-header: db01000000000001000000
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x00000000ffffffff
-header: db010000000000ffffffff
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000000100000000
-header: dc0100000000000100000000
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x000000ffffffffff
-header: dc010000000000ffffffffff
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000010000000000
-header: dd010000000000010000000000
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0000ffffffffffff
-header: dd010000000000ffffffffffff
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0001000000000000
-header: de01000000000001000000000000
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x00ffffffffffffff
-header: de010000000000ffffffffffffff
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0x0100000000000000
-header: df0100000000000100000000000000
-
-
-
-
-kid: 0x0000010000000000
-ctr: 0xffffffffffffffff
-header: df010000000000ffffffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000000000000000
-header: d0ffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000000000000001
-header: d1ffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x00000000000000ff
-header: d8ffffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000000000000100
-header: d9ffffffffffff0100
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x000000000000ffff
-header: d9ffffffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000000000010000
-header: daffffffffffff010000
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000000000ffffff
-header: daffffffffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000000001000000
-header: dbffffffffffff01000000
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x00000000ffffffff
-header: dbffffffffffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000000100000000
-header: dcffffffffffff0100000000
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x000000ffffffffff
-header: dcffffffffffffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000010000000000
-header: ddffffffffffff010000000000
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0000ffffffffffff
-header: ddffffffffffffffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0001000000000000
-header: deffffffffffff01000000000000
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x00ffffffffffffff
-header: deffffffffffffffffffffffffff
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0x0100000000000000
-header: dfffffffffffff0100000000000000
-
-
-
-
-kid: 0x0000ffffffffffff
-ctr: 0xffffffffffffffff
-header: dfffffffffffffffffffffffffffff
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000000000000000
-header: e001000000000000
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000000000000001
-header: e101000000000000
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x00000000000000ff
-header: e801000000000000ff
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000000000000100
-header: e9010000000000000100
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x000000000000ffff
-header: e901000000000000ffff
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000000000010000
-header: ea01000000000000010000
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000000000ffffff
-header: ea01000000000000ffffff
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000000001000000
-header: eb0100000000000001000000
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x00000000ffffffff
-header: eb01000000000000ffffffff
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000000100000000
-header: ec010000000000000100000000
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x000000ffffffffff
-header: ec01000000000000ffffffffff
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000010000000000
-header: ed01000000000000010000000000
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0000ffffffffffff
-header: ed01000000000000ffffffffffff
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0001000000000000
-header: ee0100000000000001000000000000
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x00ffffffffffffff
-header: ee01000000000000ffffffffffffff
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0x0100000000000000
-header: ef010000000000000100000000000000
-
-
-
-
-kid: 0x0001000000000000
-ctr: 0xffffffffffffffff
-header: ef01000000000000ffffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000000000000000
-header: e0ffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000000000000001
-header: e1ffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x00000000000000ff
-header: e8ffffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000000000000100
-header: e9ffffffffffffff0100
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x000000000000ffff
-header: e9ffffffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000000000010000
-header: eaffffffffffffff010000
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000000000ffffff
-header: eaffffffffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000000001000000
-header: ebffffffffffffff01000000
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x00000000ffffffff
-header: ebffffffffffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000000100000000
-header: ecffffffffffffff0100000000
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x000000ffffffffff
-header: ecffffffffffffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000010000000000
-header: edffffffffffffff010000000000
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0000ffffffffffff
-header: edffffffffffffffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0001000000000000
-header: eeffffffffffffff01000000000000
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x00ffffffffffffff
-header: eeffffffffffffffffffffffffffff
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0x0100000000000000
-header: efffffffffffffff0100000000000000
-
-
-
-
-kid: 0x00ffffffffffffff
-ctr: 0xffffffffffffffff
-header: efffffffffffffffffffffffffffffff
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000000000000000
-header: f00100000000000000
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000000000000001
-header: f10100000000000000
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x00000000000000ff
-header: f80100000000000000ff
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000000000000100
-header: f901000000000000000100
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x000000000000ffff
-header: f90100000000000000ffff
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000000000010000
-header: fa0100000000000000010000
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000000000ffffff
-header: fa0100000000000000ffffff
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000000001000000
-header: fb010000000000000001000000
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x00000000ffffffff
-header: fb0100000000000000ffffffff
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000000100000000
-header: fc01000000000000000100000000
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x000000ffffffffff
-header: fc0100000000000000ffffffffff
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000010000000000
-header: fd0100000000000000010000000000
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0000ffffffffffff
-header: fd0100000000000000ffffffffffff
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0001000000000000
-header: fe010000000000000001000000000000
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x00ffffffffffffff
-header: fe0100000000000000ffffffffffffff
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0x0100000000000000
-header: ff010000000000000001000000000000
-        00
-
-
-
-
-kid: 0x0100000000000000
-ctr: 0xffffffffffffffff
-header: ff0100000000000000ffffffffffffff
-        ff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000000000000000
-header: f0ffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000000000000001
-header: f1ffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x00000000000000ff
-header: f8ffffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000000000000100
-header: f9ffffffffffffffff0100
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x000000000000ffff
-header: f9ffffffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000000000010000
-header: faffffffffffffffff010000
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000000000ffffff
-header: faffffffffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000000001000000
-header: fbffffffffffffffff01000000
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x00000000ffffffff
-header: fbffffffffffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000000100000000
-header: fcffffffffffffffff0100000000
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x000000ffffffffff
-header: fcffffffffffffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000010000000000
-header: fdffffffffffffffff010000000000
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0000ffffffffffff
-header: fdffffffffffffffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0001000000000000
-header: feffffffffffffffff01000000000000
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x00ffffffffffffff
-header: feffffffffffffffffffffffffffffff
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0x0100000000000000
-header: ffffffffffffffffff01000000000000
-        00
-
-
-
-
-kid: 0xffffffffffffffff
-ctr: 0xffffffffffffffff
-header: ffffffffffffffffffffffffffffffff
-        ff
-
-
-
-
-
-
-

-D.2. AEAD encryption/decryption using AES-CTR and HMAC -

-

For each case, we provide:

-
    -
  • -

    cipher_suite: The index of the cipher suite in use (see -Section 8.1)

    -
    • -
  • -

    key: The key input to encryption/decryption

    -
    • -
  • -

    enc_key: The encryption subkey produced by the derive_subkeys() algorithm

    -
    • -
  • -

    auth_key: The encryption subkey produced by the derive_subkeys() algorithm

    -
    • -
  • -

    nonce: The nonce input to encryption/decryption

    -
    • -
  • -

    aad: The aad input to encryption/decryption

    -
    • -
  • -

    pt: The plaintext

    -
    • -
  • -

    ct: The ciphertext

    -
    • -
-

An implementation should verify that the following are true, where -AEAD.Encrypt and AEAD.Decrypt are as defined in Section 4.5.1:

-
    -
  • -

    AEAD.Encrypt(key, nonce, aad, pt) == ct

    -
    • -
  • -

    AEAD.Decrypt(key, nonce, aad, ct) == pt

    -
    • -
-

The other values in the test vector are intermediate values provided to -facilitate debugging of test failures.

-
-
-cipher_suite: 0x0001
-key: 000102030405060708090a0b0c0d0e0f
-     101112131415161718191a1b1c1d1e1f
-     202122232425262728292a2b2c2d2e2f
-enc_key: 000102030405060708090a0b0c0d0e0f
-auth_key: 101112131415161718191a1b1c1d1e1f
-          202122232425262728292a2b2c2d2e2f
-nonce: 101112131415161718191a1b
-aad: 4945544620534672616d65205747
-pt: 64726166742d696574662d736672616d
-    652d656e63
-ct: 6339af04ada1d064688a442b8dc69d5b
-    6bfa40f4bef0583e8081069cc60705
-
-
-
-
-cipher_suite: 0x0002
-key: 000102030405060708090a0b0c0d0e0f
-     101112131415161718191a1b1c1d1e1f
-     202122232425262728292a2b2c2d2e2f
-enc_key: 000102030405060708090a0b0c0d0e0f
-auth_key: 101112131415161718191a1b1c1d1e1f
-          202122232425262728292a2b2c2d2e2f
-nonce: 101112131415161718191a1b
-aad: 4945544620534672616d65205747
-pt: 64726166742d696574662d736672616d
-    652d656e63
-ct: 6339af04ada1d064688a442b8dc69d5b
-    6bfa40f4be6e93b7da076927bb
-
-
-
-
-cipher_suite: 0x0003
-key: 000102030405060708090a0b0c0d0e0f
-     101112131415161718191a1b1c1d1e1f
-     202122232425262728292a2b2c2d2e2f
-enc_key: 000102030405060708090a0b0c0d0e0f
-auth_key: 101112131415161718191a1b1c1d1e1f
-          202122232425262728292a2b2c2d2e2f
-nonce: 101112131415161718191a1b
-aad: 4945544620534672616d65205747
-pt: 64726166742d696574662d736672616d
-    652d656e63
-ct: 6339af04ada1d064688a442b8dc69d5b
-    6bfa40f4be09480509
-
-
-
-
-
-
-

-D.3. SFrame encryption/decryption -

-

For each case, we provide:

-
    -
  • -

    cipher_suite: The index of the cipher suite in use (see -Section 8.1)

    -
    • -
  • -

    kid: A KID value

    -
    • -
  • -

    ctr: A CTR value

    -
    • -
  • -

    base_key: The base_key input to the derive_key_salt algorithm

    -
    • -
  • -

    sframe_key_label: The label used to derive sframe_key in the derive_key_salt algorithm

    -
    • -
  • -

    sframe_salt_label: The label used to derive sframe_salt in the derive_key_salt algorithm

    -
    • -
  • -

    sframe_secret: The sframe_secret variable in the derive_key_salt algorithm

    -
    • -
  • -

    sframe_key: The sframe_key value produced by the derive_key_salt algorithm

    -
    • -
  • -

    sframe_salt: The sframe_salt value produced by the derive_key_salt algorithm

    -
    • -
  • -

    metadata: The metadata input to the SFrame encrypt algorithm

    -
    • -
  • -

    pt: The plaintext

    -
    • -
  • -

    ct: The SFrame ciphertext

    -
    • -
-

An implementation should verify that the following are true, where -encrypt and decrypt are as defined in Section 4.4, using an SFrame -context initialized with base_key assigned to kid:

-
    -
  • -

    encrypt(ctr, kid, metadata, plaintext) == ct

    -
    • -
  • -

    decrypt(metadata, ct) == pt

    -
    • -
-

The other values in the test vector are intermediate values provided to -facilitate debugging of test failures.

-
-
-cipher_suite: 0x0001
-kid: 0x0000000000000123
-ctr: 0x0000000000004567
-base_key: 000102030405060708090a0b0c0d0e0f
-sframe_key_label: 534672616d6520312e30205365637265
-                  74206b65792000000000000001230001
-sframe_salt_label: 534672616d6520312e30205365637265
-                   742073616c7420000000000000012300
-                   01
-sframe_secret: d926952ca8b7ec4a95941d1ada3a5203
-               ceff8cceee34f574d23909eb314c40c0
-sframe_key: 3f7d9a7c83ae8e1c8a11ae695ab59314
-            b367e359fadac7b9c46b2bc6f81f46e1
-            6b96f0811868d59402b7e870102720b3
-sframe_salt: 50b29329a04dc0f184ac3168
-metadata: 4945544620534672616d65205747
-nonce: 50b29329a04dc0f184ac740f
-aad: 99012345674945544620534672616d65
-     205747
-pt: 64726166742d696574662d736672616d
-    652d656e63
-ct: 9901234567449408b6f490086165b9d6
-    f62b24ae1a59a56486b4ae8ed036b889
-    12e24f11
-
-
-
-
-cipher_suite: 0x0002
-kid: 0x0000000000000123
-ctr: 0x0000000000004567
-base_key: 000102030405060708090a0b0c0d0e0f
-sframe_key_label: 534672616d6520312e30205365637265
-                  74206b65792000000000000001230002
-sframe_salt_label: 534672616d6520312e30205365637265
-                   742073616c7420000000000000012300
-                   02
-sframe_secret: d926952ca8b7ec4a95941d1ada3a5203
-               ceff8cceee34f574d23909eb314c40c0
-sframe_key: e2ec5c797540310483b16bf6e7a570d2
-            a27d192fe869c7ccd8584a8d9dab9154
-            9fbe553f5113461ec6aa83bf3865553e
-sframe_salt: e68ac8dd3d02fbcd368c5577
-metadata: 4945544620534672616d65205747
-nonce: e68ac8dd3d02fbcd368c1010
-aad: 99012345674945544620534672616d65
-     205747
-pt: 64726166742d696574662d736672616d
-    652d656e63
-ct: 99012345673f31438db4d09434e43afa
-    0f8a2f00867a2be085046a9f5cb4f101
-    d607
-
-
-
-
-cipher_suite: 0x0003
-kid: 0x0000000000000123
-ctr: 0x0000000000004567
-base_key: 000102030405060708090a0b0c0d0e0f
-sframe_key_label: 534672616d6520312e30205365637265
-                  74206b65792000000000000001230003
-sframe_salt_label: 534672616d6520312e30205365637265
-                   742073616c7420000000000000012300
-                   03
-sframe_secret: d926952ca8b7ec4a95941d1ada3a5203
-               ceff8cceee34f574d23909eb314c40c0
-sframe_key: 2c5703089cbb8c583475e4fc461d97d1
-            8809df79b6d550f78eb6d50ffa80d892
-            11d57909934f46f5405e38cd583c69fe
-sframe_salt: 38c16e4f5159700c00c7f350
-metadata: 4945544620534672616d65205747
-nonce: 38c16e4f5159700c00c7b637
-aad: 99012345674945544620534672616d65
-     205747
-pt: 64726166742d696574662d736672616d
-    652d656e63
-ct: 990123456717fc8af28a5a695afcfc6c
-    8df6358a17e26b2fcb3bae32e443
-
-
-
-
-cipher_suite: 0x0004
-kid: 0x0000000000000123
-ctr: 0x0000000000004567
-base_key: 000102030405060708090a0b0c0d0e0f
-sframe_key_label: 534672616d6520312e30205365637265
-                  74206b65792000000000000001230004
-sframe_salt_label: 534672616d6520312e30205365637265
-                   742073616c7420000000000000012300
-                   04
-sframe_secret: d926952ca8b7ec4a95941d1ada3a5203
-               ceff8cceee34f574d23909eb314c40c0
-sframe_key: d34f547f4ca4f9a7447006fe7fcbf768
-sframe_salt: 75234edefe07819026751816
-metadata: 4945544620534672616d65205747
-nonce: 75234edefe07819026755d71
-aad: 99012345674945544620534672616d65
-     205747
-pt: 64726166742d696574662d736672616d
-    652d656e63
-ct: 9901234567b7412c2513a1b66dbb4884
-    1bbaf17f598751176ad847681a69c6d0
-    b091c07018ce4adb34eb
-
-
-
-
-cipher_suite: 0x0005
-kid: 0x0000000000000123
-ctr: 0x0000000000004567
-base_key: 000102030405060708090a0b0c0d0e0f
-sframe_key_label: 534672616d6520312e30205365637265
-                  74206b65792000000000000001230005
-sframe_salt_label: 534672616d6520312e30205365637265
-                   742073616c7420000000000000012300
-                   05
-sframe_secret: 0fc3ea6de6aac97a35f194cf9bed94d4
-               b5230f1cb45a785c9fe5dce9c188938a
-               b6ba005bc4c0a19181599e9d1bcf7b74
-               aca48b60bf5e254e546d809313e083a3
-sframe_key: d3e27b0d4a5ae9e55df01a70e6d4d28d
-            969b246e2936f4b7a5d9b494da6b9633
-sframe_salt: 84991c167b8cd23c93708ec7
-metadata: 4945544620534672616d65205747
-nonce: 84991c167b8cd23c9370cba0
-aad: 99012345674945544620534672616d65
-     205747
-pt: 64726166742d696574662d736672616d
-    652d656e63
-ct: 990123456794f509d36e9beacb0e261d
-    99c7d1e972f1fed787d4049f17ca2135
-    3c1cc24d56ceabced279
-
-
-
-
-
-
-
-
-

-Contributors -

-
-
Frederic Jacobs
-
Apple
- -
-
-
Marta Mularczyk
-
Amazon
- -
-
-
Suhas Nandakumar
-
Cisco
- -
-
-
Tomas Rigaux
-
Cisco
- -
-
-
Raphael Robert
-
Phoenix R&D
- -
-
-
-
-
-

-Authors' Addresses -

-
-
Emad Omara
-
Apple
- -
-
-
Justin Uberti
-
Google
- -
-
-
Sergio Garcia Murillo
-
CoSMo Software
- -
-
-
Richard L. Barnes (editor)
-
Cisco
- -
-
-
Youenn Fablet
-
Apple
- -
-
-
- - - diff --git a/draft-ietf-sframe-enc-07/index.html b/draft-ietf-sframe-enc-07/index.html deleted file mode 100644 index 26c0cfa..0000000 --- a/draft-ietf-sframe-enc-07/index.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - sframe-wg/sframe draft-ietf-sframe-enc-07 preview - - - - -

Editor's drafts for draft-ietf-sframe-enc-07 branch of sframe-wg/sframe

- - - - - - -
SFrameplain textsame as main
- - - diff --git a/index.html b/index.html index d67c7ee..3d7ec21 100644 --- a/index.html +++ b/index.html @@ -24,36 +24,12 @@

Editor's drafts for main branch of secdir

- +

Preview for branch warren

+
- - - - -
SFrameplain textsame as main
-

Preview for branch murray

- - - - - - -
SFrameplain textdiff with main
-

Preview for branch draft-ietf-sframe-enc-07

- - - - - - -
SFrameplain textsame as main
-

Preview for branch artart-iana

- - - - - + + +
SFrameplain textdiff with mainSFrameplain textdiff with main
- - diff --git a/murray/draft-ietf-sframe-enc.txt b/murray/draft-ietf-sframe-enc.txt deleted file mode 100644 index e0c9422..0000000 --- a/murray/draft-ietf-sframe-enc.txt +++ /dev/null @@ -1,3160 +0,0 @@ - - - - -Network Working Group E. Omara -Internet-Draft Apple -Intended status: Standards Track J. Uberti -Expires: 4 August 2024 Google - S. Murillo - CoSMo Software - R. L. Barnes, Ed. - Cisco - Y. Fablet - Apple - 1 February 2024 - - - Secure Frame (SFrame) - draft-ietf-sframe-enc-latest - -Abstract - - This document describes the Secure Frame (SFrame) end-to-end - encryption and authentication mechanism for media frames in a - multiparty conference call, in which central media servers (selective - forwarding units or SFUs) can access the media metadata needed to - make forwarding decisions without having access to the actual media. - - The proposed mechanism differs from the Secure Real-Time Protocol - (SRTP) in that it is independent of RTP (thus compatible with non-RTP - media transport) and can be applied to whole media frames in order to - be more bandwidth efficient. - -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://sframe- - wg.github.io/sframe/draft-ietf-sframe-enc.html. Status information - for this document may be found at https://datatracker.ietf.org/doc/ - draft-ietf-sframe-enc/. - - Discussion of this document takes place on the Secure Media Frames - Working Group mailing list (mailto:sframe@ietf.org), which is - archived at https://mailarchive.ietf.org/arch/browse/sframe/. - Subscribe at https://www.ietf.org/mailman/listinfo/sframe/. - - Source for this draft and an issue tracker can be found at - https://github.com/sframe-wg/sframe. - -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 4 August 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. Goals - 4. SFrame - 4.1. Application Context - 4.2. SFrame Ciphertext - 4.3. SFrame Header - 4.4. Encryption Schema - 4.4.1. Key Selection - 4.4.2. Key Derivation - 4.4.3. Encryption - 4.4.4. Decryption - 4.5. Cipher Suites - 4.5.1. AES-CTR with SHA2 - 5. Key Management - 5.1. Sender Keys - 5.2. MLS - 6. Media Considerations - 6.1. Selective Forwarding Units - 6.1.1. LastN and RTP stream reuse - 6.1.2. Simulcast - 6.1.3. SVC - 6.2. Video Key Frames - 6.3. Partial Decoding - 7. Security Considerations - 7.1. No Header Confidentiality - 7.2. No Per-Sender Authentication - 7.3. Key Management - 7.4. Replay - 7.5. Risks due to Short Tags - 8. IANA Considerations - 8.1. SFrame Cipher Suites - 9. Application Responsibilities - 9.1. Header Value Uniqueness - 9.2. Key Management Framework - 9.3. Anti-Replay - 9.4. Metadata - 10. References - 10.1. Normative References - 10.2. Informative References - Appendix A. Acknowledgements - Appendix B. Example API - Appendix C. Overhead Analysis - C.1. Assumptions - C.2. Audio - C.3. Video - C.4. Conferences - C.5. SFrame over RTP - Appendix D. Test Vectors - D.1. Header encoding/decoding - D.2. AEAD encryption/decryption using AES-CTR and HMAC - D.3. SFrame encryption/decryption - Contributors - Authors' Addresses - -1. Introduction - - Modern multi-party video call systems use Selective Forwarding Unit - (SFU) servers to efficiently route media streams to call endpoints - based on factors such as available bandwidth, desired video size, - codec support, and other factors. An SFU typically does not need - access to the media content of the conference, allowing for the media - to be "end-to-end" encrypted so that it cannot be decrypted by the - SFU. In order for the SFU to work properly, though, it usually needs - to be able to access RTP metadata and RTCP feedback messages, which - is not possible if all RTP/RTCP traffic is end-to-end encrypted. - - As such, two layers of encryption and authentication are required: - - 1. Hop-by-hop (HBH) encryption of media, metadata, and feedback - messages between the the endpoints and SFU - - 2. End-to-end (E2E) encryption (E2EE) of media between the endpoints - - The Secure Real-Time Protocol (SRTP) is already widely used for HBH - encryption [RFC3711]. The SRTP "double encryption" scheme defines a - way to do E2E encryption in SRTP [RFC8723]. Unfortunately, this - scheme has poor efficiency and high complexity, and its entanglement - with RTP makes it unworkable in several realistic SFU scenarios. - - This document proposes a new E2EE protection scheme known as SFrame, - specifically designed to work in group conference calls with SFUs. - SFrame is a general encryption framing that can be used to protect - media payloads, agnostic of transport. - -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. - - MAC: Message Authentication Code - - E2EE: End to End Encryption - - HBH: Hop By Hop - - We use "Selective Forwarding Unit (SFU)" and "media stream" in a less - formal sense than in [RFC7656]. An SFU is a selective switching - function for media payloads, and a media stream a sequence of media - payloads, in both cases regardless of whether those media payloads - are transported over RTP or some other protocol. - -3. Goals - - SFrame is designed to be a suitable E2EE protection scheme for - conference call media in a broad range of scenarios, as outlined by - the following goals: - - 1. Provide a secure E2EE mechanism for audio and video in conference - calls that can be used with arbitrary SFU servers. - - 2. Decouple media encryption from key management to allow SFrame to - be used with an arbitrary key management system. - - 3. Minimize packet expansion to allow successful conferencing in as - many network conditions as possible. - - 4. Independence from the underlying transport, including use in non- - RTP transports, e.g., WebTransport [I-D.ietf-webtrans-overview]. - - 5. When used with RTP and its associated error resilience - mechanisms, i.e., RTX and FEC, require no special handling for - RTX and FEC packets. - - 6. Minimize the changes needed in SFU servers. - - 7. Minimize the changes needed in endpoints. - - 8. Work with the most popular audio and video codecs used in - conferencing scenarios. - -4. SFrame - - This document defines an encryption mechanism that provides effective - E2EE, is simple to implement, has no dependencies on RTP, and - minimizes encryption bandwidth overhead. This section describes how - the mechanism works, including details of how applications utilize - SFrame for media protection, as well as the actual mechanics of E2EE - for protecting media. - -4.1. Application Context - - SFrame is a general encryption framing, intended to be used as an - E2EE layer over an underlying HBH-encrypted transport such as SRTP or - QUIC [RFC3711][I-D.ietf-moq-transport]. - - The scale at which SFrame encryption is applied to media determines - the overall amount of overhead that SFrame adds to the media stream, - as well as the engineering complexity involved in integrating SFrame - into a particular environment. Two patterns are common: Either using - SFrame to encrypt whole media frames (per-frame) or individual - transport-level media payloads (per-packet). - - For example, Figure 1 shows a typical media sender stack that takes - media from some source, encodes it into frames, divides those frames - into media packets, and then sends those payloads in SRTP packets. - The receiver stack performs the reverse operations, reassembling - frames from SRTP packets and decoding. Arrows indicate two different - ways that SFrame protection could be integrated into this media - stack, to encrypt whole frames or individual media packets. - - Applying SFrame per-frame in this system offers higher efficiency, - but may require a more complex integration in environments where - depacketization relies on the content of media packets. Applying - SFrame per-packet avoids this complexity, at the cost of higher - bandwidth consumption. Some quantitative discussion of these trade- - offs is provided in Appendix C. - - As noted above, however, SFrame is a general media encapsulation, and - can be applied in other scenarios. The important thing is that the - sender and receivers of an SFrame-encrypted object agree on that - object's semantics. SFrame does not provide this agreement; it must - be arranged by the application. - - +------------------------------------------------------+ - | | - | +--------+ +-------------+ +-----------+ | - .-. | | | | | | HBH | | -| | | | Encode |----->| Packetize |----->| Protect |----------+ - '+' | | | ^ | | ^ | | | | - /|\ | +--------+ | +-------------+ | +-----------+ | | -/ + \ | | | ^ | | - / \ | SFrame SFrame | | | -/ \ | Protect Protect | | | -Alice | (per-frame) (per-packet) | | | - | ^ ^ | | | - | | | | | | - +---------------|-------------------|---------|--------+ | - | | | v - | | | +------+-+ - | E2E Key | HBH Key | Media | - +---- Management ---+ Management | Server | - | | | +------+-+ - | | | | - +---------------|-------------------|---------|--------+ | - | | | | | | - | V V | | | - .-. | SFrame SFrame | | | -| | | Unprotect Unprotect | | | - '+' | (per-frame) (per-packet) | | | - /|\ | | | V | | -/ + \ | +--------+ | +-------------+ | +-----------+ | | - / \ | | | V | | V | HBH | | | -/ \ | | Decode |<-----| Depacketize |<-----| Unprotect |<---------+ - Bob | | | | | | | | - | +--------+ +-------------+ +-----------+ | - | | - +------------------------------------------------------+ - - Figure 1 - - Like SRTP, SFrame does not define how the keys used for SFrame are - exchanged by the parties in the conference. Keys for SFrame might be - distributed over an existing E2E-secure channel (see Section 5.1), or - derived from an E2E-secure shared secret (see Section 5.2). The key - management system MUST ensure that each key used for encrypting media - is used by exactly one media sender, in order to avoid reuse of - nonces. - -4.2. SFrame Ciphertext - - An SFrame ciphertext comprises an SFrame header followed by the - output of an AEAD encryption of the plaintext [RFC5116], with the - header provided as additional authenticated data (AAD). - - The SFrame header is a variable-length structure described in detail - in Section 4.3. The structure of the encrypted data and - authentication tag are determined by the AEAD algorithm in use. - - +-+----+-+----+--------------------+--------------------+<-+ - |K|KLEN|C|CLEN| Key ID | Counter | | - +->+-+----+-+----+--------------------+--------------------+ | - | | | | - | | | | - | | | | - | | | | - | | Encrypted Data | | - | | | | - | | | | - | | | | - | | | | - +->+-------------------------------------------------------+<-+ - | | Authentication Tag | | - | +-------------------------------------------------------+ | - | | - | | - +--- Encrypted Portion Authenticated Portion ---+ - - When SFrame is applied per-packet, the payload of each packet will be - an SFrame ciphertext. When SFrame is applied per-frame, the SFrame - ciphertext representing an encrypted frame will span several packets, - with the header appearing in the first packet and the authentication - tag in the last packet. It is the responsibility of the application - to reassemble an encrypted frame from individual packets, accounting - for packet loss and reordering as necessary. - -4.3. SFrame Header - - The SFrame header specifies two values from which encryption - parameters are derived: - - * A Key ID (KID) that determines which encryption key should be used - - * A counter (CTR) that is used to construct the nonce for the - encryption - - Applications MUST ensure that each (KID, CTR) combination is used for - exactly one SFrame encryption operation. A typical approach to - achieving this guarantee is outlined in Section 9.1. - - Config Byte - | - .-----' '-----. - | | - 0 1 2 3 4 5 6 7 - +-+-+-+-+-+-+-+-+------------+------------+ - |X| K |Y| C | KID... | CTR... | - +-+-+-+-+-+-+-+-+------------+------------+ - - Figure 2: SFrame header - - The SFrame Header has the overall structure shown in Figure 2. The - first byte is a "config byte", with the following fields: - - Extended Key Id Flag (X, 1 bit): Indicates if the K field contains - the key id or the Key ID length. - - Key or Key Length (K, 3 bits): This field contains the Key ID (KID) - if the X flag is set to 0, or the key id length, minus one, if set - to 1. - - Extended Counter Flag (Y, 1 bit): Indicates if the C field contains - the counter or the counter length. - - Counter or Counter Length (C, 3 bits): This field contains the - counter (CTR) if the Y flag is set to 0, or the counter length, - minus one, if set to 1. - - The Key ID and Counter fields are encoded as compact unsigned - integers in network (big-endian) byte order. If the value of one of - these fields is in the range 0-7, then the value is carried in the - corresponding bits of the config byte (K or C) and the corresponding - flag (X or Y) is set to zero. Otherwise, the value MUST be encoded - with the minimum number of bytes required and appended after the - configuration byte, with the Key ID first and Counter second. The - header field (K or C) is set to the number of bytes in the encoded - value, minus one. The value 000 represents a length of 1, 001 a - length of 2, etc. This allows a 3-bit length field to represent the - value lengths 1-8. - - The SFrame header can thus take one of the four forms shown in - Figure 3, depending on which of the X and Y flags are set. - - KID < 8, CTR < 8: - +-+-----+-+-----+ - |0| KID |0| CTR | - +-+-----+-+-----+ - - KID < 8, CTR >= 8: - +-+-----+-+-----+------------------------+ - |0| KID |1|CLEN | CTR... (length=CLEN) | - +-+-----+-+-----+------------------------+ - - KID >= 8, CTR < 8: - +-+-----+-+-----+------------------------+ - |1|KLEN |0| CTR | KID... (length=KLEN) | - +-+-----+-+-----+------------------------+ - - KID >= 8, CTR >= 8: - +-+-----+-+-----+------------------------+------------------------+ - |1|KLEN |1|CLEN | KID... (length=KLEN) | CTR... (length=CLEN) | - +-+-----+-+-----+------------------------+------------------------+ - - Figure 3: Forms of Encoded SFrame Header - -4.4. Encryption Schema - - SFrame encryption uses an AEAD encryption algorithm and hash function - defined by the cipher suite in use (see Section 4.5). 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. We follow the convention of RFC 5116 - [RFC5116] and consider the authentication tag part of the - ciphertext produced by AEAD.Encrypt (as opposed to a separate - field as in SRTP [RFC3711]). - - * AEAD.Nk - The size in bytes of a key for the encryption algorithm - - * AEAD.Nn - The size in bytes of a nonce for the encryption - algorithm - - * AEAD.Nt - The overhead in bytes of the encryption algorithm - (typically the size of a "tag" that is added to the plaintext) - -4.4.1. Key Selection - - Each SFrame encryption or decryption operation is premised on a - single secret base_key, which is labeled with an integer KID value - signaled in the SFrame header. - - The sender and receivers need to agree on which key should be used - for a given KID. Moreover, senders and receivers need to agree on - whether keys will be used for encryption or decryption only. The - process for provisioning keys and their KID values is beyond the - scope of this specification, but its security properties will bound - the assurances that SFrame provides. For example, if SFrame is used - to provide E2E security against intermediary media nodes, then SFrame - keys need to be negotiated in a way that does not make them - accessible to these intermediaries. - - For each known KID value, the client stores the corresponding - symmetric key base_key. For keys that can be used for encryption, - the client also stores the next counter value CTR to be used when - encrypting (initially 0). - - When encrypting a plaintext, the application specifies which KID is - to be used, and the counter is incremented after successful - encryption. When decrypting, the base_key for decryption is selected - from the available keys using the KID value in the SFrame Header. - - A given key MUST NOT be used for encryption by multiple senders. - Such reuse would result in multiple encrypted frames being generated - with the same (key, nonce) pair, which harms the protections provided - by many AEAD algorithms. Implementations MUST mark each key as - usable for encryption or decryption, never both. - - Note that the set of available keys might change over the lifetime of - a real-time session. In such cases, the client will need to manage - key usage to avoid media loss due to a key being used to encrypt - before all receivers are able to use it to decrypt. For example, an - application may make decryption-only keys available immediately, but - delay the use of keys for encryption until (a) all receivers have - acknowledged receipt of the new key or (b) a timeout expires. - -4.4.2. Key Derivation - - SFrame encrytion and decryption use a key and salt derived from the - base_key associated to a KID. Given a base_key value, the key and - salt are derived using HKDF [RFC5869] as follows: - - def derive_key_salt(KID, base_key): - sframe_secret = HKDF-Extract("", base_key) - - sframe_key_label = "SFrame 1.0 Secret key " + KID + cipher_suite - sframe_key = HKDF-Expand(sframe_secret, info, AEAD.Nk) - - sframe_salt_label = "SFrame 1.0 Secret salt " + KID + cipher_suite - sframe_salt = HKDF-Expand(sframe_secret, info, AEAD.Nn) - - return sframe_key, sframe_salt - - In the derivation of sframe_secret: - - * The + operator represents concatenation of byte strings. - - * The KID value is encoded as an 8-byte big-endian integer, not the - compressed form used in the SFrame header. - - * The cipher_suite value is a 2-byte big-endian integer representing - the cipher suite in use (see Section 8.1). - - The hash function used for HKDF is determined by the cipher suite in - use. - -4.4.3. Encryption - - SFrame encryption uses the AEAD encryption algorithm for the cipher - suite in use. The key for the encryption is the sframe_key and the - nonce is formed by XORing the sframe_salt with the current counter, - encoded as a big-endian integer of length AEAD.Nn. - - The encryptor forms an SFrame header using the CTR, and KID values - provided. The encoded header is provided as AAD to the AEAD - encryption operation, together with application-provided metadata - about the encrypted media (see Section 9.4). - - def encrypt(CTR, KID, metadata, plaintext): - sframe_key, sframe_salt = key_store[KID] - - ctr = encode_big_endian(CTR, AEAD.Nn) - nonce = xor(sframe_salt, CTR) - - header = encode_sframe_header(CTR, KID) - aad = header + metadata - - ciphertext = AEAD.Encrypt(sframe_key, nonce, aad, plaintext) - return header + ciphertext - - For example, the metadata input to encryption allows for frame - metadata to be authenticated when SFrame is applied per-frame. After - encoding the frame and before packetizing it, the necessary media - metadata will be moved out of the encoded frame buffer, to be sent in - some channel visible to the SFU (e.g., an RTP header extension). - - +---------------+ - | | - | | - | plaintext | - | | - | | - +-------+-------+ - | - .- +-----+ | - | | +--+--> sframe_key ----->| Key - Header | | KID | | | - | | | +--> sframe_salt --+ | - +--+ +-----+ | | - | | | +---------------------+->| Nonce - | | | CTR | | - | | | | | - | '- +-----+ | - | | - | +----------------+ | - | | metadata | | - | +-------+--------+ | - | | | - +------------------+----------------->| AAD - | | - | AEAD.Encrypt - | | - | SFrame Ciphertext | - | +---------------+ | - +-------------->| SFrame Header | | - +---------------+ | - | | | - | |<----+ - | ciphertext | - | | - | | - +---------------+ - - Figure 4: Encrypting an SFrame Ciphertext - -4.4.4. Decryption - - Before decrypting, a receiver needs to assemble a full SFrame - ciphertext. When an SFrame ciphertext may be fragmented into - multiple parts for transport (e.g., a whole encrypted frame sent in - multiple SRTP packets), the receiving client collects all the - fragments of the ciphertext, using an appropriate sequencing and - start/end markers in the transport. Once all of the required - fragments are available, the client reassembles them into the SFrame - ciphertext, then passes the ciphertext to SFrame for decryption. - - The KID field in the SFrame header is used to find the right key and - salt for the encrypted frame, and the CTR field is used to construct - the nonce. The SFrame decryption procedure is as follows: - - def decrypt(metadata, sframe_ciphertext): - KID, CTR, header, ciphertext = parse_ciphertext(sframe_ciphertext) - - sframe_key, sframe_salt = key_store[KID] - - ctr = encode_big_endian(CTR, AEAD.Nn) - nonce = xor(sframe_salt, ctr) - aad = header + metadata - - return AEAD.Decrypt(sframe_key, nonce, aad, ciphertext) - - If a ciphertext fails to decrypt because there is no key available - for the KID in the SFrame 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 ciphertexts SHOULD be discarded - in a way that is indistinguishable (to an external observer) from - having processed a valid ciphertext. - - SFrame Ciphertext - +---------------+ - +---------------| SFrame Header | - | +---------------+ - | | | - | | |-----+ - | | ciphertext | | - | | | | - | | | | - | +---------------+ | - | | - | .- +-----+ | - | | | +--+--> sframe_key ----->| Key - | | | KID | | | - | | | | +--> sframe_salt --+ | - +->+ +-----+ | | - | | | +---------------------+->| Nonce - | | | CTR | | - | | | | | - | '- +-----+ | - | | - | +----------------+ | - | | metadata | | - | +-------+--------+ | - | | | - +------------------+----------------->| AAD - | - AEAD.Decrypt - | - V - +---------------+ - | | - | | - | plaintext | - | | - | | - +---------------+ - - Figure 5: Decrypting an SFrame Ciphertext - -4.5. Cipher Suites - - Each SFrame session uses a single cipher suite that specifies the - following primitives: - - * A hash function used for key derivation - - * An AEAD encryption algorithm [RFC5116] used for frame encryption, - optionally with a truncated authentication tag - - This document defines the following cipher suites, with the constants - defined in Section 4.4: - - +============================+====+====+====+====+ - | Name | Nh | Nk | Nn | Nt | - +============================+====+====+====+====+ - | AES_128_CTR_HMAC_SHA256_80 | 32 | 48 | 12 | 10 | - +----------------------------+----+----+----+----+ - | AES_128_CTR_HMAC_SHA256_64 | 32 | 48 | 12 | 8 | - +----------------------------+----+----+----+----+ - | AES_128_CTR_HMAC_SHA256_32 | 32 | 48 | 12 | 4 | - +----------------------------+----+----+----+----+ - | AES_128_GCM_SHA256_128 | 32 | 16 | 12 | 16 | - +----------------------------+----+----+----+----+ - | AES_256_GCM_SHA512_128 | 64 | 32 | 12 | 16 | - +----------------------------+----+----+----+----+ - - Table 1: SFrame cipher suite constants - - Numeric identifiers for these cipher suites are defined in the IANA - registry created in Section 8.1. - - In the suite names, the length of the authentication tag is indicated - by the last value: "_128" indicates a hundred-twenty-eight-bit tag, - "_80" indicates a eighty-bit tag, "_64" indicates a sixty-four-bit - tag and "_32" indicates a thirty-two-bit tag. - - In a session that uses multiple media streams, different cipher - suites might be configured for different media streams. For example, - in order to conserve bandwidth, a session might use a cipher suite - with eighty-bit tags for video frames and another cipher suite with - thirty-two-bit tags for audio frames. - -4.5.1. AES-CTR with SHA2 - - In order to allow very short tag sizes, we define a synthetic AEAD - function using the authenticated counter mode of AES together with - HMAC for authentication. We use an encrypt-then-MAC approach, as in - SRTP [RFC3711]. - - Before encryption or decryption, encryption and authentication - subkeys are derived from the single AEAD key. The overall length of - the AEAD key is Nka + Nh, where Nka represents the key size for the - AES block cipher in use and Nh represents the output size of the hash - function (as in Table 2). The encryption subkey comprises the first - Nka bytes and the authentication subkey comprises the remaining Nh - bytes. - - def derive_subkeys(sframe_key): - enc_key = sframe_key[..Nka] - auth_key = sframe_key[Nka..] - return enc_key, auth_key - - The AEAD encryption and decryption functions are then composed of - individual calls to the CTR encrypt function and HMAC. The resulting - MAC value is truncated to a number of bytes Nt fixed by the cipher - suite. - - def truncate(tag, n): - # Take the first `n` bytes of `tag` - return tag[..n] - - def compute_tag(auth_key, nonce, aad, ct): - aad_len = encode_big_endian(len(aad), 8) - ct_len = encode_big_endian(len(ct), 8) - tag_len = encode_big_endian(Nt, 8) - auth_data = aad_len + ct_len + tag_len + nonce + aad + ct - tag = HMAC(auth_key, auth_data) - return truncate(tag, Nt) - - def AEAD.Encrypt(key, nonce, aad, pt): - enc_key, auth_key = derive_subkeys(key) - initial_counter = nonce + 0x00000000 # append four zero bytes - ct = AES-CTR.Encrypt(enc_key, initial_counter, pt) - tag = compute_tag(auth_key, nonce, aad, ct) - return ct + tag - - def AEAD.Decrypt(key, nonce, aad, ct): - inner_ct, tag = split_ct(ct, tag_len) - - enc_key, auth_key = derive_subkeys(key) - candidate_tag = compute_tag(auth_key, nonce, aad, inner_ct) - if !constant_time_equal(tag, candidate_tag): - raise Exception("Authentication Failure") - - initial_counter = nonce + 0x00000000 # append four zero bytes - return AES-CTR.Decrypt(enc_key, initial_counter, inner_ct) - -5. Key Management - - SFrame must be integrated with an E2E key management framework to - exchange and rotate the keys used for SFrame encryption. The key - management framework provides the following functions: - - * Provisioning KID / base_key mappings to participating clients - - * Updating the above data as clients join or leave - - It is the responsibility of the application to provide the key - management framework, as described in Section 9.2. - -5.1. Sender Keys - - If the participants in a call have a pre-existing E2E-secure channel, - they can use it to distribute SFrame keys. Each client participating - in a call generates a fresh base_key value that it will use to - encrypt media. The client then uses the E2E-secure channel to send - their encryption key to the other participants. - - In this scheme, it is assumed that receivers have a signal outside of - SFrame for which client has sent a given frame (e.g., an RTP SSRC). - SFrame KID values are then used to distinguish between versions of - the sender's base_key. - - Key IDs in this scheme have two parts, a "key generation" and a - "ratchet step". Both are unsigned integers that begin at zero. The - key generation increments each time the sender distributes a new key - to receivers. The "ratchet step" is incremented each time the sender - ratchets their key forward for forward secrecy: - - base_key[i+1] = HKDF-Expand( - HKDF-Extract("", base_key[i]), - "SFrame 1.0 Ratchet", CipherSuite.Nh) - - For compactness, we do not send the whole ratchet step. Instead, we - send only its low-order R bits, where R is a value set by the - application. Different senders may use different values of R, but - each receiver of a given sender needs to know what value of R is used - by the sender so that they can recognize when they need to ratchet - (vs. expecting a new key). R effectively defines a re-ordering - window, since no more than 2^R ratchet steps can be active at a given - time. The key generation is sent in the remaining 64 - R bits of the - key ID. - - KID = (key_generation << R) + (ratchet_step % (1 << R)) - - 64-R bits R bits - <---------------> <------------> - +-----------------+--------------+ - | Key Generation | Ratchet Step | - +-----------------+--------------+ - - Figure 6: Structure of a KID in the Sender Keys scheme - - The sender signals such a ratchet step update by sending with a KID - value in which the ratchet step has been incremented. A receiver who - receives from a sender with a new KID computes the new key as above. - The old key may be kept for some time to allow for out-of-order - delivery, but should be deleted promptly. - - If a new participant joins in the middle of a session, they will need - to receive from each sender (a) the current sender key for that - sender and (b) the current KID value for the sender. Evicting a - participant requires each sender to send a fresh sender key to all - receivers. - - It is up to the application to decide when sender keys are updated. - A sender key may be updated by sending a new base_key (updating the - key generation) or by hashing the current base_key (updating the - ratchet step). Ratcheting the key forward is useful when adding new - receivers to an SFrame-based interaction, since it assures that the - new receivers can't decrypt any media encrypted before they were - added. If a sender wishes to assure the opposite property when - removing a receiver (i.e., ensuring that the receiver can't decrypt - media after they are removed), then the sender will need to - distribute a new sender key. - -5.2. MLS - - The Messaging Layer Security (MLS) protocol provides group - authenticated key exchange [MLS-ARCH] [MLS-PROTO]. In principle, it - could be used to instantiate the sender key scheme above, but it can - also be used more efficiently directly. - - MLS creates a linear sequence of keys, each of which is shared among - the members of a group at a given point in time. When a member joins - or leaves the group, a new key is produced that is known only to the - augmented or reduced group. Each step in the lifetime of the group - is known as an "epoch", and each member of the group is assigned an - "index" that is constant for the time they are in the group. - - To generate keys and nonces for SFrame, we use the MLS exporter - function to generate a base_key value for each MLS epoch. Each - member of the group is assigned a set of KID values, so that each - member has a unique sframe_key and sframe_salt that it uses to - encrypt with. Senders may choose any KID value within their assigned - set of KID values, e.g., to allow a single sender to send multiple - uncoordinated outbound media streams. - - base_key = MLS-Exporter("SFrame 1.0 Base Key", "", AEAD.Nk) - - For compactness, we do not send the whole epoch number. Instead, we - send only its low-order E bits, where E is a value set by the - application. E effectively defines a re-ordering window, since no - more than 2^E epochs can be active at a given time. Receivers MUST - be prepared for the epoch counter to roll over, removing an old epoch - when a new epoch with the same E lower bits is introduced. - - Let S be the number of bits required to encode a member index in the - group, i.e., the smallest value such that group_size <= (1 << S). - The sender index is encoded in the S bits above the epoch. The - remaining 64 - S - E bits of the KID value are a context value chosen - by the sender (context value 0 will produce the shortest encoded - KID). - - KID = (context << (S + E)) + (sender_index << E) + (epoch % (1 << E)) - - 64-S-E bits S bits E bits - <-----------> <------> <------> - +-------------+--------+-------+ - | Context ID | Index | Epoch | - +-------------+--------+-------+ - - Figure 7: Structure of a KID for an MLS Sender - - Once an SFrame stack has been provisioned with the - sframe_epoch_secret for an epoch, it can compute the required KID - values on demand (as well as the resulting SFrame keys/nonces derived - from the base_key and KID), as it needs to encrypt or decrypt for a - given member. - - ... - | - | - Epoch 14 +--+-- index=3 ---> KID = 0x3e - | | - | +-- index=7 ---> KID = 0x7e - | | - | +-- index=20 --> KID = 0x14e - | - | - Epoch 15 +--+-- index=3 ---> KID = 0x3f - | | - | +-- index=5 ---> KID = 0x5f - | - | - Epoch 16 +----- index=2 --+--> context = 2 --> KID = 0x820 - | | - | +--> context = 3 --> KID = 0xc20 - | - | - Epoch 17 +--+-- index=33 --> KID = 0x211 - | | - | +-- index=51 --> KID = 0x331 - | - | - ... - - Figure 8: An example sequence of KIDs for an MLS-based SFrame - session (E=4; S=6, allowing for 64 group members) - -6. Media Considerations - -6.1. Selective Forwarding Units - - Selective Forwarding Units (SFUs) (e.g., those described in - Section 3.7 of [RFC7667]) receive the media streams from each - participant and select which ones should be forwarded to each of the - other participants. There are several approaches for stream - selection, but in general, the SFU needs to access metadata - associated to each frame and modify the RTP information of the - incoming packets when they are transmitted to the received - participants. - - This section describes how this normal SFU modes of operation - interact with the E2EE provided by SFrame. - -6.1.1. LastN and RTP stream reuse - - The SFU may choose to send only a certain number of streams based on - the voice activity of the participants. To avoid the overhead - involved in establishing new transport streams, the SFU may decide to - reuse previously existing streams or even pre-allocate a predefined - number of streams and choose in each moment in time which participant - media will be sent through it. - - This means that in the same transport-level stream (e.g., an RTP - stream defined by either SSRC or MID) may carry media from different - streams of different participants. As different keys are used by - each participant for encoding their media, the receiver will be able - to verify which is the sender of the media coming within the RTP - stream at any given point in time, preventing the SFU trying to - impersonate any of the participants with another participant's media. - - Note that in order to prevent impersonation by a malicious - participant (not the SFU), a mechanism based on digital signature - would be required. SFrame does not protect against such attacks. - -6.1.2. Simulcast - - When using simulcast, the same input image will produce N different - encoded frames (one per simulcast layer) which would be processed - independently by the frame encryptor and assigned an unique counter - for each. - -6.1.3. SVC - - In both temporal and spatial scalability, the SFU may choose to drop - layers in order to match a certain bitrate or forward specific media - sizes or frames per second. In order to support the SFU selectively - removing layers, the sender MUST encapsulate each layer in a - different SFrame ciphertext. - -6.2. Video Key Frames - - Forward Security and Post-Compromise Security require that the E2EE - keys (base keys) are updated any time a participant joins or leaves - the call. - - The key exchange happens asynchronously and on a different path than - the SFU signaling and media. So it may happen that when a new - participant joins the call and the SFU side requests a key frame, the - sender generates the E2EE frame with a key not known by the receiver, - so it will be discarded. When the sender updates his sending key - with the new key, it will send it in a non-key frame, so the receiver - will be able to decrypt it, but not decode it. - - The new Receiver will then re-request a key frame, but due to sender - and SFU policies, that new key frame could take some time to be - generated. - - If the sender sends a key frame after the new E2EE key is in use, the - time required for the new participant to display the video is - minimized. - -6.3. Partial Decoding - - Some codecs support partial decoding, where individual packets can be - decoded without waiting for the full frame to arrive. When SFrame is - applied per-frame, this won't be possible because the decoder cannot - access data until an entire frame has arrived and has been decrypted. - -7. Security Considerations - -7.1. No Header Confidentiality - - SFrame provides integrity protection to the SFrame Header (the key ID - and counter values), but does not provide confidentiality protection. - Parties that can observe the SFrame header may learn, for example, - which parties are sending SFrame payloads (from KID values) and at - what rates (from CTR values). In cases where SFrame is used for end- - to-end security on top of hop-by-hop protections (e.g., running over - SRTP as described in Appendix C.5), the hop-by-hop security - mechanisms provide confidentiality protection of the SFrame header - between hops. - -7.2. No Per-Sender Authentication - - SFrame does not provide per-sender authentication of media data. Any - sender in a session can send media that will be associated with any - other sender. This is because SFrame uses symmetric encryption to - protect media data, so that any receiver also has the keys required - to encrypt packets for the sender. - -7.3. Key Management - - Key exchange mechanism is out of scope of this document, however - every client SHOULD change their keys when new clients joins or - leaves the call for forward secrecy and post compromise security. - -7.4. Replay - - The handling of replay is out of the scope of this document. - However, senders MUST reject requests to encrypt multiple times with - the same key and nonce, since several AEAD algorithms fail badly in - such cases (see, e.g., Section 5.1.1 of [RFC5116]). - -7.5. Risks due to Short Tags - - The SFrame ciphersuites based on AES-CTR allow for the use of short - authentication tags, which bring a higher risk that an attacker will - be able to cause an SFrame receiver to accept an SFrame ciphertext of - the attacker's choosing. - - Assuming that the authentication properties of the ciphersuite are - robust, the only attack that an attacker can mount is an attempt to - find an acceptable (ciphertext, tag) combination through brute force. - Such a brute-force attack will have an expected sucess rate of the - following form: - - attacker_success_rate = attempts_per_second / 2^(8*Nt) - - For example, a gigabit ethernet connection is able to transmit - roughly 2^20 packets per second. If an attacker saturated such a - link with guesses against a 32-bit authentication tag (Nt=4), then - the attacker would succeed on average roughly once every 2^12 - seconds, or about once an hour. - - In a typical SFrame usage in a real-time media application, there are - a few approaches to mitigating this risk: - - * Receivers only accept SFrame ciphertexts over HBH-secure channels - (e.g., SRTP security associations or QUIC connections). If this - is the case, only an entity that is part of such a channel can - mount the above attack. - - * The expected packet rate for a media stream is very predictable - (and typically far lower than the above example). On the one - hand, attacks at this rate will succeed even less often than the - high-rate attack described above. On the other hand, the - application may use an elevated packet arrival rate as a signal of - a brute-force attack. This latter approach is common in other - settings, e.g., mitigating brute-force attacks on passwords. - - * Media applications typically do not provide feedback to media - senders as to which media packets failed to decrypt. When media - quality feedback mechanisms are used, decryption failures will - typically appear as packet losses, but only at an aggregate level. - - * Anti-replay mechanisms (see Section 7.4) prevent the attacker from - re-using valid ciphertexts (either observed or guessed by the - attacker). A receiver applying anti-replay controls will only - accept one valid plaintext per CTR value. Since the CTR value is - covered by SFrame authentication, an attacker has to do a fresh - search for a valid tag for every forged ciphertext, even if the - encrypted content is unchanged. In other words, when the above - brute force attack succeeds, it only allows the attacker to send a - single SFrame ciphertext; the ciphertext cannot be reused because - either it will have the same CTR value and be discarded as a - replay, or else it will have a different CTR value its tag will no - longer be valid. - - Nonetheless, without these mitigations, an application that makes use - of short tags will be at heightened risk of forgery attacks. In many - cases, it is simpler to use full-size tags and tolerate slightly - higher bandwidth usage rather than add the additional defenses - necessary to safely use short tags. - -8. IANA Considerations - - This document requests the creation of the following new IANA - registry: - - * SFrame Cipher Suites (Section 8.1) - - This registry should be under a heading of "SFrame", and assignments - are made via the Specification Required policy [RFC8126]. - - RFC EDITOR: Please replace XXXX throughout with the RFC number - assigned to this document - -8.1. SFrame Cipher Suites - - This registry lists identifiers for SFrame cipher suites, as defined - in Section 4.5. The cipher suite field is two bytes wide, so the - valid cipher suites are in the range 0x0000 to 0xFFFF. - - Template: - - * Value: The numeric value of the cipher suite - - * Name: The name of the cipher suite - - * Reference: The document where this cipher suite is defined - - Initial contents: - - +=================+============================+===========+ - | Value | Name | Reference | - +=================+============================+===========+ - | 0x0001 | AES_128_CTR_HMAC_SHA256_80 | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0x0002 | AES_128_CTR_HMAC_SHA256_64 | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0x0003 | AES_128_CTR_HMAC_SHA256_32 | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0x0004 | AES_128_GCM_SHA256_128 | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0x0005 | AES_256_GCM_SHA512_128 | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0xF000 - 0xFFFF | Reserved for private use | RFC XXXX | - +-----------------+----------------------------+-----------+ - - Table 2: SFrame cipher suites - -9. Application Responsibilities - - To use SFrame, an application needs to define the inputs to the - SFrame encryption and decryption operations, and how SFrame - ciphertexts are delivered from sender to receiver (including any - fragmentation and reassembly). In this section, we lay out - additional requirements that an integration must meet in order for - SFrame to operate securely. - -9.1. Header Value Uniqueness - - Applications MUST ensure that each (base_key, KID, CTR) combination - is used for at most one SFrame encryption operation. This ensures - that the (key, nonce) pairs used by the underlying AEAD algorithm are - never reused. Typically this is done by assigning each sender a KID - or set of KIDs, then having each sender use the CTR field as a - monotonic counter, incrementing for each plaintext that is encrypted. - In addition to its simplicity, this scheme minimizes overhead by - keeping CTR values as small as possible. - -9.2. Key Management Framework - - It is up to the application to provision SFrame with a mapping of KID - values to base_key values and the resulting keys and salts. More - importantly, the application specifies which KID values are used for - which purposes (e.g., by which senders). An application's KID - assignment strategy MUST be structured to assure the non-reuse - properties discussed in Section 9.1. - - It is also up to the application to define a rotation schedule for - keys. For example, one application might have an ephemeral group for - every call and keep rotating keys when end points join or leave the - call, while another application could have a persistent group that - can be used for multiple calls and simply derives ephemeral symmetric - keys for a specific call. - - It should be noted that KID values are not encrypted by SFrame, and - are thus visible to any application-layer intermediaries that might - handle an SFrame ciphertext. If there are application semantics - included in KID values, then this information would be exposed to - intermediaries. For example, in the scheme of Section 5.1, the - number of ratchet steps per sender is exposed, and in the scheme of - Section 5.2, the number of epochs and the MLS sender ID of the SFrame - sender are exposed. - -9.3. Anti-Replay - - It is the responsibility of the application to handle anti-replay. - Replay by network attackers is assumed to be prevented by network- - layer facilities (e.g., TLS, SRTP). As mentioned in Section 7.4, - senders MUST reject requests to encrypt multiple times with the same - key and nonce. - - It is not mandatory to implement anti-replay on the receiver side. - Receivers MAY apply time or counter based anti-replay mitigations. - For example, Section 3.3.2 of [RFC3711] specifies a counter-based - anti-replay mitigation, which could be adapted to use with SFrame, - using the CTR field as the counter. - -9.4. Metadata - - The metadata input to SFrame operations is pure application-specified - data. As such, it is up to the application to define what - information should go in the metadata input and ensure that it is - provided to the encryption and decryption functions at the - appropriate points. A receiver MUST NOT use SFrame-authenticated - metadata until after the SFrame decrypt function has authenticated - it, unless the purpose of such usage is to prepare an SFrame - ciphertext for SFrame decryption. Essentially, metadata may be used - "upstream of SFrame" in a processing pipeline, but only to prepare - for SFrame decryption. - - For example, consider an application where SFrame is used to encrypt - audio frames that are sent over SRTP, with some application data - included in the RTP header extension. Suppose the application also - includes this application data in the SFrame metadata, so that the - SFU is allowed to read, but not modify the application data. A - receiver can use the application data in the RTP header extension as - part of the standard SRTP decryption process, since this is required - to recover the SFrame ciphertext carried in the SRTP payload. - However, the receiver MUST NOT use the application data for other - purposes before SFrame decryption has authenticated the application - data. - -10. References - -10.1. Normative References - - [MLS-PROTO] - Barnes, R., Beurdouche, B., Robert, R., Millican, J., - Omara, E., and K. Cohn-Gordon, "The Messaging Layer - Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, - July 2023, . - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated - Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, - . - - [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand - Key Derivation Function (HKDF)", RFC 5869, - DOI 10.17487/RFC5869, May 2010, - . - - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for - Writing an IANA Considerations Section in RFCs", BCP 26, - RFC 8126, DOI 10.17487/RFC8126, June 2017, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - -10.2. Informative References - - [I-D.codec-agnostic-rtp-payload-format] - Murillo, S. G. and A. Gouaillard, "Codec agnostic RTP - payload format for video", Work in Progress, Internet- - Draft, draft-codec-agnostic-rtp-payload-format-00, 19 - February 2021, . - - [I-D.ietf-moq-transport] - Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and - I. Swett, "Media over QUIC Transport", Work in Progress, - Internet-Draft, draft-ietf-moq-transport-02, 24 January - 2024, . - - [I-D.ietf-webtrans-overview] - Vasiliev, V., "The WebTransport Protocol Framework", Work - in Progress, Internet-Draft, draft-ietf-webtrans-overview- - 06, 6 September 2023, - . - - [MLS-ARCH] Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., and - A. Duric, "The Messaging Layer Security (MLS) - Architecture", Work in Progress, Internet-Draft, draft- - ietf-mls-architecture-11, 26 July 2023, - . - - [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. - Norrman, "The Secure Real-time Transport Protocol (SRTP)", - RFC 3711, DOI 10.17487/RFC3711, March 2004, - . - - [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session - Description Protocol", RFC 4566, DOI 10.17487/RFC4566, - July 2006, . - - [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the - Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, - September 2012, . - - [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and - B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms - for Real-Time Transport Protocol (RTP) Sources", RFC 7656, - DOI 10.17487/RFC7656, November 2015, - . - - [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, - DOI 10.17487/RFC7667, November 2015, - . - - [RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach, - "Double Encryption Procedures for the Secure Real-Time - Transport Protocol (SRTP)", RFC 8723, - DOI 10.17487/RFC8723, April 2020, - . - - [TestVectors] - "SFrame Test Vectors", 2023, - . - -Appendix A. Acknowledgements - - The authors wish to specially thank Dr. Alex Gouaillard as one of the - early contributors to the document. His passion and energy were key - to the design and development of SFrame. - -Appendix B. Example API - - *This section is not normative.* - - This section describes a notional API that an SFrame implementation - might expose. The core concept is an "SFrame context", within which - KID values are meaningful. In the key management scheme described in - Section 5.1, each sender has a different context; in the scheme - described in Section 5.2, all senders share the same context. - - An SFrame context stores mappings from KID values to "key contexts", - which are different depending on whether the KID is to be used for - sending or receiving (an SFrame key should never be used for both - operations). A key context tracks the key and salt associated to the - KID, and the current CTR value. A key context to be used for sending - also tracks the next CTR value to be used. - - The primary operations on an SFrame context are as follows: - - * *Create an SFrame context:* The context is initialized with a - ciphersuite and no KID mappings. - - * *Adding a key for sending:* The key and salt are derived from the - base key, and used to initialize a send context, together with a - zero counter value. - - * *Adding a key for receiving:* The key and salt are derived from - the base key, and used to initialize a send context. - - * *Encrypt a plaintext:* Encrypt a given plaintext using the key for - a given KID, including the specified metadata. - - * *Decrypt an SFrame ciphertext:* Decrypt an SFrame ciphertext with - the KID and CTR values specified in the SFrame Header, and the - provided metadata. - - Figure 9 shows an example of the types of structures and methods that - could be used to create an SFrame API in Rust. - - type KeyId = u64; - type Counter = u64; - type CipherSuite = u16; - - struct SendKeyContext { - key: Vec, - salt: Vec, - next_counter: Counter, - } - - struct RecvKeyContext { - key: Vec, - salt: Vec, - } - - struct SFrameContext { - cipher_suite: CipherSuite, - send_keys: HashMap, - recv_keys: HashMap, - } - - trait SFrameContextMethods { - fn create(cipher_suite: CipherSuite) -> Self; - fn add_send_key(&self, kid: KeyId, base_key: &[u8]); - fn add_recv_key(&self, kid: KeyId, base_key: &[u8]); - fn encrypt(&mut self, kid: KeyId, metadata: &[u8], - plaintext: &[u8]) -> Vec; - fn decrypt(&self, metadata: &[u8], ciphertext: &[u8]) -> Vec; - } - - Figure 9: An Example SFrame API - -Appendix C. Overhead Analysis - - Any use of SFrame will impose overhead in terms of the amount of - bandwidth necessary to transmit a given media stream. Exactly how - much overhead will be added depends on several factors: - - * How many senders are involved in a conference (length of KID) - - * How long the conference has been going on (length of CTR) - - * The cipher suite in use (length of authentication tag) - - * Whether SFrame is used to encrypt packets, whole frames, or some - other unit - - Overall, the overhead rate in kilobits per second can be estimated - as: - - OverheadKbps = (1 + |CTR| + |KID| + |TAG|) * 8 * CTPerSecond / 1024 - - Here the constant value 1 reflects the fixed SFrame header; |CTR| - and |KID| reflect the lengths of those fields; |TAG| reflects the - cipher overhead; and CTPerSecond reflects the number of SFrame - ciphertexts sent per second (e.g., packets or frames per second). - - In the remainder of this secton, we compute overhead estimates for a - collection of common scenarios. - -C.1. Assumptions - - In the below calculations, we make conservative assumptions about - SFrame overhead, so that the overhead amounts we compute here are - likely to be an upper bound on those seen in practice. - - +==============+=======+============================+ - | Field | Bytes | Explanation | - +==============+=======+============================+ - | Fixed header | 1 | Fixed | - +--------------+-------+----------------------------+ - | Key ID (KID) | 2 | >255 senders; or MLS epoch | - | | | (E=4) and >16 senders | - +--------------+-------+----------------------------+ - | Counter | 3 | More than 24 hours of | - | (CTR) | | media in common cases | - +--------------+-------+----------------------------+ - | Cipher | 16 | Full GCM tag (longest | - | overhead | | defined here) | - +--------------+-------+----------------------------+ - - Table 3 - - In total, then, we assume that each SFrame encryption will add 22 - bytes of overhead. - - We consider two scenarios, applying SFrame per-frame and per-packet. - In each scenario, we compute the SFrame overhead in absolute terms - (Kbps) and as a percentage of the base bandwidth. - -C.2. Audio - - In audio streams, there is typically a one-to-one relationship - between frames and packets, so the overhead is the same whether one - uses SFrame at a per-packet or per-frame level. - - The below table considers three scenarios, based on recommended - configurations of the Opus codec [RFC6716]: - - * Narrow-band speech: 120ms packets, 8Kbps - - * Full-band speech: 20ms packets, 32Kbps - - * Full-band stereo music: 10ms packets, 128Kbps - - +===============+=====+===========+===============+============+ - | Scenario | fps | Base Kbps | Overhead Kbps | Overhead % | - +===============+=====+===========+===============+============+ - | NB speech, | 8.3 | 8 | 1.4 | 17.9% | - | 120ms packets | | | | | - +---------------+-----+-----------+---------------+------------+ - | FB speech, | 50 | 32 | 8.6 | 26.9% | - | 20ms packets | | | | | - +---------------+-----+-----------+---------------+------------+ - | FB stereo, | 100 | 128 | 17.2 | 13.4% | - | 10ms packets | | | | | - +---------------+-----+-----------+---------------+------------+ - - Table 4: SFrame overhead for audio streams - -C.3. Video - - Video frames can be larger than an MTU and thus are commonly split - across multiple frames. Table 5 and Table 6 show the estimated - overhead of encrypting a video stream, where SFrame is applied per- - frame and per-packet, respectively. The choices of resolution, - frames per second, and bandwidth are chosen to roughly reflect the - capabilities of modern video codecs across a range from very low to - very high quality. - - +=============+=====+===========+===============+============+ - | Scenario | fps | Base Kbps | Overhead Kbps | Overhead % | - +=============+=====+===========+===============+============+ - | 426 x 240 | 7.5 | 45 | 1.3 | 2.9% | - +-------------+-----+-----------+---------------+------------+ - | 640 x 360 | 15 | 200 | 2.6 | 1.3% | - +-------------+-----+-----------+---------------+------------+ - | 640 x 360 | 30 | 400 | 5.2 | 1.3% | - +-------------+-----+-----------+---------------+------------+ - | 1280 x 720 | 30 | 1500 | 5.2 | 0.3% | - +-------------+-----+-----------+---------------+------------+ - | 1920 x 1080 | 60 | 7200 | 10.3 | 0.1% | - +-------------+-----+-----------+---------------+------------+ - - Table 5: SFrame overhead for a video stream encrypted per- - frame - - +=============+=====+=====+===========+===============+============+ - | Scenario | fps | pps | Base Kbps | Overhead Kbps | Overhead % | - +=============+=====+=====+===========+===============+============+ - | 426 x 240 | 7.5 | 7.5 | 45 | 1.3 | 2.9% | - +-------------+-----+-----+-----------+---------------+------------+ - | 640 x 360 | 15 | 30 | 200 | 5.2 | 2.6% | - +-------------+-----+-----+-----------+---------------+------------+ - | 640 x 360 | 30 | 60 | 400 | 10.3 | 2.6% | - +-------------+-----+-----+-----------+---------------+------------+ - | 1280 x 720 | 30 | 180 | 1500 | 30.9 | 2.1% | - +-------------+-----+-----+-----------+---------------+------------+ - | 1920 x 1080 | 60 | 780 | 7200 | 134.1 | 1.9% | - +-------------+-----+-----+-----------+---------------+------------+ - - Table 6: SFrame overhead for a video stream encrypted per-packet - - In the per-frame case, the SFrame percentage overhead approaches zero - as the quality of the video goes up, since bandwidth is driven more - by picture size than frame rate. In the per-packet case, the SFrame - percentage overhead approaches the ratio between the SFrame overhead - per packet and the MTU (here 22 bytes of SFrame overhead divided by - an assumed 1200-byte MTU, or about 1.8%). - -C.4. Conferences - - Real conferences usually involve several audio and video streams. - The overhead of SFrame in such a conference is the aggregate of the - overhead over all the individual streams. Thus, while SFrame incurs - a large percentage overhead on an audio stream, if the conference - also involves a video stream, then the audio overhead is likely - negligible relative to the overall bandwidth of the conference. - - For example, Table 7 shows the overhead estimates for a two person - conference where one person is sending low-quality media and the - other sending high-quality. (And we assume that SFrame is applied - per-frame.) The video streams dominate the bandwidth at the SFU, so - the total bandwidth overhead is only around 1%. - - +=====================+===========+===============+============+ - | Stream | Base Kbps | Overhead Kbps | Overhead % | - +=====================+===========+===============+============+ - | Participant 1 audio | 8 | 1.4 | 17.9% | - +---------------------+-----------+---------------+------------+ - | Participant 1 video | 45 | 1.3 | 2.9% | - +---------------------+-----------+---------------+------------+ - | Participant 2 audio | 32 | 9 | 26.9% | - +---------------------+-----------+---------------+------------+ - | Participant 2 video | 1500 | 5 | 0.3% | - +---------------------+-----------+---------------+------------+ - | Total at SFU | 1585 | 16.5 | 1.0% | - +---------------------+-----------+---------------+------------+ - - Table 7: SFrame overhead for a two-person conference - -C.5. SFrame over RTP - - SFrame is a generic encapsulation format, but many of the - applications in which it is likely to be integrated are based on RTP. - This section discusses how an integration between SFrame and RTP - could be done, and some of the challenges that would need to be - overcome. - - As discussed in Section 4.1, there are two natural patterns for - integrating SFrame into an application: applying SFrame per-frame or - per-packet. In RTP-based applications, applying SFrame per-packet - means that the payload of each RTP packet will be an SFrame - ciphertext, starting with an SFrame Header, as shown in Figure 10. - Applying SFrame per-frame means that different RTP payloads will have - different formats: The first payload of a frame will contain the - SFrame headers, and subsequent payloads will contain further chunks - of the ciphertext, as shown in Figure 11. - - In order for these media payloads to be properly interpreted by - receivers, receivers will need to be configured to know which of the - above schemes the sender has applied to a given sequence of RTP - packets. SFrame does not provide a mechanism for distributing this - configuration information. In applications that use SDP for - negotiating RTP media streams [RFC4566], an appropriate extension to - SDP could provide this function. - - Applying SFrame per-frame also requires that packetization and - depacketization be done in a generic manner that does not depend on - the media content of the packets, since the content being packetized - / depacketized will be opaque ciphertext (except for the SFrame - header). In order for such a generic packetization scheme to work - interoperably one would have to be defined, e.g., as proposed in - [I-D.codec-agnostic-rtp-payload-format]. - - +---+-+-+-------+-+-------------+-------------------------------+<-+ - |V=2|P|X| CC |M| PT | sequence number | | - +---+-+-+-------+-+-------------+-------------------------------+ | - | timestamp | | - +---------------------------------------------------------------+ | - | synchronization source (SSRC) identifier | | - +===============================================================+ | - | contributing source (CSRC) identifiers | | - | .... | | - +---------------------------------------------------------------+ | - | RTP extension(s) (OPTIONAL) | | - +->+--------------------+------------------------------------------+ | - | | SFrame header | | | - | +--------------------+ | | - | | | | - | | SFrame encrypted and authenticated payload | | - | | | | - +->+---------------------------------------------------------------+<-+ - | | SRTP authentication tag | | - | +---------------------------------------------------------------+ | - | | - +--- SRTP Encrypted Portion SRTP Authenticated Portion ---+ - - Figure 10: SRTP packet with SFrame-protected payload - - +----------------+ +---------------+ - | frame metadata | | | - +-------+--------+ | | - | | frame | - | | | - | | | - | +-------+-------+ - | | - | | - V V - +--------------------------------------+ - | SFrame Encrypt | - +--------------------------------------+ - | | - | | - | V - | +-------+-------+ - | | | - | | | - | | encrypted | - | | frame | - | | | - | | | - | +-------+-------+ - | | - | generic RTP packetize - | | - | +----------------------+--------.....--------+ - | | | | - V V V V - +---------------+ +---------------+ +---------------+ - | SFrame header | | | | | - +---------------+ | | | | - | | | payload 2/N | ... | payload N/N | - | payload 1/N | | | | | - | | | | | | - +---------------+ +---------------+ +---------------+ - - Figure 11: Encryption flow with per-frame encryption for RTP - -Appendix D. Test Vectors - - This section provides a set of test vectors that implementations can - use to verify that they correctly implement SFrame encryption and - decryption. In addition to test vectors for the overall process of - SFrame encryption/decryption, we also provide test vectors for header - encoding/decoding, and for AEAD encryption/decryption using the AES- - CTR construction defined in Section 4.5.1. - - All values are either numeric or byte strings. Numeric values are - represented as hex values, prefixed with 0x. Byte strings are - represented in hex encoding. - - Line breaks and whitespace within values are inserted to conform to - the width requirements of the RFC format. They should be removed - before use. - - These test vectors are also available in JSON format at - [TestVectors]. In the JSON test vectors, numeric values are JSON - numbers and byte string values are JSON strings containing the hex - encoding of the byte strings. - -D.1. Header encoding/decoding - - For each case, we provide: - - * kid: A KID value - - * ctr: A CTR value - - * header: An encoded SFrame header - - An implementation should verify that: - - * Encoding a header with the KID and CTR results in the provided - header value - - * Decoding the provided header value results in the provided KID and - CTR values - - kid: 0x0000000000000000 - ctr: 0x0000000000000000 - header: 00 - - kid: 0x0000000000000000 - ctr: 0x0000000000000001 - header: 01 - - kid: 0x0000000000000000 - ctr: 0x00000000000000ff - header: 08ff - - kid: 0x0000000000000000 - ctr: 0x0000000000000100 - header: 090100 - - kid: 0x0000000000000000 - ctr: 0x000000000000ffff - header: 09ffff - - kid: 0x0000000000000000 - ctr: 0x0000000000010000 - header: 0a010000 - - kid: 0x0000000000000000 - ctr: 0x0000000000ffffff - header: 0affffff - - kid: 0x0000000000000000 - ctr: 0x0000000001000000 - header: 0b01000000 - - kid: 0x0000000000000000 - ctr: 0x00000000ffffffff - header: 0bffffffff - - kid: 0x0000000000000000 - ctr: 0x0000000100000000 - header: 0c0100000000 - - kid: 0x0000000000000000 - ctr: 0x000000ffffffffff - header: 0cffffffffff - - kid: 0x0000000000000000 - ctr: 0x0000010000000000 - header: 0d010000000000 - - kid: 0x0000000000000000 - ctr: 0x0000ffffffffffff - header: 0dffffffffffff - - kid: 0x0000000000000000 - ctr: 0x0001000000000000 - header: 0e01000000000000 - - kid: 0x0000000000000000 - ctr: 0x00ffffffffffffff - header: 0effffffffffffff - - kid: 0x0000000000000000 - ctr: 0x0100000000000000 - header: 0f0100000000000000 - - kid: 0x0000000000000000 - ctr: 0xffffffffffffffff - header: 0fffffffffffffffff - - kid: 0x0000000000000001 - ctr: 0x0000000000000000 - header: 10 - - kid: 0x0000000000000001 - ctr: 0x0000000000000001 - header: 11 - - kid: 0x0000000000000001 - ctr: 0x00000000000000ff - header: 18ff - - kid: 0x0000000000000001 - ctr: 0x0000000000000100 - header: 190100 - - kid: 0x0000000000000001 - ctr: 0x000000000000ffff - header: 19ffff - - kid: 0x0000000000000001 - ctr: 0x0000000000010000 - header: 1a010000 - - kid: 0x0000000000000001 - ctr: 0x0000000000ffffff - header: 1affffff - - kid: 0x0000000000000001 - ctr: 0x0000000001000000 - header: 1b01000000 - - kid: 0x0000000000000001 - ctr: 0x00000000ffffffff - header: 1bffffffff - - kid: 0x0000000000000001 - ctr: 0x0000000100000000 - header: 1c0100000000 - - kid: 0x0000000000000001 - ctr: 0x000000ffffffffff - header: 1cffffffffff - - kid: 0x0000000000000001 - ctr: 0x0000010000000000 - header: 1d010000000000 - - kid: 0x0000000000000001 - ctr: 0x0000ffffffffffff - header: 1dffffffffffff - - kid: 0x0000000000000001 - ctr: 0x0001000000000000 - header: 1e01000000000000 - - kid: 0x0000000000000001 - ctr: 0x00ffffffffffffff - header: 1effffffffffffff - - kid: 0x0000000000000001 - ctr: 0x0100000000000000 - header: 1f0100000000000000 - - kid: 0x0000000000000001 - ctr: 0xffffffffffffffff - header: 1fffffffffffffffff - - kid: 0x00000000000000ff - ctr: 0x0000000000000000 - header: 80ff - - kid: 0x00000000000000ff - ctr: 0x0000000000000001 - header: 81ff - - kid: 0x00000000000000ff - ctr: 0x00000000000000ff - header: 88ffff - - kid: 0x00000000000000ff - ctr: 0x0000000000000100 - header: 89ff0100 - - kid: 0x00000000000000ff - ctr: 0x000000000000ffff - header: 89ffffff - - kid: 0x00000000000000ff - ctr: 0x0000000000010000 - header: 8aff010000 - - kid: 0x00000000000000ff - ctr: 0x0000000000ffffff - header: 8affffffff - - kid: 0x00000000000000ff - ctr: 0x0000000001000000 - header: 8bff01000000 - - kid: 0x00000000000000ff - ctr: 0x00000000ffffffff - header: 8bffffffffff - - kid: 0x00000000000000ff - ctr: 0x0000000100000000 - header: 8cff0100000000 - - kid: 0x00000000000000ff - ctr: 0x000000ffffffffff - header: 8cffffffffffff - - kid: 0x00000000000000ff - ctr: 0x0000010000000000 - header: 8dff010000000000 - - kid: 0x00000000000000ff - ctr: 0x0000ffffffffffff - header: 8dffffffffffffff - - kid: 0x00000000000000ff - ctr: 0x0001000000000000 - header: 8eff01000000000000 - - kid: 0x00000000000000ff - ctr: 0x00ffffffffffffff - header: 8effffffffffffffff - - kid: 0x00000000000000ff - ctr: 0x0100000000000000 - header: 8fff0100000000000000 - - kid: 0x00000000000000ff - ctr: 0xffffffffffffffff - header: 8fffffffffffffffffff - - kid: 0x0000000000000100 - ctr: 0x0000000000000000 - header: 900100 - - kid: 0x0000000000000100 - ctr: 0x0000000000000001 - header: 910100 - - kid: 0x0000000000000100 - ctr: 0x00000000000000ff - header: 980100ff - - kid: 0x0000000000000100 - ctr: 0x0000000000000100 - header: 9901000100 - - kid: 0x0000000000000100 - ctr: 0x000000000000ffff - header: 990100ffff - - kid: 0x0000000000000100 - ctr: 0x0000000000010000 - header: 9a0100010000 - - kid: 0x0000000000000100 - ctr: 0x0000000000ffffff - header: 9a0100ffffff - - kid: 0x0000000000000100 - ctr: 0x0000000001000000 - header: 9b010001000000 - - kid: 0x0000000000000100 - ctr: 0x00000000ffffffff - header: 9b0100ffffffff - - kid: 0x0000000000000100 - ctr: 0x0000000100000000 - header: 9c01000100000000 - - kid: 0x0000000000000100 - ctr: 0x000000ffffffffff - header: 9c0100ffffffffff - - kid: 0x0000000000000100 - ctr: 0x0000010000000000 - header: 9d0100010000000000 - - kid: 0x0000000000000100 - ctr: 0x0000ffffffffffff - header: 9d0100ffffffffffff - - kid: 0x0000000000000100 - ctr: 0x0001000000000000 - header: 9e010001000000000000 - - kid: 0x0000000000000100 - ctr: 0x00ffffffffffffff - header: 9e0100ffffffffffffff - - kid: 0x0000000000000100 - ctr: 0x0100000000000000 - header: 9f01000100000000000000 - - kid: 0x0000000000000100 - ctr: 0xffffffffffffffff - header: 9f0100ffffffffffffffff - - kid: 0x000000000000ffff - ctr: 0x0000000000000000 - header: 90ffff - - kid: 0x000000000000ffff - ctr: 0x0000000000000001 - header: 91ffff - - kid: 0x000000000000ffff - ctr: 0x00000000000000ff - header: 98ffffff - - kid: 0x000000000000ffff - ctr: 0x0000000000000100 - header: 99ffff0100 - - kid: 0x000000000000ffff - ctr: 0x000000000000ffff - header: 99ffffffff - - kid: 0x000000000000ffff - ctr: 0x0000000000010000 - header: 9affff010000 - - kid: 0x000000000000ffff - ctr: 0x0000000000ffffff - header: 9affffffffff - - kid: 0x000000000000ffff - ctr: 0x0000000001000000 - header: 9bffff01000000 - - kid: 0x000000000000ffff - ctr: 0x00000000ffffffff - header: 9bffffffffffff - - kid: 0x000000000000ffff - ctr: 0x0000000100000000 - header: 9cffff0100000000 - - kid: 0x000000000000ffff - ctr: 0x000000ffffffffff - header: 9cffffffffffffff - - kid: 0x000000000000ffff - ctr: 0x0000010000000000 - header: 9dffff010000000000 - - kid: 0x000000000000ffff - ctr: 0x0000ffffffffffff - header: 9dffffffffffffffff - - kid: 0x000000000000ffff - ctr: 0x0001000000000000 - header: 9effff01000000000000 - - kid: 0x000000000000ffff - ctr: 0x00ffffffffffffff - header: 9effffffffffffffffff - - kid: 0x000000000000ffff - ctr: 0x0100000000000000 - header: 9fffff0100000000000000 - - kid: 0x000000000000ffff - ctr: 0xffffffffffffffff - header: 9fffffffffffffffffffff - - kid: 0x0000000000010000 - ctr: 0x0000000000000000 - header: a0010000 - - kid: 0x0000000000010000 - ctr: 0x0000000000000001 - header: a1010000 - - kid: 0x0000000000010000 - ctr: 0x00000000000000ff - header: a8010000ff - - kid: 0x0000000000010000 - ctr: 0x0000000000000100 - header: a90100000100 - - kid: 0x0000000000010000 - ctr: 0x000000000000ffff - header: a9010000ffff - - kid: 0x0000000000010000 - ctr: 0x0000000000010000 - header: aa010000010000 - - kid: 0x0000000000010000 - ctr: 0x0000000000ffffff - header: aa010000ffffff - - kid: 0x0000000000010000 - ctr: 0x0000000001000000 - header: ab01000001000000 - - kid: 0x0000000000010000 - ctr: 0x00000000ffffffff - header: ab010000ffffffff - - kid: 0x0000000000010000 - ctr: 0x0000000100000000 - header: ac0100000100000000 - - kid: 0x0000000000010000 - ctr: 0x000000ffffffffff - header: ac010000ffffffffff - - kid: 0x0000000000010000 - ctr: 0x0000010000000000 - header: ad010000010000000000 - - kid: 0x0000000000010000 - ctr: 0x0000ffffffffffff - header: ad010000ffffffffffff - - kid: 0x0000000000010000 - ctr: 0x0001000000000000 - header: ae01000001000000000000 - - kid: 0x0000000000010000 - ctr: 0x00ffffffffffffff - header: ae010000ffffffffffffff - - kid: 0x0000000000010000 - ctr: 0x0100000000000000 - header: af0100000100000000000000 - - kid: 0x0000000000010000 - ctr: 0xffffffffffffffff - header: af010000ffffffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000000000000 - header: a0ffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000000000001 - header: a1ffffff - - kid: 0x0000000000ffffff - ctr: 0x00000000000000ff - header: a8ffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000000000100 - header: a9ffffff0100 - - kid: 0x0000000000ffffff - ctr: 0x000000000000ffff - header: a9ffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000000010000 - header: aaffffff010000 - - kid: 0x0000000000ffffff - ctr: 0x0000000000ffffff - header: aaffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000001000000 - header: abffffff01000000 - - kid: 0x0000000000ffffff - ctr: 0x00000000ffffffff - header: abffffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000100000000 - header: acffffff0100000000 - - kid: 0x0000000000ffffff - ctr: 0x000000ffffffffff - header: acffffffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000010000000000 - header: adffffff010000000000 - - kid: 0x0000000000ffffff - ctr: 0x0000ffffffffffff - header: adffffffffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0001000000000000 - header: aeffffff01000000000000 - - kid: 0x0000000000ffffff - ctr: 0x00ffffffffffffff - header: aeffffffffffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0100000000000000 - header: afffffff0100000000000000 - - kid: 0x0000000000ffffff - ctr: 0xffffffffffffffff - header: afffffffffffffffffffffff - - kid: 0x0000000001000000 - ctr: 0x0000000000000000 - header: b001000000 - - kid: 0x0000000001000000 - ctr: 0x0000000000000001 - header: b101000000 - - kid: 0x0000000001000000 - ctr: 0x00000000000000ff - header: b801000000ff - - kid: 0x0000000001000000 - ctr: 0x0000000000000100 - header: b9010000000100 - - kid: 0x0000000001000000 - ctr: 0x000000000000ffff - header: b901000000ffff - - kid: 0x0000000001000000 - ctr: 0x0000000000010000 - header: ba01000000010000 - - kid: 0x0000000001000000 - ctr: 0x0000000000ffffff - header: ba01000000ffffff - - kid: 0x0000000001000000 - ctr: 0x0000000001000000 - header: bb0100000001000000 - - kid: 0x0000000001000000 - ctr: 0x00000000ffffffff - header: bb01000000ffffffff - - kid: 0x0000000001000000 - ctr: 0x0000000100000000 - header: bc010000000100000000 - - kid: 0x0000000001000000 - ctr: 0x000000ffffffffff - header: bc01000000ffffffffff - - kid: 0x0000000001000000 - ctr: 0x0000010000000000 - header: bd01000000010000000000 - - kid: 0x0000000001000000 - ctr: 0x0000ffffffffffff - header: bd01000000ffffffffffff - - kid: 0x0000000001000000 - ctr: 0x0001000000000000 - header: be0100000001000000000000 - - kid: 0x0000000001000000 - ctr: 0x00ffffffffffffff - header: be01000000ffffffffffffff - - kid: 0x0000000001000000 - ctr: 0x0100000000000000 - header: bf010000000100000000000000 - - kid: 0x0000000001000000 - ctr: 0xffffffffffffffff - header: bf01000000ffffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000000000000 - header: b0ffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000000000001 - header: b1ffffffff - - kid: 0x00000000ffffffff - ctr: 0x00000000000000ff - header: b8ffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000000000100 - header: b9ffffffff0100 - - kid: 0x00000000ffffffff - ctr: 0x000000000000ffff - header: b9ffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000000010000 - header: baffffffff010000 - - kid: 0x00000000ffffffff - ctr: 0x0000000000ffffff - header: baffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000001000000 - header: bbffffffff01000000 - - kid: 0x00000000ffffffff - ctr: 0x00000000ffffffff - header: bbffffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000100000000 - header: bcffffffff0100000000 - - kid: 0x00000000ffffffff - ctr: 0x000000ffffffffff - header: bcffffffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000010000000000 - header: bdffffffff010000000000 - - kid: 0x00000000ffffffff - ctr: 0x0000ffffffffffff - header: bdffffffffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0001000000000000 - header: beffffffff01000000000000 - - kid: 0x00000000ffffffff - ctr: 0x00ffffffffffffff - header: beffffffffffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0100000000000000 - header: bfffffffff0100000000000000 - - kid: 0x00000000ffffffff - ctr: 0xffffffffffffffff - header: bfffffffffffffffffffffffff - - kid: 0x0000000100000000 - ctr: 0x0000000000000000 - header: c00100000000 - - kid: 0x0000000100000000 - ctr: 0x0000000000000001 - header: c10100000000 - - kid: 0x0000000100000000 - ctr: 0x00000000000000ff - header: c80100000000ff - - kid: 0x0000000100000000 - ctr: 0x0000000000000100 - header: c901000000000100 - - kid: 0x0000000100000000 - ctr: 0x000000000000ffff - header: c90100000000ffff - - kid: 0x0000000100000000 - ctr: 0x0000000000010000 - header: ca0100000000010000 - - kid: 0x0000000100000000 - ctr: 0x0000000000ffffff - header: ca0100000000ffffff - - kid: 0x0000000100000000 - ctr: 0x0000000001000000 - header: cb010000000001000000 - - kid: 0x0000000100000000 - ctr: 0x00000000ffffffff - header: cb0100000000ffffffff - - kid: 0x0000000100000000 - ctr: 0x0000000100000000 - header: cc01000000000100000000 - - kid: 0x0000000100000000 - ctr: 0x000000ffffffffff - header: cc0100000000ffffffffff - - kid: 0x0000000100000000 - ctr: 0x0000010000000000 - header: cd0100000000010000000000 - - kid: 0x0000000100000000 - ctr: 0x0000ffffffffffff - header: cd0100000000ffffffffffff - - kid: 0x0000000100000000 - ctr: 0x0001000000000000 - header: ce010000000001000000000000 - - kid: 0x0000000100000000 - ctr: 0x00ffffffffffffff - header: ce0100000000ffffffffffffff - - kid: 0x0000000100000000 - ctr: 0x0100000000000000 - header: cf01000000000100000000000000 - - kid: 0x0000000100000000 - ctr: 0xffffffffffffffff - header: cf0100000000ffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000000000000 - header: c0ffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000000000001 - header: c1ffffffffff - - kid: 0x000000ffffffffff - ctr: 0x00000000000000ff - header: c8ffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000000000100 - header: c9ffffffffff0100 - - kid: 0x000000ffffffffff - ctr: 0x000000000000ffff - header: c9ffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000000010000 - header: caffffffffff010000 - - kid: 0x000000ffffffffff - ctr: 0x0000000000ffffff - header: caffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000001000000 - header: cbffffffffff01000000 - - kid: 0x000000ffffffffff - ctr: 0x00000000ffffffff - header: cbffffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000100000000 - header: ccffffffffff0100000000 - - kid: 0x000000ffffffffff - ctr: 0x000000ffffffffff - header: ccffffffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000010000000000 - header: cdffffffffff010000000000 - - kid: 0x000000ffffffffff - ctr: 0x0000ffffffffffff - header: cdffffffffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0001000000000000 - header: ceffffffffff01000000000000 - - kid: 0x000000ffffffffff - ctr: 0x00ffffffffffffff - header: ceffffffffffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0100000000000000 - header: cfffffffffff0100000000000000 - - kid: 0x000000ffffffffff - ctr: 0xffffffffffffffff - header: cfffffffffffffffffffffffffff - - kid: 0x0000010000000000 - ctr: 0x0000000000000000 - header: d0010000000000 - - kid: 0x0000010000000000 - ctr: 0x0000000000000001 - header: d1010000000000 - - kid: 0x0000010000000000 - ctr: 0x00000000000000ff - header: d8010000000000ff - - kid: 0x0000010000000000 - ctr: 0x0000000000000100 - header: d90100000000000100 - - kid: 0x0000010000000000 - ctr: 0x000000000000ffff - header: d9010000000000ffff - - kid: 0x0000010000000000 - ctr: 0x0000000000010000 - header: da010000000000010000 - - kid: 0x0000010000000000 - ctr: 0x0000000000ffffff - header: da010000000000ffffff - - kid: 0x0000010000000000 - ctr: 0x0000000001000000 - header: db01000000000001000000 - - kid: 0x0000010000000000 - ctr: 0x00000000ffffffff - header: db010000000000ffffffff - - kid: 0x0000010000000000 - ctr: 0x0000000100000000 - header: dc0100000000000100000000 - - kid: 0x0000010000000000 - ctr: 0x000000ffffffffff - header: dc010000000000ffffffffff - - kid: 0x0000010000000000 - ctr: 0x0000010000000000 - header: dd010000000000010000000000 - - kid: 0x0000010000000000 - ctr: 0x0000ffffffffffff - header: dd010000000000ffffffffffff - - kid: 0x0000010000000000 - ctr: 0x0001000000000000 - header: de01000000000001000000000000 - - kid: 0x0000010000000000 - ctr: 0x00ffffffffffffff - header: de010000000000ffffffffffffff - - kid: 0x0000010000000000 - ctr: 0x0100000000000000 - header: df0100000000000100000000000000 - - kid: 0x0000010000000000 - ctr: 0xffffffffffffffff - header: df010000000000ffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000000000000 - header: d0ffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000000000001 - header: d1ffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x00000000000000ff - header: d8ffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000000000100 - header: d9ffffffffffff0100 - - kid: 0x0000ffffffffffff - ctr: 0x000000000000ffff - header: d9ffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000000010000 - header: daffffffffffff010000 - - kid: 0x0000ffffffffffff - ctr: 0x0000000000ffffff - header: daffffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000001000000 - header: dbffffffffffff01000000 - - kid: 0x0000ffffffffffff - ctr: 0x00000000ffffffff - header: dbffffffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000100000000 - header: dcffffffffffff0100000000 - - kid: 0x0000ffffffffffff - ctr: 0x000000ffffffffff - header: dcffffffffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000010000000000 - header: ddffffffffffff010000000000 - - kid: 0x0000ffffffffffff - ctr: 0x0000ffffffffffff - header: ddffffffffffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0001000000000000 - header: deffffffffffff01000000000000 - - kid: 0x0000ffffffffffff - ctr: 0x00ffffffffffffff - header: deffffffffffffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0100000000000000 - header: dfffffffffffff0100000000000000 - - kid: 0x0000ffffffffffff - ctr: 0xffffffffffffffff - header: dfffffffffffffffffffffffffffff - - kid: 0x0001000000000000 - ctr: 0x0000000000000000 - header: e001000000000000 - - kid: 0x0001000000000000 - ctr: 0x0000000000000001 - header: e101000000000000 - - kid: 0x0001000000000000 - ctr: 0x00000000000000ff - header: e801000000000000ff - - kid: 0x0001000000000000 - ctr: 0x0000000000000100 - header: e9010000000000000100 - - kid: 0x0001000000000000 - ctr: 0x000000000000ffff - header: e901000000000000ffff - - kid: 0x0001000000000000 - ctr: 0x0000000000010000 - header: ea01000000000000010000 - - kid: 0x0001000000000000 - ctr: 0x0000000000ffffff - header: ea01000000000000ffffff - - kid: 0x0001000000000000 - ctr: 0x0000000001000000 - header: eb0100000000000001000000 - - kid: 0x0001000000000000 - ctr: 0x00000000ffffffff - header: eb01000000000000ffffffff - - kid: 0x0001000000000000 - ctr: 0x0000000100000000 - header: ec010000000000000100000000 - - kid: 0x0001000000000000 - ctr: 0x000000ffffffffff - header: ec01000000000000ffffffffff - - kid: 0x0001000000000000 - ctr: 0x0000010000000000 - header: ed01000000000000010000000000 - - kid: 0x0001000000000000 - ctr: 0x0000ffffffffffff - header: ed01000000000000ffffffffffff - - kid: 0x0001000000000000 - ctr: 0x0001000000000000 - header: ee0100000000000001000000000000 - - kid: 0x0001000000000000 - ctr: 0x00ffffffffffffff - header: ee01000000000000ffffffffffffff - - kid: 0x0001000000000000 - ctr: 0x0100000000000000 - header: ef010000000000000100000000000000 - - kid: 0x0001000000000000 - ctr: 0xffffffffffffffff - header: ef01000000000000ffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000000000000 - header: e0ffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000000000001 - header: e1ffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x00000000000000ff - header: e8ffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000000000100 - header: e9ffffffffffffff0100 - - kid: 0x00ffffffffffffff - ctr: 0x000000000000ffff - header: e9ffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000000010000 - header: eaffffffffffffff010000 - - kid: 0x00ffffffffffffff - ctr: 0x0000000000ffffff - header: eaffffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000001000000 - header: ebffffffffffffff01000000 - - kid: 0x00ffffffffffffff - ctr: 0x00000000ffffffff - header: ebffffffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000100000000 - header: ecffffffffffffff0100000000 - - kid: 0x00ffffffffffffff - ctr: 0x000000ffffffffff - header: ecffffffffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000010000000000 - header: edffffffffffffff010000000000 - - kid: 0x00ffffffffffffff - ctr: 0x0000ffffffffffff - header: edffffffffffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0001000000000000 - header: eeffffffffffffff01000000000000 - - kid: 0x00ffffffffffffff - ctr: 0x00ffffffffffffff - header: eeffffffffffffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0100000000000000 - header: efffffffffffffff0100000000000000 - - kid: 0x00ffffffffffffff - ctr: 0xffffffffffffffff - header: efffffffffffffffffffffffffffffff - - kid: 0x0100000000000000 - ctr: 0x0000000000000000 - header: f00100000000000000 - - kid: 0x0100000000000000 - ctr: 0x0000000000000001 - header: f10100000000000000 - - kid: 0x0100000000000000 - ctr: 0x00000000000000ff - header: f80100000000000000ff - - kid: 0x0100000000000000 - ctr: 0x0000000000000100 - header: f901000000000000000100 - - kid: 0x0100000000000000 - ctr: 0x000000000000ffff - header: f90100000000000000ffff - - kid: 0x0100000000000000 - ctr: 0x0000000000010000 - header: fa0100000000000000010000 - - kid: 0x0100000000000000 - ctr: 0x0000000000ffffff - header: fa0100000000000000ffffff - - kid: 0x0100000000000000 - ctr: 0x0000000001000000 - header: fb010000000000000001000000 - - kid: 0x0100000000000000 - ctr: 0x00000000ffffffff - header: fb0100000000000000ffffffff - - kid: 0x0100000000000000 - ctr: 0x0000000100000000 - header: fc01000000000000000100000000 - - kid: 0x0100000000000000 - ctr: 0x000000ffffffffff - header: fc0100000000000000ffffffffff - - kid: 0x0100000000000000 - ctr: 0x0000010000000000 - header: fd0100000000000000010000000000 - - kid: 0x0100000000000000 - ctr: 0x0000ffffffffffff - header: fd0100000000000000ffffffffffff - - kid: 0x0100000000000000 - ctr: 0x0001000000000000 - header: fe010000000000000001000000000000 - - kid: 0x0100000000000000 - ctr: 0x00ffffffffffffff - header: fe0100000000000000ffffffffffffff - - kid: 0x0100000000000000 - ctr: 0x0100000000000000 - header: ff010000000000000001000000000000 - 00 - - kid: 0x0100000000000000 - ctr: 0xffffffffffffffff - header: ff0100000000000000ffffffffffffff - ff - - kid: 0xffffffffffffffff - ctr: 0x0000000000000000 - header: f0ffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000000000000001 - header: f1ffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x00000000000000ff - header: f8ffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000000000000100 - header: f9ffffffffffffffff0100 - - kid: 0xffffffffffffffff - ctr: 0x000000000000ffff - header: f9ffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000000000010000 - header: faffffffffffffffff010000 - - kid: 0xffffffffffffffff - ctr: 0x0000000000ffffff - header: faffffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000000001000000 - header: fbffffffffffffffff01000000 - - kid: 0xffffffffffffffff - ctr: 0x00000000ffffffff - header: fbffffffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000000100000000 - header: fcffffffffffffffff0100000000 - - kid: 0xffffffffffffffff - ctr: 0x000000ffffffffff - header: fcffffffffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000010000000000 - header: fdffffffffffffffff010000000000 - - kid: 0xffffffffffffffff - ctr: 0x0000ffffffffffff - header: fdffffffffffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0001000000000000 - header: feffffffffffffffff01000000000000 - - kid: 0xffffffffffffffff - ctr: 0x00ffffffffffffff - header: feffffffffffffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0100000000000000 - header: ffffffffffffffffff01000000000000 - 00 - - kid: 0xffffffffffffffff - ctr: 0xffffffffffffffff - header: ffffffffffffffffffffffffffffffff - ff - -D.2. AEAD encryption/decryption using AES-CTR and HMAC - - For each case, we provide: - - * cipher_suite: The index of the cipher suite in use (see - Section 8.1) - - * key: The key input to encryption/decryption - - * enc_key: The encryption subkey produced by the derive_subkeys() - algorithm - - * auth_key: The encryption subkey produced by the derive_subkeys() - algorithm - - * nonce: The nonce input to encryption/decryption - - * aad: The aad input to encryption/decryption - - * pt: The plaintext - - * ct: The ciphertext - - An implementation should verify that the following are true, where - AEAD.Encrypt and AEAD.Decrypt are as defined in Section 4.5.1: - - * AEAD.Encrypt(key, nonce, aad, pt) == ct - - * AEAD.Decrypt(key, nonce, aad, ct) == pt - - The other values in the test vector are intermediate values provided - to facilitate debugging of test failures. - - cipher_suite: 0x0001 - key: 000102030405060708090a0b0c0d0e0f - 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - enc_key: 000102030405060708090a0b0c0d0e0f - auth_key: 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - nonce: 101112131415161718191a1b - aad: 4945544620534672616d65205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 6339af04ada1d064688a442b8dc69d5b - 6bfa40f4bef0583e8081069cc60705 - - cipher_suite: 0x0002 - key: 000102030405060708090a0b0c0d0e0f - 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - enc_key: 000102030405060708090a0b0c0d0e0f - auth_key: 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - nonce: 101112131415161718191a1b - aad: 4945544620534672616d65205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 6339af04ada1d064688a442b8dc69d5b - 6bfa40f4be6e93b7da076927bb - - cipher_suite: 0x0003 - key: 000102030405060708090a0b0c0d0e0f - 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - enc_key: 000102030405060708090a0b0c0d0e0f - auth_key: 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - nonce: 101112131415161718191a1b - aad: 4945544620534672616d65205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 6339af04ada1d064688a442b8dc69d5b - 6bfa40f4be09480509 - -D.3. SFrame encryption/decryption - - For each case, we provide: - - * cipher_suite: The index of the cipher suite in use (see - Section 8.1) - - * kid: A KID value - - * ctr: A CTR value - - * base_key: The base_key input to the derive_key_salt algorithm - - * sframe_key_label: The label used to derive sframe_key in the - derive_key_salt algorithm - - * sframe_salt_label: The label used to derive sframe_salt in the - derive_key_salt algorithm - - * sframe_secret: The sframe_secret variable in the derive_key_salt - algorithm - - * sframe_key: The sframe_key value produced by the derive_key_salt - algorithm - - * sframe_salt: The sframe_salt value produced by the derive_key_salt - algorithm - - * metadata: The metadata input to the SFrame encrypt algorithm - - * pt: The plaintext - - * ct: The SFrame ciphertext - - An implementation should verify that the following are true, where - encrypt and decrypt are as defined in Section 4.4, using an SFrame - context initialized with base_key assigned to kid: - - * encrypt(ctr, kid, metadata, plaintext) == ct - - * decrypt(metadata, ct) == pt - - The other values in the test vector are intermediate values provided - to facilitate debugging of test failures. - - cipher_suite: 0x0001 - kid: 0x0000000000000123 - ctr: 0x0000000000004567 - base_key: 000102030405060708090a0b0c0d0e0f - sframe_key_label: 534672616d6520312e30205365637265 - 74206b65792000000000000001230001 - sframe_salt_label: 534672616d6520312e30205365637265 - 742073616c7420000000000000012300 - 01 - sframe_secret: d926952ca8b7ec4a95941d1ada3a5203 - ceff8cceee34f574d23909eb314c40c0 - sframe_key: 3f7d9a7c83ae8e1c8a11ae695ab59314 - b367e359fadac7b9c46b2bc6f81f46e1 - 6b96f0811868d59402b7e870102720b3 - sframe_salt: 50b29329a04dc0f184ac3168 - metadata: 4945544620534672616d65205747 - nonce: 50b29329a04dc0f184ac740f - aad: 99012345674945544620534672616d65 - 205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 9901234567449408b6f490086165b9d6 - f62b24ae1a59a56486b4ae8ed036b889 - 12e24f11 - - cipher_suite: 0x0002 - kid: 0x0000000000000123 - ctr: 0x0000000000004567 - base_key: 000102030405060708090a0b0c0d0e0f - sframe_key_label: 534672616d6520312e30205365637265 - 74206b65792000000000000001230002 - sframe_salt_label: 534672616d6520312e30205365637265 - 742073616c7420000000000000012300 - 02 - sframe_secret: d926952ca8b7ec4a95941d1ada3a5203 - ceff8cceee34f574d23909eb314c40c0 - sframe_key: e2ec5c797540310483b16bf6e7a570d2 - a27d192fe869c7ccd8584a8d9dab9154 - 9fbe553f5113461ec6aa83bf3865553e - sframe_salt: e68ac8dd3d02fbcd368c5577 - metadata: 4945544620534672616d65205747 - nonce: e68ac8dd3d02fbcd368c1010 - aad: 99012345674945544620534672616d65 - 205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 99012345673f31438db4d09434e43afa - 0f8a2f00867a2be085046a9f5cb4f101 - d607 - - cipher_suite: 0x0003 - kid: 0x0000000000000123 - ctr: 0x0000000000004567 - base_key: 000102030405060708090a0b0c0d0e0f - sframe_key_label: 534672616d6520312e30205365637265 - 74206b65792000000000000001230003 - sframe_salt_label: 534672616d6520312e30205365637265 - 742073616c7420000000000000012300 - 03 - sframe_secret: d926952ca8b7ec4a95941d1ada3a5203 - ceff8cceee34f574d23909eb314c40c0 - sframe_key: 2c5703089cbb8c583475e4fc461d97d1 - 8809df79b6d550f78eb6d50ffa80d892 - 11d57909934f46f5405e38cd583c69fe - sframe_salt: 38c16e4f5159700c00c7f350 - metadata: 4945544620534672616d65205747 - nonce: 38c16e4f5159700c00c7b637 - aad: 99012345674945544620534672616d65 - 205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 990123456717fc8af28a5a695afcfc6c - 8df6358a17e26b2fcb3bae32e443 - - cipher_suite: 0x0004 - kid: 0x0000000000000123 - ctr: 0x0000000000004567 - base_key: 000102030405060708090a0b0c0d0e0f - sframe_key_label: 534672616d6520312e30205365637265 - 74206b65792000000000000001230004 - sframe_salt_label: 534672616d6520312e30205365637265 - 742073616c7420000000000000012300 - 04 - sframe_secret: d926952ca8b7ec4a95941d1ada3a5203 - ceff8cceee34f574d23909eb314c40c0 - sframe_key: d34f547f4ca4f9a7447006fe7fcbf768 - sframe_salt: 75234edefe07819026751816 - metadata: 4945544620534672616d65205747 - nonce: 75234edefe07819026755d71 - aad: 99012345674945544620534672616d65 - 205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 9901234567b7412c2513a1b66dbb4884 - 1bbaf17f598751176ad847681a69c6d0 - b091c07018ce4adb34eb - - cipher_suite: 0x0005 - kid: 0x0000000000000123 - ctr: 0x0000000000004567 - base_key: 000102030405060708090a0b0c0d0e0f - sframe_key_label: 534672616d6520312e30205365637265 - 74206b65792000000000000001230005 - sframe_salt_label: 534672616d6520312e30205365637265 - 742073616c7420000000000000012300 - 05 - sframe_secret: 0fc3ea6de6aac97a35f194cf9bed94d4 - b5230f1cb45a785c9fe5dce9c188938a - b6ba005bc4c0a19181599e9d1bcf7b74 - aca48b60bf5e254e546d809313e083a3 - sframe_key: d3e27b0d4a5ae9e55df01a70e6d4d28d - 969b246e2936f4b7a5d9b494da6b9633 - sframe_salt: 84991c167b8cd23c93708ec7 - metadata: 4945544620534672616d65205747 - nonce: 84991c167b8cd23c9370cba0 - aad: 99012345674945544620534672616d65 - 205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 990123456794f509d36e9beacb0e261d - 99c7d1e972f1fed787d4049f17ca2135 - 3c1cc24d56ceabced279 - -Contributors - - Frederic Jacobs - Apple - Email: frederic.jacobs@apple.com - - - Marta Mularczyk - Amazon - Email: mulmarta@amazon.com - - - Suhas Nandakumar - Cisco - Email: snandaku@cisco.com - - - Tomas Rigaux - Cisco - Email: trigaux@cisco.com - - - Raphael Robert - Phoenix R&D - Email: ietf@raphaelrobert.com - - -Authors' Addresses - - Emad Omara - Apple - Email: eomara@apple.com - - - Justin Uberti - Google - Email: juberti@google.com - - - Sergio Garcia Murillo - CoSMo Software - Email: sergio.garcia.murillo@cosmosoftware.io - - - Richard L. Barnes (editor) - Cisco - Email: rlb@ipv.sx - - - Youenn Fablet - Apple - Email: youenn@apple.com diff --git a/secdir/draft-ietf-sframe-enc.txt b/secdir/draft-ietf-sframe-enc.txt deleted file mode 100644 index 05f894a..0000000 --- a/secdir/draft-ietf-sframe-enc.txt +++ /dev/null @@ -1,3193 +0,0 @@ - - - - -Network Working Group E. Omara -Internet-Draft Apple -Intended status: Standards Track J. Uberti -Expires: 1 September 2024 Google - S. Murillo - CoSMo Software - R. L. Barnes, Ed. - Cisco - Y. Fablet - Apple - 29 February 2024 - - - Secure Frame (SFrame) - draft-ietf-sframe-enc-latest - -Abstract - - This document describes the Secure Frame (SFrame) end-to-end - encryption and authentication mechanism for media frames in a - multiparty conference call, in which central media servers (selective - forwarding units or SFUs) can access the media metadata needed to - make forwarding decisions without having access to the actual media. - - The proposed mechanism differs from the Secure Real-Time Protocol - (SRTP) in that it is independent of RTP (thus compatible with non-RTP - media transport) and can be applied to whole media frames in order to - be more bandwidth efficient. - -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://sframe- - wg.github.io/sframe/draft-ietf-sframe-enc.html. Status information - for this document may be found at https://datatracker.ietf.org/doc/ - draft-ietf-sframe-enc/. - - Discussion of this document takes place on the Secure Media Frames - Working Group mailing list (mailto:sframe@ietf.org), which is - archived at https://mailarchive.ietf.org/arch/browse/sframe/. - Subscribe at https://www.ietf.org/mailman/listinfo/sframe/. - - Source for this draft and an issue tracker can be found at - https://github.com/sframe-wg/sframe. - -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 1 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. Goals - 4. SFrame - 4.1. Application Context - 4.2. SFrame Ciphertext - 4.3. SFrame Header - 4.4. Encryption Schema - 4.4.1. Key Selection - 4.4.2. Key Derivation - 4.4.3. Encryption - 4.4.4. Decryption - 4.5. Cipher Suites - 4.5.1. AES-CTR with SHA2 - 5. Key Management - 5.1. Sender Keys - 5.2. MLS - 6. Media Considerations - 6.1. Selective Forwarding Units - 6.1.1. LastN and RTP stream reuse - 6.1.2. Simulcast - 6.1.3. SVC - 6.2. Video Key Frames - 6.3. Partial Decoding - 7. Security Considerations - 7.1. No Header Confidentiality - 7.2. No Per-Sender Authentication - 7.3. Key Management - 7.4. Replay - 7.5. Risks due to Short Tags - 8. IANA Considerations - 8.1. SFrame Cipher Suites - 9. Application Responsibilities - 9.1. Header Value Uniqueness - 9.2. Key Management Framework - 9.3. Anti-Replay - 9.4. Metadata - 10. References - 10.1. Normative References - 10.2. Informative References - Appendix A. Acknowledgements - Appendix B. Example API - Appendix C. Overhead Analysis - C.1. Assumptions - C.2. Audio - C.3. Video - C.4. Conferences - C.5. SFrame over RTP - Appendix D. Test Vectors - D.1. Header encoding/decoding - D.2. AEAD encryption/decryption using AES-CTR and HMAC - D.3. SFrame encryption/decryption - Contributors - Authors' Addresses - -1. Introduction - - Modern multi-party video call systems use Selective Forwarding Unit - (SFU) servers to efficiently route media streams to call endpoints - based on factors such as available bandwidth, desired video size, - codec support, and other factors. An SFU typically does not need - access to the media content of the conference, allowing for the media - to be "end-to-end" encrypted so that it cannot be decrypted by the - SFU. In order for the SFU to work properly, though, it usually needs - to be able to access RTP metadata and RTCP feedback messages, which - is not possible if all RTP/RTCP traffic is end-to-end encrypted. - - As such, two layers of encryption and authentication are required: - - 1. Hop-by-hop (HBH) encryption of media, metadata, and feedback - messages between the the endpoints and SFU - - 2. End-to-end (E2E) encryption (E2EE) of media between the endpoints - - The Secure Real-Time Protocol (SRTP) is already widely used for HBH - encryption [RFC3711]. The SRTP "double encryption" scheme defines a - way to do E2E encryption in SRTP [RFC8723]. Unfortunately, this - scheme has poor efficiency and high complexity, and its entanglement - with RTP makes it unworkable in several realistic SFU scenarios. - - This document proposes a new E2EE protection scheme known as SFrame, - specifically designed to work in group conference calls with SFUs. - SFrame is a general encryption framing that can be used to protect - media payloads, agnostic of transport. - -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. - - MAC: Message Authentication Code - - E2EE: End to End Encryption - - HBH: Hop By Hop - - We use "Selective Forwarding Unit (SFU)" and "media stream" in a less - formal sense than in [RFC7656]. An SFU is a selective switching - function for media payloads, and a media stream a sequence of media - payloads, in both cases regardless of whether those media payloads - are transported over RTP or some other protocol. - -3. Goals - - SFrame is designed to be a suitable E2EE protection scheme for - conference call media in a broad range of scenarios, as outlined by - the following goals: - - 1. Provide a secure E2EE mechanism for audio and video in conference - calls that can be used with arbitrary SFU servers. - - 2. Decouple media encryption from key management to allow SFrame to - be used with an arbitrary key management system. - - 3. Minimize packet expansion to allow successful conferencing in as - many network conditions as possible. - - 4. Independence from the underlying transport, including use in non- - RTP transports, e.g., WebTransport [I-D.ietf-webtrans-overview]. - - 5. When used with RTP and its associated error resilience - mechanisms, i.e., RTX and FEC, require no special handling for - RTX and FEC packets. - - 6. Minimize the changes needed in SFU servers. - - 7. Minimize the changes needed in endpoints. - - 8. Work with the most popular audio and video codecs used in - conferencing scenarios. - -4. SFrame - - This document defines an encryption mechanism that provides effective - E2EE, is simple to implement, has no dependencies on RTP, and - minimizes encryption bandwidth overhead. This section describes how - the mechanism works, including details of how applications utilize - SFrame for media protection, as well as the actual mechanics of E2EE - for protecting media. - -4.1. Application Context - - SFrame is a general encryption framing, intended to be used as an - E2EE layer over an underlying HBH-encrypted transport such as SRTP or - QUIC [RFC3711][I-D.ietf-moq-transport]. - - The scale at which SFrame encryption is applied to media determines - the overall amount of overhead that SFrame adds to the media stream, - as well as the engineering complexity involved in integrating SFrame - into a particular environment. Two patterns are common: Either using - SFrame to encrypt whole media frames (per-frame) or individual - transport-level media payloads (per-packet). - - For example, Figure 1 shows a typical media sender stack that takes - media from some source, encodes it into frames, divides those frames - into media packets, and then sends those payloads in SRTP packets. - The receiver stack performs the reverse operations, reassembling - frames from SRTP packets and decoding. Arrows indicate two different - ways that SFrame protection could be integrated into this media - stack, to encrypt whole frames or individual media packets. - - Applying SFrame per-frame in this system offers higher efficiency, - but may require a more complex integration in environments where - depacketization relies on the content of media packets. Applying - SFrame per-packet avoids this complexity, at the cost of higher - bandwidth consumption. Some quantitative discussion of these trade- - offs is provided in Appendix C. - - As noted above, however, SFrame is a general media encapsulation, and - can be applied in other scenarios. The important thing is that the - sender and receivers of an SFrame-encrypted object agree on that - object's semantics. SFrame does not provide this agreement; it must - be arranged by the application. - - +------------------------------------------------------+ - | | - | +--------+ +-------------+ +-----------+ | - .-. | | | | | | HBH | | -| | | | Encode |----->| Packetize |----->| Protect |----------+ - '+' | | | ^ | | ^ | | | | - /|\ | +--------+ | +-------------+ | +-----------+ | | -/ + \ | | | ^ | | - / \ | SFrame SFrame | | | -/ \ | Protect Protect | | | -Alice | (per-frame) (per-packet) | | | - | ^ ^ | | | - | | | | | | - +---------------|-------------------|---------|--------+ | - | | | v - | | | +------+-+ - | E2E Key | HBH Key | Media | - +---- Management ---+ Management | Server | - | | | +------+-+ - | | | | - +---------------|-------------------|---------|--------+ | - | | | | | | - | V V | | | - .-. | SFrame SFrame | | | -| | | Unprotect Unprotect | | | - '+' | (per-frame) (per-packet) | | | - /|\ | | | V | | -/ + \ | +--------+ | +-------------+ | +-----------+ | | - / \ | | | V | | V | HBH | | | -/ \ | | Decode |<-----| Depacketize |<-----| Unprotect |<---------+ - Bob | | | | | | | | - | +--------+ +-------------+ +-----------+ | - | | - +------------------------------------------------------+ - - Figure 1 - - Like SRTP, SFrame does not define how the keys used for SFrame are - exchanged by the parties in the conference. Keys for SFrame might be - distributed over an existing E2E-secure channel (see Section 5.1), or - derived from an E2E-secure shared secret (see Section 5.2). The key - management system MUST ensure that each key used for encrypting media - is used by exactly one media sender, in order to avoid reuse of - nonces. - -4.2. SFrame Ciphertext - - An SFrame ciphertext comprises an SFrame header followed by the - output of an AEAD encryption of the plaintext [RFC5116], with the - header provided as additional authenticated data (AAD). - - The SFrame header is a variable-length structure described in detail - in Section 4.3. The structure of the encrypted data and - authentication tag are determined by the AEAD algorithm in use. - - +-+----+-+----+--------------------+--------------------+<-+ - |K|KLEN|C|CLEN| Key ID | Counter | | - +->+-+----+-+----+--------------------+--------------------+ | - | | | | - | | | | - | | | | - | | | | - | | Encrypted Data | | - | | | | - | | | | - | | | | - | | | | - +->+-------------------------------------------------------+<-+ - | | Authentication Tag | | - | +-------------------------------------------------------+ | - | | - | | - +--- Encrypted Portion Authenticated Portion ---+ - - When SFrame is applied per-packet, the payload of each packet will be - an SFrame ciphertext. When SFrame is applied per-frame, the SFrame - ciphertext representing an encrypted frame will span several packets, - with the header appearing in the first packet and the authentication - tag in the last packet. It is the responsibility of the application - to reassemble an encrypted frame from individual packets, accounting - for packet loss and reordering as necessary. - -4.3. SFrame Header - - The SFrame header specifies two values from which encryption - parameters are derived: - - * A Key ID (KID) that determines which encryption key should be used - - * A counter (CTR) that is used to construct the nonce for the - encryption - - Applications MUST ensure that each (KID, CTR) combination is used for - exactly one SFrame encryption operation. A typical approach to - achieving this guarantee is outlined in Section 9.1. - - Config Byte - | - .-----' '-----. - | | - 0 1 2 3 4 5 6 7 - +-+-+-+-+-+-+-+-+------------+------------+ - |X| K |Y| C | KID... | CTR... | - +-+-+-+-+-+-+-+-+------------+------------+ - - Figure 2: SFrame header - - The SFrame Header has the overall structure shown in Figure 2. The - first byte is a "config byte", with the following fields: - - Extended Key Id Flag (X, 1 bit): Indicates if the K field contains - the key id or the Key ID length. - - Key or Key Length (K, 3 bits): If the X flag is set to 0, this field - contains the Key ID. If the X flag is set to 1, then it contains - the length of the Key ID, minus one. - - Extended Counter Flag (Y, 1 bit): Indicates if the C field contains - the counter or the counter length. - - Counter or Counter Length (C, 3 bits): This field contains the - counter (CTR) if the Y flag is set to 0, or the counter length, - minus one, if set to 1. - - The Key ID and Counter fields are encoded as compact unsigned - integers in network (big-endian) byte order. If the value of one of - these fields is in the range 0-7, then the value is carried in the - corresponding bits of the config byte (K or C) and the corresponding - flag (X or Y) is set to zero. Otherwise, the value MUST be encoded - with the minimum number of bytes required and appended after the - configuration byte, with the Key ID first and Counter second. The - header field (K or C) is set to the number of bytes in the encoded - value, minus one. The value 000 represents a length of 1, 001 a - length of 2, etc. This allows a 3-bit length field to represent the - value lengths 1-8. - - The SFrame header can thus take one of the four forms shown in - Figure 3, depending on which of the X and Y flags are set. - - KID < 8, CTR < 8: - +-+-----+-+-----+ - |0| KID |0| CTR | - +-+-----+-+-----+ - - KID < 8, CTR >= 8: - +-+-----+-+-----+------------------------+ - |0| KID |1|CLEN | CTR... (length=CLEN) | - +-+-----+-+-----+------------------------+ - - KID >= 8, CTR < 8: - +-+-----+-+-----+------------------------+ - |1|KLEN |0| CTR | KID... (length=KLEN) | - +-+-----+-+-----+------------------------+ - - KID >= 8, CTR >= 8: - +-+-----+-+-----+------------------------+------------------------+ - |1|KLEN |1|CLEN | KID... (length=KLEN) | CTR... (length=CLEN) | - +-+-----+-+-----+------------------------+------------------------+ - - Figure 3: Forms of Encoded SFrame Header - -4.4. Encryption Schema - - SFrame encryption uses an AEAD encryption algorithm and hash function - defined by the cipher suite in use (see Section 4.5). We will refer - to the following aspects of the AEAD and the hash algorithm below: - - * AEAD.Encrypt and AEAD.Decrypt - The encryption and decryption - functions for the AEAD. We follow the convention of RFC 5116 - [RFC5116] and consider the authentication tag part of the - ciphertext produced by AEAD.Encrypt (as opposed to a separate - field as in SRTP [RFC3711]). - - * AEAD.Nk - The size in bytes of a key for the encryption algorithm - - * AEAD.Nn - The size in bytes of a nonce for the encryption - algorithm - - * AEAD.Nt - The overhead in bytes of the encryption algorithm - (typically the size of a "tag" that is added to the plaintext) - - * AEAD.Nka - For cipher suites using the compound AEAD described in - Section 4.5.1, the size in bytes of a key for the underlying AES- - CTR algorithm - - * Hash.Nh - The size in bytes of the output of the hash function - -4.4.1. Key Selection - - Each SFrame encryption or decryption operation is premised on a - single secret base_key, which is labeled with an integer KID value - signaled in the SFrame header. - - The sender and receivers need to agree on which base_key should be - used for a given KID. Moreover, senders and receivers need to agree - on whether a base_key will be used for encryption or decryption only. - The process for provisioning base_key values and their KID values is - beyond the scope of this specification, but its security properties - will bound the assurances that SFrame provides. For example, if - SFrame is used to provide E2E security against intermediary media - nodes, then SFrame keys need to be negotiated in a way that does not - make them accessible to these intermediaries. - - For each known KID value, the client stores the corresponding - symmetric key base_key. For keys that can be used for encryption, - the client also stores the next counter value CTR to be used when - encrypting (initially 0). - - When encrypting a plaintext, the application specifies which KID is - to be used, and the counter is incremented after successful - encryption. When decrypting, the base_key for decryption is selected - from the available keys using the KID value in the SFrame Header. - - A given base_key MUST NOT be used for encryption by multiple senders. - Such reuse would result in multiple encrypted frames being generated - with the same (key, nonce) pair, which harms the protections provided - by many AEAD algorithms. Implementations MUST mark each base_key as - usable for encryption or decryption, never both. - - Note that the set of available keys might change over the lifetime of - a real-time session. In such cases, the client will need to manage - key usage to avoid media loss due to a key being used to encrypt - before all receivers are able to use it to decrypt. For example, an - application may make decryption-only keys available immediately, but - delay the use of keys for encryption until (a) all receivers have - acknowledged receipt of the new key or (b) a timeout expires. - -4.4.2. Key Derivation - - SFrame encryption and decryption use a key and salt derived from the - base_key associated to a KID. Given a base_key value, the key and - salt are derived using HKDF [RFC5869] as follows: - - def derive_key_salt(KID, base_key): - sframe_secret = HKDF-Extract("", base_key) - - sframe_key_label = "SFrame 1.0 Secret key " + KID + cipher_suite - sframe_key = HKDF-Expand(sframe_secret, info, AEAD.Nk) - - sframe_salt_label = "SFrame 1.0 Secret salt " + KID + cipher_suite - sframe_salt = HKDF-Expand(sframe_secret, info, AEAD.Nn) - - return sframe_key, sframe_salt - - In the derivation of sframe_secret: - - * The + operator represents concatenation of byte strings. - - * The KID value is encoded as an 8-byte big-endian integer, not the - compressed form used in the SFrame header. - - * The cipher_suite value is a 2-byte big-endian integer representing - the cipher suite in use (see Section 8.1). - - The hash function used for HKDF is determined by the cipher suite in - use. - -4.4.3. Encryption - - SFrame encryption uses the AEAD encryption algorithm for the cipher - suite in use. The key for the encryption is the sframe_key and the - nonce is formed by XORing the sframe_salt with the current counter, - encoded as a big-endian integer of length AEAD.Nn. - - The encryptor forms an SFrame header using the CTR, and KID values - provided. The encoded header is provided as AAD to the AEAD - encryption operation, together with application-provided metadata - about the encrypted media (see Section 9.4). - -def encrypt(CTR, KID, metadata, plaintext): - sframe_key, sframe_salt = key_store[KID] - - # encode_big_endian(x, n) produces an n-byte string encoding the integer x in - # big-endian byte order. - ctr = encode_big_endian(CTR, AEAD.Nn) - nonce = xor(sframe_salt, CTR) - - # encode_sframe_header produces a byte string encoding the provided KID and - # CTR values into an SFrame Header. - header = encode_sframe_header(CTR, KID) - aad = header + metadata - - ciphertext = AEAD.Encrypt(sframe_key, nonce, aad, plaintext) - return header + ciphertext - - For example, the metadata input to encryption allows for frame - metadata to be authenticated when SFrame is applied per-frame. After - encoding the frame and before packetizing it, the necessary media - metadata will be moved out of the encoded frame buffer, to be sent in - some channel visible to the SFU (e.g., an RTP header extension). - - +---------------+ - | | - | | - | plaintext | - | | - | | - +-------+-------+ - | - .- +-----+ | - | | +--+--> sframe_key ----->| Key - Header | | KID | | | - | | | +--> sframe_salt --+ | - +--+ +-----+ | | - | | | +---------------------+->| Nonce - | | | CTR | | - | | | | | - | '- +-----+ | - | | - | +----------------+ | - | | metadata | | - | +-------+--------+ | - | | | - +------------------+----------------->| AAD - | | - | AEAD.Encrypt - | | - | SFrame Ciphertext | - | +---------------+ | - +-------------->| SFrame Header | | - +---------------+ | - | | | - | |<----+ - | ciphertext | - | | - | | - +---------------+ - - Figure 4: Encrypting an SFrame Ciphertext - -4.4.4. Decryption - - Before decrypting, a receiver needs to assemble a full SFrame - ciphertext. When an SFrame ciphertext may be fragmented into - multiple parts for transport (e.g., a whole encrypted frame sent in - multiple SRTP packets), the receiving client collects all the - fragments of the ciphertext, using an appropriate sequencing and - start/end markers in the transport. Once all of the required - fragments are available, the client reassembles them into the SFrame - ciphertext, then passes the ciphertext to SFrame for decryption. - - The KID field in the SFrame header is used to find the right key and - salt for the encrypted frame, and the CTR field is used to construct - the nonce. The SFrame decryption procedure is as follows: - - def decrypt(metadata, sframe_ciphertext): - KID, CTR, header, ciphertext = parse_ciphertext(sframe_ciphertext) - - sframe_key, sframe_salt = key_store[KID] - - ctr = encode_big_endian(CTR, AEAD.Nn) - nonce = xor(sframe_salt, ctr) - aad = header + metadata - - return AEAD.Decrypt(sframe_key, nonce, aad, ciphertext) - - If a ciphertext fails to decrypt because there is no key available - for the KID in the SFrame 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 ciphertexts SHOULD be discarded - in a way that is indistinguishable (to an external observer) from - having processed a valid ciphertext. - - SFrame Ciphertext - +---------------+ - +---------------| SFrame Header | - | +---------------+ - | | | - | | |-----+ - | | ciphertext | | - | | | | - | | | | - | +---------------+ | - | | - | .- +-----+ | - | | | +--+--> sframe_key ----->| Key - | | | KID | | | - | | | | +--> sframe_salt --+ | - +->+ +-----+ | | - | | | +---------------------+->| Nonce - | | | CTR | | - | | | | | - | '- +-----+ | - | | - | +----------------+ | - | | metadata | | - | +-------+--------+ | - | | | - +------------------+----------------->| AAD - | - AEAD.Decrypt - | - V - +---------------+ - | | - | | - | plaintext | - | | - | | - +---------------+ - - Figure 5: Decrypting an SFrame Ciphertext - -4.5. Cipher Suites - - Each SFrame session uses a single cipher suite that specifies the - following primitives: - - * A hash function used for key derivation - - * An AEAD encryption algorithm [RFC5116] used for frame encryption, - optionally with a truncated authentication tag - - This document defines the following cipher suites, with the constants - defined in Section 4.4: - - +============================+====+=====+====+====+====+ - | Name | Nh | Nka | Nk | Nn | Nt | - +============================+====+=====+====+====+====+ - | AES_128_CTR_HMAC_SHA256_80 | 32 | 16 | 48 | 12 | 10 | - +----------------------------+----+-----+----+----+----+ - | AES_128_CTR_HMAC_SHA256_64 | 32 | 16 | 48 | 12 | 8 | - +----------------------------+----+-----+----+----+----+ - | AES_128_CTR_HMAC_SHA256_32 | 32 | 16 | 48 | 12 | 4 | - +----------------------------+----+-----+----+----+----+ - | AES_128_GCM_SHA256_128 | 32 | n/a | 16 | 12 | 16 | - +----------------------------+----+-----+----+----+----+ - | AES_256_GCM_SHA512_128 | 64 | n/a | 32 | 12 | 16 | - +----------------------------+----+-----+----+----+----+ - - Table 1: SFrame cipher suite constants - - Numeric identifiers for these cipher suites are defined in the IANA - registry created in Section 8.1. - - In the suite names, the length of the authentication tag is indicated - by the last value: "_128" indicates a hundred-twenty-eight-bit tag, - "_80" indicates a eighty-bit tag, "_64" indicates a sixty-four-bit - tag and "_32" indicates a thirty-two-bit tag. - - In a session that uses multiple media streams, different cipher - suites might be configured for different media streams. For example, - in order to conserve bandwidth, a session might use a cipher suite - with eighty-bit tags for video frames and another cipher suite with - thirty-two-bit tags for audio frames. - -4.5.1. AES-CTR with SHA2 - - In order to allow very short tag sizes, we define a synthetic AEAD - function using the authenticated counter mode of AES together with - HMAC for authentication. We use an encrypt-then-MAC approach, as in - SRTP [RFC3711]. - - Before encryption or decryption, encryption and authentication - subkeys are derived from the single AEAD key. The overall length of - the AEAD key is Nka + Nh, where Nka represents the key size for the - AES block cipher in use and Nh represents the output size of the hash - function (as in Table 2). The encryption subkey comprises the first - Nka bytes and the authentication subkey comprises the remaining Nh - bytes. - - def derive_subkeys(sframe_key): - enc_key = sframe_key[..Nka] - auth_key = sframe_key[Nka..] - return enc_key, auth_key - - The AEAD encryption and decryption functions are then composed of - individual calls to the CTR encrypt function and HMAC. The resulting - MAC value is truncated to a number of bytes Nt fixed by the cipher - suite. - - def truncate(tag, n): - # Take the first `n` bytes of `tag` - return tag[..n] - - def compute_tag(auth_key, nonce, aad, ct): - aad_len = encode_big_endian(len(aad), 8) - ct_len = encode_big_endian(len(ct), 8) - tag_len = encode_big_endian(Nt, 8) - auth_data = aad_len + ct_len + tag_len + nonce + aad + ct - tag = HMAC(auth_key, auth_data) - return truncate(tag, Nt) - - def AEAD.Encrypt(key, nonce, aad, pt): - enc_key, auth_key = derive_subkeys(key) - initial_counter = nonce + 0x00000000 # append four zero bytes - ct = AES-CTR.Encrypt(enc_key, initial_counter, pt) - tag = compute_tag(auth_key, nonce, aad, ct) - return ct + tag - - def AEAD.Decrypt(key, nonce, aad, ct): - inner_ct, tag = split_ct(ct, tag_len) - - enc_key, auth_key = derive_subkeys(key) - candidate_tag = compute_tag(auth_key, nonce, aad, inner_ct) - if !constant_time_equal(tag, candidate_tag): - raise Exception("Authentication Failure") - - initial_counter = nonce + 0x00000000 # append four zero bytes - return AES-CTR.Decrypt(enc_key, initial_counter, inner_ct) - -5. Key Management - - SFrame must be integrated with an E2E key management framework to - exchange and rotate the keys used for SFrame encryption. The key - management framework provides the following functions: - - * Provisioning KID / base_key mappings to participating clients - - * Updating the above data as clients join or leave - - It is the responsibility of the application to provide the key - management framework, as described in Section 9.2. - -5.1. Sender Keys - - If the participants in a call have a pre-existing E2E-secure channel, - they can use it to distribute SFrame keys. Each client participating - in a call generates a fresh base_key value that it will use to - encrypt media. The client then uses the E2E-secure channel to send - their encryption key to the other participants. - - In this scheme, it is assumed that receivers have a signal outside of - SFrame for which client has sent a given frame (e.g., an RTP SSRC). - SFrame KID values are then used to distinguish between versions of - the sender's base_key. - - Key IDs in this scheme have two parts, a "key generation" and a - "ratchet step". Both are unsigned integers that begin at zero. The - key generation increments each time the sender distributes a new key - to receivers. The "ratchet step" is incremented each time the sender - ratchets their key forward for forward secrecy: - - base_key[i+1] = HKDF-Expand( - HKDF-Extract("", base_key[i]), - "SFrame 1.0 Ratchet", CipherSuite.Nh) - - For compactness, we do not send the whole ratchet step. Instead, we - send only its low-order R bits, where R is a value set by the - application. Different senders may use different values of R, but - each receiver of a given sender needs to know what value of R is used - by the sender so that they can recognize when they need to ratchet - (vs. expecting a new key). R effectively defines a re-ordering - window, since no more than 2^R ratchet steps can be active at a given - time. The key generation is sent in the remaining 64 - R bits of the - key ID. - - KID = (key_generation << R) + (ratchet_step % (1 << R)) - - 64-R bits R bits - <---------------> <------------> - +-----------------+--------------+ - | Key Generation | Ratchet Step | - +-----------------+--------------+ - - Figure 6: Structure of a KID in the Sender Keys scheme - - The sender signals such a ratchet step update by sending with a KID - value in which the ratchet step has been incremented. A receiver who - receives from a sender with a new KID computes the new key as above. - The old key may be kept for some time to allow for out-of-order - delivery, but should be deleted promptly. - - If a new participant joins in the middle of a session, they will need - to receive from each sender (a) the current sender key for that - sender and (b) the current KID value for the sender. Evicting a - participant requires each sender to send a fresh sender key to all - receivers. - - It is up to the application to decide when sender keys are updated. - A sender key may be updated by sending a new base_key (updating the - key generation) or by hashing the current base_key (updating the - ratchet step). Ratcheting the key forward is useful when adding new - receivers to an SFrame-based interaction, since it assures that the - new receivers can't decrypt any media encrypted before they were - added. If a sender wishes to assure the opposite property when - removing a receiver (i.e., ensuring that the receiver can't decrypt - media after they are removed), then the sender will need to - distribute a new sender key. - -5.2. MLS - - The Messaging Layer Security (MLS) protocol provides group - authenticated key exchange [MLS-ARCH] [MLS-PROTO]. In principle, it - could be used to instantiate the sender key scheme above, but it can - also be used more efficiently directly. - - MLS creates a linear sequence of keys, each of which is shared among - the members of a group at a given point in time. When a member joins - or leaves the group, a new key is produced that is known only to the - augmented or reduced group. Each step in the lifetime of the group - is known as an "epoch", and each member of the group is assigned an - "index" that is constant for the time they are in the group. - - To generate keys and nonces for SFrame, we use the MLS exporter - function to generate a base_key value for each MLS epoch. Each - member of the group is assigned a set of KID values, so that each - member has a unique sframe_key and sframe_salt that it uses to - encrypt with. Senders may choose any KID value within their assigned - set of KID values, e.g., to allow a single sender to send multiple - uncoordinated outbound media streams. - - base_key = MLS-Exporter("SFrame 1.0 Base Key", "", AEAD.Nk) - - For compactness, we do not send the whole epoch number. Instead, we - send only its low-order E bits, where E is a value set by the - application. E effectively defines a re-ordering window, since no - more than 2^E epochs can be active at a given time. Receivers MUST - be prepared for the epoch counter to roll over, removing an old epoch - when a new epoch with the same E lower bits is introduced. - - Let S be the number of bits required to encode a member index in the - group, i.e., the smallest value such that group_size <= (1 << S). - The sender index is encoded in the S bits above the epoch. The - remaining 64 - S - E bits of the KID value are a context value chosen - by the sender (context value 0 will produce the shortest encoded - KID). - - KID = (context << (S + E)) + (sender_index << E) + (epoch % (1 << E)) - - 64-S-E bits S bits E bits - <-----------> <------> <------> - +-------------+--------+-------+ - | Context ID | Index | Epoch | - +-------------+--------+-------+ - - Figure 7: Structure of a KID for an MLS Sender - - Once an SFrame stack has been provisioned with the - sframe_epoch_secret for an epoch, it can compute the required KID - values on demand (as well as the resulting SFrame keys/nonces derived - from the base_key and KID), as it needs to encrypt or decrypt for a - given member. - - ... - | - | - Epoch 14 +--+-- index=3 ---> KID = 0x3e - | | - | +-- index=7 ---> KID = 0x7e - | | - | +-- index=20 --> KID = 0x14e - | - | - Epoch 15 +--+-- index=3 ---> KID = 0x3f - | | - | +-- index=5 ---> KID = 0x5f - | - | - Epoch 16 +----- index=2 --+--> context = 2 --> KID = 0x820 - | | - | +--> context = 3 --> KID = 0xc20 - | - | - Epoch 17 +--+-- index=33 --> KID = 0x211 - | | - | +-- index=51 --> KID = 0x331 - | - | - ... - - Figure 8: An example sequence of KIDs for an MLS-based SFrame - session (E=4; S=6, allowing for 64 group members) - -6. Media Considerations - -6.1. Selective Forwarding Units - - Selective Forwarding Units (SFUs) (e.g., those described in - Section 3.7 of [RFC7667]) receive the media streams from each - participant and select which ones should be forwarded to each of the - other participants. There are several approaches for stream - selection, but in general, the SFU needs to access metadata - associated to each frame and modify the RTP information of the - incoming packets when they are transmitted to the received - participants. - - This section describes how this normal SFU modes of operation - interact with the E2EE provided by SFrame. - -6.1.1. LastN and RTP stream reuse - - The SFU may choose to send only a certain number of streams based on - the voice activity of the participants. To avoid the overhead - involved in establishing new transport streams, the SFU may decide to - reuse previously existing streams or even pre-allocate a predefined - number of streams and choose in each moment in time which participant - media will be sent through it. - - This means that in the same transport-level stream (e.g., an RTP - stream defined by either SSRC or MID) may carry media from different - streams of different participants. As different keys are used by - each participant for encoding their media, the receiver will be able - to verify which is the sender of the media coming within the RTP - stream at any given point in time, preventing the SFU trying to - impersonate any of the participants with another participant's media. - - Note that in order to prevent impersonation by a malicious - participant (not the SFU), a mechanism based on digital signature - would be required. SFrame does not protect against such attacks. - -6.1.2. Simulcast - - When using simulcast, the same input image will produce N different - encoded frames (one per simulcast layer) which would be processed - independently by the frame encryptor and assigned an unique counter - for each. - -6.1.3. SVC - - In both temporal and spatial scalability, the SFU may choose to drop - layers in order to match a certain bitrate or forward specific media - sizes or frames per second. In order to support the SFU selectively - removing layers, the sender MUST encapsulate each layer in a - different SFrame ciphertext. - -6.2. Video Key Frames - - Forward Security and Post-Compromise Security require that the E2EE - keys (base keys) are updated any time a participant joins or leaves - the call. - - The key exchange happens asynchronously and on a different path than - the SFU signaling and media. So it may happen that when a new - participant joins the call and the SFU side requests a key frame, the - sender generates the E2EE frame with a key not known by the receiver, - so it will be discarded. When the sender updates his sending key - with the new key, it will send it in a non-key frame, so the receiver - will be able to decrypt it, but not decode it. - - The new Receiver will then re-request a key frame, but due to sender - and SFU policies, that new key frame could take some time to be - generated. - - If the sender sends a key frame after the new E2EE key is in use, the - time required for the new participant to display the video is - minimized. - - Note that this issue does not arise for media streams that do not - have dependencies among frames, e.g., audio streams. In these - streams, each frame is independently decodeable, so there is never a - need to process two frames together which might be on two sides of a - key rotation. - -6.3. Partial Decoding - - Some codecs support partial decoding, where individual packets can be - decoded without waiting for the full frame to arrive. When SFrame is - applied per-frame, this won't be possible because the decoder cannot - access data until an entire frame has arrived and has been decrypted. - -7. Security Considerations - -7.1. No Header Confidentiality - - SFrame provides integrity protection to the SFrame Header (the key ID - and counter values), but does not provide confidentiality protection. - Parties that can observe the SFrame header may learn, for example, - which parties are sending SFrame payloads (from KID values) and at - what rates (from CTR values). In cases where SFrame is used for end- - to-end security on top of hop-by-hop protections (e.g., running over - SRTP as described in Appendix C.5), the hop-by-hop security - mechanisms provide confidentiality protection of the SFrame header - between hops. - -7.2. No Per-Sender Authentication - - SFrame does not provide per-sender authentication of media data. Any - sender in a session can send media that will be associated with any - other sender. This is because SFrame uses symmetric encryption to - protect media data, so that any receiver also has the keys required - to encrypt packets for the sender. - -7.3. Key Management - - Key exchange mechanism is out of scope of this document, however - every client SHOULD change their keys when new clients joins or - leaves the call for forward secrecy and post compromise security. - -7.4. Replay - - The handling of replay is out of the scope of this document. - However, senders MUST reject requests to encrypt multiple times with - the same key and nonce, since several AEAD algorithms fail badly in - such cases (see, e.g., Section 5.1.1 of [RFC5116]). - -7.5. Risks due to Short Tags - - The SFrame ciphersuites based on AES-CTR allow for the use of short - authentication tags, which bring a higher risk that an attacker will - be able to cause an SFrame receiver to accept an SFrame ciphertext of - the attacker's choosing. - - Assuming that the authentication properties of the ciphersuite are - robust, the only attack that an attacker can mount is an attempt to - find an acceptable (ciphertext, tag) combination through brute force. - Such a brute-force attack will have an expected sucess rate of the - following form: - - attacker_success_rate = attempts_per_second / 2^(8*Nt) - - For example, a gigabit ethernet connection is able to transmit - roughly 2^20 packets per second. If an attacker saturated such a - link with guesses against a 32-bit authentication tag (Nt=4), then - the attacker would succeed on average roughly once every 2^12 - seconds, or about once an hour. - - In a typical SFrame usage in a real-time media application, there are - a few approaches to mitigating this risk: - - * Receivers only accept SFrame ciphertexts over HBH-secure channels - (e.g., SRTP security associations or QUIC connections). If this - is the case, only an entity that is part of such a channel can - mount the above attack. - - * The expected packet rate for a media stream is very predictable - (and typically far lower than the above example). On the one - hand, attacks at this rate will succeed even less often than the - high-rate attack described above. On the other hand, the - application may use an elevated packet arrival rate as a signal of - a brute-force attack. This latter approach is common in other - settings, e.g., mitigating brute-force attacks on passwords. - - * Media applications typically do not provide feedback to media - senders as to which media packets failed to decrypt. When media - quality feedback mechanisms are used, decryption failures will - typically appear as packet losses, but only at an aggregate level. - - * Anti-replay mechanisms (see Section 7.4) prevent the attacker from - re-using valid ciphertexts (either observed or guessed by the - attacker). A receiver applying anti-replay controls will only - accept one valid plaintext per CTR value. Since the CTR value is - covered by SFrame authentication, an attacker has to do a fresh - search for a valid tag for every forged ciphertext, even if the - encrypted content is unchanged. In other words, when the above - brute force attack succeeds, it only allows the attacker to send a - single SFrame ciphertext; the ciphertext cannot be reused because - either it will have the same CTR value and be discarded as a - replay, or else it will have a different CTR value its tag will no - longer be valid. - - Nonetheless, without these mitigations, an application that makes use - of short tags will be at heightened risk of forgery attacks. In many - cases, it is simpler to use full-size tags and tolerate slightly - higher bandwidth usage rather than add the additional defenses - necessary to safely use short tags. - -8. IANA Considerations - - This document requests the creation of the following new IANA - registry: - - * SFrame Cipher Suites (Section 8.1) - - This registry should be under a heading of "SFrame", and assignments - are made via the Specification Required policy [RFC8126]. - - RFC EDITOR: Please replace XXXX throughout with the RFC number - assigned to this document - -8.1. SFrame Cipher Suites - - This registry lists identifiers for SFrame cipher suites, as defined - in Section 4.5. The cipher suite field is two bytes wide, so the - valid cipher suites are in the range 0x0000 to 0xFFFF. - - Template: - - * Value: The numeric value of the cipher suite - - * Name: The name of the cipher suite - - * Reference: The document where this cipher suite is defined - - Initial contents: - - +=================+============================+===========+ - | Value | Name | Reference | - +=================+============================+===========+ - | 0x0000 | Reserved | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0x0001 | AES_128_CTR_HMAC_SHA256_80 | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0x0002 | AES_128_CTR_HMAC_SHA256_64 | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0x0003 | AES_128_CTR_HMAC_SHA256_32 | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0x0004 | AES_128_GCM_SHA256_128 | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0x0005 | AES_256_GCM_SHA512_128 | RFC XXXX | - +-----------------+----------------------------+-----------+ - | 0xF000 - 0xFFFF | Reserved for private use | RFC XXXX | - +-----------------+----------------------------+-----------+ - - Table 2: SFrame cipher suites - -9. Application Responsibilities - - To use SFrame, an application needs to define the inputs to the - SFrame encryption and decryption operations, and how SFrame - ciphertexts are delivered from sender to receiver (including any - fragmentation and reassembly). In this section, we lay out - additional requirements that an integration must meet in order for - SFrame to operate securely. - - In general, an application using SFrame is responsible for - configuring SFrame. The application must first define when SFrame is - applied at all. When SFrame is applied, the application must define - which cipher suite is to be used. If new versions of SFrame are - defined in the future, it will be up to the application to determine - which version should be used. - - This division of responsibilities is similar to the way other media - parameters (e.g., codecs) are typically handled in media - applications, in the sense that they are set up in some signaling - protocol, and then not described in the media. Applications might - find it useful to extend the protocols used for negotiating other - media parameters (e.g., SDP [RFC4566]) to also negotiate parameters - for SFrame. - -9.1. Header Value Uniqueness - - Applications MUST ensure that each (base_key, KID, CTR) combination - is used for at most one SFrame encryption operation. This ensures - that the (key, nonce) pairs used by the underlying AEAD algorithm are - never reused. Typically this is done by assigning each sender a KID - or set of KIDs, then having each sender use the CTR field as a - monotonic counter, incrementing for each plaintext that is encrypted. - In addition to its simplicity, this scheme minimizes overhead by - keeping CTR values as small as possible. - -9.2. Key Management Framework - - It is up to the application to provision SFrame with a mapping of KID - values to base_key values and the resulting keys and salts. More - importantly, the application specifies which KID values are used for - which purposes (e.g., by which senders). An application's KID - assignment strategy MUST be structured to assure the non-reuse - properties discussed in Section 9.1. - - It is also up to the application to define a rotation schedule for - keys. For example, one application might have an ephemeral group for - every call and keep rotating keys when end points join or leave the - call, while another application could have a persistent group that - can be used for multiple calls and simply derives ephemeral symmetric - keys for a specific call. - - It should be noted that KID values are not encrypted by SFrame, and - are thus visible to any application-layer intermediaries that might - handle an SFrame ciphertext. If there are application semantics - included in KID values, then this information would be exposed to - intermediaries. For example, in the scheme of Section 5.1, the - number of ratchet steps per sender is exposed, and in the scheme of - Section 5.2, the number of epochs and the MLS sender ID of the SFrame - sender are exposed. - -9.3. Anti-Replay - - It is the responsibility of the application to handle anti-replay. - Replay by network attackers is assumed to be prevented by network- - layer facilities (e.g., TLS, SRTP). As mentioned in Section 7.4, - senders MUST reject requests to encrypt multiple times with the same - key and nonce. - - It is not mandatory to implement anti-replay on the receiver side. - Receivers MAY apply time or counter based anti-replay mitigations. - For example, Section 3.3.2 of [RFC3711] specifies a counter-based - anti-replay mitigation, which could be adapted to use with SFrame, - using the CTR field as the counter. - -9.4. Metadata - - The metadata input to SFrame operations is pure application-specified - data. As such, it is up to the application to define what - information should go in the metadata input and ensure that it is - provided to the encryption and decryption functions at the - appropriate points. A receiver MUST NOT use SFrame-authenticated - metadata until after the SFrame decrypt function has authenticated - it, unless the purpose of such usage is to prepare an SFrame - ciphertext for SFrame decryption. Essentially, metadata may be used - "upstream of SFrame" in a processing pipeline, but only to prepare - for SFrame decryption. - - For example, consider an application where SFrame is used to encrypt - audio frames that are sent over SRTP, with some application data - included in the RTP header extension. Suppose the application also - includes this application data in the SFrame metadata, so that the - SFU is allowed to read, but not modify the application data. A - receiver can use the application data in the RTP header extension as - part of the standard SRTP decryption process, since this is required - to recover the SFrame ciphertext carried in the SRTP payload. - However, the receiver MUST NOT use the application data for other - purposes before SFrame decryption has authenticated the application - data. - -10. References - -10.1. Normative References - - [MLS-PROTO] - Barnes, R., Beurdouche, B., Robert, R., Millican, J., - Omara, E., and K. Cohn-Gordon, "The Messaging Layer - Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420, - July 2023, . - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, - . - - [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated - Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, - . - - [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand - Key Derivation Function (HKDF)", RFC 5869, - DOI 10.17487/RFC5869, May 2010, - . - - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for - Writing an IANA Considerations Section in RFCs", BCP 26, - RFC 8126, DOI 10.17487/RFC8126, June 2017, - . - - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC - 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, - May 2017, . - -10.2. Informative References - - [I-D.codec-agnostic-rtp-payload-format] - Murillo, S. G. and A. Gouaillard, "Codec agnostic RTP - payload format for video", Work in Progress, Internet- - Draft, draft-codec-agnostic-rtp-payload-format-00, 19 - February 2021, . - - [I-D.ietf-moq-transport] - Curley, L., Pugin, K., Nandakumar, S., Vasiliev, V., and - I. Swett, "Media over QUIC Transport", Work in Progress, - Internet-Draft, draft-ietf-moq-transport-02, 24 January - 2024, . - - [I-D.ietf-webtrans-overview] - Vasiliev, V., "The WebTransport Protocol Framework", Work - in Progress, Internet-Draft, draft-ietf-webtrans-overview- - 06, 6 September 2023, - . - - [MLS-ARCH] Beurdouche, B., Rescorla, E., Omara, E., Inguva, S., and - A. Duric, "The Messaging Layer Security (MLS) - Architecture", Work in Progress, Internet-Draft, draft- - ietf-mls-architecture-11, 26 July 2023, - . - - [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. - Norrman, "The Secure Real-time Transport Protocol (SRTP)", - RFC 3711, DOI 10.17487/RFC3711, March 2004, - . - - [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session - Description Protocol", RFC 4566, DOI 10.17487/RFC4566, - July 2006, . - - [RFC6716] Valin, JM., Vos, K., and T. Terriberry, "Definition of the - Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716, - September 2012, . - - [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and - B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms - for Real-Time Transport Protocol (RTP) Sources", RFC 7656, - DOI 10.17487/RFC7656, November 2015, - . - - [RFC7667] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 7667, - DOI 10.17487/RFC7667, November 2015, - . - - [RFC8723] Jennings, C., Jones, P., Barnes, R., and A.B. Roach, - "Double Encryption Procedures for the Secure Real-Time - Transport Protocol (SRTP)", RFC 8723, - DOI 10.17487/RFC8723, April 2020, - . - - [TestVectors] - "SFrame Test Vectors", 2023, - . - -Appendix A. Acknowledgements - - The authors wish to specially thank Dr. Alex Gouaillard as one of the - early contributors to the document. His passion and energy were key - to the design and development of SFrame. - -Appendix B. Example API - - *This section is not normative.* - - This section describes a notional API that an SFrame implementation - might expose. The core concept is an "SFrame context", within which - KID values are meaningful. In the key management scheme described in - Section 5.1, each sender has a different context; in the scheme - described in Section 5.2, all senders share the same context. - - An SFrame context stores mappings from KID values to "key contexts", - which are different depending on whether the KID is to be used for - sending or receiving (an SFrame key should never be used for both - operations). A key context tracks the key and salt associated to the - KID, and the current CTR value. A key context to be used for sending - also tracks the next CTR value to be used. - - The primary operations on an SFrame context are as follows: - - * *Create an SFrame context:* The context is initialized with a - ciphersuite and no KID mappings. - - * *Adding a key for sending:* The key and salt are derived from the - base key, and used to initialize a send context, together with a - zero counter value. - - * *Adding a key for receiving:* The key and salt are derived from - the base key, and used to initialize a send context. - - * *Encrypt a plaintext:* Encrypt a given plaintext using the key for - a given KID, including the specified metadata. - - * *Decrypt an SFrame ciphertext:* Decrypt an SFrame ciphertext with - the KID and CTR values specified in the SFrame Header, and the - provided metadata. - - Figure 9 shows an example of the types of structures and methods that - could be used to create an SFrame API in Rust. - - type KeyId = u64; - type Counter = u64; - type CipherSuite = u16; - - struct SendKeyContext { - key: Vec, - salt: Vec, - next_counter: Counter, - } - - struct RecvKeyContext { - key: Vec, - salt: Vec, - } - - struct SFrameContext { - cipher_suite: CipherSuite, - send_keys: HashMap, - recv_keys: HashMap, - } - - trait SFrameContextMethods { - fn create(cipher_suite: CipherSuite) -> Self; - fn add_send_key(&self, kid: KeyId, base_key: &[u8]); - fn add_recv_key(&self, kid: KeyId, base_key: &[u8]); - fn encrypt(&mut self, kid: KeyId, metadata: &[u8], - plaintext: &[u8]) -> Vec; - fn decrypt(&self, metadata: &[u8], ciphertext: &[u8]) -> Vec; - } - - Figure 9: An Example SFrame API - -Appendix C. Overhead Analysis - - Any use of SFrame will impose overhead in terms of the amount of - bandwidth necessary to transmit a given media stream. Exactly how - much overhead will be added depends on several factors: - - * How many senders are involved in a conference (length of KID) - - * How long the conference has been going on (length of CTR) - - * The cipher suite in use (length of authentication tag) - - * Whether SFrame is used to encrypt packets, whole frames, or some - other unit - - Overall, the overhead rate in kilobits per second can be estimated - as: - - OverheadKbps = (1 + |CTR| + |KID| + |TAG|) * 8 * CTPerSecond / 1024 - - Here the constant value 1 reflects the fixed SFrame header; |CTR| - and |KID| reflect the lengths of those fields; |TAG| reflects the - cipher overhead; and CTPerSecond reflects the number of SFrame - ciphertexts sent per second (e.g., packets or frames per second). - - In the remainder of this secton, we compute overhead estimates for a - collection of common scenarios. - -C.1. Assumptions - - In the below calculations, we make conservative assumptions about - SFrame overhead, so that the overhead amounts we compute here are - likely to be an upper bound on those seen in practice. - - +==============+=======+============================+ - | Field | Bytes | Explanation | - +==============+=======+============================+ - | Fixed header | 1 | Fixed | - +--------------+-------+----------------------------+ - | Key ID (KID) | 2 | >255 senders; or MLS epoch | - | | | (E=4) and >16 senders | - +--------------+-------+----------------------------+ - | Counter | 3 | More than 24 hours of | - | (CTR) | | media in common cases | - +--------------+-------+----------------------------+ - | Cipher | 16 | Full GCM tag (longest | - | overhead | | defined here) | - +--------------+-------+----------------------------+ - - Table 3 - - In total, then, we assume that each SFrame encryption will add 22 - bytes of overhead. - - We consider two scenarios, applying SFrame per-frame and per-packet. - In each scenario, we compute the SFrame overhead in absolute terms - (Kbps) and as a percentage of the base bandwidth. - -C.2. Audio - - In audio streams, there is typically a one-to-one relationship - between frames and packets, so the overhead is the same whether one - uses SFrame at a per-packet or per-frame level. - - The below table considers three scenarios, based on recommended - configurations of the Opus codec [RFC6716]: - - * Narrow-band speech: 120ms packets, 8Kbps - - * Full-band speech: 20ms packets, 32Kbps - - * Full-band stereo music: 10ms packets, 128Kbps - - +===============+=====+===========+===============+============+ - | Scenario | fps | Base Kbps | Overhead Kbps | Overhead % | - +===============+=====+===========+===============+============+ - | NB speech, | 8.3 | 8 | 1.4 | 17.9% | - | 120ms packets | | | | | - +---------------+-----+-----------+---------------+------------+ - | FB speech, | 50 | 32 | 8.6 | 26.9% | - | 20ms packets | | | | | - +---------------+-----+-----------+---------------+------------+ - | FB stereo, | 100 | 128 | 17.2 | 13.4% | - | 10ms packets | | | | | - +---------------+-----+-----------+---------------+------------+ - - Table 4: SFrame overhead for audio streams - -C.3. Video - - Video frames can be larger than an MTU and thus are commonly split - across multiple frames. Table 5 and Table 6 show the estimated - overhead of encrypting a video stream, where SFrame is applied per- - frame and per-packet, respectively. The choices of resolution, - frames per second, and bandwidth are chosen to roughly reflect the - capabilities of modern video codecs across a range from very low to - very high quality. - - +=============+=====+===========+===============+============+ - | Scenario | fps | Base Kbps | Overhead Kbps | Overhead % | - +=============+=====+===========+===============+============+ - | 426 x 240 | 7.5 | 45 | 1.3 | 2.9% | - +-------------+-----+-----------+---------------+------------+ - | 640 x 360 | 15 | 200 | 2.6 | 1.3% | - +-------------+-----+-----------+---------------+------------+ - | 640 x 360 | 30 | 400 | 5.2 | 1.3% | - +-------------+-----+-----------+---------------+------------+ - | 1280 x 720 | 30 | 1500 | 5.2 | 0.3% | - +-------------+-----+-----------+---------------+------------+ - | 1920 x 1080 | 60 | 7200 | 10.3 | 0.1% | - +-------------+-----+-----------+---------------+------------+ - - Table 5: SFrame overhead for a video stream encrypted per- - frame - - +=============+=====+=====+===========+===============+============+ - | Scenario | fps | pps | Base Kbps | Overhead Kbps | Overhead % | - +=============+=====+=====+===========+===============+============+ - | 426 x 240 | 7.5 | 7.5 | 45 | 1.3 | 2.9% | - +-------------+-----+-----+-----------+---------------+------------+ - | 640 x 360 | 15 | 30 | 200 | 5.2 | 2.6% | - +-------------+-----+-----+-----------+---------------+------------+ - | 640 x 360 | 30 | 60 | 400 | 10.3 | 2.6% | - +-------------+-----+-----+-----------+---------------+------------+ - | 1280 x 720 | 30 | 180 | 1500 | 30.9 | 2.1% | - +-------------+-----+-----+-----------+---------------+------------+ - | 1920 x 1080 | 60 | 780 | 7200 | 134.1 | 1.9% | - +-------------+-----+-----+-----------+---------------+------------+ - - Table 6: SFrame overhead for a video stream encrypted per-packet - - In the per-frame case, the SFrame percentage overhead approaches zero - as the quality of the video goes up, since bandwidth is driven more - by picture size than frame rate. In the per-packet case, the SFrame - percentage overhead approaches the ratio between the SFrame overhead - per packet and the MTU (here 22 bytes of SFrame overhead divided by - an assumed 1200-byte MTU, or about 1.8%). - -C.4. Conferences - - Real conferences usually involve several audio and video streams. - The overhead of SFrame in such a conference is the aggregate of the - overhead over all the individual streams. Thus, while SFrame incurs - a large percentage overhead on an audio stream, if the conference - also involves a video stream, then the audio overhead is likely - negligible relative to the overall bandwidth of the conference. - - For example, Table 7 shows the overhead estimates for a two person - conference where one person is sending low-quality media and the - other sending high-quality. (And we assume that SFrame is applied - per-frame.) The video streams dominate the bandwidth at the SFU, so - the total bandwidth overhead is only around 1%. - - +=====================+===========+===============+============+ - | Stream | Base Kbps | Overhead Kbps | Overhead % | - +=====================+===========+===============+============+ - | Participant 1 audio | 8 | 1.4 | 17.9% | - +---------------------+-----------+---------------+------------+ - | Participant 1 video | 45 | 1.3 | 2.9% | - +---------------------+-----------+---------------+------------+ - | Participant 2 audio | 32 | 9 | 26.9% | - +---------------------+-----------+---------------+------------+ - | Participant 2 video | 1500 | 5 | 0.3% | - +---------------------+-----------+---------------+------------+ - | Total at SFU | 1585 | 16.5 | 1.0% | - +---------------------+-----------+---------------+------------+ - - Table 7: SFrame overhead for a two-person conference - -C.5. SFrame over RTP - - SFrame is a generic encapsulation format, but many of the - applications in which it is likely to be integrated are based on RTP. - This section discusses how an integration between SFrame and RTP - could be done, and some of the challenges that would need to be - overcome. - - As discussed in Section 4.1, there are two natural patterns for - integrating SFrame into an application: applying SFrame per-frame or - per-packet. In RTP-based applications, applying SFrame per-packet - means that the payload of each RTP packet will be an SFrame - ciphertext, starting with an SFrame Header, as shown in Figure 10. - Applying SFrame per-frame means that different RTP payloads will have - different formats: The first payload of a frame will contain the - SFrame headers, and subsequent payloads will contain further chunks - of the ciphertext, as shown in Figure 11. - - In order for these media payloads to be properly interpreted by - receivers, receivers will need to be configured to know which of the - above schemes the sender has applied to a given sequence of RTP - packets. SFrame does not provide a mechanism for distributing this - configuration information. In applications that use SDP for - negotiating RTP media streams [RFC4566], an appropriate extension to - SDP could provide this function. - - Applying SFrame per-frame also requires that packetization and - depacketization be done in a generic manner that does not depend on - the media content of the packets, since the content being packetized - / depacketized will be opaque ciphertext (except for the SFrame - header). In order for such a generic packetization scheme to work - interoperably one would have to be defined, e.g., as proposed in - [I-D.codec-agnostic-rtp-payload-format]. - - +---+-+-+-------+-+-------------+-------------------------------+<-+ - |V=2|P|X| CC |M| PT | sequence number | | - +---+-+-+-------+-+-------------+-------------------------------+ | - | timestamp | | - +---------------------------------------------------------------+ | - | synchronization source (SSRC) identifier | | - +===============================================================+ | - | contributing source (CSRC) identifiers | | - | .... | | - +---------------------------------------------------------------+ | - | RTP extension(s) (OPTIONAL) | | - +->+--------------------+------------------------------------------+ | - | | SFrame header | | | - | +--------------------+ | | - | | | | - | | SFrame encrypted and authenticated payload | | - | | | | - +->+---------------------------------------------------------------+<-+ - | | SRTP authentication tag | | - | +---------------------------------------------------------------+ | - | | - +--- SRTP Encrypted Portion SRTP Authenticated Portion ---+ - - Figure 10: SRTP packet with SFrame-protected payload - - +----------------+ +---------------+ - | frame metadata | | | - +-------+--------+ | | - | | frame | - | | | - | | | - | +-------+-------+ - | | - | | - V V - +--------------------------------------+ - | SFrame Encrypt | - +--------------------------------------+ - | | - | | - | V - | +-------+-------+ - | | | - | | | - | | encrypted | - | | frame | - | | | - | | | - | +-------+-------+ - | | - | generic RTP packetize - | | - | +----------------------+--------.....--------+ - | | | | - V V V V - +---------------+ +---------------+ +---------------+ - | SFrame header | | | | | - +---------------+ | | | | - | | | payload 2/N | ... | payload N/N | - | payload 1/N | | | | | - | | | | | | - +---------------+ +---------------+ +---------------+ - - Figure 11: Encryption flow with per-frame encryption for RTP - -Appendix D. Test Vectors - - This section provides a set of test vectors that implementations can - use to verify that they correctly implement SFrame encryption and - decryption. In addition to test vectors for the overall process of - SFrame encryption/decryption, we also provide test vectors for header - encoding/decoding, and for AEAD encryption/decryption using the AES- - CTR construction defined in Section 4.5.1. - - All values are either numeric or byte strings. Numeric values are - represented as hex values, prefixed with 0x. Byte strings are - represented in hex encoding. - - Line breaks and whitespace within values are inserted to conform to - the width requirements of the RFC format. They should be removed - before use. - - These test vectors are also available in JSON format at - [TestVectors]. In the JSON test vectors, numeric values are JSON - numbers and byte string values are JSON strings containing the hex - encoding of the byte strings. - -D.1. Header encoding/decoding - - For each case, we provide: - - * kid: A KID value - - * ctr: A CTR value - - * header: An encoded SFrame header - - An implementation should verify that: - - * Encoding a header with the KID and CTR results in the provided - header value - - * Decoding the provided header value results in the provided KID and - CTR values - - kid: 0x0000000000000000 - ctr: 0x0000000000000000 - header: 00 - - kid: 0x0000000000000000 - ctr: 0x0000000000000001 - header: 01 - - kid: 0x0000000000000000 - ctr: 0x00000000000000ff - header: 08ff - - kid: 0x0000000000000000 - ctr: 0x0000000000000100 - header: 090100 - - kid: 0x0000000000000000 - ctr: 0x000000000000ffff - header: 09ffff - - kid: 0x0000000000000000 - ctr: 0x0000000000010000 - header: 0a010000 - - kid: 0x0000000000000000 - ctr: 0x0000000000ffffff - header: 0affffff - - kid: 0x0000000000000000 - ctr: 0x0000000001000000 - header: 0b01000000 - - kid: 0x0000000000000000 - ctr: 0x00000000ffffffff - header: 0bffffffff - - kid: 0x0000000000000000 - ctr: 0x0000000100000000 - header: 0c0100000000 - - kid: 0x0000000000000000 - ctr: 0x000000ffffffffff - header: 0cffffffffff - - kid: 0x0000000000000000 - ctr: 0x0000010000000000 - header: 0d010000000000 - - kid: 0x0000000000000000 - ctr: 0x0000ffffffffffff - header: 0dffffffffffff - - kid: 0x0000000000000000 - ctr: 0x0001000000000000 - header: 0e01000000000000 - - kid: 0x0000000000000000 - ctr: 0x00ffffffffffffff - header: 0effffffffffffff - - kid: 0x0000000000000000 - ctr: 0x0100000000000000 - header: 0f0100000000000000 - - kid: 0x0000000000000000 - ctr: 0xffffffffffffffff - header: 0fffffffffffffffff - - kid: 0x0000000000000001 - ctr: 0x0000000000000000 - header: 10 - - kid: 0x0000000000000001 - ctr: 0x0000000000000001 - header: 11 - - kid: 0x0000000000000001 - ctr: 0x00000000000000ff - header: 18ff - - kid: 0x0000000000000001 - ctr: 0x0000000000000100 - header: 190100 - - kid: 0x0000000000000001 - ctr: 0x000000000000ffff - header: 19ffff - - kid: 0x0000000000000001 - ctr: 0x0000000000010000 - header: 1a010000 - - kid: 0x0000000000000001 - ctr: 0x0000000000ffffff - header: 1affffff - - kid: 0x0000000000000001 - ctr: 0x0000000001000000 - header: 1b01000000 - - kid: 0x0000000000000001 - ctr: 0x00000000ffffffff - header: 1bffffffff - - kid: 0x0000000000000001 - ctr: 0x0000000100000000 - header: 1c0100000000 - - kid: 0x0000000000000001 - ctr: 0x000000ffffffffff - header: 1cffffffffff - - kid: 0x0000000000000001 - ctr: 0x0000010000000000 - header: 1d010000000000 - - kid: 0x0000000000000001 - ctr: 0x0000ffffffffffff - header: 1dffffffffffff - - kid: 0x0000000000000001 - ctr: 0x0001000000000000 - header: 1e01000000000000 - - kid: 0x0000000000000001 - ctr: 0x00ffffffffffffff - header: 1effffffffffffff - - kid: 0x0000000000000001 - ctr: 0x0100000000000000 - header: 1f0100000000000000 - - kid: 0x0000000000000001 - ctr: 0xffffffffffffffff - header: 1fffffffffffffffff - - kid: 0x00000000000000ff - ctr: 0x0000000000000000 - header: 80ff - - kid: 0x00000000000000ff - ctr: 0x0000000000000001 - header: 81ff - - kid: 0x00000000000000ff - ctr: 0x00000000000000ff - header: 88ffff - - kid: 0x00000000000000ff - ctr: 0x0000000000000100 - header: 89ff0100 - - kid: 0x00000000000000ff - ctr: 0x000000000000ffff - header: 89ffffff - - kid: 0x00000000000000ff - ctr: 0x0000000000010000 - header: 8aff010000 - - kid: 0x00000000000000ff - ctr: 0x0000000000ffffff - header: 8affffffff - - kid: 0x00000000000000ff - ctr: 0x0000000001000000 - header: 8bff01000000 - - kid: 0x00000000000000ff - ctr: 0x00000000ffffffff - header: 8bffffffffff - - kid: 0x00000000000000ff - ctr: 0x0000000100000000 - header: 8cff0100000000 - - kid: 0x00000000000000ff - ctr: 0x000000ffffffffff - header: 8cffffffffffff - - kid: 0x00000000000000ff - ctr: 0x0000010000000000 - header: 8dff010000000000 - - kid: 0x00000000000000ff - ctr: 0x0000ffffffffffff - header: 8dffffffffffffff - - kid: 0x00000000000000ff - ctr: 0x0001000000000000 - header: 8eff01000000000000 - - kid: 0x00000000000000ff - ctr: 0x00ffffffffffffff - header: 8effffffffffffffff - - kid: 0x00000000000000ff - ctr: 0x0100000000000000 - header: 8fff0100000000000000 - - kid: 0x00000000000000ff - ctr: 0xffffffffffffffff - header: 8fffffffffffffffffff - - kid: 0x0000000000000100 - ctr: 0x0000000000000000 - header: 900100 - - kid: 0x0000000000000100 - ctr: 0x0000000000000001 - header: 910100 - - kid: 0x0000000000000100 - ctr: 0x00000000000000ff - header: 980100ff - - kid: 0x0000000000000100 - ctr: 0x0000000000000100 - header: 9901000100 - - kid: 0x0000000000000100 - ctr: 0x000000000000ffff - header: 990100ffff - - kid: 0x0000000000000100 - ctr: 0x0000000000010000 - header: 9a0100010000 - - kid: 0x0000000000000100 - ctr: 0x0000000000ffffff - header: 9a0100ffffff - - kid: 0x0000000000000100 - ctr: 0x0000000001000000 - header: 9b010001000000 - - kid: 0x0000000000000100 - ctr: 0x00000000ffffffff - header: 9b0100ffffffff - - kid: 0x0000000000000100 - ctr: 0x0000000100000000 - header: 9c01000100000000 - - kid: 0x0000000000000100 - ctr: 0x000000ffffffffff - header: 9c0100ffffffffff - - kid: 0x0000000000000100 - ctr: 0x0000010000000000 - header: 9d0100010000000000 - - kid: 0x0000000000000100 - ctr: 0x0000ffffffffffff - header: 9d0100ffffffffffff - - kid: 0x0000000000000100 - ctr: 0x0001000000000000 - header: 9e010001000000000000 - - kid: 0x0000000000000100 - ctr: 0x00ffffffffffffff - header: 9e0100ffffffffffffff - - kid: 0x0000000000000100 - ctr: 0x0100000000000000 - header: 9f01000100000000000000 - - kid: 0x0000000000000100 - ctr: 0xffffffffffffffff - header: 9f0100ffffffffffffffff - - kid: 0x000000000000ffff - ctr: 0x0000000000000000 - header: 90ffff - - kid: 0x000000000000ffff - ctr: 0x0000000000000001 - header: 91ffff - - kid: 0x000000000000ffff - ctr: 0x00000000000000ff - header: 98ffffff - - kid: 0x000000000000ffff - ctr: 0x0000000000000100 - header: 99ffff0100 - - kid: 0x000000000000ffff - ctr: 0x000000000000ffff - header: 99ffffffff - - kid: 0x000000000000ffff - ctr: 0x0000000000010000 - header: 9affff010000 - - kid: 0x000000000000ffff - ctr: 0x0000000000ffffff - header: 9affffffffff - - kid: 0x000000000000ffff - ctr: 0x0000000001000000 - header: 9bffff01000000 - - kid: 0x000000000000ffff - ctr: 0x00000000ffffffff - header: 9bffffffffffff - - kid: 0x000000000000ffff - ctr: 0x0000000100000000 - header: 9cffff0100000000 - - kid: 0x000000000000ffff - ctr: 0x000000ffffffffff - header: 9cffffffffffffff - - kid: 0x000000000000ffff - ctr: 0x0000010000000000 - header: 9dffff010000000000 - - kid: 0x000000000000ffff - ctr: 0x0000ffffffffffff - header: 9dffffffffffffffff - - kid: 0x000000000000ffff - ctr: 0x0001000000000000 - header: 9effff01000000000000 - - kid: 0x000000000000ffff - ctr: 0x00ffffffffffffff - header: 9effffffffffffffffff - - kid: 0x000000000000ffff - ctr: 0x0100000000000000 - header: 9fffff0100000000000000 - - kid: 0x000000000000ffff - ctr: 0xffffffffffffffff - header: 9fffffffffffffffffffff - - kid: 0x0000000000010000 - ctr: 0x0000000000000000 - header: a0010000 - - kid: 0x0000000000010000 - ctr: 0x0000000000000001 - header: a1010000 - - kid: 0x0000000000010000 - ctr: 0x00000000000000ff - header: a8010000ff - - kid: 0x0000000000010000 - ctr: 0x0000000000000100 - header: a90100000100 - - kid: 0x0000000000010000 - ctr: 0x000000000000ffff - header: a9010000ffff - - kid: 0x0000000000010000 - ctr: 0x0000000000010000 - header: aa010000010000 - - kid: 0x0000000000010000 - ctr: 0x0000000000ffffff - header: aa010000ffffff - - kid: 0x0000000000010000 - ctr: 0x0000000001000000 - header: ab01000001000000 - - kid: 0x0000000000010000 - ctr: 0x00000000ffffffff - header: ab010000ffffffff - - kid: 0x0000000000010000 - ctr: 0x0000000100000000 - header: ac0100000100000000 - - kid: 0x0000000000010000 - ctr: 0x000000ffffffffff - header: ac010000ffffffffff - - kid: 0x0000000000010000 - ctr: 0x0000010000000000 - header: ad010000010000000000 - - kid: 0x0000000000010000 - ctr: 0x0000ffffffffffff - header: ad010000ffffffffffff - - kid: 0x0000000000010000 - ctr: 0x0001000000000000 - header: ae01000001000000000000 - - kid: 0x0000000000010000 - ctr: 0x00ffffffffffffff - header: ae010000ffffffffffffff - - kid: 0x0000000000010000 - ctr: 0x0100000000000000 - header: af0100000100000000000000 - - kid: 0x0000000000010000 - ctr: 0xffffffffffffffff - header: af010000ffffffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000000000000 - header: a0ffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000000000001 - header: a1ffffff - - kid: 0x0000000000ffffff - ctr: 0x00000000000000ff - header: a8ffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000000000100 - header: a9ffffff0100 - - kid: 0x0000000000ffffff - ctr: 0x000000000000ffff - header: a9ffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000000010000 - header: aaffffff010000 - - kid: 0x0000000000ffffff - ctr: 0x0000000000ffffff - header: aaffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000001000000 - header: abffffff01000000 - - kid: 0x0000000000ffffff - ctr: 0x00000000ffffffff - header: abffffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000000100000000 - header: acffffff0100000000 - - kid: 0x0000000000ffffff - ctr: 0x000000ffffffffff - header: acffffffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0000010000000000 - header: adffffff010000000000 - - kid: 0x0000000000ffffff - ctr: 0x0000ffffffffffff - header: adffffffffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0001000000000000 - header: aeffffff01000000000000 - - kid: 0x0000000000ffffff - ctr: 0x00ffffffffffffff - header: aeffffffffffffffffffff - - kid: 0x0000000000ffffff - ctr: 0x0100000000000000 - header: afffffff0100000000000000 - - kid: 0x0000000000ffffff - ctr: 0xffffffffffffffff - header: afffffffffffffffffffffff - - kid: 0x0000000001000000 - ctr: 0x0000000000000000 - header: b001000000 - - kid: 0x0000000001000000 - ctr: 0x0000000000000001 - header: b101000000 - - kid: 0x0000000001000000 - ctr: 0x00000000000000ff - header: b801000000ff - - kid: 0x0000000001000000 - ctr: 0x0000000000000100 - header: b9010000000100 - - kid: 0x0000000001000000 - ctr: 0x000000000000ffff - header: b901000000ffff - - kid: 0x0000000001000000 - ctr: 0x0000000000010000 - header: ba01000000010000 - - kid: 0x0000000001000000 - ctr: 0x0000000000ffffff - header: ba01000000ffffff - - kid: 0x0000000001000000 - ctr: 0x0000000001000000 - header: bb0100000001000000 - - kid: 0x0000000001000000 - ctr: 0x00000000ffffffff - header: bb01000000ffffffff - - kid: 0x0000000001000000 - ctr: 0x0000000100000000 - header: bc010000000100000000 - - kid: 0x0000000001000000 - ctr: 0x000000ffffffffff - header: bc01000000ffffffffff - - kid: 0x0000000001000000 - ctr: 0x0000010000000000 - header: bd01000000010000000000 - - kid: 0x0000000001000000 - ctr: 0x0000ffffffffffff - header: bd01000000ffffffffffff - - kid: 0x0000000001000000 - ctr: 0x0001000000000000 - header: be0100000001000000000000 - - kid: 0x0000000001000000 - ctr: 0x00ffffffffffffff - header: be01000000ffffffffffffff - - kid: 0x0000000001000000 - ctr: 0x0100000000000000 - header: bf010000000100000000000000 - - kid: 0x0000000001000000 - ctr: 0xffffffffffffffff - header: bf01000000ffffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000000000000 - header: b0ffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000000000001 - header: b1ffffffff - - kid: 0x00000000ffffffff - ctr: 0x00000000000000ff - header: b8ffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000000000100 - header: b9ffffffff0100 - - kid: 0x00000000ffffffff - ctr: 0x000000000000ffff - header: b9ffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000000010000 - header: baffffffff010000 - - kid: 0x00000000ffffffff - ctr: 0x0000000000ffffff - header: baffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000001000000 - header: bbffffffff01000000 - - kid: 0x00000000ffffffff - ctr: 0x00000000ffffffff - header: bbffffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000000100000000 - header: bcffffffff0100000000 - - kid: 0x00000000ffffffff - ctr: 0x000000ffffffffff - header: bcffffffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0000010000000000 - header: bdffffffff010000000000 - - kid: 0x00000000ffffffff - ctr: 0x0000ffffffffffff - header: bdffffffffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0001000000000000 - header: beffffffff01000000000000 - - kid: 0x00000000ffffffff - ctr: 0x00ffffffffffffff - header: beffffffffffffffffffffff - - kid: 0x00000000ffffffff - ctr: 0x0100000000000000 - header: bfffffffff0100000000000000 - - kid: 0x00000000ffffffff - ctr: 0xffffffffffffffff - header: bfffffffffffffffffffffffff - - kid: 0x0000000100000000 - ctr: 0x0000000000000000 - header: c00100000000 - - kid: 0x0000000100000000 - ctr: 0x0000000000000001 - header: c10100000000 - - kid: 0x0000000100000000 - ctr: 0x00000000000000ff - header: c80100000000ff - - kid: 0x0000000100000000 - ctr: 0x0000000000000100 - header: c901000000000100 - - kid: 0x0000000100000000 - ctr: 0x000000000000ffff - header: c90100000000ffff - - kid: 0x0000000100000000 - ctr: 0x0000000000010000 - header: ca0100000000010000 - - kid: 0x0000000100000000 - ctr: 0x0000000000ffffff - header: ca0100000000ffffff - - kid: 0x0000000100000000 - ctr: 0x0000000001000000 - header: cb010000000001000000 - - kid: 0x0000000100000000 - ctr: 0x00000000ffffffff - header: cb0100000000ffffffff - - kid: 0x0000000100000000 - ctr: 0x0000000100000000 - header: cc01000000000100000000 - - kid: 0x0000000100000000 - ctr: 0x000000ffffffffff - header: cc0100000000ffffffffff - - kid: 0x0000000100000000 - ctr: 0x0000010000000000 - header: cd0100000000010000000000 - - kid: 0x0000000100000000 - ctr: 0x0000ffffffffffff - header: cd0100000000ffffffffffff - - kid: 0x0000000100000000 - ctr: 0x0001000000000000 - header: ce010000000001000000000000 - - kid: 0x0000000100000000 - ctr: 0x00ffffffffffffff - header: ce0100000000ffffffffffffff - - kid: 0x0000000100000000 - ctr: 0x0100000000000000 - header: cf01000000000100000000000000 - - kid: 0x0000000100000000 - ctr: 0xffffffffffffffff - header: cf0100000000ffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000000000000 - header: c0ffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000000000001 - header: c1ffffffffff - - kid: 0x000000ffffffffff - ctr: 0x00000000000000ff - header: c8ffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000000000100 - header: c9ffffffffff0100 - - kid: 0x000000ffffffffff - ctr: 0x000000000000ffff - header: c9ffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000000010000 - header: caffffffffff010000 - - kid: 0x000000ffffffffff - ctr: 0x0000000000ffffff - header: caffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000001000000 - header: cbffffffffff01000000 - - kid: 0x000000ffffffffff - ctr: 0x00000000ffffffff - header: cbffffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000000100000000 - header: ccffffffffff0100000000 - - kid: 0x000000ffffffffff - ctr: 0x000000ffffffffff - header: ccffffffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0000010000000000 - header: cdffffffffff010000000000 - - kid: 0x000000ffffffffff - ctr: 0x0000ffffffffffff - header: cdffffffffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0001000000000000 - header: ceffffffffff01000000000000 - - kid: 0x000000ffffffffff - ctr: 0x00ffffffffffffff - header: ceffffffffffffffffffffffff - - kid: 0x000000ffffffffff - ctr: 0x0100000000000000 - header: cfffffffffff0100000000000000 - - kid: 0x000000ffffffffff - ctr: 0xffffffffffffffff - header: cfffffffffffffffffffffffffff - - kid: 0x0000010000000000 - ctr: 0x0000000000000000 - header: d0010000000000 - - kid: 0x0000010000000000 - ctr: 0x0000000000000001 - header: d1010000000000 - - kid: 0x0000010000000000 - ctr: 0x00000000000000ff - header: d8010000000000ff - - kid: 0x0000010000000000 - ctr: 0x0000000000000100 - header: d90100000000000100 - - kid: 0x0000010000000000 - ctr: 0x000000000000ffff - header: d9010000000000ffff - - kid: 0x0000010000000000 - ctr: 0x0000000000010000 - header: da010000000000010000 - - kid: 0x0000010000000000 - ctr: 0x0000000000ffffff - header: da010000000000ffffff - - kid: 0x0000010000000000 - ctr: 0x0000000001000000 - header: db01000000000001000000 - - kid: 0x0000010000000000 - ctr: 0x00000000ffffffff - header: db010000000000ffffffff - - kid: 0x0000010000000000 - ctr: 0x0000000100000000 - header: dc0100000000000100000000 - - kid: 0x0000010000000000 - ctr: 0x000000ffffffffff - header: dc010000000000ffffffffff - - kid: 0x0000010000000000 - ctr: 0x0000010000000000 - header: dd010000000000010000000000 - - kid: 0x0000010000000000 - ctr: 0x0000ffffffffffff - header: dd010000000000ffffffffffff - - kid: 0x0000010000000000 - ctr: 0x0001000000000000 - header: de01000000000001000000000000 - - kid: 0x0000010000000000 - ctr: 0x00ffffffffffffff - header: de010000000000ffffffffffffff - - kid: 0x0000010000000000 - ctr: 0x0100000000000000 - header: df0100000000000100000000000000 - - kid: 0x0000010000000000 - ctr: 0xffffffffffffffff - header: df010000000000ffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000000000000 - header: d0ffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000000000001 - header: d1ffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x00000000000000ff - header: d8ffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000000000100 - header: d9ffffffffffff0100 - - kid: 0x0000ffffffffffff - ctr: 0x000000000000ffff - header: d9ffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000000010000 - header: daffffffffffff010000 - - kid: 0x0000ffffffffffff - ctr: 0x0000000000ffffff - header: daffffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000001000000 - header: dbffffffffffff01000000 - - kid: 0x0000ffffffffffff - ctr: 0x00000000ffffffff - header: dbffffffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000000100000000 - header: dcffffffffffff0100000000 - - kid: 0x0000ffffffffffff - ctr: 0x000000ffffffffff - header: dcffffffffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0000010000000000 - header: ddffffffffffff010000000000 - - kid: 0x0000ffffffffffff - ctr: 0x0000ffffffffffff - header: ddffffffffffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0001000000000000 - header: deffffffffffff01000000000000 - - kid: 0x0000ffffffffffff - ctr: 0x00ffffffffffffff - header: deffffffffffffffffffffffffff - - kid: 0x0000ffffffffffff - ctr: 0x0100000000000000 - header: dfffffffffffff0100000000000000 - - kid: 0x0000ffffffffffff - ctr: 0xffffffffffffffff - header: dfffffffffffffffffffffffffffff - - kid: 0x0001000000000000 - ctr: 0x0000000000000000 - header: e001000000000000 - - kid: 0x0001000000000000 - ctr: 0x0000000000000001 - header: e101000000000000 - - kid: 0x0001000000000000 - ctr: 0x00000000000000ff - header: e801000000000000ff - - kid: 0x0001000000000000 - ctr: 0x0000000000000100 - header: e9010000000000000100 - - kid: 0x0001000000000000 - ctr: 0x000000000000ffff - header: e901000000000000ffff - - kid: 0x0001000000000000 - ctr: 0x0000000000010000 - header: ea01000000000000010000 - - kid: 0x0001000000000000 - ctr: 0x0000000000ffffff - header: ea01000000000000ffffff - - kid: 0x0001000000000000 - ctr: 0x0000000001000000 - header: eb0100000000000001000000 - - kid: 0x0001000000000000 - ctr: 0x00000000ffffffff - header: eb01000000000000ffffffff - - kid: 0x0001000000000000 - ctr: 0x0000000100000000 - header: ec010000000000000100000000 - - kid: 0x0001000000000000 - ctr: 0x000000ffffffffff - header: ec01000000000000ffffffffff - - kid: 0x0001000000000000 - ctr: 0x0000010000000000 - header: ed01000000000000010000000000 - - kid: 0x0001000000000000 - ctr: 0x0000ffffffffffff - header: ed01000000000000ffffffffffff - - kid: 0x0001000000000000 - ctr: 0x0001000000000000 - header: ee0100000000000001000000000000 - - kid: 0x0001000000000000 - ctr: 0x00ffffffffffffff - header: ee01000000000000ffffffffffffff - - kid: 0x0001000000000000 - ctr: 0x0100000000000000 - header: ef010000000000000100000000000000 - - kid: 0x0001000000000000 - ctr: 0xffffffffffffffff - header: ef01000000000000ffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000000000000 - header: e0ffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000000000001 - header: e1ffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x00000000000000ff - header: e8ffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000000000100 - header: e9ffffffffffffff0100 - - kid: 0x00ffffffffffffff - ctr: 0x000000000000ffff - header: e9ffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000000010000 - header: eaffffffffffffff010000 - - kid: 0x00ffffffffffffff - ctr: 0x0000000000ffffff - header: eaffffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000001000000 - header: ebffffffffffffff01000000 - - kid: 0x00ffffffffffffff - ctr: 0x00000000ffffffff - header: ebffffffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000000100000000 - header: ecffffffffffffff0100000000 - - kid: 0x00ffffffffffffff - ctr: 0x000000ffffffffff - header: ecffffffffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0000010000000000 - header: edffffffffffffff010000000000 - - kid: 0x00ffffffffffffff - ctr: 0x0000ffffffffffff - header: edffffffffffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0001000000000000 - header: eeffffffffffffff01000000000000 - - kid: 0x00ffffffffffffff - ctr: 0x00ffffffffffffff - header: eeffffffffffffffffffffffffffff - - kid: 0x00ffffffffffffff - ctr: 0x0100000000000000 - header: efffffffffffffff0100000000000000 - - kid: 0x00ffffffffffffff - ctr: 0xffffffffffffffff - header: efffffffffffffffffffffffffffffff - - kid: 0x0100000000000000 - ctr: 0x0000000000000000 - header: f00100000000000000 - - kid: 0x0100000000000000 - ctr: 0x0000000000000001 - header: f10100000000000000 - - kid: 0x0100000000000000 - ctr: 0x00000000000000ff - header: f80100000000000000ff - - kid: 0x0100000000000000 - ctr: 0x0000000000000100 - header: f901000000000000000100 - - kid: 0x0100000000000000 - ctr: 0x000000000000ffff - header: f90100000000000000ffff - - kid: 0x0100000000000000 - ctr: 0x0000000000010000 - header: fa0100000000000000010000 - - kid: 0x0100000000000000 - ctr: 0x0000000000ffffff - header: fa0100000000000000ffffff - - kid: 0x0100000000000000 - ctr: 0x0000000001000000 - header: fb010000000000000001000000 - - kid: 0x0100000000000000 - ctr: 0x00000000ffffffff - header: fb0100000000000000ffffffff - - kid: 0x0100000000000000 - ctr: 0x0000000100000000 - header: fc01000000000000000100000000 - - kid: 0x0100000000000000 - ctr: 0x000000ffffffffff - header: fc0100000000000000ffffffffff - - kid: 0x0100000000000000 - ctr: 0x0000010000000000 - header: fd0100000000000000010000000000 - - kid: 0x0100000000000000 - ctr: 0x0000ffffffffffff - header: fd0100000000000000ffffffffffff - - kid: 0x0100000000000000 - ctr: 0x0001000000000000 - header: fe010000000000000001000000000000 - - kid: 0x0100000000000000 - ctr: 0x00ffffffffffffff - header: fe0100000000000000ffffffffffffff - - kid: 0x0100000000000000 - ctr: 0x0100000000000000 - header: ff010000000000000001000000000000 - 00 - - kid: 0x0100000000000000 - ctr: 0xffffffffffffffff - header: ff0100000000000000ffffffffffffff - ff - - kid: 0xffffffffffffffff - ctr: 0x0000000000000000 - header: f0ffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000000000000001 - header: f1ffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x00000000000000ff - header: f8ffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000000000000100 - header: f9ffffffffffffffff0100 - - kid: 0xffffffffffffffff - ctr: 0x000000000000ffff - header: f9ffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000000000010000 - header: faffffffffffffffff010000 - - kid: 0xffffffffffffffff - ctr: 0x0000000000ffffff - header: faffffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000000001000000 - header: fbffffffffffffffff01000000 - - kid: 0xffffffffffffffff - ctr: 0x00000000ffffffff - header: fbffffffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000000100000000 - header: fcffffffffffffffff0100000000 - - kid: 0xffffffffffffffff - ctr: 0x000000ffffffffff - header: fcffffffffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0000010000000000 - header: fdffffffffffffffff010000000000 - - kid: 0xffffffffffffffff - ctr: 0x0000ffffffffffff - header: fdffffffffffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0001000000000000 - header: feffffffffffffffff01000000000000 - - kid: 0xffffffffffffffff - ctr: 0x00ffffffffffffff - header: feffffffffffffffffffffffffffffff - - kid: 0xffffffffffffffff - ctr: 0x0100000000000000 - header: ffffffffffffffffff01000000000000 - 00 - - kid: 0xffffffffffffffff - ctr: 0xffffffffffffffff - header: ffffffffffffffffffffffffffffffff - ff - -D.2. AEAD encryption/decryption using AES-CTR and HMAC - - For each case, we provide: - - * cipher_suite: The index of the cipher suite in use (see - Section 8.1) - - * key: The key input to encryption/decryption - - * enc_key: The encryption subkey produced by the derive_subkeys() - algorithm - - * auth_key: The encryption subkey produced by the derive_subkeys() - algorithm - - * nonce: The nonce input to encryption/decryption - - * aad: The aad input to encryption/decryption - - * pt: The plaintext - - * ct: The ciphertext - - An implementation should verify that the following are true, where - AEAD.Encrypt and AEAD.Decrypt are as defined in Section 4.5.1: - - * AEAD.Encrypt(key, nonce, aad, pt) == ct - - * AEAD.Decrypt(key, nonce, aad, ct) == pt - - The other values in the test vector are intermediate values provided - to facilitate debugging of test failures. - - cipher_suite: 0x0001 - key: 000102030405060708090a0b0c0d0e0f - 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - enc_key: 000102030405060708090a0b0c0d0e0f - auth_key: 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - nonce: 101112131415161718191a1b - aad: 4945544620534672616d65205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 6339af04ada1d064688a442b8dc69d5b - 6bfa40f4bef0583e8081069cc60705 - - cipher_suite: 0x0002 - key: 000102030405060708090a0b0c0d0e0f - 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - enc_key: 000102030405060708090a0b0c0d0e0f - auth_key: 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - nonce: 101112131415161718191a1b - aad: 4945544620534672616d65205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 6339af04ada1d064688a442b8dc69d5b - 6bfa40f4be6e93b7da076927bb - - cipher_suite: 0x0003 - key: 000102030405060708090a0b0c0d0e0f - 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - enc_key: 000102030405060708090a0b0c0d0e0f - auth_key: 101112131415161718191a1b1c1d1e1f - 202122232425262728292a2b2c2d2e2f - nonce: 101112131415161718191a1b - aad: 4945544620534672616d65205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 6339af04ada1d064688a442b8dc69d5b - 6bfa40f4be09480509 - -D.3. SFrame encryption/decryption - - For each case, we provide: - - * cipher_suite: The index of the cipher suite in use (see - Section 8.1) - - * kid: A KID value - - * ctr: A CTR value - - * base_key: The base_key input to the derive_key_salt algorithm - - * sframe_key_label: The label used to derive sframe_key in the - derive_key_salt algorithm - - * sframe_salt_label: The label used to derive sframe_salt in the - derive_key_salt algorithm - - * sframe_secret: The sframe_secret variable in the derive_key_salt - algorithm - - * sframe_key: The sframe_key value produced by the derive_key_salt - algorithm - - * sframe_salt: The sframe_salt value produced by the derive_key_salt - algorithm - - * metadata: The metadata input to the SFrame encrypt algorithm - - * pt: The plaintext - - * ct: The SFrame ciphertext - - An implementation should verify that the following are true, where - encrypt and decrypt are as defined in Section 4.4, using an SFrame - context initialized with base_key assigned to kid: - - * encrypt(ctr, kid, metadata, plaintext) == ct - - * decrypt(metadata, ct) == pt - - The other values in the test vector are intermediate values provided - to facilitate debugging of test failures. - - cipher_suite: 0x0001 - kid: 0x0000000000000123 - ctr: 0x0000000000004567 - base_key: 000102030405060708090a0b0c0d0e0f - sframe_key_label: 534672616d6520312e30205365637265 - 74206b65792000000000000001230001 - sframe_salt_label: 534672616d6520312e30205365637265 - 742073616c7420000000000000012300 - 01 - sframe_secret: d926952ca8b7ec4a95941d1ada3a5203 - ceff8cceee34f574d23909eb314c40c0 - sframe_key: 3f7d9a7c83ae8e1c8a11ae695ab59314 - b367e359fadac7b9c46b2bc6f81f46e1 - 6b96f0811868d59402b7e870102720b3 - sframe_salt: 50b29329a04dc0f184ac3168 - metadata: 4945544620534672616d65205747 - nonce: 50b29329a04dc0f184ac740f - aad: 99012345674945544620534672616d65 - 205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 9901234567449408b6f490086165b9d6 - f62b24ae1a59a56486b4ae8ed036b889 - 12e24f11 - - cipher_suite: 0x0002 - kid: 0x0000000000000123 - ctr: 0x0000000000004567 - base_key: 000102030405060708090a0b0c0d0e0f - sframe_key_label: 534672616d6520312e30205365637265 - 74206b65792000000000000001230002 - sframe_salt_label: 534672616d6520312e30205365637265 - 742073616c7420000000000000012300 - 02 - sframe_secret: d926952ca8b7ec4a95941d1ada3a5203 - ceff8cceee34f574d23909eb314c40c0 - sframe_key: e2ec5c797540310483b16bf6e7a570d2 - a27d192fe869c7ccd8584a8d9dab9154 - 9fbe553f5113461ec6aa83bf3865553e - sframe_salt: e68ac8dd3d02fbcd368c5577 - metadata: 4945544620534672616d65205747 - nonce: e68ac8dd3d02fbcd368c1010 - aad: 99012345674945544620534672616d65 - 205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 99012345673f31438db4d09434e43afa - 0f8a2f00867a2be085046a9f5cb4f101 - d607 - - cipher_suite: 0x0003 - kid: 0x0000000000000123 - ctr: 0x0000000000004567 - base_key: 000102030405060708090a0b0c0d0e0f - sframe_key_label: 534672616d6520312e30205365637265 - 74206b65792000000000000001230003 - sframe_salt_label: 534672616d6520312e30205365637265 - 742073616c7420000000000000012300 - 03 - sframe_secret: d926952ca8b7ec4a95941d1ada3a5203 - ceff8cceee34f574d23909eb314c40c0 - sframe_key: 2c5703089cbb8c583475e4fc461d97d1 - 8809df79b6d550f78eb6d50ffa80d892 - 11d57909934f46f5405e38cd583c69fe - sframe_salt: 38c16e4f5159700c00c7f350 - metadata: 4945544620534672616d65205747 - nonce: 38c16e4f5159700c00c7b637 - aad: 99012345674945544620534672616d65 - 205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 990123456717fc8af28a5a695afcfc6c - 8df6358a17e26b2fcb3bae32e443 - - cipher_suite: 0x0004 - kid: 0x0000000000000123 - ctr: 0x0000000000004567 - base_key: 000102030405060708090a0b0c0d0e0f - sframe_key_label: 534672616d6520312e30205365637265 - 74206b65792000000000000001230004 - sframe_salt_label: 534672616d6520312e30205365637265 - 742073616c7420000000000000012300 - 04 - sframe_secret: d926952ca8b7ec4a95941d1ada3a5203 - ceff8cceee34f574d23909eb314c40c0 - sframe_key: d34f547f4ca4f9a7447006fe7fcbf768 - sframe_salt: 75234edefe07819026751816 - metadata: 4945544620534672616d65205747 - nonce: 75234edefe07819026755d71 - aad: 99012345674945544620534672616d65 - 205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 9901234567b7412c2513a1b66dbb4884 - 1bbaf17f598751176ad847681a69c6d0 - b091c07018ce4adb34eb - - cipher_suite: 0x0005 - kid: 0x0000000000000123 - ctr: 0x0000000000004567 - base_key: 000102030405060708090a0b0c0d0e0f - sframe_key_label: 534672616d6520312e30205365637265 - 74206b65792000000000000001230005 - sframe_salt_label: 534672616d6520312e30205365637265 - 742073616c7420000000000000012300 - 05 - sframe_secret: 0fc3ea6de6aac97a35f194cf9bed94d4 - b5230f1cb45a785c9fe5dce9c188938a - b6ba005bc4c0a19181599e9d1bcf7b74 - aca48b60bf5e254e546d809313e083a3 - sframe_key: d3e27b0d4a5ae9e55df01a70e6d4d28d - 969b246e2936f4b7a5d9b494da6b9633 - sframe_salt: 84991c167b8cd23c93708ec7 - metadata: 4945544620534672616d65205747 - nonce: 84991c167b8cd23c9370cba0 - aad: 99012345674945544620534672616d65 - 205747 - pt: 64726166742d696574662d736672616d - 652d656e63 - ct: 990123456794f509d36e9beacb0e261d - 99c7d1e972f1fed787d4049f17ca2135 - 3c1cc24d56ceabced279 - -Contributors - - Frederic Jacobs - Apple - Email: frederic.jacobs@apple.com - - - Marta Mularczyk - Amazon - Email: mulmarta@amazon.com - - - Suhas Nandakumar - Cisco - Email: snandaku@cisco.com - - - Tomas Rigaux - Cisco - Email: trigaux@cisco.com - - - Raphael Robert - Phoenix R&D - Email: ietf@raphaelrobert.com - - -Authors' Addresses - - Emad Omara - Apple - Email: eomara@apple.com - - - Justin Uberti - Google - Email: juberti@google.com - - - Sergio Garcia Murillo - CoSMo Software - Email: sergio.garcia.murillo@cosmosoftware.io - - - Richard L. Barnes (editor) - Cisco - Email: rlb@ipv.sx - - - Youenn Fablet - Apple - Email: youenn@apple.com diff --git a/secdir/index.html b/secdir/index.html deleted file mode 100644 index 553b2e0..0000000 --- a/secdir/index.html +++ /dev/null @@ -1,45 +0,0 @@ - - - - sframe-wg/sframe secdir preview - - - - -

Editor's drafts for secdir branch of sframe-wg/sframe

- - - - - - -
SFrameplain textsame as main
- - - diff --git a/secdir/draft-ietf-sframe-enc.html b/warren/draft-ietf-sframe-enc.html similarity index 99% rename from secdir/draft-ietf-sframe-enc.html rename to warren/draft-ietf-sframe-enc.html index 0e7da8e..42049e6 100644 --- a/secdir/draft-ietf-sframe-enc.html +++ b/warren/draft-ietf-sframe-enc.html @@ -20,12 +20,12 @@ it is independent of RTP (thus compatible with non-RTP media transport) and can be applied to whole media frames in order to be more bandwidth efficient. " name="description"> - +