inline:
Hadriel Kaplan wrote:
-----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.
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 - stub2
with 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
[EMAIL PROTECTED]
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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
