Subject: [stir] FW: New Version Notification for draft-zhang-stir-scenario-issue-00.txt

From: Hui Deng <[email-masked]>
Date: Tue, 7 Jul 2015 15:35:01 +0800

Hello all
 
Please feel free to let us know if you have any comment on it,
 
thanks a lot
 
DENG Hui

A new version of I-D, draft-zhang-stir-scenario-issue-00.txt

has been successfully submitted by Hui
Deng and posted to the IETF repository.

Name:               draft-zhang-stir-scenario-issue

Revision:  00

Title:                  Issue
with current STIR scenario

Document date:       2015-07-06

Group:               Individual
Submission

Pages:               5

URL:            https://www.ietf.org/internet-drafts/draft-zhang-stir-scenario-issue-00.txtStatus:         https://datatracker.ietf.org/doc/draft-zhang-stir-scenario-issue/Htmlized:       https://tools.ietf.org/html/draft-zhang-stir-scenario-issue-00

Abstract:

This document introduces couple of scenarios have been identified to  
find out that certificate based solution has some limitation.

Please note that it may take a couple of
minutes from the time of submission until the htmlized version and diff are
available at tools.ietf.org.

The IETF Secretariat

---

From: Brian Rosen <[email-masked]>
Date: Tue, 7 Jul 2015 09:22:32 -0400

The canonicalization of the telephone number that is required to generate the signature would result in both scenarios failing.  Even if the terminal does not send the country code or prefix (area code), it is part if the calculation of the canonical number that is signed.  I believe this addresses all the scenarios raised in your draft:

In Figure 1’s call, I’m confused about who signs.  If it’s the IPBX, then it would have to have the private key for the canonicalized 10086, which you said was a service number.  If it’s the MSC that is signing, and 10086 is a service number, first of all, it should not accept a call from the IPBX with a service number as a calling party number, but even if it did, it would add the country code to it before it was signed.  Any attempt to verify a signature with a different prefix would fail.

In Figure 2, the MSC creates the signature for the original telephone number,1335678432.  When the VoLTE AS changes it, the validation will fail.  

In 2., the original number would be canonicalized - any leading zero removed, country code added.  When that is signed, it cannot be used to validate a call that appears to be from a service number from a different country, because the canonicalization of that number is different, and thus the signature check would fail.

In 3, the original call with a hidden number has to be sent as an anonymous call, which is handled in the text.  There is no signature on such a call.  I am not sure how IMS handles anonymous calls, but the scenario you describe, where calling elements are adding prefixes and country codes to a blank number is surely not what anyone envisions for anonymous calls. 

Brian

> On Jul 7, 2015, at 3:35 AM, Hui Deng <[email-masked]> wrote:
> 
> Hello all
>  
> has been successfully submitted by Hui Deng and posted to the IETF repository.
> 
>  
> 
> Title:                  Issue with current STIR scenario
> 
> Group:               Individual Submission
> 
> Pages:               5
> 
> URL:            https://www.ietf.org/internet-drafts/draft-zhang-stir-scenario-issue-00.txt <https://www.ietf.org/internet-drafts/draft-zhang-stir-scenario-issue-00.txt>
> Status:         https://datatracker.ietf.org/doc/draft-zhang-stir-scenario-issue/ <https://datatracker.ietf.org/doc/draft-zhang-stir-scenario-issue/>
> Htmlized:       https://tools.ietf.org/html/draft-zhang-stir-scenario-issue-00 <https://tools.ietf.org/html/draft-zhang-stir-scenario-issue-00>
> Abstract:
> 
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> 
> The IETF Secretariat
> 
> _______________________________________________
> stir mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: Hui Deng <[email-masked]>
Date: Wed, 8 Jul 2015 11:53:35 +0800

Hi Brian,
 
This document is mostly talking about lots of African/South American/ South east Asian/ Countries, they don't sign their number, that cause some issues.
inline == > please
From: [email-masked]
Date: Tue, 7 Jul 2015 09:22:32 -0400
To: [email-masked]
CC: [email-masked]; [email-masked]
Subject: Re: [stir] FW: New Version Notification for draft-zhang-stir-scenario-issue-00.txt

The canonicalization of the telephone number that is required to generate the signature would result in both scenarios failing.  Even if the terminal does not send the country code or prefix (area code), it is part if the calculation of the canonical number that is signed.  I believe this addresses all the scenarios raised in your draft:== > as we said, they don't sign, so whatever country code or prefix we add.
In Figure 1’s call, I’m confused about who signs.  If it’s the IPBX, then it would have to have the private key for the canonicalized 10086, which you said was a service number.  If it’s the MSC that is signing, and 10086 is a service number, first of all, it should not accept a call from the IPBX with a service number as a calling party number, but even if it did, it would add the country code to it before it was signed.  Any attempt to verify a signature with a different prefix would fail.== > same here, they don' sign their number in their country.
In Figure 2, the MSC creates the signature for the original telephone number,1335678432.  When the VoLTE AS changes it, the validation will fail.  == > if they don't , what we can do?
In 2., the original number would be canonicalized - any leading zero removed, country code added.  When that is signed, it cannot be used to validate a call that appears to be from a service number from a different country, because the canonicalization of that number is different, and thus the signature check would fail.== > same here.
In 3, the original call with a hidden number has to be sent as an anonymous call, which is handled in the text.  There is no signature on such a call.  I am not sure how IMS handles anonymous calls, but the scenario you describe, where calling elements are adding prefixes and country codes to a blank number is surely not what anyone envisions for anonymous calls. == > today operators would like get as much as international roaming without checking their sign, that's the situation for real commerical deployment. Brian
== > thanks a  for yor comments. Best regards, DENG Hui

On Jul 7, 2015, at 3:35 AM, Hui Deng <[email-masked]> wrote:Hello all

thanks a lot
 
DENG Hui

 
Name:               draft-zhang-stir-scenario-issue
Revision:  00
Title:                  Issue with current STIR scenario
Document date:       2015-07-06
Group:               Individual Submission
Pages:               5
URL:            https://www.ietf.org/internet-drafts/draft-zhang-stir-scenario-issue-00.txtStatus:         https://datatracker.ietf.org/doc/draft-zhang-stir-scenario-issue/Htmlized:       https://tools.ietf.org/html/draft-zhang-stir-scenario-issue-00
Abstract:
   This document introduces couple of scenarios have been identified to   find out that certificate based solution has some limitation.
Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
_______________________________________________stir mailing [email-masked]://www.ietf.org/mailman/listinfo/stir

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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 8 Jul 2015 09:54:30 -0400

This is a new mechanism.  It won’t work unless it’s deployed.  If the sender doesn’t sign the signaling, the call will not be able to be validated. 
In our discussions with a small number of regulators from smaller countries, there is interest in requiring their carriers to deploy this mechanism because they understand that allowing bad actors operating in their country to defraud others is not good for their national interests.  No one signs the signaling today.  Our hope is that they will as the manufacturers offer the capability.

The stir mechanism is not a magic bullet.  It will only work where it is deployed.

One thing that will assist deployment is when customers stop accepting unsigned calls.  Then legitimate callers will need to arrange to have their signaling signed in order to get their calls to be accepted.

Brian

> On Jul 7, 2015, at 11:53 PM, Hui Deng <[email-masked]> wrote:
> 
> 
>  Hi Brian,
>  
> From: [email-masked] <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> CC: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> == > as we said, they don't sign, so whatever country code or prefix we add.
> == > same here, they don' sign their number in their country.
> == > if they don't , what we can do?
> == > same here.
> == > today operators would like get as much as international roaming without checking their sign, that's the situation for real commerical deployment.
>  
> Brian
> == > 
> thanks a for yor comments.
> Best regards,
> DENG Hui
> 
> 
> On Jul 7, 2015, at 3:35 AM, Hui Deng <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hello all
>  
> _______________________________________________ stir mailing list [email-masked] <mailto:[email-masked]>https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: Richard Shockey <[email-masked]>
Date: Wed, 08 Jul 2015 10:14:23 -0400

From:  stir <[email-masked]> on behalf of Brian Rosen
<[email-masked]>
Date:  Wednesday, July 8, 2015 at 9:54 AM
To:  Hui Deng <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject:  Re: [stir] FW: New Version Notification for
draft-zhang-stir-scenario-issue-00.txt

This is a new mechanism.  It won¹t work unless it¹s deployed.  If the sender
doesn¹t sign the signaling, the call will not be able to be validated.
In our discussions with a small number of regulators from smaller countries,
there is interest in requiring their carriers to deploy this mechanism
because they understand that allowing bad actors operating in their country
to defraud others is not good for their national interests.  No one signs
the signaling today.  Our hope is that they will as the manufacturers offer
the capability.

The stir mechanism is not a magic bullet.  It will only work where it is
deployed.

One thing that will assist deployment is when customers stop accepting
unsigned calls.  Then legitimate callers will need to arrange to have their
signaling signed in order to get their calls to be accepted.

RS So Mr Wizard how will the IMS TAS actually process the terminating
validation at the SBC in order to deliver validation data to the CUA and
where will the validation data be inserted?  I suggest someone needs to talk
to 3GPP.

Brian

> This document is mostly talking about lots of African/South American/ South
> east Asian/ Countries, they don't sign their number, that cause some issues.
> inline == > please
> 
> From: [email-masked]
> The canonicalization of the telephone number that is required to generate the
> signature would result in both scenarios failing.  Even if the terminal does
> not send the country code or prefix (area code), it is part if the calculation
> of the canonical number that is signed.  I believe this addresses all the
> scenarios raised in your draft:
> In Figure 1¹s call, I¹m confused about who signs.  If it¹s the IPBX, then it
> would have to have the private key for the canonicalized 10086, which you said
> was a service number.  If it¹s the MSC that is signing, and 10086 is a service
> number, first of all, it should not accept a call from the IPBX with a service
> number as a calling party number, but even if it did, it would add the country
> code to it before it was signed.  Any attempt to verify a signature with a
> different prefix would fail.
> In Figure 2, the MSC creates the signature for the original telephone
> number,1335678432.  When the VoLTE AS changes it, the validation will fail.
> In 2., the original number would be canonicalized - any leading zero removed,
> country code added.  When that is signed, it cannot be used to validate a call
> that appears to be from a service number from a different country, because the
> canonicalization of that number is different, and thus the signature check
> would fail.
> == > same here.
> In 3, the original call with a hidden number has to be sent as an anonymous
> call, which is handled in the text.  There is no signature on such a call.  I
> am not sure how IMS handles anonymous calls, but the scenario you describe,
> where calling elements are adding prefixes and country codes to a blank number
> is surely not what anyone envisions for anonymous calls.
> == > today operators would like get as much as international roaming without
> checking their sign, that's the situation for real commerical deployment.
>  
> Brian
> == > 
>> URL:            
>> https://www.ietf.org/internet-drafts/draft-zhang-stir-scenario-issue-00.txt
>> <https://www.ietf.org/internet-drafts/draft-zhang-stir-scenario-issue-00.txt>
>> Status:         
>> https://datatracker.ietf.org/doc/draft-zhang-stir-scenario-issue/
>> <https://datatracker.ietf.org/doc/draft-zhang-stir-scenario-issue/>
>> Htmlized:       
>> https://tools.ietf.org/html/draft-zhang-stir-scenario-issue-00
>> <https://tools.ietf.org/html/draft-zhang-stir-scenario-issue-00>
>> 
>> Abstract:
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org
>> <http://tools.ietf.org/> .
>> 
>> The IETF Secretariat
>> 
> _______________________________________________ stir mailing list
> [email-masked]://www.ietf.org/mailman/listinfo/stir

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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 8 Jul 2015 10:50:31 -0400

Yes, 3GPP work will be needed to deploy stir in IMS systems.

So?

As with lots of other implementations, I expect the operator will generate and check for a while, until the devices do it themselves.
Some of his examples have non-IMS actors, and those need either an SP or devices to implement in order for the mechanism to work.

Brian

> On Jul 8, 2015, at 10:14 AM, Richard Shockey <[email-masked]> wrote:
> 
> 
> 
> 
> From: stir <[email-masked] <mailto:[email-masked]>> on behalf of Brian Rosen <[email-masked] <mailto:[email-masked]>>
> To: Hui Deng <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> RS So Mr Wizard how will the IMS TAS actually process the terminating validation at the SBC in order to deliver validation data to the CUA and where will the validation data be inserted?  I suggest someone needs to talk to 3GPP.
> 
> 
> 
> 
> Brian
> 
>> On Jul 7, 2015, at 11:53 PM, Hui Deng <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>>  Hi Brian,
>>  
> _______________________________________________ stir mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>