Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 23 Nov 2009 13:13:29 +0100

Hi Robert,

I've been thinking about the security consideration section of the 199.
I do not think 199 introduces a new attack, because if a middle-man can
send 199 he can probably also send a BYE.

Below is some suggested text:

"12.  Security Considerations

   General security issues related to SIP responses are described in
   [RFC3261].  Due to the nature of the 199 response, it may be
   attractive to use it for launching attacks in order to terminate
   specific early dialogs (other early dialogs will not be affected). 
   In addition, if a man-in-the-middle sends a 199 response to the UAC,
which terminates 
   a specific dialog, it can take a while until the UAS finds out that
the 
   UAC, and possbile stateful intermediates, have terminated the dialog.

   However, the same kind of attack can be performed if a
man-in-the-middle sends a 
   BYE request towards the UAC. The UAC will terminate the dialog for
which the BYE
   request is sent, but it can take a while until the UAS finds out that
the dialog has
   been termianted. SIP security mechanisms (e.g. hop-to-hop TLS) can be
used to minimize, 
   or eliminate, the risk for such attacks."

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 15. lokakuuta 2009 18:53
> To: Robert Sparks
> Cc: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [sipcore] AD review draft-ietf-sipcore-199-00
> 
> Hi,
>  
> >Quick response to the clarifying questions:
> >
> ><large chunk snipped>
> >	
> >	
> >The security consideration section is not yet sufficient.
> >
> >It should have said:
> >
> >The security consideration section is not yet sufficient. If 
> there is 
> >an  effective attack here, we need text that explores it. If there
> isn't, 
> >we need text that argues it isn't. 
> 
> Ok, I'll look into that. 
> 	
> -------------------
> 		
> 
> >Bottom of page 3, next to last paragraph,
> >
> >
> >This sentence:
> >   When SIP entities upstream receive the non-2xx
> >   final response they will release resources associated with the
> >   session, and the UAC will terminate the session setup.
> >is assuming the final response wasn't something the UAC 
> could react to 
> >by trying again with some related changes (like responding to a
> 401/407).
> 
> Ok, now I got it.
> 
> So, I guess the text should say something like:
> 
> "When SIP entities upstream receive the non-2xx final 
> response they will normally release resources associated with 
> the session, and the UAC will terminate the session setup, 
> unless the final response (e.g. a 401/407 final response) 
> triggers a new session setup request to be sent."
> 
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Brett Tate <[email-masked]>
Date: Mon, 23 Nov 2009 04:37:48 -0800

Hi Christer,

BYE from called party is not allowed for terminating an early dialog.  If I recall the rfc3261 text correctly, it actually requires the ACK (or INVITE 2xx timeout) before called party can send BYE.

Since the BYE would be treated as an abnormal situation (BYE race condition with INVITE 2xx), the outcomes might be different.  Thus I don't think the second paragraph of the proposed text is accurate.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Christer Holmberg
> Sent: Monday, November 23, 2009 7:13 AM
> To: Robert Sparks
> Cc: [email-masked]; [email-masked]; sipcore-
> [email-masked]

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 23 Nov 2009 13:45:31 +0100

Hi, 

>BYE from called party is not allowed for terminating an early 
>dialog.  If I recall the rfc3261 text correctly, it actually 
>requires the ACK (or INVITE 2xx timeout) before called party 
>can send BYE.
> 
>Since the BYE would be treated as an abnormal situation (BYE 
>race condition with INVITE 2xx), the outcomes might be 
>different.  Thus I don't think the second paragraph of the 
>proposed text is accurate.

Yes, you are probably right.

In that case the second paragraph should of course be removed, and the
text should indicate (as it did previously) that it does allow a new
kind of attack.

Regards,

Christer

> > I do not think 199 introduces a new attack, because if a middle-man 
> > can send 199 he can probably also send a BYE.
> > 
> >    In addition, if a man-in-the-middle sends a 199 response to the 
> > UAC, which terminates
> >    request is sent, but it can take a while until the UAS finds out 
> > that the dialog has
> >    been termianted. SIP security mechanisms (e.g. 
> hop-to-hop TLS) can 
> > be used to minimize,
> response they 
> > > will normally release resources associated with the 
> session, and the 
> > > UAC will terminate the session setup, unless the final response 
> > > (e.g. a 401/407 final response) triggers a new session 
> setup request 
> > > to be sent."
> > >
> > >
> > > Regards,
> > >
> > > Christer
> > >
> > >
> > >
> > >
> > >
> > >

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 24 Nov 2009 09:00:43 +0100

Hi,

A new version of the suggested text:

   SIP security mechanisms (e.g. hop-to-hop TLS) can be used to
minimize, 

Regards,

Christer

-----Original Message-----
Sent: 23. marraskuuta 2009 14:46
To: Brett Tate

Hi, 

>BYE from called party is not allowed for terminating an early dialog.  
>If I recall the rfc3261 text correctly, it actually requires the ACK 
>(or INVITE 2xx timeout) before called party can send BYE.
> 
>Since the BYE would be treated as an abnormal situation (BYE race 
>condition with INVITE 2xx), the outcomes might be different.  Thus I 
>don't think the second paragraph of the proposed text is accurate.

Regards,

Christer