Maybe I don't understand what your update draft is trying to accomplish, or maybe I don't understand RFC 3325. They're written in English, but English is not my native language, so who knows. My belief is that your draft is trying to clarify that PAI can be used in other methods than INVITE, that a trusted UAC can insert it, and that it can be more and different URI schemes. It's not actually changing the fundamental definitions/scope of RFC 3325, right? So let's start with what RFC 3325 is about. For one, it's an Informational RFC for private use. For another, it actually does not say what methods a PAI can be inserted in or not - it only uses the word "message", and in fact says both requests and responses. It very clearly says that if a Proxy trusts a node, then it can believe the information as if it had authenticated the user itself. Are you suggesting your draft is going to remove that, or re-define that? For what purpose? This whole thing is about a private network deciding what "Trust" means to itself! But more importantly, RFC 3325 does not define a particular *instantiation* of a Spec(T). It gives an *example* of one, but that's it. If I decide for my network that all my PSTN Gateways and proxies trust each other, then that is my specific Spec(T). If you decide for your network that only proxies have a trust relationship, then that's your Spec(T). In my network, the PSTN gateways can certainly send back PAI in responses, because they're implicitly authenticated. In your network they can't, because they're outside of the trust domain. And the problem is...? That's why Keith doesn't need to give you any 3GPP use-case. It's not germane to the draft. 3GPP is simply one particular Spec(T). It very well could be a bad one (and I think it has some holes), but that's the nature of a private-use, privately-defined Spec(T) model to begin with, which is all RFC 3325 covers! -hadriel > -----Original Message----- > From: Elwell, John [mailto:john.elwell@xxxxxxxxxxx] > Sent: Monday, December 01, 2008 3:59 AM > To: Hadriel Kaplan; sipping > Cc: Cullen Jennings > Subject: RE: I-D Action:draft-kaplan-sipping-pai-responses-00.txt > > Hadriel, > > Thanks for writing this. However, in my opinion it still suffers from > the same problem that we had with update-pai-06 (where we just said that > the proxy must have authenticated the source of the response by some > means) and update-pai-05 (where we cited one possible circumstance where > authentication could be assumed, i.e., when an earlier request over the > same TLS connection had been digest-authenticated). We received > objections to 06 because it did not cite at least one example of how to > achieve authentication and we received objections to 05 because the > mechanism is broken (there could be an intermediary that terminates the > TLS connection, so there is no guarantee that the UA that was previously > authenticated is the same as the UA that sends the response). > > I think there are only two ways forward on this: > 1. Somebody comes up with some text that describes a plausible way of > achieving authentication using present mechanisms. For example, if my > understanding is correct, I think the 3GPP mechanism relies on using the > same credentials for authenticating the UA and the underlying transport, > and hence the broken behaviour I described above does not apply. I > really wanted somebody else to provide some text, and I had hoped Keith > would do this. > 2. We define a new mechanism. It has been stated that something based on > sip-outbound might be possible, but I don't really know what people have > in mind. As Cullen observes, this approach would most likely need to be > pursued in SIP rather than SIPPING. > > John _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
