Security Preconditions for Session Description Protocol (SDP) Media Streams
RFC 5027
Yes
No Objection
Note: This ballot was opened for revision 04 and is now closed.
Lars Eggert No Objection
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
(Jon Peterson; former steering group member) Yes
(Bill Fenner; former steering group member) No Objection
(Brian Carpenter; former steering group member) No Objection
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
^^^
(Cullen Jennings; former steering group member) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Lisa Dusseault; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
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
(Mark Townsley; former steering group member) No Objection
(Ross Callon; former steering group member) No Objection
(Russ Housley; former steering group member) (was Discuss) No Objection
(Sam Hartman; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection