inline: Hadriel Kaplan wrote:
-----Original Message----- From: Elwell, John [mailto:john.elwell at siemens.com]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 responsepasses 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.
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?
I would argue that your draft is really trying to make PAI work in a different type of 'trust domain' - one in which there are some folks that I trust a lot less. So if I have:
stub1 - SP1 - SP2 - stub2with stub1 and stub2 being enterprises which insert their own PAI, your draft would allow stub2 to determine that it was indeed stub1 who inserted the PAI, and stub2 can utilize reputation systems or whitelists/blacklists to deal with ones that misbehave.
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.
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?
Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 499 Thornall St. Cisco Fellow Edison, NJ 08837 Cisco, Voice Technology Group jdrosen at cisco.com http://www.jdrosen.net PHONE: (408) 902-3084 http://www.cisco.com _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip