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

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 14 Jul 2018 19:22:00 +0000

(Forgive the thread necromancy.)

The reason why there is this loose equivalent between the SIP Date and the value of “iat” is to realize the benefits of PASSporT’s compact form: we want to avoid sending two effectively redundant fields in the same message, so in ordinary operations, it is simplest to just assume that the SIP Date is close enough to PASSporT issuance not to matter for STIR’s threat model, so we can skip including “iat” by-value in the message at all. Hence the RFC8224 language says that if the clock time at the AS is used to populate “iat” then you MUST use full form rather than compact form. To me this usage seems consistent with the definition of “iat”, as I don’t see in RFC7519 any normative language about how we are to understand issuance, like say a MUST that “iat” means local clock time. If there were language like that, you’d be quite correct to object. But as I read the JWT RFCs, I don’t think I see the conflict here between RFC8224 and 8225, and more importantly I can’t see any practical deficiency or confusion this causes.

To your other concern about whether or not the recommended 60 second grace time for call setup is too low, due to the potential for call parking during certain types of processing, I see that as a pretty orthogonal issue. I don’t think that call parking happens between the UAC and the AS, which is the only place it matters for this concern. If your call ends up in a store-and-forward situation like that, I would expect you would do something exceptional like generating a new PASSporT. I would be reluctant to extend our recommendation.

Jon Peterson
Neustar, Inc.

From: stir <[email-masked]> on behalf of "Asveren, Tolga" <[email-masked]>
Date: Friday, May 18, 2018 at 3:28 AM
To: Chris Wendt <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [stir] "iat" value to use during PASSPorT construction

i- I don’t think we should discredit/undervalue “philosophical aspects”. This is actually what needs to be right. It is what we call “architecture”, isn’t it? It is the foundation for the procedures.
ii- Is there a rathole here? Yes, I think there is and that is because of the “confusion” in RFC8224/8225. So, it is a “self-inflicted damage”, not something which was unavoidable.
iii- It is pretty clear that “iat” pertains to JWS creation per RFC7519. It really is not a good idea to violate this.
iv- Are there practical cases where there would be a significant difference between session initiation time and JWS creation time, yes certainly and I already provided some examples. I am sure there are many more and who knows what the future will bring. Nonetheless, the real issue is that “iat” is not to assert session origination time even if there were no such cases and its use as such wouldn’t be a good idea IMHO.
v- What needs to be done?

-          RFC8224/8225 should be updated so that use of “iat” as issuance time of JWS is clear and there are no violations.

-          If there is a need to assert session origination time, then that should be a new JWS parameter defined for some claim type, for example “shaken”. Actually I would prefer that it is not tied to “shaken” and is a new claim type. The reason being that it may be needed even if one doesn’t want to use “shaken”.

I am planning to file errata for RFC8224/8225 and probably prepare a draft for a new claim type for session origination time -at least to gauge the interest-.

Thanks,
Tolga

From: Chris Wendt <[email-masked]>
Sent: Thursday, May 17, 2018 7:40 PM
To: Asveren, Tolga <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] "iat" value to use during PASSPorT construction

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

There is a bunch of philosophical ratholes we could go down here, but the “issuance” of a JWT i don’t believe is strictly meant to correspond to the “exact” time that the JWT is constructed.  My understanding is that it is meant to represent the time the token is valid in the context of the application and the claims you are making for that application.
In the context of STIR, the initiation of the INVITE and the corresponding signing of that INVITE should occur in a very small time delta, whether it happens on the same device or between the SIP UE and a network element receiving that INVITE shortly later.  I believe this scenario is completely appropriate within the scope of the definition of “issuance” time.

On May 17, 2018, at 3:46 PM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:

To add a bit more color:

The following is the most authoritative specification regarding “iat” generation in general IMHO:

RFC7519 JSON Web Token (JWT)

4.1.6.  "iat" (Issued At) Claim

   The "iat" (issued at) claim identifies the time at which the JWT was

   issued.  This claim can be used to determine the age of the JWT.  Its

   value MUST be a number containing a NumericDate value.  Use of this

   claim is OPTIONAL.

This text clearly states that “iat” is for the generation time of JWS.

So, I think both RFC8224/8225 need to be updated to prevent any ambiguity and be completely consistent with RFC7519.

Thanks,
Tolga

From: Asveren, Tolga
Sent: Tuesday, May 15, 2018 1:33 PM
To: Chris Wendt <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [stir] "iat" value to use during PASSPorT construction

Ideally specifications should have a firm stand on the scope of “iat” IMHO. Ambiguity is something to avoid even if the immediately envisioned use cases could function with both interpretations (and honestly I even doubt that let alone the impact on future extensions/new claim types).

As I already indicated, what makes sense to me is that it for the “JSW”, not for the session therefore “current time” instead of Date needs to be used.

And as a side question: Is there really a practical concern regarding full-form being longer than the compact form? Are the extra few hundreds of octets really something causing heartburn considering that media associated with a session usually would require several magnitudes more?

Thanks,
Tolga

From: Chris Wendt <[email-masked]<mailto:[email-masked]>>
Sent: Monday, May 14, 2018 10:31 AM
To: Asveren, Tolga <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [stir] "iat" value to use during PASSPorT construction

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

Hi Tolga,

I think the 60sec recommendation is a default, however, i think once we get more operational experience to see what the delta offsets of time typically are, we will have a better sense of what value to use and whether to move to a smaller time window or not.  This should in general be considered local policy what you believe is an acceptable time window. You may also want to implement secondary TDOS/replay attack types of protection to help here as well and not solely depend on “iat” freshness within that short time window.

In regards to the other part of your question, 8224 is saying to use the PASSporT “iat” to correspond to the DATE value of the SIP.  The assumption is that the PASSporT is being created at/close to the initiation of the INVITE.  I think whether you interpret that as taking the DATE and setting it exactly to the “iat” or if you are generating a PASSporT “iat” as a specifically 8225 compliant function in isolation, either will generally work if you are using full form of passport.  From what i’m personally aware of, most implementations are following the former vs the latter.

-Chris

On May 14, 2018, at 5:17 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:

RFC 8224 has the following in Section “4.1 PASSPorT Construction”:

      Third, the JSON key "iat" MUST appear.  The authentication service

      SHOULD set the value of "iat" to an encoding of the value of the

      SIP Date header field as a JSON NumericDate (as UNIX time, per

      [RFC7519], Section 2), though an authentication service MAY set

      the value of "iat" to its own current clock time.  If the

      authentication service uses its own clock time, then the use of

      the full form of PASSporT is REQUIRED.  In either case, the

      authentication service MUST NOT generate a PASSporT for a SIP

      request if the Date header is outside of its local policy for

      freshness (sixty seconds is RECOMMENDED).

RFC 8225 has the following in Section “5.1.1 “iat” (Issued At) Claim”:

   The JSON claim MUST include the "iat" (Issued At) claim ([RFC7519],

   Section 4.1.6).  As defined, the "iat" claim should be set to the

   date and time of issuance of the JWT and MUST indicate the date and

   time of the origination of the personal communications.  The time

   value should be of the NumericDate format as defined in [RFC7519],

   Section 2.  This is included for securing the token against replay

   and cut-and-paste attacks, as explained further in Section 10

   ("Security Considerations").

i- I see some conflict in RFC8225 text. It is mentioned that “iat” should be set based on issuance of JWT (which would be when PASSPorT is constructed). OTOH, it is also stated that it MUST indicate the date and time of the origination of the personal communication. The former seems to be  the right approach as what we would like to protect against cut-and-paste attacks is the PASSPorT in the context of a particular communication session. Coupling of PASSPorT with the communication session is provided through “orig”/”dest”. “iat” should be set to the time of generation of PASSPorT IMHO. RFC8244 text seems to be O.K. if one accepts this interpretation as it has the notion of “local policy for freshness”. The recommended value is on the very high end (anything more than a few seconds is too much in practice IMHO) but it is at least not mandating use of 60s.

ii- Aren’t there legitimate cases where a communication session continues for some period of time and then due to change in its nature requires addition of PASSPorT, e.g. first there is an announcement/interaction with an automated system (which may last several minutes) and then the called-party is contacted during which PASSPorT is added (because, for example, organizational boundaries are crossed and there is a need to validate calling-party identity). For such cases there could be a legitimate and major discrepancy between Date and “current time”. This is another argument in favor of considering “iat” as corresponding to PASSPorT generation rather than start of communication session IMHO. There could eb many other scenarios where similar discrepancy legitimately happens especially if one considers non-base claim types, e.g.. “div”.

So, the bottom line is I would like to get people’s opinion about whether “iat” should pertain to the start of communication session or to the creation of PASSPorT.

Thanks,
Tolga

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_stir&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0weXHNMl9xZnnsIiwRd6IgY&m=AAVoKPky2BsSImuZp_fMsI2mAY2lNbYFo36l9CD-vRk&s=ot9ai-6i_x_k2uq1Onv21l2Y1-LhEdl4yDn6Uh-kSs4&e=>

---

From: williw <[email-masked]>
Date: Fri, 20 Jul 2018 17:15:20 +0200

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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 20 Jul 2018 18:18:21 +0000

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 <[email-masked]> On Behalf Of williw
Sent: Friday, July 20, 2018 11:15 AM
To: Asveren, Tolga <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] "iat" value to use during PASSPorT construction

Is this concern valid?

Thanks

Willi

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

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Fri, 20 Jul 2018 19:12:22 +0000

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:[email-masked]]
Sent: Friday, July 20, 2018 1:18 PM
To: williw <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] "iat" value to use during PASSPorT construction

Thanks,
Tolga

From: stir <[email-masked]<mailto:[email-masked]>> On Behalf Of williw

Is this concern valid?

Thanks

Willi

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
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.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 20 Jul 2018 19:53:35 +0000

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] <[email-masked]>
Sent: Friday, July 20, 2018 3:12 PM
To: Asveren, Tolga <[email-masked]>; williw <[email-masked]>
Cc: [email-masked]
Subject: RE: [stir] "iat" value to use during PASSPorT construction

To: williw <[email-masked]<mailto:[email-masked]>>

Thanks,
Tolga

Is this concern valid?

Thanks

Willi

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Fri, 20 Jul 2018 20:23:45 +0000

I think you missed my point.  There will be authoritatively signed calls with legitimate numbers from bad actors placing illegal or unwanted calls with bad intent.  Get enough of them and you can think of it as poisoning the well.

Pierce

From: Asveren, Tolga [mailto:[email-masked]]
Sent: Friday, July 20, 2018 2:54 PM
To: Gorman, Pierce A [CTO] <[email-masked]>; williw <[email-masked]>
Cc: [email-masked]
Subject: RE: [stir] "iat" value to use during PASSPorT construction

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.

Thanks,
Tolga

From: Gorman, Pierce A [CTO] <[email-masked]<mailto:[email-masked]>>
Sent: Friday, July 20, 2018 3:12 PM
To: Asveren, Tolga <[email-masked]<mailto:[email-masked]>>; williw <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [stir] "iat" value to use during PASSPorT construction

Thanks,
Tolga

Is this concern valid?

Thanks

Willi

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fstir&data=02%7C01%7Cpierce.gorman%40sprint.com%7C7bd5c71eb8c44aaea07308d5ee7a7e60%7C4f8bc0acbd784bf5b55f1b31301d9adf%7C0%7C0%7C636677132235044610&sdata=4xbcc%2BA815i2iwOqQnmym6xX3%2FI1%2Boe%2Fv%2Bj7rRXO%2FAo%3D&reserved=0>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 20 Jul 2018 20:26:33 +0000

Again, there should be a policy to cover that, e.g. such organizations won’t be trusted anymore or at least not on the same level with others which did a good job on their end  as originating network. And probably some regulatory action can be taken based on complaints.

Thanks,
Tolga

From: Gorman, Pierce A [CTO] <[email-masked]>
Sent: Friday, July 20, 2018 4:24 PM
To: Asveren, Tolga <[email-masked]>; williw <[email-masked]>
Cc: [email-masked]
Subject: RE: [stir] "iat" value to use during PASSPorT construction

Pierce

To: Gorman, Pierce A [CTO] <[email-masked]<mailto:[email-masked]>>; williw <[email-masked]<mailto:[email-masked]>>

Thanks,
Tolga

Thanks,
Tolga

Is this concern valid?

Thanks

Willi

---

From: "Gorman, Pierce A [CTO]" <[email-masked]>
Date: Fri, 20 Jul 2018 20:32:29 +0000

None of which invalidates the concern Willi asked about.

I’m not saying there aren’t approaches available for dealing with signed and verified but still bad calls.  All I am saying is Willi is correct to be concerned because it happens today without the signatures.  What we’re discussing is constraints and limitations and those are worth identifying and acknowledging.

Pierce

From: Asveren, Tolga [mailto:[email-masked]]
Sent: Friday, July 20, 2018 3:27 PM
To: Gorman, Pierce A [CTO] <[email-masked]>; williw <[email-masked]>
Cc: [email-masked]
Subject: RE: [stir] "iat" value to use during PASSPorT construction

Thanks,
Tolga

Pierce

Thanks,
Tolga

Thanks,
Tolga

Is this concern valid?

Thanks

Willi

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 20 Jul 2018 20:35:33 +0000

I didn’t say I disagree. What I said is that none of these are introduced by “sign a call only if it leaves my network when I am the originating network” approach. It is how things are in general.

Thanks,
Tolga

From: stir <[email-masked]> On Behalf Of Gorman, Pierce A [CTO]
Sent: Friday, July 20, 2018 4:32 PM
To: Asveren, Tolga <[email-masked]>; williw <[email-masked]>
Cc: [email-masked]
Subject: Re: [stir] "iat" value to use during PASSPorT construction

Pierce

Thanks,
Tolga

Pierce

Thanks,
Tolga

Thanks,
Tolga

Is this concern valid?

Thanks

Willi