Re: [Ace] [EXTERNAL] Francesca Palombini's Discuss on draft-ietf-ace-oauth-authz-38: (with DISCUSS and COMMENT)

[Francesca Palombini <[e-mail]>]

Hi Ludwig, authors,

Thank you for all the work on the document.

I have checked all my comments (including those that you have addressed in v-39 and not reported below), and I am good with almost all of them.

Considering the clarifications added as a response to my comments regarding CoAP using CBOR encoding, and HTTP using the encoding from OAuth 2.0, I believe the document is now in good shape and not confusing anymore. I understand that when CoAP is used, CBOR MUST be used; when HTTP is used, semantics and encodings of OAuth 2.0 MUST be used. Any other encodings/transport protocol would have to be defined by a different specification.

Regarding my request for clarification on mixing different protocols (HTTP/CoAP) on different legs of the exchange, I understand that it is not in scope of this document, and it would rather be up to the profile defining such a mix to motivate and explain the use case, so I am fine with it.

Your clarifications on the use of HTTP also addresses my last DISCUSS point - a new media type is not required, as the framework now effectively reuses OAuth 2.0 encodings. Any other specification (such as MQTT) which aims to use the JSON equivalent of what defined here for CBOR instead of the OAuth encoding will define and register their own media type.

I hope we can discuss the leftover comments (especially the last point about using several profiles together) at the interim tomorrow. However, these are non-blocking points, so I will go ahead and remove my DISCUSS now.

Thanks again,
Francesca

>Hello Francesca,
>
>Thank you for your review, sorry for the long response time.
>
>Version -39 addresses some of your comments
>https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-39
>
>I have replies on the remaining comment as follows below (prefixed with 'LS:')
>
>Regards,
>
>Ludwig
>
>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.
>
>LS: This is a lower-case "may", so it does not have a normative meaning.
>There are indeed cases where CBOR is mandatory (e.g. when CoAP is used).
>

FP: Lower case "may" only makes it so that the corresponding text is not "required for interoperation or to limit behavior which has potential for causing harm" (to quote BCP 14). Even without its BCP 14 normative meaning, the text hinted that CBOR is optional IMO, which is misleading. I would suggest the following:

OLD:
   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.

NEW:
   sufficiently compact.  CBOR is a binary encoding designed for small
   code and message size. CBOR is used when CoAP is used for encoding of self
   contained tokens, and also for encoding payloads transferred in
   protocol messages.

This should go with the direction you point out below for CoAP implies CBOR, HTTP implies whatever OAuth 2.0 defined.

>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?
>
>LS: I'd rather avoid making general recommendations here, I believe this is best handled in the profiles.
>

FP: Ok.

>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?
>
>LS: The encoding depends on the type of the parameter and is described for each parameter individually

FP: I think it makes sense here to state that this document describes the CBOR encoding for the existing parameters, and that if a document needs any other parameters (defined in OAuth by a future document) then the encoding for Ace needs to be specified by that document as well. This is just to clarify that you can't just use OAuth parameters with CoAP.

>
>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.
>
>LS: Clarified in other parts of the document that when CoAP is used CBOR MUST be used

FP: Thank you.

>
>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?
>
>LS: The intent is to leave the possibility open for profiles to define other
>means of access token transfer, such as e.g. the DTLS profile does in the handshake.

FP: Ok, and at this point in the text I had missed the paragraph in section 5.10.1 that states just that.

>
>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.
>
>LS: CBOR diagnostic notation allows the use of Base64 encoding, what other encoding are you suggesting?

FP: Just sending hexadecimals CBOR byte strings instead of Base64 encoded strings. So for example in this case, replace the above with:

         "x" : h'BAC5B11CAD8F99F9C72B05CF4B9E26D244DC189F745228255A219A86D6A09EFF'

>
>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)?
>
>LS: Because those paramters depend on the grant type, and with all the existing OAuth 2.0 grant types this list would become very long and include a lot of parameters that are not very useful for ACE-OAuth. Note that IANA has a very nice listing here: https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters

FP: And the fact that there are a lot of parameters that would not be very useful for Ace is exactly why I think such a list (containing only the parameters that *are* expected to be used with Ace) would be helpful. But ok to skip if you don't think so.

>
>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.
>
>LS: Bad phrasing, it is assumed that the communication between client and AS is encrypted. I rephrased 3.1. to clarify
>

FP: Thank you, looks good.

>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"
>
>LS: Bad phrasing, fixed.

FP: Thanks, looks good.

>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?
>
>LS: Exactly, in HTTP-based interactions, the error codes are sent as specified in RFC 6749.
>

FP: Looks good now.

>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].
>
>LS: You are right, there seems to be inconsistence or at least some vagueness as to the mix-and-match options for CoAP/HTTP  and
>CBOR/JSON. Having reconsidered this item I have the following conclusions:
>1. The CoAP interactions now require to use CBOR, as it makes no sense using
>   JSON with CoAP
>2. The HTTP interactions do not need to support CBOR, I have rewritten the draft to require the use of whatever format OAuth 2.0 requires, with the new parameters added.
>3. For the interaction with the authz-info endpoint, the payload of the request
>is simply the raw access token both for CoAP and HTTP. Here no changes are required.
>

FP: Thanks, this makes sense, and in my opinion does clarify what encodings are allowed or required when HTTP or CoAP are used. 

>
>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.
>
>LS: See explanation for issue 14.

FP: Ok, thanks.

>
>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.
>
>
>
>LS: The first bullet was indeed falsely including "claim verification"
>which is repeated later, fixed that. Also the first step claims verification 
>was indeed a repeat of the verification required before, that is also remedied.

FP: Good, thanks.

>
>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.
>
>LS: RESTful resources may have child resources, so there could be /authz-info/token1345 and so on. These should not be POST-able.

FP: Ok, my point is that such child resources or their meaning and functionalities is not defined in this document, hence it seems strange to add a requirement on them.

>
>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.
>
>LS: Rephrased to clarify that this mechanism only works with CWTs and JWTs

FP: Thanks.

>
>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?
>
>LS: This is indeed a limitation of this approach, but the underlying assumption
>is that tokens for the same RS would typically have the same expiration time,
>and therefore the chances of throwing away a valid token would be slim.
>The only alternative would be to store all identifiers of expired tokens,
>which would create a problem with unbounded memory usage growth.
>I added a note explaining this issue.
>

FP: Thanks, that helps.

>
>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?
>
>LS: You are right, the way this is phrased the AS Creation Hints would be
>useless.  The whole DoS scenario here also seems unlikely since it
>requires a large number of clients getting AS Creation Hints from the same compromised RS in a very short same timeframe, in such a case the attacker could more easily mount a DoS against the AS from the compromised RS. I will remove this paragraph.
>

FP: Sounds good, thank you.

>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.
>
>LS: You could use one profile for C-RS (e.g. MQTT) and another one for C-AS (e.g. DTLS) in the same interaction. So the writer of e.g. the DTLS profile MUST NOT make security assumptions that this profile is used on _every_ leg of the communication.
>

FP: Ok, I see, you mean that the C-RS interaction uses for example one profile, while the C-AS uses another? I am not convinced this text is enough - first of all you'd have to make sure that the profiles are "combinable" - the OSCORE profile for example requires the security context to be derived, and simply using another profile without tweaking it would not be enough. Additionally, I am confused about the implications for implementers to mix and match different profiles for different legs of communication, this sounds like interoperability could be an issue. Can we discuss this more?

>============================================================================
>