Security Preconditions for Session Description Protocol (SDP) Media Streams
RFC 5027

Note: This ballot was opened for revision 04 and is now closed.

(Jon Peterson) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Brian Carpenter) No Objection

Comment (2006-12-12 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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
                                                 ^^^

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

Comment (2006-12-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  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

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Sam Hartman) No Objection

(Russ Housley) (was Discuss) No Objection

(Cullen Jennings) No Objection

(David Kessens) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

Magnus Westerlund No Objection

Comment (2006-12-13 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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