[要約] RFC 9190は、EAP-TLS 1.3プロトコルに関する文書で、TLS 1.3を使用した拡張認証プロトコル(EAP)の実装を定義しています。この文書の目的は、セキュアなネットワークアクセス認証を提供するための標準化された方法を確立することです。利用場面としては、Wi-FiネットワークやVPN接続など、セキュリティが要求されるネットワーク環境での認証に適用されます。
Internet Engineering Task Force (IETF) J. Preuß Mattsson
Request for Comments: 9190 M. Sethi
Updates: 5216 Ericsson
Category: Standards Track February 2022
ISSN: 2070-1721
EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3
EAP-TLS 1.3：TLS 1.3を使用した拡張認証プロトコルの使用
Abstract
概要
The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216.
RFC 3748で定義されている拡張認証プロトコル（EAP）は、複数の認証方法をサポートするための標準的なメカニズムを提供します。このドキュメントは、EAP-TLSの既存の実装と互換性がある場合に、TLS 1.3を使用したEAP-TLSの使用を指定します。TLS 1.3は、TLSの以前のバージョンのTLSと比較して、セキュリティとプライバシーを大幅に向上させ、待ち時間を短縮します。TLS 1.3（EAP-TLS 1.3）を備えたEAP-TLSは、常に前方秘密を提供し、常にピアアイデンティティを開示しており、以前のバージョンのTLSを使用してEAP-TLSと比較した場合の失効確認の使用を義務付けることで、セキュリティとプライバシーをさらに向上させます。この文書では、一般的にEAP-TLSの認証、承認、および再開に関するガイダンス（使用される基盤となるTLSバージョンにかかわらず）。この文書はRFC 5216を更新します。
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/rfc9190.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9190で入手できます。
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
1.1. Requirements and Terminology
2. Protocol Overview
2.1. Overview of the EAP-TLS Conversation
2.1.1. Authentication
2.1.2. Ticket Establishment
2.1.3. Resumption
2.1.4. Termination
2.1.5. No Peer Authentication
2.1.6. Hello Retry Request
2.1.7. Identity
2.1.8. Privacy
2.1.9. Fragmentation
2.2. Identity Verification
2.3. Key Hierarchy
2.4. Parameter Negotiation and Compliance Requirements
2.5. EAP State Machines
3. Detailed Description of the EAP-TLS Protocol
4. IANA Considerations
5. Security Considerations
5.1. Security Claims
5.2. Peer and Server Identities
5.3. Certificate Validation
5.4. Certificate Revocation
5.5. Packet Modification Attacks
5.6. Authorization
5.7. Resumption
5.8. Privacy Considerations
5.9. Pervasive Monitoring
5.10. Discovered Vulnerabilities
5.11. Cross-Protocol Attacks
6. References
6.1. Normative References
6.2. Informative references
Appendix A. Updated References
Acknowledgments
Contributors
Authors' Addresses
The Extensible Authentication Protocol (EAP), defined in [RFC3748],
provides a standard mechanism for support of multiple authentication
methods. EAP-TLS [RFC5216] specifies an EAP authentication method
with certificate-based mutual authentication utilizing the TLS
handshake protocol for cryptographic algorithms and protocol version
negotiation and establishment of shared secret keying material. EAP-
TLS is widely supported for authentication and key establishment in
IEEE 802.11 [IEEE-802.11] (Wi-Fi) and IEEE 802.1AE [IEEE-802.1AE]
(MACsec) networks using IEEE 802.1X [IEEE-802.1X] and it's the
default mechanism for certificate-based authentication in 3GPP 5G
[TS.33.501] and MulteFire [MulteFire] networks. Many other 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 vendor-specific EAP methods such as the
Protected Extensible Authentication Protocol (PEAP) [PEAP], depend on
TLS and EAP-TLS.
EAP-TLS [RFC5216] references TLS 1.0 [RFC2246] and TLS 1.1 [RFC4346] but can also work with TLS 1.2 [RFC5246]. TLS 1.0 and 1.1 are formally deprecated and prohibited from being negotiated or used [RFC8996]. Weaknesses found in TLS 1.2 as well as new requirements for security, privacy, and reduced latency have led to the specification of TLS 1.3 [RFC8446], which obsoletes TLS 1.2 [RFC5246]. TLS 1.3 is in large part a complete remodeling of the TLS handshake protocol including a different message flow, different handshake messages, different key schedule, different cipher suites, different resumption mechanism, different privacy protection, and different record padding. This means that significant parts of the normative text in the previous EAP-TLS specification [RFC5216] are not applicable to EAP-TLS with TLS 1.3. Therefore, aspects such as resumption, privacy handling, and key derivation need to be appropriately addressed for EAP-TLS with TLS 1.3.
EAP-TLS [RFC5216]はTLS 1.0 [RFC2246]とTLS 1.1 [RFC4346]を参照しますが、TLS 1.2 [RFC5246]でも連携できます。TLS 1.0と1.1は正式に推奨されていて、ネゴシエートまたは使用されていることを禁止しています[RFC8996]。TLS 1.2で見つかった弱点、およびセキュリティ、プライバシー、および遅延のための新たな要件は、TLS 1.3 [RFC8446]の仕様をもたらし、TLS 1.2 [RFC5246]を廃止しました。TLS 1.3は大部分があり、異なるメッセージフロー、異なるハンドシェイクメッセージ、異なるキースケジュール、異なる暗号スイート、異なる再開メカニズム、異なるプライバシー保護、および異なるレコードパディングを含むTLSハンドシェイクプロトコルの完全な改造が大部分です。これは、前のEAP-TLS仕様[RFC5216]の規範的テキストの重要な部分がTLS 1.3を持つEAP-TLSには適用されません。したがって、再開、プライバシー処理、および鍵導出などの側面は、TLS 1.3を備えたEAP-TLSについて適切に扱われる必要があります。
This document updates [RFC5216] to define how to use EAP-TLS with TLS 1.3. When older TLS versions are negotiated, RFC 5216 applies to maintain backwards compatibility. However, this document does provide additional guidance on authentication, authorization, and resumption for EAP-TLS regardless of the underlying TLS version used. This document only describes differences compared to [RFC5216]. When EAP-TLS is used with TLS 1.3, some references are updated as specified in Appendix A. All message flows are example message flows specific to TLS 1.3 and do not apply to TLS 1.2. Since EAP-TLS couples the TLS handshake state machine with the EAP state machine, it is possible that new versions of TLS will cause incompatibilities that introduce failures or security issues if they are not carefully integrated into the EAP-TLS protocol. Therefore, implementations MUST limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator.
このドキュメントは[RFC5216]を更新して、TLS 1.3でEAP-TLSを使用する方法を定義します。古いTLSバージョンがネゴシエートされると、RFC 5216は後方互換性を維持するために適用されます。ただし、この文書は、使用される基礎となるTLSバージョンに関係なく、EAP-TLSの認証、承認、および再開に関する追加のガイダンスを提供します。この文書は[RFC5216]と比較して違いのみを説明します。EAP-TLSがTLS 1.3で使用されている場合、付録Aで指定されているようにいくつかの参照が更新されます。すべてのメッセージフローはTLS 1.3に固有のメッセージフローの例であり、TLS 1.2には適用されません。EAP-TLSはTLSハンドシェイクステートマシンをEAPステートマシンに結合するため、新しいバージョンのTLSがEAP-TLSプロトコルに慎重に統合されていない場合、失敗またはセキュリティ上の問題を導入する互換性を引き起こす可能性があります。したがって、実装は管理者によって明示的に有効になっていない限り、実装は最大のTLSバージョンを1.3に制限する必要があります。
This document specifies EAP-TLS 1.3 and does not specify how other TLS-based EAP methods use TLS 1.3. The specification for how other TLS-based EAP methods use TLS 1.3 is left to other documents such as [TLS-EAP-TYPES].
このドキュメントはEAP-TLS 1.3を指定し、他のTLSベースのEAPメソッドをTLS 1.3を使用する方法を指定しません。他のTLSベースのEAPメソッドを使用する方法については、[TLS-EAP-Types]などの他の文書に左右されます。
In addition to the improved security and privacy offered by TLS 1.3, there are other significant benefits of using EAP-TLS with TLS 1.3. Privacy, which in EAP-TLS means that no information about the underlying peer identity is disclosed, is mandatory and achieved without any additional round trips. Revocation checking is mandatory and simplified with Online Certificate Status Protocol (OCSP) stapling, and TLS 1.3 introduces more possibilities to reduce fragmentation when compared to earlier versions of TLS.
TLS 1.3が提供する改善されたセキュリティとプライバシーに加えて、TLS 1.3でEAP-TLSを使用するという他の大きな利点があります。EAP-TLSでは、基礎となるピアアイデンティティに関する情報が開示されていないことを意味し、追加のラウンドトリップなしで必須で達成されます。失効確認は必須であり、オンライン証明書ステータスプロトコル（OCSP）のステープル編では、TLS 1.3では、TLSの以前のバージョンと比較して断片化を減らす可能性が高まっています。
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-TLS [RFC5216] and TLS [RFC8446]. The term EAP-TLS peer is used for the entity acting as EAP peer and TLS client. The term EAP-TLS server is used for the entity acting as EAP server and TLS server.
読者はEAP-TLS [RFC5216]とTLS [RFC8446]で使用されている用語と概念に精通していると予想されます。EAP-TLSピアという用語は、EAP PeerおよびTLSクライアントとして機能するエンティティに使用されます。EAP-TLSサーバーという用語は、EAP ServerおよびTLSサーバーとして機能するエンティティに使用されます。
This document follows the terminology from [TLS-bis] where the master secret is renamed to the main secret and the exporter_master_secret is renamed to the exporter_secret.
この文書は[TLS-BIS]からマスターシークレットがメインシークレットに名前が変更され、exporter_master_secretがexporter_secretに変更されています。
This section updates Section 2.1 of [RFC5216] by amending it in accordance with the following discussion.
次の説明に従って、[RFC5216]のセクション2.1を更新します。
If the TLS implementation correctly implements TLS version negotiation, EAP-TLS will automatically leverage that capability. The EAP-TLS implementation needs to know which version of TLS was negotiated to correctly support EAP-TLS 1.3 as well as to maintain backward compatibility with EAP-TLS 1.2.
TLS実装がTLSバージョンネゴシエーションを正しく実装している場合、EAP-TLSは自動的にその機能を活用します。EAP-TLS実装は、EAP-TLS 1.3とEAP-TLS 1.2との下位互換性を維持するために、どのバージョンのTLSがネゴシエートされたかを知る必要があります。
TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS. Therefore, much of Section 2.1 of [RFC5216] does not apply for TLS 1.3. Except for Sections 2.2 and 5.7, this update applies only when TLS 1.3 is negotiated. When TLS 1.2 is negotiated, then [RFC5216] applies.
TLS 1.3は、以前のバージョンのTLSと比較して、メッセージフローとハンドシェイクメッセージの両方を変更します。したがって、[RFC5216]のセクション2.1の大部分はTLS 1.3には適用されません。セクション2.2と5.7を除いて、この更新プログラムはTLS 1.3がネゴシエートされている場合にのみ適用されます。TLS 1.2がネゴシエートされると、[RFC5216]が適用されます。
TLS 1.3 introduces several new handshake messages including HelloRetryRequest, NewSessionTicket, and KeyUpdate. In general, these messages will be handled by the underlying TLS libraries and are not visible to EAP-TLS; however, there are a few things to note:
TLS 1.3は、HelloretryRequest、NewsessionTicket、およびKeyUpdateを含むいくつかの新しいハンドシェイクメッセージを導入します。一般に、これらのメッセージは基礎となるTLSライブラリによって処理され、EAP-TLSには表示されません。ただし、注意するものはいくつかあります。
* The HelloRetryRequest is used by the server to reject the parameters offered in the ClientHello and suggest new parameters. When this message is encountered, it will increase the number of round trips used by the protocol.
* HelloretryRequestは、ClientHelloで提供されているパラメータを拒否し、新しいパラメータを提案するためにサーバーによって使用されます。このメッセージが見つかったとき、それはプロトコルによって使用される往復の数を増やすでしょう。
* The NewSessionTicket message is used to convey resumption information and is covered in Sections 2.1.2 and 2.1.3.
* NewSessionTicketメッセージは、再開情報を伝達するために使用され、2.1.2と2.1.3で説明されています。
* The KeyUpdate message is used to update the traffic keys used on a TLS connection. EAP-TLS does not encrypt significant amounts of data so this functionality is not needed. Implementations SHOULD NOT send this message; however, some TLS libraries may automatically generate and process this message.
* KeyUpdateメッセージは、TLS接続で使用されるトラフィックキーを更新するために使用されます。EAP-TLSはかなりの量のデータを暗号化しないため、この機能は不要です。実装はこのメッセージを送信しないでください。ただし、いくつかのTLSライブラリはこのメッセージを自動的に生成して処理することがあります。
* Early Data MUST NOT be used in EAP-TLS. EAP-TLS servers MUST NOT send an early_data extension and clients MUST NOT send an EndOfEarlyData message.
* EAP-TLSでは、初期のデータを使用しないでください。EAP-TLSサーバーは、Elegre_Data拡張機能を送信してはいけません。クライアントはEndoFearlyDataメッセージを送信してはなりません。
* Post-handshake authentication MUST NOT be used in EAP-TLS. Clients MUST NOT send a "post_handshake_auth" extension and Servers MUST NOT request post-handshake client authentication.
* Handshake認証後は、EAP-TLSでは使用しないでください。クライアントは「POST_HANDSHAKE_AUTH」の拡張子を送信してはいけませんし、サーバーはハンドシェイククライアント認証を要求してはいけません。
After receiving an EAP-Request packet with EAP-Type=EAP-TLS as described in [RFC5216], the conversation will continue with the TLS handshake protocol encapsulated in the data fields of EAP-Response and EAP-Request packets. When EAP-TLS is used with TLS version 1.3, the formatting and processing of the TLS handshake SHALL be done as specified in version 1.3 of TLS. This update only lists additional and different requirements, restrictions, and processing compared to [RFC8446] and [RFC5216].
[RFC5216]で説明されているようにEAP-TYPE = EAP-TLSを使用してEAP-REQUESTパケットを受信した後、会話はEAP-ResponseおよびEAP-Requestパケットのデータフィールドにカプセル化されているTLSハンドシェイクプロトコルを継続します。EAP-TLSがTLSバージョン1.3で使用されている場合、TLSハンドシェイクのフォーマットと処理はTLSのバージョン1.3で指定されているとおりに行われます。このアップデートでは、[RFC8446]と[RFC5216]と比較して、追加およびさまざまな要件、制限、および処理のみが一覧表示されます。
This section updates Section 2.1.1 of [RFC5216] by amending it in accordance with the following discussion.
このセクションは、次の説明に従って、[RFC5216]のセクション2.1.1を更新します。
The EAP-TLS server MUST authenticate with a certificate and SHOULD require the EAP-TLS peer to authenticate with a certificate. Certificates can be of any type supported by TLS including raw public keys. Pre-Shared Key (PSK) authentication SHALL NOT be used except for resumption. The full handshake in EAP-TLS with TLS 1.3 always provides forward secrecy by exchange of ephemeral "key_share" extensions in the ClientHello and ServerHello (e.g., containing Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) public keys). SessionID is deprecated in TLS 1.3; see Sections 4.1.2 and 4.1.3 of [RFC8446]. TLS 1.3 introduced early application data that like all application data (other than the protected success indication described below) is not used in EAP-TLS; see Section 4.2.10 of [RFC8446] for additional information on the "early_data" extension. Resumption is handled as described in Section 2.1.3. As a protected success indication [RFC3748], the EAP-TLS server always sends TLS application data 0x00; see Section 2.5. Note that a TLS implementation MAY not allow the EAP-TLS layer to control in which order things are sent and the application data MAY therefore be sent before a NewSessionTicket. TLS application data 0x00 is therefore to be interpreted as success after the EAP-Request that contains TLS application data 0x00. After the EAP-TLS server has sent an EAP-Request containing the TLS application data 0x00 and received an EAP-Response packet of EAP-Type=EAP-TLS and no data, the EAP-TLS server sends EAP-Success.
EAP-TLSサーバーは証明書を認証する必要があり、EAP-TLSピアが証明書を使用して認証する必要があります。証明書は、生の公開鍵を含むTLSでサポートされている任意の型のものです。プリシェアードキー（PSK）認証は、再開を除いて使用しないでください。 TLS 1.3を搭載したEAP-TLSのフルハンドシェイクは、ClientHelloおよびServerHello（例えば、エフェメラル楕円曲線Diffie-Hellman（ECDHE）の公開鍵を搭載したエフェメラル "key_share"拡張子を交換することによって常に前進秘密を提供します。 SessionIDはTLS 1.3で非推奨です。 [RFC8446]のセクション4.1.2と4.1.3を参照してください。 TLS 1.3は、すべてのアプリケーションデータと同じように（以下に説明されている保護された成功指示以外）と同様の早期アプリケーションデータがEAP-TLSでは使用されていません。 「Elegre_Data」拡張子の詳細については、[RFC8446]のセクション4.2.10を参照してください。再開はセクション2.1.3に記載されているように処理されます。保護された成功表示[RFC3748]として、EAP-TLSサーバーは常にTLSアプリケーションデータ0x00を送信します。セクション2.5を参照してください。 TLS実装は、EAP - TLSレイヤが送信された順序が送信され、したがってNewSessionTicketの前にアプリケーションデータを送信できるようにすることができないことに留意されたい。したがって、TLSアプリケーションデータ0x00が、TLSアプリケーションデータ0x00を含むEAP要求の後に成功として解釈されるべきである。 EAP-TLSサーバーがTLSアプリケーション・データ0x00を含むEAP-Requestを送信し、EAP-Type = EAP-TLSのEAP-Responseパケットを受信した後、EAP-TLSサーバーはEAP-SUCCESSを送信します。
Figure 1 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication (and neither HelloRetryRequest nor post-handshake messages are sent).
図1は、相互認証を伴う成功したEAP-TLSフルハンドシェイクの例示的なメッセージフローを示しています（およびHellOretryRequestもhandshakeメッセージも送信されません）。
EAP-TLS Peer EAP-TLS Server
EAP-TLSピアEAP-TLSサーバー
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Certificate,
TLS CertificateVerify,
TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
Figure 1: EAP-TLS Mutual Authentication
図1：EAP-TLS相互認証
This is a new section when compared to [RFC5216].
[RFC5216]と比較した場合、これは新しいセクションです。
To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS server MUST send one or more post-handshake NewSessionTicket messages (each associated with a PSK, a PSK identity, a ticket lifetime, and other parameters) in the initial authentication. Note that TLS 1.3 [RFC8446] limits the ticket lifetime to a maximum of 604800 seconds (7 days) and EAP-TLS servers MUST respect this upper limit when issuing tickets. The NewSessionTicket is sent after the EAP-TLS server has received the client Finished message in the initial authentication. The NewSessionTicket can be sent in the same flight as the TLS server Finished or later. The PSK associated with the ticket depends on the client Finished and cannot be pre-computed (so as to be sent in the same flight as the TLS server Finished) in handshakes with client authentication. The NewSessionTicket message MUST NOT include an "early_data" extension. If the "early_data" extension is received, then it MUST be ignored. Servers should take into account that fewer NewSessionTickets will likely be needed in EAP-TLS than in the usual HTTPS connection scenario. In most cases, a single NewSessionTicket will be sufficient. A mechanism by which clients can specify the desired number of tickets needed for future connections is defined in [TICKET-REQUESTS].
TLS 1.3を使用してEAP-TLSを使用するときの再開を有効にするには、EAP-TLSサーバーは1つ以上のハンドシェイクNewSessionTicketメッセージ（PSK、PSK ID、チケットの有効期間、その他のパラメーターに関連付けられている）を送信する必要があります。 。 TLS 1.3 [RFC8446]はチケットの有効期間を最大604800秒（7日）に制限し、チケットを発行するときにEAP-TLSサーバーはこの上限を尊重しなければなりません。 NewSessionTicketは、EAP-TLSサーバーが最初の認証でクライアント完了メッセージを受信した後に送信されます。 NewsessionTicketは、TLSサーバーと同じフライトで終了したのと同じフライトで送信できます。チケットに関連付けられているPSKは、クライアントが終了したクライアントに依存し、クライアント認証を持つハンドシェイクで事前計算されることはできません（TLSサーバーと同じ飛行中に送信されるように）。 NewSessionTicketメッセージには、拡張子が「elepent_data」の拡張子を含めないでください。 「elege_data」拡張子が受信された場合、それは無視される必要があります。サーバーは、通常のHTTPS接続シナリオよりもEAP-TLSで必要なニュースセッションチケットが少ないことを考慮に入れる必要があります。ほとんどの場合、単一のNewsessionTicketは十分です。クライアントが将来の接続に必要な希望の数のチケットを指定できるメカニズムは、[ticket-requests]で定義されています。
Figure 2 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication and ticket establishment of a single ticket.
図2は、単一のチケットの相互認証とチケットの確立を備えた、成功したEAP-TLSフルハンドシェイクのメッセージフローの例を示しています。
EAP-TLS Peer EAP-TLS Server
EAP-TLSピアEAP-TLSサーバー
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Certificate,
TLS CertificateVerify,
TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS NewSessionTicket,
<-------- (TLS Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
Figure 2: EAP-TLS Ticket Establishment
図2：EAP-TLSチケット設立
This section updates Section 2.1.2 of [RFC5216] by amending it in accordance with the following discussion.
このセクションは、次の説明に従って、[RFC5216]のセクション2.1.2を更新します。
EAP-TLS is typically used with client authentication and typically fragments the TLS flights into a large number of EAP-requests and EAP-responses. Resumption significantly reduces the number of round trips and enables the EAP-TLS server to omit database lookups needed during a full handshake with client authentication. TLS 1.3 replaces the session resumption mechanisms in earlier versions of TLS with a new PSK exchange. When EAP-TLS is used with TLS version 1.3, EAP-TLS SHALL use a resumption mechanism compatible with version 1.3 of TLS.
EAP-TLSは通常、クライアント認証とともに使用され、通常はTLSのフライトを多数のEAP-REQUESTSとEAP応答にフラグメント化します。再開は、往復の数を大幅に削減し、Client認証を使用したフルハンドシェイク中に必要なデータベース検索を省略することができます。TLS 1.3は、以前のバージョンのTLSのセッション再開メカニズムを新しいPSK Exchangeで置き換えます。EAP-TLSがTLSバージョン1.3で使用されている場合、EAP-TLSはTLSのバージョン1.3と互換性のある再開メカニズムを使用します。
For TLS 1.3, resumption is described in Section 2.2 of [RFC8446]. If the client has received a NewSessionTicket message from the EAP-TLS server, the client can use the PSK identity associated with the ticket to negotiate the use of the associated PSK. If the EAP-TLS server accepts it, then the resumed session has been deemed to be authenticated and securely associated with the prior authentication or resumption. It is up to the EAP-TLS peer to use resumption, but it is RECOMMENDED that the EAP-TLS peer use resumption if it has a valid ticket that has not been used before. It is left to the EAP-TLS server whether to accept resumption, but it is RECOMMENDED that the EAP-TLS server accept resumption if the ticket that was issued is still valid. However, the EAP-TLS server MAY choose to require a full handshake. In the case a full handshake is required, the negotiation proceeds as if the session was a new authentication, and the resumption attempt is ignored. The requirements of Sections 2.1.1 and 2.1.2 then apply in their entirety. As described in Appendix C.4 of [RFC8446], reuse of a ticket allows passive observers to correlate different connections. EAP-TLS peers and EAP-TLS servers SHOULD follow the client tracking preventions in Appendix C.4 of [RFC8446].
TLS 1.3の場合、再開は[RFC8446]のセクション2.2で説明されています。クライアントがEAP-TLSサーバーからNewSessionTicketメッセージを受信した場合、クライアントはチケットに関連付けられているPSK IDを使用して、関連するPSKの使用をネゴシエートできます。 EAP-TLSサーバーがそれを受け入れると、再開されたセッションは認証され、以前の認証または再開に安全に関連付けられていると見なされました。再開を使用するには、EAP-TLSピア次第ですが、これまでに使用されていない有効なチケットがある場合は、EAP-TLSピアの使用を再開することをお勧めします。それは再開を受け入れるかどうかをEAP-TLSサーバーに残されていますが、発行されたチケットがまだ有効である場合、EAP-TLSサーバーは再開を受け入れることをお勧めします。ただし、EAP-TLSサーバーはフルハンドシェイクを必要とすることを選択できます。フルハンドシェイクが必要な場合は、セッションが新しい認証であるかのように交渉が進み、再開試行は無視されます。セクション2.1.1および2.1.2の要件は、その後全体が適用されます。 [RFC8446]の付録C.4に記載されているように、チケットの再利用はパッシブオブザーバーを使用して異なる接続を相関させることができます。 EAP-TLSピアおよびEAP-TLSサーバーは、[RFC8446]の付録C.4のクライアント追跡防止に従うべきです。
It is RECOMMENDED to use Network Access Identifiers (NAIs) with the same realm during resumption and the original full handshake. This requirement allows EAP packets to be routed to the same destination as the original full handshake. If this recommendation is not followed, resumption is likely impossible. When NAI reuse can be done without privacy implications, it is RECOMMENDED to use the same NAI in the resumption as was used in the original full handshake [RFC7542]. For example, the NAI @realm can safely be reused since it does not provide any specific information to associate a user's resumption attempt with the original full handshake. However, reusing the NAI P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm enables an on-path attacker to associate a resumption attempt with the original full handshake. The TLS PSK identity is typically derived by the TLS implementation and may be an opaque blob without a routable realm. The TLS PSK identity on its own is therefore unsuitable as an NAI in the Identity Response.
再開中の同じレルムと元のフルハンドシェイクの間、ネットワークアクセス識別子（NAIS）を使用することをお勧めします。この要件により、EAPパケットを元のフルハンドシェイクと同じ宛先にルーティングできます。この勧告に従わないと、再開が不可能である可能性があります。プライバシーの影響なしにNAIの再利用を行うことができる場合は、元のフルハンドシェイク[RFC7542]で使用されていたのと同じNAIを使用することをお勧めします。たとえば、ユーザーの再開試行を元のフルハンドシェイクに関連付けるために、特定の情報が提供されないため、NAI @Realmは安全に再利用できます。ただし、NAI P2ZIM2F OEVAO21NNWG2BVPGNNU = @ REALMを再利用することで、ON-PATE攻撃者はオリジナルのフルハンドシェイクで再開試行を関連付けることができます。 TLS PSK IDは通常、TLS実装によって導出され、ルーブラブルレルムなしの不透明なBLOBであり得る。したがって、独自のTLS PSK IDは、ID応答のNAIとしては不適切です。
Figure 3 shows an example message flow for a subsequent successful EAP-TLS resumption handshake where both sides authenticate via a PSK provisioned via an earlier NewSessionTicket and where the server provisions a single new ticket.
図3は、両側が以前のNewsessionTicketを介してプロビジョニングされたPSKを介して認証され、サーバーが単一の新しいチケットを規定している場所で認証される、次の成功したEAP-TLS再開ハンドシェイクの例を示します。
EAP-TLS Peer EAP-TLS Server
EAP-TLSピアEAP-TLSサーバー
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello
+ pre_shared_key) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
<-------- TLS Finished,
TLS NewSessionTicket)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
Figure 3: EAP-TLS Resumption
図3：EAP-TLSの再開
As specified in Section 2.2 of [RFC8446], the EAP-TLS peer SHOULD supply a "key_share" extension when attempting resumption, which allows the EAP-TLS server to potentially decline resumption and fall back to a full handshake. If the EAP-TLS peer did not supply a "key_share" extension when attempting resumption, the EAP-TLS server needs to send a HelloRetryRequest to signal that additional information is needed to complete the handshake, and the EAP-TLS peer needs to send a second ClientHello containing that information. Providing a "key_share" and using the "psk_dhe_ke" pre-shared key exchange mode is also important in order to limit the impact of a key compromise. When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning that compromise of the PSK used for resumption does not compromise any earlier connections. The "psk_dh_ke" key exchange mode MUST be used for resumption unless the deployment has a local requirement to allow configuration of other mechanisms.
[RFC8446]のセクション2.2で指定されているように、EAP-TLSピアは再開を試みるときに「key_share」拡張子を指定します。これにより、EAP-TLSサーバは再開を遅くし、フルハンドシェイクに戻ることができます。再開を試みるときにEAP-TLSピアが拡張子が「key_share」拡張子を指定しなかった場合、EAP-TLSサーバーはハンドシェイクを完了するために追加情報が必要であることを知らせるためにHellOretryRequestを送信する必要があり、EAP-TLSピアはその情報を含む2番目のClientHello。「key_share」を提供し、「PSK_DHE_KE」を使用して、主な妥協の影響を制限するために、事前共有鍵交換モードも重要です。「PSK_DHE_KE」を使用する場合、TLS 1.3は前方秘密を提供します。これは、再開に使用されるPSKの妥協点が以前の接続を損なわないことを意味します。デプロイメントに他のメカニズムを設定するためのローカル要件がない限り、「PSK_DH_KE」キー交換モードを再開に使用する必要があります。
This section updates Section 2.1.3 of [RFC5216] by amending it in accordance with the following discussion.
次の説明に従って、[RFC5216]のセクション2.1.3を更新します。
TLS 1.3 changes both the message flow and the handshake messages compared to earlier versions of TLS. Therefore, some normative text in Section 2.1.3 of [RFC5216] does not apply for TLS 1.3. The two paragraphs below replace the corresponding paragraphs in Section 2.1.3 of [RFC5216] when EAP-TLS is used with TLS 1.3. The other paragraphs in Section 2.1.3 of [RFC5216] still apply with the exception that SessionID is deprecated.
TLS 1.3は、以前のバージョンのTLSと比較して、メッセージフローとハンドシェイクメッセージの両方を変更します。したがって、[RFC5216]のセクション2.1.3の節のテキストは、TLS 1.3には適用されません。以下の2つの段落は、EAP-TLSがTLS 1.3で使用されている場合、[RFC5216]のセクション2.1.3の対応する段落を置き換えます。[RFC5216]のセクション2.1.3のその他の段落は、SessionIDが推奨されていないことを除いて適用されます。
If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used. The message flow ends with a protected success indication from the EAP-TLS server, followed by an EAP-Response packet of EAP-Type=EAP-TLS and no data from the EAP-TLS peer, followed by EAP-Success from the server.
EAP-TLSピアが正常に認証された場合、EAP-TLSサーバーは、使用されているTLSのバージョンに準拠したTLSレコードを含むEAP-TYPE = EAP-TLSとEAP-REQUESTパケットを送信する必要があります。メッセージフローは、EAP-TLSサーバーからの保護された成功指示、その後にEAP-Type = EAP-TLSのEAP-Response PacketとEAP-TLSピアからのデータなしで終わり、その後にサーバーからEAP-SECESSIONが続きます。
If the EAP-TLS server authenticates successfully, the EAP-TLS peer MUST send an EAP-Response message with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used.
EAP-TLSサーバーが正常に認証されている場合、EAP-TLSピアは、使用されているTLSのバージョンに準拠したTLSレコードを含むEAP-TYPE = EAP-TLSにEAP-RESPONSEメッセージを送信する必要があります。
Figures 4, 5, and 6 illustrate message flows in several cases where the EAP-TLS peer or EAP-TLS server sends a TLS Error alert message. In earlier versions of TLS, error alerts could be warnings or fatal. In TLS 1.3, error alerts are always fatal and the only alerts sent at warning level are "close_notify" and "user_canceled", both of which indicate that the connection is not going to continue normally; see [RFC8446].
図4,5、および6は、EAP-TLSピアまたはEAP-TLSサーバーがTLSエラーアラートメッセージを送信する場合のメッセージフローを示しています。以前のバージョンのTLSでは、エラーアラートは警告または致命的である可能性があります。TLS 1.3では、エラーアラートは常に致命的なものであり、警告レベルで送信された唯一の警告は "close_notify"と "user_canceled"です。どちらも、接続が正常に続行されないことを示しています。[RFC8446]を参照してください。
In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a fatal error condition. Failure to send TLS Error alerts means that the peer or server would have no way of determining what went wrong. EAP-TLS 1.3 strengthens this requirement. Whenever an implementation encounters a fatal error condition, it MUST send an appropriate TLS Error alert.
TLS 1.3 [RFC8446]では、致命的なエラー状態の後に送信することは必須ではありません。TLSエラーアラートの送信に失敗すると、ピアまたはサーバーには何がうまくいかなかったかを判断する方法がないことを意味します。EAP-TLS 1.3はこの要件を強化します。実装が致命的なエラー状態に遭遇したときはいつでも、適切なTLSエラーアラートを送信する必要があります。
Figure 4 shows an example message flow where the EAP-TLS server rejects the ClientHello with an error alert. The EAP-TLS server can also partly reject the ClientHello with a HelloRetryRequest; see Section 2.1.6.
図4は、EAP-TLSサーバーがエラーアラートでClientHelloを拒否するメッセージフローの例を示しています。EAP-TLSサーバーは、HellORetryRequestを使用してClientHelloを一部拒否することもできます。セクション2.1.6を参照してください。
EAP-TLS Peer EAP-TLS Server
EAP-TLSピアEAP-TLSサーバー
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Error Alert)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Failure
Figure 4: EAP-TLS Server Rejection of ClientHello
図4：ClientHelloのEAP-TLSサーバーの拒否
Figure 5 shows an example message flow where EAP-TLS server authentication is unsuccessful and the EAP-TLS peer sends a TLS Error alert.
図5に、EAP-TLSサーバー認証が失敗し、EAP-TLSピアがTLSエラーアラートを送信する例示的なメッセージフローを示しています。
EAP-TLS Peer EAP-TLS Server
EAP-TLSピアEAP-TLSサーバー
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Error Alert)
-------->
<-------- EAP-Failure
Figure 5: EAP-TLS Unsuccessful EAP-TLS Server Authentication
図5：EAP-TLSの失敗EAP-TLSサーバー認証
Figure 6 shows an example message flow where the EAP-TLS server authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer fails to authenticate to the EAP-TLS server and the server sends a TLS Error alert.
図6は、EAP-TLSサーバーがEAP-TLSピアを正常に認証する例のメッセージフローを示していますが、EAP-TLSピアはEAP-TLSサーバーへの認証に失敗し、サーバーはTLSエラーアラートを送信します。
EAP-TLS Peer EAP-TLS Server
EAP-TLSピアEAP-TLSサーバー
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Certificate,
TLS CertificateVerify,
TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Error Alert)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Failure
Figure 6: EAP-TLS Unsuccessful Client Authentication
図6：EAP-TLSクライアント認証に失敗しました
This is a new section when compared to [RFC5216].
[RFC5216]と比較した場合、これは新しいセクションです。
Figure 7 shows an example message flow for a successful EAP-TLS full handshake without peer authentication (e.g., emergency services, as described in [RFC7406]).
図7は、ピア認証を行わない完全なハンドシェイク（例えば、[RFC7406]で説明されているように、緊急サービス）のための完全なフルハンドシェイクの例示的なメッセージフローを示しています。
EAP-TLS Peer EAP-TLS Server
EAP-TLSピアEAP-TLSサーバー
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
Figure 7: EAP-TLS without Peer Authentication
図7：ピア認証なしのEAP-TLS
This is a new section when compared to [RFC5216].
[RFC5216]と比較した場合、これは新しいセクションです。
As defined in TLS 1.3 [RFC8446], EAP-TLS servers can send a HelloRetryRequest message in response to a ClientHello if the EAP-TLS server finds an acceptable set of parameters but the initial ClientHello does not contain all the needed information to continue the handshake. One use case is if the EAP-TLS server does not support the groups in the "key_share" extension (or there is no "key_share" extension) but supports one of the groups in the "supported_groups" extension. In this case, the client should send a new ClientHello with a "key_share" that the EAP-TLS server supports.
TLS 1.3 [RFC8446]で定義されているように、EAP-TLSサーバーが許容可能なパラメーター・セットを見つけた場合は、ClientHelloに応答してHelloretryRequestメッセージを送信できますが、最初のClientHelloにはハンドシェイクを続けるためのすべての必要な情報が含まれていません。。1つのユースケースは、EAP-TLSサーバーが「key_share」拡張子内のグループをサポートしていない場合（または「key_share」拡張子はありません）が、「supported_groups」拡張子内のグループの1つをサポートしています。この場合、クライアントは、EAP-TLSサーバーがサポートしている「Key_Share」を使用して新しいClientHelloを送信する必要があります。
Figure 8 shows an example message flow for a successful EAP-TLS full handshake with mutual authentication and HelloRetryRequest. Note the extra round trip as a result of the HelloRetryRequest.
図8は、相互認証とHellORetryRequestを備えたEAP-TLSフルハンドシェイクの成功のメッセージフローの例を示しています。HelloretryRequestの結果としての余分な往復の旅行に注意してください。
EAP-TLS Peer EAP-TLS Server
EAP-TLSピアEAP-TLSサーバー
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS HelloRetryRequest)
<--------
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Certificate,
TLS CertificateVerify,
TLS Finished) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
Figure 8: EAP-TLS with Hello Retry Request
図8：Hello Retry要求付きのEAP-TLS
This is a new section when compared to [RFC5216].
[RFC5216]と比較した場合、これは新しいセクションです。
It is RECOMMENDED to use anonymous NAIs [RFC7542] in the Identity Response as such identities are routable and privacy-friendly. While opaque blobs are allowed by [RFC3748], such identities are NOT RECOMMENDED as they are not routable and should only be considered in local deployments where the EAP-TLS peer, EAP authenticator, and EAP-TLS server all belong to the same network. Many client certificates contain an identity such as an email address, which is already in NAI format. When the client certificate contains an NAI as subject name or alternative subject name, an anonymous NAI SHOULD be derived from the NAI in the certificate; see Section 2.1.8. More details on identities are described in Sections 2.1.3, 2.1.8, 2.2, and 5.8.
そのような識別情報がルーティング可能でプライバシーにやさしいものとして、ID応答で匿名のNAIS [RFC7542]を使用することをお勧めします。不透明なBLOBは[RFC3748]で許可されているが、そのような識別情報はルーティング可能ではなく、EAP-TLSピア、EAP Authenticator、およびEAP-TLSサーバーがすべて同じネットワークに属しているローカル展開でのみ検討されるべきです。多くのクライアント証明書には、電子メールアドレスなどのIDが含まれています。これは既にNAI形式にあります。クライアント証明書に件名または代替の件名としてNAIが含まれている場合、匿名NAIは証明書のNAIから派生する必要があります。セクション2.1.8を参照してください。アイデンティティの詳細については、2.1.3,2.1.8,2.2、および5.8のセクションで説明されています。
This section updates Section 2.1.4 of [RFC5216] by amending it in accordance with the following discussion.
次の説明に従って、[RFC5216]のセクション2.1.4を更新します。
EAP-TLS 1.3 significantly improves privacy when compared to earlier versions of EAP-TLS. EAP-TLS 1.3 forbids cipher suites without confidentiality, which means that TLS 1.3 is always encrypting large parts of the TLS handshake including the certificate messages.
EAP-TLS 1.3以前のバージョンのEAP-TLSと比較して、プライバシーを大幅に向上させます。EAP-TLS 1.3は機密性なしで暗号スイートを禁止します。つまり、TLS 1.3は常に証明書メッセージを含むTLSハンドシェイクの大部分を暗号化しています。
EAP-TLS peer and server implementations supporting TLS 1.3 MUST support anonymous Network Access Identifiers (NAIs) (Section 2.4 of [RFC7542]). A client supporting TLS 1.3 MUST NOT send its username (or any other permanent identifiers) in cleartext in the Identity Response (or any message used instead of the Identity Response). Following [RFC7542], it is RECOMMENDED to omit the username (i.e., the NAI is @realm), but other constructions such as a fixed username (e.g., anonymous@realm) or an encrypted username (e.g., xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm) are allowed. Note that the NAI MUST be a UTF-8 string as defined by the grammar in Section 2.2 of [RFC7542].
TLS 1.3をサポートするEAP-TLSピアおよびサーバーの実装は、匿名ネットワークアクセス識別子（NAIS）をサポートしている必要があります（[RFC7542]のセクション2.4）。TLS 1.3をサポートするクライアントは、ID応答（またはID応答の代わりに使用されたメッセージの代わりに使用されているメッセージ）で、そのユーザー名（または他の恒久的な識別子）をClearTextに送信してはなりません。[RFC7542]の後、ユーザー名（つまり、NAIが@REALM）を省略することをお勧めしますが、固定ユーザー名（例えば、匿名@レルムなど）や暗号化されたユーザー名などの他の構成（例：XCZINCPTK5 7Y81CRSBPG RKPE3OTRYLN4AQC4AC2U = @ REALM））許可されています。NAIは、[RFC7542]のセクション2.2の文法によって定義されたUTF-8文字列でなければなりません。
The HelloRequest message used for privacy in EAP-TLS 1.2 does not exist in TLS 1.3 but as the certificate messages in TLS 1.3 are encrypted, there is no need to send an empty certificate_list and perform a second handshake for privacy (as needed by EAP-TLS with earlier versions of TLS). When EAP-TLS is used with TLS version 1.3, the EAP-TLS peer and EAP-TLS server SHALL follow the processing specified by version 1.3 of TLS. This means that the EAP-TLS peer only sends an empty certificate_list if it does not have an appropriate certificate to send, and the EAP-TLS server MAY treat an empty certificate_list as a terminal condition.
EAP-TLS 1.2のプライバシーに使用されているHellOreQuestメッセージはTLS 1.3には存在しませんが、TLS 1.3の証明書メッセージは暗号化されているため、空の証明書を送信してプライバシーの2番目のハンドシェイクを実行する必要はありません（EAPで必要に応じて以前のバージョンのTLSを持つTLS）。EAP-TLSがTLSバージョン1.3で使用されている場合、EAP-TLSピアおよびEAP-TLSサーバーはTLSのバージョン1.3で指定された処理に従います。つまり、EAP-TLSピアは、適切な証明書が送信されていない場合にのみ、EAP-TLSサーバーが空の証明書を端末条件として扱うことがあります。
EAP-TLS with TLS 1.3 is always used with privacy. This does not add any extra round trips and the message flow with privacy is just the normal message flow as shown in Figure 1.
TLS 1.3を持つEAP-TLSは常にプライバシーで使用されています。これは余分な往復のトリップを追加するものではなく、プライバシーを持つメッセージフローは図1に示すように通常のメッセージフローだけです。
This section updates Section 2.1.5 of [RFC5216] by amending it in accordance with the following discussion.
このセクションは、次の説明に従って、[RFC5216]のセクション2.1.5を更新します。
Including ContentType (1 byte), ProtocolVersion (2 bytes), and length (2 bytes) headers, a single TLS record may be up to 16645 octets in length. EAP-TLS fragmentation support is provided through addition of a flags octet within the EAP-Response and EAP-Request packets, as well as a (conditional) TLS Message Length field of four octets. Implementations MUST NOT set the L bit in unfragmented messages, but they MUST accept unfragmented messages with and without the L bit set.
ContentType（1バイト）、ProtocolVersion（2バイト）、および長さ（2バイト）ヘッダーを含み、1つのTLSレコードの長さは最大16645オクテットです。EAP-TLSフラグメンテーションサポートは、EAP応答およびEAP要求パケット内のフラグオクテットを追加し、4オクテットの（条件付き）TLSメッセージ長フィールドを使用することによって提供されます。実装は訂正されていないメッセージでLビットを設定してはいけませんが、Lビットセットの有無にかかわらず無効になっているメッセージを受け入れる必要があります。
Some EAP implementations and access networks may limit the number of EAP packet exchanges that can be handled. To avoid fragmentation, it is RECOMMENDED to keep the sizes of EAP-TLS peer, EAP-TLS server, and trust anchor certificates small and the length of the certificate chains short. In addition, it is RECOMMENDED to use mechanisms that reduce the sizes of Certificate messages. For a detailed discussion on reducing message sizes to prevent fragmentation, see [RFC9191].
EAP実装とアクセスネットワークには、処理できるEAPパケット交換の数を制限する可能性があります。断片化を避けるために、EAP-TLSピア、EAP-TLSサーバー、およびトラストアンカー証明書のサイズを小さく、証明書チェーンの長さを短くすることをお勧めします。さらに、証明書メッセージのサイズを縮小するメカニズムを使用することをお勧めします。フラグメンテーションを防ぐためのメッセージサイズの短縮についての詳細な説明については、[RFC9191]を参照してください。
This section replaces Section 2.2 of [RFC5216] with the following discussion. The guidance in this section is relevant for EAP-TLS in general (regardless of the underlying TLS version used).
このセクションでは、[RFC5216]のセクション2.2に置き換えられます。このセクションのガイダンスは、一般的にEAP-TLS（使用される基礎となるTLSバージョンに関係なく）に関連しています。
The EAP peer identity provided in the EAP-Response/Identity is not authenticated by EAP-TLS. Unauthenticated information MUST NOT be used for accounting purposes or to give authorization. The authenticator and the EAP-TLS server MAY examine the identity presented in EAP-Response/Identity for purposes such as routing and EAP method selection. EAP-TLS servers MAY reject conversations if the identity does not match their policy. Note that this also applies to resumption; see Sections 2.1.3, 5.6, and 5.7.
EAP-Response / IDで提供されているEAPピアIDは、EAP-TLSによって認証されません。認証されていない情報は、会計上の目的で、または権限を与えるために使用してはいけません。オーセンティケータとEAP-TLSサーバーは、ルーティングやEAPメソッドの選択などの目的で、EAP応答/ IDに表示されているIDを調べることができます。IDがポリシーと一致しない場合、EAP-TLSサーバーは会話を拒否することがあります。これは再開にも適用されます。セクション2.1.3,5.6、および5.7を参照してください。
The EAP server identity in the TLS server certificate is typically a fully qualified domain name (FQDN) in the SubjectAltName (SAN) extension. Since EAP-TLS deployments may use more than one EAP server, each with a different certificate, EAP peer implementations SHOULD allow for the configuration of one or more trusted root certificates (CA certificate) to authenticate the server certificate and one or more server names to match against the SubjectAltName (SAN) extension in the server certificate. If any of the configured names match any of the names in the SAN extension, then the name check passes. To simplify name matching, an EAP-TLS deployment can assign a name to represent an authorized EAP server and EAP Server certificates can include this name in the list of SANs for each certificate that represents an EAP-TLS server. If server name matching is not used, then it degrades the confidence that the EAP server with which it is interacting is authoritative for the given network. If name matching is not used with a public root CA, then effectively any server can obtain a certificate that will be trusted for EAP authentication by the peer. While this guidance to verify domain names is new, and was not mentioned in [RFC5216], it has been widely implemented in EAP-TLS peers. As such, it is believed that this section contains minimal new interoperability or implementation requirements on EAP-TLS peers and can be applied to earlier versions of TLS.
TLSサーバー証明書のEAPサーバーのIDは、通常、SubjectalTNAME（SAN）拡張子内の完全修飾ドメイン名（FQDN）です。 EAP-TLSの展開は、それぞれ異なる証明書を持つ複数のEAPサーバーを使用することができるので、EAPピアの実装は1つ以上の信頼されたルート証明書（CA証明書）の設定を許可する必要があります（CA証明書）、サーバー証明書と1つ以上のサーバー名を認証する必要があります。サーバー証明書のSubjectalTname（SAN）拡張子と一致します。設定された名前のいずれかがSAN拡張子内のいずれかの名前と一致する場合は、名前チェックがパスを渡します。名前一致を簡単にするために、EAP-TLS展開は、許可されたEAPサーバーを表す名前を割り当てることができ、EAPサーバー証明書はEAP-TLSサーバーを表す各証明書のSANのリストにこの名前を含めることができます。サーバー名の一致が使用されていない場合、それが対話しているEAPサーバーが与えられたネットワークにとって権威あるという信頼性を低下させます。名前の一致が公共のルートCAと共に使用されていない場合、効果的にサーバーはピアによるEAP認証に信頼される証明書を取得できます。ドメイン名を検証するためのこのガイダンスは新規であり、[RFC5216]では言及されていなかったが、それはEAP-TLSピアで広く実装されています。このように、このセクションにはEAP-TLSピアの新しい相互運用性または実装要件が最小限にあり、TLSの以前のバージョンに適用できます。
The process of configuring a root CA certificate and a server name is non-trivial; therefore, automated methods of provisioning are RECOMMENDED. For example, the eduroam federation [RFC7593] provides a Configuration Assistant Tool (CAT) to automate the configuration process. In the absence of a trusted root CA certificate (user configured or system-wide), EAP peers MAY implement a trust on first use (TOFU) mechanism where the peer trusts and stores the server certificate during the first connection attempt. The EAP peer ensures that the server presents the same stored certificate on subsequent interactions. Use of a TOFU mechanism does not allow for the server certificate to change without out-of-band validation of the certificate and is therefore not suitable for many deployments including ones where multiple EAP servers are deployed for high availability. TOFU mechanisms increase the susceptibility to traffic interception attacks and should only be used if there are adequate controls in place to mitigate this risk.
ルートCA証明書とサーバー名を設定するプロセスは非些細なことです。したがって、プロビジョニングの自動化方法が推奨されています。たとえば、EDUROAMフェデレーション[RFC7593]は、構成プロセスを自動化するための構成アシスタントツール（CAT）を提供します。信頼できるルートCA証明書（ユーザー構成またはシステム全体）がない場合、EAPピアは最初の接続試行中にピアが信頼し、サーバー証明書を格納している最初の使用（TOFU）メカニズムに関する信頼を実装することができます。 EAPピアは、サーバーが後続の対話で同じ保存された証明書を提示するようにします。豆腐メカニズムの使用は、証明書の帯域外の検証なしにサーバー証明書を変更することはできず、したがって、複数のEAPサーバーが高可用性のためにデプロイされているものを含む多くの展開には適していません。豆腐メカニズムは、交通遮断攻撃に対する感受性を高め、このリスクを軽減するための適切なコントロールがある場合にのみ使用されるべきです。
This section updates Section 2.3 of [RFC5216] by replacing it in accordance with the following discussion.
次の説明に従って、[RFC5216]のセクション2.3を更新します。
TLS 1.3 replaces the TLS pseudorandom function (PRF) used in earlier versions of TLS with the HMAC-based Key Derivation Function (HKDF) and completely changes the key schedule. The key hierarchies shown in Section 2.3 of [RFC5216] are therefore not correct when EAP-TLS is used with TLS version 1.3. For TLS 1.3 the key schedule is described in Section 7.1 of [RFC8446].
TLS 1.3以前のバージョンのTLSで使用されているTLS疑似andom関数（PRF）をHMACベースのキー導出関数（HKDF）で置き換え、キースケジュールを完全に変更します。したがって、[RFC5216]のセクション2.3に示されているキー階層は、TLSバージョン1.3でEAP-TLSが使用されている場合は正しくありません。TLS 1.3キースケジュールは[RFC8446]のセクション7.1で説明されています。
When EAP-TLS is used with TLS version 1.3, the Key_Material and Method-Id SHALL be derived from the exporter_secret using the TLS exporter interface [RFC5705] (for TLS 1.3, this is defined in Section 7.5 of [RFC8446]). Type is the value of the EAP Type field defined in Section 2 of [RFC3748]. For EAP-TLS, the Type field has value 0x0D.
EAP-TLSがTLSバージョン1.3で使用されている場合、key_materialとmethod-idはTLSエクスポターインターフェイス[RFC5705]を使用してexporter_secretから派生します（TLS 1.3の場合は、[RFC8446]のセクション7.5で定義されています）。typeは、[RFC3748]のセクション2で定義されているEAP Typeフィールドの値です。EAP-TLSの場合、TYPEフィールドは値0x0Dです。
Type = 0x0D Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", Type, 128) Method-Id = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id", Type, 64) Session-Id = Type || Method-Id
type = 0x0d key_material = tls-exporter（ "exporter_eap_tls_key_material"、type、128）method-id = tls-exporter（ "exporter_eap_tls_method-id"、type、64）session-id = type ||メソッドID
The MSK and EMSK are derived from the Key_Material in the same manner as with EAP-TLS [RFC5216], Section 2.3. The definitions are repeated below for simplicity:
MSKとEMSKは、EAP-TLS [RFC5216]、セクション2.3と同じ方法でkey_materialから派生しています。簡単にするために定義は以下で繰り返されます。
MSK = Key_Material(0, 63)
EMSK = Key_Material(64, 127)
Other TLS-based EAP methods can use the TLS exporter in a similar fashion; see [TLS-EAP-TYPES].
他のTLSベースのEAPメソッドも同様の方法でTLSエクスポーターを使用できます。[TLS-EAP-Type]を参照してください。
[RFC5247] deprecates the use of an Initialization Vector (IV). Thus, RECV-IV and SEND-IV are not exported in EAP-TLS with TLS 1.3. As noted in [RFC5247], lower layers use the MSK in a lower-layer-dependent manner. EAP-TLS with TLS 1.3 exports the MSK and does not specify how it is used by lower layers.
[RFC5247]初期化ベクトル（IV）の使用を廃止する。したがって、RECV-IVとSend-IVは、TLS 1.3でEAP-TLSでエクスポートされません。[RFC5247]で述べたように、下位層はより低い層に依存してMSKを使用します。TLS 1.3のEAP-TLSはMSKをエクスポートし、下位レイヤーで使用される方法を指定しません。
Note that the key derivation MUST use the length values given above. While in TLS 1.2 and earlier it was possible to truncate the output by requesting less data from the TLS-Exporter function, this practice is not possible with TLS 1.3. If an implementation intends to use only a part of the output of the TLS-Exporter function, then it MUST ask for the full output and then only use the desired part. Failure to do so will result in incorrect values being calculated for the above keying material.
キーの導出は上記の長さの値を使用しなければならないことに注意してください。TLS 1.2以前では、TLS-Exporter関数からのデータが少ないことで出力を切り捨てることが可能であったが、TLS 1.3ではこの練習は不可能です。実装がTLS-Exporter関数の出力の一部のみを使用する予定の場合は、フル出力を要求してから目的の部分を使用するだけです。そうしないと、上記のキーイング材料について誤った値が計算されます。
By using the TLS exporter, EAP-TLS can use any TLS 1.3 implementation that provides a public API for the exporter. Note that when TLS 1.2 is used with the EAP-TLS exporter [RFC5705] it generates the same key material as in EAP-TLS [RFC5216].
TLSエクスポータを使用することによって、EAP-TLSはエクスポーターのパブリックAPIを提供する任意のTLS 1.3実装を使用できます。EAP-TLS Exporter [RFC5705]でTLS 1.2を使用している場合[RFC5216]と同じキーマテリアルを生成します。
This section updates Section 2.4 of [RFC5216] by amending it in accordance with the following discussion.
次の説明に従って、[RFC5216]のセクション2.4を更新します。
TLS 1.3 cipher suites are defined differently than in earlier versions of TLS (see Appendix B.4 of [RFC8446]), and the cipher suites discussed in Section 2.4 of [RFC5216] can therefore not be used when EAP-TLS is used with TLS version 1.3.
TLS 1.3暗号スイートは、以前のバージョンのTLSよりも異なる定義されています（[RFC8446]の付録B.4を参照）、[RFC5216]のセクション2.4で説明されている暗号スイートは、TLSで使用されている場合は使用できません。バージョン1.3。
When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP-TLS servers MUST comply with the compliance requirements (mandatory-to-implement cipher suites, signature algorithms, key exchange algorithms, extensions, etc.) defined in Section 9 of [RFC8446]. In EAP-TLS with TLS 1.3, only cipher suites with confidentiality SHALL be supported.
EAP-TLSがTLSバージョン1.3で使用されている場合、EAP-TLSピアおよびEAP-TLSサーバーはコンプライアンス要件（必須の暗号化スイート、署名アルゴリズム、鍵交換アルゴリズム、拡張機能など）に準拠している必要があります。[RFC8446]の第9章。TLS 1.3を搭載したEAP-TLSでは、機密性のある暗号スイートのみをサポートします。
While EAP-TLS does not protect any application data except for the 0x00 byte that serves as protected success indication, the negotiated cipher suites and algorithms MAY be used to secure data as done in other TLS-based EAP methods.
EAP-TLSは、保護された成功指示として機能する0x00バイトを除くすべてのアプリケーションデータを保護しませんが、ネゴシエートされた暗号スイートとアルゴリズムを使用して、他のTLSベースのEAPメソッドで行われるようにデータを保護することができます。
This is a new section when compared to [RFC5216] and only applies to TLS 1.3. [RFC4137] offers a proposed state machine for EAP.
これは[RFC5216]と比較され、TLS 1.3にのみ適用される場合にのみ新しいセクションです。[RFC4137] EAP用の提案されたステートマシンを提供しています。
TLS 1.3 [RFC8446] introduces post-handshake messages. These post-handshake messages use the handshake content type and can be sent after the main handshake. Examples of post-handshake messages are NewSessionTicket, which is used for resumption and KeyUpdate, which is not useful and not expected in EAP-TLS. After sending TLS Finished, the EAP-TLS server may send any number of post-handshake messages in one or more EAP-Requests.
TLS 1.3 [RFC8446]は、握手のメッセージを紹介します。これらのハンドシェークメッセージはハンドシェイクコンテンツタイプを使用し、メインハンドシェイクの後に送信できます。handshakeメッセージの例はNewSessionTicketです。これは、再開およびkeyUpdateに使用されます。TLSが終了した後、EAP-TLSサーバーは1つ以上のEAP要求で任意の数のハンドシェイクメッセージを送信することがあります。
To provide a protected success result indication and to decrease the uncertainty for the EAP-TLS peer, the following procedure MUST be followed:
保護された成功結果表示を提供し、EAP-TLSピアの不確実性を減らすには、次の手順に従う必要があります。
When an EAP-TLS server has successfully processed the TLS client Finished and sent its last handshake message (Finished or a post-handshake message), it sends an encrypted TLS record with application data 0x00. The encrypted TLS record with application data 0x00 is a protected success result indication, as defined in [RFC3748]. After sending an EAP-Request that contains the protected success result indication, the EAP-TLS server must not send any more EAP-Requests and may only send an EAP-Success. The EAP-TLS server MUST NOT send an encrypted TLS record with application data 0x00 before it has successfully processed the client Finished and sent its last handshake message.
EAP-TLSサーバーが完成したTLSクライアントを正常に処理し、最後のハンドシェイク・メッセージを送信した（完成または握手・メッセージ）の場合、アプリケーション・データ0x00で暗号化されたTLSレコードを送信します。アプリケーションデータ0x00を含む暗号化されたTLSレコードは、[RFC3748]で定義されているように、保護された成功結果表示です。保護された成功結果表示を含むEAP-REQUESTを送信した後、EAP-TLSサーバーはそれ以上のEAP要求を送信してはならず、EAP-SUCCESSを送信するだけです。EAP-TLSサーバーは、クライアントが終了した最後のハンドシェイクメッセージを正常に処理する前に、アプリケーションデータ0x00で暗号化されたTLSレコードを送信してはいけません。
TLS Error alerts SHOULD be considered a failure result indication, as defined in [RFC3748]. Implementations following [RFC4137] set the alternate indication of failure variable altReject after sending or receiving an error alert. After sending or receiving a TLS Error alert, the EAP-TLS server may only send an EAP-Failure. Protected TLS Error alerts are protected failure result indications, and unprotected TLS Error alerts are not.
[RFC3748]で定義されているように、TLSエラーアラートは障害結果表示と見なすべきです。[RFC4137]の実装[RFC4137]エラーアラートを送信または受信した後に、障害変数Altrijectの代替表示を設定します。TLSエラーアラートを送信または受信した後、EAP-TLSサーバーはEAP障害のみを送信できます。Protected TLSエラーアラートは保護された障害結果の指示であり、保護されていないTLSエラーアラートはそうではありません。
The keying material can be derived after the TLS server Finished has been sent or received. Implementations following [RFC4137] can then set the eapKeyData and aaaEapKeyData variables.
キーイングマテリアルは、TLSサーバが終了した後に送信または受信された後に導出することができる。[RFC4137]に続く実装は、EAPKEYDATAおよびAAAEAPKEYDATA変数を設定できます。
The keying material can be made available to lower layers and the authenticator after the authenticated success result indication has been sent or received. Implementations following [RFC4137] can set the eapKeyAvailable and aaaEapKeyAvailable variables.
認証された成功結果表示が送受信された後に、キーイング材料を下位層およびオーセンティケータに利用できるようにすることができる。[RFC4137]に続く実装は、EAPKEYAVAILABLEABLEABLEABLABLEABLEVERBLESを設定できます。
There are no updates to Section 3 of [RFC5216].
[RFC5216]のセクション3への更新はありません。
This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to EAP-TLS 1.3 in accordance with [RFC8126].
このセクションでは、[RFC8126]に従って、EAP-TLS 1.3に関連する値の登録に関するインターネット割り当てられた番号局（IANA）へのガイダンスについて説明します。
Per this document, IANA has added the following labels to the "TLS Exporter Labels" registry defined by [RFC5705]. These labels are used in derivation of Key_Material and Method-Id as defined in Section 2.3:
このドキュメントごとに、IANAは[RFC5705]によって定義された「TLSエクスポータラベル」レジストリに次のラベルを追加しました。これらのラベルは、セクション2.3で定義されているkey_materialおよびmethod-idの派生に使用されます。
+===============================+=========+=============+======+
| Value | DTLS-OK | Recommended | Note |
+===============================+=========+=============+======+
| EXPORTER_EAP_TLS_Key_Material | N | Y | |
+-------------------------------+---------+-------------+------+
| EXPORTER_EAP_TLS_Method-Id | N | Y | |
+-------------------------------+---------+-------------+------+
Table 1: TLS Exporter Labels
表1：TLSエクスポーターラベル
The security considerations of TLS 1.3 [RFC8446] apply to EAP-TLS 1.3.
TLS 1.3 [RFC8446]のセキュリティ上の考慮事項はEAP-TLS 1.3に適用されます。
Using EAP-TLS with TLS 1.3 does not change the security claims for EAP-TLS as given in Section 5.1 of [RFC5216]. However, it strengthens several of the claims as described in the following updates to the notes given in Section 5.1 of [RFC5216].
TLS 1.3でEAP-TLSを使用すると、[RFC5216]のセクション5.1で示すように、EAP-TLSのセキュリティクレームは変更されません。ただし、[RFC5216]のセクション5.1に記載されている注記の下記の更新で説明されているような、請求項のうちのいくつかを強化します。
[1] Mutual authentication: By mandating revocation checking of certificates, the authentication in EAP-TLS with TLS 1.3 is stronger as authentication with revoked certificates will always fail.
[1] 相互認証：証明書の失効確認を命令することによって、失効した証明書を持つ認証が常に失敗するため、TLS 1.3を持つEAP-TLSの認証は強くなります。
[2] Confidentiality: The TLS 1.3 handshake offers much better confidentiality than earlier versions of TLS. EAP-TLS with TLS 1.3 mandates use of cipher suites that ensure confidentiality. TLS 1.3 also encrypts certificates and some of the extensions. When using EAP-TLS with TLS 1.3, the use of privacy is mandatory and does not cause any additional round trips.
[2] 機密性：TLS 1.3ハンドシェイクは、以前のバージョンのTLSよりもはるかに優れた機密性を提供します。TLS 1.3のEAP-TLSは、機密性を保証する暗号スイートの使用を義務付けています。TLS 1.3はまた証明書といくつかの拡張機能を暗号化します。TLS 1.3でEAP-TLSを使用する場合、プライバシーの使用は必須であり、追加の往復も発生しません。
[3] Cryptographic strength: TLS 1.3 only defines strong algorithms without major weaknesses and EAP-TLS with TLS 1.3 always provides forward secrecy; see [RFC8446]. Weak algorithms such as 3DES, CBC mode, RC4, SHA-1, MD5, P-192, and RSA-1024 have not been registered for use in TLS 1.3.
[3] 暗号強度：TLS 1.3は、大きな弱点なしで強力なアルゴリズムを定義し、TLS 1.3を持つEAP-TLSは常に前進秘密を提供します。[RFC8446]を参照してください。3DES、CBCモード、RC4、SHA-1、MD5、P-192、およびRSA-1024などの弱いアルゴリズムは、TLS 1.3で使用するために登録されていません。
[4] Cryptographic negotiation: The TLS layer handles the negotiation of cryptographic parameters. When EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic negotiation of the AEAD algorithm, HKDF hash algorithm, key exchange groups, and signature algorithm; see Section 4.1.1 of [RFC8446].
[4] 暗号化ネゴシエーション：TLSレイヤは暗号化パラメータのネゴシエーションを処理します。EAP-TLSがTLS 1.3で使用されている場合、EAP-TLSは、AEDアルゴリズム、HKDFハッシュアルゴリズム、キー交換グループ、および署名アルゴリズムの暗号化ネゴシエーションを継承します。[RFC8446]のセクション4.1.1を参照してください。
No updates to Section 5.2 of [RFC5216]. Note that Section 2.2 has additional discussion on identities.
[RFC5216]のセクション5.2の更新はありません。セクション2.2にはIDに関する追加の説明があります。
No updates to Section 5.3 of [RFC5216]. In addition to Section 5.3 of [RFC5216], guidance on server certificate validation can be found in [RFC6125].
[RFC5216]のセクション5.3の更新はありません。[RFC5216]のセクション5.3に加えて、サーバー証明書の検証に関するガイダンスは[RFC6125]にあります。
This section updates Section 5.4 of [RFC5216] by amending it in accordance with the following discussion.
次の説明に従って、[RFC5216]のセクション5.4を更新します。
There are a number of reasons (e.g., key compromise, CA compromise, privilege withdrawn, etc.) why EAP-TLS peer, EAP-TLS server, or sub-CA certificates have to be revoked before their expiry date. Revocation of the EAP-TLS server's certificate is complicated by the fact that the EAP-TLS peer may not have Internet connectivity until authentication completes.
多くの理由（例えば、主要妥協、CA妥協、特権引き出しなど）が、その有効期限の前にEAP-TLSピア、EAP-TLSサーバー、またはサブCA証明書を取り消す必要がある理由がいくつかあります。EAP-TLSサーバーの証明書の失効は、認証が完了するまでEAP-TLSピアがインターネット接続を持たない可能性があるという事実によって複雑です。
When EAP-TLS is used with TLS 1.3, the revocation status of all the certificates in the certificate chains MUST be checked (except the trust anchor). An implementation may use the Certificate Revocation List (CRL), Online Certificate Status Protocol (OSCP), or other standardized/proprietary methods for revocation checking. Examples of proprietary methods are non-standard formats for distribution of revocation lists as well as certificates with very short lifetime.
EAP-TLSがTLS 1.3で使用されている場合、証明書チェーン内のすべての証明書の失効状態を確認する必要があります（信頼アンカーを除く）。実装は、証明書失効リスト（CRL）、オンライン証明書ステータスプロトコル（OSCP）、または失効検査のためのその他の標準化された/独自の方法を使用することがあります。独自の方法の例は、失効リストの配布および非常に短い寿命の証明書のための標準的なフォーマットです。
EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status Requests (OCSP stapling) as specified in [RFC6066] and Section 4.4.2.1 of [RFC8446]. It is RECOMMENDED that EAP-TLS peers and EAP-TLS servers use OCSP stapling for verifying the status of the EAP-TLS server's certificate chain. When an EAP-TLS peer uses Certificate Status Requests to check the revocation status of the EAP-TLS server's certificate chain, it MUST treat a CertificateEntry (but not the trust anchor) without a valid CertificateStatus extension as invalid and abort the handshake with an appropriate alert. The OCSP status handling in TLS 1.3 is different from earlier versions of TLS; see Section 4.4.2.1 of [RFC8446]. In TLS 1.3, the OCSP information is carried in the CertificateEntry containing the associated certificate instead of a separate CertificateStatus message as in [RFC6066]. This enables sending OCSP information for all certificates in the certificate chain (except the trust anchor).
TLS 1.3をサポートするEAP-TLSサーバー[RFC6066]および[RFC8446]の[4.4.2.1]の[4.4.2.1]の[4.4.2.1]で証明書ステータス要求（OCSPステイプルリング）を実装する必要があります。EAP-TLSピアおよびEAP-TLSサーバーは、EAP-TLSサーバーの証明書チェーンのステータスを検証するためにOCSPステープルを使用することをお勧めします。EAP-TLSピアが証明書ステータス要求を使用してEAP-TLSサーバーの証明書チェーンの失効状態を確認する場合は、有効なCertificateStatus拡張を無効として無効として（信頼アンカーではない）を扱う必要があります。警戒します。TLS 1.3のOCSPステータス処理は、以前のバージョンのTLSとは異なります。[RFC8446]の4.4.2.1項を参照してください。TLS 1.3では、OCSP情報は[RFC6066]のように別のCertificateStatusメッセージの代わりに関連証明書を含む証明書エントリで運ばれます。これにより、証明書チェーン内のすべての証明書のOCSP情報を送信できます（信頼アンカーを除く）。
To enable revocation checking in situations where EAP-TLS peers do not implement or use OCSP stapling, and where network connectivity is not available prior to authentication completion, EAP-TLS peer implementations MUST also support checking for certificate revocation after authentication completes and network connectivity is available. An EAP peer implementation SHOULD NOT trust the network (and any services) until it has verified the revocation status of the server certificate after receiving network connectivity. An EAP peer MUST use a secure transport to verify the revocation status of the server certificate. An EAP peer SHOULD NOT send any other traffic before revocation checking for the server certificate is complete.
EAP-TLSピアがOCSPステイプルを実装または使用しない状況での失効確認を可能にする認証完了の前に、EAP-TLSピアの実装は、認証の完了とネットワーク接続が完了した後も証明書の失効のチェックをサポートする必要があります。利用可能。EAPピアの実装は、ネットワーク接続を受信した後にサーバー証明書の失効状態を確認するまで、ネットワーク（および任意のサービス）を信頼しないでください。EAPピアは安全なトランスポートを使用して、サーバー証明書の失効状態を確認する必要があります。EAPピアは、サーバー証明書の失効確認が完了する前に他のトラフィックを送信しないでください。
This section updates Section 5.5 of [RFC5216] by amending it in accordance with the following discussion.
次の説明に従って、[RFC5216]のセクション5.5を更新します。
As described in [RFC3748] and Section 5.5 of [RFC5216], the only information that is integrity and replay protected in EAP-TLS are the parts of the TLS Data that TLS protects. All other information in the EAP-TLS message exchange including EAP-Request and EAP-Response headers, the identity in the Identity Response, EAP-TLS packet header fields, Type, Flags, EAP-Success, and EAP-Failure can be modified, spoofed, or replayed.
[RFC5216]の[RFC3748]とセクション5.5で説明されているように、EAP-TLSで保護されている整合性と再生のみがTLSが保護するTLSデータの一部です。EAP-RequestヘッダーとEAP-Response Headersを含むEAP-TLSメッセージ交換の他のすべての情報、ID応答のID、EAP-TLS Packet Headerフィールド、タイプ、フラグ、EAP-SUCCESS、およびEAP障害を変更できます。なりすまし、または再生された。
Protected TLS Error alerts are protected failure result indications and enable the EAP-TLS peer and EAP-TLS server to determine that the failure result was not spoofed by an attacker. Protected failure result indications provide integrity and replay protection but MAY be unauthenticated. Protected failure results do not significantly improve availability as TLS 1.3 treats most malformed data as a fatal error.
Protected TLSエラーアラートは、保護された障害結果の指示であり、EAP-TLSピアおよびEAP-TLSサーバーが攻撃者によって偽装されていないと判断することができます。保護された失敗結果表示は、完全性と再生保護を提供しますが、認証されていない可能性があります。TLS 1.3が最も不正な形式のデータを致命的なエラーとして扱うため、保護された失敗結果は可用性を大幅に向上させません。
This is a new section when compared to [RFC5216]. The guidance in this section is relevant for EAP-TLS in general (regardless of the underlying TLS version used).
[RFC5216]と比較した場合、これは新しいセクションです。このセクションのガイダンスは、一般的にEAP-TLS（使用される基礎となるTLSバージョンに関係なく）に関連しています。
EAP servers will usually require the EAP peer to provide a valid certificate and will fail the connection if one is not provided. Some deployments may permit no peer authentication for some or all connections. When peer authentication is not used, EAP-TLS server implementations MUST take care to limit network access appropriately for unauthenticated peers, and implementations MUST use resumption with caution to ensure that a resumed session is not granted more privilege than was intended for the original session. An example of limiting network access would be to invoke a vendor's walled garden or quarantine network functionality.
EAPサーバーは通常、EAPピアが有効な証明書を提供する必要があり、指定されていない場合は接続を失敗させます。一部の展開は、一部の接続またはすべての接続に対してピア認証を許可しない場合があります。ピア認証が使用されていない場合、EAP-TLSサーバーの実装は認証されていないピアに対してネットワークアクセスを適切に制限するように注意しなければならず、再開セッションが元のセッションを対象としたよりも多くの特権を与えられないようにするために慎重なセッションが許可されていないことを実装しなければなりません。ネットワークアクセスを制限する例は、ベンダーの壁に囲まれた庭園または隔離ネットワーク機能を呼び出すことです。
EAP-TLS is typically encapsulated in other protocols such as PPP [RFC1661], RADIUS [RFC2865], Diameter [RFC6733], or the Protocol for Carrying Authentication for Network Access (PANA) [RFC5191]. The encapsulating protocols can also provide additional, non-EAP information to an EAP-TLS server. This information can include, but is not limited to, information about the authenticator, information about the EAP-TLS peer, or information about the protocol layers above or below EAP (MAC addresses, IP addresses, port numbers, Wi-Fi Service Set Identifiers (SSIDs), etc.). EAP-TLS servers implementing EAP-TLS inside those protocols can make policy decisions and enforce authorization based on a combination of information from the EAP-TLS exchange and non-EAP information.
EAP-TLSは通常、PPP [RFC1661]、RADIUS [RFC2865]、直径[RFC6733]などの他のプロトコル、またはネットワークアクセス（PANA）[RFC5191]などのプロトコルにカプセル化されています。カプセル化プロトコルは、追加のEAP以外の情報をEAP-TLSサーバーに提供することもできます。この情報には、認証者に関する情報、EAP-TLSピアに関する情報、またはEAPの上または下のプロトコル層に関する情報（MACアドレス、IPアドレス、ポート番号、Wi-Fiサービスセット識別子）の情報を含めることができます。（SSID）など）。EAP-TLSサーバーは、それらのプロトコル内のEAP-TLSを実装することで、EAP-TLS ExchangeとEAP以外の情報からの情報の組み合わせに基づいて、ポリシーの決定と許可を強制することができます。
As noted in Section 2.2, the identity presented in EAP-Response/ Identity is not authenticated by EAP-TLS and is therefore trivial for an attacker to forge, modify, or replay. Authorization and accounting MUST be based on authenticated information such as information in the certificate or the PSK identity and cached data provisioned for resumption as described in Section 5.7. Note that the requirements for Network Access Identifiers (NAIs) specified in Section 4 of [RFC7542] still apply and MUST be followed.
セクション2.2に記載されているように、EAP-Response / IDに表示されているIDはEAP-TLSによって認証されず、したがって攻撃者が偽造、変更、または再生するための簡単です。認証と会計は、証明書内の情報やPSK IDなどの認証された情報と、セクション5.7で説明されているように再開のためにプロビジョニングされたキャッシュデータに基づいている必要があります。[RFC7542]のセクション4で指定されているネットワークアクセス識別子（NAIS）の要件は、まだ適用され、続いている必要があります。
EAP-TLS servers MAY reject conversations based on non-EAP information provided by the encapsulating protocol, for example if the MAC address of the authenticator does not match the expected policy.
EAP-TLSサーバは、例えば認証者のMACアドレスが予想ポリシーと一致しない場合など、カプセル化プロトコルによって提供される非EAP情報に基づいて会話を拒否することができる。
In addition to allowing configuration of one or more trusted root certificates (CA certificate) to authenticate the server certificate and one or more server names to match against the SubjectAltName (SAN) extension, EAP peer implementations MAY allow binding the configured acceptable SAN to a specific CA (or CAs) that should have issued the server certificate to prevent attacks from rogue or compromised CAs.
1つ以上の信頼されたルート証明書（CA証明書）の設定を許可することに加えて、サーバー証明書とSubjectLatName（SAN）拡張子と一致する1つ以上のサーバー名を認証することに加えて、EAPピアの実装は、構成された許容可能なSANを特定のものにバインドすることを可能にします。不正または侵害されたCAからの攻撃を防ぐためにサーバー証明書を発行する必要があるCA（またはCAS）。
This is a new section when compared to [RFC5216]. The guidance in this section is relevant for EAP-TLS in general (regardless of the underlying TLS version used).
[RFC5216]と比較した場合、これは新しいセクションです。このセクションのガイダンスは、一般的にEAP-TLS（使用される基礎となるTLSバージョンに関係なく）に関連しています。
There are a number of security issues related to resumption that are not described in [RFC5216]. The problems, guidelines, and requirements in this section therefore apply to EAP-TLS when it is used with any version of TLS.
[RFC5216]には記載されていない再開に関連するセキュリティ問題がいくつかあります。したがって、このセクションの問題、ガイドライン、および要件は、任意のバージョンのTLSで使用されている場合、EAP-TLSに適用されます。
When resumption occurs, it is based on cached information at the TLS layer. To perform resumption securely, the EAP-TLS peer and EAP-TLS server need to be able to securely retrieve authorization information such as certificate chains from the initial full handshake. This document uses the term "cached data" to describe such information. Authorization during resumption MUST be based on such cached data. The EAP-TLS peer and EAP-TLS server MAY perform fresh revocation checks on the cached certificate data. Any security policies for authorization MUST be followed also for resumption. The certificates may have been revoked since the initial full handshake and the authorizations of the other party may have been reduced. If the cached revocation data is not sufficiently current, the EAP-TLS peer or EAP-TLS server MAY force a full TLS handshake.
再開が発生すると、TLSレイヤのキャッシュ情報に基づいています。再開を確実に実行するためには、EAP-TLSピアおよびEAP-TLSサーバーは、最初のフルハンドシェイクから証明書チェーンなどの許可情報を安全に取得できる必要があります。この文書では、「キャッシュされたデータ」という用語を使用してそのような情報を記述します。再開中の承認は、そのようなキャッシュされたデータに基づいている必要があります。EAP-TLS PeerおよびEAP-TLSサーバーは、キャッシュされた証明書データに対して新たな失効チェックを実行することがあります。承認のためのセキュリティポリシーにも、再開のためにも従う必要があります。最初のフルハンドシェイクと相手方の権限が減少してから証明書が取り消された可能性があります。キャッシュされた失効データが十分に電流でない場合、EAP-TLSピアまたはEAP-TLSサーバーはフルTLSハンドシェイクを強制することがあります。
There are two ways to retrieve the cached data from the original full handshake. The first method is that the EAP-TLS server and client cache the information locally. The cached information is identified by an identifier. For TLS versions before 1.3, the identifier can be the session ID; for TLS 1.3, the identifier is the PSK identity. The second method for retrieving cached information is via [RFC5077] or [RFC8446], where the EAP-TLS server avoids storing information locally and instead encapsulates the information into a ticket that is sent to the client for storage. This ticket is encrypted using a key that only the EAP-TLS server knows. Note that the client still needs to cache the original handshake information locally and will obtain it while determining the session ID or PSK identity to use for resumption. However, the EAP-TLS server is able to decrypt the ticket or PSK to obtain the original handshake information.
元のフルハンドシェイクからキャッシュされたデータを取得する方法は2つあります。最初の方法は、EAP-TLSサーバーとクライアントが情報をローカルにキャッシュすることです。キャッシュされた情報は識別子によって識別されます。1.3の前のTLSバージョンの場合、識別子はセッションIDになることができます。TLS 1.3の場合、識別子はPSK IDです。キャッシュされた情報を検索するための2番目の方法は[RFC5077]または[RFC8446]を介して、EAP-TLSサーバーは情報をローカルに格納し、代わりにストレージのためにクライアントに送信されるチケットに情報をカプセル化します。このチケットは、EAP-TLSサーバーのみを知っているキーを使用して暗号化されています。クライアントはまだオリジナルのハンドシェイク情報をローカルにキャッシュする必要があり、再開に使用するセッションIDまたはPSKアイデンティティを決定しながら入手します。ただし、EAP-TLSサーバーはチケットまたはPSKを復号化して元のハンドシェイク情報を取得できます。
The EAP-TLS server or EAP client MUST cache data during the initial full handshake sufficient to allow authorization decisions to be made during resumption. If cached data cannot be retrieved securely, resumption MUST NOT be done.
EAP-TLSサーバーまたはEAPクライアントは、再開中に許可の決定を行うのを許可するのに十分な最初のフルハンドシェイク中にデータをキャッシュする必要があります。キャッシュされたデータを安全に取り出すことができない場合は、再開を行わなければなりません。
The above requirements also apply if the EAP-TLS server expects some system to perform accounting for the session. Since accounting must be tied to an authenticated identity, and resumption does not supply such an identity, accounting is impossible without access to cached data. Therefore, systems that expect to perform accounting for the session SHOULD cache an identifier that can be used in subsequent accounting.
上記の要件は、EAP-TLSサーバーが一部のシステムがセッションの会計処理を実行することを期待している場合も適用されます。会計処理は認証されたアイデンティティに関連付けられており、再開はそのような身元を提供しないため、キャッシュされたデータにアクセスすることなく考慮されません。したがって、セッションの会計処理を実行することを期待するシステムは、後続のアカウンティングで使用できる識別子をキャッシュする必要があります。
As suggested in [RFC8446], EAP-TLS peers MUST NOT store resumption PSKs or tickets (and associated cached data) for longer than 604800 seconds (7 days) regardless of the PSK or ticket lifetime. The EAP-TLS peer MAY delete them earlier based on local policy. The cached data MAY also be removed on the EAP-TLS server or EAP-TLS peer if any certificate in the certificate chain has been revoked or has expired. In all such cases, an attempt at resumption results in a full TLS handshake instead.
[RFC8446]で示唆されているように、EAP-TLSピアは、PSKまたはチケットの有効期間に関係なく、604800秒（7日）を超えると、再開PSKまたはチケット（および関連キャッシュデータ）を保存してはなりません。EAP-TLSピアは、ローカルポリシーに基づいて以前に削除することがあります。証明書チェーン内の証明書が失効されたか、または期限切れになっている場合は、キャッシュされたデータをEAP-TLSサーバーまたはEAP-TLSピアで削除することもできます。そのような場合には、再開の試みは代わりにフルTLSハンドシェイクをもたらす。
Information from the EAP-TLS exchange (e.g., the identity provided in EAP-Response/Identity) as well as non-EAP information (e.g., IP addresses) may change between the initial full handshake and resumption. This change creates a "time-of-check time-of-use" (TOCTOU) security vulnerability. A malicious or compromised user could supply one set of data during the initial authentication, and a different set of data during resumption, potentially allowing them to obtain access that they should not have.
EAP-TLS Exchange（例えば、EAP-Response / IDで提供されたID）および非EAP情報（例えば、IPアドレス）からの情報（例えば、IPアドレス）は、最初のフルハンドシェイクと再開の間で変化します。この変更により、「チェックタイムの使用時刻」（TOCTOU）セキュリティの脆弱性が発生します。悪意のあるまたは侵害されたユーザーは、初期認証中に1組のデータセット、および再開中に異なるデータセットを供給することができ、それらがそれらがそれらが持っていなければならないアクセスを取得する可能性があります。
If any authorization, accounting, or policy decisions were made with information that has changed between the initial full handshake and resumption, and if change may lead to a different decision, such decisions MUST be reevaluated. It is RECOMMENDED that authorization, accounting, and policy decisions are reevaluated based on the information given in the resumption. EAP-TLS servers MAY reject resumption where the information supplied during resumption does not match the information supplied during the original authentication. If a safe decision is not possible, EAP-TLS servers SHOULD reject the resumption and continue with a full handshake.
最初のフルハンドシェイクと再開の間で変更された情報で、許可、会計、またはポリシーの決定が行われた場合、および変更が異なる場合がある場合は、そのような決定を再評価する必要があります。再開中の情報に基づいて、許可、会計、およびポリシーの決定が再評価されることをお勧めします。EAP-TLSサーバーは、再開中に供給された情報が元の認証中に提供された情報と一致しない場合の再開を拒否することができます。安全な決定が不可能な場合は、EAP-TLSサーバーは再開を拒否し、フルハンドシェイクを続ける必要があります。
Sections 2.2 and 4.2.11 of [RFC8446] provide security considerations for TLS 1.3 resumption.
[RFC8446]のセクション2.2および4.2.11は、TLS 1.3の再開のセキュリティ上の考慮事項を提供します。
This is a new section when compared to [RFC5216].
[RFC5216]と比較した場合、これは新しいセクションです。
TLS 1.3 offers much better privacy than earlier versions of TLS as discussed in Section 2.1.8. In this section, we only discuss the privacy properties of EAP-TLS with TLS 1.3. For privacy properties of TLS 1.3 itself, see [RFC8446].
TLS 1.3は、2.1.8項で説明したように、以前のバージョンのTLSよりもはるかに優れたプライバシーを提供します。このセクションでは、EAP-TLSのプライバシープロパティのみをTLS 1.3と議論します。TLS 1.3自体のプライバシープロパティの場合は、[RFC8446]を参照してください。
EAP-TLS sends the standard TLS 1.3 handshake messages encapsulated in EAP packets. Additionally, the EAP-TLS peer sends an identity in the first EAP-Response. The other fields in the EAP-TLS Request and the EAP-TLS Response packets do not contain any cleartext privacy-sensitive information.
EAP-TLSは、EAPパケットにカプセル化された標準のTLS 1.3ハンドシェイクメッセージを送信します。さらに、EAP-TLSピアは最初のEAP応答で識別情報を送信します。EAP-TLS要求およびEAP-TLS応答パケットの他のフィールドには、クリアテキストのプライバシーに敏感な情報が含まれていません。
Tracking of users by eavesdropping on Identity Responses or certificates is a well-known problem in many EAP methods. When EAP-TLS is used with TLS 1.3, all certificates are encrypted, and the username part of the Identity Response is not revealed (e.g., using anonymous NAIs). Note that even though all certificates are encrypted, the server's identity is only protected against passive attackers while the client's identity is protected against both passive and active attackers. As with other EAP methods, even when privacy-friendly identifiers or EAP tunneling is used, the domain name (i.e., the realm) in the NAI is still typically visible. How much privacy-sensitive information the domain name leaks is highly dependent on how many other users are using the same domain name in the particular access network. If all EAP-TLS peers have the same domain, no additional information is leaked. If a domain name is used by a small subset of the EAP-TLS peers, it may aid an attacker in tracking or identifying the user.
アイデンティティ応答または証明書を盗聴することによってユーザーの追跡は、多くのEAPメソッドでよく知られている問題です。 EAP-TLSがTLS 1.3で使用されている場合、すべての証明書が暗号化され、ID応答のユーザー名部分は明らかにされていません（たとえば、anonymous NAISを使用）。すべての証明書が暗号化されていても、サーバーのIDはパッシブ攻撃者からのみ保護されますが、クライアントのIDはパッシブとアクティブな攻撃者の両方に対して保護されています。他のEAPメソッドと同様に、プライバシーに優しい識別子またはEAPトンネリングが使用されていても、NAI内のドメイン名（すなわち、レルム）は依然として典型的には見える。ドメイン名のリークは、特定のアクセスネットワークで同じドメイン名を使用している他のユーザーが何人のユーザーの数のリークが大きく依存しています。すべてのEAP-TLSピアが同じドメインを持つ場合、追加情報はリークされません。ドメイン名がEAP-TLSピアの小さなサブセットによって使用されている場合、それはユーザーの追跡または識別の攻撃者を助けるかもしれません。
Without padding, information about the size of the client certificate is leaked from the size of the EAP-TLS packets. The EAP-TLS packets sizes may therefore leak information that can be used to track or identify the user. If all client certificates have the same length, no information is leaked. EAP-TLS peers SHOULD use record padding; see Section 5.4 of [RFC8446] to reduce information leakage of certificate sizes.
パディングなしでは、クライアント証明書のサイズに関する情報がEAP-TLSパケットのサイズからリークされています。したがって、EAP-TLSパケットサイズは、ユーザーを追跡または識別するために使用できる情報をリークすることができます。すべてのクライアント証明書が同じ長さを持つ場合、情報は漏洩しません。EAP-TLSピアはレコードパディングを使用する必要があります。証明書サイズの情報漏洩を減らすために[RFC8446]のセクション5.4を参照してください。
If anonymous NAIs are not used, the privacy-friendly identifiers need to be generated with care. The identities MUST be generated in a cryptographically secure way so that it is computationally infeasible for an attacker to differentiate two identities belonging to the same user from two identities belonging to different users in the same realm. This can be achieved, for instance, by using random or pseudo-random usernames such as random byte strings or ciphertexts and only using the pseudo-random usernames a single time. Note that the privacy-friendly usernames also MUST NOT include substrings that can be used to relate the identity to a specific user. Similarly, privacy-friendly usernames MUST NOT be formed by a fixed mapping that stays the same across multiple different authentications.
匿名のNAISが使用されていない場合、プライバシーに優しい識別子を注意して生成する必要があります。識別情報は、同じレルム内の異なるユーザーに属する2つの識別情報から同じユーザーに属する2つの識別情報を区別することが攻撃者が計算できるようにするように、暗号的に安全な方法で生成されなければなりません。これは、例えば、ランダムバイト文字列や暗号文などのランダムまたは擬似ランダムなユーザ名を使用し、擬似ランダムなユーザ名を単一の時間だけ使用することによって達成することができる。プライバシーに優しいユーザー名も、IDを特定のユーザーに関連付けるために使用できる部分文字列を含めてはならないことに注意してください。同様に、プライバシーに優しいユーザー名は、複数の異なる認証にわたって同じままである固定マッピングによって形成されてはならない。
An EAP-TLS peer with a policy allowing communication with EAP-TLS servers supporting only TLS 1.2 without privacy and with a static RSA key exchange is vulnerable to disclosure of the EAP-TLS peer username. An active attacker can in this case make the EAP-TLS peer believe that an EAP-TLS server supporting TLS 1.3 only supports TLS 1.2 without privacy. The attacker can simply impersonate the EAP-TLS server and negotiate TLS 1.2 with static RSA key exchange and send a TLS alert message when the EAP-TLS peer tries to use privacy by sending an empty certificate message. Since the attacker (impersonating the EAP-TLS server) does not provide a proof-of-possession of the private key until the Finished message when a static RSA key exchange is used, an EAP-TLS peer may inadvertently disclose its identity (username) to an attacker. Therefore, it is RECOMMENDED for EAP-TLS peers to not use EAP-TLS with TLS 1.2 and static RSA-based cipher suites without privacy. This implies that an EAP-TLS peer SHOULD NOT continue the EAP authentication attempt if a TLS 1.2 EAP-TLS server sends an EAP-TLS/Request with a TLS alert message in response to an empty certificate message from the peer.
PROVICACYのないTLS 1.2のみをサポートするEAP-TLSサーバーとの通信を可能にするEAP-TLSピアは、EAP-TLSピアユーザ名の開示に対して脆弱です。この場合、アクティブな攻撃者は、TLS 1.3をサポートするEAP-TLSサーバーがプライバシーなしでTLS 1.2のみをサポートすると、EAP-TLSピアを考えることができます。攻撃者は、EAP-TLSサーバーを偽装し、静的RSAキー交換でTLS 1.2をネゴシエートすることができ、EAP-TLSピアが空の証明書メッセージを送信してプライバシーを使用しようとしたときにTLS警告メッセージを送信します。攻撃者（EAP-TLSサーバーを偽装する）は、静的RSA鍵交換が使用されているときに完成したメッセージが使用されるまで秘密鍵の証明を提供しないので、EAP-TLSピアは誤ってそのIDを開示する可能性があります（ユーザー名）。攻撃者に。したがって、PC-TLSは、プライバシーなしでTLS 1.2およびStatic RSAベースの暗号スイートを使用してEAP-TLSを使用しないことをお勧めします。これは、TLS 1.2 EAP-TLSサーバーがピアからの空の証明書メッセージに応答して、TLSアラートメッセージを使用してEAP-TLS /要求を送信した場合、EAP-TLSピアがEAP認証の試みを続行しないことを意味します。
This is a new section when compared to [RFC5216].
[RFC5216]と比較した場合、これは新しいセクションです。
Pervasive monitoring refers to widespread surveillance of users. In the context of EAP-TLS, pervasive monitoring attacks can target EAP-TLS peer devices for tracking them (and their users) when they join a network. By encrypting more information, mandating the use of privacy, and always providing forward secrecy, EAP-TLS with TLS 1.3 offers much better protection against pervasive monitoring. In addition to the privacy attacks discussed above, surveillance on a large scale may enable tracking of a user over a wide geographical area and across different access networks. Using information from EAP-TLS together with information gathered from other protocols increases the risk of identifying individual users.
Pervasive Monitoringは、ユーザーの広範な監視を指します。EAP-TLSのコンテキストでは、Pervasive Monitoring Attacksは、ネットワークに参加したときにそれらを追跡するためのEAP-TLSピアデバイスをターゲットにすることができます。より多くの情報を暗号化することによって、プライバシーの使用を義務付け、そして常に前進秘密を提供することによって、TLS 1.3を持つEAP-TLSは、Pervasive Monitoringに対してはるかに優れた保護を提供します。上述したプライバシー攻撃に加えて、大規模な監視は、広い地理的領域を介して、そして異なるアクセスネットワークを介してユーザの追跡を可能にし得る。EAP-TLSからの情報を他のプロトコルから収集された情報と共に使用すると、個々のユーザーを特定するリスクが高まります。
In TLS 1.3, the post-handshake key update mechanism provides forward secrecy for the traffic secrets. EAP-TLS 1.3 does not provide a similar mechanism for MSK and EMSK. Implementation using the exported MSK and EMSK can achieve forward secrecy by frequently deriving new keys in a similar way as described in Section 7.2 of [RFC8446].
TLS 1.3では、握手後の鍵更新メカニズムは、トラフィック秘密のための前方秘密を提供します。EAP-TLS 1.3はMSKとEMSKと同様のメカニズムを提供しません。エクスポートされたMSKとEMSKを使用した実装は、[RFC8446]のセクション7.2で説明されているように、新しいキーを頻繁に導出することで、既知の秘密を達成できます。
This is a new section when compared to [RFC5216].
[RFC5216]と比較した場合、これは新しいセクションです。
Over the years, there have been several serious attacks on earlier versions of Transport Layer Security (TLS), including attacks on its most commonly used ciphers and modes of operation. [RFC7457] summarizes the attacks that were known at the time of publishing, and BCP 195 [RFC7525] [RFC8996] provides recommendations and requirements for improving the security of deployed services that use TLS. However, many of the attacks are less serious for EAP-TLS as EAP-TLS only uses the TLS handshake and does not protect any application data. EAP-TLS implementations MUST mitigate known attacks. EAP-TLS implementations need to monitor and follow new EAP- and TLS-related security guidance and requirements such as [RFC8447] and [RFC9155].
長年にわたり、以前のバージョンのトランスポート層セキュリティ（TLS）に対する深刻な攻撃は、最も一般的に使用されている暗号化や操作モードへの攻撃を含む。[RFC7457]出版時に知られていた攻撃を要約し、BCP 195 [RFC7525] [RFC8996] TLSを使用するデプロイされたサービスのセキュリティを向上させるための推奨事項と要件を提供します。ただし、EAP-TLSはTLSハンドシェイクのみを使用し、アプリケーションデータを保護しないため、多くの攻撃はEAP-TLSには発生しません。EAP-TLSの実装は既知の攻撃を軽減する必要があります。EAP-TLSの実装は、新しいEAPおよびTLS関連のセキュリティガイダンスと[RFC8447]や[RFC9155]などの要件を監視および追従する必要があります。
This is a new section when compared to [RFC5216].
[RFC5216]と比較した場合、これは新しいセクションです。
Allowing the same certificate to be used in multiple protocols can potentially allow an attacker to authenticate via one protocol and then "resume" that session in another protocol. Section 2.2 suggests that certificates typically have one or more FQDNs in the SAN extension. However, those fields are for EAP validation only and do not indicate that the certificates are suitable for use with HTTPS or other protocols on the named host.
同じ証明書を複数のプロトコルで使用できるようにすると、攻撃者が1つのプロトコルを介して認証し、そのセッションを別のプロトコルで「再開」することができます。セクション2.2は、証明書が通常SAN拡張子に1つ以上のFQDNを持っていることを示唆しています。ただし、これらのフィールドはEAP検証のみのみです。証明書が名前付きホスト上のHTTPSまたはその他のプロトコルでの使用に適していることを示していません。
Section 2.1.3 suggests that authorization rules should be reapplied on resumption but does not mandate this behavior. As a result, this cross-protocol resumption could allow the attacker to bypass authorization policies and to obtain undesired access to secured systems. Along with making sure that appropriate authorization information is available and used during resumption, using different certificates and resumption caches for different protocols is RECOMMENDED to help keep different protocol usages separate.
セクション2.1.3は、許可規則を再開時に再適用する必要があることを示唆していますが、この動作を義務付けません。結果として、このクロスプロトコルの再開により、攻撃者は許可ポリシーを回避し、保護されたシステムへの望ましくないアクセスを取得することができる。適切な認証情報が利用可能で再開中に使用されていることを確認し、異なるプロトコルのための異なる証明書と再開キャッシュを使用して、さまざまなプロトコル使用量を個別に保つために推奨されます。
[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>。
[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>。
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC5705] RESCORLA、E。、「トランスポート層セキュリティ（TLS）」、RFC 5705、DOI 10.17487 / RFC5705、2010年3月、<https://www.rfc-editor.org/info/rfc5705>。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066]イーストレイク3RD、D.、「トランスポートレイヤセキュリティ（TLS）拡張：拡張定義」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<https：//ww.rfc-editor.org/info/rfc6066>。
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6960] Santesson、S.、Myers、M.、Ankney、R.、Malpani、A.、Galparin、S.、およびC. ADAMS、「インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル - OCSP」、RFC6960、DOI 10.17487 / RFC6960、2013年6月、<https：//www.rfc-editor.org/info/rfc6960>。
[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>。
[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>。
[IEEE-802.11] IEEE, "IEEE Standard for Information technology-Telecommunications and information exchange between systems Local and metropolitan area networks-Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Std. 802.11-2020, DOI 10.1109/IEEESTD.2016.7786995, February 2021, <https://doi.org/10.1109/IEEESTD.2016.7786995>.
[IEEE-802.11] IEEE、「情報技術 - 電気通信および情報交換のためのIEEE規格」ネットワーク固有の要件 - 第11部：無線LANメディアアクセス制御（MAC）および物理層（PHY）仕様）、IEEEstd。802.11-2020、DOI 10.1109 / IEEESTD.2016.7786995、2021年2月、<https：//doi.org/10.1109/ieeeestd.2016.7786995>。
[IEEE-802.1AE] IEEE, "IEEE Standard for Local and metropolitan area networks -- Media Access Control (MAC) Security", IEEE Std. 802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, December 2018, <https://doi.org/10.1109/IEEESTD.2018.8585421>.
[IEEE-802.1ae] IEEE、「地元および首都圏ネットワークのIEEE規格 - メディアアクセス制御（MAC）セキュリティ」、IEEE STD。802.1ae-2018、DOI 10.1109 / IEEESTD.2018.8585421、2018年12月、<https：//doi.org/10.1109/ieeeestd.2018.8585421>。
[IEEE-802.1X] IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Port-Based Network Access Control", IEEE Std. 802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, February 2020, <https://doi.org/10.1109/IEEESTD.2020.9018454>.
[IEEE-802.1X] IEEE、「ローカルおよび首都圏ネットワーク - ポートベースネットワークアクセス制御のためのIEEE規格」、IEEE STD。802.1X-2020、DOI 10.1109 / IEEESTD.2020.9018454、<https：//doi.org/10.1109/ieeeestd.2020.9018454>。
[MulteFire] MulteFire Alliance, "MulteFire Release 1.1 Specification", 2019.
[Multifire] Multifire Alliance、「Multifire Release 1.1仕様」、2019。
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)", June 2021.
[PEAP] Microsoft Corporation、[MS-PEAP]：Protected Extensible認証プロトコル（PEAP） "、2021年6月。
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, <https://www.rfc-editor.org/info/rfc1661>.
[RFC1661] SimpSon、W。、「ポイントツーポイントプロトコル（PPP）」、STD 51、RFC 1661、DOI 10.17487 / RFC1661、1994年7月、<https：//www.rfc-editor.org/ info / rfc1661>。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999, <https://www.rfc-editor.org/info/rfc2246>.
[RFC2246] Dierks、T.およびC.Allen、「TLSプロトコルバージョン1.0」、RFC 2246、DOI 10.17487 / RFC2246、1999年1月、<https：//www.rfc-editor.org/info/rfc2246>。
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, DOI 10.17487/RFC2560, June 1999, <https://www.rfc-editor.org/info/rfc2560>.
[RFC2560]マイヤーズ、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. ADAMS、「Internet Public Key Infrastructureオンライン証明書ステータスプロトコル - OCSP」、RFC 2560、DOI 10.17487 /RFC2560、1999年6月、<https://www.rfc-editor.org/info/rfc2560>。
[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>。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, DOI 10.17487/RFC3280, April 2002, <https://www.rfc-editor.org/info/rfc3280>.
[RFC3280] housley、R.、Polk、W.、Ford、W.、およびD. Solo、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル"、RFC 3280、DOI 10.17487 / RFC3280、2002年4月、<https：//www.rfc-editor.org/info/rfc3280>。
[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>。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, DOI 10.17487/RFC4282, December 2005, <https://www.rfc-editor.org/info/rfc4282>.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、「ネットワークアクセス識別子」、RFC 4282、DOI 10.17487 / RFC4282、2005年12月、<https：//www.rfc-editor.org/info/rfc4282>。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, DOI 10.17487/RFC4346, April 2006, <https://www.rfc-editor.org/info/rfc4346>.
[RFC4346] Dierks、T.およびE. Rescorla、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.1」、RFC 4346、DOI 10.17487 / RFC4346、2006年4月、<https：//www.rfc-editor.org/info/ RFC4346>。
[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>。
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, "Transport Layer Security (TLS) Session Resumption without Server-Side State", RFC 5077, DOI 10.17487/RFC5077, January 2008, <https://www.rfc-editor.org/info/rfc5077>.
[RFC5077] Salowey、J.、Zhou、H.、Eronen、P.、およびH.Schofenig、「サーバー側の状態なしのトランスポート層セキュリティ（TLS）セッション再開」、RFC 5077、DOI 10.17487 / RFC5077、2008年1月、<https://www.rfc-editor.org/info/rfc5077>。
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, May 2008, <https://www.rfc-editor.org/info/rfc5191>.
[RFC5191] Forsberg、D.、OHBA、Y、ED。、PATIL、B.、TSCHOFENIG、H.、A. YEGIN、「ネットワークアクセスの認証を搬送するためのプロトコル」、RFC 5191、DOI 10.17487 /RFC5191、2008年5月、<https：//www.rfc-editor.org/info/rfc5191>。
[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>。
[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>。
[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>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P.およびJ.HODGES、「ドメインベースのアプリケーションサービスIDの表現と検証は、トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用した（PKIX）証明書を使用しています。RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<https：//www.rfc-editor.org/info/rfc6125>。
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <https://www.rfc-editor.org/info/rfc6733>.
[RFC6733] Fajardo、V.、Ed。、Arkko、J.、Loughney、J.、およびG. Zorn、Ed。、「Diameter Base Protocol」、RFC 6733、DOI 10.17487 / RFC6733、2012年10月、<https：//ww.rfc-editor.org/info/rfc6733>。
[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>。
[RFC7406] Schulzrinne, H., McCann, S., Bajko, G., Tschofenig, H., and D. Kroeselberg, "Extensions to the Emergency Services Architecture for Dealing With Unauthenticated and Unauthorized Devices", RFC 7406, DOI 10.17487/RFC7406, December 2014, <https://www.rfc-editor.org/info/rfc7406>.
[RFC7406] Schulzrinne、H.、McCann、S.、Bajko、G.、Tschofenig、H.、D。Kroeselberg、「未認証および不正なデバイスを扱うための緊急サービスアーキテクチャへの拡張」、RFC 7406、DOI 10.17487 /RFC7406、2014年12月、<https：//www.rfc-editor.org/info/rfc7406>。
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7457] Sheffer、Y、Holz、R.およびP.Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムTLS（DTLS）およびデータグラムTLS（DTLS）」、RFC 7457、DOI 10.17487 / RFC7457、2015年2月、<https://www.rfc-editor.org/info/rfc7457>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y、Holz、R.およびP.Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）およびデータグラムトランスポート層セキュリティ（DTLS）」、BCP 195、RFC 7525、DOI 10.17487/ RFC7525、2015年5月、<https：//www.rfc-editor.org/info/rfc7525>。
[RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam Architecture for Network Roaming", RFC 7593, DOI 10.17487/RFC7593, September 2015, <https://www.rfc-editor.org/info/rfc7593>.
[RFC7593] Wierenga、K.、Winter、S.、T.Wolniewicz、「ネットワークローミングのためのエドロムアーキテクチャ」、RFC 7593、DOI 10.17487 / RFC7593、2015年9月、<https：//www.rfc-editor.org/ info / rfc7593>。
[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>。
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/info/rfc8447>.
[RFC8447] Salowey、J.およびS.ターナー、「TLSおよびDTLSのIANAレジストリアップデート」、RFC 8447、DOI 10.17487 / RFC8447、2018年8月、<https：//www.rfc-editor.org/info/rfc8447>。
[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, <https://www.rfc-editor.org/info/rfc8996>.
[RFC8996] MoriAlty、K.およびS. Farrell、「非推奨TLS 1.0およびTLS 1.1」、BCP 195、RFC 8996、DOI 10.17487 / RFC8996、2021年3月、<https：//www.rfc-editor.org/info/RFC8996>。
[RFC9155] Velvindron, L., Moriarty, K., and A. Ghedini, "Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2", RFC 9155, DOI 10.17487/RFC9155, December 2021, <https://www.rfc-editor.org/info/rfc9155>.
[RFC9155] Velvindron、L.、Moriarty、K.、およびA. Ghedini、「TLS 1.2およびDTLS 1.2における非推奨MD5およびSHA-1シグネチャハッシュ」、RFC 9155、DOI 10.17487 / RFC9155、2021年12月、<https：//www.rfc-editor.org/info/rfc9155>。
[RFC9191] Sethi, M., Preuß Mattsson, J., and S. Turner, "Handling Large Certificates and Long Certificate Chains in TLS-Based EAP Methods", RFC 9191, DOI 10.17487/RFC9191, February 2022, <https://www.rfc-editor.org/rfc/rfc9191>.
[RFC9191] Sethi、M.、PreußMattsson、J.、およびS.ターナー、「TLSベースのEAPメソッドの大文字と長い証明書チェーンの処理」、RFC 9191、DOI 10.17487 / RFC9191、2022年2月、<https：//www.rfc-editor.org/rfc/rfc9191>。
[TICKET-REQUESTS] Pauly, T., Schinazi, D., and C. A. Wood, "TLS Ticket Requests", Work in Progress, Internet-Draft, draft-ietf-tls-ticketrequests-07, 3 December 2020, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-07>.
[チケット要求] Pauly、T.、Schinazi、D.、およびCA Wood、「TLSチケットリクエスト」、進行中の作業、インターネットドラフト、ドラフト-IETF-TLS-THITEAQUESTS-07、<https：//datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-07>。
[TLS-bis] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-rfc8446bis-03, 25 October 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-tls-rfc8446bis-03>.
[TLS-BIS] Rescorla、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、進行中の作業、インターネットドラフト、ドラフト-IETF-TLS-RFC8446BIS-03,25,25、<https：//dataTracker.ietf.org/doc/html/draft-ietf-tls-rfc8446bis-03>。
[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, 21 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,2022,21https://datatracker.ietf.org/doc/html/ proft-ietf-emu-tls-eap-types-04>。
[TS.33.501] 3GPP, "Security architecture and procedures for 5G system", Release 17, TS 33.501, January 2022.
[TS.33.501] 3GPP、「5Gシステムのためのセキュリティアーキテクチャと手順」、リリース17、TS 33.501、2022年1月。
The following references in [RFC5216] are updated as specified below when EAP-TLS is used with TLS 1.3.
[RFC5216]の次の参照は、TLS 1.3でEAP-TLSが使用されている場合は、以下のように更新されます。
* All references to [RFC2560] are updated to refer to [RFC6960].
* [RFC2560]へのすべての参照は[RFC6960]を参照するように更新されます。
* All references to [RFC3280] are updated to refer to [RFC5280]. References to Section 4.2.1.13 of [RFC3280] are updated to refer to Section 4.2.1.12 of [RFC5280].
* [RFC3280]への参照はすべて[RFC5280]を参照するように更新されます。[RFC3280]のセクション4.2.1.13への参照は、[RFC5280]のセクション4.2.1.12を参照するように更新されます。
* All references to [RFC4282] are updated to refer to [RFC7542]. References to Section 2.1 of [RFC4282] are updated to refer to Section 2.2 of [RFC7542].
* [RFC4282]への参照はすべて[RFC7542]を参照するように更新されます。[RFC4282]のセクション2.1への参照は、[RFC7542]のセクション2.2を参照するように更新されます。
Acknowledgments
謝辞
The authors want to thank Bernard Aboba, Jari Arkko, Terry Burton, Alan DeKok, Ari Keränen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar, Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa Torvinen, Hannes Tschofenig, and Heikki Vatiainen for comments and suggestions on this document. Special thanks to the Document Shepherd Joseph Salowey.
著者らは、Bernard Aboba、Jari Arkko、Terry Burton、Alan Dekok、AralKeränen、Benjamin Kaduk、Jouni Malinen、Oleg Pekar、Eric Rescorla、Jim Schaad、Joseph Salowey、Martin Thomson、Hannes Tschofenig、Heikki Vatiainenこの文書のコメントや提案について。羊飼いのジョセフサロウェイのおかげで特別な。
Contributors
貢献者
Alan DeKok, FreeRADIUS
Freeradius、Alan Dekok
Authors' Addresses
著者の住所
John Preuß Mattsson Ericsson SE-164 40 Kista Sweden
ジョンプールマッツソンエリクソンSE-164 40キスタスウェーデン
Email: john.mattsson@ericsson.com
Mohit Sethi Ericsson FI-02420 Jorvas Finland
Mohit Sethi Ericsson FI-02420 Jorvas Finland
Email: mohit@iki.fi