> 11 feb. 2019 kl. 19:29 skrev Jim Schaad <i...@augustcellars.com>: > > > >> -----Original Message----- >> From: Ace <ace-boun...@ietf.org> On Behalf Of Ludwig Seitz >> Sent: Monday, February 11, 2019 6:23 AM >> To: ace@ietf.org >> 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 +46(0)70-349 92 51 > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
