Hello, I would like to add my two cents to this as the MQTT-TLS profile does use HTTP/JSON for client-AS and rs-AS communication as similar already was supported in MQTT implementations between an MQTT broker and external servers (e.g., via auth plug-ins).
For points like 13: Making CBOR mandatory would break how it is implemented for MQTT-TLS, which implements the AS creation hints as a User Property inside an MQTT message. "The User Property is a UTF-8 string pair, composed of a name and a value. The name of the User Property MUST be set to "ace_as_hint". The value of the user property is a UTF-8 encoded JSON string containing the mandatory "AS" parameter, and the optional parameters "audience", "kid", "cnonce", and "scope" as defined in Section 5.1.2 of the ACE framework" Kind regards, --Cigdem On Thu, Mar 25, 2021 at 1:53 PM Francesca Palombini <francesca.palombini= [email protected]> wrote: > Ludwig, > > Thank you for the quick reply, and for the useful background information. > > As I said, I think this document is important and should move forward > asap, and it can do so without changing the main assumptions, with some > additional clarifications in the text about CBOR vs "other" when HTTP is > used (which in my opinions are necessary - see points 1, 8, 10, 11, 13, 15, > 17, 22, 23, 26, 28). > > What I wanted to highlight is that it would simplify the document a lot to > just remove this flexibility, for which I don't understand the motivation, > and say "CBOR is mandatory" even when HTTP is used. The flexibility could > be added in a future document if needed. However, I understand that there > is history in the working group, and I will step back and remove my DISCUSS > if I am in the rough. Note however that in terms of work on the document I > suspect that keeping this flexibility will require more work, not less. > > Looking forward to discussing this with Ben during the telechat. > Francesca > > On 25/03/2021, 08:50, "iesg on behalf of Seitz Ludwig" < > [email protected] on behalf of [email protected]> wrote: > > Hello Francesca, > > Thank you for your review. I will address your detailed comments > separately, with regards to your DISCUSS: > > The option to allow both HTTP and JSON for any leg of the > communication (client-AS, rs-AS, client-rs) was the result of long > discussions in the WG. If I recall correctly the intent was to allow legacy > OAuth 2.0 equipment (i.e. not supporting ACE) to be used in ACE > interactions on those legs of the communication where no constrained > devices are involved. > I am reluctant to reopen these discussions at this point in time, and > I suspect doing the necessary analysis to provide in-depth considerations > on the choices between HTTP/CoAP and JSON/CBOR will significantly delay the > progress of this document. > > @ace-chairs: What is your suggestion on how to best handle this? > (Please note that I am unable to commit significant amounts of time to > this work in the foreseeable future) > > Regards, > > Ludwig > > > > -----Original Message----- > > From: Ace <[email protected]> On Behalf Of Francesca Palombini > via > > Datatracker > > Sent: den 24 mars 2021 15:50 > > To: The IESG <[email protected]> > > Cc: [email protected]; [email protected]; draft-ietf-ace-oauth- > > [email protected]; [email protected] > > Subject: [EXTERNAL] [Ace] Francesca Palombini's Discuss on > draft-ietf-ace- > > oauth-authz-38: (with DISCUSS and COMMENT) > > > > Francesca Palombini has entered the following ballot position for > > draft-ietf-ace-oauth-authz-38: Discuss > > > > When responding, please keep the subject line intact and reply to > all email > > addresses included in the To and CC lines. (Feel free to cut this > introductory > > paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ > > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > Thank you for this document. I think this is an important document > which > > should move forward, but I would like to discuss some points before > it does > > so. These might result in simple clarifications, or might require > more > > discussion, but I do hope they help improve the document. > > > > General comments: > > > > I found confusing to understand how optional or mandatory is the use > of > > CBOR for profiles of this specification compared to the transport > used. I > > understand the need for flexibility, but maybe it should be > clarified the > > implication of using CoAP (is CBOR mandatory then?) vs HTTP (is CBOR > always > > permitted? How is the encoding in that case? Is the same media type > > application/ace+cbor used in that case?). Note also that while > requests > > include the content type to use, both in case HTTP or CoAP+CBOR are > used, > > the response don't seem to include this information. > > > > I would like it to be clarified what requirements (or even just > > recommendations) are there to use CoAP vs HTTP for different legs of > the > > exchange - not necessarily remove the flexibility but to clarify for > > implementers what can be done and what would be the reasoning to do > > that: for example if both endpoints support HTTP with the AS, most > likely you > > can have HTTP between C and RS, so does it really make sense to run > this > > instead of OAuth 2.0? Right now all is permitted, but does it all > make sense? I > > feel like this type of considerations are missing. As a note - I am > not sure > > what allowing a different encoding than CBOR for any leg of the > exchange > > adds to the specification - it makes things more confusing, and if > needed it > > could be specified in another document. > > > > While going through and thinking about encodings (assuming we keep > the > > doc as is with regards to allowing more than just CBOR), I wondered > if it > > would be better to define a new media type to use when the ACE > > framework is used with HTTP, to differentiate from OAuth 2.0, since > some of > > the endpoints used are the same (/token and /introspect at the AS). > I am > > interested to hear more from my co-AD as well if this would be an OK > use of > > a new media type - I am thinking of the case where AS is supporting > both > > OAuth 2.0 and the Ace framework - or if it is unnecessary, since the > > encodings are the same, and the parameters are registered in OAuth > 2.0 > > registry. > > > > More detailed comments below. > > Francesca > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > > ---------------------------------------------------------------------- > > > > Detailed comments: > > > > 1. ----- > > > > sufficiently compact. CBOR is a binary encoding designed for > small > > code and message size, which may be used for encoding of self > > contained tokens, and also for encoding payloads transferred in > > protocol messages. > > > > FP: "may be used" make it seem as if CBOR is always optional (even > when > > CoAP is used). See points 11. and 13. for examples of text that seem > to imply > > that CBOR is mandatory in some cases. > > > > 2. ----- > > > > 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 > > > > FP: token validity - it is not clear what it means for a token to > become invalid > > (vs expiring). As this is the first time it is mentioned, it should > be explained > > here or referenced. > > > > 3. ----- > > > > An asymmetric key pair is generated on the token's recipient > > and the public key is sent to the AS (if it does not already > > > > inside the token and sent back to the requesting party. > The > > consumer of the token can identify the public key from the > > > > FP: "token's recipient" and "consumer of the token" - why not talk > about > > client and resource server here? It would fit better with the > terminology > > used in the rest of the document. > > > > 4. ----- > > > > This framework RECOMMENDS the use of CoAP as replacement for HTTP > > for > > use in constrained environments. For communication security this > > > > FP: This was already stated in the introduction in the following > sentence: > > > > of processing capabilities, available memory, etc. For web > > applications on constrained nodes, this specification RECOMMENDS > the > > use of the Constrained Application Protocol (CoAP) [RFC7252] as > > replacement for HTTP. > > > > Not sure repeating is useful. > > > > 5. ----- > > > > OAuth 2.0 (such as [RFC7521] and [RFC8628]). What grant types > works > > best depends on the usage scenario and [RFC7744] describes many > > different IoT use cases but there are two preferred grant types, > > namely the Authorization Code Grant (described in Section 4.1 of > > > > FP: nit: s/works/work . I think "preferred" is probably not the > right term > > here, and should be rephrased or clarified - preferred respect to? > > > > 6. ----- > > > > In addition to the response parameters defined by OAuth 2.0 and > > the PoP access token extension, this framework defines > parameters > > that can be used to inform the client about capabilities of the > > RS, e.g. the profiles the RS supports. More information about > > > > FP: I believe this is a leftover from a previous version of the > document, but > > should be "profile" and not "profiles" as the AS is only allowed to > > communicate one profile to the client and RS - see for example the > following > > sentences: > > > > The Client and the RS mutually authenticate using the security > > protocol specified in the profile (see step B) and the keys > > > > The AS informs the client of the selected profile using the > > "ace_profile" parameter in the token response. > > > > 7. ----- > > > > (1) the client sends the access token containing, or > > referencing, the authorization information to the RS, that > may > > be used for subsequent resource requests by the client, and > > > > FP: s/may/will > > > > 8. ----- > > > > While the structure and encoding of the access token varies > > throughout deployments, a standardized format has been defined > > with the JSON Web Token (JWT) [RFC7519] where claims are > encoded > > as a JSON object. In [RFC8392], an equivalent format using > CBOR > > encoding (CWT) has been defined. > > > > FP: Would it make sense to RECOMMEND the use of JWT when HTTP is > used? > > Or is CWT always RECOMMENDED? > > > > 9. ----- > > > > parameters. When profiles of this framework use CoAP instead, it > is > > REQUIRED to use of the following alternative instead of 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. > > > > FP: I think it should be better defined (or at least hinted in this > paragraph) > > the mapping between the CBOR encoded parameters and the Uri-query > > parameters: > > are they all encoded as CBOR text strings? > > > > 10. ----- > > > > Applications that use this media type: The type is used by > > authorization servers, clients and resource servers that support > the > > ACE framework as specified in [this document]. > > > > FP: I suggest adding "that support the ACE framework with CBOR > encoding, > > as specified ..." > > > > 11. ----- > > > > The OAuth 2.0 AS uses a JSON structure in the payload of its > > responses both to client and RS. If CoAP is used, it is REQUIRED > to > > use CBOR [RFC8949] instead of JSON. Depending on the profile, the > > CBOR payload MAY be enclosed in a non-CBOR cryptographic wrapper. > > > > FP: This sentence seems to add a requirement (when CoAP is used, then > > CBOR must be used) only for communication from AS to C or RS. I > could not > > find in the rest of the specification the same type of requirement > for the > > other legs of communication (C to AS, RS to AS, C to RS). Please let > me know > > if I missed it. > > > > 12. ----- > > > > the AS authorization is not in scope for this document. C may, > e.g., > > ask it's owner if this AS is authorized for this RS. C may also > use > > a mechanism that addresses both problems at once. > > > > FP: nit - s/it's/its . Also "C may also use ... at once" such as? I > think it would be > > good to give an example here. > > > > 13. ----- > > > > valid access token. The AS Request Creation Hints message is a > CBOR > > map, with an OPTIONAL element "AS" specifying an absolute URI (see > > > > FP: another case where CBOR seem mandatory.. Is this the case, even > if > > HTTP or other protocol is used? > > > > 14. ----- > > > > MUST discard the access token. If this was an interaction with > > the authz-info endpoint the RS MUST also respond with an error > > message using a response code equivalent to the CoAP code 4.01 > > (Unauthorized). > > > > FP: This seems to imply that another endpoint could be used to > receive an > > access token. Is that the case, and if so where is this defined? > > > > 15. ----- > > > > Section 5.8: > > > > If HTTPS is used, JSON or CBOR payloads may be supported. If JSON > > payloads are used, the semantics of Section 4 of the OAuth 2.0 > > specification MUST be followed (with additions as described > below). > > > > FP: I suggest to point to the specific subsection in OAuth - namely > 4.1.3 and > > 4.1.4 > > > > 16. ----- > > > > If CBOR is used then these parameters MUST be provided as a CBOR > map. > > > > FP: s/as/in . I suggest to reference Figure 12. > > > > 17. ----- > > > > the HTTP request entity-body, as defined in section 3.2 of > [RFC6749]. > > > > FP: Section 3.2 of OAuth 2.0 specifies: > > > > The endpoint URI MAY include an > "application/x-www-form-urlencoded" > > formatted (per Appendix B) query component ([RFC3986] Section > 3.4), > > which MUST be retained when adding additional query parameters. > The > > endpoint URI MUST NOT include a fragment component. > > > > which explicitly specifies that the parameters are transported as > query > > components. I either suggest to change this reference to Appendix B > of > > RFC6749. > > > > 18. ----- > > > > "x" : b64'usWxHK2PmfnHKwXPS54m0kTcGJ90UiglWiGahtagnv8' > > > > FP: noted here since this is the first time it appears, but same > comment for > > the rest of the document. I think it would make more sense to show > > examples where CBOR byte strings are used instead of Base64. > > > > 19. ----- > > > > Figure 8 summarizes the parameters that can currently be part of > the > > Access Information. Future extensions may define additional > > parameters. > > > > FP: This is useful! Why not having the same type of figure listing > all > > acceptable parameters for the request (section 5.8.1)? > > > > 20. ----- > > > > Header: Created (Code=2.01) > > Content-Format: "application/ace+cbor" > > Payload: > > { > > "access_token" : b64'SlAV32hkKG ... > > (remainder of CWT omitted for brevity; > > CWT contains COSE_Key in the "cnf" claim)', > > "ace_profile" : "coap_dtls", > > "expires_in" : "3600", > > "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. > > > > FP: Section 3.1 states: > > > > Symmetric PoP key: > > The AS generates a random symmetric PoP key. The key is > either > > stored to be returned on introspection calls or encrypted > and > > included in the token. The PoP key is also encrypted for > the > > token recipient and sent to the recipient together with the > > token. > > > > But in the example the key is not encrypted. > > > > 21. ----- > > > > o When using CBOR the raw payload before being processed by the > > communication security protocol MUST be encoded as a CBOR map. > > > > FP: I don't understand "before being processed by the communication > > security protocol" > > > > 22. ----- > > > > o The Content-Format (for CoAP-based interactions) or media type > > (for HTTP-based interactions) "application/ace+cbor" MUST be > used > > for the error response. > > > > FP: Does this mean that CBOR is always used for errors? However in > the > > same > > section: > > > > o The parameters "error", "error_description" and "error_uri" > MUST > > be abbreviated using the codes specified in Figure 12, when a > CBOR > > encoding is used. > > > > "when a CBOR encoding is used" so not always? > > > > 23. ----- > > > > Sections 5.8.2, 5.8.3, 5.9.1, 5.9.2, 5.9.3, 5.10.1 > > > > FP: I found useful that Section 5.8.1 spelled out the encoding when > HTTP is > > used (See sentence below). I think it would be as useful to have the > same > > type of phrasing in these and following sections (wherever it is > missing now). > > I think in general it is very clear in the document what format the > message > > has when CBOR is used, and it seems that CBOR can be used with HTTP > > according to this specification (but not sure it is actually > recommended, what > > are the pros and cons). In some sections (5.8.2, 5.8.3, etc) it is > left to implicit > > references to OAuth 2.0 for the implementers to figure out what the > > encoding is (and what media type is used), although modifications > are added > > to it. > > > > When HTTP is used as a transport then the client makes a request > to > > the token endpoint by sending the parameters using the > "application/ > > x-www-form-urlencoded" format with a character encoding of UTF-8 > in > > the HTTP request entity-body, as defined in section 3.2 of > [RFC6749]. > > > > 24. ----- > > > > including the error code "unsupported_pop_key" defined in > > Figure 10. > > > > including the error code "incompatible_ace_profiles" defined in > > Figure 10. > > > > FP: nit - these error codes are not "defined" in figure 10. > > > > 25. ----- > > > > In this framework the "pop" value for the "token_type" parameter > is > > the default. The AS may, however, provide a different value. > > > > FP: I would change the sentence to: > > > > In this framework the "pop" value for the "token_type" parameter > is > > the default. The AS may, however, provide a different value from > those > > registered in [IANA registry]. > > > > 26. ----- > > > > Clients that want the AS to provide them with the "ace_profile" > > parameter in the access token response can indicate that by > sending a > > ace_profile parameter with a null value (for CBOR-based > interactions) > > or an empty string (for JSON based interactions) in the access > token > > request. > > > > Hints Section 5.3. The parameter is encoded as a byte string > for > > CBOR-based interactions, and as a string (Base64 encoded binary) > for > > JSON-based interactions. > > > > FP: OAuth 2.0 section 4.1.3 says that JSON is not used, the > parameters are > > encoded using "application/x-www-form-urlencoded" > > format in the request entity-body. > > > > 27. ----- > > > > The figures of this section uses CBOR diagnostic notation without > the > > > > FP: Nit - s/use > > > > 28. ----- > > > > A client using this method MUST make a POST request to the > authz-info > > endpoint at the RS with the access token in the payload. The RS > > > > FP: The formatting of the request is unclear - could you clarify > that it depends > > on the access token used, and the media type (or content format) > needs to > > reflect that? I.e. if CWT is used, the media type MUST be > application/cwt. > > > > 29. ----- > > > > o If token or claim verification fails, the RS MUST discard the > > token and, if this was an interaction with authz-info, return > an > > error message with a response code equivalent to the CoAP code > > > > FP: Same comment as before, "if this was an interaction with > authz-info" - > > the alternative needs to be clarified. > > > > 30. ----- > > > > Errors may happen during this initial processing stage: > > > > o If token or claim verification fails, the RS MUST discard the > > token and, if this was an interaction with authz-info, return > an > > error message with a response code equivalent to the CoAP code > > 4.01 (Unauthorized). > > > > ... > > > > Next, the RS MUST verify claims, if present, contained in the > access > > token. Errors are returned when claim checks fail, in the order > of > > priority of this list: > > > > FP: It seems weird to read first about errors due to claim > verification, and > > then "Next" discuss claim verification - unless this is two > different claim > > verifications, in which case I think this needs to be clarified. > Also in each > > claim: > > > > the RS MUST discard the token. If this was an interaction with > > authz-info, the RS MUST also respond with a response code > > equivalent to the CoAP code 4.01 (Unauthorized). > > > > Seems like a repeat of the sentence above. > > > > 31. ----- > > > > on the authz-info endpoint and on it's children (if any). > > > > FP: nit - s/it's/its > > > > 32. ----- > > > > The POST method SHOULD NOT be allowed on children of the > authz-info > > endpoint. > > > > FP: What children? They do not seem to be defined, so I do not > understand > > this sentence. > > > > 33. ----- > > > > + When creating the token, the AS MUST add a 'cti' claim ( > or > > 'jti' for JWTs) to the access token. The value of this > > > > FP: Since the use of CWT and JWT are only recommended, it might be > good > > to rephrase this as to allow for other access token's encodings too. > > > > 34. ----- > > > > + When creating the token, the AS MUST add a 'cti' claim ( > or > > 'jti' for JWTs) to the access token. The value of this > > claim MUST be created as the binary representation of the > > concatenation of the identifier of the RS with a sequence > > number counting the tokens containing an 'exi' claim, > issued > > by this AS for the RS. > > > > + The RS MUST store the highest sequence number of an > expired > > token containing the "exi" claim that it has seen, and > treat > > tokens with lower sequence numbers as expired. > > > > FP: A question rather than a comment - I am not sure I understand > this. An > > "exi" value might be higher for a different token (with a lower > sequence > > number), so how does the counter of the tokens help? Wouldn't that > make > > the RS discard a valid token just because it has a lower sequence > number? > > > > 35. ----- > > > > RS. Therefore, C must not communicate with an AS if it cannot > > determine that this AS has the authority to issue access tokens > for > > this RS. Otherwise, a compromised RS may use this to perform a > > > > FP: How is C supposed to determine that? Doesn't this sentence make > the > > whole AS Creation Hints response useless - either the client already > knows, > > or it doesn't and it must not communicate with it regardless of RS > says? > > > > 36. ----- > > > > compromised. In order to prevent this, an RS may use the > nonce-based > > mechanism defined in Section 5.3 to ensure freshness of an Access > > > > FP: please mention "cnonce" to make it easier to find. > > > > 37. ----- > > > > 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. The security of a > > profile MUST NOT depend on the assumption that the profile is used > > for all the different types of interactions in this framework. > > > > FP: This seems strange - maybe I just don't understand how this is > supposed > > to work, but each profile defines exactly at least C - RS > communication and > > security, if several are combined, it seems that at least the C-RS > would > > conflict. > > > > > > > > _______________________________________________ > > Ace mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ace > > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace >
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
