Re: [Ace] Shepard review for draft-ietf-ace-oauth-authz

[Ludwig Seitz <[e-mail]>]

Hello,

we have an unresolved review comment by Steffi that got lost in the 
holiday season:

https://mailarchive.ietf.org/arch/msg/ace/CBTkVUBzYrfC55zH3_UJDngiy9U
https://mailarchive.ietf.org/arch/msg/ace/NrQWetugoy0TWp9eg3lwtSictc8


The issue is the following (my words):

The AS provides the client with key material used by the RS. This can 
either be a common symmetric pop-key, or an asymmetric key used by the 
RS to authenticate towards the client.

Since there is (currently) no metadata associated to those keys, the 
client has no way of knowing if these keys are still valid. This may 
lead to situations where the client sends requests containing sensitive 
information to the RS using a key that is expired and possibly in the 
hands of an attacker, or accepts responses from the RS that are no 
properly protected and could possibly have been forged by an attacker.


The options to resolve this that I currently see are this:


1. If the client has no additional data it MUST assume that the key is 
valid as long as the access token together with which it received that 
key. Since the access token is opaque to the client, the client MUST now 
determine how long the token is valid:

Option 1.1 The client is provisioned in advance with a default validity 
time for tokens issued by the AS. This could be done when the client is 
registered at the AS.

Option 1.2 The AS informs the client using the "expires_in" parameter in 
the Access Information.

This means that we need to implement a check whether the client knows a 
default validity, and if that is not the case reject an access token 
that does not come together with an "expires_in" parameter.

2. We can define a new parameter that informs the client specifically 
about the validity of the keys the RS uses, if that differs from the 
validity of the token. Note that this is a realistic use case, since the 
RS might use an asymmetric key for authentication that is valid for a 
significantly longer period than some access token.


I would need some feed-back from the group to proceed here.

/Ludwig

-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone [phone]