Subject: RE: [MMUSIC] Question on sdp-new

From: "Elwell, John" <[email-masked]>
Date: Tue, 18 Oct 2005 07:50:39 +0100

> -----Original Message-----
> From: Mark Baugher [mailto:[email-masked]] 
> Sent: 17 October 2005 20:47
> To: Dan Wing
> Cc: [email-masked]; [email-masked]; 'Mats Näslund' ; 
> 'Paul Kyzivat'; Elwell, John; [email-masked]; 
> [email-masked]
> Subject: Re: [MMUSIC] Question on sdp-new
> 
> 
> On Oct 14, 2005, at 4:18 PM, Dan Wing wrote:
> 
> >> It seems to me that it is not (only) the SRTP offer that 
> needs to be
> >> protected, but rather the combination of the two RTP/SRTP 
> offers. If
> >> this is not done, a "man in the middle" simply deletes the 
> SRTP-part
> >> (be it protected or not), leaving only plain RTP. This would be
> >> a so-called bidding down attack.
> >
> > The only techniques to protect against that are to (a) 
> S/MIME protect
> > the entire SIP body (that is, both the RTP and the SRTP offers), or
> > (2) sip-identity protect the entire SIP body.  S/MIME 
> protecting both
> > the RTP and SRTP offers is almost nonsensical, leaving us with
> > sip-identity.
> 
> And what do you do with legacy endpoints that don't support 
> sip-identity?
[JRE] Legacy endpoints that don't support sip-identity will just ignore the
identity information, but then of course they will be unable to detect a bid
down attack.

John

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Mark Baugher <[email-masked]>
Date: Tue, 18 Oct 2005 06:53:16 -0700

On Oct 17, 2005, at 11:50 PM, Elwell, John wrote:
...

> identity information, but then of course they will be unable to  

So the problem is not solved here then, is it?

Mark

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 18 Oct 2005 08:37:42 -0700

> > identity information, but then of course they will be unable to  
> > detect a bid down attack.
> 

What's needed is authenticated error responses in SIP, at least
that's my view of what's needed -- very much akin to ICMPs that
you receive from arbitrary routers along your path which could all
lie about 'no route to host'.  We don't have that in IPv4.

-d