Hi all, The length of this review notwithstanding, this document is generally in good shape -- there's a bunch of localized items to tighten up, and we can flesh out the security considerations some more, but nothing too drastic should be needed. Perhaps the most far-reaching changes needed will be to rename the "profile" claim, since that has already been allocated to OIDC Core for a very different usage. I also made a pull request with a bunch of trivial editorial stuff that's easier to fix than describe how to fix, up at https://github.com/ace-wg/ace-oauth/pull/175 .
One general note before getting into the section-by-section comments: There's a bunch of places where we talk about parameters that "MUST be mapped to CBOR types as specified in Figure N"; we may want to point to the IANA registry as authoritative and just give the figure reference for description. Abstract OAuth. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing nit: It's easy to (mis)read this text as saying that just amalgamating OAuth 2.0 and CoAP magically makes for a solution that is well-known and widely used. I'd suggest rewording slightly, perhaps "thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices". specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined. nit: from a rhetorical point of view, it's probably better to reiterate why the extensions are added and profiles defined ("to better serve the IoT case") than to just stop with a flat declaration of what is done. Section 1 Authorization is the process for granting approval to an entity to access a resource [RFC4949]. The authorization task itself can best be described as granting access to a requesting client, for a resource hosted on a device, the resource server (RS). This exchange I had to pause for a while after reading this and ponder whether I agreed with it. I think that my reticence stems from some friction between the most generic abstract definition of "resource" and a more specific one used in the web/HTTP world and, to a lesser extent, the world of URIs and URNs in general. The resources we are discussing here are not always specific named resources, but can also refer to attributes or capabilities mediated by a RS; similarly, we may be creating/modifying named resources as part of the resource access performed by a client in the OAuth model. I don't think it's wise to diverge from the RFC 4949 definition just yet, but am still considering whether adding some additional clarifying text here is worthwhile. Section 3 It's probably worth adding (informative) references for HTTP/2, MQTT, BLE, and QUIC. A fourth building block is the compact CBOR-based secure message "compact CBOR" has the "PIN number" nature and is probably redundant. format COSE [RFC8152], which enables application layer security as an alternative or complement to transport layer security (DTLS [RFC6347] I'm undecided whether it's better to think of this as "application layer security" or "object-level security". or TLS [RFC8446]). COSE is used to secure self-contained tokens such as proof-of-possession (PoP) tokens, which is an extension to the OAuth tokens. The default token format is defined in CBOR web token nit: I think there's a singular/plural mismatch in "is an extension", which currently seems to be talking about the PoP tokens themselves. Section 3.1 Refresh Tokens: Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner). Issuing a refresh token is optional at the nit: I'd suggest "such access tokens" in the parenthetical. A refresh token in OAuth 2.0 is a string representing the authorization granted to the client by the resource owner. The string is usually opaque to the client. The token denotes an Apparently I'd forgotten that this couldn't be binary. Proof of Possession Tokens: An access token may be bound to a cryptographic key, which is then Can refresh tokens not be PoP? The proof-of-possession (PoP) security concept assumes that the AS acts as a trusted third party that binds keys to access tokens. nit: I think we're describing the PoP model used by ace, not the generic PoP concept. Scopes and Permissions: In OAuth 2.0, the client specifies the type of permissions it is seeking to obtain (via the scope parameter) in the access token request. In turn, the AS may use the scope response parameter to inform the client of the scope of the access token issued. As the client could be a constrained device as well, this specification defines the use of CBOR encoding as data format, see Section 5, to request scopes and to be informed what scopes the access token actually authorizes. nit: I think there's a word missing in "the use of CBOR encoding as data format". 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? Section 4 If the description for step (C) is going to refer to the "profile (see step B)", then we need to mention the profile as an example of the Access Information in step (B). The RS verifies that the token is integrity protected by the AS and compares the claims contained in the access token with the resource request. [...] I note that this verification of "integrity protected by the AS" implicitly also includes verification of the source authentication (i.e., signature or keyed MAC in key known only to AS and RS, in the non-introspection case); do we want to make that more explicit in the text? Section 5 Credential Provisioning For IoT, it cannot be assumed that the client and RS are part of a common key infrastructure, so the AS provisions credentials or associated information to allow mutual authentication. These credentials need to be provided to the parties before or during the authentication protocol is executed, and may be re-used for subsequent token requests. nit: either "before or during the execution of the authentication protocol" or "before or during the authentication protocol's execution". And just to double-check that we mean the authentication protocol of provisioning in the last sentence, not the authorization protocol that occurs between the client and RS. OAuth 2.0 requires the use of TLS both to protect the communication between AS and client when requesting an access token; between client and RS when accessing a resource and between AS and RS if introspection is used. In constrained settings TLS is not always feasible, or desirable. Nevertheless it is REQUIRED that the data exchanged with the AS is encrypted, integrity protected and protected against message replay. It is also REQUIRED that the AS and the endpoint communicating with it (client or RS) perform mutual authentication. [...] This seems to leave open the possibility that client/RS interactions are not encrypted, integrity protected, and/or replay protected; is that intentional? (We do require later on that all resource access gets the "usual protections" other than the authz-info endpoint, so this is mostly just an editorial remark.) In OAuth 2.0 the communication with the Token and the Introspection endpoints at the AS is assumed to be via HTTP and may use Uri-query parameters. When profiles of this framework use CoAP instead, this framework REQUIRES the use of the following alternative instead of nit: REQUIRES is not an RFC 2119 keyword (just REQUIRED). Uri-query parameters: The sender (client or RS) encodes the parameters of its request as a CBOR map and submits that map as the payload of the POST request. Profiles that use CBOR encoding of protocol message parameters MUST use the media format 'application/ ace+cbor', unless the protocol message is wrapped in another Content- Format (e.g. object security). [...] Is the bit starting at "Profiles that use CBOR" directly tied to the CBOR-map submission to the AS, or a more general requirement on all protocol flows (that would better be split off in its own paragraph)? Also, some IESG members have not liked the "MUST [...], unless [...]" construction, as it makes the MUST "no longer a MUST". So perhaps we could rephrase this as a positive statement, such as "CBOR-encoded protocol messages that appeare at the outermost encoding layer MUST use the media type "application/ace+cbor or, for CoAP, the corresponding Content-Format's short ID of 19". Section 5.1 Instead of the initial Unauthorized Resource Request message, other discovery methods may be used, or the client may be pre-provisioned with the address of the AS. nit: I suggest "pre-provisioned with an RS-to-AS mapping" so that we don't have the "the AS" construct that implies there is only a single AS. Section 5.1.1 Note: These conditions ensure that RS can handle requests autonomously once access was granted and a secure channel has been established between C and RS. The authz-info endpoint MUST NOT be protected as specified above, in order to allow clients to upload access tokens to RS (cf. Section 5.8.1). I have some editorial suggestions here that I'll put into a pull requeste. Section 5.1.2 It may not be worth having an attempt at a printable version of the cnonce in the comments in Figure 4. Section 5.1.2.1 o A RS sending a "cnonce" parameter in an an AS Request Creation Hints message MUST store information to validate that a given cnonce is fresh. How this is implemented internally is out of scope for this specification. Expiration of client-nonces should be based roughly on the time it would take a client to obtain an access token after receiving the AS Request Creation Hints message. nit: I suggest to add something like "with some allowance for slop". Section 5.2 The grant type is selected depending on the use case. In cases where the client acts on behalf of the resource owner, authorization code grant is recommended. If the client acts on behalf of the resource owner, but does not have any display or very limited interaction possibilities it is recommended to use the device code grant defined in [I-D.ietf-oauth-device-flow]. In cases where the client does not acts autonomously the client credentials grant is recommended. The context seems to suggest that this last sentence was intended as "cases where the client acts autonomously"; is that correct? Section 5.5 well. Non-constrained clients interacting with constrained resource servers can use the specifications in section 3.1 of [RFC6749] and of section 4.2 of [RFC6819]. nit: Section 4.2 of RFC 6819 isn't exactly a "specification" per se; we might want to reword this. Section 5.6 For the AS to be able to issue a token, the client MUST be authenticated and present a valid grant for the scopes requested. Profiles of this framework MUST specify how the AS authenticates the client and how the communication between client and AS is protected. We should probably list what attributes this protection entails -- confidentiality+integrity, of course, and we already mentioned both sides of the mutual authentiation; do we need anything else like replay protection? The default name of this endpoint in an url-path is '/token', however implementations are not required to use this name and can define their own instead. We may get questions about the relationship between this "default" and BCP 190; unfortunately, I haven't had a time to internalize the changes proposed for draft-nottingham-rfc7320bis yet to see whether they would affect us. (To be clear, "leave it as-is for now and see if we get complaints from the experts" is the right thing to do.) Section 5.6.1 The client sends a POST request to the token endpoint at the AS. The profile MUST specify how the communication is protected. The content In the previous section we said that maybe even other transports than coaps or https would be possible; are we limited to those that have POST verbs? Also, a similar comment as above about what attributes the protection entails seems to apply. o The "scope" parameter MAY be encoded as a byte string instead of the string encoding specified in section 3.3 of [RFC6749], in order allow compact encoding of complex scopes. "scope" is a space-separated list (in the string encoding); is 0x20 still the list separator in the binary encoding? o A client MUST be able to use the parameters from [I-D.ietf-ace-oauth-params] in an access token request to the token endpoint and the AS MUST be able to process these additional parameters. [we might get someone complaining that if support for these is mandatory they might as well be in the core document. I don't mind the split, but be forewarned.] Figure 5: Example request for an access token bound to a symmetric key. I wouldn't be surprised is some reviewers asked for more text to clarify that the AS-generated symmetric key is the default, so we don't need any extra parameters to indicate that's what's being requested. I'm a little surprised that OSCORE didn't provide some more scrutable diagnostic notation for the OSCORE CoAP option. To check: h is set, n is 1, k is not set, the (1-byte) partial IV is 0x05, s is 5, and the rest of the option is the kid context? Figure 7 shows a request for a token where a previously communicated proof-of-possession key is only referenced. Note that the client performs a password based authentication in this example by submitting its client_secret (see Section 2.3.1 of [RFC6749]). Note RFC 6749 says about the bare "client_secret" that "[i]ncluding the client credentials in the request-body using the two parameters is NOT RECOMMENDED and SHOULD be limited to clients unable to directly utilize the HTTP Basic authentication scheme (or other password-based HTTP authentication schemes)." I know this is "just an example", so our obligations are somewhat weak, but I still think we should note that this is not recommended by 6749 (but since there is no CoAP analogue of HTTP Basic, it's the only plain-password scheme available). that this example uses the "req_cnf" parameter from [I-D.ietf-ace-oauth-params]. Er, the "req_cnf" parameter is exactly how the previously communicated key is being referenced. So we should not have a separate "Note" that doesn't link back to the point of the example. 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. Section 5.6.2 Note that the AS decides which token type and profile to use when issuing a successful response. It is assumed that the AS has prior Would it be useful to note that this can be shaped by the "req_cnf" contents? token_type: This parameter is OPTIONAL, as opposed to 'required' in [RFC6749]. By default implementations of this framework SHOULD assume that the token_type is "pop". If a specific use case requires another token_type (e.g., "Bearer") to be used then this parameter is REQUIRED. When we are "weakening" the formal requirements of the parent spec like this, we should be careful about what happens when someone is trying to use the ACE stuff but ends up needing to go over HTTPS like traditional OAuth -- do they have to fall back to the OAuth required behavior in that case or are we trying to preempt that as well? Given that we're requiring support for them, I think including the parameters from draft-ietf-ace-oauth-params in Figure 8 (and removing the note above it) would be helpful to the reader. We probably also want to leave some room for future extensions when we talk about it ("summarizes the parameters that may be part of the Access Information" could maybe be read as restrictive, though it's clearly not meant to be). "cnf" : { "COSE_Key" : { "kty" : "Symmetric", "kid" : b64'39Gqlw', "k" : b64'hJtXhkV8FJG+Onbc6mxCcQh' } } } Figure 9: Example AS response with an access token bound to a symmetric key. In light of the related discussion on cwt-proof-of-possession (resulting in the removal of a bunch of text), do we want to say anything about the scope of the 'kid' (that is, which participants are expecting to receive and understand that value)? Section 5.6.3 The error responses for CoAP-based interactions with the AS are equivalent to the ones for HTTP-based interactions as defined in Section 5.2 of [RFC6749], with the following differences: "equivalent [...] with the following differences" is going to get complaints from the IESG. I suggest "generally equivalent". o A response code equivalent to the CoAP code 4.00 (Bad Request) MUST be used for all error responses, except for invalid_client where a response code equivalent to the CoAP code 4.01 (Unauthorized) MAY be used under the same conditions as specified in Section 5.2 of [RFC6749]. 6749 has a case where 401 MUST be used, but I think it does not apply to us (since WWW-Authenticate would have to have been used). I'm not sure whether it makes sense to note that or not, though. Section 5.6.4.3 responses. Furthermore profiles MUST define proof-of-possession methods, if they support proof-of-possession tokens. nit: define the *methods* or the *list* of allowed ones? A profile MUST specify an identifier that MUST be used to uniquely identify itself in the "profile" parameter. The textual representation of the profile identifier is just intended for human readability and MUST NOT be used in parameters and claims. This seems like an opportunity for a registry...just like we have in Section 8.7. I'd suggest mentioning that registry here. Section 5.6.5 Perhaps the title of Figure 12 should include both requests and responses? Section 5.7.1 map with a "token" entry containing either the access token or a reference to the token (e.g., the cti). Further optional parameters [...] The same parameters are required and optional as in Section 2.1 of [RFC7662]. This seems somewhat problematic, in that 7662 is pretty clear that the "token" value is, well, the actual token. So if we want to be able to use "cti" instead, then we need to have some text saying that we're deviating from 7662 and the specification for how "cti" is used there. { "token" : b64'7gj0dXJQ43U', "token_type_hint" : "pop" } Figure 14: Decoded token. nit: I think this is a decoded payload, not a decoded token. Section 5.7.2 cnonce OPTIONAL. A client-nonce previously provided to the AS by the RS via the client. See Section 5.6.4.4. I think this statement is only true after the token in question has been properly validated at the RS. Before that, all we can say is that it is the client-nonce provided to the AS by the client, since there is nothing to enforce that the client actually provided the same value that was generated by the RS. Section 5.7.4 "scope" is showing up with the key 9 a lot; I have mixed feelings about having the CBOR map key value be aliased across different contexts (but it's probably too late to change without disruption anyway). Section 5.8 In order to facilitate offline processing of access tokens, this document uses the "cnf" claim from [I-D.ietf-ace-cwt-proof-of-possession] and specifies the "scope" claim for JWT- and CWT-encoded tokens. [looks like draft-ietf-oauth-token-exchange is going to beat us for the JWT version of "scope": https://www.iana.org/assignments/jwt/jwt.xhtml#claims ] The "scope" claim explicitly encodes the scope of a given access token. This claim follows the same encoding rules as defined in Section 3.3 of [RFC6749], but in addition implementers MAY use byte strings as scope values, to achieve compact encoding of large scope elements. The meaning of a specific scope value is application specific and expected to be known to the RS running that application. I think I commented above about the use of 0x20 as the list separator; whatever we do there should be applied here as well (or the text otherwise consolidated to only need to say it once). Section 5.8.1 The access token, containing authorization information and information about the key used by the client, needs to be transported to the RS so that the RS can authenticate and authorize the client request. nit(?): do we want to talk about the "confirmation method" rather than the "key", out of some sense of remaining generic? This specification RECOMMENDS that an RS stores only one token per proof-of-possession key, meaning that an additional token linked to the same key will overwrite any existing token at the RS. I might consider mentioning that this greatly simplifies implementation, as not only is there not a need for the extra storage, but when a request comes in using a given key, there's no need to resolve which token to use with that request (and whether there would be different access decisions made depending on which token was used), since the key can be used directly for dispatch (e.g., with DTLS raw public key). If the payload sent to the authz-info endpoint does not parse to a token, the RS MUST respond with a response code equivalent to the CoAP code 4.00 (Bad Request). Do we want this to specifically be about "parse to a token" with no need to be a valid token? (What error do we return for a syntactically valid but semantically invalid token?) 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. The RS MAY make an introspection request to validate the token before responding to the POST request to the authz-info endpoint. [...] A RS MAY use introspection on a token received through the authz-info endpoint, e.g. if the token is an opaque reference. Some transport We should probably deduplicate the "MAY use introspection"s. Section 5.8.1.1 I think we whould make an explicit note at the end of the list of claims that we specify processing for, that additional processing is done (in a profile-specific manner?) for other claims in the token. If the access token contains any other claims that the RS cannot process the RS MUST discard the token. If this was an interaction Just to double-check: this is overriding the JWT/CWT default so that all token claims are comprehension-mandatory? It might be worth making this deviation from the core [JC]WT more explicitly a deviation. Section 5.8.2 If an RS receives a request from a client, and the target resource requires authorization, the RS MUST first verify that it has an access token that authorizes this request, and that the client has performed the proof-of-possession for that token. As written, this sounds like it's okay to only do proof-of-possession when posting tokens to the authz-info endpoint and not bind the proof/key to the current request. Is that intended? The response code MUST be 4.01 (Unauthorized) in case the client has not performed the proof-of-possession, or if RS has no valid access token for the client. If RS has an access token for the client but not for the resource that was requested, RS MUST reject the request nit: I suggest "but the token does not authorize access for". Section 5.8.3 o The RS verifies the validity of the token by performing an introspection request as specified in Section 5.7. This requires the RS to have a reliable network connection to the AS and to be able to handle two secure sessions in parallel (C to RS and AS to RS). nit: isn't the second one RS to AS, not AS to RS? 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. Section 5.8.4 The AS provides the client with key material that the RS uses. 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 no Can you walk me through how a symmetric PoP key would be used for mutual authentication (i.e., authentication of RS to client)? It's easy/common to do the PoP the other way, making the client prove it knows the key associated with the token, but the other direction is not always possible, depending on the protocol. o The client knows a default validity period for all tokens it is using. This information could be provisioned to the client when it is registered at the AS, or published by the AS in a way that the client can query. Just to double-check: this validity period is time since issuance? I'm not sure whether this is sufficiently obvious that it goes without saying (but it might be). 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 :( Section 6 There could perhaps be some security considerations relating to discovery of RSes/resources thereon, but since we don't really talk about that much to begin with, it's probably okay to skip the security considerations discussion as well. Both the client and the RS need to have their own respective long-term credentials with the AS; we should talk about protecting those credentials, what is risked/lost if the credentials are compromised, how to recover from compromise, and the general key management lifecycle (per BCP 107). We should probably mention revocation in some fashion (even if only to say that it's unlikely in practice) -- right now we just have one passing mention as an optional responsibility of the AS, in Appendix B. A large range of threats can be mitigated by protecting the contents of the access token by using a digital signature or a keyed message digest (MAC) or an Authenticated Encryption with Associated Data I won't be surprised if someone asks for examples of that "large range of threats", so be prepared to answer... (AEAD) algorithm. Consequently, the token integrity protection MUST be applied to prevent the token from being modified, particularly since it contains a reference to the symmetric key or the asymmetric key. [...] nit: "key used for proof of possession" (though my previous remark about limiting to keys may apply as well). key. If the access token contains the symmetric key, this symmetric key MUST be encrypted by the authorization server so that only the resource server can decrypt it. Note that using an AEAD algorithm is preferable over using a MAC unless the message needs to be publicly readable. nit(?) is "the message" here still "the token" like it was for the rest of the paragraph? If the token is intended for multiple recipients (i.e. an audience that is a group), integrity protection of the token with a symmetric key is not sufficient, since any of the recipients could modify the token undetected by the other recipients. Therefore a token with a I can't decide whether we should clarify that this is "integrity protection of the token with a symmetric key shared by the AS and RS" (as opposed to a symmetric PoP key). It is important for the authorization server to include the identity of the intended recipient (the audience), typically a single resource server (or a list of resource servers), in the token. Using a single shared secret with multiple resource servers to simplify key management is NOT RECOMMENDED since the benefit from using the proof- of-possession concept is significantly reduced. I think we should word this more clearly with respect to "single shared secret" -- is this the credential used by the RS to authenticate itself to the client? I'm not even sure if this text is intended to be describing a workflow using symmetric or asymmetric keys. Profiles MUST specify how confidentiality protection is provided, and additional protection can be applied by encrypting the token, for example encryption of CWTs is specified in Section 5.1 of [RFC8392]. We should probably be a little more precise about what the additional protection is -- it's not exactly protection for the PoP key, since that's transmitted alongside the token in the authorization info (i.e., outside the token contents), but it does provide protection when the token is subsequently used. also, nit: comma splice Section 6.1 I think we should have a little bit more discussion about what attacks are possible even when a client hard-codes a list of trustworthy ASes, e.g., when a device in one AS's purview is compromised and tries to get the client to use a different (possibly also compromised, or maybe just buggy) AS than the one that's supposed to be responsible for the device in question. In short, yes, spoofing is only possible within that set of trusted ASes, but spoofing can still cause problems. Are there any AS parameters other than URI that might be useful for an out-of-band-configured list of valid values? Section 6.2 client MUST be able to determine whether an AS has the authority to issue access tokens for a certain RS. This can be done through pre-configured lists, or through an online lookup mechanism that in turn also must be secured. nit: I suggest "for example" to preempt anyone complaining about this being needlessly prescriptive. Section 6.4 There may be use cases were different profiles of this framework are combined. For example, an MQTT-TLS profile is used between the client and the RS in combination with a CoAP-DTLS profile for interactions between the client and the AS. Ideally, profiles should be designed in a way that the security of system should not depend on the specific security mechanisms used in individual protocol interactions. I think the IESG is going to pounce on this "ideally" -- what can we do to ensure this is the case and/or warn when it isn't? Can we just say that profiles MUST NOT make assume that the same profile is used for the different types of interactions? Section 6.6 inadvertently communicating with the wrong RS. The correct values for "audience" can either be provisioned to the client as part of its configuration, or provided by the RS as part of the "AS Request Creation Hints" Section 5.1.2 or dynamically looked up by the client I'm not sure that the AS Request Creation Hints are a big help here, since they are untrusted input and it seems like bogus hints could cause the client to obtain a token for a "wrong" RS. Section 6.7 First an attacker could perform a denial of service attack against the introspection endpoint at the AS in order to prevent validation of access tokens. To mitigate this attack, an RS that is configured to use introspection MUST NOT allow access based on a token for which it couldn't reach the introspection endpoint. I'm not sure that "mitigate" is quite right, as the attack (denial of service) succeeds! Probably we want something like "To maintain the security of the system" instead. nit: comma after First (and Second, in the next paragraph). an introspection call. RS can mitigate such attacks by implementing a rate limit on how many introspection requests they perform in a given time interval and rejecting incoming requests to authz-info for a certain amount of time, when that rate limit has been reached. I think the rate limit can be partially per client IP address (but a global limit will probably still be necessary, too). Section 7 Introspection could potentially output a lot of information from a given token; some of the claims that might be found in a JWT or CWT can have privacy considerations. Though for constrained usage, it is likely that the claims set will be pretty stripped down, so that might be more of an exceptional case. (When signed-only CWT/JWT are used, similar considerations apply to the same claims, which is mostly covered already under the "if access tokens are only integrity protected" part. information as possible in an unencrypted response. Means of encrypting communication between C and RS already exist, more detailed information may be included with an error response to provide C with sufficient information to react on that particular error. nit: I think the sentence is supposed to start with "When" or "If". Section 8.X I might consider adding a sentence to the toplevel Section 8 that notes "this document creates several registries with a registration policy of Expert Review; guidelines to the experts are given in Section 8.16" so that we have a heads-up that these guidelines exist while we're reading through the rest of the sections. Though, perhaps most people aren't reading it straight through like I am... Section 8.3 Name The OAuth Error Code name, refers to the name in Section 5.2. of [RFC6749], e.g., "invalid_request". We should refer to the OAuth registry as the authority on names, not the immutable RFC. (Similarly for the other mappings registries; I won't repeat it each time, though for the later ones we're already doing the right thing.) Section 8.5 We should check what capitalization we want for the token type name, as it's used all-lowercase elsewhere in the document but appears here as "PoP". Section 8.9 Note that the mappings of parameters corresponding to claim names intentionally coincide with the CWT claim name mappings from [RFC8392]. I tried to spot-check this but couldn't find any that match up; am I looking in the wrong place? Section 8.11 Reference This contains a pointer to the public specification of the grant type abbreviation, if one exists. Do we have some copy/paste issue with the "grant type abbreviation" going on here (and elsewhere)? Section 8.12 "scope" is already registered by draft-ietf-oauth-token-exchange (for the same meaning). "profile" is already registered by OIDC Core, for a "profile page URL". So we will probably have to change to (e.g.) "ace_profile" everywhere. :( :( :( Section 8.13 The entry for "scope" should maybe also point to the oauth draft that defined it for JWT. (We can't get "profile" here, either.) Section 8.14 I think for the media type we still want to use the IESG as the contact. Section 8.16 o Specifications are required for the standards track range of point assignment. Specifications should exist for specification required ranges, but early assignment before a specification is available is considered to be permissible. Specifications are This seems to be attempting to re-explain things already in RFC 8126, but introduces some divergence along the way (which is bad). I do note that RFC 7120 covers early allocations, but specifically excludes doing so from Expert Review registries. I think technically that would exclude using the early allocation procedure even for the "standards action" or "specification required" ranges, though the experts would still have leeway to make allocations under essentially the same circumstances. document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size. seems to duplicate "number of code points of that length that are left". Section 10.1 We may get some debate about whether IANA registries are properly Normative of Informative references, but we can wait for that to happen -- no need to do anything now. Section 10.2 If we're using RFC 4949 for terminology definitions, I think that makes it a normative reference. If we REQUIRE CBOR when used with CoAP, that also feels like a normative reference. I also think 7519 needs to be normative, since we mandate some of its processing rules. Appendix A Proof-of-Possession: This framework makes use of proof-of-possession tokens, using the "cnf" claim [I-D.ietf-ace-cwt-proof-of-possession]. A semantically and syntactically identical request and response parameter is defined for the token endpoint, to allow requesting and stating confirmation keys. This aims at making token theft nit: the wording here is a little weird in terms of specifying what is identical. I'm not sure I have a great suggestion for improvement, though; what I'm coming up with is a lot more words. Appendix C Skimming through the main text, a couple more items we may want to list here: - optional procedures for client discovery of RS/resources/permissions (Section 4) - optionally define new grant types (Section 5.2) - optional use of client certificate as client credentials (Section 5.3) o Specify the security protocol the client and RS must use to protect their communication (e.g., OSCORE or DTLS over CoAP). IIRC both DTLS over CoAP and CoAP over DTLS are defined; do we need specifically one of them? Appendix D o The symmetric key shared between client or RS and AS (if any). I suggest splitting this into separate bullet points for client/AS and RS/AS, to avoid chance of confusion. Appendix E.1 the Access Information contains the public key of the RS. For communication security this example uses DTLS RawPublicKey between the client and the RS. The issued token will have a short validity time, i.e., "exp" close to "iat", to protect the RS from replay attacks. The token includes the claim such as "scope" with With DTLS RPK I don't think replay is a huge concern; the short lifetime seems more of a bound on how soon the authorization might be invalidated. In Figure 18 and the other example request payloads, let's use a higher-entropy client_secret than "qwerty" (or "ytrewq"), so as to not give anyone bad ideas. I'm not 100% sure, but the << "access_token" : b64'SlAV32hkKG ...', >> snippet doesn't seem to decode to the start of the expanded token contents shown in Figure 19. Do we want to update the times in the tokens/etc. to be closer to "now"? Messages C and F are shown in Figure 20 - Figure 21. C: The client then sends the PoP access token to the authz-info endpoint at the RS. This is a plain CoAP request, i.e., no transport or application layer security is used between client and RS since the token is integrity protected between the AS and RS. The RS verifies that the PoP access token was created by a known and trusted AS, is valid, and has been issued to the client. The How can the RS check that the token "has been issued to the client"? (How does it identify the client at this point to do so?) The client sends the CoAP request GET to /temperature on RS over DTLS. The RS verifies that the request is authorized, based on previously established security context. F: The RS responds with a resource representation over DTLS. nit: we should probably be consistent about whether we mention the CoAP layer in the request+response. Appendix E.2 Note: In this example the client does not know the exact door it will be used to access since the token request is not send at the time of access. So the scope and audience parameters are set quite wide to start with and new values different form the original once can be returned from introspection later on. Maybe add "and tailored to the RS performing introspection"? A: The client sends the request using POST to the token endpoint at AS. The request contains the Audience parameter set to "PACS1337" (PACS, Physical Access System), a value the that the online door in question identifies itself with. The AS generates Didn't we just say that the client doesn't know the exact door it is going to be talking to? an access token as an opaque string, which it can match to the specific client, a targeted audience and a symmetric key. The So we're handing out a symmetric PoP key for a long-lived token that may be used at multiple resources? Isn't that the example we gave earlier that lets RSes impersonate the client to each other? In Figure 22, should we show the communications security layer between client and AS? The introspection response in Figure 25 only has a 'kid' element for the confirmation claim (that corresponds to a symmetric key); how is the RS supposed to know/learn the corresponding key so as to be able to verify the client's proof of possession? Thanks! -Ben _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace