Re: [stir] "iat" value to use during PASSPorT construction

Not disagreeing with your points in general but:

I don’t think there is “protocol level” check possible whether a signature generated by an intermediary and verified successfully is created maliciously or not. This has to depend on policy. Depending on attestation level one may check whether signer is authoritative for  origin or whether it can be trusted for the particular attestation level without such a check. Whom to trust for which attestation level is really an operational/administrative decision and doesn’t have anything to do with protocol semantics AFAICS. But eventually, it may be “learned”, based on ratio of valid/spam/malicious/etc… calls signed by a certain organization.

Thanks,
Tolga

From: Gorman, Pierce A [CTO] <Pierce.Gorman@sprint.com>
Sent: Friday, July 20, 2018 3:12 PM
To: Asveren, Tolga <tasveren@rbbn.com>; williw <wilhelm@wimmreuter.de>
Cc: stir@ietf.org
Subject: RE: [stir] "iat" value to use during PASSPorT construction

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

Because of the large volume of porting and ported numbers I assume it is impractical (or at least undesirable) to validate in real-time that a number is “owned” by the originating carrier.  This also won’t work for the scenarios where the call is signed by a transit or gateway carrier (say for automated traceback).

It has been said many times that just as all unwanted and illegal robocalls do not use spoofed calling numbers, it should be assumed that bad actors will originate signed calls with bad intent.  Prepaid phones and ephemeral enterprise SIP trunks will be a good home for these kinds of calls.  And there are other scenarios as well.

From: Asveren, Tolga [mailto:tasveren@rbbn.com]
Sent: Friday, July 20, 2018 1:18 PM
To: williw <wilhelm@wimmreuter.de<mailto:wilhelm@wimmreuter.de>>
Cc: stir@ietf.org<mailto:stir@ietf.org>
Subject: Re: [stir] "iat" value to use during PASSPorT construction

I don’t think that is an issue as that signature is cryptographically valid doesn’t mean that is “completely fine”. It also should be checked that signing organization is authoritative for the claimed (and verified) origination.

Please consider that the scenario you mention is not related with “originating network signs only if the call leaves the network” policy. It can happen for any case: an intermediary (maybe with malicious intent) just can generate a valid signature for any call by using its own key; but then the above check I mentioned would detect that signer is not authoritative for the origination, i.e. signature is not generated by the originating network.

Thanks,
Tolga

From: stir <stir-bounces@ietf.org<mailto:stir-bounces@ietf.org>> On Behalf Of williw
Sent: Friday, July 20, 2018 11:15 AM
To: Asveren, Tolga <tasveren@rbbn.com<mailto:tasveren@rbbn.com>>
Cc: stir@ietf.org<mailto:stir@ietf.org>
Subject: Re: [stir] "iat" value to use during PASSPorT construction

________________________________
NOTICE: This email was received from an EXTERNAL sender
________________________________

Sorry, I unsuccessfully submitted my concern on jabber list during the meeting.
However, this could be valid in this and applies possibly other areas of stir as well.

My concern that came up while seeing the cat slides in meeting was the following:

Signing outbound / E-gres calls only.
This emulates the old PSTN paradigm and enables impersonation as we have it in SS7.
Without originating signatures this seems to be a big impersonation hole I assume.

In fact, operators will happily sign my robocalls and other malicious stuff.
And this will guarantee that my robocalls have a valid signature that will also be perfect for OOB signalling etc.

Is this concern valid?

Sorry this did not come through the scribe and to the mic.

Thanks

Willi

_______________________________________________
stir mailing list
stir@ietf.org<mailto:stir@ietf.org>
https://www.ietf.org/mailman/listinfo/stir<https://www.ietf.org/mailman/listinfo/stir>

________________________________

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.