[AVT] Re: SRTP MAC question

[Allison Mankin <mankin@psg.com>]

Chairs, SRTP authors, AVT WG group,

Steve Casner asked me and Steve Bellovin for some written
clarifications of our remarks about SRTP from Atlanta.  The holidays
and some doublechecking slowed us down, but now here are specific
responses to the questions Steve posed in that message.  (I've
appended the original mail, after a security analysis that was
prepared by Eric Rescorla for the Security and Transport Areas).

The conclusion of Eric Rescorla and Steve Bellovin is that it is not
necessary to add a CBC mode to SRTP.

But they did conclude that there are very limited circumstances in
which the counter mode may be used without a MAC of at least 80 bits,
and that applications to be used without a MAC must have accompanying
information with specific data about the error frequency in the
channel that justifies this usage.

So as Area Director, I would like to see such a description added to
the current case of SRTP for cellular voice in the i-d being revised.
Instead of it being "up to the user's security profile to request
authentication" (Section 9.5), it should be there that the MAC is
chosen not to be used, and the Security Considerations of this
document should provide data justifying the choice.  For other
profiles without the error rate, the Security advisors have asked for
an 80-bit MAC to be the default.

Steve Casner's mail mentions that a number of people hold avoidance of
use of a MAC as a requirement for some applications.  What I request
here allows them to have their requirement, it just asks them to
substantiate it.  In addition, it takes the outcome of the security
analysis and ensures that the higher risk of easy integrity attacks is
not accidentally imposed by default on applications that may not have
the tradeoff made by the SRTP design as written currently.

Allison (for myself, Steve Bellovin and Eric Rescorla)


-----------
Security Summary of SRTP Discussion by Eric Rescorla <ekr@rtfm.com>

Following the AVT WG meeting in Atlanta, a number of people asked
me to write up a summary of what Allison, Steve, and I said
in the session.

The basic principle is that one should attempt to secure traffic
to the greatest extent practical. This doesn't mean that you have
to apply the absolute possible maximum level of security but it
does mean that you have to justify why you didn't do so. 

This brings us to the issue at hand, namely that the integrity
protection in SRTP is a lot weaker than what's generally considered
appropriate in Internet protocols. To review, SRTP offers three
forms of integrity protection:

      (1) None
      (2) 32-bit MAC
      (3) 128-bit MAC
      
This is made somewhat additionally scary by the fact that it
uses CTR mode, which we know to be susceptible to easy integrity
attacks.

The authors provided a number of qualitative arguments for
why this was necessary, generally hinging on performance. 
Unfortunately, performance decisions are generally quantitative
and numbers have been pretty thin on the ground. There seemed
to be wide acceptance that a stronger transform should 
be used for most Internet-style channels that have high 
capacity and low BER. The debate, as far as I can tell,
centers on what's appropriate for constrained and noisy
channels (primarily wireless).

So, what's needed here is two things:
(1) Require some stronger (96-bit? 80-bit?) MAC for general
    Internet-wide use.
(2) Write a Security Considerations section that explains why a lower
    level of integrity protection is appropriate/required for certain
    constrained channels. Speaking solely for myself, what I'd like to
    see is calculations of:

    (1) The expected capacity of the channel.
    (2) The expected bit error rate of the channel.
    (3) The number of damaged packets.
    (4) The amount of FEC (and corresponding reduction in capacity)
	required to achieve any given packet loss rate.
    (5) The effect that this reduction in channel capacity would
	have on applications. 
    (6) The possible attacks (and their severity) that would be
	allowed by this design.

The idea here is that this analysis would convince the reader
that this set of tradeoffs was the right ones.


----------- Forwarded message ----------

Date: Wed, 18 Dec 2002 15:43:07 -0800 (PST)
From: Stephen Casner <casner@acm.org>
To: Allison Mankin <mankin@psg.com>,
         "Steven M. Bellovin" <smb@research.att.com>
cc: AVT WG <avt@ietf.org>
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



------- End of Forwarded Message

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