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

From: Ludwig Seitz <[email-masked]>
Date: Mon, 11 Feb 2019 15:23:10 +0100

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 +46(0)70-349 92 51

---

From: Jim Schaad <[email-masked]>
Date: Mon, 11 Feb 2019 10:28:44 -0800

> -----Original Message-----
> From: Ace <[email-masked]> On Behalf Of Ludwig Seitz
> Sent: Monday, February 11, 2019 6:23 AM
> To: [email-masked]
> 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):
> 
> > 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.
> >
> >
> > 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

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.

Jim

> > 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.
> >
> >

---

From: Göran Selander <[email-masked]>
Date: Tue, 12 Feb 2019 07:47:26 +0000

> 11 feb. 2019 kl. 19:29 skrev Jim Schaad <[email-masked]>:
> 
> 
> 

+1

Reusing ”expires_in” seems like a good solution. 

Göran

> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace