RE: Galois/Counter Mode of Operation in SRTP

["Eugene Nechamkin" <enechamkin@xxxxxxxxxxxx>]

Hi David,

I can think of the following pro-s for the AES-GCM compared with the
drawbacks of the current AES-CM in SRTP:
	- computational overhead related to HMAC-SHA1 (even with the HW
accelerations)
	- ambiguity with the choice of the Auth Tag length: 80 bits ? 32
bits ? 
	- more than one computational algorithms involved in SRTP
processing (with the corresponding HW and/or SW penalty).
	- not future proof: the SHA1 problem may be potentially
affecting the current SRTP ciphers. I realize that this may be not the
most serious concern due to the presence of HMAC.
	- the ability of the SRTP to offer the crypto methods allowing
the simple (cheep) HW implementations are very important for a wide
variety of the voice and video-over-IP devices, especially the ones with
the integrated networking functionality.
	- as AES-GCM is becoming increasingly included or even mandated
in other areas of the network security (e.g. MACsec, IKEv2, TLS), the
devices can easily benefit from re-use of the GCM implementation.

I agree, the fact that auth tag of AES-GCM cannot be truncated is
somewhat restricting. However, this may be a drawback which many
applications/devices can compromise on given other advantages of GCM.

One of the justifications for Authentication and Encryption to be
separate is the ability of the authentication to prevent (or remedy) the
DoS attacks when the device is bombarded with the arbitrary fabricated
(or modified) packets and, consequently, chokes on the decryption of
these packets. Such separation can be viewed as an advantage over the
AEAD provided that the time required for calculation of the
authentication tag is significantly less than the time for the
decryption process. With the cipher suites required by SRTP (AES-CM and
HMAC-SHA1), this does not seem to be the case. I think, this criteria
may be even used as a condition for the AES-GCM suitability for the
particular application. So, potentially, the absence of the separate
authentication procedure in AES-GCM cannot be considered as a
fundamental drawback compared to the current SRTP. 

I would also basically agree with the way how the "plain text" can be
defined to accommodate the RTP header and ROC in AES-GCM. However, I was
wondering why not to define the "plain text" as follows:

	plaintext = RTP_Packet || ROC 

where
	RTP_Packet = rtp_header || rtp_payload 

This seems to be easier on the device - no need for re-packaging the RTP
packet.

My biggest issue would be to evaluate how much of the memory toll the
AES-GCM requires to achieve the performance comparable (or higher) with
the standard [AES-CM+HMAC-SHA1] combo. If somebody knows of such
estimations, would be great to hear this.

Thanks,
Eugene.


-----Original Message-----
From: David McGrew [mailto:mcgrew@xxxxxxxxx] 
Sent: Thursday, March 29, 2007 7:05 AM
To: Lee Dilkie; Eugene Nechamkin
Cc: ietf-rtpsec
Subject: Re: Galois/Counter Mode of Operation in SRTP

Hi Lee and Eugene,

I agree that this is potentially useful.  I've discussed it with a few
people, and would like to look into it more.  Russ Housley kindly
offered to sponsor a document (back when he was security AD :-)  I would
be interested to hear your thoughts on some of the aspects that I've
been looking into.

Here are some of the pros and cons.  In many software implementations of
SRTP, HMAC-SHA1 is the single biggest computational cost, because that
algorithm is relatively slow on shorter packets, while AES CTR has
performance that is uniform across different packet lengths.  So AES GCM
could potentially address this performance issue, because it performs
well as long as a decent amount of memory can be used to  
store some precomputed data that is used in the authentication.   
Applications that have a bit of memory to spare for precomputation can
benefit from better performance, while applications that don't will have
a performance that is probably no worse than current  
performance with the SRTP default cryptoalgorithms.   In hardware,  
AES GCM wins hands down (though it is not clear how important hardware
implementations are, at least in the short term).

One con is that GCM could not be used with an authentication tag length
of four bytes, as is sometimes done with HMAC-SHA1, because GCM can't be
truncated.  However, I expect that this is OK, since the SRTP default of
ten bytes seems to be acceptable in many applications.

There is a minor technical issue with the use of GCM or any other  
AEAD method in SRTP, in the way that the SRTP ROC is authenticated.   
The SRTP authenticated data is formed as

input_to_MAC = rtp_header || encrypted_payload || ROC

... and the authenticated-but-not encrypted data is split by the
encrypted_payload.  What we'd want to do is to define the AEAD inputs as

                     plaintext = rtp_payload
additional_authenticated_data = ROC || rtp_header

Probably this technical point is no big deal.  An easy way to
accommodate this would be to write a spec defining "how to use AEAD in
SRTP".

I'd definitely like to get some implementation experience with AES- GCM
in SRTP, to see how things work out in practice.

best regards,

David

On Mar 29, 2007, at 3:52 AM, Lee Dilkie wrote:

>
> Not having heard of this before, I read the draft you quoted and I'm 
> intrigued. Looks like a natural fit for a 0-byte overhead SRTP 
> algorithm that includes message integrity without adding a per-packet 
> header.
>
> If anybody does have more info, please post to the list.
>
> Thanks,
>
> Lee Dilkie
> Mitel
>
> Eugene Nechamkin wrote:
>> Hi all,
>>
>> The draft "draft-mcgrew-auth-enc-02" defines the AES-GCM (Galois/ 
>> Counter Mode of Operation) cipher for authenticated encryption. For 
>> some voice/video-over-IP applications, this method seems to be a 
>> plausible alternative to the "standard" AES-CM in SRTP. I was 
>> wondering if anybody can point me to such discussions or publications

>> on possibility of using the AES-GCM in SRTP.
>>
>> Thanks,
>> Eugene Nechamkin,
>> Broadcom Corp.
>>
>>