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