Re: [stir] 8224: "end users"

["Holmes, David W [CTO]" <[e-mail]>]

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 [phone]  |  [e-mail]<mailto:[e-mail]>
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:[e-mail]] On Behalf Of Michael Thomas
Sent: Tuesday, April 28, 2020 12:50 PM
To: [e-mail]
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:

   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