Subject: [Sip] comments on draft-ietf-sip-sips

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 23 Jul 2007 09:03:02 -0400

My two main large comments are organizational, but they are important:

1. the draft reads like a union of an informational overview of sips and 
a normative specification of sips. If this draft is meant to normatively 
describe sips, section 3 needs to turn into a proper overview of 
operations section. Right now it is enormous, way out of wack for what 
it should be.

2. the normative rules are very hard to follow. They need to be split up 
in the way described in rfc4596, and have clear rules for UAC, UAS and 
proxy. They should separately handle dialog forming requests, mid-dialog 
requests, registrations, and non-dialog requests for all three.

Some more specific comments:

>  While SIPS is useful to request that a resource be contacted
>    securely, it is not useful as an indication that a resource was in
>    fact contacted securely.

This is not quite true; its an indication that, if you trust all
proxies, the resource will be contacted securely.

> There is
>    currently no mechanism to provide an indication of end-to-end
>    security for SIP. 

I think its worth noting here that this is a consequence of the
difficulty in doing this. The fact that we have both signaling and
media, that the connectivity is between two endpoints and not just
client/server, and things like conferences and PSTN gateways make this
incredibly complicated - far more than a web server.

> Some have asked why is SIPS useful in a global open environment such
>    as the Internet, if (when used in a Request-URI) it is not an
>    absolute guarantee that the request will in fact be delivered over
>    TLS on each hop?  Why is SIPS any different than just using TLS
>    transport with SIP? 

there are two separate questions here and your text that follows answers
only the second.

To answer the first, I think its important to point out that, a large
number of deployments make an assumption that the servers are trusted.
In such a deployment, sips provides protection against a large number of
attacks that would otherwise be possible. It prevents against
eavesdropping of signaling, modification of signaling, and other attacks
by any outsider. The only attack it does not mitigate is ones where the
network infrastructure itself is the attacker. However, the view is that
its level of security is satisfactory for many applications.

> It is outside of the scope of this document to specify what
>    happens when a SIPS URI identifies a UAS resource that "maps" outside
>    of the SIP network, for example, to other networks such as the PSTN.

A SIPS URI never identifies a resource outside of SIP; its definition is
that it identifies a sip resource. That resource may just happen to be a
number on a PSTN gateway, which the gateway then chooses to contact
through the PSTN. The main point is that SIPS protects only within the
SIP network, from UAC to UAS.

Section 3.2.1 is really short and its not clear why its not just folded
into 3.2, or else 3.2 should be split up more.

> Since upgrading from SIP to SIPS is allowed in other circumstances
>    (e.g., a user "guessing" a SIPS AOR from a SIP AOR on a business
>    card), 

I think its important to be clear here that this upgrading is by a human
user and not by a proxy.

Also the term guessing is wrong since its not a guess at all that this
is the right URI. It is. Its only a guess about whether it will work. Of
course you can't know in advance if a call to a non-SIPS URI will work
either. So I'd suggest nuking the 'guessing' term.

Section 3.3 is pretty clear on downgrading but is very vague on
upgrading. Some clear statements here are needed.

> to describe how to achieve backward compatibility.  If a proxy
>    conforms to this specification, the procedures in this section are
>    not used.

If we have eliminated changing from SIP to SIPS we should nuke this
section. Anyway double record-routing is now documented in the
record-route-fix draft so why do we need it here.

> The reinstatement of the transport=tls parameter, or of an
>    alternative mechanism for indicating the use of the TLS on a single
>    hop in a URI, is outside the scope of this specification (see
>    Appendix A.3).

Its really odd that we have a whole section explaining how it works,
followed by a statement that says ignore the previous section since we
are not re-instating it. If its in, we should describe it. If its out,
we should say so, and thats it. I personally think real world experience
has shown it useful and we should keep it.

> When presented with a SIPS URI, a UAC or UAS MUST NOT change it to a
>    SIP URI.  For example, if a directory entry includes a SIPS AOR, the
>    UAC must not send requests to that AOR using a SIP Request-URI.
>    Similarly, if a user reads a business card with a SIPS URI, he should
>    not infer a SIP URI.  If a 3XX response includes a SIPS Contact
>    header field, the UAC MUST NOT replace it with a SIP Request-URI
>    (e.g., by replacing the SIPS scheme with a SIP scheme) when sending a
>    request as a result of the redirection.

I think with user interaction this is fine, and certainly cannot be 
prevented.

> If a UAS does not wish to be reached with a SIPS URI but only with a
>    SIP URI, it SHOULD respond with a 418 (SIPS Not Allowed). 

Respond to what? I think you need to say, "request whose request-URI is 
a SIP URI"

> Upon receiving a 416 or 418, a UAC MUST NOT re-
>    attempt the request by automatically replacing the SIPS scheme with a
>    SIP scheme as described in [RFC3261]/8.1.3.5 as it would be a
>    security vulnerability.  If the UAC does re-attempt the call with a
>    SIP URI, it SHOULD get a confirmation from the user to authorize re-
>    initiating the session with a SIP Request-URI instead of a SIPS
>    Request-URI.

These two sentences are contradictory.

Section 4 really needs to have separate behaviors for UAC and UAS, proxy 
and registrar.

> The UAC registers Contacts header fields to either a SIPS or a SIP
>    AOR.  From a routing perspective, it does not matter which one is
>    used for registration as they identify the same resource.

the part, "which one is used" could refer to either contact or AOR. You 
should clarify you mean AOR in the To header field.

> Similarly, a UA SHOULD NOT register both a SIP
>    Contact header field and a SIPS Contact header field in separate
>    registrations as the SIP Contact header field would be superfluous.

What should proxy routing logic be in this case? Should clarify.

> If all the Contact header fields in a REGISTER are SIPS, a SIPS AOR
>    MUST be used by the UAC in the REGISTER.  If at least one of the
>    Contact header fields is SIP or is neither SIP nor SIPS (e.g.,
>    mailto, tel, http, https), a SIP AOR MUST also be used by the UAC.
>    However, the registrar MUST treat the SIP and SIPS schemes of the AOR
>    the same way (i.e., it MUST not care if it is SIP or SIPS).  These
>    are purely mechanical rules with no influence on routing.

The MUST requirement for setting the AOR in the To header field doesn't 
make sense when combined with the requirement that proxies MUST treat 
sip and sips the same. The requirement on the AOR in the To from a UAC 
probably should be a SHOULD. Also you should be clear that when you say 
AOR you mean To header field since there is an AOR in the From header 
field also.

> Furthermore, it is a matter of local policy for a UA to accept
>    incoming requests addressed to a URI scheme that does not correspond
>    to what it used for registration.  For example, a UA with a policy of
>    "always SIPS" would address the Registrar using a SIPS Request-URI
>    over TLS, 

This is the first mention of setting the R-URI in REGISTER. I think its 
important. Indeed this paragraph provides the clearest guidance on what 
to do, and its not normative text..

> A registrar MUST only accept a binding to a SIPS Contact header field
>    if all the appropriate URIs are of the SIPS scheme, otherwise there
>    could be an inadvertent binding of a secure resource (SIPS) to an
>    unsecured one (SIP).  This includes the Request-URI, the Contacts and
>    all the Path headers, but does not include the From and To headers.
>    If the URIs are not of the proper SIPS scheme, the registrar MUST
>    reject the REGISTER with a 419 (SIPS Required).

You need to define 'appropriate'. Please state explicit cases and 
behaviors that are required.

> If the Request-URI in a request that initiates a dialog is a SIP URI,
>    then the UAC needs to be careful about what to use in the Contact
>    header field (in case Record-Route is not used for this hop).  If the
> 
> 
> 
> Audet                   Expires December 27, 2007              [Page 17]
> 
> Internet-Draft                    SIPS                         June 2007
> 
> 
>    Contact header field was a SIPS URI, it would mean that it would only
>    accept mid-dialog requests that are sent over secure transport on
>    each hop. 

I thought we were going to forbid this case. If the R-URI is SIP, then 
Contact, Route, etc. are all SIP. If the R-URI is SIPS, then Route and 
Contact are SIPS. Mixed modes not allowed.

> When a target refresh occurs within a dialog (e.g., re-INVITE,
>    UPDATE), the UAC and UAS MUST include a Contact header field with a
>    SIPS URI if the original request used a SIPS Request-URI.

You'll get this for free as a side effect of normal dialog processing rules.

> Note that a REFER may also be used for referring to resources that do
>    not result in dialogs being created.  In fact, a REFER may be used to
>    point to resources that are of a different type than the original one
>    (i.e., not SIP or SIPS).  Please see [RFC3515]/5.2 for security
>    considerations related to this.

So what is the normative requirement here. Is it allowed to send a REFER 
on a SIPS dialog, to an http URI?

> If the wrong scheme is received in the GRUU (which would be an error
>    in the registrar), the UAC SHOULD treat it as if the proper scheme
>    was used (i.e., it SHOULD replace the scheme with the proper scheme
>    before using the GRUU).

what is the value in having this behavior? I think handling of errors in 
registrar like this is out of scope.

> When a proxy receives a request with a SIP Request-URI, the proxy
>    MUST NOT forward the request to a SIPS Request-URI.  If the target
>    UAS had registered previously using a SIPS Contact header field, and
>    the proxy decides to forward the request, it MUST replace that SIPS
>    scheme with a SIP scheme while leaving the rest of the URI as is, and
>    use the resulting URI as the Request-URI of the forwarded request.
>    The proxy MUST use TLS to forward the request to the UAS.  

when the R-URI is SIP, you MUST use TLS??

> 4.2.  Proxy Behavior

This section is missing an essential behavior somewhere, that needs to 
be very clear that when targeting a SIPS URI, you MUST send over TLS.

> Using a Redirect Server with TLS instead of using a Proxy has some
>    limitations that have to be taken into account.  Since there no pre-
>    established connection between the Proxy and the UAS (such as with
>    [I-D.ietf-sip-outbound]), it is only appropriate for scenarios where
>    inbound connections are allowed.

I don't follow this. You can have redirects and redirect servers with 
pre-established connections. What use case are you referring to here?
 From the paragraph below it seems you are assuming that the redirect is 
at the home proxy, redirecting to the registered UA's Contact. I agree 
this is not likely to work but its not likely to work without sips either.

> When a redirect server receives a request with a SIP Request-URI, the
>    redirect server MAY redirect with a 3XX response to either a SIP or a
>    SIPS Contact header field.  If the target UAS had registered
>    previously using a SIPS Contact header field, the redirect server
>    SHOULD return a SIPS Contact header field if it is in an environment
>    where TLS is usable (as described in the previous paragraph).  If the
>    target UAS had registered previously using a SIP Contact header
>    field, the redirect server MUST return a SIP Contact header field in
>    a 3XX response if it redirects the request.
> 
>    When a redirect server receives a request with a SIPS Request-URI,
>    the redirect server MAY redirect with a 3XX response to either a SIP
>    or a SIPS Contact header field.  If the target UAS had registered
>    previously using a SIPS Contact header field, the redirect server
>    SHOULD return a SIPS Contact header field if it is in an environment
>    where TLS is usable.  If the target UAS had registered previously
>    using a SIP Contact header field, the redirect server MUST return a
>    SIP Contact header field in a 3XX response if it chooses to redirect;
>    otherwise it may reject the request with a 418 (SIPS Not Allowed).

these two paragraphs are nearly identical. Should merge them or something.

Also this section treats only the case of a redirect server that is 
redirecting to registered contacts. This never really happens. most 
redirect servers are things like route servers that return PSTN gateway 
routes. You should handle this case and I think say that a server 
receiving a SIPS r-uri SHOULD redirect to SIPS.

> The UAS or proxy cannot process the request because the SIPS scheme
>    is not allowed.  This response differs from 416 because the UAS or
>    proxy recognizes the SIPS URI but it is not allowed, and because the
>    UAC SHOULD NOT retry the request automatically using a SIP URI.

why shouldn't it retry?

* draft should probably talk about the tel URI, and discuss how to handle it

Minor/Nits:

> In this model, both the TLS client and the TLS server provide a
>    certificate in the TLS handshake phase.  When no TLS connection is in
>    place, the UAC would therefore take on the role of the TLS Client and
>    the UAS would therefore take on the role of the TLS server.  Since in
>    SIP, a UA or a Proxy act both as UAC and UAS depending on if they are
>    sending or receiving requests, the symmetrical nature of mutual TLS
>    is very convenient. 

This paragraph is confusing. The discussion on UAC and UAS is misleading
since its only true for UA to UA communications. Also a proxy is not a
UAC or UAS; the terms are client and server.

>    UA a                        Proxy                         UA b
>
>          -------REQUEST sips:-------->-------REQUEST sip:--------->
>                                         Record-Route: <sip:p;lr>,
>                                                       <sips:p;lr>
>
>          <------Response sips:-------<-------Response sip:---------
>           Record-Route: <sip:p;lr>      Record-Route: <sip:p;lr>,
>                         <sips:p;lr>                   <sips:p;lr>
>
>                       Record routing from SIPS to SIP

The terms 'Response sips' and 'Response sip' are kind of meaningless
since there is no such URI in the response. Suggest you clarify instead
where there is TLS and relabel REQUEST to REQUEST-URI.

> When [I-D.ietf-sip-outbound] is used, a transport parameter in a
>    REGISTER message would normally be ignored since the existing
>    connection is re-used instead.

This is true for Contact, not for other fields.

> In a Contact header field in a dialog-creating request, it would only
>    be useful in the cases where Record-Route is not used.  However, as
>    described in this specification, this is extremely unlikely to work
>    because of the difficulty in establishing the TLS connection between
>    peers (i.e., they would need to have certificates).

too many 'its' and 'this' in this paragraph - needs clarification.

> The UAC registers Contacts header fields to either a SIPS or a SIP
>    AOR. 

s/contacts/contact
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip