[Ace] Fwd: FW: New Version Notification for draft-sengul-ace-mqtt-tls-profile-03.txt

Cigdem Sengul <cigdem.sengul@gmail.com> Fri, 05 October 2018 08:35 UTC

Return-Path: <cigdem.sengul@gmail.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B138E130DD5 for <ace@ietfa.amsl.com>; Fri, 5 Oct 2018 01:35:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gT6zfJCDiidy for <ace@ietfa.amsl.com>; Fri, 5 Oct 2018 01:35:55 -0700 (PDT)
Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BEA9130DE6 for <ace@ietf.org>; Fri, 5 Oct 2018 01:35:55 -0700 (PDT)
Received: by mail-qk1-x730.google.com with SMTP id 23-v6so5049862qkh.8 for <ace@ietf.org>; Fri, 05 Oct 2018 01:35:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=R1WQj9gDFbDxTxyIzfnIYHhJrDcAE85Ts+Xkh6x3uUQ=; b=M3Z0RdFl1MycthsAo9h1n5OjVMP0dJJtMbu8JlR4doRx5SsUaiLy128u3uZpE/UDc7 6JdeghpTA/6G52PPLL8P8PIpVehvUxLYlrUHmoLjyhapkwGWZSgMLhRP3glOExkdstjo 1SgrhxZCE9otUi9fDDZtw69fcJbnoZstV4Ipj7yW0dohxTun/hJFaDrhA8CrtneC4u1+ tf+qKfXgjuCKGmve4+2svPOtd4n/bf2h9EyfliACQVw2ouz75LKWpZBuWdIAFqTIqjru Z+kE4HEyf9xPIGXMjlYnkM8wwjfxXdFab5ZGYWYOOmkUzYIXK8p8n1TlPwzVyU2MOsEY MZIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=R1WQj9gDFbDxTxyIzfnIYHhJrDcAE85Ts+Xkh6x3uUQ=; b=OEI0Wc5QaUe1byLH09gK0gMvdfvzWJLnYj9JqVT8xU+YiEqjSKYq38h0w0xUz7bDDc KDOm4aMMgnzl0RPlfXCkA81vwhHVSRlHT+VR/C9aOjLwEE1vjiqAnlp4wqlRZpfGsUNf wJs8uniqyuhySAzLs2Y5zzPAUcRNZdx1A2YhcKf6PIQWQFWrO9r/8K4BAnfqwnN4Sd7a mBLrL10JfMlXe437/6cZZBoGHea3H10Rh/1sViuQjm14PJHmNhZAKXU8fD4nef7c3pWS 1YvSYH7QFPj37teTTaH5GJDCM7A0Sa04pkLgURMnL+MWPsV/WLw58zg9YmkNXnoHs7l5 72UA==
X-Gm-Message-State: ABuFfohSYb0a6ZDoSKSARR7VyGxP2iQIAgy25ufqV2Afl+7fsUFqdGw3 AAX4Cr6lELT1vn4pQTjRB5fgVv5hiFj+TnF2lutIatQb
X-Google-Smtp-Source: ACcGV61eNv72XJ2CsDvO4dRAkKbLVAY0zvQmP+FiIPphBZ3LsWk12vDEPmKmPYc51zjyP1eZ8bXK3NWfXGWuMYyRoyM=
X-Received: by 2002:a37:1b4b:: with SMTP id b72-v6mr8194027qkb.48.1538728553549; Fri, 05 Oct 2018 01:35:53 -0700 (PDT)
MIME-Version: 1.0
References: <153872786909.1031.6765450646719822547.idtracker@ietfa.amsl.com> <2F638E19-26FF-4647-933E-81075F8150DD@nominet.uk>
In-Reply-To: <2F638E19-26FF-4647-933E-81075F8150DD@nominet.uk>
From: Cigdem Sengul <cigdem.sengul@gmail.com>
Date: Fri, 5 Oct 2018 09:35:41 +0100
Message-ID: <CAA7SwCMQA=BJ7D6bLNja7nAJvtGKMbMTvrZoUjxaT38k8h6_Dg@mail.gmail.com>
To: ace@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d7130e05777728c6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/uYSWQ1_AdP4-Eaqq52sM8UeQdqQ>
Subject: [Ace] Fwd: FW: New Version Notification for draft-sengul-ace-mqtt-tls-profile-03.txt
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Oct 2018 08:36:00 -0000

Hello ACE,

We submitted an update of draft-sengul-ace-mqtt-tls-profile with the


  Requirements language fixed according to the new IETF recommendation.

  The use of audience and scopes claims in access tokens has been clarified.

  Encoding used in the access token has been clarified.

  Sections on IANA, security and privacy considerations are added.

With these changes, we aimed to address the review comments of Ludwig Seitz
on May 15, 2018.

Thanks again Ludwig for the detailed review. Our response comments are also


1. Introduction

" Section 4 of the ACE framework [I-D.ietf-ace-oauth-authz]"

If you make that "Section 4 of [I-D.ietf-ace-oauth-authz]" the IETF

html-izer will not turn this into a link to section 4 of your draft (I


See: https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#anchor18

— Together with Ludwig, we decided we did not have this problem.

1.1. Requirements Language

There is a new recommendation how this section should be worded:

  "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",


    "OPTIONAL" in this document are to be interpreted as described in BCP

    14 [RFC2119] [RFC8174] when, and only when, they appear in all

    capitals, as shown here."

— Done.

1.2.  ACE-Related Terminology

"The term "Resource" is used to refer to an MQTT "topic", which is

    defined in Section 1.2."

This references back to the same section, perhaps this was meant to

reference to some other part of the draft?

— Fixed.

2.1.  Authorizing Connection Establishment

Figure 1 could clarify that steps E and F are optional.

— Fixed both in text and on figure.

2.1.1.  Client Authorization Server (CAS) and Authorization Server (AS)


"and the client is authorized to obtain a token for the indicated

    audience (e.g., topics) and scopes (e.g., publish/subscribe


Note that the audience claim is typically used to identify the RS (so in

this case the MQTT broker), while the scope is intended to identify both

the resource (=topic) and the actions (=publish, subscribe).

See this for how OAuth scopes are typically used:


— Cleaned up after a mailing list discussion: authorizes the client for the
indicated audience (e.g. RS) and scopes (e.g. publish/subscribe permissions
over topics)

"This includes a token, which is assumed to be PoP by default."

The abbreviation PoP is not defined at this point, I would write it out

as in "... assumed to be a Proof-of-Possession (PoP) token ..."

— Fixed

2.1.2.  Client connection request to the broker

" For the basic operation described in this section,

    the Username field MUST be set to the token."

I think this refers to the access token right? I'd suggest to be more

specific, since there is room for confusion (CoAP has also the concept

of a token, and then OAuth has different types of tokens, the access

token being one of them).

— Fixed both in Figure 2 and text. “ the Username field MUST be set to the
access token”

"The Password field MUST be set to the keyed message digest (MAC) or


Please make it explicit already here that this is the

Proof-of-possession mechanism for the key associated to the token.

— Clarified with the following text.  “The Password field MUST be set to
the keyed message digest (MAC) or signature associated with the access
token for proof-of-possession.  The client MAY apply the PoP key either to
the token or the entire request by computing a keyed message digest (for
symmetric key) or a digital signature (for asymmetric key).”

"(The Username field is a UTF-8 encoded string,"

You need to specify how the (possibly binary) access token is supposed

to be converted into an UTF-8 string. Base64 encoding would be obvious,

but it needs to be explicitly stated.

— Clarified with the following text. “ Section 3.1.3 of MQTT v3.1 - the
OASIS Standard [MQTT-OASIS-Standard] defines the MQTT Username as a UTF-8
encoded string, which is prefixed by a 2-byte length field followed by
UTF-8 encoded character data up to 65535 bytes.  Therefore an access token
that is not valid UTF-8 MUST be Base64 [RFC4648] encoded.  (The MQTT
Password allows binary data (up to 65535 bytes) so does not require

General comment:

An example of how the CONNECT message could look like would be good.

— Rather than a direct example, we clarified the text and the figure 2.

2.1.3.  Token validation

"The broker MAY cache the introspection result because it will need to

    decide whether to accept subsequent PUBLISH and SUBSCRIBE messages"

This could warrant a section in the security considerations about the

trade-off of caching introspection results (freshness vs. connectivity


—  A discussion was added to the Security considerations section.

"If the introspection result is not cached, then the RS needs to

introspect the saved token for each request."

This is only true if the token is not self-contained. I would rephrase

this statement.

— This is clarified at the beginning of the paragraph that the saved token
is not self-contained.

In 2.1.3:

“ If the token is not self-contained and  broker uses token introspection”

"Note: Scope strings MAY follow ..."

Note that a scope is a "space-delimited list strings" (OAuth 2.0 3.3.)

so you could include several topics in one scope as in e.g. "connect

publish_topic1 publish_topic2 subsrcibe_topic3"

The use of 'aud' as described in this paragraph is definitely not the

intended use, and I would not recommend this type of use. See

https://tools.ietf.org/html/rfc7519#section-4.1.3 for the definition of aud.

— This is clarified as follows after a discussion with Ludwig on the
mailing list:

In 2.1.3:

 “Scope strings SHOULD be encoded as a permission, followed by an

   underscore, followed by a topic filter.  Two permissions apply to

   topics: 'publish' and 'subscribe'.  An example scope field may

   contain multiple such strings, space delimited, e.g., 'publish_topic1

   subscribe_topic2/#'.  Hence, this access token would give 'publish'

   permission to the 'topic1', 'subscribe' permission to all the

   subtopics of 'topic2'.  If there is a single RS, then scope strings

   MAY be simply the keywords 'publish' or 'subscribe,' and the 'aud'

   field in the access token MAY be used to define the topic filter.”

2.4.  Token expiration

"The token validation is done either by checking the 'exp' claim of a

    CWT/JWT or via performing an introspection request with the

    Authorization server as described in Section 8.2 of the ACE framework


The word "token validation" here could be misconstrued to ignoring

crypto wrappers, token issuers ect. While it is clear from the context

(to me) that you only refer to checking the expiration of a token, the

full validation of a token would include the following steps:

1. Check that the issuer of the token (= AS) is acceptable

2. Check the cryptographic wrapper of the token (may be MAC or signature or

AEAD encryption)

3. Check that the token contains all expected claims

4. Check that the "exp" and "nbf" claims are fulfilled if present

5. Check that the "aud" claim applies to the recipient if present

— Token validation explains the aforementioned steps more clearly. For
token expiration in 2.4, the text is corrected.

 “The token expiration is checked by checking the 'exp' claim”

3.1.  Token Transport via Authentication Exchange (AUTH)

"The first option is that Authentication data contains both the token

    and the keyed message digest (MAC) or signature as described in

    Section 2.1.2."

You need to specify how these two items are encoded. I would suggest a

CBOR array since this property expects binary data. An example would also

be very helpful here.

— We have  put CBOR and COSE as a MAY.

"... RS responds with a CONNACK reason code '0x87 (Not Authorized)' and

    includes a User Property set to the address of the AS."

You need to specify the format of this user property, in order to mirror

the framework's section 5.1.2. I guess you could use either a JSON map

or binary data containing a CBOR map for this.

 — Clarified in text:

“AS Information contains the absolute URI of AS, and MAY also contain a
nonce as defined in the Section 5.1.2 of the ACE framework.

This information my be CBOR encoded”.

4.  IANA Considerations

"   This memo includes no request to IANA."

This should instead register the new profile identifier "mqtt_tls" in

the soon-to-be-created IANA registry for ACE profile identifiers. See

the DTLS profile for example:


—Added the relevant text.

5. Security Considerations

You should add some text here about the security implications of the

limitations of MQTT v3.1 (client disconnect only).

I could imagine that you could perform some attacks on a client that

hasn't realized it was disconnected for example.

-- We added discussion on security implications, but a client disconnection
should not be a problem.

Even if the broker disconnects abruptly at the MQTT layer, it is expected
the TCP/TLS session is terminated correctly.

On 05/10/2018, 09:24, "internet-drafts@ietf.org"; <internet-drafts@ietf.org>;

    A new version of I-D, draft-sengul-ace-mqtt-tls-profile-03.txt
    has been successfully submitted by Cigdem Sengul and posted to the
    IETF repository.

    Name:               draft-sengul-ace-mqtt-tls-profile
    Revision:   03
    Title:              MQTT-TLS profile of ACE
    Document date:      2018-10-05
    Group:              Individual Submission
    Pages:              22

       This document specifies a profile for the ACE (Authentication and
       Authorization for Constrained Environments) to enable authorization
       in an MQTT-based publish-subscribe messaging system.  Proof-of-
       possession keys, bound to OAuth2.0 access tokens, are used to
       authenticate and authorize publisher and subscriber clients.  The
       protocol relies on TLS for confidentiality and server authentication.

    Please note that it may take a couple of minutes from the time of
    until the htmlized version and diff are available at tools.ietf.org.

    The IETF Secretariat