Subject: [cnit] CNIT and Modern Charter

From: Cullen Jennings <[email-masked]>
Date: Mon, 9 Mar 2015 09:10:58 -0600

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 <[email-masked]> 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 +1 703-593-2683
> 
> 
> From: "DOLLY, MARTIN C" <[email-masked]>
> Date: Tuesday, February 24, 2015 at 9:02 PM
> To: Richard Shockey <[email-masked]>
> Cc: "Holmes, David W [CTO]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Peterson, Jon" <[email-masked]>
> 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
> +1-609-903-3390
> Sent from my iPhone
> 
> On Feb 24, 2015, at 6:36 PM, Richard Shockey <[email-masked]> 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]" <[email-masked]>
>> Date: Tuesday, February 24, 2015 at 5:06 PM
>> To: "Peterson, Jon" <[email-masked]>, "[email-masked]" <[email-masked]>
>> 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:[email-masked]] On Behalf Of Peterson, Jon
>> Sent: Wednesday, February 11, 2015 9:19 AM
>> To: [email-masked]
>> 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 [email-masked] https://www.ietf.org/mailman/listinfo/modern
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
> _______________________________________________ Modern mailing list [email-masked] https://www.ietf.org/mailman/listinfo/modern_______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Richard Shockey <[email-masked]>
Date: Mon, 09 Mar 2015 15:18:01 -0400

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

On 3/9/15, 11:10 AM, "Cullen Jennings" <[email-masked]> wrote:

>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.
>
>> 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 coordinate with National Numbering Authorities
>>and National Regulatory Authorities as needed.
>> 
>> €	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
>> Cc: "Holmes, David W [CTO]" <[email-masked]>,
>>"[email-masked]" <[email-masked]>, "[email-masked]"
>><[email-masked]>, "Peterson, Jon" <[email-masked]>
>>> 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.
>>> 
>>> 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 
>>> 
>>> 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.
>>>  
>>> 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.
>>>  
>>> -          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:
>>> -          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
>>> 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
>>>[email-masked] https://www.ietf.org/mailman/listinfo/modern
>> _______________________________________________ Modern mailing list
>>[email-masked] 
>>https://www.ietf.org/mailman/listinfo/modern_____________________________
>>__________________
>> dispatch mailing list
>> [email-masked]

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Mon, 9 Mar 2015 22:25:58 +0000

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:[email-masked]] On Behalf Of Richard Shockey
Sent: March 09, 2015 2:18 PM
To: Cullen Jennings; [email-masked]; [email-masked]; [email-masked]
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.

‹
Richard Shockey
Shockey Consulting LLC

On 3/9/15, 11:10 AM, "Cullen Jennings" <[email-masked]> wrote:

>> €A problem statement and requirements detailing the current deployment
>> €Define either a new SIP header or document a repurpose of an SIP
>> €Define a data model for the Calling Name Identity Trust object (s)
>> €Deliver an analysis of privacy implications of the proposed Calling

_______________________________________________
Modern mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/modern

________________________________

---

From: Chris Wendt <[email-masked]>
Date: Tue, 10 Mar 2015 14:37:44 -0400

I agree that this would be useful just from the standpoint that if service providers are going to implement in-band signing of caller-id, would quite make sense to provide a better payload for delivering additional and/or more useful calling party information along with signing it as well.

-Chris

> On Mar 9, 2015, at 3:18 PM, Richard Shockey <[email-masked]> wrote:
> 
> 
> though we donąt have to define policy at this stage and frankly I donąt
>>>> Iąm violently opposed to łend world hunger˛ WGąs.
>>>> 
>>>> 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

---

From: Richard Shockey <[email-masked]>
Date: Tue, 10 Mar 2015 14:53:17 -0400

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]" <[email-masked]>
wrote:

>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.
>     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)
>
>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
>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.
>
>>>>_______________________________________________________________________
>>>>_
>>>>______
>>>>
>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.

---

From: Richard Shockey <[email-masked]>
Date: Tue, 10 Mar 2015 14:57:48 -0400

Exactly.  If the IETF is going to remain responsible for core SIP
protocols and signaling its our job to properly define these mechanisms.
There is reason to believe if we don’t do this it will be done for us.
There were two bills in the US Congress about this last year and who knows
what elsewhere.

IMHO the in band model is clearly the first use case. That alone would
help a great deal. 

On 3/10/15, 2:37 PM, "Chris Wendt" <[email-masked]> wrote:

>I agree that this would be useful just from the standpoint that if
>service providers are going to implement in-band signing of caller-id,
>would quite make sense to provide a better payload for delivering
>additional and/or more useful calling party information along with
>signing it as well.
>
>-Chris
>
>>and
>>viable
>>>> The working group will, to the best of its ability, reuse existing
>>>>IETF
>>>> protocols.
>>>> 
>>>>>______________________________________________________________________
>>>>>__
>>>>> ______
>>>>>

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Tue, 10 Mar 2015 18:58:28 +0000

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:[email-masked]]
Sent: March 10, 2015 1:53 PM
To: Gorman, Pierce A [CTO]; Cullen Jennings; [email-masked]; [email-masked]; [email-masked]
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]" <[email-masked]>
wrote:

>     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)
>
>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.
>
>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.
>
>>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.
>>
>>> 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.
>>>
>>>altered in transit creating a variety of malicious abuses similar to
>>>the ones identified by the IETF STIR working group.
>>>
>>>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.
>>>
>>>IETF protocols.
>>> The working group will coordinate with National Numbering
>>>Authorities and National Regulatory Authorities as needed.
>>>
>>> €A problem statement and requirements detailing the current
>>>deployment environment and situations that motivate work on Calling
>>>Name Identity Trust.
>>>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
>>>> 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.
>>>>
>>>>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.
>>>>access markets is important but we all know ³Money is the answer
>>>>what is the  question ..²
>>>>
>>>> Last week I gave a talk on this to a panel that included many of
>>>>our friends among the national regulators.
>>>>
>>>>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.
>>>>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.
>>>>
>>>>face obsolescence as the voice communications infrastructure evolves
>>>>to IP technology and new applications for TNs become possible.  The
>>>> 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 sole use of the recipient(s). Any use by others is prohibited.
>>>>If you are not the intended recipient, please contact the sender and
>>>https://www.ietf.org/mailman/listinfo/modern_________________________
>>>___
>>>_
>>>__________________
>>> dispatch mailing list
>>> [email-masked]
>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.

---

From: Richard Shockey <[email-masked]>
Date: Tue, 10 Mar 2015 15:36:59 -0400

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]" <[email-masked]>
wrote:

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

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Tue, 10 Mar 2015 19:42:49 +0000

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:[email-masked]]
Sent: March 10, 2015 2:37 PM
To: Gorman, Pierce A [CTO]; Cullen Jennings; [email-masked]; [email-masked]; [email-masked]
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.

On 3/10/15, 2:58 PM, "Gorman, Pierce A [CTO]" <[email-masked]>
wrote:

>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.
>
>calling party data is presented to the consumer. STIR in and of itself
>is not enough.  This is ultimately a consumer protection issue.
>
>
>
>
>>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.
>>
>>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
>>>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?
>>>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
>>>>party number in the Public Switched Telephone Network [PSTN].  In
>>>>the PSTN this data is sent by the originating network only at the
>>>> Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683
>>>>
>>>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Mar 2015 16:19:34 +0000

There seem to be two cases:

(1) The originator of the call also provides the "CNAM" information, e.g., based on their customer information.

(2) A third party provides the CNAM information (e.g., a licensing entity or Dun & Bradstreet) that essentially says "I certify that the phone number 212 555 1234 belongs to Citibank")

Thus, there are two questions:

(1) What information should be carried?

(2) How does the cryptographic binding work? 

For example, would it make sense to have two 4474bis signatures, to address case #2? Or should there be a separate signature that simply asserts the phone number to name binding, but it's not tied to the call itself.

________________________________________
From: cnit [[email-masked]] on behalf of Richard Shockey [[email-masked]]
Sent: Tuesday, March 10, 2015 2:57 PM
To: Chris Wendt
Cc: Cullen Jennings; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [cnit] [dispatch] CNIT and Modern Charter

On 3/10/15, 2:37 PM, "Chris Wendt" <[email-masked]> wrote:

>>>phone
>>>>the
>>>>carry
>>>>>CNAM+/CNIT
>>>>>service
>>>>>regarding
>>>>>to

_______________________________________________
cnit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cnit

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Mar 2015 16:22:32 +0000

To clarify, by "originator", I meant the originating service provider (carrier), i.e., the entity that holds the phone number. Case #2 would obviously work in the case where the originating enterprise signs the call using 4474bis.

________________________________________
From: cnit [[email-masked]] on behalf of Henning Schulzrinne [[email-masked]]
Sent: Wednesday, March 11, 2015 12:19 PM
To: Richard Shockey; Chris Wendt
Cc: Cullen Jennings; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [cnit] [dispatch] CNIT and Modern Charter

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Mar 2015 16:25:41 +0000

Would a simple vCard (RFC 7095) model work?

________________________________________
From: Modern [[email-masked]] on behalf of Chris Wendt [[email-masked]]
Sent: Tuesday, March 10, 2015 2:37 PM
To: Richard Shockey
Cc: Cullen Jennings; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Modern] [dispatch] CNIT and Modern Charter

-Chris

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 11 Mar 2015 16:32:52 +0000

I think this highlights two options:

(1) In-band delivery of the content, signed. The receiving device would need to decide whether it trusts the signer.

(2) Third-party lookup, where the number (STIR-signed) is used as a lookup into a trustable database, rather similar to the CNAM model, but maybe with additional cryptographic signing. In other words, the database contains signed vCards. The hard part is coordinating the databases in that case.

(3) A combination of the two, where the Call-Info header provides the pointer. (That obviously already exists.)

Henning

________________________________________
From: dispatch [[email-masked]] on behalf of Cullen Jennings [[email-masked]]
Sent: Monday, March 09, 2015 11:10 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [dispatch] CNIT and Modern Charter

---

From: Chris Wendt <[email-masked]>
Date: Wed, 11 Mar 2015 14:32:28 -0400

I think that makes a lot of sense.

> On Mar 11, 2015, at 12:25 PM, Henning Schulzrinne <[email-masked]> wrote:
>

---

From: Eric Burger <[email-masked]>
Date: Sun, 15 Mar 2015 21:26:47 -0400

This is IDN all over again. On the one hand, we need to be aware that some bad people will try to ρηιςη instead of φισ, because the former looks like phish. On the other hand, last I looked, this is the IETF, and a US-centric or Roman-script-centric solution is not going to be internationally acceptable.

Sincerely,
柏尔立

P.S., while we are expanding the charter to encompass the ocean, can I specify “Eric Burger” for domestic calls and "柏尔立” for calls to China? ;-)

> On Mar 9, 2015, at 11:10 AM, Cullen Jennings <[email-masked]> wrote:
> 
>

---

From: Eric Burger <[email-masked]>
Date: Mon, 16 Mar 2015 07:12:50 -0400

In principle this makes sense. However, if we cannot get the world to agree on countries (e.g., Tibet, Taiwan, etc.), how are we going to get an agreed list of enterprise types? We could go the ITU route and define the protocol machinery and leave the enterprise definitions a local matter. However, that does not foster global interoperability. Moreover, your state-sponsored source of foreign currency might look to me to be a criminal enterprise. Would it be a registered bank or a registered 'trading' company?

--
Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF LEMONADE for mobile email! See <http://www.standardstrack.com/ietf/lemonade/>

> On Mar 15, 2015, at 9:52 PM, Henning Schulzrinne <[email-masked]> wrote:
> 
> This seems like a separable problem, i.e., where the mechanism of preventing IDN impersonation is left to the certifying entity. Unlike for web pages, these entities are likely to be domestic so that a callee is likely to be suspicious if it receives a Russian-certified caller that kind of looks like Citibank. But you illustrate a good reason why certifying the type of entity (e.g., FDIC-insured bank, registered medical provider) may be more important than relying on a name alone.
> 
> Henning
> 
>> On Sun, Mar 15, 2015 at 9:26 PM, Eric Burger <[email-masked]> wrote:

---

From: Richard Shockey <[email-masked]>
Date: Mon, 16 Mar 2015 08:44:05 -0400

Its the boil the ocean problem I’d like to avoid.

As a first pass I would strongly argue that the only relevant items to
address initially are what header to use for CNAM/CNIT and what is the data
object(s). Constrict the initial charter to those things then build on
success through recharter.

MARTINI comes to mind.

In this case some of us would propose a simple reuse of an existing header
and and a simple reuse existing data object. Path to RFC might be within
this decade. 

From:  Henning Schulzrinne <[email-masked]>
Date:  Monday, March 16, 2015 at 8:10 AM
To:  Eric Burger <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [dispatch] [Modern] CNIT and Modern Charter

My general approach is not to make the problem more difficult than it has to
be. Otherwise, positing problems that are hypothetical corner cases prevent
the solution of the real problem.

Almost all (legitimate) business calls that most people receive are either
from their own country or a country they are familiar with (e.g., because
they are first or second generation immigrants). Thus, how Nigeria
classifies or regulates financial institutions is of little concern to me
since I don't expect to receive a call from a Nigerian bank or "bank". Also,
there is very little legitimate cold-calling from businesses; most
cold-calling falls into the illegal side of the TCPA (the US law governing
telemarketing). The goal is to be able to tell that if I get a call from the
IRS or Bank of America, that they are indeed who they claim to be, without
having to remember what phone numbers they use.

Henning

On Mon, Mar 16, 2015 at 7:12 AM, Eric Burger <[email-masked]>
wrote:
> In principle this makes sense. However, if we cannot get the world to agree on
> countries (e.g., Tibet, Taiwan, etc.), how are we going to get an agreed list
> of enterprise types? We could go the ITU route and define the protocol
> machinery and leave the enterprise definitions a local matter. However, that
> does not foster global interoperability. Moreover, your state-sponsored source
> of foreign currency might look to me to be a criminal enterprise. Would it be
> a registered bank or a registered 'trading' company?
> 
> --
> Sent from a mobile device. Sorry for typos or weird auto-correct. Thank IETF
> LEMONADE for mobile email! See <http://www.standardstrack.com/ietf/lemonade/>
> 
>> This seems like a separable problem, i.e., where the mechanism of preventing
>> IDN impersonation is left to the certifying entity. Unlike for web pages,
>> these entities are likely to be domestic so that a callee is likely to be
>> suspicious if it receives a Russian-certified caller that kind of looks like
>> Citibank. But you illustrate a good reason why certifying the type of entity
>> (e.g., FDIC-insured bank, registered medical provider) may be more important
>> than relying on a name alone.
>> 
>> Henning
>> 
>>> This is IDN all over again. On the one hand, we need to be aware that some
>>> bad people will try to ρηιςη instead of φισ, because the former looks like
>>> phish. On the other hand, last I looked, this is the IETF, and a US-centric
>>> or Roman-script-centric solution is not going to be internationally
>>> acceptable.
>>> 
>>> Sincerely,
>>> 柏尔立
>>> 
>>> P.S., while we are expanding the charter to encompass the ocean, can I
>>> specify “Eric Burger” for domestic calls and "柏尔立” for calls to China? ;-)
>>> 

_______________________________________________ dispatch mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/dispatch

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Mar 2015 21:52:35 -0400

This seems like a separable problem, i.e., where the mechanism of
preventing IDN impersonation is left to the certifying entity. Unlike for
web pages, these entities are likely to be domestic so that a callee is
likely to be suspicious if it receives a Russian-certified caller that kind
of looks like Citibank. But you illustrate a good reason why certifying the
type of entity (e.g., FDIC-insured bank, registered medical provider) may
be more important than relying on a name alone.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Mar 2015 08:10:34 -0400

My general approach is not to make the problem more difficult than it has
to be. Otherwise, positing problems that are hypothetical corner cases
prevent the solution of the real problem.

Almost all (legitimate) business calls that most people receive are either
from their own country or a country they are familiar with (e.g., because
they are first or second generation immigrants). Thus, how Nigeria
classifies or regulates financial institutions is of little concern to me
since I don't expect to receive a call from a Nigerian bank or "bank".
Also, there is very little legitimate cold-calling from businesses; most
cold-calling falls into the illegal side of the TCPA (the US law governing
telemarketing). The goal is to be able to tell that if I get a call from
the IRS or Bank of America, that they are indeed who they claim to be,
without having to remember what phone numbers they use.

Henning

On Mon, Mar 16, 2015 at 7:12 AM, Eric Burger <[email-masked]>
wrote:

> In principle this makes sense. However, if we cannot get the world to
> agree on countries (e.g., Tibet, Taiwan, etc.), how are we going to get an
> agreed list of enterprise types? We could go the ITU route and define the
> protocol machinery and leave the enterprise definitions a local matter.
> However, that does not foster global interoperability. Moreover, your
> state-sponsored source of foreign currency might look to me to be a
> criminal enterprise. Would it be a registered bank or a registered
> 'trading' company?
>
> --
> Sent from a mobile device. Sorry for typos or weird auto-correct. Thank
> IETF LEMONADE for mobile email! See <
> http://www.standardstrack.com/ietf/lemonade/>
>
>> This is IDN all over again. On the one hand, we need to be aware that
>> some bad people will try to ρηιςη instead of φισ, because the former looks
>> like phish. On the other hand, last I looked, this is the IETF, and a
>> US-centric or Roman-script-centric solution is not going to be
>> internationally acceptable.
>>
>> Sincerely,
>> 柏尔立
>>