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

[Ludwig Seitz <[e-mail]>]

On 12/12/2018 10:27, Stefanie Gerdes wrote:
> 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.
> 

Note that expires_in (exi) is currently defined as "expires in x seconds 
from the time at which the RS first saw the token".

I am aware that this is quite weak since malicious clients can hoard 
tokens that would be valid indefinitely. I do not currently see any 
other means of expiration when the RS has no connectivity to the AS and 
no synchronized clock. I would be open for suggestions if you have 
better ideas.


>>>
>>> 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.
> 
We do acknowledge that, in the security considerations of 
draft-ietf-ace-oauth-params where req_aud is defined. I'll add 
additional clarification to that text though, since it currently only 
talks about the needing to RS know which audiences it recognizes.




-- 
Ludwig Seitz, PhD
Security Lab, RISE
Phone [phone]