> -----Original Message----- > From: Jonathan Rosenberg [mailto:[EMAIL PROTECTED] > > If you are accepting the notion of trust domain defined in 3324 and used > by 3325, then I think PASS doesn't provide any additional value. If we > do indeed all mutually trust each other, then why do I need to > cryptographically verify the asserter?
There're a couple points: 1) The trust-domain's transitive nature is brittle - we all know this, and the easy answer is "transitive trust doesn't work" or "that's the nature of transitive trust", but I think there are different levels of what one can and can't believe in for transitive trust - or at least I think providers have different concerns. For example I don't think providers are very worried about MitM attacks, even in transitive trust domains. (Or rather they worry about it in a different way) And I don't think they're very worried about explicitly malicious providers in a transitive trust context. But I do think they're worried about systems that are mis-configured or more open; or at least I think they will be when peering grows and gets more end-end SIP. 2) PAI's trust-domain is not fully transitive, in practice. By that I mean some providers trust the PAI asserted by a peer, but not PAI's transited by that peer (PAI's asserted by domains beyond that peer). Without some asserter identifier it's tricky to figure out the scope of the assertion trust domain. In other words you could have providers A--B--C, and C trusts B's PAIs for calls originating at B, but not transiting through it. One possible way to address those is with just a P-Asserter value, and not bother to sign it - under the rationale that if you're not worried about malicious behavior or MitM or whatever, an asserter identifier is sufficient to determine scope, and troubleshoot and such. But I'm guessing that certain provider domains may be more believable by some folks based on their size or brand reputation, and that those high-profile providers would want to protect their brand from being used/abused by others. But it's just a guess. > Indeed, I'd go so far as to say that, your draft is trying to add > cryptographic assertions to PAI so that it has some possibility of being > used on the Internet and in topologies that don't fit the trust domain > definition of RFC3324/5, and in that sense it really is an alternative > to RFC4474. Sort of, yes. The idea for adding a P-Asserter id actually started before the idea of signing it - some of my customers were running into issues with PAI where troubleshooting it was painful in big peering arrangements (they weren't purposefully fraudulent, just wrong). Then I was having an off-line discussion with some folks on this mailing list regarding 4474 Identity, and someone mentioned that PAI was very popular and that some providers will think PAI is good enough for identity. So then we got into a discussion of why PAI will fail, and I suggested we just sign it, instead of From, and so yes that's the genesis of the draft. But no I don't mean it for the "Internet", because it won't work right for all use cases/scenarios, and only applies for PAI. > What I think is missing from your draft is a clear discussion of what > attacks are possible in RFC3325 which are now prevented here. Barring a > reputation system or whitelist of asserters, I wasn't clear there were > any. Would you agree? Yup. I should add that in far more detail. -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
