Subject: [Sipping] Another issue with update-pai

From: "Elwell, John" <[email-masked]>
Date: Fri, 21 Nov 2008 15:11:40 +0000

I think Cullen has a concern about the following text:

"If a registrar receives a REGISTER request containing a
P-Asserted-Identity header field, it MUST disregard the asserted
identity unless received over a secure transport from a node within the
Trust Domain. Otherwise it MAY use this as evidence that the registering
UA has been authenticated as representing the identity asserted in the
header field."

I think we may need to delete the second sentence.

John
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 21 Nov 2008 10:18:38 -0500

> I think we may need to delete the second sentence.

I find it troubling to then leave the implied else clause undefined. If 
not this sentence, then what???

	Thanks,
	Paul

---

From: "Theo Zourzouvillys" <[email-masked]>
Date: Sat, 22 Nov 2008 16:48:28 +0000

> I think we may need to delete the second sentence.

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.

 ~ Theo

-- 
Theo Zourzouvillys
Chief Technical Officer
VoIP.co.uk - Commerce House, Telford Road, Bicester, OX26 4LD
Tel: +44 1908 764 196

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 22 Nov 2008 13:01:34 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Theo Zourzouvillys
> Sent: Saturday, November 22, 2008 11:48 AM
>

+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

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 25 Nov 2008 07:21:45 +0000

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 22 November 2008 18:02
> To: Theo Zourzouvillys; Elwell, John
> Cc: sipping
> Subject: RE: [Sipping] Another issue with update-pai
> 
> 
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> > Of Theo Zourzouvillys
> 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.
> 
> 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