[Ace] Unresolved issue blocking progress for draft-ietf-ace-oauth-authz

[Ludwig Seitz <[e-mail]>]

Hello all,

I would like to call the group's attention to this message of mine
(it was probably drowned out in the shepherd's review thread):

On 31/01/2019 10:40, Ludwig Seitz wrote:
> 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 not 
> 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

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