Hadriel, 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. By the way, there is no syntax definition for P-Original-To.
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. 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. "For SIP responses, the P-Original-To URI value would typically be the URI of the From header field. Details on the generation of this header are provided in Section 10." I assume that "this header" refers to P-Original-To. However, I can't find anything on that in section 10. John > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Hadriel Kaplan > Sent: 07 July 2008 23:57 > To: [email protected] > Subject: [Sip] Signing P-Asserted-Identity > > Howdy, > As the discussions about RFC4474 Identity, E.164, and all > that seem of the type that will take a very long time to > resolve, I've submitted an ID about a private extension for > "Asserter Identity", which works in concert with the > P-Asserted-Identity mechanism. It works very similarly to > RFC4474, but doesn't sign quite the same things, and can be > used to sign TEL URI's, fwiw. > > Comments welcomed, of course. > > Title : Private Extensions to the Session > Initiation Protocol (SIP) for Asserter Identification within > Trusted Networks > Author(s) : H. Kaplan > Filename : draft-kaplan-sip-asserter-identity-00.txt > Pages : 18 > Date : 2008-07-07 > > This document describes private extensions to the Session > Initiation Protocol (SIP) that enable a network of trusted > SIP servers to identify the asserter of private user identity > defined in RFC 3325. The use of these extensions is only > applicable inside a set of administrative domains with > previously agreed-upon policies for generation, transport and > usage of such information. > This document does NOT offer a general identity model > suitable for use between different trust domains, or use in > the Internet at large. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-sip-asserter- > identity-00.txt > > -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 > _______________________________________________ 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
