Hello all, I would like to call the group's attention to this message of mine (it was probably drowned out in the shepherd's review thread):
On 31/01/2019 10:40, Ludwig Seitz wrote:
Hello,we have an unresolved review comment by Steffi that got lost in the holiday season:https://mailarchive.ietf.org/arch/msg/ace/CBTkVUBzYrfC55zH3_UJDngiy9U https://mailarchive.ietf.org/arch/msg/ace/NrQWetugoy0TWp9eg3lwtSictc8 The issue is the following (my words):The AS provides the client with key material used by the RS. This can either be a common symmetric pop-key, or an asymmetric key used by the RS to authenticate towards the client.Since there is (currently) no metadata associated to those keys, the client has no way of knowing if these keys are still valid. This may lead to situations where the client sends requests containing sensitive information to the RS using a key that is expired and possibly in the hands of an attacker, or accepts responses from the RS that are not properly protected and could possibly have been forged by an attacker.The options to resolve this that I currently see are this:1. If the client has no additional data it MUST assume that the key is valid as long as the access token together with which it received that key. Since the access token is opaque to the client, the client MUST now determine how long the token is valid:Option 1.1 The client is provisioned in advance with a default validity time for tokens issued by the AS. This could be done when the client is registered at the AS.Option 1.2 The AS informs the client using the "expires_in" parameter in the Access Information.This means that we need to implement a check whether the client knows a default validity, and if that is not the case reject an access token that does not come together with an "expires_in" parameter.2. We can define a new parameter that informs the client specifically about the validity of the keys the RS uses, if that differs from the validity of the token. Note that this is a realistic use case, since the RS might use an asymmetric key for authentication that is valid for a significantly longer period than some access token.I would need some feed-back from the group to proceed here. /Ludwig
/Ludwig -- Ludwig Seitz, PhD Security Lab, RISE Phone +46(0)70-349 92 51
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
