]> Cisco

rlb@ipv.sx

Apple

eomara@apple.com

Apple

aron.rosenberg@apple.com

Applications and Real-Time Secure Media Frames SFrame cryptography This document addresses two omissions in the Secure Frames (SFrame) protocol specification. First, the definition of the IANA registry for SFrame ciphersuites omits several important fields. This document requests that IANA add those fields and defines the contents of those fields for current entries. Second, the AEAD construction based on AES-CTR and HMAC is defined only for the 128-bit security level. This document registers parallel constructions at the 256-bit security level. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Secure Media Frames Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Secure Frames (SFrame) protocol specification defines an IANA registry for cipher suites. The initial definition in is missing several important fields. This document requests that IANA add those fields and defines the contents of those fields for current entries. We also define new entries that extend the SFrame CTR+HMAC construction to support AES-256. This document addresses two omissions in the Secure Frames (SFrame) protocol specification . First, the definition in of the IANA registry for SFrame ciphersuites omits several important fields. This document requests that IANA add those fields and defines the contents of those fields for current entries. Second, the AEAD construction based on AES-CTR and HMAC (in ) is defined only for the 128-bit security level. This document registers parallel constructions at the 256-bit security level.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

AES-256-CTR with HMAC-SHA512 defines a compound authenticated encryption construction, using the unauthenticated CTR mode of AES for encryption and HMAC for authentication. The original specification only defines cipher suite values for instances of this construction using AES-128-CTR and HMAC-SHA256. The construction works the same way when used with AES-256-CTR and HMAC-SHA512. The only differences are in the lengths of some SFrame-internal fields:

• The keys generated by SFrame-internal key derivation (derive_key_salt) are longer to match the needs of AES-256-CTR and HMAC-SHA512 (96 bytes vs 48 bytes for AES-128-CTR and HMAC-SHA256).
• The initial tag value tag in compute_tag is 64 bytes instead of 32 bytes.

Identifiers for cipher suites using AES-256-CTR and HMAC-SHA512 are defined in .

Security Considerations The registry changes in this document have no affect on the security of SFrame. The new algorithms registered by this document allow the CTR+HMAC construction to be used in environments that require a 256-bit security level.

IANA Considerations This document makes three requests of IANA: Updating the columns in the "SFrame Cipher Suites" registry, adding entries to the updated registry for the new cipher suites defined in this document, and add this document as an additional reference for this registry."

"SFrame Cipher Suites" Registry Update The SFrame Cipher Suites registry should be updated to add the following columns:

• Nh: The size in bytes of the output of the hash function
• Nka: For cipher suites using the compound AEAD described in , the size in bytes of a key for the underlying encryption algorithm
• Nk: The size in bytes of a key for the encryption algorithm
• Nn: The size in bytes of a nonce for the encryption algorithm
• Nt: The overhead in bytes of the encryption algorithm (typically the size of a "tag" that is added to the plaintext)

illustrates the new structure of the registry, and provides the required values for the currently registered entries. New structure and contents of the SFrame Cipher Suites registry

Value	Name	Nh	Nka	Nk	Nn	Nt	R	Reference	Change Controller
0x0000	Reserved	-	-	-	-	-	-	RFC 9605	IETF
0x0001	AES_128_CTR_HMAC_SHA256_80	32	16	48	12	10	Y	RFC 9605	IETF
0x0002	AES_128_CTR_HMAC_SHA256_64	32	16	48	12	8	Y	RFC 9605	IETF
0x0003	AES_128_CTR_HMAC_SHA256_32	32	16	48	12	4	Y	RFC 9605	IETF
0x0004	AES_128_GCM_SHA256_128	32	n/a	16	12	16	Y	RFC 9605	IETF
0x0005	AES_256_GCM_SHA512_128	64	n/a	32	12	16	Y	RFC 9605	IETF
0xF000 - 0xFFFF	Reserved for Private Use	-	-	-	-	-	-	RFC 9605	IETF

Cipher Suites for AES-256-CTR with HMAC-SHA512 The following new entries should be added to the SFrame Cipher Suites registry: New entries SFrame Cipher Suites registry

Value	Name	Nh	Nka	Nk	Nn	Nt	R	Reference	Change Controller
0x0006	AES_256_CTR_HMAC_SHA512_80	64	32	96	12	10	Y	RFC XXXX	IETF
0x0007	AES_256_CTR_HMAC_SHA512_64	64	32	96	12	8	Y	RFC XXXX	IETF
0x0008	AES_256_CTR_HMAC_SHA512_32	64	32	96	12	4	Y	RFC XXXX	IETF

References Normative References 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. This 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. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References

Test Vectors This section provides a set of test vectors that implementations can use to verify that they correctly implement SFrame encryption and decryption with the cipher suites registered in this document. Test vectors are provided for both the AES-256-CTR-HMAC construction and for full SFrame encryption with the new cipher suites. 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 . 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.

AEAD Encryption/Decryption Using AES-CTR and HMAC For each case, we provide:

• cipher_suite: The index of the cipher suite in use (see )
• key: The key input to encryption/decryption
• enc_key: The encryption subkey produced by the derive_subkeys() algorithm
• auth_key: The authentication 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 :

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

SFrame Encryption/Decryption For each case, we provide:

• cipher_suite: The index of the cipher suite in use (see )
• 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 , 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.