Subject: [cuss] Comment on draft-johnston-cuss-sip-uui-01

From: "Elwell, John" <[email-masked]>
Date: Mon, 20 Dec 2010 12:54:14 +0100

1. In 3.6: "The requirement for end-to-end
   privacy could be met using S/MIME or using encryption at the
   application layer."
How does S/MIME provide privacy for a header field, which is what 3.6 is talking about?
Also there is a similar issue in section 7 concerning S/MIME and confidentiality.

2. Also in 3.6: "To meet REQ-12 in redirection and referral use cases, a History-Info
   [I-D.ietf-sipcore-rfc4244bis] extension could be used.  During
   redirection or retargeting, History-Info captures the history and the
   identity of the entity performing the redirection or referral.  It
   seems likely that a new History-Info parameter could be defined to
   indicate that the UUI was inserted during this operation.  The source
   of UUI inserted during redirection or referral could then be
   determined by examination of the History-Info header field."
It is unclear to me how this would work. Let's consider the redirection case. The redirect server inserts UUI, but the redirect server does not insert an H-I entry and therefore would not be in a position to insert this new H-I parameter. The recursing entity inserts an H-I entry, but the recursing entity should not need to be aware of escaped UUI in the contact URI, so it too would be unable to insert this new parameter.

For referral it is even less clear, because H-I carries nothing about a referring entity.

John

---

From: Alan Johnston <[email-masked]>
Date: Mon, 20 Dec 2010 08:07:30 -0600

John,

Thanks for your comments on the draft.  See my responses below.   Do
you have any other high level opinions on the mechanism?

- Alan -

> Also there is a similar issue in section 7 concerning S/MIME and confidentiality.

I thought I included the relevant reference to RFC 3261, which is
Section 23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling
SIP.  This section, which I do not plan to reproduce in this document,
describes how S/MIME can be used to provide privacy and integrity
protection of SIP header fields.  Of course, this requires an
additional message body to be included in the request - which I point
out in the next sentence.  This does have some well known drawbacks.
However, this is nothing compared to the main drawback that S/MIME has
essentially no deployment in real SIP networks.  If I had my
preference, I would remove all discussion of S/MIME from the document,
but we have a quaint tradition in writing SIP specs of using S/MIME as
a fig-leaf, so I have continued that here.

> It is unclear to me how this would work. Let's consider the redirection case. The redirect server inserts UUI, but the redirect server does not insert an H-I entry and therefore would not be in a p…

I'm no expert on History-Info, but I can do some design here if folks
think this is an important feature.  You are correct that the redirect
server does not insert H-I, per Section 4.3.4 of RFC 4244.  However,
Section 4.3.1 talks about UAC behavior when redirection occurs where I
believe it is a MAY strength for the UA to add a H-I field about the
redirection.  There are a couple of examples in the text involving
redirection such as:

   History-Info: <sip:[email-masked]?Reason=SIP;cause=302>\
                  text="Moved Temporarily">; index=1,
                 <sip:[email-masked]>; index=2

This is where I would expect we could add a UUI indication.  In fact,
if the full Contact URI is included (I'll need to check to see if this
is recommended), then this would include the escaped UUI header field
from the 3xx, and we would get this without any H-I extensions.

As for whether the UA understands the UUI mechanism or not, I have
tried to clarify the text in the draft around this.

Although RFC 3261 requires UAs to unescape unknown header fields in
URIs, I don't know of any in practice that do this, nor do I suspect
it is good security practice.  Instead, UAs tend to unescape header
fields they understand, such as Replaces and Join.  I would expect the
UUI header field to be similar - only UAs that understand it (and
hopefully there will eventually be lots of them) would unescape it and
use it.  If anyone gets a different impression from any text in this
document, please let me know so I can fix it.

> For referral it is even less clear, because H-I carries nothing about a referring entity.

Right, I was sloppy referring to referral, if you pardon the
expression.  For referral we would need an extension to the
Referred-By mechanism defined in RFC 3892.  Again, if this is
considered important, I can look at the details.  I'm not aware of
much implementation of this header field, although I think a few UAs
include the header field sans the S/MIME body.

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

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 20 Dec 2010 16:08:54 +0100

Alan,

> -----Original Message-----
> From: Alan Johnston [mailto:[email-masked]] 
> Sent: 20 December 2010 14:08
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [cuss] Comment on draft-johnston-cuss-sip-uui-01
> 
> John,
> 
[JRE] Sorry, I forgot to say that I am in agreement with the general direction of the draft (in fact I would support adoption as a WG item). My comments were only on the detail.

> a fig-leaf, so I have continued that here.
[JRE] OK, I see now what you are suggesting. The header field would appear ONLY in the encrypted S/MIME body. But the arguments against using a SIP body part for the solution, including the inability to meet REQ-9, would apply. I completely agree S/MIME is not a viable solution - I just wanted to make sure we didn't make any false claims for S/MIME.

> > It is unclear to me how this would work. Let's consider the 
> redirection case. The redirect server inserts UUI, but the 
> redirect server does not insert an H-I entry and therefore 
> would not be in a position to insert this new H-I parameter. 
> The recursing entity inserts an H-I entry, but the recursing 
> entity should not need to be aware of escaped UUI in the 
> contact URI, so it too would be unable to insert this new parameter.
> 
[JRE] OK, I missed the bit about requiring changes to UACs in order to handle the unescaping of the new header field. Of course, this would apply also to any proxies that choose to recurse rather than passing the 302 back upstream to the UAC. So yes, a new H-I parameter might be feasible.
However, I am still not sure the H-I entry with the new parameter would necessarily identify the inserter of UUI. Perhaps another solution would be a new parameter in the UUI header field identifying the inserting node.

> include the header field sans the S/MIME body.
[JRE] I don't have an opinion as to whether this is important enough to cover.

John