Hi Steffi, ~snip~
> 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 think that's a useful recommendation. I do, however, believe that we are not making the same assumption for an asymmetric key bound to 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. I would think that it is rather unlikely that the RS will change its public/private key pair so quickly. Right? > 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? Ciao Hannes Viele Grüße Steffi _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
