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

[Cigdem Sengul <[e-mail]>]

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=
[e-mail]> 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" <
> [e-mail] on behalf of [e-mail]> 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 <[e-mail]> On Behalf Of Francesca Palombini
> via
>     > Datatracker
>     > Sent: den 24 mars 2021 15:50
>     > To: The IESG <[e-mail]>
>     > Cc: [e-mail]; [e-mail]; draft-ietf-ace-oauth-
>     > [e-mail]; [e-mail]
>     > 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
>     > [e-mail]
>     > https://www.ietf.org/mailman/listinfo/ace
>
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>