Re: [Ace] Fwd: New Version Notification for draft-ietf-ace-oauth-authz-17.txt and draft-ietf-ace-oauth-params-01.txt

[Stefanie Gerdes <[e-mail]>]

Hi Jim,

thank you for your quick response.

On 12/11/2018 09:38 PM, Jim Schaad wrote:
>>
>> C may receive keying material for the communication with RS from AS.
>> Unfortunately, the AS does not inform C how long the keying material is
> valid. C
>> therefore may use outdated keying material for the communication. C cannot
>> rely on RS to reject messages that were sent with outdated keying material
>> because 1. the information in the request sent by C may be confidential
> and is
>> then compromised and 2. C cannot be sure that it is actually communicating
>> with the intended RS if the keying material is no longer valid.
> 
> Would you feel that this would be eased by requiring the expires_in field to
> be required as part of the response?  It is the expiration of the token, but
> I have never understood the difference between the expiration of the token
> and the expiration of keying material myself.  Keying material never
> expires, you just cannot use it without a valid token.

As long as it is clear that the expires_in field describes the time
until the keying material expires, this is at least better than nothing,
although it leaves the problem that the client does not know when the
token was created and how much time has already passed since then.

The ACE framework should also point out that a client must check if its
keying material for RS is still valid before it makes a request.

BTW, I don't think keying material should be valid forever, especially
if there is no useful revocation mechanism.

> 
>>
>> I did not find any indication how the client knows how to choose the
> correct
>> req_aud for RS. The document must point out that C may communicate with
>> the wrong RS unless C and AS have a common understanding how RS is
>> identified.
> 
> Scope is also something that the client does not know how to build.  

In the worst case, a wrong scope can only prevent a client from
accessing a certain resource. Even if the client does not specify any
scope, the AS can still grant it permissions. If they are broad enough,
they will likely cover the resource that C wants to access.
A wrong req_aud however may cause the client to communicate with the
wrong RS. Even worse, C will not be able to notice that it communicates
with the wrong RS. This is a serious security risk. Currently, the ACE
framework does not even acknowledge that such a risk exists.

Viele Grüße
Steffi