Re: [sipcore] Security issue in -keep-08

Hi Robert,

I suggest adding the following new paragraph to the security considerations section:

"In order to prevent attacks, when an entity sends STUN keep-alives to an adjacent downstream entity that is not willing to receive keep-alives (or does not support STUN), but for which willingess to receive keep-alives has been inidicated by some other downstream entity, if the sending entity does not receive a response to any of the STUN keep-alive requests, it MUST stop 
sending the keep-alive requests for the remaining duration of the dialog (if the sending of keep-alives were negotiated for a dialog) or until the sending of keep-alives is re-negotiated for the registration (if the sending keep-alives were negotiated for a registration). Further actions taken by the sending entity is outside the scope of this specification."

Regards,

Christer

> -----Original Message-----
> From: sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
> Sent: 24. marraskuuta 2010 14:50
> To: Robert Sparks; SIPCORE
> Subject: Re: [sipcore] Security issue in -keep-08
> 
> 
> Hi Robert,
> 
> Thanks for reviewing the document!
> 
> I guess the attack you describe could also happen in 
> Outbound, if someone inserts an "ob" parameter in the Path 
> header of the proxy adjacent to the UA, and that proxy does 
> not check its Path header before forwarding the response to the UA.
> 
> Having said that, I guess a way to protect against this 
> attack could be to say that an entity MUST stop sending STUN 
> messages if it doesn't receive a response to them.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Robert Sparks [mailto:rjsparks@nostrum.com]
> > Sent: 23. marraskuuta 2010 22:00
> > To: SIPCORE
> > Cc: Christer Holmberg
> > Subject: Security issue in -keep-08
> > 
> > I believe there is a serious problem with the 
> recommendations in the 
> > Security Considerations section in keep-08 where it 
> discusses having 
> > downstream elements change the keep parameter.
> > 
> > Consider this scenario. A user agent implementing this 
> specification 
> > sends a request that goes through two proxies before it 
> arrives at its 
> > destination. The first proxy does not know about this 
> specification. 
> > The second proxy does, and chooses to attempt to maliciously affect 
> > the relationship between UA1 and P1 as suggested in these security 
> > considerations.
> > 
> > View the following flow in a fixed-width font:
> > 
> > UA1                  P1               P2    UA2
> >  |                   |                |      | 
> >  | INVITE            |                |      |
> >  | Via: UA;keep      | INVITE         |      |
> >  |------------------>| Via: P1        |      | 
> >  |                   | Via: UA;keep   |      | 
> >  |                   |--------------->|      |
> >  |                   |                |----->| 
> >  |                   |                | 200  |
> >  |                   | 200            |<-----|
> >  |                   | Via: P1        |      |
> >  | 200               | Via: UA;keep=1 |      |
> >  | Via: UA;keep=1    |<---------------|      |
> >  |<------------------|                |      | 
> >  |                   |                |      | 
> > 
> > 
> > Since P1 doesn't support this specification, it does not 
> know to look 
> > at "it's" Via to see if some downstream element has 
> modified what it 
> > would have put in the keep parameter value - the 
> recommendation in the 
> > current draft does not mitigate this attack at all. If the 
> hop between 
> > UA1 and P1 is UDP, this may result in STUN being send 
> towards P1's SIP 
> > listening port with P1 not expecting (or being able to deal 
> with) it.
> > 
> > This is a general problem with attempting to use Via parameters to 
> > indicate support for extensions. A similar problem exists 
> for ;rport, 
> > and for ;lr. However, if a downstream element abused those 
> parameters, 
> > signaling is guaranteed to fail. This proposed parameter has a 
> > different property - this abuse may only result in extra 
> traffic for 
> > someone else.
> > 
> > I don't think this document is the right place to solve the general 
> > problem, but this discussion needs to be rewritten to be 
> clearer about 
> > the problem and the lack of any current way to mitigate it.
> > 
> > RjS
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 