diff --git a/auth48/draft-ietf-sframe-enc.html b/auth48/draft-ietf-sframe-enc.html index ca6d45d..ca9bebf 100644 --- a/auth48/draft-ietf-sframe-enc.html +++ b/auth48/draft-ietf-sframe-enc.html @@ -4,16 +4,14 @@ -Secure Frame (SFrame) +Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-Time Media - + CoSMo Software
-
R. L. Barnes, Ed. +
R. Barnes, Ed.
Cisco
@@ -1089,7 +1087,7 @@
-

Secure Frame (SFrame)

+

Secure Frame (SFrame): Lightweight Authenticated Encryption for Real-Time Media

Abstract

This document describes the Secure Frame (SFrame) end-to-end encryption and @@ -1786,12 +1784,12 @@

Extended Counter Flag (Y, 1 bit):
-

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

+

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 +

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

@@ -1954,9 +1952,9 @@

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

+the next CTR value 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, +and the CTR value 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 @@ -2018,7 +2016,7 @@

SFrame encryption uses the AEAD encryption algorithm for the cipher suite in use. The key for the encryption is the sframe_key. The nonce is formed by first XORing -the sframe_salt with the current counter, and then encoding the result as a big-endian integer of +the sframe_salt with the current CTR value, and then encoding the result 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 @@ -2427,7 +2425,7 @@

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 synchronization source (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". +

KID values 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:

@@ -2445,7 +2443,7 @@

when they need to ratchet (vs. expecting a new key). R effectively defines a reordering 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.

+bits of the KID.

 KID = (key_generation << R) + (ratchet_step % (1 << R))
@@ -2493,7 +2491,7 @@ 

 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
+
It is the application's responsibility 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,
@@ -2538,7 +2536,7 @@ 

 
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
+the KID value are a context value chosen by the sender (context value 0 will
 produce the shortest encoded KID).

 

 
@@ -2720,11 +2718,12 @@ 

 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 Media Identification (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.

+by either SSRC or Media Identification (MID)) may carry media from different
+streams of different participants. Because each participant uses a different key
+to encrypt their media, the receiver will be able to verify the sender of the
+media within the RTP stream at any given point in time. Thus the receiver will
+correctly associate the media with the sender indicated by the authenticated
+SFrame KID value, irrespective of how the SFU transmits the media to the client.

 
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.

@@ -2737,7 +2736,7 @@ 

           

 
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.

+frame encryptor and assigned an unique CTR value for each.

@@ -2799,8 +2798,8 @@

7.1. No Header Confidentiality

-

SFrame provides integrity protection to the SFrame header (the Key ID and -counter values), but it does not provide confidentiality protection. Parties that +

SFrame provides integrity protection to the SFrame header (the KID and +CTR values), but it 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 @@ -3035,7 +3034,7 @@

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 +versions of SFrame are defined in the future, it will be the application's responsibility 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 @@ -3069,12 +3068,12 @@

9.2. Key Management Framework

-

It is up to the application to provision SFrame with a mapping of KID values to +

The application is responsible for provisioning 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 +

The application is also responsible for defining a rotation schedule for keys. For example, one application might have an ephemeral group for every call and keep rotating keys when endpoints join or leave the call, while another application could have a persistent group that can be used for multiple calls and simply @@ -3108,7 +3107,7 @@

9.4. Metadata

The metadata input to SFrame operations an opaque byte string specified by the application. As -such, it is up to the application to define what information should go in the +such, the application needs 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 @@ -3243,7 +3242,7 @@

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

    +used to initialize a send context, together with a zero CTR value.

  • Add a key for receiving: The key and salt are derived from the base key and @@ -3397,13 +3396,13 @@

    of the Opus codec [RFC6716]:

    • -

      Narrow-band (NB) speech: 120 ms packets, 8 kbps

      +

      Narrow-band (NB) speech: 120 ms packets (8 frames per second (fps)), 8 kbps

    • -

      Full-band (FB) speech: 20 ms packets, 32 kbps

      +

      Full-band (FB) speech: 20 ms packets (32 fps), 32 kbps

    • -

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

      +

      Full-band stereo music: 10 ms packets (100 fps), 128 kbps

    @@ -3415,7 +3414,7 @@

    Scenario - Frames per Second (fps) + fps Base kbps Overhead kbps Overhead % @@ -6296,7 +6295,7 @@

    -
    Richard L. Barnes (editor)
    +
    Richard Barnes (editor)
    Cisco