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

[Göran Selander <[e-mail]>]

> 11 feb. 2019 kl. 19:29 skrev Jim Schaad <[e-mail]>:
> 
> 
> 
>> -----Original Message-----
>> From: Ace <[e-mail]> On Behalf Of Ludwig Seitz
>> Sent: Monday, February 11, 2019 6:23 AM
>> To: [e-mail]
>> Subject: [Ace] Unresolved issue blocking progress for draft-ietf-ace-oauth-
>> authz
>> 
>> 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.
> 
> This is my personal preference.  Telling the client that the RS key expires in a long time is only reasonable if you are planning to do client anonymous TLS connections.  It also has the problem that you no longer have a way to revoke that key.
> 

+1

Reusing ”expires_in” seems like a good solution. 

Göran


> Jim
> 
>>> 
>>> 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]
> 
> 
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace