[要約] RFC 9140は、EAP-NOOB（Nimble Out-of-Band Authentication for EAP）に関する文書で、簡易な外部認証を提供することを目的としています。主に初回接続時やデバイスが互いに未知の状態である場面で利用され、安全な接続確立を支援します。
Internet Engineering Task Force (IETF) T. Aura
Request for Comments: 9140 Aalto University
Category: Standards Track M. Sethi
ISSN: 2070-1721 Ericsson
A. Peltonen
Aalto University
December 2021
Nimble Out-of-Band Authentication for EAP (EAP-NOOB)
EAP（EAP-NOOB）の帯域外認証のNimble
Abstract
概要
The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. The EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have no preconfigured authentication credentials. The method makes use of a user-assisted, one-directional, out-of-band (OOB) message between the peer device and authentication server to authenticate the in-band key exchange. The device must have a nonnetwork input or output interface, such as a display, microphone, speaker, or blinking light, that can send or receive dynamically generated messages of tens of bytes in length.
拡張認証プロトコル（EAP）は、複数の認証方法をサポートしています。このドキュメントでは、帯域外帯域外（OOB）認証とキー導出のためのEAP-NOOB認証方法を定義します。EAPメソッドは、事前設定された認証資格情報を持たないすべての種類のインターネット（IOT）デバイスのブートストラップを目的としています。この方法は、インバンド鍵交換を認証するために、ピア装置と認証サーバとの間のユーザ補助、一方向の帯域外（OOB）メッセージを利用する。デバイスは、ディスプレイ、マイクロフォン、スピーカー、または点滅ライトなど、ネットワーク入力または出力インタフェースを必要とする必要があります。これは、長さの数十バイトのメッセージを送受信できます。
Status of This Memo
本文書の位置付け
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/rfc9140.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9140で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2021 IETFの信頼と文書著者として識別された人。全著作権所有。
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.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
2. Terminology
3. EAP-NOOB Method
3.1. Protocol Overview
3.2. Protocol Messages and Sequences
3.2.1. Common Handshake in All EAP-NOOB Exchanges
3.2.2. Initial Exchange
3.2.3. OOB Step
3.2.4. Completion Exchange
3.2.5. Waiting Exchange
3.3. Protocol Data Fields
3.3.1. Peer Identifier and NAI
3.3.2. Message Data Fields
3.4. Fast Reconnect and Rekeying
3.4.1. Persistent EAP-NOOB Association
3.4.2. Reconnect Exchange
3.4.3. User Reset
3.5. Key Derivation
3.6. Error Handling
3.6.1. Invalid Messages
3.6.2. Unwanted Peer
3.6.3. State Mismatch
3.6.4. Negotiation Failure
3.6.5. Cryptographic Verification Failure
3.6.6. Application-Specific Failure
4. ServerInfo and PeerInfo Contents
5. IANA Considerations
5.1. Cryptosuites
5.2. Message Types
5.3. Error Codes
5.4. ServerInfo Data Fields
5.5. PeerInfo Data Fields
5.6. Domain Name Reservation
5.7. Guidance for Designated Experts
6. Security Considerations
6.1. Authentication Principle
6.2. Identifying Correct Endpoints
6.3. Trusted Path Issues and Misbinding Attacks
6.4. Peer Identifiers and Attributes
6.5. Downgrading Threats
6.6. Protected Success and Failure Indications
6.7. Channel Binding
6.8. Denial of Service
6.9. Recovery from Loss of Last Message
6.10. Privacy Considerations
6.11. EAP Security Claims
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Exchanges and Events per State
Appendix B. Application-Specific Parameters
Appendix C. EAP-NOOB Roaming
Appendix D. OOB Message as a URL
Acknowledgments
Authors' Addresses
This document describes a method for registration, authentication, and key derivation for network-connected smart devices, such as consumer and enterprise appliances that are part of the Internet of Things (IoT). These devices may be off-the-shelf hardware that is sold and distributed without any prior registration or credential-provisioning process, or they may be recycled devices after a hard reset. Thus, the device registration in a server database, ownership of the device, and the authentication credentials for both network access and application-level security must all be established at the time of the device deployment. Furthermore, many such devices have only limited user interfaces that could be used for their configuration. Often, the user interfaces are limited to either only input (e.g., a camera) or output (e.g., a display screen). The device configuration is made more challenging by the fact that the devices may exist in large numbers and may have to be deployed or reconfigured nimbly based on user needs.
この資料は、インターネットのインターネット（IoT）の一部である消費者や企業機器などのネットワーク接続されたスマートデバイスの登録、認証、および鍵導出のための方法について説明します。これらのデバイスは、以前の登録または資格情報プロビジョニングプロセスなしに販売および分散されているオフザルハードウェアであり得るか、またはハードリセット後にリサイクルされたデバイスである場合があります。したがって、サーバーデータベースのデバイス登録、デバイスの所有権、およびネットワークアクセスとアプリケーションレベルのセキュリティの両方の認証資格情報は、デバイスの展開時にすべて確立されていなければなりません。さらに、多くのそのような装置は、それらの構成に使用することができる限られたユーザインターフェースのみを有する。多くの場合、ユーザインタフェースは入力（例えば、カメラ）または出力（例えば表示画面）のみに制限されている。デバイス構成は、デバイスが大数に存在してもよく、ユーザーのニーズに基づいて展開または再設定する必要がある可能性があるという事実によって、より困難になります。
To summarize, devices may have the following characteristics:
要約するために、デバイスには次のような特徴がある可能性があります。
* no preestablished relation with the intended server or user,
* 意図されたサーバーまたはユーザーと予熱された関係はありません。
* no preprovisioned device identifier or authentication credentials, or
* プリプロビジーデバイス識別子または認証資格情報、または
* an input or output interface that may be capable of only one-directional out-of-band communication.
* 一方向に帯域外の通信しかない可能性がある入力または出力インタフェース。
Many proprietary out-of-band (OOB) configuration methods exist for specific IoT devices. The goal of this specification is to provide an open standard and a generic protocol for bootstrapping the security of network-connected appliances, such as displays, printers, speakers, and cameras. The security bootstrapping in this specification makes use of a user-assisted OOB channel. The device authentication relies on a user having physical access to the device, and the key exchange security is based on the assumption that attackers are not able to observe or modify the messages conveyed through the OOB channel. We follow the common approach taken in pairing protocols: performing a Diffie-Hellman key exchange over the insecure network and authenticating the established key with the help of the OOB channel in order to prevent impersonation attacks.
特定のIoTデバイスには、多数の独自の帯域外（OOB）設定方法が存在します。本明細書の目的は、ディスプレイ、プリンタ、スピーカー、カメラなどのネットワーク接続機器のセキュリティをブートストラップするためのオープンスタンダードおよび一般的なプロトコルを提供することです。この仕様のセキュリティブートストラップは、ユーザー支援OOBチャネルを利用します。デバイス認証は、装置への物理的アクセスを有するユーザに依存し、鍵交換セキュリティは攻撃者がOOBチャネルを介して伝達されたメッセージを観察または変更することができないという仮定に基づいている。ペアリングプロトコルで行われた共通のアプローチに従います。
The solution presented here is intended for devices that have either a nonnetwork input or output interface, such as a camera, microphone, display screen, speaker, or blinking Light Emitting Diode (LED) light, that is able to send or receive dynamically generated messages of tens of bytes in length. Naturally, this solution may not be appropriate for very small sensors or actuators that have no user interface at all or for devices that are inaccessible to the user. We also assume that the OOB channel is at least partly automated (e.g., a camera scanning a bar code); thus, there is no need to absolutely minimize the length of the data transferred through the OOB channel. This differs, for example, from Bluetooth pairing [Bluetooth], where it is essential to minimize the length of the manually transferred or compared codes. The OOB messages in this specification are dynamically generated. Thus, we do not support static printed registration codes. One reason for requiring dynamic OOB messages is that the receipt of the OOB message authorizes the server to take ownership of the device. Dynamic OOB messages are more secure than static printed codes, which could be leaked and later misused.
ここで提示された解決策は、動的に生成されたメッセージを送受信することができる、カメラ、マイクロフォン、ディスプレイスクリーン、スピーカー、または点滅発光ダイオード（LED）光などのノンネットワーク入力または出力インタフェースを持つデバイスを対象としています。長さの数十バイト。当然のことながら、この解決策は、ユーザーにアクセスできないデバイスに、ユーザーインターフェースを含まない、またはユーザーインターフェースを持たない非常に小さいセンサーまたはアクチュエーターには適していない可能性があります。また、OOBチャネルが少なくとも部分的に自動化されている（例えば、バーコードをスキャンするカメラ）と仮定します。したがって、OOBチャネルを介して転送されたデータの長さを絶対に最小限に抑える必要はない。これは、例えば、Bluetoothペアリング[Bluetooth]から、手動で転送されたコードまたは比較されたコードの長さを最小にすることが不可欠です。この仕様のOOBメッセージは動的に生成されます。したがって、静的印刷登録コードをサポートしていません。動的OOBメッセージを必要とする理由の1つは、OOBメッセージの受信がサーバーがデバイスの所有権を取得するように許可されていることです。動的OOBメッセージは静的印刷コードよりも安全であり、これはリークされ、後で誤用される可能性があります。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
In addition, this document frequently uses the following terms as they have been defined in [RFC5216]:
さらに、この文書では、[RFC5216]で定義されているとおりに次の用語を使用しています。
authenticator The entity initiating EAP authentication.
Authenticator EAP認証を開始するエンティティ。
peer The entity that responds to the authenticator. In [IEEE-802.1X], this entity is known as the supplicant. (We use the terms peer, device, and peer device interchangeably.)
オーセンティケータに応答するエンティティをピアにします。[IEEE-802.1X]では、この事業体はサプリカントとして知られています。（私たちは、ピア、デバイス、ピアデバイスを互換的に使用します。）
server The entity that terminates the EAP authentication method with the peer. In the case where no backend authentication server is used, the EAP server is part of the authenticator. In the case where the authenticator operates in pass-through mode, the EAP server is located on the backend authentication server.
サーバーピアを使用してEAP認証方法を終了するエンティティ。バックエンド認証サーバーが使用されていない場合、EAPサーバーはオーセンティケータの一部です。オーセンティケータがパススルーモードで動作する場合、EAPサーバはバックエンド認証サーバ上にあります。
This section defines the EAP-NOOB method. The protocol is a generalized version of the original idea presented by Sethi et al. [Sethi14].
このセクションでは、EAP-NOOBメソッドを定義します。このプロトコルは、Sethiらによって提示された元のアイデアの一般化されたバージョンです。[Sethi14]。
One EAP-NOOB method execution spans two or more EAP conversations, called Exchanges in this specification. Each Exchange consists of several EAP request-response pairs. At least two separate EAP conversations are needed to give the human user time to deliver the OOB message between them.
1つのEAP-NOOBメソッド実行は、この仕様の交換と呼ばれる2つ以上のEAP会話をスパンします。各交換は、いくつかのEAP要求応答ペアで構成されています。それらの間でOOBメッセージを配信するために人間のユーザー時間を与えるために少なくとも2つの別々のEAP会話が必要です。
The overall protocol starts with the Initial Exchange, which comprises four EAP request-response pairs. In the Initial Exchange, the server allocates an identifier to the peer, and the server and peer negotiate the protocol version and cryptosuite (i.e., cryptographic algorithm suite), exchange nonces, and perform an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key exchange. The user-assisted OOB Step then takes place. This step requires only one out-of-band message, either from the peer to the server or from the server to the peer. While waiting for the OOB Step action, the peer MAY probe the server by reconnecting to it with EAP-NOOB. If the OOB Step has already taken place, the probe leads to the Completion Exchange, which completes the mutual authentication and key confirmation. On the other hand, if the OOB Step has not yet taken place, the probe leads to the Waiting Exchange, and the peer will perform another probe after a server-defined minimum waiting time. The Initial Exchange and Waiting Exchange always end in EAP-Failure, while the Completion Exchange may result in EAP-Success. Once the peer and server have performed a successful Completion Exchange, both endpoints store the created association in persistent storage, and the OOB Step is not repeated. Thereafter, creation of new temporal keys, ECDHE rekeying, and updates of cryptographic algorithms can be achieved with the Reconnect Exchange.
全体のプロトコルは、4つのEAP要求応答ペアを含む最初のExchangeから始まります。最初の交換では、サーバは識別子をピアに割り当て、サーバとピアはプロトコルバージョンと暗号化された（すなわち暗号化アルゴリズムスイート）、Exchange Nonceをネゴシエートし、エフェメラル楕円曲線Diffie-Hellman（ECDHE）キー交換を実行します。 。その後、ユーザー支援OOBステップが行われます。このステップでは、ピアからサーバーへ、またはサーバーからピアへの帯域外メッセージのみが必要です。 OOBステップアクションを待っている間、ピアはEAP-NOOBと一緒に再接続してサーバーをプローブすることができます。 OOBステップが既に行われている場合、プローブは完了交換をもたらし、これは相互認証と鍵の確認を完了します。一方、OOBステップがまだ行われていない場合、プローブは待機交換をもたらし、同ピアはサーバ定義の最小待ち時間の後に別のプローブを実行します。最初のExchangeとWaiting Exchangeは常にEAP障害で終了し、完了した交換はEAP成功になる可能性があります。ピアとサーバーが正常に完了した交換を実行したら、両方のエンドポイントが作成されたアソシエーションを永続ストレージに保存し、OOBステップは繰り返されません。その後、新しい時間キー、ECDHEの生成、および暗号化アルゴリズムの更新の作成は、再接続交換で達成することができる。
OOB Output/Initial Exchange/
Waiting Exchange
.-----.
| v
.------------------. Initial .------------------.
| | Exchange | |
.->| Unregistered (0) |---------------->|Waiting for OOB(1)|
| | (ephemeral) | | (ephemeral) |
| | | | |
| '------------------' '------------------'
| | | ^
User Reset Completion | | |
| Exchange | OOB OOB
|<-------. .-------------------------' Input Reject/
| | | | Initial
| | | | Exchange
| | v v |
| .------------------. Completion .------------------.
| | | Exchange | |
| | Registered (4) |<----------------| OOB Received (2) |
| | (persistent) | | (ephemeral) |
| | | | |
| '------------------' '------------------'
| | ^
| Mobility/ |
| Timeout/ Reconnect
| Failure Exchange
| | |
| v |
| .------------------.
| | |
'--| Reconnecting (3) |
| (persistent) |
| |
'------------------'
Figure 1: EAP-NOOB Server-Peer Association State Machine
図1：EAP-NOOBサーバーピアアソシエーションステートマシン
Figure 1 shows the association state machine, which is the same for the server and for the peer. (For readability, only the main state transitions are shown. The complete table of transitions can be found in Appendix A.) When the peer initiates the EAP-NOOB method, the server chooses the ensuing message exchange based on the combination of the server and peer states. The EAP server and peer are initially in the Unregistered (0) state, in which no state information needs to be stored. Before a successful Completion Exchange, the server-peer association state is ephemeral in both the server and peer (ephemeral states 0..2), and a timeout or error may cause one or both endpoints to go back to the Unregistered (0) state so that the Initial Exchange is repeated. After the Completion Exchange has resulted in EAP-Success, the association state becomes persistent (persistent states 3..4). Only user reset or memory failure can cause the return of the server or the peer from the persistent states to the ephemeral states and to the Initial Exchange.
図1は、サーバとピアに同じアソシエーションステートマシンを示しています。 （読みやすさのために、主な状態遷移のみが示されています。遷移の完全なテーブルは付録Aにあります。）ピアがEAP-NOOBメソッドを開始すると、サーバーはサーバーの組み合わせに基づいて次のメッセージ交換を選択します。ピアの状態EAPサーバとピアは、最初は未登録（0）状態にあり、ここでは状態情報を格納する必要がない。完了した完了Exchangeが正常になる前に、サーバーピアアソシエーション状態はサーバーとピアの両方（エフェメラル状態0..2）の両方で、タイムアウトまたはエラーが一方または両方のエンドポイントを未登録（0）状態に戻る可能性があります。最初の交換が繰り返されるように。完了ExchangeがEAP成功した後、関連状態は永続的になります（永続状態3..4）。ユーザリセットまたはメモリ障害のみが、サーバまたはピアの永続状態からエフェメラル状態への復帰、および最初のExchangeにのみを引き起こす可能性があります。
The server MUST NOT repeat a successful OOB Step with the same peer except if the association with the peer is explicitly reset by the user or lost due to failure of the persistent storage in the server. More specifically, once the association has entered the Registered (4) state, the server MUST NOT delete the association or go back to the ephemeral states 0..2 without explicit user approval. Similarly, the peer MUST NOT repeat the OOB Step unless the user explicitly deletes the association with the server from the peer or resets the peer to the Unregistered (0) state. The server and peer MAY implement user reset of the association by deleting the state data from that endpoint. If an endpoint continues to store data about the association after the user reset, its behavior MUST be equivalent to having deleted the association data.
サーバは、ピアとの関連が明確に起因するサーバ内の永続ストレージの障害のために、ユーザによってリセットまたは失われた場合を除き、同じピアと成功OOBのステップを繰り返してはなりません。関連付けが登録（4）状態に入った後は具体的には、サーバは、関連付けを削除したり、ユーザーの明示的な承認なしにはかない状態0..2に戻してはなりません。ユーザが明示的ピアからサーバとの関連付けを削除または未登録（0）状態にピアをリセットしない限り同様に、ピアは、OOBステップを繰り返してはいけません。サーバとピアは、そのエンドポイントからの状態データを削除することによって、関連のユーザのリセットを実施することができます。エンドポイントがユーザリセット後のアソシエーションに関するデータを記憶し続ける場合、その動作は、関連データを削除したと同等でなければなりません。
It can happen that the peer accidentally (or through user reset) loses its persistent state and reconnects to the server without a previously allocated peer identifier. In that case, the server MUST treat the peer as a new peer. The server MAY use auxiliary information, such as the PeerInfo field received in the Initial Exchange, to detect multiple associations with the same peer. However, it MUST NOT delete or merge redundant associations without user or application approval because EAP-NOOB internally has no secure way of verifying that the two peers are the same physical device. Similarly, the server might lose the association state because of a memory failure or user reset. In that case, the only way to recover is that the user also resets the peer.
誤ってピアが永続的な状態を失い、以前に割り当てられたピア識別子なしでサーバーに再接続することができます。その場合、サーバーはピアを新しいピアとして扱う必要があります。サーバは、最初の交換で受信されたPeerInfoフィールドなどの補助情報を使用して、同じピアとの複数の関連付けを検出することができる。ただし、EAP-Noobが内部的に2つのピアが同じ物理デバイスであることを確認するための安全な方法がないため、ユーザーまたはアプリケーションの承認なしに冗長関連性を削除またはマージしてはなりません。同様に、メモリ障害またはユーザーリセットのため、サーバーは関連状態を失う可能性があります。その場合、回復する唯一の方法は、ユーザーがピアをリセットすることです。
A special feature of the EAP-NOOB method is that the server is not assumed to have any a priori knowledge of the peer. Therefore, the peer initially uses the generic identity string "noob@eap-noob.arpa" as its Network Access Identifier (NAI). The server then allocates a server-specific identifier to the peer. The generic NAI serves two purposes: firstly, it tells the server that the peer supports and expects the EAP-NOOB method; secondly, it allows routing of the EAP-NOOB sessions to a specific authentication server in an Authentication, Authorization, and Accounting (AAA) architecture.
EAP-NOOBメソッドの特別な機能は、サーバーがピアの先験的な知識を持つと想定されていないことです。したがって、ピアは最初にネットワークアクセス識別子（NAI）として一般識別文字列 "noob @ ap-noob.arpa"を使用します。その後、サーバーはサーバー固有の識別子をピアに割り当てます。一般的なNAIは2つの目的を果たします。次に、認証、許可、および会計（AAA）アーキテクチャでEAP-NOOBセッションを特定の認証サーバーへのルーティングを可能にします。
EAP-NOOB is an unusual EAP method in that the peer has to have multiple EAP conversations with the server before it can receive EAP-Success. The reason is that, while EAP allows delays between the request-response pairs, e.g., for repeated password entry, the user delays in OOB authentication can be much longer than in password trials. Moreover, EAP-NOOB supports peers with no input capability in the user interface (e.g., LED light bulbs). Since users cannot initiate the protocol in these devices, the devices have to perform the Initial Exchange opportunistically and hope for the OOB Step to take place within a timeout period (NoobTimeout), which is why the timeout needs to be several minutes rather than seconds. To support such high-latency OOB channels, the peer and server perform the Initial Exchange in one EAP conversation, then allow time for the OOB message to be delivered, and later perform the Waiting Exchange and Completion Exchange in different EAP conversations.
EAP-NOOBは、ピアがEAP成功を受ける前にサーバーと複数のEAP会話を持たなければならないという点で、異常なEAPメソッドです。その理由は、EAPが要求応答ペア間の遅延、例えば繰り返しパスワードエントリの間の遅延を許容するが、OOB認証のユーザ遅延はパスワード試験よりもはるかに長くなる可能性がある。さらに、EAP-NOOBは、ユーザインタフェース（例えば、LED電球）に入力能力がないピアをサポートする。ユーザーはこれらのデバイスでプロトコルを開始できないため、デバイスは最初の交換機会を実行し、OOBステップがタイムアウト期間（NoobTimeout）内で行われることを希望する必要があります。そのため、タイムアウトは秒単位ではなく数分必要です。そのような高度な遅延OOBチャネルをサポートするために、ピアとサーバは1つのEAP会話で最初のExchangeを実行し、OOBメッセージの配信時間を許可し、後で異なるEAP会話で待機交換と完了Exchangeを実行します。
This section defines the EAP-NOOB exchanges, which correspond to EAP conversations. The exchanges start with a common handshake, which determines the type of the following exchange. The common handshake messages and the subsequent messages for each exchange type are listed in the diagrams below. The diagrams also specify the data fields present in each message. Each exchange comprises multiple EAP request-response pairs and ends in either EAP-Failure, indicating that authentication is not (yet) successful, or in EAP-Success.
このセクションでは、EAP-NOOB交換を定義します。これはEAP会話に対応しています。交換は一般的なハンドシェイクから始まります。これは、次の交換の種類を決定します。一般的なハンドシェイクメッセージと各交換タイプの後続のメッセージは、以下の図に記載されています。図は各メッセージに存在するデータフィールドも指定します。各交換機は複数のEAP要求 - 応答ペアを含み、その認証が（まだ）成功していないこと、またはEAP成功しているEAP障害のいずれでも終了します。
All EAP-NOOB exchanges start with common handshake messages. The handshake begins with the identity request and response that are common to all EAP methods. Their purpose is to enable the AAA architecture to route the EAP conversation to the EAP server and to enable the EAP server to select the EAP method. The handshake then continues with one EAP-NOOB request-response pair in which the server discovers the peer identifier used in EAP-NOOB and the peer state.
すべてのEAP-NOOB交換は、一般的なハンドシェイクメッセージから始まります。ハンドシェイクは、すべてのEAPメソッドに共通のID要求と応答から始まります。その目的は、AAAアーキテクチャがEAP会話をEAPサーバーにルーティングし、EAPサーバーがEAPメソッドを選択できるようにすることです。その後、ハンドシェイクは、サーバーがEAP-NOOBおよびピア状態で使用されるピア識別子を検出する1つのEAP-NOOB要求応答ペアで続行されます。
In more detail, each EAP-NOOB exchange begins with the authenticator sending an EAP-Request/Identity packet to the peer. From this point on, the EAP conversation occurs between the server and the peer, and the authenticator acts as a pass-through device. The peer responds to the authenticator with an EAP-Response/Identity packet, which contains the Network Access Identifier (NAI). The authenticator, acting as a pass-through device, forwards this response and the following EAP conversation between the peer and the AAA architecture. The AAA architecture routes the conversation to a specific AAA server (called "EAP server" or simply "server" in this specification) based on the realm part of the NAI. The server selects the EAP-NOOB method based on the user part of the NAI, as defined in Section 3.3.1.
より詳細には、各EAP-NOOB交換は、オーセンティケータがEAP-REQUEST / IDパケットをピアに送信することから始まります。この点から、EAP会話はサーバーとピアの間で発生し、オーセンティケータはパススルーデバイスとして機能します。ピアは、ネットワークアクセス識別子（NAI）を含むEAP対応/識別パケットを使用してオーセンティケータに応答します。パススルーデバイスとして機能するオーセンティケータは、この応答と次のEAP会話をピアとAAAアーキテクチャとの間で転送します。AAAアーキテクチャは、NAIの領域部分に基づいて、会話を特定のAAAサーバ（「EAPサーバ」と呼ばれる、または本明細書では「サーバ」と呼ばれます）に会話をルーティングします。サーバーは、セクション3.3.1で定義されているように、NAIのユーザー部分に基づいてEAP-NOOBメソッドを選択します。
After receiving the EAP-Response/Identity message, the server sends the first EAP-NOOB request (Type=1) to the peer, which responds with the peer identifier (PeerId) and state (PeerState) in the range 0..3. However, the peer SHOULD omit the PeerId from the response (Type=1) when PeerState=0. The server then chooses the EAP-NOOB exchange, i.e., the ensuing message sequence, as explained below. The peer recognizes the exchange based on the message type field (Type) of the next EAP-NOOB request received from the server.
EAP-Response / Identityメッセージを受信した後、サーバーは最初のEAP-NOOB要求（Type = 1）をピアに送信します。これにより、ピア識別子（PeerID）と状態（PeState）と応答します.0..3。ただし、PeerState = 0のとき、ピアは応答からピアードを省略します（TYPE = 1）。次に、サーバは、以下に説明するように、EAP - NOOB交換、すなわち続くメッセージシーケンスを選択する。ピアは、サーバーから受信した次のEAP-NOOB要求のメッセージタイプフィールド（Type）に基づいて交換を認識します。
The server MUST determine the exchange type based on the combination of the peer and server states as follows (also summarized in Table 14). If either the peer or server is in the Unregistered (0) state and the other is in one of the ephemeral states (0..2), the server chooses the Initial Exchange. If either the peer or server is in the OOB Received (2) state and the other is either in the Waiting for OOB (1) or OOB Received (2) state, the OOB Step has taken place and the server chooses the Completion Exchange. If both the server and peer are in the Waiting for OOB (1) state, the server chooses the Waiting Exchange. If the peer is in the Reconnecting (3) state and the server is in the Registered (4) or Reconnecting (3) state, the server chooses the Reconnect Exchange. All other state combinations are error situations where user action is required, and the server SHOULD indicate such errors to the peer with the error code 2002 (see Section 3.6.3). Note also that the peer MUST NOT initiate EAP-NOOB when the peer is in the Registered (4) state.
サーバーは、次のようにピアの状態とサーバーの状態の組み合わせに基づいて交換タイプを決定する必要があります（表14にも要約されています）。ピアまたはサーバーが未登録（0）状態にある場合、もう1つはエフェメラサート（0..2）にある場合、サーバーは最初のExchangeを選択します。 PeerまたはServerがOOBにある場合（2）状態ともう1つはOOB（1）またはOOBの待機（2）状態のどちらかで、OOBステップが行われ、サーバーが完了Exchangeを選択しました。サーバーとピアの両方がOOB（1）状態の待機中の場合、サーバーは待機交換を選択します。ピアが再接続（3）状態とサーバが登録されている（4）または再接続（3）状態にある場合、サーバは再接続交換を選択します。他のすべての状態の組み合わせは、ユーザーの処置が必要なエラー状況であり、サーバーはエラーコード2002を使用してそのようなエラーをピアに表示する必要があります（セクション3.6.3を参照）。ピアが登録されている（4）状態にあるときに、ピアがEAP-NOOBを開始してはいけません。
EAP Peer Authenticator EAP Server
| | |
|<----------- EAP-Request/Identity -| |
| |
| |
|------------ EAP-Response/Identity -------------->|
| (NAI=noob@eap-noob.arpa) |
| |
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=1) |
| |
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=1,[PeerId],PeerState=1) |
| |
| continuing with exchange-specific messages... |
Figure 2: Common Handshake in All EAP-NOOB Exchanges
図2：すべてのEAP-NOOB交換における一般的なハンドシェイク
The Initial Exchange comprises the common handshake and two further EAP-NOOB request-response pairs: one for version, cryptosuite, and parameter negotiation and the other for the ECDHE key exchange. The first EAP-NOOB request (Type=2) from the server contains a newly allocated PeerId for the peer and an optional NewNAI for assigning a new NAI to the peer. The server allocates a new PeerId in the Initial Exchange regardless of any old PeerId received in the previous response (Type=1). The server also sends in the request a list of the protocol versions (Vers) and cryptosuites (Cryptosuites) it supports, an indicator of the OOB channel directions it supports (Dirs), and a ServerInfo object. The peer chooses one of the versions and cryptosuites. The peer sends a response (Type=2) with the selected protocol version (Verp), the received PeerId, the selected cryptosuite (Cryptosuitep), an indicator of the OOB channel direction(s) selected by the peer (Dirp), and a PeerInfo object. In the second EAP-NOOB request and response (Type=3), the server and peer exchange the public components of their ECDHE keys and nonces (PKs, Ns, PKp, and Np). The ECDHE keys MUST be based on the negotiated cryptosuite, i.e., Cryptosuitep. The Initial Exchange always ends with EAP-Failure from the server because the authentication cannot yet be completed.
最初の交換は、一般的なハンドシェイクと2つのEAP-NOOB要求 - 応答ペアを含みます.1つは、バージョン、暗号化、およびパラメータネゴシエーション用、もう1つはECDHE鍵交換用です。サーバーから最初のEAP-NOOB要求（TYPE = 2）には、ピアのための新しく割り当てられたPeeridと、新しいNAIをピアに割り当てるためのオプションのNewnaiが含まれています。前の応答で受信された古いPeeridに関係なく、サーバーは最初の交換で新しいPeeridを割り当てます（TYPE = 1）。サーバーはまた、サポートされているプロトコルバージョン（vers）と暗号スイート（CryptoSuites）、それがサポートするOOBチャネルの指標（DIRS）、およびServerInfoオブジェクトのリストを送信します。ピアはバージョンと暗号スイートの1つを選択します。ピアは、選択されたプロトコルバージョン（verp）、受信したPeerid、選択された暗号化（CryptoSuitep）、ピア（DIRP）によって選択されたOOBチャネル方向のインジケータを、応答（TYPE = 2）を送信します。 PeerInfoオブジェクト。 2番目のEAP-NOOB要求と応答（Type = 3）では、サーバーとピアはECDHEキーとノンスの公開コンポーネント（PKS、NS、PKP、およびNP）を交換します。 ECDHEキーは、ネゴシエートされた暗号化除岩、すなわち暗号化粧品に基づく必要があります。認証はまだ完了できないため、最初の交換は常にサーバーからEAP障害で終わります。
EAP Peer EAP Server
| ...continuing from common handshake |
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=2,Vers,PeerId,[NewNAI], |
| Cryptosuites,Dirs,ServerInfo) |
| |
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=2,Verp,PeerId,Cryptosuitep, |
| Dirp,PeerInfo) |
| |
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=3,PeerId,PKs,Ns,[SleepTime]) |
| |
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=3,PeerId,PKp,Np) |
| |
| |
|<----------- EAP-Failure -------------------------|
| |
Figure 3: Initial Exchange
図3：最初のExchange.
At the conclusion of the Initial Exchange, both the server and the peer move to the Waiting for OOB (1) state.
最初の交換の終了時に、サーバーとピアの両方がOOB（1）の状態を待っています。
The OOB Step, labeled as OOB Output and OOB Input in Figure 1, takes place after the Initial Exchange. Depending on the negotiated OOB channel direction, the peer or the server outputs the OOB message as shown in Figures 4 or 5, respectively. The data fields are the PeerId, the secret nonce Noob, and the cryptographic fingerprint Hoob. The contents of the data fields are defined in Section 3.3.2. The OOB message is delivered to the other endpoint via a user-assisted OOB channel.
図1のOOB出力とOOB入力としてラベル付けされたOOBステップは、最初の交換後に行われます。ネゴシエートされたOOBチャネル方向に応じて、ピアまたはサーバはそれぞれ図4または5に示すようにOOBメッセージを出力する。データフィールドは、Peerid、Secret Nonce Noob、および暗号化指紋ボブです。データフィールドの内容はセクション3.3.2で定義されています。OOBメッセージは、ユーザ支援OOBチャネルを介して他のエンドポイントに配信される。
For brevity, we will use the terms OOB sender and OOB receiver in addition to the already familiar EAP server and EAP peer. If the OOB message is sent in the server-to-peer direction, the OOB sender is the server and the OOB receiver is the peer. On the other hand, if the OOB message is sent in the peer-to-server direction, the OOB sender is the peer and the OOB receiver is the server.
簡潔にするために、すでにおなじみのEAPサーバーとEAPピアに加えて、OOB送信者とOOB受信者の用語を使用します。OOBメッセージがサーバーからピア方向に送信された場合、OOB送信者はサーバーであり、OOB受信者はピアです。一方、OOBメッセージがピア間の方向に送信された場合、OOB送信者はピア、OOB受信者はサーバです。
EAP Peer EAP Server
| |
|=================OOB=============================>|
| (PeerId,Noob,Hoob) |
| |
Figure 4: OOB Step, from Peer to EAP Server
図4：PeerからEAPサーバーへのOOBステップ
EAP Peer EAP Server
| |
|<================OOB==============================|
| (PeerId,Noob,Hoob) |
| |
Figure 5: OOB Step, from EAP Server to Peer
図5：OOBステップ、EAPサーバーからピアへ
The OOB receiver MUST compare the received value of the fingerprint Hoob (see Section 3.3.2) with a value that it computed locally for the PeerID received. This integrity check ensures that the endpoints agree on contents of the Initial Exchange. If the values are equal, the receiver moves to the OOB Received (2) state. Otherwise, the receiver MUST reject the OOB message. For usability reasons, the OOB receiver SHOULD indicate the acceptance or rejection of the OOB message to the user. The receiver SHOULD reject invalid OOB messages without changing its state in the association state machine until an application-specific number of invalid messages (OobRetries) has been reached; after which, the receiver SHOULD consider it an error and go back to the Unregistered (0) state.
OOB受信機は、受信したPeeridのために局所的に計算された値で指紋踏み上げの受信値（セクション3.3.2参照）を比較する必要があります。この整合性チェックにより、エンドポイントが最初のExchangeの内容に同意するようになります。値が等しい場合、受信側はOOBに移動します（2）状態になります。それ以外の場合、受信機はOOBメッセージを拒否する必要があります。ユーザビリティ上の理由から、OOB受信者は、OOBメッセージのユーザへの受付または拒否を示すべきである。受信側は、Application State Machineの状態を変更せずに無効なOOBメッセージ（OOBRETRIES）に達するまで、無効なOOBメッセージを拒否する必要があります。その後、受信機はエラーを考慮して未登録（0）状態に戻るべきです。
The server or peer MAY send multiple OOB messages with different Noob values while in the Waiting for OOB (1) state. The OOB sender SHOULD remember the Noob values until they expire and accept any one of them in the following Completion Exchange. The Noob values sent by the server expire after an application-dependent timeout (NoobTimeout), and the server MUST NOT accept Noob values older than that in the Completion Exchange. The RECOMMENDED value for NoobTimeout is 3600 seconds if there are no application-specific reasons for making it shorter or longer. The Noob values sent by the peer expire, as defined in Section 3.2.5.
サーバーまたはピアは、OOB（1）の状態を待っている間に、異なるNOOB値を持つ複数のOOBメッセージを送信することができます。OOB送信者は、それらが期限切れになるまでNoob値を覚えておく必要があり、次の完了Exchangeでそれらのいずれかを受け入れます。アプリケーション依存タイムアウト（NoobTimeout）の後にServerによって送信されたNOOB値が期限切れになり、サーバーは完了Exchange以外のNOOB値を使用してはいけません。アプリケーション固有の理由が短くても長くするため、NoObTimeoutの推奨値は3600秒です。セクション3.2.5で定義されているように、ピアの有効期限が切れるNOOB値。
The OOB receiver does not accept further OOB messages after it has accepted one and moved to the OOB Received (2) state. However, the receiver MAY buffer redundant OOB messages in case an OOB message expiry or similar error detected in the Completion Exchange causes it to return to the Waiting for OOB (1) state. It is RECOMMENDED that the OOB receiver notifies the user about redundant OOB messages, but it MAY instead discard them silently.
OOB受信者は、それが受け入れられた後にさらにOOBメッセージを受け入れず、受信した（2）状態にあるOOBに移動しました。ただし、完了Exchangeで検出されたOOBメッセージの有効期限または同様のエラーが発生した場合には、受信側が冗長OOBメッセージをバッファしてもよい。OOB受信者が冗長OOBメッセージについてユーザーに通知することをお勧めしますが、代わりに黙って廃棄することがあります。
The sender will typically generate a new Noob, and therefore a new OOB message, at constant time intervals (NoobInterval). The RECOMMENDED interval is
送信者は通常、新しいNoob、したがって新しいOOBメッセージ、したがって、一定の時間間隔（NoobInterval）で生成されます。推奨されている間隔です
NoobInterval = NoobTimeout / 2
in which case, the receiver of the OOB will at any given time accept either of the two latest Noob values. However, the timing of the Noob generation may also be based on user interaction or on implementation considerations.
その場合、OOBの受信機はいつでも2つの最新のNOOB値のいずれかを受け入れます。しかしながら、NOOB世代のタイミングは、ユーザの対話または実装上の考慮事項に基づいてもよい。
Even though not recommended (see Section 3.3), this specification allows both directions to be negotiated (Dirp=3) for the OOB channel. In that case, both sides SHOULD output the OOB message, and it is up to the user to deliver at least one of them.
推奨されていないとしても（セクション3.3を参照）、この仕様はOOBチャネルの両方向（DIRP = 3）を交渉することを可能にします。その場合、両側はOOBメッセージを出力する必要があり、その少なくとも1つを配信するのはユーザー次第です。
The details of the OOB channel implementation including the message encoding are defined by the application. Appendix D gives an example of how the OOB message can be encoded as a URL that may be embedded in a dynamic QR code or NFC (Near Field Communication) tag.
メッセージエンコーディングを含むOOBチャネル実装の詳細は、アプリケーションによって定義されます。付録Dは、動的QRコードまたはNFC（近くのフィールド通信）タグに埋め込まれている可能性があるURLとして、OOBメッセージをどのようにエンコードするかの例を示します。
After the Initial Exchange, if the OOB channel directions selected by the peer include the peer-to-server direction, the peer SHOULD initiate the EAP-NOOB method again after an applications-specific waiting time in order to probe for completion of the OOB Step. If the OOB channel directions selected by the peer include the server-to-peer direction and the peer receives the OOB message, it SHOULD initiate the EAP-NOOB method immediately. Depending on the combination of the peer and server states, the server continues with the Completion Exchange or Waiting Exchange (see Section 3.2.1 on how the server makes this decision).
最初のExchangeの後、ピアによって選択されたOOBチャネルの指示がピアツーサーバーの方向を含む場合、PEERは、OOBステップの完了を探すためにアプリケーション固有の待ち時間の後に再びEAP-NOOBメソッドを開始する必要があります。。ピアによって選択されたOOBチャネルの方向がサーバからピア方向を含む場合、ピアはOOBメッセージを受信した場合、すぐにEAP-NOOBメソッドを開始する必要があります。ピアの状態とサーバーの状態の組み合わせに応じて、サーバーは完了ExchangeまたはWaiting Exchangeを続けます（サーバーがこの決定を下す方法についてのセクション3.2.1を参照）。
The Completion Exchange comprises the common handshake and one or two further EAP-NOOB request-response pairs. If the peer is in the Waiting for OOB (1) state, the OOB message has been sent in the peer-to-server direction. In that case, only one request-response pair (Type=6) takes place. In the request, the server sends the NoobId value (see Section 3.3.2), which the peer uses to identify the exact OOB message received by the server. On the other hand, if the peer is in the OOB Received (2) state, the direction of the OOB message is from server to peer. In this case, two request-response pairs (Type=5 and Type=6) are needed. The purpose of the first request-response pair (Type=5) is that it enables the server to discover NoobId, which identifies the exact OOB message received by the peer. The server returns the same NoobId to the peer in the latter request.
完了した交換は、共通のハンドシェイクと1つか2つのEAP-NOOB要求 - 応答ペアを含みます。ピアがOOB（1）状態の待機中の場合、OOBメッセージはピア間の方向に送信されました。その場合、1つの要求応答ペア（Type = 6）のみが行われます。リクエストでは、サーバーはNoobID値を送信します（セクション3.3.2を参照）、ピアはサーバーによって受信された正確なOOBメッセージを識別するために使用します。一方、ピアがOOBの状態（2）状態の場合、OOBメッセージの方向はサーバからピアへのものです。この場合、2つの要求応答ペア（Type = 5、Type = 6）が必要です。最初の要求応答ペア（Type = 5）の目的は、サーバーがNoobidを検出できることです。これは、ピアによって受信された正確なOOBメッセージを識別します。サーバーは、後者の要求の同じNOOBIDをピアに戻します。
In the last request-response pair (Type=6) of the Completion Exchange, the server and peer exchange message authentication codes. Both sides MUST compute the keys Kms and Kmp, as defined in Section 3.5, and the message authentication codes MACs and MACp, as defined in Section 3.3.2. Both sides MUST compare the received message authentication code with a locally computed value. If the peer finds that it has received the correct value of MACs and the server finds that it has received the correct value of MACp, the Completion Exchange ends in EAP-Success. Otherwise, the endpoint where the comparison fails indicates this with an error message (error code 4001, see Section 3.6.5), and the Completion Exchange ends in EAP-Failure.
完了Exchangeの最後の要求応答ペア（Type = 6）では、サーバーとピア交換メッセージ認証コード。両側は、セクション3.5で定義されているキーKMSとKMPを、セクション3.3.2で定義されているように、MACSとMACPにメッセージ認証コードを計算する必要があります。両側は受信したメッセージ認証コードをローカルに計算された値と比較する必要があります。ピアがMACの正しい値を受信したことが判明した場合、サーバーがMACPの正しい値を受信したことを検出した場合、完了ExchangeはEAP-SUCCESSで終了します。それ以外の場合、比較が失敗したエンドポイントはエラーメッセージ（エラーコード4001、セクション3.6.5を参照）で、完了ExchangeはEAP障害で終了します。
After the successful Completion Exchange, both the server and the peer move to the Registered (4) state. They also derive the output keying material and store the persistent EAP-NOOB association state, as defined in Sections 3.4 and 3.5.
完了完了交換が終了したら、サーバーとピアの両方が登録済み（4）状態に移動します。それらはまた、セクション3.4および3.5で定義されているように、出力キーイングマテリアルを導出し、永続的なEAP-NOOBアソシエーション状態を格納します。
It is possible that the OOB message expires before it is received. In that case, the sender of the OOB message no longer recognizes the NoobId that it receives in the Completion Exchange. Another reason why the OOB sender might not recognize the NoobId is if the received OOB message was spoofed and contained an attacker-generated Noob value. The recipient of an unrecognized NoobId indicates this with an error message (error code 2003, see Section 3.6.1), and the Completion Exchange ends in EAP-Failure. The recipient of the error message 2003 moves back to the Waiting for OOB (1) state. This state transition is called OOB Reject in Figure 1 (even though it really is a specific type of failed Completion Exchange). On the other hand, the sender of the error message stays in its previous state.
OOBメッセージが受信される前に期限切れになる可能性があります。その場合、OOBメッセージの送信者は、完了Exchangeで受信したNoobidを認識しなくなりました。OOB送信者がnoobidを認識しないことがあるもう1つの理由は、受信したOOBメッセージが偽装され、攻撃者に生成されたNOOB値を含んでいた場合です。認識されていないNoobidの受信者はエラーメッセージ（エラーコード2003、セクション3.6.1を参照）でこれを示し、完了ExchangeはEAP障害で終了します。エラーメッセージ2003の受信者は、OOB（1）状態の待機中に戻る。この状態遷移は図1のOOB拒否と呼ばれます（実際には特定のタイプの失敗した完了Exchangeがあります）。一方、エラーメッセージの送信者は以前の状態に留まります。
Although it is not expected to occur in practice, poor user interface design could lead to two OOB messages delivered simultaneously, one from the peer to the server and the other from the server to the peer. The server detects this event in the beginning of the Completion Exchange by observing that both the server and peer are in the OOB Received (2) state. In that case, as a tiebreaker, the server MUST behave as if only the server-to-peer message had been delivered.
実際には発生することは期待されていませんが、ユーザーインターフェイス設計の低下は、同時に2つのOOBメッセージが同時に配信される可能性があります。これは、ピアからサーバーへ、もう1つはサーバーからピアへのものです。サーバーは、サーバーとピアの両方がOOBにあることを観察することによって、完了Exchangeの開始時にこのイベントを検出します（2）状態。その場合、タイブレーカーとして、サーバーはサーバーからピアメッセージのみが配信されたかのように動作しなければなりません。
EAP Peer EAP Server
| ...continuing from common handshake |
| |
|<----------- [ EAP-Request/EAP-NOOB ] ------------|
| (Type=5,PeerId) |
| |
| |
|------------ [ EAP-Response/EAP-NOOB ] ---------->|
| (Type=5,PeerId,NoobId) |
| |
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=6,PeerId,NoobId,MACs) |
| |
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=6,PeerId,MACp) |
| |
| |
|<----------- EAP-Success -------------------------|
| |
Figure 6: Completion Exchange
図6：完了Exchange
As explained in Section 3.2.4, the peer SHOULD probe the server for completion of the OOB Step. When the combination of the peer and server states indicates that the OOB message has not yet been delivered, the server chooses the Waiting Exchange (see Section 3.2.1 on how the server makes this decision). The Waiting Exchange comprises the common handshake and one further request-response pair, and it always ends in EAP-Failure.
3.2.4節で説明したように、ピアはOOBステップの完了のためにサーバーをプローブする必要があります。PeerとServerの状態の組み合わせがOOBメッセージがまだ配信されていないことを示している場合、サーバーは待機交換を選択します（サーバーがこの決定を下す方法については、セクション3.2.1を参照）。待機交換は、一般的なハンドシェイクと1つのさらなる要求応答ペアを含み、常にEAP障害で終了します。
In order to limit the rate at which peers probe the server, the server MAY send to the peer either in the Initial Exchange or in the Waiting Exchange a minimum time to wait before probing the server again. A peer that has not received an OOB message SHOULD wait at least the server-specified minimum waiting time in seconds (SleepTime) before initiating EAP again with the same server. The peer uses the latest SleepTime value that it has received in or after the Initial Exchange. If the server has not sent any SleepTime value, the peer MUST wait for an application-specified minimum time (SleepTimeDefault).
ピアがサーバをプローブするレートを制限するために、サーバは、サーバを再びプロービングする前に待機して待機して待機して待機して待機してもよい。OOBメッセージを受信していないピアは、同じサーバーを使用してEAPを再び開始する前に、少なくともサーバー指定の最小待機時間（SELEPTIME）を待機する必要があります。ピアは、最初のExchange以降に受信した最新のSleeptime値を使用します。サーバーがSLEPTIME値を送信していない場合、ピアはアプリケーション指定の最小時間（SLEPTIMEDEPAULT）を待機する必要があります。
After the Waiting Exchange, the peer MUST discard (from its local ephemeral storage) Noob values that it has sent to the server in OOB messages that are older than the application-defined timeout NoobTimeout (see Section 3.2.3). The peer SHOULD discard such expired Noob values even if the probing failed because of, e.g., failure to connect to the EAP server or an incorrect message authentication code. The timeout of peer-generated Noob values is defined like this in order to allow the peer to probe the server once after it has waited for the server-specified SleepTime.
待機交換後、ピアは、アプリケーション定義のタイムアウトNOOBTIMEOUTより古いOOBメッセージでサーバーに送信されたNOOB値を廃棄しなければなりません（セクション3.2.3を参照）。プロービングが失敗したとしても、ピアはそのような期限切れのNOOB値を破棄しても、EAPサーバまたは誤ったメッセージ認証コードへの接続が失敗するはずです。ピア生成されたNOOB値のタイムアウトは、サーバー指定されたSleeptimeを待ってから1回サーバーをプローブできるようにするために、このように定義されます。
If the server and peer have negotiated to use only the server-to-peer direction for the OOB channel (Dirp=2), the peer SHOULD nevertheless probe the server. The purpose of this is to keep the server informed about the peers that are still waiting for OOB messages. The server MAY set SleepTime to a high number (e.g., 3600) to prevent the peer from probing the server frequently.
サーバーとピアがOOBチャネル（DIRP = 2）のサーバーからピア方向のみを使用するようにネゴシエートされた場合、ピアはサーバーをプローブする必要があります。これの目的は、依然としてOOBメッセージを待っているピアについてサーバーを通知させることです。サーバーは、ピアがサーバーを頻繁にプローブするのを防ぐために、SLEPTIMEを多数（例えば、3600）に設定することができます。
EAP Peer EAP Server
| ...continuing from common handshake |
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=4,PeerId,[SleepTime]) |
| |
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=4,PeerId) |
| |
| |
|<----------- EAP-Failure -------------------------|
| |
Figure 7: Waiting Exchange
図7：エクスチェンジ待ち
This section defines the various identifiers and data fields used in the EAP-NOOB method.
このセクションでは、EAP-NOOBメソッドで使用されるさまざまな識別子とデータフィールドを定義します。
The server allocates a new peer identifier (PeerId) for the peer in the Initial Exchange. The peer identifier MUST follow the syntax of the utf8-username specified in [RFC7542]. The server MUST generate the identifiers in such a way that they do not repeat and cannot be guessed by the peer or third parties before the server sends them to the peer in the Initial Exchange. One way to generate the identifiers is to choose a random 16-byte identifier and to base64url encode it without padding [RFC4648] into a 22-character ASCII string. Another way to generate the identifiers is to choose a random 22-character alphanumeric ASCII string. It is RECOMMENDED to not use identifiers longer than this because they result in longer OOB messages.
サーバーは、最初のExchange内のピアの新しいピア識別子（PeerID）を割り当てます。ピア識別子は、[RFC7542]で指定されたutf8-usernameの構文に従う必要があります。サーバーは、サーバーが最初のExchangeのピアにそれらを送信する前に、それらが繰り返されずに推測できないような方法で識別子を生成する必要があります。識別子を生成する1つの方法は、ランダムな16バイトの識別子を選択することであり、22文字のASCII文字列にパディングすることなく符号化したBase64URLエンコードを選択することです。識別子を生成するもう1つの方法は、ランダムな22文字の英数字のASCII文字列を選択することです。これより長い識別子を使用しないことをお勧めします。
The peer uses the allocated PeerId to identify itself to the server in the subsequent exchanges. The peer MUST copy the PeerId byte by byte from the message where it was allocated, and the server MUST perform a byte-by-byte comparison between the received and the previously allocated PeerID. The peer sets the PeerId value in response type 1 as follows. As stated in Section 3.2.1, when the peer is in the Unregistered (0) state, it SHOULD omit the PeerId from response type 1. When the peer is in one of the states 1..2, it MUST use the PeerId that the server assigned to it in the latest Initial Exchange. When the peer is in one of the persistent states 3..4, it MUST use the PeerId from its persistent EAP-NOOB association. (The PeerId is written to the association when the peer moves to the Registered (4) state after a Completion Exchange.)
ピアは割り当てられたピアドを使用して、次の交換内のサーバーに自分自身を識別します。ピアは、割り当てられているメッセージからPeeridバイトをバイトでコピーする必要があり、サーバーは受信した、および以前に割り当てられたPEERIDとの間のバイトごとの比較を実行する必要があります。ピアは、次のように応答タイプ1のPeerid値を設定します。セクション3.2.1に記載されているように、ピアが未登録（0）状態にあるとき、それは応答タイプ1からピアドを省略してください。ピアが一方の状態1..2にあるとき、それはPeeridを使用しなければなりません。最新の最初の交換でそれに割り当てられたサーバー。ピアが永続状態3..4のいずれかにある場合、それはその永続的なEAP-NOOB関連のアソシエーションからPeeridを使用する必要があります。（ピアが完了した後に登録された状態（4）状態に移行した場合、PeerIDは関連付けに書き込まれます。）
The default NAI for the peer is "noob@eap-noob.arpa". The peer implementation MAY allow the user or application to configure a different NAI, which overrides the default NAI. Furthermore, the server MAY assign a new NAI to the peer in the Initial Exchange or Reconnect Exchange in the NewNAI field of request types 2 and 7 to override any previous NAI value. When the peer is in the Unregistered (0) state, or when the peer is in one of the states 1..2 and the server did not send a NewNAI in the latest Initial Exchange, the peer MUST use the configured NAI or, if it does not exist, the default NAI. When the peer is in one of the states 1..2 and the server sent a NewNAI in the latest Initial Exchange, the peer MUST use this server-assigned NAI. When the peer moves to the Registered (4) state after the Completion Exchange, it writes to the persistent EAP-NOOB association the same NAI value that it used in the Completion Exchange. When the peer is in the Reconnecting (3) or Registered (4) state, it MUST use the NAI from its persistent EAP-NOOB association. When the server sends NewNAI in the Reconnect Exchange, the peer writes its value to the persistent EAP-NOOB association when it moves from the Reconnecting (3) state to the Registered (4) state. All the NAI values MUST follow the syntax specified in [RFC7542].
ピアのデフォルトのNAIは "noob@ap-noob.arpa"です。ピア実装は、ユーザまたはアプリケーションがデフォルトのNAIをオーバーライドする別のNAIを構成することを可能にし得る。さらに、サーバは、最初のNAI値2および7のNewnaiフィールド内の新しいNAIまたは再接続交換をピアに割り当てることができ、前のNAI値をオーバーライドすることができる。ピアが未登録（0）状態にある場合、またはピアが状態1..2とサーバーが最新の最初のExchangeでNEWNAIを送信しなかった場合、ピアは設定されたNAIを使用する必要があります。デフォルトのNAIは存在しません。ピアが最新の最初のExchangeでNewnaiを送信した状態のいずれかの状態にある場合、ピアはこのサーバー割り当てられたNAIを使用しなければなりません。完了Exchangeの後にピアが登録（4）状態に移動すると、永続的なEAP-NOOBアソシエーションに完了したExchangeで使用したものと同じNAI値が書き込まれます。ピアが再接続（3）または登録されている（4）状態にあるとき、それはその永続的なEAP-NOOB協会からNAIを使用しなければなりません。サーバーが再接続ExchangeでNewnaiを送信すると、ピアは再接続（3）状態から登録されている（4）状態に移動すると、その値を永続的なEAP-NOOBアソシエーションに書き込みます。すべてのNAI値は[RFC7542]で指定された構文に従う必要があります。
The purpose of the server-assigned NAI is to enable more flexible routing of the EAP sessions over the AAA infrastructure, including roaming scenarios (see Appendix C). Moreover, some authenticators or AAA servers use the realm part of the assigned NAI to determine peer-specific connection parameters, such as isolating the peer to a specific VLAN. On the other hand, the user- or application-configured NAI enables registration of new devices while roaming. It also enables manufacturers to set up their own AAA servers for bootstrapping of new peer devices.
サーバーが割り当てられたNAIの目的は、ローミングシナリオを含む、AAAインフラストラクチャを介したEAPセッションのより柔軟なルーティングを有効にすることです（付録Cを参照）。さらに、いくつかのオーセンティケータンスまたはAAAサーバは、割り当てられたNAIのレルム部分を使用して、ピアを特定のVLANに分離するなど、ピア固有の接続パラメータを決定します。一方、ユーザまたはアプリケーション設定されたNAIにより、ローミング中に新しいデバイスの登録が可能になります。また、製造業者は新しいピアデバイスのブートストラップのために独自のAAAサーバを設定することができます。
The peer's PeerId and server-assigned NAI are ephemeral until a successful Completion Exchange takes place. Thereafter, the values become parts of the persistent EAP-NOOB association until the user resets the peer and server or until a new NAI is assigned in the Reconnect Exchange.
完了した完了交換が行われるまで、ピアのPeeridとServerが割り当てられたNAIはエフェメラルです。その後、ユーザがピアとサーバをリセットするまで、または再接続交換で新しいNAIが割り当てられるまで、値は永続的なEAP-NOOB関連の一部になります。
Table 1 defines the data fields in the protocol messages. The in-band messages are formatted as JSON objects [RFC8259] in UTF-8 encoding. The JSON member names are in the left-hand column of the table.
表1は、プロトコルメッセージ内のデータフィールドを定義します。インバンドメッセージは、UTF-8エンコーディングのJSONオブジェクト[RFC8259]としてフォーマットされています。JSONメンバー名はテーブルの左側の列にあります。
+===============+=================================================+
| Data Field | Description |
+===============+=================================================+
| Vers, Verp | EAP-NOOB protocol versions supported by the EAP |
| | server and the protocol version chosen by the |
| | peer. Vers is a JSON array of unsigned |
| | integers, and Verp is an unsigned integer. |
| | Example values are "[1]" and "1", respectively. |
+---------------+-------------------------------------------------+
| PeerId | Peer identifier, as defined in Section 3.3.1. |
+---------------+-------------------------------------------------+
| NAI, NewNAI | Peer NAI and server-assigned new peer NAI, as |
| | defined in Section 3.3.1. |
+---------------+-------------------------------------------------+
| Type | EAP-NOOB message type. The type is an integer |
| | in the range 0..9. EAP-NOOB requests and the |
| | corresponding responses share the same type |
| | value. |
+---------------+-------------------------------------------------+
| PeerState | Peer state is an integer in the range 0..4 (see |
| | Figure 1). However, only values 0..3 are ever |
| | sent in the protocol messages. |
+---------------+-------------------------------------------------+
| PKs, PKp | The public components of the ECDHE keys of the |
| | server and peer. PKs and PKp are sent in the |
| | JSON Web Key (JWK) format [RFC7517]. The |
| | detailed format of the JWK object is defined by |
| | the cryptosuite. |
+---------------+-------------------------------------------------+
| Cryptosuites, | The identifiers of cryptosuites supported by |
| Cryptosuitep | the server and of the cryptosuite selected by |
| | the peer. The server-supported cryptosuites in |
| | Cryptosuites are formatted as a JSON array of |
| | the identifier integers. The server MUST send |
| | a nonempty array with no repeating elements, |
| | ordered by decreasing priority. The peer MUST |
| | respond with exactly one suite in the |
| | Cryptosuitep value, formatted as an identifier |
| | integer. Mandatory-to-implement cryptosuites |
| | and the registration procedure for new |
| | cryptosuites are specified in Section 5.1. |
| | Example values are "[1]" and "1", respectively. |
+---------------+-------------------------------------------------+
| Dirs, Dirp | An integer indicating the OOB channel |
| | directions supported by the server and the |
| | directions selected by the peer. The possible |
| | values are 1=peer-to-server, 2=server-to-peer, |
| | and 3=both directions. |
+---------------+-------------------------------------------------+
| Dir | The actual direction of the OOB message |
| | (1=peer-to-server, 2=server-to-peer). This |
| | value is not sent over any communication |
| | channel, but it is included in the computation |
| | of the cryptographic fingerprint Hoob. |
+---------------+-------------------------------------------------+
| Ns, Np | 32-byte nonces for the Initial Exchange. |
+---------------+-------------------------------------------------+
| ServerInfo | This field contains information about the |
| | server to be passed from the EAP method to the |
| | application layer in the peer. The information |
| | is specific to the application or to the OOB |
| | channel, and it is encoded as a JSON object of |
| | at most 500 bytes. It could include, for |
| | example, the access-network name and server |
| | name, a Uniform Resource Locator (URL) |
| | [RFC3986], or some other information that helps |
| | the user deliver the OOB message to the server |
| | through the out-of-band channel. |
+---------------+-------------------------------------------------+
| PeerInfo | This field contains information about the peer |
| | to be passed from the EAP method to the |
| | application layer in the server. The |
| | information is specific to the application or |
| | to the OOB channel, and it is encoded as a JSON |
| | object of at most 500 bytes. It could include, |
| | for example, the peer brand, model, and serial |
| | number, which help the user distinguish between |
| | devices and deliver the OOB message to the |
| | correct peer through the out-of-band channel. |
+---------------+-------------------------------------------------+
| SleepTime | The number of seconds for which the peer MUST |
| | NOT start a new execution of the EAP-NOOB |
| | method with the authenticator, unless the peer |
| | receives the OOB message or the sending is |
| | triggered by an application-specific user |
| | action. The server can use this field to limit |
| | the rate at which peers probe it. SleepTime is |
| | an unsigned integer in the range 0..3600. |
+---------------+-------------------------------------------------+
| Noob | 16-byte secret nonce sent through the OOB |
| | channel and used for the session key |
| | derivation. The endpoint that received the OOB |
| | message uses this secret in the Completion |
| | Exchange to authenticate the exchanged key to |
| | the endpoint that sent the OOB message. |
+---------------+-------------------------------------------------+
| Hoob | 16-byte cryptographic fingerprint (i.e., hash |
| | value) computed from all the parameters |
| | exchanged in the Initial Exchange and in the |
| | OOB message. Receiving this fingerprint over |
| | the OOB channel guarantees the integrity of the |
| | key exchange and parameter negotiation. Hence, |
| | it authenticates the exchanged key to the |
| | endpoint that receives the OOB message. |
+---------------+-------------------------------------------------+
| NoobId | 16-byte identifier for the OOB message, |
| | computed with a one-way function from the nonce |
| | Noob in the message. |
+---------------+-------------------------------------------------+
| MACs, MACp | Message authentication codes (HMAC) for mutual |
| | authentication, key confirmation, and integrity |
| | check on the exchanged information. The input |
| | to the HMAC is defined below, and the key for |
| | the HMAC is defined in Section 3.5. |
+---------------+-------------------------------------------------+
| Ns2, Np2 | 32-byte nonces for the Reconnect Exchange. |
+---------------+-------------------------------------------------+
| KeyingMode | Integer indicating the key derivation method. 0 |
| | in the Completion Exchange, and 1..3 in the |
| | Reconnect Exchange. |
+---------------+-------------------------------------------------+
| PKs2, PKp2 | The public components of the ECDHE keys of the |
| | server and peer for the Reconnect Exchange. |
| | PKp2 and PKs2 are sent in the JSON Web Key |
| | (JWK) format [RFC7517]. The detailed format of |
| | the JWK object is defined by the cryptosuite. |
+---------------+-------------------------------------------------+
| MACs2, MACp2 | Message authentication codes (HMAC) for mutual |
| | authentication, key confirmation, and integrity |
| | check on the Reconnect Exchange. The input to |
| | the HMAC is defined below, and the key for the |
| | HMAC is defined in Section 3.5. |
+---------------+-------------------------------------------------+
| ErrorCode | Integer indicating an error condition. Defined |
| | in Section 5.3. |
+---------------+-------------------------------------------------+
| ErrorInfo | Textual error message for logging and debugging |
| | purposes. A UTF-8 string of at most 500 bytes. |
+---------------+-------------------------------------------------+
Table 1: Message Data Fields
表1：メッセージデータフィールド
It is RECOMMENDED for servers to support both OOB channel directions (Dirs=3) unless the type of the OOB channel limits them to one direction (Dirs=1 or Dirs=2). On the other hand, it is RECOMMENDED that the peer selects only one direction (Dirp=1 or Dirp=2) even when both directions (Dirp=3) would be technically possible. The reason is that, if value 3 is negotiated, the user may be presented with two OOB messages, one for each direction, even though only one of them needs to be delivered. This can be confusing to the user. Nevertheless, the EAP-NOOB protocol is designed to also cope with the value 3; in which case, it uses the first delivered OOB message. In the unlikely case of simultaneously delivered OOB messages, the protocol prioritizes the server-to-peer direction.
OOBチャネルの種類がそれらを一方向に制限する（DIRS = 1またはDIRS = 2）を指定しない限り、サーバーはOOBチャネルの方向（dirs = 3）をサポートすることが推奨されます。一方、両方向（DIRP = 3）が技術的に可能であっても、ピアは一方向（DIRP = 1またはDIRP = 2）のみを選択することをお勧めします。その理由は、値3がネゴシエートされている場合、それらのうちの1つだけが配信される必要があるとしても、ユーザは各方向に対して1つずつ、2つのOOBメッセージを提示することができるからである。これはユーザーにとって混乱を招く可能性があります。それにもかかわらず、EAP-NOOBプロトコルは値3にも対処するように設計されています。その場合、最初に配信されたOOBメッセージを使用します。同時にOOBメッセージを配信するのではあり得ない場合、プロトコルはサーバーからピア方向に優先されます。
The nonces in the in-band messages (Ns, Np, Ns2, Np2) are 32-byte fresh random byte strings, and the secret nonce Noob is a 16-byte fresh random byte string. All the nonces are generated by the endpoint that sends the message.
インバンドメッセージ（NS、NP、NS2、NP2）内のノンスは32バイトのフレッシュランダムバイト文字列であり、Secret Nonce Noobは16バイトのフレッシュランダムバイト文字列です。すべてのノンスはメッセージを送信するエンドポイントによって生成されます。
The fingerprint Hoob and the identifier NoobId are computed with the cryptographic hash function H, which is specified in the negotiated cryptosuite and truncated to the 16 leftmost bytes of the output. The message authentication codes (MACs, MACp, MACs2, MACp2) are computed with the function HMAC, which is the hashed message authentication code [RFC2104] based on the cryptographic hash function H and truncated to the 32 leftmost bytes of the output.
指紋加紙および識別子Noobidは、ネゴシエートされた暗号化中で指定され、出力の16個の最左バイトに切り捨てられる暗号化ハッシュ関数Hを用いて計算される。メッセージ認証コード（MACS、MACP、MACS2、MACP2）は、暗号化ハッシュ関数Hに基づいてハッシュされたメッセージ認証コード[RFC2104]であり、出力の残りの32バイトに切り捨てられた関数HMACで計算されます。
The inputs to the hash function for computing the fingerprint Hoob and to the HMAC for computing MACs, MACp, MACs2, and MACp2 are JSON arrays containing a fixed number (17) of elements. The array elements MUST be copied to the array verbatim from the sent and received in-band messages. When the element is a JSON object, its members MUST NOT be reordered or reencoded. White space MUST NOT be added anywhere in the JSON structure. Implementers should check that their JSON library copies the elements as UTF-8 strings, does not modify them in any way, and does not add white space to the HMAC input.
指紋加孔を計算するためのハッシュ関数およびMACS、MACP、MACS2、およびMACP2を計算するためのHMACへの入力は、固定数（17）の要素を含むJSONアレイである。配列要素は、送受信された帯域内のメッセージからアレイverbatimにコピーする必要があります。要素がJSONオブジェクトの場合、そのメンバーは並べ替えまたは再停止されてはいけません。ホワイトスペースは、JSON構造内のどこにでも追加してはいけません。実装者は、JSONライブラリが要素をUTF-8文字列としてコピーしていることを確認し、それらを任意の方法で変更しないため、HMAC入力に空白を追加しません。
The inputs for computing the fingerprint and message authentication codes are the following:
指紋とメッセージ認証コードを計算するための入力は次のとおりです。
Hoob = H(Dir,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo, Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob).
Hoob = H（DIR、Vers、Verp、Peerid、CryptoSuites、Dirs、ServerInfo、CryptoSuitep、Dirp、Nai、PeerInfo、0、PKS、NS、PKP、NP、Noob）。
NoobId = H("NoobId",Noob).
noobid = h（ "noobid"、noob）。
MACs = HMAC(Kms; 2,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo, Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob).
MACS = HMAC（KMS; 2、Verp、Verp、Peerid、CryptoSuites、Dirs、ServerInfo、CryptoSupep、Dirp、Nai、PeerInfo、0、PKS、NS、PKP、NP、Noob）。
MACp = HMAC(Kmp; 1,Vers,Verp,PeerId,Cryptosuites,Dirs,ServerInfo, Cryptosuitep,Dirp,NAI,PeerInfo,0,PKs,Ns,PKp,Np,Noob).
MacP = HMAC（KMP; 1、Verp、Verp、Peerid、CryptoSuites、Dirs、ServerInfo、CryptoSuitep、Dirp、Nai、PeerInfo、0、PKS、NS、PKP、NP、Noob）。
MACs2 = HMAC(Kms2; 2,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo], Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2,"")
MACS2 = HMAC（KMS2; 2、Verp、Verp、Peerid、CryptoSuites、 "、[ServerInfo]、CryptoSuitep、" "、Nai、[PeerInfo]、キーイングモード、[PKS2]、NS2、[PKP2]、NP2、" "）
MACp2 = HMAC(Kmp2; 1,Vers,Verp,PeerId,Cryptosuites,"",[ServerInfo], Cryptosuitep,"",NAI,[PeerInfo],KeyingMode,[PKs2],Ns2,[PKp2],Np2,"")
MACP2 = HMAC（KMP2; 1、Verp、Verp、Peerid、CryptoSuites、 "、[ServerInfo]、CryptoSuitep、" "、Nai、[PeerInfo]、キーイングモード、[PKS2]、NS2、[PKP2]、NP2、" "）
The inputs denoted with "" above are not present, and the values in brackets [] are optional. Both kinds of missing input values are represented by empty strings "" in the HMAC input (JSON array). The NAI included in the inputs is the NAI value that will be in the persistent EAP-NOOB association if the Completion Exchange or Reconnect Exchange succeeds. In the Completion Exchange, the NAI is the NewNAI value assigned by the server in the preceding Initial Exchange or, if no NewNAI was sent, the NAI used by the client in the Initial Exchange. In the Reconnect Exchange, the NAI is the NewNAI value assigned by the server in the same Reconnect Exchange or, if no NewNAI was sent, the unchanged NAI from the persistent EAP-NOOB association. Each of the values in brackets for the computation of Macs2 and Macp2 MUST be included if it was sent or received in the same Reconnect Exchange; otherwise, the value is replaced by an empty string "".
上記の「」で示される入力は存在しないため、括弧[]の値はオプションです。HMAC入力（JSONアレイ）には、両方の種類の欠落入力値が空の文字列で表されます。入力に含まれているNAIは、完了ExchangeまたはRececonnect Exchangeが成功した場合、永続的なEAP-NOOB関連付けられているNAI値です。完了Exchangeでは、前の最初のExchangeでサーバーによって割り当てられたNewnai値、またはNewnaiが送信されていない場合は、最初のExchangeでクライアントによって使用されます。Reconnect Exchangeでは、NAIは、同じ再接続交換内のサーバーによって割り当てられたNEWNAI値、またはNEWNAIが送信されなかった場合は、永続的なEAP-NOOBアソシエーションからの変更されていません。MACS2およびMACP2の計算のためのブラケットの各値は、同じ再接続交換内で送受信された場合に含まれていなければなりません。それ以外の場合、値は空の文字列 ""に置き換えられます。
The parameter Dir indicates the direction in which the OOB message containing the Noob value is being sent (1=peer-to-server, 2=server-to-peer). This field is included in the Hoob input to prevent the user from accidentally delivering the OOB message back to its originator in the rare cases where both OOB directions have been negotiated. The keys (Kms, Kmp, Kms2, and Kmp2) for the HMACs are defined in Section 3.5.
パラメータDIRは、NOOB値を含むOOBメッセージが送信されている方向を示します（1 = Peer-To-Server、2 =サーバーからピア）。このフィールドは、両方のOOB方向がネゴシエートされたまれに、ユーザがOOBメッセージをその発信者に誤って配信するのを防ぐために、ホブ入力に含まれています。HMACのキー（KMS、KMP、KMS2、およびKMP2）はセクション3.5で定義されています。
The nonces (Ns, Np, Ns2, Np2, and Noob) and the hash value (NoobId) MUST be base64url encoded [RFC4648] when they are used as input to the cryptographic functions H or HMAC. These values and the message authentication codes (MACs, MACp, MACs2, and MACp2) MUST also be base64url encoded when they are sent as JSON strings in the in-band messages. The values Noob and Hoob in the OOB channel MAY be base64url encoded if that is appropriate for the application and the OOB channel. All base64url encoding is done without padding. The base64url-encoded values will naturally consume more space than the number of bytes specified above (e.g., a 22-character string for a 16-byte nonce and a 43-character string for a 32-byte nonce or message authentication code). In the key derivation in Section 3.5, on the other hand, the unencoded nonces (raw bytes) are used as input to the key derivation function.
ノンス（NS、NP、NS2、NP2、NOB）およびハッシュ値（NOOBID）は、暗号関数HまたはHMACへの入力として使用される場合、基本64URL符号化[RFC4648]でなければなりません。これらの値とメッセージ認証コード（MACS、MACP、MACS2、およびMACP2）は、帯域内のメッセージ内のJSON文字列として送信されたときに符号化されているBase64URLでなければなりません。OOBチャネル内のValues NOOBおよびHOOBは、アプリケーションおよびOOBチャネルに適している場合、Base64URLエンコードされている可能性があります。すべてのBase64URLエンコーディングはパディングなしで行われます。Base64URLエンコードされた値は、上で指定されたバイト数（例えば、16バイトのNonceの22文字の文字列、32バイトのNonceまたはメッセージ認証コードの場合は43文字の文字列）よりも多くのスペースを消費します。一方、セクション3.5の鍵導出では、鍵導出機能への入力として、符号化されていないノンス（生のバイト）が使用されています。
The ServerInfo and PeerInfo are JSON objects with UTF-8 encoding. The length of either encoded object as a byte array MUST NOT exceed 500 bytes. The format and semantics of these objects MUST be defined by the application that uses the EAP-NOOB method.
ServerInfoとPeerInfoは、UTF-8エンコーディングを備えたJSONオブジェクトです。1バイト配列としてのエンコードされたオブジェクトの長さは500バイトを超えてはいけません。これらのオブジェクトのフォーマットとセマンティクスは、EAP-NOOBメソッドを使用するアプリケーションによって定義する必要があります。
EAP-NOOB implements fast reconnect ([RFC3748], Section 7.2.1), which avoids repeated use of the user-assisted OOB channel.
EAP-NOOBは高速再接続（[RFC3748]、7.2.1）を実装しています。これにより、ユーザー支援OOBチャネルの使用を繰り返し使用します。
The rekeying and the Reconnect Exchange may be needed for several reasons. New EAP output values Main Session Key (MSK) and Extended Main Session Key (EMSK) may be needed because of mobility or timeout of session keys. Software or hardware failure or user action may also cause the authenticator, EAP server, or peer to lose its nonpersistent state data. The failure would typically be detected by the peer or authenticator when session keys are no longer accepted by the other endpoint. Changes in the supported cryptosuites in the EAP server or peer may also cause the need for a new key exchange. When the EAP server or peer detects any one of these events, it MUST change from the Registered (4) state to the Reconnecting (3) state. These state transitions are labeled Mobility/Timeout/Failure in Figure 1. The EAP-NOOB method will then perform the Reconnect Exchange the next time when EAP is triggered.
いくつかの理由で、生後再結合と再接続交換が必要になる場合があります。セッションキーのモビリティまたはタイムアウトのために、新しいEAP出力値メインセッションキー（MSK）と拡張メインセッションキー（EMSK）が必要になる場合があります。ソフトウェアまたはハードウェアの障害またはユーザーの処置は、オーセンティケータ、EAPサーバ、またはピアはその非永続状態データを失います。セッションキーが他のエンドポイントによって受け入れられなくなったときに、障害は通常、ピアまたはオーセンティケータによって検出されます。EAPサーバーまたはピア内のサポートされている暗号スイートの変更も、新しい鍵交換の必要性を引き起こす可能性があります。EAPサーバまたはピアがこれらのイベントのいずれかを検出すると、登録されている（4）状態から再接続（3）状態に変更する必要があります。これらの状態遷移は、図1のモビリティ/タイムアウト/障害とラベル付けされています.EAP-NOOBメソッドは、EAPがトリガーされたときの次回の再接続Exchangeを実行します。
To enable rekeying, the EAP server and peer store the session state in persistent memory after a successful Completion Exchange. This state data, called "persistent EAP-NOOB association", MUST include at least the data fields shown in Table 2. They are used for identifying and authenticating the peer in the Reconnect Exchange. When a persistent EAP-NOOB association exists, the EAP server and peer are in the Registered (4) state or Reconnecting (3) state, as shown in Figure 1.
REKKINGを有効にするには、EAPサーバーとピアは、完了した完了Exchangeの後にセッション状態を永続メモリに格納します。「永続的なEAP-NOOBアソシエーション」と呼ばれるこの状態データは、少なくとも表2に示すデータフィールドを含める必要があります。それらは、再接続交換のピアの識別と認証に使用されます。永続的なEAP-NOOB関連付けが存在する場合、図1に示すように、EAPサーバーとピアは登録済み（4）状態または再接続（3）状態にあります。
+==================+==========================+===================+
| Data Field | Value | Type |
+==================+==========================+===================+
| PeerId | Peer identifier | UTF-8 string |
| | allocated by server | (typically 22 |
| | | ASCII characters) |
+------------------+--------------------------+-------------------+
| Verp | Negotiated protocol | integer |
| | version | |
+------------------+--------------------------+-------------------+
| Cryptosuitep | Negotiated cryptosuite | integer |
+------------------+--------------------------+-------------------+
| CryptosuitepPrev | Previous cryptosuite | integer |
| (at peer only) | | |
+------------------+--------------------------+-------------------+
| NAI | NAI assigned by the | UTF-8 string |
| | server or configured by | |
| | the user or the default | |
| | NAI "noob@eap-noob.arpa" | |
+------------------+--------------------------+-------------------+
| Kz | Persistent key material | 32 bytes |
+------------------+--------------------------+-------------------+
| KzPrev (at peer | Previous Kz value | 32 bytes |
| only) | | |
+------------------+--------------------------+-------------------+
Table 2: Persistent EAP-NOOB Association
表2：永続的なEAP-NOOB協会
The server chooses the Reconnect Exchange when both the peer and the server are in a persistent state and fast reconnection is needed (see Section 3.2.1 for details).
サーバーは、ピアとサーバーの両方が永続状態にあるときに再接続交換を選択し、速い再接続が必要です（詳細はセクション3.2.1を参照）。
The Reconnect Exchange comprises the common handshake and three further EAP-NOOB request-response pairs: one for cryptosuite and parameter negotiation, another for the nonce and ECDHE key exchange, and the last one for exchanging message authentication codes. In the first request and response (Type=7), the server and peer negotiate a protocol version and cryptosuite in the same way as in the Initial Exchange. The server SHOULD NOT offer and the peer MUST NOT accept protocol versions or cryptosuites that it knows to be weaker than the one currently in the Cryptosuitep field of the persistent EAP-NOOB association. The server SHOULD NOT needlessly change the cryptosuites it offers to the same peer because peer devices may have limited ability to update their persistent storage. However, if the peer has different values in the Cryptosuitep and CryptosuitepPrev fields, it SHOULD also accept offers that are not weaker than CryptosuitepPrev. Note that Cryptosuitep and CryptosuitePrev from the persistent EAP-NOOB association are only used to support the negotiation as described above; all actual cryptographic operations use the newly negotiated cryptosuite. The request and response (Type=7) MAY additionally contain PeerInfo and ServerInfo objects.
再接続交換は、共通のハンドシェイクと3つのEAP-NOOB要求応答ペアとを含みます.1つは、暗号化され、パラメータネゴシエーション用のもの、もう1つ、もう1つ、もう1つはNonceキー交換、およびメッセージ認証コードを交換するための最後のものです。最初の要求と応答（Type = 7）では、サーバーとピアは、最初のExchangeと同じ方法でプロトコルバージョンと暗号化をネゴシエートします。サーバーは提供してはいけません。ピアは、永続的なEAP-NoobアソシエーションのCryptoSuitepフィールドにあるものよりも弱くなることを知っているプロトコルバージョンまたは暗号スイートを受け入れないでください。サーバーは、ピアデバイスがそれらの永続ストレージを更新する機能が限られている可能性があるため、それが同じピアに提供する暗号スイートを必要に変えるべきではありません。ただし、PeerがCryptoSuitepおよびCryptoSuitePprevフィールドに異なる値を持つ場合は、CryptoSuitePPREVよりも弱いオファーを受け入れる必要があります。永続的なEAP-NOOBアソシエーションからのCryptoSuitepおよびCryptoSuitePrevは、上記のようにネゴシエーションをサポートするためにのみ使用されます。実際の暗号化操作はすべて、新しく交渉された暗号化を使用します。要求と応答（type = 7）には、PeerInfoオブジェクトとServerInfoオブジェクトを追加することができます。
The server then determines the KeyingMode (defined in Section 3.5) based on changes in the negotiated cryptosuite and whether it desires to achieve forward secrecy or not. The server SHOULD only select KeyingMode 3 when the negotiated cryptosuite differs from the Cryptosuitep in the server's persistent EAP-NOOB association, although it is technically possible to select this value without changing the cryptosuite. In the second request and response (Type=8), the server informs the peer about the KeyingMode and the server and peer exchange nonces (Ns2, Np2). When KeyingMode is 2 or 3 (rekeying with ECDHE), they also exchange public components of ECDHE keys (PKs2, PKp2). The server ECDHE key MUST be fresh, i.e., not previously used with the same peer, and the peer ECDHE key SHOULD be fresh, i.e., not previously used.
次に、サーバは、ネゴシエートされた暗号化済みの変更に基づいてキーインモード（セクション3.5で定義）を決定し、それがof of.Secrecyを達成したいかどうかを判断します。Nefotated Cryptosuiteがサーバーの永続的なEAP-NOOBアソシエーションのCryptoSuitepと異なる場合にのみ、サーバーはキーイングモード3のみを選択してください。2番目の要求と応答（Type = 8）では、サーバーはキーインモードとサーバーとピア交換ノンス（NS2、NP2）についてピアに通知します。キーイングモードが2または3の場合（ECDHEとの再確認）、それらはECDHEキーの公共構成要素（PKS2、PKP2）も交換します。サーバーECDHEキーは、新しいピアと同じピアで使用されていない、すなわち新しいピアで使用されていない、すなわちピアECDHEキーは新鮮で使用されるべきである必要があります。
In the third and final request and response (Type=9), the server and peer exchange message authentication codes. Both sides MUST compute the keys Kms2 and Kmp2, as defined in Section 3.5, and the message authentication codes MACs2 and MACp2, as defined in Section 3.3.2. Both sides MUST compare the received message authentication code with a locally computed value.
3番目の要求および応答（Type = 9）では、サーバーとピア交換メッセージ認証コード。両側は、セクション3.5で定義されているキーKMS2およびKMP2を計算し、セクション3.3.2で定義されているように、MACS2およびMACP2を計算する必要があります。両側は受信したメッセージ認証コードをローカルに計算された値と比較する必要があります。
The rules by which the peer compares the received MACs2 are nontrivial because, in addition to authenticating the current exchange, MACs2 may confirm the success or failure of a recent cryptosuite upgrade. The peer processes the final request (Type=9) as follows:
現在のExchangeを認証することに加えて、MACS2が最近の暗号化アップグレードの成功または失敗を確認することができるため、ピアが受信したMACS2を比較する規則は非論理的です。ピアは次のように最終要求（TYPE = 9）を処理します。
1. The peer first compares the received MACs2 value with one it computed using the Kz stored in the persistent EAP-NOOB association. If the received and computed values match, the peer deletes any data stored in the CryptosuitepPrev and KzPrev fields of the persistent EAP-NOOB association. It does this because the received MACs2 confirms that the peer and server share the same Cryptosuitep and Kz, and any previous values must no longer be accepted.
1. ピアは最初に受信したMACS2の値を、永続的なEAP-NOOBアソシエーションに格納されているKZを使用して計算された1つを比較します。受信した値と計算値が一致すると、ピアは永続的なEAP-NOOBアソシエーションのCryptoSuitepprevおよびkzprevフィールドに格納されているデータを削除します。受信したMACS2は、ピアとサーバーが同じCryptoSuitepとKZを共有し、以前の値を受け入れなくてもらわなければなりません。
2. On the other hand, if the peer finds that the received MACs2 value does not match the one it computed locally with Kz, the peer checks whether the KzPrev field in the persistent EAP-NOOB association stores a key. If it does, the peer repeats the key derivation (Section 3.5) and local MACs2 computation (Section 3.3.2) using KzPrev in place of Kz. If this second computed MACs2 matches the received value, the match indicates synchronization failure caused by the loss of the last response (Type=9) in a previously attempted cryptosuite upgrade. In this case, the peer rolls back that upgrade by overwriting Cryptosuitep with CryptosuitepPrev and Kz with KzPrev in the persistent EAP-NOOB association. It also clears the CryptosuitepPrev and KzPrev fields.
2. 一方、ピアが受信したMACS2の値がKZでローカルに計算されたものと一致しないと判断した場合、ピアは、永続的なEAP-NOOBアソシエーションのKZPREVフィールドがキーを格納するかどうかを確認します。そうであれば、kzの代わりにkzprevを使用して、ピアはキー導出（セクション3.5）およびローカルMACS2計算（セクション3.3.2）を繰り返します。この2番目の計算されたMACS2が受信値と一致する場合、一致は前回のResponseの損失によって引き起こされる同期失敗を示します（TYPE = 9）。この場合、ピアは、CryptoSuitpprevおよびKZをkzprevで永続的なEAP-Noobアソシエーションでkzprevで上書きすることで、アップグレードをロールバックします。また、CryptoSuitePprevおよびkzprevフィールドもクリアされます。
3. If the received MACs2 matched one of the locally computed values, the peer proceeds to send the final response (Type=9). The peer also moves to the Registered (4) state. When KeyingMode is 1 or 2, the peer stops here. When KeyingMode is 3, the peer also updates the persistent EAP-NOOB association with the negotiated Cryptosuitep and the newly derived Kz value. To prepare for possible synchronization failure caused by the loss of the final response (Type=9) during cryptosuite upgrade, the peer copies the old Cryptosuitep and Kz values in the persistent EAP-NOOB association to the CryptosuitepPrev and KzPrev fields.
3. 受信したMACS2がローカルに計算された値の1つと一致した場合、ピアは最終応答を送信します（TYPE = 9）。ピアは登録済み（4）状態に移動します。キーイングモードが1または2のとき、ピアはここで停止します。キーイングモードが3の場合、ピアはネゴシエートされた暗号化UPと新しく派生したKZ値を持つ永続的なEAP-NOOBアソシエーションを更新します。CryptoSuiteのアップグレード中に最終的な応答の損失（TYPE = 9）によって引き起こされる可能な同期失敗のために準備するために、ピアは古い暗号化UPEPとKZ値を永続的なEAP-NOOB関連付けにCryptoSuitPrevおよびKZPREVフィールドにコピーします。
4. Finally, if the peer finds that the received MACs2 does not match either of the two values that it computed locally (or one value if no KzPrev was stored), the peer sends an error message (error code 4001, see Section 3.6.5), which causes the Reconnect Exchange to end in EAP-Failure.
4. 最後に、受信したMACS2がローカルに計算された2つの値のいずれか（またはkzprevが格納されていない場合）のいずれかの2つの値のいずれかと一致しない場合、ピアはエラーメッセージを送信します（エラーコード4001、セクション3.6.5を参照）。これにより、再接続交換がEAP障害で終了します。
The server rules for processing the final message are simpler than the peer rules because the server does not store previous keys and it never rolls back a cryptosuite upgrade. Upon receiving the final response (Type=9), the server compares the received value of MACp2 with one it computes locally. If the values match, the Reconnect Exchange ends in EAP-Success. When KeyingMode is 3, the server also updates Cryptosuitep and Kz in the persistent EAP-NOOB association. On the other hand, if the server finds that the values do not match, it sends an error message (error code 4001), and the Reconnect Exchange ends in EAP-Failure.
サーバーが以前のキーを保存しないため、最後のメッセージを処理するためのサーバーのルールはピアルールよりも簡単です。最終的な応答（Type = 9）を受信すると、サーバはMACP2の受信値とローカルに計算されているものと比較されます。値が一致すると、再接続交換はEAP成功で終了します。キーインモードが3のとき、サーバーは永続的なEAP-NOOBアソシエーションでCryptoSuitepとKZも更新します。一方、サーバが値が一致しないことを検索した場合は、エラーメッセージ（エラーコード4001）を送信し、再接続交換はEAP障害で終了します。
The endpoints MAY send updated NewNAI, ServerInfo, and PeerInfo objects in the Reconnect Exchange. When there is no update to the values, they SHOULD omit this information from the messages. If the NewNAI was sent, each side updates NAI in the persistent EAP-NOOB association when moving to the Registered (4) state.
エンドポイントは、Reconnect Exchangeに更新されたNewnai、ServerInfo、およびPeerInfoオブジェクトを送信することができます。値に更新がない場合は、メッセージからこの情報を省略してください。Newnaiが送信された場合、登録されている（4）状態に移動するときに、永続的なEAP-NoobアソシエーションのNAIを更新します。
EAP Peer EAP Server
| ...continuing from common handshake |
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=7,Vers,PeerId,Cryptosuites, |
| [NewNAI],[ServerInfo]) |
| |
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=7,Verp,PeerId,Cryptosuitep,[PeerInfo])|
| |
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=8,PeerId,KeyingMode,[PKs2],Ns2) |
| |
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=8,PeerId,[PKp2],Np2) |
| |
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=9,PeerId,MACs2) |
| |
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=9,PeerId,MACp2) |
| |
| |
|<----------- EAP-Success -------------------------|
| |
Figure 8: Reconnect Exchange
図8：Exchangeの再接続
As shown in the association state machine in Figure 1, the only specified way for the association to return from the Registered (4) state to the Unregistered (0) state is through user-initiated reset. After the reset, a new OOB message will be needed to establish a new association between the EAP server and peer. Typical situations in which the user reset is required are when the other side has accidentally lost the persistent EAP-NOOB association data or when the peer device is decommissioned.
図1の関連状態マシンに示すように、登録された（4）状態から未登録（0）状態に戻るための唯一の指定された方法は、ユーザ起動リセットを介して行われます。リセット後、EAPサーバーとピア間の新しい関連付けを確立するために新しいOOBメッセージが必要になります。ユーザリセットが必要な典型的な状況は、誤って永続的なEAP-NOOB関連データを失ったとき、またはピア装置が廃止されているときです。
The server could detect that the peer is in the Registered or Reconnecting state, but the server itself is in one of the ephemeral states 0..2 (including situations where the server does not recognize the PeerId). In this case, effort should be made to recover the persistent server state, for example, from a backup storage -- especially if many peer devices are similarly affected. If that is not possible, the EAP server SHOULD log the error or notify an administrator. The only way to continue from such a situation is by having the user reset the peer device.
サーバーは、ピアが登録状態または再接続状態にあることを検出できますが、サーバー自体は0..2（サーバーがピアツを認識していない状況を含む）のいずれかのエフェメラサートのいずれかにあります。この場合、例えばバックアップストレージから永続サーバ状態を回復するための努力を行うべきである - 特に多くのピア装置が同様に影響を受ける場合には。それが不可能な場合、EAPサーバーはエラーを記録するか、管理者に通知する必要があります。そのような状況から継続する唯一の方法は、ユーザーがピア装置をリセットさせることです。
On the other hand, if the peer is in any of the ephemeral states 0..2, including the Unregistered state, the server will treat the peer as a new peer device and allocate a new PeerId to it. The PeerInfo can be used by the user as a clue to which physical device has lost its state. However, there is no secure way of matching the "new" peer with the old PeerId without repeating the OOB Step. This situation will be resolved when the user performs the OOB Step and thus identifies the physical peer device. The server user interface MAY support situations where the "new" peer is actually a previously registered peer that has been reset by a user or otherwise lost its persistent data. In those cases, the user could choose to merge the new peer identity with the old one in the server. The alternative is to treat the device just like a new peer.
一方、登録解除状態を含めてピアが0..2のいずれかにある場合、サーバはピアを新しいピアデバイスとして扱い、新しいピアドを割り当てます。PeerInfoは、物理デバイスがその状態を失った手がかりとしてユーザーが使用できます。ただし、OOBステップを繰り返すことなく、「新規」ピアと古いピアドと一致する安全な方法はありません。この状況は、ユーザがOOBステップを実行し、したがって物理ピア装置を識別すると解決されます。サーバユーザインタフェースは、「新規」ピアが実際には、ユーザによってリセットされた、またはその他の方法で永続データを失ったような事前に登録されたピアである状況をサポートすることができる。そのような場合、ユーザーは新しいピアアイデンティティをサーバー内の古いものとマージすることを選択できます。代替案は、新しいピアのように装置を扱うことです。
EAP-NOOB derives the EAP output values MSK and EMSK and other secret keying material from the output of an Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) algorithm following the NIST specification [NIST-DH]. In NIST terminology, we use a C(2e, 0s, ECC CDH) scheme, i.e., two ephemeral keys and no static keys. In the Initial Exchange and Reconnect Exchange, the server and peer compute the ECDHE shared secret Z, as defined in Section 6.1.2 of the NIST specification [NIST-DH]. In the Completion Exchange and Reconnect Exchange, the server and peer compute the secret keying material from Z with the one-step key derivation function (KDF) defined in Section 5.8.2.1 of the NIST specification. The auxiliary function H is a hash function, and it is taken from the negotiated cryptosuite.
EAP-NOOBは、NIST仕様[NIST-DH]に続く、EAP出力値MSKおよびEMSKおよびその他の秘密キーイング材料を導出します[NIST-DH]。NIST用語では、C（2E、0S、ECC CDH）方式、すなわち2つの一時キーとスタティックキーを使用しています。最初のExchangeとReconnect Exchangeでは、ServerとPeerは、NIST仕様[NIST-DH]のセクション6.1.2で定義されているECDHE共有Secret Zを計算します。完了ExchangeとReconsect Exchangeでは、サーバーとピアは、NIST仕様のセクション5.8.2.1で定義されているワンステップキー派生機能（KDF）を使用して、Zから秘密のキーワード資料をZから計算します。補助関数hはハッシュ関数であり、交渉された暗号石から取られている。
+============+============================================+
| KeyingMode | Description |
+============+============================================+
| 0 | Completion Exchange (always with ECDHE) |
+------------+--------------------------------------------+
| 1 | Reconnect Exchange, rekeying without ECDHE |
+------------+--------------------------------------------+
| 2 | Reconnect Exchange, rekeying with ECHDE, |
| | no change in cryptosuite |
+------------+--------------------------------------------+
| 3 | Reconnect Exchange, rekeying with ECDHE, |
| | new cryptosuite negotiated |
+------------+--------------------------------------------+
Table 3: Keying Modes
表3：キーイングモード
The key derivation has four different modes (KeyingMode), which are specified in Table 3. Table 4 defines the inputs to KDF in each KeyingMode.
鍵導出には、表3に指定されている4つの異なるモード（キーイングモード）があります。表4は、各キーインモードのKDFへの入力を定義します。
In the Completion Exchange (KeyingMode=0), the input Z comes from the preceding Initial exchange. The KDF takes some additional inputs (FixedInfo), for which we use the concatenation format defined in Section 5.8.2.1.1 of the NIST specification [NIST-DH]. FixedInfo consists of the AlgorithmId, PartyUInfo, PartyVInfo, and SuppPrivInfo fields. The first three fields are fixed-length bit strings, and SuppPrivInfo is a variable-length string with a one-byte Datalength counter. AlgorithmId is the fixed-length, 8-byte ASCII string "EAP-NOOB". The other input values are the server and peer nonces. In the Completion Exchange, the inputs also include the secret nonce Noob from the OOB message.
完了Exchange（KeyingMode = 0）では、入力Zは前の最初の交換から来ています。KDFは追加の入力（FixedInfo）を取り、NIST仕様[NIST-DH]のセクション5.8.2.1.1で定義されている連結フォーマットを使用します。FixedInfoは、AlgorithmID、PartyUINFO、PartyVInfo、およびSuppRivInfoフィールドで構成されています。最初の3つのフィールドは固定長ビット文字列で、SuppPrivinfoは1バイトのDataLengthカウンタを持つ可変長ストリングです。algorithmIDは、固定長、8バイトのASCII文字列 "EAP-NOOB"です。他の入力値はサーバーとピアノンスです。完了した交換では、入力にはOOBメッセージからの秘密のNONOBも含まれます。
In the simplest form of the Reconnect Exchange (KeyingMode=1), fresh nonces are exchanged, but no ECDHE keys are sent. In this case, input Z to the KDF is replaced with the shared key Kz from the persistent EAP-NOOB association. The result is rekeying without the computational cost of the ECDHE exchange but also without forward secrecy.
再接続交換の最も単純な形式（KeyingMode = 1）では、新鮮なノンスが交換されますが、ECDHEキーは送信されません。この場合、KDFへの入力Zは、永続的なEAP-NOOBアソシエーションから共有キーKZに置き換えられます。その結果、ECDHE交換の計算コストなしではなく、秘密の秘密のないものがなくなります。
When forward secrecy is desired in the Reconnect Exchange (KeyingMode=2 or KeyingMode=3), both nonces and ECDHE keys are exchanged. Input Z is the fresh shared secret from the ECDHE exchange with PKs2 and PKp2. The inputs also include the shared secret Kz from the persistent EAP-NOOB association. This binds the rekeying output to the previously authenticated keys.
再接続Exchange（キーイングモード= 2またはキーイングモード= 3）で順方向秘密が望まれる場合、NonceキーとECDHEキーの両方が交換されます。入力Zは、PKS2とPKP2とのECDHE交換からの新鮮な共有秘密です。入力には、永続的なEAP-NOOB協会からの共有秘密kzも含まれています。これにより、Reking出力が以前に認証されたキーにバインドされます。
+=========================+==============+===============+==========+
| KeyingMode | KDF input | Value | Length |
| | field | | (bytes) |
+=========================+==============+===============+==========+
| 0 Completion | Z | ECDHE shared | variable |
| | | secret from | |
| | | PKs and PKp | |
| +--------------+---------------+----------+
| | AlgorithmId | "EAP-NOOB" | 8 |
| +--------------+---------------+----------+
| | PartyUInfo | Np | 32 |
| +--------------+---------------+----------+
| | PartyVInfo | Ns | 32 |
| +--------------+---------------+----------+
| | SuppPubInfo | (not | |
| | | allowed) | |
| +--------------+---------------+----------+
| | SuppPrivInfo | Noob | 16 |
+-------------------------+--------------+---------------+----------+
| 1 Reconnect, rekeying | Z | Kz | 32 |
| without ECDHE +--------------+---------------+----------+
| | AlgorithmId | "EAP-NOOB" | 8 |
| +--------------+---------------+----------+
| | PartyUInfo | Np2 | 32 |
| +--------------+---------------+----------+
| | PartyVInfo | Ns2 | 32 |
| +--------------+---------------+----------+
| | SuppPubInfo | (not | |
| | | allowed) | |
| +--------------+---------------+----------+
| | SuppPrivInfo | (null) | 0 |
+-------------------------+--------------+---------------+----------+
| 2 or 3 Reconnect, | Z | ECDHE shared | variable |
| rekeying, with ECDHE, | | secret from | |
| same or new cryptosuite | | PKs2 and | |
| | | PKp2 | |
| +--------------+---------------+----------+
| | AlgorithmId | "EAP-NOOB" | 8 |
| +--------------+---------------+----------+
| | PartyUInfo | Np2 | 32 |
| +--------------+---------------+----------+
| | PartyVInfo | Ns2 | 32 |
| +--------------+---------------+----------+
| | SuppPubInfo | (not | |
| | | allowed) | |
| +--------------+---------------+----------+
| | SuppPrivInfo | Kz | 32 |
+-------------------------+--------------+---------------+----------+
Table 4: Key Derivation Input
表4：キー導出入力
Table 5 defines how the output bytes of the KDF are used. In addition to the EAP output values MSK and EMSK, the server and peer derive another shared secret key AMSK (Application Main Session Key), which MAY be used for application-layer security. Further output bytes are used internally by EAP-NOOB for the message authentication keys (Kms, Kmp, Kms2, and Kmp2).
表5は、KDFの出力バイトをどのように使用するかを定義します。EAP出力値MSKおよびEMSKに加えて、サーバーとピアは別の共有秘密鍵AMSK（アプリケーションメインセッションキー）を導出します。これは、アプリケーションレイヤセキュリティに使用できます。さらに出力バイトは、メッセージ認証キー（KMS、KMP、KMS2、およびKMP2）のEAP-NOOBによって内部的に使用されます。
The Completion Exchange (KeyingMode=0) produces the shared secret Kz, which the server and peer store in the persistent EAP-NOOB association. When a new cryptosuite is negotiated in the Reconnect Exchange (KeyingMode=3), it similarly produces a new Kz. In that case, the server and peer update both the cryptosuite and Kz in the persistent EAP-NOOB association. Additionally, the peer stores the previous Cryptosuitep and Kz values in the CryptosuitepPrev and KzPrev fields of the persistent EAP-NOOB association.
完了Exchange（KeyingMode = 0）は、サーバーとピアストアが永続的なEAP-NOOBアソシエーションに保管されている共有シークレットKZを作成します。再接続Exchange（KeyingMode = 3）で新しい暗号化されたクリプトスイートがネゴシエートされると、同様に新しいKZが生成されます。その場合、サーバーとピアは、永続的なEAP-NOOBアソシエーションでCryptoSuiteとKZの両方を更新します。さらに、ピアは、永続的なEAP-NOOBアソシエーションのCryptoSuitepprevおよびkzprevフィールドに、以前の暗号化UPとKZ値を格納します。
+==============================+============+==========+=========+
| KeyingMode | KDF output | Used as | Length |
| | bytes | | (bytes) |
+==============================+============+==========+=========+
| 0 Completion | 0..63 | MSK | 64 |
| +------------+----------+---------+
| | 64..127 | EMSK | 64 |
| +------------+----------+---------+
| | 128..191 | AMSK | 64 |
| +------------+----------+---------+
| | 192..223 | MethodId | 32 |
| +------------+----------+---------+
| | 224..255 | Kms | 32 |
| +------------+----------+---------+
| | 256..287 | Kmp | 32 |
| +------------+----------+---------+
| | 288..319 | Kz | 32 |
+------------------------------+------------+----------+---------+
| 1 or 2 Reconnect, rekeying | 0..63 | MSK | 64 |
| without ECDHE, or with ECDHE +------------+----------+---------+
| and unchanged cryptosuite | 64..127 | EMSK | 64 |
| +------------+----------+---------+
| | 128..191 | AMSK | 64 |
| +------------+----------+---------+
| | 192..223 | MethodId | 32 |
| +------------+----------+---------+
| | 224..255 | Kms2 | 32 |
| +------------+----------+---------+
| | 256..287 | Kmp2 | 32 |
+------------------------------+------------+----------+---------+
| 3 Reconnect, rekeying with | 0..63 | MSK | 64 |
| ECDHE, new cryptosuite +------------+----------+---------+
| | 64..127 | EMSK | 64 |
| +------------+----------+---------+
| | 128..191 | AMSK | 64 |
| +------------+----------+---------+
| | 192..223 | MethodId | 32 |
| +------------+----------+---------+
| | 224..255 | Kms2 | 32 |
| +------------+----------+---------+
| | 256..287 | Kmp2 | 32 |
| +------------+----------+---------+
| | 288..319 | Kz | 32 |
+------------------------------+------------+----------+---------+
Table 5: Key Derivation Output
表5：キー導出出力
Finally, every EAP method must export a Server-Id, Peer-Id, and Session-Id [RFC5247]. In EAP-NOOB, the exported Peer-Id is the PeerId that the server has assigned to the peer. The exported Server-Id is a zero-length string (i.e., null string) because EAP-NOOB neither knows nor assigns any server identifier. The exported Session-Id is created by concatenating the one-byte Type-Code 0x38 (decimal value 56) with the MethodId, which is obtained from the KDF output, as shown in Table 5.
最後に、すべてのEAPメソッドは、サーバーID、Peer-ID、およびSession-ID [RFC5247]をエクスポートする必要があります。EAP-NOOBでは、エクスポートされたPeer-IDは、サーバーがピアに割り当てられたPeeridです。エクスポートされたサーバーIDは、EAP-NOOBがどのサーバー識別子も認識されたり割り当てたりしないため、長さゼロの文字列（すなわち、NULL文字列）です。エクスポートされたセッションIDは、表5に示すように、KDF出力から取得されているMethodIDを使用して、1バイトのタイプコード0x38（10進数56）を連結することによって作成されます。
Various error conditions in EAP-NOOB are handled by sending an error notification message (Type=0) instead of a next EAP request or response message. Both the EAP server and the peer may send the error notification, as shown in Figures 9 and 10. After sending or receiving an error notification, the server MUST send an EAP-Failure (as required by [RFC3748], Section 4.2). The notification MAY contain an ErrorInfo field, which is a UTF-8-encoded text string with a maximum length of 500 bytes. It is used for sending descriptive information about the error for logging and debugging purposes.
EAP-Noobのさまざまなエラー状態は、次のEAP要求または応答メッセージの代わりにエラー通知メッセージ（TYPE = 0）を送信することによって処理されます。EAPサーバとピアの両方がエラー通知を送信することができます。通知には、最大長さ500バイトのUTF-8エンコードされたテキスト文字列であるErrorInfoフィールドが含まれている可能性があります。ロギングやデバッグの目的でエラーに関する説明情報を送信するために使用されます。
EAP Peer EAP Server
... ...
| |
|<----------- EAP-Request/EAP-NOOB ----------------|
| (Type=0,[PeerId],ErrorCode,[ErrorInfo]) |
| |
| |
|<----------- EAP-Failure -------------------------|
| |
Figure 9: Error Notification from Server to Peer
図9：サーバーからピアへのエラー通知
EAP Peer EAP Server
... ...
| |
|------------ EAP-Response/EAP-NOOB -------------->|
| (Type=0,[PeerId],ErrorCode,[ErrorInfo]) |
| |
| |
|<----------- EAP-Failure -------------------------|
| |
Figure 10: Error Notification from Peer to Server
図10：ピアからサーバーへのエラー通知
After the exchange fails due to an error notification, the server and peer set the association state as follows. In the Initial Exchange, both the sender and recipient of the error notification MUST set the association state to the Unregistered (0) state. In the Waiting Exchange and Completion Exchange, each side MUST remain in its old state as if the failed exchange had not taken place, with the exception that the recipient of error code 2003 processes it as specified in Section 3.2.4. In the Reconnect Exchange, both sides MUST set the association state to the Reconnecting (3) state.
エラー通知によりExchangeが失敗した後、サーバーとピアは次のように関連状態を設定します。最初の交換では、エラー通知の送信者と受信者の両方が、アソシエーション状態を未登録（0）状態に設定する必要があります。待機交換と完了Exchangeでは、エラーコード2003の受信者がセクション3.2.4で指定されているように処理されたことを除いて、障害のないExchangeが行われていないかのように、各辺が古い状態に留まる必要があります。再接続交換では、両面は関連状態を再接続状態（3）状態に設定する必要があります。
Errors that occur in the OOB channel are not explicitly notified in-band.
OOBチャネルで発生するエラーは、帯域内で明示的に通知されません。
If the NAI structure is invalid, the server SHOULD send the error code 1001 to the peer. The recipient of an EAP-NOOB request or response SHOULD send the following error codes back to the sender: 1002 if it cannot parse the message as a JSON object or the top-level JSON object has missing or unrecognized members; 1003 if a data field has an invalid value, such as an integer out of range, and there is no more specific error code available; 1004 if the received message type was unexpected in the current state; 2004 if the PeerId has an unexpected value; 2003 if the NoobId is not recognized; and 1005 if the ECDHE key is invalid.
NAI構造が無効な場合、サーバーはエラーコード1001をピアに送信する必要があります。EAP-NOOB要求または応答の受信者は、JSONオブジェクトとしてメッセージを解析できない場合、または最上位のJSONオブジェクトが欠落しているか、認識されていないメンバーが欠落していない場合は、次のエラーコードを送信者に送信する必要があります。1003データフィールドに範囲外の整数などの無効な値がある場合、および利用可能な具体的なエラーコードはそれほどありません。1004受信したメッセージタイプが現在の状態で予期しない場合。PeerIDが予期せぬ値を持つ場合2004。2003年NOOBIDが認識されていない場合。ECDHEキーが無効な場合は1005です。
The preferred way for the EAP server to rate limit EAP-NOOB connections from a peer is to use the SleepTime parameter in the Waiting Exchange. However, if the EAP server receives repeated EAP-NOOB connections from a peer that apparently should not connect to this server, the server MAY indicate that the connections are unwanted by sending the error code 2001. After receiving this error message, the peer MAY refrain from reconnecting to the same EAP server, and, if possible, both the EAP server and peer SHOULD indicate this error condition to the user or server administrator. However, in order to avoid persistent denial of service, peer devices that are unable to alert a user SHOULD continue to try to reconnect infrequently (e.g., approximately every 3600 seconds).
EAPサーバがピアからの制限EAP-NOOB接続を評価するための推奨される方法は、待機交換内のSleeptimeパラメータを使用することです。ただし、EAPサーバーがこのサーバーに接続してはならないピアからEAP-NOOB接続を繰り返し受信した場合、サーバーはエラーコード2001を送信することによって接続が不要であることを示している可能性があります。このエラーメッセージを受信した後、ピアは控えてください。同じEAPサーバーへの再接続から、可能であれば、EAPサーバーとピアの両方がこのエラー状態をユーザーまたはサーバー管理者に示す必要があります。ただし、永続的なサービス拒否を回避するために、ユーザーに警告できないピアデバイスは、（例えば、約3600秒ごとに）頻度に頻繁に再接続しようとしているはずです。
In the states indicated by "-" in Table 14 in Appendix A, user action is required to reset the association state or to recover it, for example, from backup storage. In those cases, the server sends the error code 2002 to the peer. If possible, both the EAP server and peer SHOULD indicate this error condition to the user or server administrator.
付録Aの表14の「 - 」で示される状態では、例えばバックアップストレージから、関連付け状態をリセットするか、またはそれを回復するためにユーザアクションが必要である。そのような場合、サーバーはエラーコード2002をピアに送信します。可能であれば、EAPサーバーとピアの両方がこのエラー状態をユーザーまたはサーバー管理者に示す必要があります。
If there is no matching protocol version, the peer sends the error code 3001 to the server. If there is no matching cryptosuite, the peer sends the error code 3002 to the server. If there is no matching OOB direction, the peer sends the error code 3003 to the server.
一致するプロトコルバージョンがない場合、ピアはエラーコード3001をサーバーに送信します。一致する暗号化がない場合、ピアはエラーコード3002をサーバーに送信します。一致するOOB方向がない場合、ピアはエラーコード3003をサーバに送信する。
In practice, there is no way of recovering from these errors without software or hardware changes. If possible, both the EAP server and peer SHOULD indicate these error conditions to the user.
実際には、ソフトウェアやハードウェアの変更なしでこれらのエラーから回復する方法はありません。可能であれば、EAPサーバーとピアの両方がこれらのエラー状態をユーザーに示す必要があります。
If the receiver of the OOB message detects an unrecognized PeerId or incorrect fingerprint (Hoob) in the OOB message, the receiver MUST remain in the Waiting for OOB (1) state as if no OOB message was received. The receiver SHOULD indicate the failure to accept the OOB message to the user. No in-band error message is sent.
OOBメッセージの受信者が認識されていないPeeridまたは誤った指紋（Hoob）を検出した場合、受信者はOOBメッセージが受信されていないかのようにOOB（1）の状態を待っている必要があります。受信者は、OOBメッセージをユーザに受け入れる障害を示すべきです。インバンドエラーメッセージは送信されません。
Note that if the OOB message was delivered from the server to the peer and the peer does not recognize the PeerId, the likely cause is that the user has unintentionally delivered the OOB message to the wrong peer device. If possible, the peer SHOULD indicate this to the user; however, the peer device may not have the capability for many different error indications to the user, and it MAY use the same indication as in the case of an incorrect fingerprint.
OOBメッセージがサーバーからピアに配信され、ピアがPeerIDを認識しない場合、原因はユーザーが意図せずにOOBメッセージを間違ったピアデバイスに配信していることです。可能であれば、ピアはこれをユーザーに示す必要があります。しかしながら、ピア装置は、ユーザにさまざまなエラー表示の機能を持たない可能性があり、誤った指紋の場合と同じ表示を使用することができます。
The rationale for the above is that the invalid OOB message could have been presented to the receiver by mistake or intentionally by a malicious party; thus, it should be ignored in the hope that the honest user will soon deliver a correct OOB message.
上記の理論的根拠は、無効なOOBメッセージが悪意のあるパーティーによって誤ってまたは意図的に受信者に提示された可能性があることです。したがって、正直なユーザーがすぐに正しいOOBメッセージを配信することを願って無視されるべきです。
If the EAP server or peer detects an incorrect message authentication code (MACs, MACp, MACs2, or MACp2), it sends the error code 4001 to the other side. As specified in the beginning of Section 3.6, the failed Completion Exchange will not result in server or peer state changes, while an error in the Reconnect Exchange will put both sides to the Reconnecting (3) state and thus lead to another reconnect attempt.
EAPサーバーまたはピアが誤ったメッセージ認証コード（MACS、MACP、MACS2、またはMACP2）を検出すると、エラーコード4001を反対側に送信します。セクション3.6の冒頭で指定されているように、失敗した完了Exchangeはサーバーまたはピア状態の変更をもたらさず、再接続交換のエラーは両側を再接続（3）状態にし、したがって別の再接続の試みにつながります。
The rationale for this is that the invalid cryptographic message may have been spoofed by a malicious party; thus, it should be ignored. In particular, a spoofed message on the in-band channel should not force the honest user to perform the OOB Step again. In practice, however, the error may be caused by other failures, such as a software bug. For this reason, the EAP server MAY limit the rate of peer connections with SleepTime after the above error. Also, there SHOULD be a way for the user to reset the peer to the Unregistered (0) state so that the OOB Step can be repeated as the last resort.
この理論的根拠は、無効な暗号メッセージが悪意のあるパーティーによって偽装された可能性があることです。したがって、それは無視されるべきです。特に、インバンドチャネル上の偽装されたメッセージは、正直なユーザにOOBステップを再び実行することを強制しないでください。しかし実際には、ソフトウェアのバグなどの他の障害によってもエラーが発生する可能性があります。このため、EAPサーバは、上記のエラー後のSleeptimeとのピア接続のレートを制限することがあります。また、OOBステップを最後のリゾートとして繰り返すことができるように、ユーザが登録済み（0）状態にピアをリセットする方法があるべきである。
Applications MAY define new error messages for failures that are specific to the application or to one type of OOB channel. They MAY also use the generic application-specific error code 5001 or the error codes 5002 and 5004, which have been reserved for indicating invalid data in the ServerInfo and PeerInfo fields, respectively. Additionally, anticipating OOB channels that make use of a URL, the error code 5003 has been reserved for indicating an invalid server URL.
アプリケーションは、アプリケーションに固有の障害または1種類のOOBチャネルに新しいエラーメッセージを定義できます。それらはまた、それぞれServerInfoフィールドおよびPeerInfoフィールド内の無効なデータを示すために予約されている汎用アプリケーション固有のエラーコード5001またはエラーコード5002および5004を使用することもできる。さらに、URLを利用するOOBチャネルを予測すると、エラーコード5003は無効なサーバURLを示すために予約されている。
The ServerInfo and PeerInfo fields in the Initial Exchange and Reconnect Exchange enable the server and peer, respectively, to send information about themselves to the other endpoint. They contain JSON objects whose structure may be specified separately for each application and each type of OOB channel. ServerInfo and PeerInfo MAY contain auxiliary data needed for the OOB channel messaging and for EAP channel binding (see Section 6.7). This section describes the optional initial data fields for ServerInfo and PeerInfo registered by this specification. Further specifications may request new application-specific ServerInfo and PeerInfo data fields from IANA (see Sections 5.4 and 5.5).
最初のExchangeとReconnect ExchangeのServerInfoおよびPeerInfoフィールドで、それぞれサーバーとピアを有効にして、自分自身に関する情報を他のエンドポイントに送信します。これらは、アプリケーションごとに別々に指定されているJSONオブジェクトと、各タイプのOOBチャネルを含みます。ServerInfoおよびPeerInfoには、OOBチャネルメッセージングおよびEAP Channel Bindingに必要な補助データが含まれている場合があります（セクション6.7を参照）。このセクションでは、この仕様によって登録されているServerInfoとPeerInfoのオプションの初期データフィールドについて説明します。さらなる仕様は、IANAから新しいアプリケーション固有のServerInfoおよびPeerInfoデータ項目を要求することができます（セクション5.4および5.5を参照）。
+================+=================================================+
| Data Field | Description |
+================+=================================================+
| Type | Type-tag string that can be used by the peer as |
| | a hint for how to interpret the ServerInfo |
| | contents. |
+----------------+-------------------------------------------------+
| ServerName | String that may be used to aid human |
| | identification of the server. |
+----------------+-------------------------------------------------+
| ServerURL | Prefix string when the OOB message is formatted |
| | as a URL, as suggested in Appendix D. |
+----------------+-------------------------------------------------+
| SSIDList | List of IEEE 802.11 wireless network service |
| | set identifier (SSID) strings used for roaming |
| | support, as suggested in Appendix C. JSON |
| | array of ASCII-encoded SSID strings. |
+----------------+-------------------------------------------------+
| Base64SSIDList | List of IEEE 802.11 wireless network identifier |
| | (SSID) strings used for roaming support, as |
| | suggested in Appendix C. JSON array of SSIDs, |
| | each of which is base64url-encoded without |
| | padding. Peers SHOULD send at most one of the |
| | fields SSIDList and Base64SSIDList in PeerInfo, |
| | and the server SHOULD ignore SSIDList if |
| | Base64SSIDList is included. |
+----------------+-------------------------------------------------+
Table 6: ServerInfo Data Fields
表6：ServerInfoデータ・フィールド
+==============+===================================================+
| Data Field | Description |
+==============+===================================================+
| Type | Type-tag string that can be used by the server as |
| | a hint for how to interpret the PeerInfo |
| | contents. |
+--------------+---------------------------------------------------+
| PeerName | String that may be used to aid human |
| | identification of the peer. |
+--------------+---------------------------------------------------+
| Manufacturer | Manufacturer or brand string. |
+--------------+---------------------------------------------------+
| Model | Manufacturer-specified model string. |
+--------------+---------------------------------------------------+
| SerialNumber | Manufacturer-assigned serial number. |
+--------------+---------------------------------------------------+
| MACAddress | Peer link-layer 48-bit extended unique identifier |
| | (EUI-48) in the 12-digit base-16 form [EUI-48]. |
| | The string MAY be in upper or lower case and MAY |
| | include additional colon ':' or dash '-' |
| | characters that MUST be ignored by the server. |
+--------------+---------------------------------------------------+
| SSID | IEEE 802.11 network SSID for channel binding. |
| | The SSID is an ASCII string. |
+--------------+---------------------------------------------------+
| Base64SSID | IEEE 802.11 network SSID for channel binding. |
| | The SSID is base64url encoded. Peer SHOULD send |
| | at most one of the fields SSID and Base64SSID in |
| | PeerInfo, and the server SHOULD ignore SSID if |
| | Base64SSID is included. |
+--------------+---------------------------------------------------+
| BSSID | Wireless network basic service set identifier |
| | (BSSID) (EUI-48) in the 12-digit base-16 form |
| | [EUI-48] for channel binding. The string MAY be |
| | in upper or lower case and MAY include additional |
| | colon ':' or dash '-' characters that MUST be |
| | ignored by the server. |
+--------------+---------------------------------------------------+
Table 7: PeerInfo Data Fields
表7：PeerInfoデータフィールド
This section provides information regarding registration of values related to the EAP-NOOB method, in accordance with [RFC8126].
このセクションでは、[RFC8126]に従って、EAP-NOOBメソッドに関連する値の登録に関する情報を提供します。
The EAP Method Type for EAP-NOOB (value 56) has been assigned in the "Method Types" subregistry of the "Extensible Authentication Protocol (EAP) Registry".
EAP-NOOBのEAPメソッドタイプ（値56）は、「拡張認証プロトコル（EAP）レジストリ」の「メソッドTypes」サブリュートで割り当てられています。
Per this memo, IANA has created and will maintain a new registry entitled "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" in the Extensible Authentication Protocol (EAP) category. Also, IANA has created and will maintain the subregistries defined in the following subsections.
このメモに従って、IANAが作成され、拡張認証プロトコル（EAP）カテゴリの「EAPパラメータ（EAPパラメータ（EAP-NOOB）」という新しいレジストリを維持します。また、IANAが作成し、次のサブセクションで定義されているサブレジストリーを維持します。
IANA has created and will maintain a new subregistry entitled "EAP-NOOB Cryptosuites" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry. Cryptosuites are identified by an integer. Each cryptosuite MUST specify an ECDHE curve for the key exchange, encoding of the ECDHE public key as a JWK object, and a cryptographic hash function for the fingerprint and HMAC computation and key derivation. The hash value output by the cryptographic hash function MUST be at least 32 bytes in length. The initial values for this registry are:
IANAが作成され、「EAPパラメータ（EAP-NOOB）の「EAPパラメータ（EAP-NOOB）」レジストリの「EAPBLEアウトオブバンド認証」の「EAP-NOOB暗号スイート」という名前の新しいサブレジストを維持します。暗号スイートは整数によって識別されます。各暗号化岩は、鍵交換のECDHE曲線、ECDHE公開鍵の符号化、JWKオブジェクトとしての符号化、および指紋およびHMAC計算および鍵導出のための暗号化ハッシュ関数を指定する必要があります。暗号化ハッシュ関数によって出力されるハッシュ値は、長さは少なくとも32バイトでなければなりません。このレジストリの初期値は次のとおりです。
+=============+===============================================+
| Cryptosuite | Algorithms |
+=============+===============================================+
| 0 | Reserved |
+-------------+-----------------------------------------------+
| 1 | ECDHE curve Curve25519 [RFC7748], public-key |
| | format [RFC7517], hash function SHA-256 |
| | [RFC6234]. The JWK encoding of Curve25519 |
| | public key is defined in [RFC8037]. For |
| | clarity, the "crv" parameter is "X25519", the |
| | "kty" parameter is "OKP", and the public-key |
| | encoding contains only an x-coordinate. |
+-------------+-----------------------------------------------+
| 2 | ECDHE curve NIST P-256 [FIPS186-4], public- |
| | key format [RFC7517], hash function SHA-256 |
| | [RFC6234]. The JWK encoding of NIST P-256 |
| | public key is defined in [RFC7518]. For |
| | clarity, the "crv" parameter is "P-256", the |
| | "kty" parameter is "EC", and the public-key |
| | encoding has both an x and y coordinate, as |
| | defined in Section 6.2.1 of [RFC7518]. |
+-------------+-----------------------------------------------+
Table 8: EAP-NOOB Cryptosuites
表8：EAP-NOOB暗号スイート
EAP-NOOB implementations MUST support Cryptosuite 1. Support for Cryptosuite 2 is RECOMMENDED. An example of a Cryptosuite 1 public-key encoded as a JWK object is given below. (Line breaks are for readability only.)
EAP-Noobの実装はCryptoSuite 1をサポートしている必要があります.CryptoSuite 2のサポートをお勧めします。JWKオブジェクトとして符号化された暗号化1公開鍵の一例を以下に示す。（ラインブレークは読みやすさのみです。）
"jwk":{"kty":"OKP","crv":"X25519","x":"3p7bfXt9wbTTW2HC7OQ1Nz-
DQ8hbeGdNrfx-FG-IK08"}
Assignment of new values for new cryptosuites MUST be done through IANA with "Specification Required", as defined in [RFC8126].
[RFC8126]で定義されているように、新しい暗号スイートの新しい値の割り当ては、「仕様必須」を使用してIANAを通じて行わなければなりません。
IANA has created and will maintain a new subregistry entitled "EAP-NOOB Message Types" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry. EAP-NOOB request and response pairs are identified by an integer Message Type. The initial values for this registry are:
IANAが作成し、「EAPパラメータ（EAP-NOOB）」レジストリの「Nimble Oun-and Authentication」の「EAP-NOOBメッセージタイプ」と題された新しいサブレジストを維持します。EAP-NOOB要求と応答ペアは、整数メッセージタイプによって識別されます。このレジストリの初期値は次のとおりです。
+=========+============+========================================+
| Message | Used in | Purpose |
| Type | Exchange | |
+=========+============+========================================+
| 0 | Error | Error notification |
+---------+------------+----------------------------------------+
| 1 | All | PeerId and PeerState discovery |
| | exchanges | |
+---------+------------+----------------------------------------+
| 2 | Initial | Version, cryptosuite, and parameter |
| | | negotiation |
+---------+------------+----------------------------------------+
| 3 | Initial | Exchange of ECDHE keys and nonces |
+---------+------------+----------------------------------------+
| 4 | Waiting | Indication to the peer that the server |
| | | has not yet received an OOB message |
+---------+------------+----------------------------------------+
| 5 | Completion | NoobId discovery |
+---------+------------+----------------------------------------+
| 6 | Completion | Authentication and key confirmation |
| | | with HMAC |
+---------+------------+----------------------------------------+
| 7 | Reconnect | Version, cryptosuite, and parameter |
| | | negotiation |
+---------+------------+----------------------------------------+
| 8 | Reconnect | Exchange of ECDHE keys and nonces |
+---------+------------+----------------------------------------+
| 9 | Reconnect | Authentication and key confirmation |
| | | with HMAC |
+---------+------------+----------------------------------------+
Table 9: EAP-NOOB Message Types
表9：EAP-NOOBメッセージタイプ
Assignment of new values for new Message Types MUST be done through IANA with "Specification Required", as defined in [RFC8126].
[RFC8126]で定義されているように、新しいメッセージタイプの新しい値の割り当ては、「指定必須」を使用してIANAを介して行う必要があります。
IANA has created and will maintain a new subregistry entitled "EAP-NOOB Error codes" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry. Cryptosuites are identified by an integer. The initial values for this registry are:
IANAが作成し、「EAPパラメータ（EAP-NOOB）」レジストリの「Nimble Oun-and Authentical認証」の「EAP-NOOBエラーコード」という名前の新しいサブレジストを維持します。暗号スイートは整数によって識別されます。このレジストリの初期値は次のとおりです。
+============+===========================================+
| Error code | Purpose |
+============+===========================================+
| 1001 | Invalid NAI |
+------------+-------------------------------------------+
| 1002 | Invalid message structure |
+------------+-------------------------------------------+
| 1003 | Invalid data |
+------------+-------------------------------------------+
| 1004 | Unexpected message type |
+------------+-------------------------------------------+
| 1005 | Invalid ECDHE key |
+------------+-------------------------------------------+
| 2001 | Unwanted peer |
+------------+-------------------------------------------+
| 2002 | State mismatch, user action required |
+------------+-------------------------------------------+
| 2003 | Unrecognized OOB message identifier |
+------------+-------------------------------------------+
| 2004 | Unexpected peer identifier |
+------------+-------------------------------------------+
| 3001 | No mutually supported protocol version |
+------------+-------------------------------------------+
| 3002 | No mutually supported cryptosuite |
+------------+-------------------------------------------+
| 3003 | No mutually supported OOB direction |
+------------+-------------------------------------------+
| 4001 | HMAC verification failure |
+------------+-------------------------------------------+
| 5001 | Application-specific error |
+------------+-------------------------------------------+
| 5002 | Invalid server info |
+------------+-------------------------------------------+
| 5003 | Invalid server URL |
+------------+-------------------------------------------+
| 5004 | Invalid peer info |
+------------+-------------------------------------------+
| 6001-6999 | Reserved for Private and Experimental Use |
+------------+-------------------------------------------+
Table 10: EAP-NOOB Error Codes
表10：EAP-NOOBエラーコード
Assignment of new error codes MUST be done through IANA with "Specification Required", as defined in [RFC8126], except for the range 6001-6999. This range is reserved for "Private Use" and "Experimental Use", both locally and on the open Internet.
6001-6999の範囲を除いて、[RFC8126]で定義されているように、「指定必須」を使用して、新しいエラーコードの割り当てを行う必要があります。この範囲は、ローカルでオープンインターネット上でも、「プライベート使用」および「実験的使用」のために予約されています。
IANA has created and will maintain a new subregistry entitled "EAP-NOOB ServerInfo Data Fields" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry. The initial values for this registry are:
IANAは作成され、「EAPパラメータ（EAP-NOOB）」レジストリの「Nimble Out-and Authent認証」の「EAP-NOOB ServerInfoデータ・フィールド」と題された新しいサブレジストを維持します。このレジストリの初期値は次のとおりです。
+================+=====================+
| Data Field | Specification |
+================+=====================+
| Type | RFC 9140, Section 4 |
+----------------+---------------------+
| ServerName | RFC 9140, Section 4 |
+----------------+---------------------+
| ServerURL | RFC 9140, Section 4 |
+----------------+---------------------+
| SSIDList | RFC 9140, Section 4 |
+----------------+---------------------+
| Base64SSIDList | RFC 9140, Section 4 |
+----------------+---------------------+
Table 11: ServerInfo Data Fields
表11：ServerInfoデータ・フィールド
Assignment of new values for new ServerInfo data fields MUST be done through IANA with "Specification Required", as defined in [RFC8126].
[RFC8126]で定義されているように、新しいServerInfoデータフィールドの新しい値の割り当ては、「指定必須」を使用してIANAを通じて行わなければなりません。
IANA is requested to create and maintain a new subregistry entitled "EAP-NOOB PeerInfo Data Fields" in the "Nimble Out-of-Band Authentication for EAP Parameters (EAP-NOOB)" registry. The initial values for this registry are:
IANAは、「EAPパラメータ（EAP-NOOB）のレジストリの「Nimble Out-and Authentication」の「EAP-NOOB PeerInfoデータ・フィールド」と題された新しいサブレイストを作成して維持することが要求されています。このレジストリの初期値は次のとおりです。
+==============+=====================+
| Data Field | Specification |
+==============+=====================+
| Type | RFC 9140, Section 4 |
+--------------+---------------------+
| PeerName | RFC 9140, Section 4 |
+--------------+---------------------+
| Manufacturer | RFC 9140, Section 4 |
+--------------+---------------------+
| Model | RFC 9140, Section 4 |
+--------------+---------------------+
| SerialNumber | RFC 9140, Section 4 |
+--------------+---------------------+
| MACAddress | RFC 9140, Section 4 |
+--------------+---------------------+
| SSID | RFC 9140, Section 4 |
+--------------+---------------------+
| Base64SSID | RFC 9140, Section 4 |
+--------------+---------------------+
| BSSID | RFC 9140, Section 4 |
+--------------+---------------------+
Table 12: PeerInfo Data Fields
表12：PeerInfoデータフィールド
Assignment of new values for new PeerInfo data fields MUST be done through IANA with "Specification Required", as defined in [RFC8126].
[RFC8126]で定義されているように、新しいPeerInfoデータフィールドの新しい値の割り当ては、「仕様必須」を使用してIANAを介して行う必要があります。
The special-use domain "eap-noob.arpa" has been registered in the .arpa registry (https://www.iana.org/domains/arpa) and the "Special-Use Domain Names" registry (https://www.iana.org/assignments/special-use-domain-names).
特殊使用ドメイン "eap-noob.arpa"は、.ARPAレジストリ（https://www.iana.org/domains/arpa）に登録されています。 "https：//"特別使用ドメイン名 "レジストリ（https：//www.iana.org/assignments/special-use-domain-names）。
Experts SHOULD be conservative in the allocation of new Cryptosuites. Experts MUST ascertain that the requested values match the current Crypto Forum Research Group (CFRG) guidance on cryptographic algorithm security. Experts MUST ensure that any new Cryptosuites fully specify the encoding of the ECDHE public key and should include details, such as the value of the "kty" (key type) parameter when JWK [RFC7517] encoding is used.
専門家は、新しい暗号スイートの割り当てにおいて保守的であるべきです。専門家は、要求された価値が、Cryptographalアルゴリズムのセキュリティに関する現在の暗号フォーラム研究グループ（CFRG）ガイダンスと一致することを確認する必要があります。専門家は、新しい暗号化がECDHE公開鍵の符号化を完全に指定し、JWK [RFC7517]エンコーディングが使用されている場合の「KTY」（キータイプ）パラメータのような詳細を含める必要があります。
Experts SHOULD be conservative in the allocation of new Message Types. Experts SHOULD ascertain that a well-defined specification for the new Message Type is permanently and publicly available.
専門家は、新しいメッセージタイプの割り当てにおいて保守的であるべきです。専門家は、新しいメッセージタイプの明確な仕様が恒久的かつ公に利用可能であることを確認する必要があります。
Experts SHOULD be conservative in the allocation of new Error codes, since the 6001-6999 range is already reserved for private and experimental use.
6001-6999の範囲は既にプライベートおよび実験的な使用のために予約されているので、専門家は新しいエラーコードの割り当てにおいて保守的であるべきです。
Experts MAY be liberal in the allocation of new ServerInfo and PeerInfo data fields. Experts MUST ensure that the data field requested has a unique name that is not easily confused with existing registrations. For example, requests for a new PeerInfo data field "ssid" should be rejected even though it is unique because it can be confused with the existing registration of "SSID". Experts MUST ensure that a suitable Description for the data field is available.
専門家は、新しいServerInfoとPeerInfoデータフィールドの割り当ての中でリベラルになることがあります。専門家は、要求されたデータフィールドに既存の登録とは容易に混同されていない一意の名前があることを確認する必要があります。たとえば、「SSID」の既存の登録と混同できるため、新しいPeerInfoデータフィールド "SSID"の要求は拒否されます。専門家は、データフィールドの適切な説明が利用可能であることを確認する必要があります。
EAP-NOOB is an authentication and key derivation protocol; thus, security considerations can be found in most sections of this specification. In the following, we explain the protocol design and highlight some other special considerations.
EAP-NOOBは認証および鍵導出プロトコルです。したがって、セキュリティ上の考慮事項は、この仕様のほとんどのセクションで見つけることができます。以下では、プロトコル設計を説明し、他の特別な考慮事項を強調しています。
EAP-NOOB establishes a shared secret with an authenticated ECDHE key exchange. The mutual authentication in EAP-NOOB is based on two separate features, both conveyed in the OOB message. The first authentication feature is the secret nonce Noob. The peer and server use this secret in the Completion Exchange to mutually authenticate the session key previously created with ECDHE. The message authentication codes computed with the secret nonce Noob are alone sufficient for authenticating the key exchange. The second authentication feature is the integrity-protecting fingerprint Hoob. Its purpose is to prevent impersonation attacks even in situations where the attacker is able to eavesdrop on the OOB channel and the nonce Noob is compromised. In some human-assisted OOB channels, such as human-perceptible audio or a user-typed URL, it may be easier to detect tampering than disclosure of the OOB message, and such applications benefit from the second authentication feature.
EAP-Noobは、認証されたECDHE鍵交換で共有秘密を確立します。EAP-Noobの相互認証は、両方ともOOBメッセージで伝達されている2つの別々の機能に基づいています。最初の認証機能は秘密のNOCE NOOBです。ピアとサーバーは完了Exchangeでこの秘密を使用して、ECDHEで以前に作成されたセッションキーを相互に認証します。秘密Nonce Noobで計算されたメッセージ認証コードは、鍵交換を認証するのに十分です。2番目の認証機能は、整合性保護指紋穴です。その目的は、攻撃者がOOBチャンネルを盗聴することができ、Nonce Noobが損なわれている状況でも、偽装攻撃を防ぐことです。人間知覚不可能なオーディオやユーザ入力されたURLなどの人間支援OOBチャネルでは、OOBメッセージの開示よりも改ざんが検出されやすくなり、そのようなアプリケーションは第2の認証機能から利益を得ることができる。
The additional security provided by the cryptographic fingerprint Hoob is somewhat intricate to understand. The endpoint that receives the OOB message uses Hoob to verify the integrity of the ECDHE exchange. Thus, the OOB receiver can detect impersonation attacks that may have happened on the in-band channel. The other endpoint, however, is not equally protected because the OOB message and fingerprint are sent only in one direction. Some protection to the OOB sender is afforded by the fact that the user may notice the failure of the association at the OOB receiver and therefore reset the OOB sender. Other device-pairing protocols have solved similar situations by requiring the user to confirm to the OOB sender that the association was accepted by the OOB receiver, e.g., with a button press on the sender side. Applications MAY implement EAP-NOOB in this way. Nevertheless, since EAP-NOOB was designed to work with strictly one-directional OOB communication and the fingerprint is only the second authentication feature, the EAP-NOOB specification does not mandate such explicit confirmation to the OOB sender.
暗号指紋ぼんだったフオブによって提供される追加のセキュリティは、理解するのが多少複雑です。 OOBメッセージを受信するエンドポイントは、ECDHE交換の整合性を検証するためにHoobを使用します。したがって、OOB受信機は、インバンドチャネル上で起こった可能性がある偽装攻撃を検出することができる。ただし、OOBメッセージや指紋が一方向にのみ送信されるため、他のエンドポイントは等しく保護されていません。 OOB送信者へのいくつかの保護は、ユーザーがOOB受信者での関連付けの失敗に気付くかもしれないという事実によって与えられ、したがってOOB送信者をリセットすることによって与えられます。他のデバイスペアリングプロトコルは、協会がOOB受信機によって、例えば、送信者側を押すと、ユーザがOOB送信者を確認することを要求することによって同様の状況を解決した。このようにしてEAP-NOOBを実装することができます。それにもかかわらず、EAP-Noobは厳密に一方向OOB通信で動作するように設計されており、指紋は2番目の認証機能のみであるため、EAP-Noobの仕様はそのような明示的な確認をOOB送信者に義務付けません。
To summarize, EAP-NOOB uses the combined protection of the secret nonce Noob and the cryptographic fingerprint Hoob, both conveyed in the OOB message. The secret nonce Noob alone is sufficient for mutual authentication unless the attacker can eavesdrop on it from the OOB channel. Even if an attacker is able to eavesdrop on the secret nonce Noob, it nevertheless cannot perform a full impersonation attack on the in-band channel because a mismatching fingerprint would alert the OOB receiver, which would reject the OOB message. The attacker that eavesdropped on the secret nonce can impersonate the OOB receiver to the OOB sender. If it does, the association will appear to be complete only on the OOB sender side, and such situations have to be resolved by the user by resetting the OOB sender to the initial state.
要約すると、EAP-Noobは、秘密のNonce Noobの組み合わせ保護と暗号指紋フオブを使用し、どちらもOOBメッセージで伝えられています。攻撃者がOOBチャネルから盗聴できる限り、秘密のNOOB単独では相互認証に十分です。攻撃者が秘密のNonce Noobを盗聴できる場合でも、それは、不一致指紋がOOBメッセージを拒否するため、インバンドチャネルに対して完全な偽装攻撃を実行することはできません。秘密のNonceを盗聴した攻撃者は、OOB受信者をOOB送信者に偽装することができます。そうであれば、関連付けはOOB送信者側でのみ完了しているように見え、そのような状況はOOB送信者を初期状態にリセットすることによってユーザによって解決されなければならない。
The expected use cases for EAP-NOOB are ones where it replaces a user-entered access credential in IoT appliances. In wireless network access without EAP, the user-entered credential is often a passphrase that is shared by all the network stations. The advantage of an EAP-based solution, including EAP-NOOB, is that it establishes a different shared secret for each peer device, which makes the system more resilient against device compromise. Another advantage is that it is possible to revoke the security association for an individual device on the server side.
EAP-NOOBの予想されるユースケースは、IOTアプライアンスのユーザー入力されたアクセス信任状を置き換えるものです。EAPのないワイヤレスネットワークアクセスでは、ユーザー入力信任状はしばしばすべてのネットワークステーションによって共有されているパスフレーズです。EAP-NOOBを含むEAPベースのソリューションの利点は、ピアデバイスごとに異なる共有秘密を確立し、システムはデバイスの侵害に対してシステムをより弾力的にします。他の利点は、サーバ側の個々の装置のセキュリティ関連付けを取り消すことが可能であることである。
Forward secrecy during fast reconnect in EAP-NOOB is optional. The Reconnect Exchange in EAP-NOOB provides forward secrecy only if both the server and peer send their fresh ECDHE keys. This allows both the server and peer to limit the frequency of the costly computation that is required for forward secrecy. The server MAY adjust the frequency of its attempts at ECDHE rekeying based on what it knows about the peer's computational capabilities.
EAP-NOOBでの高速再接続中の順序秘密はオプションです。EAP-Noobの再接続Exchangeは、サーバーとピアの両方が新しいECDHEキーを送信している場合にのみ、前方秘密を提供します。これにより、サーバーとピアの両方が、前方秘密に必要なコストのかかる計算の頻度を制限できます。サーバは、ピアの計算能力について知っているものに基づいて、ECDHE REKKINGでのその試行の頻度を調整することができる。
Another way in which some servers may control their computational load is to reuse the same ECDHE key for all peers over a short server-specific time window. In that case, forward secrecy will be achieved only after the server updates its ECDHE key, which may be a reasonable trade-off between security and performance. However, the server MUST NOT reuse the same ECDHE key with the same peer when rekeying with ECDHE (KeyingMode=2 or KeyingMode=3). Instead, it can simply not send an ECDHE key (KeyingMode=1).
一部のサーバーが自分の計算ロードを制御できるもう1つの方法は、短いサーバー固有のタイムウィンドウを介してすべてのピアに同じECDHEキーを再利用することです。その場合、サーバーがそのECDHEキーを更新した後にのみ、前方秘密が達成されます。これは、セキュリティとパフォーマンスの間の合理的なトレードオフである可能性があります。ただし、ECDHEで回復したときに同じECDHEキーを同じピアで再利用してはいけません（キーイングモード= 2またはキーイングモード= 3）。代わりに、それは単にECDHEキーを送信しない（キーイングモード= 1）。
The users delivering the OOB messages will often authenticate themselves to the EAP server, e.g., by logging into a secure web page or API. In this case, the server can associate the peer device with the user account. Applications that make use of EAP-NOOB can use this information for configuring the initial owner of the freshly registered device.
OOBメッセージを配信するユーザは、例えば安全なWebページまたはAPIにログインすることによって、多くの場合、EAPサーバに自分自身を認証します。この場合、サーバーはピアデバイスをユーザーアカウントに関連付けることができます。EAP-NOOBを利用するアプリケーションは、この情報を使用して、登録されているデバイスの最初の所有者を設定できます。
Potential weaknesses in EAP-NOOB arise from the fact that the user must physically identify the correct peer device. If the user mistakenly delivers the OOB message from the wrong peer device to the server, the server may create an association with the wrong peer. The reliance on the user in identifying the correct endpoints is an inherent property of user-assisted, out-of-band authentication. To understand the potential consequences of the user mistake, we need to consider a few different scenarios. In the first scenario, there is no malicious party, and the user makes an accidental mistake between two out-of-the-box devices that are both ready to be registered to a server. If the user delivers the OOB message from the wrong device to the server, confusion may arise but usually no security issues. In the second scenario, an attacker intentionally tricks the user, for example, by substituting the original peer device with a compromised one. This is essentially a supply chain attack where the user accepts a compromised physical device.
EAP-Noobの潜在的な弱点は、ユーザーが正しいピアデバイスを物理的に識別しなければならないという事実から発生します。ユーザが誤って誤ったピア装置からサーバにOOBメッセージを配信すると、サーバは間違ったピアとの関連付けを作成することができる。正しいエンドポイントを識別する際のユーザーへの依存は、ユーザー支援された帯域外認証の固有のプロパティです。ユーザーの間違いの潜在的な影響を理解するためには、いくつかの異なるシナリオを考慮する必要があります。最初のシナリオでは悪意のあるパーティーはありません、そしてユーザーはサーバーに登録する準備ができている2つのボックス外のデバイス間で偶然の間違いを犯します。ユーザーが誤ったデバイスからサーバーにOOBメッセージを配信すると、混乱が発生する可能性がありますが、通常はセキュリティ上の問題はありません。第2のシナリオでは、攻撃者は意図的に、例えば元のピア装置を侵害されたものと置き換えることによってユーザをトリックします。これは本質的に、ユーザーが妥協された物理デバイスを受け入れるサプライチェーン攻撃です。
There is also a third scenario, in which an opportunistic attacker tries to take advantage of the user's accidental mistake. For example, the user could play an audio or a blinking LED message to a device that is not expecting to receive it. In simple security bootstrapping solutions that transfer a primary key to the device via the OOB channel, the device could misuse or leak the accidentally received primary key. EAP-NOOB is not vulnerable to such opportunistic attackers because the OOB message has no value to anyone who did not take part in the corresponding Initial Exchange.
第3のシナリオもあり、日和見論的攻撃者がユーザの偶発的な間違いを利用しようとしようとしている。例えば、ユーザは、それを受け取ることを期待していない装置へのオーディオまたは点滅LEDメッセージを再生することができる。OOBチャネルを介してデバイスをデバイスに転送する単純なセキュリティブートストラップソリューションでは、デバイスは誤って受信された主キーを誤用または漏洩する可能性があります。EAP-NOOBは、OOBメッセージが対応する最初のExchangeに参加しなかった人に価値がないため、このような日和見論的攻撃者に対して脆弱ではありません。
One mechanism that can mitigate user mistakes is certification of peer devices. A certificate or an attestation token (e.g., [TLS-CWT] and [RATS-EAT]) can convey to the server authentic identifiers and attributes, such as model and serial number, of the peer device. Compared to a fully certificate-based authentication, however, EAP-NOOB can be used without trusted third parties and does not require the user to know any identifier of the peer device; physical access to the device is sufficient for bootstrapping with EAP-NOOB.
ユーザー間違いを軽減できる1つのメカニズムは、ピアデバイスの認証です。証明書または検証トークン（例えば、[TLS-CWT]および[RATS-EAT]]）は、ピアデバイスのモデルおよびシリアル番号などのサーバーの本物の識別子および属性に伝えることができます。ただし、完全証明書ベースの認証と比較して、EAP-NOOBは信頼できる第三者なしで使用でき、ユーザーがピアデバイスの識別子を知る必要はありません。デバイスへの物理的アクセスは、EAP-NOOBを使用したブートストラップに十分です。
Similarly, the attacker can try to trick the user into delivering the OOB message to the wrong server so that the peer device becomes associated with the wrong server. If the EAP server is accessed through a web user interface, the attack is akin to phishing attacks where the user is tricked into accessing the wrong URL and wrong web page. OOB implementation with a dedicated app on a mobile device, which communicates with a server API at a preconfigured URL, can protect against such attacks.
同様に、攻撃者は、ピアデバイスが間違ったサーバーに関連付けられているように、ユーザーを誤ったサーバーに配信するようにユーザーをトリックさせることができます。EAPサーバーがWebユーザーインターフェースを介してアクセスされた場合、攻撃はユーザーが間違ったURLと間違ったWebページにアクセスするためにトリックされているフィッシング攻撃に似ています。Preconfiged URLでサーバーAPIと通信するモバイルデバイス上の専用アプリを使用したOOB実装は、そのような攻撃から保護することができます。
After the device registration, an attacker could clone the device identity by copying the keys from the persistent EAP-NOOB association into another device. The attacker can be an outsider who gains access to the keys or the device owner who wants to have two devices matching the same registration. The cloning threats can be mitigated by creating the cryptographic keys and storing the persistent EAP-NOOB association on the peer device in a secure hardware component such as a trusted execution environment (TEE). Furthermore, remote attestation on the application level could provide assurance to the server that the device has not been cloned. Reconnect Exchange with a new cryptosuite (KeyingMode=3) will also disconnect all but the first clone that performs the update.
デバイス登録の後、攻撃者は、永続的なEAP-Noobアソシエーションから別のデバイスにキーをコピーすることによってデバイスIDをクローン作成できます。攻撃者は、同じ登録に一致する2つのデバイスがあるキーまたはデバイス所有者へのアクセスを獲得する部外者になることができます。クローニングの脅威は、暗号化キーを作成し、信頼できる実行環境（TEE）などの安全なハードウェアコンポーネント内の永続的なEAP-NOOBアソシエーションを保存することによって軽減できます。さらに、アプリケーションレベルのリモート認証は、デバイスがクローン化されていないサーバーに保証を提供できます。Exchangeを新しい暗号化済み（キーイングモード= 3）との再接続も、アップデートを実行する最初のクローンをすべて切断します。
Another potential threat is spoofed user input or output on the peer device. When the user is delivering the OOB message to or from the correct peer device, a trusted path between the user and the peer device is needed. That is, the user must communicate directly with an authentic operating system and EAP-NOOB implementation in the peer device and not with a spoofed user interface. Otherwise, a registered device that is under the control of the attacker could emulate the behavior of an unregistered device. The secure path can be implemented, for example, by having the user press a reset button to return the device to the Unregistered (0) state and to invoke a trusted UI. The problem with such trusted paths is that they are not standardized across devices.
もう1つの潜在的な脅威は、ピアデバイス上のユーザー入力または出力を偽装しています。ユーザがOOBメッセージを正しいピア装置に配信しているとき、ユーザとピア装置との間の信頼された経路が必要とされる。すなわち、ユーザは、偽造されたユーザインタフェースではなく、本物のオペレーティングシステムとEAP-Noobの実装と直接通信する必要があります。そうでなければ、攻撃者の制御下にある登録された装置は、未登録の装置の動作をエミュレートすることができる。セキュアパスは、例えば、ユーザがリセットボタンを押すことによって、装置を未登録（0）状態に戻し、信頼されたUIを呼び出すことによって実装することができる。そのような信頼できるパスの問題は、それらがデバイス間で標準化されていないことです。
Another potential consequence of a spoofed UI is the misbinding attack where the user tries to register a correct but compromised device, which tricks the user into registering another (uncompromised) device instead. For example, the compromised device might have a malicious, full-screen app running, which presents to the user QR codes copied, in real time, from another device's screen. If the unwitting user scans the QR code and delivers the OOB message in it to the server, the wrong device may become registered in the server. Such misbinding vulnerabilities arise because the user does not have any secure way of verifying that the in-band cryptographic handshake and the out-of-band physical access are terminated at the same physical device. Sethi et al. [Sethi19] analyze the misbinding threat against device-pairing protocols and also EAP-NOOB. Essentially, all protocols where the authentication relies on the user's physical access to the device are vulnerable to misbinding, including EAP-NOOB.
偽装されたUIのもう1つの潜在的な結果は、ユーザーが正しいが侵害されたデバイスを登録しようとしています。たとえば、侵入されたデバイスは、悪意のあるフルスクリーンのアプリの実行を行い、他のデバイスの画面からリアルタイムでコピーされたユーザーQRコードを提示します。拒否されていないユーザーがQRコードをスキャンしてサーバーにOOBメッセージを配信すると、誤ったデバイスがサーバーに登録される可能性があります。そのような不可逆的な脆弱性は、帯域内暗号ハンドシェイクおよび帯域外の物理アクセスが同じ物理デバイスで終了することを検証するための安全な方法を何も認証しないので生じる。 Sethiら。 [SETHI19]デバイスペアリングプロトコルとEAP-NOOBに対する誤解脅威を分析します。基本的に、認証がデバイスへのユーザーの物理的アクセスに依存するすべてのプロトコルは、EAP-NOOBを含む不正行為に対して脆弱です。
A standardized trusted path for communicating directly with the trusted computing base in a physical device would mitigate the misbinding threat, but such paths rarely exist in practice. Careful asset tracking on the server side can also prevent most misbinding attacks if the peer device sends its identifiers or attributes in the PeerInfo field and the server compares them with the expected values. The wrong but uncompromised device's PeerInfo will not match the expected values. Device certification by the manufacturer can further strengthen the asset tracking.
物理デバイスの信頼できるコンピューティングベースと直接通信するための標準化された信頼されたパスは、誤解された脅威を軽減するだろうが、そのような経路は実際には存在しない。サーバー側での慎重な資産追跡は、ピアデバイスがPeerInfoフィールドにその識別子または属性を送信し、サーバーがそれらを期待値と比較した場合、ほとんどの不正な攻撃を防ぐことができます。間違ったが妥協のないデバイスのPeerInfoは、期待値と一致しません。製造元によるデバイス認証は、資産追跡をさらに強化することができます。
The PeerId value in the protocol is a server-allocated identifier for its association with the peer and SHOULD NOT be shown to the user because its value is initially ephemeral. Since the PeerId is allocated by the server and the scope of the identifier is the single server, the so-called identifier squatting attacks, where a malicious peer could reserve another peer's identifier, are not possible in EAP-NOOB. The server SHOULD assign a random or pseudorandom PeerId to each new peer. It SHOULD NOT select the PeerId based on any peer characteristics that it may know, such as the peer's link-layer network address.
プロトコル内のPeerID値は、ピアとの関連付けのためのサーバ割り当て識別子であり、その値は最初は一時的なものであるため、ユーザーに表示されるべきではありません。PeerIDはサーバーによって割り当てられ、識別子の範囲が単一のサーバーであるため、悪意のあるピアが別のピアの識別子を留保することができる、いわゆる識別子スクロース攻撃は、EAP-NOOBでは不可能です。サーバーは、新しいピアごとにランダムまたは疑似乱数Peeridを割り当てる必要があります。ピアのリンク層のネットワークアドレスなど、わかっている可能性がある任意のピア特性に基づいて、PeerIDを選択しないでください。
User reset or failure in the OOB Step can cause the peer to perform many Initial Exchanges with the server, which allocates many PeerId values and stores the ephemeral protocol state for them. The peer will typically only remember the latest ones. EAP-NOOB leaves it to the implementation to decide when to delete these ephemeral associations. There is no security reason to delete them early, and the server does not have any way to verify that the peers are actually the same one. Thus, it is safest to store the ephemeral states on the server for at least one day. If the OOB messages are sent only in the server-to-peer direction, the server SHOULD NOT delete the ephemeral state before all the related Noob values have expired.
OOBステップでのユーザーリセットまたは失敗により、ピアはサーバーと多くの初期交換を実行させるため、多くのPeerid値を割り当て、それらのためのエフェメラルプロトコル状態を格納します。ピアは通常最新のもののみを覚えています。EAP-Noobは、これらのエフェラサーマルアソシエーションをいつ削除するかを決定するために実装に残します。それらを早く削除するセキュリティ理由はありません。サーバーには、ピアが実際に同じものがあることを確認する方法はありません。したがって、少なくとも1日間サーバー上の一時的な状態を保存するのは最も安全です。OOBメッセージがサーバーからピア方向にのみ送信された場合、関連するすべてのNOOB値が期限切れになる前に、サーバーはエフェメラ語状態を削除しないでください。
After completion of EAP-NOOB, the server may store the PeerInfo data, and the user may use it to identify the peer and its attributes, such as the make and model or serial number. A compromised peer could lie in the PeerInfo that it sends to the server. If the server stores any information about the peer, it is important that this information is approved by the user during or after the OOB Step. Without verification by the user or authentication on the application level, the PeerInfo is not authenticated information and should not be relied on. One possible use for the PeerInfo field is EAP channel binding (see Section 6.7).
EAP-NOOBの完了後、サーバーはPeerInfoデータを格納することができ、ユーザーはそれを使用して、PeerとMakeとModelまたはSerial Numberなどのその属性を識別するために使用できます。侵入先ピアは、サーバーに送信するPeerInfoにある可能性があります。サーバーがピアに関する情報を格納している場合は、この情報がOOBステップの間または後にユーザーによって承認されることが重要です。アプリケーションレベルでのユーザーまたは認証による検証なしに、PeerInfoは認証されていない情報ではなく、依存しないでください。PeerInfoフィールドに可能な1つの可能な使用はEAPチャネルバインディングです（6.7項を参照）。
The fingerprint Hoob protects all the information exchanged in the Initial Exchange, including the cryptosuite negotiation. The message authentication codes MACs and MACp also protect the same information. The message authentication codes MACs2 and MACp2 protect information exchanged during key renegotiation in the Reconnect Exchange. This prevents downgrading attacks to weaker cryptosuites, as long as the possible attacks take more time than the maximum time allowed for the EAP-NOOB completion. This is typically the case for recently discovered cryptanalytic attacks.
指紋揚錨機は、暗号型ネゴシエーションを含む、最初の交換で交換されたすべての情報を保護します。メッセージ認証コードMACSおよびMACPも同じ情報を保護する。メッセージ認証コードMACS2およびMACP2は、再接続交換内のキーの再生中に交換された情報を保護する。これは、可能な攻撃がEAP-NOOBの完了の可能な最大時間よりも時間がかかる限り、攻撃を弱めるのを防ぎます。これは通常、最近発見された暗号分析攻撃の場合です。
As an additional precaution, the EAP server and peer MUST check for downgrading attacks in the Reconnect Exchange as follows. As long as the server or peer saves any information about the other endpoint, it MUST also remember the previously negotiated cryptosuite and MUST NOT accept renegotiation of any cryptosuite that is known to be weaker than the previous one, such as a deprecated cryptosuite. Determining the relative strength of the cryptosuites is out of scope of this specification and may be managed by implementations or by local policies at the peer and server.
追加の予防策として、EAPサーバーとピアは次のように再接続交換の攻撃をダウングレードする必要があります。サーバーまたはピアが他のエンドポイントに関する情報を保存する限り、以前にネゴシエートされた暗号化を覚えておく必要があり、以前に非推奨の暗号化済みのような前のものよりも弱いことが知られている任意の暗号化済みのリネクシエーションを受け入れてはなりません。暗号スイートの相対的な強度を決定することは、この仕様の範囲外であり、実装によって、またはピアおよびサーバーのローカルポリシーによって管理されてもよい。
Integrity of the direction negotiation cannot be verified in the same way as the integrity of the cryptosuite negotiation. That is, if the OOB channel used in an application is critically insecure in one direction, an on-path attacker could modify the negotiation messages and thereby cause that direction to be used. Applications that support OOB messages in both directions SHOULD, therefore, ensure that the OOB channel has sufficiently strong security in both directions. While this is a theoretical vulnerability, it could arise in practice if EAP-NOOB is deployed in new applications. Currently, we expect most peer devices to support only one OOB direction; in which case, interfering with the direction negotiation can only prevent the completion of the protocol.
暗号型ネゴシエーションの完全性と同じ方法で、方向交渉の完全性を検証することはできません。すなわち、アプリケーションで使用されているOOBチャネルが一方向に非常に安全である場合、オンパス攻撃者はネゴシエーションメッセージを変更してその方向を使用する可能性がある。したがって、両方向にOOBメッセージをサポートするアプリケーションは、OOBチャネルが両方向に十分強いセキュリティを持っていることを確認する必要があります。これは理論的な脆弱性ですが、EAP-NOOBが新しいアプリケーションに展開されている場合は実際には発生する可能性があります。現在、ほとんどのピアデバイスが1つのOOB方向しかサポートできないと予想しています。その場合、方向交渉を妨害することで、プロトコルの完了を防ぐことができます。
The long-term shared key material Kz in the persistent EAP-NOOB association is established with an ECDHE key exchange when the peer and server are first associated. It is a weaker secret than a manually configured random shared key because advances in cryptanalysis against the used ECDHE curve could eventually enable the attacker to recover Kz. EAP-NOOB protects against such attacks by allowing cryptosuite upgrades in the Reconnect Exchange and by updating the shared key material Kz whenever the cryptosuite is upgraded. We do not expect the cryptosuite upgrades to be frequent, but, if an upgrade becomes necessary, it can be done without manual reset and reassociation of the peer devices.
永続的なEAP-NOOBアソシエーション内の長期共有キーマテリアルkzは、ピアとサーバーが最初に関連付けられているときにECDHE鍵交換で確立されます。使用されているECDHE曲線に対する暗号化の進歩が最終的に攻撃者がKZを回復できるようになるため、手動で構成されたランダム共有キーよりも弱い秘密です。EAP-NOOBは、Reconnect Exchangeの暗号化アップグレードを許可し、暗号化されたキーマテリアルkzをアップグレードすることによって、そのような攻撃から保護し、暗号化されたキーマテリアルKZをアップデートすることによって保護します。暗号化アップグレードが頻繁に予想されないが、アップグレードが必要な場合は、手動リセットやピアデバイスの再割り当てなしで行うことができます。
Section 7.16 of [RFC3748] allows EAP methods to specify protected result indications because EAP-Success and EAP-Failure packets are neither acknowledged nor integrity protected. [RFC3748] notes that these indications may be explicit or implicit.
[RFC3748]のセクション7.16を使用すると、EAP-SuccessパケットとEAP障害パケットは確認応答も保護されていないため、EAPメソッドは保護された結果の表示を指定できます。[RFC3748]これらの指示は明示的または暗黙的な場合があります。
EAP-NOOB relies on implicit, protected success indicators in the Completion Exchange and Reconnect Exchange. Successful verification of MACs and MACs2 in the EAP-Request message from the server (message type 6 and message type 9, respectively) acts as an implicit, protected success indication to the peer. Similarly, successful verification of MACp and MACp2 in the EAP-Response message from the peer (message type 6 and message type 9, respectively) act as an implicit, protected success indication to the server.
EAP-Noobは、完了交換の暗黙の保護された成功指標に依存し、再接続交換。サーバからのEAP要求メッセージ内のMACSおよびMACS2の検証が成功した（それぞれメッセージタイプ6とメッセージタイプ9）は、ピアへの暗黙的な保護された成功指示として機能します。同様に、ピアからEAP応答メッセージ内のMACPおよびMACP2の検証を成功させる（それぞれメッセージタイプ6およびメッセージタイプ9）は、サーバーへの暗黙の保護された成功指示として機能します。
EAP-NOOB failure messages are not protected. Protected failure result indications would not significantly improve availability since EAP-NOOB reacts to most malformed data by ending the current EAP conversation in EAP-Failure. However, since EAP-NOOB spans multiple conversations, failure in one conversation usually means no state change on the level of the EAP-NOOB state machine.
EAP-NOOB障害メッセージは保護されていません。EAP-NOOBは、EAP-障害時の現在のEAP会話を終了することで、最も不正なデータに反応するため、保護された失敗結果表示は可用性を大幅に向上させません。ただし、EAP-NOOBは複数の会話に及ぶため、1つの会話の失敗は通常、EAP-NOOBステートマシンのレベルの状態変更を意味します。
EAP channel binding, defined in [RFC6677], means that the endpoints compare their perceptions of network properties, such as lower-layer identifiers, over the secure channel established by EAP authentication. Section 4.1 of [RFC6677] defines two approaches to channel binding. EAP-NOOB follows the first approach, in which the peer and server exchange plaintext information about the network over a channel that is integrity protected with keys derived during the EAP execution. More specifically, channel information is exchanged in the plaintext PeerInfo and ServerInfo objects and is later verified with message authentication codes (MACp, MACs, MACp2, and MACs2). This allows policy-based comparison with locally perceived network properties on either side, as well as logging for debugging purposes. The peer MAY include in PeerInfo any data items that it wants to bind to the EAP-NOOB association and to the exported keys. These can be properties of the authenticator or the access link, such as the SSID and BSSID of the wireless network (see Table 6). As noted in Section 4.3 of [RFC6677], the scope of the channel binding varies between deployments. For example, the server may have less link-layer information available from roaming networks than from a local enterprise network, and it may be unable to verify all the network properties received in PeerInfo. There are also privacy considerations related to exchanging the ServerInfo and PeerInfo while roaming (see Section 6.10).
[RFC6677]で定義されているEAP Channel Bindingは、EAP認証によって確立されたセキュア・チャネルを介して、下位識別子などのネットワーク・プロパティーのそれらの認識を比較することを意味します。 [RFC6677]のセクション4.1は、チャネルバインディングへの2つのアプローチを定義します。 EAP-Noobは最初のアプローチに従います。このアプローチに従います。このアプローチに従います。このアプローチに従います。このアプローチに従います。ここで、EAP実行中に積算されたキーで保護された整合性であるチャネルに関するネットワークとサーバー交換プレーンテキストより具体的には、チャネル情報はPlaintext PeerInfoオブジェクトとServerInfoオブジェクトで交換され、後でメッセージ認証コード（MACP、MAC、MACP2、およびMACS2）で検証されます。これにより、どちらの側でのローカルに知覚されるネットワークプロパティとのポリシーベースの比較も、デバッグ目的のロギングを可能にします。ピアは、EAP-NOOBアソシエーションとエクスポートされたキーにバインドしたいデータ項目をPeerInfoに含めることができます。これらは、認証者または無線ネットワークのSSIDやBSSIDなどのアクセスリンクのプロパティです（表6を参照）。 [RFC6677]のセクション4.3に記載されているように、チャネルバインディングの範囲は展開によって異なります。例えば、サーバは、ローカルエンタープライズネットワークからよりもローミングネットワークから利用可能なリンクレイヤ情報が少ない可能性があり、PeerInfoで受信したすべてのネットワークプロパティを検証できない可能性がある。ローミング中にServerInfoとPeerInfoの交換に関連するプライバシーに関する考慮事項もあります（6.10項を参照）。
Channel binding to secure channels, defined in [RFC5056], binds authentication at a higher protocol layer to a secure channel at a lower layer. Like most EAP methods, EAP-NOOB exports the session keys MSK and EMSK, and an outer tunnel or a higher-layer protocol can bind its authentication to these keys. Additionally, EAP-NOOB exports the key AMSK, which may be used to bind application-layer authentication to the secure channel created by EAP-NOOB and to the session keys MSK and EMSK.
[RFC5056]で定義されているセキュアチャネルへのチャネルバインディングは、より高いプロトコル層で認証を下位レイヤーで安全なチャネルにバインドします。ほとんどのEAPメソッドと同様に、EAP-NOOBはセッションキーMSKとEMSKをエクスポートし、外部トンネルまたは上位プロトコルはこれらのキーに認証をバインドできます。さらに、EAP-NoobはキーAMSKをエクスポートします。これは、アプリケーションレイヤ認証をEAP-NOOBによって作成されたセキュアチャネルとセッションキーMSKとEMSKにバインドするために使用できます。
While denial-of-service (DoS) attacks by on-link attackers cannot be fully prevented, the design goal in EAP-NOOB is to void long-lasting failure caused by an attacker who is present only temporarily or intermittently. The main defense mechanism is the persistent EAP-NOOB association, which is never deleted automatically due to in-band messages or error indications. Thus, the endpoints can always use the persistent association for reconnecting after the DoS attacker leaves the network. In this sense, the persistent association serves the same function in EAP-NOOB as a permanent primary key or certificate in other authentication protocols. We discuss logical attacks against the updates of the persistent association in Section 6.9.
オンリンク攻撃者によるサービス拒否（DOS）攻撃を十分に防ぐことはできませんが、EAP-Noobの設計目標は、一時的または断続的に存在している攻撃者によって引き起こされる長期的な失敗を無効にすることです。主な防衛メカニズムは、永続的なEAP-Noob協会です。これは、インバンドメッセージやエラー表示のために自動的に削除されることはありません。したがって、エンドポイントは、DOS攻撃者がネットワークを離れた後に再接続するために常に永続的な関連付けを使用することができます。この意味で、永続的アソシエーションは、他の認証プロトコルの恒久的な主キーまたは証明書としてEAP-NOOBの同じ機能を果たします。6.9の永続アソシエーションの更新に対する論理攻撃について説明します。
In addition to logical DoS attacks, it is necessary to consider resource exhaustion attacks against the EAP server. The number of persistent EAP-NOOB associations created in the server is limited by the need for a user to assist in delivering the OOB message. The users can be authenticated for the input or output of the OOB message at the EAP server, and any users who create excessive numbers of persistent associations can be held accountable and their associations can be deleted by the server administrator. What the attacker can do without user authentication is to perform the Initial Exchange repeatedly and create a large number of ephemeral associations (server in Waiting for OOB (1) state) without ever delivering the OOB message. In Section 6.4, it was suggested that the server should store the ephemeral states for at least a day. This may require off-loading the state storage from memory to disk during a DoS attack. However, if the server implementation is unable to keep up with a rate of Initial Exchanges performed by a DoS attacker and needs to drop some ephemeral states, no damage is caused to already-created persistent associations, and the honest users can resume registering new peers when the DoS attacker leaves the network.
論理DOS攻撃に加えて、EAPサーバーに対するリソースの枯渇攻撃を考慮する必要があります。サーバーで作成された永続的なEAP-Noob関連の数は、OOBメッセージの配信を支援するためのユーザーが必要とされる必要があります。ユーザーはEAPサーバーでOOBメッセージの入力または出力のために認証され、過度の永続的な関連付けを作成するユーザーを説明可能にし、それらの関連付けをサーバー管理者によって削除することができます。ユーザー認証なしで攻撃者ができることは、最初のExchangeを繰り返し実行し、OOBメッセージを配信することなく多数のエフェメラルアソシエーション（OOB（1）状態を待機中のサーバー）を作成することです。 6.4節では、サーバーが少なくとも1日の間にエフェメラル状態を保存する必要があることが示唆されました。これは、DOS攻撃の間にメモリからディスクへの状態ストレージをオフロードする必要があるかもしれません。ただし、サーバーの実装がDOS攻撃者によって実行され、一部の一時的な状態を落とす必要がある場合、損害は永続的な協会に損害を与えられていないため、損傷は発生しません。 DOS攻撃者がネットワークを離れるとき。
There are some trade-offs in the protocol design between politely backing off and giving way to DoS attackers. An on-link DoS attacker could spoof the SleepTime value in the Initial Exchange or Waiting Exchange to cause denial of service against a specific peer device. There is an upper limit on the SleepTime (3600 seconds) to mitigate the spoofing threat. This means that, in the presence of an on-link DoS attacker who spoofs the SleepTime, it could take up to one hour after the delivery of the OOB message before the device performs the Completion Exchange and becomes functional. Similarly, the Unwanted peer error (error code 2001) could cause the peer to stop connecting to the network. If the peer device is able to alert the user about the error condition, it can safely stop connecting to the server and wait for the user to trigger a reconnection attempt, e.g., by resetting the device. As mentioned in Section 3.6.2, peer devices that are unable to alert the user should continue to retry the Initial Exchange infrequently to avoid a permanent DoS condition. We believe a maximum backoff time of 3600 seconds is reasonable for a new protocol because malfunctioning or misconfigured peer implementations are at least as great a concern as DoS attacks, and politely backing off within some reasonable limits will increase the acceptance of the protocol. The maximum backoff times could be updated to be shorter as the protocol implementations mature.
丁寧にバックアップとDOS攻撃者への道を与えることの間のプロトコルデザインにいくつかのトレードオフがあります。オンリンクドDOS攻撃者は、最初の交換または待機交換の中継機器の値を、特定のピア装置に対してサービス拒否を引き起こす可能性があります。スプーフィング脅威を軽減するために、Sleeptime（3600秒）に上限があります。つまり、SELEPTIMEを偽装したオンリンクDOS攻撃者が存在する場合は、デバイスが完了Exchangeを実行して機能的になる前に、OOBメッセージの配信から1時間までかかる可能性があります。同様に、不要なピアエラー（エラーコード2001）は、ピアがネットワークへの接続を停止させる可能性があります。ピア装置がエラー状態についてユーザに警告することができる場合、それは安全にサーバへの接続を停止し、ユーザがデバイスをリセットすることによって、ユーザが再接続試行を起動するのを待つことができる。セクション3.6.2で述べたように、ユーザーに警告できないピアデバイスは、永続的なDOS条件を回避するために初めての交換を依然として再試行し続けるべきです。誤動作または誤ったピアの実装が少なくともDOS攻撃などの懸念があるため、最大のバックオフ時間が合理的なバックオフ時間が合理的であり、妥当な限界内で丁寧にバックアップされているため、プロトコルの受け入れが増えます。最大バックオフ時間は、プロトコル実装が成熟するにつれて短くなるように更新されます。
The EAP-NOOB Completion Exchange, as well as the Reconnect Exchange with cryptosuite update, results in a persistent state change that should take place either on both endpoints or on neither; otherwise, the result is a state mismatch that requires user action to resolve. The state mismatch can occur if the final EAP response of the exchanges is lost. In the Completion Exchange, the loss of the final response (Type=6) results in the peer moving to the Registered (4) state and creating a persistent EAP-NOOB association while the server stays in an ephemeral state (1 or 2). In the Reconnect Exchange, the loss of the final response (Type=9) results in the peer moving to the Registered (4) state and updating its persistent key material Kz while the server stays in the Reconnecting (3) state and keeps the old key material.
EAP-Noob補完交換、CryptoSuite Updateとの再接続Exchangeは、両方のエンドポイントまたはどちらのエンドポイントでも起こる必要がある永続状態の変更をもたらします。それ以外の場合、結果はユーザーのアクションを解決する必要がある状態の不一致です。州の不一致は、交換の最後のEAP応答が失われた場合に発生する可能性があります。完了した交換では、最終的な応答の損失（Type = 6）は、登録された（4）状態に移動し、サーバーが一時的な状態（1または2）に留まる間に登録された（4）状態に移行し、永続的なEAP-NOOB関連付けを作成します。再接続交換では、最終的な応答の損失（Type = 9）は、サーバーが再接続（3）状態に留まる間、登録されたピアが登録され、永続キー素材KZを更新し、その永続キー素材KZを更新し、古い状態に保ちます。主な素材
The state mismatch is an example of an unavoidable problem in distributed systems: it is theoretically impossible to guarantee synchronous state changes in endpoints that communicate asynchronously. The protocol will always have one critical message that may get lost, so that one side commits to the state change and the other side does not. In EAP, the critical message is the final response from the peer to the server. While the final response is normally followed by EAP-Success, [RFC3748], Section 4.2 states that the peer MAY assume that the EAP-Success was lost and the authentication was successful. Furthermore, EAP method implementations in the peer do not receive notification of the EAP-Success message from the parent EAP state machine [RFC4137]. For these reasons, EAP-NOOB on the peer side commits to a state change already when it sends the final response.
状態の不一致は、分散システムにおける避けられない問題の例である：非同期で通信エンドポイントでの同期状態の変化を保証することは理論的に不可能です。プロトコルは、常に1つの側は、状態変化にコミットし、他側はしないように迷子になることができる1つの重要なメッセージを、持っています。EAPにおいて、クリティカルメッセージは、サーバへのピアからの最終応答です。最終的な応答は、通常、EAP-成功、[RFC3748]に続いている間に、4.2節の状態は、ピアはEAP-成功が失われたと仮定することができることは、認証が成功しました。さらに、ピアにおけるEAPメソッドの実装は、親EAPステートマシン[RFC4137]からのEAP-Successメッセージの通知を受信しません。それが最終的な応答を送信するときにこれらの理由から、ピア側のEAP-NOOBは、すでに状態変化にコミットします。
The best available solution to the loss of the critical message is to keep trying. EAP retransmission behavior defined in Section 4.3 of [RFC3748] suggests 3-5 retransmissions. In the absence of an attacker, this would be sufficient to reduce the probability of failure to an acceptable level. However, a determined attacker on the in-band channel can drop the final EAP-Response message and all subsequent retransmissions. In the Completion Exchange (KeyingMode=0) and Reconnect Exchange with cryptosuite upgrade (KeyingMode=3), this could result in a state mismatch and persistent denial of service until the user resets the peer state.
重要なメッセージの紛失に対する最高の利用可能な解決策は、試み続けることです。[RFC3748]のセクション4.3に定義されているEAP再送信動作は、3-5の再送信を示唆しています。攻撃者が存在しない場合、これは許容可能なレベルへの失敗の可能性を減らすのに十分であろう。しかしながら、インバンドチャネル上の決定された攻撃者は、最終的なEAP応答メッセージおよびその後のすべての再送信をドロップすることができる。完了Exchange（KeyingMode = 0）とCryptoSuiteアップグレード（キーイングモード= 3）との再接続では、ユーザーがピアの状態をリセットするまで、状態の不一致と永続的なサービス拒否が発生する可能性があります。
EAP-NOOB implements its own recovery mechanism that allows unlimited retries of the Reconnect Exchange. When the DoS attacker eventually stops dropping packets on the in-band channel, the protocol will recover. The logic for this recovery mechanism is specified in Section 3.4.2.
EAP-Noobは、再接続交換の無制限の再試行を可能にする独自の回復メカニズムを実装しています。DOS攻撃者が最終的にインバンドチャネル上のパケットのドロップを停止すると、プロトコルは回復します。この回復メカニズムのロジックはセクション3.4.2で指定されています。
EAP-NOOB does not implement the same kind of retry mechanism in the Completion Exchange. The reason is that there is always a user involved in the initial association process, and the user can repeat the OOB Step to complete the association after the DoS attacker has left. On the other hand, Reconnect Exchange needs to work without user involvement.
EAP-Noobは、完了Exchangeに同じ種類のリトライメカニズムを実装しません。その理由は、初期協会プロセスに関与するユーザが常にあるため、DOS攻撃者が残った後にOOBステップを繰り返すことができる。一方、為替交換はユーザーの関与なしに機能する必要があります。
There are privacy considerations related to performing the Reconnect Exchange while roaming. The peer and server may send updated PeerInfo and ServerInfo fields in the Reconnect Exchange. This data is sent unencrypted between the peer and the EAP authenticator, such as a wireless access point. Thus, it can be observed by both outsiders and the access network. The PeerInfo field contains identifiers and other information about the peer device (see Table 6). While the information refers to the peer device and not directly to the user, it can leak information about the user to the access network and to outside observers. The ServerInfo, on the other hand, can leak information about the peer's affiliation with the home network. For this reason, the optional PeerInfo and ServerInfo in the Reconnect Exchange SHOULD be omitted unless some critical data has changed and it cannot be updated on the application layer.
ローミング中に再接続交換を実行することに関連するプライバシーに関する考慮事項があります。ピアとサーバーは、再接続Exchangeに更新されたPeerInfoフィールドとServerInfoフィールドを送信することがあります。このデータは、ピアとEAPオーセンティケータの間で無線アクセスポイントなどの暗号化されていない。したがって、それは部外器とアクセスネットワークの両方によって観察され得る。PeerInfoフィールドには、識別子とピアデバイスに関するその他の情報が含まれています（表6を参照）。情報は直接ユーザにはないため、ユーザに関する情報をアクセスネットワークおよび外部オブザーバに漏れることができる。一方、ServerInfoは、ホームネットワークとのピアの所属に関する情報をリークすることができます。このため、重要なデータが変更されていない限り、再接続ExchangeのオプションのPeerInfoとServerInfoは省略され、アプリケーション層では更新できません。
Peer devices that randomize their Layer 2 address to prevent tracking can do this whenever the user resets the EAP-NOOB association. During the lifetime of the association, the PeerId is a unique identifier that can be used to track the peer in the access network. Later versions of this specification may consider updating the PeerId at each Reconnect Exchange. In that case, it is necessary to consider how the authenticator and access-network administrators can recognize and add misbehaving peer devices to a deny list, as well as how to avoid loss of synchronization between the server and the peer if messages are lost during the identifier update.
レイヤ2アドレスをランダム化してトラッキングを防ぐピアデバイスは、ユーザーがEAP-NOOBアソシエーションをリセットするたびにこれを実行できます。関連付けの有効期間中、PeerIDはアクセスネットワーク内のピアを追跡するために使用できる一意の識別子です。この仕様の後のバージョンは、各再接続交換時のPeerIDを更新することを検討してもよい。その場合、オーセンティケータとアクセスネットワーク管理者が拒否リストに誤ってピアデバイスを認識して追加する方法、およびメッセージが失われた場合にサーバーとピアの間の同期の喪失を回避する方法を考慮する必要があります。識別子の更新
To enable stronger identity protection in later versions of EAP-NOOB, the optional server-assigned NAI (NewNAI) SHOULD have a constant username part. The RECOMMENDED username is "noob". The server MAY, however, send a different username in NewNAI to avoid username collisions within its realm or to conform to a local policy on usernames.
以降のバージョンのEAP-NOOBでより強いID保護を有効にするには、オプションのサーバーが割り当てられたNAI（Newnai）には、常時ユーザー名部分があるはずです。推奨されるユーザー名は "noob"です。ただし、サーバーは、そのレルム内のユーザー名の衝突を回避するため、またはユーザー名のローカルポリシーに準拠するために、Newnaiに異なるユーザー名を送信することができます。
EAP security claims are defined in Section 7.2.1 of [RFC3748]. The security claims for EAP-NOOB are listed in Table 13.
EAPセキュリティの請求は、[RFC3748]のセクション7.2.1で定義されています。EAP-NOOBのセキュリティクレームを表13に示します。
+=================+=================================================+
| Security | EAP-NOOB Claim |
| Property | |
+=================+=================================================+
| Authentication | ECDHE key exchange with out-of-band |
| mechanism | authentication |
+-----------------+-------------------------------------------------+
| Protected | yes |
| cryptosuite | |
| negotiation | |
+-----------------+-------------------------------------------------+
| Mutual | yes |
| authentication | |
+-----------------+-------------------------------------------------+
| Integrity | yes |
| protection | |
+-----------------+-------------------------------------------------+
| Replay | yes |
| protection | |
+-----------------+-------------------------------------------------+
| Confidentiality | no |
+-----------------+-------------------------------------------------+
| Key derivation | yes |
+-----------------+-------------------------------------------------+
| Key strength | The specified cryptosuites provide |
| | key strength of at least 128 bits. |
+-----------------+-------------------------------------------------+
| Dictionary | yes |
| attack | |
| protection | |
+-----------------+-------------------------------------------------+
| Fast reconnect | yes |
+-----------------+-------------------------------------------------+
| Cryptographic | not applicable |
| binding | |
+-----------------+-------------------------------------------------+
| Session | yes |
| independence | |
+-----------------+-------------------------------------------------+
| Fragmentation | no |
+-----------------+-------------------------------------------------+
| Channel binding | yes (The ServerInfo and PeerInfo can |
| | be used to convey integrity-protected |
| | channel properties, such as network |
| | SSID or peer MAC address.) |
+-----------------+-------------------------------------------------+
Table 13: EAP Security Claims
表13：EAPセキュリティの主張
[EUI-48] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture", DOI 10.1109/IEEESTD.2014.6847097, IEEE Standard 802-2014, June 2014, <https://doi.org/10.1109/IEEESTD.2014.6847097>.
[EUI-48] IEEE、「地元と首都圏ネットワークのためのIEEE規格：概要と建築」、DOI 10.1109 / IEEESTD.2014.6847097、IEEE規格802-2014、2014年6月、<https：//doi.org/10.1109/ieeeestd.2014.6847097>。
[FIPS186-4] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", DOI 10.6028/NIST.FIPS.186-4, FIPS 186-4, July 2013, <https://doi.org/10.6028/NIST.FIPS.186-4>.
[FIPS186-4]国立標準技術研究所（NIST）、「デジタルシグネチャスタンダード（DSS）」、DOI 10.6028 / NIST.FIPS.186-4、FIPS 186-4、2013年7月、<HTTPS：// DOI。ORG / 10.6028 / NIST.FIPS.186-4>。
[NIST-DH] Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Davis, "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography", DOI 10.6028/NIST.SP.800-56Ar3, NIST Special Publication 800-56A Revision 3, April 2018, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-56Ar3.pdf>.
[NIST-DH] Barker、E.、Chen、L.、Roginsky、A.、Vassilev、A.、R.Davis、「離散対数暗号化を用いたペアワイズ鍵確立方式の推奨」、DOI 10.6028 / NIST.SP.800-56AR3、NIST特別発表800-56Aリビジョン3、<https：//nvlpubs.nist.gov/nistpubs/specialPublications/ Nist.Sp.800-56ar3.pdf>。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.
[RFC2104] Krawczyk、H.、Belleare、M.、およびR. Canetti、 "HMAC：メッセージ認証のための鍵付きハッシング"、RFC 2104、DOI 10.17487 / RFC2104、1997年2月、<https：//www.rfc-編集者.org / info / rfc2104>。
[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>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/info/rfc3748>.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、ED。、「拡張認証プロトコル（EAP）」、RFC 3748、DOI 10.17487 / RFC3748、2004年6月<https：//www.rfc-editor.org/info/rfc3748>。
[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>.
[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<https：//www.rfc-editor.org/info/rfc4648>。
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, DOI 10.17487/RFC5247, August 2008, <https://www.rfc-editor.org/info/rfc5247>.
[RFC5247] Aboba、B.、Simon、D.、およびP.Eronen、「拡張認証プロトコル（EAP）キー管理フレームワーク」、RFC 5247、DOI 10.17487 / RFC5247、2008年8月、<https：//www.rfc-editor.org/info/rfc5247>。
[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>.
[RFC6234]イーストレイク3RD、D.およびT.ハンセン、「米国セキュアハッシュアルゴリズム（SHAおよびSHAベースのHMACおよびHKDF）」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<https：///www.rfc-editor.org/info/rfc6234>。
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <https://www.rfc-editor.org/info/rfc7517>.
[RFC7517] Jones、M.、 "JSON Webキー（JWK）"、RFC 7517、DOI 10.17487 / RFC7517、2015年5月、<https：//www.rfc-editor.org/info/rfc7517>。
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <https://www.rfc-editor.org/info/rfc7518>.
[RFC7518] Jones、M.、 "JSON Web Algorithms（JWA）"、RFC 7518、DOI 10.17487 / RFC7518、<https：//www.rfc-editor.org/info/rfc7518>。
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, <https://www.rfc-editor.org/info/rfc7542>.
[RFC7542] Dekok、A。、「ネットワークアクセス識別子」、RFC 7542、DOI 10.17487 / RFC7542、<https：//www.rfc-editor.org/info/rfc7542>。
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC7748] Langley、A.、Hamburg、M.、およびS.ターナー、「セキュリティのための楕円曲線」、RFC 7748、DOI 10.17487 / RFC7748、2016年1月、<https：//www.rfc-editor.org/info/ RFC7748>。
[RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, <https://www.rfc-editor.org/info/rfc8037>.
[RFC8037] Liusvaara、I。、「CFRG楕円曲線Diffie-Hellman（ECDH）およびJSONオブジェクト署名および暗号化（JoSE）」、RFC 8037、DOI 10.17487 / RFC8037、2017年1月、<https：//ww.rfc-editor.org/info/rfc8037>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www.rfc-editor.org / info / rfc8126>。
[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>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T.、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https://www.rfc-editor.org/ info / rfc8259>。
[Bluetooth] Bluetooth Special Interest Group, "Bluetooth Core Specification Version 5.3", July 2021, <https://www.bluetooth.com/specifications/bluetooth-core-specification>.
[Bluetooth] Bluetooth特別興味グループ「Bluetooth Core Specification Version 5.3」、<https：//www.bluetooth.com/specifications/bluetooth-core-specification>。
[IEEE-802.1X] IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Port-Based Network Access Control", IEEE Standard 802.1X-2020, February 2020.
[IEEE-802.1X] IEEE、「地域およびメトロポリタンエリアネットワーク - ポートベースネットワークアクセス制御」、IEEE規格802.1X-2020、2020年2月。
[RATS-EAT] Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity Attestation Token (EAT)", Work in Progress, Internet-Draft, draft-ietf-rats-eat-11, 24 October 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat-11>.
[ラット]ルンドブレード、L.、マンディアム、G.、J.O'Donoghue、「エンティティ認証トークン（ETERTESTATION TOKEN（ETESTATION TOKEN（ET）」、進行中の作業、インターネットドラフト、Draft-IETF-RATF-EAT-11、2021年10月24日、<https://datatracker.ietf.org/doc/html/draft-ietf-ratseat-11>。
[RFC2904] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, G., de Bruijn, B., de Laat, C., Holdrege, M., and D. Spence, "AAA Authorization Framework", RFC 2904, DOI 10.17487/RFC2904, August 2000, <https://www.rfc-editor.org/info/rfc2904>.
[RFC2904] Vollbrecht、J.、Calhoun、P.、Farrell、S.、Gommans、L.、Gross、G.、De Bruijn、B.、De Laat、C.、Holdrege、M.、D. Spence、「AAA認証フレームワーク」、RFC 2904、DOI 10.17487 / RFC2904、2000年8月、<https：//www.rfc-editor.org/info/rfc2904>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Field、R.、およびL.Masinter、 "Uniform Resource Identifier（URI）：汎用構文"、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, "State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator", RFC 4137, DOI 10.17487/RFC4137, August 2005, <https://www.rfc-editor.org/info/rfc4137>.
[RFC4137] Vollbrecht、J.、Eronen、P.、Petroni、N.、およびY。OHBA、「伸縮認証プロトコル（EAP）ピアおよびオーセンティケータ用状態機械」、RFC 4137、DOI 10.17487 / RFC4137、2005年8月、<https://www.rfc-editor.org/info/rfc4137>。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007, <https://www.rfc-editor.org/info/rfc5056>.
[RFC5056] Williams、N.、「保護チャネルへのチャネルバインディングの使用」、RFC 5056、DOI 10.17487 / RFC5056、2007年11月、<https：//www.rfc-editor.org/info/rfc5056>。
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, <https://www.rfc-editor.org/info/rfc5216>.
[RFC5216] Simon、D.、Aboba、B.およびR. Hurst、「EAP-TLS認証プロトコル」、RFC 5216、DOI 10.17487 / RFC5216、2008年3月、<https：//www.rfc-editor.org/ info / rfc5216>。
[RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012, <https://www.rfc-editor.org/info/rfc6677>.
[RFC6677] Hartman、S.、Ed。、Clancy、T.、およびK。HOEPER、「拡張認証プロトコル（EAP）方法のためのチャネルバインディングサポート」、RFC 6677、DOI 10.17487 / RFC6677、2012年7月、<https：//www.rfc-editor.org/info/rfc6677>。
[Sethi14] Sethi, M., Oat, E., Di Francesco, M., and T. Aura, "Secure bootstrapping of cloud-managed ubiquitous displays", Proceedings of ACM International Joint Conference on Pervasive and Ubiquitous Computing (UbiComp 2014), pp. 739-750, Seattle, USA, DOI 10.1145/2632048.2632049, September 2014, <http://dx.doi.org/10.1145/2632048.2632049>.
[Sethi14] Sethi、M.、Oat、E.、Di Francesco、M.、およびT. Aura、「クラウドマネージドユビキタスディスプレイのセキュアブートストラップ」、Pervasiveおよびユビキタスコンピューティングに関するACM国際共同会議（UBICOMP 2014）、PP。739-750、シアトル、アメリカ、DOI 10.1145 / 2632048.2632049、2014年9月、<http://dx.doi.org/10.1145/2632048.2632049>。
[Sethi19] Sethi, M., Peltonen, A., and T. Aura, "Misbinding Attacks on Secure Device Pairing and Bootstrapping", DOI 10.1145/3321705.3329813, February 2019, <https://arxiv.org/abs/1902.07550>.
[Sethi19] Sethi、M.、Peltonen、A.およびT.Aura、「安全なデバイスペアリングとブートストラップに対する誤解攻撃」、DOI 10.1145 / 3321705.3329813、2019年2月、<https：//arxiv.org/abs/1902.07550>。
[TLS-CWT] Tschofenig, H. and M. Brossard, "Using CBOR Web Tokens (CWTs) in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, Internet-Draft, draft-tschofenig-tls-cwt-02, 13 July 2020, <https://datatracker.ietf.org/doc/html/draft-tschofenig-tls-cwt-02>.
[TLS-CWT] TSCHOFENIG、H。およびM. BROSSARD、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）」の「CBOR WEBトークン（CWTS）」、進行中の作業、インターネットドラフト、ドラフトTSCHOFENIG-tls-cwt-02,2020,13 <https://datatracker.ietf.org/doc/html/draft-tchofenig-tls-cwt-02>
Table 14 shows how the EAP server chooses the exchange type depending on the server and peer states. In the state combinations marked with hyphen "-", there is no possible exchange and user action is required to make progress. Note that peer state 4 is omitted from the table because the peer never connects to the server when the peer is in that state. The table also shows the handling of errors in each exchange. A notable detail is that the recipient of error code 2003 moves to state 1.
表14は、サーバーとピアの状態に応じてEAPサーバーがExchangeタイプを選択する方法を示しています。ハイフン「 - 」とマークされている状態の組み合わせでは、取り替えやユーザの処置は進行するために必要な場合は利用できません。ピアがその状態にあるときにピアがサーバに接続されないため、ピア状態4はテーブルから省略されていることに注意してください。表には、各交換のエラーの処理も示します。注目すべき詳細は、エラーコード2003の受信者が状態1に移動することである。
+=============+===============================+==================+
| Peer States | Exchange Chosen by the Server | Next Peer and |
| | | Server States |
+=============+===============================+==================+
| Server State: Unregistered (0) |
+-------------+-------------------------------+------------------+
| 0..2 | Initial Exchange | both 1 (0 on |
| | | error) |
+-------------+-------------------------------+------------------+
| 3 | - | no change, |
| | | notify user |
+-------------+-------------------------------+------------------+
| Server State: Waiting for OOB (1) |
+-------------+-------------------------------+------------------+
| 0 | Initial Exchange | both 1 (0 on |
| | | error) |
+-------------+-------------------------------+------------------+
| 1 | Waiting Exchange | both 1 (no |
| | | change on error) |
+-------------+-------------------------------+------------------+
| 2 | Completion Exchange | both 4 (A) |
+-------------+-------------------------------+------------------+
| 3 | - | no change, |
| | | notify user |
+-------------+-------------------------------+------------------+
| Server State: OOB Received (2) |
+-------------+-------------------------------+------------------+
| 0 | Initial Exchange | both 1 (0 on |
| | | error) |
+-------------+-------------------------------+------------------+
| 1 | Completion Exchange | both 4 (B) |
+-------------+-------------------------------+------------------+
| 2 | Completion Exchange | both 4 (A) |
+-------------+-------------------------------+------------------+
| 3 | - | no change, |
| | | notify user |
+-------------+-------------------------------+------------------+
| Server State: Reconnecting (3) or Registered (4) |
+-------------+-------------------------------+------------------+
| 0..2 | - | no change, |
| | | notify user |
+-------------+-------------------------------+------------------+
| 3 | Reconnect Exchange | both 4 (3 on |
| | | error) |
+-------------+-------------------------------+------------------+
Table 14: How the Server Chooses the Exchange Type
表14：サーバーがExchangeタイプを選択する方法
(A) peer to 1 on error 2003; no other changes on error
（a）エラー2003でピアツーピング。エラーの他の変更はありません
(B) server to 1 on error 2003; no other changes on error
（b）エラー2003でサーバ1へのサーバ。エラーの他の変更はありません
Table 15 lists the local events that can take place in the server or peer. Both the server and peer output and accept OOB messages in association state 1, leading the receiver to state 2. Communication errors and timeouts in states 0..2 lead back to state 0, while similar errors in states 3..4 lead to state 3. An application request for rekeying (e.g., to refresh session keys or to upgrade cryptosuite) also takes the association from state 3..4 to state 3. The user can always reset the association state to 0. Recovering association data, e.g., from a backup, leads to state 3.
表15に、サーバーまたはピアで発生する可能性があるローカルイベントを示します。サーバーとピア出力の両方がアソシエーション状態1でOOBメッセージを共有し、受信側を先導するために、受信側2をリードする2.状態0..2状態0にリードします。3. REKINCYのアプリケーション要求（たとえば、セッションキーを更新するか、またはCryptoSuiteをアップグレードするために）は、状態3..4から状態3との関連付けも取り除くことができる。ユーザは常に関連付け状態を0にリセットすることができる。バックアップから、状態3につながります。
+===================+========================+=========+
| Server/Peer State | Possible Local Events | Next |
| | in the Server and Peer | State |
+===================+========================+=========+
| 1 | OOB Output | 1 |
+-------------------+------------------------+---------+
| 1 | OOB Input | 2 (1 on |
| | | error) |
+-------------------+------------------------+---------+
| 0..2 | Mobility/timeout/ | 0 |
| | network failure | |
+-------------------+------------------------+---------+
| 3..4 | Mobility/timeout/ | 3 |
| | network failure | |
+-------------------+------------------------+---------+
| 3..4 | Rekeying request | 3 |
+-------------------+------------------------+---------+
| 0..4 | User resets | 0 |
| | association | |
+-------------------+------------------------+---------+
| 0..4 | Association state | 3 |
| | recovery | |
+-------------------+------------------------+---------+
Table 15: Local Events in the Server and Peer
表15：サーバーとピアのローカルイベント
Table 16 lists OOB channel parameters that need to be specified in each application that makes use of EAP-NOOB. The list is not exhaustive and is included for the convenience of implementers only.
表16に、EAP-NOOBを使用する各アプリケーションで指定する必要があるOOBチャネルパラメータを示します。リストは網羅的なものではなく、実装者のみの便宜のために含まれています。
+====================+=========================================+
| Parameter | Description |
+====================+=========================================+
| OobDirs | Allowed directions of the OOB channel. |
+--------------------+-----------------------------------------+
| OobMessageEncoding | How the OOB message data fields are |
| | encoded for the OOB channel. |
+--------------------+-----------------------------------------+
| SleepTimeDefault | Default minimum time in seconds that |
| | the peer should sleep before the next |
| | Waiting Exchange. |
+--------------------+-----------------------------------------+
| OobRetries | Number of received OOB messages with |
| | invalid Hoob, after which the receiver |
| | moves to Unregistered (0) state. When |
| | the OOB channel has error detection or |
| | correction, the RECOMMENDED value is 5. |
+--------------------+-----------------------------------------+
| NoobTimeout | How many seconds the sender of the OOB |
| | message remembers the sent Noob value. |
| | The RECOMMENDED value is 3600 seconds. |
+--------------------+-----------------------------------------+
| ServerInfoType | The value of the Type field and the |
| | other required fields in ServerInfo. |
+--------------------+-----------------------------------------+
| PeerInfoType | The value of the Type field and the |
| | other required fields in PeerInfo. |
+--------------------+-----------------------------------------+
Table 16: OOB Channel Characteristics
表16：OOBチャネルの特性
AAA architectures [RFC2904] allow for roaming of network-connected appliances that are authenticated over EAP. While the peer is roaming in a visited network, authentication still takes place between the peer and an authentication server at its home network. EAP-NOOB supports such roaming by allowing the server to assign a NAI to the peer. After the NAI has been assigned, it enables the visited network to route the EAP session to the peer's home AAA server.
AAAアーキテクチャ[RFC2904] EAP上で認証されているネットワーク接続機器のローミングを可能にします。ピアは訪問先ネットワークでローミングしている間、認証はまだそのホームネットワークでピアと認証サーバーの間で行われます。EAP-Noobは、サーバーがPeerにNAIを割り当てることを可能にすることで、そのようなローミングをサポートします。NAIが割り当てられた後、訪問先ネットワークはEAPセッションをピアのHome AAAサーバにルーティングすることができます。
A peer device that is new or has gone through a hard reset should be connected first to the home network and establish an EAP-NOOB association with its home AAA server before it is able to roam. After that, it can perform the Reconnect Exchange from the visited network.
ハードリセットを通して新規であるか、またはハードリセットを実行しているピア装置は、まずホームネットワークに接続され、それがローミングする前にそのホームAAAサーバとのEAP-NOOBアソシエーションを確立する必要があります。その後、訪問先ネットワークから再接続交換を実行できます。
Alternatively, the device may provide some method for the user to configure the NAI of the home network. This is the user or application-configured NAI mentioned in Section 3.3.1. In that case, the EAP-NOOB association can be created while roaming. The configured NAI enables the EAP messages to be routed correctly to the home AAA server.
あるいは、装置は、ホームネットワークのNAIを構成するためのユーザに何らかの方法を提供することができる。これは、セクション3.3.1で述べられたユーザーまたはアプリケーション構成NAIです。その場合は、ローミング中にEAP-NOOB関連付けを作成できます。設定されたNAIにより、EAPメッセージをホームAAAサーバに正しくルーティングすることができます。
While roaming, the device needs to identify the networks where the EAP-NOOB association can be used to gain network access. For 802.11 access networks, the server MAY send a list of SSID strings in the ServerInfo field, called either SSIDList or Base64SSIDList. The list is formatted as explained in Table 6. If present, the peer MAY use this list as a hint to determine the networks where the EAP-NOOB association can be used for access authorization, in addition to the access network where the Initial Exchange took place.
ローミング中、デバイスは、EAP-NOOBアソシエーションを使用してネットワークアクセスを得ることができるネットワークを識別する必要があります。802.11アクセスネットワークの場合、サーバーはSSIDListまたはBase64SSidListと呼ばれるSSID文字列のSSID文字列のリストを送信することができます。リストは表6で説明されているようにフォーマットされています。場所。
While EAP-NOOB does not mandate any particular OOB communication channel, typical OOB channels include graphical displays and emulated NFC tags. In the peer-to-server direction, it may be convenient to encode the OOB message as a URL, which is then encoded as a QR code for displays and printers or as an NFC Data Exchange Format (NDEF) record for dynamic NFC tags. A user can then simply scan the QR code or NFC tag and open the URL, which causes the OOB message to be delivered to the authentication server. The URL MUST specify https or another server-authenticated scheme so that there is a secure connection to the server and the on-path attacker cannot read or modify the OOB message.
EAP-NOOBは特定のOOB通信チャネルを義務付けていませんが、一般的なOOBチャネルにはグラフィカル・ディスプレイとエミュレートNFCタグが含まれます。同輩からサーバ方向に、OOBメッセージをURLとして符号化することが便利であり得、次にディスプレイおよびプリンタのQRコードとして、または動的NFCタグのNFCデータ交換フォーマット（NDEF）レコードとして符号化される。その後、ユーザは単にQRコードまたはNFCタグをスキャンしてURLを開くことができ、これによりOOBメッセージが認証サーバに配信される。サーバーへの安全な接続があるように、URLはHTTPSまたは別のサーバー認証スキームを指定し、OOBメッセージを読み取ったり変更することはできません。
The ServerInfo in this case includes a field called ServerURL of the following format with a RECOMMENDED length of at most 60 characters:
この場合のServerInfoには、次の形式のServerURLと呼ばれるフィールドが含まれています。
https://<host>[:<port>]/[<path>]
To this, the peer appends the OOB message fields (PeerId, Noob, and Hoob) as a query string. PeerId is provided to the peer by the server and might be a 22-character ASCII string. The peer base64url encodes, without padding, the 16-byte values Noob and Hoob into 22-character ASCII strings. The query parameters MAY be in any order. The resulting URL is of the following format:
これに、ピアは、クエリ文字列としてOOBメッセージフィールド（PeerID、Noob、およびHoob）を追加します。PeerIDはサーバーによってピアに提供され、22文字のASCII文字列である可能性があります。ピアBase64URLは、パディングなしで、16バイトの値NOOBとHOOBを22文字のASCII文字列にエンコードします。クエリパラメータは任意の順序であり得る。結果のURLは次の形式です。
https://<host>[:<port>]/[<path>]?P=<PeerId>&N=<Noob>&H=<Hoob>
The following is an example of a well-formed URL encoding the OOB message (without line breaks):
以下は、OOBメッセージをエンコードする整形式のURLの例です（ラインブレークなし）。
https://aaa.example.com/eapnoob?P=mcm5BSCDZ45cYPlAr1ghNw&N=rMinS0-F4E
fCU8D9ljxX_A&H=QvnMp4UGxuQVFaXPW_14UW
Acknowledgments
謝辞
Max Crone, Shiva Prasad TP, and Raghavendra MS implemented parts of this protocol with wpa_supplicant and hostapd. Eduardo Inglés and Dan Garcia-Carrillo were involved in the implementation of this protocol on Contiki. Their inputs helped us in improving the specification.
Max Crone、Shiva Prasad TP、およびRaghavendra MSは、このプロトコルの一部をWPA_SupplicantとHostApdで実装しました。EduardoInglésとDan Garcia-Carrilloは、Contikiに関するこのプロトコルの実施に関わっていました。彼らの入力は仕様の改善の上で私たちを助けました。
The authors would like to thank Rhys Smith and Josh Howlett for providing valuable feedback, as well as new use cases and requirements for the protocol. Thanks to Eric Rescorla, Alan Dekok, Darshak Thakore, Stefan Winter, Hannes Tschofenig, Daniel Migault, Roman Danyliw, Benjamin Kaduk, Francesca Palombini, Steve Hanna, Lars Eggert, and Éric Vyncke for their comments and reviews.
著者らは、貴重なフィードバックを提供するためにRhys SmithとJosh Howlettに、そしてプロトコルのための新しいユースケースと要件に感謝します。Eric Rescorla、Alan Dekok、Darshak Thakore、Stefan Winter、Hannes Tschofenig、Daniel Migault、Roman Danyliw、Benjamin Kaduk、Francesca Palombini、Steve Hanna、Lars Eggert、およびコメントやレビューのためのÉricVyncke。
We would also like to express our sincere gratitude to Dave Thaler for his thorough review of the document.
私たちはまた、文書の徹底的なレビューのためにDave Thalerに私たちの誠実な感謝を表現したいと思います。
Authors' Addresses
著者の住所
Tuomas Aura Aalto University FI-00076 Aalto Finland
Tuomas Aura Aalto Universy FI-00076アロトフィンランド
Email: tuomas.aura@aalto.fi
Mohit Sethi Ericsson FI-02420 Jorvas Finland
Mohit Sethi Ericsson FI-02420 Jorvas Finland
Email: mohit@iki.fi
Aleksi Peltonen Aalto University FI-00076 Aalto Finland
Aleksi Peltonen Aalto University FI-00076アロトフィンランド
Email: aleksi.peltonen@aalto.fi