[要約] RFC 9431 は、MQTTベースのパブリッシュ-サブスクライブメッセージングシステムにおいて、ACEフレームワークの認証と認可プロファイルを定義し、OAuth 2.0アクセストークンにバインドされたPoPキーを使用してMQTTクライアントを認証および認可することを目的としています。TLSを利用して機密性とMQTTサーバー（ブローカー）の認証を行います。
Internet Engineering Task Force (IETF) C. Sengul
Request for Comments: 9431 Brunel University
Category: Standards Track A. Kirby
ISSN: 2070-1721 Oxbotica
July 2023
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework to enable authorization in a publish-subscribe messaging system based on Message Queuing Telemetry Transport (MQTT). Proof-of-Possession keys, bound to OAuth 2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (Broker) authentication.
このドキュメントは、メッセージキューイングテレメトリートランスポート（MQTT）に基づいて、パブリッシュサブスクライブメッセージングシステムで認可を有効にするための制約環境（ACE）フレームワークの認証と承認のプロファイルを指定します。OAUTH 2.0アクセストークンにバインドされたProof-of-Possessionキーは、MQTTクライアントを認証および承認するために使用されます。プロトコルは、機密性とMQTTサーバー（ブローカー）認証のためにTLSに依存しています。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9431.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9431で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Requirements Language
1.2. ACE-Related Terminology
1.3. MQTT-Related Terminology
2. Authorizing Connection Requests
2.1. Client Token Request to the Authorization Server (AS)
2.2. Client Connection Request to the Broker (C)
2.2.1. Overview of Client-RS Authentication Methods over TLS
and MQTT
2.2.2. authz-info: The Authorization Information Topic
2.2.3. Client Authentication over TLS
2.2.3.1. Raw Public Key Mode
2.2.3.2. Pre-Shared Key Mode
2.2.4. Client Authentication over MQTT
2.2.4.1. Transporting the Access Token inside the MQTT
CONNECT
2.2.4.2. Authentication Using the AUTH Property
2.2.5. Broker Token Validation
2.3. Token Scope and Authorization
2.4. Broker Response to Client Connection Request
2.4.1. Unauthorized Request and the Optional Authorization
Server Discovery
2.4.2. Authorization Success
3. Authorizing PUBLISH and SUBSCRIBE Packets
3.1. PUBLISH Packets from the Publisher Client to the Broker
3.2. PUBLISH Packets from the Broker to the Subscriber Clients
3.3. Authorizing SUBSCRIBE Packets
4. Token Expiration, Update, and Reauthentication
5. Handling Disconnections and Retained Messages
6. Reduced Protocol Interactions for MQTT v3.1.1
6.1. Token Transport
6.2. Handling Authorization Errors
7. IANA Considerations
7.1. TLS Exporter Labels Registration
7.2. Media Type Registration
7.3. ACE OAuth Profile Registration
7.4. AIF
8. Security Considerations
9. Privacy Considerations
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Checklist for Profile Requirements
Acknowledgments
Authors' Addresses
This document specifies a profile for the ACE framework [RFC9200]. In this profile, Clients and Servers (Brokers) use MQTT to exchange Application Messages. The protocol relies on TLS for communication security between entities. The MQTT protocol interactions are described based on the MQTT v5.0 OASIS Standard [MQTT-OASIS-Standard-v5]. Since it is expected that MQTT deployments will continue to support MQTT v3.1.1 Clients, this document also describes a reduced set of protocol interactions for the MQTT v3.1.1 OASIS Standard [MQTT-OASIS-Standard-v3.1.1]. However, MQTT v5.0 is the RECOMMENDED version, as it works more naturally with ACE-style authentication and authorization.
このドキュメントは、ACEフレームワーク[RFC9200]のプロファイルを指定します。このプロファイルでは、クライアントとサーバー（ブローカー）を使用してアプリケーションメッセージを交換します。このプロトコルは、エンティティ間の通信セキュリティのためにTLSに依存しています。MQTTプロトコルの相互作用は、MQTT V5.0 OASIS標準[MQTT-OASIS-STANDARD-V5]に基づいて説明されています。MQTTの展開はMQTT V3.1.1クライアントを引き続きサポートすることが予想されるため、このドキュメントでは、MQTT V3.1.1 OASIS標準のプロトコル相互作用の減少[MQTT-Oasis-Standard-V3.1.1]についても説明しています。ただし、MQTT v5.0は推奨バージョンです。これは、ACEスタイルの認証と承認により自然に機能するためです。
MQTT is a publish-subscribe protocol, and after connecting to the MQTT Server (Broker), a Client can publish and subscribe to multiple topics. The Broker, which acts as the Resource Server (RS), is responsible for distributing messages published by the publishers to their subscribers. In the rest of the document, the terms "RS", "MQTT Server", and "Broker" are used interchangeably.
MQTTはパブリッシュサブスクライブプロトコルであり、MQTTサーバー（Broker）に接続した後、クライアントは複数のトピックを公開および購読できます。リソースサーバー（RS）として機能するブローカーは、出版社が発行したメッセージを加入者に配布する責任があります。ドキュメントの残りの部分では、「RS」、「MQTTサーバー」、および「ブローカー」という用語が同じ意味で使用されます。
Messages are published under a Topic Name, and subscribers subscribe to the Topic Names to receive the corresponding messages. The Broker uses the Topic Name in a published message to determine which subscribers to relay the messages to. In this document, topics (more specifically, Topic Names) are treated as resources. The Clients are assumed to have identified the publish/subscribe topics of interest out of band (topic discovery is not a feature of the MQTT protocol). A Resource Owner can preconfigure policies at the Authorization Server (AS) that give Clients publish or subscribe permissions to different topics.
メッセージはトピック名で公開され、サブスクライバーはトピック名を購読して対応するメッセージを受信します。ブローカーは、公開されたメッセージでトピック名を使用して、メッセージを中継するサブスクライバーを決定します。このドキュメントでは、トピック（より具体的には、トピック名）がリソースとして扱われます。クライアントは、関心のあるパブリッシュ/サブスクライブのトピックをバンドから特定したと想定されています（トピック発見はMQTTプロトコルの機能ではありません）。リソースの所有者は、クライアントが異なるトピックにアクセス許可を公開または購読することを許可サーバー（AS）で事前に設定できます。
Clients prove their permission to publish and subscribe to topics hosted on an MQTT Broker using an access token that is bound to a Proof-of-Possession (PoP) key. This document describes how to authorize the following exchanges between the Clients and the Broker.
クライアントは、Proof-ossession（POP）キーにバインドされているアクセストークンを使用して、MQTTブローカーでホストされているトピックを公開および購読する許可を証明します。このドキュメントでは、クライアントとブローカーの間の次の交換を承認する方法について説明します。
* connection requests from the Clients to the Broker
* クライアントからブローカーへの接続要求
* publish requests from the Clients to the Broker and from the Broker to the Clients
* クライアントからブローカー、ブローカーからクライアントへのリクエストを公開する
* subscribe requests from the Clients to the Broker
* クライアントからブローカーへのリクエストを購読します
Clients use the MQTT PUBLISH packet to publish to a topic. The mechanisms specified in this document do not protect the Payload of the PUBLISH packet from the Broker. Hence, the Payload is not signed or encrypted specifically for the subscribers. This functionality may be implemented using the proposal outlined in the ACE Pub-Sub Profile [ACE-PUBSUB-PROFILE].
クライアントはMQTTパブリッシュパケットを使用して、トピックに公開します。このドキュメントで指定されているメカニズムは、ブローカーからのパブリッシュパケットのペイロードを保護しません。したがって、ペイロードはサブスクライバー専用に署名または暗号化されていません。この機能は、ACE Pub-Subプロファイル[ACE-Pubsub-Profile]に概説されている提案を使用して実装できます。
To provide communication confidentiality and Broker authentication to the MQTT Clients, TLS is used, and TLS 1.3 [RFC8446] is RECOMMENDED. This document makes the same assumptions as Section 4 of the ACE framework [RFC9200] regarding Client and RS registration with the AS for setting up the 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 [RFC9110], using the "application/ace+json" content type and, unless otherwise specified, JSON encoding. The token MAY be an opaque reference to authorization information or a JSON Web Token (JWT) [RFC7519]. For JWTs, this document follows [RFC7800] for PoP semantics for JWTs, and the mechanisms for providing and verifying PoP are detailed in Section 2.2. The Client-AS and RS-AS exchanges MAY also use protocols other than HTTP, e.g., Constrained Application Protocol (CoAP) [RFC7252] or MQTT. It is recommended that TLS is used to secure these communication channels between Client-AS and RS-AS. To reduce the protocol memory and bandwidth requirements, implementations MAY also use the "application/ace+cbor" content type, Concise Binary Object Representation (CBOR) encoding [RFC8949], CBOR Web Tokens (CWTs) [RFC8392], and associated PoP semantics. For more information, see "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)" [RFC8747]. A JWT uses JSON Object Signing and Encryption (JOSE), while a CWT uses CBOR Object Signing and Encryption (COSE) [RFC9052] for security protection.
MQTTクライアントにコミュニケーションの機密性とブローカー認証を提供するために、TLSが使用され、TLS 1.3 [RFC8446]が推奨されます。このドキュメントは、Keying素材のセットアップに関するクライアントとRS登録に関するACEフレームワーク[RFC9200]のセクション4と同じ仮定を作成します。クライアント - ブローカーの交換はMQTTを超えていますが、「アプリケーション/ACE JSON」コンテンツタイプを使用して、特に指定されていない限り、JSONエンコードを使用して、必要なクライアントASおよびRS-ASインタラクションがHTTPSベースのコミュニケーション[RFC9110]で説明されています。。トークンは、認証情報またはJSON Webトークン（JWT）[RFC7519]への不透明な参照である場合があります。JWTSの場合、このドキュメントはJWTSのPOPセマンティクスの[RFC7800]に従い、POPを提供および検証するためのメカニズムについて詳しく説明します。クライアントASおよびRS-AS取引所は、HTTP以外のプロトコル、たとえば制約付きアプリケーションプロトコル（COAP）[RFC7252]またはMQTTを使用する場合があります。TLSを使用して、クライアントASとRS-ASの間でこれらの通信チャネルを保護することをお勧めします。プロトコルのメモリと帯域幅の要件を削減するために、実装は「アプリケーション/ACE CBOR」コンテンツタイプ、コンザスバイナリオブジェクト表現（CBOR）をエンコードする[RFC8949]、CBOR Webトークン（CWTS）[RFC8392]、および関連するPOPセマントを使用する場合があります。詳細については、「CBOR Web Tokens（CWTS）のProof-of-Possession Key Semantics」[RFC8747]を参照してください。JWTはJSONオブジェクトの署名と暗号化（ホセ）を使用し、CWTはセキュリティ保護のためにCBORオブジェクトの署名と暗号化（COSE）[RFC9052]を使用します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Certain security-related terms, such as "authentication", "authorization", "data confidentiality", "(data) integrity", "message authentication code" (MAC), and "verify", are taken from [RFC4949].
「認証」、「認証」、「データの機密性」、「データ）、「整合性」、「メッセージ認証コード」（MAC）、「検証」などの特定のセキュリティ関連の用語は、[RFC4949]から取得されます。
The terminology for entities in the architecture is defined in OAuth 2.0 [RFC6749], such as "Client" (C), "Resource Server" (RS), and "Authorization Server" (AS).
アーキテクチャ内のエンティティの用語は、「クライアント」（c）、「リソースサーバー」（RS）、「認証サーバー」（AS）など、OAUTH 2.0 [RFC6749]で定義されています。
The term "resource" is used to refer to an MQTT Topic Name, which is defined in Section 1.3. Hence, the "Resource Owner" is any entity that can authoritatively speak for the topic. This document also defines a Client Authorization Server for Clients that are not able to support HTTP.
「リソース」という用語は、セクション1.3で定義されているMQTTトピック名を参照するために使用されます。したがって、「リソースの所有者」は、トピックについて権威をもって話すことができるエンティティです。このドキュメントでは、HTTPをサポートできないクライアント向けのクライアント認証サーバーも定義しています。
Client Authorization Server (CAS)
クライアント認証サーバー（CAS）
An entity that prepares and endorses authentication and authorization data for a Client and communicates to the AS using HTTPS.
クライアントの認証データと承認データを準備および承認し、HTTPSを使用してASに通信するエンティティ。
The document describes message exchanges as MQTT protocol interactions. The Clients are MQTT Clients, which connect to the Broker to publish and subscribe to Application Messages (which are labeled with their topics). For additional information, please refer to the MQTT v5.0 OASIS Standard [MQTT-OASIS-Standard-v5] or MQTT v3.1.1 OASIS Standard [MQTT-OASIS-Standard-v3.1.1].
ドキュメントは、メッセージ交換をMQTTプロトコルの相互作用として説明しています。クライアントはMQTTクライアントであり、ブローカーに接続してアプリケーションメッセージ（トピックにラベル付けされています）を公開および購読しています。詳細については、MQTT V5.0 OASIS標準[MQTT-OASIS-STANDARD-V5]またはMQTT V3.1.1 OASIS標準[MQTT-OASIS-STANDARD-V3.1.1]を参照してください。
Broker
ブローカ
The Server in MQTT. It acts as an intermediary between the Clients that publish Application Messages and the Clients that made Subscriptions. The Broker acts as the Resource Server for the Clients.
MQTTのサーバー。アプリケーションメッセージを公開するクライアントとサブスクリプションを作成したクライアントの間の仲介者として機能します。ブローカーは、クライアントのリソースサーバーとして機能します。
Client
クライアント
A device or program that uses MQTT.
MQTTを使用するデバイスまたはプログラム。
Network Connection
ネットワーク接続
A construct provided by the underlying transport protocol that is being used by MQTT. It connects the Client to the Server. It provides the means to send an ordered, lossless stream of bytes in both directions. This document uses TLS as the transport protocol.
MQTTが使用している基礎となる輸送プロトコルによって提供される構造。クライアントをサーバーに接続します。順序付けられたロスレスのないバイトのストリームを両方向に送信する手段を提供します。このドキュメントでは、TLSを輸送プロトコルとして使用しています。
Session
セッション
A stateful interaction between a Client and a Broker. Some Sessions last only as long as the Network Connection; others can span multiple Network Connections.
クライアントとブローカーの間のステートフルな相互作用。一部のセッションは、ネットワーク接続以来のみ続きます。その他は、複数のネットワーク接続に及ぶことができます。
Application Message
アプリケーションメッセージ
The data carried by the MQTT protocol. The data has an associated Quality-of-Service (QoS) level and Topic Name.
MQTTプロトコルによって運ばれるデータ。データには、関連するサービス品質（QOS）レベルとトピック名があります。
MQTT Control Packet
MQTTコントロールパケット
The MQTT protocol operates by exchanging a series of MQTT Control Packets. Each packet is composed of a Fixed Header, a Variable Header (depending on the Control Packet type), and a Payload.
MQTTプロトコルは、一連のMQTT制御パケットを交換することにより動作します。各パケットは、固定ヘッダー、可変ヘッダー（コントロールパケットタイプに応じて）、およびペイロードで構成されています。
UTF-8-encoded string
UTF-8エンコード文字列
A string prefixed with a two-byte-length field that gives the number of bytes in a UTF-8-encoded string itself. Unless stated otherwise, all UTF-8-encoded strings can have any length in the range 0 to 65535 bytes.
UTF-8エンコードされた文字列自体にバイト数を与える2バイトの長さのフィールドが付いた文字列。特に明記しない限り、すべてのUTF-8エンコードされた文字列は、0〜65535バイトの範囲に任意の長さを持つことができます。
Binary Data
バイナリデータ
Binary Data is represented by a two-byte-length field, which indicates the number of data bytes, followed by that number of bytes. Thus, the length of Binary Data is limited to the range of 0 to 65535 bytes.
バイナリデータは、データバイトの数を示す2バイトの長さのフィールドで表され、その後のバイト数が続きます。したがって、バイナリデータの長さは0〜65535バイトの範囲に制限されます。
Variable Byte Integer
可変バイト整数
A Variable Byte Integer is encoded using an encoding scheme that uses a single byte for values up to 127. For larger values, the least significant seven bits of each byte encode the data, and the most significant bit is used to indicate whether there are bytes following in the representation. Thus, each byte encodes 128 values and a "continuation bit". The maximum number of bytes in the Variable Byte Integer field is four.
変数バイト整数は、最大127の値に対して単一のバイトを使用するエンコードスキームを使用してエンコードされます。より大きな値の場合、各バイトをエンコードし、最も重要なビットを使用して、バイトがあるかどうかを示すために最も重要なビットが使用されます。表現に続く。したがって、各バイトは128の値と「継続ビット」をエンコードします。可変バイト整数フィールドの最大バイト数は4です。
QoS level
QoSレベル
The level of assurance for the delivery of an Application Message. The QoS level can be 0-2, where 0 indicates "At most once delivery", 1 indicates "At least once delivery", and 2 indicates "Exactly once delivery".
アプリケーションメッセージの配信の保証のレベル。QOSレベルは0-2になります。ここで、0は「最大で配送」を示し、1は「少なくとも1回の配達」を示し、2は「配信が1回だけ」を示します。
Property
財産
The last field of the Variable Header is a set of properties for several MQTT Control Packets (e.g., CONNECT and CONNACK). A property consists of an Identifier that defines its usage and data type, followed by a value. The Identifier is encoded as a Variable Byte Integer. For example, the "Authentication Data" property uses the identifier 22.
変数ヘッダーの最後のフィールドは、いくつかのMQTT制御パケット（ConnectやConnackなど）のプロパティのセットです。プロパティは、使用法とデータ型を定義し、その後に値を定義する識別子で構成されています。識別子は、可変バイト整数としてエンコードされます。たとえば、「認証データ」プロパティは識別子22を使用します。
Topic Name
トピック名
The label attached to an Application Message, which is matched to a Subscription.
サブスクリプションに一致するアプリケーションメッセージに添付されたラベル。
Subscription
サブスクリプション
A Subscription comprises a Topic Filter and a maximum QoS. A Subscription is associated with a single Session.
サブスクリプションは、トピックフィルターと最大Qosを含みます。サブスクリプションは、単一のセッションに関連付けられています。
Topic Filter
トピックフィルター
An expression that indicates interest in one or more Topic Names. Topic Filters may include wildcards.
1つ以上のトピック名への関心を示す式。トピックフィルターにはワイルドカードが含まれる場合があります。
MQTT sends various Control Packets across a Network Connection. The following is not an exhaustive list, and the Control Packets that are not relevant for authorization are not explained. For instance, these include the PUBREL and PUBCOMP packets used in the 4-step handshake required for QoS level 2.
MQTTは、ネットワーク接続全体にさまざまな制御パケットを送信します。以下は網羅的なリストではなく、許可に関連しない制御パケットは説明されていません。たとえば、これらには、QoSレベル2に必要な4段階の握手で使用されるPubrelとPubCompパケットが含まれます。
CONNECT
接続する
The Client requests to connect to the Broker. This is the first packet sent by a Client.
クライアントはブローカーに接続するよう要求します。これは、クライアントから送信された最初のパケットです。
CONNACK
コナック
The Broker connection acknowledgment. CONNACK packets contain return codes that indicate either a success or an error state in response to a Client's CONNECT packet.
ブローカー接続の承認。Connackパケットには、クライアントの接続パケットに応じて成功またはエラー状態のいずれかを示すリターンコードが含まれています。
AUTH
認証
An AUTH Control Packet is sent from the Client to the Broker or from the Broker to the Client as part of an extended authentication exchange. AUTH properties include the Authentication Method and Authentication Data. The Authentication Method is set in the CONNECT packet, and consequent AUTH packets follow the same Authentication Method. The contents of the Authentication Data are defined by the Authentication Method.
Auth Controlパケットは、拡張認証交換の一環として、クライアントからブローカー、またはブローカーからクライアントに送信されます。AUTHプロパティには、認証方法と認証データが含まれます。認証方法はConnectパケットに設定されており、結果のAUTHパケットは同じ認証方法に従います。認証データの内容は、認証方法によって定義されます。
PUBLISH
公開
Publish request sent from a publishing Client to the Broker or from the Broker to a subscribing Client.
公開クライアントからブローカーまたはブローカーから購読クライアントに送信されたリクエストを公開します。
PUBACK
パブ
Response to a PUBLISH request with QoS level 1. PUBACK can be sent from the Broker to a Client or from a Client to the Broker.
QOSレベル1を使用した公開リクエストへの応答。ブローカーからクライアントに、またはクライアントからブローカーに送信できます。
PUBREC
パブレック
Response to a PUBLISH request with QoS level 2. PUBREC can be sent from the Broker to a Client or from a Client to the Broker.
QOSレベル2を使用した公開リクエストへの応答Pubrecは、ブローカーからクライアントまたはクライアントからブローカーに送信できます。
SUBSCRIBE
購読する
Subscribe request sent from a Client.
クライアントから送信されたリクエストを購読します。
SUBACK
suback
Subscribe acknowledgment from the Broker to the Client.
ブローカーからクライアントへの承認を購読します。
PINGREQ
pingreq
A ping request sent from a Client to the Broker. It signals to the Broker that the Client is alive and is used to confirm that the Broker is also alive. The "Keep Alive" period is set in the CONNECT packet.
クライアントからブローカーに送信されたpingリクエスト。ブローカーに、クライアントが生きていることを示し、ブローカーも生きていることを確認するために使用されます。「Keep Alive」期間は、Connectパケットに設定されています。
PINGRESP
pingResp
Response sent by the Broker to the Client in response to PINGREQ. It indicates the Broker is alive.
ブローカーがPingReqに応じてクライアントに送信した応答。ブローカーが生きていることを示しています。
DISCONNECT
切断します
The DISCONNECT packet is the final MQTT Control Packet sent from the Client or the Broker. It indicates the reason why the Network Connection is being closed. If the Network Connection is closed without the Client first sending a DISCONNECT packet with reason code 0x00 (Normal disconnection) and the MQTT Connection has a Will Message, the Will Message is published.
切断パケットは、クライアントまたはブローカーから送信された最終的なMQTTコントロールパケットです。ネットワーク接続が閉じられている理由を示しています。クライアントが最初に理由コード0x00（通常の切断）を使用して切断パケットを送信することなくネットワーク接続が閉じられ、MQTT接続にWillメッセージがある場合、Willメッセージが公開されます。
Will
意思
If the Network Connection is not closed normally, the Broker sends a last Will Message for the Client if the Client provided one in its CONNECT packet. Situations in which the Will Message is published include, but are not limited to, the following:
ネットワーク接続が正常に閉じられていない場合、ブローカーは、クライアントがConnectパケットに提供した場合にクライアントに最後のウィルメッセージを送信します。Willメッセージが公開される状況には、以下が含まれますが、これらに限定されません。
* an I/O error or network failure detected by the Broker,
* ブローカーによって検出されたI/Oエラーまたはネットワークの障害、
* the Client fails to communicate within the Keep Alive period,
* クライアントは、Keep Alive期間内に通信できません。
* the Client closes the Network Connection without first sending a DISCONNECT packet with reason code 0x00 (Normal disconnection), and
* クライアントは、最初に理由コード0x00（通常の切断）を使用して切断パケットを送信せずにネットワーク接続を閉じます。
* the Broker closes the Network Connection without first receiving a DISCONNECT packet with reason code 0x00 (Normal disconnection).
* ブローカーは、理由0x00（通常の切断）を使用して最初に切断パケットを受信せずにネットワーク接続を閉じます。
If the Will Flag is set in the CONNECT flags, then the Payload of the CONNECT packet includes information about the Will. The information consists of the Will Properties, Will Topic, and Will Payload fields.
WillフラグがConnectフラグに設定されている場合、Connect PacketのペイロードにはWillに関する情報が含まれています。情報は、意志プロパティ、ウィルトピック、およびウィルペイロードフィールドで構成されています。
This section specifies how Client connections are authorized by the AS and verified by the MQTT Broker. Figure 1 shows the basic protocol flows during connection setup. The token request and response use the token endpoint at the AS, specified for HTTP-based interactions in Section 5.8 of the ACE framework [RFC9200]. Steps (D) and (E) are optional and use the introspection endpoint specified in Section 5.9 of the ACE framework [RFC9200]. The discussion in this document assumes that the Client and the Broker use HTTPS to communicate with the AS via these endpoints. The Client and the Broker use MQTT to communicate between them. The C-AS and Broker-AS communications MAY be implemented using protocols other than HTTPS, e.g., CoAP or MQTT. Whatever protocol is used for the C-AS and Broker-AS communications MUST provide mutual authentication, confidentiality protection, and integrity protection.
このセクションでは、クライアント接続がASによってASによって承認され、MQTTブローカーによって検証される方法を指定します。図1は、接続セットアップ中の基本的なプロトコルフローを示しています。トークン要求と応答は、ACEフレームワーク[RFC9200]のセクション5.8でHTTPベースの相互作用に指定されたASでトークンエンドポイントを使用します。手順（d）および（e）はオプションであり、ACEフレームワーク[RFC9200]のセクション5.9で指定された内省エンドポイントを使用します。このドキュメントでの議論は、クライアントとブローカーがHTTPSを使用してこれらのエンドポイントを介してASと通信することを前提としています。クライアントとブローカーは、MQTTを使用してそれらの間で通信します。C-ASおよびBROKER-AS通信は、HTTPS以外のプロトコル、例えばCOAPまたはMQTTを使用して実装できます。C-ASおよびBroker-ASコミュニケーションに使用されるプロトコルは、相互認証、機密保護、および完全性保護を提供する必要があります。
If the Client is resource constrained or does not support HTTPS, a separate Client Authorization Server may carry out the token request on behalf of the Client (Figure 1, steps (A) and (B)) and, later, onboard the Client with the token. The interactions between a Client and its Client Authorization Server for token onboarding and support for MQTT-based token requests at the AS are out of the scope of this document.
クライアントがリソースが制約されているか、HTTPSをサポートしていない場合、別のクライアント認証サーバーは、クライアントに代わってトークンリクエストを実行できます（図1、ステップ（a）および（b））。トークン。クライアントとそのクライアント認証サーバーと、トークンオンボーディングのためのクライアント認証サーバーと、このドキュメントの範囲外であるASでのMQTTベースのトークン要求のサポートとの相互作用。
+---------------------+
| Client |
| |
+---(A) Token request------| Client - |
| | Authorization |
| +-(B) Access token-----> Server Interface |
| | | (HTTPS) |
| | |_____________________|
| | | |
+--v-------------+ | Pub/Sub Interface |
| Authorization | | (MQTT over TLS) |
| Server | +----------------^----+
|________________| | |
| ^ (C) Connection (F) Connection
| | request + response
| | access token |
| | | |
| | +---v--------------+
| | | Broker |
| | | (MQTT over TLS) |
| | |__________________|
| +(D) Introspection-----| |
| request (optional)| RS-AS interface |
| | (HTTPS) |
+-(E) Introspection-------->|__________________|
response (optional)
Figure 1: Connection Setup
図1：接続のセットアップ
The first step in the protocol flow (Figure 1, step (A)) is the token acquisition by the Client from the AS. The Client and the AS MUST perform mutual authentication. The Client requests an access token from the AS, as described in Section 5.8.1 of the ACE framework [RFC9200]. The document follows the procedures defined in Section 3.2.1 of the DTLS profile [RFC9202] for raw public keys (RPKs) [RFC7250]) and in Section 3.3.1 of [RFC7250] for pre-shared keys (PSKs). However, the content type of the request is set to "application/ace+json", and the AS uses JSON in the Payload of its responses to the Client and the RS. As explained earlier, implementations MAY also use the "application/ace+cbor" content type.
プロトコルフローの最初のステップ（図1、ステップ（a））は、ASからのクライアントによるトークンの取得です。クライアントとASは相互認証を実行する必要があります。クライアントは、ACEフレームワーク[RFC9200]のセクション5.8.1で説明されているように、ASからアクセストークンを要求します。このドキュメントは、生の公共キー（RPK）[RFC7250]）のDTLSプロファイル[RFC9202]のセクション3.2.1 [RFC7250]）と、株式前キー（PSK）の[RFC7250]のセクション3.3.1で定義されている手順に従います。ただし、リクエストのコンテンツタイプは「アプリケーション/エースJSON」に設定され、ASはクライアントとRSへの応答のペイロードでJSONを使用します。前に説明したように、実装は「アプリケーション/ACE CBOR」コンテンツタイプを使用する場合があります。
On receipt of the token request, the AS verifies the request. If the AS successfully verifies the access token request and authorizes the Client for the indicated audience (i.e., RS) and scopes (i.e., publish/subscribe permissions over topics, as described in Section 2.3), the AS issues an access token (Figure 1, step (B)).
トークンリクエストを受け取ったとき、ASはリクエストを検証します。ASがアクセストークンリクエストを正常に検証し、指定された視聴者（つまりRS）とスコープ（つまり、セクション2.3で説明されているように、トピックを介して公開/購読する権限を公開/購読する）のクライアントを許可する場合、AS AS ACASSE TOKEN（図1、ステップ（b））。
The response includes the parameters described in Section 5.8.2 of the ACE framework [RFC9200]. For RPKs, the parameters are as described in Section 3.2.1 of the DTLS profile [RFC9202]. For PSKs, the document follows Section 3.3.1 of the DTLS profile [RFC9202]. In both cases, if the response contains an "ace_profile" parameter, this parameter is set to "mqtt_tls". The returned token is a Proof-of-Possession (PoP) token by default.
応答には、ACEフレームワークのセクション5.8.2 [RFC9200]で説明されているパラメーターが含まれます。RPKの場合、パラメーターは、DTLSプロファイル[RFC9202]のセクション3.2.1で説明されています。PSKの場合、ドキュメントはDTLSプロファイル[RFC9202]のセクション3.3.1に従います。どちらの場合も、応答に「ace_profile」パラメーターが含まれている場合、このパラメーターは「mqtt_tls」に設定されます。返されたトークンは、デフォルトでのプルーフポッセッション（ポップ）トークンです。
This document follows [RFC7800] for PoP semantics for JWTs (CWTs MAY also be used). The AS includes a "cnf" (confirmation) parameter in the PoP token to declare that the Client possesses a particular key and the RS can cryptographically confirm that the Client has possession of that key, as described in [RFC9201].
このドキュメントは、JWTSのPOPセマンティクスについて[RFC7800]に続きます（CWTSも使用できます）。ASには、ポップトークンに「CNF」（確認）パラメーターが含まれて、クライアントが特定のキーを所有していることを宣言し、RSは[RFC9201]で説明されているように、クライアントがそのキーを所有していることを暗号化できることを確認できます。
Note that the contents of the web tokens (including the "cnf" parameter) are to be consumed by the RS and not the Client (the Client obtains the key information in a different manner). The RPK case is handled as described in Section 3.2.1 of the DTLS profile [RFC9202]. For the PSK case, the referenced procedures apply, with the following exceptions to accommodate JWT and JOSE use. In this case, the AS adds a "cnf" parameter to the Access Information carrying a JSON Web Key (JWK) [RFC7517] object that contains either the symmetric key itself or a key identifier that can be used by the RS to determine the secret key it shares with the Client. The JWT is created as explained in Section 7 of [RFC7519], and the JWT MUST include a JSON Web Encryption (JWE) [RFC7516]. If a CWT/COSE is used, this information MUST be inside the "COSE_Key" object and MUST be encrypted using a "COSE_Encrypt0" structure.
Webトークンの内容（「CNF」パラメーターを含む）は、クライアントではなくRSによって消費されることに注意してください（クライアントは異なる方法で重要な情報を取得します）。RPKケースは、DTLSプロファイル[RFC9202]のセクション3.2.1で説明されているように処理されます。PSKの場合、参照された手順が適用されます。これは、JWTとホセの使用に対応するための以下の例外を除きます。この場合、ASはJSON Webキー（JWK）[RFC7517]オブジェクトを運ぶアクセス情報に「CNF」パラメーターを追加します。クライアントと共有するキー。JWTは[RFC7519]のセクション7で説明されているように作成されており、JWTにはJSON Web暗号化（JWE）[RFC7516]を含める必要があります。CWT/COSEを使用する場合、この情報は「cose_key」オブジェクトの内部にあり、「cose_encrypt0」構造を使用して暗号化する必要があります。
The AS returns error responses for JSON-based interactions following Section 5.2 of [RFC6749]. When CBOR is used, the interactions MUST implement the procedure described in Section 5.8.3 of the ACE framework [RFC9200].
ASは、[RFC6749]のセクション5.2に従って、JSONベースの相互作用のエラー応答を返します。CBORを使用する場合、インタラクションは、ACEフレームワーク[RFC9200]のセクション5.8.3で説明されている手順を実装する必要があります。
Unless the Client publishes and subscribes to only public topics, the Client and the Broker MUST perform mutual authentication. The Client MUST authenticate to the Broker either over MQTT or TLS before performing any other action. For MQTT, the options are "None" and "ace". For TLS, the options are "Anon" for an anonymous client, and "Known(RPK/PSK)" for RPKs and PSKs, respectively. The "None" and "Anon" options do not provide client authentication but can be used either during authentication or in combination with authentication at the other layer. When the Client uses TLS:Anon,MQTT:None, the Client can only publish or subscribe to public topics. Thus, the client authentication procedures involve the following possible combinations:
クライアントがパブリックトピックのみを公開および購読しない限り、クライアントとブローカーは相互認証を実行する必要があります。クライアントは、他のアクションを実行する前に、MQTTまたはTLSを介してブローカーに認証する必要があります。MQTTの場合、オプションは「なし」と「エース」です。TLSの場合、オプションは匿名クライアントの「アノン」であり、RPKとPSKの「既知（RPK/PSK）」です。「なし」および「アノン」オプションは、クライアント認証を提供しませんが、認証中または他のレイヤーでの認証と組み合わせて使用できます。クライアントがTLS：ANON、MQTT：なしを使用する場合、クライアントはパブリックトピックのみを公開または購読できます。したがって、クライアント認証手順には、次の可能な組み合わせが含まれます。
TLS:Anon,MQTT:None:
TLS：Anon、MQTT：なし：
This option is used only for the topics that do not require authorization, including the "authz-info" topic. Publishing to the "authz-info" topic is described in Section 2.2.2.
このオプションは、「authz-info」トピックを含む承認を必要としないトピックにのみ使用されます。「authz-info」トピックへの公開については、セクション2.2.2で説明しています。
TLS:Anon,MQTT:ace:
TLS：ANON、MQTT：ACE：
The token is transported inside the CONNECT packet and MUST be validated using one of the methods described in Section 2.2.2. This option also supports a tokenless connection request for AS discovery. As per the ACE framework [RFC9200], a separate step is needed to determine whether the discovered AS URI is authorized to act as an AS.
トークンは接続パケット内で輸送され、セクション2.2.2で説明されている方法のいずれかを使用して検証する必要があります。このオプションは、発見のためのトークンレス接続要求もサポートしています。ACEフレームワーク[RFC9200]によると、URIとして発見されたものがASとして行動することが許可されているかどうかを判断するために、別のステップが必要です。
TLS:Known(RPK/PSK),MQTT:none:
TLS：既知（RPK/PSK）、MQTT：なし：
This specification supports client authentication with TLS with RPKs and PSKs, following the procedures described in the DTLS profile [RFC9202]. For the RPK, the Client MUST have published the token to the "authz-info" topic. For the PSK, the token MAY be published to the "authz-info" topic or MAY be, alternatively, provided as a "PSK identity" (e.g., an "identity" in the "identities" field in the Client's "pre_shared_key" extension in TLS 1.3).
この仕様は、DTLSプロファイル[RFC9202]で説明されている手順に従って、RPKおよびPSKを使用したTLSを使用したクライアント認証をサポートします。RPKの場合、クライアントはトークンを「authz-info」トピックに公開している必要があります。PSKの場合、トークンは「authz-info」トピックに公開されるか、あるいは「PSK ID」として提供される場合があります（たとえば、クライアントの「pre_shared_key」拡張機能の「アイデンティティ」フィールドの「アイデンティティ」フィールドTLS 1.3で）。
TLS:Known(RPK/PSK),MQTT:ace:
TLS：既知（RPK/PSK）、MQTT：ACE：
This option SHOULD NOT be chosen as the token transported in the CONNECT packet and overwrites any permissions passed during the TLS authentication.
このオプションは、Connectパケットで輸送されたトークンを選択し、TLS認証中に渡されたアクセス許可を上書きしないように選択する必要はありません。
It is RECOMMENDED that the Client implements TLS:Anon,MQTT:ace as the first choice when working with protected topics. However, MQTT v3.1.1 Clients that do not prefer to overload the User Name and Password fields for ACE (as described in Section 6) MAY implement TLS:Known(RPK/PSK),MQTT:none and, consequently, TLS:Anon,MQTT:None to submit their token to "authz-info".
クライアントは、保護されたトピックを操作する際に最初の選択肢としてTLS：ANON、MQTT：ACEを実装することをお勧めします。ただし、ACEのユーザー名とパスワードフィールドを過負荷することを好まないMQTT v3.1.1クライアント（セクション6で説明）は、TLSを実装できます：既知（RPK/PSK）、MQTT：なし、およびその結果、TLS：ANON、MQTT：トークンを「authz-info」に送信するものはありません。
The Broker MUST support TLS:Anon,MQTT:ace. To support Clients with different capabilities, the Broker MAY provide multiple client authentication options, e.g., support TLS:Known(RPK),MQTT:none and TLS:Anon,MQTT:None, to enable RPK-based client authentication.
ブローカーは、TLS：ANON、MQTT：ACEをサポートする必要があります。さまざまな機能を備えたクライアントをサポートするために、ブローカーは複数のクライアント認証オプションを提供できます。たとえば、サポートTLS：既知（RPK）、MQTT：なし、TLS：ANON、MQTT：NONE、RPKベースのクライアント認証を有効にします。
The Client MUST authenticate the Broker during the TLS handshake. If the Client authentication uses TLS:Known(RPK/PSK), then the Broker is authenticated using the respective method. Otherwise, to authenticate the Broker, the Client MUST validate a public key from an X.509 certificate or an RPK from the Broker against the "rs_cnf" parameter in the token response, which contains information about the public key used by the RS to authenticate if the token type is "pop" and asymmetric keys are used as defined in [RFC9201]. The AS MAY include the thumbprint of the RS's X.509 certificate in the "rs_cnf" (thumbprint, as defined in [RFC9360]). In this case, the Client MUST validate the RS certificate against this thumbprint.
クライアントは、TLSの握手中にブローカーを認証する必要があります。クライアント認証がTLS：既知（RPK/PSK）を使用している場合、ブローカーはそれぞれの方法を使用して認証されます。それ以外の場合は、ブローカーを認証するには、クライアントは、X.509証明書またはブローカーからのRPKから公開キーを検証する必要があります。トークン応答の「RS_CNF」パラメーターは、RSが使用する公開鍵に関する情報を含むものです。トークンタイプが「ポップ」であり、非対称キーが[RFC9201]で定義されている場合。ASには、「RS_CNF」（[RFC9360]で定義されているように）のRSのX.509証明書のサムプリントが含まれる場合があります。この場合、クライアントはこのthumbprintに対してRS証明書を検証する必要があります。
In the cases when the Client must transport the token to the Broker first, the Client connects to the Broker to publish its token to the "authz-info" topic. The "authz-info" topic MUST only be published (i.e., the Clients are not allowed to subscribe to it). "authz-info" is not protected, and hence, the Client uses the TLS:Anon,MQTT:None option over a TLS connection. After publishing the token, the Client disconnects from the Broker and is expected to reconnect using client authentication over TLS (i.e., TLS:Known(RPK/PSK),MQTT:none).
クライアントが最初にトークンをブローカーに輸送する必要がある場合、クライアントはブローカーに接続してトークンを「authz-info」トピックに公開します。「authz-info」トピックは公開する必要があります（つまり、クライアントはそれを購読することは許可されていません）。「authz-info」は保護されていないため、クライアントはtls：anon、mqtt：なしのTLS接続を使用します。トークンを公開した後、クライアントはブローカーから切断され、TLSを介したクライアント認証を使用して再接続することが期待されます（つまり、TLS：既知（RPK/PSK）、MQTT：なし）。
The Broker stores and indexes all tokens received to the "authz-info" topic in its key store (similar to the DTLS profile for ACE [RFC9202]). This profile follows the recommendation of Section 5.10.1 of the ACE framework [RFC9200] and expects that the Broker stores only one token per PoP key, and any other token linked to the same key overwrites an existing token.
ブローカーは、すべてのトークンがキーストアの「authz-info」トピックに受け取ったすべてのトークンを保存およびインデックス作成します（ACE [RFC9202]のDTLSプロファイルと同様）。このプロファイルは、ACEフレームワーク[RFC9200]のセクション5.10.1の推奨に従い、ブローカーがポップキーごとに1つのトークンのみを保存し、同じキーにリンクされた他のトークンは既存のトークンを上書きすることを期待しています。
The Broker MUST verify the validity of the token (i.e., through local validation or introspection if the token is a reference), as described in Section 2.2.5. If the token is not valid, the Broker MUST discard the token.
ブローカーは、セクション2.2.5で説明されているように、トークンの有効性（つまり、トークンが参照である場合はローカル検証または内省を介して）を検証する必要があります。トークンが有効でない場合、ブローカーはトークンを廃棄する必要があります。
Depending on the QoS level of the PUBLISH packet, the Broker returns the error response as a PUBACK, PUBREC, or DISCONNECT packet. If the QoS level is equal to 0, and the token is not valid, or if the claims cannot be obtained in the case of an introspected token, the Broker MUST send a DISCONNECT packet with reason code 0x87 (Not authorized). If the PUBLISH Payload does not parse to a token, the Broker MUST send a DISCONNECT with reason code 0x99 (Payload format invalid).
Publish PacketのQoSレベルに応じて、ブローカーはエラー応答をPuback、Pubrec、または切断パケットとして返します。QOSレベルが0に等しく、トークンが有効でない場合、またはイントロスケートトークンの場合にクレームを取得できない場合、ブローカーは理由コード0x87（許可されていない）で切断パケットを送信する必要があります。パブリッシュペイロードがトークンに解析されない場合、ブローカーは理由コード0x99（ペイロード形式が無効）との切断を送信する必要があります。
If the QoS level of the PUBLISH packet is greater than or equal to 1, and the token is not valid, or the claims cannot be obtained in the case of an introspected token, the Broker MUST send reason code 0x87 (Not authorized) in the PUBACK or PUBREC. If the PUBLISH Payload does not parse to a token, the PUBACK/PUBREC reason code is 0x99 (Payload format invalid).
パブリッシュパケットのQoSレベルが1以上であり、トークンが有効でない場合、またはイントロスタートトークンの場合にクレームを取得できない場合、ブローカーは理由0x87（許可されていない）を送信する必要があります。PubackまたはPubrec。パブリッシュペイロードがトークンに解析されない場合、Puback/Pubrec理由コードは0x99（ペイロード形式が無効）です。
When the Broker sends the "Not authorized" response, it must be noted that this corresponds to the token being not valid and not that the actual PUBLISH packet was not authorized. Given that the "authz-info" is a public topic, this response is not expected to cause confusion.
ブローカーが「許可されていない」応答を送信する場合、これはトークンが無効であることに対応し、実際のパブリックパケットが承認されていないことに注意する必要があります。「authz-info」が公的なトピックであることを考えると、この応答は混乱を引き起こすとは予想されていません。
This document supports TLS with raw public keys (RPKs) [RFC7250] and with pre-shared keys (PSKs). The TLS session setup follows the DTLS profile for ACE [RFC9202], as the profile applies to TLS equally well [RFC9430]. When there are exceptions to the DTLS profile, these are explicitly stated in the document. If TLS 1.2 is used, [RFC7925] describes how TLS can be used for constrained devices, alongside recommended cipher suites. Additionally, TLS 1.2 implementations MUST use the "Extended Main Secret" extension (terminology adopted from [TLS-bis]) to incorporate the handshake transcript into the main secret [RFC7627]. TLS implementations SHOULD use the Server Name Indication (SNI) [RFC6066] and Application-Layer Protocol Negotiation (ALPN) [RFC7301] extensions so the TLS handshake authenticates as much of the protocol context as possible.
このドキュメントは、生のパブリックキー（RPK）[RFC7250]および事前共有キー（PSK）を使用してTLSをサポートしています。TLSセッションのセットアップは、ACE [RFC9202]のDTLSプロファイルに従います。これは、プロファイルがTLSに等しく適切に適用されるためです[RFC9430]。DTLSプロファイルに例外がある場合、これらはドキュメントに明示的に記載されています。TLS 1.2を使用する場合、[RFC7925]は、推奨される暗号スイートとともに、制約付きデバイスにTLSを使用する方法を説明します。さらに、TLS 1.2の実装は、「拡張されたメインシークレット」拡張（[TLS-BIS]から採用された用語）を使用して、ハンドシェイク転写産物をメインシークレット[RFC7627]に組み込む必要があります。TLSの実装では、サーバー名表示（SNI）[RFC6066]およびアプリケーション層プロトコル交渉（ALPN）[RFC7301]拡張を使用する必要があります。
This document follows the procedures defined in Section 3.2.2 of the DTLS profile for ACE [RFC9202] with the following exceptions. The Client MUST upload the access token to the Broker using the method specified in Section 2.2.2 before initiating the handshake.
このドキュメントは、以下の例外を除いて、ACE [RFC9202]のDTLSプロファイルのセクション3.2.2で定義されている手順に従います。クライアントは、ハンドシェイクを開始する前に、セクション2.2.2で指定された方法を使用して、アクセストークンをブローカーにアップロードする必要があります。
This document follows the procedures defined in Section 3.3.2 of the DTLS profile for ACE [RFC9202] with the following exceptions.
このドキュメントは、以下の例外を除いて、ACE [RFC9202]のDTLSプロファイルのセクション3.3.2で定義されている手順に従います。
To use TLS 1.3 with pre-shared keys, the Client utilizes the PSK extension specified in [RFC8446] using the key conveyed in the "cnf" parameter of the AS response. The same key is bound to the access token in the "cnf" claim. The Client can upload the token, as specified in Section 2.2.2, before initiating the handshake. When using a previously uploaded token, the Client MUST indicate during the handshake which previously uploaded access token it intends to use. To do so, it MUST create a "COSE_Key" or "JWK" structure with the "kid" that was conveyed in the "rs_cnf" claim in the token response from the AS and the key type "symmetric". This structure is then included as the only element in the "cnf" structure and the encoded value of that "cnf" structure used as a PSK identity in TLS. As an alternative to the access token upload, the Client can provide the most recent access token, JWT or CWT, as a PSK identity.
事前共有キーを使用してTLS 1.3を使用するために、クライアントは、AS応答の「CNF」パラメーターで伝達されたキーを使用して[RFC8446]で指定されたPSK拡張機能を使用します。同じキーは、「CNF」クレームのアクセストークンに縛られています。握手を開始する前に、セクション2.2.2で指定されているように、クライアントはトークンをアップロードできます。以前にアップロードされたトークンを使用する場合、クライアントは、使用する予定のアクセストークンを以前にアップロードした握手中に示す必要があります。そのためには、ASからのトークン応答とキータイプの「対称」で「RS_CNF」クレームで伝えられた「KID」と「cose_key」または「jwk」構造を作成する必要があります。この構造は、「CNF」構造の唯一の要素として、およびTLSでPSKアイデンティティとして使用される「CNF」構造のエンコードされた値として含まれます。アクセストークンアップロードの代替として、クライアントはPSK IDとして最新のアクセストークン、JWTまたはCWTを提供できます。
In contrast to the DTLS profile for ACE [RFC9202], a Client MAY omit support for the cipher suites TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8. For TLS 1.2, however, a client MUST support TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 for PSKs [RFC8442] and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for RPKs [RFC8422], as recommended in [RFC9325] (and adjusted to be a PSK cipher suite as appropriate).
ACE [RFC9202]のDTLSプロファイルとは対照的に、クライアントはCipher Suites TLS_PSK_WITH_AES_128_CCM_8およびTLS_ECDHE_ECDSA_WITH_AES_128_CCM_8のサポートを省略できます。ただし、TLS 1.2の場合、クライアントはPSKS [RFC8442]およびTLS_GCM_SHA256をサポートする必要があります[RFC8442]およびTLS_GCM_SHA256およびTLS_ECDSA_WITH_AES_128_GCM_SHA256 for rpks [rfc8422] for as as as as as asedase adasued assoce as assecidea必要に応じてk cipherスイート）。
This section describes how the Client transports the token to the Broker inside the CONNECT packet. If this method is used, the Client TLS connection is expected to be anonymous, and the Broker is authenticated during the TLS connection setup. The approach described in this section is similar to an earlier proposal by Fremantle, et al. [Fremantle14].
このセクションでは、クライアントがConnectパケット内のブローカーにトークンを輸送する方法について説明します。この方法を使用すると、クライアントTLS接続は匿名であると予想され、TLS接続のセットアップ中にブローカーは認証されます。このセクションで説明したアプローチは、Fremantle et al。による以前の提案に似ています。[Fremantle14]。
After sending the CONNECT packet, the Client MUST wait to receive the CONNACK packet from the Broker. The only packets it is allowed to send are DISCONNECT or AUTH that are in response to the Broker AUTH. Similarly, except for a DISCONNECT and AUTH response from the Client, the Broker MUST NOT process any packets before sending a CONNACK packet.
Connectパケットを送信した後、クライアントはブローカーからConnackパケットを受信するのを待つ必要があります。送信が許可されている唯一のパケットは、ブローカーの認証に応じた切断またはAUTHです。同様に、クライアントからの切断および認証応答を除き、ブローカーはコナックパケットを送信する前にパケットを処理してはなりません。
Figure 2 shows the structure of the MQTT CONNECT packet used in MQTT v5.0. A CONNECT packet is composed of a Fixed Header, a Variable Header, and a Payload The Fixed Header contains the Control Packet Type (CPT), Reserved, and Remaining Length fields. The Remaining Length is a Variable Byte Integer that represents the number of bytes remaining within the current Control Packet, including data in the Variable Header and the Payload. The Variable Header contains the Protocol Name, Protocol Level, Connect flags, Keep Alive, and Properties fields. The Connect flags in the Variable Header specify the properties of the MQTT Session. It also indicates the presence or absence of some fields in the Payload. The Payload contains one or more encoded fields, namely a unique Client Identifier for the Client, a Will Topic, Will Payload, User Name, and Password. All but the Client Identifier can be omitted depending on the flags in the Variable Header. The Client Identifier identifies the Client to the Broker and, therefore, is unique for each Client. It must be noted that the Client Identifier is an unauthenticated identifier used within the MQTT protocol and so is not bound to the access token.
図2は、MQTT v5.0で使用されるMQTT接続パケットの構造を示しています。Connectパケットは、固定ヘッダー、可変ヘッダー、およびペイロードで構成されています。固定ヘッダーには、コントロールパケットタイプ（CPT）、予約済み、残りの長さフィールドが含まれています。残りの長さは、変数ヘッダーのデータやペイロードのデータを含む、現在のコントロールパケット内に残っているバイト数を表す可変バイト整数です。変数ヘッダーには、プロトコル名、プロトコルレベル、接続フラグ、Keep Alve、およびPropertiesフィールドが含まれます。変数ヘッダーの接続フラグは、MQTTセッションのプロパティを指定します。また、ペイロード内の一部のフィールドの有無を示します。ペイロードには、1つ以上のエンコードされたフィールドが含まれています。つまり、クライアントの一意のクライアント識別子であるWillトピックは、ペイロード、ユーザー名、パスワードです。クライアント識別子を除くすべては、変数ヘッダーのフラグに応じて省略できます。クライアント識別子は、クライアントをブローカーに識別するため、クライアントごとに一意です。クライアント識別子は、MQTTプロトコル内で使用される認証されていない識別子であるため、アクセストークンに拘束されないことに注意する必要があります。
0 8 16
+---------------------------+
|Protocol name length = 4 |
+---------------------------+
| 'M' 'Q' |
+---------------------------+
| 'T' 'T' |
+---------------------------+
|Proto.level=5|Connect flags|
+---------------------------+
| Keep alive |
+---------------------------+
| CONNECT Properties Length |
| (up to 4 bytes) |
+---------------------------+
| ( ..Other properties..) |
+---------------------------+
| Authentication Method |
| (0x15) | Len |
| Len | 'a' |
| 'c' | 'e' |
+---------------------------+
| Authentication Data |
| (0x16) | Len |
| Len | token |
| or token + PoP data |
+---------------------------+
Figure 2: MQTT v5 CONNECT Variable Header with Authentication Method Property for ACE
図2：MQTT v5は、ACEの認証方法プロパティを持つ可変ヘッダーを接続します
The CONNECT flags are User Name, Password, Will Retain, Will QoS, Will Flag, Clean Start, and Reserved. Table 1 shows how the flags MUST be set to use AUTH packets for authentication and authorization, i.e., the User Name Flag and Password Flag MUST be set to 0. An MQTT v5.0 Broker MAY also support token transport using the User Name and Password to provide a security option for MQTT v3.1.1 Clients, as described in Section 6.
Connectフラグはユーザー名、パスワード、保持され、QOS、Flag、Clean Start、および予約されます。表1は、認証と承認のためにAuthパケットを使用するようにフラグを設定する方法、つまりユーザー名フラグとパスワードフラグを0に設定する必要があることを示しています。セクション6で説明されているように、MQTT V3.1.1クライアントにセキュリティオプションを提供します。
+===========+==========+========+======+======+=======+==========+
| User Name | Password | Will | Will | Will | Clean | Reserved |
| Flag | Flag | Retain | QoS | Flag | Start | |
+===========+==========+========+======+======+=======+==========+
| 0 | 0 | X | X X | X | X | 0 |
+-----------+----------+--------+------+------+-------+----------+
Table 1: CONNECT Flags for AUTH
表1：AUTHのフラグを接続します
The Will Flag indicates that a Will Message needs to be sent. The Client MAY set the Will Flag as desired (marked as "X" in Table 1). If the Will Flag is set to 1, the Broker MUST check that the token allows the publication of the Will Message (i.e., the Will Topic Filter is in the scope array). The check is performed against the token scope described in Section 2.3. If the Will authorization fails, the connection is refused, as described in Section 2.4.1. If the Broker accepts the connection request, the Broker stores the Will Message and publishes it when the Network Connection is closed according to Will QoS, Will Retain parameters, and MQTT Will management rules. To avoid publishing the Will Messages in the case of temporary network disconnections, the Client specifies a Will Delay Interval in the Will Properties. Section 5 explains how the Broker deals with the retained messages in further detail.
遺言フラグは、Willメッセージを送信する必要があることを示します。クライアントは、必要に応じてウィルフラグを設定できます（表1の「x」とマークされています）。Willフラグが1に設定されている場合、ブローカーはトークンがWillメッセージの公開を許可していることを確認する必要があります（つまり、Willトピックフィルターはスコープアレイにあります）。チェックは、セクション2.3で説明されているトークンスコープに対して実行されます。セクション2.4.1で説明されているように、意志認証が失敗した場合、接続は拒否されます。ブローカーが接続要求を受け入れた場合、ブローカーはWill ConnectionがWill QOSに従って閉じられ、パラメーターを保持し、MQTTが管理ルールを保持したときにWillメッセージを保存し、公開します。一時的なネットワーク切断の場合にWillメッセージを公開しないようにするために、クライアントはWillプロパティの[遅延間隔を指定します。セクション5では、ブローカーが保持されたメッセージをさらに詳細に扱う方法について説明します。
In MQTT v5.0, the Client signals a new Session (i.e., that the Session does not continue an existing Session) by setting the Clean Start flag to 1 in the CONNECT packet. In this profile, the Client SHOULD always start with a new Session. The Broker MAY also signal that it does not support the continuation of an existing Session by setting the Session Expiry Interval to 0 in the CONNACK. If the Broker starts a new Session, the Broker MUST set the Session Present flag to 0 in the CONNACK packet to signal this to the Client.
MQTT V5.0では、クライアントは、ConnectパケットでClean Startフラグを1に設定することにより、新しいセッション（つまり、セッションが既存のセッションを継続しないことを示すことを示しています）を示します。このプロファイルでは、クライアントは常に新しいセッションから開始する必要があります。ブローカーはまた、セッションの有効期限間隔をConnackで0に設定することにより、既存のセッションの継続をサポートしていないことを示す場合があります。ブローカーが新しいセッションを開始した場合、ブローカーはConnackパケットのセッションプレゼントフラグを0に設定して、これをクライアントに合図する必要があります。
The Broker MAY support continuing an existing Session, e.g., if the Broker requires it for QoS reasons. In this case, if a CONNECT packet is received with Clean Start set to 0, and there is a Session associated with the Client Identifier, the Broker MUST resume communications with the Client based on the state from the existing Session. In its response, the Broker MUST set the Session Present flag to 1 in the CONNACK packet to signal the continuation of an existing Session to the Client. The Session State stored by the Client and the Broker is described in Section 5.
ブローカーは、ブローカーがQoSの理由でそれを必要とする場合、既存のセッションの継続をサポートする場合があります。この場合、クリーンスタート設定が0に設定された接続パケットが受信され、クライアント識別子に関連付けられたセッションがある場合、ブローカーは既存のセッションの状態に基づいてクライアントとの通信を再開する必要があります。その応答において、ブローカーは、セッションの現在のフラグをConnackパケットの1に設定して、既存のセッションの継続をクライアントに合図する必要があります。クライアントとブローカーが保存するセッション状態については、セクション5に記載されています。
When reconnecting to a Broker that supports continuing existing Sessions, the Client MUST still provide a token in addition to using the same Client Identifier and setting the Clean Start to 0. The Broker MUST still perform PoP validation on the provided token. If the token matches the stored state, the Broker MAY skip introspecting a token-by-reference and use the stored introspection result. The Broker MUST also verify the Client is authorized to receive or send MQTT packets that are pending transmission. When a Client connects with a long Session Expiry Interval, the Broker may need to maintain the Client's MQTT Session State after it disconnects for an extended period. Brokers SHOULD implement administrative policies to limit misuse.
継続的な既存のセッションをサポートするブローカーに再接続する場合、クライアントは同じクライアント識別子を使用し、クリーンスタートを0に設定することに加えてトークンを提供する必要があります。ブローカーは、提供されたトークンでポップ検証を実行する必要があります。トークンが保存された状態と一致する場合、ブローカーはトークンごとの参照の内省をスキップし、保存された内省結果を使用する場合があります。ブローカーはまた、クライアントが保留中の送信であるMQTTパケットを受信または送信することを許可されていることを確認する必要があります。クライアントが長いセッションの有効期限間隔で接続する場合、ブローカーは、長期間切断された後、クライアントのMQTTセッション状態を維持する必要がある場合があります。ブローカーは、誤用を制限するために管理ポリシーを実装する必要があります。
Note that, according to the MQTT standard, the Broker uses the Client Identifier to identify the Session State. In the case of a Client Identifier collision, a Client may take over another Client's Session. Given that the Broker MUST associate the Client with a valid token, a Client will only send or receive messages to its authorized topics. Therefore, while this issue is not expected to affect security, it may affect QoS (i.e., PUBLISH or QoS messages saved for Client A may be delivered to a Client B). In addition, if this Client Identifier represents a Client already connected to the Broker, the Broker sends a DISCONNECT packet to the existing Client with reason code 0x8E (Session taken over) and closes the connection to the Client.
MQTT標準によれば、ブローカーはクライアント識別子を使用してセッション状態を識別することに注意してください。クライアント識別子の衝突の場合、クライアントは別のクライアントのセッションを引き継ぐことができます。ブローカーがクライアントを有効なトークンに関連付ける必要があることを考えると、クライアントは認可されたトピックにメッセージを送信または受信するだけです。したがって、この問題はセキュリティに影響を与えるとは予想されていませんが、QoSに影響を与える可能性があります（つまり、クライアントAに保存された公開またはQoSメッセージがクライアントbに配信される場合があります）。さらに、このクライアント識別子がブローカーに既に接続されているクライアントを表している場合、ブローカーは理由コード0x8e（セッションが引き継がれた）で既存のクライアントに切断パケットを送信し、クライアントへの接続を閉じます。
Figure 2 shows the Authentication Method and Authentication Data fields when the client authenticates using the AUTH property. The Client MUST set the Authentication Method as a property of a CONNECT packet by using the property identifier 21 (0x15). This is followed by a UTF-8-encoded string containing the name of the Authentication Method, which MUST be set to "ace". If the Broker does not support this profile, it sends a CONNACK packet with reason code 0x8C (Bad authentication method).
図2は、クライアントがAUTHプロパティを使用して認証するときの認証方法と認証データフィールドを示しています。クライアントは、プロパティ識別子21（0x15）を使用して、認証方法を接続パケットのプロパティとして設定する必要があります。これに続いて、認証方法の名前を含むUTF-8エンコード文字列が続きます。これは「ACE」に設定する必要があります。ブローカーがこのプロファイルをサポートしていない場合、Reason Code 0x8c（悪い認証方法）を備えたConnackパケットを送信します。
The Authentication Method is followed by the Authentication Data, which has a property identifier 22 (0x16) and is Binary Data. Based on the Authentication Data, the Broker MUST support both options below:
認証方法の後に、認証データが続きます。認証データは、プロパティ識別子22（0x16）を持ち、バイナリデータです。認証データに基づいて、ブローカーは以下の両方のオプションをサポートする必要があります。
* proof of possession using a challenge from the TLS session
* TLSセッションからの課題を使用した所有証明
* proof of possession via a Broker-generated challenge/response
* ブローカーで生成された課題/対応による所持の証明
+-----------------------------------------------------------------+
|Authentication|Token Length|Token |MAC or Signature |
|Data Length | | |(over TLS exporter content) |
+-----------------------------------------------------------------+
Figure 3: Authentication Data for PoP Based on TLS Exporter Content
図3：TLSエクスポートコンテンツに基づくPOPの認証データ
For this option, the Authentication Data inside the Client's CONNECT packet MUST contain the two-byte integer token length, the token, and the keyed message digest (MAC) or the Client signature (as shown in Figure 3). The Proof-of-Possession key in the token is used to calculate the keyed message digest (MAC) or the Client signature based on the content obtained from the TLS exporter ([RFC5705] for TLS 1.2 and Section 7.5 of [RFC8446] for TLS 1.3). This content is exported from the TLS session using the exporter label "EXPORTER-ACE-MQTT-Sign-Challenge", an empty context, and a length of 32 bytes. The token is also validated, as described in Section 2.2.5, and the Broker responds with a CONNACK packet with the appropriate response code. The Client cannot reauthenticate using this method during the same TLS session (see Section 4).
このオプションでは、クライアントの接続パケット内の認証データには、2バイトの整数トークン長、トークン、キー付きメッセージダイジェスト（MAC）またはクライアントの署名（図3を参照）を含める必要があります。トークンの入力証明キーは、TLS 1.2およびTLSの[RFC8446]のセクション7.5のTLS輸出国（[RFC5705]から得られたコンテンツに基づいて、キー付きメッセージダイジェスト（MAC）またはクライアントの署名を計算するために使用されます。1.3）。このコンテンツは、空のコンテキスト、および32バイトの長さであるExporterラベル「Exporter-ace-MQTT-Sign-Challenge」を使用して、TLSセッションからエクスポートされます。セクション2.2.5で説明されているように、トークンも検証され、ブローカーは適切な応答コードを使用してConnackパケットで応答します。クライアントは、同じTLSセッション中にこの方法を使用して再認証することはできません（セクション4を参照）。
+------------------------------------+
|Authentication|Token Length|Token |
|Data Length | | |
+------------------------------------+
Figure 4: Authentication Data to Initiate PoP Based on Challenge/ Response
図4：チャレンジ/応答に基づいてPOPを開始する認証データ
+--------------------------+
|Authentication|RS Nonce |
|Data Length |(8 bytes) |
+--------------------------+
Figure 5: Authentication Data for Broker Challenge
図5：ブローカーチャレンジの認証データ
For this option, the Broker follows a Broker-generated challenge/ response protocol. If the Authentication Data inside the Client's CONNECT contains only the two-byte integer token length and the token (as shown in Figure 4), the Broker MUST respond with an AUTH packet with the authenticated reason code set to 0x18 (Continue Authentication). The Broker also uses this method if the Authentication Data does not contain a token, but the Broker has a token stored for the connecting Client.
このオプションでは、ブローカーはブローカーで生成されたチャレンジ/応答プロトコルに従います。クライアントの接続内の認証データに2バイトの整数トークンの長さとトークンのみが含まれている場合（図4を示すように）、ブローカーは認証された理由コードを0x18に設定したAUTHパケットで応答する必要があります（認証を継続）。ブローカーは、認証データにトークンが含まれていない場合もこの方法を使用しますが、ブローカーには接続クライアント用のトークンが保存されています。
The Broker continues authentication using an AUTH packet that contains the Authentication Method and the Authentication Data. The Authentication Method MUST be set to "ace", and the Authentication Data MUST NOT be empty and MUST contain an 8-byte RS nonce as a challenge for the Client (Figure 5).
ブローカーは、認証方法と認証データを含む認証パケットを使用して認証を継続します。認証方法は「ACE」に設定する必要があり、認証データは空ではなく、クライアントの課題として8バイトのRS NonCEを含める必要があります（図5）。
+---------------------------------------------------------+
|Authentication|Client Nonce |MAC or Signature |
|Data Length |(8 bytes) |(over RS nonce+Client nonce)|
+---------------------------------------------------------+
Figure 6: Authentication Data for the Client Challenge Response
図6：クライアントチャレンジ応答の認証データ
The Client responds to this with an AUTH packet with reason code 0x18 (Continue Authentication). Similarly, the Client packet sets the Authentication Method to "ace". The Authentication Data in the Client's response is formatted as shown in Figure 6 and includes the 8-byte Client nonce and the signature or MAC computed over the RS nonce concatenated with the Client nonce using PoP key in the token.
クライアントは、Reason Code 0x18（継続認証）を備えたAuthパケットでこれに応答します。同様に、クライアントパケットは認証方法を「ACE」に設定します。クライアントの応答の認証データは、図6に示すようにフォーマットされており、8バイトクライアントNonceと、トークンのPOPキーを使用してクライアントNonCeと連結されたRS Nonceで計算された署名またはMacが含まれます。
Next, the token is validated as described in Section 2.2.5. The success case is illustrated in Figure 7. The Client MAY also reauthenticate using this challenge-response flow, as described in Section 4.
次に、トークンはセクション2.2.5で説明されているように検証されます。成功事例を図7に示します。クライアントは、セクション4で説明されているように、この課題反応の流れを使用して再認証することもできます。
Client Broker
| |
|<===========>| TLS connection setup
| |
| |
+------------>| CONNECT with Authentication Data
| | contains only token
| |
<-------------+ AUTH 0x18 (Cont. Authentication)
| | 8-byte RS nonce as challenge
| |
|------------>| AUTH 0x18 (Cont. Authentication)
| | 8-byte Client nonce + signature/MAC
| |
| |---+ Token validation
| | | (may involve introspection)
| |<--+
| |
|<------------+ CONNACK 0x00 (Success)
Figure 7: PoP Challenge/Response Flow - Success
図7：ポップチャレンジ/応答フロー - 成功
The Broker MUST verify the validity of the token either locally (e.g., in the case of a self-contained token) or MAY send a request to the introspection endpoint of the AS (as described for HTTP-based interactions in Section 5.9 of the ACE framework [RFC9200]). The Broker MUST verify the claims in the access token according to the rules set in Section 5.10.1.1 of the ACE framework [RFC9200].
ブローカーは、局所的にトークンの妥当性を検証する必要があります（たとえば、自己完結型トークンの場合）、またはASの内省エンドポイントにリクエストを送信する必要があります（ACEのセクション5.9のHTTPベースの相互作用について説明するようにフレームワーク[RFC9200]）。ブローカーは、ACEフレームワーク[RFC9200]のセクション5.10.1.1に設定されたルールに従って、アクセストークンのクレームを確認する必要があります。
To authenticate the Client, the Broker validates the signature or the MAC, depending on how the PoP protocol is implemented. For self-contained tokens, the Broker MUST process the security protection of the token first, as specified by the respective token format, i.e., a CWT uses COSE, while a JWT uses JOSE. For a token-by-reference, the Broker uses the "cnf" structure returned as a result of token introspection, as specified in [RFC7519]. HMAC-SHA-256 (HS256) [RFC6234] and Ed25519 [RFC8032] are mandatory to implement for the Broker. The Client MUST implement at least one of them depending on the choice of symmetric or asymmetric validation. Validation of the signature or MAC MUST fail if the signature algorithm is set to "none" when the key used for the signature algorithm cannot be determined or the computed and received signature/MAC do not match.
クライアントを認証するために、ブローカーは、POPプロトコルの実装方法に応じて、署名またはMacを検証します。自己完結型のトークンの場合、ブローカーは、それぞれのトークン形式で指定されているように、最初にトークンのセキュリティ保護を処理する必要があります。つまり、CWTはCOSEを使用し、JWTはホセを使用します。トークンごとに参照するために、ブローカーは[RFC7519]で指定されているように、トークン内省の結果として返された「CNF」構造を使用します。HMAC-SHA-256（HS256）[RFC6234]およびED25519 [RFC8032]は、ブローカーのために実装することが必須です。クライアントは、対称または非対称検証の選択に応じて、少なくとも1つを実装する必要があります。署名アルゴリズムが署名アルゴリズムに使用されているキーを決定できない場合、または計算および受信した署名/Macが一致しない場合、署名アルゴリズムが「なし」に設定されている場合、署名またはMacの検証が失敗する必要があります。
The Broker MUST check if the access token is still valid, if it is the intended destination (i.e., the audience) of the token, and if the token was issued by an authorized Authorization Server. If the Client is using TLS RPK mode to authenticate to the Broker, the AS constructs the access token so that the Broker can associate the access token with the Client's public key. The "cnf" claim MUST contain either the Client's RPK or, if the key is already known by the Broker (e.g., from previous communication), a reference to it.
ブローカーは、アクセストークンがまだ有効であるか、トークンの目的の宛先（視聴者）であるかどうか、トークンが承認承認サーバーによって発行されたかどうかを確認する必要があります。クライアントがTLS RPKモードを使用してブローカーに認証している場合、ASはアクセストークンを構築して、ブローカーがアクセストークンをクライアントの公開キーに関連付けることができます。「CNF」クレームには、クライアントのRPKまたはキーがブローカー（以前のコミュニケーションから）に既にわかっている場合（以前のコミュニケーションから）、それを参照する必要があります。
The scope field contains the publish and subscribe permissions for the Client. Therefore, the token or its introspection result MUST be cached to allow a Client's future PUBLISH and SUBSCRIBE messages. During the CONNECT, if the Will Flag is set to 1, the Broker MUST also authorize the publication of the Will Topic and Will Message using the token's scope field. The Broker uses the scope to match against the Topic Name in a PUBLISH packet (including Will Topic in the CONNECT) or a Topic Filter in a SUBSCRIBE packet.
スコープフィールドには、クライアントの公開および購読許可が含まれています。したがって、クライアントの将来の公開および購読メッセージを許可するために、トークンまたはその内省結果をキャッシュする必要があります。接続中、Willフラグが1に設定されている場合、ブローカーはWillトピックの公開も承認する必要があり、Tokenのスコープフィールドを使用してWillにメッセージを送信する必要があります。ブローカーは、スコープを使用して、公開パケットのトピック名（ConnectのWillトピックを含む）またはサブスクライブパケットのトピックフィルターと一致します。
The scope in the token is a single value. For a JWT, the single scope is a base64url-encoded string with any padding characters removed, which has an internal structure of a JSON array. For a CWT, this information is represented in CBOR. The internal structure follows the Authorization Information Format (AIF) for ACE [RFC9237]. Using the Concise Data Definition Language (CDDL) [RFC8610], the specific data model for MQTT is:
トークンのスコープは単一の値です。JWTの場合、単一のスコープは、jsonアレイの内部構造を持つパディング文字が削除されたbase64urlエンコード文字列です。CWTの場合、この情報はCBORで表されます。内部構造は、ACE [RFC9237]の承認情報形式（AIF）に従います。簡潔なデータ定義言語（CDDL）[RFC8610]を使用して、MQTTの特定のデータモデルは次のとおりです。
AIF-MQTT = AIF-Generic<mqtt-topic-filter, mqtt-permissions>
AIF-Generic<Toid, Tperm> = [* [Toid, Tperm]]
mqtt-topic-filter = tstr ; as per Section 4.7 of MQTT v5.0
mqtt-permissions = [+permission]
permission = "pub"/"sub"
Figure 8: AIF-MQTT Data Model
図8：AIF-MQTTデータモデル
Topic Filters are implemented according to Section 4.7 of the MQTT v5.0 OASIS Standard [MQTT-OASIS-Standard-v5]. By default, Wildcard Subscriptions are supported, and so, the Topic Filter may include special wildcard characters. The multi-level wildcard, "#", matches any number of levels within a topic, and the single-level wildcard, "+", matches one topic level. The Broker MAY signal in the CONNACK explicitly whether Wildcard Subscriptions are supported by returning a CONNACK property "Wildcard Subscription Available". A value of 0 means that Wildcard Subscriptions are not supported. A value of 1 means Wildcard Subscriptions are supported.
トピックフィルターは、MQTT V5.0 OASIS標準[MQTT-Oasis-Standard-V5]のセクション4.7に従って実装されています。デフォルトでは、ワイルドカードサブスクリプションがサポートされているため、トピックフィルターには特別なワイルドカード文字が含まれる場合があります。マルチレベルのワイルドカード「＃」は、トピック内の任意の数のレベルと一致し、シングルレベルのワイルドカード「」は1つのトピックレベルと一致します。ブローカーは、Connackプロパティ「WildCardサブスクリプションが利用可能」を返すことでワイルドカードサブスクリプションがサポートされているかどうかをConnackで明示的に合図する場合があります。0の値は、ワイルドカードサブスクリプションがサポートされていないことを意味します。1の値は、ワイルドカードサブスクリプションがサポートされていることを意味します。
Following this model, an example scope may contain:
このモデルに従って、例のスコープには次のものが含まれている場合があります。
[["topic1",["pub","sub"]],["topic2/#",["pub"]],["+/topic3",["sub"]]]
Figure 9: Example Scope
図9：例の範囲
This access token gives publish ("pub") and subscribe ("sub") permissions to the "topic1", publish permission to all the subtopics of "topic2", and subscribe permission to all "topic3", skipping one level.
このアクセストークンは、パブリッシュ（ "Pub"）と「topic1」への購読（「sub」）許可を与え、「Topic2」のすべてのサブトピックに許可を公開し、すべての「Topic3」に許可をサブスクライブし、1つのレベルをスキップします。
If the scope is empty, the Broker records no permissions for the Client for any topic. In this case, the Client is not able to publish or subscribe to any protected topics. The non-empty scope is used to authorize the Will Topic, if provided, in the CONNECT packet, during connection setup and, if the connection request succeeds, the Topic Names or Topic Filters requested in the future PUBLISH and SUBSCRIBE packets. For the authorization to succeed, the Broker MUST verify that the Topic Name or Topic Filter in question is either an exact match to or a subset of at least one "topic_filter" in the scope.
スコープが空の場合、ブローカーは、トピックについてクライアントの権限を記録しません。この場合、クライアントは保護されたトピックを公開または購読することはできません。空でないスコープは、接続パケットで、接続セットアップ中にWILLトピックを承認するために使用され、接続要求が成功した場合、将来のパケットを公開および購読するトピック名またはトピックフィルターを承認します。成功するためには、ブローカーは、問題のトピック名またはトピックフィルターが、範囲内の少なくとも1つの「topic_filter」の正確な一致またはサブセットであることを確認する必要があります。
Based on the validation result (obtained either via local inspection or using the introspection interface of the AS), the Broker MUST send a CONNACK packet to the Client.
検証結果に基づいて（ローカル検査またはASの内省インターフェイスを使用して取得）、ブローカーはクライアントにConnackパケットを送信する必要があります。
Authentication can fail for the following reasons:
認証は次の理由で失敗する可能性があります。
* if the Client does not provide a valid token,
* クライアントが有効なトークンを提供していない場合、
* the Client omits the Authentication Data field and the Broker has no token stored for the Client,
* クライアントは認証データフィールドを省略し、ブローカーにはクライアントに保存されているトークンがありません。
* the token or Authentication data are malformed, or
* トークンまたは認証データは奇形です
* if the Will Flag is set, the authorization checks for the Will Topic fails.
* Willフラグが設定されている場合、Willトピックの認可チェックは失敗します。
The Broker responds with the CONNACK reason code 0x87 (Not Authorized) or any other applicable reason code.
ブローカーは、Connack理由コード0x87（許可されていない）またはその他の適用される理由コードで応答します。
The Broker MAY also trigger AS discovery and include a User Property (identified as property type 38 (0x26)) in the CONNACK for the AS Request Creation Hints. 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 object containing the mandatory "AS" parameter and the optional parameters "audience", "kid", "cnonce", and "scope", as defined in Section 5.3 of the ACE framework [RFC9200].
ブローカーは、発見としてトリガーし、ASリクエスト作成のヒントのコナックにユーザープロパティ（プロパティタイプ38（0x26）として識別）を含めることもできます。ユーザープロパティは、名前と値で構成されるUTF-8文字列ペアです。ユーザープロパティの名前は、「ace_as_hint」に設定する必要があります。ユーザープロパティの値は、「パラメーター」として「パラメーター」と「「kid」、「cnonce」、「scope」として「パラメーター」と「パラメーター」として「パラメーター」、「scope」として「パラメーター」を含むUTF-8エンコードのJSONオブジェクトです。ACEフレームワーク[RFC9200]。
On success, the reason code of the CONNACK is 0x00 (Success). If the Broker starts a new Session, it MUST also set Session Present to 0 in the CONNACK packet to signal a new Session to the Client. Otherwise, it MUST set Session Present to 1.
成功すると、Connackの理由は0x00（成功）です。ブローカーが新しいセッションを開始する場合、Connackパケットのセッションの存在を0に設定して、クライアントに新しいセッションを知らせる必要があります。それ以外の場合は、セッションを1に設定する必要があります。
Having accepted the connection, the Broker MUST be prepared to store the token during the connection and after disconnection for future use. If the token is not self-contained and the Broker uses token introspection, it MAY cache the validation result to authorize the subsequent PUBLISH and SUBSCRIBE packets. PUBLISH and SUBSCRIBE packets, which are sent after a connection setup, do not contain access tokens. If the introspection result is not cached, the Broker needs to introspect the saved token for each request. The Broker SHOULD also use a cache timeout to introspect tokens regularly. The timeout value is specific to the application and should be chosen to reduce the risk of using stale introspection responses.
接続を受け入れた後、ブローカーは、接続中および将来の使用のために切断後にトークンを保存する準備をしなければなりません。トークンが自己完結型ではなく、ブローカーがトークン内省を使用している場合、検証結果をキャッシュして後続のパブリックパケットと購読パケットを承認する場合があります。接続のセットアップ後に送信されるパケットを公開および購読するには、アクセストークンが含まれていません。内省結果がキャッシュされていない場合、ブローカーは各リクエストに対して保存されたトークンを内省する必要があります。ブローカーはまた、キャッシュタイムアウトを使用して、トークンを定期的に内省する必要があります。タイムアウト値はアプリケーションに固有であり、古い内省反応を使用するリスクを減らすために選択する必要があります。
Using the cached token or its introspection result, the Broker uses the scope field to match against the Topic Name in a PUBLISH packet or a Topic Filter in a SUBSCRIBE packet.
キャッシュされたトークンまたはその内省結果を使用して、ブローカーはスコープフィールドを使用して、サブスクライブパケットのパブリッシュパケットまたはトピックフィルターのトピック名と一致します。
On receiving the PUBLISH packet, the Broker MUST use the type of packet (i.e., PUBLISH) and the Topic Name in the packet header to match against the scope array items in the cached token or its introspection result. Following the example in Section 2.3, the Client sending a PUBLISH packet for "topic2/a" would be allowed, as the scope array includes the ["topic2/#",["pub"]].
パブリッシュパケットを受信すると、ブローカーはパケットの種類（パブリッシュ）とパケットヘッダーのトピック名を使用して、キャッシュされたトークンのスコープアレイアイテムまたはその内省結果と一致する必要があります。セクション2.3の例に従って、スコープアレイには["Topic2/＃"、["pub"]]が含まれているため、「トピック2/a」のパブリッシュパケットを送信するクライアントが許可されます。
If the Client is allowed to publish to the topic, the Broker publishes the message to all valid subscribers of the topic. In the case of an authorization failure, the Broker MUST return an error if the Client has set the QoS level of the PUBLISH packet to greater than or equal to 1. Depending on the QoS level, the Broker responds with either a PUBACK or PUBREC packet with reason code 0x87 (Not authorized). On receiving an acknowledgment with 0x87 (Not authorized), the Client MAY reauthenticate by providing a new token, as described in Section 4.
クライアントがトピックに公開することを許可されている場合、ブローカーはトピックのすべての有効なサブスクライバーにメッセージを公開します。承認障害の場合、ブローカーは、クライアントがパブリックパケットのQOSレベルを1以上に設定している場合、エラーを返す必要があります。QOSレベルに応じて、ブローカーはPubackまたはPubrecパケットで応答します。理由コード0x87（許可されていません）。セクション4で説明されているように、クライアントは0x87（許可されていない）での承認を受け取ると、新しいトークンを提供することにより再認証できます。
For QoS level 0, the Broker sends a DISCONNECT packet with reason code 0x87 (Not authorized) and closes the Network Connection. Note that the server-side DISCONNECT is a new feature of MQTT v5.0 (in MQTT v3.1.1, the server needs to drop the connection).
QoSレベル0の場合、ブローカーは理由コード0x87（許可されていない）を使用して切断パケットを送信し、ネットワーク接続を閉じます。サーバー側の切断は、MQTT V5.0の新機能であることに注意してください（MQTT v3.1.1では、サーバーが接続をドロップする必要があります）。
For all QoS levels, the Broker MAY return 0x80 (Unspecified error) if they do not want to leak the Topic Names to unauthorized clients.
すべてのQoSレベルについて、ブローカーは、トピック名を不正なクライアントに漏らしたくない場合、0x80（不特定のエラー）を返す場合があります。
To forward PUBLISH packets to the subscribing Clients, the Broker identifies all the subscribers that have valid matching Topic Subscriptions to the Topic Name of the PUBLISH packet (i.e., the tokens are valid, and token scopes allow a Subscription to this particular Topic Name). The Broker forwards the PUBLISH packet to all the valid subscribers.
パケットをサブスクライティングクライアントに転送するために、ブローカーは、パブリックパケットのトピック名に有効な一致するトピックサブスクリプションを持っているすべてのサブスクライバーを識別します（つまり、トークンは有効であり、トークンスコープはこの特定のトピック名のサブスクリプションを許可します）。ブローカーは、すべての有効なサブスクライバーにPublish Packetを転送します。
The Broker MUST NOT forward messages to unauthorized subscribers. To avoid silently dropping messages, the Broker MUST close the Network Connection and SHOULD inform the affected subscribers. In this case, the only way to inform a client would be sending a DISCONNECT packet. Therefore, the Broker SHOULD send a DISCONNECT packet with reason code 0x87 (Not authorized) before closing the Network Connection to these clients.
ブローカーは、不正なサブスクライバーにメッセージを転送してはなりません。静かにメッセージを削除するのを避けるために、ブローカーはネットワーク接続を閉じ、影響を受ける加入者に通知する必要があります。この場合、クライアントに通知する唯一の方法は、切断パケットを送信することです。したがって、ブローカーは、これらのクライアントへのネットワーク接続を閉じる前に、理由コード0x87（許可されていない）を使用して切断パケットを送信する必要があります。
In MQTT, a SUBSCRIBE packet is sent from a Client to the Broker to create one or more Subscriptions to one or more topics. The SUBSCRIBE packet may contain multiple Topic Filters. The Topic Filters may include wildcard characters.
MQTTでは、サブスクライブパケットがクライアントからブローカーに送信され、1つ以上のトピックに1つ以上のサブスクリプションを作成します。購読パケットには、複数のトピックフィルターが含まれる場合があります。トピックフィルターには、ワイルドカード文字が含まれる場合があります。
On receiving the SUBSCRIBE packet, the Broker MUST use the type of packet (i.e., SUBSCRIBE) and the Topic Filter in the packet header to match against the scope field of the stored token or introspection result. The Topic Filters MUST be an exact match to or be a subset of at least one of the "topic_filter" fields in the scope array found in the Client's token. For example, if the Client sends a SUBSCRIBE request for topic "a/b/*" and has a token that permits "a/*", this is a valid SUBSCRIBE request, as "a/b/*" is a subset of "a/*". (The process is similar to a Broker matching the Topic Name in a PUBLISH packet against the Subscriptions known to the Server.)
購読パケットを受信すると、ブローカーは、保存されたトークンまたは内省結果のスコープフィールドと一致するように、パケットヘッダーのタイプのパケット（つまり、サブスクライブ）とトピックフィルターを使用する必要があります。トピックフィルターは、クライアントのトークンで見つかったスコープアレイの「Topic_Filter」フィールドの少なくとも1つのサブセットと一致するか、またはサブセットでなければなりません。たとえば、クライアントがトピック「a/b/*」のサブスクライブリクエストを送信し、「a/*」を許可するトークンを持っている場合、これは「a/b/*」がサブセットであるため、有効なサブスクライブリクエストです。「A/*」。（このプロセスは、サーバーに既知のサブスクリプションに対してパケットパケットのトピック名を一致させるブローカーに似ています。）
As a response to the SUBSCRIBE packet, the Broker issues a SUBACK packet. For each Topic Filter, the SUBACK packet includes a return code matching the QoS level for the corresponding Topic Filter. In the case of failure, the return code is 0x87, indicating that the Client is not authorized. The Broker MAY return 0x80 (Unspecified error) if they do not want to leak the Topic Names to unauthorized clients. A reason code is returned for each Topic Filter. Therefore, the Client may receive success codes for a subset of its Topic Filters while being unauthorized for the rest.
購読パケットへの応答として、ブローカーはSubackパケットを発行します。各トピックフィルターについて、Subackパケットには、対応するトピックフィルターのQoSレベルに一致するリターンコードが含まれています。障害の場合、返品コードは0x87であり、クライアントが許可されていないことを示しています。ブローカーは、トピック名を不正なクライアントに漏らしたくない場合、0x80（不特定のエラー）を返す場合があります。各トピックフィルターに対して理由コードが返されます。したがって、クライアントは、トピックフィルターのサブセットのサクセスコードを受け取ることができますが、残りは不正であることがあります。
The Broker MUST check for token expiration whenever a CONNECT, PUBLISH, or SUBSCRIBE packet is received or sent. The Broker SHOULD check for token expiration on receiving a PINGREQ packet. The Broker MAY also check for token expiration periodically, e.g., every hour. This may allow for early detection of a token expiry.
ブローカーは、接続、公開、または購読パケットを受信または送信するたびに、トークンの有効期限を確認する必要があります。ブローカーは、PingReqパケットの受信時にトークンの有効期限を確認する必要があります。ブローカーは、たとえば1時間ごとに定期的にトークンの有効期限を確認することもできます。これにより、トークンの有効期限が早期に検出される可能性があります。
The token expiration is checked by checking the "exp" claim of a JWT or introspection response or via performing an introspection request with the AS, as described in Section 5.9 of the ACE framework [RFC9200]. Token expirations may trigger the Broker to send PUBACK, SUBACK, and DISCONNECT packets with the return code set to "Not authorized". After sending a DISCONNECT packet, the Network Connection is closed, and no more messages can be sent.
トークンの有効期限は、JWTまたは内省的応答の「EXP」クレームをチェックするか、ACEフレームワーク[RFC9200]のセクション5.9で説明されているように、ASで内省要求を実行することによりチェックされます。トークンの満了は、ブローカーが「承認されていない」に設定された返品コードを使用してパケットを送信し、サブカックし、パケットを切断し、パケットを切断するようにトリガーする場合があります。切断パケットを送信した後、ネットワーク接続が閉じられ、これ以上メッセージを送信できません。
The Client MAY reauthenticate a response to PUBACK and SUBACK, which signal loss of authorization. The Clients MAY also proactively update their tokens, i.e., before they receive a packet with a "Not authorized" return code. To start reauthentication, the Client MUST send an AUTH packet with reason code 0x19 (Reauthentication). The Client MUST set the Authentication Method as "ace" and transport the new token in the Authentication Data. If reauthenticating during the current TLS session, the Client MUST NOT use the method described in Section 2.2.4.2.1, i.e., proof of possession using a challenge from the TLS session, to avoid reusing the same challenge value from the TLS-Exporter. Note that this means that servers will either need to record in the session ticket or database entry whether the TLS-Exporter-derived challenge was used or always deny use of the TLS-Exporter-derived challenge for resumed sessions. In TLS 1.3, the resumed connection would have a new exporter value, but the requirement is phrased this way for simplicity. For reauthentications in the same TLS-session, the Client MUST use the challenge-response PoP, as defined in Section 2.2.4.2.2. The Broker accepts reauthentication requests if the Client has already submitted a token (may be expired), for which it performed proof of possession. Otherwise, the Broker MUST deny the request. If the reauthentication fails, the Broker MUST send a DISCONNECT packet with reason code 0x87 (Not Authorized).
クライアントは、承認の喪失を示すPubackおよびSubackへの応答を再認証する場合があります。クライアントは、「認定されていない」返品コードを備えたパケットを受信する前に、トークンを積極的に更新することもできます。再認証を開始するには、クライアントはReason Code 0x19（再認証）を備えたAUTHパケットを送信する必要があります。クライアントは、認証方法を「ACE」として設定し、認証データに新しいトークンを輸送する必要があります。現在のTLSセッション中に再保証する場合、クライアントはセクション2.2.4.2.1で説明されている方法、つまりTLSセッションからの課題を使用して所持の証明を使用しては、TLS-Exporterから同じ課題の値を再利用しないようにしてはなりません。これは、サーバーがセッションチケットまたはデータベースエントリにTLS-Exporter由来の課題が使用されたかどうかを記録する必要があることを意味するか、再開されたセッションのためにTLS-Exporter由来のチャレンジの使用を常に拒否することを意味することに注意してください。TLS 1.3では、再開された接続には新しい輸出者値がありますが、要件はこの方法で簡単に表現されます。同じTLSセッションでの再認証のために、セクション2.2.4.2.2で定義されているように、クライアントはチャレンジ応答POPを使用する必要があります。ブローカーは、クライアントが既にトークンを提出している（期限が切れている可能性がある）かどうかの再認証要求を受け入れ、そのために所有証明を実行しました。それ以外の場合、ブローカーはリクエストを拒否する必要があります。再認証が失敗した場合、ブローカーは理由コード0x87を使用して切断パケットを送信する必要があります（許可されていません）。
In the case of a Client DISCONNECT, if the Session Expiry Interval is set to 0, the Broker doesn't store the Session State but MUST keep the retained messages. If the Broker stores the Session State, the state MAY include the token and its introspection result (for reference tokens) in addition to the MQTT Session State. The MQTT Session State is identified by the Client Identifier and includes the following:
クライアントの切断の場合、セッションの有効期限間隔が0に設定されている場合、ブローカーはセッション状態を保存せず、保持されたメッセージを保持する必要があります。ブローカーがセッション状態を保存している場合、状態には、MQTTセッション状態に加えて、トークンとその内省結果（参照トークン用）を含めることができます。MQTTセッションの状態は、クライアント識別子によって識別され、以下が含まれます。
* the Client Subscriptions,
* クライアントのサブスクリプション、
* messages with QoS levels 1 and 2, which have not been completely acknowledged or are pending transmission to the Client, and
* QoSレベル1および2のメッセージは、完全に認められていないか、クライアントへの送信が保留されていません。
* if the Session is currently not connected, the time at which the Session will end and the Session State will be discarded.
* セッションが現在接続されていない場合、セッションが終了し、セッション状態が廃棄される時間。
The token/introspection state is not part of the MQTT Session State, and PoP validation is required for each new connection, regardless of whether existing MQTT Sessions are continued.
トークン/内省状態はMQTTセッション状態の一部ではなく、既存のMQTTセッションが継続されているかどうかにかかわらず、新しい接続ごとにポップ検証が必要です。
The messages to be retained are indicated to the Broker by setting a RETAIN flag in a PUBLISH packet. This way, the publisher signals to the Broker to store the most recent message for the associated topic. Hence, the new subscribers can receive the last sent message from the publisher for that particular topic without waiting for the next PUBLISH packet. The Broker MUST continue publishing the retained messages as long as the associated tokens are valid. In the MQTT standard, if QoS is 0 for the PUBLISH packet, the Broker may discard the retained message any time. For QoS > 1, the message expiry interval dictates how long the retained message is kept. However, it is important that the Broker avoids sending messages indefinitely for the Clients that never update their tokens (i.e., the Client connects briefly with a valid token, sends a PUBLISH packet with the RETAIN flag set to 1 and QoS > 1, disconnects, and never connects again). Therefore, the Broker MUST use the minimum of the token expiry and message expiry interval to discard a retained message.
保持されるメッセージは、パブリッシュパケットに[フラグ]を設定することにより、ブローカーに示されます。このようにして、出版社はブローカーに通知し、関連するトピックの最新のメッセージを保存します。したがって、新しいサブスクライバーは、次のパブリッシュパケットを待つことなく、その特定のトピックのパブリッシャーから最後の送信メッセージを受信できます。ブローカーは、関連するトークンが有効である限り、保持されたメッセージを公開し続ける必要があります。MQTT標準では、QOSがパケットパケットの場合は0の場合、ブローカーはいつでも保持されたメッセージを破棄する場合があります。QOS> 1の場合、メッセージの有効期限間隔は、保持されたメッセージの保持期間を決定します。ただし、ブローカーがトークンを更新しないクライアントにメッセージを無期限に送信することを避けることが重要です（つまり、クライアントは有効なトークンと簡単に接続し、flagセットを1およびqos> 1に設定してパブリッシュパケットを送信します。二度と接続しないでください）。したがって、ブローカーは、保持されたメッセージを破棄するために、トークンの有効期限とメッセージの有効期限間隔の最小値を使用する必要があります。
In case of disconnections due to network errors or server disconnection due to a protocol error (which includes authorization errors), the Will Message is sent if the Client supplied a Will in the CONNECT packet. The Client's token scope array MUST include the Will Topic. The Will Message MUST be published to the Will Topic, regardless of whether the corresponding token has expired (as it has been validated and accepted during CONNECT).
ネットワークエラーまたはプロトコルエラーによるサーバー切断による切断の場合（認証エラーを含む）、クライアントがConnectパケットにWillを提供した場合にWillメッセージが送信されます。クライアントのトークンスコープアレイには、Willトピックを含める必要があります。Willメッセージは、対応するトークンの有効期限が切れているかどうかにかかわらず、Willトピックに公開する必要があります（Connect中に検証および受け入れられたため）。
This section describes a reduced set of protocol interactions for the MQTT v3.1.1 Clients. An MQTT v5.0 Broker MAY implement these interactions for the MQTT v3.1.1 Clients; the flows described in this section are NOT RECOMMENDED for use by MQTT v5.0 Clients. Brokers that do not support MQTT v3.1.1 Clients return a CONNACK packet with reason code 0x84 (Unsupported Protocol Version) in response to the connection requests.
このセクションでは、MQTT V3.1.1クライアントのプロトコル相互作用の削減について説明します。MQTT V5.0ブローカーは、MQTT V3.1.1クライアントにこれらの相互作用を実装できます。このセクションで説明するフローは、MQTT V5.0クライアントが使用することをお勧めしません。MQTT V3.1.1クライアントをサポートしていないブローカーは、接続要求に応じてReason Code 0x84（サポートされていないプロトコルバージョン）を使用してConnackパケットを返します。
As in MQTT v5.0, the token MAY either be transported before, by publishing to the "authz-info" topic, or inside the CONNECT packet. If the Client provided the token via the "authz-info" topic and will not update the token in the CONNECT packet, it MUST authenticate over TLS. The Broker SHOULD still be prepared to store the Client access token for future use (regardless of the method of transport).
MQTT v5.0のように、トークンは、「authz-info」トピックに公開するか、または接続パケット内に公開することにより、前に輸送される場合があります。クライアントが「authz-info」トピックを介してトークンを提供し、接続パケットでトークンを更新しない場合、TLSを超えて認証する必要があります。ブローカーは、将来の使用のためにクライアントアクセストークンを保存する準備をする必要があります（輸送方法に関係なく）。
In MQTT v3.1.1, after the Client has published to the "authz-info" topic, the Broker cannot communicate the result of the token validation because PUBACK reason codes or server-side DISCONNECT packets are not supported. In any case, the subsequent TLS handshake would fail without a valid token, which can prompt the Client to obtain a valid token.
MQTT v3.1.1では、クライアントが「authz-info」トピックに公開した後、ブローカーはトークン検証の結果を通信できません。いずれにせよ、その後のTLSハンドシェイクは、有効なトークンなしで失敗し、クライアントに有効なトークンを取得するように促す可能性があります。
To transport the token to the Broker inside the CONNECT packet, the Client uses the User Name and Password fields. Figure 10 shows the structure of the MQTT CONNECT packet.
トークンを接続パケット内のブローカーに輸送するには、クライアントはユーザー名とパスワードフィールドを使用します。図10は、MQTT接続パケットの構造を示しています。
0 8 16
+---------------------------+
|Protocol name length = 4 |
+---------------------------+
| 'M' 'Q' |
+---------------------------+
| 'T' 'T' |
+---------------------------+
|Proto.level=5|Connect flags|
+---------------------------+
| Keep alive |
+---------------------------+
| Payload |
| Client Identifier |
| (UTF-8-encoded string) |
| User Name as access token |
| (UTF-8-encoded string) |
| Password for signature/MAC|
| (Binary Data) |
+---------------------------+
Figure 10: MQTT CONNECT Variable Header Using a User Name and Password for ACE
図10：MQTT接続変数ヘッダーユーザー名とエースのパスワードを使用して
Table 2 shows how the MQTT connect flags MUST be set to initiate a connection with the Broker.
表2は、ブローカーとの接続を開始するためにMQTT Connectフラグを設定する方法を示しています。
+================+==========+========+======+======+=======+=======+
| User Name Flag | Password | Will | Will | Will | Clean | Rsvd. |
| | Flag | Retain | QoS | Flag | | |
+================+==========+========+======+======+=======+=======+
| 1 | 1 | X | X X | X | X | 0 |
+----------------+----------+--------+------+------+-------+-------+
Table 2: MQTT CONNECT Flags (Rsvd. = Reserved)
表2：MQTT接続フラグ（RSVD。=予約済み）
The Client SHOULD set the Clean flag to 1 to always start a new Session. If the Clean flag is set to 0, the Broker MUST resume communications with the Client based on the state from the current Session (as identified by the Client Identifier). If there is no Session associated with the Client Identifier, the Broker MUST create a new Session. The Broker MUST set the Session Present flag in the CONNACK packet accordingly, i.e., 0 to indicate a new Session to the Client and 1 to indicate that the existing Session is continued. The Broker MUST still perform PoP validation on the provided Client token. MQTT v3.1.1 does not use a Session Expiry Interval, and the Client expects that the Broker maintains the Session State after it disconnects. However, the stored Session State can be discarded as a result of administrator action or policies (e.g., defining an automated response based on storage capabilities), and Brokers SHOULD implement administrative policies to limit misuse.
クライアントは、常に新しいセッションを開始するために、クリーンフラグを1に設定する必要があります。クリーンフラグが0に設定されている場合、ブローカーは、現在のセッションから州に基づいてクライアントとの通信を再開する必要があります（クライアント識別子によって識別されます）。クライアント識別子に関連付けられたセッションがない場合、ブローカーは新しいセッションを作成する必要があります。ブローカーは、それに応じてConnack Packetにセッションの現在のフラグを設定する必要があります。つまり、クライアントに新しいセッションを示し、既存のセッションが継続されていることを示すために1を示す必要があります。ブローカーは、提供されたクライアントトークンで引き続きPOP検証を実行する必要があります。MQTT V3.1.1はセッションの有効期限間隔を使用せず、クライアントは、ブローカーが切断された後にセッション状態を維持することを期待しています。ただし、保存されたセッション状態は、管理者のアクションまたはポリシー（たとえば、ストレージ機能に基づいて自動化された応答を定義する）の結果として破棄できます。ブローカーは、誤用を制限するために管理ポリシーを実装する必要があります。
The Client MAY set the Will Flag as desired (marked as "X" in Table 2). User Name and Password flags MUST be set to 1 to ensure that the Payload of the CONNECT packet includes both the User Name and Password fields. The MQTT User Name is a UTF-8-encoded string, and the MQTT Password is Binary Data.
クライアントは、必要に応じてWillフラグを設定できます（表2の「x」とマークされています）。ユーザー名とパスワードフラグを1に設定する必要があります。接続パケットのペイロードには、ユーザー名とパスワードフィールドの両方が含まれるようにします。MQTTユーザー名はUTF-8エンコード文字列であり、MQTTパスワードはバイナリデータです。
The CONNECT in MQTT v3.1.1 does not have a field to indicate the Authentication Method. To signal that the User Name field contains an ACE token, this field MUST be prefixed with the keyword "ace", i.e., the User Name field is a concatenation of 'a', 'c', 'e', and the access token represented as:
MQTT v3.1.1の接続には、認証方法を示すフィールドがありません。ユーザー名フィールドにACEトークンが含まれていることを示すには、このフィールドにキーワード「ACE」が付いている必要があります。つまり、ユーザー名フィールドは「A」、「C '、「E」、およびアクセストークンの連結です。表現：
'U+0061'||'U+0063'||'U+0065'||UTF-8(access token)
Figure 11: User Name in CONNECT
図11：接続のユーザー名
To this end, the access token MUST be encoded with base64url, omitting the "=" padding characters [RFC4648].
この目的のために、アクセストークンはbase64urlでエンコードする必要があり、「=」パディング文字[RFC4648]を省略する必要があります。
The Password field MUST be set to the keyed message digest (MAC) or signature associated with the access token for PoP. The Client MUST apply the PoP key on the challenge derived from the TLS session, as described in Section 2.2.4.2.1.
パスワードフィールドは、キー付きメッセージダイジェスト（MAC）またはPOPのアクセストークンに関連付けられた署名に設定する必要があります。セクション2.2.4.2.1で説明されているように、クライアントはTLSセッションから派生したチャレンジにPOPキーを適用する必要があります。
Error handling is more primitive in MQTT v3.1.1 due to not having appropriate error fields, error codes, and server-side DISCONNECTs. Therefore, the Broker will disconnect on almost any error and may not keep the Session State, necessitating that clients make a greater effort to ensure that tokens remain valid and do not attempt to publish to topics that they do not have permissions for. The following lists how the Broker responds to specific errors.
適切なエラーフィールド、エラーコード、サーバー側の切断がないため、MQTT v3.1.1ではエラー処理がより原始的です。したがって、ブローカーはほぼすべてのエラーを切断し、セッション状態を維持しない可能性があり、クライアントがトークンが有効であり続け、許可がないトピックに公開しようとしないようにするために、より大きな努力をする必要があります。次のリストには、ブローカーが特定のエラーにどのように応答するかを示します。
CONNECT without a token:
トークンなしで接続します：
The tokenless CONNECT attempt MUST fail. This is because the challenge-response-based PoP is not possible for MQTT v3.1.1. It is also not possible to support AS discovery since a CONNACK packet in MQTT v3.1.1 does not include a means to provide additional information to the Client. Therefore, AS discovery needs to take place out of band.
トークンレス接続試行は失敗する必要があります。これは、MQTT V3.1.1では、チャレンジ対応ベースのPOPが不可能であるためです。MQTT V3.1.1のConnackパケットには、クライアントに追加情報を提供する手段が含まれていないため、発見としてサポートすることもできません。したがって、発見がバンドから出る必要があるため。
Client-Broker PUBLISH authorization failure:
クライアントブローカー公開承認の失敗：
In the case of a failure, it is not possible to return an error in MQTT v3.1.1. Acknowledgment messages only indicate success. In the case of an authorization error, the Broker MUST ignore the PUBLISH packet and disconnect the Client. Also, as DISCONNECT packets are only sent from a Client to the Broker, the server disconnection needs to take place below the application layer.
障害の場合、MQTT v3.1.1のエラーを返すことはできません。謝辞メッセージは成功のみを示します。承認エラーの場合、ブローカーは公開パケットを無視し、クライアントを切断する必要があります。また、切断パケットはクライアントからブローカーにのみ送信されるため、サーバーの切断はアプリケーションレイヤーの下に行う必要があります。
SUBSCRIBE authorization failure:
承認の失敗を購読する：
In the SUBACK packet, the return code is 0x80, indicating failure for the unauthorized topic(s). Note that, in both MQTT versions, a reason code is returned for each Topic Filter.
Subackパケットでは、返品コードは0x80であり、不正なトピックの障害を示しています。両方のMQTTバージョンで、各トピックフィルターに対して理由コードが返されることに注意してください。
Broker-Client PUBLISH authorization failure:
ブローカークライアント公開承認の失敗：
When the Broker is forwarding PUBLISH packets to the subscribed Clients, it may discover that some of the subscribers are no longer authorized due to expired tokens. These token expirations MUST lead to disconnecting the Client rather than silently dropping messages.
ブローカーがサブスクライブされたクライアントに公開パケットを転送している場合、一部のサブスクライバーは、期限切れのトークンのために承認されなくなったことがわかります。これらのトークンの有効期限は、メッセージを静かに削除するのではなく、クライアントを切断することにつながる必要があります。
This document registers "EXPORTER-ACE-MQTT-Sign-Challenge" (introduced in Section 2.2.4.2.1 in this document) in the "TLS Exporter Labels" registry [RFC8447].
このドキュメントは、「TLS Exporter Labels」レジストリ[RFC8447]に「Exporter-ACE-MQTT-Sign-Challenge」（このドキュメントのセクション2.2.4.2.1で導入）を登録します。
Recommended:
推奨：
N
n
DTLS-OK:
DTLS-OK：
N
n
Reference:
参照：
RFC 9431
RFC 9431
This document registers the "application/ace+json" media type for messages of the protocols defined in this document carrying parameters encoded in JSON.
このドキュメントは、JSONでエンコードされたパラメーターを運ぶこのドキュメントで定義されているプロトコルのメッセージの「アプリケーション/ACE JSON」メディアタイプを登録します。
Type name:
タイプ名：
application
応用アプリケーション出願塗布申請アプリ使用利用申込申し込み応募運用願い願い出要請控訴勉励丹念請求応用力適用業務
Subtype name:
サブタイプ名：
ace+json
エースJSON
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
Encoding considerations are identical to those specified for the "application/json" media type.
エンコーディングの考慮事項は、「アプリケーション/JSON」メディアタイプに指定されたものと同じです。
Security considerations:
セキュリティ上の考慮事項：
Section 8 of RFC 9431
RFC 9431のセクション8
Interoperability considerations:
相互運用性の考慮事項：
none
なしのどれも
Published specification:
公開された仕様：
RFC 9431
RFC 9431
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
This media type is intended for Authorization-Server-Client and Authorization-Server-Resource-Server communication as part of the ACE framework using JSON encoding, as specified in RFC 9431.
このメディアタイプは、RFC 9431で指定されているように、JSONエンコーディングを使用してACEフレームワークの一部として、承認サーバークライアントおよび認証サーバーリソースサーバーコミュニケーションを目的としています。
Fragment identifier considerations:
フラグメント識別子の考慮事項：
none
なしのどれも
Additional information:
追加情報：
Deprecated alias names for this type:
このタイプの非推奨エイリアス名：
none
なしのどれも
Magic number(s):
マジックナンバー：
none
なしのどれも
File extension(s):
ファイル拡張子：
none
なしのどれも
Macintosh file type code(s):
Macintoshファイルタイプコード：
none
なしのどれも
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
Cigdem Sengul <csengul@acm.org>
cigdem sengul <csengul@acm.org>
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
none
なしのどれも
Author:
著者：
Cigdem Sengul <csengul@acm.org>
cigdem sengul <csengul@acm.org>
Change controller:
Change Controller：
IETF
IETF
The following registrations have been made in the "ACE Profiles" registry, following the procedure specified in [RFC9200].
[RFC9200]で指定された手順に従って、「ACEプロファイル」レジストリで次の登録が行われました。
Name:
名前：
mqtt_tls
mqtt_tls
Description:
説明：
Profile for delegating Client authentication and authorization using MQTT for the Client and Broker (RS) interactions and HTTP for the AS interactions. TLS is used for confidentiality and integrity protection and server authentication. Client authentication can be provided either via TLS or using in-band PoP validation at the MQTT application layer.
クライアントとブローカー（RS）のインタラクションとASインタラクションのHTTPを使用して、クライアント認証と承認を委任するためのプロファイル。TLSは、機密性と整合性の保護とサーバー認証に使用されます。クライアント認証は、TLSを介して、またはMQTTアプリケーションレイヤーでインバンドポップ検証を使用して提供できます。
CBOR Value:
CBOR値：
3
3
Reference:
参照：
RFC 9431
RFC 9431
For the media types "application/aif+cbor" and "application/ aif+json", defined in Section 5.1 of [RFC9237], IANA has registered the following entries for the two media type parameters Toid and Tperm in the respective subregistry defined in Section 5.2 of [RFC9237] within the "Media Type Sub-Parameter Registries".
[RFC9237]のセクション5.1で定義されているメディアタイプ「アプリケーション/ AIF CBOR」および「Application/ AIF JSON」の場合、IANAはセクション5.2で定義されているそれぞれのサブレジストリで2つのメディアタイプパラメーターとTPERMの次のエントリを登録しました。[メディアタイプのサブパラメーターレジストリ]内の[RFC9237]の。
For Toid:
TOIDのために：
Name:
名前：
mqtt-topic-filter
mqtt-topic-filter
Description/Specification:
説明/仕様：
Topic Filter, as defined in Section 2.3 of RFC 9431.
RFC 9431のセクション2.3で定義されているトピックフィルター。
Reference:
参照：
RFC 9431, Section 2.3
RFC 9431、セクション2.3
For Tperm:
TPERMの場合：
Name:
名前：
mqtt-permissions
mqtt-permissions
Description/Specification:
説明/仕様：
Permissions for the MQTT Client, as defined in Section 2.3 of RFC 9431. Tperm is an array of one or more text strings that each have a value of either "pub" or "sub".
RFC 9431のセクション2.3で定義されているMQTTクライアントの権限。TPERMは、それぞれが「パブ」または「サブ」のいずれかの値を持つ1つ以上のテキスト文字列の配列です。
Reference:
参照：
RFC 9431, Section 2.3
RFC 9431、セクション2.3
This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework [RFC9200]. Therefore, the security considerations outlined in [RFC9200] apply to this work.
このドキュメントは、制約された環境（ACE）フレームワーク[RFC9200]の認証と認証のプロファイルを指定します。したがって、[RFC9200]で概説されているセキュリティ上の考慮事項は、この作業に適用されます。
In addition, the security considerations outlined in the MQTT v5.0 OASIS Standard [MQTT-OASIS-Standard-v5] and MQTT v3.1.1 OASIS Standard [MQTT-OASIS-Standard-v3.1.1] apply. Mainly, this document provides an authorization solution for MQTT, the responsibility of which is left to the specific implementation in the MQTT standards. In the following, we comment on a few relevant issues based on the current MQTT specifications.
さらに、MQTT V5.0 OASIS Standard [MQTT-Oasis-Standard-V5]およびMQTT V3.1.1 OASIS Standard [MQTT-Oasis-Standard-V3.1.1]で概説されているセキュリティ上の考慮事項が適用されます。主に、このドキュメントはMQTTの承認ソリューションを提供します。その責任は、MQTT規格の特定の実装に任されています。以下では、現在のMQTT仕様に基づいて、いくつかの関連する問題についてコメントします。
After the Broker validates an access token and accepts a connection from a client, it caches the token to authorize a Client's publish and subscribe requests in an ongoing Session. The Broker does not cache any tokens that cannot be validated. If a Client's permissions get revoked, but the access token has not expired, the Broker may still grant publish/subscribe to revoked topics. If the Broker caches the token introspection responses, then the Broker SHOULD use a reasonable cache timeout to introspect tokens regularly. The timeout value is application specific and should be chosen to reduce the risk of using stale introspection responses. When permissions change dynamically, it is expected that the AS also follows a reasonable expiration strategy for the access tokens.
ブローカーがアクセストークンを検証し、クライアントからの接続を受け入れると、トークンをキャッシュして、継続的なセッションでクライアントの公開とサブスクライブのリクエストを承認します。ブローカーは、検証できないトークンをキャッシュしません。クライアントのアクセス許可が取り消されたが、アクセストークンが期限切れになっていない場合、ブローカーはまだ取り消されたトピックを公開/購読することができます。ブローカーがトークン内省反応をキャッシュする場合、ブローカーは合理的なキャッシュタイムアウトを使用してトークンを定期的に内省する必要があります。タイムアウト値はアプリケーション固有であり、古い内省反応を使用するリスクを減らすために選択する必要があります。権限が動的に変更されると、ASはアクセストークンの合理的な有効期限戦略にも従うことが予想されます。
The Broker may monitor Client behavior to detect potential security problems, especially those affecting availability. These include repeated token transfer attempts to the public "authz-info" topic, repeated connection attempts, abnormal terminations, and Clients that connect but do not send any data. If the Broker supports the public "authz-info" topic, described in Section 2.2.2, then this may be vulnerable to a DDoS attack, where many Clients use the "authz-info" public topic to transport tokens that are not meant to be used and that the Broker may need to store until they expire.
ブローカーは、クライアントの動作を監視して、潜在的なセキュリティ問題、特に可用性に影響を与えるものを検出できます。これらには、繰り返されるトークン転送試行試行は、一般の「authz-info」トピックへの試み、繰り返される接続の試み、異常な終端、およびデータを接続しますが、データを送信しないクライアントが含まれます。ブローカーがセクション2.2.2で説明されている公開「Authz-info」トピックをサポートしている場合、これはDDOS攻撃に対して脆弱である可能性があります。使用され、ブローカーが期限切れになるまで保存する必要がある場合があります。
For MQTT v5.0, when a Client connects with a long Session Expiry Interval, the Broker may need to maintain the Client's MQTT Session State after it disconnects for an extended period. For MQTT v3.1.1, the Session State may need to be stored indefinitely, as it does not have a Session Expiry Interval feature. The Broker SHOULD implement administrative policies to limit misuse by the Client resulting from continuing existing Sessions.
MQTT v5.0の場合、クライアントが長いセッションの有効期限間隔に接続する場合、ブローカーは、クライアントのMQTTセッション状態を長期間切断した後に維持する必要があります。MQTT v3.1.1の場合、セッションの有効期限インターバル機能がないため、セッション状態を無期限に保存する必要があります。ブローカーは、既存のセッションを継続したことに起因するクライアントによる誤用を制限するための管理ポリシーを実装する必要があります。
The privacy considerations outlined in [RFC9200] apply to this work.
[RFC9200]で概説されているプライバシーに関する考慮事項は、この作業に適用されます。
In MQTT, the Broker is a central trusted party and may forward potentially sensitive information between Clients. The mechanisms defined in this document do not protect the contents of the PUBLISH packet from the Broker, and hence, the content of the PUBLISH packet is not signed or encrypted separately for the subscribers. This functionality may be implemented using the proposal outlined in the ACE Pub-Sub Profile [ACE-PUBSUB-PROFILE]. However, this solution would still not provide privacy for other fields of the packet, such as Topic Name.
MQTTでは、ブローカーは中心的な信頼できる当事者であり、クライアント間で潜在的に機密情報を転送することができます。このドキュメントで定義されているメカニズムは、ブローカーからのパブリッシュパケットのコンテンツを保護するものではないため、パブリックパケットのコンテンツは、サブスクライバーのために個別に署名または暗号化されていません。この機能は、ACE Pub-Subプロファイル[ACE-Pubsub-Profile]に概説されている提案を使用して実装できます。ただし、このソリューションは、トピック名など、パケットの他のフィールドにプライバシーを提供しません。
[MQTT-OASIS-Standard-v3.1.1]
Banks, A., Ed. and R. Gupta, Ed., "MQTT Version 3.1.1 Plus
Errata 01", OASIS Standard, December 2015,
<https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-
v3.1.1.html>.
[MQTT-OASIS-Standard-v5]
Banks, A., Ed., Briggs, E., Ed., Borgendale, K., Ed., and
R. Gupta, Ed., "MQTT Version 5.0", OASIS Standard, March
2019, <https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-
v5.0.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/info/rfc6749>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC7627] Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
Langley, A., and M. Ray, "Transport Layer Security (TLS)
Session Hash and Extended Master Secret Extension",
RFC 7627, DOI 10.17487/RFC7627, September 2015,
<https://www.rfc-editor.org/info/rfc7627>.
[RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
Possession Key Semantics for JSON Web Tokens (JWTs)",
RFC 7800, DOI 10.17487/RFC7800, April 2016,
<https://www.rfc-editor.org/info/rfc7800>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", RFC 8422,
DOI 10.17487/RFC8422, August 2018,
<https://www.rfc-editor.org/info/rfc8422>.
[RFC8442] Mattsson, J. and D. Migault, "ECDHE_PSK with AES-GCM and
AES-CCM Cipher Suites for TLS 1.2 and DTLS 1.2", RFC 8442,
DOI 10.17487/RFC8442, September 2018,
<https://www.rfc-editor.org/info/rfc8442>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H.
Tschofenig, "Proof-of-Possession Key Semantics for CBOR
Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March
2020, <https://www.rfc-editor.org/info/rfc8747>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/info/rfc9052>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/info/rfc9200>.
[RFC9201] Seitz, L., "Additional OAuth Parameters for Authentication
and Authorization for Constrained Environments (ACE)",
RFC 9201, DOI 10.17487/RFC9201, August 2022,
<https://www.rfc-editor.org/info/rfc9201>.
[RFC9202] Gerdes, S., Bergmann, O., Bormann, C., Selander, G., and
L. Seitz, "Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for
Constrained Environments (ACE)", RFC 9202,
DOI 10.17487/RFC9202, August 2022,
<https://www.rfc-editor.org/info/rfc9202>.
[RFC9237] Bormann, C., "An Authorization Information Format (AIF)
for Authentication and Authorization for Constrained
Environments (ACE)", RFC 9237, DOI 10.17487/RFC9237,
August 2022, <https://www.rfc-editor.org/info/rfc9237>.
[RFC9360] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header Parameters for Carrying and Referencing X.509
Certificates", RFC 9360, DOI 10.17487/RFC9360, February
2023, <https://www.rfc-editor.org/info/rfc9360>.
[RFC9430] Bergmann, O., Preuß Mattsson, J., and G. Selander,
"Extension of the Datagram Transport Layer Security (DTLS)
Profile for Authentication and Authorization for
Constrained Environments (ACE) to Transport Layer Security
(TLS)", RFC 9430, DOI 10.17487/RFC9430, July 2023,
<https://www.rfc-editor.org/info/rfc9430>.
[ACE-PUBSUB-PROFILE]
Palombini, F., Sengul, C., and M. Tiloca, "Publish-
Subscribe Profile for Authentication and Authorization for
Constrained Environments (ACE)", Work in Progress,
Internet-Draft, draft-ietf-ace-pubsub-profile-06, 13 March
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
ace-pubsub-profile-06>.
[Fremantle14]
Fremantle, P., Aziz, B., Kopecky, J., and P. Scott,
"Federated Identity and Access Management for the Internet
of Things", International Workshop on Secure Internet of
Things, DOI 10.1109/SIoT.2014.8, September 2014,
<https://dx.doi.org/10.1109/SIoT.2014.8>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<https://www.rfc-editor.org/info/rfc4949>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
Security (TLS) / Datagram Transport Layer Security (DTLS)
Profiles for the Internet of Things", RFC 7925,
DOI 10.17487/RFC7925, July 2016,
<https://www.rfc-editor.org/info/rfc7925>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018,
<https://www.rfc-editor.org/info/rfc8447>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[TLS-bis] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", Work in Progress, Internet-Draft, draft-
ietf-tls-rfc8446bis-09, 7 July 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-tls-
rfc8446bis-09>.
Based on the requirements on profiles for the ACE framework [RFC9200], this document fulfills the following:
ACEフレームワーク[RFC9200]のプロファイルに関する要件に基づいて、このドキュメントは以下を満たしています。
* Optional AS discovery: AS discovery is supported with the MQTT v5.0 described in Section 2.2.
* 発見としてオプション：セクション2.2で説明されているMQTT V5.0で発見がサポートされています。
* The communication protocol between the Client and Broker (RS): MQTT
* クライアントとブローカーの間の通信プロトコル（RS）：MQTT
* The security protocol between the Client and RS: TLS
* クライアントとRSの間のセキュリティプロトコル：TLS
* Client and RS mutual authentication: Several options are possible and described in Section 2.2.1.
* クライアントとRS相互認証：いくつかのオプションが可能であり、セクション2.2.1で説明されています。
* Proof-of-possession protocols: Both symmetric and asymmetric keys are supported, as specified in Section 2.2.4.2.
* Proof-of-Possessionプロトコル：セクション2.2.4.2で指定されているように、対称キーと非対称キーの両方がサポートされています。
* Content-Format: For the HTTPS interactions with AS, "application/ ace+json".
* コンテンツフォーマット：HTTPSがAS「Application/ Ace JSON」と相互作用するため。
* Unique profile identifier: mqtt_tls
* 一意のプロファイル識別子：MQTT_TLS
* Token introspection: The RS uses the HTTPS introspection interface of the AS.
* トークン内省：RSは、ASのHTTPS内省インターフェイスを使用します。
* Token request: The Client or its Client AS uses the HTTPS token endpoint of the AS.
* トークンリクエスト：ASのHTTPSトークンエンドポイントを使用するクライアントまたはそのクライアント。
* authz-info endpoint: It MAY be supported using the method described in Section 2.2.2 but is not protected other than by the TLS channel between the Client and RS.
* authz-infoエンドポイント：セクション2.2.2で説明した方法を使用してサポートされる場合がありますが、クライアントとRSの間のTLSチャネル以外に保護されていません。
* Token transport: Via the "authz-info" topic, TLS with PSKs (provided as a PSK identity), or in the MQTT CONNECT packet for both versions of MQTT. The AUTH extensions can also be used for authentication and reauthentication for MQTT v5.0, as described in Sections 2.2 and 4.
* トークントランスポート：「authz-info」トピックを介して、PSKを備えたTLS（PSKアイデンティティとして提供）、またはMQTTの両方のバージョンのMQTT Connectパケット。AUTH拡張機能は、セクション2.2および4で説明されているように、MQTT V5.0の認証と再認証にも使用できます。
The authors would like to thank Ludwig Seitz for his review and his input on the authorization information endpoint; Benjamin Kaduk for his review, insightful comments, and contributions to resolving issues; and Carsten Bormann for his review and revisions to the AIF-MQTT data model. The authors would like to thank Paul Fremantle for the initial discussions on MQTT v5.0 support.
著者は、Ludwig Seitzのレビューと認証情報のエンドポイントに関する入力に感謝したいと思います。Benjamin Kadukのレビュー、洞察に満ちたコメント、および問題の解決への貢献について。AIF-MQTTデータモデルのレビューと改訂についてのCarsten Bormann。著者は、MQTT V5.0サポートに関する最初の議論についてPaul Fremantleに感謝したいと思います。
Cigdem Sengul
Brunel University
Dept. of Computer Science
Uxbridge
UB8 3PH
United Kingdom
Email: csengul@acm.org
Anthony Kirby
Oxbotica
1a Milford House
Mayfield Road, Summertown
Oxford
OX2 7EL
United Kingdom
Email: anthony@anthony.org