[Sip] Comments on rosenberg-sip-identity-coexistence

[Cullen Jennings <[e-mail]>]

I really glad to see this draft on how to migrate from where we are  
today to using Identity. I have some small complaints about parts and  
some suggestions on the B2BUA part but overall really like it. The  
most important part of this email is the B2BUA section near the end.

Section 1:

I think one of  the major reason for creating PAI was to provide  
malicious call trace for anonymous calls. I don't think it was for  
dealing with spoofing the From header. If that was the goal, we could  
have solved it just by having device that ends up inserting the PAI  
just reject any request that has spoofed From headers.

Small nit but ... I think identity was designed such that the UAS  
domain proxy could do everything on behalf of the UAS  as a migration  
step. Clearly that is the point of the draft but the "called party  
must be upgraded to support it" part I don't quite agree with.

My last small nit .... I've sent several posts about why I think  
B2BUA work with Identity in a large percentage of the cases. I think  
this draft seems like a great place to explain all this - both what  
works and what does not. I don't buy into the statement that Identity  
breaks B2BUAs.

Section 2.

One of the design choices we need to make in the originating domain  
is if the ingress or egress proxy inserts the Identity signature. My  
preference is to explain the pro's and cons of this and allow either.  
I see the pros/cons of the egress doing it be that since not all  
calls will require the PKI computation to insert the signature and  
the cons that now the egress proxy has to authenticate the UA which  
in may deployments will involved a re-challenge to UA which like  
inserts another round trip of signaling both to the UA and to the AAA  
server. I see the pros/cons of the ingress doing it that a) all calls  
have it even inside the domain b) we provide integrity protection for  
calls in the domain c) devices receiving the call inside the domain  
can treat the Identity header the same was as call outside the  
domain. I'm sure others millage may vary but my mucking around makes  
me think the ingress proxy doing it will turn out to be best for most  
deployments. It certainly has better security properties and  
depending on your mix of inter/intra domain calls, the trade off of  
the PKI on ingress is offset by extra messaging on egress.

I'm big fan of Terminating domain checking Identity signature and if  
it is OK, then inserting PAI for that. I like this. I think this is  
right. I think this is critical for migration to Identity. If I can  
be any more positive about this idea let me know how :-)

I don't see why we would need the id-coexists options tags. It seems  
like they never get used.


Section 3.3

I don't think that having the PAI override a broken identity will  
really fly from a security point of view. This takes this back to  
something that is only deployable in fully trusted networks. What I  
mean by this is that   if anyone can insert a PAI header, they can  
totally break the integrity mechanism that identity provides.  I  
realize that you are trying to solve the B2BUA issue here - more on  
that later - I agree we need to work with B2BUA but I think we can. I  
like to consider having
rules in this order
1) if there is an invalid identity header, reject call
2) if there is a valid identity header, use AOR in From
3) if three is no identity, look for PAI and use that AOR if exists
4) if no PAI, use AOR in From
Take the AOR and lookup in local address book and if found, display  
the user name associated with that entry in address book otherwise  
display the AOR and if Display Name is used clearly mark it as not  
being secure

2nd para - I might be confused on what you are suggesting here - In  
this section you talk about the UAS knowing if the UAC supports  
Identity or not. I don't know how to do this in a secure way - I  
think it is pretty hard - the approach of using DNS to look it up  
might work but has lots of issues too.

4.1 - I think whichever proxy first authenticates the UAS should  
insert the Identity signature

4.3 - I might be missing some of the stuff you are thinking about  
with the anonymous URI. However, it seems like for anonymous calls  
between domains that have an acceptable RFC 3325 Spec T, they will  
still want to pass the PAI for malicious call trace reasons.

Section 5

Ok, I think that having PAI override PAI would break Identity in a  
way that we would never have strong identity in SIP  - so I think we  
need a better way to work with B2BUA. I think the camarillo-sipping- 
sbc-funcs draft on the where B2BUA gets used and why might be helpful  
for working through the cases. Let me look at some starting cases here

First let me separate telephone numbers from email style AOR. In all  
cases telephone numbers are easy as what you generally want is the  
B2BUA to decide it trusts the number it received, based on Identity  
or other information, then resign with it's credentials. This is  
because the E.164 namespace is not delegated to any of the devices  
doing the signatures. If DNSsec was available, and ENUM was widely  
deployed, more interesting solutions might be available. Probably  
worth thinking about.

So for the case with email style AORs

case 1) an egress B2BUA on originating domain - this one is actually  
trivial to deal with. This B2BUA can have the credentials to  
correctly re-sign the message

case 2) ingress B2B on terminating domain - this is fairly easy too.  
This B2BUA resigns the incoming request. To do this it uses a cert  
that has a wildcard for all domain - the UAS need to be configured to  
have this cert in it root trust list. What the UAS is doing here is  
delegating that it trust any name that the
  B2BUA trusts. This is the sort of trust delegation one wants to be  
able to make.

case 3) a B2BUA in a transit provider between the originating and  
terminating domain. There are two very different cases here - one is  
where the transit provider is an intermediate in providing PSTN  
termination services and using E.164 addresses. For example some  
company, contracts its PSTN termination from say MCI who for numbers  
in Australia perhaps uses Telstra. The company wants to see the phone  
number asserted by MCI, not Telstra  - it is MCI they trust and can  
make an authorization decision based on. They have no idea who  
Telstra is so whatever telstra wants to claim is useless for the  
company. The point is, whatever things Telstra might assert to MCI,  
the company wants MCI to make an assertion that the company can use  
for it authorization decision. In these cases the transit B2BUA needs  
to resign things. The next sub case is where the transit provider  
provides an anonymization service - here you clearly need to resign  
things. The second sub case is not a PSTN termination service but a  
"trust broker" between a bunch of companies. An example of this case,  
a bunch of companies join some consortium and the consortium make  
sure that they can all talk to each other and no bad people are  
allowed to talk them because only good people are in the consortium.  
(I'm always a little confused on the value of all this but many  
people have suggested it might be useful - there is some groups like  
this something to do with drug dealers of america or something that  
people always bring up as an example). Here the consortium has two  
choices, it can provide new names for all the users and remap them or  
it can be  allowed to sign on behalf of the organizations that are in  
it. For example, [e-mail] might become  
alice.example.consortium.com or [e-mail] or even  
just [e-mail]. Or alternatively, the UA that trust  
consortium.com might allow the consortium to have a root cert such  
that it could sign things [e-mail]. There are many options  
here and I find it hard to pick one as I don't really understand why  
this type of service would exist in the first place. However, as we  
work out the requirements for this type of service, I suspect a  
soltuion is possible.

As a last note, I do think there are workable solutions for the B2BUA  
case. Having UA accept message with a bad Identity header but that  
have a PAI seriously breaks Identify. One of the key things that  
Identity provides is a close to end to end integrity for the bodies.  
This breaks this and we have no other good way to provide this. What  
I am suggesting above provides a way to keep this integrity property  
so that no device can tamper with the integrity other than devices  
that the UAS or UAC explicitly trusts to tamper with the integrity. I  
think this is a fairly important property and achievable.

Cullen <with my individual contributor hat on>





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