[要約] RFC 9190は、TLS 1.3をEAP認証に適用した「EAP-TLS 1.3」の標準仕様を規定し、以前のRFC 5216を更新しています。TLS 1.3の特性を活かし、証明書の暗号化と匿名NAIによるプライバシー保護の義務化、前方秘匿性の提供、およびOCSPによる失効確認の必須化を実現しています。新しい鍵導出方法、PSKを用いたセッション再開、および保護された成功通知手順（0x00データ）を定義し、Wi-Fiや5G等のアクセス認証の安全性を向上させます。
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 1.3でのEAP-TLS（EAP-TLS 1.3）は、常に前方秘匿性を提供し、ピアの識別情報を決して開示せず、証明書の失効確認を必須とすることで、以前のTLSバージョンでのEAP-TLSよりもセキュリティとプライバシーをさらに向上させます。また本書は、基盤となるTLSバージョンにかかわらず、EAP-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.
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
本書は、発行日に有効なBCP 78およびIETF文書に関するIETF Trustの法的条項（https://trustee.ietf.org/license-info）の適用対象です。これらの文書には、本書に関する権利と制限が記載されているため、注意して確認してください。本書から抽出したコードコンポーネントには、Trustの法的条項セクション4.eに記載された改訂BSDライセンスの文面を含める必要があります。また、改訂BSDライセンスに記載されたとおり、保証なしで提供されます。
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
1. Introduction
1. はじめに
1.1. Requirements and Terminology
1.1. 要件と用語
2. Protocol Overview
2. プロトコルの概要
2.1. Overview of the EAP-TLS Conversation
2.1. EAP-TLS会話の概要
2.1.1. Authentication
2.1.1. 認証
2.1.2. Ticket Establishment
2.1.2. チケット設立
2.1.3. Resumption
2.1.3. 再開
2.1.4. Termination
2.1.4. セッションの終了
2.1.5. No Peer Authentication
2.1.5. ピア認証なし
2.1.6. Hello Retry Request
2.1.6. HelloRetryRequest
2.1.7. Identity
2.1.7. 識別情報
2.1.8. Privacy
2.1.8. プライバシー
2.1.9. Fragmentation
2.1.9. フラグメンテーション
2.2. Identity Verification
2.2. 識別情報の検証
2.3. Key Hierarchy
2.3. 鍵階層
2.4. Parameter Negotiation and Compliance Requirements
2.4. パラメーターのネゴシエーションと適合要件
2.5. EAP State Machines
2.5. EAP状態機械
3. Detailed Description of the EAP-TLS Protocol
3. EAP-TLSプロトコルの詳細
4. IANA Considerations
4. IANAに関する考慮事項
5. Security Considerations
5. セキュリティに関する考慮事項
5.1. Security Claims
5.1. セキュリティ上の主張
5.2. Peer and Server Identities
5.2. ピアとサーバーの識別情報
5.3. Certificate Validation
5.3. 証明書の検証
5.4. Certificate Revocation
5.4. 証明書の失効
5.5. Packet Modification Attacks
5.5. パケット改変攻撃
5.6. Authorization
5.6. 認可
5.7. Resumption
5.7. セッション再開
5.8. Privacy Considerations
5.8. プライバシーに関する考慮事項
5.9. Pervasive Monitoring
5.9. 広範な監視
5.10. Discovered Vulnerabilities
5.10. 発見された脆弱性
5.11. Cross-Protocol Attacks
5.11. クロスプロトコル攻撃
6. References
6. 参考文献
6.1. Normative References
6.1. 引用文献
6.2. Informative references
6.2. Informative references
Appendix A. Updated References
Appendix A. 更新された参照
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.
[RFC3748]で定義される拡張認証プロトコル（EAP）は、複数の認証方式をサポートするための標準機構を提供します。EAP-TLS [RFC5216]は、暗号アルゴリズムとプロトコルバージョンのネゴシエーション、および共有シークレット鍵素材の確立にTLSハンドシェイクプロトコルを用いる、証明書ベースの相互認証EAP方式を規定します。EAP-TLSは、IEEE 802.1X [IEEE-802.1X]を用いるIEEE 802.11 [IEEE-802.11]（Wi-Fi）およびIEEE 802.1AE [IEEE-802.1AE]（MACsec）ネットワークでの認証と鍵確立に広く採用されています。また、3GPP 5G [TS.33.501]およびMulteFire [MulteFire]ネットワークでは、証明書ベース認証の既定方式です。Flexible Authentication via Secure Tunneling（EAP-FAST）[RFC4851]、Tunneled Transport Layer Security（EAP-TTLS）[RFC5281]、Tunnel Extensible Authentication Protocol（TEAP）[RFC7170]などの多くのEAP方式や、Protected Extensible Authentication Protocol（PEAP）[PEAP]などベンダー固有のEAP方式も、TLSおよび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とTLS 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.
本書は、TLS 1.3でEAP-TLSを使用する方法を定めるため、[RFC5216]を更新します。以前のTLSバージョンがネゴシエートされた場合は、後方互換性を保つためRFC 5216が適用されます。ただし本書は、基盤となるTLSバージョンにかかわらず、EAP-TLSの認証、認可、およびセッション再開に関する追加の指針も示します。本書では[RFC5216]からの変更点のみを説明します。TLS 1.3でEAP-TLSを使用する場合、付録Aのとおり一部の参照先が更新されます。図示するメッセージフローはすべてTLS 1.3に固有の例であり、TLS 1.2には適用されません。EAP-TLSはTLSハンドシェイクの状態機械とEAPの状態機械を連携させるため、新しいTLSバージョンをEAP-TLSプロトコルに慎重に統合しないと、互換性の問題が障害やセキュリティ上の問題を招く可能性があります。したがって、管理者が後続バージョンを明示的に有効にしない限り、実装は使用するTLSの最大バージョンを1.3に制限しなければなりません (MUST)。
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-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におけるプライバシーとは、ピアの本来の識別情報を一切開示しないことです。これは必須であり、追加のラウンドトリップなしに実現されます。証明書失効確認も必須であり、Online Certificate Status Protocol（OCSP）ステープリングによって簡素化されます。またTLS 1.3では、以前の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]の用語に従い、master secretをmain secretに、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 1.3を正しくサポートし、EAP-TLS 1.2との後方互換性を保つには、EAP-TLS実装がネゴシエートされた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 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では大量のデータを暗号化しないため、この機能は不要です。実装はこのメッセージを送信すべきではありません (SHOULD NOT)。ただし、一部の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ではEarly Dataを使用してはなりません (MUST NOT)。EAP-TLSサーバーはearly_data拡張を送信してはならず (MUST NOT)、クライアントはEndOfEarlyDataメッセージを送信してはなりません (MUST NOT)。
* 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.
* EAP-TLSではハンドシェイク後認証を使用してはなりません (MUST NOT)。クライアントはpost_handshake_auth拡張を送信してはならず (MUST NOT)、サーバーはハンドシェイク後のクライアント認証を要求してはなりません (MUST NOT)。
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].
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サーバーは証明書を用いて認証しなければなりません (MUST)。また、EAP-TLSピアにも証明書を用いた認証を求めるべきです (SHOULD)。証明書には、TLSがサポートする任意の種類を使用でき、生公開鍵も含まれます。セッション再開を除き、事前共有鍵（PSK）による認証を使用してはなりません (MUST NOT)。TLS 1.3でのEAP-TLSのフルハンドシェイクは、ClientHelloとServerHelloで一時的なkey_share拡張（例えば一時的な楕円曲線ディフィー・ヘルマン（ECDHE）公開鍵を含むもの）を交換するため、常に前方秘匿性を提供します。SessionIDはTLS 1.3では非推奨です。[RFC8446]のセクション4.1.2および4.1.3を参照してください。TLS 1.3では早期アプリケーションデータが導入されましたが、後述する保護された成功通知を除き、EAP-TLSではアプリケーションデータを使用しません。early_data拡張の詳細は[RFC8446]のセクション4.2.10を参照してください。セッション再開はセクション2.1.3の説明に従って処理します。[RFC3748]で定義される保護された成功通知として、EAP-TLSサーバーは常にTLSアプリケーションデータ0x00を送信します。セクション2.5を参照してください。TLS実装によっては、EAP-TLS層が送信順序を制御できない場合があります (MAY)。その場合、アプリケーションデータはNewSessionTicketより前に送信されてもかまいません (MAY)。したがって、TLSアプリケーションデータ0x00を含むEAP-Requestを受信した時点で、TLSアプリケーションデータ0x00を成功として解釈します。EAP-TLSサーバーは、TLSアプリケーションデータ0x00を含むEAP-Requestを送信し、データを含まないEAP-Type=EAP-TLSのEAP-Responseを受信した後に、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に、HelloRetryRequestもハンドシェイク後メッセージも送信しない、相互認証付き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 Application Data 0x00)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
Figure 1: EAP-TLS Mutual Authentication
図1：EAP-TLSの相互認証
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サーバーは初回認証時に、ハンドシェイク後のNewSessionTicketメッセージを1つ以上送信しなければなりません (MUST)。各チケットにはPSK、PSK識別子、チケット有効期間などのパラメーターが関連付けられます。TLS 1.3 [RFC8446]ではチケットの有効期間は最大604800秒（7日間）に制限されており、EAP-TLSサーバーはチケット発行時にこの上限を守らなければなりません (MUST)。NewSessionTicketは、初回認証でEAP-TLSサーバーがクライアントのFinishedメッセージを受信した後に送信されます。これはTLSサーバーのFinishedと同じフライトで送信しても、その後に送信してもかまいません。クライアント認証を行うハンドシェイクでは、チケットに関連付けるPSKはクライアントのFinishedに依存するため、事前に計算してTLSサーバーのFinishedと同じフライトで送信することはできません。NewSessionTicketメッセージにearly_data拡張を含めてはなりません (MUST NOT)。early_data拡張を受信した場合は無視しなければなりません (MUST)。通常のHTTPS接続と比べ、EAP-TLSでは必要となるNewSessionTicketが少ないと考えられる点をサーバーは考慮してください。ほとんどの場合、チケットは1つで十分です。クライアントが将来の接続に必要なチケット数を指定する仕組みは[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に、相互認証を行い、チケットを1つ確立する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-RequestとEAP-Responseに分割されます。セッション再開によりラウンドトリップ数を大幅に減らし、クライアント認証付きのフルハンドシェイクで必要となるデータベース検索をEAP-TLSサーバーが省略できます。TLS 1.3では、以前のTLSバージョンのセッション再開方式が新しいPSK交換方式に置き換わっています。TLS 1.3でEAP-TLSを使用する場合、EAP-TLSはTLS 1.3と互換性のある再開方式を使用しなければなりません (SHALL)。
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識別子を使って、対応するPSKの使用をネゴシエートできます。EAP-TLSサーバーがこれを受け入れると、再開セッションは認証済みとみなされ、直前の認証または再開に安全に結び付けられます。セッション再開を使うかどうかはEAP-TLSピアが決めますが、未使用で有効なチケットがある場合は再開を使うことが推奨されます (RECOMMENDED)。発行したチケットがまだ有効な場合に再開を受け入れるかどうかはEAP-TLSサーバーが決めますが、受け入れることが推奨されます (RECOMMENDED)。ただし、サーバーはフルハンドシェイクを要求してもかまいません (MAY)。フルハンドシェイクが必要な場合、セッションが新規認証であるかのようにネゴシエーションを進め、再開の試みは無視します。その場合、セクション2.1.1および2.1.2の要件がすべて適用されます。[RFC8446]の付録C.4で説明されているように、チケットを再利用すると受動的な観測者が複数の接続を関連付けられます。EAP-TLSピアおよびサーバーは、[RFC8446]の付録C.4にあるクライアント追跡防止策に従うべきです (SHOULD)。
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.
セッション再開時には、初回のフルハンドシェイクと同じレルムを持つNetwork Access Identifier（NAI）を使うことが推奨されます (RECOMMENDED)。これにより、EAPパケットを初回のフルハンドシェイクと同じ宛先へルーティングできます。この推奨に従わない場合、再開できない可能性が高くなります。プライバシー上の問題が生じない場合は、初回のフルハンドシェイクで使ったものと同じNAIを再開時にも使うことが推奨されます (RECOMMENDED) [RFC7542]。例えば、NAIの@realmは、利用者の再開試行を初回のフルハンドシェイクに結び付ける具体的な情報を含まないため、安全に再利用できます。一方、NAIのP2ZIM2F+OEVAO21nNWg2bVpgNnU=@realmを再利用すると、経路上の攻撃者が再開試行を初回のフルハンドシェイクに関連付けられます。TLS PSK識別子は通常TLS実装が導出し、ルーティング可能なレルムを含まない不透明なデータの場合があります。したがって、TLS PSK識別子だけではIdentity Responseに含める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を使って双方が認証し、サーバーが新しいチケットを1つ発行する、その後の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拡張を送信すべきです (SHOULD)。これにより、EAP-TLSサーバーは再開を拒否してフルハンドシェイクに切り替えられます。再開時にピアがkey_share拡張を送信しなかった場合、サーバーはハンドシェイクに必要な追加情報があることを示すためHelloRetryRequestを送信する必要があり、ピアはその情報を含む2回目のClientHelloを送信する必要があります。key_shareを提示し、psk_dhe_ke事前共有鍵交換モードを使うことは、鍵侵害の影響を抑えるうえでも重要です。psk_dhe_keを使うTLS 1.3では前方秘匿性が得られるため、再開に使ったPSKが侵害されても過去の接続は侵害されません。配備環境に他の方式を設定可能にするローカル要件がある場合を除き、再開にはpsk_dh_ke鍵交換モードを使用しなければなりません (MUST)。
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.
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パケットを送信しなければなりません (MUST)。メッセージフローは、EAP-TLSサーバーによる保護された成功通知、データを含まないEAP-Type=EAP-TLSのEAP-Responseパケットを返すEAP-TLSピア、そしてサーバーによるEAP-Successの順に終了します。
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メッセージを送信しなければなりません (MUST)。
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 Errorアラートメッセージを送信する場合のメッセージフローを示します。以前の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 Errorアラートを送信することは必須ではありません。TLS Errorアラートが送信されなければ、ピアまたはサーバーはエラー原因を特定できません。EAP-TLS 1.3はこの要件を強化します。実装は致命的なエラー状態に遭遇した場合、適切なTLS Errorアラートを送信しなければなりません (MUST)。
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サーバーがTLS ErrorアラートでClientHelloを拒否するメッセージフローの例を示します。サーバーは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：EAP-TLSサーバーによるClientHelloの拒否
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 Errorアラートを送信する場合のメッセージフロー例を示します。
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サーバー認証の失敗
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ピアのサーバーに対する認証が失敗し、サーバーがTLS Errorアラートを送信する場合のメッセージフロー例を示します。
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：クライアント認証の失敗
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に、ピア認証を行わないEAP-TLSフルハンドシェイクの成功例を示します（例えば[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
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]では、サーバーが受け入れ可能なパラメーターの組み合わせを見つけたものの、最初のClientHelloにハンドシェイクの続行に必要な情報がすべて含まれていない場合、EAP-TLSサーバーはClientHelloへの応答としてHelloRetryRequestを送信できます。例えば、サーバーがkey_share拡張に含まれるグループ（またはkey_share拡張自体）をサポートしていない一方、supported_groups拡張に含まれるグループのいずれかをサポートしている場合です。この場合、クライアントはサーバーがサポートするグループの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によりラウンドトリップが1回増える点に注意してください。
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：HelloRetryRequestを伴うEAP-TLS
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.
Identity Responseには、ルーティング可能でプライバシーに配慮した識別情報として、匿名NAI [RFC7542]を使用することが推奨されます (RECOMMENDED)。[RFC3748]は不透明なデータも許容しますが、そのような識別情報はルーティングできないため推奨されません (NOT RECOMMENDED)。これらを使用するのは、EAP-TLSピア、EAPオーセンティケーター、およびEAP-TLSサーバーがすべて同じネットワークに属するローカル配備に限るべきです。多くのクライアント証明書には、すでにNAI形式になっているメールアドレスなどの識別情報が含まれます。クライアント証明書のsubject nameまたはsubject alternative nameにNAIが含まれる場合は、その証明書内のNAIから匿名NAIを導出すべきです (SHOULD)。セクション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ピアおよびサーバーの実装は、匿名Network Access Identifier（NAI、[RFC7542]のセクション2.4）をサポートしなければなりません (MUST)。TLS 1.3をサポートするクライアントは、Identity Response（またはその代わりに使うメッセージ）でユーザー名やその他の恒久的な識別子を平文で送信してはなりません (MUST NOT)。[RFC7542]に従い、ユーザー名を省略する（すなわちNAIを@realmとする）ことが推奨されます (RECOMMENDED)。固定ユーザー名（例：anonymous@realm）や暗号化したユーザー名（例：xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm）など、別の形式も許容されます。NAIは[RFC7542]のセクション2.2の文法で定義されるUTF-8文字列でなければなりません (MUST)。
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では証明書メッセージが暗号化されるため、プライバシー保護のために空のcertificate_listを送信して2回目のハンドシェイクを行う必要はありません（従来のTLSバージョンでEAP-TLSを使う場合には必要でした）。TLS 1.3でEAP-TLSを使用する場合、EAP-TLSピアとサーバーはTLS 1.3の処理規則に従わなければなりません (SHALL)。つまり、EAP-TLSピアが空のcertificate_listを送信するのは、送信に適した証明書を持たない場合だけです。EAP-TLSサーバーは、空のcertificate_listを終端条件として扱ってもかまいません (MAY)。
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バイト）、およびlength（2バイト）の各ヘッダーを含めると、1つのTLSレコードの長さは最大16645オクテットです。EAP-TLSでは、EAP-ResponseおよびEAP-Requestパケットにフラグオクテットを追加し、条件付きで4オクテットのTLS Message Lengthフィールドを使ってフラグメンテーションをサポートします。実装は、フラグメント化されていないメッセージでLビットを設定してはなりません (MUST NOT)。一方、Lビットの有無にかかわらず、フラグメント化されていないメッセージを受け入れなければなりません (MUST)。
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サーバー、およびトラストアンカーの証明書を小さくし、証明書チェーンを短く保つことが推奨されます (RECOMMENDED)。また、Certificateメッセージのサイズを小さくする仕組みを使用することも推奨されます (RECOMMENDED)。フラグメンテーションを防ぐためのメッセージサイズ削減の詳細は[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に置き換わります。本節の指針は、基盤となるTLSバージョンにかかわらず、EAP-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/Identityで提示されるEAPピアの識別情報は、EAP-TLSによって認証されません。認証されていない情報を課金や認可に使ってはなりません (MUST NOT)。オーセンティケーターおよびEAP-TLSサーバーは、ルーティングやEAP方式の選択などを目的として、EAP-Response/Identityの識別情報を調べてもかまいません (MAY)。識別情報がポリシーに合わない場合、EAP-TLSサーバーはセッションを拒否してもかまいません (MAY)。この指針はセッション再開にも適用されます。セクション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サーバー識別情報は、通常、SubjectAltName（SAN）拡張に含まれる完全修飾ドメイン名（FQDN）です。EAP-TLSの配備では、異なる証明書を持つ複数のEAPサーバーを使用することがあります。そのため、EAPピア実装は、サーバー証明書の認証に使う1つ以上の信頼されたルート証明書（CA証明書）と、サーバー証明書のSAN拡張と照合する1つ以上のサーバー名を設定できるようにすべきです (SHOULD)。設定名のいずれかが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証明書とサーバー名の設定は容易ではないため、自動プロビジョニング方式の使用が推奨されます (RECOMMENDED)。例えば、eduroam連合 [RFC7593] は、設定を自動化するConfiguration Assistant Tool（CAT）を提供しています。信頼されたルートCA証明書（ユーザー設定またはシステム全体の設定）がない場合、EAPピアは初回接続時にサーバー証明書を信頼して保存するtrust on first use（TOFU）方式を実装してもかまいません (MAY)。EAPピアは、その後の接続でもサーバーが保存済みの証明書と同じ証明書を提示することを確認します。TOFUでは、帯域外で証明書を検証しない限りサーバー証明書を変更できないため、可用性確保のため複数のEAPサーバーを配備する環境など、多くの配備には適しません。TOFU方式は通信傍受攻撃を受けやすくするため、このリスクを軽減する適切な対策がある場合に限って使うべきです。
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].
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.
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 || Method-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-TYPES]を参照してください。
[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.
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.
鍵導出では、上記の長さの値を使わなければならない点に注意してください (MUST)。TLS 1.2以前では、TLS-Exporter関数に要求するデータ量を減らして出力を切り詰められましたが、TLS 1.3ではこの方法を使えません。実装がTLS-Exporter関数の出力の一部だけを使う場合でも、まず出力全体を要求し、その後で必要な部分だけを使わなければなりません (MUST)。そうしないと、上記の鍵素材の値が正しく計算されません。
This section updates Section 2.4 of [RFC5216] by amending it in accordance with the following discussion.
本節では、以下の説明に従って[RFC5216]のセクション2.4を修正し、更新します。
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.
TLS 1.3でEAP-TLSを使用する場合、EAP-TLSピアとEAP-TLSサーバーは[RFC8446]のセクション9で定義される適合要件（実装必須の暗号スイート、署名アルゴリズム、鍵交換アルゴリズム、拡張など）に従わなければなりません (MUST)。TLS 1.3でのEAP-TLSでは、機密性を備えた暗号スイートのみをサポートしなければなりません (SHALL)。
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方式と同様にデータ保護に使ってもかまいません (MAY)。
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]ではハンドシェイク後メッセージが導入されています。これらはハンドシェイクのコンテンツタイプを使い、メインのハンドシェイク後に送信できます。例えば、セッション再開に使うNewSessionTicketや、EAP-TLSでは有用でなく、通常想定されないKeyUpdateがあります。TLS Finishedを送信した後、EAP-TLSサーバーは1つ以上のEAP-Requestでハンドシェイク後メッセージを任意の数だけ送信できます。
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ピアの不確実性を減らすため、以下の手順に従わなければなりません (MUST)。
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クライアントのFinishedを正常に処理し、最後のハンドシェイクメッセージ（Finishedまたはハンドシェイク後メッセージ）を送信した後、アプリケーションデータ0x00を含む暗号化TLSレコードを送信します。[RFC3748]で定義されるように、このレコードは保護された成功結果通知です。この通知を含むEAP-Requestを送信した後、EAP-TLSサーバーはそれ以降のEAP-Requestを送信せず、EAP-Successのみを送信できます。EAP-TLSサーバーは、クライアントのFinishedを正常に処理し、最後のハンドシェイクメッセージを送信する前に、アプリケーションデータ0x00を含む暗号化TLSレコードを送信してはなりません (MUST NOT)。
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.
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サーバーのFinishedを送信または受信した後に鍵素材を導出できます。[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]に従う実装は、eapKeyAvailable変数とaaaEapKeyAvailable変数を設定できます。
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に関連する値の登録についてInternet Assigned Numbers Authority（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 Exporter Labels」レジストリに、以下のラベルを追加しました。これらのラベルは、セクション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 Exporter Labels
The security considerations of TLS 1.3 [RFC8446] apply to EAP-TLS 1.3.
TLS 1.3 [RFC8446]のセキュリティに関する考慮事項は、EAP-TLS 1.3にも適用されます。
[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層が処理します。TLS 1.3でEAP-TLSを使う場合、AEADアルゴリズム、HKDFハッシュアルゴリズム、鍵交換グループ、および署名アルゴリズムの暗号ネゴシエーションはTLSから引き継がれます。[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でも説明しています。
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.
EAP-TLSピア、EAP-TLSサーバー、または下位CAの証明書は、鍵の侵害、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.
TLS 1.3でEAP-TLSを使用する場合、信頼アンカーを除き、証明書チェーン内のすべての証明書について失効状態を確認しなければなりません (MUST)。実装は、証明書失効リスト（CRL）、Online Certificate Status Protocol（OCSP）、またはその他の標準方式・独自方式で失効を確認できます。独自方式の例には、失効リストの独自配布形式や有効期間が非常に短い証明書があります。
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に従ってCertificate Status Request（OCSPステープリング）を実装しなければなりません (MUST)。EAP-TLSピアとサーバーは、EAP-TLSサーバーの証明書チェーンの状態を検証するためにOCSPステープリングを使うことが推奨されます (RECOMMENDED)。EAP-TLSピアがCertificate Status Requestを使ってサーバー証明書チェーンの失効状態を確認する場合、有効なCertificateStatus拡張がないCertificateEntry（信頼アンカーを除く）を無効として扱い、適切なアラートでハンドシェイクを中止しなければなりません (MUST)。TLS 1.3のOCSP状態処理は以前のTLSバージョンとは異なります。[RFC8446]のセクション4.4.2.1を参照してください。TLS 1.3では、[RFC6066]のように別個のCertificateStatusメッセージを使うのではなく、対象の証明書を含むCertificateEntryにOCSP情報を載せます。これにより、信頼アンカーを除く証明書チェーン内の全証明書について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ピア実装は、認証完了後にネットワーク接続が可能になってから証明書の失効を確認する機能もサポートしなければなりません (MUST)。EAPピア実装は、ネットワーク接続後にサーバー証明書の失効状態を確認するまで、ネットワークやそのサービスを信頼すべきではありません (SHOULD NOT)。EAPピアは安全な転送路を使ってサーバー証明書の失効状態を確認しなければなりません (MUST)。サーバー証明書の失効確認が終わる前に、EAPピアは他の通信を送信すべきではありません (SHOULD NOT)。
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.
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.
保護されたTLS Errorアラートは保護された失敗結果通知であり、失敗結果が攻撃者に偽装されていないことをEAP-TLSピアとサーバーが確認できます。保護された失敗結果通知は完全性とリプレイ保護を提供しますが、認証されていない場合もあります (MAY)。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]にはない新設の節です。本節の指針は、基盤となるTLSバージョンにかかわらず、EAP-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サーバー実装は未認証ピアのネットワークアクセスを適切に制限するよう注意しなければなりません (MUST)。また、再開セッションに当初意図した以上の権限を与えないよう、実装はセッション再開を慎重に扱わなければなりません (MUST)。ネットワークアクセスを制限する方法の例として、ベンダーのウォールドガーデン機能や隔離ネットワーク機能があります。
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]、Diameter [RFC6733]、またはネットワークアクセス認証搬送プロトコル（PANA）[RFC5191]などの他のプロトコルにカプセル化されます。カプセル化プロトコルは、EAP以外の追加情報をEAP-TLSサーバーに渡す場合もあります。これには、オーセンティケーター、EAP-TLSピア、またはEAPより上位・下位のプロトコル層に関する情報（MACアドレス、IPアドレス、ポート番号、Wi-Fi Service Set Identifier（SSID）など）が含まれますが、これらに限りません。これらのプロトコル内でEAP-TLSを実装するサーバーは、EAP-TLS交換の情報と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/Identityで提示される識別情報はEAP-TLSによって認証されないため、攻撃者は容易に偽造、改変、または再送できます。認可とアカウンティングは、証明書内の情報やPSK識別子などの認証済み情報、およびセクション5.7の説明に従って再開用に保存したデータに基づかなければなりません (MUST)。[RFC7542]のセクション4で規定されるNetwork Access Identifier（NAI）の要件も引き続き適用され、それらに従わなければなりません (MUST)。
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サーバーは、カプセル化プロトコルから渡されたEAP以外の情報に基づいてセッションを拒否してもかまいません (MAY)。例えば、オーセンティケーターのMACアドレスが想定されたポリシーに合わない場合が該当します。
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.
サーバー証明書の認証に使う信頼されたルート証明書（CA証明書）と、SubjectAltName（SAN）拡張と照合するサーバー名を1つ以上設定できることに加え、EAPピア実装は、設定された許容SANを、そのサーバー証明書を発行すべき特定のCA（または複数のCA）に結び付けてもかまいません (MAY)。これにより、不正なCAや侵害されたCAによる攻撃を防げます。
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]にはない新設の節です。本節の指針は、基盤となるTLSバージョンにかかわらず、EAP-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ピアとサーバーが、初回のフルハンドシェイク時の証明書チェーンなど、認可に必要な情報を安全に取得できなければなりません。本書では、これらの情報を「キャッシュデータ」と呼びます。再開時の認可は、このキャッシュデータに基づかなければなりません (MUST)。EAP-TLSピアとサーバーは、キャッシュした証明書データについて失効状態を改めて確認してもかまいません (MAY)。再開時にも、認可に関するすべてのセキュリティポリシーに従わなければなりません (MUST)。初回のフルハンドシェイク以降に証明書が失効したり、相手に与える認可が縮小されたりしている可能性があります。キャッシュされた失効情報が十分に新しくない場合、EAP-TLSピアまたはサーバーはフルTLSハンドシェイクを強制してもかまいません (MAY)。
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つあります。1つ目は、EAP-TLSサーバーとクライアントが情報をそれぞれローカルに保存する方法です。保存した情報は識別子で特定します。TLS 1.3より前のバージョンではセッションID、TLS 1.3ではPSK識別子を使えます。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クライアントは、再開時の認可判断に十分なキャッシュデータを初回のフルハンドシェイク中に保存しなければなりません (MUST)。キャッシュデータを安全に取得できない場合、セッション再開を行ってはなりません (MUST NOT)。
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.
セッションについてアカウンティングを行うシステムがある場合も、上記の要件が適用されます。アカウンティングの記録は認証済み識別情報に結び付ける必要がありますが、再開時にはその識別情報が提示されないため、キャッシュデータにアクセスできなければアカウンティングを行えません。したがって、セッションのアカウンティングを予定するシステムは、後続の記録に使える識別子を保存すべきです (SHOULD)。
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やチケットの有効期間にかかわらず、再開用PSKまたはチケット（および関連するキャッシュデータ）を604800秒（7日間）を超えて保存してはなりません (MUST NOT)。EAP-TLSピアはローカルポリシーに基づき、それより早く削除してもかまいません (MAY)。証明書チェーン内の証明書が失効または期限切れになった場合、EAP-TLSサーバーまたはピアはキャッシュデータを削除してもかまいません (MAY)。いずれの場合も、再開を試みると代わりにフル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交換の情報（例：EAP-Response/Identityで提示された識別情報）やEAP以外の情報（例：IPアドレス）は、初回のフルハンドシェイクから再開までの間に変わる可能性があります。この変化は、検査時と使用時の状態が異なる（time-of-check time-of-use、TOCTOU）というセキュリティ上の脆弱性を生みます。悪意ある利用者や侵害された利用者が、初回認証時と再開時に異なる情報を提示すると、本来許可されないアクセスを得る可能性があります。
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.
初回のフルハンドシェイクから再開までに変わった情報を使って認可、アカウンティング、またはポリシーの判断を行っており、その変化によって判断が変わり得る場合、その判断を再評価しなければなりません (MUST)。再開時に提示された情報に基づいて、認可、アカウンティング、およびポリシーの判断を再評価することが推奨されます (RECOMMENDED)。EAP-TLSサーバーは、再開時に提示された情報が初回認証時の情報と一致しない場合、再開を拒否してもかまいません (MAY)。安全な判断ができない場合、サーバーは再開を拒否し、フルハンドシェイクに進むべきです (SHOULD)。
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のセッション再開に関するセキュリティ上の考慮事項があります。
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].
セクション2.1.8で説明したように、TLS 1.3は以前のTLSバージョンよりも高いプライバシー保護を提供します。本節では、TLS 1.3でのEAP-TLSのプライバシー特性だけを説明します。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は、標準のTLS 1.3ハンドシェイクメッセージをEAPパケットにカプセル化して送信します。さらに、EAP-TLSピアは最初のEAP-Responseで識別情報を送信します。EAP-TLSのRequestおよびResponseパケットのその他のフィールドには、平文のプライバシー関連情報は含まれません。
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.
Identity Responseや証明書を盗聴して利用者を追跡することは、多くのEAP方式に共通する既知の問題です。TLS 1.3でEAP-TLSを使う場合、すべての証明書が暗号化され、匿名NAIなどを使えばIdentity Responseのユーザー名部分も開示されません。証明書がすべて暗号化されても、サーバーの識別情報が保護されるのは受動的攻撃者に対してだけですが、クライアントの識別情報は受動的攻撃者と能動的攻撃者の両方から保護されます。他の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ピアはレコードパディングを使用すべきです (SHOULD)。[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.
匿名NAIを使わない場合は、プライバシーに配慮した識別子を慎重に生成する必要があります。同じレルム内の同一利用者に属する2つの識別子と、別の利用者に属する2つの識別子とを攻撃者が計算上区別できないよう、識別子を暗号学的に安全な方法で生成しなければなりません (MUST)。例えば、ランダムなバイト列や暗号文などのランダムまたは擬似ランダムなユーザー名を使い、各擬似ランダムユーザー名を一度だけ使う方法があります。プライバシーに配慮したユーザー名には、特定利用者との関連付けに使える部分文字列を含めてはなりません (MUST NOT)。また、複数の認証を通じて同じ値となる固定対応によって、そのようなユーザー名を生成してはなりません (MUST NOT)。
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.
TLS 1.2のみをサポートし、プライバシー保護のない静的RSA鍵交換を使うEAP-TLSサーバーとの通信を許可するポリシーを持つEAP-TLSピアは、ユーザー名を開示する危険があります。この場合、能動的攻撃者は、TLS 1.3対応サーバーがプライバシー保護のないTLS 1.2しかサポートしていないとピアに信じ込ませることができます。攻撃者はEAP-TLSサーバーになりすまし、静的RSA鍵交換でTLS 1.2をネゴシエートしたうえで、ピアが空の証明書メッセージを送ってプライバシーを保護しようとしたときにTLSアラートを送ればよいのです。静的RSA鍵交換では、攻撃者（EAP-TLSサーバーになりすました者）はFinishedメッセージまで秘密鍵の所持を証明しません。そのため、EAP-TLSピアが誤ってユーザー名を攻撃者に開示するおそれがあります。したがって、プライバシー保護のないTLS 1.2および静的RSAベースの暗号スイートでEAP-TLSを使用しないことが推奨されます (RECOMMENDED)。このため、TLS 1.2のEAP-TLSサーバーがピアからの空の証明書メッセージに応答してTLSアラートを含むEAP-TLS/Requestを送信した場合、EAP-TLSピアはEAP認証を続行すべきではありません (SHOULD NOT)。
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.
広範な監視とは、利用者に対する大規模な監視を指します。EAP-TLSでは、利用者がネットワークに接続した際の追跡を目的として、EAP-TLSピア端末が広範な監視攻撃の標的になることがあります。TLS 1.3でのEAP-TLSは、より多くの情報を暗号化し、プライバシー保護を必須とし、常に前方秘匿性を提供するため、広範な監視に対する保護を大幅に強化します。前述のプライバシー攻撃に加え、大規模監視によって、広い地理的範囲や異なるアクセスネットワークをまたいで利用者が追跡される可能性があります。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と同様に新しい鍵を定期的に導出することで、前方秘匿性を実現できます。
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実装は既知の攻撃を軽減しなければなりません (MUST)。また、[RFC8447]や[RFC9155]など、EAPおよびTLSに関連する新たなセキュリティ指針と要件を監視し、それに従う必要があります。
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.
同じ証明書を複数のプロトコルで使えるようにすると、攻撃者が一方のプロトコルで認証した後、別のプロトコルでそのセッションを「再開」できる可能性があります。セクション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では、再開時に認可規則を再適用するよう推奨していますが、必須とはしていません。そのため、このクロスプロトコル再開によって攻撃者が認可ポリシーを回避し、保護対象システムへ意図されていないアクセスを得る可能性があります。適切な認可情報を再開時に利用できるようにすることに加え、プロトコルごとに異なる証明書と再開キャッシュを使い、プロトコル間の利用を分離することが推奨されます (RECOMMENDED)。
[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., "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>.
[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., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <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., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, <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., 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>.
[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., "Keying Material Exporters for Transport Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705, March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[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>.
[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., 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>.
[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., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, <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., "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>.
[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., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <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 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.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 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.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 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>.
[MulteFire] MulteFire Alliance, "MulteFire Release 1.1 Specification", 2019.
[MulteFire] MulteFire Alliance, "MulteFire Release 1.1 Specification", 2019.
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)", June 2021.
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible Authentication Protocol (PEAP)", June 2021.
[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., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, <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. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, DOI 10.17487/RFC2246, January 1999, <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] 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>.
[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., 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>.
[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., 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>.
[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., 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>.
[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., and P. Eronen, "The Network Access Identifier", RFC 4282, DOI 10.17487/RFC4282, December 2005, <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. 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>.
[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., 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>.
[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., 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>.
[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., 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>.
[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. 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>.
[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., 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>.
[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. 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>.
[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. 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>.
[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., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <https://www.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., 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>.
[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., 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>.
[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., 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>.
[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., 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>.
[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., and T. Wolniewicz, "The eduroam Architecture for Network Roaming", RFC 7593, DOI 10.17487/RFC7593, September 2015, <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] 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>.
[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. 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>.
[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] 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>.
[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., 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>.
[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., 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>.
[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>.
[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>.
[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., "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-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-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>.
[TS.33.501] 3GPP, "Security architecture and procedures for 5G system", Release 17, TS 33.501, January 2022.
[TS.33.501] 3GPP, "Security architecture and procedures for 5G system", Release 17, TS 33.501, January 2022.
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が使用されている場合は、以下のように更新されます。
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, Ari Keränen, Benjamin Kaduk, Jouni Malinen, Oleg Pekar, Eric Rescorla, Jim Schaad, Joseph Salowey, Martin Thomson, Vesa Torvinen, Hannes Tschofenig、およびHeikki Vatiainenに感謝します。文書シェパードのJoseph Saloweyには特に感謝します。
Contributors
貢献者
Alan DeKok, FreeRADIUS
Alan DeKok, FreeRADIUS
Authors' Addresses
著者の住所
John Preuß Mattsson Ericsson SE-164 40 Kista Sweden
John Preuß Mattsson Ericsson SE-164 40 Kista Sweden
Email: john.mattsson@ericsson.com
Mohit Sethi Ericsson FI-02420 Jorvas Finland
Mohit Sethi Ericsson FI-02420 Jorvas Finland
Email: mohit@iki.fi