1.1.Problem Statement

The Secure Real-time Transport Protocol (SRTP)[RFC3711] mechanism provides messageauthentication for the entire RTP packet but only encrypts the RTP payload.This has not historically been a problem, as much of the information carriedin the header has minimal sensitivity (e.g., RTP timestamp); in addition,certain fields need to remain as cleartext because they are used for keyscheduling (e.g., RTP synchronization source (SSRC) and sequence number).¶

However, as noted in[RFC6904], the security requirements can be different forinformation carried in RTP header extensions, including the per-packet soundlevels defined in[RFC6464] and[RFC6465], which are specifically noted asbeing sensitive in the Security Considerations sections of those RFCs.¶

In addition to the contents of the header extensions, there are now enoughheader extensions in active use that the header extension identifiersthemselves can provide meaningful information in terms of determining theidentity of the endpoint and/or application. Accordingly, these identifierscan be considered a fingerprinting issue.¶

Finally, the CSRCs included in RTP packets can also be sensitive, potentiallyallowing a network eavesdropper to determine who was speaking and when duringan otherwise secure conference call.¶

1.2.Previous Solutions

Encryption of Header Extensions in SRTP[RFC6904] was proposed in 2013 as a solution to the problem of unprotectedheader extension values. However, it has not seen significant adoption andhas a few technical shortcomings.¶

First, the mechanism is complicated. Since it allows encryption to benegotiated on a per-extension basis, a fair amount of signaling logic isrequired. And in the SRTP layer, a somewhat complex transform is requiredto allow only the selected header extension values to be encrypted. One ofthe most popular SRTP implementations had a significant bug in this areathat was not detected for five years.¶

Second, the mechanism only protects the header extension values and not their identifiers orlengths. It also does not protect the CSRCs. As noted above, this leavesa fair amount of potentially sensitive information exposed.¶

Third, the mechanism bloats the header extension space. Because each extension mustbe offered in both unencrypted and encrypted forms, twice as many headerextensions must be offered, which will in many cases push implementationspast the 14-extension limit for the use of one-byte extension headersdefined in[RFC8285]. Accordingly, in many cases, implementations will need to usetwo-byte headers, which are not supported well by someexisting implementations.¶

Finally, the header extension bloat combined with the need for backwardcompatibility results in additional wire overhead. Because two-byteextension headers may not be handled well by existing implementations,one-byte extension identifiers will need to be used for the unencrypted(backward-compatible) forms, and two-byte for the encrypted forms.Thus, deployment of encryption for header extensions[RFC6904] willtypically result in multiple extra bytes in each RTP packet, comparedto the present situation.¶

1.3.Goals

From the previous analysis, the desired properties of a solution are:¶

• Built on the existing SRTP framework[RFC3711] (simple to understand)¶
• Built on the existing header extension framework[RFC8285] (simple to implement)¶
• Protection of header extension identifiers, lengths, and values¶
• Protection of CSRCs when present¶
• Simple signaling¶
• Simple crypto transform and SRTP interactions¶
• Backward compatibility with unencrypted endpoints, if desired¶
• Backward compatibility with existing RTP tooling¶

The last point deserves further discussion. While other possible solutions that would have encrypted more of the RTP header (e.g., the number of CSRCs) were considered, the inability to parse the resultant packets with current tools and a generally higher level of complexity outweighed the slight improvement in confidentiality in these solutions. Hence, a more pragmatic approach was taken to solve the problem described inSection 1.1.¶

5.1.Sending

When the mechanism defined by this specification has been negotiated,sending an RTP packet that has any CSRCs or contains any header extensions[RFC8285] follows the steps below. This mechanismMUST NOT beused with header extensions other than the variety described in[RFC8285].¶

If the RTP packet contains one-byte headers, the 16-bit RTP header extension tagMUST be set to 0xC0DE to indicate that the encryption has been applied and the one-byte framing is being used. If the RTP packet contains two-byte headers, the header extension tagMUST be set to 0xC2DE to indicate encryption has been applied and the two-byte framing is being used.¶

If the packet contains CSRCs but no header extensions, an empty extension blockconsisting of the 0xC0DE tag and a 16-bit length field set to zero (explicitlypermitted by[RFC3550])MUST be appended, and the X bitMUST be set to 1 toindicate an extension block is present. This is necessary to provide the receiveran indication that the CSRCs in the packet are encrypted.¶

The RTP packetMUST then be encrypted as described inSection 6.2 ("Encryption Procedure").¶

5.2.Receiving

When receiving an RTP packet that contains header extensions, the"defined by profile" fieldMUST be checked to ensure the payload isformatted according to this specification. If the field does not matchone of the values defined above, the implementationMUST insteadhandle it according to the specification that defines that value.¶

Alternatively, if the implementation considers the use of this specification mandatory and the "defined by profile" field does not match one of the values defined above, itMUST stop the processing of the RTP packet and report an error for the RTP stream.¶

If the RTP packet passes this check, it is then decrypted as described inSection 6.3 ("Decryption Procedure") and passed to the next layer to processthe packet and its extensions. In the event that a zero-length extensionblock was added as indicated above, it can be left as is and will beprocessed normally.¶

6.1.Packet Structure

When this mechanism is active, the SRTP packet is protected as follows:¶

   0                   1                   2                   3   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+  |V=2|P|X|  CC   |M|     PT      |       sequence number         | |  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  |                           timestamp                           | |  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  |           synchronization source (SSRC) identifier            | |+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ || |            contributing source (CSRC) identifiers             | || |                               ....                            | |+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |X |  0xC0 or 0xC2 |    0xDE       |           length              | |+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || |                  RFC 8285 header extensions                   | || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || |                          payload  ...                         | || |                               +-------------------------------+ || |                               | RTP padding   | RTP pad count | |+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+| ~          SRTP Master Key Identifier (MKI) (OPTIONAL)          ~ || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || :                 authentication tag (RECOMMENDED)              : || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ||                                                                   |+- Encrypted Portion                       Authenticated Portion ---+

Note that, as required by[RFC8285], the 4 bytes at the start of the extension block are not encrypted.¶

Specifically, the Encrypted PortionMUST include any CSRC identifiers, anyRTP header extension (except for the first 4 bytes), and the RTP payload.¶

6.2.Encryption Procedure

The encryption procedure is identical to that of[RFC3711] except for the Encrypted Portion of the SRTP packet. The plaintext input to the cipher is as follows:¶

Plaintext = CSRC identifiers (if used) || header extension data ||     RTP payload || RTP padding (if used) || RTP pad count (if used)

Here "header extension data" refers to the content of the RTP extension field,excluding the first four bytes (the extension header[RFC8285]). The first4 * CSRC count (CC) bytes of the ciphertext are placed in the CSRC field of the RTP header.The remainder of the ciphertext is the RTP payload of the encrypted packet.¶

To minimize changes to surrounding code, the encryption mechanism can chooseto replace a "defined by profile" field from[RFC8285] with its counterpartdefined inSection 5 ("RTP Header Processing") and encrypt at the same time.¶

For Authenticated Encryption with Associated Data (AEAD) ciphers (e.g., AES-GCM), the 12-byte fixed header and the four-byte headerextension header (the "defined by profile" field and the length) are consideredadditional authenticated data (AAD), even though they are non-contiguous in the packet if CSRCs are present.¶

Associated Data: fixed header || extension header (if X=1)

Here "fixed header" refers to the 12-byte fixed portion of the RTP header, and"extension header" refers to the four-byte extension header[RFC8285] ("definedby profile" and extension length).¶

Implementations can rearrange a packet so that the AAD and plaintext arecontiguous by swapping the order of the extension header and the CSRCidentifiers, resulting in an intermediate representation of the form shown inFigure 2. After encryption, the CSRCs (now encrypted) andextension header would need to be swapped back to their original positions. Asimilar operation can be done when decrypting to create contiguous ciphertextand AAD inputs.¶

   0                   1                   2                   3   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+  |V=2|P|X|  CC   |M|     PT      |       sequence number         | |  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  |                           timestamp                           | |  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  |           synchronization source (SSRC) identifier            | |  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  |  0xC0 or 0xC2 |    0xDE       |           length              | |+>+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+<+| |            contributing source (CSRC) identifiers             | || |                               ....                            | || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || |                  RFC 8285 header extensions                   | || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ || |                          payload  ...                         | || |                               +-------------------------------+ || |                               | RTP padding   | RTP pad count | |+>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ||                                                                   |+- Plaintext Input                                     AAD Input ---+

Note that this intermediate representation is only displayed as reference for implementations and is not meant to be sent on the wire.¶

6.3.Decryption Procedure

The decryption procedure is identical to that of[RFC3711] exceptfor the Encrypted Portion of the SRTP packet, which is as shown in the section above.¶

To minimize changes to surrounding code, the decryption mechanism can chooseto replace the "defined by profile" field with its no-encryption counterpartfrom[RFC8285] and decrypt at the same time.¶

A.1.AES-CTR

The following subsections list the test vectors for using Cryptex with AES-CTR as per[RFC3711].¶

Common values are organized as follows:¶

Rollover Counter:          00000000Master Key:                e1f97a0d3e018be0d64fa32c06de4139Master Salt:               0ec675ad498afeebb6960b3aabe6Crypto Suite:              AES_CM_128_HMAC_SHA1_80Session Key:               c61e7a93744f39ee10734afe3ff7a087Session Salt:              30cbbc08863d8c85d49db34a9ae1Authentication Key:        cebe321f6ff7716b6fd4ab49af256a156d38baa4

    900f1235    decafbad    cafebabe    bede0001    51000200    abababab    abababab    abababab    abababab

    900f1235    decafbad    cafebabe    c0de0001    eb923652    51c3e036    f8de27e9    c27ee3e0    b4651d9f    bc4218a7    0244522f    34a5

    900f1236    decafbad    cafebabe    10000001    05020002    abababab    abababab    abababab    abababab

    900f1236    decafbad    cafebabe    c2de0001    4ed9cc4e    6a712b30    96c5ca77    339d4204    ce0d7739    6cab6958    5fbce381    94a5

    920f1238    decafbad    cafebabe    0001e240    0000b26e    bede0001    51000200    abababab    abababab    abababab    abababab

    920f1238    decafbad    cafebabe    8bb6e12b    5cff16dd    c0de0001    92838c8c    09e58393    e1de3a9a    74734d67    45671338    c3acf11d    a2df8423    bee0

    920f1239    decafbad    cafebabe    0001e240    0000b26e    10000001    05020002    abababab    abababab    abababab    abababab

    920f1239    decafbad    cafebabe    f70e513e    b90b9b25    c2de0001    bbed4848    faa64466    5f3d7f34    125914e9    f4d0ae92    3c6f479b    95a0f7b5    3133

    920f123a    decafbad    cafebabe    0001e240    0000b26e    bede0000    abababab    abababab    abababab    abababab

    920f123a    decafbad    cafebabe    7130b6ab    fe2ab0e3    c0de0000    e3d9f64b    25c9e74c    b4cf8e43    fb92e378    1c2c0cea    b6b3a499    a14c

    920f123b    decafbad    cafebabe    0001e240    0000b26e    10000000    abababab    abababab    abababab    abababab

    920f123b    decafbad    cafebabe    cbf24c12    4330e1c8    c2de0000    599dd45b    c9d687b6    03e8b59d    771fd38e    88b170e0    cd31e125    eabe

A.2.AES-GCM

The following subsections list the test vectors for using Cryptex with AES-GCM as per[RFC7714].¶

Common values are organized as follows:¶

    Rollover Counter:          00000000    Master Key:                000102030405060708090a0b0c0d0e0f    Master Salt:               a0a1a2a3a4a5a6a7a8a9aaab    Crypto Suite:              AEAD_AES_128_GCM    Session Key:               077c6143cb221bc355ff23d5f984a16e    Session Salt:              9af3e95364ebac9c99c5a7c4

    900f1235    decafbad    cafebabe    bede0001    51000200    abababab    abababab    abababab    abababab

    900f1235    decafbad    cafebabe    c0de0001    39972dc9    572c4d99    e8fc355d    e743fb2e    94f9d8ff    54e72f41    93bbc5c7    4ffab0fa    9fa0fbeb

    900f1236    decafbad    cafebabe    10000001    05020002    abababab    abababab    abababab    abababab

    900f1236    decafbad    cafebabe    c2de0001    bb75a4c5    45cd1f41    3bdb7daa    2b1e3263    de313667    c9632490    81b35a65    f5cb6c88    b394235f

    920f1238    decafbad    cafebabe    0001e240    0000b26e    bede0001    51000200    abababab    abababab    abababab    abababab

    920f1238    decafbad    cafebabe    63bbccc4    a7f695c4    c0de0001    8ad7c71f    ac70a80c    92866b4c    6ba98546    ef913586    e95ffaaf    fe956885    bb0647a8    bc094ac8

    920f1239    decafbad    cafebabe    0001e240    0000b26e    10000001    05020002    abababab    abababab    abababab    abababab

    920f1239    decafbad    cafebabe    3680524f    8d312b00    c2de0001    c78d1200    38422bc1    11a7187a    18246f98    0c059cc6    bc9df8b6    26394eca    344e4b05    d80fea83

    920f123a    decafbad    cafebabe    0001e240    0000b26e    bede0000    abababab    abababab    abababab    abababab

    920f123a    decafbad    cafebabe    15b6bb43    37906fff    c0de0000    b7b96453    7a2b03ab    7ba5389c    e9331712    6b5d974d    f30c6884    dcb651c5    e120c1da

    920f123b    decafbad    cafebabe    0001e240    0000b26e    10000000    abababab    abababab    abababab    abababab

    920f123b    decafbad    cafebabe    dcb38c9e    48bf95f4    c2de0000    61ee432c    f9203170    76613258    d3ce4236    c06ac429    681ad084    13512dc9    8b5207d8