Session Description Protocol (SDP) Security Descriptions for Media Streams
draft-ietf-mmusic-sdescriptions-12

[Ballot discuss]
draft-ietf-mmusic-kmgmt-ext-13.txt and draft-ietf-mmusic-sdescriptions-09.txt
  are both approaches to establishing keys with SDP.  However, neither
  document includes an applicability statement.  When is it appropriate
  to use this technique, and when should the other one be used?

  Section 7 says:
  >
  > Like all SDP messages, SDP messages containing security
  > descriptions, are conveyed in an encapsulating application protocol
  > (e.g., SIP, MGCP, etc.).  It is the responsibility of the
  > encapsulating protocol to ensure the protection of the SDP security
  > descriptions.  Therefore, IT IS REQUIRED that the application invoke
  > its own security mechanisms (e.g., secure multiparts such as S/MIME
  > [smime]) or alternatively utilize a lower-layer security service
  > (e.g., TLS, or IPSec).  IT IS REQUIRED that this security service
  > provide strong message authentication and packet-payload encryption
  > as well as effective replay protection.
  >
  S/MIME (as defined in RFC 2633, and as updated in RFC 3851) does not
  provide the needed replay protection.  However, there are fields in
  SIP header that can be used to provide the needed protection.  This
  situation needs to be explained.

[Ballot comment]
Section 7.2 says:
  >
  > ... the same AES keystream.
  >
  AES is a block cipher, so it does not have a keystream.  However,
  there are modes of AES that can generate keystream, such as AES in
  Counter Mode.  This needs clarification.