Subject: [Id-event] "exp" claim in draft-ietf-secevent-token-07

From: Marius Scurtescu <[email-masked]>
Date: Wed, 21 Mar 2018 20:49:02 -0700

Section 2.2 for "exp" states:

"this claim is the time after which the JWT MUST NOT be accepted for
processing.  In the context of a SET however, this notion does not
typically apply, since a SET represents something that has already occurred
and is historical in nature. Therefore, its use is NOT RECOMMENDED."

Similarly, section 4.5 makes recommendations against "exp".

At IETF 100 in Singapore we briefly talked about this and the following
problem came up: without "exp" how long should a receiver cache "jti"
values to prevent double submissions (and replay attacks)?

Today the same problem was raised as implementation feedback.

It seems that "exp" should rather be required. Thoughts?

What happens to section 4.5 if "exp" is required?

Also, a required (or recommended) "exp" leads to implementation challenges
when it comes to delivery. A transmitter that is retrying to deliver
unconfirmed SETs, will have to probably re-mint them on each delivery
attempt, as opposed to simply cache a minted SET and keep retrying with
that. Or the transmitter will have to set an expiration period longer than
the retry period, but long expiration periods put bigger loads on receivers
(larger cache).

Any chance this can be discussed on Friday?

Marius

---

From: Mike Jones <[email-masked]>
Date: Thu, 22 Mar 2018 10:29:29 +0000

To me, it seems that trying to mandate that an expiration time be sent when there is no natural expiration time for the information is odd at best, and counterproductive at worst.  We should not encourage deployers to have to “invent” arbitrarily chosen values and include them as claims to satisfy a MUST that shouldn’t have been there.

Caching decisions are highly deployment specific.  They could, for instance, be based on a deployment-specified delta from the “iat” (issued at) value and not use “exp” at all.

With respect to “exp”, I think the spec already has it right for the general case.  Of course, it’s fine for particular Profiling Specifications to require that “exp” be present and define constraints that the claim value must satisfy for deployments using that profile…

                                                       -- Mike

From: Id-event <[email-masked]> On Behalf Of Marius Scurtescu
Sent: Thursday, March 22, 2018 3:49 AM
To: ID Events Mailing List <[email-masked]>
Subject: [Id-event] "exp" claim in draft-ietf-secevent-token-07

"this claim is the time after which the JWT MUST NOT be accepted for processing.  In the context of a SET however, this notion does not typically apply, since a SET represents something that has already occurred and is historical in nature. Therefore, its use is NOT RECOMMENDED."

At IETF 100 in Singapore we briefly talked about this and the following problem came up: without "exp" how long should a receiver cache "jti" values to prevent double submissions (and replay attacks)?

Also, a required (or recommended) "exp" leads to implementation challenges when it comes to delivery. A transmitter that is retrying to deliver unconfirmed SETs, will have to probably re-mint them on each delivery attempt, as opposed to simply cache a minted SET and keep retrying with that. Or the transmitter will have to set an expiration period longer than the retry period, but long expiration periods put bigger loads on receivers (larger cache).

Marius

---

From: Phil Hunt <[email-masked]>
Date: Thu, 22 Mar 2018 10:41:43 +0000

There are also a number of security considerations in the draft regarding use of “exp” and differentiation from access tokens that are important. 

Phil

> On Mar 22, 2018, at 10:29 AM, Mike Jones <[email-masked]> wrote:
> 
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=QQOgQSojDGJSe_9Lg0oGRRneEiqaQvngT0E72naO7dw&s=6ko84GUvrZOLjdLorjYhGWnlDd8x_j2zTLxeEESL56c&e=

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 22 Mar 2018 12:26:31 -0700

Leif, I believe you raised this issue at a past meeting. Do you have any
thoughts?

Comments inline...

On Thu, Mar 22, 2018 at 3:29 AM, Mike Jones <[email-masked]>
wrote:

> To me, it seems that trying to mandate that an expiration time be sent
> when there is no natural expiration time for the information is odd at
> best, and counterproductive at worst.  We should not encourage deployers to
> have to “invent” arbitrarily chosen values and include them as claims to
> satisfy a MUST that shouldn’t have been there.
>

"exp" does not apply to the event(s), it applies to the envelope, same as
"iat". Here is the definition from RFC 7519:
"The "exp" (expiration time) claim identifies the expiration time on or
after which the JWT MUST NOT be accepted for processing."

Transmitters don't "invent" the value, the value falls out of re-try
parameters and the specific delivery method used. Are IdPs inventing the
exp in an Id Token?

Also, "exp" in a SET should probably be "RECOMMENDED" and not "MUST".

>
> Caching decisions are highly deployment specific.  They could, for
> instance, be based on a deployment-specified delta from the “iat” (issued
> at) value and not use “exp” at all.
>

For sure, but an exp claim makes the whole process more secure. A receiver
may decide to cache for 2 minutes (and not accept SETs older than 2
minutes, hopefully), but a transmitter my keep re-trying to send events for
10 minutes. Many things can go wrong if exp is not present.

>
>
> With respect to “exp”, I think the spec already has it right for the
> general case.  Of course, it’s fine for particular Profiling Specifications
> to require that “exp” be present and define constraints that the claim
> value must satisfy for deployments using that profile…
>

Yaron just raised concerns about interop, pushing this issue to profiles is
not helping interop IMO.

>
>
>                                                        -- Mike
>
>
>
> *From:* Id-event <[email-masked]> *On Behalf Of *Marius
> Scurtescu
> *Sent:* Thursday, March 22, 2018 3:49 AM
> *To:* ID Events Mailing List <[email-masked]>
> *Subject:* [Id-event] "exp" claim in draft-ietf-secevent-token-07
>
>
>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 22 Mar 2018 12:29:13 -0700

On Thu, Mar 22, 2018 at 3:41 AM, Phil Hunt <[email-masked]> wrote:

> There are also a number of security considerations in the draft regarding
> use of “exp” and differentiation from access tokens that are important.
>

Yes, of course. That's why I mentioned section 4.5.

I don't think we should fix the id token confusion problem by introducing a
replay attack problem.

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=QQOgQSojDGJSe_
> 9Lg0oGRRneEiqaQvngT0E72naO7dw&s=6ko84GUvrZOLjdLorjYhGWnlDd8x_
> j2zTLxeEESL56c&e=
>
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 23 Mar 2018 09:30:19 +0000

I disagree with your characterization that “exp” has anything to do with the delivery method.  Having it do so would be a layering violation, as a SET should be the same no matter what transport is used.  If a particular delivery method needs caching/timeout parameters it should specify them as part of the transport (just like HTTP does), rather than trying to inject transport-specific content into the payload.

                                                       -- Mike

From: Marius Scurtescu <[email-masked]>
Sent: Thursday, March 22, 2018 7:27 PM
To: Mike Jones <[email-masked]>; Leif Johansson <[email-masked]>
Cc: ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] "exp" claim in draft-ietf-secevent-token-07

Leif, I believe you raised this issue at a past meeting. Do you have any thoughts?

Comments inline...

On Thu, Mar 22, 2018 at 3:29 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
To me, it seems that trying to mandate that an expiration time be sent when there is no natural expiration time for the information is odd at best, and counterproductive at worst.  We should not encourage deployers to have to “invent” arbitrarily chosen values and include them as claims to satisfy a MUST that shouldn’t have been there.

"exp" does not apply to the event(s), it applies to the envelope, same as "iat". Here is the definition from RFC 7519:
"The "exp" (expiration time) claim identifies the expiration time on or after which the JWT MUST NOT be accepted for processing."

Transmitters don't "invent" the value, the value falls out of re-try parameters and the specific delivery method used. Are IdPs inventing the exp in an Id Token?

For sure, but an exp claim makes the whole process more secure. A receiver may decide to cache for 2 minutes (and not accept SETs older than 2 minutes, hopefully), but a transmitter my keep re-trying to send events for 10 minutes. Many things can go wrong if exp is not present.

Yaron just raised concerns about interop, pushing this issue to profiles is not helping interop IMO.

                                                       -- Mike

From: Id-event <[email-masked]<mailto:[email-masked]>> On Behalf Of Marius Scurtescu
Sent: Thursday, March 22, 2018 3:49 AM
To: ID Events Mailing List <[email-masked]<mailto:[email-masked]>>
Subject: [Id-event] "exp" claim in draft-ietf-secevent-token-07

Marius