Re: [dispatch] [Modern] CNIT and Modern Charter

[Richard Shockey <[e-mail]>]

Excellent point you’re absolutely right. Its a perfectly valid use case.





On 3/10/15, 3:42 PM, "Gorman, Pierce A [CTO]" <[e-mail]>
wrote:

>Why?  A common scam is to get someone to call, text, e-mail, browse, to a
>location of bad actions.  If there was someway to authenticate that the
>caller hasn't actually reached the "real" Bank of America, or whatever,
>there is some value to the consumer.  Just a thought.  TLS includes a nod
>to mutual authentication.  I was just trying to think more about "trust
>models" and what they can/should look like.
>
>Best regards,
>
>
>Pierce Gorman
>Voice Architecture
>Core Planning/Sprint
>913-439-4368 (Desk)
>
>-----Original Message-----
>From: Richard Shockey [mailto:[e-mail]]
>Sent: March 10, 2015 2:37 PM
>To: Gorman, Pierce A [CTO]; Cullen Jennings; [e-mail];
>[e-mail]; [e-mail]
>Subject: Re: [dispatch] CNIT and Modern Charter
>
>
>As a matter of principal I wouldn’t rule anything like this out but there
>could be some philshing issues.
>
>My question would be why?  Sort of like the old out of band STIR idea
>that I’m convinced is going no where.
>
>I’d like to fix one simple problem reasonably quickly.
>
>
>
>On 3/10/15, 2:58 PM, "Gorman, Pierce A [CTO]" <[e-mail]>
>wrote:
>
>>Should there be mutual authentication?  Should the calling party
>>receive a called party identity?
>>
>>Best regards,
>>
>>
>>Pierce Gorman
>>Voice Architecture
>>Core Planning/Sprint
>>913-439-4368 (Desk)
>>
>>-----Original Message-----
>>From: Richard Shockey [mailto:[e-mail]]
>>Sent: March 10, 2015 1:53 PM
>>To: Gorman, Pierce A [CTO]; Cullen Jennings; [e-mail];
>>[e-mail]; [e-mail]
>>Subject: Re: [dispatch] CNIT and Modern Charter
>>
>>
>>Exactly… studying the trust models are perfectly appropriate.
>>Obviously the calling party data can come from different sources though
>>I suspect in its earliest models it comes from the originating service
>>provider through the SIP signaling mechanism to the terminating CUA.
>>Especially in the VoLTE case.
>>
>>Enterprise to Enterprise would clearly be different.  Certainly 3rd
>>party databases could be involved in some way.
>>
>>I would remind folks that the rationale for this is consumers and
>>National Regulators are NOT HAPPY AT ALL with the current state of how
>>calling party data is presented to the consumer. STIR in and of itself
>>is not enough.  This is ultimately a consumer protection issue.
>>
>>
>>
>>
>>On 3/9/15, 6:25 PM, "Gorman, Pierce A [CTO]" <[e-mail]>
>>wrote:
>>
>>>I don't have any useful charter text.
>>>I agree that the IETF should not propose business models, but it seems
>>>important to consider trust model(s) to see if it/they drive protocol
>>>considerations.
>>>We could start with listing assumptions.  I'll start by listing two.
>>>     1) I assume there would be multiple authorities and multiple
>>>levels of trust.
>>>     2) I assume there are international tradename, and trademark and
>>>the aforementioned UTF-8 international character code spoofing
>>>considerations.
>>>
>>>
>>>Best regards,
>>>
>>>
>>>Pierce Gorman
>>>Voice Architecture
>>>Core Planning/Sprint
>>>913-439-4368 (Desk)
>>>
>>>-----Original Message-----
>>>From: Modern [mailto:[e-mail]] On Behalf Of Richard
>>>Shockey
>>>Sent: March 09, 2015 2:18 PM
>>>To: Cullen Jennings; [e-mail]; [e-mail]; [e-mail]
>>>Subject: Re: [Modern] [dispatch] CNIT and Modern Charter
>>>
>>>
>>>The first order issue is properly defining what this looks like in SIP
>>>and where in the headers it should reside. There is ample evidence
>>>that any number of other SDO are looking at this and without some
>>>proper standardization there will be no interoperability at all
>>>especially even for STIR validation data at the CUA and IMHO doing
>>>nothing is not a viable option. The basic FROM and PAI usage is not
>>>helpful.
>>>
>>>We are all aware of how smart phones work. This is principally about
>>>sessions that would originate outside a select number of phone book
>>>entries and some display of whether that information has been
>>>validated though we don¹t have to define policy at this stage and
>>>frankly I don¹t think the IETF should try any more than it could try
>>>and establish the business model for how this would deploy.
>>>
>>>The purpose here is simply adding more information about who
>>>originated the session so the called party has more information than
>>>they currently have.  We already have enough bad actors as it is
>>>impersonating tax authorities, banks, health care professionals and
>>>other governmental entities. The purpose is to try and bound those
>>>problems to a manageable level.  There is no silver bullet here.
>>>
>>>I would appreciate any suggestions on charter text if you have them.
>>>
>>>
>>>
>>>‹
>>>Richard Shockey
>>>Shockey Consulting LLC
>>>Chairman of the Board SIP Forum
>>>www.shockey.us
>>>www.sipforum.org
>>>richard<at>shockey.us
>>>Skype-Linkedin-Facebook rshockey101
>>>PSTN [phone]
>>>
>>>
>>>
>>>
>>>
>>>On 3/9/15, 11:10 AM, "Cullen Jennings" <[e-mail]> wrote:
>>>
>>>>
>>>>On the particular CNAM like topic ...
>>>>
>>>>I'm not keen on moving forward with something like this unless we can
>>>>show the trust and human factors issues is an engineering problem not
>>>>a research problem. We have seen the difficulty with human readable
>>>>names in SPAM. Particularly when using UTF-8, how do we stop bad
>>>>actor getting names that look the same as someone they wish to
>>>>impersonate?
>>>>Who will validate the names and issue some sort of trust token that
>>>>says I can use "Cullen Jennings" or whatever. Who else can use that
>>>>name and what about names visually similar to it.
>>>>
>>>>On the flip side we are seeing most smart phones take the incoming
>>>>phone number, and look it up the personal address book of the user
>>>>and display the name that the user of the smartphone assigned. We are
>>>>seeing enterprise phones that do a similar things using the users
>>>>social networks as well as personal address book.
>>>>
>>>>What would be bad is phone display a display name that some how
>>>>claimed to be trustable but was not. That would be worse that the
>>>>current situation. Perhaps people have a good way to solve this in
>>>>mind but I'm not seeing that that is.
>>>>
>>>>Cullen (with my individual contribute hat on of course)
>>>>
>>>>
>>>>
>>>>> On Feb 25, 2015, at 10:05 AM, Richard Shockey <[e-mail]>
>>>>>wrote:
>>>>>
>>>>>
>>>>> Thanks Martin .. This is my very raw first cut at a charter. Its
>>>>>hopefully simple and straight forward.
>>>>>
>>>>> Send me any edits etc.
>>>>>
>>>>> *****
>>>>>
>>>>> CNIT Charter [Calling Name Identity Trust]
>>>>>
>>>>> WG Chairs TBD:
>>>>>
>>>>> Calling Name Delivery [CNAM] is a string of up to 15 ASCII
>>>>>Characters of information associated with a specific E.164 calling
>>>>>party number in the Public Switched Telephone Network [PSTN].  In
>>>>>the PSTN this data is sent by the originating network only at the
>>>>>specific request of the terminating network via a SS7 Transaction
>>>>>Application Part [TCAP] response message.  In the Session Initiation
>>>>>Protocol [SIP] this information can be inserted into the FROM: part
>>>>>of the originating INVITE message or by other means.
>>>>>
>>>>> As with the originating source telephone number, this data can be
>>>>>altered in transit creating a variety of malicious abuses similar to
>>>>>the ones identified by the IETF STIR working group.
>>>>>
>>>>> The purpose of the CNIT working group will be to define a data
>>>>>structure, a new SIP header or repurpose an existing SIP header to
>>>>>carry an advanced form of CNAM as well as information from a STIR
>>>>>Validation Authority.  The purpose of this work is to present to the
>>>>>SIP called party trusted information from the calling party in order
>>>>>that the called party make a more reasoned and informed judgment on
>>>>>whether to accept the INVITE or not.
>>>>>
>>>>> The working group will not invalidate any existing SIP mechanism
>>>>>for anonymous calling.
>>>>>
>>>>> The working group will, to the best of its ability, reuse existing
>>>>>IETF protocols.
>>>>>
>>>>> Full Internationalization of the Calling Name Identity Trust data
>>>>>object(s) is a requirement.
>>>>>
>>>>> The working group will closely work with the IETF STIR working
>>>>> group
>>>>>
>>>>> The working group will immediately liaison with 3GPP SA-1 in order
>>>>>to coordinate efforts.
>>>>>
>>>>> The working group will coordinate with National Numbering
>>>>>Authorities and National Regulatory Authorities as needed.
>>>>>
>>>>> The working group will deliver the flowing.
>>>>>
>>>>> €A problem statement and requirements detailing the current
>>>>>deployment environment and situations that motivate work on Calling
>>>>>Name Identity Trust.
>>>>> €Define either a new SIP header or document a repurpose of an SIP
>>>>>existing header for Calling Name Identify Trust data  €Define a data
>>>>>model for the Calling Name Identity Trust object (s) which may
>>>>>include various forms of multimedia data  €Deliver an analysis of
>>>>>privacy implications of the proposed Calling Name Identity Trust
>>>>>mechanism.
>>>>>
>>>>>
>>>>> Milestones:
>>>>>
>>>>>
>>>>> ‹
>>>>> Richard Shockey
>>>>> Shockey Consulting LLC
>>>>> Chairman of the Board SIP Forum
>>>>> www.shockey.us
>>>>> www.sipforum.org
>>>>> richard<at>shockey.us
>>>>> Skype-Linkedin-Facebook rshockey101 PSTN [phone]
>>>>>
>>>>>
>>>>> From: "DOLLY, MARTIN C" <[e-mail]>
>>>>> Date: Tuesday, February 24, 2015 at 9:02 PM
>>>>> To: Richard Shockey <[e-mail]>
>>>>> Cc: "Holmes, David W [CTO]" <[e-mail]>,
>>>>>"[e-mail]" <[e-mail]>, "[e-mail]"
>>>>><[e-mail]>, "Peterson, Jon" <[e-mail]>
>>>>> Subject: Re: [Modern] [dispatch] draft charter
>>>>>
>>>>> I support Richard on this
>>>>>
>>>>> Martin Dolly
>>>>> Lead Member of Technical Staff
>>>>> Core & Gov't/Regulatory Standards
>>>>> AT&T Standards and
>>>>> Industry Alliances
>>>>> [phone]
>>>>> Sent from my iPhone
>>>>>
>>>>> On Feb 24, 2015, at 6:36 PM, Richard Shockey <[e-mail]>
>>>>>wrote:
>>>>>
>>>>>>
>>>>>> Excellent points David.
>>>>>>
>>>>>> My concern here is charter overreach. I really want to keep
>>>>>>CNAM+/CNIT out of this.  IMHO that is a very separate and highly
>>>>>>focused effort to define both the modification of the SIP headers
>>>>>>necessary to support some enhanced calling party identification and
>>>>>>a very limited effort to define the object and or the STIR validation
>>>>>>data.
>>>>>>
>>>>>> I¹m violently opposed to ³end world hunger² WG¹s.
>>>>>>
>>>>>> If registries can be used fine but I certainly want to see how this
>>>>>>can be accomplished in bi lateral agreements between consenting
>>>>>>service providers and work with CUA vendors on how the data is
>>>>>>displayed aka Apple, Samsung, Microsoft in the context of a formal
>>>>>>liaison with 3GPP.
>>>>>> Certainly the relevance of CNAM+/CNIT in enterprise and residential
>>>>>>access markets is important but we all know ³Money is the answer
>>>>>>what is the  question ..²
>>>>>>
>>>>>> I¹ve asked for time in Dispatch to look at the CNAM/CNIT issue and
>>>>>>report on the JTF on NNI. As you well know we have made considerable
>>>>>>progress.
>>>>>>
>>>>>> Last week I gave a talk on this to a panel that included many of
>>>>>>our friends among the national regulators.
>>>>>>
>>>>>> http://apps.fcc.gov/ecfs/document/view?id=60001033217
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: "Holmes, David W [CTO]" <[e-mail]>
>>>>>> Date: Tuesday, February 24, 2015 at 5:06 PM
>>>>>> To: "Peterson, Jon" <[e-mail]>, "[e-mail]"
>>>>>><[e-mail]>
>>>>>> Subject: Re: [Modern] draft charter
>>>>>>
>>>>>> Jon,
>>>>>>
>>>>>> Thank you for the work in assembling this draft of the charter for
>>>>>>MODERN.
>>>>>>
>>>>>> We would like to suggest some minor clarifications to the bullets
>>>>>>describing the deliverables, to align them with the statement
>>>>>>regarding flexibility to support the needs of different regulatory
>>>>>>regimes, & thus to ensure that if quoted alone they are not taken
>>>>>>out of context; i.e. the group product will be the protocols to
>>>>>>support the allocation etc. activities, & it would not attempt to
>>>>>>define the allocation processes.  We also would like the charter to
>>>>>>note the relevant work that has already been performed by both IETF
>>>>>>& the ATIS/SIP Forum JTF, & incorporate that into the output from the
>>>>>>MODERN WG as appropriate.
>>>>>>These changes/additions are have been added to your text inline
>>>>>>below.
>>>>>>
>>>>>> We are hoping that the MODERN session at IETF#92 will have remote
>>>>>>access, to allow participation by those of us that cannot attend in
>>>>>>person due to other commitments that week.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> David/Sprint
>>>>>>
>>>>>>____________________________________________________________________
>>>>>>___
>>>>>>_
>>>>>>______
>>>>>>
>>>>>> From: Modern [mailto:[e-mail]] On Behalf Of
>>>>>>Peterson, Jon
>>>>>> Sent: Wednesday, February 11, 2015 9:19 AM
>>>>>> To: [e-mail]
>>>>>> Subject: [Modern] draft charter
>>>>>>
>>>>>>
>>>>>> At the Dallas IETF meeting in March, we'd like to get together and
>>>>>>talk about what a working group for MODERN might look like. As an
>>>>>>initial input to the discussion, a few of us have put together a
>>>>>>proposed charter. While the TeRQ work was positively evaluated in
>>>>>>the DISPATCH process, we feel this is broader enough in scope to
>>>>>>warrant its own BoF.
>>>>>>
>>>>>> Comments are welcome, this is just a starting point.
>>>>>>
>>>>>> ------
>>>>>>
>>>>>> Modern charter text:
>>>>>>
>>>>>> The MODERN working group will define a set of Internet-based
>>>>>>mechanisms for the purposes of managing and resolving telephone
>>>>>>numbers
>>>>>>(TNs) in an IP environment.  Existing mechanisms for these purposes
>>>>>>face obsolescence as the voice communications infrastructure evolves
>>>>>>to IP technology and new applications for TNs become possible.  The
>>>>>>traditional model of a TN having an association to a single service
>>>>>>provider and a single application is breaking down.  Its use as a
>>>>>>network locator is going away, but its use as an identifier for an
>>>>>>individual or an organization will remain for some time. Devices,
>>>>>>applications, and network tools increasingly need to manage TNs,
>>>>>>including requesting and acquiring TN delegations from authorities.
>>>>>>
>>>>>> The working group will define a framework for the roles and
>>>>>>functions involved in managing and resolving TNs in an IP
>>>>>>environment. This includes a protocol mechanism for acquiring TNs,
>>>>>>which will provide an enrollment process for the individuals and
>>>>>>entities that use and manage TNs. TNs may either be managed in a
>>>>>>hierarchical tree, or in a distributed peer-to-peer architecture.
>>>>>>Privacy of the enrollment data and security of the resource will be
>>>>>>primary considerations.
>>>>>>
>>>>>> Additionally, the working group will deliver a protocol mechanism
>>>>>>for resolving TNs which will allow entities such as service
>>>>>>providers, devices, and applications to access data related to TNs,
>>>>>>possibly including caller name data (CNAM).  Maintaining
>>>>>>reliability, real time application performance, security and privacy
>>>>>>are primary considerations.  The working group will take into
>>>>>>consideration existing IETF work including ENUM, SPEERMINT, STIR, and
>>>>>>DRINKS.
>>>>>>
>>>>>> The work of this group is limited to specifying a solution for TNs
>>>>>>and covers any service that can be addressed using a TN.  Expanding
>>>>>>the work to other identifiers is out of scope.  Solutions and
>>>>>>mechanisms created by the working group will be flexible enough to
>>>>>>accommodate different policies, e.g., by different regulatory
>>>>>>agencies.
>>>>>>
>>>>>> The work group will deliver the following:
>>>>>>
>>>>>> -          An architecture overview document that includes high
>>>>>>level
>>>>>>requirements and security/privacy considerationsbuilt on the work of
>>>>>>IETF & the ATIS/SIP Forum JTF, that included:
>>>>>> o   Call routing architecture
>>>>>> o   Inter-carrier NNI
>>>>>> o   Cryptographically-enabled Anti-spoofing (STIR)
>>>>>> o   Enhanced Calling Name (CNIT/CNAM)
>>>>>> -          A document describing the protocols to support enrollment
>>>>>>processes for existing and new TNs including any modifications to
>>>>>>metadata related to those TNs
>>>>>> -          A document describing protocol mechanisms for accessing
>>>>>>contact information associated with enrollments
>>>>>> -          A document describing protocol mechanisms for resolving
>>>>>>information related to TNs
>>>>>>
>>>>>> -
>>>>>>
>>>>>>
>>>>>> This e-mail may contain Sprint proprietary information intended for
>>>>>>the sole use of the recipient(s). Any use by others is prohibited.
>>>>>>If you are not the intended recipient, please contact the sender and
>>>>>>delete all copies of the message.
>>>>>> _______________________________________________ Modern mailing list
>>>>>>[e-mail] https://www.ietf.org/mailman/listinfo/modern
>>>>>> _______________________________________________
>>>>>> dispatch mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>> _______________________________________________ Modern mailing list
>>>>>[e-mail]
>>>>>https://www.ietf.org/mailman/listinfo/modern_________________________
>>>>>___
>>>>>_
>>>>>__________________
>>>>> dispatch mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>>
>>>>_______________________________________________
>>>>dispatch mailing list
>>>>[e-mail]
>>>>https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>>
>>>_______________________________________________
>>>Modern mailing list
>>>[e-mail]
>>>https://www.ietf.org/mailman/listinfo/modern
>>>
>>>________________________________
>>>
>>>This e-mail may contain Sprint proprietary information intended for the
>>>sole use of the recipient(s). Any use by others is prohibited. If you
>>>are not the intended recipient, please contact the sender and delete
>>>all copies of the message.
>>
>>
>>
>>________________________________
>>
>>This e-mail may contain Sprint proprietary information intended for the
>>sole use of the recipient(s). Any use by others is prohibited. If you are
>>not the intended recipient, please contact the sender and delete all
>>copies of the message.
>
>
>
>________________________________
>
>This e-mail may contain Sprint proprietary information intended for the
>sole use of the recipient(s). Any use by others is prohibited. If you are
>not the intended recipient, please contact the sender and delete all
>copies of the message.
>_______________________________________________
>Modern mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/modern