[AVTCORE] header extensions and draft-ietf-avtcore-srtp-aes-gcm-04.txt

["Igoe, Kevin M." <[e-mail]>]

If the header extensions are to use the same key as the
AEAD but with different salts, I've got a problem with
preventing IV reuse.  Currently the IV's are formed by

               0  0  0  0  0  0  0  0  0  0  1  1
               0  1  2  3  4  5  6  7  8  9  0  1
             +--+--+--+--+--+--+--+--+--+--+--+--+
             |00|00|    SSRC   |     ROC   | SEQ |---+
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
                                                     |
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
             |      SRTP Encryption Salt         |->(+)
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
                                                     |
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
             |       Initialization Vector       |<--+
             +--+--+--+--+--+--+--+--+--+--+--+--+

           Figure 1: AES-GCM and AES-CCM SRTP
                     Initialization Vector formation.

and your proposal for header extensions seems to call for
the IV to be

               0  0  0  0  0  0  0  0  0  0  1  1
               0  1  2  3  4  5  6  7  8  9  0  1
             +--+--+--+--+--+--+--+--+--+--+--+--+
             |00|00|    SSRC   |     ROC   | SEQ |---+
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
                                                     |
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
             |       HE Encryption Salt          |->(+)
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
                                                     |
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
             |       Initialization Vector       |<--+
             +--+--+--+--+--+--+--+--+--+--+--+--+

We MUST insure the IV's are all distinct, so even between packets
with different SSRC, ROC and SEQ we must insure

     base_0 XOR SRTP_SALT != base_1 XOR HE_SALT_1

where base_i = 0x0000 || SSRC_i || ROC_i || SEQ_i.

We have a problem whenever HE_SALT XOR SRTP_SALT = base_0 XOR base_1.

I believe we can avoid this by playing games with the most significant
bytes of the SALT {and hence of the IV, since he base starts with 0x00).

For SRTP, force the msB of the SRTP salt to be 0x0000 by taking
the msB of the SRTP salt to be 0x00:

               0  0  0  0  0  0  0  0  0  0  1  1
               0  1  2  3  4  5  6  7  8  9  0  1
             +--+--+--+--+--+--+--+--+--+--+--+--+
             |00|00|    SSRC   |     ROC   | SEQ |---+
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
                                                     |
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
             |00|     SRTP Encryption Salt        |->(+)
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
                                                     |
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
             |    SRTP Initialization Vector     |<--+
             +--+--+--+--+--+--+--+--+--+--+--+--+

so the high order byte of the IV is 0x00,

When we are using a 1-byte extentsion element headers,
the extension starts with the byte HH = ID ||L (both ID
and L are 4 bits each), so we proceed as below:

               0  0  0  0  0  0  0  0  0  0  1  1
               0  1  2  3  4  5  6  7  8  9  0  1
             +--+--+--+--+--+--+--+--+--+--+--+--+
             |00|00|    SSRC   |     ROC   | SEQ |---+
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
                                                     |
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
             |HH|     HE Encryption Salt         |->(+)
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
                                                     |
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
             |    HE Initialization Vector       |<--+
             +--+--+--+--+--+--+--+--+--+--+--+--+

so the first nibble of the IV is the ID.

For 2-byte extension headers, we have an 8-bit ID, so we use


               0  0  0  0  0  0  0  0  0  0  1  1
               0  1  2  3  4  5  6  7  8  9  0  1
             +--+--+--+--+--+--+--+--+--+--+--+--+
             |00|00|    SSRC   |     ROC   | SEQ |---+
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
                                                     |
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
             |ID|     HE Encryption Salt         |->(+)
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
                                                     |
             +--+--+--+--+--+--+--+--+--+--+--+--+   |
             |    HE Initialization Vector       |<--+
             +--+--+--+--+--+--+--+--+--+--+--+--+

and hence the first byte of the IV is the ID.

Since the ID is never allowed to be zero, and recalling that a given
session never mixes 1-byte and 2-byte extensions, the inclusion of the ID
directly in the IV insures all of the IV's are distinct.

I presume the ID and length fields are to be sent in the clear?
I'd recommend that AEAD treat them as AAD.  Indeed, it would be
prudent to have AEAD treat the encrypted header extension data
field as AAD.  This eliminates all sorts of potential spoofing
attack worries.

What do you think?





From: Jonathan Lennox [mailto:[e-mail]]
Sent: Wednesday, February 06, 2013 5:23 PM
To: Igoe, Kevin M.
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-04.txt

Sorry, I was probably too brief in my comment.  I was specifically referring to draft-ietf-avtcore-srtp-encrypted-header-ext (currently in AD review), which works out all these issues but adds a requirement that new SRTP encryption transforms define how they generate the encrypted header keystream.

I've attached my e-mail exchange with David from the aes-gcm WGLC, which includes text I proposed be added to the aes-gcm draft.


On Feb 6, 2013, at 3:44 PM, Igoe, Kevin M. wrote:

> I'm not sure I understand header extensions well enough to come up with
> a "one size fits all" solution.  Which parts are to be treated as PT
> to be encrypted and authenticated, which as additional authenticated data
> to be only authenticated, and which as raw data?  Will this change form
> one flavor of extension to another?  I hope to tap your expertise on
> these points.
>
> RFC 5283 talks about the presence and format of a header extension being
> negotiated out-of-band.  The best solution I can think of is that this
> out-of-band negotiation should also decide how AEAD will treat the various
> fields in the header extension.  If that is sufficient for our needs, then
> I believe we can add that in w/o too much trouble.  But I really don't want
> to get bogged down in how the out-of-band negotiation is to be done.
>
> Another point I'd like your input on: does the requirement that the AEAD
> authentication tag MUST be validated before any of the cipher is decrypted
> or any of the AAD be processed in any way cause problems for existing header
> extensions?
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Jonathan Lennox
>> Sent: Monday, February 04, 2013 6:00 PM
>> To: IETF AVTCore WG
>> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-
>> 04.txt
>>
>> This new version still doesn't appear to have any text about header
>> extension encryption.  Is there a reason this was omitted?
>>
>> On Feb 4, 2013, at 1:14 PM, <[e-mail]> wrote:
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>> This draft is a work item of the Audio/Video Transport Core
>> Maintenance Working Group of the IETF.
>>>
>>>      Title           : AES-GCM and AES-CCM Authenticated Encryption in
>> Secure RTP (SRTP)
>>>      Author(s)       : David A. McGrew
>>>                         Kevin M. Igoe
>>>      Filename        : draft-ietf-avtcore-srtp-aes-gcm-04.txt
>>>      Pages           : 28
>>>      Date            : 2013-02-04
>>>
>>> Abstract:
>>>  This document defines how AES-GCM and AES-CCM Authenticated
>>>  Encryption with Associated Data algorithms can be used to provide
>>>  confidentiality and data authentication in the SRTP protocol.
>>>
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm
>>>
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-04
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-srtp-aes-gcm-04
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> Audio/Video Transport Core Maintenance
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/avt
>>>
>>
>> --
>> Jonathan Lennox
>> [e-mail]
>>
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/avt

--
Jonathan Lennox
[e-mail]