Hi Hannes, On 12/15/2018 04:04 PM, Hannes Tschofenig wrote: > Hi Steffi, > > ~snip~ > > >> 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. > > I would think that it is rather unlikely that the RS will change its > public/private key pair so quickly. Right?
I don't really know what you mean with "quickly". Access tokens may be valid for a long time, depending on the application scenario. Also, RS may already have its RPK for a while at the time when AS generates the access token. RPKs do not contain semantic information and C may not have additional information about the RPK. Therefore, C must be able to assume that the RS' RPK is valid as long as the access token. > >> 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. > > These checks make sense to me. > > >> 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. > > Not sure how you came to this conclusion. Why is the request sent by the C to > the RS revealed to an attacker when the token expires? I did not refer to the token, but to the keying material for RS that AS provides to C. If it is outdated, it may have been compromised. Viele Grüße Steffi _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
