Security Preconditions for Session Description Protocol (SDP) Media Streams
draft-ietf-mmusic-securityprecondition-04

[Ballot discuss]
The means to deal with refusals is identified in the security
  considerations as a work in progress (SDPCN).  This seems like an
  important feature.  How can this be reviewed or deployed without
  SDPCN?

[Ballot comment]
Section 2:

"Real-Time Transfer protocol" RTP stands for "real-time transport protocol"

Section 3:

At that moment, we furthermore require that ser agents MUST start
  using the new session parameters for media packets being sent.

Spelling: ser/user

[Ballot comment]
From Gen-ART review by David Black:

In the new security considerations section, I didn't see any mention
  of downgrade attacks (man-in-the-middle removes secure alternative
  from negotiation, causing use of non-secure streams when secure streams
  would have been used in his absence) - this mention is ok to omit, as
  the important point that the offerer's security policy allows non-secure
  streams in this situation has been added.  Similarly, the security
  considerations section doesn't say how to avoid the "malicious malicious
  media stream packets until the answer (indicating the chosen secure
  alternative) is received" vulnerability, but it's reasonably clear from
  context that the only obvious way to avoid it is to not offer the
  non-secure alternative.

  I saw this typo in the new text in Section 3:

    At that moment, we furthermore require that ser agents MUST start
                                                ^^^

[Ballot discuss]
Security for media streams typically uses SRTP.  The whole purpose of
  this document is to stall media transmission until the necessary keys
  for RTP security are in place, which avoids media clipping.  The
  security precondition ensures that the receiver is "ready" to receive
  "secure" data.  This is not needed with some of the in-band key
  management techniques that are being discussed.  Should we wait to
  advance this document?  If we wait and the RTPsec solution does not
  need this mechanism, we will have reduced complexity.

  The means to deal with refusals is identified in the security
  considerations as a work in progress (SDPCN).  This seems like an
  important feature.  How can this be reviewed or deployed without
  SDPCN?

[Ballot comment]
Idnits finds boilerplate issues.


Section 3, paragraph 1:
>    If the security precondition is used with a non-secure
>    media stream, the security precondition is by definition satisfied.

  That sentence just reads oddly. How about "A security
  precondition used with a non-secure media stream has no effect."


Section 3, paragraph 4:
>    Security preconditions do not guarantee that an established media
>    stream will be secure.  They merely guarantee that the recipient of
>    the media stream packets will be able to perform any relevant
>    decryption and integrity checking on those media stream packets.

  The term "security precondition" is really misleading. How about
  something like "stream setup synchronization precondition" or
  "security parameter exchange precondition?"


Section 5, paragraph 4:
>    integrity protection of signaling, e.g., IPSec or TLS.  In all other

  Nit: s/IPSec/IPsec/


Section 9, paragraph 4:
>    [RFC2327] M. Handley and V. Jacobson, "SDP: Session Description
>    Protocol", RFC 2327, April 1998.

  Nit: cited as [SDP] in the text

Proto Writeup:

    1.a) Have the chairs personally reviewed this version of the ID and
        do they believe this ID is sufficiently baked to forward to the
        IESG for publication?

Yes.

    1.b) Has the document had adequate review from both key WG members
        and key non-WG members?  Do you have any concerns about the
        depth or breadth of the reviews that have been performed?

The document has had adequate review; I have no concerns.

    1.c) Do you have concerns that the document needs more review from a
        particular (broader) perspective (e.g., security, operational
        complexity, someone familiar with AAA, etc.)?

No.

    1.d) Do you have any specific concerns/issues with this document 
that
        you believe the ADs and/or IESG should be aware of?  For
        example, perhaps you are uncomfortable with certain parts of 
the
        document, or have concerns whether there really is a need for
        it, etc.  If your issues have been discussed in the WG and the
        WG has indicated it wishes to advance the document anyway, note
        if you continue to have concerns.

I have no concerns.

    1.e) How solid is the WG consensus behind this document?  Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

There is solid consensus.

    1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise what are they upset about.

No.

    1.g) Have the chairs verified that the document adheres to _all_ of
        the ID nits? (see http://www.ietf.org/ID-Checklist.html).

There are minor nits in the boilerplate text that make idnits-1.82 
complain, but nothing significant.

    1.h) Does the document a) split references into normative/
        informative, and b) are there normative references to IDs, 
where
        the IDs are not also ready for advancement or are otherwise in
        an unclear state? (Note: the RFC editor will not publish an RFC
        with normative references to IDs, it will delay publication
        until all such IDs are also ready for publication as RFCs.)

References have been split. There are no normative references to I-Ds.

        *    Technical Summary

This document defines a new security precondition for the Session 
Description Protocol precondition framework described in RFCs 3312 
and 4032.  A security precondition can be used to delay session 
establishment or modification until media stream security has been 
negotiated successfully.

        *    Working Group Summary

This is a typical application of the SIP/SDP preconditions framework. 
There was no controversy surrounding the work, and it is needed by a 
range of SIP users.

        *    Protocol Quality

The draft appears to be of good quality.