> -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@xxxxxxxxxxxxxx] > Sent: 22 November 2008 18:02 > To: Theo Zourzouvillys; Elwell, John > Cc: sipping > Subject: RE: Another issue with update-pai > > > > > -----Original Message----- > > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf > > Of Theo Zourzouvillys > > Sent: Saturday, November 22, 2008 11:48 AM > > > > I don't like the first sentence :-) > > > > we might want to run our registrars on a private vlan with REGISTER > > messages routed via a proxy that is multi homed on public > and private > > vlans and does the security checks for PAI. so there is not > > necessarily a secure transport (i.e TLS) between the proxy and > > registrar, but due to network design PAI in REGISTER can be trusted. > > +1, sort of... > > PAI is defined to be only usable and believable within a > trust domain, as defined by rfc3325 and 3324. RFC 3325 > already says the nodes in a PAI trust domain must be secured > with TLS, although it later adds in IPsec as an option; even > though we know both are summarily ignored in practice. > Technically RFC 3324 only talks about secure "connections", > which is not synonymous with secure "transport" because it > implies TLS. For example a single cable between two nodes in > a secure facility is a secure connection, but not secure transport. > > Also, the second sentence of the draft is confusing because > it uses the word "otherwise" right after saying it must be a > secure transport, which implies if a secure transport is not > used then the second sentence applies, which is not the case. > > To be consistent, I suggest we replace the draft's statement with: > "If a registrar receives a REGISTER request containing a > P-Asserted-Identity header field, it MUST disregard the > asserted identity unless received from a node within the > Trust Domain. If the node is within the Trust Domain, the > Registrar MAY use this as evidence that the registering UA > has been authenticated and represents the identity asserted > in the header field." > > I believe that captures the intent of the draft's current > statement. My only concern is that it creates a possibility > for fraud, because if the Proxy doesn't know about this draft > but the Registrar does, then the UA sending in a PAI can > claim whatever it likes and the Registrar will believe it. > But I guess the very definition of Trust Domain and behavior > of RFC 3325 requires all nodes within it to be on the same > page, so caveat emptor. [JRE] Yes, but at first glance it does not address Cullen's original concern, which was that the second sentence changes RFC 3261 behaviour for a registrar. Cullen contended that RFC 3261 mandated authentication of the UAC. I just looked in section 10.3 of RFC 3261, where it states: "3. A registrar SHOULD authenticate the UAC. Mechanisms for the authentication of SIP user agents are described in Section 22. Registration behavior in no way overrides the generic authentication framework for SIP. If no authentication mechanism is available, the registrar MAY take the From address as the asserted identity of the originator of the request." So authentication is only SHOULD strength. It does not state the conditions under which it is permissible to disregard the SHOULD, but I think the PAI case we are talking about (where PAI is received from a trusted node, e.g., an edge proxy that has authenticated the UAC) is exactly the sort of case where it should be permissible to ignore the "SHOULD". So Cullen and others: can you accept the text that Hadriel proposes above? 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
