Internet Engineering Task Force (IETF) J. Arkko
Request for Comments: 9678 K. Norrman
Updates: 5448, 9048 J. Preuß Mattsson
Category: Standards Track Ericsson
ISSN: 2070-1721 March 2025
This document updates RFC 9048, "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')", and its predecessor RFC 5448 with an optional extension providing ephemeral key exchange. The extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated, provides forward secrecy for the session keys generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term key from obtaining session keys established in the past. In addition, EAP-AKA' FS mitigates passive attacks (e.g., large-scale pervasive monitoring) against future sessions. This forces attackers to use active attacks instead.
このドキュメントは、RFC 9048、「3GPPモバイルネットワーク認証とキー契約（EAP-AKA '）の改善された拡張可能な認証プロトコルメソッド」を更新し、その前任者のRFC 5448は、一時的なキー交換を提供するオプションの拡張機能を備えています。拡張eap-aka 'forward Secrecy（eap-aka' fs）は、交渉されたときに、Eap-akaでの認証実行の一部として生成されたセッションキーに秘密を提供します。これにより、過去に確立されたセッションキーを取得することで、長期キーにアクセスした攻撃者が防止されます。さらに、EAP-AKA 'FSは、将来のセッションに対するパッシブ攻撃（例：大規模な広範なモニタリング）を緩和します。これにより、攻撃者は代わりにアクティブな攻撃を使用せざるを得ません。
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/rfc9678.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9678で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Requirements Language
3. Protocol Design and Deployment Objectives
4. Background
4.1. AKA
4.2. EAP-AKA' Protocol
4.3. Attacks Against Long-Term Keys in Smart Cards
5. Protocol Overview
6. Extensions to EAP-AKA'
6.1. AT_PUB_ECDHE
6.2. AT_KDF_FS
6.3. Forward Secrecy Key Derivation Functions
6.4. ECDHE Groups
6.5. Message Processing
6.5.1. EAP-Request/AKA'-Identity
6.5.2. EAP-Response/AKA'-Identity
6.5.3. EAP-Request/AKA'-Challenge
6.5.4. EAP-Response/AKA'-Challenge
6.5.5. EAP-Request/AKA'-Reauthentication
6.5.6. EAP-Response/AKA'-Reauthentication
6.5.7. EAP-Response/AKA'-Synchronization-Failure
6.5.8. EAP-Response/AKA'-Authentication-Reject
6.5.9. EAP-Response/AKA'-Client-Error
6.5.10. EAP-Request/AKA'-Notification
6.5.11. EAP-Response/AKA'-Notification
7. Security Considerations
7.1. Deployment Considerations
7.2. Security Properties
7.3. Denial of Service
7.4. Identity Privacy
7.5. Unprotected Data and Privacy
7.6. Forward Secrecy within AT_ENCR
7.7. Post-Quantum Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgments
Authors' Addresses
Many different attacks have been reported as part of the revelations associated with pervasive surveillance. Some of the reported attacks involved compromising the Universal Subscriber Identity Module (USIM) card supply chain. Attacks revealing the AKA long-term key may occur, for instance:
広範な監視に関連する啓示の一部として、多くの異なる攻撃が報告されています。報告された攻撃のいくつかは、ユニバーサルサブスクライバーIDモジュール（USIM）カードサプライチェーンの侵害を伴いました。別名長期キーを明らかにする攻撃は、たとえば次のように発生する可能性があります。
* during the manufacturing process of USIM cards,
* USIMカードの製造プロセス中、
* during the transfer of the cards and associated information to the operator, and
* カードと関連情報をオペレーターに転送する際、および
* when the system is running.
* システムが実行されているとき。
Since the publication of reports about such attacks (see [Heist2015]), manufacturing and provisioning processes have gained much scrutiny and have improved.
そのような攻撃に関するレポートの公開（[Heist2015]を参照）以来、製造およびプロビジョニングプロセスは多くの精査を受け、改善されています。
However, the danger of resourceful attackers attempting to gain information about long-term keys is still a concern because these keys are high-value targets. Note that the attacks are largely independent of the used authentication technology; the issue is not vulnerabilities in algorithms or protocols, but rather the possibility of someone gaining unauthorized access to key material. Furthermore, an explicit goal of the IETF is to ensure that we understand the surveillance concerns related to IETF protocols and take appropriate countermeasures [RFC7258].
ただし、これらのキーは価値の高いターゲットであるため、長期的なキーに関する情報を取得しようとする機知に富んだ攻撃者の危険性は依然として懸念事項です。攻撃は、使用されている認証テクノロジーから大きく依存しないことに注意してください。この問題は、アルゴリズムやプロトコルの脆弱性ではなく、誰かが重要な資料への不正アクセスを得る可能性です。さらに、IETFの明示的な目標は、IETFプロトコルに関連する監視懸念を理解し、適切な対策を講じることです[RFC7258]。
While strong protection of manufacturing and other processes is essential in mitigating surveillance and other risks associated with AKA long-term keys, there are also protocol mechanisms that can help.
製造やその他のプロセスの強力な保護は、監視や別名長期キーに関連するその他のリスクの緩和に不可欠ですが、役立つプロトコルメカニズムもあります。
This document updates [RFC9048], "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')", with an optional extension providing ephemeral key exchange, which minimizes the impact of long-term key compromise and strengthens the identity privacy requirements. This is important, given the large number of users of AKA in mobile networks.
このドキュメントは[RFC9048]を更新し、「3GPPモバイルネットワーク認証と主要な契約（EAP-AKA '）の拡張可能な認証プロトコル法を改善します」。これは、モバイルネットワークのAKAの多数のユーザーを考えると重要です。
The extension, when negotiated, provides Forward Secrecy (FS) [DOW1992] for the session key generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term key in a USIM card from getting access to past session keys. In addition to FS, the included Diffie-Hellman exchange forces attackers to be active if they want access to future session keys, even if they have access to the long-term key. This is beneficial because active attacks demand many more resources to launch and are easier to detect. As with other protocols, an active attacker with access to the long-term key material will, of course, be able to attack all future communications, but risks detection, particularly if done at scale.
拡張機能は、交渉されたときに、EAP-AKAで実行される認証実行の一部として生成されたセッションキーに対して、フォワード秘密（FS）[DOW1992]を提供します。これにより、USIMカードの長期キーにアクセスして過去のセッションキーにアクセスすることができなくなります。FSに加えて、含まれているDiffie-Hellman Exchangeは、長期キーにアクセスできる場合でも、将来のセッションキーにアクセスしたい場合にアクティブになります。これは、アクティブな攻撃では、発売にもっと多くのリソースを必要とし、検出が容易であるため、これは有益です。他のプロトコルと同様に、長期的なキーマテリアルにアクセスできるアクティブな攻撃者は、もちろんすべての将来のコミュニケーションを攻撃することができますが、特に大規模に行われた場合は、リスクの検出が可能になります。
It should also be noted that 5G network architecture [TS.33.501] includes the use of the EAP framework for authentication. While any methods can be run, the default authentication method within that context will be EAP-AKA'. As a result, improvements in EAP-AKA' security have the potential to improve security for many users.
また、5Gネットワークアーキテクチャ[Ts.33.501]には、認証用のEAPフレームワークの使用が含まれていることにも注意してください。すべてのメソッドを実行できますが、そのコンテキスト内のデフォルトの認証方法はEAP-AKA 'になります。その結果、EAP-AKAのセキュリティの改善は、多くのユーザーのセキュリティを改善する可能性があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
The extension specified here reuses large portions of the current structure of 3GPP interfaces and functions, with the rationale that this will make the construction more easily adopted. In particular, the construction keeps the interface between the USIM and the mobile terminal intact. As a consequence, there is no need to roll out new credentials to existing subscribers. The work is based on an earlier paper (see [TrustCom2015]) and uses much of the same material but is applied to EAP rather than the underlying AKA method.
ここで指定された拡張機能は、3GPPインターフェイスと機能の現在の構造の大部分を再利用し、これにより構造がより簡単に採用されるという理論的根拠とともに。特に、この構造により、USIMとモバイル端末の間のインターフェースがそのまま続きます。結果として、既存の加入者に新しい資格情報を展開する必要はありません。作業は以前の論文（[Trustcom2015]を参照）に基づいており、同じ素材の多くを使用していますが、基礎となるAKAメソッドではなくEAPに適用されます。
It has been a goal to implement this change as an extension of the widely supported EAP-AKA' method, rather than implement a completely new authentication method. The extension is implemented as a set of new, optional attributes that are provided alongside the base attributes in EAP-AKA'. Old implementations can ignore these attributes, but their presence will nevertheless be verified as part of the base EAP-AKA' integrity verification process, helping protect against bidding down attacks. This extension does not increase the number of rounds necessary to complete the protocol.
まったく新しい認証方法を実装するのではなく、広くサポートされているEAP-AKA 'メソッドの拡張としてこの変更を実装することが目標となっています。拡張機能は、EAP-AKA 'のベース属性とともに提供される新しいオプションの属性のセットとして実装されます。古い実装はこれらの属性を無視することができますが、それでもそれらの存在は、基本的なEAP-AKAの整合性検証プロセスの一部として検証され、入札攻撃から保護されます。この拡張機能は、プロトコルを完了するために必要なラウンド数を増やしません。
The use of this extension is at the discretion of the authenticating parties. It should be noted that FS and defenses against passive attacks do not solve all problems, but they can provide a partial defense that increases the cost and risk associated with pervasive surveillance.
この拡張機能の使用は、認証当事者の裁量にあります。受動的攻撃に対するFSと防御はすべての問題を解決しないが、広範な監視に関連するコストとリスクを高める部分的な防御を提供できることに注意する必要があります。
While adding FS to the existing mobile network infrastructure can be done in multiple different ways, this document specifies a solution that is relatively easy to deploy. In particular:
既存のモバイルネットワークインフラストラクチャにFSを追加することは、さまざまな方法で実行できますが、このドキュメントは、展開が比較的簡単なソリューションを指定します。特に：
* As noted above, no new credentials are needed; there is no change to USIM cards.
* 上記のように、新しい資格情報は必要ありません。USIMカードに変更はありません。
* FS property can be incorporated into any current or future system that supports EAP, without changing any network functions beyond the EAP endpoints.
* FSプロパティは、EAPエンドポイントを超えてネットワーク機能を変更することなく、EAPをサポートする現在または将来のシステムに組み込むことができます。
* Key generation happens at the endpoints, enabling the highest grade key material to be used both by the endpoints and the intermediate systems (such as access points that are given access to specific keys).
* キー生成はエンドポイントで発生し、エンドポイントと中間システム（特定のキーへのアクセスが与えられるアクセスポイントなど）の両方で最も高いグレードのキー資料を使用できます。
* While EAP-AKA' is just one EAP method, for practical purposes, FS being available for both EAP-TLS [RFC5216] [RFC9190] and EAP-AKA' ensures that, for many practical systems, FS can be enabled for either all or a significant fraction of users.
* EAP-AKA 'は実用的な目的のために1つのEAPメソッドですが、FSはEAP-TLS [RFC5216] [RFC9190]とEAP-AKAの両方で利用可能であり、多くの実用的なシステムでは、ユーザーのすべてまたはかなりの部分でFSを有効にすることができます。
The reader is assumed to have a basic understanding of the EAP framework [RFC3748].
読者は、EAPフレームワーク[RFC3748]を基本的に理解していると想定されています。
We use the term "Authentication and Key Agreement" (or "AKA") for the main authentication and key agreement protocol used by 3GPP mobile networks from the third generation (3G) and onward. Later generations add new features to AKA, but the core remains the same. It is based on challenge-response mechanisms and symmetric cryptography. In contrast to its earlier GSM counterparts, AKA provides long key lengths and mutual authentication. The phone typically executes AKA in a USIM. A USIM is technically just an application that can reside on a removable Universal Integrated Circuit Card (UICC), an embedded UICC, or integrated in a Trusted Execution Environment (TEE). In this document, we use the term "USIM card" to refer to any Subscriber Identity Module (SIM) capable of running AKA.
3GPPモバイルネットワークが第3世代（3G）および以降に使用する主な認証と主要な契約プロトコルには、「認証と主要な契約」（または「別名」）という用語を使用します。後の世代は別名に新しい機能を追加しますが、コアは同じままです。これは、チャレンジ応答メカニズムと対称暗号化に基づいています。以前のGSMカウンターパートとは対照的に、別名は長いキーの長さと相互認証を提供します。電話は通常、USIMで別名を実行します。USIMは、技術的には、取り外し可能なユニバーサル統合回路カード（UICC）、埋め込みUICC、または信頼できる実行環境（TEE）に統合された統合されたアプリケーションです。このドキュメントでは、「USIMカード」という用語を使用して、AKAを実行できるサブスクライバーIDモジュール（SIM）を参照しています。
The goals of AKA are to mutually authenticate the USIM and the so-called home environment, which is the authentication Server in the subscriber's home operator's network, and to establish key material between the two.
別名の目標は、サブスクライバーのホームオペレーターのネットワーク内の認証サーバーであるUSIMといわゆるホーム環境を相互に認証し、2つの間に重要な資料を確立することです。
AKA works in the following manner:
別名は次の方法で機能します。
* The USIM and the home environment have agreed on a long-term symmetric key beforehand.
* USIMとホーム環境は、事前に長期的な対称キーに同意しています。
* The actual authentication process starts by having the home environment produce an authentication vector, based on the long-term key and a sequence number. The authentication vector contains a random part RAND, an authenticator part AUTN used for authenticating the network to the USIM, an expected result part XRES, a 128-bit session key for the integrity check IK, and a 128-bit session key for the encryption CK.
* 実際の認証プロセスは、長期キーとシーケンス番号に基づいて、ホーム環境に認証ベクトルを生成させることから始まります。認証ベクトルには、ランダムパーツRAND、USIMへのネットワークを認証するために使用される認証装置パーツAUTN、予想される結果パートXRES、Integrity Check IKの128ビットセッションキー、暗号化CKの128ビットセッションキーが含まれています。
* The authentication vector is passed to the serving network, which uses it to authenticate the device.
* 認証ベクトルは、デバイスを認証するために使用するサービングネットワークに渡されます。
* The RAND and the AUTN are delivered to the USIM.
* ランドとautnはUSIMに配信されます。
* The USIM verifies the AUTN, again based on the long-term key and the sequence number. If this process is successful (the AUTN is valid and the sequence number used to generate the AUTN is within the correct range), the USIM produces an authentication result RES and sends it to the serving network.
* USIMは、再び長期キーとシーケンス番号に基づいてAUTNを検証します。このプロセスが成功した場合（AUTNが有効であり、AUTNの生成に使用されるシーケンス番号が正しい範囲内にあります）、USIMは認証結果RESを生成し、サービングネットワークに送信します。
* The serving network verifies that the result from the USIM matches the expected value in the authentication vector. If it does, the USIM is considered authenticated, and the IK and CK can be used to protect further communications between the USIM and the home environment.
* サービングネットワークは、USIMからの結果が認証ベクトルの期待値と一致することを確認します。もしそうなら、USIMは認証されていると見なされ、IKとCKを使用してUSIMとホーム環境間のさらなる通信を保護できます。
When AKA is embedded into EAP, the authentication processing on the network side is moved to the home environment. The 3GPP Authentication Database (AD) generates authentication vectors. The 3GPP authentication Server takes the role of EAP Server. The USIM combined with the mobile phone takes the role of client. The difference between EAP-AKA [RFC4187] and EAP-AKA' [RFC9048] is that EAP-AKA' binds the derived keys to the name of the access network. Figure 1 describes the basic flow in the EAP-AKA' authentication process. The definition of the full protocol behavior, along with the definition of the attributes AT_RAND, AT_AUTN, AT_MAC, and AT_RES can be found in [RFC9048] and [RFC4187]. Note the use of EAP terminology from hereon. That is, the 3GPP serving network takes on the role of an EAP access network.
AKAがEAPに埋め込まれると、ネットワーク側の認証処理はホーム環境に移動されます。3GPP認証データベース（AD）は、認証ベクトルを生成します。3GPP認証サーバーは、EAPサーバーの役割を担います。携帯電話と組み合わされたUSIMは、クライアントの役割を担っています。EAP-AKA [RFC4187]とEAP-AKA '[RFC9048]の違いは、EAP-AKAが派生キーをアクセスネットワークの名前に結合することです。図1は、EAP-AKAの認証プロセスの基本的なフローを示しています。AT_RAND、AT_AUTN、AT_MAC、およびAT_RESの属性の定義とともに、完全なプロトコル動作の定義は[RFC9048]および[RFC4187]にあります。本書からのEAP用語の使用に注意してください。つまり、3GPPサービングネットワークは、EAPアクセスネットワークの役割を引き受けます。
Peer Server
| |
| EAP-Request/Identity |
|<-----------------------------------------------------------+
| |
| EAP-Response/Identity |
| (Includes user's Network Access Identifier (NAI)) |
+----------------------------------------------------------->|
| +-------------------------------------------------------+--+
| | The Server determines the network name and ensures that |
| | the given access network is authorized to use the |
| | claimed name. The Server then runs the EAP-AKA' |
| | algorithms generating RAND and AUTN, and derives session |
| | keys from CK' and IK'. RAND and AUTN are sent as |
| | AT_RAND and AT_AUTN attributes, whereas the network name |
| | is transported in the AT_KDF_INPUT attribute. AT_KDF |
| | signals the used key derivation function. The session |
| | keys are used to create the AT_MAC attribute. |
| +-------------------------------------------------------+--+
| |
| EAP-Request/AKA'-Challenge |
| (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC) |
|<-----------------------------------------------------------+
+--+------------------------------------------------------+ |
| The Peer determines what the network name should be, | |
| based on, e.g., what access technology it is using. | |
| The Peer also retrieves the network name sent by the | |
| network from the AT_KDF_INPUT attribute. The two names | |
| are compared for discrepancies, and if they do not | |
| match, the authentication is aborted. Otherwise, the | |
| network name from the AT_KDF_INPUT attribute is used | |
| in running the EAP-AKA' algorithms, verifying AUTN from | |
| AT_AUTN and Message Authentication Code (MAC) from the | |
| AT_MAC attributes. The Peer then generates RES. The | |
| Peer also derives session keys from CK'/IK. The AT_RES | |
| and AT_MAC attributes are constructed. | |
+--+------------------------------------------------------+ |
| |
| EAP-Response/AKA'-Challenge |
| (AT_RES, AT_MAC) |
+----------------------------------------------------------->|
| +-----------------------------------------------------+--+
| | The Server checks the RES and MAC values received in |
| | AT_RES and AT_MAC, respectively. Success requires |
| | both compared values match, respectively. |
| +-----------------------------------------------------+--+
| |
| EAP-Success |
|<-----------------------------------------------------------+
| |
Figure 1: EAP-AKA' Authentication Process
図1：EAP-AKA '認証プロセス
The general security properties and potential vulnerabilities of AKA and EAP-AKA' are discussed in [RFC9048].
AKAおよびEAP-AKAの一般的なセキュリティ特性と潜在的な脆弱性については、[RFC9048]で説明しています。
An important question in that discussion relates to the potential compromise of long-term keys, as discussed earlier. Attacks on long-term keys are not specific to AKA or EAP-AKA', and all security systems fail, at least to some extent, if key material is stolen. However, it would be preferable to retain some security even in the face of such attacks. This document specifies a mechanism that reduces the risks of compromising key material belonging to previous sessions, before the long-term keys were compromised. It also forces attackers to be active even after the compromise.
その議論の重要な質問は、前述のように、長期キーの潜在的な妥協に関するものです。長期キーへの攻撃は、AKAまたはEAP-AKAに固有のものではなく、すべてのセキュリティシステムが盗まれている場合、少なくともある程度は失敗します。ただし、そのような攻撃に直面しても、セキュリティを保持することが望ましいでしょう。このドキュメントは、長期キーが損なわれる前に、以前のセッションに属する重要な資料を侵害するリスクを減らすメカニズムを指定します。また、攻撃者に妥協後もアクティブになります。
Forward Secrecy (FS) for EAP-AKA' is achieved by using an Elliptic Curve Diffie-Hellman (ECDH) exchange [RFC7748]. To provide FS, the exchange must be run in an ephemeral manner, i.e., both sides generate temporary keys according to the negotiated ciphersuite. For example, for X25519, this is done as specified in [RFC7748]. This method is referred to as "ECDHE", where the last "E" stands for "Ephemeral". The two initially registered elliptic curves and their wire formats are chosen to align with the elliptic curves and formats specified for Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4 of 3GPP [TS.33.501].
EAP-AKAの前方秘密（FS）は、楕円曲線diffie-hellman（ECDH）Exchange [RFC7748]を使用して達成されます。FSを提供するには、交換は一時的な方法で実行する必要があります。つまり、双方が交渉された暗号化に従って一時的なキーを生成する必要があります。たとえば、X25519の場合、これは[RFC7748]で指定されているとおりに行われます。この方法は「ecdhe」と呼ばれ、最後の「e」は「はかない」を表します。最初に登録された2つの楕円曲線とそのワイヤ形式は、3GPP [Ts.33.501]の付録C.3.4のサブスクリプション隠し識別子（suci）暗号化に指定された楕円曲線と形式に沿って選択されます。
The enhancements in the EAP-AKA' FS protocol are compatible with the signaling flow and other basic structures of both AKA and EAP-AKA'. The intent is to implement the enhancement as optional attributes that legacy implementations ignore.
EAP-AKA 'FSプロトコルの拡張機能は、AKAとEAP-AKAの両方のシグナル伝達の流れやその他の基本構造と互換性があります。目的は、レガシーの実装が無視するオプションの属性として強化を実装することです。
The purpose of the protocol is to achieve mutual authentication between the EAP Server and Peer and to establish key material for secure communication between the two. This document specifies the calculation of key material, providing new properties that are not present in key material provided by EAP-AKA' in its original form.
プロトコルの目的は、EAPサーバーとピア間の相互認証を実現し、2つの間で安全な通信のための重要な資料を確立することです。このドキュメントは、主要な材料の計算を指定し、元の形式でEAP-AKAが提供する重要な資料に存在しない新しいプロパティを提供します。
Figure 2 describes the overall process. Since the goal has been to not require new infrastructure or credentials, the flow diagrams also show the conceptual interaction with the USIM card and the home environment. Recall that the home environment represents the 3GPP Authentication Database (AD) and Server. The details of those interactions are outside the scope of this document; however, and the reader is referred to the 3GPP specifications (for 5G, this is specified in 3GPP [TS.33.501]).
図2は、全体的なプロセスを説明しています。目標は新しいインフラストラクチャや資格情報を必要としないことであったため、フロー図は、USIMカードとホーム環境との概念的な相互作用も示しています。ホーム環境は3GPP認証データベース（AD）とサーバーを表していることを思い出してください。これらの相互作用の詳細は、このドキュメントの範囲外です。ただし、読者は3GPP仕様に紹介されます（5Gの場合、これは3GPP [Ts.33.501]で指定されています）。
USIM Peer Server AD
| | | |
| | EAP-Req/Identity | |
| |<---------------------------+ |
| | | |
| | EAP-Resp/Identity | |
| | (Privacy-Friendly) | |
| +--------------------------->| |
| +-------+----------------------------+----------------+----+
| | The Server now has an identity for the Peer. The Server |
| | then asks the help of the AD to run EAP-AKA algorithms, |
| | generating RAND, AUTN, XRES, CK, and IK. Typically, the |
| | AD performs the first part of derivations so that the |
| | authentication Server gets the CK' and IK' keys already |
| | tied to a particular network name. |
| +-------+----------------------------+----------------+----+
| | | |
| | | ID, key deriv. |
| | | function, |
| | | network name |
| | +--------------->|
| | | |
| | | RAND, AUTN, |
| | | XRES, CK', IK' |
| | |<---------------+
| +-------+----------------------------+----------------+----+
| | The Server now has the needed authentication vector. It |
| | generates an ephemeral key pair, and sends the public |
| | key of that key pair and the first EAP method message to |
| | the Peer. In the message the AT_PUB_ECDHE attribute |
| | carries the public key and the AT_KDF_FS attribute |
| | carries other FS-related parameters. Both of these are |
| | skippable attributes that can be ignored if the Peer |
| | does not support this extension. |
| +-------+----------------------------+----------------+----+
| | | |
| | EAP-Req/AKA'-Challenge | |
| | AT_RAND, AT_AUTN, AT_KDF, | |
| | AT_KDF_FS, AT_KDF_INPUT, | |
| | AT_PUB_ECDHE, AT_MAC | |
| |<---------------------------+ |
+--+--------------+----------------------------+---------+ |
| The Peer checks if it wants to do the FS extension. | |
| If yes, it will eventually respond with AT_PUB_ECDHE | |
| and AT_MAC. If not, it will ignore AT_PUB_ECDHE and | |
| AT_KDF_FS and base all calculations on basic EAP-AKA' | |
| attributes, continuing just as in EAP-AKA' per RFC | |
| 9048 rules. In any case, the Peer needs to query the | |
| auth parameters from the USIM card. | |
+--+--------------+----------------------------+---------+ |
| | | |
| RAND, AUTN | | |
|<-------------+ | |
| | | |
| CK, IK, RES | | |
+------------->| | |
+--+--------------+----------------------------+---------+ |
| The Peer now has everything to respond. If it wants | |
| to participate in the FS extension, it will then | |
| generate its key pair, calculate a shared key based on | |
| its key pair and the Server's public key. Finally, it | |
| proceeds to derive all EAP-AKA' key values and | |
| constructs a full response. | |
+--+--------------+----------------------------+---------+ |
| | | |
| | EAP-Resp/AKA'-Challenge | |
| | AT_RES, AT_PUB_ECDHE, | |
| | AT_MAC | |
| +--------------------------->| |
| +-------+----------------------------+----------------+--+
| | The Server now has all the necessary values. It |
| | generates the ECDHE shared secret and checks the RES |
| | and MAC values received in AT_RES and AT_MAC, |
| | respectively. Success requires both to be found |
| | correct. Note that when this document is used, |
| | the keys generated from EAP-AKA' are based on CK, IK, |
| | and the ECDHE value. Even if there was an attacker |
| | who held the long-term key, only an active attacker |
| | could have determined the generated session keys; in |
| | basic EAP-AKA' the generated keys are only based on CK |
| | and IK. |
| +-------+----------------------------+----------------+--+
| | | |
| | EAP-Success | |
| |<---------------------------+ |
| | | |
Figure 2: EAP-AKA' FS Authentication Process
図2：EAP-AKA 'FS認証プロセス
The AT_PUB_ECDHE attribute carries an ECDHE value.
AT_PUB_ECDHE属性にはECDHE値があります。
The format of the AT_PUB_ECDHE attribute is shown below.
AT_PUB_ECDHE属性の形式を以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_PUB_ECDHE | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows:
フィールドは次のとおりです。
AT_PUB_ECDHE:
at_pub_ecdhe：
This is set to 152.
これは152に設定されています。
Length:
長さ：
This is the length of the attribute, set as other attributes in EAP-AKA [RFC4187]. The length is expressed in multiples of 4 bytes. The length includes the attribute type field, the Length field itself, and the Value field (along with any padding).
これは属性の長さであり、EAP-AKA [RFC4187]の他の属性として設定されています。長さは4バイトの倍数で表されます。長さには、属性タイプフィールド、長さフィールド自体、値フィールド（任意のパディングとともに）が含まれます。
Value:
値：
This value is the sender's ECDHE public key. The value depends on the AT_KDF_FS attribute and is calculated as follows:
この値は、送信者のECDHE公開キーです。値はAT_KDF_FS属性によって異なり、次のように計算されます。
* For X25519, the length of this value is 32 bytes, encoded as specified in Section 5 of [RFC7748].
* X25519の場合、この値の長さは32バイトで、[RFC7748]のセクション5で指定されているようにエンコードされています。
* For P-256, the length of this value is 33 bytes, encoded using the compressed form specified in Section 2.3.3 of [SEC1].
* P-256の場合、この値の長さは33バイトで、[SEC1]のセクション2.3.3で指定された圧縮形式を使用してエンコードされます。
Because the length of the attribute must be a multiple of 4 bytes, the sender pads the Value field with zero bytes when necessary. To retain the security of the keys, the sender SHALL generate a fresh value for each run of the protocol.
属性の長さは4バイトの倍数である必要があるため、送信者は必要に応じてゼロバイトの値フィールドをパッドにパッドします。キーのセキュリティを保持するには、送信者はプロトコルの実行ごとに新鮮な値を生成するものとします。
The AT_KDF_FS attribute indicates the used or desired FS key generation function, if the FS extension is used. It will also indicate the used or desired ECDHE group. A new attribute is needed to carry this information, as AT_KDF carries the basic KDF value that is still used together with the FS KDF value. The basic KDF value is also used by those EAP Peers that cannot or do not want to use this extension.
AT_KDF_FS属性は、FS拡張機能を使用する場合、使用されているFSキー生成関数を示します。また、使用または目的のECDHEグループを示します。AT_KDFには、FS KDF値と一緒に使用されている基本的なKDF値が含まれているため、この情報を携帯するために新しい属性が必要です。基本的なKDF値は、この拡張機能を使用できない、または使用したくないEAPピアによっても使用されます。
This document only specifies the behavior relating to the following combinations of basic KDF values and FS KDF values:
このドキュメントは、基本的なKDF値とFS KDF値の次の組み合わせに関連する動作のみを指定します。
* the basic KDF value in AT_KDF is 1, as specified in [RFC5448] and [RFC9048] and
* [RFC5448]および[RFC9048]で指定されているように、AT_KDFの基本的なKDF値は1です。
* the FS KDF values in AT_KDF_FS are 1 or 2, as specified below and in Section 6.3.
* AT_KDF_FSのFS KDF値は、以下とセクション6.3で指定されているように、1または2です。
Any future specifications that add either new basic KDFs or new FS KDF values need to specify how they are treated and what combinations are allowed. This requirement is an update to how [RFC5448] and [RFC9048] may be extended in the future.
新しい基本的なKDFまたは新しいFS KDF値を追加する将来の仕様は、それらがどのように扱われ、どの組み合わせが許可されているかを指定する必要があります。この要件は、[RFC5448]と[RFC9048]が将来拡張される方法の更新です。
The format of the AT_KDF_FS attribute is shown below.
AT_KDF_FS属性の形式を以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_KDF_FS | Length | FS Key Derivation Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows:
フィールドは次のとおりです。
AT_KDF_FS:
at_kdf_fs：
This is set to 153.
これは153に設定されています。
Length:
長さ：
This is the length of the attribute; it MUST be set to 1.
これは属性の長さです。1に設定する必要があります。
FS Key Derivation Function:
FSキー派生関数：
This is an enumerated value representing the FS Key Derivation Function (KDF) that the Server (or Peer) wishes to use. See Section 6.3 for the functions specified in this document. Note: this field has a different name space than the similar field in the AT_KDF attribute KDF defined in [RFC9048].
これは、サーバー（またはピア）が使用したいFSキー派生関数（KDF）を表す列挙値です。このドキュメントで指定された関数については、セクション6.3を参照してください。注：このフィールドには、[RFC9048]で定義されているAT_KDF属性KDFの同様のフィールドとは異なる名前空間があります。
Servers MUST send one or more AT_KDF_FS attributes in the EAP-Request/AKA'-Challenge message. These attributes represent the desired functions ordered by preference, with the most preferred function being the first attribute. The most preferred function is the only one that the Server includes a public key value for, however. So, for a set of AT_KDF_FS attributes, there is always only one AT_PUB_ECDHE attribute.
サーバーは、EAP-Request/AKA'-Challengeメッセージに1つ以上のAT_KDF_FS属性を送信する必要があります。これらの属性は、好みによって順序付けられた目的の関数を表し、最も好ましい関数は最初の属性です。ただし、最も好ましい関数は、サーバーが公開キー値を含む唯一の機能です。したがって、AT_KDF_FS属性のセットの場合、AT_PUB_ECDHE属性は常に1つしかありません。
Upon receiving a set of these attributes:
これらの属性のセットを受信すると：
* If the Peer supports and is willing to use the FS KDF indicated by the first AT_KDF_FS attribute, and is willing and able to use the extension defined in this document, the function will be used without any further negotiation.
* ピアが最初のAT_KDF_FS属性で示されているFS KDFをサポートし、喜んで使用し、このドキュメントで定義されている拡張機能を喜んで使用できる場合、機能はさらなる交渉なしで使用されます。
* If the Peer does not support this function or is unwilling to use it, it responds to the Server with an indication that a different function is needed. Similarly, with the negotiation process defined in [RFC9048] for AT_KDF, the Peer sends an EAP-Response/ AKA'-Challenge message that contains only one attribute, AT_KDF_FS, with the value set to the desired alternative function from among the ones suggested by the Server earlier. If there is no suitable alternative, the Peer has a choice of either falling back to EAP-AKA' or behaving as if the AUTN had been incorrect and failing authentication (see Figure 3 of [RFC4187]). The Peer MUST fail the authentication if there are any duplicate values within the list of AT_KDF_FS attributes (except where the duplication is due to a request to change the KDF; see below for further information).
* ピアがこの関数をサポートしていないか、それを使用したくない場合、異なる関数が必要であることを示してサーバーに応答します。同様に、AT_KDFの[RFC9048]で定義されているネゴシエーションプロセスを使用すると、ピアは、以前のサーバーが提案したサーバーの中から目的の代替関数に設定された1つの属性のみを含むEAP Response/ AKA'-Challengeメッセージを送信します。適切な代替手段がない場合、ピアはEAP-AKAに戻るか、AUTNが正しくないかのように動作し、認証に障害があるかの選択を選択します（[RFC4187]の図3を参照）。AT_KDF_FS属性のリスト内に重複した値がある場合、ピアは認証に失敗する必要があります（複製がKDFを変更するリクエストが原因である場合を除きます。詳細については以下を参照してください）。
* If the Peer does not recognize the extension defined in this document or is unwilling to use it, it ignores the AT_KDF_FS attribute.
* ピアがこのドキュメントで定義されている拡張機能を認識していない場合、または使用したくない場合、AT_KDF_FS属性を無視します。
Upon receiving an EAP-Response/AKA'-Challenge message with an AT_KDF_FS attribute from the Peer, the Server checks that the suggested AT_KDF_FS value was one of the alternatives in its offer. The first AT_KDF_FS value in the message from the Server is not a valid alternative. If the Peer has replied with the first AT_KDF_FS value, the Server behaves as if the AT_MAC of the response had been incorrect and fails the authentication. For an overview of the failed authentication process in the Server side, see Section 3 and Figure 2 in [RFC4187]. Otherwise, the Server re-sends the EAP-Response/AKA'-Challenge message, but adds the selected alternative to the beginning of the list of AT_KDF_FS attributes and retains the entire list following it. Note that this means that the selected alternative appears twice in the set of AT_KDF values. Responding to the Peer's request to change the FS KDF is the only valid situation where such duplication may occur.
ピアからAT_KDF_FS属性を使用してEAP-Response/AKA'-Challengeメッセージを受信すると、サーバーは、提案されたAT_KDF_FS値がオファーの代替案の1つであることをチェックします。サーバーからのメッセージ内の最初のAT_KDF_FS値は、有効な代替手段ではありません。ピアが最初のAT_KDF_FS値で返信した場合、サーバーは応答のAT_MACが正しくなく、認証に失敗したかのように動作します。サーバー側の認証プロセスの失敗の概要については、[RFC4187]のセクション3と図2を参照してください。それ以外の場合、サーバーはEAP-Response/AKA'-Challengeメッセージを再送信しますが、AT_KDF_FS属性のリストの先頭に選択した代替案を追加し、それに続いてリスト全体を保持します。これは、選択された代替がAT_KDF値のセットに2回表示されることを意味することに注意してください。FS KDFを変更するためのピアのリクエストに対応することは、そのような重複が発生する可能性のある唯一の有効な状況です。
When the Peer receives the new EAP-Request/AKA'-Challenge message, it MUST check that the requested change, and only the requested change, occurred in the list of AT_KDF_FS attributes. If so, it continues. If not, it behaves as if AT_MAC were incorrect and fails the authentication. If the Peer receives multiple EAP-Request/AKA'- Challenge messages with differing AT_KDF_FS attributes without having requested negotiation, the Peer MUST behave as if AT_MAC were incorrect and fail the authentication.
ピアが新しいEAP-Request/Aka'-Challengeメッセージを受信すると、要求された変更と要求された変更のみがAT_KDF_FS属性のリストで発生したことを確認する必要があります。もしそうなら、それは続きます。そうでない場合、AT_MACが正しくなく、認証に失敗したかのように動作します。ピアが、交渉を要求せずに異なるAT_KDF_FS属性を持つ複数のEAP-Request/AKA'-チャレンジメッセージを受信した場合、ピアはAT_MACが正しくなく、認証に失敗したかのように振る舞う必要があります。
Two new FS KDF types are defined for "EAP-AKA' with ECDHE and X25519", represented by value 1, and "EAP-AKA' with ECDHE and P-256", represented by value 2. These values represent a particular choice of KDF and, at the same time, select an ECDHE group to be used.
2つの新しいFS KDFタイプは、値1で表される「eap-aka」とx25519を含む「eap-aka」、およびvalue 2で表される「ecdheとp-256を含む「eap-aka」に対して定義されています。これらの値は、KDFの特定の選択を表し、同時に使用するECDHEグループを選択します。
The FS KDF type value is only used in the AT_KDF_FS attribute. When the FS extension is used, the AT_KDF_FS attribute determines how to derive the MK_ECDHE key, K_re key, Master Session Key (MSK), and Extended Master Session Key (EMSK). The AT_KDF_FS attribute should not be confused with the different range of KDFs that can be represented in the AT_KDF attribute as defined in [RFC9048]. When the FS extension is used, the AT_KDF attribute only specifies how to derive the Master Key (MK), the K_encr key, and the K_aut key.
FS KDFタイプの値は、AT_KDF_FS属性でのみ使用されます。FS拡張機能を使用すると、AT_KDF_FS属性は、MK_ECDHEキー、K_REキー、マスターセッションキー（MSK）、および拡張マスターセッションキー（EMSK）を導出する方法を決定します。AT_KDF_FS属性は、[RFC9048]で定義されているAT_KDF属性で表現できるさまざまな範囲のKDFSと混同しないでください。FS拡張機能を使用する場合、AT_KDF属性は、マスターキー（MK）、K_ENCRキー、およびK_AUTキーを導出する方法のみを指定します。
Key derivation in this extension produces exactly the same keys for internal use within one authentication run as EAP-AKA' [RFC9048] does. For instance, the K_aut that is used in AT_MAC is still exactly as it was in EAP-AKA'. The only change to key derivation is in the re-authentication keys and keys exported out of the EAP method, MSK and EMSK. As a result, EAP-AKA' attributes such as AT_MAC continue to be usable even when this extension is in use.
この拡張機能のキー派生は、EAP-AKA [RFC9048]と同じように、1つの認証実行内で内部使用のためにまったく同じキーを生成します。たとえば、AT_MACで使用されるK_AUTは、EAP-AKA 'とまったく同じです。キー派生への唯一の変更は、EAPメソッド、MSKおよびEMSKからエクスポートされる再認証キーとキーにあります。その結果、AT_MACなどのEAP-AKAの属性は、この拡張機能が使用されている場合でも使用可能です。
When the FS KDF field in the AT_KDF_FS attribute is set to 1 or 2 and the KDF field in the AT_KDF attribute is set to 1, the MK and accompanying keys are derived as follows:
AT_KDF_FS属性のFS KDFフィールドが1または2に設定され、AT_KDF属性のKDFフィールドが1に設定されている場合、MKと付随するキーは次のように導出されます。
MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity)
K_encr = MK[0..127]
K_aut = MK[128..383]
K_re = MK_ECDHE[0..255]
MSK = MK_ECDHE[256..767]
EMSK = MK_ECDHE[768..1279]
An explanation of the notation used above is copied here:
上記で使用した表記の説明は、ここにコピーされています。
* [n..m] denotes the substring from bit n to m.
* [n..m]は、ビットnからmへのサブストリングを示します。
* PRF' is a new pseudorandom function specified in [RFC9048].
* PRF 'は、[RFC9048]で指定された新しい擬似ランダム機能です。
* K_encr is the encryption key (128 bits).
* K_ENCRは暗号化キー（128ビット）です。
* K_aut is the authentication key (256 bits).
* K_AUTは認証キー（256ビット）です。
* K_re is the re-authentication key (256 bits).
* K_REは再認可キー（256ビット）です。
* MSK is the Master Session Key (512 bits).
* MSKはマスターセッションキー（512ビット）です。
* EMSK is the Extended Master Session Key (512 bits).
* EMSKは、拡張マスターセッションキー（512ビット）です。
Note: MSK and EMSK are outputs from a successful EAP method run [RFC3748].
注：MSKとEMSKは、成功したEAPメソッドの実行からの出力です[RFC3748]。
The CK and IK are produced by the AKA algorithm. The IK' and CK' are derived as specified in [RFC9048] from the IK and CK.
CKとIKは、AKAアルゴリズムによって生成されます。IK 'およびCK'は、IKおよびCKから[RFC9048]で指定されているように導出されます。
The value "EAP-AKA'" is an ASCII string that is 8 characters long. It is used as is, without any trailing NUL characters. Similarly, "EAP-AKA' FS" is an ASCII string that is 11 characters long, also used as is.
値「eap-aka」は、8文字の長さのASCII文字列です。そのまま使用されていますが、nul文字を後期にすることはありません。同様に、「Eap-aka 'fs」は11文字の長さのASCII文字列であり、そのまま使用されます。
Requirements for how to securely generate, validate, and process the ephemeral public keys depend on the elliptic curve.
短命のパブリックキーを安全に生成、検証、および処理する方法の要件は、楕円曲線に依存します。
For P-256, the SHARED_SECRET is the shared secret computed as specified in Section 5.7.1.2 of [SP-800-56A]. Requirements are defined in Section 5 of [SP-800-56A], in particular, Sections 5.6.2.3.4, 5.6.3.1, and 5.6.3.3. At least partial public key validation MUST be done for the ephemeral public keys. The uncompressed y-coordinate can be computed as described in Section 2.3.4 of [SEC1].
P-256の場合、Shared_Secretは[SP-800-56A]のセクション5.7.1.2で指定されているように計算された共有秘密です。要件は、[SP-800-56A]のセクション5、特にセクション5.6.2.3.4、5.6.3.1、および5.6.3.3で定義されています。はかない公開鍵に対して、少なくとも部分的な公開鍵の検証を行う必要があります。圧縮されていないY座標は、[SEC1]のセクション2.3.4で説明されているように計算できます。
For X25519, the SHARED_SECRET is the shared secret computed as specified in Section 6.1 of [RFC7748]. Both the Peer and the Server MAY check for the zero-value shared secret as specified in Section 6.1 of [RFC7748].
X25519の場合、Shared_Secretは[RFC7748]のセクション6.1で指定されているように計算された共有秘密です。ピアとサーバーの両方が、[RFC7748]のセクション6.1で指定されているように、ゼロ値共有秘密をチェックすることができます。
Note: If performed inappropriately, the way that the shared secret is tested for zero can provide an ability for attackers to listen to CPU power usage side channels. Refer to [RFC7748] for a description of how to perform this check in a way that it does not become a problem.
注：不適切に実行された場合、共有シークレットがゼロでテストされる方法は、攻撃者がCPUの電力使用量サイドチャネルを聴く能力を提供することができます。このチェックを実行する方法の説明については、問題にならない方法で[RFC7748]を参照してください。
If validation of the other party's ephemeral public key or the shared secret fails, a party MUST behave as if the current EAP-AKA' process starts again from the beginning.
相手の一時的な公開鍵または共有秘密の鍵を検証する場合、当事者は、現在のEAP-AKAプロセスが最初から再び始まるかのように振る舞わなければなりません。
The rest of the computation proceeds as defined in Section 3.3 of [RFC9048].
残りの計算は、[RFC9048]のセクション3.3で定義されているように進行します。
The selection of suitable groups for the elliptic curve computation is necessary. The choice of a group is made at the same time as the decision to use a particular KDF in the AT_KDF_FS attribute.
楕円曲線計算に適したグループの選択が必要です。グループの選択は、AT_KDF_FS属性で特定のKDFを使用する決定と同時に行われます。
For "EAP-AKA' with ECDHE and X25519", the group is the Curve25519 group specified in [RFC7748]. The support for this group is REQUIRED.
ecdheとx25519を含む「eap-aka」の場合、グループは[rfc7748]で指定された曲線25519グループです。このグループのサポートが必要です。
For "EAP-AKA' with ECDHE and P-256", the group is the NIST P-256 group (SEC group secp256r1), specified in Section 3.2.1.3 of [SP-800-186] or alternatively, Section 2.4.2 of [SEC2]. The support for this group is REQUIRED.
「ECDHEおよびP-256を含む「EAP-AKA」」の場合、グループは[SP-800-186]のセクション3.2.1.3または[SEC2]のセクション2.4.2で指定されているNIST P-256グループ（SECグループSECP256R1）です。このグループのサポートが必要です。
The term "support" here means that the group MUST be implemented.
ここでの「サポート」という用語は、グループを実装する必要があることを意味します。
This section specifies the changes related to message processing when this extension is used in EAP-AKA'. It specifies when a message may be transmitted or accepted, which attributes are allowed in a message, which attributes are required in a message, and other message-specific details, where those details are different for this extension than the base EAP-AKA' or EAP-AKA protocol. Unless otherwise specified here, the rules from [RFC9048] or [RFC4187] apply.
このセクションでは、この拡張機能がEAP-AKAで使用される場合のメッセージ処理に関連する変更を指定します。メッセージが送信または受け入れられる場合があります。メッセージで属性が許可されます。メッセージに属性が必要です。この属性は、この拡張子の詳細がベースEAP-AKA 'またはEAP-AKAプロトコルとは異なる場合です。ここで特に指定されていない限り、[RFC9048]または[RFC4187]のルールが適用されます。
There are no changes for the EAP-Request/AKA'-Identity, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this message. The appearance of these attributes in a received message MUST be ignored.
AT_KDF_FSまたはAT_PUB_ECDHE属性をこのメッセージに追加しないでください。受信したメッセージ内のこれらの属性の外観は無視する必要があります。
There are no changes for the EAP-Response/AKA'-Identity, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this message. The appearance of these attributes in a received message MUST be ignored. The Peer identifier SHALL comply with the privacy-friendly requirements of [RFC9190]. An example of a compliant way of constructing a privacy-friendly Peer identifier is using a non-null SUCI [TS.33.501].
AT_KDF_FSまたはAT_PUB_ECDHE属性をこのメッセージに追加しないでください。受信したメッセージ内のこれらの属性の外観は無視する必要があります。ピア識別子は、[RFC9190]のプライバシーに優しい要件に準拠するものとします。プライバシーに優しいピア識別子を構築する準拠の方法の例は、非ヌルSUCI [Ts.33.501]を使用することです。
The Server sends the EAP-Request/AKA'-Challenge on full authentication as specified by [RFC4187] and [RFC9048]. The attributes AT_RAND, AT_AUTN, and AT_MAC MUST be included and checked on reception as specified in [RFC4187]. They are also necessary for backwards compatibility.
サーバーは、[RFC4187]および[RFC9048]で指定されているように、完全な認証でEAP-Request/Aka'-Challengeを送信します。[RFC4187]で指定されているように、AT_RAND、AT_AUTN、およびAT_MACを含めてレセプションで確認する必要があります。また、後方互換性にも必要です。
In the EAP-Request/AKA'-Challenge, there is no message-specific data covered by the MAC for the AT_MAC attribute. The AT_KDF_FS and AT_PUB_ECDHE attributes MUST be included. The AT_PUB_ECDHE attribute carries the Server's public Diffie-Hellman key. If either AT_KDF_FS or AT_PUB_ECDHE is missing on reception, the Peer MUST treat it as if neither one was sent and assume that the extension defined in this document is not in use.
EAP-Request/Aka'-Challengeでは、AT_MAC属性のMACがカバーするメッセージ固有のデータはありません。AT_KDF_FSおよびAT_PUB_ECDHE属性を含める必要があります。AT_PUB_ECDHE属性には、サーバーのpublic diffie-hellmanキーが搭載されています。AT_KDF_FSまたはAT_PUB_ECDHEのいずれかが受信で欠落している場合、ピアはそれを送信しないかのように扱う必要があり、このドキュメントで定義されている拡張機能が使用されていないと仮定します。
The AT_RESULT_IND, AT_CHECKCODE, AT_IV, AT_ENCR_DATA, AT_PADDING, AT_NEXT_PSEUDONYM, AT_NEXT_REAUTH_ID, and other attributes may be included as specified in Section 9.3 of [RFC4187].
AT_RESULT_IND、AT_CHECKCODE、AT_IV、AT_ENCR_DATA、AT_PADDING、AT_NEXT_PSEUDNYNAMNY、AT_NEXT_REAUTH_ID、およびその他の属性は、[RFC4187]のセクション9.3で指定されているように含まれている場合があります。
When processing this message, the Peer MUST process AT_RAND, AT_AUTN, AT_KDF_FS, and AT_PUB_ECDHE before processing other attributes. The Peer derives keys and verifies AT_MAC only if these attributes are verified to be valid. If the Peer is unable or unwilling to perform the extension specified in this document, it proceeds as defined in [RFC9048]. Finally, if there is an error, see Section 6.3.1 of [RFC4187].
このメッセージを処理するとき、ピアは他の属性を処理する前に、AT_RAND、AT_AUTN、AT_KDF_FS、およびAT_PUB_ECDHEを処理する必要があります。ピアはキーを導き出し、これらの属性が有効であると確認された場合にのみAT_MACを検証します。ピアがこのドキュメントで指定された拡張機能を実行できない、または実行したくない場合、[RFC9048]で定義されているように進行します。最後に、エラーがある場合は、[RFC4187]のセクション6.3.1を参照してください。
The Peer sends an EAP-Response/AKA'-Challenge in response to a valid EAP-Request/AKA'-Challenge message, as specified by [RFC4187] and [RFC9048]. If the Peer supports and is willing to perform the extension specified in this protocol, and the Server had made a valid request involving the attributes specified in Section 6.5.3, the Peer responds per the rules specified below. Otherwise, the Peer responds as specified in [RFC4187] and [RFC9048] and ignores the attributes related to this extension. If the Peer has not received attributes related to this extension from the Server, and has a policy that requires it to always use this extension, it behaves as if the AUTN were incorrect and fails the authentication.
ピアは、[RFC4187]および[RFC9048]で指定されているように、有効なEAP-Request/AKA'-Challengeメッセージに応じて、EAP応答/Aka'-Challengeを送信します。ピアがこのプロトコルで指定された拡張機能をサポートし、喜んで実行し、サーバーがセクション6.5.3で指定された属性を含む有効な要求を行った場合、ピアは以下に指定されたルールに従って応答します。それ以外の場合、ピアは[RFC4187]および[RFC9048]で指定されているように応答し、この拡張機能に関連する属性を無視します。ピアがサーバーからこの拡張機能に関連する属性を受信しておらず、常にこの拡張機能を使用する必要があるポリシーがある場合、Autnが正しくなく、認証に失敗するかのように動作します。
The AT_MAC attribute MUST be included and checked as specified in [RFC9048]. In the EAP-Response/AKA'-Challenge, there is no message-specific data covered by the MAC. The AT_PUB_ECDHE attribute MUST be included and carries the Peer's public Diffie-Hellman key.
AT_MAC属性を含めて[RFC9048]で指定されているようにチェックする必要があります。EAP-Response/Aka'-Challengeでは、MACでカバーされているメッセージ固有のデータはありません。AT_PUB_ECDHE属性を含める必要があり、ピアのパブリックディフェルマンキーを搭載する必要があります。
The AT_RES attribute MUST be included and checked as specified in [RFC4187]. When processing this message, the Server MUST process AT_RES before processing other attributes. The Server derives keys and verifies AT_MAC only when this attribute is verified to be valid.
AT_RES属性を含めて[RFC4187]で指定されているようにチェックする必要があります。このメッセージを処理する場合、サーバーは他の属性を処理する前にAT_RESを処理する必要があります。サーバーは、この属性が有効であると確認された場合にのみ、キーを導出し、AT_MACを検証します。
If the Server has proposed the use of the extension specified in this protocol, but the Peer ignores and continues the basic EAP-AKA' authentication, the Server makes a policy decision of whether this is allowed. If this is allowed, it continues the EAP-AKA' authentication to completion. If it is not allowed, the Server MUST behave as if authentication failed.
サーバーがこのプロトコルで指定された拡張機能の使用を提案しているが、ピアが基本的なEAP-AKA認証を無視して継続する場合、サーバーはこれが許可されるかどうかをポリシー決定します。これが許可されている場合、完了するためのEAP-AKA認証を継続します。許可されていない場合、サーバーは認証が失敗したかのように動作する必要があります。
The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA, and other attributes may be included as specified in Section 9.4 of [RFC4187].
AT_CHECKCODE、AT_RESULT_IND、AT_IV、AT_ENCR_DATA、およびその他の属性は、[RFC4187]のセクション9.4で指定されているように含まれている場合があります。
There are no changes for the EAP-Request/AKA'-Reauthentication, but note that the re-authentication process uses the keys generated in the original EAP-AKA' authentication, which employs key material from the Diffie-Hellman procedure if the extension specified in this document is in use.
EAP-Request/Aka'-Reauthenticationに変更はありませんが、再認証プロセスは、このドキュメントで指定された拡張機能が使用されている場合、Diffie-Hellman手順からキーマテリアルを使用する元のEAP-AKA認証で生成されたキーを使用することに注意してください。
There are no changes for the EAP-Response/AKA'-Reauthentication, but as discussed in Section 6.5.5, re-authentication is based on the key material generated by EAP-AKA' and the extension defined in this document.
EAP応答/AKA'-ReAuthenticationに変更はありませんが、セクション6.5.5で説明したように、再認可はEAP-AKA 'によって生成された重要な材料と、このドキュメントで定義されている拡張に基づいています。
There are no changes for the EAP-Response/AKA'-Synchronization-Failure, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this message. The appearance of these attributes in a received message MUST be ignored.
AT_KDF_FSまたはAT_PUB_ECDHE属性をこのメッセージに追加しないでください。受信したメッセージ内のこれらの属性の外観は無視する必要があります。
There are no changes for the EAP-Response/AKA'-Authentication-Reject, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this message. The appearance of these attributes in a received message MUST be ignored.
AT_KDF_FSまたはAT_PUB_ECDHE属性をこのメッセージに追加しないでください。受信したメッセージ内のこれらの属性の外観は無視する必要があります。
There are no changes for the EAP-Response/AKA'-Client-Error, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this message. The appearance of these attributes in a received message MUST be ignored.
AT_KDF_FSまたはAT_PUB_ECDHE属性をこのメッセージに追加しないでください。受信したメッセージ内のこれらの属性の外観は無視する必要があります。
There are no changes for the EAP-Request/AKA'-Notification.
EAP-Request/Aka'-Notificationに変更はありません。
There are no changes for the EAP-Response/AKA'-Notification.
EAP応答/AKA'-Notificationに変更はありません。
This section deals only with changes to security considerations for EAP-AKA' or new information that has been gathered since the publication of [RFC9048].
このセクションでは、EAP-AKAのセキュリティ上の考慮事項の変更または[RFC9048]の公開以来収集された新しい情報の変更のみを扱います。
As discussed in Section 1, FS is an important countermeasure against adversaries who gain access to long-term keys. The long-term keys can be best protected with good processes, e.g., restricting access to the key material within a factory or among personnel, etc. Even so, not all attacks can be entirely ruled out. For instance, well-resourced adversaries may be able to coerce insiders to collaborate, despite any technical protection measures. The zero trust principles suggest that we assume that breaches are inevitable or have potentially already occurred and that we need to minimize the impact of these breaches (see [NSA-ZT] and [NIST-ZT]). One type of breach is key compromise or key exfiltration.
セクション1で説明したように、FSは長期キーにアクセスできる敵に対する重要な対策です。長期的なキーは、工場内や人員の間でキーマテリアルへのアクセスを制限することなど、優れたプロセスで最適に保護できます。それでも、すべての攻撃を完全に除外できるわけではありません。たとえば、技術的な保護措置にもかかわらず、リソースされた敵がインサイダーを強制して協力することができるかもしれません。ゼロの信頼の原則は、違反が避けられないか、潜在的にすでに発生していると仮定し、これらの違反の影響を最小限に抑える必要があると仮定していることを示唆しています（[NSA-ZT]および[Nist-ZT]を参照）。1つのタイプの違反は、重要な妥協または重要な除去です。
If a mechanism without ephemeral key exchange (such as 5G-AKA or EAP-AKA') is used, the effects of key compromise are devastating. There are serious consequences to not properly providing FS for the key establishment, for the control plane and the user plane, and for both directions:
はかないキー交換のないメカニズム（5G-AKAやEAP-AKAなど）が使用される場合、キー妥協の効果は壊滅的です。主要な施設、コントロールプレーンとユーザープレーン、および両方の方向にFSを適切に提供しないことには深刻な結果があります。
1. An attacker can decrypt 5G communication that they previously recorded.
1. 攻撃者は、以前に記録した5G通信を復号化できます。
2. A passive attacker can eavesdrop (decrypt) all future 5G communication.
2. 受動的な攻撃者は、将来のすべての5G通信を盗用（decrypt）することができます。
3. An active attacker can impersonate the User Equipment (UE) or the network and inject messages in an ongoing 5G connection between the real UE and the real network.
3. アクティブな攻撃者は、ユーザー機器（UE）またはネットワークになりすまして、実際のUEと実際のネットワークの間の継続的な5G接続にメッセージを注入できます。
At the time of writing, best practice security is to mandate FS (as is done in Wi-Fi Protected Access 3 (WPA3), EAP-TLS 1.3, EAP-TTLS 1.3, Internet Key Exchange Protocol Version 2 (IKEv2), Secure Shell (SSH), QUIC, WireGuard, Signal, etc.). In deployments, it is recommended that EAP-AKA methods without FS be phased out in the long term.
執筆時点で、ベストプラクティスのセキュリティはFSを義務付けることです（Wi-Fi保護アクセス3（WPA3）、EAP-TLS 1.3、EAP-TTLS 1.3、Internet Key Exchange Protocolバージョン2（IKEV2）、セキュアシェル（SSH）、QUIC、ワイヤルガード、シグナルなど）。展開では、FSのないEAP-AKAメソッドを長期的に段階的に廃止することをお勧めします。
The FS extension provides assistance against passive attacks from attackers that have compromised the key material on USIM cards. Passive attacks are attractive for attackers performing large-scale pervasive monitoring as they require far fewer resources and are much harder to detect. The extension also provides protection against active attacks as the attacker is forced to be on-path during the AKA run and subsequent communication between the parties. Without FS, an active attacker that has compromised the long-term key can inject messages in a connection between the real Peer and the real Server without being on-path. This extension is most useful when implemented in a context where the MSK or EMSK are used in protocols not providing FS. For instance, if used with IKEv2 [RFC7296], the session keys produced by IKEv2 will in any case have this property, so the improvements from the use of EAP-AKA' FS are not that useful. However, typical link-layer usage of EAP does not involve running another key exchange with forward secrecy. Therefore, using EAP to authenticate access to a network is one situation where the extension defined in this document can be helpful.
FS拡張は、USIMカードの重要な資料を損なった攻撃者からの受動的攻撃に対する支援を提供します。受動的な攻撃は、大規模なリソースがはるかに少なく、検出がはるかに困難であるため、大規模な広範なモニタリングを実行する攻撃者にとって魅力的です。また、攻撃者は、AKAランニングおよびその後の当事者間のコミュニケーション中に攻撃者がパスになることを余儀なくされるため、積極的な攻撃に対する保護も提供します。FSがなければ、長期キーを侵害したアクティブな攻撃者は、現実のピアとリアルサーバーの間の接続にメッセージを挿入できます。この拡張機能は、MSKまたはEMSKがFSを提供しないプロトコルで使用されるコンテキストで実装される場合に最も便利です。たとえば、IKEV2 [RFC7296]で使用すると、IKEV2によって生成されたセッションキーはいずれにしてもこのプロパティを持っているため、EAP-AKA 'FSの使用による改善はそれほど有用ではありません。ただし、EAPの典型的なリンク層の使用には、フォワードの秘密を備えた別の重要な交換を実行することは含まれません。したがって、EAPを使用してネットワークへのアクセスを認証することは、このドキュメントで定義されている拡張機能が役立つ状況の1つです。
The FS extension generates key material using the ECDHE exchange in order to gain the FS property. This means that once an EAP-AKA' authentication run ends, the session that it was used to protect is closed, and the corresponding keys are destroyed. Even someone who has recorded all of the data from the authentication run and session and gets access to all of the AKA long-term keys cannot reconstruct the keys used to protect the session or any previous session, without doing a brute-force search of the session key space.
FS拡張機能は、FSプロパティを獲得するためにECDHE Exchangeを使用して重要な材料を生成します。これは、EAP-AKA '認証が終了すると、保護するために使用されたセッションが閉じられ、対応するキーが破壊されることを意味します。認証実行とセッションのすべてのデータを記録し、AKAの長期キーにアクセスできる人でさえ、セッションキースペースをブルートフォース検索することなく、セッションまたは以前のセッションの保護に使用されるキーを再構築することはできません。
Even if a compromise of the long-term keys has occurred, FS is still provided for all future sessions, as long as the attacker does not become an active attacker.
攻撃者がアクティブな攻撃者にならない限り、長期キーの妥協が発生したとしても、FSはまだすべての将来のセッションに提供されます。
The extension does not provide protection against active attackers that mount an on-path attack on future EAP-AKA' runs and have access to the long-term key. They will be able to eavesdrop on the traffic protected by the resulting session key(s). Still, past sessions where FS was in use remain protected.
この拡張機能は、将来のEAP-AKA 'の実行にパス上の攻撃を行い、長期キーにアクセスできるアクティブな攻撃者に対する保護を提供しません。彼らは、結果のセッションキーによって保護されているトラフィックを盗聴することができます。それでも、FSが使用していた過去のセッションは保護されたままです。
Using EAP-AKA' FS once provides FS. FS limits the effect of key leakage in one direction (compromise of a key at time T2 does not compromise some key at time T1 where T1 < T2). Protection in the other direction (compromise at time T1 does not compromise keys at time T2) can be achieved by rerunning ECDHE frequently. If a long-term authentication key has been compromised, rerunning EAP-AKA' FS gives protection against passive attackers. Using the terms in [RFC7624], FS without rerunning ECDHE does not stop an attacker from doing static key exfiltration. Frequently rerunning EC(DHE) forces an attacker to do dynamic key exfiltration (or content exfiltration).
EAP-AKA 'FSを使用すると、FSが提供されます。FSは、一方向にキーリークの影響を制限します（時間T2のキーの妥協は、T1 <T2では、T1 <T2でキーを損なうことはありません）。他の方向の保護（時間T1での妥協は、時間T2のキーを妥協しません）は、頻繁にecdheを再実行することで達成できます。長期的な認証キーが侵害されている場合、EAP-AKA FSを再実行すると、受動的な攻撃者からの保護が得られます。[RFC7624]の用語を使用して、ecdheを再実行せずにFSは、攻撃者が静的なキー除去を行うのを止めません。頻繁にEC（DHE）を再実行すると、攻撃者に動的なキー剥離（またはコンテンツ除去）を行うように強制します。
Achieving FS requires that, when a connection is closed, each endpoint MUST destroy not only the ephemeral keys used by the connection but also any information that could be used to recompute those keys.
FSを達成するには、接続が閉じられている場合、各エンドポイントが接続で使用されるはかないキーだけでなく、それらのキーを再計算するために使用できる情報も破壊する必要があります。
Similarly, other parts of the system matter. For instance, when the keys generated by EAP are transported to a pass-through authenticator, such transport must also provide forward secure encryption with respect to the long-term keys used to establish its security. Otherwise, an adversary may attack the transport connection used to carry keys from EAP, and use this method to gain access to current and past keys from EAP, which, in turn, would lead to the compromise of anything protected by those EAP keys.
同様に、システムの他の部分は重要です。たとえば、EAPによって生成されたキーがパススルー認証器に輸送される場合、そのような輸送は、セキュリティを確立するために使用される長期キーに関して、前方の安全な暗号化を提供する必要があります。それ以外の場合、敵はEAPからキーを運ぶために使用される輸送接続を攻撃し、この方法を使用してEAPから過去および過去のキーへのアクセスを得ることができます。
Of course, these considerations apply to any EAP method, not only this one.
もちろん、これらの考慮事項は、これだけでなく、あらゆるEAP方法にも当てはまります。
The following security properties of EAP-AKA' are impacted through this extension:
EAP-AKAの次のセキュリティプロパティは、この拡張機能を通じて影響を受けます。
Protected ciphersuite negotiation:
保護されたciphersuite交渉：
EAP-AKA' has a negotiation mechanism for selecting the KDFs, and this mechanism has been extended by the extension specified in this document. The resulting mechanism continues to be secure against bidding-down attacks.
EAP-AKA 'には、KDFSを選択するための交渉メカニズムがあり、このメカニズムは、このドキュメントで指定された拡張機能によって拡張されています。結果として生じるメカニズムは、入札ダウン攻撃に対して安全であり続けます。
There are two specific needs in the negotiation mechanism:
交渉メカニズムには2つの特定のニーズがあります。
Negotiating KDFs within the extension:
拡張機能内でKDFを交渉する：
The negotiation mechanism allows changing the offered KDF, but the change is visible in the final EAP-Request/AKA'-Challenge message that the Server sends to the Peer. This message is authenticated via the AT_MAC attribute, and carries both the chosen alternative and the initially offered list. The Peer refuses to accept a change it did not initiate. As a result, both parties are aware that a change is being made and what the original offer was.
交渉メカニズムにより、提供されるKDFを変更できますが、サーバーがピアに送信する最終的なEAP-Request/AKA'-Challengeメッセージで変更が表示されます。このメッセージは、AT_MAC属性を介して認証されており、選択した代替案と最初に提供されたリストの両方を搭載しています。ピアは、開始しなかった変更を受け入れることを拒否します。その結果、両当事者は、変更が加えられていることと、元の申し出が何であるかを認識しています。
Negotiating the use of this extension:
この拡張機能の使用を交渉する：
This extension is offered by the Server through presenting the AT_KDF_FS and AT_PUB_ECDHE attributes in the EAP-Request/AKA'- Challenge message. These attributes are protected by AT_MAC, so attempts to change or omit them by an adversary will be detected.
この拡張機能は、EAP-Request/AKA'- ChallengeメッセージにAT_KDF_FSおよびAT_PUB_ECDHE属性を提示することにより、サーバーによって提供されます。これらの属性はAT_MACによって保護されているため、敵によって変更または省略しようとする試みが検出されます。
These attempts will be detected, except of course, if the adversary holds the long-term key and is willing to engage in an active attack. For instance, such an attack can forge the negotiation process so that no FS will be provided. However, as noted above, an attacker with these capabilities will, in any case, be able to impersonate any party in the protocol and perform on-path attacks. That is not a situation that can be improved by a technical solution. However, as discussed in the Introduction, even an attacker with access to the long-term keys is required to be on-path on each AKA run and subsequent communication, which makes mass surveillance more laborious.
もちろん、敵が長期的な鍵を保持し、積極的な攻撃に従事することをいとわない場合を除き、これらの試みは検出されます。たとえば、このような攻撃は、FSが提供されないように交渉プロセスを築くことができます。ただし、上記のように、これらの機能を備えた攻撃者は、いずれにせよ、プロトコル内のあらゆる当事者になりすましてパス上の攻撃を実行することができます。これは、技術的なソリューションによって改善できる状況ではありません。ただし、紹介で説明したように、長期キーにアクセスできる攻撃者でさえ、それぞれの実行とその後のコミュニケーションでパスをオンにする必要があります。これにより、大量監視がより面倒になります。
The security properties of the extension also depend on a policy choice. As discussed in Section 6.5.4, both the Peer and the Server make a policy decision of what to do when it was willing to perform the extension specified in this protocol, but the other side does not wish to use the extension. Allowing this has the benefit of allowing backwards compatibility to equipment that did not yet support the extension. When the extension is not supported or negotiated by the parties, no FS can obviously be provided.
拡張機能のセキュリティプロパティは、ポリシーの選択にも依存します。セクション6.5.4で説明したように、ピアとサーバーの両方が、このプロトコルで指定された拡張機能を実行する意思があるときに何をすべきかをポリシー決定しますが、反対側は拡張機能を使用したくありません。これを許可するには、まだ拡張機能をサポートしていない機器との逆方向の互換性を許可する利点があります。拡張機能が当事者によってサポートまたは交渉されていない場合、FSは明らかに提供できません。
If turning off the extension specified in this protocol is not allowed by policy, the use of legacy equipment that does not support this protocol is no longer possible. This may be appropriate when, for instance, support for the extension is sufficiently widespread or required in a particular version of a mobile network.
このプロトコルで指定された拡張機能がポリシーで許可されていない場合、このプロトコルをサポートしないレガシー機器の使用は不可能です。これは、たとえば、拡張機能のサポートがモバイルネットワークの特定のバージョンで十分に広くまたは必要とされる場合に適切かもしれません。
Key derivation:
キー派生：
This extension provides FS. As described in several places in this specification, this can be roughly summarized as follows: an attacker with access to long-term keys is unable to obtain session keys of ended past sessions, assuming these sessions deleted all relevant session key material. This extension does not change the properties related to re-authentication. No new Diffie-Hellman run is performed during the re-authentication allowed by EAP-AKA'. However, if this extension was in use when the original EAP-AKA' authentication was performed, the keys used for re-authentication (K_re) are based on the Diffie-Hellman keys; hence, they continue to be equally safe against exposure of the long-term key as the original authentication.
この拡張機能はFSを提供します。この仕様のいくつかの場所で説明されているように、これは次のように大まかに要約できます。長期キーにアクセスできる攻撃者は、これらのセッションがすべての関連セッションキー資料を削除したと仮定して、終了した過去のセッションのセッションキーを取得できません。この拡張機能は、再認証に関連するプロパティを変更しません。EAP-AKAが許可された再認証中に、新しいDiffie-Hellmanの実行は実行されません。ただし、元のEAP-AKA認証が実行されたときにこの拡張機能が使用されている場合、再認証に使用されるキー（k_re）はdiffie-hellmanキーに基づいています。したがって、彼らは元の認証として長期キーの露出に対して等しく安全である。
It is worthwhile to discuss Denial-of-Service (DoS) attacks and their impact on this protocol. The calculations involved in public key cryptography require computing power, which could be used in an attack to overpower either the Peer or the Server. While some forms of DoS attacks are always possible, the following factors help mitigate the concerns relating to public key cryptography and EAP-AKA' FS.
サービス拒否（DOS）攻撃とこのプロトコルへの影響について議論することは価値があります。公開キーの暗号化に関与する計算には、ピアまたはサーバーのいずれかを圧倒するために攻撃で使用できます。いくつかの形式のDOS攻撃は常に可能ですが、次の要因は、公開キーの暗号化とEAP-AKA FSに関連する懸念を軽減するのに役立ちます。
* In a 5G context, other parts of the connection setup involve public key cryptography, so while performing additional operations in EAP-AKA' is an additional concern, it does not change the overall situation. As a result, the relevant system components need to be dimensioned appropriately, and detection and management mechanisms to reduce the effect of attacks need to be in place.
* 5Gコンテキストでは、接続セットアップの他の部分には公開キーの暗号が含まれるため、EAP-AKAで追加の操作を実行することは追加の懸念ですが、全体的な状況は変わりません。その結果、関連するシステムコンポーネントを適切に寸法化する必要があり、攻撃の影響を減らすための検出および管理メカニズムを導入する必要があります。
* This specification is constructed so that it is possible to have a separation between the USIM and Peer on the client side and between the Server and AD on the network side. This ensures that the most sensitive (or legacy) system components cannot be the target of the attack. For instance, EAP-AKA' and public key cryptography both take place in the phone and not the low-power USIM card.
* この仕様は、クライアント側とネットワーク側のサーバーと広告の間でUSIMとピアを分離できるように構築されています。これにより、最も敏感な（またはレガシー）システムコンポーネントが攻撃のターゲットにならないことが保証されます。たとえば、EAP-AKA 'と公開キーの暗号はどちらも電話で行われ、低電力USIMカードではありません。
* EAP-AKA' has been designed so that the first actual message in the authentication process comes from the Server, and that this message will not be sent unless the user has been identified as an active subscriber of the operator in question. While the initial identity can be spoofed before authentication has succeeded, this reduces the efficiency of an attack.
* EAP-AKA 'は、認証プロセスの最初の実際のメッセージがサーバーから来るように設計されており、ユーザーが問題のオペレーターのアクティブなサブスクライバーとして識別されない限り、このメッセージは送信されません。認証が成功する前に初期のアイデンティティをスプーフィングすることができますが、これにより攻撃の効率が低下します。
* Finally, this memo specifies an order in which computations and checks must occur. For instance, when processing the EAP-Request/ AKA'-Challenge message, the AKA authentication must be checked and succeed before the Peer proceeds to calculating or processing the FS-related parameters (see Section 6.5.4). The same is true of an EAP-Response/AKA'-Challenge (see Section 6.5.4). This ensures that the parties need to show possession of the long-term key in some way, and only then will the FS calculations become active. This limits the DoS to specific, identified subscribers. While botnets and other forms of malicious parties could take advantage of actual subscribers and their key material, at least such attacks are:
* 最後に、このメモは、計算とチェックが発生する必要がある順序を指定します。たとえば、EAP-Request/ AKA'-Challengeメッセージを処理する場合、ピアがFS関連のパラメーターの計算または処理に進む前に、AKA認証をチェックして成功させる必要があります（セクション6.5.4を参照）。同じことは、EAP応答/別名チャレンジに当てはまります（セクション6.5.4を参照）。これにより、当事者は何らかの形で長期キーの所持を示す必要があり、その後、FS計算がアクティブになります。これにより、DOSが特定の識別されたサブスクライバーに制限されます。ボットネットやその他の悪意のあるパーティーは、実際の加入者とその主要な資料を利用することができますが、少なくともそのような攻撃は次のとおりです。
a. limited in terms of subscribers they control, and
a. 彼らが制御する加入者に関して限定されています
b. identifiable for the purposes of blocking the affected subscribers.
b. 影響を受ける加入者をブロックする目的で識別可能。
As specified in Section 6.5, the Peer identity sent in the Identity Response message needs to follow the privacy-friendly requirements in [RFC9190].
セクション6.5で指定されているように、ID応答メッセージで送信されたピアIDは、[RFC9190]のプライバシーに優しい要件に従う必要があります。
Unprotected data and metadata can reveal sensitive information and need to be selected with care. In particular, this applies to AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT. AT_KDF, AT_KDF_FS, and AT_PUB_ECDHE reveal the used cryptographic algorithms; if these depend on the Peer identity, they leak information about the Peer. AT_KDF_INPUT reveals the network name, although that is done on purpose to bind the authentication to a particular context.
保護されていないデータとメタデータは、機密情報を明らかにし、注意して選択する必要があります。特に、これはAT_KDF、AT_KDF_FS、AT_PUB_ECDHE、およびAT_KDF_INPUTに適用されます。AT_KDF、AT_KDF_FS、およびAT_PUB_ECDHEは、使用済みの暗号化アルゴリズムを明らかにします。これらがピアアイデンティティに依存する場合、ピアに関する情報を漏らします。AT_KDF_INPUTはネットワーク名を明らかにしますが、それは特定のコンテキストに認証をバインドするために意図的に行われています。
An attacker observing network traffic may use the above types of information for traffic flow analysis or to track an endpoint.
攻撃者の観察ネットワークトラフィックは、トラフィックフロー分析に上記の種類の情報を使用するか、エンドポイントを追跡する場合があります。
The keys K_encr and K_aut are calculated and used before the shared secret from the ephemeral key exchange is available.
キーK_ENCRとK_AUTは、一時的なキーエクスチェンジから共有された秘密が利用可能になる前に計算および使用されます。
K_encr and K_aut are used to encrypt and calculate a MAC in the EAP-Req/AKA'-Challenge message, especially the DH g^x ephemeral pub key. At that point, the Server does not yet have the corresponding g^y from the Peer and cannot compute the shared secret. K_aut is then used as the authentication key for the shared secret.
K_ENCRとK_AUTは、EAP-REQ/AKA'-CHALLENGEメッセージ、特にDH G^X Ephemeral PubキーのMACを暗号化および計算するために使用されます。その時点で、サーバーはまだピアから対応するg^yを持っておらず、共有された秘密を計算することはできません。K_AUTは、共有秘密の認証キーとして使用されます。
However, for K_encr, none of the encrypted data sent in the EAP-Req/ AKA'-Challenge message in the AT_ENCR attribute will be a forward secret. That data may include re-authentication pseudonyms, so an adversary compromising the long-term key would be able to link re-authentication protocol runs when pseudonyms are used, within a sequence of runs followed after a full EAP-AKA' authentication. No such linking would be possible across different full authentication runs. If the pseudonym linkage risk is not acceptable, one way to avoid the linkage is to always require full EAP-AKA' authentication.
ただし、K_ENCRの場合、AT_ENCR属性のEAP-REQ/ AKA'-CHALLENGEメッセージで送信された暗号化されたデータのいずれも、前向きな秘密ではありません。そのデータには再認証の仮名が含まれる可能性があるため、長期キーを損なう敵は、完全なEAP-AKA「認証の後に続く一連の実行内で、仮名が使用されるときに再認証プロトコルの実行）をリンクできます。異なる完全な認証の実行にわたって、そのようなリンクは不可能です。仮名リンケージリスクが受け入れられない場合、リンケージを回避する1つの方法は、常に完全なEAP-AKA認証を必要とすることです。
As of the publication of this document, it is unclear when or even if a quantum computer of sufficient size and power to exploit ECC will exist. Deployments that need to consider risks decades into the future should transition to Post-Quantum Cryptography (PQC) in the not-too-distant future. Other systems may employ PQC when the quantum threat is more imminent. Current PQC algorithms have limitations compared to ECC, and the data sizes could be problematic for some constrained systems. If a Cryptographically Relevant Quantum Computer (CRQC) is built, it could recover the SHARED_SECRET from the ECDHE public keys.
このドキュメントの公開の時点で、ECCを悪用するのに十分なサイズとパワーの量子コンピューターがいつ存在するか、または存在する場合でも不明です。何十年もリスクを考慮する必要がある展開は、それほど遠くない将来において、Quantum後の暗号（PQC）に移行する必要があります。他のシステムは、量子の脅威がより差し迫っている場合、PQCを採用する場合があります。現在のPQCアルゴリズムにはECCと比較して制限があり、一部の制約されたシステムではデータサイズに問題がある可能性があります。暗号化に関連する量子コンピューター（CRQC）が構築されている場合、ecdheパブリックキーからshared_secretを回復する可能性があります。
However, this would not affect the ability of EAP-AKA', with or without this extension, to authenticate properly. As symmetric key cryptography is safe even if CRQCs are built, an adversary still will not be able to disrupt authentication as it requires computing a correct AT_MAC value. This computation requires the K_aut key, which is based on the MK, CK', and IK', but not SHARED_SECRET.
ただし、これは、この拡張機能の有無にかかわらず、EAP-AKA 'の能力に適切に認証する能力に影響しません。CRQCが構築されていても対称的なキー暗号化は安全であるため、正しいAT_MAC値を計算する必要があるため、敵は認証を破壊することはできません。この計算には、MK、CK '、およびIK'に基づいたK_AUTキーが必要ですが、Shared_Secretではありません。
Other output keys do include SHARED_SECRET via MK_ECDHE, but they still include the CK' and IK', which are entirely based on symmetric cryptography. As a result, an adversary with a quantum computer still cannot compute the other output keys either.
他の出力キーには、MK_ECDHE経由のShared_Secretが含まれますが、対称暗号化に完全に基づいたCK 'とIK'が含まれます。その結果、量子コンピューターを備えた敵は、他の出力キーも計算することはできません。
However, if the adversary has also obtained knowledge of the long-term key, they could then compute the CK', IK', SHARED_SECRET, and any derived output keys. This means that the introduction of a powerful enough quantum computer would disable this protocol extension's ability to provide the forward secrecy capability. This would make it necessary to update the current ECC algorithms in this document to PQC algorithms. This document does not add such algorithms, but a future update can do that.
ただし、敵が長期キーの知識も得た場合、CK、IK '、Shared_Secret、および派生した出力キーを計算できます。これは、強力な十分な量子コンピューターを導入すると、このプロトコル拡張機能が将来の秘密機能を提供する能力を無効にすることを意味します。これにより、このドキュメントの現在のECCアルゴリズムをPQCアルゴリズムに更新する必要があります。このドキュメントはそのようなアルゴリズムを追加しませんが、将来の更新はそれを行うことができます。
Symmetric algorithms used in EAP-AKA' FS, such as HMAC-SHA-256 and the algorithms used to generate AT_AUTN and AT_RES, are practically secure against even large, robust quantum computers. EAP-AKA' FS is currently only specified for use with ECDHE key exchange algorithms, but use of any Key Encapsulation Method (KEM), including PQC KEMs, can be specified in the future. While the key exchange is specified with terms of the Diffie-Hellman protocol, the key exchange adheres to a KEM interface. AT_PUB_ECDHE would then contain either the ephemeral public key of the Server or the SHARED_SECRET encapsulated with the Server's public key. Note that the use of a KEM might require other changes, such as including the ephemeral public key of the Server in the key derivation to retain the property that both parties contribute randomness to the session key.
HMAC-SHA-256やAT_AUTNおよびAT_RESの生成に使用されるアルゴリズムなど、EAP-AKA 'FSで使用される対称アルゴリズムは、大規模で堅牢な量子コンピューターに対して実際に安全です。EAP-AKA 'FSは現在、ECDHEキーエクスチェンジアルゴリズムでのみ使用するために指定されていますが、PQC KEMを含むキーカプセル化方法（KEM）の使用は将来指定できます。キー交換はdiffie-hellmanプロトコルの条件で指定されていますが、キーエクスチェンジはKEMインターフェイスに準拠しています。AT_PUB_ECDHEには、サーバーのはかない公開キーまたはサーバーの公開キーにカプセル化されたShared_Secretが含まれます。KEMの使用には、キーの派生にサーバーの短命な公開鍵を含めるなど、両当事者がセッションキーにランダム性を寄付するプロパティを保持するなど、他の変更が必要になる場合があることに注意してください。
This extension of EAP-AKA' shares its attribute space and subtypes with the following:
EAP-AKA 'のこの拡張は、次の属性スペースとサブタイプを共有しています。
* "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)" [RFC4186],
* 「モバイルコミュニケーション用のグローバルシステムのための拡張可能な認証プロトコル法（GSM）サブスクライバーIDモジュール（EAP-SIM）」[RFC4186]、
* "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)" [RFC4187], and
* 「第3世代認証とキー契約（EAP-AKA）のための拡張可能な認証プロトコル法」[RFC4187]、および
* "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')" [RFC9048].
* 「3GPPモバイルネットワーク認証と主要な合意（EAP-AKA '）の拡張可能な認証プロトコル法の改善」[RFC9048]。
IANA has assigned two new values in the "Attribute Types (Skippable Attributes 128-255)" registry under the "EAP-AKA and EAP-SIM Parameters" group as follows:
IANAは、「属性タイプ（Skippable Attributes 128-255）」に2つの新しい値を「EAP-AKAおよびEAP-SIMパラメーター」グループに割り当てました。
152:
152：
AT_PUB_ECDHE (Section 6.1)
at_pub_ecdhe（セクション6.1）
153:
153：
AT_KDF_FS (Section 6.2)
AT_KDF_FS（セクション6.2）
IANA has also created the "EAP-AKA' AT_KDF_FS Key Derivation Function Values" registry to represent FS KDF types. The "EAP-AKA' with ECDHE and X25519" and "EAP-AKA' with ECDHE and P-256" types (1 and 2, see Section 6.3) have been assigned, along with one reserved value. The initial contents of this registry are illustrated in Table 1; new values can be created through the Specification Required policy [RFC8126]. Expert reviewers should ensure that the referenced specification is clearly identified and stable and that the proposed addition is reasonable for the given category of allocation.
IANAはまた、FS KDFタイプを表すために「EAP-AKA 'AT_KDF_FSキー派生関数値」レジストリを作成しました。ECDHEおよびX25519を含むeap-aka "およびecdheおよびp-256を備えた「eap-aka」タイプ（1および2、セクション6.3を参照）は、1つの予約値とともに割り当てられています。このレジストリの初期内容を表1に示します。新しい値は、必要なポリシー[RFC8126]を使用して作成できます。専門家のレビュアーは、参照された仕様が明確に識別され、安定していること、および提案された追加が特定の割り当てのカテゴリに合理的であることを確認する必要があります。
+=========+================================+===========+
| Value | Description | Reference |
+=========+================================+===========+
| 0 | Reserved | RFC 9678 |
+---------+--------------------------------+-----------+
| 1 | EAP-AKA' with ECDHE and X25519 | RFC 9678 |
+---------+--------------------------------+-----------+
| 2 | EAP-AKA' with ECDHE and P-256 | RFC 9678 |
+---------+--------------------------------+-----------+
| 3-65535 | Unassigned | RFC 9678 |
+---------+--------------------------------+-----------+
Table 1: EAP-AKA' AT_KDF_FS Key Derivation Function Values Registry Initial Contents
表1：EAP-AKA 'AT_KDF_FSキー派生関数値レジストリ初期コンテンツ
[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>.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187,
January 2006, <https://www.rfc-editor.org/info/rfc4187>.
[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
Extensible Authentication Protocol Method for 3rd
Generation Authentication and Key Agreement (EAP-AKA')",
RFC 5448, DOI 10.17487/RFC5448, May 2009,
<https://www.rfc-editor.org/info/rfc5448>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>.
[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>.
[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>.
[RFC9048] Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,
"Improved Extensible Authentication Protocol Method for
3GPP Mobile Network Authentication and Key Agreement (EAP-
AKA')", RFC 9048, DOI 10.17487/RFC9048, October 2021,
<https://www.rfc-editor.org/info/rfc9048>.
[SEC1] Standards for Efficient Cryptography, "SEC 1: Elliptic
Curve Cryptography", Version 2.0, May 2009,
<https://www.secg.org/sec1-v2.pdf>.
[SEC2] Standards for Efficient Cryptography, "SEC 2: Recommended
Elliptic Curve Domain Parameters", Version 2.0, January
2010, <https://www.secg.org/sec2-v2.pdf>.
[SP-800-186]
Chen, L., Moody, D., Randall, K., Regenscheid, A., and A.
Robinson, "Recommendations for Discrete Logarithm-based
Cryptography: Elliptic Curve Domain Parameters", NIST SP
800-186, DOI 10.6028/NIST.SP.800-186, February 2023,
<https://doi.org/10.6028/NIST.SP.800-186>.
[SP-800-56A]
Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
Davis, "Recommendation for Pair-Wise Key-Establishment
Schemes Using Discrete Logarithm Cryptography", NIST SP
800-56A, DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
<https://doi.org/10.6028/NIST.SP.800-56Ar3>.
[DOW1992] Diffie, W., Van Oorschot, P. C., and M. J. Wiener,
"Authentication and authenticated key exchanges", Designs,
Codes and Cryptography, vol. 2, pp. 107-125,
DOI 10.1007/BF00124891, June 1992,
<https://doi.org/10.1007/BF00124891>.
[Heist2015]
Scahill, J. and J. Begley, "The Great SIM Heist", February
2015,
<https://theintercept.com/2015/02/19/great-sim-heist/>.
[NIST-ZT] National Institute of Standards and Technology,
"Implementing a Zero Trust Architecture", NIST SP 1800-35,
July 2024, <https://www.nccoe.nist.gov/sites/default/
files/2024-07/zta-nist-sp-1800-35-preliminary-draft-
4.pdf>.
[NSA-ZT] National Security Agency, "Embracing a Zero Trust Security
Model", February 2021, <https://media.defense.gov/2021/
Feb/25/2002588479/-1/-1/0/
CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF>.
[RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible
Authentication Protocol Method for Global System for
Mobile Communications (GSM) Subscriber Identity Modules
(EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006,
<https://www.rfc-editor.org/info/rfc4186>.
[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>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the
Extensible Authentication Protocol with TLS 1.3",
RFC 9190, DOI 10.17487/RFC9190, February 2022,
<https://www.rfc-editor.org/info/rfc9190>.
[TrustCom2015]
Arkko, J., Norrman, K., Näslund, M., and B. Sahlin, "A
USIM Compatible 5G AKA Protocol with Perfect Forward
Secrecy", IEEE International Conference on Trust, Security
and Privacy in Computing and Communications (TrustCom),
DOI 10.1109/Trustcom.2015.506, August 2015,
<https://doi.org/10.1109/Trustcom.2015.506>.
[TS.33.501]
3GPP, "Security architecture and procedures for 5G
System", Version 19.0.0, 3GPP TS 33.501, September 2024.
The authors would like to note that the technical solution in this document came out of the TrustCom paper [TrustCom2015], whose authors were J. Arkko, K. Norrman, M. Näslund, and B. Sahlin. This document also uses a lot of material from [RFC4187] by J. Arkko and H. Haverinen, as well as [RFC5448] by J. Arkko, V. Lehtovirta, and P. Eronen.
著者は、このドキュメントの技術的なソリューションがTrustcom論文[Trustcom2015]から出てきたことに注意したいと考えています。このドキュメントでは、J。ArkkoとH. Haverinenによる[RFC4187]の多くの資料、およびJ. Arkko、V。Lehtovirta、およびP. Eronenによる[RFC5448]を使用しています。
The authors would also like to thank Ben Campbell, Meiling Chen, Roman Danyliw, Linda Dunbar, Tim Evans, Zhang Fu, Russ Housley, Tero Kivinen, Murray Kucherawy, Warren Kumari, Eliot Lear, Vesa Lehtovirta, Kathleen Moriarty, Prajwol Kumar Nakarmi, Francesca Palombini, Anand R. Prasad, Michael Richardson, Göran Rune, Bengt Sahlin, Joseph Salowey, Mohit Sethi, Orie Steele, Rene Struik, Vesa Torvinen, Sean Turner, Helena Vahidi Mazinani, Robert Wilton, Paul Wouters, Bo Wu, Peter Yee, and many other people at the IETF, GSMA, and 3GPP groups for interesting discussions in this problem space.
著者はまた、ベン・キャンベル、メーリング・チェン、ローマン・ダニリウ、リンダ・ダンバー、ティム・エヴァンス、チャン・フー、ラシュ・ヒューズリー、テロ・キビネン、マレー・クチェラウィー、ウォーレン・クマリ、エリオット・リア、ヴェサ・レトヴィルタ、キャスリーン・モリアルティ、プラジュウォル・クマル・ナカム・ナカム・ナカム・ランシャルティに感謝したいと思います。プラサド、マイケル・リチャードソン、ゲラン・ルーン、ベント・サハリン、ジョセフ・サロウィー、モヒト・セティ、オリー・スティール、レネ・ストルーイク、ヴェサ・トーヴィネン、ショーン・ターナー、ヘレナ・ヴァヒディ・マジナニ、ロバート・ウィルトン、ポール・ワーターズ、ボー・ウーターズ、ピーター・イー、そしてイン・イン・インクラッツ・イン・イン・イン・イン・ザ・イン・ザ・イン・gSma、空間。
Jari Arkko
Ericsson
FI-02420 Jorvas
Finland
Email: jari.arkko@piuha.net
Karl Norrman
Ericsson
SE-16483 Stockholm
Sweden
Email: karl.norrman@ericsson.com
John Preuß Mattsson
Ericsson
SE-164 40 Kista
Sweden
Email: john.mattsson@ericsson.com