[Ace] Security of the Communication Between C and RS (was: Re: 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 Ludwig,

>>
>> I am currently only referring to the keying material that AS provides to
>> C, i.e., the symmetric key shared between C and RS or, if asymmetric
>> keys are used, RS's RPK. Since it is clear to you that symmetric keys
>> are only valid as long as the token, you should point that out in the
>> document. C then has at least some clue how long the token is valid.
>> Which is better than nothing.
> 
> How would that give C a clue? There is no metadata associated to
> proof-of-possession keys that would tell C how long they are valid. Are
> you proposing we define such meta-data?
> 
> If symmetric pop-keys are created for an access token, what point would
> there be to give them another lifetime than the token? Do you really
> think we need to write that out.

I really think you should point out that symmetric keying material that
the AS provides to the client is valid as long as the token.

I also think that the client must be able to assume that RS' RPK that C
receives from AS is also valid as long as the token, unless C has
additional information.

The access information optionally can contain an expires_in field. It
would help to prevent security breaches under the following conditions:
1. the keying material is valid as long as the ticket, 2. the expires_in
field is present in the access information that AS sends to C, 3. the
client checks the expires_in field when it gets the access information
from the AS, and 4. the client checks if the keying material is still
valid each time before it sends a request to RS.

Without these steps, the confidentiality of the request data that C
sends to RS may be breached, and C may communicate with the wrong RS
using outdated keying material.

Viele Grüße
Steffi