authentication request may not have limited lifetime

[Joseph Heenan]

7.1.1. Signed Authentication Request requests the exp claim and the iat claim, but not nbf.

This means if an attacker is able to control the clock on the client (very possible in the case per-instance registered mobile apps) they may be able to generate a long lived authentication request.

I'm not entirely sure why exp is mandatory, but given the stated intent is that exp limits the validity lifetime it would seem sensible to require nbf rather than (or as well as) iat.

[Dave Tonge]

I'm trying to understand this one, please help me understand. If the attacker can control the clock, can't they control iat, nbf and exp?

[Brian Campbell]

I did think about you and the very similar issues in FAPI when I did this part of the document :)

exp is mandatory just because it seemed like a generally good thing to put some temporal constraint on the thing rather than allowing for or encouraging good forever JWTs.

I included iat because somewhere along the line I got the idea from someone or someones that one main driver for these singed requests was for keeping around for auditability or something like that and a timestamp of sorts like iat seemed good there. Also it could be used to detect the kind of situation you describe with an attacker being able to control the clock on the client. Although there's no such normative required behavior for it.

As far as I understand CIBA itslef, the client is highly unlikely to ever be a per-instance registered mobile app. But I'm often wrong about such pronouncements.

But with all that said, there's really no harm in adding nbf as a required claim in this context. So I'll get to that...

[Brian Campbell]

and update the examples... sigh

[Joseph Heenan]

Sorry Brian :-)

To respond to Dave:

If the attacker can control the clock, can't they control iat, nbf and exp?

Yes, that's correct - but what they can't do is control the delta between nbf and exp [without fully compromising the device which is a significantly harder challenge].

Without nbf, I can nudge the clock on a mobile device and get it to get a request that's valid for a few years, where as I'd presume the expected validity of the request to only be enough to allow for clock skew & communication time (so minutes or less if we ignore interstellar use cases :-) .)

I don't know how you go on to translate this into a full attack, but it seems like a significant chink on the armour - I suspect many people doing security analysis would assume that the request did have a limited validity which might lead to a flawed assumption somewhere else.

As far as I understand CIBA itslef, the client is highly unlikely to ever be a per-instance registered mobile app. But I'm often wrong about such pronouncements.

I'm struggling to fully convince myself either way. The kind of use case it might come up in might be an app an an iPad being used as a portable way to do id checks (similar to the bank teller use case in the spec). To me, the two obvious choices there are to have a backend server that's the RP and have a proprietary protocol to talk device <-> backend, or do away with the backend and avoid anything proprietary. Given that FAPI-RW effectively rules out public clients I suspect we may see increasing use of dynamically registered clients, and CIBA seems like a way to use one mobile device to grant access to someone else using another mobile device.

[Brian Campbell]

please take a quick review of 208ff04 and mark this one as resolved if it looks okay

[Joseph Heenan]

Looks good to me, thanks Brian.

[Dave Tonge]

Thanks Joseph.

That helps, but I want to make sure I fully understand this. For example, if in pseudo code:

iat = Date.now()
exp = iat + TOKEN_LIFETIME // e.g. 5 minutes

Then if the attacker nudges the clock into the future won't I end up with an iat that is also in the future?

An iat in the future should be regarded as invalid?

[Joseph Heenan]

Hi Dave, The specs don’t define any default required behaviour for iat, whereas they do for nbf.

The ciba spec could define behaviour for iat that achieves the same effect (I think) but as nbf has the desired behaviour and is already implemented that way by many libraries it seems better to use that. (I had the same question when we ran into this in FAPI for the request object & am thankful to Brian for explaining this to me at rhe time - I suspect his explanation was a bit better though!)

[Dave Tonge]

Thanks Joseph - the libraries I use enforce that iat must not be in the future (I've run into this because of clock skew) but I didn't realise that this behaviour isn't mandated by the specs. I'm fine with nbf I just wanted to make sure I fully understand the issue.

Thanks again