Subject: Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14

From: Ben Campbell <[email-masked]>
Date: Thu, 11 Sep 2014 18:19:44 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  
draft-ietf-avtcore-srtp-aes-gcm-14
Reviewer: Ben Campbell
Review Date: 2014-09-11
IETF LC End Date: 2014-09-11

Summary: This draft is almost ready for publication as a proposed standard, but there are open issues that should be addressed first.

Note: I have not attempted to verify the pseudocode fragments in this draft. 

Major issues:

[Note: I am on the fence on whether the following is a major or minor issue. I put it in the major section to draw attention to it, but I am prepared to downgrade it if discussion seems to suggest doing so.]

-- Section 9.4, SSRC Management

If I read this section correctly, the draft requires central management of SSRC values when you have a master key shared among endpoints in a SRTP session, and goes so far to require authentication of data a central SSRC manager. This seems like a pretty big architectural change to the handling of SSRC that would likely be an impediment to deployment.  I also have to wonder if such an SSRC manager could become a central point of attack.

I note that RFC 3711, section 9.1 talks about what I gather is the same issue, and does not seem to call for a central SSRC manager. Are the requirements here that different than for 3711?

Minor issues:

-- General:

There are a number of instances of 2119 normative language that I suspect do not define new normative requirements as much as repeat normative requirements from elsewhere (either in this draft, or from elsewhere.) This creates confusion on which text is authoritative, and creates an opportunity for inconsistent normative statements about the same thing. I strongly suggest that anytime you repeat or summarize normative text that is authoritatively stated elsewhere, you either use descriptive (non-normative) language (e.g., Foo is required to bar the baz), or clearly attribute the source (e.g. [XXX] says that foo MUST bar the baz.)

-- References:

The draft has normative down ref to RFC 3610. This was not explicitly mentioned in the IETF last call email, and does not appear to be included in the down ref registry.

-- 8.1:

If this draft contradicts normative language from RFC 3711, it should explicitly update 3711.

-- 8.2

Can you offer guidance on when it might be (or not be) necessary to disguise the length of the plaintext?  Especially how that might be known at the SRTP layer?

-- 14.1:

Does the master salt need to be kept secret? If the answer is "it depends", can you offer guidance?

Also, can you offer a definition of "properly erased"?

Nits/editorial comments:

-- There is a citation of RFC2675, but it doesn't appear in the references.

-- The abstract is out of place (Should be at beginning.)

-- section 1, third paragraph: "... provides a high level of security ..."

That may change over time. I suggest prefacing with "At the time of this writing..."

-- section 3, last paragraph:

Please expand IV on first mention.

-- section 5.3, last paragraph:

First and last sentence seem to contradict each other.

-- 15.1:

The IANA registration section for the SDES crypto-suites is oddly stated. That registry is just a table; the use of the srtp-crypto-suite-ext ABNF construction may be confusing.

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Mon, 15 Sep 2014 20:02:21 +0000

Ben et al:

  Here is the reasoning behind some of the issues you raise.  At least one
of them (SSRC re-use) is security critical.  

=========================================================================
SSRC Management:

"If I read this section correctly, the draft requires central management
of SSRC values when you have a master key shared among endpoints in a SRTP 
session, and goes so far to require authentication of data a central SSRC manager."

Yes indeed, having unique SSRC values is a crucial requirement in aes-gcm, 
since using the same IV (i.e. (ROC,SEQ,SSRC) triple) with the same key 
K more than once results in two undesirable consequences:

	1) It compromises secret authentication value H which is used to
         authenticate ALL messages that use the key K.

	2) It effectively reveals the contents of any packets using this
         common IV value.

Revealing the authentication key is a risk common to aes-gcm and many
other AEAD algorithms. But revealing the message content is a risk for
any key stream, including AES counter mode.

   RFC 3711 is willing to accept the compromise of some data, using the SRTP
SSRC collision detection process to detect such a compromise after it has
occurred.  But for my user base, detecting a data compromise after it has
occurred is insufficient.  For any high value data stream, any data compromise 
has potentially disasterous consequences

Though I didn't want to specify a mechanism for achieving the goal of having
unique SSRCs, the solution I had in the back of my mind was
	a) Each source has its own key for encrypting its outgoing data streams.
      b) The key it uses to decrypt incoming data depends upon the originator.
	c) For a given key K, the burden of preventing SSRC reuse with K depends
         solely upon the single source forming outgoing data streams using that
         key.  
One way or another, using either the current I-D or RFC 3711 with high value
data streams requires a mechanism that prevents the use of the same SSRC with 
two or more data sources that are using the same key on their outgoing data.
This decentralizes the burden on SSRC management, but requires each source have
its own outgoing data key.  If some usage of STTP requires that multiple sources 
must use the same outgoing data key, a mechanism needs to be in place to impose 
some discipline on how the members of this subnet assign SSRC values.  This holds 
for both RFC 3711 and the current I-D.
 
=====================================================================================         
"-- References:

The draft has normative down ref to RFC 3610. This was not explicitly mentioned in the IETF last call email, and does not appear to be included in the down ref registry."

Mea culpa, need to update this.

=====================================================================================

-- 8.1:

Its not so much that tie I-D updates updates as that it deale with a different context.   
In AEAD an algorithms integrity, is an intrinsic part of the encryption/decryption process, 
not a separate independent process.  RFC 3711 implicitly assumes integrity and privacy are 
two separate processes, but that it not true of AES-GCM.  For non-AEAD algorithms, RFC 3711 is 
correct in how it handles integrity, but AEAD an algorithm handle integrity in a radically different 
way and requires the modifications outlined in section 8.1.

=====================================================================================
-- 8.2

=====================================================================================
-- 14.1:

Lurking in section 3.2.1 of RFC 3711 is the following bullet. 

   *  a master salt, to be used in the key derivation of session keys.
      This value, when used, MUST be random, but MAY be public.  Use of
      master salt is strongly RECOMMENDED, see Section 9.2.  A "NULL"
      salt is treated as 00...0.

We took that to say that if the master salt MAY be public, it is also possible
for it to be secret.  I can not think of any instance in which it needs to be 
secret, but apparently the authors of RFC 3711 weren't quite so certain. 

=====================================================================================
Also, can you offer a definition of "properly erased"?

Gladly! I mean overwritten, not just dereferenced.  It's a bad idea to leave secret
values floating around in memory, just waiting for an adversary to read them out.

=====================================================================================
----------------+--------------------------------------------------
Kevin M. Igoe   | "We can't solve problems by using the same kind
[email-masked]  | of thinking we used when we created them." 
                |              - Albert Einstein -
----------------+--------------------------------------------------

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: Thursday, September 11, 2014 7:20 PM
To: [email-masked]
Cc: [email-masked] Team ([email-masked]); IETF Discussion
Subject: Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at

Please resolve these comments along with any other Last Call comments you may receive.

Document:  

Major issues:

Minor issues:

-- General:

-- References:

-- 8.1:

-- 8.2

-- 14.1:

Nits/editorial comments:

-- 15.1:

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Sep 2014 16:17:59 -0500

Hi, thanks for the response. Further comments inline. I will remove sections that do not appear to need further comment:

> of them (SSRC re-use) is security critical.  

Do I undertand correctly that you would need a repeat of all 3 inputs to invoke the problem, not just SSRC, right?

> has potentially disasterous consequences

Can you elaborate on your user base? Is this draft intended for general use?

> for both RFC 3711 and the current I-D.

Does the "source" in each source mean the synchronization source?

I'm not entirely sure I follow you, but I read this to mean you avoid the need for central management of SSRCs by not sharing keys between more than one originator? (that is Assuming so (and my next comment will make no sense otherwise): Wouldn't it make more sense to discourage shared keys, since such sharing would create a need for central ssrc management, rather than suggest ssrc management in the first place?

Or do you expect communities to actually implement central ssrc management?

[...]

> way and requires the modifications outlined in section 8.1.

In my personal opinion (and the IESG may fee otherwise), if an RFC proposes the existence of a context in which a MUST level requirement in another RFC can be relaxed, then it updates that other RFC. Such an update need not imply that the MUST be relaxed for all purposes--just this one. I might feel otherwise if the modified language had been a SHOULD, since the whole point of SHOULD is to allow for situations where it doesn't apply

In this case, it's probably up to the security ADs to make the call.

Did you mean for your response to 14.1 to apply also apply here?

I think some readers may take the fact master salt is called out in the first place to imply some need to keep it secret. I know you don't say that, but it might be worth a sentence to emphasize that the draft doesn't take a position on whether it needs to be kept secret in the first place.

That's pretty much what I figured. I would be helpful to mention that in the draft.

[...]

---

From: Ben Campbell <[email-masked]>
Date: Thu, 18 Sep 2014 16:17:01 -0500

Hi Kevin,

For the record, based on your comments I now consider the SSRC text to be a minor issue rather than a major one. 

Comments inline (again, deleting parts that seem closed)

On Sep 18, 2014, at 10:30 AM, Igoe, Kevin M. <[email-masked]> wrote:

[...]

> These terms get a little slippery, bit what I mean is the gear responsible
> for encrypting outgoing data. Let’s call this the originating box.
>  
> Yes, but sadly key management is out-of-scope for srtp.  Also a stronger verb that
> than “discourage” is needed, more like “prohibit”.

I don't think the fact that key management is out-of-scope for srtp in general prevents you from offering guidance security critical parts.

> If there is a small network of devices sharing the same key, say a video conference with
> a handful of participants. One could envision giving each box entering the conference
> a unique SSRC prefix it uses for any SSRCs it needs to create, once again localizing the
> SSRC management (save for the task of handing out SSRC prefixes).
>  
> The bottom line is that there are several ways to mitigate the need for centralized
> SSRC magament.  I agree with you that the key management based approach is far and
> away the cleanest approach.
>  
> My sole concern is not reusing an (SRTP, key) pair.  Any robust mechanism (i.e.
> not probabilistic) that achieves this goal is acceptable.

I guess my problem is that I took the text as written to suggest that centralized ssrc management was expected to be the "normal" case. I think it would be perfectly reasonable to say something to the effect of "... MUST not share keys unless a secure mechanism is used to guarantee that SSRC values never collide." I realize that is logically similar to "MUST have [ssrc coordination] in order to share keys", but the spin is a bit different.

---

From: "Igoe, Kevin M." <[email-masked]>
Date: Thu, 18 Sep 2014 15:30:58 +0000

Ben:

   Comment inline.  As I mention below, the fact that SRTP places
key management out of scope is an annoyance when dealing with
SSRC management.

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Wednesday, September 17, 2014 5:18 PM
To: Igoe, Kevin M.
Cc: [email-masked]; [email-masked] Team ([email-masked]); IETF Discussion
Subject: Re: Gen-ART LC Review of draft-ietf-avtcore-srtp-aes-gcm-14

On Sep 15, 2014, at 3:02 PM, Igoe, Kevin M. <[email-masked]<mailto:[email-masked]>> wrote:

> Ben et al:
>
>  Here is the reasoning behind some of the issues you raise.  At least
> one of them (SSRC re-use) is security critical.
>
> "If I read this section correctly, the draft requires central
> management of SSRC values when you have a master key shared among
> endpoints in a SRTP session, and goes so far to require authentication of data a central SSRC manager."
>
> Yes indeed, having unique SSRC values is a crucial requirement in
> aes-gcm, since using the same IV (i.e. (ROC,SEQ,SSRC) triple) with the
> same key K more than once results in two undesirable consequences:
>

Correct.  But the SEQ and POC are counters that start at zero, so their
presence is not helpful.  The IV for the first packet will be (SSRC,0,0),
so only the SSRC guards against repeated IVs.

>   RFC 3711 is willing to accept the compromise of some data, using the
> SRTP SSRC collision detection process to detect such a compromise
> after it has occurred.  But for my user base, detecting a data
> compromise after it has occurred is insufficient.  For any high value
> data stream, any data compromise has potentially disasterous
> consequences

As you can see from my e-mail address, my mission is to provide information
assurance for producers/consumers of US Gov't classified data.  My goal is to
help bring commercial gear up to a point where it could be used with classified
traffic. The classified community isn't alone in needing iron clad security; banks,
financial institutions, and many other organizations have an equally serious need
for iron clad security (this is my co-author's focus).

This I-D started life as an informational RFC, but early on it was requested that
this I-D be moved to standards track because of its wide applicability, resulting
in the current document.

>
>
> Though I didn't want to specify a mechanism for achieving the goal of
> having unique SSRCs, the solution I had in the back of my mind was
> One way or another, using either the current I-D or RFC 3711 with high
> value data streams requires a mechanism that prevents the use of the
> same SSRC with two or more data sources that are using the same key on their outgoing data.
> This decentralizes the burden on SSRC management, but requires each
> source have its own outgoing data key.  If some usage of STTP requires
> that multiple sources must use the same outgoing data key, a mechanism
> needs to be in place to impose some discipline on how the members of
> this subnet assign SSRC values.  This holds for both RFC 3711 and the current I-D.
>

These terms get a little slippery, bit what I mean is the gear responsible
for encrypting outgoing data. Let's call this the originating box.

Yes, but sadly key management is out-of-scope for srtp.  Also a stronger verb that
than "discourage" is needed, more like "prohibit".

[...]

> In AEAD an algorithms integrity, is an intrinsic part of the
> encryption/decryption process, not a separate independent process.
> RFC 3711 implicitly assumes integrity and privacy are two separate
> processes, but that it not true of AES-GCM.  For non-AEAD algorithms,
> RFC 3711 is correct in how it handles integrity, but AEAD an algorithm handle integrity in a radically different way and requires the modifications outlined in section 8.1.
>

A similar issue came up in Suite B for Secure Shell, and the the original secsh RFCs were
left unaltered. But that was an informational RFC, not standards track.

Yes, I'd be reluctant to go beyond what is already said in 3371.

> We took that to say that if the master salt MAY be public, it is also
> possible for it to be secret.  I can not think of any instance in
> which it needs to be secret, but apparently the authors of RFC 3711 weren't quite so certain.

Sounds reasonable to me.

>
>
> ======================================================================
> =============== Also, can you offer a definition of "properly erased"?
>
> Gladly! I mean overwritten, not just dereferenced.  It's a bad idea to
> leave secret values floating around in memory, just waiting for an adversary to read them out.

Another good idea.

[...]