Subject: RE: SIPS related clarifications (was: [Sip] SIPS question)

From: [email-masked]
Date: Tue, 3 Dec 2002 15:32:29 +0530

Hi Peterson,

Thanks for your response. Please find some comments inline.

Regards,
Siddharth.

-------------------------------------------------------
Siddharth Toshniwal
Hughes Software Systems
Prestige Opal                    http://www.hssworld.com
146, Infantry Road          Ph (O): +91-80-2286390 (7094)
Bangalore-560001, India           Mobile: +91-9845154068
-------------------------------------------------------

> We did discuss this issue a bit in Atlanta.
> Unfortunately, I think all we agreed on is that we
> all need to think about it some more.

Aside from this question, can someone suggest what is
the best way to track open issues related to the spec?

I tried the bugzilla this time around, but as you
mentioned some issues (like this one) may take a while
to reach there if there are other significant issues
surrounding the original question that you wish to
discuss before proposing a solution.

If the spec is going to undergo rewording in some aspect,
I would request the authors to post to the discussion
list while they discussed the changes... else people
may implement incorrect behaviour and would need to go
back and change the same when the draft gets fixed.

It would help if you could give me a pointer for this
IETF's minutes regarding SIP issues that were discussed.

>> * Is it allowed for a SIP proxy that got a request on
>>   TLS to forward the request downstream on a non-TLS
>>   protocol?
>
> Depends on what you mean by 'got a request'. This also
> doesn't say whether or not SIPS appears in the Request-URI
> or not; it is possible for a proxy server to receive a
> request over TLS that does not have the SIPS URI scheme
> in the Request-URI.

I'm sorry for the ambiguity in my question. I had
referred to the foll scenario:

Lets say that the request-uri does not contain
"sips:" but the request was received on TLS (perhaps
because of a Route header configured with a previous
hop). Can the proxy send it downstream on a non-TLS
protocol if there are no more Route headers present
in the message?

From your mail, I gather this is allowed.

<snip>
>>  while Rosenberg had mentioned that the presence
>>   of "sips:" should imply that the end-to-end path is
>>   secure.
>
> If SIPS appears in the Request-URI of the original
> request sent by the UAC, it implies this end-to-end
> path security.
</snip>

<snip>
>> I guess the way I understand the spec stands
>> at present is that if the Req-URI is re-written to a
>> "sips:" URL at any stage of the routing, then any hop
>> downstream _from_this_hop_onwards_ has to forward the
>> request on TLS.
>
> I agree, that is how we should understand it - with the
> caveat that SIPS only applies to the entire path until
> it reaches the domain indicated by the hostname portion
> of the Request-URI. Once a proxy server in the destination
> gets hold of the request, it can retarget it arbitrarily
> (to non-SIPS resources, if it wishes).
</snip>

Aren't the 2 texts quoted by you at opposite ends?

a) the UAS cannot be sure of end-to-end security if it
   received a INVITE with the request-URI as "sips:" ...
   Some hop in the middle could have modified the req-URI
   for "sips:". It may even be the proxy with whom the UAS
   registered with the Contact as "sips:" ?

b) (If the caveat that you mentioned holds) the UAC
   cannot be sure that the UAS received the request
   on TLS. Shouldn't the destination's proxy be
   disallowed to route a request received on TLS to
   a non-TLS client?

>> * What is the response code to be used by a UAS to
>>   inform the UAC that it is not willing to accept
>>   insecure calls and that the UAC should retry the
>>   request on TLS?
>>
>
> Although 416 might look like an attractive candidate, the language in
> 8.1.3.5 makes it a little ugly. I would suggest 403.

can we add this text to the spec too if everyone agrees on it?

_______________________________________________
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

---

From: "F.S.Salloum" <[email-masked]>
Date: Tue, 3 Dec 2002 17:12:03 +0200

Dear all,

<Siddharth>
	>From your mail, I gather this is allowed.
</Siddharth>

I believe that the difference between sip over TLS and
sips over TLS is the following

Using sip: over TLS the UA that sends the requests over
TLS to a proxy server has no assurance that TLS will be used
end-to-end  (RFC3261:pp238)

Using sips: over TLS the SIPS scheme signifies that each
hop over which the request is forwarded, until the request
reaches the SIP entity responsible for the domain portion of the
Request URI must be secured with TLS; once it reaches the domain
in question it is handled in accordance with local security and
routing policy, quite possibly using TLS for any last hop to a UAS.
(RFC3261:pp238)

<Siddharth>
	<snip>
	> request sent by the UAC, it implies this end-to-end
	</snip>
</Siddharth>

In this case end-to-end actually referes the UAC and the first entity
in the domain in question then it depends on the local security and routing
policy
of that domain.

<Siddharth>
	<snip>
	</snip>

	The UAS by parsing the sips is sure that security exist
	between the previous hop and him.
	The UAC initiator is the only one sure for end-to-end security (till the
domain etc)
	because he has initiated a session using sips:

</Siddharth>

I believe that end-to-end security is reffered between the UAC and
the first entity in the domain in question and not the final UAS this
depends on routing and local security policy. For example the edge proxy
may connect with the UAs or the final UAC using IPSec since maybe the UAs
have a pre-shared kwying relationship with their first-hop proxy server.

The sure thing is that when something is sent with sips then the sender is
sure that
it will be sent securely till the referenced domain ...

if a UA receives something with sips it is sure that has been sent securely
from the previous hop...

Regards
F.S.Salloum