[要約] RFC 9191は、TLSベースのEAPメソッドで大きな証明書や長い証明書チェーンを扱うためのガイドラインを提供します。この文書の目的は、認証プロセス中にメモリ制限やパケットサイズの制約に直面するデバイスをサポートすることです。主に、無線LANやVPN接続でのセキュアな認証を強化する場面で利用されます。
Internet Engineering Task Force (IETF) M. Sethi
Request for Comments: 9191 J. Preuß Mattsson
Category: Informational Ericsson
ISSN: 2070-1721 S. Turner
sn3rd
February 2022
Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods
TLSベースのEAPメソッドで大規模証明書と長い証明書チェーンを処理する
Abstract
概要
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. EAP-TLS and other TLS-based EAP methods are widely deployed and used for network access authentication. Large certificates and long certificate chains combined with authenticators that drop an EAP session after only 40 - 50 round trips is a major deployment problem. This document looks at this problem in detail and describes the potential solutions available.
RFC 3748で定義されている拡張認証プロトコル（EAP）は、複数の認証方法をサポートするための標準的なメカニズムを提供します。EAP-TLSおよび他のTLSベースのEAPメソッドは、ネットワークアクセス認証に広く展開されて使用されています。大規模証明書と長い証明書チェーンは、40~50 round tripsのみでEAPセッションを削除するオーセンティケインと組み合わせて、大きな展開の問題です。この文書はこの問題を詳細に見え、利用可能な潜在的な解決策を説明します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。それは情報提供のために公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書はインターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それはパブリックレビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。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/rfc9191.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9191で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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. Experience with Deployments
4. Handling of Large Certificates and Long Certificate Chains
4.1. Updating Certificates and Certificate Chains
4.1.1. Guidelines for Certificates
4.1.2. Pre-distributing and Omitting CA Certificates
4.1.3. Using Fewer Intermediate Certificates
4.2. Updating TLS and EAP-TLS Code
4.2.1. URLs for Client Certificates
4.2.2. Caching Certificates
4.2.3. Compressing Certificates
4.2.4. Compact TLS 1.3
4.2.5. Suppressing Intermediate Certificates
4.2.6. Raw Public Keys
4.2.7. New Certificate Types and Compression Algorithms
4.3. Updating Authenticators
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
The Extensible Authentication Protocol (EAP), defined in [RFC3748], provides a standard mechanism for support of multiple authentication methods. EAP-TLS [RFC5216] [RFC9190] relies on TLS [RFC8446] to provide strong mutual authentication with certificates [RFC5280] and is widely deployed and often used for network access authentication. There are also many other standardized TLS-based EAP methods such as Flexible Authentication via Secure Tunneling (EAP-FAST) [RFC4851], Tunneled Transport Layer Security (EAP-TTLS) [RFC5281], the Tunnel Extensible Authentication Protocol (TEAP) [RFC7170], as well as several vendor-specific EAP methods such as the Protected Extensible Authentication Protocol (PEAP) [PEAP].
[RFC3748]で定義されている拡張認証プロトコル（EAP）は、複数の認証方法をサポートするための標準メカニズムを提供します。EAP-TLS [RFC5216] [RFC9190]はTLS [RFC8446]に依存して証明書[RFC5280]との強力な相互認証を提供し、広く展開され、ネットワークアクセス認証によく使用されます。セキュアトンネリング（EAP-FAST）[RFC4851]、トンネルトランスポートレイヤセキュリティ（EAP-TTLS）[RFC5281]、トンネル拡張認証プロトコル（TEAP）[RFC7170]の他の多くの標準化されたTLSベースのEAPメソッドもあります。]、および保護された拡張認証プロトコル（PEAP）[PEAP]などのいくつかのベンダー固有のEAPメソッド。
Certificates in EAP deployments can be relatively large, and the certificate chains can be long. Unlike the use of TLS on the web, where typically only the TLS server is authenticated, EAP-TLS deployments typically authenticate both the EAP peer and the EAP server. Also, from deployment experience, EAP peers typically have longer certificate chains than servers. This is because EAP peers often follow organizational hierarchies and tend to have many intermediate certificates. Thus, EAP-TLS authentication usually involves exchange of significantly more octets than when TLS is used as part of HTTPS.
EAP展開の証明書は比較的大きくなり、証明書チェーンが長くなる可能性があります。Web上のTLSの使用とは異なり、通常TLSサーバーのみが認証されている場合、EAP-TLS展開は通常、EAPピアとEAPサーバーの両方を認証します。また、展開経験から、EAPピアは通常、サーバーよりも証明書チェーンが長いです。これは、EAPピアがしばしば組織階層に従い、多くの中間証明書を持つ傾向があるためです。したがって、EAP-TLS認証は通常、TLSがHTTPSの一部として使用されるときよりもかなり多くのオクテットの交換を含みます。
Section 3.1 of [RFC3748] states that EAP implementations can assume a Maximum Transmission Unit (MTU) of at least 1020 octets from lower layers. The EAP fragment size in typical deployments is just 1020 - 1500 octets (since the maximum Ethernet frame size is ~ 1500 bytes). Thus, EAP-TLS authentication needs to be fragmented into many smaller packets for transportation over the lower layers. Such fragmentation not only can negatively affect the latency, but also results in other challenges. For example, some EAP authenticator (e.g., an access point) implementations will drop an EAP session if it has not finished after 40 - 50 round trips. This is a major problem and means that, in many situations, the EAP peer cannot perform network access authentication even though both the sides have valid credentials for successful authentication and key derivation.
[RFC3748]のセクション3.1は、EAP実装が下位層から少なくとも1020オクテットの最大伝送ユニット（MTU）を想定できることを示しています。一般的な展開のEAPフラグメントサイズはわずか1020~1500オクテットです（最大イーサネットフレームサイズは~1500バイトです）。したがって、EAP-TLS認証は、下位層を介した輸送のために多くの小さなパケットに断片化される必要があります。そのような断片化は待ち時間に悪影響を及ぼすだけでなく、他の課題も生じる。たとえば、一部のEAPオーセンティケータ（例えば、アクセスポイント）実装は、40 - 50ラウンドトリップ後に終了していない場合はEAPセッションを削除します。これは大きな問題であり、多くの状況では、両側が正常な認証とキー導出のための有効な認証情報を持っていても、EAPピアはネットワークアクセス認証を実行できません。
Not all EAP deployments are constrained by the MTU of the lower layer. For example, some implementations support EAP over Ethernet "jumbo" frames that can easily allow very large EAP packets. Larger packets will naturally help lower the number of round trips required for successful EAP-TLS authentication. However, deployment experience has shown that these jumbo frames are not always implemented correctly. Additionally, EAP fragment size is also restricted by protocols such as RADIUS [RFC2865], which are responsible for transporting EAP messages between an authenticator and an EAP server. RADIUS can generally transport only about 4000 octets of EAP in a single message (the maximum length of a RADIUS packet is restricted to 4096 octets in [RFC2865]).
すべてのEAP展開が下位レイヤーのMTUによって制約されているわけではありません。たとえば、一部の実装では、非常に大きなEAPパケットを簡単に許可できるETHERNET "Jumbo"フレームをサポートしています。より大きなパケットは当然、成功したEAP-TLS認証に必要な往復の数を減らすのに役立ちます。ただし、展開エクスペリエンスは、これらのジャンボフレームが常に正しく実装されていないことを示しています。さらに、EAPフラグメントサイズもRADIUS [RFC2865]などのプロトコルによって制限されています。これは、オーセンティケータとEAPサーバー間のEAPメッセージの転送を担当します。RADIUSは一般的に単一のメッセージ内の約4000オクテットのEAPのみを転送できます（RADIUSパケットの最大長は[RFC2865]の4096オクテットに制限されています）。
This document looks at related work and potential tools available for overcoming the deployment challenges induced by large certificates and long certificate chains. It then discusses the solutions available to overcome these challenges. Many of the solutions require TLS 1.3 [RFC8446]. The IETF has standardized EAP-TLS 1.3 [RFC9190] and is working on specifications such as [TLS-EAP-TYPES] for how other TLS-based EAP methods use TLS 1.3.
この文書は、大規模証明書と長い証明書チェーンによって引き起こされる展開の課題を克服するために利用可能な関連作業と潜在的なツールを見ます。次に、これらの課題を克服するために利用可能な解決策について説明します。多くのソリューションにはTLS 1.3 [RFC8446]が必要です。IETFは、EAP-TLS 1.3 [RFC9190]を標準化し、他のTLSベースのEAPメソッドのTLS 1.3を使用する方法については[TLS-EAP-Type]などの仕様に取り組んでいます。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
Readers are expected to be familiar with the terms and concepts used in EAP [RFC3748], EAP-TLS [RFC5216], and TLS [RFC8446]. In particular, this document frequently uses the following terms as they have been defined in [RFC5216]:
読者は、EAP [RFC3748]、EAP-TLS [RFC5216]、およびTLS [RFC8446]で使用される用語と概念に精通していると予想されます。特に、この文書は頻繁に[RFC5216]で定義されていると定義されているように次の用語を使用します。
Authenticator: The entity initiating EAP authentication. Typically implemented as part of a network switch or a wireless access point.
認証者：EAP認証を開始するエンティティ。通常、ネットワークスイッチまたは無線アクセスポイントの一部として実装されています。
EAP peer: The entity that responds to the authenticator. In [IEEE-802.1X], this entity is known as the supplicant. In EAP-TLS, the EAP peer implements the TLS client role.
EAPピア：オーセンティケータに応答するエンティティ。[IEEE-802.1X]では、この事業体はサプリカントとして知られています。EAP-TLSでは、EAPピアはTLSクライアントロールを実装しています。
EAP 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. In EAP-TLS, the EAP server implements the TLS server role.
EAP Server：EAP認証方法をピアで終端するエンティティ。バックエンド認証サーバーが使用されていない場合、EAPサーバーはオーセンティケータの一部です。オーセンティケータがパススルーモードで動作する場合、EAPサーバはバックエンド認証サーバ上にあります。EAP-TLSでは、EAPサーバーはTLSサーバーの役割を実装しています。
The document additionally uses the terms "trust anchor" and "certification path" defined in [RFC5280].
この文書は、[RFC5280]で定義されている「信頼アンカー」と「認証パス」という用語をさらに使用しています。
As stated earlier, the EAP fragment size in typical deployments is just 1020 - 1500 octets. A certificate can, however, be large for a number of reasons:
前述のように、一般的な展開のEAPフラグメントサイズはわずか1020~1500オクテットです。ただし、証明書は多くの理由で大きくなります。
* It can have a long Subject Alternative Name field.
* それは長い主題代替名フィールドを持つことができます。
* It can have long Public Key and Signature fields.
* それは長い公開鍵と署名フィールドを持つことができます。
* It can contain multiple object identifiers (OIDs) that indicate the permitted uses of the certificate as noted in Section 5.3 of [RFC5216]. Most implementations verify the presence of these OIDs for successful authentication.
* [RFC5216]のセクション5.3に記載されているように、証明書の許可されている使用を示す複数のオブジェクト識別子（OID）を含めることができます。ほとんどの実装では、認証が成功するためのこれらのOIDの存在を検証します。
* It can contain multiple organization naming fields to reflect the multiple group memberships of a user (in a client certificate).
* ユーザーの複数のグループメンバーシップ（クライアント証明書）を反映するための複数の組織ネームフィールドを含めることができます。
A certificate chain (called a certification path in [RFC5280]) in EAP-TLS can commonly have 2 - 6 intermediate certificates between the end-entity certificate and the trust anchor.
EAP-TLSの証明書チェーン（[RFC5280]の[RFC5280]の認証パス）は、エンドエンティティ証明書と信頼アンカー間の2 - 6の中間証明書を含むことができます。
The size of certificates (and certificate chains) may also increase manyfold in the future with the introduction of post-quantum cryptography. For example, lattice-based cryptography would have public keys of approximately 1000 bytes and signatures of approximately 2000 bytes.
証明書（および証明書チェーン）のサイズは、将来的には多額の暗号化の導入により増加する可能性があります。たとえば、ラティスベースの暗号化は、約1000バイトの公開鍵と約2000バイトのシグネチャを持ちます。
Many access point implementations drop EAP sessions that do not complete within 40 - 50 round trips. This means that if the chain is larger than ~ 60 kilobytes, EAP-TLS authentication cannot complete successfully in most deployments.
多くのアクセスポイントの実装は、40 - 50往復で完了しないEAPセッションを削除します。つまり、チェーンが~60キロバイトを超える場合、EAP-TLS認証はほとんどの展開で正常に完了できません。
This section discusses some possible alternatives for overcoming the challenge of large certificates and long certificate chains in EAP-TLS authentication. Section 4.1 considers recommendations that require an update of the certificates or certificate chains used for EAP-TLS authentication without requiring changes to the existing EAP-TLS code base. It also provides some guidelines that should be followed when issuing certificates for use with EAP-TLS. Section 4.2 considers recommendations that rely on updates to the EAP-TLS implementations and can be deployed with existing certificates. Finally, Section 4.3 briefly discusses what could be done to update or reconfigure authenticators when it is infeasible to replace deployed components giving a solution that can be deployed without changes to existing certificates or code.
このセクションでは、EAP-TLS認証で大規模証明書と長い証明書チェーンの課題を克服するためのいくつかの可能な選択肢について説明します。セクション4.1は、既存のEAP-TLSコードベースへの変更を必要とせずに、EAP-TLS認証に使用される証明書または証明書チェーンの更新を必要とする推奨事項を検討します。また、EAP-TLSで使用する証明書を発行するときに従うべきガイドラインも提供します。セクション4.2は、EAP-TLS実装への更新に依存して既存の証明書を展開することができる推奨事項を検討します。最後に、セクション4.3は、展開されたコンポーネントを置き換えることができない場合に、既存の証明書またはコードを変更することなく展開することができる展開コンポーネントを置き換えることができない場合に、認証者を更新または再構成することができることを簡単に説明します。
Many IETF protocols now use elliptic curve cryptography (ECC) [RFC6090] for the underlying cryptographic operations. The use of ECC can reduce the size of certificates and signatures. For example, at a 128-bit security level, the size of a public key with traditional RSA is about 384 bytes, while the size of a public key with ECC is only 32-64 bytes. Similarly, the size of a digital signature with traditional RSA is 384 bytes, while the size is only 64 bytes with the elliptic curve digital signature algorithm (ECDSA) and the Edwards-curve digital signature algorithm (EdDSA) [RFC8032]. Using certificates that use ECC can reduce the number of messages in EAP-TLS authentication, which can alleviate the problem of authenticators dropping an EAP session because of too many round trips. In the absence of a standard application profile specifying otherwise, TLS 1.3 [RFC8446] requires implementations to support ECC. New cipher suites that use ECC are also specified for TLS 1.2 [RFC8422]. Using ECC-based cipher suites with existing code can significantly reduce the number of messages in a single EAP session.
多くのIETFプロトコルは、基礎となる暗号化操作に対して楕円曲線暗号（ECC）[RFC6090]を使用しています。 ECCの使用は、証明書と署名のサイズを減らすことができます。たとえば、128ビットのセキュリティレベルでは、従来のRSAを使用した公開鍵のサイズは約384バイトですが、ECCの公開鍵のサイズはわずか32~64バイトです。同様に、従来のRSAを使用したデジタル署名のサイズは384バイトですが、サイズは楕円曲線デジタル署名アルゴリズム（ECDSA）とEdward-Curve Digital Signatutal Algorithm（EDDSA）[RFC8032]を使用して64バイトです。 ECCを使用する証明書を使用すると、EAP-TLS認証でのメッセージ数を減らすことができます。これにより、往復が多すぎるため、EAPセッションをドロップするという問題が発生する可能性があります。それ以外の場合、標準のアプリケーションプロファイルがない場合、TLS 1.3 [RFC8446]はECCをサポートするための実装を必要とします。 TLS 1.2 [RFC8422]には、ECCを使用する新しい暗号スイートも指定されています。 ECCベースの暗号スイートを使用する既存のコードを使用すると、単一のEAPセッション内のメッセージ数を大幅に削減できます。
The general guideline of keeping the certificate size small by not populating fields with excessive information can help avert the problems of failed EAP-TLS authentication. More specific recommendations for certificates used with EAP-TLS are as follows:
フィールドに余分な情報を入力しないことによって証明書サイズを小さく保つという一般的なガイドラインは、失敗したEAP-TLS認証の問題を回避するのに役立ちます。EAP-TLSで使用されている証明書に対するより具体的な推奨事項は次のとおりです。
* Object Identifier (OID) is an ASN.1 data type that defines unique identifiers for objects. The OID's ASN.1 value, which is a string of integers, is then used to name objects to which they relate. The Distinguished Encoding Rules (DER) specify that the first two integers always occupy one octet and subsequent integers are base-128 encoded in the fewest possible octets. OIDs are used lavishly in X.509 certificates [RFC5280] and while not all can be avoided, e.g., OIDs for extensions or algorithms and their associate parameters, some are well within the certificate issuer's control:
* オブジェクト識別子（OID）は、オブジェクトの一意の識別子を定義するASN.1データ型です。整数の整数であるOIDのASN.1値は、それらが関連するオブジェクトに名前を付けるために使用されます。識別された符号化規則（DER）は、最初の2つの整数が常に1つのオクテットを占めるように指定され、後続の整数は可能なオクテットで符号化された基本128であることを指定します。OIDはX.509証明書[RFC5280]でLAVISHLYに使用され、すべてが回避できないが、例えば、拡張子またはアルゴリズムのためのOID、およびそれらの関連付けパラメータは、証明書発行者のコントロール内にうまくいっています。
- Each naming attribute in a DN (Distinguished Name) has one. DNs are used in the issuer and subject fields as well as numerous extensions. A shallower name will be smaller, e.g., C=FI, O=Example, SN=B0A123499EFC as against C=FI, O=Example, OU=Division 1, SOPN=Southern Finland, CN=Coolest IoT Gadget Ever, and SN=B0A123499EFC.
- DN（識別名）内の各命名属性には1があります。DNSは、発行者およびサブジェクトフィールド、および多数の拡張機能で使用されています。浅い名称は小さくなります。例えば、c = fi、o =例、c = fi、o =例、ou = division 1、sopn =南フィンランド、cn = colest iotガジェット、そしてsn =B0A123499FCC。
- Every certificate policy (and qualifier) and any mappings to another policy uses identifiers. Consider carefully what policies apply.
- すべての証明書ポリシー（および修飾子）と別のポリシーへのマッピングは識別子を使用します。どのポリシーが適用されるかを慎重に検討してください。
* DirectoryString and GeneralName types are used extensively to name things, e.g., the DN naming attribute O= (the organizational naming attribute) DirectoryString includes "Example" for the Example organization and uniformResourceIdentifier can be used to indicate the location of the Certificate Revocation List (CRL), e.g., "http://crl.example.com/sfig2s1-128.crl", in the CRL Distribution Point extension. For these particular examples, each character is a single byte. For some non-ASCII character strings, characters can be several bytes. Obviously, the names need to be unique, but there is more than one way to accomplish this without long strings. This is especially true if the names are not meant to be meaningful to users.
* DirectoryStringとGeneralName型は、Mothingに広範囲に使用されています。）CRL配布ポイント拡張子の「http://crl.example.com/sfig2s1-128.crl」など、「http://crl.example.com/sfig2s1-128.crl」。これらの特定の例では、各文字は1バイトです。一部の非ASCII文字文字列では、文字は数バイトになる可能性があります。明らかに、名前は一意である必要がありますが、長い文字列なしでこれを達成するための複数の方法があります。これは、名前がユーザーにとって意味があることを意味していない場合に特に当てはまります。
* Extensions are necessary to comply with [RFC5280], but the vast majority are optional. Include only those that are necessary to operate.
* [RFC5280]に準拠するために拡張が必要ですが、大部分はオプションです。操作に必要なものだけを含めます。
* As stated earlier, certificate chains of the EAP peer often follow organizational hierarchies. In such cases, information in intermediate certificates (such as postal addresses) do not provide any additional value and they can be shortened (for example, only including the department name instead of the full postal address).
* 前述のように、EAPピアの証明書チェーンはしばしば組織階層に従います。そのような場合、中間証明書（郵便アドレスなど）の情報は追加の値を提供しないため、短縮することができます（たとえば、全郵便アドレスの代わりに部署名のみを含めます）。
The TLS Certificate message conveys the sending endpoint's certificate chain. TLS allows endpoints to reduce the size of the Certificate message by omitting certificates that the other endpoint is known to possess. When using TLS 1.3, all certificates that specify a trust anchor known by the other endpoint may be omitted (see Section 4.4.2 of [RFC8446]). When using TLS 1.2 or earlier, only the self-signed certificate that specifies the root certificate authority may be omitted (see Section 7.4.2 of [RFC5246]). Therefore, updating TLS implementations to version 1.3 can help to significantly reduce the number of messages exchanged for EAP-TLS authentication. The omitted certificates need to be pre-distributed independently of TLS, and the TLS implementations need to be configured to omit these pre-distributed certificates.
TLS証明書メッセージは送信側エンドポイントの証明書チェーンを伝えます。TLSは、他のエンドポイントが所有することが知られている証明書を省略することによって、エンドポイントが証明書メッセージのサイズを減らすことを可能にします。TLS 1.3を使用する場合、他のエンドポイントで知られている信頼アンカーを指定するすべての証明書を省略することができます（[RFC8446]のセクション4.4.2を参照）。TLS 1.2以前を使用する場合、ルート認証局を指定する自己署名証明書のみを省略することができます（[RFC5246]のセクション7.4.2を参照）。したがって、TLS実装をバージョン1.3にアップデートすると、EAP-TLS認証に対して交換されるメッセージの数を大幅に削減できます。省略された証明書はTLSとは無関係に事前に分散される必要があり、TLS実装はこれらの分散証明書を省略するように設定する必要があります。
The EAP peer certificate chain does not have to mirror the organizational hierarchy. For successful EAP-TLS authentication, certificate chains SHOULD NOT contain more than 4 intermediate certificates.
EAPピア証明書チェーンは、組織の階層をミラーリングする必要はありません。EAP-TLS認証を成功させるには、証明書チェーンに4つ以上の中間証明書を含めるべきではありません。
Administrators responsible for deployments using TLS-based EAP methods can examine the certificate chains and make rough calculations about the number of round trips required for successful authentication. For example, dividing the total size of all the certificates in the peer and server certificate chain (in bytes) by 1020 bytes will indicate the number of round trips required. If this number exceeds 50, then administrators can expect failures with many common authenticator implementations.
TLSベースのEAPメソッドを使用して展開を担当する管理者は、証明書チェーンを調べて、認証が成功したために必要な往復の数についての大まかな計算を行うことができます。たとえば、ピアとサーバーの証明書チェーン（バイト単位）のすべての証明書の合計サイズを1020バイトで割ると、必要な往復の数が示されます。この数が50を超えると、管理者は多くの一般的なオーセンティケータの実装で失敗を期待できます。
This section discusses how the fragmentation problem can be avoided by updating the underlying TLS or EAP-TLS implementation. Note that in some cases, the new feature may already be implemented in the underlying library and simply needs to be enabled.
このセクションでは、基礎となるTLSまたはEAP-TLS実装を更新することで、フラグメンテーションの問題を回避できる方法について説明します。場合によっては、新機能はすでに基礎となるライブラリに実装されており、単に有効にされる必要があることに注意してください。
[RFC6066] defines the "client_certificate_url" extension, which allows TLS clients to send a sequence of Uniform Resource Locators (URLs) instead of the client certificate chain. URLs can refer to a single certificate or a certificate chain. Using this extension can curtail the amount of fragmentation in EAP deployments thereby allowing EAP sessions to successfully complete.
[RFC6066]「client_certificate_url」拡張子を定義します。これにより、TLSクライアントはクライアント証明書チェーンの代わりに一様なリソース・ロケーター（URL）のシーケンスを送信できます。URLは単一の証明書または証明書チェーンを参照できます。この拡張機能を使用すると、EAP展開の断片化量を削減することで、EAPセッションが正常に完了することができます。
The TLS Cached Information Extension [RFC7924] specifies an extension where a server can exclude transmission of certificate information cached in an earlier TLS handshake. The client and the server would first execute the full TLS handshake. The client would then cache the certificate provided by the server. When the TLS client later connects to the same TLS server without using session resumption, it can attach the "cached_info" extension to the ClientHello message. This would allow the client to indicate that it has cached the certificate. The client would also include a fingerprint of the server certificate chain. If the server's certificate has not changed, then the server does not need to send its certificate and the corresponding certificate chain again. In case information has changed, which can be seen from the fingerprint provided by the client, the certificate payload is transmitted to the client to allow the client to update the cache. The extension, however, necessitates a successful full handshake before any caching. This extension can be useful when, for example, a successful authentication between an EAP peer and EAP server has occurred in the home network. If authenticators in a roaming network are stricter at dropping long EAP sessions, an EAP peer can use the Cached Information Extension to reduce the total number of messages.
TLSキャッシュ情報拡張[RFC7924]は、サーバーが以前のTLSハンドシェイクでキャッシュされた証明書情報の送信を除外できる拡張子を指定します。クライアントとサーバーは最初にフルTLSハンドシェイクを実行します。クライアントはサーバーによって提供された証明書をキャッシュします。 TLSクライアントがセッションの再開を使用せずに同じTLSサーバーに接続すると、ClientHelloメッセージに "cached_info"拡張子を添付できます。これにより、クライアントは証明書をキャッシュしたことを示すことができます。クライアントには、サーバー証明書チェーンの指紋も含まれます。サーバーの証明書が変更されていない場合、サーバーはその証明書と対応する証明書チェーンを再度送信する必要はありません。クライアントによって提供された指紋から見ることができる場合、情報が変更された場合、クライアントがキャッシュを更新できるように、証明書ペイロードがクライアントに送信されます。ただし、拡張子はキャッシングの前に完全なハンドシェイクを成功させる必要があります。この拡張機能は、たとえば、ホームネットワークでEAPピアとEAPサーバー間の認証が成功した場合に役立ちます。ローミングネットワーク内のオーセンティケータが長いEAPセッションをドロップする上で厳密な場合、EAPピアはキャッシュされた情報拡張を使用してメッセージの総数を減らすことができます。
However, if all authenticators drop the EAP session for a given EAP peer and EAP server combination, a successful full handshake is not possible. An option in such a scenario would be to cache validated certificate chains even if the EAP-TLS exchange fails, but such caching is currently not specified in [RFC7924].
ただし、すべてのオーセンティケータが特定のEAPピアとEAPサーバーの組み合わせのEAPセッションを削除した場合、完全なハンドシェイクが成功しないことはできません。そのようなシナリオのオプションは、EAP-TLS Exchangeが失敗した場合でも検証済みの証明書チェーンをキャッシュすることですが、[RFC7924]にそのようなキャッシュは現在指定されていません。
The TLS Working Group has standardized an extension for TLS 1.3 [RFC8879] that allows compression of certificates and certificate chains during full handshakes. The client can indicate support for compressed server certificates by including this extension in the ClientHello message. Similarly, the server can indicate support for compression of client certificates by including this extension in the CertificateRequest message. While such an extension can alleviate the problem of excessive fragmentation in EAP-TLS, it can only be used with TLS version 1.3 and higher. Deployments that rely on older versions of TLS cannot benefit from this extension.
TLSワーキンググループは、フルハンドシェイク中に証明書と証明書チェーンの圧縮を可能にするTLS 1.3 [RFC8879]の拡張子を標準化しました。クライアントは、ClientHelloメッセージでこの拡張子を含めることで、圧縮サーバー証明書のサポートを示すことができます。同様に、サーバーは、CertificateRequestメッセージ内のこの拡張子を含めることで、クライアント証明書の圧縮のサポートを示すことができます。そのような延長はEAP-TLSで過度の断片化の問題を軽減することができますが、TLSバージョン1.3以降でのみ使用できます。古いバージョンのTLSに依存する展開は、この拡張子から利益を得ることができません。
[cTLS] defines a "compact" version of TLS 1.3 and reduces the message size of the protocol by removing obsolete material and using more efficient encoding. It also defines a compression profile with which either side can define a dictionary of "known certificates". Thus, cTLS could provide another mechanism for EAP-TLS deployments to reduce the size of messages and avoid excessive fragmentation.
[CTLS]「コンパクトな」バージョンのTLS 1.3を定義し、時代遅れの資料を削除し、より効率的な符号化を使用してプロトコルのメッセージサイズを縮小します。また、どちら側が「既知の証明書」の辞書を定義できる圧縮プロファイルを定義します。したがって、CTLは、EAP-TLS展開に別のメカニズムを提供し、メッセージのサイズを縮小し、過度の断片化を回避できます。
For a client that has all intermediate certificates in the certificate chain, having the server send intermediates in the TLS handshake increases the size of the handshake unnecessarily. [TLS-SIC] proposes an extension for TLS 1.3 that allows a TLS client that has access to the complete set of published intermediate certificates to inform servers of this fact so that the server can avoid sending intermediates, reducing the size of the TLS handshake. The mechanism is intended to be complementary with certificate compression.
証明書チェーン内のすべての中間証明書を持つクライアントの場合、サーバーがTLSハンドシェイクに中間体を送信させることで、ハンドシェイクのサイズが不必要に増加します。[TLS-SIC]はTLS 1.3の拡張を提案しています。これにより、サーバーが中間体の送信を回避でき、TLSハンドシェイクのサイズを変更できるように、この事実のサーバーに通知するためにTLSクライアントがこの事実のサーバーに通知することができます。メカニズムは証明書圧縮と相補的であることを意図しています。
The Authority Information Access (AIA) extension specified in [RFC5280] can be used with end-entity and CA certificates to access information about the issuer of the certificate in which the extension appears. For example, it can be used to provide the address of the Online Certificate Status Protocol (OCSP) responder from where revocation status of the certificate (in which the extension appears) can be checked. It can also be used to obtain the issuer certificate. Thus, the AIA extension can reduce the size of the certificate chain by only including a pointer to the issuer certificate instead of including the entire issuer certificate. However, it requires the side receiving the certificate containing the extension to have network connectivity (unless the information is already cached locally). Naturally, such indirection cannot be used for the server certificate (since EAP peers in most deployments do not have network connectivity before authentication and typically do not maintain an up-to-date local cache of issuer certificates).
[RFC5280]で指定された権限情報アクセス（AIA）拡張子は、エンドエンティティとCA証明書を使用して、拡張子が表示されている証明書の発行者に関する情報にアクセスできます。たとえば、証明書の失効状態（拡張機能が表示されている場所）からオンライン証明書ステータスプロトコル（OCSP）レスポンダのアドレスを入力するために使用できます。発行者証明書を入手するためにも使用できます。したがって、AIA拡張は、発行者証明書全体を含めるのではなく、発行者証明書へのポインタを含めて、証明書チェーンのサイズを減らすことができます。ただし、ネットワーク接続を持つ証明書を受信する側面は、（情報がすでにローカルにキャッシュされていない限り）。当然のことながら、そのような間接事象はサーバー証明書には使用できません（ほとんどの展開のEAPピアは認証前にネットワーク接続がないため、通常は発行者証明書の最新のローカルキャッシュを維持しない）。
[RFC7250] defines a new certificate type and TLS extensions to enable the use of raw public keys for authentication. Raw public keys use only a subset of information found in typical certificates and are therefore much smaller in size. However, raw public keys require an out-of-band mechanism to bind the public key with the entity presenting the key. Using raw public keys will obviously avoid the fragmentation problems resulting from large certificates and long certificate chains. Deployments can consider their use as long as an appropriate out-of-band mechanism for binding public keys with identifiers is in place. Naturally, deployments will also need to consider the challenges of revocation and key rotation with the use of raw public keys.
[RFC7250]認証用の生の公開鍵を使用できるようにする新しい証明書の種類とTLS拡張機能を定義します。RAW Public Keysは、一般的な証明書にある情報のサブセットのみを使用し、したがってサイズがはるかに小さいです。ただし、生の公開鍵では、鍵を表示しているエンティティで公開鍵をバインドするために帯域外のメカニズムが必要です。生の公開鍵を使用すると、明らかに大規模な証明書と長い証明書チェーンから生じる断片化の問題が回避されます。識別子を使用して公開鍵を拘束するための適切な帯域外機構が所定の位置にある限り、展開はそれらの使用を検討することができる。当然のことながら、展開も生の公開鍵を使用した失効とキー回転の課題を考慮する必要があります。
There is ongoing work to specify new certificate types that are
smaller than traditional X.509 certificates. For example,
[CBOR-CERT] defines a Concise Binary Object Representation (CBOR)
[RFC8949] encoding of X.509 Certificates. The CBOR encoding can be
used to compress existing X.509 certificates or for natively signed
CBOR certificates. [TLS-CWT] registers a new TLS Certificate type
that would enable TLS implementations to use CBOR Web Tokens (CWTs)
[RFC8392] as certificates. While these are early initiatives, future
EAP-TLS deployments can consider the use of these new certificate
types and compression algorithms to avoid large message sizes.
There are several legitimate reasons that authenticators may want to limit the number of packets / octets / round trips that can be sent. The main reason has been to work around issues where the EAP peer and EAP server end up in an infinite loop ACKing their messages. Another reason is that unlimited communication from an unauthenticated device using EAP could provide a channel for inappropriate bulk data transfer. A third reason is to prevent denial-of-service attacks.
認証者が送信できるパケット/オクテット/ラウンドトリップの数を制限したいと思うかもしれないといういくつかの正当な理由があります。主な理由は、EAPピアとEAPサーバーが自分のメッセージを有効にする無限ループで終わる問題を回避することでした。もう1つの理由は、EAPを使用する認証されていないデバイスからの無制限の通信が不適切なバルクデータ転送のためのチャネルを提供できることです。3番目の理由は、サービス拒否攻撃を防ぐことです。
Updating the millions of already deployed access points and switches is in many cases not realistic. Vendors may be out of business or no longer supporting the products and administrators may have lost the login information to the devices. For practical purposes, the EAP infrastructure is ossified for the time being.
すでに展開されている既存のアクセスポイントとスイッチを更新することは、多くの場合現実的ではありません。ベンダーがビジネスから出ていないか、もはや製品をサポートし、管理者はデバイスへのログイン情報を失った可能性があります。実用的な目的のために、EAPインフラストラクチャはその間に漏洩されます。
Vendors making new authenticators should consider increasing the number of round trips allowed to 100 before denying the EAP authentication to complete. Based on the size of the certificates and certificate chains currently deployed, such an increase would likely ensure that peers and servers can complete EAP-TLS authentication. At the same time, administrators responsible for EAP deployments should ensure that this 100 round-trip limit is not exceeded in practice.
新しいオーセンティケータを作るベンダーは、完了するためにEAP認証を拒否する前に、100に許可されている往復の数を増やすことを検討する必要があります。現在デプロイされている証明書と証明書チェーンのサイズに基づいて、そのような増加は、ピアとサーバーがEAP-TLS認証を完了できるようになる可能性があります。同時に、EAP展開を担当する管理者は、この100回のラウンドトリップ制限が実際には超えていないことを確認する必要があります。
This document has no IANA actions.
この文書にはIANAの行動がありません。
Updating implementations to TLS version 1.3 allows omitting all certificates with a trust anchor known by the other endpoint. TLS 1.3 additionally provides improved security, privacy, and reduced latency for EAP-TLS [RFC9190].
TLSバージョン1.3に実装を更新すると、他のエンドポイントで知られている信頼アンカーを使用してすべての証明書を省略できます。TLS 1.3はさらに、EAP-TLS [RFC9190]のセキュリティ、プライバシー、およびレイテンシの短縮を提供します。
Security considerations when compressing certificates are specified in [RFC8879].
[RFC8879]に証明書を圧縮するときのセキュリティ上の考慮事項。
Specific security considerations of the referenced documents apply when they are taken into use.
参照されている文書の具体的なセキュリティ上の考慮事項は、それらが使用されたときに適用されます。
[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>。
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)", RFC 4851, DOI 10.17487/RFC4851, May 2007, <https://www.rfc-editor.org/info/rfc4851>.
[RFC4851] Cam-Winget、N.、McGrew、D.、Salowey、J.、およびH.Zhou、「安全なトンネリングの拡張認証プロトコル方法（EAP-FAST）」、RFC 4851、DOI 10.17487 / RFC48512007年5月、<https：//www.rfc-editor.org/info/rfc4851>。
[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>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW.Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル「、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)", RFC 5281, DOI 10.17487/RFC5281, August 2008, <https://www.rfc-editor.org/info/rfc5281>.
[RFC5281] FUNK、P.およびS.BLAKE-WILSON、「拡張認証プロトコルトンネルトランスポート層セキュリティ認証プロトコルバージョン0（EAP-TTLSV0）」、RFC 5281、DOI 10.17487 / RFC5281、2008年8月、<HTTPS：// WWW.rfc-editor.org / info / rfc5281>。
[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, <https://www.rfc-editor.org/info/rfc7170>.
[RFC7170] Zhou、H.、Cam-Winget、N.、Salowey、J.、およびS.Hanna、 "Tunnel Extensible認証プロトコル（Teap）バージョン1"、RFC 7170、DOI 10.17487 / RFC7170、2014年5月、<HTTPS///www.rfc-editor.org/info/rfc7170>。
[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>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E。、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、<https：//www.rfc-editor.org/info/rfc8446>。
[RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3", RFC 9190, DOI 10.17487/RFC9190, February 2022, <https://www.rfc-editor.org/rfc/rfc9190>.
[RFC9190]PreußMattsson、J.およびM.Sethi、「EAP-TLS 1.3：TLS 1.3の拡張認証プロトコルの使用」、RFC 9190、DOI 10.17487 / RFC9190、2022年2月、<https：//www.rfc-編集者.ORG / RFC / RFC9190>。
[CBOR-CERT] Raza, S., Höglund, J., Selander, G., Preuß Mattsson, J., and M. Furuhed, "CBOR Encoded X.509 Certificates (C509 Certificates)", Work in Progress, Internet-Draft, draft-mattsson-cose-cbor-cert-compress-08, 22 February 2021, <https://datatracker.ietf.org/doc/html/draft-mattsson-cose-cbor-cert-compress-08>.
[CBOR-CERT] Raza、S.、Höglund、J.、Selander、G.、PreußMattsson、J.、およびM. Furuhed、 "CBOR ENCODED X.509証明書（C509証明書）"、進行中、インターネット - ドラフト、draft-mattsson-cbor-cert-chor-cert-compress-08,2021、<https://datatracker.ietf.org/doc/html/draft-mattsson-cose-cos-cert-compress-08>。
[cTLS] Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-ctls-04, 25 October 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctls-04>.
[CTLS] Rescorla、E.、Barnes、R.、およびH.Tschofenig、「コンパクトTLS 1.3」、進行中の作業、インターネットドラフト、ドラフト-IETF-TLS-CTLS-04,2021、<https：//datatracker.ietf.org/doc/html/draft-ietf-tls-ctls-04>。
[IEEE-802.1X] IEEE, "IEEE Standard for Local and Metropolitan Area NNetworks--Port-Based Network Access Control", DOI 10.1109/IEEESTD.2020.9018454, IEEE Standard 802.1X-2020, February 2020, <https://doi.org/10.1109/IEEESTD.2020.9018454>.
[IEEE-802.1X] IEEE、「地元および首都圏NNETWORKS - ポートベースネットワークアクセス制御」、DOI 10.1109 / IEEESTD.2020.9018454、IEEE規格802.1X-2020、2020年2月、<https：// doi.ORG / 10.1109 / IEEESTD.2020.9018454>。
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)", June 2021.
[PEAP] Microsoft Corporation、[MS-PEAP]：Protected Extensible認証プロトコル（PEAP） "、2021年6月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.
[RFC2865] Rigney、C、Willens、S.、Rubens、A.、およびW.Simpson、「ユーザーサービスのリモート認証ダイヤル（RADIUS）」、RFC 2865、DOI 10.17487 / RFC2865、2000年6月、<https：//www.rfc-editor.org/info/rfc2865>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T.およびE. Rescorla、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https：//www.rfc-editor.org/info/ RFC5246>。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066]イーストレイク3RD、D.、「トランスポートレイヤセキュリティ（TLS）拡張：拡張定義」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<https：//ww.rfc-editor.org/info/rfc6066>。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <https://www.rfc-editor.org/info/rfc6090>.
[RFC6090] MCGREW、D.、IGOE、K。、およびM. Salter、「基本楕円曲線暗号アルゴリズム」、RFC 6090、DOI 10.17487 / RFC6090、2011年2月、<https：//www.rfc-editor.org/情報/ RFC6090>。
[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>.
[RFC7250] Wouters、P.、ED。、Tschofenig、H。、ED。、Gilmore、J.、Weiler、S.、T.Kivinen、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層での生の公開鍵を使用する」セキュリティ（DTLS） "、RFC 7250、DOI 10.17487 / RFC7250、2014年6月、<https：//www.rfc-editor.org/info/rfc7250>。
[RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016, <https://www.rfc-editor.org/info/rfc7924>.
[RFC7924] Santesson、S.およびH.Tschofenig、「トランスポート層セキュリティ（TLSキャッシュ情報拡張」、RFC 7924、DOI 10.17487 / RFC7924、2016年7月、<https：//www.rfc-editor.org/info/RFC7924>。
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <https://www.rfc-editor.org/info/rfc8032>.
[RFC8032] Josefsson、S.およびI. Liusvaara、 "Edward-Curve Digital Signatutal Algorithm（EDDSA）"、RFC 8032、DOI 10.17487 / RFC8032、2017年1月、<https：//www.rfc-editor.org/info/RFC8032>。
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, May 2018, <https://www.rfc-editor.org/info/rfc8392>.
[RFC8392] Jones、M.、Wahlstroem、E.、Erdtman、S.、およびH.Tschofenig、「CBOR Webトークン（CWT）」、RFC 8392、DOI 10.17487 / RFC8392、<https：// www。rfc-editor.org/info/rfc8392>。
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier", RFC 8422, DOI 10.17487/RFC8422, August 2018, <https://www.rfc-editor.org/info/rfc8422>.
[RFC8422] NIR、Y、Josefsson、S.、およびM. Pegourie-Gonnard、「楕円曲線暗号化（ECC）CISHIPHスイート（TLS）バージョン1.2およびそれ以前の「RFC 8422、DOI 10.17487 / RFC84222018年8月、<https://www.rfc-editor.org/info/rfc8422>。
[RFC8879] Ghedini, A. and V. Vasiliev, "TLS Certificate Compression", RFC 8879, DOI 10.17487/RFC8879, December 2020, <https://www.rfc-editor.org/info/rfc8879>.
[RFC8879] Ghedini、A.およびV.Vasiliev、「TLS証明書圧縮」、RFC 8879、DOI 10.17487 / RFC8879、2020年12月、<https：//www.rfc-editor.org/info/rfc8879>。
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[RFC8949] Bormann、C.およびP.HOFFMAN、「簡潔なバイナリオブジェクト表現（CBOR）」、STD 94、RFC 8949、DOI 10.17487 / RFC8949、2020年12月、<https：//www.rfc-editor.org/info/ RFC8949>。
[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>
[TLS-EAP-TYPES] DeKok, A., "TLS-based EAP types and TLS 1.3", Work in Progress, Internet-Draft, draft-ietf-emu-tls-eap-types-04, 22 January 2022, <https://datatracker.ietf.org/doc/html/ draft-ietf-emu-tls-eap-types-04>.
[TLS-EAP-Types] Dekok、A。、「TLSベースのEAPタイプとTLS 1.3」、進行中の作業、インターネットドラフト、ドラフト-IETF-EMU-TLS-EAP-TypeS-04,22 1月22日、<https://datatracker.ietf.org/doc/html/ proft-ietf-emu-tls-eap-types-04>。
[TLS-SIC] Thomson, M., "Suppressing Intermediate Certificates in TLS", Work in Progress, Internet-Draft, draft-thomson-tls-sic-00, 27 March 2019, <https://datatracker.ietf.org/doc/html/draft-thomson-tls-sic-00>.
[TLS-SIC] Thomson、M.、「TLSの中間証明書の抑制」、進行中、インターネットドラフト、ドラフト - THOMSON-TLS-SIC-00,27,27、<https：//datatracker.ietf.org/ doc / html / draft-thomson-TLS-SIC-00>。
Acknowledgements
謝辞
This document is a result of several useful discussions with Alan DeKok, Bernard Aboba, Jari Arkko, Jouni Malinen, Darshak Thakore, and Hannes Tschofening.
この文書は、Alan Dekok、Bernard Aboba、Jari Arkko、Jouni Malinen、Darshak Thakore、およびHannes Tschofingのいくつかの便利な議論の結果です。
Authors' Addresses
著者の住所
Mohit Sethi Ericsson FI-02420 Jorvas Finland
Mohit Sethi Ericsson FI-02420 Jorvas Finland
Email: mohit@iki.fi
John Preuß Mattsson Ericsson Kista Sweden
JohnPreußMattssonEricsson Kistaスウェーデン
Email: john.mattsson@ericsson.com
Sean Turner sn3rd
Sean Turner SN3RD
Email: sean@sn3rd.com