[AVT] SRTP security concerns: Status of resolution?

[Euchner Martin ICN M SR 3 <martin.euchner@siemens.com>]

Dear all,

it has been quite silent regarding the pending resolution of the SRTP
security concerns as raised during the IETF#55 Atlanta AVT WG meeting. Some
discussion took place during the meeting, but seemed to have ceased somehow
after IETF#55 closed. Since then, I haven't seen any progress.

What is the current status of discussion? Where are we at the moment?

In the interest of making progress in these matters, I've attached my notes
from the past AVT meeting, summarizing what I've seen on Eric's slides and
what I've heard in the discussion. I hope that this captures most of the
crucial stuff.
* SRTP has unusual design features.
* AES counter mode has no integrity protection; thus it is easy to make
predictable changes for known-plaintext; especially known syntax. Therefore
there is a need for a MAC. 
* The default MAC is only 32 bits, this is felt as too weak security.
Question is if 80 bit HMAC should be mandated.
* The "no MAC" option is seen very problematic.
* Threats are seen: modified message streams; forged traffic; big problems
for other kinds of media.
* Latency (i.e. delay): MACs (or IVs) consume bandwidth.
* Wireless channels are often noisy; this would result in total packet loss
with integrity.
As options for resolution two options are envisaged:
1.) FEC after encryption/MAC (not a perfect solution).
2.) Two sets of transforms:
* Partial integrity for wireless voice, mandatory integrity protection over
control data only. 
* Full integrity for everything else; an 80 bit MAC should be fine and this
should be the default.
I believe the latter two issues deserve more clarification and further
discussion.

It also became obvious that the text should provide some strong security
warning for the weaker security mechanisms and should give due
considerations of the costs of security in payload (when to turn security
off?). Considerations should be given on the environment with some
analysis/impact.

Do I miss anything?


With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 62366
| ICN M SR 3                     mailto:Martin.Euchner@siemens.com
|                                mailto:martin.euchner@ties.itu.int
| Hofmannstr. 51                 Intranet:
http://intranet.icn.siemens.de/marketing/cs27/topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

 -----Original Message-----
From: 	Stephen Casner [mailto:casner@acm.org] 
Sent:	Thursday, December 19, 2002 12:43 AM
To:	Allison Mankin; Steven M. Bellovin
Cc:	AVT WG
Subject:	[AVT] SRTP MAC question

Allison and Steve,

In the minutes of the AVT meeting in Atlanta, which were prepared from
notes taken during the meeting and a review of the audio tape, we
noted the following statements from you as part of the discussion of
SRTP security considerations:

   Mark Baugher asked if changing the default mandatory transforms,
   adding CBC mode as an option, would satisfy concerns?  Steve Bellovin
   answered that, assuming you meet requirements for safely using counter
   mode, there is no strong need for CBC mode; the MAC is much more
   critical.

   Allison commented that the draft is intended to be general purpose,
   but is optimized for cellular use.  The default transform needs to be
   suitable for the general case, with a non-optional MAC if counter mode
   is used, and justification why weaker options are present for cellular
   operation.

I would like to get a clarification of your position:  Independent of
what transforms are chosen as the defaults, are you saying that if
counter mode is selected as the cypher for a particular application,
then a MAC MUST also be used?  And if so, do you mean to impose a
minimum size for the MAC?

Note that if your answer is yes, we have a conflict with what a number
of people hold as the requirements for some applications.

                                                        -- Steve

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt