> -----Original Message----- > From: Elwell, John [mailto:john.elwell@xxxxxxxxxxx] > Sent: Monday, December 01, 2008 11:46 AM > > [JRE] Spec(T) applies between trusted nodes. This is not the issue. The > issue is when a proxy receives a response from an untrusted node, on > what basis can it assert an identity for the UAS. Or how can it > authenticate the UAS? That's only one of several scenarios. The pai-responses draft covers the scenarios where the UA is *within* the Trust Domain, for example, and I don't think those are currently covered by your update-pai draft. And my draft said if the UA is outside the Trust Domain, then the Proxy MUST remove any received PAI. I assume the main concern would be the following paragraph: "If a Proxy receives an ACK or CANCEL request from a UAC, or any response for any method from a UAS, and the message does not contain a P-Asserted-Identity header field, the Proxy MAY insert the header field, if it has knowledge of the UA's identity per [RFC 3325]. This would require the Proxy to have previously authenticated the UA's identity over the same secure transport as the response was received from. If the message has a P-Preferred-Identity header value, the Proxy MAY use this information as a hint for P-Asserted- Identity generation, per the rules in [RFC 3325]. The Proxy MUST remove any P-Preferred-Identity from any message it forwards, per [RFC 3325]." I admit that concept bothers me too. Clearly without either a client-side certificate matching the identity, or some shared key model tied to a secure transport's authentication mechanism (like 3gpp), it can't really be done for responses/ACK/CANCEL. That doesn't mean it can't be done. It just means only some can do it. -hadriel _______________________________________________ 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
