> -----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. -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
