Subject: [stir] 8224: "end users"

From: Michael Thomas <[email-masked]>
Date: Tue, 28 Apr 2020 12:50:17 -0700

The Abstract says:

    The baseline security mechanisms in the Session Initiation Protocol
    (SIP) are inadequate for cryptographically assuring the identity of
    the end users that originate SIP requests, especially in an
    interdomain context.  This document defines a mechanism for securely
    identifying originators of SIP requests.  It does so by defining a
    SIP header field for conveying a signature used for validating the
    identity and for conveying a reference to the credentials of the
    signer.

Given the rest of the document, "end user" and "originators" is highly 
misleading. The document acknowledges that although UA's can potentially 
create Identity headers, it is not a very normal use case, and that its 
deployment would be relatively rare. What the abstract, etc seems to be 
asserting is that the verifier should, in fact, be able to trust that 
the user-part of a sip: URI as being authenticated. Putting aside the 
telephone numbers scraped out of sip: uri's, that implication is wrong. 
The receiving party cannot know what the sending party's practices are 
unless it either whitelisted them, or more likely was informed by some 
third party service which audits their practices. A sender making such a 
claim is no better than rfc3514's security protections.

This seems to be sprinkled all over the document, and I haven't taken 
exact notes as to where all of this is implied or more, but this is an 
error and a pretty serious one. If the receiver makes decisions with 
that supposed guarantee in mind, that is exploitable. Even if that is 
not the intent (which is not at all clear), it distinctly leaves the 
reader with that implication. The document should make it completely 
clear that the receiver cannot trust the rfc 8224 sender's word about 
the user-part, and that that is not in scope.

This is should be corrected.

Mike

---

From: "Holmes, David W [CTO]" <[email-masked]>
Date: Tue, 28 Apr 2020 22:29:54 +0000

Michael,

I believe you are referring to the issue of “reputation”; which is a commercial/legal concept & way beyond the purview of any technical standards group to verify.  Validation of the ID of the originating party as described is only one factor that may be used, along with other factors with others as you note, to evaluate the reputation of the originator & allow trust of the originator & potentially of the content of the communication.

BR/David

David Holmes
Standards
Direct 425.256.7082 | Mobile 425.260.1868  |  [email-masked]<mailto:[email-masked]>
Sprint.com<http://www.sprint.com/> | Follow us on Twitter<https://twitter.com/sprint?lang=en>, Facebook<https://www.facebook.com/sprint/> and Instagram<https://www.instagram.com/sprint/>
[A close up of a logo  Description automatically generated]

From: stir [mailto:[email-masked]] On Behalf Of Michael Thomas
Sent: Tuesday, April 28, 2020 12:50 PM
To: [email-masked]
Subject: [stir] 8224: "end users"

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

The Abstract says:

   signer.

Given the rest of the document, "end user" and "originators" is highly misleading. The document acknowledges that although UA's can potentially create Identity headers, it is not a very normal use case, and that its deployment would be relatively rare. What the abstract, etc seems to be asserting is that the verifier should, in fact, be able to trust that the user-part of a sip: URI as being authenticated. Putting aside the telephone numbers scraped out of sip: uri's, that implication is wrong. The receiving party cannot know what the sending party's practices are unless it either whitelisted them, or more likely was informed by some third party service which audits their practices. A sender making such a claim is no better than rfc3514's security protections.

This seems to be sprinkled all over the document, and I haven't taken exact notes as to where all of this is implied or more, but this is an error and a pretty serious one. If the receiver makes decisions with that supposed guarantee in mind, that is exploitable. Even if that is not the intent (which is not at all clear), it distinctly leaves the reader with that implication. The document should make it completely clear that the receiver cannot trust the rfc 8224 sender's word about the user-part, and that that is not in scope.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Tue, 28 Apr 2020 15:41:02 -0700

On 4/28/20 3:29 PM, Holmes, David W [CTO] wrote:
>
> Michael,
>
> I believe you are referring to the issue of “reputation”; which is a 
> commercial/legal concept & way beyond the purview of any technical 
> standards group to verify.  Validation of the ID of the originating 
> party as described is only one factor that may be used, along with 
> other factors with others as you note, to evaluate the reputation of 
> the originator & allow trust of the originator & potentially of the 
> content of the communication.
>
I'm referring to reputation, insofar as that would be one way to vet 
another doman's practices, but that is a side point. My main point that 
I want discussed is that if the document(s) are in any way suggesting 
that the receiving party can trust the user@ from the sending domain to 
actually be user@, that is a large mistake and should be corrected.

Mike