> -----Original Message----- > From: Elwell, John [mailto:[EMAIL PROTECTED] > > This is an interesting draft, but I am not sure to what extent it > addresses the e2e identity issues discussed in > draft-elwell-sip-e2e-identity-important, even though that draft is > referenced in section 1.1 of your draft. If a request or response passes > through two or more trust domains, the UA will receive only the > assertion from the nearest trust domain. Also the P-Original-To header > field will not necessarily contain the original To value.
PASS is intended to only address such issues in specific deployment scenarios, just as PAI is. I don't think I said PASS was end-to-end in all scenarios - just for a given trust-domain, and yes the scope of PAI and PASS is tied. The main scenario for its use would be one of a single trust-domain, including one where there are stub nodes/domains attached to that trust-domain but are not technically in it, and are not transits themselves. For example, a scenario such as: A ---[ SP1 --- SP2 --- SP3 ]--- B Where SP1/SP2/SP3 are all member of a single PAI trust domain, and A and B are endpoints or Enterprises. If SP2 is not in the trust domain of SP1 or SP3, then following the rules of rfc3325, SP3 would not believe any PAI received from SP2 (or at least one that doesn't identify an identity in SP2). If SP3 thus removes the PAI or changes its contents, it will invalidate the PASS signature clearly (which is a good thing essentially), if that's not also removed. (and you point out something that should definitely be discussed in the draft) But really PASS is only attesting to the Asserter's identity and what it claims the PAI/POT are. If SP3 changes the PAI/POT, why shouldn't B believe SP3 over all the others? It's the trust-domain it has a relationship with. It's not optimal, but the whole issue is SP3 is claiming a different PAI/POT than what A/SP1/SP2 did. Imagine this in the 4474 context - if SP3 changed the From/To, what should the behavior be? The answer is "well SP3 shouldn't change those things", and likewise here. The "good" part about this is if SP3 gets it wrong, then B knows who got it wrong and can complain to SP3. The issue though I think you're trying to get to is the ability for an Enterprise to forward calls from outside its domain into service providers, which you've told me before would mean the service provider inserts a PAI which identifies the Enterprise rather than the true originator. In other words that SP3 will insert a PAI identifying a "default" SP3 identity, even though the request came from A in the previous example. In my mind that PAI behavior is clearly broken - it's not following rfc3325, and it's not really useful. If TISPAN wants to make the PAI an ANI instead of a CLID, it should at least define a parameter to indicate it as such for such cases, because the receivers of that PAI will use it for caller-id display otherwise. PASS signing the PAI in such a case only points out the bad behavior - if SP3 doesn't feel it should be signing such a PAI, then why is it generating such a PAI? > By the way, > there is no syntax definition for P-Original-To. It's shocking how the ID submission tool removes entire sections. Just kidding. Yes good catch - will add it in next rev. :) > A proxy in one trust domain might pass on PAI (and hence PASS) to an > untrusted proxy. According to RFC 3325, that second proxy, assuming it > likewise does not trust the first proxy, must remove PAI. Presumably it > would also be required to remove PASS headers. This is not clear in the > draft. Section 8 talks about forwarding to an untrusted proxy, but does > not talk about receiving from an untrusted proxy. Right, another good catch - will fix. I need to say the PAI and PASS fates are shared. > Presumably, after removing PAI and PASS headers from a message from an > untrusted node, a proxy could insert its own PAI and PASS headers. Hence > we end up only with hop-by-hop authenticated assertions still. Yes, but not hop-by-hop, rather trust-domain by trust-domain. It's not panacea, but it covers a lot of ground in the real world methinks, where so far the majority of usage has only one trust-domain (the PAI gets all the way through). -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
