Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication

[Göran Selander <[e-mail]>]

Hi Daniel,

draft-ietf-ace-oscore-profile-16 does recommend a security protocol to be used between RS and AS, see Section 5:

 "As specified in the ACE framework (section 5.9 of
   [I-D.ietf-ace-oauth-authz]), the requesting entity (RS and/or client)
   and the AS communicates via the introspection or token endpoint.  The
   use of CoAP and OSCORE ([RFC8613]) for this communication is
   RECOMMENDED in this profile; other protocols fulfilling the security
   requirements defined in section 5 of [I-D.ietf-ace-oauth-authz] (such
   as HTTP and DTLS or TLS) MAY be used instead."

For draft-ietf-ace-dtls-authorize-15: "The use of introspection is out of scope for this specification."

So it seems your concern is already resolved in these drafts.

We might ask ourselves why introspection is included in one or not the other. It is not heavily used in draft-ietf-ace-oscore-profile-16, only in Section 4.2:

 "The RS may make an introspection request (see Section 5.9.1
   of [I-D.ietf-ace-oauth-authz]) to validate the token before
   responding to the POST request to the authz-info endpoint."

A similar sentence could have been included in draft-ietf-ace-dtls-authorize as well (together with a recommendation to use DTLS). 

Is this something we want to change at this stage?


Göran




On 2021-03-05, 22:11, "Ace on behalf of Daniel Migault" <[e-mail] on behalf of daniel.migault=[e-mail]> wrote:

    Hi, 

    Now that the authz document is being consolidated, I do have some minor concerns regarding the recommendations mentioned in the profile documents, that might require an additional update.

    The update to the authz document indicates more more clearly than before that profiles need to provide some recommendations for the RS – AS communication. 

    “””
    Profiles MUST  specify for introspection a communication security protocol RECOMMENDED to be used between RS and AS that provides the features required above. “””

    It seems to me the MQTT profile text makes it pretty clear that TLS is recommended for all communications but I am wondering if additional clarification would be beneficial – see below. That said I agree this is a very minor point in this case that could be handled by the RFC editor.
    For the OSCORE or DTLS profiles, unless I am missing the RS – AS recommendations in the documents , it seems to me it has been omitted and needs to be added -- see below.


    Yours, 
    Daniel

    ## MQTT - draft-ietf-ace-mqtt-tls-profile-10

    “””
       To provide communication confidentiality and RS authentication, TLS
       is used, and TLS 1.3 [RFC8446] is RECOMMENDED.  This document makes
       the same assumptions as Section 4 of the ACE framework
       [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with
       the AS and setting up keying material.  While the Client-Broker
       exchanges are only over MQTT, the required Client-AS and RS-AS
       interactions are described for HTTPS-based communication [RFC7230],
       using 'application/ace+json' content type, and unless otherwise
       specified, using JSON encoding.
    “””

    I am wondering if that would not be more appropriated to specify in the first line RS and AS authentication or simply authentication.   





    * OSCORE draft-ietf-ace-oscore-profile-16

    “””
    This
       profile RECOMMENDS the use of OSCORE between client and AS, to reduce
       the number of libraries the client has to support, but other
       protocols fulfilling the security requirements defined in section 5
       of [I-D.ietf-ace-oauth-authz] (such as TLS or DTLS) MAY be used as
       well.
    “””



    * DTLS draft-ietf-ace-dtls-authorize-15


    “””
    It is RECOMMENDED that the client
       uses DTLS with the same keying material to secure the communication
       with the authorization server, proving possession of the key as part
       of the token request.  Other mechanisms for proving possession of the
       key may be defined in the future.
    “””