Thanks for your comment on the draft. Brian Stucker's now-expired draft, "Coping with Early Media in the Session Initiation Protocol", http://tools.ietf.org/html/draft-stucker-sipping-early-media-coping-03, describes several types of early media:
Pre-routing early media Pre-presentation early media Post-presentation early media Non-SDP early media I'm not sure which of those we would want to use to fulfill requirement R15 -- they have quite different security properties from an attack that concerns me. My concern is that R15 would put an SRTP caller at risk of receiving an attacker's RTP. Once the called party's SRTP key is known, I expect the caller could discard the incoming RTP in favor of the SRTP. But for a time period (between the INVITE being sent and the called party's SRTP key being known), the calling party is vulnerable to receiving (and playing out) arbitrary RTP media from any arbitrary host on the network. -d > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Schneider, Peter (NSN - DE/Muenich) > Sent: Monday, March 03, 2008 4:05 AM > To: [email protected] > Subject: [Sip] Removal of RTP-to-SRTP-upgrade requirement > indraft-ietf-sip-media-security-requirements > > Former versions of the draft included the requirement > > R15: The media security key management protocol SHOULD allow > endpoints to start with RTP and then upgrade to SRTP. > > The current version -03 doesn't contain the requirement. > > As quoted from RFC3264 in the draft, after the INVITE with the SDP > offer, the offerer must be prepared to receive media, e.g. for > announcements. I feel it makes sense to support a use case where such > announcements can be sent unencrypted, even if the caller wants to set > up an encrypted call. Obviously, this allows an attack (e.g. > sending of > forged announcements), but on the other hand, it may be useful for the > caller to hear the announcements. It could be a local policy of the > calling user agent to drop such media (in order to avoid > attacks) or to > play it out. The user agent may also be configured to indicate somehow > whether "the call is secured" or not. > > So I suggest to revive R15, maybe in a wording that makes more clear > what use case(s) should be supported. > > Peter > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
