Internet Engineering Task Force (IETF) O. Friel
Request for Comments: 9966 Cisco
Category: Standards Track D. Harkins
ISSN: 2070-1721 Hewlett-Packard Enterprise
May 2026
This document defines a mechanism that enables a bootstrapping device to establish trust and mutually authenticate against a TLS server. Bootstrapping devices have a public/private key pair; this mechanism enables a TLS server to prove to the device that it knows the public key and enables the device to prove to the TLS server that it knows the private key. The mechanism leverages existing Device Provisioning Profile (DPP) and TLS standards and can be used in an Extensible Authentication Protocol (EAP) exchange with an EAP server.
この文書では、ブートストラップ デバイスが信頼を確立し、TLS サーバーに対して相互認証できるようにするメカニズムを定義します。ブートストラップ デバイスには公開キーと秘密キーのペアがあります。このメカニズムにより、TLS サーバーは公開キーを知っていることをデバイスに証明でき、デバイスは TLS サーバーに秘密キーを知っていることを証明できます。このメカニズムは既存のデバイス プロビジョニング プロファイル (DPP) および TLS 標準を利用しており、EAP サーバーとの拡張認証プロトコル (EAP) 交換で使用できます。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9966.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9966 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Terminology
1.2. Bootstrapping Overview
1.3. EAP Network Access
1.4. Supported EAP Methods
2. Bootstrap Key
2.1. Alignment with Wi-Fi Alliance Device Provisioning Profile
3. Bootstrapping in TLS 1.3
3.1. EPSK Derivation
3.2. TLS 1.3 Handshake Details
4. Using TLS Bootstrapping in EAP
5. IANA Considerations
6. Implementation Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Test Vectors
A.1. Test Vector 1: prime256v1
A.2. Test Vector 2: secp384r1
A.3. Test Vector 3: secp521r1
A.4. Test Vector 4: brainpoolP256r1
Authors' Addresses
Onboarding devices with no, or limited, user interface can be difficult. Sometimes a credential is needed to access a network based on [IEEE8802.1x] or EAP, and network connectivity is needed to obtain a credential. This poses a challenge for onboarding devices.
ユーザー インターフェイスがないか、ユーザー インターフェイスが制限されているデバイスのオンボーディングは困難な場合があります。[IEEE8802.1x] または EAP に基づくネットワークにアクセスするには資格情報が必要になる場合があり、資格情報を取得するにはネットワーク接続が必要です。これは、デバイスのオンボーディングに課題をもたらします。
If a device has a public/private key pair, and trust in the integrity of a device's public key can be obtained in an out-of-band fashion, a device can be authenticated and provisioned with a usable credential for [IEEE8802.1x] / EAP-based network access. While this authentication can be strong, the device's authentication of the network is somewhat weaker. [DUCKLING] presents a functional security model to address this asymmetry.
デバイスに公開キーと秘密キーのペアがあり、デバイスの公開キーの整合性に対する信頼を帯域外方式で取得できる場合、デバイスを認証し、[IEEE8802.1x] / EAP ベースのネットワーク アクセスに使用可能な資格情報をプロビジョニングできます。この認証は強力ですが、デバイスのネットワーク認証は多少弱くなります。[DUCKLING] は、この非対称性に対処するための機能的セキュリティ モデルを提示しています。
Device onboarding protocols such as the Device Provisioning Profile [DPP], also referred to as Wi-Fi Easy Connect, address this use case, but they have drawbacks. For instance, [DPP] does not support wired network access and does not specify how the device's DPP key pair can be used in a TLS handshake. This document describes an authentication mechanism that a device can use to mutually authenticate against a TLS server and describes how that authentication protocol can be used in an EAP exchange for wired network access as described in [IEEE8802.1x]. This protocol is called "TLS Proof of Knowledge" or "TLS-POK".
Wi-Fi Easy Connect とも呼ばれるデバイス プロビジョニング プロファイル [DPP] などのデバイス オンボーディング プロトコルは、この使用例に対処しますが、欠点もあります。たとえば、[DPP] は有線ネットワーク アクセスをサポートしておらず、TLS ハンドシェイクでデバイスの DPP キー ペアを使用する方法を指定していません。この文書では、デバイスが TLS サーバーに対して相互認証するために使用できる認証メカニズムについて説明し、[IEEE8802.1x] で説明されている有線ネットワーク アクセスの EAP 交換でその認証プロトコルをどのように使用できるかについて説明します。このプロトコルは「TLS Proof of Knowledge」または「TLS-POK」と呼ばれます。
This document does not address the problem of wireless network discovery, where a bootstrapping device detects multiple different wireless networks and needs a more robust and scalable mechanism than simple round-robin to determine the correct network to attach to. DPP addresses this issue for Wi-Fi, but DPP's discovery will not work on a wired [IEEE8802.1x] ethernet port, but TLS-POK will. Therefore, TLS-POK SHOULD NOT be used for bootstrapping against wireless networks and SHOULD be used for bootstrapping against wired networks.
このドキュメントでは、ワイヤレス ネットワーク検出の問題については扱っていません。この問題では、ブートストラップ デバイスが複数の異なるワイヤレス ネットワークを検出し、接続する正しいネットワークを決定するために、単純なラウンドロビンよりも堅牢でスケーラブルなメカニズムが必要です。DPP は Wi-Fi に関するこの問題に対処しますが、DPP の検出は有線 [IEEE8802.1x] イーサネット ポートでは機能しませんが、TLS-POK は機能します。したがって、TLS-POK は無線ネットワークに対するブートストラップには使用すべきではなく、有線ネットワークに対するブートストラップには使用すべきです。
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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
The following terminology is used throughout this document.
このドキュメントでは次の用語が使用されます。
802.1X:
802.1X:
IEEE Port-Based Network Access Control [IEEE8802.1x]
IEEE ポートベースのネットワーク アクセス制御 [IEEE8802.1x]
BSK:
BSK:
Bootstrap Key, which is an elliptic curve public/private key pair from a cryptosystem suitable for doing ECDSA
ブートストラップ キー。ECDSA の実行に適した暗号システムからの楕円曲線の公開キーと秘密キーのペアです。
DPP:
DPP:
Device Provisioning Profile [DPP]
デバイス プロビジョニング プロファイル [DPP]
EAP:
EAP:
Extensible Authentication Protocol [RFC3748]
拡張可能な認証プロトコル [RFC3748]
EC:
EC:
Elliptic Curve
楕円曲線
ECDSA:
ECDSA:
Elliptic Curve Digital Signature Algorithm
楕円曲線デジタル署名アルゴリズム
EPSK:
EPSK:
External Pre-Shared Key
外部事前共有キー
EST:
EST:
Enrollment over Secure Transport [RFC7030]
安全なトランスポートを介した登録 [RFC7030]
NAI:
NAI:
Network Access Identifier
ネットワークアクセス識別子
PSK:
PSK:
Pre-Shared Key
事前共有キー
TEAP:
ティープ:
Tunnel Extensible Authentication Protocol [RFC9930]
トンネル拡張可能認証プロトコル [RFC9930]
A bootstrapping device holds a public/private Elliptic Curve (EC) key pair, which this document refers to as a "Bootstrap Key" (or "BSK"). The private key of the BSK is known only by the device. The public key of the BSK is:
ブートストラップ デバイスは、公開/秘密楕円曲線 (EC) キーのペアを保持します。このドキュメントでは、これを「ブートストラップ キー」(または「BSK」) と呼びます。BSK の秘密キーはデバイスのみが知っています。BSK の公開キーは次のとおりです。
* known by the device,
* デバイスによって認識される、
* known by the owner or holder of the device, and
* デバイスの所有者または所有者が知っている、および
* provisioned on the TLS server by the TLS server operator.
* TLS サーバー オペレーターによって TLS サーバー上にプロビジョニングされます。
In order to establish trust and mutually authenticate, the TLS server proves to the device that it knows the public part of the BSK, and the device proves to the TLS server that it knows the private part of the BSK. More details on the BSK are given in Section 2.
信頼を確立して相互認証するために、TLS サーバーは BSK のパブリック部分を知っていることをデバイスに証明し、デバイスは TLS サーバーに BSK のプライベート部分を知っていることを証明します。BSK の詳細についてはセクション 2 で説明します。
The TLS server could be an EAP server for 802.1X network access or could, for example, be an Enrollment over Secure Transport (EST) [RFC7030] server. In the case of authentication against an EAP server, the EAP server SHOULD provision the device with a credential that it uses for subsequent EAP authentication.
TLS サーバーは、802.1X ネットワーク アクセス用の EAP サーバーである場合もあれば、たとえば Enrollment over Secure Transport (EST) [RFC7030] サーバーである場合もあります。EAP サーバーに対する認証の場合、EAP サーバーは、後続の EAP 認証に使用する資格情報をデバイスにプロビジョニングする必要があります (SHOULD)。
Enterprise deployments typically require an 802.1X / EAP-based authentication to obtain network access. Protocols like Enrollment over Secure Transport (EST) [RFC7030] can be used to enroll devices with a Certification Authority to allow them to authenticate using 802.1X / EAP. This creates a problem for bootstrapping devices where a certificate is needed for EAP authentication and 802.1X network access is needed to obtain a certificate.
エンタープライズ展開では通常、ネットワーク アクセスを取得するために 802.1X / EAP ベースの認証が必要です。Enrollment over Secure Transport (EST) [RFC7030] のようなプロトコルを使用して、デバイスを認証局に登録し、802.1X / EAP を使用して認証できるようにすることができます。これにより、EAP 認証に証明書が必要であり、証明書を取得するために 802.1X ネットワーク アクセスが必要なデバイスのブートストラップで問題が発生します。
Devices whose BSK public key can be obtained in an out-of-band fashion and provisioned on the EAP server can authenticate with the EAP server using the mechanism defined in Sections 3 and 4. This network connectivity can then be used to perform an enrollment protocol (such as provided by [RFC9930]) to obtain a credential for subsequent EAP authentication. Certificate lifecycle management may also be performed in subsequent TEAP transactions.
BSK 公開鍵を帯域外方式で取得し、EAP サーバー上でプロビジョニングできるデバイスは、セクション 3 および 4 で定義されたメカニズムを使用して EAP サーバーで認証できます。このネットワーク接続を使用して、登録プロトコル ([RFC9930] で提供されるものなど) を実行し、後続の EAP 認証のための資格情報を取得できます。証明書のライフサイクル管理は、後続の TEAP トランザクションでも実行される場合があります。
This document defines a bootstrapping mechanism that results in a certificate being provisioned on a device that can be used for subsequent EAP authentication. Therefore, an EAP method supporting the provisioning of a certificate on a device is required. The only EAP method that currently supports provisioning of a certificate on a device is TEAP; therefore, this document assumes that TEAP is the only supported EAP method. Section 4 describes how TLS-POK is used with TEAP, including defining a suitable NAI.
このドキュメントでは、後続の EAP 認証に使用できる証明書がデバイス上にプロビジョニングされるブートストラップ メカニズムを定義します。したがって、デバイス上での証明書のプロビジョニングをサポートする EAP メソッドが必要です。現在、デバイス上での証明書のプロビジョニングをサポートしている唯一の EAP メソッドは TEAP です。したがって、このドキュメントでは、TEAP がサポートされる唯一の EAP 方式であると想定しています。セクション 4 では、適切な NAI の定義を含め、TLS-POK が TEAP でどのように使用されるかについて説明します。
If future EAP methods are defined supporting certificate provisioning, then TLS-POK could potentially be used with those methods. Defining how this would work is out of scope of this document.
将来の EAP メソッドが証明書プロビジョニングをサポートするように定義された場合、TLS-POK がそれらのメソッドで使用される可能性があります。これがどのように機能するかを定義することは、このドキュメントの範囲外です。
The mechanism for device onboarding defined in this document relies on an EC BSK. This BSK MUST be from a cryptosystem suitable for doing ECDSA. A bootstrapping client device has an associated EC BSK. The BSK may be static and baked into device firmware at manufacturing time or may be dynamic and generated at onboarding time by the device. The BSK public key MUST be encoded as the DER representation of an ASN.1 SEQUENCE SubjectPublicKeyInfo from [RFC5480]. The subjectPublicKey MUST be the compressed format of the public key. Note that the BSK public key encoding MUST include the ASN.1 AlgorithmIdentifier in addition to the subjectPublicKey. If the BSK public key can be shared in a trustworthy manner with a TLS server, a form of entity authentication (the step from which all subsequent authentication proceeds) can be obtained.
このドキュメントで定義されているデバイス オンボーディングのメカニズムは、EC BSK に依存しています。この BSK は、ECDSA を実行するのに適した暗号システムからのものでなければなりません。ブートストラップ クライアント デバイスには、関連付けられた EC BSK があります。BSK は、静的で製造時にデバイスのファームウェアに組み込まれることも、動的でオンボーディング時にデバイスによって生成されることもあります。BSK 公開鍵は、[RFC5480] の ASN.1 SEQUENCE SubjectPublicKeyInfo の DER 表現としてエンコードされなければなりません (MUST)。subjectPublicKey は、公開キーの圧縮形式でなければなりません。BSK 公開キーのエンコーディングには、subjectPublicKey に加えて ASN.1 AlgorithmIdentifier を含める必要があることに注意してください。BSK 公開キーを信頼できる方法で TLS サーバーと共有できれば、エンティティ認証の形式 (その後のすべての認証が開始されるステップ) を取得できます。
The exact mechanism by which the TLS server gains knowledge of the BSK public key is out of scope of this specification, but possible mechanisms include scanning a QR code to obtain a base64 encoding of the DER representation of the ASN.1 SubjectPublicKeyInfo or uploading of a Bill of Materials (BOM) that includes this information. More information on QR encoding is given in Section 2.1. If the QR code is physically attached to the client device, or the BOM is associated with the device, the assumption is that the BSK public key obtained in this bootstrapping method belongs to the client. In this model, physical possession of the device implies legitimate ownership of the device.
TLS サーバーが BSK 公開キーの情報を取得する正確なメカニズムはこの仕様の範囲外ですが、考えられるメカニズムには、QR コードをスキャンして ASN.1 SubjectPublicKeyInfo の DER 表現の Base64 エンコードを取得することや、この情報を含む部品表 (BOM) のアップロードが含まれます。QR エンコードの詳細については、セクション 2.1 を参照してください。QR コードがクライアント デバイスに物理的に添付されている場合、または BOM がデバイスに関連付けられている場合、このブートストラップ方法で取得された BSK 公開キーはクライアントに属していると想定されます。このモデルでは、デバイスの物理的な所有は、デバイスの正当な所有権を意味します。
The TLS server may have knowledge of multiple BSK public keys corresponding to multiple devices, and existing TLS mechanisms are leveraged that enable the server to identify a specific BSK public key corresponding to a specific device.
TLS サーバーは、複数のデバイスに対応する複数の BSK 公開キーの知識を持っている場合があり、サーバーが特定のデバイスに対応する特定の BSK 公開キーを識別できるようにする既存の TLS メカニズムが利用されます。
Using the process defined herein, the client proves to the TLS server that it has possession of the private key of its BSK. Provided that the mechanism in which the server obtained the BSK public key is trustworthy, a commensurate amount of authenticity of the resulting connection can be obtained. The server also proves that it knows the client's BSK public key, which, if the client does not gratuitously expose its public key, can be used to obtain a modicum of correctness, that the client is connecting to the correct server (see [DUCKLING]).
ここで定義されたプロセスを使用して、クライアントは TLS サーバーに対して、BSK の秘密キーを所有していることを証明します。サーバーが BSK 公開キーを取得したメカニズムが信頼できる場合、結果として得られる接続の信頼性を同等に得ることができます。また、サーバーは、クライアントの BSK 公開鍵を知っていることも証明します。これは、クライアントがその公開鍵をいたずらに公開しない場合、クライアントが正しいサーバーに接続していることをある程度の正確性を得るために使用できます ([DUCKLING] を参照)。
The definition of the BSK public key aligns with [DPP]. This, for example, enables the QR code format as defined in [DPP] to be reused for TLS-POK. Therefore, a device that supports both wired LAN and Wi-Fi LAN connections can have a single QR code printed on its label, or dynamically display a single QR code on a display, and the BSK can be used for DPP if the device bootstraps against a Wi-Fi network or TLS-POK if the device bootstraps against a wired network. Similarly, a common BSK public key format could be imported into a BOM into a server that handles devices connecting over both wired and Wi-Fi networks.
BSK 公開鍵の定義は [DPP] に準拠しています。これにより、たとえば、[DPP] で定義されている QR コード形式を TLS-POK に再利用できるようになります。したがって、有線 LAN 接続と Wi-Fi LAN 接続の両方をサポートするデバイスでは、ラベルに 1 つの QR コードを印刷したり、ディスプレイに 1 つの QR コードを動的に表示したりできます。また、デバイスが Wi-Fi ネットワークに対してブートストラップする場合は BSK を DPP に使用でき、デバイスが有線ネットワークに対してブートストラップする場合は TLS-POK に BSK を使用できます。同様に、一般的な BSK 公開キー形式を、有線ネットワークと Wi-Fi ネットワークの両方を介して接続するデバイスを処理するサーバーの BOM にインポートできます。
[DPP], and therefore TLS-POK, does not support the use of RSA or postquantum crypto systems due to the size of public key and its unsuitableness to be represented in a QR code. If [DPP] is modified in the future to support postquantum crypto systems, this document will be updated to track support.
[DPP]、したがって TLS-POK は、公開鍵のサイズと QR コードで表現するには不適切であるため、RSA またはポスト量子暗号システムの使用をサポートしていません。将来、ポスト量子暗号システムをサポートするために [DPP] が変更された場合、このドキュメントはサポートを追跡するために更新されます。
Any bootstrapping method defined for, or used by, [DPP] is compatible with TLS-POK.
[DPP] 用に定義された、または [DPP] によって使用されるブートストラップ方式はすべて、TLS-POK と互換性があります。
Bootstrapping in TLS 1.3 leverages Certificate-Based Authentication (as per [RFC8773]) with an EPSK. The EPSK is derived from the BSK public key as described in Section 3.1, and the EPSK is imported using "Importing External Pre-Shared Keys (PSKs) for TLS 1.3" [RFC9258]. As the BSK public key is an ASN.1 SEQUENCE SubjectPublicKeyInfo from [RFC5480], and not a full PKI Certificate. The client must present the BSK as a raw public key as described in [RFC7250] and use ECDSA as defined in [NIST.FIPS.186-5] for authentication.
TLS 1.3 のブートストラップは、EPSK を使用した証明書ベースの認証 ([RFC8773] による) を利用します。EPSK はセクション 3.1 で説明されているように BSK 公開鍵から導出され、EPSK は「TLS 1.3 用の外部事前共有キー (PSK) のインポート」[RFC9258] を使用してインポートされます。BSK 公開鍵は [RFC5480] の ASN.1 SEQUENCE SubjectPublicKeyInfo であり、完全な PKI 証明書ではないためです。クライアントは、[RFC7250] で説明されているように、BSK を生の公開鍵として提示し、認証に [NIST.FIPS.186-5] で定義されている ECDSA を使用する必要があります。
The TLS PSK handshake gives the client proof that the TLS server knows the BSK public key. Certificate-based authentication of the client to the server using the BSK gives the server proof that the client knows the BSK private key. This satisfies the proof of ownership requirements outlined in Section 1.
TLS PSK ハンドシェイクは、TLS サーバーが BSK 公開キーを知っていることをクライアントに証明します。BSK を使用したサーバーに対するクライアントの証明書ベースの認証により、クライアントが BSK 秘密キーを知っているという証明がサーバーに与えられます。これは、セクション 1 で概説した所有権証明の要件を満たします。
An EPSK [RFC9258] is made up of the tuple of (Base Key, External Identity, Hash). The Base Key is the DER-encoded ASN.1 subjectPublicKeyInfo representation of the BSK public key. Zero-byte padding MUST NOT be added to the DER-encoded representation of the BSK public key.
EPSK [RFC9258] は、(ベースキー、外部 ID、ハッシュ) のタプルで構成されます。基本キーは、BSK 公開キーの DER エンコードされた ASN.1 subjectPublicKeyInfo 表現です。ゼロバイトのパディングを、BSK 公開鍵の DER エンコード表現に追加してはなりません (MUST NOT)。
The External Identity is derived from the DER-encoded representation of the BSK public key using [RFC5869] with the SHA-256 hash algorithm [SHA2] as follows:
外部 ID は、次のように [RFC5869] と SHA-256 ハッシュ アルゴリズム [SHA2] を使用して、BSK 公開鍵の DER エンコード表現から導出されます。
epskid = HKDF-Expand(HKDF-Extract(<>, Base Key),
"tls13-bspsk-identity", L)
where:
- epskid is the EPSK External Identity
- Base Key is the DER-encoded ASN.1 subjectPublicKeyInfo
representation of the BSK public key
- L equals 32, the length in octets of the SHA-256 output
- <> is a NULL salt, which is a string of L zeros
SHA-256 MUST be used when deriving epskid using [RFC5869].
[RFC5869] を使用して epskid を導出する場合は、SHA-256 を使用しなければなりません (MUST)。
The ImportedIdentity structure [RFC9258] is defined as:
InstantIdentity 構造体 [RFC9258] は次のように定義されています。
struct {
opaque external_identity<1...2^16-1>;
opaque context<0..2^16-1>;
uint16 target_protocol;
uint16 target_kdf;
} ImportedIdentity;
and is created using the following values:
次の値を使用して作成されます。
external_identity = epskid
context = "tls13-bsk"
target_protocol = TLS1.3(0x0304)
target_kdf = <as per RFC 9258>
The ImportedIdentity context value MUST be "tls13-bsk". This informs the server that the mechanisms specified in this document for deriving the EPSK and executing the TLS handshake MUST be used. The EPSK and ImportedIdentity are used in the TLS handshake as specified in [RFC9258]. Multiple ImportedIdentity values may be imported as per Section 5.1 of [RFC9258]. The target_kdf follows [RFC9258] and aligns with the cipher suite hash algorithms advertised in the TLS 1.3 handshake between the device and the server.
インポートされたアイデンティティのコンテキスト値は「tls13-bsk」である必要があります。これは、EPSK の導出と TLS ハンドシェイクの実行のためにこの文書で指定されたメカニズムを使用しなければならないことをサーバーに通知します。EPSK と ippedIdentity は、[RFC9258] で指定されているように、TLS ハンドシェイクで使用されます。[RFC9258] のセクション 5.1 に従って、複数の ippedIdentity 値をインポートできます。target_kdf は [RFC9258] に従い、デバイスとサーバー間の TLS 1.3 ハンドシェイクでアドバタイズされる暗号スイート ハッシュ アルゴリズムに準拠します。
A server can choose a trade-off between performance and storage by precomputing the identity of every bootstrapped key with every hash algorithm that it uses in TLS and use that to quickly lookup the bootstrap key and generate the PSK. Servers that choose not to employ this optimization will have to do a runtime check with every bootstrap key it holds against the identity the client provides.
サーバーは、TLS で使用するすべてのハッシュ アルゴリズムを使用してすべてのブートストラップ キーの ID を事前計算し、それを使用してブートストラップ キーを迅速に検索し、PSK を生成することで、パフォーマンスとストレージの間のトレードオフを選択できます。この最適化を採用しないことを選択したサーバーは、クライアントが提供する ID に対して保持するすべてのブートストラップ キーを使用して実行時チェックを行う必要があります。
Test vectors for derivation of an EPSK External Identity from a BSK are given in the appendix.
BSK から EPSK 外部 ID を導出するテスト ベクトルは付録に記載されています。
The client includes the "tls_cert_with_extern_psk" extension in the ClientHello, per [RFC8773]. The client identifies the BSK public key by inserting the serialized content of ImportedIdentity into the PskIdentity.identity in the PSK extension, per [RFC9258]. The client MUST also include the "client_certificate_type" extension per [RFC7250] in the ClientHello and MUST specify type of RawPublicKey.
[RFC8773] に従って、クライアントには ClientHello に「tls_cert_with_extern_psk」拡張機能が含まれています。クライアントは、[RFC9258] に従って、IMPORTEDIdentity のシリアル化されたコンテンツを PSK 拡張機能の PskIdentity.identity に挿入することにより、BSK 公開鍵を識別します。クライアントは、[RFC7250] に従って「client_certificate_type」拡張子を ClientHello に含めなければならず、RawPublicKey のタイプを指定しなければなりません (MUST)。
Upon receipt of the ClientHello, the server looks up the client's EPSK in its database using the mechanisms documented in [RFC9258]. If no match is found, the server MUST terminate the TLS handshake with an alert. If the server finds the matching BSK public key, it includes the "tls_cert_with_extern_psk" extension in the ServerHello message and the corresponding EPSK identity in the "pre_shared_key" extension. When these extensions have been successfully negotiated, the TLS 1.3 key schedule MUST include both the EPSK in the Early Secret derivation and a Diffie-Hellman Ephemeral (DHE) or ECDHE shared secret value in the Handshake Secret derivation.
ClientHello を受信すると、サーバーは [RFC9258] に記載されているメカニズムを使用してデータベース内のクライアントの EPSK を検索します。一致するものが見つからない場合、サーバーはアラートを発行して TLS ハンドシェイクを終了しなければなりません (MUST)。サーバーが一致する BSK 公開キーを見つけると、ServerHello メッセージに「tls_cert_with_extern_psk」拡張子が含まれ、「pre_shared_key」拡張子に対応する EPSK ID が含まれます。これらの拡張のネゴシエーションが成功した場合、TLS 1.3 鍵スケジュールには、Early Secret 導出に EPSK と、Handshake Secret 導出に Diffie-Hellman Ephemeral (DHE) または ECDHE 共有シークレット値の両方が含まれなければなりません (MUST)。
After successful negotiation of these extensions, the full TLS 1.3 handshake is performed with the additional caveat that the server MUST send a CertificateRequest message and the client MUST authenticate with a raw public key (its BSK) per [RFC7250]. The BSK is always an EC key pair; therefore, the type of the client's Certificate MUST be ECDSA and MUST contain the client's BSK public key as a DER-encoded ASN.1 subjectPublicKeyInfo SEQUENCE.
これらの拡張機能のネゴシエーションが成功した後、完全な TLS 1.3 ハンドシェイクが実行されますが、[RFC7250] に従って、サーバーは CertificateRequest メッセージを送信しなければならず、クライアントは生の公開鍵 (BSK) で認証しなければならないという追加の注意事項があります。BSK は常に EC キー ペアです。したがって、クライアントの証明書のタイプは ECDSA でなければならず、クライアントの BSK 公開鍵を DER でエンコードされた ASN.1 subjectPublicKeyInfo SEQUENCE として含めなければなりません。
Note that the client MUST NOT share its BSK public key with the server until after the client has completed processing of the ServerHello and verified the TLS key schedule. The PSK proof is completed at this stage, and the server has proven to the client that it knows the BSK public key, and it is therefore safe for the client to send the BSK public key to the server in the Certificate message. If the PSK verification step fails when processing the ServerHello, the client terminates the TLS handshake and the BSK public key MUST NOT be shared with the server.
クライアントは、ServerHello の処理を完了し、TLS 鍵スケジュールを検証するまで、BSK 公開鍵をサーバーと共有してはいけないことに注意してください。PSK 証明はこの段階で完了し、サーバーは BSK 公開キーを知っていることをクライアントに証明したので、クライアントは証明書メッセージで BSK 公開キーをサーバーに安全に送信できます。ServerHello の処理時に PSK 検証ステップが失敗した場合、クライアントは TLS ハンドシェイクを終了し、BSK 公開キーをサーバーと共有してはなりません (MUST NOT)。
When the server processes the client's Certificate, it MUST ensure that it is identical to the BSK public key that it used to generate the EPSK and ImportedIdentity for this handshake.
サーバーがクライアントの証明書を処理するときは、それがこのハンドシェイクの EPSK および ippedIdentity の生成に使用した BSK 公開キーと同一であることを確認しなければなりません (MUST)。
When clients are configured to trust the first network that proves possession of their public key (as in [DUCKLING]), they MAY forgo the checking of the server's certificate in the CertificateVerify and rely on the integrity of the bootstrapping method employed to distribute its key in order to validate trust in the authenticated TLS connection.
クライアントが、([DUCKLING] のように) 公開鍵の所有を証明する最初のネットワークを信頼するように設定されている場合、CertificateVerify でのサーバーの証明書のチェックを省略し、認証された TLS 接続の信頼性を検証するために鍵の配布に使用されるブートストラップ方式の完全性に依存してもよい(MAY)。
The handshake is shown in Figure 1.
ハンドシェイクを図 1 に示します。
Client Server
-------- --------
ClientHello
+ cert_with_extern_psk
+ client_cert_type=RawPublicKey
+ key_share
+ pre_shared_key -------->
ServerHello
+ cert_with_extern_psk
+ client_cert_type=RawPublicKey
+ key_share
+ pre_shared_key
{EncryptedExtensions}
{CertificateRequest}
{Certificate}
{CertificateVerify}
<-------- {Finished}
{Certificate}
{CertificateVerify}
{Finished} -------->
Figure 1: TLS 1.3 TLS-POK Handshake
図 1: TLS 1.3 TLS-POK ハンドシェイク
Upon "link up", an Authenticator on an 802.1X-protected port will issue an EAP Identity request to the newly connected peer. For unprovisioned devices that desire to take advantage of TLS-POK, there is no initial realm in which to construct an NAI (see [RFC7542]). This document uses the NAI mechanisms defined in [RFC9965] and defines the EAP username "tls-pok-dpp" for use with the TEAP realm "teap.eap.arpa". The username "tls-pok-dpp" MUST be included, yielding an initial identity of "tls-pok-dpp@teap.eap.arpa". This identifier MUST be included in the EAP Identity response in order to indicate to the Authenticator that TEAP is the desired EAP method. [RFC9965] recommends how the device should behave if the Authenticator does not support TEAP or TLS-POK.
「リンクアップ」すると、802.1X で保護されたポート上のオーセンティケータが、新しく接続されたピアに EAP ID 要求を発行します。TLS-POK を利用したいプロビジョニングされていないデバイスの場合、NAI を構築するための初期レルムはありません ([RFC7542] を参照)。この文書は、[RFC9965] で定義された NAI メカニズムを使用し、TEAP レルム「teap.eap.arpa」で使用する EAP ユーザー名「tls-pok-dpp」を定義します。ユーザー名「tls-pok-dpp」を含める必要があり、初期 ID は「tls-pok-dpp@teap.eap.arpa」になります。TEAP が望ましい EAP 方式であることを認証者に示すために、この識別子を EAP Identity 応答に含めなければなりません (MUST)。[RFC9965] では、Authenticator が TEAP または TLS-POK をサポートしていない場合にデバイスがどのように動作するかを推奨しています。
EAP Peer EAP Server
-------- ----------
<- EAP-Request/
Identity
EAP-Response/
Identity
(tls-pok-dpp@teap.eap.arpa) ->
<- EAP-Request/
EAP-Type=TEAP
(TLS Start)
EAP-Response/
EAP-Type=TEAP
(TLS client_hello with
tls_cert_with_extern_psk
and pre_shared_key) ->
.
.
.
Figure 2: EAP Exchange Using TLS-POK
図 2: TLS-POK を使用した EAP 交換
Both client and server have derived the EPSK and associated ImportedIdentity [RFC9258] from the BSK public key as described in Section 3.1. When the client starts the TLS exchange in the EAP transaction, it includes the ImportedIdentity structure in the pre_shared_key extension in the ClientHello. When the server receives the ClientHello, it extracts the ImportedIdentity and looks up the EPSK and BSK public key. As previously mentioned in Section 2, the exact mechanism by which the server has gained knowledge of or been provisioned with the BSK public key is outside the scope of this document.
クライアントとサーバーの両方は、セクション 3.1 で説明されているように、BSK 公開鍵から EPSK と関連する ippedIdentity [RFC9258] を導出しています。クライアントが EAP トランザクションで TLS 交換を開始すると、ClientHello の pre_shared_key 拡張機能に ippedIdentity 構造体が含まれます。サーバーは ClientHello を受信すると、ippededIdentity を抽出し、EPSK および BSK 公開キーを検索します。セクション 2 で前述したように、サーバーが BSK 公開キーの情報を取得したり、BSK 公開キーをプロビジョニングしたりする正確なメカニズムは、このドキュメントの範囲外です。
The server continues with the TLS handshake and uses the EPSK to prove that it knows the BSK public key. When the client replies with its Certificate, CertificateVerify, and Finished messages, the server MUST ensure that the public key in the Certificate message matches the BSK public key.
サーバーは TLS ハンドシェイクを続行し、EPSK を使用して BSK 公開キーを知っていることを証明します。クライアントが Certificate、CertificateVerify、および Finished メッセージで応答するとき、サーバーは Certificate メッセージ内の公開鍵が BSK 公開鍵と一致することを確認しなければなりません (MUST)。
Once the TLS handshake completes, the client and server have established mutual trust. The server can then proceed to provision a credential onto the client using, for example, the mechanisms outlined in [RFC9930].
TLS ハンドシェイクが完了すると、クライアントとサーバーは相互信頼を確立します。その後、サーバーは、たとえば [RFC9930] で概説されているメカニズムを使用して、クライアントに資格情報をプロビジョニングすることができます。
The client can then use this provisioned credential for subsequent EAP authentication. The BSK is only used during bootstrap and is not used for any subsequent EAP authentication.
クライアントは、このプロビジョニングされた資格情報を後続の EAP 認証に使用できます。BSK はブートストラップ中にのみ使用され、その後の EAP 認証には使用されません。
This document adds the following entry to the "EAP Provisioning Identifiers" registry in the "Extensible Authentication Protocol (EAP) Registry" registry group.
このドキュメントでは、「Extensible Authentication Protocol (EAP) Registry」レジストリ グループの「EAP Provisioning Identifiers」レジストリに次のエントリを追加します。
NAI:
NAI:
tls-pok-dpp@teap.eap.arpa
tls-pok-dpp@teap.eap.arpa
Method Type:
メソッドの種類:
TEAP
ティープ
Reference:
参照：
RFC 9966
RFC 9966
Three key points are documented above and are repeated here.
3 つの重要な点は上で文書化されており、ここでも繰り返します。
* The subjectPublicKey contained in the ASN.1 SEQUENCE SubjectPublicKeyInfo MUST be the compressed format of the public key.
* ASN.1 SEQUENCE SubjectPublicKeyInfo に含まれる subjectPublicKey は、公開鍵の圧縮形式でなければなりません。
* When deriving the EPSK from the BSK, zero-byte padding MUST NOT be added to the DER-encoded representation of the BSK public key.
* BSK から EPSK を導出する場合、BSK 公開鍵の DER エンコード表現にゼロバイトのパディングを追加してはなりません (MUST NOT)。
* SHA-256 MUST be used when following [RFC5869] to derive the EPSK from the BSK.
* [RFC5869]に従ってBSKからEPSKを導出する場合は、SHA-256を使用しなければなりません(MUST)。
* The BSK public key MUST NOT be freely available on the network.
* BSK 公開キーはネットワーク上で自由に利用できてはなりません。
Bootstrap and trust establishment by the TLS server are based on proof of knowledge of the client's BSK public key, a non-public datum. The TLS server obtains proof that the client knows its BSK public key and also possesses its corresponding private key.
TLS サーバーによるブートストラップと信頼の確立は、クライアントの BSK 公開キー (非公開データ) の知識の証明に基づいています。TLS サーバーは、クライアントがその BSK 公開キーを知っており、対応する秘密キーも所有しているという証拠を取得します。
Trust on the part of the client is based on successful completion of the TLS 1.3 handshake using the EPSK derived from the BSK. This proves to the client that the server knows its BSK public key. In addition, the client assumes that knowledge of its BSK public key is not widely disseminated; therefore, any server that proves knowledge of its BSK public key is the appropriate server from which to receive provisioning, for instance via [RFC9930]. [DUCKLING] describes a security model for this type of "imprinting".
クライアント側の信頼は、BSK から派生した EPSK を使用した TLS 1.3 ハンドシェイクの正常な完了に基づいています。これにより、サーバーが BSK 公開キーを知っていることがクライアントに証明されます。さらに、クライアントは、BSK 公開キーの知識が広く普及していないと想定しています。したがって、BSK 公開鍵の知識を証明するサーバーは、たとえば [RFC9930] 経由でプロビジョニングを受け取るのに適切なサーバーです。[DUCKLING] は、このタイプの「インプリンティング」のセキュリティ モデルについて説明しています。
An attack on the bootstrapping method, which substitutes the public key of a rogue device for the public key of an honest device, can result in the TLS server onboarding and trusting the rogue device.
不正なデバイスの公開キーを正規のデバイスの公開キーに置き換えるブートストラップ方式に対する攻撃により、TLS サーバーが不正なデバイスをオンボーディングして信頼する可能性があります。
If an adversary has knowledge of the BSK public key, the adversary may be able to make the client bootstrap against the adversary's network. For example, if an adversary intercepts and scans QR labels on clients, and the adversary can force the client to connect to its server, then the adversary can complete the TLS-POK handshake with the client and the client will connect to the adversary's server. Since physical possession implies ownership, there is nothing to prevent a stolen device from being onboarded.
敵対者が BSK 公開鍵を知っている場合、敵対者は敵対者のネットワークに対してクライアント ブートストラップを行うことができる可能性があります。たとえば、攻撃者がクライアント上の QR ラベルを傍受してスキャンし、攻撃者がクライアントにそのサーバーへの接続を強制できる場合、攻撃者はクライアントとの TLS-POK ハンドシェイクを完了でき、クライアントは攻撃者のサーバーに接続します。物理的な所有は所有権を意味するため、盗難されたデバイスの搭載を妨げるものは何もありません。
The BSK key pair used for ECDSA MUST be generated and validated according to Section 6.2 of [NIST.FIPS.186-5].
ECDSA に使用される BSK 鍵ペアは、[NIST.FIPS.186-5] のセクション 6.2 に従って生成および検証されなければなりません (MUST)。
Manufacturers SHOULD use a unique BSK for every single device they manufacture. If multiple devices share the same BSK, then network operators cannot differentiate between these devices and cannot ensure that only specific authorized devices are allowed connect to their networks.
メーカーは、製造するすべてのデバイスに固有の BSK を使用する必要があります。複数のデバイスが同じ BSK を共有する場合、ネットワーク オペレータはこれらのデバイスを区別できず、特定の許可されたデバイスのみがネットワークに接続できるようにすることができません。
[NIST.FIPS.186-5]
NIST, "Digital Signature Standard (DSS)", NIST FIPS 186-5,
DOI 10.6028/NIST.FIPS.186-5, February 2023,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-5.pdf>.
[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>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<https://www.rfc-editor.org/info/rfc5480>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[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>.
[RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based
Authentication with an External Pre-Shared Key", RFC 8773,
DOI 10.17487/RFC8773, March 2020,
<https://www.rfc-editor.org/info/rfc8773>.
[RFC9258] Benjamin, D. and C. A. Wood, "Importing External Pre-
Shared Keys (PSKs) for TLS 1.3", RFC 9258,
DOI 10.17487/RFC9258, July 2022,
<https://www.rfc-editor.org/info/rfc9258>.
[RFC9965] DeKok, A., "The eap.arpa. Domain and Extensible
Authentication Protocol (EAP) Provisioning", RFC 9965,
DOI 10.17487/RFC9965, May 2026,
<https://www.rfc-editor.org/info/rfc9965>.
[DPP] Wi-Fi Alliance, "Wi-Fi Easy Connect(TM) Specification",
Version 3.0, 2022, <https://www.wi-fi.org/system/files/Wi-
Fi_Easy_Connect_Specification_v3.0.pdf>.
[DUCKLING] Stajano, F. and R. Anderson, "The Resurrecting Duckling:
Security Issues for Ad-Hoc Wireless Networks", Security
Protocols, 7th International Workshop Proceedings, Lecture
Notes in Computer Science, vol. 1796, pp. 172-182,
DOI 10.1007/10720107_24, 1999,
<https://www.cl.cam.ac.uk/~fms27/papers/1999-StajanoAnd-
duckling.pdf>.
[IEEE8802.1x]
IEEE/ISO/IEC, "IEEE/ISO/IEC International Standard-
Telecommunications and exchange between information
technology systems--Requirements for local and
metropolitan area networks-/-Part 1X:Port-based network
access control", ISO/IEC/IEEE 8802-1X:2021,
DOI 10.1109/IEEESTD.2021.9650828, 2021,
<https://ieeexplore.ieee.org/document/9650828>.
[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>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/info/rfc7030>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>.
[RFC9930] DeKok, A., Ed., "Tunnel Extensible Authentication Protocol
(TEAP) Version 1", RFC 9930, DOI 10.17487/RFC9930,
February 2026, <https://www.rfc-editor.org/info/rfc9930>.
[SHA2] NIST, "Secure Hash Standard", NIST FIPS 180-4,
DOI 10.6028/NIST.FIPS.180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.
Base64 encoding of BSK:
BSK の Base64 エンコード:
MDkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDIgACMvLyoOykj8sFJxSoZfzafuVEvM+kNYCxp
EC6KITLb9g=
Base64 encoding of epskid:
epskid の Base64 エンコード:
Bd+lLlg/ERdtYacfzDfh1LjdL0+QWJQHdYXoS7JDSkA=
Bd+lLlg/ERdtYacfzDfh1LjdL0+QWJQHdYXoS7JDSkA=
Base64 encoding of BSK:
BSK の Base64 エンコード:
MEYwEAYHKoZIzj0CAQYFK4EEACIDMgACwDXKQ1pytcR1WbfqPaNGaXQ0RJnijJG1em8ZK
ilryZRDfNioq7+EPquT6l9laRvw
Base64 encoding of epskid:
epskid の Base64 エンコード:
yMWK26ec3klVFewg2znKntQgVoRcRRjW81n677GL+8w=
Base64 encoding of BSK:
BSK の Base64 エンコード:
MFgwEAYHKoZIzj0CAQYFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZ
UvxdXKJR9KW5RVB3HDQfmkoQWHEz4XngXUeFyDXliEo3eF6vhqDMFgwEAYHKoZIzj0CAQ
YFK4EEACMDRAADAIiHIAOXdPVuI8khCnJQHT1j53rQRnFCcY3CZUvxdXKJR9KW5RVB3HD
QfmkoQWHEz4XngXUeFyDXliEo3eF6vhqD
Base64 encoding of epskid:
epskid の Base64 エンコード:
D+s3Ex81A8N36ECI3AdXwBzrOXuonZUMdhhHXVINhg8=
D+s3Ex81A8N36ECI3AdXwBzrOXuonZUMdhhHXVINhg8=
Base64 encoding of BSK:
BSK の Base64 エンコード:
MDowFAYHKoZIzj0CAQYJKyQDAwIIAQEHAyIAA3fyUWqiV8NC9DAC88JzmVqnoT/
reuCvq8lHowtwWNOZ
Base64 encoding of epskid:
epskid の Base64 エンコード:
j2TLWcXtrTej+f3q7EZrhp5SmP31uk1ZB23dfcR93EY=
Owen Friel
Cisco
Email: ofriel@cisco.com
Dan Harkins
Hewlett-Packard Enterprise
Email: daniel.harkins@hpe.com