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 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
