Subject: Re: [martini] Proposed work split: tackle telephone-numberregistration first

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 1 Feb 2010 18:29:38 -0800

Dean said:

"The problem with SIP URIs is: what domain would go in the To:? Clearly it
has to be the domain of the SSP, for all of our domain- authority work to do
what it is supposed to do. 

There are still some questions about the security implications of multiple
registrations over one Outbound connection, but I'm thinking (hoping?) those
could be resolved by a carefully worded applicability statement."

[BA]  Yes, in the case you mentioned the domain in the To: would be the
domain of the SSP, since only the Request-URI is remapped.   As far as I can
tell though, this doesn't lead to any of the problems referred to in the
Problem Statement document.  Are there other issues we should be thinking
about? 

In terms of the security issues, I can understand the potential need to
validate the remapping (e.g. you don't want to allow anyone to use "pbx.com"
as a contact domain).  But that concern exists for single-AOR registration
as well as multiple.   Is the concern that different AORs could be mapped to
different contact domains and that this could intermingle requests among
different "virtual PBXes"?   If so, then each "virtual PBX" can just use its
own separate connection, no?

---

From: Dean Willis <[email-masked]>
Date: Tue, 2 Feb 2010 00:00:01 -0600

On Feb 1, 2010, at 8:29 PM, Bernard Aboba wrote:
>
> [BA]  Yes, in the case you mentioned the domain in the To: would be  
> the domain of the SSP, since only the Request-URI is remapped.   As  
> far as I can tell though, this doesn’t lead to any of the problems  
> referred to in the Problem Statement document.  Are there other  
> issues we should be thinking about?

I have not yet thought through P-Associated-URI in the context of the  
proposal. I'm pretty sure it blows chunks (dramatically doesn't work),  
but I might be wrong. Path, Service-Route, and Outbound work  
unmodified, AFAIK, with the restriction that the vectors are the same  
for all contacts resulting from a single request.

>
> In terms of the security issues, I can understand the potential need  
> to validate the remapping (e.g. you don’t want to allow anyone to  
> use “pbx.com” as a contact domain).  But that concern exists for  
> single-AOR registration as well as multiple.

Yes, the authorization problem is essentially the same as with  
individual registration. Authorization is a provisioning problem, not  
a registration problem. The SSP must be able to answer the question  
"Is the identity asserted by the PBX allowed to register for every AOR  
produced by expansion of the request?" Further, the SSP must be able  
to authenticate the identity of the PBX.

  I believe the syntax I proposed works with an unmodified digest  
authentication as well as mutual TLS and RFC 3274 (asserted by PBX).  
I'm not certain about Adam's syntax with digest.

> Is the concern that different AORs could be mapped to different  
> contact domains and that this could intermingle requests among  
> different “virtual PBXes”?   If so, then each “virtual PBX” can just  
> use its own separate connection, no?

Yes, that's right. The PBX would need something like a virtual-domain  
table showing which domain is in-use for each connection. If Outbound  
is used with TLS, this is easy; for "conventional SIP", we need a  
virtual-domain demuxer within the user-part of the contact, and such  
could be constructed by PBX using either of the two syntaxes so far  
suggested.

The other open question is what, if any, security implications arise  
from having multiple registrations sharing the same "flow" in  
outbound. I cant see any as yet, but that doesn't mean they aren't  
there. Obviously, PBX has the ability to spoof/mix/match/whatever the  
identities of users on the PBX; it is the trust anchor for identity  
assertion within the set of identities the PBX is authorized to  
express, much as any UNIX host could lie about identd.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 02 Feb 2010 11:23:38 -0500

Bernard Aboba wrote:
> Dean said:
> 
> “The problem with SIP URIs is: what domain would go in the To:? Clearly 
> it has to be the domain of the SSP, for all of our domain- authority 
> work to do what it is supposed to do.
> 
> There are still some questions about the security implications of 
> multiple registrations over one Outbound connection, but I'm thinking 
> (hoping?) those could be resolved by a carefully worded applicability 
> statement.”
> 
> domain of the SSP, since only the Request-URI is remapped.   As far as I 
> can tell though, this doesn’t lead to any of the problems referred to in 
> the Problem Statement document.  Are there other issues we should be 
> thinking about?

Then is the To used by the PBX *always* sip:<number>@SSP, even when the 
call is intra-pbx??? Most likely the originating device doesn't know if 
the call is inter-pbx or not, so I guess it must be.

And what about From? Typically you would want From to be an address at 
which you can be reached. If you cannot be reached externally via 
sip:<number>@pbx.com, then you don't want that on calls that leave the 
pbx. So you end wanting to use From: sip:<number>@SSP.

Alternatively, all calls originating on the pbx could start out with To 
being sip:<number>@pbx.com, but then any that aren't intra-pbx will need 
to have To, From, etc. all mapped before passing to the SSP.

> validate the remapping (e.g. you don’t want to allow anyone to use 
> “pbx.com” as a contact domain).  But that concern exists for single-AOR 
> registration as well as multiple.   Is the concern that different AORs 
> could be mapped to different contact domains and that this could 
> intermingle requests among different “virtual PBXes”?   If so, then each 
> “virtual PBX” can just use its own separate connection, no?

If security is hooked on From, then you can't really use 
sip:<number>@SSP, because you can't sign that.

	Thanks,
	Paul