> -----Original Message-----
> From: Ace <[email protected]> On Behalf Of Ludwig Seitz
> Sent: Monday, February 11, 2019 6:23 AM
> To: [email protected]
> 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.
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
[email protected]
https://www.ietf.org/mailman/listinfo/ace
