Hello ACE,I've had a side-meeting with Ben at IETF 106 and we clarified the outstanding issues as follows. I have submitted -26 implementing the resolutions resulting from these clarifications. See below for detailed comments.
/Ludwig On 17/11/2019 07:25, Benjamin Kaduk wrote:
On Wed, Nov 13, 2019 at 01:55:44PM +0100, Ludwig Seitz wrote:On 10/11/2019 04:28, Benjamin Kaduk wrote:
16.) Section 3.2 One application of COSE is OSCORE [I-D.ietf-core-object-security], which provides end-to-end confidentiality, integrity and replay protection, and a secure binding between CoAP request and response messages. In OSCORE, the CoAP messages are wrapped in COSE objects and sent using CoAP. This framework RECOMMENDS the use of CoAP as replacement for HTTP for use in constrained environments. Do we have a reason to mention OSCORE if we're not going to make a recommendation about its use?[LS] We also mention DTLS and TLS without making any recommendation about which to use. I would suggest to either remove all of it or to add a sentence noting that this is an enumeration of some security options, and the choice depends on the specific application scenario.Adding a sentence feels like a slightly better option to me, though it could easily go either way.Fixed
Note: I thought I had fixed this in -25, but it turned out to only be in my head. It's now also fixed in the document (i.e. -26).
39.) Refresh tokens are typically not stored as securely as proof-of- possession keys in requesting clients. Proof-of-possession based refresh token requests MUST NOT request different proof-of-possession keys or different audiences in token requests. Refresh token requests can only use to request access tokens bound to the same proof-of-possession key and the same audience as access tokens issued in the initial token request. This is perhaps something of a philosophical question, but if a refresh token is only usable at the token endpoint, in some sense its audience is definitionally the AS. So there's a little bit of a mismatch in treating it as having the audience value that the access tokens issued from it will have. I don't know the background for audience-restriced refresh tokens in regular OAuth 2.0, though, so hopefully someone can educate me.[LS] I'm equally confused. I suggest that Hannes or one of the other OAuth experts give us a hint on that one.[We had some stab at this in the other thread, but additional input might still be in order]Let's hear with OAuth people in Singapore.
We discussed that now, the text refers to the audience of the access token, not the refresh token which is just an opaque reference. -> No textual change.
58.) Profiles MUST specify whether the authz-info endpoint is protected, including whether error responses from this endpoint are protected. Note that since the token contains information that allow the client and the RS to establish a security context in the first place, mutual authentication may not be possible at this point. We'll need some careful reasoning about this for the security considerations, since the authz-info transaction can impact what profile the RS thinks is in use. E.g., whether a network attacker could cause the client to think that a different (vulnerable) profile is in use than the one the RS expects to use.[LS] Noted. Do you think the reasoning in section 6.5 needs to be extended?I think we should add some more text, yes. Specifically, we should mention that the authz-info interaction can affect what profile RS will use (e.g., via "ace_profile"), and that profile developers should be conscious of the risk of downgrade attacks that involve other profile types. (Am I reading this right that the client will know what profile to use by the time it is ready to post to the authz-info endpoint and that the response will not change what profile the client uses? Specifically, even if a client supports multiple profiles that use different methods for token transport, a client is not going to try one method/profile and then fall back to a different one if the first one (transiently) fails?)I'm not sure how you would mount such a downgrade attack. The client receives the profile to use either by implicit configuration or explicitly through the "profile" parameter from the AS. If the client does not receive a "profile" parameter and has no implicit profile configured this is an error. The RS either has the profile pre-configured or receives it via an authenticated "profile" claim in the access token (again if the claim is missing and no pre-configured profile exists this is an error). Even though the token is sent to authz-info over an insecure channel and the client is not yet authenticated, the access token itself is, and therefore I find it hard to see how an attacker would trick the RS to use a different profile.The general idea I have in mind is that the attacker can send a different token to authz-info than would be used in normal operation. Maybe it's an old one, or supposed to be for a different client, or something else, but the risk is that the attacker confuses the RS about what token (and thus which profile) to use with a given client. I think we have enough flexibility in how these things are done that the core framework does not provide a solid guarantee that such a mixup can never happen.
I've added some clarifying text in section 6.8 providing a description of the attack and what the RO can do to mitigate it.
65.) specification defines the following approach: The claim "exi" ("expires in") can be used, to provide the RS with the lifetime of the token in seconds from the time the RS first receives the token. This approach is of course vulnerable to malicious clients holding back tokens they do not want to expire. Such an attack It also has suboptimal behavior if the RS loses state (e.g., by rebooting), and possibly requires the RS to store indefinitely all tokens with an "exi" value. I have mixed feelings about specifying it at all, though I concede it probably does have some value. Regardless, I think a dedicated subsection in the security considerations is in order.[LS] We wanted to provide some solution for expiring tokens for RSes that have no connectivity and no synchronized clocks. Using the "exp" claim in such cases would have pretty unpredictable results. I have extended section 6.3 in the security considerations to go into the detail of "exi", please have a look if this covers the necessary issues.I think we should also say something about the amount of such persistent storage potentially growing without bound, as those counters (or some similar indication) are the only thing that will cause the RS to reject tokens that have been used the requisite number of times. So, RS state requirements grows with the number of 'exi'-bearing tokens that are issued for them. I suppose a bloom filter might be a way out, though...I don't see why storage requirements would grow more compared to regular tokens with the "exp" claim. The way exi is intended to be implemented is as follows: 1. C ---Token(exi=100)---> RS (internal_clock=54645) 2. RS generates a new 'exp' for the token, sets it to 54745 and discards the exi claim. 3. RS expires token according to internal clock (i.e. at 54745) If you send the RS a lot of tokens it will eventually exhaust its memory, but that would happen with regular exp claims as well if the attacker can craft/obtain enough tokens with sufficiently long lifetime. Note that these would have to be tokens for different clients, since the framework currently recommends to only store one token per client. The advantage for the attacker with exi is that it could hold back any tokens without having to worry about the expiration, but it would still have to hoard enough tokens for different clients, all applicable to the RS in order to exhaust the RS's storage.My point is that a token with "exi" is potentially valid "forever". Suppose I use that token once, and the RS does as you describe above, computing an "exp" for that token. If I post a new token to that RS so it discards the "exi"-ful token, or the expiration timer fires and the RS forgets about that token, then there is nothing to stop me (or an attacker) from replaying that same original "exi"-bearing token. The RS would then see "exi", compute a new derived "exp", and give the token a whole nother validity period. Only if the RS retains some state that it has seen that specific token and used up the "exi" period is this token replay prevented. I don't see a way to reliably retain that state without having some permanent storage dedicated to the state for each "exi" token that has evern been received, over the lifetime of the RS. (A bloom filter or similar solution uses less state, but reduces reliability to some extent.)
I've added text in sections 6.6. and 5.8.3 to address this.
68.) o The client performs an introspection of the token. Although this is not explicitly forbidden, how exactly a client does introspection is not currently specified for OAuth. I'm pretty sure this is overtaken by events (sorry for my part in that!). E.g., draft-ietf-oauth-jwt-introspection-response discusses clients doing introspection, and even RFC 7662 itself discusses using a client secret to authenticate to the introspection endpoint. I think there's another document between those two that's also relevant, but can't find it right now[LS] I am not so sure. When reading the fine print in both RFC 7662 and draft-ietf-oauth-jwt-introspection-response, I find that when they mention the term "client", they refer to the protected resource / RS as being a client of the AS introspection endpoint. A client holding an access token and performing introspection is never explicitly mentioned in both documents, to my best knowledge.It seems like we should try to check on this in Singapore, while the usual suspects are easily at hand.Yes together with the other OAuth questions.
We discussed this, OAuth experts disagree whether introspection by clients is implicitly forbidden. It is not explicitly forbidden at least, so the text is still correct. -> No change
Background: The OAuth experts arguing for "implicitly forbidden" point to the text saying: "In OAuth 2.0 [RFC6749], the contents of tokens are opaque to clients." (from RFC 7662) and read this as "the client should/must not know the contents of the token and therefore not be allowed to do introspection".
/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
