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 +46(0)70-349 92 51
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
