Subject: [AVT] The use of AES-192 and AES-256 in Secure RTP

From: David McGrew <[email-masked]>
Date: Tue, 2 May 2006 08:15:41 -0700

Hello,

there has been some interest in using AES with larger key sizes in  
Secure RTP, and some implementations have gone in this direction in  
advance of any specification.  I wrote up an internet draft to fill  
this gap (after trying unsuccessfully to get someone else to write  
it :-) and to provide usage guidance and (eventually) test vectors.   
It's online at http://www.ietf.org/internet-drafts/draft-mcgrew-srtp- 
big-aes-00.txt

I propose that this draft be adopted for standards track, and I ask  
for your review (if you have an interest in Secure RTP).  Please note  
the "Open Questions" section.   The ietf-rtpsec list is copied since  
this draft is potentially interesting there, even though the draft  
has little architectural impact.

Best regards,

David

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 02 May 2006 09:50:27 -0700

Hi David,

  As I read the email, I wondered about replacing HMAC-SHA-1 in 3711 
also, and glad to see that your open questions lists that.  I have a 
few questions:

1. Is the 112-bit salt sufficient even with longer keys?  You might 
recall that we've (Mark B., you and I) had discussions on the master 
key and salt being input to a KDF that results in the derivation of 
the encr_key, integ_key and a salt, where the output might be longer 
than the input to the KDF.  You are the expert in this area, but I am 
still wondering if it is an issue.

Figure 2 applies to AES-128 only, right?

2. I would suggest that this draft include AES-based CMAC, so we can 
move away from SHA-1 and also use a single crypto primitive for 
encryption, and PRF and MAC computation (opinion on your open question).

Q: What are the considerations in truncating cipher-based MAC 
outputs?  Specifically, is truncating below half-the-size of the 
output (which I vaguely recall as relating to the birthday attack in 
case of hash-based MACs -- perhaps it is not) of the cipher-based MAC 
ok?  What would be the strength of the MAC in that case.  If we are 
making a case for AES-192 or AES-256, then we have a certain stronger 
adversary in mind (one that requires us to move away from 
AES-128).  In that case, why is MAC truncation not an issue?

Let's discuss those for now.  I may have more later :-).   Thanks for 
doing this!  I was going to ask you about using CMAC in 3711!

regards,
Lakshminath

At 08:15 AM 5/2/2006, David McGrew wrote:

>It's online at 
>http://www.ietf.org/internet-drafts/draft-mcgrew-srtp- big-aes-00.txt
>

---

From: David McGrew <[email-masked]>
Date: Tue, 2 May 2006 13:41:56 -0700

Hi Lakshminath,

thanks for your comments, more inline:

On May 2, 2006, at 9:50 AM, Lakshminath Dondeti wrote:

> also, and glad to see that your open questions lists that.  I have  
> a few questions:
>
> recall that we've (Mark B., you and I) had discussions on the  
> master key and salt being input to a KDF that results in the  
> derivation of the encr_key, integ_key and a salt, where the output  
> might be longer than the input to the KDF.  You are the expert in  
> this area, but I am still wondering if it is an issue.

I think that the 112-bit salt is sufficient.  The srtp salt is  
present so that the srtp use of counter mode is essentially as secure  
as CBC mode against attacks that amortize computational effort over  
multiple target keys.  This property still holds for the larger key  
sizes.  Besides, there's not much that we can do to increase the salt  
length, since there are only 16 more bits that we could possibly  
add.  I also think that it is valuable to retain counter-format  
compatibility with the AES-128 counter mode.

> Figure 2 applies to AES-128 only, right?

No, it's for all of the key sizes.  AES-192 and AES-256 still have 16  
byte plaintexts.  Or maybe I'm not understanding; did I mislabel  
something?

> 2. I would suggest that this draft include AES-based CMAC, so we  
> can move away from SHA-1 and also use a single crypto primitive for  

We think alike :-)  I implemented AES CMAC for SRTP and found that it  
performs better than HMAC-SHA1 for very short packets (like those for  
conversational voice over a WAN) but not long packets (like video).   
It also has some other advantages.  But OTOH there is a cost to  
proliferating cryptoalgorithms.  Let's start up a separate thread on  
CMAC.

> output (which I vaguely recall as relating to the birthday attack  
> in case of hash-based MACs -- perhaps it is not) of the cipher- 
> based MAC ok?

Ah, good points.  The NIST CMAC specification disallows truncation to  
MACs shorter than 64 bits.  This is not because CMAC is weaker than  
an ideal MAC with respect to truncation, though.  CMAC has been shown  
to be a good pseudorandom function if AES is a good blockcipher (as  
long as some usage limits are respected), and a PRF essentially is an  
ideal MAC.  I'm pretty sure that the CMAC specification insists on  
MACs of at least 64 bits because it feels that a per-MAC forgery  
probability greater than 2^64 is not acceptable.  No doubt they were  
not considering the case of stateless codecs, which some SRTP users  
need only 32-bit MACs.   It is an interesting question as to what tag  
sizes would be recommended for use with CMAC!

> What would be the strength of the MAC in that case.  If we are  
> making a case for AES-192 or AES-256, then we have a certain  
> stronger adversary in mind (one that requires us to move away from  

That's a good question.  I think that in some circumstances it could  
make sense to use a short authentication tag and a huge key.  If some  
unanticipated advance in cryptanalysis enables us to break AES-128  
but not AES-256, but some user is still okay with accepting one out  
of a billion forged g.711 packets, this scenario would fit the bill.   
So the cryptosuites defined in the draft might make sense.  But I  
take your point that users concerned that AES-128 doesn't have enough  
security may well not be satisfied with a 32-bit MAC.  It would be  
good to get some input from the Suite B community on this question.

>
> Let's discuss those for now.  I may have more later :-).   Thanks  
> for doing this!  I was going to ask you about using CMAC in 3711!
>

Any thoughts on whether or not AES-192 should be included?

David

>> It's online at http://www.ietf.org/internet-drafts/draft-mcgrew- 
>> srtp- big-aes-00.txt
>>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 02 May 2006 15:08:50 -0700

Hi David,

Thanks for the clarifications.  Please see inline for some follow-up notes:

>compatibility with the AES-128 counter mode.

Ok, I understand the limitation on the salt size (also see below 
about my misunderstanding of the block size in AES).  I also 
understand the aspect of offsetting counter-mode's relative key 
strength using the salt and that for that purpose 112-bit salt is sufficient.

What about using a 128, 192, or 256-bit master key and 112-bit salt 
to derive a 128, 192, 256-bit encryption key and a 160-bit, 256-bit 
(assuming SHA-1 or SHA-2) and a session salt key (this is 112-bits in 
size, right?)?  Is entropy or lack thereof is a consideration.

>byte plaintexts.  Or maybe I'm not understanding; did I mislabel

No, my mistake.  I forgot that AES uses 128-bit blocks irrespective 
of the key size.  Apologies.

>proliferating cryptoalgorithms.  Let's start up a separate thread on

We did talk about it before.  The concept of using the same crypto 
primitive came up elsewhere and that sounds like a good idea.  Please 
start that thread of discussion.

>>in case of hash-based MACs -- perhaps it is not) of the cipher- based MAC ok?
>

Let me think more about this.

>good to get some input from the Suite B community on this question.

Yes, we'll wait to hear from others.

>Any thoughts on whether or not AES-192 should be included?

I think the use of AES-192 should be specified (at the expense of 
more work for you :-) ), but let the "market" decide whether the 
switch is to 192 or 256-bit keys.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 03 May 2006 15:25:13 -0700

Hi Steve,

It all started with David's notes copy-pasted below:

++++++++
+++++++

It looks like all we are doing at the IETF is to specify; business as 
usual :-).  We could add a recommendation along the lines you propose below.

regards,
Lakshminath

At 02:28 PM 5/3/2006, Stephen Kent wrote:
>I'm not a cryptographer, but I generally advise against encouraging 
>users to employ AES with 256-bit keys. The 256-bit key size is there 
>primarily as a hedge against the future development of quantum 
>computers. Since there are some performance costs with the use of 
>big keys, it seems unnecessary to adopt them at this time.
>
>Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 May 2006 18:31:00 -0400

At 3:25 PM -0700 5/3/06, Lakshminath Dondeti wrote:
>It looks like all we are doing at the IETF is to specify; business 
>as usual :-).  We could add a recommendation along the lines you 
>propose below.
>
>regards,
>Lakshminath

If we decide that we need to specify how to use 256-bit keys, then 
we at least owe it to users to explain why they might not wish to 
take advantage of that capability. So, yes, adding suitable text 
would make me feel more comfortable.

thanks,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 May 2006 18:31:00 -0400

thanks,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 May 2006 17:28:56 -0400

I'm not a cryptographer, but I generally advise against encouraging 
users to employ AES with 256-bit keys. The 256-bit key size is there 
primarily as a hedge against the future development of quantum 
computers. Since there are some performance costs with the use of big 
keys, it seems unnecessary to adopt them at this time.

Steve

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 3 May 2006 19:08:01 -0400

On Wed, 3 May 2006 17:28:56 -0400, Stephen Kent <[email-masked]> wrote:

> computers. Since there are some performance costs with the use of [email-masked]>
	<[email-masked]>
	<[email-masked]>
Date: Wed, 3 May 2006 17:28:56 -0400
To: Lakshminath Dondeti <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: [email-masked], [email-masked], AVT <[email-masked]>
Subject: [AVT] Re: [saag] The use of AES-192 and AES-256 in Secure RTP

Steve

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 3 May 2006 19:08:01 -0400

> keys, it seems unnecessary to adopt them at this time.
And even NSA recommends against 192-bit keys, preferring 128 for SECRET
and 256 for TOP SECRET.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Stephen Kent <[email-masked]>
Date: Wed, 3 May 2006 18:31:00 -0400

thanks,

Steve

---



[email-masked]>

Steve

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 3 May 2006 19:08:01 -0400

---

From: David McGrew <[email-masked]>
Date: Thu, 4 May 2006 04:14:26 -0700

Hi Steve,

I pretty much agree.  The reason that I wrote up the draft is because  
it's been implemented (see http://sourceforge.net/mailarchive/ 
forum.php?thread_id=9620686&forum_id=9697) and it's been referred to  
in internet drafts (Section 4.1.3 of draft-zimmermann-avt- 
zrtp-01.txt), even though it's not been specified.  There is an  
important implementation detail (when using AES-XYZ for encryption,  
use AES-XYZ for key derivation) that won't be obvious to every  
implementer, so a spec is going to provide some value (even if we do  
decide that we don't want for AES-256 in SRTP to become a standard).

One reason that I can think of for implementing AES-256 in this case  
would be to conform to Suite B "TOP SECRET".  But there are not many  
other good reasons for implementing that key size at the present  
time.  The spec does promote algorithm agility, which is a good  
thing.  I guess that the trick is to provide for that agility without  
making interoperability harder.  I tried to do address the  
interoperability issue in the draft by pointing out that AES-256 is  
an addition to, not a replacement for, for AES-128.  I also tried to  
write the security considerations in such a way that encourages the  
use of AES-128.  The bigger key sizes are a hedge, as you put it, and  
for almost all uses they are not needed at present.  At least I tried  
to convey that impression - I'd value comments from readers, and I'd  
be happy to add or modify text in this direction.

David

On May 3, 2006, at 2:28 PM, Stephen Kent wrote:

> users to employ AES with 256-bit keys. The 256-bit key size is  
> there primarily as a hedge against the future development of  
> quantum computers. Since there are some performance costs with the  
> use of big keys, it seems unnecessary to adopt them at this time.
>
> Steve

---

From: David McGrew <[email-masked]>
Date: Thu, 4 May 2006 07:11:35 -0700

Hi Lakshminath,

a couple of comments inline:

On May 2, 2006, at 3:08 PM, Lakshminath Dondeti wrote:

> (assuming SHA-1 or SHA-2) and a session salt key (this is 112-bits  
> in size, right?)?  Is entropy or lack thereof is a consideration.

That's a good question.  I believe that the way that there aren't any  
problems with the way that key derivation is defined, but it deserves  
some text in the security considerations.

> primitive came up elsewhere and that sounds like a good idea.   
> Please start that thread of discussion.

Will do, but it may take a week.

> switch is to 192 or 256-bit keys.

Actually, the draft does include AES-192, though at this point I'm  
inclined to remove it (TLS doesn't support it, as you pointed  
out :-)   Not that it is a big deal, though.  One approach that we  
could take would be to have the "big keys" draft say AES-256 is a  
MUST and AES-192 is a MAY.

David

---

From: Stephen Kent <[email-masked]>
Date: Thu, 4 May 2006 10:36:39 -0400

At 4:14 AM -0700 5/4/06, David McGrew wrote:
>...

David,

I don't think Suite B is relevant here.  To be approved for 
protecting classified data at the TS level, a product will have to 
meet a lot of requirements, and the algorithm and key size are two of 
the easiest ones to meet. SRTP is carefully engineered to minimize 
overhead, and for commercial applications the tradeoffs that were 
made re security seem reasonable.  However, there is non indication 
that these tradeoffs are appropriate for use in the classified data 
protection area.  I note that DoD folks are working hard on defining 
how to use ROHC with IPsec, and a primary motivation is to enable use 
of IPsec, as implemented in HAIPS-compliant devices, to protect voice 
traffic.  That is indicative of the current view on the suitability 
of using SRTP as a primary security mechanism for classified VoIP 
apoplications.

Steve

---

From: David McGrew <[email-masked]>
Date: Thu, 4 May 2006 08:26:25 -0700

Hi Steve,

On May 4, 2006, at 7:36 AM, Stephen Kent wrote:

>> One reason that I can think of for implementing AES-256 in this  
>> case would be to conform to Suite B "TOP SECRET".  But there are  
>> not many other good reasons for implementing that key size at the  
>> present time.  The spec does promote algorithm agility, which is a  
>> good thing.  I guess that the trick is to provide for that agility  
>> without making interoperability harder.  I tried to do address the  
>> interoperability issue in the draft by pointing out that AES-256  
>> is an addition to, not a replacement for, for AES-128.  I also  
>> tried to write the security considerations in such a way that  
>> encourages the use of AES-128.  The bigger key sizes are a hedge,  
>> as you put it, and for almost all uses they are not needed at  
>> present.  At least I tried to convey that impression - I'd value  
>> comments from readers, and I'd
> meet a lot of requirements, and the algorithm and key size are two  
> of the easiest ones to meet.

I take your point here.  At http://www.nsa.gov/ia/industry/ 
crypto_suite_b.cfm, we're told that a CMVP evaluation is all that's  
needed to protect unclassified information (at which level AES-128 is  
considered sufficient, but AES-256 is allowed), but an NSA evaluation  
is required for implementations that protect classified info (which  
would require AES-256).   An important question is: will the adopters  
of Suite B for the protection of unclassified information regard  
AES-256 as desirable?

> SRTP is carefully engineered to minimize overhead, and for  
> commercial applications the tradeoffs that were made re security  
> seem reasonable.  However, there is non indication that these  
> tradeoffs are appropriate for use in the classified data protection  
> area.  I note that DoD folks are working hard on defining how to  
> use ROHC with IPsec, and a primary motivation is to enable use of  
> IPsec, as implemented in HAIPS-compliant devices, to protect voice  
> traffic.

For sure the interest in ROHC stems from a desire to protect VoIP  
with ESP, and IMO this makes good sense.

> That is indicative of the current view on the suitability of using  
> SRTP as a primary security mechanism for classified VoIP  
> apoplications.
>
> Steve

Perhaps, though SRTP is comparable to ESP transport mode, and header  
compression in ESP is applicable to tunnel mode.  Also, I've heard  
that AES-256 in SRTP has been discussed in other US DoD contexts,  
FWIW.  But at any rate, I can't speak for the Suite B community, and  
I'm glad to take input from them on the content of the draft.

There has been a bunch of good discussion on this draft, and my  
feeling is that we ought to standardize how to use AES-256 as an  
option in SRTP, but provide lots of guidance about the sufficiency of  
AES-128.  Given that TLS and IPsec provide AES-256 options, I don't  
see how we can argue otherwise, and I'm concerned that incompatible  
implementations would proliferate in the absence of a standard.  If  
the reference to Suite B is inappropriate, then it can be amended or  
removed.

David