Subject: [cuss] Security in draft-johnston-cuss-sip-uui

From: Cullen Jennings <[email-masked]>
Date: Sun, 7 Nov 2010 15:54:12 -0700

I find the security part of this draft, well, frankly baffling. It says you MUST use S/MIME but says nothing about how given S/MINE in 3261 protect bodes and this is a header - I think more detail would be needed before we decide if it is better to carry UUI in a URI, header, or body.  I'm also interested in if the use of S/MIME would require multipart. Given the non existent deployments of S/MIME, I fairly skeptical about basing the security on S/MIME. I'd love to hear the consensus of the room on will people implement S/MIME  to secure UUI? (note I said implement not deploy)

In section 3.5 you say that UA's commonly take escaped but unknown header is a Refer-To or Contact and put put them in the resulting message. As I have mentioned many times before, I don't think this is generally true. Thoughts?

I've got a wacky idea for you... and given the tone of my above points I imagine you might not be in the most open to suggestions mode but give this idea a fair hearing. It wacky and gross even by my low standards but it might be worth considering. 

We sort of blew it when we did SIP and we have no real forward compatibility mechanism for new bodies without using multipart and we did not mandate multipart as part of the base SIP spec. Now we've tried to fix that but I agree with your basic analysis that the fact of the matter is that lots of existing devices don't support multipart. My proposal here is a general solution to forward compatibility of new bodies in SIP INVITES without breaking stuff that does not do multipart - it would work for UUI as well as anything else that wished it could use multipart but can't. The ideas is we make a new SDP session level attribute called multipart that contains a base64 encoded version of the multipart message. Endpoints that support this see this attribute get the multipart data, and them process it as per normal. Endpoints that don't support it just ignore this and use the backwards compatible SDP. Stuff that deals with security of bodies does not change. 

Clearly if we were designing a protocol from scratch we would never do this but we do have this extensibility problem in SIP and this would fix the problem of multipart not being deployable. I'm going to give this some ore thought and if it does not seem totally insane perhaps write up a draft for UUI with it so we can see how they compare.

---

From: Alan Johnston <[email-masked]>
Date: Mon, 8 Nov 2010 04:09:45 -0600

Cullen,

Thanks for your comments on the draft.  As the mechanism is currently only deployed for the ISDN service, security has not been an issue, and the text in the draft isn't very mature.  So your comments and suggestions are most welcome.

Now, I agree S/MIME is not ideal.  S/MIME can be used to sign and encrypt SIP header fields, but it does this by adding a body, as you say.  And adding a body to an INVITE usually means multipart MIME, something we'd like to avoid.  Also, there's that minor issue that few implement S/MIME and no one deploys it...

As for the escaped header field in Refer-To.  If my text misled you to believe that I think that people will unescape an unknown header field, then I need to clean up the text.  I do not think this is true.  However, most implementations that do some variant of attended transfer do support unescaping of Replaces header fields.  This code is written, tested, and people are comfortable with it.  I would ague that extending this running code to also do an unescape a UUI header field is relatively trivial.  Now, compare this with trying to get people to allow unescaping of bodies in a Refer-To - this will be much harder.  I'm not even sure I understand all the potential issues with this and how it should be done - we've just never gone there before.

For you wacky idea, I'm really glad you suggested this.  It is an interesting idea that would have been great about 10 years ago... ;-)  I just don't think that this will work as a non-header solution.  The main issue is that proxies don't touch SDP - only UAs do.  So our requirement for border proxies to be able to filter out UUI would turn them all into B2BUAs.  Now this idea might be useful for other SIP cases where multipart might be used, so I wouldn't give up on the idea entirely.

However, your idea got me thinking, and I have a perhaps wacky counter proposal.  This approach would actually have similar security properties to your proposal but not have the drawback I mention.   

What if we carried the UUI in a header field, but also put some kind of a hash or fingerprint of the UUI as an SDP attribute?  An RFC 4474 signature would then provide integrity protection, which I think is the most important property needed or SIP transport of UUI.  Personally, I think that if confidentiality of the UUI is required, the application itself should take care of that (i.e. the app should encrypt and decrypt the UUI and not rely on some non-existent and non-deployed SIP mechanism).

What do you think?

- Alan -

On Nov 7, 2010, at 4:54 PM, Cullen Jennings wrote:

> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 12 Nov 2010 06:08:50 +0100

Hi,

I think that embedding new bodies within SDP will break 3PCC flows in which INVITE's are generated without SDP if the new information is needed in the same INVITE. This would for example be the case with UUI. Therefore I don't see how mechanism could work.

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Cullen Jennings
> Sent: 07 November 2010 22:54
> To: [email-masked]
> Subject: [cuss] Security in draft-johnston-cuss-sip-uui
> 
> 
> I find the security part of this draft, well, frankly 
> baffling. It says you MUST use S/MIME but says nothing about 
> how given S/MINE in 3261 protect bodes and this is a header - 
> I think more detail would be needed before we decide if it is 
> better to carry UUI in a URI, header, or body.  I'm also 
> interested in if the use of S/MIME would require multipart. 
> Given the non existent deployments of S/MIME, I fairly 
> skeptical about basing the security on S/MIME. I'd love to 
> hear the consensus of the room on will people implement 
> S/MIME  to secure UUI? (note I said implement not deploy)
> 
> In section 3.5 you say that UA's commonly take escaped but 
> unknown header is a Refer-To or Contact and put put them in 
> the resulting message. As I have mentioned many times before, 
> I don't think this is generally true. Thoughts?
> 
> I've got a wacky idea for you... and given the tone of my 
> above points I imagine you might not be in the most open to 
> suggestions mode but give this idea a fair hearing. It wacky 
> and gross even by my low standards but it might be worth considering. 
> 
> We sort of blew it when we did SIP and we have no real 
> forward compatibility mechanism for new bodies without using 
> multipart and we did not mandate multipart as part of the 
> base SIP spec. Now we've tried to fix that but I agree with 
> your basic analysis that the fact of the matter is that lots 
> of existing devices don't support multipart. My proposal here 
> is a general solution to forward compatibility of new bodies 
> in SIP INVITES without breaking stuff that does not do 
> multipart - it would work for UUI as well as anything else 
> that wished it could use multipart but can't. The ideas is we 
> make a new SDP session level attribute called multipart that 
> contains a base64 encoded version of the multipart message. 
> Endpoints that support this see this attribute get the 
> multipart data, and them process it as per normal. Endpoints 
> that don't support it just ignore this and use the backwards 
> compatible SDP. Stuff that deals with security of bodies does 
> not change. 
> 
> Clearly if we were designing a protocol from scratch we would 
> never do this but we do have this extensibility problem in 
> SIP and this would fix the problem of multipart not being 
> deployable. I'm going to give this some ore thought and if it 
> does not seem totally insane perhaps write up a draft for UUI 
> with it so we can see how they compare. 
> 
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 18 Nov 2010 16:36:42 -0700

> Now, I agree S/MIME is not ideal.  S/MIME can be used to sign and encrypt SIP header fields, but it does this by adding a body, as you say.  And adding a body to an INVITE usually means multipart M…
agree

> As for the escaped header field in Refer-To.  If my text misled you to believe that I think that people will unescape an unknown header field, then I need to clean up the text.  I do not think this…

Right - I agree with that. I think the text might need a bit of updates to make that clear. 

> What if we carried the UUI in a header field, but also put some kind of a hash or fingerprint of the UUI as an SDP attribute?  An RFC 4474 signature would then provide integrity protection, which I…

That's an interesting idea - deals with a bunch of my concerns. What size do you think the UUI data encoded in the a SIP header will be. I've been looking at the size limits configured in some SBC for headers (and for that matter some SIP stack in proxies also have size limits in the headers).

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 18 Nov 2010 16:38:09 -0700

Well, I think the code is going to have to change on devices that generate new invites with UUI information no matter what we do so this seems like not too big an issue one way or the other.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 19 Nov 2010 10:16:47 +0100

The problem is not in generating the INVITE with UUI information but receiving it. 

3PCC scenarios in which an INVITE without SDP is used are widely deployed and trying to extend SDP to include anything other than SDP will break all these existing 3PCC deployments. We cannot say that UUI will not be needed in a 3PCC INVITE without SDP so we cannot put it in an SDP body.

I vote for including it in a header.

Regards
Andy

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 18 November 2010 23:38
> To: Hutton, Andrew
> Cc: [email-masked]
> Subject: Re: [cuss] Security in draft-johnston-cuss-sip-uui
> 
> 
> Well, I think the code is going to have to change on devices 
> that generate new invites with UUI information no matter what 
> we do so this seems like not too big an issue one way or the other. 
> 
> > I think that embedding new bodies within SDP will break 
> 3PCC flows in which INVITE's are generated without SDP if the 
> new information is needed in the same INVITE. This would for 
> example be the case with UUI. Therefore I don't see how 
> mechanism could work.
> > 
> > Regards
> > Andy
> > 
> > 
> >

---

From: Alan Johnston <[email-masked]>
Date: Mon, 22 Nov 2010 09:12:48 -0600

Cullen,

Thanks for your comments.  See mine below.

- Alan -

> Right - I agree with that. I think the text might need a bit of updates to make that clear. 

I will do so in the next version.

> That's an interesting idea - deals with a bunch of my concerns. What size do you think the UUI data encoded in the a SIP header will be. I've been looking at the size limits configured in some SBC…

ISDN UUI is limited to 128 octets, so that isn't too big.  We haven't yet decided if we will keep that size restriction in non-ISDN UUI or allow an application usage to determine the maximum size.  I do not think UUI should be large - if it gets too large, then passing by ref in a Call-Info is a better approach.  And we would not want UUI to become a "torture test" message...

I'll see if I can find out what some common size limitations in real implementations are - we would do well to avoid being even close to these.