On Jan 22, 2010, at 8:11 AM, Paul Kyzivat wrote:

> Dean,
>
> I don't think the points you make about security assumptions have  
> been raised before, and they are important.
>

Thanks! I try to say at least one relevant thing for every three crazy  
ones.

> OTOH, I surmise many of those that are requesting this work may have  
> more limited expectations. Specifically, the argument that "the PBX  
> *is* the user" may indeed apply in the case where the PBX is itself  
> a B2BUA and does all the identity management for all the numbers it  
> is responsible for. So perhaps the registration model would be  
> applicable in that limited (but large) scope of applicability.

You have an excellent point.

If the SSP were a traditional proxy/registrar that is authoritative  
for the domain and the PBX were a multi-user telephone adapter with  
credentials for each user in the domain, such that the PBX could send  
a unique REGISTER for each user, then we might well be having a  
different conversation. This conversation would be about ways to  
reduce the number of REGISTER messages required to effect registration  
of the PBX as a contact for each user. So we might be talking about  
"multiple authentication", perhaps extending the digest-authentication  
model to allow a separate authentication header for each AOR being  
registered. This would preserve the property that the proxy/registrar  
has established an authenticated relationship between each AOR and its  
Contact, a property that is fundamental to REGISTER within RFC 3261  
and its current kin. Such an approach would clearly work reasonably  
well within our current security assumptions, although it should be  
noted that it does not prevent "identity substitution" attacks in the  
PBX. For example, if the PBX chose to claim that a call is from Bob  
when in fact the originating user is Alice, the SSP has no way to  
determine that this substitution has been made. This is a fundamental  
property of a shared connection in SIP (or indeed, in multi-user  
systems in general; how do you know this email came from me and not my  
sysadmin?) and there's not a lot we can do about it short of requiring  
users to provide single-use keys for each transaction (the equivalent  
of me signing this message using PGP).

If we scoped the applicability to such an environment, then I'd be  
willing to accept that REGISTER can be used for a domain, at least to  
the extent I think it works for an individual user (I think REGISTER  
is deeply wounded and we've had to put a lot of ugly bandaids on it to  
keep it from bleeding out). MARTINI could quite reasonably define an  
extension to REGISTER that works within this scope.


However, our discussion recently has centered on models where SSP is  
NOT authoritative for the domain in-question; rather it is just one of  
many possible relays that might be used to reach the domain- 
authoritative "PBX". This model potentially allows SSP to make  
different security assertions. For example, SSP could assert 1) that  
SSP is transitively authorized as a route for reaching the domain of  
pbx.com, and that 2) a request exiting through SSP comes from some  
user in the domain of PBX. Note that this second assertion is not the  
same as SSP being able to assert that a specific user in the domain is  
involved. In this model, only PBX (or perhaps the user itself) can  
make assertions about specific user identities.

The fundamental security question: How does SSP prove to others that  
it is authorized to route requests to/from the domain of PBX? We don't  
have a security framework for this in SIP. This leads to the "alt  
root" problem we recently discussed. What keeps a rogue node from  
claiming to be authoritative as a route toward a domain? For that  
matter, what keeps a node from claiming to be authoritative for a  
domain itself, rather than just as a route toward that domain?

Let's start with this second question and work backwards. Our  
fundamental security model (when we have any security at all) assumes  
that the node that is authoritative for a domain has in its possession  
booth the public and private keys needed to cryptographically assert  
that domain. This understanding comes from the basic references of TLS  
in RFC 3261, and is echoed in our various documents (draft-ietf-sip- 
certs, draft-ietf-sip-domain-certs, etc.). So if we make a TLS  
connection to a node, and that TLS connection uses at the other end a  
trusted cert for the domain in question, then we assume that the other  
end is trusted to assert identities within that domain. RFC 3274  
provides a transitive mechanism for assertion of identity in the  
context of a SIP request message that is also based on this model of  
certification.

So what we need is something like RFC 3274 for route certification.  
This has to allow for route redistribution and aggregation, since  
there might be more than one relay proxy between the source and  
destination of a SIP request. Adam's draft-roach-martini-up-00 defines  
a possible syntax for a "route" (using XML), as well as a means for  
advertising a route (PUBLISH). One can readily envision adding a  
signature to this syntax. It's straightforward then to go from a  
single-hop route to a routing vector, where each hop in the vector is  
signed by the next hop, providing a fully certificated transit chain  
to the destination.

--
Dean