Network Working Group H. Haverinen, Ed.
Request for Comments: 4186 Nokia
Category: Informational J. Salowey, Ed.
Cisco Systems
January 2006
Extensible Authentication Protocol Method for
Global System for Mobile Communications (GSM)
Subscriber Identity Modules (EAP-SIM)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
IESG Note
IESG注意
The EAP-SIM protocol was developed by 3GPP. The documentation of EAP-SIM is provided as information to the Internet community. While the EAP WG has verified that EAP-SIM is compatible with EAP, as defined in RFC 3748, no other review has been done, including validation of the security claims. The IETF has also not reviewed the security of the cryptographic algorithms.
EAP-SIMプロトコルは、3GPPにより開発されました。 EAP-SIMのドキュメントは、インターネットコミュニティに情報として提供されます。 EAP WGは、RFC 3748で定義されているEAP-SIMは、EAPと互換性があることを確認したが、他のレビューは、セキュリティクレームの妥当性検証を含む、行われていません。 IETFはまた、暗号アルゴリズムの安全性を検討していません。
Abstract
抽象
This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). GSM is a second generation mobile network standard. The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure.
この文書は、移動通信用グローバルシステム（GSM）加入者識別モジュール（SIM）を使用して認証およびセッション鍵の配布のために拡張認証プロトコル（EAP）メカニズムを指定します。 GSMは、第二世代モバイルネットワーク規格です。 EAP-SIM機構は、GSM認証及び複数の認証トリプレットは、認証応答と個々のGSMトリプレットを超える強度のセッション・キーを作成するために組み合わせることができる鍵合意の拡張を指定します。機構はまた、ネットワーク認証、ユーザの匿名サポート、結果の表示、及び速い再認証手順を含んでいます。
Table of Contents
目次
1. Introduction ....................................................4
2. Terms ...........................................................5
3. Overview ........................................................8
4. Operation ......................................................10
4.1. Version Negotiation .......................................10
4.2. Identity Management .......................................11
4.2.1. Format, Generation and Usage of Peer Identities ....11
4.2.2. Communicating the Peer Identity to the Server ......17
4.2.3. Choice of Identity for the EAP-Response/Identity ...19
4.2.4. Server Operation in the Beginning of
EAP-SIM Exchange ...................................19
4.2.5. Processing of EAP-Request/SIM/Start by the Peer ....20
4.2.6. Attacks Against Identity Privacy ...................21
4.2.7. Processing of AT_IDENTITY by the Server ............22
4.3. Message Sequence Examples (Informative) ...................23
4.3.1. Full Authentication ................................24
4.3.2. Fast Re-authentication .............................25
4.3.3. Fall Back to Full Authentication ...................26
4.3.4. Requesting the Permanent Identity 1 ................27
4.3.5. Requesting the Permanent Identity 2 ................28
4.3.6. Three EAP-SIM/Start Roundtrips .....................28
5. Fast Re-Authentication .........................................30
5.1. General ...................................................30
5.2. Comparison to UMTS AKA ....................................31
5.3. Fast Re-authentication Identity ...........................31
5.4. Fast Re-authentication Procedure ..........................33
5.5. Fast Re-authentication Procedure when Counter Is
Too Small .................................................36
6. EAP-SIM Notifications ..........................................37
6.1. General ...................................................37
6.2. Result Indications ........................................39
6.3. Error Cases ...............................................40
6.3.1. Peer Operation .....................................40
6.3.2. Server Operation ...................................41
6.3.3. EAP-Failure ........................................42
6.3.4. EAP-Success ........................................42
7. Key Generation .................................................43
8. Message Format and Protocol Extensibility ......................45
8.1. Message Format ............................................45
8.2. Protocol Extensibility ....................................47
9. Messages .......................................................48
9.1. EAP-Request/SIM/Start .....................................48
9.2. EAP-Response/SIM/Start ....................................49
9.3. EAP-Request/SIM/Challenge .................................49
9.4. EAP-Response/SIM/Challenge ................................50
9.5. EAP-Request/SIM/Re-authentication .........................51
9.6. EAP-Response/SIM/Re-authentication ........................51
9.7. EAP-Response/SIM/Client-Error .............................52
9.8. EAP-Request/SIM/Notification ..............................52
9.9. EAP-Response/SIM/Notification .............................53
10. Attributes ....................................................53
10.1. Table of Attributes ......................................53
10.2. AT_VERSION_LIST ..........................................54
10.3. AT_SELECTED_VERSION ......................................55
10.4. AT_NONCE_MT ..............................................55
10.5. AT_PERMANENT_ID_REQ ......................................56
10.6. AT_ANY_ID_REQ ............................................56
10.7. AT_FULLAUTH_ID_REQ .......................................57
10.8. AT_IDENTITY ..............................................57
10.9. AT_RAND ..................................................58
10.10. AT_NEXT_PSEUDONYM .......................................59
10.11. AT_NEXT_REAUTH_ID .......................................59
10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING .....................60
10.13. AT_RESULT_IND ...........................................62
10.14. AT_MAC ..................................................62
10.15. AT_COUNTER ..............................................63
10.16. AT_COUNTER_TOO_SMALL ....................................63
10.17. AT_NONCE_S ..............................................64
10.18. AT_NOTIFICATION .........................................64
10.19. AT_CLIENT_ERROR_CODE ....................................65
11. IANA Considerations ...........................................66
12. Security Considerations .......................................66
12.1. A3 and A8 Algorithms .....................................66
12.2. Identity Protection ......................................66
12.3. Mutual Authentication and Triplet Exposure ...............67
12.4. Flooding the Authentication Centre .......................69
12.5. Key Derivation ...........................................69
12.6. Cryptographic Separation of Keys and Session
Independence .............................................70
12.7. Dictionary Attacks .......................................71
12.8. Credentials Re-use .......................................71
12.9. Integrity and Replay Protection, and Confidentiality .....72
12.10. Negotiation Attacks .....................................73
12.11. Protected Result Indications ............................73
12.12. Man-in-the-Middle Attacks ...............................74
12.13. Generating Random Numbers ...............................74
13. Security Claims ...............................................74
14. Acknowledgements and Contributions ............................75
14.1. Contributors .............................................75
14.2. Acknowledgements .........................................75
14.2.1. Contributors' Addresses ...........................77
15. References ....................................................78
15.1. Normative References .....................................78
15.2. Informative References ...................................79
Appendix A. Test Vectors .........................................81
A.1. EAP-Request/Identity .....................................81
A.2. EAP-Response/Identity ....................................81
A.3. EAP-Request/SIM/Start ....................................82
A.4. EAP-Response/SIM/Start ...................................82
A.5. EAP-Request/SIM/Challenge ................................83
A.6. EAP-Response/SIM/Challenge ...............................86
A.7. EAP-Success ..............................................86
A.8. Fast Re-authentication ...................................86
A.9. EAP-Request/SIM/Re-authentication ........................87
A.10. EAP-Response/SIM/Re-authentication ......................89
Appendix B. Pseudo-Random Number Generator .......................90
This document specifies an Extensible Authentication Protocol (EAP) [RFC3748] mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM).
この文書は、移動通信用グローバルシステム（GSM）加入者識別モジュール（SIM）を使用して認証およびセッション鍵の配布のために拡張認証プロトコル（EAP）[RFC3748]メカニズムを指定します。
GSM is a second generation mobile network standard. Second generation mobile networks and third generation mobile networks use different authentication and key agreement mechanisms. EAP-AKA [EAP-AKA] specifies an EAP method that is based on the Authentication and Key Agreement (AKA) mechanism used in 3rd generation mobile networks.
GSMは、第二世代モバイルネットワーク規格です。第二世代モバイルネットワークと第三世代モバイルネットワークは異なる認証および鍵合意のメカニズムを使用します。 EAP-AKA [EAP-AKA]は第三世代モバイルネットワークで使用される認証および鍵合意（AKA）メカニズムに基づいているEAP方式を指定します。
GSM authentication is based on a challenge-response mechanism. The A3/A8 authentication and key derivation algorithms that run on the SIM can be given a 128-bit random number (RAND) as a challenge. The SIM runs operator-specific algorithms, which take the RAND and a secret key Ki (stored on the SIM) as input, and produce a 32-bit response (SRES) and a 64-bit long key Kc as output. The Kc key is originally intended to be used as an encryption key over the air interface, but in this protocol, it is used for deriving keying material and is not directly used. Hence, the secrecy of Kc is critical to the security of this protocol. For more information about GSM authentication, see [GSM-03.20]. See Section 12.1 for more discussion about the GSM algorithms used in EAP-SIM.
GSM認証は、チャレンジ・レスポンスメカニズムに基づいています。 SIM上で実行A3 / A8認証および鍵導出アルゴリズムは、チャレンジとして128ビットの乱数（RAND）を挙げることができます。 SIMは、入力としてRANDおよび秘密鍵Ki（SIMに保存されている）を取るオペレータ固有のアルゴリズムを実行し、32ビットの応答（SRES）と、出力として64ビット長の鍵Kcを生成します。 Kcの鍵は、元々のエアインタフェースを介して暗号鍵として使用されることが意図されているが、このプロトコルでは、鍵材料を導出するために使用され、直接使用されません。したがって、Kcをの秘密は、このプロトコルのセキュリティにとって非常に重要です。 GSM認証の詳細については、[GSM-03.20]。 EAP-SIMで使用されるGSMアルゴリズムについての詳細な議論については、セクション12.1を参照してください。
The lack of mutual authentication is a weakness in GSM authentication. The derived 64-bit cipher key (Kc) is not strong enough for data networks in which stronger and longer keys are required. Hence, in EAP-SIM, several RAND challenges are used for generating several 64-bit Kc keys, which are combined to constitute stronger keying material. In EAP-SIM, the client issues a random number NONCE_MT to the network in order to contribute to key derivation, and to prevent replays of EAP-SIM requests from previous exchanges. The NONCE_MT can be conceived as the client's challenge to the network. EAP-SIM also extends the combined RAND challenges and other messages with a message authentication code in order to provide message integrity protection along with mutual authentication.
相互認証の欠如は、GSM認証の弱点です。誘導された64ビットの暗号鍵（Kcが）より強く、より長い鍵が必要とされるデータネットワークのために十分に強くありません。したがって、EAP-SIMに、いくつかのRANDの課題は、より強力な鍵材料を構成するために組み合わされる、いくつかの64ビットのKc鍵を生成するために使用されます。 EAP-SIMでは、クライアントは鍵導出に貢献する、と以前の取引所からのEAP-SIM要求のリプレイを防ぐために、ネットワークへの乱数NONCE_MTを発行します。 NONCE_MTは、ネットワークへのクライアントの課題として考えられます。 EAP-SIMはまた、相互認証と一緒に、メッセージの完全性保護を提供するために、メッセージ認証コードと組み合わせたRANDの課題と他のメッセージを拡張します。
EAP-SIM specifies optional support for protecting the privacy of subscriber identity using the same concept as the GSM, which uses pseudonyms/temporary identifiers. It also specifies an optional fast re-authentication procedure.
EAP-SIMは偽名/一時的な識別子を使用していますGSM、同じ概念を使用して加入者識別のプライバシーを保護するためのオプションのサポートを指定します。また、オプションの高速再認証手順を指定します。
The security of EAP-SIM builds on underlying GSM mechanisms. The security properties of EAP-SIM are documented in Section 11 of this document. Implementers and users of EAP-SIM are advised to carefully study the security considerations in Section 11 in order to determine whether the security properties are sufficient for the environment in question, especially as the secrecy of Kc keys is essential to the security of EAP-SIM. In brief, EAP-SIM is in no sense weaker than the GSM mechanisms. In some cases EAP-SIM provides better security properties than the underlying GSM mechanisms, particularly if the SIM credentials are only used for EAP-SIM and are not re-used from GSM/GPRS. Many of the security features of EAP-SIM rely upon the secrecy of the Kc values in the SIM triplets, so protecting these values is key to the security of the EAP-SIM protocol.
EAP-SIMのセキュリティは、基礎となるGSMメカニズムに基づいています。 EAP-SIMのセキュリティプロパティは、このドキュメントのセクション11に記載されています。 EAP-SIMの実装およびユーザーは、慎重にセキュリティプロパティがKcの鍵の秘密は、EAP-SIMのセキュリティに不可欠である、特にとして、問題の環境のために十分であるかどうかを判断するために、第11節のセキュリティの考慮事項を検討することをお勧めします。簡単に説明すると、EAP-SIMは、GSMメカニズムよりも弱いない意味です。いくつかのケースでは、EAP-SIMは、SIMクレデンシャルのみEAP-SIMのために使用され、GSM / GPRSから再使用されていない場合は特に、基礎となるGSMメカニズムよりも優れたセキュリティ特性を提供します。 EAP-SIMのセキュリティ機能の多くは、そう、これらの値を保護することは、EAP-SIMプロトコルのセキュリティへの鍵である、SIMトリプレット中のKc値の機密性に依存しています。
The 3rd Generation Partnership Project (3GPP) has specified an enhanced Authentication and Key Agreement (AKA) architecture for the Universal Mobile Telecommunications System (UMTS). The 3rd generation AKA mechanism includes mutual authentication, replay protection, and derivation of longer session keys. EAP-AKA [EAP-AKA] specifies an EAP method that is based on the 3rd generation AKA. EAP-AKA, which is a more secure protocol, may be used instead of EAP-SIM, if 3rd generation identity modules and 3G network infrastructures are available.
3GPP（3rd Generation Partnership Project）はユニバーサル移動通信システム（UMTS）のために強化され、認証および鍵合意（AKA）アーキテクチャを指定しています。第3世代AKAメカニズムは、相互認証、再生保護、および長いセッションキーの導出を含んでいます。 EAP-AKA [EAP-AKA]は、第3世代AKAに基づいているEAP方式を指定します。第3世代アイデンティティモジュールと3Gネットワークインフラストラクチャが利用可能な場合、より安全なプロトコルであるEAP-AKAは、代わりに、EAP-SIMを用いてもよいです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The terms and abbreviations "authenticator", "backend authentication server", "EAP server", "peer", "Silently Discard", "Master Session Key (MSK)", and "Extended Master Session Key (EMSK)" in this document are to be interpreted as described in [RFC3748].
用語および略語「オーセンティケータ」、「バックエンド認証サーバ」、「EAPサーバ」、「ピア」、「サイレント破棄」、この文書の「マスターセッションキー（MSK）」、および「拡張マスターセッションキー（EMSK）」 [RFC3748]で説明されるように解釈されるべきです。
This document frequently uses the following terms and abbreviations:
このドキュメントは頻繁に次の用語および略語を使用しています。
AAA protocol
AAAプロトコル
Authentication, Authorization, and Accounting protocol
認証、認可、およびアカウンティングプロトコル
AuC
AuCは
Authentication Centre. The GSM network element that provides
the authentication triplets for authenticating
the subscriber.
Authentication vector
認証ベクトル
GSM triplets can be alternatively called authentication
vectors.
EAP
EAP
Extensible Authentication Protocol
拡張認証プロトコル
Fast re-authentication
高速再認証
An EAP-SIM authentication exchange that is based on keys
derived upon a preceding full authentication exchange.
The GSM authentication and key exchange algorithms are not
used in the fast re-authentication procedure.
Fast Re-authentication Identity
高速再認証アイデンティティ
A fast re-authentication identity of the peer, including an NAI
realm portion in environments where a realm is used. Used on
fast re-authentication only.
Fast Re-authentication Username
高速再認証ユーザ名
The username portion of fast re-authentication identity,
i.e., not including any realm portions.
Full authentication
完全な認証
An EAP-SIM authentication exchange based on the GSM
authentication and key agreement algorithms.
GSM
GSM
Global System for Mobile communications.
モバイル通信用グローバルシステム。
GSM Triplet
GSMトリプレット
The tuple formed by the three GSM authentication values RAND,
Kc, and SRES.
IMSI
IMSI
International Mobile Subscriber Identifier, used in GSM to
identify subscribers.
MAC
マック
Message Authentication Code
メッセージ認証コード
NAI
ない
Network Access Identifier
ネットワークアクセス識別子
Nonce
使節
A value that is used at most once or that is never repeated
within the same cryptographic context. In general, a nonce can
be predictable (e.g., a counter) or unpredictable (e.g., a
random value). Since some cryptographic properties may depend
on the randomness of the nonce, attention should be paid to
whether a nonce is required to be random or not. In this
document, the term nonce is only used to denote random nonces,
and it is not used to denote counters.
Permanent Identity
永久的なアイデンティティ
The permanent identity of the peer, including an NAI realm
portion in environments where a realm is used. The permanent
identity is usually based on the IMSI. Used on full
authentication only.
Permanent Username
恒久的なユーザー名
The username portion of permanent identity, i.e., not including
any realm portions.
Pseudonym Identity
仮名アイデンティティ
A pseudonym identity of the peer, including an NAI realm
portion in environments where a realm is used. Used on
full authentication only.
Pseudonym Username
仮名ユーザー名
The username portion of pseudonym identity, i.e., not including
any realm portions.
SIM
SIM
Subscriber Identity Module. The SIM is traditionally a smart
card distributed by a GSM operator.
Figure 1 shows an overview of the EAP-SIM full authentication procedure, wherein optional protected success indications are not used. The authenticator typically communicates with an EAP server that is located on a backend authentication server using an AAA protocol. The authenticator shown in the figure is often simply relaying EAP messages to and from the EAP server, but these backend AAA communications are not shown.
図1は、オプションの保護された成功の指標が使用されていない、請求EAP-SIM完全認証手順の概要を示しています。オーセンティケータは、典型的には、AAAプロトコルを使用してバックエンド認証サーバ上に位置するEAPサーバと通信を行います。図に示す認証システムは、多くの場合、単純にし、EAPサーバからEAPメッセージを中継しているが、これらのバックエンドのAAA通信は表示されません。
Peer Authenticator
| EAP-Request/Identity |
|<---------------------------------------------------------|
| |
| EAP-Response/Identity |
|--------------------------------------------------------->|
| |
| EAP-Request/SIM/Start (AT_VERSION_LIST) |
|<---------------------------------------------------------|
| |
| EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)|
|--------------------------------------------------------->|
| |
| EAP-Request/SIM/Challenge (AT_RAND, AT_MAC) |
|<---------------------------------------------------------|
+-------------------------------------+ |
| Peer runs GSM algorithms, verifies | |
| AT_MAC and derives session keys | |
+-------------------------------------+ |
| EAP-Response/SIM/Challenge (AT_MAC) |
|--------------------------------------------------------->|
| |
| EAP-Success |
|<---------------------------------------------------------|
| |
Figure 1: EAP-SIM full authentication procedure
図1：EAP-SIMの完全な認証手順
The first EAP Request issued by the authenticator is EAP-Request/Identity. On full authentication, the peer's response includes either the user's International Mobile Subscriber Identity (IMSI) or a temporary identity (pseudonym) if identity privacy is in effect, as specified in Section 4.2.
オーセンティケータによって発行された最初のEAP要求は、EAP要求/アイデンティティです。 4.2節で指定されたアイデンティティプライバシーは、有効である場合、完全な認証では、ピアの応答は、ユーザの国際移動加入者識別（IMSI）または一時的なアイデンティティ（仮名）のいずれかを含んでいます。
Following the peer's EAP-Response/Identity packet, the peer receives EAP Requests of Type 18 (SIM) from the EAP server and sends the corresponding EAP Responses. The EAP packets that are of the Type SIM also have a Subtype field. On full authentication, the first EAP-Request/SIM packet is of the Subtype 10 (Start). EAP-SIM packets encapsulate parameters in attributes, encoded in a Type, Length, Value format. The packet format and the use of attributes are specified in Section 8.
ピアのEAP応答/アイデンティティパケットに続いて、ピアはEAPサーバからタイプ18（SIM）のEAP要求を受信し、対応EAP応答を送信します。タイプSIMであるEAPパケットはまた、サブタイプのフィールドを持っています。完全な認証では、最初のEAP要求/ SIMパケットは、サブタイプ10（スタート）です。 EAP-SIMパケットは、タイプ、長さ、値の形式で符号化された属性のパラメータをカプセル化。パケットフォーマットと属性の使用はセクション8で指定されています。
The EAP-Request/SIM/Start packet contains the list of EAP-SIM versions supported by the EAP server in the AT_VERSION_LIST attribute. This packet may also include attributes for requesting the subscriber identity, as specified in Section 4.2.
EAP要求/ SIM /スタートパケットはAT_VERSION_LIST属性におけるEAPサーバでサポートされているEAP-SIMバージョンのリストが含まれています。このパケットはまた、4.2節で指定されるように、加入者識別を要求するための属性を含むことができます。
The peer responds to a EAP-Request/SIM/Start with the EAP-Response/SIM/Start packet, which includes the AT_NONCE_MT attribute that contains a random number NONCE_MT, chosen by the peer, and the AT_SELECTED_VERSION attribute that contains the version number selected by the peer. The version negotiation is protected by including the version list and the selected version in the calculation of keying material (Section 7).
ピアは、ピアによって選ばれた乱数NONCE_MTを、含まれていAT_NONCE_MT属性が含まEAP応答/ SIM / Startパケットと、選択したバージョン番号が含まれているAT_SELECTED_バージョン属性でEAP要求/ SIM /スタートに応答しますピアによります。バージョンネゴシエーションは、バージョンリストと材料（セクション7）キーイングの計算において選択されたバージョンを含むことによって保護されています。
After receiving the EAP Response/SIM/Start, the EAP server obtains n GSM triplets for use in authenticating the subscriber, where n = 2 or n = 3. From the triplets, the EAP server derives the keying material, as specified in Section 7. The triplets may be obtained by contacting an Authentication Centre (AuC) on the GSM network; per GSM specifications, between 1 and 5 triplets may be obtained at a time. Triplets may be stored in the EAP server for use at a later time, but triplets MUST NOT be re-used, except in some error cases that are specified in Section 10.9.
セクション7で指定されたEAP応答/ SIM /開始を受信した後に、EAPサーバは、ここで、n = 2又はn =トリプレット3.、EAPサーバは鍵材料を導出する、加入者を認証する際に使用するためのトリプレットを取得N GSM 。トリプレットは、GSMネットワーク上の認証センター（AUC）を接触させることによって得ることができます。 GSMの仕様ごとに、1〜5トリプレットを一度に得ることができます。三つ子は、後で使用するためのEAPサーバに格納してもよいが、三つ子は10.9節で指定されているいくつかのエラーの場合を除き、再使用してはいけません。
The next EAP Request the EAP Server issues is of the type SIM and subtype Challenge (11). It contains the RAND challenges and a message authentication code attribute AT_MAC to cover the challenges. The AT_MAC attribute is a general message authentication code attribute that is used in many EAP-SIM messages.
次のEAP要求EAP Serverの問題タイプSIMとサブタイプの挑戦（11）です。それは挑戦をカバーするためにRAND挑戦とメッセージ認証コード属性AT_MACが含まれています。 AT_MAC属性は、多くのEAP-SIMメッセージで使用される一般的なメッセージ認証コード属性です。
On receipt of the EAP-Request/SIM/Challenge message, the peer runs the GSM authentication algorithm and calculates a copy of the message authentication code. The peer then verifies that the calculated MAC equals the received MAC. If the MAC's do not match, then the peer sends the EAP-Response/SIM/Client-Error packet and the authentication exchange terminates.
EAPリクエスト/ SIM / Challengeメッセージを受信すると、ピアは、GSM認証アルゴリズムを実行し、メッセージ認証コードのコピーを算出します。ピアは、次いで、計算されたMACは、受信MACと等しいことを検証します。 MACのが一致しない場合、ピアはEAP応答/ SIM /クライアントエラーパケットを送信し、認証交換は終了します。
Since the RANDs given to a peer are accompanied by the message authentication code AT_MAC, and since the peer's NONCE_MT value contributes to AT_MAC, the peer is able to verify that the EAP-SIM message is fresh (i.e., not a replay) and that the sender possesses valid GSM triplets for the subscriber.
ピアに付与ランズは、メッセージ認証コードAT_MACを伴うので、ピアのNONCE_MT値はAT_MACに寄与するため、および、ピアはEAP-SIMメッセージが新鮮であることを確認することができる（すなわち、ないリプレイ）とすることです送信者は、加入者のための有効なGSM三つ子を有しています。
If all checks out, the peer responds with the EAP-Response/SIM/Challenge, containing the AT_MAC attribute that covers the peer's SRES response values (Section 9.4). The EAP server verifies that the MAC is correct. Because protected success indications are not used in this example, the EAP server sends the EAP-Success packet, indicating that the authentication was successful. (Protected success indications are discussed in Section 6.2.) The EAP server may also include derived keying material in the message it sends to the authenticator. The peer has derived the same keying material, so the authenticator does not forward the keying material to the peer along with EAP-Success.
もしすべてのチェックアウト、ピアはピアのSRESの応答値（9.4節）をカバーAT_MAC属性を含む、EAP応答/ SIM /挑戦で応答します。 EAPサーバは、MACが正しいことを確認します。保護された成功指摘がこの例で使用されていないので、EAPサーバは認証が成功したことを示す、EAP-Successパケットを送信します。 （成功指示がセクション6.2で議論されている保護された。）EAPサーバはまた、オーセンティケータに送信するメッセージで導出鍵材料を含むことができます。オーセンティケータがEAP-成功と一緒に相手に合わせることの材料を転送しないように、ピアは、同じ鍵素材を得ました。
EAP-SIM also includes a separate fast re-authentication procedure that does not make use of the A3/A8 algorithms or the GSM infrastructure. Fast re-authentication is based on keys derived on full authentication. If the peer has maintained state information for fast re-authentication and wants to use fast re-authentication, then the peer indicates this by using a specific fast re-authentication identity instead of the permanent identity or a pseudonym identity. The fast re-authentication procedure is described in Section 5.
EAP-SIMはまた、A3 / A8アルゴリズムまたはGSMインフラストラクチャを使用しない別速い再認証手順を含んでいます。高速再認証は完全な認証に引き出されたキーに基づいています。ピアが速い再認証のための状態情報を維持し、高速再認証を使用したいしている場合、ピアは、代わりに永久的なアイデンティティか匿名のアイデンティティの特定の速い再認証のアイデンティティを使用してこれを示します。高速再認証手順は、第5章で説明されています。
EAP-SIM includes version negotiation so as to allow future developments in the protocol. The version negotiation is performed on full authentication and it uses two attributes, AT_VERSION_LIST, which the server always includes in EAP-Request/SIM/Start, and AT_SELECTED_VERSION, which the peer includes in EAP-Response/SIM/Start on full authentication.
プロトコルでの今後の展開を可能にするように、EAP-SIMは、バージョン交渉が含まれています。バージョン交渉は完全な認証で実行され、それは、ピアは完全な認証にEAP応答/ SIM /スタートに含まれるサーバは常にEAP要求/ SIM /スタート、およびAT_SELECTED_バージョンに含まれてAT_VERSION_LISTを、二つの属性を使用しています。
AT_VERSION_LIST includes the EAP-SIM versions supported by the server. If AT_VERSION_LIST does not include a version that is implemented by the peer and allowed in the peer's security policy, then the peer MUST send the EAP-Response/SIM/Client-Error packet (Section 9.7) to the server with the error code "unsupported version". If a suitable version is included, then the peer includes the AT_SELECTED_VERSION attribute, containing the selected version in the EAP-Response/SIM/Start packet. The peer MUST only indicate a version that is included in the AT_VERSION_LIST. If several versions are acceptable, then the peer SHOULD choose the version that occurs first in the version list.
AT_VERSION_LISTは、サーバーでサポートされているEAP-SIMのバージョンが含まれています。 AT_VERSION_LISTは、ピアによって実装され、ピアのセキュリティポリシーで許可されているバージョンが含まれていない場合は、ピアは、「サポートされていないエラーコードでサーバーにEAP応答/ SIM /クライアントエラーパケット（セクション9.7）を送らなければなりません版"。適したバージョンが含まれている場合、ピアはEAP応答/ SIM /スタートパケット内の選択したバージョンを含む、AT_SELECTED_バージョン属性を含んでいます。ピアはAT_VERSION_LISTに含まれているバージョンを示すだけしなければなりません。いくつかのバージョンが許容されている場合、ピアは、バージョンリストの最初に発生したバージョンを選択する必要があります。
The version number list of AT_VERSION_LIST and the selected version of AT_SELECTED_VERSION are included in the key derivation procedure (Section 7). If an attacker modifies either one of these attributes, then the peer and the server derive different keying material. Because K_aut keys are different, the server and peer calculate different AT_MAC values. Hence, the peer detects that AT_MAC, included in EAP-Request/SIM/Challenge, is incorrect and sends the EAP-Response/SIM/Client-Error packet. The authentication procedure terminates.
AT_VERSION_LISTのバージョン番号のリストとAT_SELECTED_バージョンの選択されたバージョンは、鍵導出手順（セクション7）に含まれます。攻撃者がこれらの属性のいずれかを変更する場合は、ピアとサーバが異なるキーイング材料を導き出します。 K_autキーが異なるため、サーバとピアは異なるAT_MAC値を計算します。したがって、ピアはAT_MACは、EAP要求/ SIM /挑戦に含まれていることを検出し、間違っているとEAP応答/ SIM /クライアントエラーパケットを送信します。認証手続きは終了します。
In the beginning of EAP authentication, the Authenticator or the EAP server usually issues the EAP-Request/Identity packet to the peer. The peer responds with the EAP-Response/Identity, which contains the user's identity. The formats of these packets are specified in [RFC3748].
EAP認証の冒頭では、オーセンティケータまたはEAPサーバは通常、ピアにEAP要求/アイデンティティパケットを発行します。ピアは、ユーザーのIDが含まれているEAP応答/アイデンティティで応答します。これらのパケットのフォーマットは、[RFC3748]で指定されています。
GSM subscribers are identified with the International Mobile Subscriber Identity (IMSI) [GSM-03.03]. The IMSI is a string of not more than 15 digits. It is composed of a three digit Mobile Country Code (MCC), a two or three digit Mobile Network Code (MNC), and a Mobile Subscriber Identification Number (MSIN) of no more than 10 digits. MCC and MNC uniquely identify the GSM operator and help identify the AuC from which the authentication vectors need to be retrieved for this subscriber.
GSM加入者は、国際移動電話加入者識別番号（IMSI）[GSM-03.03]で識別されます。 IMSIはない以上15以下の数字の文字列です。これは、3桁のモバイル国コード（MCC）、2つ、または3桁のモバイルネットワークコード（MNC）、およびせいぜい10桁の移動加入者識別番号（MSIN）から構成されています。 MCCとMNCを一意GSMオペレータを識別し、認証ベクトルは、この加入者のために検索する必要があるから、AUCは識別するのに役立ちます。
Internet AAA protocols identify users with the Network Access Identifier (NAI) [RFC4282]. When used in a roaming environment, the NAI is composed of a username and a realm, separated with "@" (username@realm). The username portion identifies the subscriber within the realm.
インターネットAAAプロトコルは、ネットワークアクセス識別子（NAI）[RFC4282]を使用してユーザーを識別します。ローミング環境で使用される場合、NAIは、「@」（ユーザ名@レルム）で区切られ、ユーザ名およびレルムで構成されています。ユーザ名部分は、領域内の加入者を識別する。
This section specifies the peer identity format used in EAP-SIM. In this document, the term "identity" or "peer identity" refers to the whole identity string that is used to identify the peer. The peer identity may include a realm portion. "Username" refers to the portion of the peer identity that identifies the user, i.e., the username does not include the realm portion.
このセクションでは、EAP-SIMで使用されるピア・アイデンティティの形式を指定します。この文書では、用語「同一」または「ピアのアイデンティティは」ピアを識別するために使用される全体のアイデンティティストリングを指します。ピアのアイデンティティはレルム部分を含んでいてもよいです。 「ユーザ名」、すなわち、ユーザ名がレルム部分を含まない、ユーザを識別するピア同一の部分を指します。
EAP-SIM includes optional identity privacy (anonymity) support that can be used to hide the cleartext permanent identity and thereby make the subscriber's EAP exchanges untraceable to eavesdroppers. Because the permanent identity never changes, revealing it would help observers to track the user. The permanent identity is usually based on the IMSI, which may further help the tracking, because the same identifier may be used in other contexts as well. Identity privacy is based on temporary identities, or pseudonyms, which are equivalent to but separate from the Temporary Mobile Subscriber Identities (TMSI) that are used on cellular networks. Please see Section 12.2 for security considerations regarding identity privacy.
EAP-SIMは、クリアテキスト永久的なアイデンティティを隠し、それによって、盗聴者に加入者のEAP交換が追跡不可能にするために使用することができる任意のアイデンティティプライバシー（匿名）のサポートを含みます。永久的なアイデンティティが変化したことがないので、明らかにそれは、ユーザーを追跡するためにオブザーバーを助けます。同じ識別子は、他のコンテキストで使用することができるので、永久的なアイデンティティは、通常、さらに追跡を助けることができるIMSIに基づいています。アイデンティティプライバシーはと同等のが、携帯電話ネットワーク上で使用されている一時的なモバイル加入者アイデンティティ（TMSI）から分離され、一時的なアイデンティティ、または仮名に基づいています。アイデンティティプライバシーに関するセキュリティ上の考慮事項については、セクション12.2を参照してください。
There are three types of usernames in EAP-SIM peer identities:
EAP-SIMのピア・アイデンティティにおけるユーザ名の3つのタイプがあります。
(1) Permanent usernames. For example, 1123456789098765@myoperator.com might be a valid permanent identity. In this example, 1123456789098765 is the permanent username.
（1）永久ユーザ名。例えば、1123456789098765@myoperator.comは有効な永久的なアイデンティティであるかもしれません。この例では、1123456789098765は永久的なユーザ名です。
(2) Pseudonym usernames. For example, 3s7ah6n9q@myoperator.com might be a valid pseudonym identity. In this example, 3s7ah6n9q is the pseudonym username.
（2）匿名ユーザ名。例えば、3s7ah6n9q@myoperator.comは有効な匿名のアイデンティティであるかもしれません。この例では、3s7ah6n9qは、匿名ユーザ名です。
(3) Fast re-authentication usernames. For example, 53953754@myoperator.com might be a valid fast re-authentication identity. In this case, 53953754 is the fast re-authentication username. Unlike permanent usernames and pseudonym usernames, fast re-authentication usernames are one-time identifiers, which are not re-used across EAP exchanges.
（3）高速再認証ユーザ名。例えば、53953754@myoperator.comは有効な速い再認証のアイデンティティであるかもしれません。この場合、53953754は速い再認証ユーザ名です。永久的なユーザ名と匿名ユーザ名とは異なり、高速再認証ユーザ名は、EAP交換の間で再利用されていない1回限りの識別子は、あります。
The first two types of identities are used only on full authentication and the last one only on fast re-authentication. When the optional identity privacy support is not used, the non-pseudonym permanent identity is used on full authentication. The fast re-authentication exchange is specified in Section 5.
アイデンティティの最初の2つのタイプだけ完全な認証とだけ速い再認証の最後の1で使用されています。オプションのアイデンティティプライバシーサポートが使用されていない場合は、非仮名永久的なアイデンティティは完全な認証に使用されています。高速再認証交換はセクション5で指定されています。
In some environments, the peer may need to decorate the identity by prepending or appending the username with a string, in order to indicate supplementary AAA routing information in addition to the NAI realm. (The usage of an NAI realm portion is not considered decoration.) Username decoration is out of the scope of this document. However, it should be noted that username decoration might prevent the server from recognizing a valid username. Hence, although the peer MAY use username decoration in the identities that the peer includes in EAP-Response/Identity, and although the EAP server MAY accept a decorated peer username in this message, the peer or the EAP server MUST NOT decorate any other peer identities that are used in various EAP-SIM attributes. Only the identity used in the EAP-Response/Identity may be decorated.
いくつかの環境では、ピアは、NAIのレルムに加えて補助AAAルーティング情報を示すために、前置または文字列とユーザ名を追加することによって識別を装飾する必要があるかもしれません。 （NAIのレルム部分の使用は、装飾を考慮されていない。）のユーザ名デコレーションは、この文書の範囲外です。しかし、ユーザ名デコレーションが有効なユーザー名を認識することからサーバーを防ぐ可能性があることに留意すべきです。したがって、ピアはEAP応答/アイデンティティに含まれており、EAPサーバは、このメッセージで装飾ピアのユーザ名を受け入れるかもしれないが、ピアまたはEAPサーバが他のピアを飾るてはならないことをピアがアイデンティティにユーザ名の装飾を使用してもよいが様々なEAP-SIM属性で使用されているアイデンティティ。 EAP応答/アイデンティティで使用される唯一のアイデンティティが飾られていてもよいです。
The peer MAY include a realm portion in the peer identity, as per the NAI format. The use of a realm portion is not mandatory.
ピアはNAIフォーマットに従って、ピア・アイデンティティにレルム部分を含むことができます。分野の部分の使用は必須ではありません。
If a realm is used, the realm MAY be chosen by the subscriber's home operator and it MAY be a configurable parameter in the EAP-SIM peer implementation. In this case, the peer is typically configured with the NAI realm of the home operator. Operators MAY reserve a specific realm name for EAP-SIM users. This convention makes it easy to recognize that the NAI identifies a GSM subscriber. Such a reserved NAI realm may be a useful hint as to the first authentication method to use during method negotiation. When the peer is using a pseudonym username instead of the permanent username, the peer selects the realm name portion similarly as it select the realm portion when using the permanent username.
レルムが使用されている場合、レルムは、加入者のホームオペレータによって選択することができる、それがEAP-SIM同輩実装で構成パラメータであってもよいです。この場合、ピアは、典型的には、ホームオペレータのNAIのレルムで構成されています。オペレータはEAP-SIMユーザーのための特定の分野名を予約することができます。この規則は、NAIは、GSM加入者を識別することを認識することが容易になります。そのような予約されたNAIのレルムは、メソッドのネゴシエーション中に使用する第1の認証方法についての有用なヒントであってもよいです。ピアが匿名ユーザ名の代わりに、永久的なユーザ名を使用している場合、ピアは、永久的なユーザ名を使用する場合、それは分野の部分を選択するのと同様に領域名部分を選択します。
If no configured realm name is available, the peer MAY derive the realm name from the MCC and MNC portions of the IMSI. A RECOMMENDED way to derive the realm from the IMSI using the realm 3gppnetwork.org is specified in [3GPP-TS-23.003].
全く設定さレルム名が使用できない場合、ピアは、IMSIのMCCとMNC部分からレルム名を導き出すことができます。レルム3gppnetwork.orgを用いてIMSIからレルムを導出する推奨される方法は、[3GPP-TS-23.003]で指定されています。
Some old implementations derive the realm name from the IMSI by concatenating "mnc", the MNC digits of IMSI, ".mcc", the MCC digits of IMSI, and ".owlan.org". For example, if the IMSI is 123456789098765, and the MNC is three digits long, then the derived realm name is "mnc456.mcc123.owlan.org". As there are no DNS servers running at owlan.org, these realm names can only be used with manually configured AAA routing. New implementations SHOULD use the mechanism specified in [3GPP-TS-23.003] instead of owlan.org.
いくつかの古い実装では、「MNC」、IMSIのMNCケタ、「.mcc」、IMSIのMCCの数字、「.owlan.org」を連結することにより、IMSIからレルム名を導き出します。例えば、IMSI場合123456789098765で、MNCは、派生レルム名は「mnc456.mcc123.owlan.org」で、3桁の長さです。 owlan.orgで実行中のDNSサーバが存在しないように、これらのレルム名は手動でのみ設定されたAAAルーティングで使用することができます。新しい実装ではなくowlan.orgの[3GPP-TS-23.003]で指定されたメカニズムを使用すべきです。
The IMSI is a string of digits without any explicit structure, so the peer may not be able to determine the length of the MNC portion. If the peer is not able to determine whether the MNC is two or three digits long, the peer MAY use a 3-digit MNC. If the correct length of the MNC is two, then the MNC used in the realm name includes the first digit of the MSIN. Hence, when configuring AAA networks for operators that have 2-digit MNCs, the network SHOULD also be prepared for realm names with incorrect, 3-digit MNCs.
IMSIは、明示的な構造を持たない数字の文字列であるため、ピアはMNC部分の長さを決定することができないかもしれません。ピアは、MNCが2または3桁の長さであるかどうかを決定することができない場合、ピアは、3桁のMNCを使用するかもしれません。 MNCの正しい長さが2である場合、レルム名に使用MNCはMSINの最初の数字を含みます。 2桁のMNCを有する事業者のAAAネットワークを構成するときしたがって、ネットワークは、また、誤った、3桁のMNCとレルム名に準備されるべきです。
The non-pseudonym permanent username SHOULD be derived from the IMSI. In this case, the permanent username MUST be of the format "1" | IMSI, where the character "|" denotes concatenation. In other words, the first character of the username is the digit one (ASCII value 31 hexadecimal), followed by the IMSI. The IMSI is encoded as an ASCII string that consists of not more than 15 decimal digits (ASCII values between 30 and 39 hexadecimal), one character per IMSI digit, in the order specified in [GSM-03.03]. For example, a permanent username derived from the IMSI 295023820005424 would be encoded as the ASCII string "1295023820005424" (byte values in hexadecimal notation: 31 32 39 35 30 32 33 38 32 30 30 30 35 34 32 34).
非仮名永久ユーザー名はIMSIから導出されるべきです。この場合、永久的なユーザ名はフォーマット「1」である必要があります| IMSI、文字「|」連結を示しています。換言すれば、ユーザ名の最初の文字がIMSIに続く数字1（ASCII値31進数）です。 IMSIは、[GSM-03.03]で指定された順序で以下15桁（30と39進数の間のASCII値）、IMSI桁ごとに一つの文字から成るASCII文字列として符号化されます。例えば、IMSI 295023820005424由来する永久的なユーザ名がASCII文字列 "1295023820005424"（：31 32 39 35 30 32 33 38 32 30 30 30 35 34 32 34 16進数のバイト値）として符号化されるであろう。
The EAP server MAY use the leading "1" as a hint to try EAP-SIM as the first authentication method during method negotiation, rather than, for example EAP/AKA. The EAP-SIM server MAY propose EAP-SIM, even if the leading character was not "1".
EAPサーバは、EAP / AKA例えば、メソッドのネゴシエーションの間に第1の認証方式としてEAP-SIMを試してみてください、というよりもにつながる「1」のヒントを使用するかもしれません。 EAP-SIMサーバは、先頭の文字が「1」でなかった場合でも、EAP-SIMを提案することができます。
Alternatively, an implementation MAY choose a permanent username that is not based on the IMSI. In this case, the selection of the username, its format, and its processing is out of the scope of this document. In this case, the peer implementation MUST NOT prepend any leading characters to the username.
また、実装はIMSIに基づいていない永久的なユーザ名を選ぶかもしれません。この場合には、ユーザ名、そのフォーマット、およびその処理の選択は、この文書の範囲外です。この場合、ピアの実装では、ユーザー名の先頭の文字を付加してはなりません。
4.2.1.7. Generating Pseudonyms and Fast Re-authentication Identities by the Server
4.2.1.7。サーバーによって仮名と高速再認証アイデンティティの生成
Pseudonym usernames and fast re-authentication identities are generated by the EAP server. The EAP server produces pseudonym usernames and fast re-authentication identities in an implementation-dependent manner. Only the EAP server needs to be able to map the pseudonym username to the permanent identity, or to recognize a fast re-authentication identity.
匿名ユーザ名と速い再認証のアイデンティティはEAPサーバによって生成されます。 EAPサーバは実装依存的に匿名ユーザ名と速い再認証IDを生成します。唯一のEAPサーバが永久的なアイデンティティへの匿名ユーザ名をマッピングする、または速い再認証のアイデンティティを認識できるようにする必要があります。
EAP-SIM includes no provisions to ensure that the same EAP server that generated a pseudonym username will be used on the authentication exchange when the pseudonym username is used. It is recommended that the EAP servers implement some centralized mechanism to allow all EAP servers of the home operator to map pseudonyms generated by other severs to the permanent identity. If no such mechanism is available, then the EAP server failing to understand a pseudonym issued by another server can request the that peer send the permanent identity.
EAP-SIMは、匿名ユーザ名を使用する場合は匿名ユーザ名を生成し、同じEAPサーバが認証交換に使用されることを保証するために、何の条項が含まれていません。 EAPサーバがホームオペレータのすべてのEAPサーバが永久的なアイデンティティに他の切断によって生成された仮名をマッピングできるようにするために、いくつかの集中管理メカニズムを実装することをお勧めします。そのようなメカニズムが利用できない場合は、別のサーバによって発行された仮名を理解するために失敗EAPサーバが永久的なアイデンティティを送るピアように要求することができます。
When issuing a fast re-authentication identity, the EAP server may include a realm name in the identity to make the fast re-authentication request be forwarded to the same EAP server.
速い再認証IDを発行する場合、EAPサーバが速い再認証要求が同じEAPサーバに転送させるためにアイデンティティでレルム名を含むことができます。
When generating fast re-authentication identities, the server SHOULD choose a fresh, new fast re-authentication identity that is different from the previous ones that were used after the same full authentication exchange. A full authentication exchange and the associated fast re-authentication exchanges are referred to here as the same "full authentication context". The fast re-authentication identity SHOULD include a random component. This random component works as a full authentication context identifier. A context-specific fast re-authentication identity can help the server to detect whether its fast re-authentication state information matches that of its peer (in other words, whether the state information is from the same full authentication exchange). The random component also makes the fast re-authentication identities unpredictable, so an attacker cannot initiate a fast re-authentication exchange to get the server's EAP-Request/SIM/ Re-authentication packet.
速い再認証IDを生成するとき、サーバは同じ完全な認証交換の後に使用された前のものと異なっている新鮮な、新しい高速再認証アイデンティティを選択する必要があります。完全な認証交換と関連した高速再認証交換は、ここで同じ「完全な認証コンテキスト」と呼ばれています。速い再認証のアイデンティティは、ランダム成分を含むべきです。このランダム成分は完全な認証コンテキスト識別子として機能します。コンテキスト固有の高速再認証アイデンティティは、その速い再認証状態情報（状態情報が同じ完全な認証交換からのものであるか否か、換言すれば）そのピアのものと一致するか否かを検出するためのサーバを助けることができます。ランダム成分はまた、攻撃者は、サーバのEAP要求/ SIM /再認証パケットを取得するために、高速再認証交換を開始することができない、予測不可能な高速再認証アイデンティティになります。
Transmitting pseudonyms and fast re-authentication identities from the server to the peer is discussed in Section 4.2.1.8. The pseudonym is transmitted as a username, without an NAI realm, and the fast re-authentication identity is transmitted as a complete NAI, including a realm portion if a realm is required. The realm is included in the fast re-authentication identity to allow the server to include a server-specific realm.
サーバーからのピアに仮名と速い再認証のアイデンティティを送信することは、セクション4.2.1.8で説明されています。偽名は、NAIのレルムなしに、ユーザ名として送信され、高速再認証アイデンティティはレルムが必要な場合レルム部分を含む、完全なNAIとして送信されます。レルムは、サーバがサーバ固有のレルムを含めることができるように、高速再認証アイデンティティーに含まれています。
Regardless of the construction method, the pseudonym username MUST conform to the grammar specified for the username portion of an NAI. The fast re-authentication identity also MUST conform to the NAI grammar. The EAP servers that the subscribers of an operator can use MUST ensure that the pseudonym usernames and the username portions used in fast re-authentication identities they generate are unique.
かかわらず、施工方法の、匿名ユーザ名はNAIのユーザ名部分に指定された文法に従わなければなりません。高速再認証アイデンティティもNAI文法に従わなければなりません。オペレータの加入者が使用できるEAPサーバは、生成匿名ユーザ名と速い再認証のアイデンティティに使用するユーザ名部分が一意であることを保証しなければなりません。
In any case, it is necessary that permanent usernames, pseudonym usernames, and fast re-authentication usernames are separate and recognizable from each other. It is also desirable that EAP-SIM and EAP-AKA [EAP-AKA] usernames be distinguishable from each other as an aid for the server on which method to offer.
いずれの場合においても、永久的なユーザ名、匿名ユーザ名、および速い再認証ユーザ名が互いから分離して認識可能であることが必要です。 EAP-SIMおよびEAP-AKA [EAP-AKA]ユーザ名を提供する方法でサーバのための助剤として、互いに区別可能であることも望ましいです。
In general, it is the task of the EAP server and the policies of its administrator to ensure sufficient separation of the usernames. Pseudonym usernames and fast re-authentication usernames are both produced and used by the EAP server. The EAP server MUST compose pseudonym usernames and fast re-authentication usernames so that it can determine if an NAI username is an EAP-SIM pseudonym username or an EAP-SIM fast re-authentication username. For instance, when the usernames have been derived from the IMSI, the server could use different leading characters in the pseudonym usernames and fast re-authentication usernames (e.g., the pseudonym could begin with a leading "3" character). When mapping a fast re-authentication identity to a permanent identity, the server SHOULD only examine the username portion of the fast re-authentication identity and ignore the realm portion of the identity.
一般的には、ユーザ名の十分な分離を確保するために、EAPサーバとその管理者の政策の課題です。匿名ユーザ名と速い再認証ユーザ名は、両方の生産とEAPサーバによって使用されています。それはNAIのユーザ名は、EAP-SIMの匿名ユーザ名またはEAP-SIM高速再認証ユーザ名であるかどうかを判断できるように、EAPサーバは、匿名ユーザ名と速い再認証のユーザー名を構成しなければなりません。ユーザ名は、IMSIから導出された場合例えば、サーバは匿名ユーザ名と速い再認証のユーザー名で別の主要な文字を使用することができます（例えば、仮名は先頭の「3」の文字で始めることができます）。永久的なアイデンティティへの速い再認証のアイデンティティをマッピングする場合、サーバーは高速再認証アイデンティティのユーザ名部分を調べ、アイデンティティの分野の部分を無視する必要があります。
Because the peer may fail to save a pseudonym username sent in an EAP-Request/SIM/Challenge, for example due to malfunction, the EAP server SHOULD maintain at least the most recently used pseudonym username in addition to the most recently issued pseudonym username. If the authentication exchange is not completed successfully, then the server SHOULD NOT overwrite the pseudonym username that was issued during the most recent successful authentication exchange.
ピアは、EAP要求/ SIM /挑戦に送られた匿名ユーザ名を保存するために失敗することがありますので、例えば誤動作に、EAPサーバは最も最近発行された匿名ユーザ名に加えて、少なくとも最近使用匿名ユーザ名を維持する必要があります。認証交換が正常に完了していない場合、サーバーは、最新の成功した認証交換の際に発行された匿名ユーザ名を上書きすべきではありません。
4.2.1.8. Transmitting Pseudonyms and Fast Re-authentication Identities to the Peer
4.2.1.8。ピアに仮名と高速再認証アイデンティティを送信
The server transmits pseudonym usernames and fast re-authentication identities to the peer in cipher, using the AT_ENCR_DATA attribute.
サーバーは、AT_ENCR_DATA属性を使用して、暗号でピアに匿名ユーザ名と速い再認証のアイデンティティを送信します。
The EAP-Request/SIM/Challenge message MAY include an encrypted pseudonym username and/or an encrypted fast re-authentication identity in the value field of the AT_ENCR_DATA attribute. Because identity privacy support and fast re-authentication are optional implementations, the peer MAY ignore the AT_ENCR_DATA attribute and always use the permanent identity. On fast re-authentication (discussed in Section 5), the server MAY include a new, encrypted fast re-authentication identity in the EAP-Request/SIM/Re-authentication message.
EAP要求/ SIM /挑戦メッセージはAT_ENCR_DATA属性の値フィールドに暗号化された匿名ユーザ名および/または暗号化された高速再認証アイデンティティを含むかもしれません。アイデンティティプライバシーサポートと速い再認証はオプションで実装されているので、ピアはAT_ENCR_DATA属性を無視して、常に永久的なアイデンティティを使用するかもしれません。 （第5節で説明）高速再認証では、サーバがEAP要求/ SIM /再認証メッセージで新しい、暗号化された高速再認証アイデンティティを含むかもしれません。
On receipt of the EAP-Request/SIM/Challenge, the peer MAY decrypt the encrypted data in AT_ENCR_DATA. If the authentication exchange is successful, and the encrypted data includes a pseudonym username, then the peer may use the obtained pseudonym username on the next full authentication. If a fast re-authentication identity is included, then the peer MAY save it together with other fast re-authentication state information, as discussed in Section 5, for the next fast re-authentication. If the authentication exchange does not complete successfully, the peer MUST ignore the received pseudonym username and the fast re-authentication identity.
EAP要求/ SIM /挑戦を受け取り次第、ピアはAT_ENCR_DATAで暗号化されたデータを復号化するかもしれません。認証交換が成功すると、暗号化されたデータは匿名ユーザ名が含まれている場合、ピアは、次の完全な認証で得た匿名ユーザ名を使用することができます。速い再認証のアイデンティティが含まれている場合は、次の速い再認証のために、第5節で述べたように、ピアは、他の高速再認証状態情報と一緒に保存することができます。認証交換が正常に完了しない場合、ピアは受信匿名ユーザ名と速い再認証のアイデンティティを無視しなければなりません。
If the peer does not receive a new pseudonym username in the EAP-Request/SIM/Challenge message, the peer MAY use an old pseudonym username instead of the permanent username on the next full authentication. The username portions of fast re-authentication identities are one-time usernames, which the peer MUST NOT re-use. When the peer uses a fast re-authentication identity in an EAP exchange, the peer MUST discard the fast re-authentication identity and not re-use it in another EAP authentication exchange, even if the authentication exchange was not completed.
ピアは、EAP要求/ SIM /挑戦メッセージの新しい匿名ユーザ名を受信しない場合、ピアは、次の完全な認証に永久的なユーザ名の代わりに古い匿名ユーザ名を使用するかもしれません。高速再認証アイデンティティのユーザ名部分は、ピアが再利用してはならない1回限りのユーザー名、です。ピアは、EAP交換で速い再認証のアイデンティティを使用する場合、ピアは認証交換が完了しなかった場合でも、それは別のEAP認証交換で再使用しないで速い再認証のアイデンティティを破棄しなければなりません。
When the optional identity privacy support is used on full authentication, the peer MAY use a pseudonym username received as part of a previous full authentication sequence as the username portion of the NAI. The peer MUST NOT modify the pseudonym username received in AT_NEXT_PSEUDONYM. However, as discussed above, the peer MAY need to decorate the username in some environments by appending or prepending the username with a string that indicates supplementary AAA routing information.
オプションのアイデンティティプライバシーサポートが完全な認証に使用されている場合、ピアは、NAIのユーザ名部分として、前の完全な認証系列の一部として受け取った匿名ユーザ名を使用するかもしれません。ピアはAT_NEXT_PSEUDONYMで受け取った匿名ユーザ名を変更してはいけません。しかしながら、上述したように、ピアは、ルーティング情報を補足AAAを示す文字列でユーザー名を追加または付加することで、いくつかの環境ではユーザ名を飾るために必要があるかもしれません。
When using a pseudonym username in an environment where a realm portion is used, the peer concatenates the received pseudonym username with the "@" character and an NAI realm portion. The selection of the NAI realm is discussed above. The peer can select the realm portion similarly, regardless of whether it uses the permanent username or a pseudonym username.
分野の部分が使用されている環境で、匿名ユーザ名を使用している場合、ピアは、「@」文字とNAI分野の部分で受信匿名ユーザ名を連結します。 NAIのレルムの選択は、上述されています。ピアは関係なく、それが永久的なユーザ名または匿名ユーザ名を使用するかどうかの、同様分野の部分を選択することができます。
On fast re-authentication, the peer uses the fast re-authentication identity that was received as part of the previous authentication sequence. A new re-authentication identity may be delivered as part of both full authentication and fast re-authentication. The peer MUST NOT modify the username part of the fast re-authentication identity received in AT_NEXT_REAUTH_ID, except in cases when username decoration is required. Even in these cases, the "root" fast re-authentication username must not be modified, but it may be appended or prepended with another string.
速い再認証に、ピアは以前の認証シーケンスの一部として受信された高速再認証アイデンティティを使用します。新しい再認証アイデンティティは完全な認証と速い再認証の両方の一部として提供することができます。ピアは、ユーザ名デコレーションが必要な場合を除いて、AT_ネクスト_REAUTH_IDで受信速い再認証のアイデンティティのユーザ名部分を変更してはいけません。これらの場合であっても、「ルート」高速再認証のユーザー名は変更してはならないが、それは別の文字列を付加または先頭に追加することができます。
The peer identity MAY be communicated to the server with the EAP-Response/Identity message. This message MAY contain the permanent identity, a pseudonym identity, or a fast re-authentication identity. If the peer uses the permanent identity or a pseudonym identity, which the server is able to map to the permanent identity, then the authentication proceeds as discussed in the overview of Section 3. If the peer uses a fast re-authentication identity, and if the fast re-authentication identity matches with a valid fast re-authentication identity maintained by the server, and if the server agrees to use fast re-authentication, then a fast re-authentication exchange is performed, as described in Section 5.
ピアのアイデンティティはEAP-Response / Identityメッセージをサーバーに通信することができます。このメッセージは永久的なアイデンティティ、匿名のアイデンティティ、または速い再認証のアイデンティティを含むかもしれません。ピアは、ピアが速い再認証IDを使用している場合、セクション3の概要で説明したように、サーバは、次に、永久的なアイデンティティを認証進行をマッピングすることができる永久的な同一性または匿名のアイデンティティを使用し、もしあれば高速再認証アイデンティティは、サーバによって維持有効な速い再認証のアイデンティティと一致し、サーバが速い再認証を使用することに同意する場合は、セクション5で説明したように、その後、高速再認証交換が行われます。
The peer identity can also be transmitted from the peer to the server using EAP-SIM messages instead of the EAP-Response/Identity. In this case, the server includes an identity-requesting attribute (AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the EAP-Request/SIM/Start message, and the peer includes the AT_IDENTITY attribute, which contains the peer's identity, in the EAP-Response/SIM/Start message. The AT_ANY_ID_REQ attribute is a general identity-requesting attribute, which the server uses if it does not specify which kind of an identity the peer should return in AT_IDENTITY. The server uses the AT_FULLAUTH_ID_REQ attribute to request either the permanent identity or a pseudonym identity. The server uses the AT_PERMANENT_ID_REQ attribute to request that the peer send its permanent identity.
ピアのアイデンティティはまた、代わりにEAP応答/アイデンティティのEAP-SIMメッセージを使用してサーバーにピアから送信することができます。この場合、サーバがEAP要求/ SIM / Startメッセージにおけるアイデンティティ要求属性（_どんなAT__ID REQ、AT_FULLAUTH_ID_REQまたはAT_PERMANENT_ID_REQ）を含み、ピアは/ EAP-応答では、ピアのアイデンティティを含んでAT_IDENTITY属性を含み、 SIM / Startメッセージ。 _どんなAT__ID REQ属性は、ピアがAT_IDENTITYに戻す必要がありますアイデンティティのどの種類を指定しない場合は、サーバーが使用する一般的なアイデンティティを要求属性、です。サーバが永久的なアイデンティティか匿名のアイデンティティのどちらかを要求するAT_FULLAUTH_ID_REQ属性を使用しています。サーバは、同輩が永久的なアイデンティティを送るように要求するAT_PERMANENT_ID_REQ属性を使用しています。
The identity format in the AT_IDENTITY attribute is the same as in the EAP-Response/Identity packet (except that identity decoration is not allowed). The AT_IDENTITY attribute contains a permanent identity, a pseudonym identity, or a fast re-authentication identity.
AT_IDENTITY属性におけるアイデンティティ形式は（許可されていないというアイデンティティの装飾を除く）EAP応答/アイデンティティパケットの場合と同じです。 AT_IDENTITY属性が永久的なアイデンティティ、匿名のアイデンティティ、または速い再認証のアイデンティティを含んでいます。
Please note that the EAP-SIM peer and the EAP-SIM server only process the AT_IDENTITY attribute; entities that only pass through EAP packets do not process this attribute. Hence, the authenticator and other intermediate AAA elements (such as possible AAA proxy servers) will continue to refer to the peer with the original identity from the EAP-Response/Identity packet unless the identity authenticated in the AT_IDENTITY attribute is communicated to them in another way within the AAA protocol.
EAP-SIMのピアとEAP-SIMサーバが唯一のAT_IDENTITY属性を処理することに注意してください。唯一のEAPパケットを通過実体は、この属性を処理しません。 AT_IDENTITY属性に認証されたアイデンティティが別のそれらに伝達される場合を除きしたがって、オーセンティケータと（このような可能なAAAプロキシサーバなど）他の中間AAA要素はEAP応答/アイデンティティパケットから元のアイデンティティにピアを参照し続けますAAAプロトコル内の方法。
The EAP-Response/Identity packet is not method-specific, so in many implementations it may be handled by an EAP Framework. This introduces an additional layer of processing between the EAP peer and EAP server. The extra layer of processing may cache identity responses or add decorations to the identity. A modification of the identity response will cause the EAP peer and EAP server to use different identities in the key derivation, which will cause the protocol to fail.
EAP応答/アイデンティティパケットはメソッド固有ではないので、多くの実装では、EAPフレームワークによって処理されてもよいです。これは、EAPピアとEAPサーバ間の処理の追加の層を導入します。処理の追加の層は、身元応答をキャッシュやアイデンティティに装飾を追加することができます。アイデンティティ応答の修正は、EAPピアとEAPサーバは、プロトコルが失敗する原因になりますキー導出に異なるIDを使用するようになります。
For this reason, it is RECOMMENDED that the EAP peer and server use the method-specific identity attributes in EAP-SIM, and the server is strongly discouraged from relying upon the EAP-Response/Identity.
このため、EAPピアとサーバはメソッド固有のアイデンティティはEAP-SIMで属性を使用し、サーバーが強くEAP応答/アイデンティティに依存するからがっかりすることをお勧めします。
In particular, if the EAP server receives a decorated identity in EAP-Response/Identity, then the EAP server MUST use the identity-requesting attributes to request that the peer send an unmodified and undecorated copy of the identity in AT_IDENTITY.
EAPサーバは、EAP応答/アイデンティティで装飾されたアイデンティティを受信した場合、特に、その後、EAPサーバは、ピアがAT_IDENTITYでアイデンティティの変更されていないと装飾されていないコピーを送信することを要求するためにアイデンティティを要求する属性を使用しなければなりません。
If EAP-SIM peer is started upon receiving an EAP-Request/Identity message, then the peer MAY use an EAP-SIM identity in the EAP-Response/Identity packet. In this case, the peer performs the following steps.
EAP-SIM同輩がEAP-Request / Identityメッセージを受信したときに開始された場合、ピアはEAP応答/アイデンティティパケットでEAP-SIMのアイデンティティを使用するかもしれません。この場合、ピアは、以下のステップを実行します。
If the peer has maintained fast re-authentication state information and wants to use fast re-authentication, then the peer transmits the fast re-authentication identity in EAP-Response/Identity.
ピアが速い再認証の状態情報を維持し、高速再認証を使用したいしている場合、ピアはEAP応答/アイデンティティにおける速い再認証のアイデンティティを送信します。
Else, if the peer has a pseudonym username available, then the peer transmits the pseudonym identity in EAP-Response/Identity.
同輩に利用可能な匿名ユーザ名を持っている場合はそうでなければ、その後、ピアはEAP応答/アイデンティティにおける匿名のアイデンティティを送信します。
In other cases, the peer transmits the permanent identity in EAP-Response/Identity.
他の場合には、ピアはEAP応答/アイデンティティにおける永久的なアイデンティティを送信します。
As discussed in Section 4.2.2.2, the server SHOULD NOT rely on an identity string received in EAP-Response/Identity. Therefore, the RECOMMENDED way to start an EAP-SIM exchange is to ignore any received identity strings. The server SHOULD begin the EAP-SIM exchange by issuing the EAP-Request/SIM/Start packet with an identity-requesting attribute to indicate that the server wants the peer to include an identity in the AT_IDENTITY attribute of the EAP-Response/SIM/Start message. Three methods to request an identity from the peer are discussed below.
セクション4.2.2.2で説明したように、サーバは、EAP応答/アイデンティティで受信した識別文字列に依存すべきではありません。したがって、EAP-SIM交換を開始することをお勧めの方法は、任意のアイデンティティ文字列を受け取っ無視することです。サーバは、サーバは、ピアはEAP応答/ SIMのAT_IDENTITY属性にアイデンティティを含めたいことを示すためにアイデンティティを要求属性でEAP要求/ SIM /スタートパケットを発行することにより、EAP-SIMの交換を開始する必要があります/メッセージを開始します。ピアからのアイデンティティを要求する3つの方法が、以下に説明されています。
If the server chooses not to ignore the contents of EAP-Response/Identity, then the server may have already received an EAP-SIM identity in this packet. However, if the EAP server has not received any EAP-SIM peer identity (permanent identity, pseudonym identity, or fast re-authentication identity) from the peer when sending the first EAP-SIM request, or if the EAP server has received an EAP-Response/Identity packet but the contents do not appear to be a valid permanent identity, pseudonym identity or a re-authentication identity, then the server MUST request an identity from the peer using one of the methods below.
サーバがEAP応答/アイデンティティの内容を無視しないことを選択した場合、サーバはすでにこのパケットにEAP-SIMのアイデンティティを受けている可能性があります。しかしながら、EAPサーバはEAP受信した場合、最初のEAP-SIM要求を送信する場合、またはEAPサーバはピアから任意のEAP-SIMピアアイデンティティ（永久的なアイデンティティ、匿名のアイデンティティ、または速い再認証ID）を受信していない場合-response /アイデンティティパケットが、内容は、サーバは以下のいずれかの方法を使用してピアからのアイデンティティを要求しなければなりません、有効な永久的なアイデンティティ、匿名のアイデンティティや再認証のアイデンティティであることが表示されません。
The server sends the EAP-Request/SIM/Start message with the AT_PERMANENT_ID_REQ attribute to indicate that the server wants the peer to include the permanent identity in the AT_IDENTITY attribute of the EAP-Response/SIM/Start message. This is done in the following cases:
サーバがEAP要求/ SIM /サーバは、ピアは、EAP応答/ SIM /開始メッセージのAT_IDENTITY属性で永久的なアイデンティティを含めたいことを示すためにAT_PERMANENT_ID_REQ属性でメッセージを起動し送信します。これは、次の場合に行われます。
o The server does not support fast re-authentication or identity privacy.
Oサーバが速い再認証やアイデンティティプライバシーをサポートしていません。
o The server decided to process a received identity, and the server recognizes the received identity as a pseudonym identity but the server is not able to map the pseudonym identity to a permanent identity.
Oサーバは、受信したアイデンティティを処理することを決定し、サーバは匿名IDとして受信アイデンティティを認識するが、サーバが永久的なアイデンティティに匿名IDをマッピングすることができません。
The server issues the EAP-Request/SIM/Start packet with the AT_FULLAUTH_ID_REQ attribute to indicate that the server wants the peer to include a full authentication identity (pseudonym identity or permanent identity) in the AT_IDENTITY attribute of the EAP-Response/SIM/Start message. This is done in the following cases:
サーバは、サーバは、ピアはEAP応答/ SIM /スタートのAT_IDENTITY属性に完全な認証のアイデンティティ（匿名のアイデンティティまたは永久的なアイデンティティ）を含むように望んでいることを示すために、AT_FULLAUTH_ID_REQ属性でEAP要求/ SIM /スタートパケットを発行しますメッセージ。これは、次の場合に行われます。
o The server does not support fast re-authentication and the server supports identity privacy.
Oサーバが速い再認証をサポートしていないと、サーバはアイデンティティプライバシーをサポートしています。
o The server decided to process a received identity, and the server recognizes the received identity as a re-authentication identity but the server is not able to map the re-authentication identity to a permanent identity.
Oサーバは、受信したアイデンティティを処理することを決定し、サーバは再認証IDとして受信アイデンティティを認識するが、サーバが永久的なアイデンティティに再認証アイデンティティをマッピングすることができません。
The server issues the EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ attribute to indicate that the server wants the peer to include an identity in the AT_IDENTITY attribute of the EAP-Response/SIM/Start message, and the server does not indicate any preferred type for the identity. This is done in other cases, such as when the server ignores a received EAP-Response/Identity, the server does not have any identity, or the server does not recognize the format of a received identity.
サーバは、サーバがEAP応答/ SIM / Startメッセージ、およびサーバーのAT_IDENTITY属性にアイデンティティを含めるピアがいずれかを示すものではありません望んでいることを示すために_どんなAT__ID REQ属性でEAP要求/ SIM /スタートパケットを発行しますアイデンティティのための好ましい種類。これは、サーバが受信したEAP応答/アイデンティティを無視するとき、サーバは任意のIDを持っていない、またはサーバーが受信した識別の形式を認識しないなど、他の例で行われています。
Upon receipt of an EAP-Request/SIM/Start message, the peer MUST perform the following steps.
EAPリクエスト/ SIM /開始メッセージを受信すると、ピアは、以下のステップを実行する必要があります。
If the EAP-Request/SIM/Start does not include an identity request attribute, then the peer responds with EAP-Response/SIM/Start without AT_IDENTITY. The peer includes the AT_SELECTED_VERSION and AT_NONCE_MT attributes, because the exchange is a full authentication exchange.
EAP要求/ SIM / Startがアイデンティティ要求属性が含まれていない場合は、ピアはAT_IDENTITYなし/スタートEAP応答/ SIMで応答します。交換が完全な認証交換であるため、ピアは、AT_SELECTED_バージョンとAT_NONCE_MT属性を含みます。
If the EAP-Request/SIM/Start includes AT_PERMANENT_ID_REQ, and if the peer does not have a pseudonym available, then the peer MUST respond with EAP-Response/SIM/Start and include the permanent identity in
EAP要求/ SIM /スタートAT_PERMANENT_ID_REQを含み、ピアが利用可能な匿名を持っていない場合、ピアはEAP応答/ SIM /スタートで応答し、中に永久的なアイデンティティを含まなければならない場合
AT_IDENTITY. If the peer has a pseudonym available, then the peer MAY refuse to send the permanent identity; hence, in this case the peer MUST either respond with EAP-Response/SIM/Start and include the permanent identity in AT_IDENTITY or respond with EAP-Response/SIM/ Client-Error packet with the code "unable to process packet".
AT_IDENTITY。ピアが利用可能な匿名を持っている場合、ピアは、永久的なアイデンティティを送信するために拒否することができます。したがって、この場合には、ピアは、いずれかのEAP応答/ SIM /スタートで応答し、AT_IDENTITYで永久的なアイデンティティを含めるか、「パケットを処理できません」のコードとEAP応答/ SIM /クライアント誤りパケットで応じなければなりません。
If the EAP-Request/SIM/Start includes AT_FULL_AUTH_ID_REQ, and if the peer has a pseudonym available, then the peer SHOULD respond with EAP-Response/SIM/Start and include the pseudonym identity in AT_IDENTITY. If the peer does not have a pseudonym when it receives this message, then the peer MUST respond with EAP-Response/SIM/Start and include the permanent identity in AT_IDENTITY. The Peer MUST NOT use a re-authentication identity in the AT_IDENTITY attribute.
EAP-要求した場合/ SIM /スタートはAT_FULL_AUTH_ID_REQを含み、ピアが利用可能な匿名を持っている場合、ピアはEAP応答/ SIM /スタートで応答し、AT_IDENTITYで匿名のアイデンティティを含むべきです。ピアが仮名を持っていない場合は、このメッセージを受信したとき、ピアはEAP応答/ SIM /スタートで応答し、AT_IDENTITYで永久的なアイデンティティを含まなければなりません。ピアはAT_IDENTITY属性に再認証のアイデンティティを使用してはなりません。
If the EAP-Request/SIM/Start includes AT_ANY_ID_REQ, and if the peer has maintained fast re-authentication state information and the peer wants to use fast re-authentication, then the peer responds with EAP-Response/SIM/Start and includes the fast re-authentication identity in AT_IDENTITY. Else, if the peer has a pseudonym identity available, then the peer responds with EAP-Response/SIM/Start and includes the pseudonym identity in AT_IDENTITY. Else, the peer responds with EAP-Response/SIM/Start and includes the permanent identity in AT_IDENTITY.
EAP要求/ SIM /スタートは_どんなAT__ID REQを含み、ピアが速い再認証の状態情報を維持しているし、ピアが速い再認証を使用したい場合、ピアはEAP応答/ SIM /スタートで応答し、含まれている場合場合AT_IDENTITYで速い再認証のアイデンティティ。同輩に利用可能な匿名のアイデンティティを持っている場合はそうでなければ、その後、ピアはEAP応答/ SIM /スタートで応答し、AT_IDENTITYで匿名のアイデンティティを含んでいます。そうでなければ、ピアはEAP応答/ SIM /スタートで応答し、AT_IDENTITYで永久的なアイデンティティを含んでいます。
An EAP-SIM exchange may include several EAP/SIM/Start rounds. The server may issue a second EAP-Request/SIM/Start if it was not able to recognize the identity that the peer used in the previous AT_IDENTITY attribute. At most, three EAP/SIM/Start rounds can be used, so the peer MUST NOT respond to more than three EAP-Request/SIM/Start messages within an EAP exchange. The peer MUST verify that the sequence of EAP-Request/SIM/Start packets that the peer receives comply with the sequencing rules defined in this document. That is, AT_ANY_ID_REQ can only be used in the first EAP-Request/SIM/Start; in other words, AT_ANY_ID_REQ MUST NOT be used in the second or third EAP-Request/SIM/Start. AT_FULLAUTH_ID_REQ MUST NOT be used if the previous EAP-Request/SIM/Start included AT_PERMANENT_ID_REQ. The peer operation, in cases when it receives an unexpected attribute or an unexpected message, is specified in Section 6.3.1.
EAP-SIM交換は、いくつかのEAP / SIM /スタートラウンドを含むことができます。相手が前のAT_IDENTITY属性に使用するIDを認識することができなかった場合、サーバは、第二のEAP要求/ SIM /スタートを発行することができます。せいぜい、EAP / SIM / Startは丸め3を使用することができますので、ピアはEAP交換の中つ以上のEAP要求/ SIM /開始メッセージに応じてはいけません。ピアは、ピアがこの文書で定義されたシーケンシング規則を遵守する受信EAP要求/ SIM / Startパケットのシーケンスいることを確かめなければなりません。すなわち、_どんなAT__ID REQは、最初のEAP-Requestに使用することができ、ある/ SIM /スタート。換言すれば、_どんなAT__ID REQは、第二又は第三のEAPリクエスト/ SIM /開始に使用してはいけません。前のEAP要求/ SIM /スタートAT_PERMANENT_ID_REQが含まれている場合AT_FULLAUTH_ID_REQを使用してはいけません。ピア動作は、それは予期しない属性または予期しないメッセージを受信した場合には、セクション6.3.1で指定されています。
The section above specifies two possible ways the peer can operate upon receipt of AT_PERMANENT_ID_REQ. This is because a received AT_PERMANENT_ID_REQ does not necessarily originate from the valid network, but an active attacker may transmit an EAP-Request/SIM/ Start packet with an AT_PERMANENT_ID_REQ attribute to the peer, in an effort to find out the true identity of the user. If the peer does not want to reveal its permanent identity, then the peer sends the
上記セクションは、ピアがAT_PERMANENT_ID_REQを受けて動作することができる2つの可能な方法を特定します。受信AT_PERMANENT_ID_REQは必ずしも有効なネットワークから発信しませんが、アクティブな攻撃者は、ユーザーの本当のアイデンティティを見つけるための努力で、ピアにAT_PERMANENT_ID_REQ属性でEAP要求/ SIM /スタートパケットを送信することができるからです。同輩が永久的なアイデンティティを明らかにしたくない場合には、ピアが送信します
EAP-Response/SIM/Client-Error packet with the error code "unable to process packet", and the authentication exchange terminates.
エラーコードとEAP応答/ SIM /クライアント・エラー・パケットは、「パケットを処理できない」、および認証交換が終了します。
Basically, there are two different policies that the peer can employ with regard to AT_PERMANENT_ID_REQ. A "conservative" peer assumes that the network is able to maintain pseudonyms robustly. Therefore, if a conservative peer has a pseudonym username, the peer responds with EAP-Response/SIM/Client-Error to the EAP packet with AT_PERMANENT_ID_REQ, because the peer believes that the valid network is able to map the pseudonym identity to the peer's permanent identity. (Alternatively, the conservative peer may accept AT_PERMANENT_ID_REQ in certain circumstances, for example, if the pseudonym was received a long time ago.) The benefit of this policy is that it protects the peer against active attacks on anonymity. On the other hand, a "liberal" peer always accepts the AT_PERMANENT_ID_REQ and responds with the permanent identity. The benefit of this policy is that it works even if the valid network sometimes loses pseudonyms and is not able to map them to the permanent identity.
基本的には、ピアはAT_PERMANENT_ID_REQに関して採用することができる2つの異なるポリシーがあります。 「保守的な」ピアは、ネットワークがロバスト匿名性を維持することが可能であることを前提としています。保守的なピアが匿名ユーザ名を持っている場合、ピアは、有効なネットワークがピアの恒久的に匿名のアイデンティティをマッピングすることが可能であると考えているので、したがって、ピアは、AT_PERMANENT_ID_REQでEAPパケットをEAP応答/ SIM /クライアントエラーで応答し身元。 （仮名は長い時間前に受信された場合あるいは、保守的なピアが、例えば、特定の状況においてAT_PERMANENT_ID_REQを受け入れることができる。）このポリシーの利点は、匿名でアクティブ攻撃に対するピアを保護することです。一方、「リベラル」ピアは常にAT_PERMANENT_ID_REQを受け入れて、永久的なアイデンティティで応答します。このポリシーの利点は、それが有効なネットワークが時々匿名を失い、永久的なアイデンティティにマップすることができない場合でも動作することです。
When the server receives an EAP-Response/SIM/Start message with the AT_IDENTITY (in response to the server's identity requesting attribute), the server MUST operate as follows.
サーバーが（サーバーのID要求の属性に応じて）AT_IDENTITYとEAP応答/ SIM / Startメッセージを受信すると、以下のように、サーバが動作しなければなりません。
If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does not contain a valid permanent identity, then the server sends EAP-Request/SIM/Notification with AT_NOTIFICATION code "General failure" (16384), and the EAP exchange terminates. If the server recognizes the permanent identity and is able to continue, then the server proceeds with full authentication by sending EAP-Request/SIM/ Challenge.
サーバーはAT_PERMANENT_ID_REQを使用した場合、およびAT_IDENTITYが有効な永久的なアイデンティティを含んでいない場合、サーバはAT_NOTIFICATIONコード「一般失敗」（16384）でEAP要求/ SIM /通知を送信し、EAP交換が終了します。サーバが永久的なアイデンティティを認識し続けることができるなら、サーバはEAP要求/ SIM /挑戦を送信することにより、完全な認証を進めます。
If the server used AT_FULLAUTH_ID_REQ, and if AT_IDENTITY contains a valid permanent identity or a pseudonym identity that the server can map to a valid permanent identity, then the server proceeds with full authentication by sending EAP-Request/SIM/Challenge. If AT_IDENTITY contains a pseudonym identity that the server is not able to map to a valid permanent identity, or an identity that the server is not able to recognize or classify, then the server sends EAP-Request/SIM/Start with AT_PERMANENT_ID_REQ.
サーバがAT_FULLAUTH_ID_REQを使用し、場合AT_IDENTITYが有効な永久的なアイデンティティやサーバがEAP要求/ SIM /挑戦を送信することにより、その後、有効な永久的なアイデンティティに完全な認証を使用してサーバーに進行をマッピングすることができます匿名のアイデンティティが含まれている場合。 AT_IDENTITYがサーバが有効な永久的なアイデンティティ、またはサーバーが認識または分類することができないことをアイデンティティーにマップすることはできないことを匿名のアイデンティティが含まれている場合、サーバはAT_PERMANENT_ID_REQにEAP要求/ SIM /スタートを送信します。
If the server used AT_ANY_ID_REQ, and if the AT_IDENTITY contains a valid permanent identity or a pseudonym identity that the server can map to a valid permanent identity, then the server proceeds with full authentication by sending EAP-Request/SIM/Challenge.
サーバが_どんなAT__ID REQも使用し、AT_IDENTITYがサーバがEAP要求/ SIM /挑戦を送信することにより、有効な永久的なアイデンティティに完全な認証と、サーバーが進行をマッピングすることができ、有効な永久的なアイデンティティか匿名のアイデンティティが含まれている場合。
If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid fast re-authentication identity and the server agrees on using re-authentication, then the server proceeds with fast re-authentication by sending EAP-Request/SIM/Re-authentication (Section 5).
サーバが_どんなAT__ID REQを使用し、場合AT_IDENTITYが有効な速い再認証のアイデンティティを含んでいると、サーバーは再認証を使用することに同意した場合、その後、EAP要求/ SIMは/再認証を送信することにより、高速な再認証を使用して、サーバー移行する（第5節）。
If the server used AT_ANY_ID_REQ, and if the peer sent an EAP-Response/SIM/Start with only AT_IDENTITY (indicating re-authentication), but the server is not able to map the identity to a permanent identity, then the server sends EAP-Request/SIM/Start with AT_FULLAUTH_ID_REQ.
サーバが_どんなAT__ID REQも使用し、ピアが（再認証を示す）のみAT_IDENTITYでEAP応答/ SIM /スタートを送ったが、サーバーが永久的なアイデンティティへのアイデンティティをマッピングすることはできません、そして、サーバはEAP-を送信した場合要求/ AT_FULLAUTH_ID_REQとSIM /スタート。
If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid fast re-authentication identity that the server is able to map to a permanent identity, and if the server does not want to use fast re-authentication, then the server sends EAP-Request/SIM/Start without any identity requesting attributes.
サーバが_どんなAT__ID REQも使用し、AT_IDENTITYがサーバが永久的なアイデンティティにマッピングすることが可能であることを、有効な速い再認証のアイデンティティを含んでいて、サーバが速い再認証を使用したくない場合は、サーバがEAP-Requestを送信する場合/属性を要求する任意のアイデンティティのないSIM /スタート。
If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an identity that the server recognizes as a pseudonym identity but the server is not able to map the pseudonym identity to a permanent identity, then the server sends EAP-Request/SIM/Start with AT_PERMANENT_ID_REQ.
サーバが_どんなAT__ID REQを使用して、AT_IDENTITYがサーバが匿名のアイデンティティとして認識しているアイデンティティーが含まれていますが、サーバが永久的なアイデンティティへの匿名のアイデンティティをマッピングすることができない場合、サーバーはAT_PERMANENT_ID_REQにEAP要求/ SIM /スタートを送信します。
If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an identity that the server is not able to recognize or classify, then the server sends EAP-Request/SIM/Start with AT_FULLAUTH_ID_REQ.
サーバが_どんなAT__ID REQを使用して、AT_IDENTITYがサーバが認識または分類することができないというアイデンティティが含まれている場合、サーバーはAT_FULLAUTH_ID_REQにEAP要求/ SIM /スタートを送信します。
This section contains non-normative message sequence examples to illustrate how the peer identity can be communicated to the server.
このセクションでは、ピアのアイデンティティをサーバに通信することができる方法を説明するために、非規範的メッセージシーケンスの例を含んでいます。
This case for full authentication is illustrated below in Figure 2. In this case, AT_IDENTITY contains either the permanent identity or a pseudonym identity. The same sequence is also used in case the server uses the AT_FULLAUTH_ID_REQ in EAP-Request/SIM/Start.
完全な認証のために、この場合は、この場合には図2に以下に示す、AT_IDENTITYは永久的な同一性または匿名のアイデンティティのいずれかを含みます。同じ配列はまた、サーバがEAP要求/ SIM /スタートでAT_FULLAUTH_ID_REQを使用した場合に使用されています。
Peer Authenticator
| |
| +------------------------------+
| | Server does not have a |
| | Subscriber identity available|
| | When starting EAP-SIM |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |
Figure 2: Requesting any identity, full authentication
図2：任意のアイデンティティを要求し、完全な認証
If the peer uses its full authentication identity and the AT_IDENTITY attribute contains a valid permanent identity or a valid pseudonym identity that the EAP server is able to map to the permanent identity, then the full authentication sequence proceeds as usual with the EAP Server issuing the EAP-Request/SIM/Challenge message.
ピアはその完全な認証IDを使用して、AT_IDENTITY属性が有効な永久的なアイデンティティやEAPサーバが永久的なアイデンティティにマッピングすることが可能であることを、有効な匿名のアイデンティティが含まれている場合、完全な認証シーケンスは、EAPを発行するEAPサーバといつものように進行します-request / SIM /挑戦メッセージ。
The case when the server uses the AT_ANY_ID_REQ and the peer wants to perform fast re-authentication is illustrated below in Figure 3.
サーバが_どんなAT__ID REQを使用し、ピアが速い再認証を行いたい場合は、図3で以下に示されています。
Peer Authenticator
| |
| +------------------------------+
| | Server does not have a |
| | Subscriber identity available|
| | When starting EAP-SIM |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY containing a fast re-auth. identity) |
|------------------------------------------------------>|
| |
Figure 3: Requesting any identity, fast re-authentication
図3：任意のアイデンティティ、高速再認証を要求
On fast re-authentication, if the AT_IDENTITY attribute contains a valid fast re-authentication identity and the server agrees on using fast re-authentication, then the server proceeds with the fast re-authentication sequence and issues the EAP-Request/SIM/ Re-authentication packet, as specified in Section 5.
高速再認証では、AT_IDENTITY属性が有効な速い再認証のアイデンティティを含んでおり、サーバが速い再認証を使用する上で同意した場合、その後、高速再認証シーケンスと問題EAP要求/ SIM /再使用してサーバーが進みます第5節で指定されているよう-authenticationパケット。
Figure 4 illustrates cases in which the server does not recognize the fast re-authentication identity the peer used in AT_IDENTITY, and issues a second EAP-Request/SIM/Start message.
図4は、サーバが高速再認証アイデンティティをAT_IDENTITYで使用されるピアを認識し、問題第EAP-リクエスト/ SIM /開始メッセージない場合を示しています。
Peer Authenticator
| |
| +------------------------------+
| | Server does not have a |
| | Subscriber identity available|
| | When starting EAP-SIM |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY containing a fast re-auth. identity) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server does not recognize |
| | The fast re-auth. |
| | Identity |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY with a full-auth. identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |
Figure 4: Fall back to full authentication
図4：完全認証にフォールバック
Figure 5 illustrates the case in which the EAP server fails to map the pseudonym identity included in the EAP-Response/Identity packet to a valid permanent identity.
図5は、EAPサーバが匿名のアイデンティティが有効な永久的なアイデンティティへのEAP応答/アイデンティティパケットに含まれるマップに失敗した場合を示します。
Peer Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes a pseudonym) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server fails to map the |
| | Pseudonym to a permanent id. |
| +------------------------------+
| EAP-Request/SIM/Start |
| (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY with permanent identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |
Figure 5: Requesting the permanent identity
図5：永久的なアイデンティティを要求
If the server recognizes the permanent identity, then the authentication sequence proceeds as usual with the EAP Server issuing the EAP-Request/SIM/Challenge message.
サーバが永久的なアイデンティティを認識した場合、認証シーケンスは、EAPサーバがEAP要求/ SIM /挑戦メッセージを発行するといつものように進行します。
Figure 6 illustrates the case in which the EAP server fails to map the pseudonym included in the AT_IDENTITY attribute to a valid permanent identity.
図6は、EAPサーバが有効な永久的なアイデンティティへのAT_IDENTITY属性に含ま仮名をマッピングするために失敗した場合を示します。
Peer Authenticator
| |
| +------------------------------+
| | Server does not have a |
| | Subscriber identity available|
| | When starting EAP-SIM |
| +------------------------------+
| EAP-Request/SIM/Start |
| (AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
|EAP-Response/SIM/Start |
|(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| +-------------------------------+
| | Server fails to map the |
| | Pseudonym in AT_IDENTITY |
| | to a valid permanent identity |
| +-------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY with permanent identity, |
| AT_NONCE_MT, AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |
Figure 6: Requesting a permanent identity (two EAP-SIM Start rounds)
図6：永久的なアイデンティティを要求（2 EAP-SIMスタート丸め）
In the worst case, there are three EAP/SIM/Start round trips before the server obtains an acceptable identity. This case is illustrated in Figure 7.
サーバが許容できるIDを取得する前に、最悪の場合、3つのEAP / SIM /スタートラウンドトリップがあります。この場合は、図7に示されています。
Peer Authenticator
| |
| +------------------------------+
| | Server does not have a |
| | Subscriber identity available|
| | When starting EAP-SIM |
| +------------------------------+
| EAP-Request/SIM/Start |
| (Includes AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY with fast re-auth. identity) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server does not accept |
| | The fast re-auth. |
| | Identity |
| +------------------------------+
| EAP-Request/SIM/Start |
| (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
: :
: :
: :
: :
|EAP-Response/SIM/Start |
|(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |
| +-------------------------------+
| | Server fails to map the |
| | Pseudonym in AT_IDENTITY |
| | to a valid permanent identity |
| +-------------------------------+
| EAP-Request/SIM/Start |
| (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY with permanent identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |
Figure 7: Three EAP-SIM Start rounds
After the last EAP-Response/SIM/Start message, the full authentication sequence proceeds as usual. If the EAP Server recognizes the permanent identity and is able to proceed, the server issues the EAP-Request/SIM/Challenge message.
最後のEAP応答/ SIM /開始メッセージの後、完全な認証系列はいつものように進行します。 EAPサーバが永久的なアイデンティティを認識して進めることができる場合、サーバがEAP要求/ SIM /挑戦メッセージを発行します。
In some environments, EAP authentication may be performed frequently. Because the EAP-SIM full authentication procedure makes use of the GSM SIM A3/A8 algorithms, and therefore requires 2 or 3 fresh triplets from the Authentication Centre, the full authentication procedure is not very well suited for frequent use. Therefore, EAP-SIM includes a more inexpensive fast re-authentication procedure that does not make use of the SIM A3/A8 algorithms and does not need new triplets from the Authentication Centre. Re-authentication can be performed in fewer roundtrips than the full authentication.
一部の環境では、EAP認証が頻繁に行われてもよいです。 EAP-SIM完全な認証手順がGSM SIM A3 / A8アルゴリズムを利用し、したがって、認証センターから2つの又は3新鮮トリプレットを必要とするので、完全な認証手順が頻繁に使用するのに非常に適していません。したがって、EAP-SIMは、SIM A3 / A8アルゴリズムを利用しないと認証センターからの新しいトリプレットを必要としない、より安価な高速再認証手順を含んでいます。再認証は、完全な認証よりも少ないのラウンドトリップで実行することができます。
Fast re-authentication is optional to implement for both the EAP-SIM server and peer. On each EAP authentication, either one of the entities may also fall back on full authentication if it does not want to use fast re-authentication.
高速再認証は、EAP-SIMサーバとピアの両方に実装するオプションです。それは速い再認証を使用したくない場合は、各EAP認証では、エンティティのいずれか一方がまた戻って完全な認証に落ちることがあります。
Fast re-authentication is based on the keys derived on the preceding full authentication. The same K_aut and K_encr keys that were used in full authentication are used to protect EAP-SIM packets and attributes, and the original Master Key from full authentication is used to generate a fresh Master Session Key, as specified in Section 7.
高速再認証が前の完全な認証のときに引き出されたキーに基づいています。完全な認証に使用したのと同じK_autとK_encrキーは、EAP-SIMパケットと属性を保護するために使用され、そして7節で指定された完全な認証から元のマスタキーは、新鮮なマスターセッションキーを生成するために使用されます。
The fast re-authentication exchange makes use of an unsigned 16-bit counter, included in the AT_COUNTER attribute. The counter has three goals: 1) it can be used to limit the number of successive reauthentication exchanges without full authentication 2) it contributes to the keying material, and 3) it protects the peer and the server from replays. On full authentication, both the server and the peer initialize the counter to one. The counter value of at least one is used on the first fast re-authentication. On subsequent fast re-authentications, the counter MUST be greater than on any of the previous re-authentications. For example, on the second fast re-authentication, the counter value is two or greater. The AT_COUNTER attribute is encrypted.
高速再認証交換はAT_COUNTER属性に含まれる符号なしの16ビットカウンタを使用します。それは鍵材料に寄与し、3）それがピアとリプレイからサーバを保護する1）完全な認証なしで2連続再認証交換の数を制限するために使用することができる）：カウンタが3つのゴールを有します。完全な認証では、サーバとピアの両方は1つにカウンターを初期化します。少なくとも一つのカウンタ値は、第1速い再認証に使用されます。その後の速い再認証に、カウンタは、前回の再認証のいずれかよりも大きくなければなりません。例えば、第二高速再認証に、カウンタの値が2以上です。 AT_COUNTER属性は暗号化されています。
Both the peer and the EAP server maintain a copy of the counter. The EAP server sends its counter value to the peer in the fast re-authentication request. The peer MUST verify that its counter value is less than or equal to the value sent by the EAP server.
ピアとEAPサーバの両方がカウンターのコピーを維持します。 EAPサーバが速い再認証要求にピアにそのカウンタ値を送信します。ピアは、そのカウンタ値がEAPサーバによって送信された値以下であることを確かめなければなりません。
The server includes an encrypted server random nonce (AT_NONCE_S) in the fast re-authentication request. The AT_MAC attribute in the peer's response is calculated over NONCE_S to provide a challenge/response authentication scheme. The NONCE_S also contributes to the new Master Session Key.
サーバが速い再認証要求で暗号化されたサーバーのランダムなナンス（AT_NONCE_S）が含まれています。ピアの応答におけるAT_MAC属性は、チャレンジ/レスポンス認証方式を提供するために、NONCE_Sに対して計算されます。 NONCE_Sはまた、新しいマスターセッションキーに貢献しています。
Both the peer and the server SHOULD have an upper limit for the number of subsequent fast re-authentications allowed before a full authentication needs to be performed. Because a 16-bit counter is used in fast re-authentication, the theoretical maximum number of re-authentications is reached when the counter value reaches FFFF hexadecimal.
完全な認証を実行する必要がある前に、ピアとサーバの両方が許可され、その後の速い再認証の数の上限を有するべきです。 16ビット・カウンタが速い再認証に使用されるので、再認証の理論上の最大数は、カウンタ値がFFFF 16進数に達したときに達成されます。
In order to use fast re-authentication, the peer and the EAP server need to store the following values: Master Key, latest counter value and the next fast re-authentication identity. K_aut, K_encr may either be stored or derived again from MK. The server may also need to store the permanent identity of the user.
マスターキー、最新のカウンタ値と次の速い再認証のアイデンティティ：速い再認証を使用するには、ピアとEAPサーバは、以下の値を格納する必要があります。 K_autは、K_encrが格納またはMKから再び誘導することができるいずれか。また、サーバは、ユーザの永久的なアイデンティティを格納する必要があるかもしれません。
When analyzing the fast re-authentication exchange, it may be helpful to compare it with the UMTS Authentication and Key Agreement (AKA) exchange, which it resembles closely. The counter corresponds to the UMTS AKA sequence number, NONCE_S corresponds to RAND, AT_MAC in EAP-Request/SIM/Re-authentication corresponds to AUTN, the AT_MAC in EAP-Response/SIM/Re-authentication corresponds to RES, AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the counter corresponds to the usage of the Anonymity Key. Also, the key generation on fast re-authentication, with regard to random or fresh material, is similar to UMTS AKA -- the server generates the NONCE_S and counter values, and the peer only verifies that the counter value is fresh.
速い再認証交換を分析する場合、密接に似ているUMTS認証および鍵合意（AKA）交換とそれを比較することは有用であり得ます。カウンタはUMTS AKAに対応するEAP-応答/ SIM /再認証はRESに対応するにNONCE_SはEAP-要求/ SIMでRAND、AT_MACに相当/再認証AUTNに対応するシーケンス番号、AT_MACは、AT_COUNTER_TOO_SMALLはAUTSに対応します、およびカウンタを暗号化することは匿名のキーの使用方法に対応しています。また、ランダムまたは新鮮な材料に関して速い再認証の鍵生成は、UMTS AKAと同様である - サーバーがNONCE_Sとカウンタ値を生成し、ピアは、カウンタ値が新鮮であることを検証します。
It should also be noted that encrypting the AT_NONCE_S, AT_COUNTER, or AT_COUNTER_TOO_SMALL attributes is not important to the security of the fast re-authentication exchange.
またAT_NONCE_S、AT_COUNTER、またはAT_COUNTER_TOO_SMALL属性を暗号化すると、高速再認証交換のセキュリティにとって重要ではないことに留意すべきです。
The fast re-authentication procedure makes use of separate re-authentication user identities. Pseudonyms and the permanent identity are reserved for full authentication only. If a re-authentication identity is lost and the network does not recognize it, the EAP server can fall back on full authentication.
高速再認証手順は別々の再認証のユーザーIDを使用します。偽名と永久的なアイデンティティは唯一完全な認証のために予約されています。再認証のアイデンティティが失われ、ネットワークがそれを認識しない場合は、EAPサーバは完全な認証に頼ることができます。
If the EAP server supports fast re-authentication, it MAY include the skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of EAP-Request/SIM/Challenge message (Section 9.3). This attribute contains a new fast re-authentication identity for the next fast re-authentication. The attribute also works as a capability flag that, indicating that the server supports fast re-authentication, and that the server wants to continue using fast re-authentication within the current context. The peer MAY ignore this attribute, in which case it MUST use full authentication next time. If the peer wants to use re-authentication, it uses this fast re-authentication identity on next authentication. Even if the peer has a fast re-authentication identity, the peer MAY discard the fast re-authentication identity and use a pseudonym or the permanent identity instead, in which case full authentication MUST be performed. If the EAP server does not include the AT_NEXT_REAUTH_ID in the encrypted data of EAP-Request/SIM/Challenge or EAP-Request/SIM/ Re-authentication, then the peer MUST discard its current fast re-authentication state information and perform a full authentication next time.
EAPサーバが速い再認証をサポートしている場合、それはEAP要求/ SIM /挑戦メッセージ（セクション9.3）の暗号化されたデータでスキップ可能AT_ネクスト_REAUTH_ID属性を含むかもしれません。この属性は、次の速い再認証のための新しい速い再認証のアイデンティティを含んでいます。属性はまた、サーバが速い再認証をサポートしていることを示す機能フラグとして動作し、サーバは現在のコンテキスト内で高速再認証を継続して使用したいということ。ピアは、それは次回のフル認証を使用する必要があり、その場合には、この属性を無視してもよいです。ピアは再認証を使用したい場合は、次の認証にこの速い再認証のアイデンティティを使用しています。ピアが速い再認証IDを有する場合であっても、ピアが速い再認証IDを破棄し、完全な認証を実行しなければならない場合には匿名またはその代わりに永久的なアイデンティティを使用することができます。 EAPサーバがEAP要求/ SIM /挑戦かEAP要求/ SIM /再認証の暗号化されたデータにAT_ネクスト_REAUTH_IDが含まれていない場合は、ピアは、現在の高速再認証状態情報を破棄し、完全な認証を実行しなければなりません次回。
In environments where a realm portion is needed in the peer identity, the fast re-authentication identity received in AT_NEXT_REAUTH_ID MUST contain both a username portion and a realm portion, as per the NAI format. The EAP Server can choose an appropriate realm part in order to have the AAA infrastructure route subsequent fast re-authentication related requests to the same AAA server. For example, the realm part MAY include a portion that is specific to the AAA server. Hence, it is sufficient to store the context required for fast re-authentication in the AAA server that performed the full authentication.
レルム部分がピア識別に必要とされる環境では、AT_ネクスト_REAUTH_IDで受信高速再認証アイデンティティはNAIフォーマットに従って、ユーザ名部分と領域部分の両方を含まなければなりません。 EAPサーバは、同じAAAサーバにAAAインフラストラクチャのルート、その後の速い再認証関連の要求を持っているために、適切なレルムの一部を選択することができます。例えば、レルム部分はAAAサーバに固有の部分を含むことができます。したがって、完全な認証を行うAAAサーバに速い再認証に必要なコンテキストを格納するのに十分です。
The peer MAY use the fast re-authentication identity in the EAP-Response/Identity packet or, in response to the server's AT_ANY_ID_REQ attribute, the peer MAY use the fast re-authentication identity in the AT_IDENTITY attribute of the EAP-Response/SIM/Start packet.
ピアは、EAP応答/アイデンティティパケットで速い再認証のアイデンティティを使用したり、サーバーの_どんなAT__ID REQ属性に応じて、ピアはEAP応答/ SIMのAT_IDENTITY属性に速い再認証のアイデンティティを使用するかもしれ/パケットを開始します。
The peer MUST NOT modify the username portion of the fast re-authentication identity, but the peer MAY modify the realm portion or replace it with another realm portion. The peer might need to modify the realm in order to influence the AAA routing, for example, to make sure that the correct server is reached. It should be noted that sharing the same fast re-authentication key among several servers may have security risks, so changing the realm portion of the NAI in order to change the EAP server is not desirable.
ピアは速い再認証のアイデンティティのユーザ名部分を変更してはいけませんが、ピアが分野の部分を変更したり、他の分野の部分でそれを置き換えることができます。ピアは正しいサーバーに到達したことを確認するために、例えば、AAAルーティングに影響を与えるためにレルムを変更する必要があります。これは、複数のサーバに同じ速い再認証キーを共有するので、EAPサーバを変更するためにNAIの分野の部分を変更し、セキュリティリスクを持っていることに留意すべきであることは望ましくありません。
Even if the peer uses a fast re-authentication identity, the server may want to fall back on full authentication, for example because the server does not recognize the fast re-authentication identity or does not want to use fast re-authentication. In this case, the server starts the full authentication procedure by issuing an EAP-Request/SIM/Start packet. This packet always starts a full authentication sequence if it does not include the AT_ANY_ID_REQ attribute. If the server was not able to recover the peer's identity from the fast re-authentication identity, the server includes either the AT_FULLAUTH_ID_REQ or the AT_PERMANENT_ID_REQ attribute in this EAP request.
ピアが速い再認証のアイデンティティを使用している場合でも、サーバが速い再認証のアイデンティティを認識していないか、速い再認証を使用したくないので、サーバーには、例えば、完全な認証にフォールバックすることもできます。この場合、サーバがEAP要求/ SIM /スタートパケットを発行することによって、完全な認証手順を開始します。それは_どんなAT__ID REQ属性が含まれていない場合は、このパケットは、常に完全な認証シーケンスを開始します。サーバが速い再認証のアイデンティティから同輩のアイデンティティを回復することができなかった場合、サーバはAT_FULLAUTH_ID_REQまたはこのEAP要求におけるAT_PERMANENT_ID_REQ属性のいずれかを含んでいます。
Figure 8 illustrates the fast re-authentication procedure. In this example, the optional protected success indication is not used. Encrypted attributes are denoted with '*'. The peer uses its re-authentication identity in the EAP-Response/Identity packet. As discussed above, an alternative way to communicate the re-authentication identity to the server is for the peer to use the AT_IDENTITY attribute in the EAP-Response/SIM/Start message. This latter case is not illustrated in the figure below, and it is only possible when the server requests that the peer send its identity by including the AT_ANY_ID_REQ attribute in the EAP-Request/SIM/Start packet.
図8は、高速再認証手順を示しています。この例では、オプションで保護された成功指示が使用されていません。暗号化された属性は、「*」で表されています。ピアは、EAP応答/アイデンティティパケットでの再認証のアイデンティティを使用しています。上述したように、サーバへの再認証アイデンティティを通信するための別の方法は、EAP-応答/ SIM /開始メッセージでAT_IDENTITY属性を使用するピアのためのものです。この後者の場合は、下の図に示されていない、そしてそれが唯一可能な場合、ピアは、EAP要求/ SIM /スタートパケットで_どんなAT__ID REQ属性を含めることによって、そのIDを送信サーバー要求。
If the server recognizes the identity as a valid fast re-authentication identity, and if the server agrees to use fast re-authentication, then the server sends the EAP-Request/SIM/ Re-authentication packet to the peer. This packet MUST include the encrypted AT_COUNTER attribute, with a fresh counter value, the encrypted AT_NONCE_S attribute that contains a random number chosen by the server, the AT_ENCR_DATA and the AT_IV attributes used for encryption, and the AT_MAC attribute that contains a message authentication code over the packet. The packet MAY also include an encrypted AT_NEXT_REAUTH_ID attribute that contains the next fast re-authentication identity.
サーバーが有効な速い再認証のアイデンティティとしてのアイデンティティを認識し、サーバが速い再認証を使用することに同意する場合は、サーバは、ピアへのEAP要求/ SIM /再認証パケットを送信する場合。このパケットは、サーバによって選ばれた乱数、AT_ENCR_DATAと暗号化に使用AT_IV属性、およびオーバーメッセージ認証コードが含まれているAT_MAC属性が含まれている新鮮なカウンタ値、暗号化されたAT_NONCE_S属性で、暗号化されたAT_COUNTER属性を含まなければなりませんパケット。パケットはまた、次の速い再認証のアイデンティティを含む暗号化AT_ネクスト_REAUTH_ID属性を含むかもしれません。
Fast re-authentication identities are one-time identities. If the peer does not receive a new fast re-authentication identity, it MUST use either the permanent identity or a pseudonym identity on the next authentication to initiate full authentication.
高速再認証アイデンティティは、ワンタイムIDです。ピアが新しい速い再認証IDを受信しない場合、それは完全な認証を開始するために、次の認証に永久的なアイデンティティか匿名のアイデンティティのどちらかを使用しなければなりません。
The peer verifies that AT_MAC is correct, and that the counter value is fresh (greater than any previously used value). The peer MAY save the next fast re-authentication identity from the encrypted AT_NEXT_REAUTH_ID for next time. If all checks are successful, the peer responds with the EAP-Response/SIM/Re-authentication packet, including the AT_COUNTER attribute with the same counter value and AT_MAC attribute.
ピアはAT_MACが正しいこと、およびカウンタ値が（以前に使用された値よりも大きい）新鮮であることを検証します。ピアは、次回のために暗号化されたAT_ネクスト_REAUTH_IDから次の速い再認証のアイデンティティを保存することがあります。すべてのチェックが成功した場合、ピアは同じカウンタ値とAT_MAC属性を持つAT_COUNTER属性を含むEAP応答/ SIM /再認証パケットで応答します。
The server verifies the AT_MAC attribute and also verifies that the counter value is the same that it used in the EAP-Request/SIM/ Re-authentication packet. If these checks are successful, the re-authentication has succeeded and the server sends the EAP-Success packet to the peer.
サーバは、AT_MAC属性を検証し、また、カウンタの値は、それがEAP要求/ SIMは/再認証パケットで使用していることと同じであることを確認します。これらのチェックが成功した場合、再認証が成功したとサーバがピアにEAP-Successパケットを送信します。
If protected success indications (Section 6.2) were used, the EAP-Success packet would be preceded by an EAP-SIM notification round.
保護された成功指摘（セクション6.2）を使用した場合は、EAP-Successパケットは、EAP-SIM通知ラウンドによって先行されるだろう。
Peer Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes a fast re-authentication identity) |
|------------------------------------------------------>|
| |
| +--------------------------------+
| | Server recognizes the identity |
| | and agrees to use fast |
| | re-authentication |
| +--------------------------------+
| |
: :
: :
: :
: :
| EAP-Request/SIM/Re-authentication |
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER, |
| *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) |
|<------------------------------------------------------|
| |
+-----------------------------------------------+ |
| Peer verifies AT_MAC and the freshness of | |
| the counter. Peer MAY store the new fast re- | |
| authentication identity for next re-auth. | |
+-----------------------------------------------+ |
| |
| EAP-Response/SIM/Re-authentication |
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, |
| AT_MAC) |
|------------------------------------------------------>|
| +--------------------------------+
| | Server verifies AT_MAC and |
| | the counter |
| +--------------------------------+
| |
| EAP-Success |
|<------------------------------------------------------|
| |
Figure 8: Fast Re-authentication
図8：高速再認証
If the peer does not accept the counter value of EAP-Request/SIM/ Re-authentication, it indicates the counter synchronization problem by including the encrypted AT_COUNTER_TOO_SMALL in EAP-Response/SIM/ Re-authentication. The server responds with EAP-Request/SIM/Start to initiate a normal full authentication procedure. This is illustrated in Figure 9. Encrypted attributes are denoted with '*'.
ピアは、EAP要求/ SIM /再認証のカウンタ値を受け入れない場合は、EAP応答/ SIM /再認証で暗号化されたAT_COUNTER_TOO_SMALLを含むことにより、カウンタ同期の問題があることを示します。サーバーは、通常のフル認証手続きを開始するために、EAP要求/ SIM /スタートで応答します。これは、「*」で表されている図9暗号化された属性に例示されています。
Peer Authenticator
| EAP-Request/SIM/Start |
| (AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY) |
| (Includes a fast re-authentication identity) |
|------------------------------------------------------>|
| |
| EAP-Request/SIM/Re-authentication |
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER, |
| *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) |
|<------------------------------------------------------|
+-----------------------------------------------+ |
| AT_MAC is valid but the counter is not fresh. | |
+-----------------------------------------------+ |
| |
| EAP-Response/SIM/Re-authentication |
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL, |
| *AT_COUNTER, AT_MAC) |
|------------------------------------------------------>|
| +----------------------------------------------+
| | Server verifies AT_MAC but detects |
| | That peer has included AT_COUNTER_TOO_SMALL |
| +----------------------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_VERSION_LIST) |
|<------------------------------------------------------|
+---------------------------------------------------------------+
| Normal full authentication follows. |
+---------------------------------------------------------------+
| |
Figure 9: Fast Re-authentication, counter is not fresh
図9：高速再認証、カウンタは新鮮ではありません
In the figure above, the first three messages are similar to the basic fast re-authentication case. When the peer detects that the counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL attribute in EAP-Response/SIM/Re-authentication. This attribute doesn't contain any data, but it is a request for the server to initiate full authentication. In this case, the peer MUST ignore the contents of the server's AT_NEXT_REAUTH_ID attribute.
上の図では、最初の3つのメッセージは、基本的な速い再認証の場合と同様です。ピアは、カウンタ値が新鮮でないことを検出すると、それはEAP応答/ SIM /再認証にAT_COUNTER_TOO_SMALL属性を含んでいます。この属性は、すべてのデータが含まれていませんが、完全な認証を開始するサーバーの要求です。この場合、ピアは、サーバのAT_ネクスト_REAUTH_ID属性の内容を無視しなければなりません。
On receipt of AT_COUNTER_TOO_SMALL, the server verifies AT_MAC and verifies that AT_COUNTER contains the same counter value as in the EAP-Request/SIM/Re-authentication packet. If not, the server terminates the authentication exchange by sending the EAP-Request/SIM/Notification with AT_NOTIFICATION code "General failure" (16384). If all checks on the packet are successful, the server transmits a new EAP-Request/SIM/Start packet and the full authentication procedure is performed as usual. Since the server already knows the subscriber identity, it MUST NOT include AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_PERMANENT_ID_REQ in the EAP-Request/SIM/Start.
AT_COUNTER_TOO_SMALLを受信すると、サーバは、AT_MACを検証し、AT_COUNTERがEAP要求/ SIM /再認証パケットと同じカウンタ値が含まれていることを確認します。そうでない場合、サーバはAT_NOTIFICATIONコード「一般失敗」（16384）でEAP要求/ SIM /通知を送信して認証交換を終了します。パケット上のすべてのチェックが成功した場合、サーバーは新しいEAP要求/ SIM /スタートパケットを送信し、完全な認証手順が通常通りに行われます。サーバがすでに加入者識別を知っているので、それはEAP要求/ SIM /スタートで_どんなAT__ID REQ、AT_FULLAUTH_ID_REQ、またはAT_PERMANENT_ID_REQを含んではいけません。
It should be noted that in this case, peer identity is only transmitted in the AT_IDENTITY attribute at the beginning of the whole EAP exchange. The fast re-authentication identity used in this AT_IDENTITY attribute will be used in key derivation (see Section 7).
なお、この場合、ピア・アイデンティティは全体のみEAP交換の冒頭でAT_IDENTITY属性で送信されることに留意すべきです。このAT_IDENTITY属性に使用される高速再認証アイデンティティが鍵の導出に使用されます（セクション7を参照）。
EAP-SIM does not prohibit the use of the EAP Notifications as specified in [RFC3748]. EAP Notifications can be used at any time in the EAP-SIM exchange. It should be noted that EAP-SIM does not protect EAP Notifications. EAP-SIM also specifies method-specific EAP-SIM notifications that are protected in some cases.
[RFC3748]で指定されるようにEAP-SIMは、EAP通知の使用を禁止していません。 EAP通知は、EAP-SIM交換でいつでも使用することができます。 EAP-SIMがEAP通知を保護しないことに留意すべきです。 EAP-SIMはまた、いくつかのケースで保護されているメソッド固有のEAP-SIM通知を指定します。
The EAP server can use EAP-SIM notifications to convey notifications and result indications (Section 6.2) to the peer.
EAPサーバは、通知を伝え、相手に表示（6.2節）をもたらすためにEAP-SIM通知を使用することができます。
The server MUST use notifications in cases discussed in Section 6.3.2. When the EAP server issues an EAP-Request/SIM/Notification packet to the peer, the peer MUST process the notification packet. The peer MAY show a notification message to the user and the peer MUST respond to the EAP server with an EAP-Response/SIM/Notification packet, even if the peer did not recognize the notification code.
サーバーは、6.3.2項で述べた例では、通知を使用しなければなりません。 EAPサーバは、ピアへのEAP要求/ SIM /通知パケットを発行すると、ピアは通知パケットを処理しなければなりません。ピアは、ユーザーに通知メッセージが表示されることとピアは、ピアが通知コードを認識しなかった場合でも、EAP応答/ SIM /通知パケットでEAPサーバに応じなければなりません。
An EAP-SIM full authentication exchange or a fast re-authentication exchange MUST NOT include more than one EAP-SIM notification round.
EAP-SIMの完全な認証交換または速い再認証交換は、複数のEAP-SIM通知ラウンドを含んではいけません。
The notification code is a 16-bit number. The most significant bit is called the Success bit (S bit). The S bit specifies whether the notification implies failure. The code values with the S bit set to zero (code values 0...32767) are used on unsuccessful cases. The receipt of a notification code from this range implies a failed EAP exchange, so the peer can use the notification as a failure indication. After receiving the EAP-Response/SIM/Notification for these notification codes, the server MUST send the EAP-Failure packet.
通知コードは16ビット数です。最上位ビットが成功ビット（Sビット）と呼ばれています。 Sビットは、通知が失敗を意味するかどうかを指定します。 Sとコード値は失敗した場合に使用される（コードが0 ... 32767値）がゼロにビットセット。ピアが失敗指示として通知を使用できるように、この範囲からの通知コードの受信が失敗したEAP交換を意味しています。これらの通知コードのためのEAP応答/ SIM /通知を受け取った後、サーバは、EAP-Failureパケットを送らなければなりません。
The receipt of a notification code with the S bit set to one (values 32768...65536) does not imply failure. Notification code "Success" (32768) has been reserved as a general notification code to indicate successful authentication.
Sとの通知コードの受信が失敗したことを意味しない（32768 ... 65536値）を一度にビットセット。通知コード「成功」（32768）認証の成功を示すために、一般的な通知コードとして予約されています。
The second most significant bit of the notification code is called the Phase bit (P bit). It specifies at which phase of the EAP-SIM exchange the notification can be used. If the P bit is set to zero, the notification can only be used after a successful EAP/SIM/Challenge round in full authentication or a successful EAP/SIM/Re-authentication round in reauthentication. A re-authentication round is considered successful only if the peer has successfully verified AT_MAC and AT_COUNTER attributes, and does not include the AT_COUNTER_TOO_SMALL attribute in EAP-Response/SIM/Re-authentication.
通知コードの第2最上位ビットは、位相ビット（Pビット）と呼ばれます。これは、通知を使用することができるEAP-SIM交換のどの段階で指定します。 Pビットがゼロに設定されている場合、通知は、完全な認証に成功したEAP / SIM /チャレンジラウンド又は再認証に成功したEAP / SIM /再認証ラウンド後に使用することができます。再認証ラウンドは、ピアが正常にAT_MACとAT_COUNTER属性、およびEAP応答/ SIM /再認証にAT_COUNTER_TOO_SMALL属性が含まれていない確認した場合にのみ成功したとみなされます。
If the P bit is set to one, the notification can only by used before the EAP/SIM/Challenge round in full authentication, or before the EAP/SIM/Re-authentication round in reauthentication. These notifications can only be used to indicate various failure cases. In other words, if the P bit is set to one, then the S bit MUST be set to zero.
Pビットが1に設定されている場合、通知のみによって完全な認証にEAP / SIM /チャレンジラウンドの前に、または再認証にEAP / SIM /再認証ラウンドの前に使用することができます。これらの通知はさまざまな障害例を示すために使用することができます。 Pビットが1に設定されている場合、つまり、次にSビットはゼロに設定しなければなりません。
Section 9.8 and Section 9.9 specify what other attributes must be included in the notification packets.
セクション9.8とセクション9.9は、他の属性は、通知パケットに含まれていなければならないものを指定します。
Some of the notification codes are authorization related and, hence, are not usually considered part of the responsibility of an EAP method. However, they are included as part of EAP-SIM because there are currently no other ways to convey this information to the user in a localizable way, and the information is potentially useful for the user. An EAP-SIM server implementation may decide never to send these EAP-SIM notifications.
通知コードの一部は、認可に関連していると、それゆえ、通常、EAPメソッドの責任の一部とはみなされません。そこにローカライズの方法でユーザーにこの情報を伝えるために、他の方法は現在ありません、との情報がユーザにとって有用である可能性があるので、しかし、彼らは、EAP-SIMの一部として含まれています。 EAP-SIMサーバの実装は、これらのEAP-SIM通知を送信するために決して決定しないことがあります。
As discussed in Section 6.3, the server and the peer use explicit error messages in all error cases. If the server detects an error after successful authentication, the server uses an EAP-SIM notification to indicate failure to the peer. In this case, the result indication is integrity and replay protected.
6.3節で述べたように、サーバとピアはすべてのエラーの場合には、明示的なエラーメッセージを使用しています。サーバが認証に成功した後にエラーを検出した場合、サーバーは、ピアに失敗したことを示すために、EAP-SIM通知を使用しています。この場合、結果の表示が整合性とリプレイ保護されています。
By sending an EAP-Response/SIM/Challenge packet or an EAP-Response/SIM/Re-authentication packet (without AT_COUNTER_TOO_SMALL), the peer indicates that it has successfully authenticated the server and that the peer's local policy accepts the EAP exchange. In other words, these packets are implicit success indications from the peer to the server.
EAP応答/ SIM /挑戦パケットか（AT_COUNTER_TOO_SMALLなし）EAP応答/ SIM /再認証パケットを送信することにより、ピアはそれが首尾よくサーバを認証して、同輩のローカルの方針がEAP交換を受け入れることを示しています。言い換えれば、これらのパケットは、サーバへのピアからの暗黙の成功指摘しています。
EAP-SIM also supports optional protected success indications from the server to the peer. If the EAP server wants to use protected success indications, it includes the AT_RESULT_IND attribute in the EAP-Request/SIM/Challenge or the EAP-Request/SIM/Re-authentication packet. This attribute indicates that the EAP server would like to use result indications in both successful and unsuccessful cases. If the peer also wants this, the peer includes AT_RESULT_IND in EAP-Response/SIM/Challenge or EAP-Response/SIM/Re-authentication. The peer MUST NOT include AT_RESULT_IND if it did not receive AT_RESULT_IND from the server. If both the peer and the server used AT_RESULT_IND, then the EAP exchange is not complete yet, but an EAP-SIM notification round will follow. The following EAP-SIM notification may indicate either failure or success.
EAP-SIMは、サーバーからのピアに、オプションの保護された成功指摘をサポートしています。 EAPサーバは、保護された成功指摘を使用したい場合は、EAP要求/ SIM /挑戦かEAP要求/ SIM /再認証パケット内のAT_RESULT_IND属性を含んでいます。この属性は、EAPサーバが成功と失敗の両方のケースでは、結果の表示を使用したいことを示しています。ピアもこれを望んでいる場合、ピアはEAP応答/ SIM /挑戦かEAP応答/ SIM /再認証にAT_RESULT_INDが含まれています。それは、サーバからAT_RESULT_INDを受信しなかった場合、ピアはAT_RESULT_INDを含んではいけません。ピアとAT_RESULT_INDを使用サーバの両方場合は、EAP交換はまだ完全ではありませんが、EAP-SIM通知ラウンドが続きます。以下のEAP-SIM通知は失敗か成功のどちらかを示すかもしれません。
Success indications with the AT_NOTIFICATION code "Success" (32768) can only be used if both the server and the peer indicate they want to use them with AT_RESULT_IND. If the server did not include AT_RESULT_IND in the EAP-Request/SIM/Challenge or EAP-Request/SIM/Re-authentication packet, or if the peer did not include AT_RESULT_IND in the corresponding response packet, then the server MUST NOT use protected success indications.
サーバとピアの両方が、彼らはAT_RESULT_INDでそれらを使用したい場合は指示AT_NOTIFICATIONコード「成功」（32768）との成功指摘にのみ使用することができます。サーバがEAP要求/ SIM /挑戦かEAP要求/ SIM /再認証パケットにAT_RESULT_INDが含まれていなかった、またはピアは、対応する応答パケットにAT_RESULT_INDが含まれていなかった場合、サーバは保護された成功を使用してはならない場合適応症。
Because the server uses the AT_NOTIFICATION code "Success" (32768) to indicate that the EAP exchange has completed successfully, the EAP exchange cannot fail when the server processes the EAP-SIM response to this notification. Hence, the server MUST ignore the contents of the EAP-SIM response it receives from the EAP-Request/SIM/Notification with this code. Regardless of the contents of the EAP-SIM response, the server MUST send EAP-Success as the next packet.
サーバがEAP交換が正常に完了したことを示すためにAT_NOTIFICATIONコード「成功」（32768）を使用しているため、サーバがこの通知にEAP-SIM応答を処理するとき、EAP交換は失敗することはできません。したがって、サーバは、このコードでEAP-リクエスト/ SIM /通知を受信するEAP-SIM応答の内容を無視しなければなりません。かかわらず、EAP-SIM応答の内容の、サーバは次のパケットとしてEAP-成功を送らなければなりません。
This section specifies the operation of the peer and the server in error cases. The subsections below require the EAP-SIM peer and server to send an error packet (EAP-Response/SIM/Client-Error from the peer or EAP-Request/SIM/Notification from the server) in error cases. However, implementations SHOULD NOT rely upon the correct error reporting behavior of the peer, authenticator, or the server. It is possible for error and other messages to be lost in transit or for a malicious participant to attempt to consume resources by not issuing error messages. Both the peer and the EAP server SHOULD have a mechanism to clean up state, even if an error message or EAP-Success is not received after a timeout period.
このセクションでは、エラーの場合、ピアおよびサーバの動作を指定します。以下のサブセクションでは、エラーの場合には（サーバーからピアまたはEAP要求/ SIM /通知からEAP応答/ SIM /クライアントエラー）エラーパケットを送信するためにEAP-SIMのピアとサーバを必要としています。しかし、実装は、ピア、オーセンティケータ、またはサーバーの正しいエラー報告の動作時に頼るべきではありません。エラーやその他のメッセージが転送中に、またはエラーメッセージを発行しないことにより、リソースを消費しようとする悪質な参加者のために失われることが可能です。ピアとEAPサーバの両方がエラーメッセージまたはEAP-成功がタイムアウト時間後に受信されていない場合でも、状態をクリーンアップするメカニズムを持っているべきです。
In general, if an EAP-SIM peer detects an error in a received EAP-SIM packet, the EAP-SIM implementation responds with the EAP-Response/SIM/Client-Error packet. In response to the EAP-Response/SIM/Client-Error, the EAP server MUST issue the EAP-Failure packet and the authentication exchange terminates.
EAP-SIMのピアは、受信したEAP-SIMパケットにエラーを検出した場合、一般的には、EAP-SIMの実装では、EAP応答/ SIM /クライアントエラーパケットで応答します。 EAP応答/ SIM /クライアントのエラーに対応して、EAPサーバは、EAP-Failureパケットを発行しなければなりませんし、認証交換は終了します。
By default, the peer uses the client error code 0, "unable to process packet". This error code is used in the following cases:
デフォルトでは、ピアは、クライアントのエラーコード0、「パケットを処理できない」を使用しています。このエラーコードは、次の場合に使用されます。
o EAP exchange is not acceptable according to the peer's local policy.
O EAP交換が同輩のローカルポリシーに従って受け入れられません。
o the peer is not able to parse the EAP request, i.e., the EAP request is malformed.
ピアoを、すなわち、EAP要求が不正である、EAP要求を解析することができません。
o the peer encountered a malformed attribute.
Oピアが不正な形式の属性に遭遇しました。
o wrong attribute types or duplicate attributes have been included in the EAP request.
O間違った属性タイプまたは重複した属性がEAP要求に含まれています。
o a mandatory attribute is missing.
O必須属性が欠落しています。
o unrecognized, non-skippable attribute.
O認識されていない、非スキップ可能属性。
o unrecognized or unexpected EAP-SIM Subtype in the EAP request.
EAP要求におけるO認識されていないか、予期しないEAP-SIMサブタイプ。
o A RAND challenge repeated in AT_RAND.
AT_RANDで繰り返さRANDチャレンジO。
o invalid AT_MAC. The peer SHOULD log this event.
O AT_MACを無効。ピアは、このイベントをログに記録すべきです。
o invalid pad bytes in AT_PADDING.
AT_PADDING中のOの無効なパッドバイト。
o the peer does not want to process AT_PERMANENT_ID_REQ.
OピアはAT_PERMANENT_ID_REQを処理する必要はありません。
Separate error codes have been defined for the following error cases in Section 10.19:
個別のエラーコードは、セクション10.19で、次のエラーの場合のために定義されています：
As specified in Section 4.1, when processing the AT_VERSION_LIST attribute, which lists the EAP-SIM versions supported by the server, if the attribute does not include a version that is implemented by the peer and allowed in the peer's security policy, then the peer MUST send the EAP-Response/SIM/Client-Error packet with the error code "unsupported version".
セクション4.1で指定されているように属性がピアによって実装され、ピアのセキュリティポリシーで許可されているバージョン、ピアMUSTが含まれていない場合は、サーバーでサポートされているEAP-SIMバージョンを示しますAT_VERSION_LIST属性を処理するときエラーコード「サポートされていないバージョン」とEAP応答/ SIM /クライアントエラーパケットを送信します。
If the number of RAND challenges is smaller than what is required by peer's local policy when processing the AT_RAND attribute, the peer MUST send the EAP-Response/SIM/Client-Error packet with the error code "insufficient number of challenges".
RANDの数が挑戦している場合は、ピアのローカルポリシーによって必要とされるものよりも小さいAT_RAND属性を処理するときに、ピアはエラーコード「の課題の数が不十分」とのEAP応答/ SIM /クライアントエラーパケットを送らなければなりません。
If the peer believes that the RAND challenges included in AT_RAND are not fresh e.g., because it is capable of remembering some previously used RANDs, the peer MUST send the EAP-Response/SIM/Client-Error packet with the error code "RANDs are not fresh".
ピアはRANDが課題と考えている場合AT_RANDに含まれて新鮮ではありません例えば、それはいくつかの以前に使用ランズを覚えることのできるので、ピアは、エラーコード「ランズとEAP応答/ SIM /クライアントエラーパケットを送らなければなりませんではありません新鮮な"。
If an EAP-SIM server detects an error in a received EAP-SIM response, the server MUST issue the EAP-Request/SIM/Notification packet with an AT_NOTIFICATION code that implies failure. By default, the server uses one of the general failure codes ("General failure after authentication" (0), or "General failure" (16384)). The choice between these two codes depends on the phase of the EAP-SIM exchange, see Section 6. When the server issues an EAP-Request/SIM/Notification that implies failure, the error cases include the following:
EAP-SIMサーバは、受信したEAP-SIM応答でエラーを検出した場合、サーバーは失敗を意味AT_NOTIFICATIONコードとEAP要求/ SIM /通知パケットを発行しなければなりません。デフォルトでは、サーバは、一般的なエラーコード（「認証後に一般的な失敗」（0）、または「一般失敗」（16384））のいずれかを使用しています。これら2つのコード間の選択は、EAP-SIM交換の段階に依存し、サーバーが障害を意味EAP要求/ SIM /通知を発行すると、セクション6を参照してください、エラーの場合には、次のものがあります。
o the server is not able to parse the peer's EAP response
Oサーバーは、ピアのEAP応答を解析することができません
o the server encounters a malformed attribute, a non-recognized non-skippable attribute, or a duplicate attribute
Oサーバは奇形の属性、非認識非スキップ可能属性、または重複した属性に遭遇しました
o a mandatory attribute is missing or an invalid attribute was included
O必須属性が欠落しているか、または無効な属性が含まれていました
o unrecognized or unexpected EAP-SIM Subtype in the EAP Response
EAP応答でO認識されていないか、予期しないEAP-SIMサブタイプ
o invalid AT_MAC. The server SHOULD log this event.
O AT_MACを無効。サーバーは、このイベントをログに記録すべきです。
o invalid AT_COUNTER
O無効AT_COUNTER
The EAP-SIM server sends EAP-Failure in two cases:
EAP-SIMサーバは、2つのケースでEAP-失敗を送信します。
1) In response to an EAP-Response/SIM/Client-Error packet the server has received from the peer, or
1）EAP-応答/ SIM /クライアントエラーパケットに応じてサーバがピアから受信した、または
2) Following an EAP-SIM notification round, when the AT_NOTIFICATION code implies failure.
AT_NOTIFICATIONコードが失敗を意味するとき2）、EAP-SIM通知ラウンドに続き。
The EAP-SIM server MUST NOT send EAP-Failure in cases other than these two. However, it should be noted that even though the EAP-SIM server would not send an EAP-Failure, an authorization decision that happens outside EAP-SIM, such as in the AAA server or in an intermediate AAA proxy, may result in a failed exchange.
EAP-SIMサーバは、これら2以外の場合にEAP-失敗を送ってはいけません。しかし、EAP-SIMサーバは、AAAサーバまたは中間AAAプロキシのように、EAP-失敗、EAP-SIMの外に起こるの認可決定を送信しませんにもかかわらず、失敗したをもたらすことができることに留意すべきです交換。
The peer MUST accept the EAP-Failure packet in case 1) and case 2), above. The peer SHOULD silently discard the EAP-Failure packet in other cases.
ピアは、上記）ケース1）とケース2にEAP-Failureパケットを受け入れなければなりません。ピアは黙って他のケースではEAP-失敗パケットを破棄すべきです。
On full authentication, the server can only send EAP-Success after the EAP/SIM/Challenge round. The peer MUST silently discard any EAP-Success packets if they are received before the peer has successfully authenticated the server and sent the EAP-Response/SIM/Challenge packet.
完全な認証では、サーバはEAP / SIM /挑戦ラウンド後にEAP-成功を送ることができます。それらが受信された場合、同輩が首尾よくサーバを認証し、EAP応答/ SIM /挑戦パケットを送信した前に、ピアは静かにどんなEAP-成功パケットを捨てなければなりません。
If the peer did not indicate that it wants to use protected success indications with AT_RESULT_IND (as discussed in Section 6.2) on full authentication, then the peer MUST accept EAP-Success after a successful EAP/SIM/Challenge round.
ピアは、それは完全な認証にAT_RESULT_IND（6.2節で述べたように）で保護された成功指摘を使用したいことを指示しなかった場合、ピアは成功したEAP / SIM /挑戦ラウンド後にEAP-成功を受け入れなければなりません。
If the peer indicated that it wants to use protected success indications with AT_RESULT_IND (as discussed in Section 6.2), then the peer MUST NOT accept EAP-Success after a successful EAP/SIM/Challenge round. In this case, the peer MUST only accept EAP-Success after receiving an EAP-SIM Notification with the AT_NOTIFICATION code "Success" (32768).
ピアは、それがAT_RESULT_IND（セクション6.2で議論するように）で保護された成功指摘を使用したいことが示された場合、ピアは成功したEAP / SIM /挑戦ラウンド後にEAP-成功を受け入れてはいけません。この場合、ピアは、AT_NOTIFICATIONコード「成功」（32768）とEAP-SIM通知を受信した後、EAP-成功を受け入れなければなりません。
On fast re-authentication, EAP-Success can only be sent after the EAP/SIM/Re-authentication round. The peer MUST silently discard any EAP-Success packets if they are received before the peer has successfully authenticated the server and sent the EAP-Response/SIM/Re-authentication packet.
速い再認証では、EAP-成功はEAP / SIM /再認証ラウンド後に送信することができます。それらが受信された場合、同輩が首尾よくサーバを認証し、EAP応答/ SIM /再認証パケットを送信した前に、ピアは静かにどんなEAP-成功パケットを捨てなければなりません。
If the peer did not indicate that it wants to use protected success indications with AT_RESULT_IND (as discussed in Section 6.2) on fast
ピアは、高速に（セクション6.2で議論するように）、それはAT_RESULT_INDで保護された成功指摘を使用したいことを指示しなかった場合
re-authentication, then the peer MUST accept EAP-Success after a successful EAP/SIM/Re-authentication round.
再認証、ピアは成功したEAP / SIM /再認証ラウンド後にEAP-成功を受け入れなければなりません。
If the peer indicated that it wants to use protected success indications with AT_RESULT_IND (as discussed in Section 6.2), then the peer MUST NOT accept EAP-Success after a successful EAP/SIM/Re-authentication round. In this case, the peer MUST only accept EAP-Success after receiving an EAP-SIM Notification with the AT_NOTIFICATION code "Success" (32768).
ピアは、それがAT_RESULT_IND（セクション6.2で議論するように）で保護された成功指摘を使用したいことが示された場合、ピアは成功したEAP / SIM /再認証ラウンド後にEAP-成功を受け入れてはいけません。この場合、ピアは、AT_NOTIFICATIONコード「成功」（32768）とEAP-SIM通知を受信した後、EAP-成功を受け入れなければなりません。
If the peer receives an EAP-SIM notification (Section 6) that indicates failure, then the peer MUST no longer accept the EAP-Success packet, even if the server authentication was successfully completed.
ピアが失敗を示すEAP-SIM通知（第6節）を受信した場合、ピアはもはやサーバ認証が正常に完了した場合でも、EAP-Successパケットを受け入れてはなりません。
This section specifies how keying material is generated.
このセクションでは、キーイング材料を生成する方法を指定します。
On EAP-SIM full authentication, a Master Key (MK) is derived from the underlying GSM authentication values (Kc keys), the NONCE_MT, and other relevant context as follows.
次のようにEAP-SIM完全な認証に、マスター鍵（MK）は、基礎となるGSM認証値（Kcのキー）、NONCE_MT、及び他の関連コンテキストから導出されます。
MK = SHA1(Identity|n*Kc| NONCE_MT| Version List| Selected Version)
MK = SHA1（アイデンティティ| N * Kcを| NONCE_MT |バージョン一覧|選択したバージョン）
In the formula above, the "|" character denotes concatenation. "Identity" denotes the peer identity string without any terminating null characters. It is the identity from the last AT_IDENTITY attribute sent by the peer in this exchange, or, if AT_IDENTITY was not used, it is the identity from the EAP-Response/Identity packet. The identity string is included as-is, without any changes. As discussed in Section 4.2.2.2, relying on EAP-Response/Identity for conveying the EAP-SIM peer identity is discouraged, and the server SHOULD use the EAP-SIM method-specific identity attributes.
上記の式において、「|」文字は連結を示しています。 「アイデンティティ」は、任意の終端のnull文字をせずに、ピアのID文字列を示しています。それは、この交換でピアによって送信された最後のAT_IDENTITY属性からのアイデンティティである、または、AT_IDENTITYが使用されなかった場合、それはEAP応答/アイデンティティパケットからアイデンティティです。アイデンティティ文字列は変更せず、そのまま含まれています。 EAP-応答に依存して、セクション4.2.2.2で論じたように/ EAP-SIMピアのアイデンティティを搬送するためのアイデンティティは推奨され、サーバはEAP-SIM法固有の識別属性を使用すべきです。
The notation n*Kc in the formula above denotes the n Kc values concatenated. The Kc keys are used in the same order as the RAND challenges in AT_RAND attribute. NONCE_MT denotes the NONCE_MT value (not the AT_NONCE_MT attribute, but only the nonce value). The Version List includes the 2-byte-supported version numbers from AT_VERSION_LIST, in the same order as in the attribute. The Selected Version is the 2-byte selected version from AT_SELECTED_VERSION. Network byte order is used, just as in the attributes. The hash function SHA-1 is specified in [SHA-1]. If several EAP/SIM/Start roundtrips are used in an EAP-SIM exchange, then the NONCE_MT, Version List and Selected version from the last EAP/SIM/Start round are used, and the previous EAP/SIM/Start rounds are ignored.
上記式中の記号N * KcがKcが連結された値Nを表します。 Kcの鍵はAT_RAND属性でRAND挑戦と同じ順序で使用されています。 NONCE_MTはNONCE_MT値（ないAT_NONCE_MT属性が、唯一のナンス値）を示しています。バージョンリストは、属性と同じ順序で、AT_VERSION_LISTから2バイト対応のバージョン番号が含まれています。選択したバージョンはAT_SELECTED_バージョンから2バイトの選択されたバージョンです。ネットワークバイトオーダーは単に属性のように、使用されています。ハッシュ関数SHA-1 [SHA-1]で指定されています。いくつかのEAP / SIM /スタート・ラウンドトリップがEAP-SIM交換に使用されている場合は、NONCE_MT、バージョン一覧と最後のEAP / SIM /から選択したバージョンは、ラウンドを開始します使用され、以前のEAP / SIM /スタートラウンドは無視されます。
The Master Key is fed into a Pseudo-Random number Function (PRF) which generates separate Transient EAP Keys (TEKs) for protecting EAP-SIM packets, as well as a Master Session Key (MSK) for link layer security, and an Extended Master Session Key (EMSK) for other purposes. On fast re-authentication, the same TEKs MUST be used for protecting EAP packets, but a new MSK and a new EMSK MUST be derived from the original MK and from new values exchanged in the fast re-authentication.
マスターキーは、リンク層セキュリティ、および拡張マスターのためのEAP-SIMパケットを保護するための別過渡EAPキー（のTEK）を生成する擬似乱数関数（PRF）、ならびにマスターセッションキー（MSK）に供給されます他の目的のためにセッションキー（EMSK）。速い再認証に、同一のTEKは、EAPパケットを保護するために使用されなければならないが、新しいMSKと新しいEMSKは速い再認証に交換元MKからの値と新しい値から導出されなければなりません。
EAP-SIM requires two TEKs for its own purposes; the authentication key K_aut is to be used with the AT_MAC attribute, and the encryption key K_encr is to be used with the AT_ENCR_DATA attribute. The same K_aut and K_encr keys are used in full authentication and subsequent fast re-authentications.
EAP-SIMは、自身の目的のために2つのTEKを必要とします。認証キーK_autはAT_MAC属性で使用される、および暗号化キーK_encrはAT_ENCR_DATA属性で使用されるべきです。同じK_autとK_encrキーが完全な認証とその後の速い再認証に使用されています。
Key derivation is based on the random number generation specified in NIST Federal Information Processing Standards (FIPS) Publication 186-2 [PRF]. The pseudo-random number generator is specified in the change notice 1 (2001 October 5) of [PRF] (Algorithm 1). As specified in the change notice (page 74), when Algorithm 1 is used as a general-purpose pseudo-random number generator, the "mod q" term in step 3.3 is omitted. The function G used in the algorithm is constructed via the Secure Hash Standard, as specified in Appendix 3.3 of the standard. It should be noted that the function G is very similar to SHA-1, but the message padding is different. Please refer to [PRF] for full details. For convenience, the random number algorithm with the correct modification is cited in Appendix B.
キー導出はNIST連邦情報処理規格（FIPS）186-2文献[PRF]で指定された乱数生成に基づいています。擬似乱数生成器は[PRF]（アルゴリズム1）の変更通知1（2001 10月5日）で指定されています。アルゴリズム1は、汎用の擬似乱数発生器として使用される変更通知（74ページ）で指定されているように、ステップ3.3において、「MOD Q」という用語は、省略されています。標準の付録3.3で指定されたアルゴリズムで使用される関数Gは、セキュアハッシュ規格を介して構成されています。関数Gは、SHA-1と非常に類似しているが、メッセージパディングが異なることに留意すべきです。完全な詳細については[PRF]を参照してください。便宜のために、正しい修飾と乱数アルゴリズムは、付録Bに引用されています
160-bit XKEY and XVAL values are used, so b = 160. On each full authentication, the Master Key is used as the initial secret seed-key XKEY. The optional user input values (XSEED_j) in step 3.1 are set to zero.
各完全な認証の160 = B、マスターキーは、初期秘密シード鍵XKEYとして使用されるように、160ビットXKEYとXVAL値が、使用されています。ステップ3.1において、オプションのユーザ入力値（XSEED_j）はゼロに設定されます。
On full authentication, the resulting 320-bit random numbers (x_0, x_1, ..., x_m-1) are concatenated and partitioned into suitable-sized chunks and used as keys in the following order: K_encr (128 bits), K_aut (128 bits), Master Session Key (64 bytes), Extended Master Session Key (64 bytes).
完全な認証に、320ビットの乱数を得（X_0、X_1、...、x_m-1）は、連結し、適当なサイズのチャンクに分割され、次の順序でキーとして使用される：K_encr（128ビット）、K_aut（ 128ビット）、マスターセッションキー（64バイト）、拡張マスタセッションキー（64バイト）。
On fast re-authentication, the same pseudo-random number generator can be used to generate a new Master Session Key and a new Extended Master Session Key. The seed value XKEY' is calculated as follows:
速い再認証では、同じ擬似乱数生成器は、新しいマスターセッションキーと新しい拡張マスターセッションキーを生成するために使用することができます。次のようにシード値XKEY」を計算されます。
XKEY' = SHA1(Identity|counter|NONCE_S| MK)
XKEY」= SHA1（アイデンティティ|カウンター| NONCE_S | MK）
In the formula above, the Identity denotes the fast re-authentication identity, without any terminating null characters, from the AT_IDENTITY attribute of the EAP-Response/SIM/Start packet, or, if
上記の式では、アイデンティティがあれば、EAP応答/ SIM /スタートパケットのAT_IDENTITY属性から、いずれかの終端のNULL文字をせずに、高速再認証アイデンティティを表し、または
EAP-Response/SIM/Start was not used on fast re-authentication, it denotes the identity string from the EAP-Response/Identity packet. The counter denotes the counter value from the AT_COUNTER attribute used in the EAP-Response/SIM/Re-authentication packet. The counter is used in network byte order. NONCE_S denotes the 16-byte NONCE_S value from the AT_NONCE_S attribute used in the EAP-Request/SIM/Re-authentication packet. The MK is the Master Key derived on the preceding full authentication.
EAP応答/ SIM /スタートが速い再認証に使用されていなかった、それはEAP応答/アイデンティティパケットからアイデンティティ文字列を示しています。カウンタは、EAP応答/ SIM /再認証パケットで使用されるAT_COUNTER属性からカウンタ値を示しています。カウンタはネットワークバイトオーダーに使用されています。 NONCE_Sは、EAP要求/ SIM /再認証パケットで使用されるAT_NONCE_S属性から16バイトNONCE_S値を示しています。 MKは前の完全な認証のときに得られたマスターキーです。
On fast re-authentication, the pseudo-random number generator is run with the new seed value XKEY', and the resulting 320-bit random numbers (x_0, x_1, ..., x_m-1) are concatenated and partitioned into two 64-byte chunks and used as the new 64-byte Master Session Key and the new 64-byte Extended Master Session Key. Note that because K_encr and K_aut are not derived on fast re-authentication, the Master Session Key and the Extended Master Session key are obtained from the beginning of the key stream (x_0, x_1, ...).
速い再認証に、擬似乱数発生器は、2つの64に連結され、分配された新しいシード値XKEY」、得られた320ビットの乱数（X_0、X_1、...、x_m-1）で実行され-byteチャンクと新しい64バイトのマスターセッションキーと新しい64バイトの拡張マスターセッションキーとして使用します。 K_encrとK_autが速い再認証に誘導されたものではないので、マスターセッションキーと拡張マスターセッションキーは、キーストリーム（X_0、X_1、...）の先頭から取得されることに注意してください。
The first 32 bytes of the MSK can be used as the Pairwise Master Key (PMK) for IEEE 802.11i.
MSKの最初の32のバイトはIEEE 802.11iのためのペアワイズマスターキー（PMK）として使用することができます。
When the RADIUS attributes specified in [RFC2548] are used to transport keying material, then the first 32 bytes of the MSK correspond to MS-MPPE-RECV-KEY and the second 32 bytes to MS-MPPE-SEND-KEY. In this case, only 64 bytes of keying material (the MSK) are used.
[RFC2548]で指定されたRADIUS属性が材料を合わせる輸送するために使用される場合、次いで、MSKの最初の32のバイトは、MS-MPPE-RECV-KEYおよびMS-MPPE-SEND-KEYの第32バイトに対応します。この場合、鍵材料（MSK）のわずか64バイトが使用されます。
When generating the initial Master Key, the hash function is used as a mixing function to combine several session keys (Kc's) generated by the GSM authentication procedure and the random number NONCE_MT into a single session key. There are several reasons for this. The current GSM session keys are, at most, 64 bits, so two or more of them are needed to generate a longer key. By using a one-way function to combine the keys, we are assured that, even if an attacker managed to learn one of the EAP-SIM session keys, it wouldn't help him in learning the original GSM Kc's. In addition, since we include the random number NONCE_MT in the calculation, the peer is able to verify that the EAP-SIM packets it receives from the network are fresh and not replays (also see Section 11).
初期マスターキーを生成する際、ハッシュ関数は、単一のセッション鍵にGSM認証手続き及び乱数NONCE_MTによって生成されたいくつかのセッション鍵（Kcの者）を結合する混合関数として使用されます。これにはいくつかの理由があります。現在のGSMセッションキーは、最大で、64ビットであるので、それらの2つ以上は、長い鍵を生成するために必要とされます。キーを組み合わせること一方向関数を使用することにより、我々は、攻撃者は、EAP-SIMセッションキーのいずれかを学ぶことができたとしても、それは本来のGSM Kcの者を学んで彼を助けないだろう、と確信しています。我々は計算に乱数NONCE_MTを含むために加えて、ピアは、ネットワークから受信したEAP-SIMパケットは新鮮でないリプレイであることを確認することが可能である（また、セクション11を参照）。
As specified in [RFC3748], EAP packets begin with the Code, Identifiers, Length, and Type fields, which are followed by EAP-method-specific Type-Data. The Code field in the EAP header is set to 1 for EAP requests, and to 2 for EAP Responses. The usage of the
[RFC3748]で指定されるように、EAPパケットはEAPメソッド固有のタイプのデータが続くコード、識別子、長さ、タイプフィールド、で始まります。 EAPヘッダーのコードフィールドは、EAP要求を1に設定し、EAP応答の2です。の使い方
Length and Identifier fields in the EAP header are also specified in [RFC3748]. In EAP-SIM, the Type field is set to 18.
EAPヘッダーの長さと識別子フィールドはまた、[RFC3748]に規定されています。 EAP-SIMでは、タイプフィールドが18に設定されています。
In EAP-SIM, the Type-Data begins with an EAP-SIM header that consists of a 1-octet Subtype field and a 2-octet reserved field. The Subtype values used in EAP-SIM are defined in the IANA considerations section of the EAP-AKA specification [EAP-AKA]. The formats of the EAP header and the EAP-SIM header are shown below.
EAP-SIMにおいて、タイプデータは1オクテットのサブタイプフィールド及び2オクテットの予約フィールドから成るEAP-SIMヘッダから始まります。 EAP-SIMで使用されるサブタイプ値は、EAP-AKA仕様[EAP-AKA]のIANA問題部に定義されています。 EAPヘッダーとEAP-SIMヘッダのフォーマットを以下に示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The rest of the Type-Data that immediately follows the EAP-SIM header consists of attributes that are encoded in Type, Length, Value format. The figure below shows the generic format of an attribute.
直ちにEAP-SIMヘッダーに続くタイプ - データの残りの部分は、タイプ、長さ、値の形式でエンコードされた属性から成ります。下の図は、属性の一般的なフォーマットを示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attribute Type
属性タイプ
Indicates the particular type of attribute. The attribute type
values are listed in the IANA considerations section of the
EAP-AKA specification [EAP-AKA].
Length
長さ
Indicates the length of this attribute in multiples of four
bytes. The maximum length of an attribute is 1024 bytes. The
length includes the Attribute Type and Length bytes.
Value
値
The particular data associated with this attribute. This field
is always included and it may be two or more bytes in length.
The type and length fields determine the format and length
of the value field.
Attributes numbered within the range 0 through 127 are called non-skippable attributes. When an EAP-SIM peer encounters a non-skippable attribute that the peer does not recognize, the peer MUST send the EAP-Response/SIM/Client-Error packet, which terminates the authentication exchange. If an EAP-SIM server encounters a non-skippable attribute that the server does not recognize, then the server sends the EAP-Request/SIM/Notification packet with an AT_NOTIFICATION code, which implies general failure ("General failure after authentication" (0), or "General failure" (16384), depending on the phase of the exchange), which terminates the authentication exchange.
127までの範囲内で0番の属性がスキップ不可属性と呼ばれます。 EAP-SIMのピアは、ピアが認識しないことをスキップ不可能な属性を検出すると、ピアは認証交換を終了EAP応答/ SIM /クライアントエラーパケットを送信しなければなりません。 EAP-SIMサーバは、サーバが認識しないことをスキップ不可能な属性に遭遇した場合、サーバは、一般的な失敗を意味AT_NOTIFICATIONコードとEAP要求/ SIM /通知パケット、（「認証後に一般的な失敗」を送信します（0認証交換を終了エクスチェンジ）、の位相に応じて）、または「一般失敗」（16384）、。
Attributes within the range of 128 through 255 are called skippable attributes. When a skippable attribute is encountered and is not recognized, it is ignored. The rest of the attributes and message data MUST still be processed. The Length field of the attribute is used to skip the attribute value in searching for the next attribute.
128〜255の範囲内の属性は、スキップ可能な属性と呼ばれています。スキップ可能な属性が検出されたと認識されていない場合、それは無視されます。属性とメッセージデータの残りの部分は、まだ処理しなければなりません。属性の長さフィールドは、次の属性を検索する際に、属性値をスキップするために使用されます。
Unless otherwise specified, the order of the attributes in an EAP-SIM message is insignificant and an EAP-SIM implementation should not assume a certain order to be used.
特に断りのない限り、EAP-SIMメッセージ内の属性の順序は重要ではないとEAP-SIMの実装では、使用する特定の順序を想定してはなりません。
Attributes can be encapsulated within other attributes. In other words, the value field of an attribute type can be specified to contain other attributes.
属性は他の属性内にカプセル化することができます。言い換えれば、属性タイプの値フィールドは、他の属性を含むように指定することができます。
EAP-SIM can be extended by specifying new attribute types. If skippable attributes are used, it is possible to extend the protocol without breaking old implementations.
EAP-SIMは、新しい属性タイプを指定することによって拡張することができます。スキップ可能な属性が使用されている場合、昔の実装を壊すことなく、プロトコルを拡張することが可能です。
However, any new attributes added to the EAP-Request/SIM/Start or EAP-Response/SIM/Start packets would not be integrity-protected. Therefore, these messages MUST NOT be extended in the current version of EAP-SIM. If the list of supported EAP-SIM versions in the AT_VERSION_LIST does not include versions other than 1, then the server MUST NOT include attributes other than those specified in this document in the EAP-Request/SIM/Start message. Note that future versions of this protocol might specify new attributes for EAP-Request/SIM/Start and still support version 1 of the protocol. In this case, the server might send an EAP-Request/SIM/Start message that includes new attributes and indicates support for protocol version 1 and other versions in the AT_VERSION_LIST attribute. If the peer selects version 1, then the peer MUST ignore any other attributes included in EAP-Request/SIM/Start, other than those specified in this document. If the selected EAP-SIM version in peer's AT_SELECTED_VERSION is 1, then the peer MUST NOT include other attributes aside from those specified in this document in the EAP-Response/SIM/Start message.
しかし、EAP要求/ SIM /スタートまたはEAP-レスポンスに追加された新しい属性は、/ SIM / Startパケットは、整合性が保護されないでしょう。したがって、これらのメッセージは、EAP-SIMの現在のバージョンで拡張されてはなりません。 AT_VERSION_LISTでサポートされているEAP-SIMバージョンのリストが1以外のバージョンが含まれていない場合、サーバは、EAP要求/ SIM /開始メッセージに、この文書で指定されたもの以外の属性を含んではいけません。このプロトコルの将来のバージョンは、EAP要求/ SIM /スタートのための新しい属性を指定すると、まだプロトコルのバージョン1をサポートするかもしれないことに注意してください。この場合、サーバは、新しい属性が含まれており、プロトコルバージョン1とAT_VERSION_LIST属性で他のバージョンのサポートを示しEAP要求/ SIM /開始メッセージを送信することがあります。ピアは、バージョン1を選択した場合、ピアは、この文書で指定されている以外のEAP要求/ SIM /スタート、中に含まれる任意の他の属性を無視しなければなりません。ピアのAT_SELECTED_バージョンでは、選択したEAP-SIMのバージョンが1である場合、ピアはEAP応答/ SIM /開始メッセージに、この文書で指定されたものとは別に、他の属性を含んではいけません。
When specifying new attributes, it should be noted that EAP-SIM does not support message fragmentation. Hence, the sizes of the new extensions MUST be limited so that the maximum transfer unit (MTU) of the underlying lower layer is not exceeded. According to [RFC3748], lower layers must provide an EAP MTU of 1020 bytes or greater, so any extensions to EAP-SIM SHOULD NOT exceed the EAP MTU of 1020 bytes.
新しい属性を指定する場合、EAP-SIMは、メッセージの断片化をサポートしていないことに留意すべきです。基礎をなす下位層の最大転送単位（MTU）を超えないように、したがって、新しい拡張のサイズは制限されなければなりません。 [RFC3748]によれば、下部層1020バイト以上のEAP MTUを提供しなければならないので、EAP-SIMへの拡張1020バイトのEAP MTUを超えてはなりません。
Because EAP-SIM supports version negotiation, new versions of the protocol can also be specified by using a new version number.
EAP-SIMがバージョン交渉をサポートしているため、プロトコルの新しいバージョンは、新しいバージョン番号を使用して指定することができます。
This section specifies the messages used in EAP-SIM. 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. The general message format is specified in Section 8.1.
このセクションでは、EAP-SIMで使用されるメッセージを指定します。メッセージが送信または受け入れられる場合には、属性がメッセージに必要とされるメッセージ、および他のメッセージの特定の詳細に許可されている属性を指定します。一般的なメッセージフォーマットはセクション8.1で指定されています。
In full authentication the first SIM-specific EAP Request is EAP-Request/SIM/Start. The EAP/SIM/Start roundtrip is used for two purposes. In full authentication this packet is used to request the peer to send the AT_NONCE_MT attribute to the server. In addition, as specified in Section 4.2, the Start round trip may be used by the server for obtaining the peer identity. As discussed in Section 4.2, several Start rounds may be required to obtain a valid peer identity.
完全な認証では最初のSIM固有のEAP要求は、EAP要求/ SIM /スタートです。 EAP / SIM /スタート往復は2つの目的のために使用されています。完全な認証では、このパケットはサーバにAT_NONCE_MT属性を送信するためにピアを要求するために使用されます。また、セクション4.2で指定されるように、スタートラウンドトリップは、ピアのアイデンティティを得るためにサーバによって使用されてもよいです。 4.2節で述べたように、いくつかのスタートラウンドは有効なピアIDを取得する必要があります。
The server MUST always include the AT_VERSION_LIST attribute.
サーバーは常にAT_VERSION_LIST属性を含まなければなりません。
The server MAY include one of the following identity-requesting attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ. These three attributes are mutually exclusive, so the server MUST NOT include more than one of the attributes.
AT_PERMANENT_ID_REQ、AT_FULLAUTH_ID_REQ、または_どんなAT__ID REQ：サーバーには、次のアイデンティティを要求する属性の1つを含むことができます。これらの3つの属性は相互に排他的であるため、サーバーは、属性を複数含んではいけません。
If the server has received a response from the peer, it MUST NOT issue a new EAP-Request/SIM/Start packet if it has previously issued an EAP-Request/SIM/Start message either without any identity requesting attributes or with the AT_PERMANENT_ID_REQ attribute.
サーバは、ピアからの応答を受信した場合、それは以前に属性を要求する任意のアイデンティティなしまたはAT_PERMANENT_ID_REQ属性でいずれかのEAP要求/ SIM / Startメッセージを発行した場合、それは新しいEAP要求/ SIM /スタートパケットを発行してはなりません。
If the server has received a response from the peer, it MUST NOT issue a new EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ or AT_FULLAUTH_ID_REQ attributes if it has previously issued an EAP-Request/SIM/Start message with the AT_FULLAUTH_ID_REQ attribute.
サーバは、ピアからの応答を受信した場合、それは以前にAT_FULLAUTH_ID_REQ属性を持つEAP要求/ SIM / Startメッセージを発行した場合_どんなAT__ID REQまたはAT_FULLAUTH_ID_REQ持つ新しいEAP要求/ SIM /スタートパケットの属性を発行してはなりません。
If the server has received a response from the peer, it MUST NOT issue a new EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ attribute if the server has previously issued an EAP-Request/SIM/Start message with the AT_ANY_ID_REQ attribute.
サーバは、ピアからの応答を受信した場合、サーバが以前に_どんなAT__ID REQ属性を持つEAP要求/ SIM / Startメッセージを発行した場合、それは_どんなAT__ID REQ属性を持つ新しいEAP要求/ SIM /スタートパケットを発行してはいけません。
This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.
このメッセージはAT_MAC、AT_IV、またはAT_ENCR_DATAを含んではいけません。
The peer sends EAP-Response/SIM/Start in response to a valid EAP-Request/SIM/Start from the server.
ピアは、サーバから有効なEAP要求/ SIM /スタートに応じて/スタートEAP応答/ SIMを送信します。
If and only if the server's EAP-Request/SIM/Start includes one of the identity-requesting attributes, then the peer MUST include the AT_IDENTITY attribute. The usage of AT_IDENTITY is defined in Section 4.2.
そして、サーバのEAP要求/ SIM / Startがアイデンティティ要求のいずれかの属性が含まれている場合にのみ場合、ピアはAT_IDENTITY属性を含まなければなりません。 AT_IDENTITYの使用はセクション4.2で定義されています。
The AT_NONCE_MT attribute MUST NOT be included if the AT_IDENTITY with a fast re-authentication identity is present for fast re-authentication. AT_NONCE_MT MUST be included in all other cases (full authentication).
速い再認証のアイデンティティを持つAT_IDENTITYが速い再認証のために存在している場合AT_NONCE_MT属性を含んではいけません。 AT_NONCE_MTは、他のすべての例（完全な認証）に含まれなければなりません。
The AT_SELECTED_VERSION attribute MUST NOT be included if the AT_IDENTITY attribute with a fast re-authentication identity is present for fast re-authentication. In all other cases, AT_SELECTED_VERSION MUST be included (full authentication). This attribute is used in version negotiation, as specified in Section 4.1.
速い再認証のアイデンティティを持つAT_IDENTITY属性が速い再認証のために存在している場合AT_SELECTED_バージョン属性を含んではいけません。他のすべてのケースでは、AT_SELECTED_バージョンは、（完全な認証）に含まれなければなりません。セクション4.1で指定されるこの属性は、バージョン交渉で使用されています。
This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.
このメッセージはAT_MAC、AT_IV、またはAT_ENCR_DATAを含んではいけません。
The server sends the EAP-Request/SIM/Challenge after receiving a valid EAP-Response/SIM/Start that contains AT_NONCE_MT and AT_SELECTED_VERSION, and after successfully obtaining the subscriber identity.
サーバがEAP要求/ SIM /挑戦AT_NONCE_MTとAT_SELECTED_バージョンが含まれている有効なEAP応答/ SIM /スタートを受け取った後に送信し、成功した加入者識別を得た後。
The AT_RAND attribute MUST be included.
AT_RAND属性を含まなければなりません。
The AT_RESULT_IND attribute MAY be included. The usage of this attribute is discussed in Section 6.2.
AT_RESULT_IND属性が含まれるかもしれません。この属性の使用方法は、セクション6.2で議論されています。
The AT_MAC attribute MUST be included. For EAP-Request/SIM/Challenge, the MAC code is calculated over the following data:
AT_MAC属性を含まなければなりません。 EAP-要求に対して/ SIM /チャレンジは、MACコードは、次のデータに対して計算されます。
EAP packet| NONCE_MT
EAPパケット| NONCE_MT
The EAP packet is represented as specified in Section 8.1. It is followed by the 16-byte NONCE_MT value from the peer's AT_NONCE_MT attribute.
8.1節で指定されたEAPパケットが示されています。これは、ピアのAT_NONCE_MT属性から16バイトのNONCE_MT値が続いています。
The EAP-Request/SIM/Challenge packet MAY include encrypted attributes for identity privacy and for communicating the next fast re-authentication identity. In this case, the AT_IV and AT_ENCR_DATA attributes are included (Section 10.12).
EAP要求/ SIM /挑戦パケットはアイデンティティプライバシーのために、次の速い再認証のアイデンティティを通信するための暗号化された属性を含むかもしれません。この場合、AT_IVとAT_ENCR_DATA属性は（セクション10.12）が含まれています。
The plaintext of the AT_ENCR_DATA value field consists of nested attributes. The nested attributes MAY include AT_PADDING (as specified in Section 10.12). If the server supports identity privacy and wants to communicate a pseudonym to the peer for the next full authentication, then the nested encrypted attributes include the AT_NEXT_PSEUDONYM attribute. If the server supports re-authentication and wants to communicate a fast re-authentication identity to the peer, then the nested encrypted attributes include the AT_NEXT_REAUTH_ID attribute.
AT_ENCR_DATA値フィールドの平文は、ネストされた属性で構成されます。 （セクション10.12で指定）ネストされた属性はAT_PADDINGを含むかもしれません。サーバはアイデンティティプライバシーをサポートし、次の完全な認証のためにピアに仮名を通信したい場合は、ネストされた暗号化された属性はAT_NEXT_PSEUDONYM属性が含まれます。サーバが再認証をサポートし、ピアに速い再認証のアイデンティティを通信したい場合は、ネストされた暗号化された属性はAT_ネクスト_REAUTH_ID属性が含まれます。
When processing this message, the peer MUST process AT_RAND before processing other attributes. Only if AT_RAND is verified to be valid, the peer derives keys and verifies AT_MAC. The operation in case an error occurs is specified in Section 6.3.1.
このメッセージを処理する場合、ピアは、他の属性を処理する前にAT_RANDを処理しなければなりません。 AT_RANDが有効であることが確認された場合にのみ、ピアは、キーを導出し、AT_MACを検証します。エラーが発生した場合の動作はセクション6.3.1で指定されています。
The peer sends EAP-Response/SIM/Challenge in response to a valid EAP-Request/SIM/Challenge.
ピアは有効なEAP要求/ SIM /挑戦に応じて、EAP応答/ SIM /挑戦を送ります。
Sending this packet indicates that the peer has successfully authenticated the server and that the EAP exchange will be accepted by the peer's local policy. Hence, if these conditions are not met, then the peer MUST NOT send EAP-Response/SIM/Challenge, but the peer MUST send EAP-Response/SIM/Client-Error.
このパケットを送信すると、同輩が首尾よくサーバを認証し、EAP交換が同輩のローカルの方針で受け入れられることをしていることを示しています。したがって、これらの条件が満たされていない場合は、その後、ピアはEAP応答/ SIM /挑戦を送ってはいけませんが、ピアはEAP応答/ SIM /クライアントエラーを送らなければなりません。
The AT_MAC attribute MUST be included. For EAP-Response/SIM/Challenge, the MAC code is calculated over the following data:
AT_MAC属性を含まなければなりません。 EAP-応答/ SIM /チャレンジのために、MACコードは、以下のデータに対して計算されます。
EAP packet| n*SRES
EAPパケット| N * SRES
The EAP packet is represented as specified in Section 8.1. The EAP packet bytes are immediately followed by the two or three SRES values concatenated, denoted above with the notation n*SRES. The SRES values are used in the same order as the corresponding RAND challenges in the server's AT_RAND attribute.
8.1節で指定されたEAPパケットが示されています。 EAPパケットバイトが直ちに表記N * SRESと上方に示さ連結二、三SRES値、が続きます。 SRES値は、サーバーのAT_RAND属性に対応するRAND挑戦と同じ順序で使用されています。
The AT_RESULT_IND attribute MAY be included if it was included in EAP-Request/SIM/Challenge. The usage of this attribute is discussed in Section 6.2.
それがEAP要求/ SIM /挑戦に含まれていたなら、AT_RESULT_IND属性が含まれるかもしれません。この属性の使用方法は、セクション6.2で議論されています。
Later versions of this protocol MAY make use of the AT_ENCR_DATA and AT_IV attributes in this message to include encrypted (skippable) attributes. The EAP server MUST process EAP-Response/SIM/Challenge messages that include these attributes even if the server did not implement these optional attributes.
このプロトコルの後のバージョンはAT_ENCR_DATAを利用することができるとAT_IVは暗号化された（スキップ可能）属性を含めるには、このメッセージの属性。 EAPサーバは、サーバがこれらの任意の属性を実装していない場合でも、これらの属性が含まれるEAP応答/ SIM /挑戦メッセージを処理しなければなりません。
The server sends the EAP-Request/SIM/Re-authentication message if it wants to use fast re-authentication, and if it has received a valid fast re-authentication identity in EAP-Response/Identity or EAP-Response/SIM/Start.
それは速い再認証を使用したい場合は、サーバーは、EAP要求/ SIM /再認証メッセージを送信し、それはEAP応答/アイデンティティまたはEAP応答/ SIM /スタートで有効な速い再認証IDを受信した場合。
AT_MAC MUST be included. No message-specific data is included in the MAC calculation. See Section 10.14.
AT_MACを含まなければなりません。いいえメッセージ固有のデータは、MAC計算に含まれません。セクション10.14を参照してください。
The AT_RESULT_IND attribute MAY be included. The usage of this attribute is discussed in Section 6.2.
AT_RESULT_IND属性が含まれるかもしれません。この属性の使用方法は、セクション6.2で議論されています。
The AT_IV and AT_ENCR_DATA attributes MUST be included. The plaintext consists of the following nested encrypted attributes, which MUST be included: AT_COUNTER and AT_NONCE_S. In addition, the nested encrypted attributes MAY include the following attributes: AT_NEXT_REAUTH_ID and AT_PADDING.
AT_IVとAT_ENCR_DATA属性を含まなければなりません。 AT_COUNTERとAT_NONCE_S：平文が含まれなければならない次のネストされた暗号化された属性で構成されています。 AT_ネクスト_REAUTH_IDとAT_PADDING：また、ネストされた暗号化された属性は、次の属性を含むかもしれません。
The client sends the EAP-Response/SIM/Re-authentication packet in response to a valid EAP-Request/SIM/Re-authentication.
クライアントは有効なEAP要求/ SIM /再認証に応じて、EAP応答/ SIM /再認証パケットを送信します。
The AT_MAC attribute MUST be included. For EAP-Response/SIM/Re-authentication, the MAC code is calculated over the following data:
AT_MAC属性を含まなければなりません。 EAP-応答/ SIM /再認証のために、MACコードは、以下のデータに対して計算されます。
EAP packet| NONCE_S
EAPパケット| NONCE_S
The EAP packet is represented as specified in Section 8.1. It is followed by the 16-byte NONCE_S value from the server's AT_NONCE_S attribute.
8.1節で指定されたEAPパケットが示されています。これは、サーバーのAT_NONCE_S属性から16バイトNONCE_S値が続いています。
The AT_IV and AT_ENCR_DATA attributes MUST be included. The nested encrypted attributes MUST include the AT_COUNTER attribute. The AT_COUNTER_TOO_SMALL attribute MAY be included in the nested encrypted attributes, and it is included in cases specified in Section 5. The AT_PADDING attribute MAY be included.
AT_IVとAT_ENCR_DATA属性を含まなければなりません。ネストされた暗号化された属性は、AT_COUNTER属性を含まなければなりません。 AT_COUNTER_TOO_SMALL属性は、ネストされた暗号化された属性に含まれるかもしれ、それはAT_PADDING属性が含まれるかもしれセクション5で指定された場合に含まれています。
The AT_RESULT_IND attribute MAY be included if it was included in EAP-Request/SIM/Re-authentication. The usage of this attribute is discussed in Section 6.2.
それがEAP要求/ SIM /再認証に含まれていたなら、AT_RESULT_IND属性が含まれるかもしれません。この属性の使用方法は、セクション6.2で議論されています。
Sending this packet without AT_COUNTER_TOO_SMALL indicates that the peer has successfully authenticated the server and that the EAP exchange will be accepted by the peer's local policy. Hence, if these conditions are not met, then the peer MUST NOT send EAP-Response/SIM/Re-authentication, but the peer MUST send EAP-Response/SIM/Client-Error.
AT_COUNTER_TOO_SMALLせずにこのパケットを送信すると、同輩が首尾よくサーバを認証して、EAP交換が同輩のローカルの方針で受け入れられることを示しています。したがって、これらの条件が満たされていない場合、ピアは再認証EAP応答/ SIMを/送ってはいけませんが、ピアはEAP応答/ SIM /クライアントエラーを送らなければなりません。
The peer sends EAP-Response/SIM/Client-Error in error cases, as specified in Section 6.3.1.
6.3.1節で指定されたピアは、エラーの場合にEAP応答/ SIM /クライアントエラーを送信します。
The AT_CLIENT_ERROR_CODE attribute MUST be included.
AT_CLIENT_ERROR_CODE属性を含まなければなりません。
The AT_MAC, AT_IV, or AT_ENCR_DATA attributes MUST NOT be used with this packet.
AT_MAC、AT_IV、またはAT_ENCR_DATA属性このパケットを使用してはいけません。
The usage of this message is specified in Section 6. The AT_NOTIFICATION attribute MUST be included.
このメッセージの使用はAT_NOTIFICATION属性が含まれなければならないセクション6で指定されています。
The AT_MAC attribute MUST be included if the P bit of the notification code in AT_NOTIFICATION is set to zero, and MUST NOT be included in cases when the P bit is set to one. The P bit is discussed in Section 6.
AT_NOTIFICATIONに通知コードのPビットがゼロに設定され、Pビットが1にセットされたときのケースに含まれていない必要がある場合AT_MAC属性を含まなければなりません。 Pビットはセクション6で説明されています。
No message-specific data is included in the MAC calculation. See Section 10.14.
いいえメッセージ固有のデータは、MAC計算に含まれません。セクション10.14を参照してください。
If EAP-Request/SIM/Notification is used on a fast re-authentication exchange, and if the P bit in AT_NOTIFICATION is set to zero, then AT_COUNTER is used for replay protection. In this case, the AT_ENCR_DATA and AT_IV attributes MUST be included, and the encapsulated plaintext attributes MUST include the AT_COUNTER attribute. The counter value included in AT_COUNTER MUST be the same as in the EAP-Request/SIM/Re-authentication packet on the same fast re-authentication exchange.
場合EAPリクエスト/ SIM /通知が速い再認証交換に使用され、そしてAT_NOTIFICATIONのPビットがゼロに設定されている場合、AT_COUNTERはリプレイ保護のために使用されます。この場合、AT_ENCR_DATAとAT_IVが含まれなければならない属性、およびカプセル化された平文の属性はAT_COUNTER属性を含まなければなりません。 AT_COUNTERに含まれるカウンタ値は同じ速い再認証交換にEAP要求/ SIM /再認証パケットと同じでなければなりません。
The usage of this message is specified in Section 6. This packet is an acknowledgement of EAP-Request/SIM/Notification.
このメッセージの使用は、このパケットはEAP-要求/ SIM /通知の確認応答である、セクション6で指定されています。
The AT_MAC attribute MUST be included in cases when the P bit of the notification code in AT_NOTIFICATION of EAP-Request/SIM/Notification is set to zero, and MUST NOT be included in cases when the P bit is set to one. The P bit is discussed in Section 6.
EAPリクエスト/ SIM /通知のAT_NOTIFICATIONに通知コードのPビットがゼロに設定され、Pビットが1にセットされたときのケースに含まれていない必要がある場合。AT_MAC属性は、ケース内に含まれなければなりませんPビットはセクション6で説明されています。
No message-specific data is included in the MAC calculation, see Section 10.14.
いいえメッセージ固有のデータはMAC計算に含まれていない、セクション10.14を参照してください。
If EAP-Request/SIM/Notification is used on a fast re-authentication exchange, and if the P bit in AT_NOTIFICATION is set to zero, then AT_COUNTER is used for replay protection. In this case, the AT_ENCR_DATA and AT_IV attributes MUST be included, and the encapsulated plaintext attributes MUST include the AT_COUNTER attribute. The counter value included in AT_COUNTER MUST be the same as in the EAP-Request/SIM/Re-authentication packet on the same fast re-authentication exchange.
場合EAPリクエスト/ SIM /通知が速い再認証交換に使用され、そしてAT_NOTIFICATIONのPビットがゼロに設定されている場合、AT_COUNTERはリプレイ保護のために使用されます。この場合、AT_ENCR_DATAとAT_IVが含まれなければならない属性、およびカプセル化された平文の属性はAT_COUNTER属性を含まなければなりません。 AT_COUNTERに含まれるカウンタ値は同じ速い再認証交換にEAP要求/ SIM /再認証パケットと同じでなければなりません。
This section specifies the format of message attributes. The attribute type numbers are specified in the IANA considerations section of the EAP-AKA specification [EAP-AKA].
このセクションでは、メッセージ属性の形式を指定します。属性タイプ番号はEAP-AKA仕様[EAP-AKA]のIANA問題部で指定されています。
The following table provides a guide to which attributes may be found in which kinds of messages, and in what quantity. Messages are denoted with numbers in parentheses as follows: (1) EAP-Request/SIM/Start, (2) EAP-Response/SIM/Start, (3) EAP-Request/SIM/Challenge, (4) EAP-Response/SIM/Challenge, (5) EAP-Request/SIM/Notification, (6) EAP-Response/SIM/Notification, (7) EAP-Response/SIM/Client-Error, (8) EAP-Request/SIM/Re-authentication, and (9) EAP-Response/SIM/Re-authentication. The column denoted with "Encr" indicates whether the attribute is a nested attribute that MUST be included within AT_ENCR_DATA, and the column denoted with "Skip" indicates whether the attribute is a skippable attribute.
以下の表は、属性メッセージの種類のもので、どのような量で見出されてもよいためのガイドを提供します。次のようにメッセージが括弧内の数字で示されている：（1）EAP-リクエスト/ SIM /開始、（2）EAP-応答/ SIM /スタート、（3）EAPリクエスト/ SIM /チャレンジ（4）EAP応答/ SIM /チャレンジ（5）EAPリクエスト/ SIM /通知、（6）EAP-応答/ SIM /通知、（7）EAP-応答/ SIM /クライアントエラー、（8）EAPリクエスト/ SIM /再認証、および（9）EAP応答/ SIM /再認証。 「ENCR」で示す列は、属性がAT_ENCR_DATA内に含まれなければならない、ネストされた属性であり、「スキップ」で示す列は属性がスキップ可能な属性であるかどうかを示すかどうかを示します。
"0" indicates that the attribute MUST NOT be included in the message, "1" indicates that the attribute MUST be included in the message, "0-1" indicates that the attribute is sometimes included in the message, and "0*" indicates that the attribute is not included in the message in cases specified in this document, but MAY be included in future versions of the protocol.
「0」、「1」属性がメッセージに含まれなければならないことを示し、属性がメッセージに含まれてはならないことを意味し、「0-1」属性が時々メッセージに含まれていることを示し、「0 *」属性は、この文書で指定された場合には、メッセージに含まれていませんが、プロトコルの将来のバージョンに含まれる可能性があることを示します。
Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) Encr Skip AT_VERSION_LIST 1 0 0 0 0 0 0 0 0 N N AT_SELECTED_VERSION 0 0-1 0 0 0 0 0 0 0 N N AT_NONCE_MT 0 0-1 0 0 0 0 0 0 0 N N AT_PERMANENT_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N AT_ANY_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N AT_FULLAUTH_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N AT_IDENTITY 0 0-1 0 0 0 0 0 0 0 N N AT_RAND 0 0 1 0 0 0 0 0 0 N N AT_NEXT_PSEUDONYM 0 0 0-1 0 0 0 0 0 0 Y Y AT_NEXT_REAUTH_ID 0 0 0-1 0 0 0 0 0-1 0 Y Y AT_IV 0 0 0-1 0* 0-1 0-1 0 1 1 N Y AT_ENCR_DATA 0 0 0-1 0* 0-1 0-1 0 1 1 N Y AT_PADDING 0 0 0-1 0* 0-1 0-1 0 0-1 0-1 Y N AT_RESULT_IND 0 0 0-1 0-1 0 0 0 0-1 0-1 N Y AT_MAC 0 0 1 1 0-1 0-1 0 1 1 N N AT_COUNTER 0 0 0 0 0-1 0-1 0 1 1 Y N AT_COUNTER_TOO_SMALL 0 0 0 0 0 0 0 0 0-1 Y N AT_NONCE_S 0 0 0 0 0 0 0 1 0 Y N AT_NOTIFICATION 0 0 0 0 1 0 0 0 0 N N AT_CLIENT_ERROR_CODE 0 0 0 0 0 0 1 0 0 N N
項目（1）（2）（3）（4）（5）（6）（7）（8）（9）ENCRスキップAT_VERSION_LIST 1 0 0 0 0 0 0 0 0 NN AT_SELECTED_バージョン0 0-1 0 0 0 0 0 0 NN AT_NONCE_MT 0 0-1 0 0 0 0 0 0 0 NN AT_PERMANENT_ID_REQ 0-1 0 0 0 0 0 0 0 0 NN _どんなAT__ID REQ 0-1 0 0 0 0 0 0 0 0 NN AT_FULLAUTH_ID_REQ 0-1 0 0 0 0 0 0 0 NN AT_IDENTITY 0 0-1 0 0 0 0 0 0 0 NN AT_RAND 0 0 1 0 0 0 0 0 0 NN AT_NEXT_PSEUDONYM 0 0-1 0 0 0 0 0 0 YYのAT_ネクスト_REAUTH_ID 0 0 0 0-1 0 0 0 0-1 0 YY AT_IV 0 0 0 0-1 * 0-1 0-1 0 1 1 NY AT_ENCR_DATA 0 0 0 0-1 * 0-1 0-1 0 1 1 NY AT_PADDING 0 0 0-1 0 * 0-1 0-1 0-1 0-1 0 YN AT_RESULT_IND 0 0 0-1 0-1 0 0 0 0-1 0-1 NY AT_MAC 0 0 1 1 0-1 0-1 0 1 1 NN AT_COUNTER 0 0 0 0 0-1 0-1 0 1 1 YN AT_COUNTER_TOO_SMALL 0 0 0 0 0 0 0 0 0-1 YN AT_NONCE_S 0 0 0 0 0 0 0 1 0 YN AT_NOTIFICATION 0 0 0 0 1 0 0 0 0 NN AT_CLIENT_ERROR_CODE 0 0 0 0 0 0 1 0 0 NN
It should be noted that attributes AT_PERMANENT_ID_REQ, AT_ANY_ID_REQ, and AT_FULLAUTH_ID_REQ are mutually exclusive; only one of them can be included at the same time. If one of the attributes AT_IV and AT_ENCR_DATA is included, then both of the attributes MUST be included.
AT_PERMANENT_ID_REQ、_どんなAT__ID REQ、およびAT_FULLAUTH_ID_REQは相互に排他的である属性のことに留意すべきです。いずれか一方のみを同時に含めることができます。属性AT_IVとAT_ENCR_DATAのいずれかが含まれている場合、その属性の両方が含まれなければなりません。
The format of the AT_VERSION_LIST attribute is shown below.
AT_VERSION_LIST属性の書式は以下に示されています。
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_VERSION_L..| Length | Actual Version List Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Version 1 | Supported Version 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Version N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This attribute is used in version negotiation, as specified in Section 4.1. The attribute contains the version numbers supported by the EAP-SIM server. The server MUST only include versions that it implements and that are allowed in its security policy. The server SHOULD list the versions in the order of preference, with the most preferred versions listed first. At least one version number MUST be included. The version number for the protocol described in this document is one (0001 hexadecimal).
セクション4.1で指定されるこの属性は、バージョン交渉で使用されています。属性は、EAP-SIMサーバでサポートされているバージョン番号が含まれています。サーバーは、それが実装しているが、そのセキュリティポリシーで許可されているバージョンを含まなければなりません。サーバは、最初にリストされ、最も好ましいバージョンで、優先順にバージョンを表示すべきです。少なくとも一つのバージョン番号を含まなければなりません。この文書に記載されているプロトコルのバージョン番号は、一つ（0001 16進数）です。
The value field of this attribute begins with 2-byte Actual Version List Length, which specifies the length of the Version List in bytes, not including the Actual Version List Length attribute length. This field is followed by the list of the versions supported by the server, which each have a length of 2 bytes. For example, if there is only one supported version, then the Actual Version List Length is 2. Because the length of the attribute must be a multiple of 4 bytes, the sender pads the value field with zero bytes when necessary.
この属性の値フィールドは、実際のバージョンリストの長さ属性の長さを含まないバイト単位のバージョンリストの長さを指定する2バイトの実際のバージョンリストの長さ、で始まります。このフィールドは、それぞれが2バイトの長さを有するサーバによってサポートされているバージョンのリストが続きます。唯一サポートされているバージョンがある場合、属性の長さは、送信側パッドゼロバイトの値のフィールドに必要な4バイトの倍数でなければならないため、例えば、実際のバージョンリストの長さは2です。
The format of the AT_SELECTED_VERSION attribute is shown below.
AT_SELECTED_バージョン属性の書式は以下に示されています。
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_SELECTED...| Length = 1 | Selected Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This attribute is used in version negotiation, as specified in Section 4.1. The value field of this attribute contains a two-byte version number, which indicates the EAP-SIM version that the peer wants to use.
セクション4.1で指定されるこの属性は、バージョン交渉で使用されています。この属性の値フィールドは、ピアが使用したいEAP-SIMのバージョンを示す2バイトのバージョン番号が含まれています。
The format of the AT_NONCE_MT attribute is shown below.
AT_NONCE_MT属性の書式は以下に示されています。
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_NONCE_MT | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NONCE_MT |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of the NONCE_MT attribute contains two reserved bytes followed by a random number freshly generated by the peer (16 bytes long) for this EAP-SIM authentication exchange. The random number is used as a seed value for the new keying material. The reserved bytes are set to zero upon sending and ignored upon reception.
NONCE_MT属性の値フィールドは、新たにこのEAP-SIM認証交換のためのピア（16バイト長）が生成した乱数が続く予約された2つのバイトを含みます。乱数は、新しい鍵材料のためのシード値として使用されます。予約されたバイトは、送信時にゼロに設定し、受信時には無視されます。
The peer MUST NOT re-use the NONCE_MT value from a previous EAP-SIM authentication exchange. If an EAP-SIM exchange includes several EAP/SIM/Start rounds, then the peer SHOULD use the same NONCE_MT value in all EAP-Response/SIM/Start packets. The peer SHOULD use a good source of randomness to generate NONCE_MT. Please see [RFC4086] for more information about generating random numbers for security applications.
ピアは、前のEAP-SIM認証交換からNONCE_MT値を再使用してはなりません。 EAP-SIM交換がいくつかのEAP / SIM / Startが丸め含まれている場合、ピアは、すべてのEAP応答/ SIM /スタートパケットに同じNONCE_MT値を使用すべきです。ピアはNONCE_MTを生成するのに偶発性の良い源を使用すべきです。セキュリティアプリケーションのために乱数を生成の詳細については、[RFC4086]を参照してください。
The format of the AT_PERMANENT_ID_REQ attribute is shown below.
AT_PERMANENT_ID_REQ属性の書式は以下に示されています。
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_PERM..._REQ | Length = 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The use of the AT_PERMANENT_ID_REQ is defined in Section 4.2. The value field contains only two reserved bytes, which are set to zero on sending and ignored on reception.
AT_PERMANENT_ID_REQの使用はセクション4.2で定義されています。値フィールドは、送信時にゼロに設定され、受信時には無視されている2つだけの予約バイトを含んでいます。
The format of the AT_ANY_ID_REQ attribute is shown below.
_どんなAT__ID REQ属性の書式は以下に示されています。
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_ANY_ID_REQ | Length = 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The use of the AT_ANY_ID_REQ is defined in Section 4.2. The value field contains only two reserved bytes, which are set to zero on sending and ignored on reception.
_どんなAT__ID REQの使用はセクション4.2で定義されています。値フィールドは、送信時にゼロに設定され、受信時には無視されている2つだけの予約バイトを含んでいます。
The format of the AT_FULLAUTH_ID_REQ attribute is shown below.
AT_FULLAUTH_ID_REQ属性の書式は以下に示されています。
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_FULLAUTH_...| Length = 1 | Reserved |
+---------------+---------------+-------------------------------+
The use of the AT_FULLAUTH_ID_REQ is defined in Section 4.2. The value field contains only two reserved bytes, which are set to zero on sending and ignored on reception.
AT_FULLAUTH_ID_REQの使用はセクション4.2で定義されています。値フィールドは、送信時にゼロに設定され、受信時には無視されている2つだけの予約バイトを含んでいます。
The format of the AT_IDENTITY attribute is shown below.
AT_IDENTITY属性の書式は以下に示されています。
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_IDENTITY | Length | Actual Identity Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Identity (optional) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The use of the AT_IDENTITY is defined in Section 4.2. The value field of this attribute begins with a 2-byte actual identity length, which specifies the length of the identity in bytes. This field is followed by the subscriber identity of the indicated actual length. The identity is the permanent identity, a pseudonym identity, or a fast re-authentication identity. The identity format is specified in Section 4.2.1. The same identity format is used in the AT_IDENTITY attribute and the EAP-Response/Identity packet, with the exception that the peer MUST NOT decorate the identity it includes in AT_IDENTITY. The identity does not include any terminating null characters. Because the length of the attribute must be a multiple of 4 bytes, the sender pads the identity with zero bytes when necessary.
AT_IDENTITYの使用はセクション4.2で定義されています。この属性の値フィールドは、バイト単位でのアイデンティティの長さを指定する2バイトの実際のアイデンティティの長さ、で始まります。このフィールドが示さ実際の長さの加入者識別情報が続きます。アイデンティティは、永久的なアイデンティティ、匿名のアイデンティティ、または速い再認証のアイデンティティです。アイデンティティ形式はセクション4.2.1で指定されています。同じIDの形式は、ピアは、それがAT_IDENTITYに含まれるアイデンティティを飾るてはならないことを除いて、AT_IDENTITY属性とEAP応答/アイデンティティパケットで使用されています。アイデンティティは、任意の終端のnull文字が含まれていません。属性の長さが4バイトの倍数でなければならないため、送信側のパッドゼロバイトのアイデンティティ必要。
The format of the AT_RAND attribute is shown below.
AT_RAND属性の書式は以下に示されています。
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_RAND | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. n*RAND .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute contains two reserved bytes followed by n GSM RANDs, each 16 bytes long. The value of n can be determined by the attribute length. The reserved bytes are set to zero upon sending and ignored upon reception.
この属性の値フィールドは、各16バイト長n個のGSMのランズ続く予約された2つのバイトを含みます。 nの値は、属性の長さによって決定することができます。予約されたバイトは、送信時にゼロに設定し、受信時には無視されます。
The number of RAND challenges (n) MUST be two or three. The peer MUST verify that the number of RAND challenges is sufficient according to the peer's policy. The server MUST use different RAND values. In other words, a RAND value can only be included once in AT_RAND. When processing the AT_RAND attribute, the peer MUST check that the RANDs are different.
RAND挑戦（N）の数は、2つまたは3つでなければなりません。ピアは、RAND挑戦の数は、ピアのポリシーに従って十分であることを確かめなければなりません。サーバが異なるRAND値を使用しなければなりません。言い換えれば、RAND値は、一度だけAT_RANDに含めることができます。 AT_RAND属性を処理する場合、ピアはランズが異なっていることをチェックしなければなりません。
The EAP server MUST obtain fresh RANDs for each EAP-SIM full authentication exchange. More specifically, the server MUST consider RANDs it included in AT_RAND to be consumed if the server receives an EAP-Response/SIM/Challenge packet with a valid AT_MAC, or an EAP-Response/SIM/Client-Error with the code "insufficient number of challenges" or "RANDs are not fresh". However, in other cases (if the server does not receive a response to its EAP-Request/SIM/Challenge packet, or if the server receives a response other than the cases listed above), the server does not need to consider the RANDs to be consumed, and the server MAY re-use the RANDs in the AT_RAND attribute of the next full authentication attempt.
EAPサーバは、各EAP-SIMの完全な認証交換のための新鮮ランズを取得する必要があります。具体的には、サーバは、サーバがコード「不足数と有効AT_MACとEAP応答/ SIM /挑戦パケット、またはEAP応答/ SIM /クライアントのエラーを受信した場合に消費されるようにAT_RANDに含まランズを考慮する必要があります挑戦」または 『ランズの』新鮮ではありません。しかし、（サーバがEAP要求/ SIM /挑戦パケットに対する応答を受信しない場合、またはサーバーが上記の例以外の応答を受信した場合）他の例では、サーバがへランズを考慮する必要はありません。消費され、サーバーは次の完全な認証試行のAT_RAND属性にランズを再利用するかもしれません。
The format of the AT_NEXT_PSEUDONYM attribute is shown below.
AT_NEXT_PSEUDONYM属性の書式は以下に示されています。
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_NEXT_PSEU..| Length | Actual Pseudonym Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Next Pseudonym .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute begins with the 2-byte actual pseudonym length, which specifies the length of the following pseudonym in bytes. This field is followed by a pseudonym username that the peer can use in the next authentication. The username MUST NOT include any realm portion. The username does not include any terminating null characters. Because the length of the attribute must be a multiple of 4 bytes, the sender pads the pseudonym with zero bytes when necessary. The username encoding MUST follow the UTF-8 transformation format [RFC3629]. This attribute MUST always be encrypted by encapsulating it within the AT_ENCR_DATA attribute.
この属性の値フィールドは、バイト単位で、次の仮名の長さを指定する2バイトの実際の仮名の長さ、で始まります。このフィールドは、ピアは、次の認証に使用することができます匿名ユーザ名が続いています。ユーザー名は、すべての分野の部分を含んではいけません。ユーザー名は、任意の終端のnull文字が含まれていません。属性の長さが4バイトの倍数でなければならないので、送信側パッドゼロバイトの仮名必要。ユーザ名のエンコーディングはUTF-8変換形式[RFC3629]を従わなければなりません。この属性は常にAT_ENCR_DATA属性の中でそれをカプセル化することによって暗号化されなければなりません。
The format of the AT_NEXT_REAUTH_ID attribute is shown below.
AT_ネクスト_REAUTH_ID属性の書式は以下に示されています。
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_NEXT_REAU..| Length | Actual Re-Auth Identity Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Next Fast Re-authentication Username .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute begins with the 2-byte actual re-authentication identity length which specifies the length of the following fast re-authentication identity in bytes. This field is followed by a fast re-authentication identity that the peer can use in the next fast re-authentication, as described in Section 5. In environments where a realm portion is required, the fast re-authentication identity includes both a username portion and a realm name portion. The fast re-authentication identity does not include any terminating null characters. Because the length of the attribute must be a multiple of 4 bytes, the sender pads the fast re-authentication identity with zero bytes when necessary. The identity encoding MUST follow the UTF-8 transformation format [RFC3629]. This attribute MUST always be encrypted by encapsulating it within the AT_ENCR_DATA attribute.
この属性の値フィールドは、バイト単位で、次の速い再認証のアイデンティティの長さを指定する2バイトの実際の再認証アイデンティティ長で始まります。レルム部分が必要とされる環境では、セクション5で説明したように、このフィールドは、ピアが次の速い再認証に使用することができ、高速再認証アイデンティティ続いて、高速再認証アイデンティティはユーザ名部分の両方を含みますレルム名部分。速い再認証のアイデンティティは、任意の終端のnull文字が含まれていません。属性の長さは4バイトで、送信者のパッドに必要なゼロバイトの高速再認証アイデンティティの倍数でなければならないので。同一の符号は、UTF-8変換形式[RFC3629]を従わなければなりません。この属性は常にAT_ENCR_DATA属性の中でそれをカプセル化することによって暗号化されなければなりません。
AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted information between the EAP-SIM peer and server.
AT_IVとAT_ENCR_DATAは、EAP-SIMのピアとサーバ間の暗号化された情報を送信するために使用することができる属性。
The value field of AT_IV contains two reserved bytes followed by a 16-byte initialization vector required by the AT_ENCR_DATA attribute. The reserved bytes are set to zero when sending and ignored on reception. The AT_IV attribute MUST be included if and only if the AT_ENCR_DATA is included. Section 6.3 specifies the operation if a packet that does not meet this condition is encountered.
AT_IVの値フィールドは、AT_ENCR_DATA属性によって必要とされる16バイトの初期化ベクトルに続く2つの予約バイトを含みます。予約されたバイトは、送信時にゼロに設定され、受信時には無視されます。 AT_ENCR_DATAが含まれている場合だけAT_IV属性が含まれなければなりません。この条件を満たしていないパケットが発生した場合、セクション6.3には、操作を指定します。
The sender of the AT_IV attribute chooses the initialization vector at random. The sender MUST NOT re-use the initialization vector value from previous EAP-SIM packets. The sender SHOULD use a good source of randomness to generate the initialization vector. Please see [RFC4086] for more information about generating random numbers for security applications. The format of AT_IV is shown below.
AT_IV属性の送信者はランダムに初期化ベクトルを選択します。送信者は、前のEAP-SIMパケットから初期化ベクトル値を再使用してはなりません。送信者は、初期化ベクトルを生成するのに偶発性の良い源を使用すべきです。セキュリティアプリケーションのために乱数を生成の詳細については、[RFC4086]を参照してください。 AT_IVの書式は以下に示されています。
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_IV | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Initialization Vector |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of the AT_ENCR_DATA attribute consists of two reserved bytes followed by cipher text bytes encrypted using the Advanced Encryption Standard (AES) [AES] with a 128-bit key in the Cipher Block Chaining (CBC) mode of operation using the initialization vector from the AT_IV attribute. The reserved bytes are set to zero when sending and ignored on reception. Please see [CBC] for a description of the CBC mode. The format of the AT_ENCR_DATA attribute is shown below.
AT_ENCR_DATA属性の値フィールドは、初期化ベクトルを用いた操作の暗号ブロック連鎖（CBC）モードで128ビットキーで高度暗号化標準（AES）[AES]を用いて暗号化バイト暗号文に続く2つの予約バイトで構成しますAT_IV属性から。予約されたバイトは、送信時にゼロに設定され、受信時には無視されます。 CBCモードの説明については、[CBC]を参照してください。 AT_ENCR_DATA属性の書式は以下に示されています。
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_ENCR_DATA | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Encrypted Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The derivation of the encryption key (K_encr) is specified in Section 7.
暗号化キー（K_encr）の導出はセクション7で指定されています。
The plaintext consists of nested EAP-SIM attributes.
平文は、ネストされたEAP-SIM属性で構成されています。
The encryption algorithm requires the length of the plaintext to be a multiple of 16 bytes. The sender may need to include the AT_PADDING attribute as the last attribute within AT_ENCR_DATA. The AT_PADDING attribute is not included if the total length of other nested attributes within the AT_ENCR_DATA attribute is a multiple of 16 bytes. As usual, the Length of the Padding attribute includes the Attribute Type and Attribute Length fields. The length of the Padding attribute is 4, 8, or 12 bytes. It is chosen so that the length of the value field of the AT_ENCR_DATA attribute becomes a multiple of 16 bytes. The actual pad bytes in the value field are set to zero (00 hexadecimal) on sending. The recipient of the message MUST verify that the pad bytes are set to zero. If this verification fails on the peer, then it MUST send the EAP-Response/SIM/Client-Error packet with the error code "unable to process packet" to terminate the authentication exchange. If this verification fails on the server, then the server sends the peer the EAP-Request/SIM/Notification packet with an AT_NOTIFICATION code that implies failure to terminate the authentication exchange. The format of the AT_PADDING attribute is shown below.
暗号化アルゴリズムは、16バイトの倍数になるように、平文の長さを必要とします。送信者はAT_ENCR_DATA内の最後の属性としてAT_PADDING属性を含める必要があるかもしれません。 AT_ENCR_DATA属性内の他のネストされた属性の合計の長さは16バイトの倍数である場合AT_PADDING属性が含まれていません。いつものように、パディング属性の長さは、属性タイプと属性の長さフィールドを含んでいます。パディング属性の長さは、4,8、または12バイトです。 AT_ENCR_DATA属性の値フィールドの長さは16バイトの倍数となるように、それが選択されます。値フィールドの実際のパッドバイトが送信に（00進数）がゼロに設定されます。メッセージの受信者は、パッドバイトがゼロに設定されていることを確認しなければなりません。この検証は、ピアに失敗した場合、それは認証交換を終了するために、「パケットを処理できません」のエラーコードとEAP応答/ SIM /クライアントエラーパケットを送らなければなりません。この検証は、サーバー上で失敗した場合、サーバーは、ピアに認証交換を終了できなかったことを意味AT_NOTIFICATIONコードとEAP要求/ SIM /通知パケットを送信します。 AT_PADDING属性の書式は以下に示されています。
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_PADDING | Length | Padding... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the AT_RESULT_IND attribute is shown below.
AT_RESULT_IND属性の書式は以下に示されています。
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_RESULT_...| Length = 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute consists of two reserved bytes, which are set to zero upon sending and ignored upon reception. This attribute is always sent unencrypted, so it MUST NOT be encapsulated within the AT_ENCR_DATA attribute.
この属性の値フィールドは、送信時にゼロに設定し、受信時には無視されている2つの予約バイト、から成ります。それはAT_ENCR_DATA属性の中にカプセル化してはならないので、この属性は常に、暗号化されずに送信されます。
The AT_MAC attribute is used for EAP-SIM message authentication. Section 8 specifies in which messages AT_MAC MUST be included.
AT_MAC属性はEAP-SIMメッセージ認証に使用されます。第8章では、メッセージAT_MACが必ず含まれなければならないで指定します。
The value field of the AT_MAC attribute contains two reserved bytes followed by a keyed message authentication code (MAC). The MAC is calculated over the whole EAP packet and concatenated with optional message-specific data, with the exception that the value field of the MAC attribute is set to zero when calculating the MAC. The EAP packet includes the EAP header that begins with the Code field, the EAP-SIM header that begins with the Subtype field, and all the attributes, as specified in Section 8.1. The reserved bytes in AT_MAC are set to zero when sending and ignored on reception. The contents of the message-specific data that may be included in the MAC calculation are specified separately for each EAP-SIM message in Section 9.
AT_MAC属性の値フィールドは、鍵付きメッセージ認証コード（MAC）、続いて2つの予約バイトを含みます。 MACは全体のEAPパケットにわたって計算され、MACを計算する際にMAC属性の値フィールドはゼロに設定されていることを除いて、任意のメッセージ特有のデータと連結されています。 EAPパケットはセクション8.1で指定されるように、コードフィールド、サブタイプフィールドで始まり、EAP-SIMヘッダ、およびすべての属性で始まるEAPヘッダを含みます。 AT_MACの予約バイトは、送信時にゼロに設定され、受信時には無視されます。 MAC計算に含めることができるメッセージ固有のデータの内容は、第9の各EAP-SIMメッセージを個別に指定されています。
The format of the AT_MAC attribute is shown below.
AT_MAC属性の書式は以下に示されています。
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_MAC | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MAC |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MAC algorithm is an HMAC-SHA1-128 [RFC2104] keyed hash value. (The HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by truncating the output to the first 16 bytes. Hence, the length of the MAC is 16 bytes. The derivation of the authentication key (K_aut) used in the calculation of the MAC is specified in Section 7.
MACアルゴリズムはHMAC-SHA1-128 [RFC2104]キー付きハッシュ値です。 （HMAC-SHA1-128値は最初の16バイトに出力を切り捨てることにより20バイトのHMAC-SHA1値から得られる。したがって、MACの長さは16バイトである。使用される認証キー（K_aut）の導出MACの計算にセクション7で指定されています。
When the AT_MAC attribute is included in an EAP-SIM message, the recipient MUST process the AT_MAC attribute before looking at any other attributes, except when processing EAP-Request/SIM/Challenge. The processing of EAP-Request/SIM/Challenge is specified in Section 9.3. If the message authentication code is invalid, then the recipient MUST ignore all other attributes in the message and operate as specified in Section 6.3.
AT_MAC属性はEAP-SIMメッセージに含まれている場合、受信者は、EAP要求/ SIM /挑戦を処理する場合を除き、他の属性を見る前にAT_MAC属性を処理しなければなりません。 EAP要求/ SIM /挑戦の処理はセクション9.3で指定されています。メッセージ認証コードが無効である場合には、受信者はメッセージ内の他のすべての属性を無視しなければなりませんし、セクション6.3で指定されるように動作します。
The format of the AT_COUNTER attribute is shown below.
AT_COUNTER属性の書式は以下に示されています。
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_COUNTER | Length = 1 | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of the AT_COUNTER attribute consists of a 16-bit unsigned integer counter value, represented in network byte order. This attribute MUST always be encrypted by encapsulating it within the AT_ENCR_DATA attribute.
AT_COUNTER属性の値フィールドは、ネットワークバイト順で表される16ビットの符号なし整数のカウンタ値、から成ります。この属性は常にAT_ENCR_DATA属性の中でそれをカプセル化することによって暗号化されなければなりません。
The format of the AT_COUNTER_TOO_SMALL attribute is shown below.
AT_COUNTER_TOO_SMALL属性の書式は以下に示されています。
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_COUNTER...| Length = 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute consists of two reserved bytes, which are set to zero upon sending and ignored upon reception. This attribute MUST always be encrypted by encapsulating it within the AT_ENCR_DATA attribute.
この属性の値フィールドは、送信時にゼロに設定し、受信時には無視されている2つの予約バイト、から成ります。この属性は常にAT_ENCR_DATA属性の中でそれをカプセル化することによって暗号化されなければなりません。
The format of the AT_NONCE_S attribute is shown below.
AT_NONCE_S属性の書式は以下に示されています。
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_NONCE_S | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| NONCE_S |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of the AT_NONCE_S attribute contains two reserved bytes followed by a random number freshly generated by the server (16 bytes) for this EAP-SIM fast re-authentication. The random number is used as a challenge for the peer and also as a seed value for the new keying material. The reserved bytes are set to zero upon sending and ignored upon reception. This attribute MUST always be encrypted by encapsulating it within the AT_ENCR_DATA attribute.
AT_NONCE_S属性の値フィールドは、新たにこのEAP-SIM高速再認証のためにサーバ（16バイト）が生成した乱数が続く予約された2つのバイトを含みます。乱数は、ピアのための課題として、また新たなキーイング材料のためのシード値として使用されます。予約されたバイトは、送信時にゼロに設定し、受信時には無視されます。この属性は常にAT_ENCR_DATA属性の中でそれをカプセル化することによって暗号化されなければなりません。
The server MUST NOT re-use the NONCE_S value from any previous EAP-SIM fast re-authentication exchange. The server SHOULD use a good source of randomness to generate NONCE_S. Please see [RFC4086] for more information about generating random numbers for security applications.
サーバーは、以前のEAP-SIM高速再認証交換からNONCE_S値を再使用してはなりません。サーバーはNONCE_Sを生成するのに偶発性の良い源を使用すべきです。セキュリティアプリケーションのために乱数を生成の詳細については、[RFC4086]を参照してください。
The format of the AT_NOTIFICATION attribute is shown below.
AT_NOTIFICATION属性の書式は以下に示されています。
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_NOTIFICATION| Length = 1 |S|P| Notification Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute contains a two-byte notification code. The first and second bit (S and P) of the notification code are interpreted as described in Section 6.
この属性の値フィールドは、2バイトの通知コードが含まれています。通知コードの第1および第2のビット（SとP）第6節に記載されるように解釈されます。
The notification code values listed below have been reserved. The descriptions below illustrate the semantics of the notifications.
下記の通知コードの値が予約されています。以下の説明では、通知の意味を説明します。
The peer implementation MAY use different wordings when presenting the notifications to the user. The "requested service" depends on the environment where EAP-SIM is applied.
ユーザーに通知を提示するとき、ピアの実装が異なる文言を使用するかもしれません。 「要求されたサービスは、」EAP-SIMが適用される環境に依存します。
0 - General failure after authentication. (Implies failure, used after successful authentication.)
0 - 認証後に一般的な失敗。 （認証の成功後に使用失敗したことを、意味します。）
16384 - General failure. (Implies failure, used before authentication.)
16384 - 一般的な失敗。 （認証前に使用失敗したことを、意味します。）
32768 - Success. User has been successfully authenticated. (Does not imply failure, used after successful authentication). The usage of this code is discussed in Section 6.2.
32768 - 成功。ユーザーが正常に認証されました。 （認証の成功後に使用失敗を、意味するものではありません）。このコードの使用は、セクション6.2で議論されています。
1026 - User has been temporarily denied access to the requested service. (Implies failure, used after successful authentication.)
1026 - ユーザーは、一時的に要求されたサービスへのアクセスを拒否されています。 （認証の成功後に使用失敗したことを、意味します。）
1031 - User has not subscribed to the requested service. (Implies failure, used after successful authentication.)
1031 - ユーザーが要求されたサービスに加入していません。 （認証の成功後に使用失敗したことを、意味します。）
The format of the AT_CLIENT_ERROR_CODE attribute is shown below.
AT_CLIENT_ERROR_CODE属性の書式は以下に示されています。
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_CLIENT_ERR..| Length = 1 | Client Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute contains a two-byte client error code. The following error code values have been reserved.
この属性の値フィールドは、2バイトのクライアント・エラー・コードが含まれています。次のエラーコードの値が予約されています。
0 "unable to process packet": a general error code
一般的なエラーコード：0「パケットを処理できません」
1 "unsupported version": the peer does not support any of the versions listed in AT_VERSION_LIST
1「サポートされていないバージョン」：ピアがAT_VERSION_LISTに記載されているバージョンのいずれかをサポートしていません
2 "insufficient number of challenges": the peer's policy requires more triplets than the server included in AT_RAND
2「課題の数が不十分」：ピアのポリシーはAT_RANDに含まれるサーバよりも多くのトリプレットが必要です
3 "RANDs are not fresh": the peer believes that the RAND challenges included in AT_RAND were not fresh
3「ランズは新鮮ではありません」：ピアはAT_RANDに含まRAND挑戦が新鮮ではなかったと信じています
IANA has assigned the EAP type number 18 for this protocol.
IANAは、このプロトコルのためのEAPタイプ番号18が割り当てられています。
EAP-SIM shares most of the protocol design, such as attributes and message Subtypes, with EAP-AKA [EAP-AKA]. EAP-SIM protocol numbers should be administered in the same IANA registry as EAP-AKA. The initial values are listed in [EAP-AKA] for both protocols, so this document does not require any new registries or parameter allocation. As a common registry is used for EAP-SIM and EAP-AKA, the protocol number allocation policy for both protocols is specified in [EAP-AKA].
EAP-SIM例えばEAP-AKA [EAP-AKA]を持つ属性とメッセージサブタイプ、などのプロトコル設計の最も株、。 EAP-SIMプロトコル番号は、EAP-AKAと同じIANAレジストリに投与すべきです。初期値は、両方のプロトコルのために[EAP-AKA]に記載されているので、この文書は、新しいレジストリまたはパラメータの割り当てを必要としません。共通レジストリがEAP-SIMおよびEAP-AKAのために使用されるように、両方のプロトコルのプロトコル番号の割り当てポリシーは、[EAP-AKA]で指定されています。
The EAP specification [RFC3748] describes the security vulnerabilities of EAP, which does not include its own security mechanisms. This section discusses the claimed security properties of EAP-SIM, as well as vulnerabilities and security recommendations.
EAP仕様[RFC3748]は、独自のセキュリティメカニズムを備えていないEAPのセキュリティの脆弱性を、記載されています。このセクションでは、特許請求のセキュリティEAP-SIMの性質だけでなく、脆弱性やセキュリティの推奨事項について説明します。
The GSM A3 and A8 algorithms are used in EAP-SIM. [GSM-03.20] specifies the general GSM authentication procedure and the external interface (inputs and outputs) of the A3 and A8 algorithms. The operation of these functions falls completely within the domain of an individual operator, and therefore, the functions are specified by each operator rather than being fully standardised. The GSM-MILENAGE algorithm, specified publicly in [3GPP-TS-55.205], is an example algorithm set for A3 and A8 algorithms.
GSM A3とA8アルゴリズムはEAP-SIMで使用されています。 [GSM-03.20は、一般GSM認証手続きとA3とA8アルゴリズムの外部インターフェース（入力および出力）を指定します。これらの機能の動作が完全に個々のオペレータのドメイン内に収まるので、関数は各オペレータによって指定されるのではなく、完全に標準化されています。 [3GPP-TS-55.205]で公に指定GSM-MILENAGEアルゴリズムは、A3とA8アルゴリズムに設定例アルゴリズムです。
The security of the A3 and A8 algorithms is important to the security of EAP-SIM. Some A3/A8 algorithms have been compromised; see [GSM-Cloning] for discussion about the security of COMP-128 version 1. Note that several revised versions of the COMP-128 A3/A8 algorithm have been devised after the publication of these weaknesses and that the publicly specified GSM-MILENAGE algorithm is not vulnerable to any known attacks.
A3とA8アルゴリズムのセキュリティはEAP-SIMのセキュリティにとって重要です。いくつかのA3 / A8アルゴリズムが危険にさらされています。 COMP-128 A3 / A8アルゴリズムのいくつかの改訂版は、これらの弱点の出版後と公に指定されたGSM-MILENAGEアルゴリズムことが考案されていることをCOMP-128バージョン1注のセキュリティについての議論のための[GSM-クローニング]を参照してください任意の既知の攻撃に対して脆弱ではありません。
EAP-SIM includes optional identity privacy support that protects the privacy of the subscriber identity against passive eavesdropping. This document only specifies a mechanism to deliver pseudonyms from the server to the peer as part of an EAP-SIM exchange. Hence, a peer that has not yet performed any EAP-SIM exchanges does not typically have a pseudonym available. If the peer does not have a pseudonym available, then the privacy mechanism cannot be used, but the permanent identity will have to be sent in the clear. The terminal SHOULD store the pseudonym in a non-volatile memory so that it can be maintained across reboots. An active attacker that impersonates the network may use the AT_PERMANENT_ID_REQ attribute to attempt to learn the subscriber's permanent identity. However, as discussed in Section 4.2.2, the terminal can refuse to send the cleartext permanent identity if it believes that the network should be able to recognize the pseudonym.
EAP-SIMは、受動的な盗聴に対して加入者識別のプライバシーを保護し、オプションのアイデンティティプライバシーサポートを含んでいます。この文書では、唯一のEAP-SIM交換の一環として、ピアにサーバーから匿名を提供するためのメカニズムを指定します。したがって、まだEAP-SIM交換を行っていないピアは、典型的には、利用可能な匿名を有していません。ピアが利用可能な匿名を持っていない場合は、プライバシーのメカニズムを使用することはできませんが、永久的なアイデンティティを平文で送信する必要があります。それは再起動にわたって維持することができるように、端末は、不揮発性メモリに偽名を格納する必要があります。ネットワークを偽装し、アクティブ攻撃者は、加入者の永久的なアイデンティティを学ぶしようとするAT_PERMANENT_ID_REQ属性を使用することができます。しかし、4.2.2項で説明したように、端末がネットワークに仮名を認識することができるはずと考えていた場合、クリアテキスト永久的なアイデンティティを送信することを拒否することができます。
If the peer and server cannot guarantee that the pseudonym will be maintained reliably, and identity privacy is required, then additional protection from an external security mechanism (such as Protected Extensible Authentication Protocol (PEAP) [PEAP]) may be used. If an external security mechanism is in use, the identity privacy features of EAP-SIM may not be useful. The security considerations of using an external security mechanism with EAP-SIM are beyond the scope of this document.
ピア及びサーバは匿名が確実に維持され、同一のプライバシーが必要であることを保証できない場合、（例えば、保護された拡張認証プロトコル（PEAP）[PEAP]のような）外部のセキュリティ機構からの追加の保護を使用することができます。外部のセキュリティ・メカニズムを使用している場合は、EAP-SIMのアイデンティティプライバシー機能は便利ではないかもしれません。 EAP-SIMと外部のセキュリティ・メカニズムを使用してセキュリティの考慮事項は、この文書の範囲を超えています。
EAP-SIM provides mutual authentication. The peer believes that the network is authentic because the network can calculate a correct AT_MAC value in the EAP-Request/SIM/Challenge packet. To calculate AT_MAC it is sufficient to know the RAND and Kc values from the GSM triplets (RAND, SRES, Kc) used in the authentication. Because the network selects the RAND challenges and the triplets, an attacker that knows n (2 or 3) GSM triplets for the subscriber is able to impersonate a valid network to the peer. (Some peers MAY employ an implementation-specific counter-measure against impersonating a valid network by re-using a previously used RAND; see below.) In other words, the security of EAP-SIM is based on the secrecy of Kc keys, which are considered secret intermediate results in the EAP-SIM cryptographic calculations.
EAP-SIMは、相互認証を提供します。ピアは、ネットワークがEAP-要求/ SIM / Challengeパケット内の正しいAT_MAC値を算出することができるので、ネットワークが真正であると考えています。 AT_MACを計算することは、認証に使用されるGSMトリプレット（RAND、SRES、Kcの）からRAND及びKcの値を知ることで十分です。ネットワークはRANDの課題とトリプレット、加入者用のn知っている攻撃者が（2または3）GSMトリプレットを選択するためのピアに有効なネットワークになりすますことができます。 （いくつかのピアが以前に使用RANDを再使用して有効なネットワークになりすましに対して実装固有の対策を採用してもよい;以下を参照のこと）つまり、EAP-SIMのセキュリティはKcを鍵の秘密に基づいていますEAP-SIMの暗号計算に秘密の中間結果と考えられています。
Given physical access to the SIM card, it is easy to obtain any number of GSM triplets.
SIMカードへの物理的アクセスを考えると、GSM三つ子の任意の数を得ることは容易です。
Another way to obtain triplets is to mount an attack on the peer platform via a virus or other malicious piece of software. The peer SHOULD be protected against triplet querying attacks by malicious software. Care should be taken not to expose Kc keys to attackers when they are stored or handled by the peer, or transmitted between subsystems of the peer. Steps should be taken to limit the transport, storage, and handling of these values outside a protected environment within the peer. However, the virus protection of the peer and the security capabilities of the peer's operating system are outside the scope of this document.
三つ子を得るための別の方法は、ウイルスやソフトウェアの他の悪質な作品を経て、ピア・プラットフォーム上で攻撃をマウントすることです。ピアは、悪質なソフトウェアによる攻撃を問い合わせるトリプレットに対して保護する必要があります。それらが格納されている、またはピアによって処理、またはピアのサブシステムとの間で送信される場合注意が攻撃者にKcのキーが露出しないように注意すべきです。ステップは、ピア内の保護された環境の外に、これらの値の輸送、保管、および取り扱いを制限するものと解釈されるべきです。しかし、ピアのウイルス保護とピアのオペレーティングシステムのセキュリティ機能は、この文書の範囲外です。
The EAP-SIM server typically obtains the triplets from the Home Location Register (HLR). An attacker might try to obtain triplets by attacking against the network used between the EAP-SIM server and the HLR. Care should be taken not to expose Kc keys to attackers when they are stored or handled by the EAP-SIM server, or transmitted between the EAP server and the HLR. Steps should be taken to limit the transport, storage, and handling of these values outside a protected environment. However, the protection of the communications between the EAP-SIM server and the HLR is outside the scope of this document.
EAP-SIMサーバは通常、ホームロケーションレジスタ（HLR）からトリプレットを取得します。攻撃者は、EAP-SIMサーバとHLRの間で使用されるネットワークに対する攻撃することによってトリプレットを取得しようとするかもしれません。彼らは保存またはEAP-SIMサーバによって処理、またはEAPサーバとHLRとの間で送信されている場合には注意が攻撃者にKcの鍵を公開しないように注意してください。手順は、保護された環境の外に輸送、貯蔵、及びこれらの値の取り扱いを制限するものと解釈されるべきです。しかし、EAP-SIMサーバとHLRとの間の通信を保護することは、この文書の範囲外です。
If the same SIM credentials are also used for GSM traffic, the triplets could be revealed in the GSM network; see Section 12.8.
同じSIMの認証情報もGSMトラフィックに使用されている場合は、トリプレットは、GSMネットワークで明らかにすることができ、 12.8項を参照してください。
In GSM, the network is allowed to re-use the RAND challenge in consecutive authentication exchanges. This is not allowed in EAP-SIM. The EAP-SIM server is mandated to use fresh triplets (RAND challenges) in consecutive authentication exchanges, as specified in Section 3. EAP-SIM does not mandate any means for the peer to check if the RANDs are fresh, so the security of the scheme leans on the secrecy of the triplets. However, the peer MAY employ implementation-specific mechanisms to remember some of the previously used RANDs, and the peer MAY check the freshness of the server's RANDs. The operation in cases when the peer detects that the RANDs are not fresh is specified in Section 6.3.1.
GSMでは、ネットワークは、連続した認証交換中RANDチャレンジを再使用することができます。これは、EAP-SIMで許可されていません。 EAP-SIMサーバが第3 EAP-SIMで指定されているように、連続した認証交換に新鮮なトリプレット（RAND挑戦を）使用することを義務付けられているランズが新鮮かどうかを確認するために、ピアのための任意の手段を義務付ける、それほどのセキュリティはありませんスキームは、トリプレットの秘密に傾きます。しかし、ピアは、以前に使用ランズの一部を覚えて、実装固有のメカニズムを使用してもよいし、ピアは、サーバのランズの新鮮さをチェックすることができます。ピアはランズは新鮮でないことを検出した場合の動作は、セクション6.3.1で指定されています。
Preventing the re-use of authentication vectors has been taken into account in the design of the UMTS Authentication and Key Agreement (AKA), which is used in EAP-AKA [EAP-AKA]. In cases when the triplet re-use properties of EAP-SIM are not considered sufficient, it is advised to use EAP-AKA.
認証ベクトルの再使用を防止するEAP-AKA [EAP-AKA]で使用されるUMTS認証および鍵合意（AKA）の設計において考慮されています。 EAP-SIMのトリプレットの再利用性が十分考慮されていない場合には、EAP-AKAを使用することをお勧めします。
Note that EAP-SIM mutual authentication is done with the EAP server. In general, EAP methods do not authenticate the identity or services provided by the EAP authenticator (if distinct from the EAP server) unless they provide the so-called channel bindings property. The vulnerabilities related to this have been discussed in [RFC3748], [EAP-Keying], [Service-Identity].
EAP-SIM相互認証がEAPサーバで行われることに注意してください。彼らはいわゆるチャネルバインディングプロパティを提供しない限り、一般的には、EAPメソッドは、EAP認証（EAPサーバは異なる場合）が提供するアイデンティティまたはサービスを認証しません。これに関連した脆弱性は、[RFC3748]、[EAP-キーイング]、[サービスアイデンティティ]で議論されています。
EAP-SIM does not provide the channel bindings property, so it only authenticates the EAP server. However, ongoing work such as [Service-Identity] may provide such support as an extension to popular EAP methods such as EAP-TLS, EAP-SIM, or EAP-AKA.
EAP-SIMは、チャネルバインディングのプロパティを提供していないので、それだけでEAPサーバを認証します。しかしながら、このような[サービスアイデンティティ]などの進行中の作業は、EAP-TLS、EAP-SIMまたはEAP-AKAなどの一般EAPメソッドの拡張として、このようなサポートを提供してもよいです。
The EAP-SIM server typically obtains authentication vectors from the Authentication Centre (AuC). EAP-SIM introduces a new usage for the AuC. The protocols between the EAP-SIM server and the AuC are out of the scope of this document. However, it should be noted that a malicious EAP-SIM peer may generate a lot of protocol requests to mount a denial of service attack. The EAP-SIM server implementation SHOULD take this into account and SHOULD take steps to limit the traffic that it generates towards the AuC, preventing the attacker from flooding the AuC and from extending the denial of service attack from EAP-SIM to other users of the AuC.
EAP-SIMサーバは通常、認証センター（AUC）から認証ベクトルを取得します。 EAP-SIMはAuCのための新たな使い方を紹介します。 EAP-SIMサーバとAuCの間のプロトコルは、この文書の範囲外です。しかし、悪質なEAP-SIMのピアがサービス拒否攻撃を行うプロトコル要求の多くを生成することに留意すべきです。 EAP-SIMサーバの実装は、AUCは洪水からの他のユーザーにEAP-SIMからのサービス拒否攻撃を拡張するから攻撃を防ぎ、これを考慮に入れる必要があり、それがAuCに向けて生成トラフィックを制限するための措置をとるべきですAuCは。
EAP-SIM supports key derivation. The key hierarchy is specified in Section 7. EAP-SIM combines several GSM triplets in order to generate stronger keying material and stronger AT_MAC values. The actual strength of the resulting keys depends, among other things, on operator-specific parameters including authentication algorithms, the strength of the Ki key, and the quality of the RAND challenges. For example, some SIM cards generate Kc keys with 10 bits set to zero. Such restrictions may prevent the concatenation technique from yielding strong session keys. Because the strength of the Ki key is 128 bits, the ultimate strength of any derived secret key material is never more than 128 bits.
EAP-SIMは、鍵の導出をサポートしています。キー階層は、EAP-SIMは、強い鍵材料と強いAT_MAC値を生成するためにいくつかのGSMトリプレットを組み合わせ、セクション7で指定されています。得られたキーの実際の強度は、認証アルゴリズム、のKiキーの強度、およびRANDチャレンジの品質を含むオペレータ特有のパラメータに、とりわけ依存します。例えば、いくつかのSIMカードはゼロに設定さ10ビットのKcの鍵を生成します。このような制限は、強力なセッションキーをもたらすから連結技術を妨げることがあります。 Kiキーの強さが128ビットであるので、任意の派生秘密鍵材料の極限強さは以上128ビットになることはありません。
It should also be noted that a security policy that allows n=2 to be used may compromise the security of a future policy that requires three triplets, because adversaries may be able to exploit the messages exchanged when the weaker policy is applied.
また、留意すべき敵が弱くポリシーが適用されたときにメッセージを交換利用することができる可能性があるため、N = 2三枚のトリプレットを要求将来ポリシーのセキュリティを損なう可能性が使用されることを可能にするセキュリティポリシー。
There is no known way to obtain complete GSM triplets by mounting an attack against EAP-SIM. A passive eavesdropper can learn n*RAND and AT_MAC and may be able to link this information to the subscriber identity. An active attacker that impersonates a GSM subscriber can easily obtain n*RAND and AT_MAC values from the EAP server for any given subscriber identity. However, calculating the Kc and SRES values from AT_MAC would require the attacker to reverse the keyed message authentication code function HMAC-SHA1-128.
EAP-SIMに対する攻撃を装着することで、完全なGSM三つ子を得るための既知の方法はありません。受動的な盗聴者が学ぶのn * RANDとAT_MACと加入者識別にこの情報をリンクすることができるかもしれできます。 GSM加入者が容易に任意の加入者識別のためのEAPサーバからN * RANDとAT_MAC値を得ることができる偽装アクティブアタッカー。しかし、AT_MACからKcをとSRES値を計算する鍵付きメッセージ認証コード関数HMAC-SHA1-128を逆に攻撃者を必要とするであろう。
As EAP-SIM does not expose any values calculated from an individual GSM Kc keys, it is not possible to mount a brute force attack on only one of the Kc keys in EAP-SIM. Therefore, when considering brute force attacks on the values exposed in EAP-SIM, the effective length of EAP-SIM session keys is not compromised by the fact that they are combined from several shorter keys, i.e., the effective length of 128 bits may be achieved. For additional considerations, see Section 12.8.
EAP-SIMは、個々のGSM Kcのキーから計算された値を公開しないように、EAP-SIMにおけるKcのキーのいずれか一方のみにブルートフォース攻撃を実装することは不可能です。 EAP-SIM内に露出値に対するブルートフォース攻撃を考慮した場合、したがって、EAP-SIMセッションキーの有効長が、それらはいくつかの短いキー、すなわちから合成されるという事実によって損なわれない、128ビットの有効な長さであってもよいです達成。追加の考慮事項については、12.8項を参照してください。
The EAP Transient Keys used to protect EAP-SIM packets (K_encr, K_aut), the Master Session Key, and the Extended Master Session Key are cryptographically separate in EAP-SIM. An attacker cannot derive any non-trivial information about any of these keys based on the other keys. An attacker also cannot calculate the pre-shared secret (Ki) from the GSM Kc keys, from EAP-SIM K_encr, from EAP-SIM K_aut, from the Master Session Key, or from the Extended Master Session Key.
EAP一時キーはEAP-SIMパケット（K_encr、K_aut）を保護するために使用され、マスターセッションキー、および拡張マスターセッションキーは、EAP-SIMで、暗号別のものです。攻撃者は、他のキーに基づいて、これらのキーのいずれかについての非自明な情報を引き出すことができません。攻撃者はまた、EAP-SIM K_encrから、EAP-SIM K_autから、マスターセッションキーから、または拡張マスターセッションキーから、GSMのKcキーから事前共有秘密（KI）を計算することはできません。
Each EAP-SIM exchange generates fresh keying material, and the keying material exported from the method upon separate EAP-SIM exchanges is cryptographically separate. The EAP-SIM peer contributes to the keying material with the NONCE_MT parameter, which must be chosen freshly for each full authentication exchange. The EAP server is mandated to choose the RAND challenges freshly for each full authentication exchange. If either the server or the peer chooses its random value (NONCE_MT or RAND challenges) freshly, even if the other entity re-used its value from a previous exchange, then the EAP Transient Keys, the Master Session Key, and the Extended Master Session Key will be different and cryptographically separate from the corresponding values derived upon the previous full authentication exchange.
各EAP-SIM交換は、新鮮な鍵材料を生成し、別個のEAP-SIM交換の際方法からエクスポート鍵材料は、別個の暗号です。 EAP-SIMピアはそれぞれ完全な認証交換のために新たに選択されなければならないNONCE_MTパラメータを使用して鍵材料に寄与する。 EAPサーバは、RANDを選択することが義務付けられている各完全な認証交換に新鮮に挑戦。サーバーまたはピアは、そのランダムな値を選択した場合、他のエンティティは、以前の交換機からその値を再使用した場合でも、たて（NONCE_MTまたはRANDは挑戦）、その後、EAP一時キーズ、マスターセッションキー、および拡張マスターセッションキーは異なり、前の完全な認証交換の際に誘導された対応する値とは別の暗号あろう。
On fast re-authentication, freshness of the Master Session Key and the Extended Master Session Key is provided with a counter (AT_COUNTER). The same EAP Transient Keys (K_encr, K_aut) that were used in the full authentication exchange are used to protect the EAP negotiation. However, replay and integrity protection across all the fast re-authentication exchanges that use the same EAP Transient Keys is provided with AT_COUNTER.
高速再認証では、マスターセッションキーおよび拡張マスターセッションキーの鮮度はカウンタ（AT_COUNTER）が設けられています。完全な認証交換に使用したのと同じEAP一時キーズ（K_encr、K_aut）は、EAPネゴシエーションを保護するために使用されています。しかし、同じEAP一時キーを使用するすべての高速再認証交換全体でリプレイ性と完全性保護がAT_COUNTERを備えています。
[RFC3748] defines session independence as the "demonstration that passive attacks (such as capture of the EAP conversation) or active attacks (including compromise of the MSK or EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs". Because the MSKs and EMSKs are separate between EAP exchanges, EAP-SIM supports this security claim.
[RFC3748]は、「または（MSK又はEMSKの妥協を含む）アクティブな攻撃（例えば、EAPの会話の捕捉など）、受動的攻撃は、後続または先行たMSK又はEMSKsの妥協を有効にしないことを実証」としてセッションの独立性を定義します。たMSKとEMSKsはEAP交換の間に分離されているので、EAP-SIMは、このセキュリティ主張をサポートしています。
It should be noted that [Patel-2003], which predates [RFC3748], uses a slightly different meaning for session independence. The EAP-SIM protocol does not allow the peer to ensure that different Kc key values would be used in different exchanges. Only the server is able to ensure that fresh RANDs, and therefore, fresh Kc keys are used.
セッションの独立のため、わずかに異なる意味を使用して、[パテル-2003]、[RFC3748]を先行していることに留意すべきです。 EAP-SIMプロトコルは、ピアが異なるKcのキー値が異なる交換に使用されることを保証することはできません。サーバだけがその新鮮ランズを確保することが可能であるため、新鮮Kcのキーが使用されています。
Hence, the peer cannot guarantee EAP-SIM sessions to be independent with regard to the internal Kc values. However, in EAP-SIM, the Kc keys are considered to be secret intermediate results, which are not exported outside the method. See Section 12.3 for more information about RAND re-use.
したがって、ピアは、内部のKc値に関して独立しているように、EAP-SIMセッションを保証することはできません。しかしながら、EAP-SIMで、Kcをキーはメソッド外に輸出されていない秘密の中間結果であると考えられます。 RANDの再利用についての詳細は、12.3節を参照してください。
Because EAP-SIM is not a password protocol, it is not vulnerable to dictionary attacks. (The pre-shared symmetric secret stored on the SIM card is not a passphrase, nor is it derived from a passphrase.)
EAP-SIMは、パスワードプロトコルではありませんので、それは辞書攻撃に対して脆弱ではありません。 （SIMカードに格納された事前共有対称秘密パスフレーズではない、またそれは、パスフレーズから誘導されます。）
EAP-SIM cannot prevent attacks over the GSM or GPRS radio networks. If the same SIM credentials are also used in GSM or GPRS, it is possible to mount attacks over the cellular interface.
EAP-SIMは、GSMやGPRS無線ネットワークを介した攻撃を防ぐことはできません。同じSIM資格情報はまた、GSMやGPRSに使用されている場合、携帯インタフェースを介した攻撃を実装することが可能となります。
A passive attacker can eavesdrop GSM or GPRS traffic and obtain RAND, SRES pairs. He can then use a brute force attack or other cryptanalysis techniques to obtain the 64-bit Kc keys used to encrypt the GSM or GPRS data. This makes it possible to attack each 64-bit key separately.
受動的攻撃者がGSMまたはGPRSトラフィックを盗聴し、RAND、SRESペアを取得することができます。彼は、その後、GSM又はGPRSデータを暗号化するために使用される64ビットのKc鍵を取得するためにブルートフォース攻撃または他の暗号解読技術を使用することができます。これは、個別に各64ビットの鍵を攻撃することが可能となります。
An active attacker can mount a "rogue GSM/GPRS base station attack", replaying previously seen RAND challenges to obtain SRES values. He can then use a brute force attack to obtain the Kc keys. If successful, the attacker can impersonate a valid network or decrypt previously seen traffic, because EAP-SIM does not provide perfect forward secrecy (PFS).
活発な攻撃者は、SRES値を得るために、以前に見たRAND挑戦を再生、「不正なGSM / GPRS基地局攻撃」をマウントすることができます。彼はその後、Kcのキーを取得するためにブルートフォース攻撃を使用することができます。成功した場合は、EAP-SIMが完全転送秘密（PFS）を提供していないため、攻撃者は、有効なネットワークを偽装したり、以前に見られたトラフィックを復号化することができます。
Due to several weaknesses in the GSM encryption algorithms, the effective key strength of the Kc keys is much less than the expected 64 bits (no more than 40 bits if the A5/1 GSM encryption algorithm is used; as documented in [Barkan-2003], an active attacker can force the peer to use the weaker A5/2 algorithm that can be broken in less than a second).
GSM暗号化アルゴリズムにはいくつかの弱点に、Kcの鍵の有効鍵強度は、予想される64ビット（A5 / 1 GSM暗号化アルゴリズムが使用される場合超えない40ビットよりもはるかに小さい。[Barkan-2003に記載されるよう]、活発な攻撃者は、1秒未満で破壊することができる弱いA5 / 2アルゴリズム）を使用するピアを強制することができます。
Because the A5 encryption algorithm is not used in EAP-SIM, and because EAP-SIM does not expose any values calculated from individual Kc keys, it should be noted that these attacks are not possible if the SIM credentials used in EAP-SIM are not shared in GSM/GPRS.
A5の暗号化アルゴリズムは、EAP-SIMで使用されていない、とEAP-SIMは、個々のKcキーから計算された値を公開していないので、EAP-SIMで使用されるSIMの認証情報がない場合は、これらの攻撃は可能ではないことに留意すべきであるのでGSM / GPRSで共有しました。
At the time this document was written, the 3rd Generation Partnership Project (3GPP) has started to work on fixes to these A5 vulnerabilities. One of the solution proposals discussed in 3GPP is integrity-protected A5 version negotiation, which would require the base station to prove knowledge of the Kc key before the terminal sends any values calculated from the Kc to the network. Another proposal is so-called special RANDs, where some bits of the RAND challenge would be used for cryptographic separation by indicating the allowed use of the triplet, such as the allowed A5 algorithm in GSM or the fact that the triplet is intended for EAP-SIM. This is currently a work in progress, and the mechanisms have not been selected yet.
この文書が書かれた時点では、3GPP（3rd Generation Partnership Project）は、これらのA5の脆弱性への修正に取り組み始めています。 3GPPで議論ソリューション提案の一つは、端末がネットワークにKcをから計算された値を送信する前のKcキーの知識を証明するために基地局を必要とする完全性保護されたA5版の交渉、です。別の提案は、GSMにおける許容A5アルゴリズムまたはトリプレットがEAP-のために意図されていることを事実としてRANDチャレンジのいくつかのビットはトリプレットの許可使用を指示することにより暗号分離のために使用される、いわゆる特殊ランズ、ありますSIM。これは、現在進行中の作業であり、メカニズムはまだ選択されていません。
AT_MAC, AT_IV, AT_ENCR_DATA, and AT_COUNTER attributes are used to provide integrity, replay and confidentiality protection for EAP-SIM requests and responses. Integrity protection with AT_MAC includes the EAP header. These attributes cannot be used during the EAP/SIM/Start roundtrip. However, the protocol values (user identity string, NONCE_MT, and version negotiation parameters) are (implicitly) protected by later EAP-SIM messages by including them in key derivation.
AT_MAC、AT_IV、AT_ENCR_DATA、およびAT_COUNTER属性はEAP-SIMの要求と応答のための整合性、リプレイや機密性保護を提供するために使用されています。 AT_MACと完全性保護は、EAPヘッダを含みます。これらの属性は、EAP / SIM /スタート往復旅行中に使用することはできません。しかし、プロトコル値（ユーザーID文字列、NONCE_MT、およびバージョン交渉パラメータ）（暗黙的に）キー導出にそれらを含めることにより、後でEAP-SIMメッセージによって保護されています。
Integrity protection (AT_MAC) is based on a keyed message authentication code. Confidentiality (AT_ENCR_DATA and AT_IV) is based on a block cipher.
完全性保護（AT_MAC）は、鍵付きメッセージ認証コードに基づいています。機密性（AT_ENCR_DATAとAT_IV）は、ブロック暗号に基づいています。
Confidentiality protection is applied only to a part of the protocol fields. The table of attributes in Section 10.1 summarizes which fields are confidentiality-protected. It should be noted that the error and notification code attributes AT_CLIENT_ERROR_CODE and AT_NOTIFICATION are not confidential, but they are transmitted in the clear. Identity protection is discussed in Section 12.2.
機密性の保護は唯一のプロトコルフィールドの一部に適用されます。セクション10.1内の属性のテーブルには、フィールドが機密保護されているまとめたものです。エラーと通知コードがAT_CLIENT_ERROR_CODEとAT_NOTIFICATIONが機密ではありませんが、それらは明らかで送信されている属性のことに留意すべきです。アイデンティティ保護は、セクション12.2で説明されています。
On full authentication, replay protection of the EAP exchange is provided by the RAND values from the underlying GSM authentication scheme and the use of the NONCE_MT value. Protection against replays of EAP-SIM messages is also based on the fact that messages that can include AT_MAC can only be sent once with a certain EAP-SIM Subtype, and on the fact that a different K_aut key will be used for calculating AT_MAC in each full authentication exchange.
完全な認証に、EAP交換のリプレイ保護は、基礎となるGSM認証方式及びNONCE_MT値の使用からRAND値によって提供されます。 EAP-SIMメッセージのリプレイに対する保護もAT_MACを含むことができるメッセージのみ特定のEAP-SIMサブタイプで一度送信され、異なるK_autキーはそれぞれAT_MACを計算するために使用されるという事実にすることができるという事実に基づいています完全な認証交換。
On fast re-authentication, a counter included in AT_COUNTER and a server random nonce is used to provide replay protection. The AT_COUNTER attribute is also included in EAP-SIM notifications if it is used after successful authentication in order to provide replay protection between re-authentication exchanges.
高速再認証では、カウンタはAT_COUNTERに含まれており、サーバーのランダムなナンスはリプレイ保護を提供するために使用されます。それは再認証交換の間のリプレイ保護を提供するために、認証成功後に使用されている場合AT_COUNTER属性はまた、EAP-SIM通知に含まれています。
Because EAP-SIM is not a tunneling method, EAP-Request/Notification, EAP-Response/Notification, EAP-Success, or EAP-Failure packets are not confidential, integrity-protected, or replay-protected in EAP-SIM. On physically insecure networks, this may enable an attacker to send false notifications to the peer and to mount denial of service attacks by spoofing these packets. As discussed in Section 6.3, the peer will only accept EAP-Success after the peer successfully authenticates the server. Hence, the attacker cannot force the peer to believe successful mutual authentication has occurred until the peer successfully authenticates the server or after the peer fails to authenticate the server.
EAP-SIMがトンネリング方式ではないので、EAP要求/通知、EAP応答/通知、EAP-成功、またはEAP-失敗パケットは、機密完全性保護された、またはリプレイ保護されたEAP-SIMではありません。物理的に安全でないネットワークでは、これはピアに虚偽の通知を送信するために、攻撃者を可能にし、これらのパケットをスプーフィングすることにより、サービス拒否攻撃をマウントします。 6.3節で説明したように、ピアが正常にサーバを認証した後、ピアはEAP-成功を受け入れます。そのため、攻撃者は、ピアが正常にサーバを認証またはピアの後にサーバを認証に失敗するまで成功した相互認証が発生していると信じてピアを強制することはできません。
The security considerations of EAP-SIM result indications are covered in Section 12.11
EAP-SIMの結果指摘のセキュリティの考慮事項は、セクション12.11で覆われています
An eavesdropper will see the EAP-Request/Notification, EAP-Response/Notification, EAP-Success, and EAP-Failure packets sent in the clear. With EAP-SIM, confidential information MUST NOT be transmitted in EAP Notification packets.
盗聴者が平文で送信されたEAP要求/通知、EAP応答/通知、EAP-成功、およびEAP-失敗パケットが表示されます。 EAP-SIMを使用すると、機密情報は、EAP通知パケットで送信してはなりません。
EAP-SIM does not protect the EAP-Response/Nak packet. Because EAP-SIM does not protect the EAP method negotiation, EAP method downgrading attacks may be possible, especially if the user uses the same identity with EAP-SIM and other EAP methods.
EAP-SIMは、EAP応答/ NAKパケットを保護しません。 EAP-SIMがEAPメソッドのネゴシエーションを保護しないので、EAPメソッド格下げ攻撃は、ユーザがEAP-SIMおよび他のEAPメソッドと同じIDを使用している場合は特に、可能かもしれません。
EAP-SIM includes a version negotiation procedure. In EAP-SIM the keying material derivation includes the version list and selected version to ensure that the protocol cannot be downgraded and that the peer and server use the same version of EAP-SIM.
EAP-SIMは、バージョン交渉手順が含まれています。 EAP-SIMに鍵材料導出バージョンのリストとプロトコルはダウングレードし、ピア及びサーバはEAP-SIMの同じバージョンを使用することができないことを保証するために選択されたバージョンを含みます。
EAP-SIM does not support ciphersuite negotiation.
EAP-SIMは、暗号スイートネゴシエーションをサポートしていません。
EAP-SIM supports optional protected success indications and acknowledged failure indications. If a failure occurs after successful authentication, then the EAP-SIM failure indication is integrity- and replay-protected.
EAP-SIMは、オプションの保護された成功指摘をサポートし、失敗指摘を認めました。失敗が認証に成功した後に発生した場合、EAP-SIM障害表示は・インテグリティおよびリプレイ保護されています。
Even if an EAP-Failure packet is lost when using EAP-SIM over an unreliable medium, then the EAP-SIM failure indications will help ensure that the peer and EAP server will know the other party's authentication decision. If protected success indications are used, then the loss of Success packet will also be addressed by the acknowledged, integrity- and replay-protected EAP-SIM success indication. If the optional success indications are not used, then the peer may end up believing that the server succeeded authentication, when it actually failed. Since access will not be granted in this case, protected result indications are not needed unless the client is not able to realize it does not have access for an extended period of time.
信頼性の低い媒体を介してEAP-SIMを使用した場合、EAP-Failureパケットが失われた場合でも、その後、EAP-SIMの失敗指摘は、ピアとEAPサーバが相手の認証決定を知っているだろうことを保証するのに役立ちます。保護された成功指摘が使用される場合、成功パケットの損失も認め、・インテグリティおよびリプレイ保護されたEAP-SIMの成功指示によって対処されます。オプションの成功指摘が使用されていない場合、ピアは、それが実際に失敗したときに、サーバーが認証を成功したことを信じてしまうことがあります。アクセスは、この場合に付与されることはありませんので、クライアントは、それが長時間のためのアクセスを持っていない実現することができない場合を除き、保護された結果の表示は必要ありません。
In order to avoid man-in-the-middle attacks and session hijacking, user data SHOULD be integrity-protected on physically insecure networks. The EAP-SIM Master Session Key, or keys derived from it, MAY be used as the integrity protection keys, or, if an external security mechanism such as PEAP is used, then the link integrity protection keys MAY be derived by the external security mechanism.
man-in-the-middle攻撃とセッションハイジャックを防ぐために、ユーザデータは、物理的に安全でないネットワーク上の整合性は、保護されるべきです。 EAP-SIMマスターセッションキー、またはそれから派生したキーは、完全性保護キーとして使用してもよいし、あるいは、そのようPEAPなどの外部セキュリティ・メカニズムが使用されている場合は、リンク完全性保護鍵は外部セキュリティ・メカニズムによって誘導することができます。
There are man-in-the-middle attacks associated with the use of any EAP method within a tunneled protocol. For instance, an early version of PEAP [PEAP-02] was vulnerable to this attack. This specification does not address these attacks. If EAP-SIM is used with a tunneling protocol, there should be cryptographic binding provided between the protocol and EAP-SIM to prevent man-in-the-middle attacks through rogue authenticators being able to setup one-way authenticated tunnels. For example, newer versions of PEAP include such cryptographic binding. The EAP-SIM Master Session Key MAY be used to provide the cryptographic binding. However, the mechanism by which the binding is provided depends on the tunneling protocol and is beyond the scope of this document.
トンネル化プロトコル内の任意のEAP方式の使用に関連したman-in-the-middle攻撃があります。たとえば、PEAP [PEAP-02]の初期のバージョンでは、この攻撃に対して脆弱でした。この仕様は、これらの攻撃には対処できません。 EAP-SIMは、トンネリングプロトコルで使用される場合、セットアップ一方向認証トンネルすることができる不正オーセンティケータを介してman-in-the-middle攻撃を防止するために、プロトコル及びEAP-SIMとの間に設けられた結合暗号化があるべきです。例えば、PEAPの新しいバージョンは、このような暗号化的結合を含みます。 EAP-SIMマスターセッションキーは暗号バインディングを提供するために使用され得ます。しかしながら、結合が提供されるメカニズムは、トンネリングプロトコルに依存し、この文書の範囲外です。
An EAP-SIM implementation SHOULD use a good source of randomness to generate the random numbers required in the protocol. Please see [RFC4086] for more information on generating random numbers for security applications.
EAP-SIMの実装では、プロトコルに必要な乱数を生成するのに偶発性の良い源を使用すべきです。セキュリティアプリケーションのために乱数を生成の詳細については、[RFC4086]を参照してください。
This section provides the security claims required by [RFC3748].
このセクションでは、[RFC3748]で必要なセキュリティクレームを提供します。
Auth. mechanism: EAP-SIM is based on the GSM SIM mechanism, which is a challenge/response authentication and key agreement mechanism based on a symmetric 128-bit pre-shared secret. EAP-SIM also makes use of a peer challenge to provide mutual authentication.
認証。機構：EAP-SIMは、対称128ビットの事前共有秘密に基づいて、チャレンジ/レスポンス認証と鍵合意のメカニズムであるGSM SIM機構に基づいています。 EAP-SIMはまた、相互認証を提供するために、ピアチャレンジを使用しています。
Ciphersuite negotiation: No
暗号スイートのネゴシエーション：いいえ
Mutual authentication: Yes (Section 12.3)
相互認証：はい（12.3節）
Integrity protection: Yes (Section 12.9)
整合性の保護：はい（セクション12.9）
Replay protection: Yes (Section 12.9)
リプレイ保護：はい（セクション12.9）
Confidentiality: Yes, except method-specific success and failure indications (Section 12.2, Section 12.9)
機密性：はい、メソッド固有の成功と失敗の表示（第12.2節12.9）を除きます
Key derivation: Yes
キー派生：はい
Key strength: EAP-SIM supports key derivation with 128-bit effective key strength (Section 12.5). However, as discussed in Section 11, if the same credentials are used in GSM/GPRS and in EAP-SIM, then the key strength may be reduced considerably, basically to the same level as in GSM, by mounting attacks over GSM/GPRS. For example an active attack using a false GSM/GPRS base station reduces the effective key strength to almost zero.
キー強度：EAP-SIMは、128ビットの実効キー強度（12.5項）と鍵導出をサポートしています。しかし、同じ資格情報がGSM / GPRSおよびEAP-SIMで使用される場合、セクション11で説明したように、その後、鍵強度はGSM / GPRS上取付攻撃することによって、基本的にはGSMと同じレベルにまで、大幅に低減することができます。例えば、偽GSM / GPRS基地局を使用してアクティブな攻撃は、ほぼゼロに有効なキーの強度を低下させます。
Description of key hierarchy: Please see Section 7.
キー階層の説明：セクション7を参照してください。
Dictionary attack protection: N/A (Section 12.7)
辞書攻撃からの保護：N / A（12.7節）
Fast reconnect: Yes
高速再接続：はい
Cryptographic binding: N/A
暗号化は、バインディング：N / A
Session independence: Yes (Section 12.6)
セッション独立：はい（セクション12.6）
Fragmentation: No
フラグメンテーション：いいえ
Channel binding: No
チャンネルは、バインディング：いいえ
Indication of vulnerabilities: Vulnerabilities are discussed in Section 12.
脆弱性の目安：脆弱性は、セクション12で議論されています。
In addition to the editors, Nora Dabbous, Jose Puthenkulam, and Prasanna Satarasinghe were significant contributors to this document.
編集者に加えて、ノラDabbous、ホセPuthenkulam、およびプラザンナSatarasingheはこのドキュメントへの重要な貢献者でした。
Pasi Eronen and Jukka-Pekka Honkanen contributed Appendix A.
パシEronenとユッカ=ペッカ・ホンカネンは、付録Aを拠出しました
Juha Ala-Laurila, N. Asokan, Jan-Erik Ekberg, Patrik Flykt, Jukka-Pekka Honkanen, Antti Kuikka, Jukka Latva, Lassi Lehtinen, Jyri Rinnemaa, Timo Takamaki, and Raimo Vuonnala contributed many original ideas and concepts to this protocol.
ユハ・アラ - Laurila、N.アソカ、ジャン・エリック・エクバーグ、パトリックFlykt、ユッカ=ペッカ・ホンカネン、アンティKuikka、ユッカLatva、ラッシーLehtinenの、Jyri Rinnemaa、ティモTakamaki、およびRaimo Vuonnalaは、このプロトコルには多くの独創的なアイデアやコンセプトを貢献しました。
N. Asokan, Pasi Eronen, and Jukka-Pekka Honkanen contributed and helped in innumerable ways during the development of the protocol.
N. Asokan、パシEronen、およびユッカ=ペッカ・ホンカネンが貢献し、プロトコルの開発中に無数の方法で助けました。
Valtteri Niemi and Kaisa Nyberg contributed substantially to the design of the key derivation and the fast re-authentication procedure, and have also provided their cryptographic expertise in many discussions related to this protocol.
Valtteriニエミとカイサ・ニーバーグは鍵導出し、高速再認証手順の設計に大きく貢献し、また、このプロトコルに関連した多くの議論での暗号化の専門知識を提供してきました。
Simon Blake-Wilson provided very helpful comments on key derivation and version negotiation.
サイモン・ブレイク・ウィルソンは鍵導出およびバージョン交渉に非常に有用なコメントを提供しました。
Thanks to Greg Rose for his very valuable comments to an early version of this specification [S3-020125], and for reviewing and providing very useful comments on version 12.
この仕様の初期バージョンへの彼の非常に貴重なコメント[S3-020125]について、およびバージョン12に非常に有益なコメントを検討し、提供するためのグレッグ・ローズに感謝します。
Thanks to Bernard Aboba, Vladimir Alperovich, Florent Bersani, Jacques Caron, Gopal Dommety, Augustin Farrugia, Mark Grayson, Max de Groot, Prakash Iyer, Nishi Kant, Victor Lortz, Jouni Malinen, Sarvar Patel, Tom Porcher, Michael Richardson, Stefan Schroeder, Uma Shankar, Jesse Walker, and Thomas Wieland for their contributions and critiques. Special thanks to Max for proposing improvements to the MAC calculation.
バーナードAboba、ウラジミールAlperovich、フロランBersani、ジャック・キャロン、ゴパルDommety、オーギュFarrugia、マーク・グレイソン、マックス・デ・グルート、プラカシュアイヤル、西カント、ビクターLortz、Jouni Malinen、シャール・パテル、トム・ポルシェ、マイケル・リチャードソン、ステファン・シュローダーのおかげで、彼らの貢献と批判のためのユマ・シャンカール、ジェシーウォーカー、そしてトーマス・ヴィーラント。 MAC計算に改善を提案するマックスに感謝します。
Thanks to Glen Zorn for reviewing this document and for providing very useful comments on the protocol.
この文書を検討するためのプロトコルに非常に有益なコメントを提供するためのグレンソーンに感謝します。
Thanks to Sarvar Patel for his review of the protocol [Patel-2003].
プロトコル[パテル-2003]の彼のレビューのためのシャール・パテルに感謝します。
Thanks to Bernard Aboba for reviewing this document for RFC 3748 compliance.
RFC 3748準拠のため、この文書を検討するためのバーナードAbobaに感謝します。
The identity privacy support is based on the identity privacy support of [EAP-SRP]. The attribute format is based on the extension format of Mobile IPv4 [RFC3344].
アイデンティティプライバシーサポートは、[EAP-SRP]のアイデンティティプライバシーサポートに基づいています。属性フォーマットは、モバイルIPv4 [RFC3344]の拡張フォーマットに基づいています。
This protocol has been partly developed in parallel with EAP-AKA [EAP-AKA], and hence this specification incorporates many ideas from Jari Arkko.
このプロトコルは、部分的にEAP-AKA [EAP-AKA]と並行して開発されており、したがって本明細書ではヤリArkkoから多くのアイデアを組み込んでいます。
Nora Dabbous Gemplus 34 rue Guynemer 92447 Issy les Moulineaux France
ノラDabbousジェムプラス34 RUE Guynemer 92447イシレムリノーフランス
Phone: +33 1 4648 2000 EMail: nora.dabbous@gemplus.com
電話：+33 1 4648 2000 Eメール：nora.dabbous@gemplus.com
Jose Puthenkulam Intel Corporation 2111 NE 25th Avenue, JF2-58 Hillsboro, OR 97124 USA
ホセPuthenkulamインテルコーポレーション2111 NE 25日アベニュー、JF2-58ヒルズボロ、OR 97124 USA
Phone: +1 503 264 6121 EMail: jose.p.puthenkulam@intel.com
電話：+1 503 264 6121 Eメール：jose.p.puthenkulam@intel.com
Prasanna Satarasinghe Transat Technologies 180 State Street, Suite 240 Southlake, TX 76092 USA
プラザンナSatarasinghe Transatの技術180ステート・ストリート、スイート240サウスレイク、TX 76092 USA
Phone: + 1 817 4814412 EMail: prasannas@transat-tech.com
電話：+ 1 817 4814412 Eメール：prasannas@transat-tech.com
[GSM-03.20] European Telecommunications Standards Institute, "GSM Technical Specification GSM 03.20 (ETS 300 534): "Digital cellular telecommunication system (Phase 2); Security related network functions"", August 1997.
[GSM-03.20]欧州電気通信規格協会、 "GSM技術仕様GSM 03.20（ETS 300 534）：" デジタルセルラー通信システム（フェーズ2）。セキュリティ関連のネットワーク機能「」、1997年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[GSM-03.03] European Telecommunications Standards Institute, "GSM Technical Specification GSM 03.03 (ETS 300 523): "Digital cellular telecommunication system (Phase 2); Numbering, addressing and identification"", April 1997.
[GSM-03.03]欧州電気通信規格協会、 "GSM技術仕様GSM 03.03（ETS 300 523）：" デジタルセルラー通信システム（フェーズ2）。 1997年4月、「アドレッシングおよび識別」番号、。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[AES] National Institute of Standards and Technology, "Federal Information Processing Standards (FIPS) Publication 197, "Advanced Encryption Standard (AES)"", November 2001. http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf
[AES]米国国立標準技術研究所、「連邦情報処理規格（FIPS）出版197、 『高度暗号化標準（AES）』」、2001年11月http://csrc.nist.gov/publications/fips/fips197/ FIPS-197.pdf
[CBC] National Institute of Standards and Technology, "NIST Special Publication 800-38A, "Recommendation for Block Cipher Modes of Operation - Methods and Techniques"", December 2001. http://csrc.nist.gov/publications/nistpubs/ 800-38a/sp800-38a.pdf
[CBC]アメリカ国立標準技術研究所、「は、NIST Special Publication 800-38A、 『操作のブロック暗号モードのための推薦 - の方法と技術』」、2001年12月http://csrc.nist.gov/publications/nistpubs/ 800-38A / sp800-38a.pdf
[SHA-1] National Institute of Standards and Technology, U.S. Department of Commerce, "Federal Information Processing Standard (FIPS) Publication 180-1, "Secure Hash Standard"", April 1995.
[SHA-1]アメリカ国立標準技術研究所、米国商務省が、「連邦情報処理規格（FIPS）180-1公報、 『セキュアハッシュ標準』」、1995年4月。
[PRF] National Institute of Standards and Technology, "Federal Information Processing Standards (FIPS) Publication 186-2 (with change notice); Digital Signature Standard (DSS)", January 2000. Available on-line at: http://csrc.nist.gov/publications/ fips/fips186-2/fips186-2-change1.pdf
[PRF]米国国立標準技術研究所、「（変更通知付き）連邦情報処理規格（FIPS）186-2公報、デジタル署名標準（DSS）」は2000年1月には利用可能で、オンラインでます。http：// CSRC .nist.gov /出版/ FIPS / FIPS186-2 / FIPS186-2-change1.pdf
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[EAP-AKA] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
[EAP-AKA] Arkko、J.とH. Haverinen、 "第3世代認証及び鍵合意（EAP-AKA）のための拡張認証プロトコル方式"、RFC 4187、2006年1月。
[3GPP-TS-23.003] 3rd Generation Partnership Project, "3GPP Technical Specification 3GPP TS 23.003 V6.8.0: "3rd Generation Parnership Project; Technical Specification Group Core Network; Numbering, addressing and identification (Release 6)"", December 2005.
[3GPP-TS-23.003]第3世代パートナーシッププロジェクト、 "3GPP技術仕様書3GPP TS 23.003 V6.8.0：" 第3世代Parnershipプロジェクト。技術仕様グループコアネットワーク;ナンバリング、アドレッシングおよび識別2005年12月、 ""（リリース6）。
[3GPP-TS-55.205] 3rd Generation Partnership Project, "3GPP Technical Specification 3GPP TS 55.205 V 6.0.0: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Specification of the GSM-MILENAGE Algorithms: An example algorithm set for the GSM Authentication and Key Generation functions A3 and A8 (Release 6)"", December 2002.
[3GPP-TS-55.205]第3世代パートナーシッププロジェクト、 "3GPP技術仕様書3GPP TS 55.205 V 6.0.0：" 第3世代パートナーシッププロジェクト。グループサービス及びシステムアスペクト技術仕様; GSM-MILENAGEアルゴリズムの仕様：GSM認証と鍵の生成機能のための設定例アルゴリズムA3とA8（リリース6）「」、2002年12月。
[PEAP] Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in Progress, October 2004.
[PEAP] Palekar、A.、サイモン、D.、ゾルン、G.、Salowey、J.、周、H.、およびS. Josefsson氏、 "保護されたEAPプロトコル（PEAP）バージョン2"、進行中で働いて2004年10月。
[PEAP-02] Anderson, H., Josefsson, S., Zorn, G., Simon, D., and A. Palekar, "Protected EAP Protocol (PEAP)", Work in Progress, February 2002.
[PEAP-02]アンダーソン、H.、Josefsson氏、S.、ゾルン、G.、サイモン、D.、およびA. Palekar、 "保護されたEAPプロトコル（PEAP）"、進歩、2002年2月に働いています。
[EAP-Keying] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. Levkowetz, "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, October 2005.
[EAP-キーイング] Aboba、B.、サイモン、D.、Arkko、J.、Eronen、P.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）鍵管理フレームワーク"、進歩、2005年10月に作業。
[Service-Identity] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", Work in Progress, October 2004.
[サービスアイデンティティ] Arkko、J.、およびP. Eronen、「拡張認証プロトコル（EAP）のための認証サービスの情報」、進歩、2004年10月に作業。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、3、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[S3-020125] Qualcomm, "Comments on draft EAP/SIM, 3rd Generation Partnership Project document 3GPP TSG SA WG3 Security S3#22, S3-020125", February 2002.
[S3-020125]クアルコム、 "ドラフトEAP / SIMへのコメント、第3世代パートナーシップ・プロジェクトの文書3GPP TSG SA WG3セキュリティS3は＃22、S3-020125"、2002年2月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
[RFC3344]パーキンス、C.、 "IPv4のIPモビリティサポート"、RFC 3344、2002年8月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes ", RFC 2548, March 1999.
[RFC2548]ソーン、G.、 "マイクロソフトのベンダー固有のRADIUSアトリビュート"、RFC 2548、1999年3月。
[EAP-SRP] Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 Authentication Protocol", Work in Progress, July 2001.
[EAP-SRP]カールソン、J.、Aboba、B.、およびH. Haverinen、 "EAP SRP-SHA1認証プロトコル"、進歩、2001年7月ワーク。
[GSM-Cloning] Wagner, D., "GSM Cloning". Web page about COMP-128 version 1 vulnerabilities, available at http://www.isaac.cs.berkeley.edu/isaac/gsm.html
[GSM-クローニング]ワグナー、D.、 "GSMクローニング"。 http://www.isaac.cs.berkeley.edu/isaac/gsm.htmlで利用可能COMP-128バージョン1件の脆弱性に関するWebページ、
[Barkan-2003] Barkan, E., Biham, E., and N. Keller, "Instant Ciphertext-Only Cryptanalysis of GSM Encrypted Communications". available on-line at http://cryptome.org/gsm-crack-bbk.pdf
[Barkan-2003] Barkan、E.、Biham、E.、およびN.ケラー、 "GSM暗号化通信のインスタント暗号文のみ暗号解読"。 http://cryptome.org/gsm-crack-bbk.pdfでのオンライン利用可能
[Patel-2003] Patel, S., "Analysis of EAP-SIM Session Key Agreement". Posted to the EAP mailing list 29 May,2003. http:// mail.frascone.com/pipermail/public/eap/2003-May/ 001267.html
[パテル-2003]パテル、S.、 "EAP-SIMセッション鍵共有の分析"。 EAPメーリングリスト2003年5月29日に投稿されました。 http：// mail.frascone.com/pipermail/public/eap/2003-May/ 001267.html
Appendix A. Test Vectors
付録A.テストベクトル
Test vectors for the NIST FIPS 186-2 pseudo-random number generator [PRF] are available at the following URL: http://csrc.nist.gov/encryption/dss/Examples-1024bit.pdf
NIST FIPS 186-2擬似乱数生成器[PRF]のためのテストベクトルは、次のURLで入手可能である：http://csrc.nist.gov/encryption/dss/Examples-1024bit.pdf
The following examples show the contents of EAP-SIM packets on full authentication and fast re-authentication.
次の例では、完全な認証と速い再認証にEAP-SIMパケットの内容を示しています。
A.1. EAP-Request/Identity
A.1。 EAP要求/アイデンティティ
The first packet is a plain Identity Request:
最初のパケットは、プレーンアイデンティティ要求であります：
01 ; Code: Request 00 ; Identifier: 0 00 05 ; Length: 5 octets 01 ; Type: Identity
01;コード：リクエスト00;識別子：0 00 05。長さ：5つのオクテット01;タイプ：アイデンティティ
A.2. EAP-Response/Identity
A.2。 EAP応答/アイデンティティ
The client's identity is "1244070100000001@eapsim.foo", so it responds with the following packet:
それは、次のパケットで応答してクライアントのIDは、「1244070100000001@eapsim.foo」です。
02 ; Code: Response 00 ; Identifier: 0 00 20 ; Length: 32 octets 01 ; Type: Identity 31 32 34 34 ; "1244070100000001@eapsim.foo" 30 37 30 31 30 30 30 30 30 30 30 31 40 65 61 70 73 69 6d 2e 66 6f 6f
02;コード：レスポンス00;識別子：0 00 20。長さ：32個のオクテット01;タイプ：アイデンティティ31 32 34 34。 "1244070100000001@eapsim.foo" 30 37 30 31 30 30 30 30 30 30 30 31 40 65 61 70 73 69 6D 2E 66 6F 6F
A.3. EAP-Request/SIM/Start
A.3。 EAP要求/ SIM /スタート
The server's first packet looks like this:
サーバーの最初のパケットは次のようになります。
01 ; Code: Request 01 ; Identifier: 1 00 10 ; Length: 16 octets 12 ; Type: EAP-SIM 0a ; EAP-SIM subtype: Start 00 00 ; (reserved) 0f ; Attribute type: AT_VERSION_LIST 02 ; Attribute length: 8 octets (2*4) 00 02 ; Actual version list length: 2 octets 00 01 ; Version: 1 00 00 ; (attribute padding)
01;コード：リクエスト01;識別子：1 00 10。長さ：16個のオクテット12;タイプ：EAP-SIMの0A; EAP-SIMサブタイプ：スタート00 00。 （予約）0F。属性タイプ：AT_VERSION_LIST 02;長さ属性：8つのオクテット（2×4）00 02。実際のバージョンリストの長さ：2つのオクテット00 01。バージョン：1 00 00。 （属性パディング）
A.4. EAP-Response/SIM/Start
A.4。 EAP応答/ SIM /スタート
The client selects a nonce and responds with the following packet:
クライアントはnonceを選択して、次のパケットで応答します。
02 ; Code: Response 01 ; Identifier: 1 00 20 ; Length: 32 octets 12 ; Type: EAP-SIM 0a ; EAP-SIM subtype: Start 00 00 ; (reserved) 07 ; Attribute type: AT_NONCE_MT 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) 01 23 45 67 ; NONCE_MT value 89 ab cd ef fe dc ba 98 76 54 32 10 10 ; Attribute type: AT_SELECTED_VERSION 01 ; Attribute length: 4 octets (1*4) 00 01 ; Version: 1
02;コード：レスポンス01;識別子：1 00 20。長さ：32個のオクテット12;タイプ：EAP-SIMの0A; EAP-SIMサブタイプ：スタート00 00。 （予約）07。属性タイプ：AT_NONCE_MT 05;長さ属性：20個のオクテット（5 * 4）00 00。 01 23 45 67（予約）。 NONCE_MT値89のABは、CD、EF FE直流BA 98 76 54 32 10 10。属性タイプ：AT_SELECTED_バージョン01。長さ属性：4つのオクテット（1 * 4）00 01。バージョン：1
A.5. EAP-Request/SIM/Challenge
A.5。 EAP要求/ SIM /挑戦
Next, the server selects three authentication triplets
次に、サーバは、3つの認証トリプレットを選択します
(RAND1,SRES1,Kc1) = (10111213 14151617 18191a1b 1c1d1e1f,
d1d2d3d4,
a0a1a2a3 a4a5a6a7)
(RAND2,SRES2,Kc2) = (20212223 24252627 28292a2b 2c2d2e2f,
e1e2e3e4,
b0b1b2b3 b4b5b6b7)
(RAND3,SRES3,Kc3) = (30313233 34353637 38393a3b 3c3d3e3f,
f1f2f3f4,
c0c1c2c3 c4c5c6c7)
Next, the MK is calculated as specified in Section 7*.
次に、MKは、第7 *で指定されているように計算されます。
MK = e576d5ca 332e9930 018bf1ba ee2763c7 95b3c712
MK = e576d5ca 332e9930 018bf1ba ee2763c7 95b3c712
And the other keys are derived using the PRNG:
そして、他のキーはPRNGを使用して導出されています。
K_encr = 536e5ebc 4465582a a6a8ec99 86ebb620
K_aut = 25af1942 efcbf4bc 72b39434 21f2a974
MSK = 39d45aea f4e30601 983e972b 6cfd46d1
c3637733 65690d09 cd44976b 525f47d3
a60a985e 955c53b0 90b2e4b7 3719196a
40254296 8fd14a88 8f46b9a7 886e4488
EMSK = 5949eab0 fff69d52 315c6c63 4fd14a7f
0d52023d 56f79698 fa6596ab eed4f93f
bb48eb53 4d985414 ceed0d9a 8ed33c38
7c9dfdab 92ffbdf2 40fcecf6 5a2c93b9
Next, the server selects a pseudonym and a fast re-authentication identity (in this case, "w8w49PexCazWJ&xCIARmxuMKht5S1sxR DqXSEFBEg3DcZP9cIxTe5J4OyIwNGVzxeJOU1G" and "Y24fNSrz8BP274jOJaF17WfxI8YO7QX0 0pMXk9XMMVOw7broaNhTczuFq53aEpOkk3L0dm@eapsim.foo", respectively).
次に、サーバは、匿名と速い再認証IDを選択する（この場合、「w8w49PexCazWJ＆xCIARmxuMKht5S1sxR DqXSEFBEg3DcZP9cIxTe5J4OyIwNGVzxeJOU1G」それぞれ「Y24fNSrz8BP274jOJaF17WfxI8YO7QX0 0pMXk9XMMVOw7broaNhTczuFq53aEpOkk3L0dm@eapsim.foo」）。
The following plaintext will be encrypted and stored in the AT_ENCR_DATA attribute:
以下の平文は、AT_ENCR_DATA属性に暗号化して保存されます。
84 ; Attribute type: AT_NEXT_PSEUDONYM
13 ; Attribute length: 76 octets (19*4)
00 46 ; Actual pseudonym length: 70 octets
77 38 77 34 39 50 65 78 43 61 7a 57 4a 26 78 43
49 41 52 6d 78 75 4d 4b 68 74 35 53 31 73 78 52
44 71 58 53 45 46 42 45 67 33 44 63 5a 50 39 63
49 78 54 65 35 4a 34 4f 79 49 77 4e 47 56 7a 78
65 4a 4f 55 31 47
00 00 ; (attribute padding)
85 ; Attribute type: AT_NEXT_REAUTH_ID
16 ; Attribute length: 88 octets (22*4)
00 51 ; Actual re-auth identity length: 81 octets
59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f
4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30
30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f
61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b
6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f
6f
00 00 00 ; (attribute padding)
06 ; Attribute type: AT_PADDING
03 ; Attribute length: 12 octets (3*4)
00 00 00 00
00 00 00 00
00 00
The EAP packet looks like this:
EAPパケットは次のようになります。
01 ; Code: Request 02 ; Identifier: 2 01 18 ; Length: 280 octets 12 ; Type: EAP-SIM 0b ; EAP-SIM subtype: Challenge 00 00 ; (reserved) 01 ; Attribute type: AT_RAND 0d ; Attribute length: 52 octets (13*4) 00 00 ; (reserved) 10 11 12 13 ; first RAND 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 ; second RAND 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
01;コード：リクエスト02;識別子：2 01 18。長さ：280オクテット12;タイプ：EAP-SIM 0B; EAP-SIMサブタイプ：チャレンジ00 00。 （予約）01。タイプ属性：AT_RANDの0Dを。長さ属性：52個のオクテット（13 * 4）00 00。 10 11 12 13（予約）。最初のRAND 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23。第RAND 24 25 26 27 28 29図2a図2b図2c図2d 2E 2F
30 31 32 33 ; third RAND 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 81 ; Attribute type: AT_IV 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) 9e 18 b0 c2 ; IV value 9a 65 22 63 c0 6e fb 54 dd 00 a8 95 82 ; Attribute type: AT_ENCR_DATA 2d ; Attribute length: 180 octets (45*4) 00 00 ; (reserved) 55 f2 93 9b bd b1 b1 9e a1 b4 7f c0 b3 e0 be 4c ab 2c f7 37 2d 98 e3 02 3c 6b b9 24 15 72 3d 58 ba d6 6c e0 84 e1 01 b6 0f 53 58 35 4b d4 21 82 78 ae a7 bf 2c ba ce 33 10 6a ed dc 62 5b 0c 1d 5a a6 7a 41 73 9a e5 b5 79 50 97 3f c7 ff 83 01 07 3c 6f 95 31 50 fc 30 3e a1 52 d1 e1 0a 2d 1f 4f 52 26 da a1 ee 90 05 47 22 52 bd b3 b7 1d 6f 0c 3a 34 90 31 6c 46 92 98 71 bd 45 cd fd bc a6 11 2f 07 f8 be 71 79 90 d2 5f 6d d7 f2 b7 b3 20 bf 4d 5a 99 2e 88 03 31 d7 29 94 5a ec 75 ae 5d 43 c8 ed a5 fe 62 33 fc ac 49 4e e6 7a 0d 50 4d 0b ; Attribute type: AT_MAC 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) fe f3 24 ac ; MAC value 39 62 b5 9f 3b d7 82 53 ae 4d cb 6a
30 31 32 33。第RAND 34 35 36 37 38 39図3a図3b図3c 3D 3E 3F 81。属性タイプ：AT_IV 05;長さ属性：20個のオクテット（5 * 4）00 00。 （予約）9E 18 B0 C2と; IV値9A 65 22 63 C0 6EのFB 54 DD 00 A8 95 82。タイプ属性：AT_ENCR_DATA 2dは、長さ属性：180個のオクテット（45 * 4）00 00。 （予約）55 F2 93 9B BD B1 B1 9E A1 B4 7F C0 B3 E0 53 58 35 4B D4 21 0F AB 2C F7 37 2D 98 E3 02 3C 6B B9 24 15 72 3D 58 BA D6 6C E0 84 E1 01 B6 4cはです82 78 AE A7のBF 2cとのBAのCE 33 10 6A ED DC 62 5B 0C 1D 5A A6 7aを41 73 9A E5 B5 79 50 97 3F C7 83 01 07 3C 6F 95 31 50 FF FC 30 3E A1 52 D1、E1の0Aの2D 1Fの4F 11 2F 07 A6 F8 BC 52 26 DA A1 EE 90 05 47 22 52 BD B3、B7 1D 6Fの0℃の3A 34 90 31 6C 46 92 98 71 BD 45 CD fdが71 79 90 D2 5F 6D D7 F2 B7 B3 20 BF 4dと5aとすること99 2E 88 03 31 D7 29 94 5A EC 75 AE 5D 43 C8 ED A5 FE 62 33 FC AC 49 4E E6 7aは0D 50 4D 0B。属性タイプ：AT_MAC 05;長さ属性：20個のオクテット（5 * 4）00 00。 （予約）FE F3 24 AC。 MAC値39 62 B5 9F 3B D7 82 53 AE 4D CB 6aと
The MAC is calculated over the EAP packet above (with MAC value set to zero), followed by the NONCE_MT value (a total of 296 bytes).
MACはNONCE_MT値（296バイトの合計）、続いて、（ゼロに設定したMAC値）上記のEAPパケットに対して計算されます。
A.6. EAP-Response/SIM/Challenge
A.6。 EAP応答/ SIM /挑戦
The client's response looks like this:
クライアントの応答は次のようになります。
02 ; Code: Response 02 ; Identifier: 2 00 1c ; Length: 28 octets 12 ; Type: EAP-SIM 0b ; EAP-SIM subtype: Challenge 00 00 ; (reserved) 0b ; Attribute type: AT_MAC 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) f5 6d 64 33 ; MAC value e6 8e d2 97 6a c1 19 37 fc 3d 11 54
02;コード：レスポンス02;識別子：2 00 1C。長さ：28個のオクテット12;タイプ：EAP-SIM 0B; EAP-SIMサブタイプ：チャレンジ00 00。 （予約）0B。属性タイプ：AT_MAC 05;長さ属性：20個のオクテット（5 * 4）00 00。 （予約）F5 6D 64 33。 MAC値E6 8E D2 97 6aはC1 19 37 FC 3D 11 54
The MAC is calculated over the EAP packet above (with MAC value set to zero), followed by the SRES values (a total of 40 bytes).
MACは、SRES値（40バイトの合計）、続いて上記のEAPパケット（ゼロに設定されたMAC値）にわたって計算されます。
A.7. EAP-Success
A.7。 EAP-成功
The last packet is an EAP-Success:
最後のパケットは、EAP-成功です。
03 ; Code: Success 02 ; Identifier: 2 00 04 ; Length: 4 octets
03;コード：成功02。識別子：2 00 04。長さ：4つのオクテット
A.8. Fast Re-authentication
A.8。高速再認証
When performing fast re-authentication, the EAP-Request/Identity packet is the same as usual. The EAP-Response/Identity contains the fast re-authentication identity (from AT_ENCR_DATA attribute above):
高速再認証を行う際に、EAP要求/アイデンティティパケットはいつもと同じです。 （AT_ENCR_DATAは、上記の属性から）EAP応答/アイデンティティが速い再認証のアイデンティティを含んでいます。
02 ; Code: Response 00 ; Identifier: 0 00 56 ; Length: 86 octets 01 ; Type: Identity 59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f 4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30 30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f 61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b 6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f 6f
02;コード：レスポンス00;識別子：0 00 56。長さ：86個のオクテット01;タイプ：アイデンティティ59 32 34 66 4E 53 72 7A 38 42 50 32 37 34 6aは4F 4aの61 46 31 37 57 66 78 49 38 59 4F 37 51 58 30 30 70 4D 58 6B 39 58 4D 4D 56 4F 77 37 62 72 6F 61 4E 68 54 63 7A 75 46 71 35 33 61 45 70 4F 6B 6B 33 4C 30 64 6D 40 65 61 70 73 69 66 6D 2E 6F 6F
A.9. EAP-Request/SIM/Re-authentication
A.9。 EAP要求/ SIM /再認証
The server recognizes the reauthentication identity, so it will respond with EAP-Request/SIM/Re-authentication. It retrieves the associated counter value, generates a nonce, and picks a new reauthentication identity (in this case, "uta0M0iyIsMwWp5TTdSdnOLvg2XDVf21OYt1vnfiMcs5dnIDHOIFVavIRzMR yzW6vFzdHW@eapsim.foo").
サーバーは再認証のアイデンティティを認識するので、EAP要求/ SIMで応答します/再認証。これは、関連するカウンタ値を取得nonceを生成し、新たな再認証のアイデンティティ（この場合、「uta0M0iyIsMwWp5TTdSdnOLvg2XDVf21OYt1vnfiMcs5dnIDHOIFVavIRzMR yzW6vFzdHW@eapsim.foo」）を選びます。
The following plaintext will be encrypted and stored in the AT_ENCR_DATA attribute. Note that AT_PADDING is not used because the length of the plaintext is a multiple of 16 bytes.
以下の平文は、AT_ENCR_DATA属性に暗号化して保存されます。平文の長さが16バイトの倍数であるためAT_PADDINGが使用されていないことに留意されたいです。
13 ; Attribute type: AT_COUNTER
01 ; Attribute length: 4 octets (1*4)
00 01 ; Counter value
15 ; Attribute type: AT_NONCE_S
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
01 23 45 67 ; NONCE_S value
89 ab cd ef
fe dc ba 98
76 54 32 10
85 ; Attribute type: AT_NEXT_REAUTH_ID
16 ; Attribute length: 88 octets (22*4)
00 51 ; Actual re-auth identity length: 81 octets
75 74 61 30 4d 30 69 79 49 73 4d 77 57 70 35 54
54 64 53 64 6e 4f 4c 76 67 32 58 44 56 66 32 31
4f 59 74 31 76 6e 66 69 4d 63 73 35 64 6e 49 44
48 4f 49 46 56 61 76 49 52 7a 4d 52 79 7a 57 36
76 46 7a 64 48 57 40 65 61 70 73 69 6d 2e 66 6f
6f
00 00 00 ; (attribute padding)
The EAP packet looks like this:
EAPパケットは次のようになります。
01 ; Code: Request 01 ; Identifier: 1 00 a4 ; Length: 164 octets 12 ; Type: EAP-SIM 0d ; EAP-SIM subtype: Re-authentication 00 00 ; (reserved) 81 ; Attribute type: AT_IV 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) d5 85 ac 77 ; IV value 86 b9 03 36 65 7c 77 b4 65 75 b9 c4 82 ; Attribute type: AT_ENCR_DATA 1d ; Attribute length: 116 octets (29*4) 00 00 ; (reserved) 68 62 91 a9 d2 ab c5 8c aa 32 94 b6 e8 5b 44 84 6c 44 e5 dc b2 de 8b 9e 80 d6 9d 49 85 8a 5d b8 4c dc 1c 9b c9 5c 01 b9 6b 6e ca 31 34 74 ae a6 d3 14 16 e1 9d aa 9d f7 0f 05 00 88 41 ca 80 14 96 4d 3b 30 a4 9b cf 43 e4 d3 f1 8e 86 29 5a 4a 2b 38 d9 6c 97 05 c2 bb b0 5c 4a ac e9 7d 5e af f5 64 04 6c 8b d3 0b c3 9b e5 e1 7a ce 2b 10 a6 0b ; Attribute type: AT_MAC 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) 48 3a 17 99 ; MAC value b8 3d 7c d3 d0 a1 e4 01 d9 ee 47 70
01;コード：リクエスト01;識別子：1 00 A4。長さ：164オクテット12;タイプ：EAP-SIMの0D。 EAP-SIMサブタイプ：再認証00 00。 （予約）81。属性タイプ：AT_IV 05;長さ属性：20個のオクテット（5 * 4）00 00。 （予約）85 AC 77 D5。 IV値86 B9 03 36 65 7C 77 B4 65 75 B9 C4は82;タイプ属性：AT_ENCR_DATA 1dは、長さ属性：116個のオクテット（29 * 4）00 00。 DC 1C 9B C9 5C 01 B9 6B 6E CA 31 34 74 AE 4C（予約）68 62 91 A9 D2 AB C5 8cのAA 32 94 B6 E8 5B 44 84 6C 44 E5 DC B2デ8B 9E 80 D6 9D 49 85 8A 5DのB8 A6 D3 14 16 E1 9D AA 9D F7 0F 05 00 88 41、CA 80 14 96 4D 3B 30 A4 9BのCF 43台のE4 D3のF1 8E 86 29 5A部4a 2B 38 D9 6C 97 05 C2のBB B0部5c 4A交流E9 7dと5EのAF用F5 64 04 6C 8B D3 0B C3 9B E5 E1 7aはCE 2B 10 A6 0B。属性タイプ：AT_MAC 05;長さ属性：20個のオクテット（5 * 4）00 00。 48 3A 17 99（予約）。 MAC値B8 3D 7C D3 D0 A1 E4 01 D9 eeで47 70
The MAC is calculated over the EAP packet above (with MAC value set to zero; a total of 164 bytes).
MACは、上記のEAPパケット（、164バイトの合計がゼロに設定されたMAC値）にわたって計算されます。
Finally, the server derives new keys. The XKEY' is calculated as described in Section 7*:
最後に、サーバは、新しいキーを導出します。第7 *で説明したようにXKEYは」計算されます。
XKEY' = 863dc120 32e08343 c1a2308d b48377f6 801f58d4
XKEY」= 863dc120 32e08343 c1a2308d b48377f6 801f58d4
The new MSK and EMSK are derived using the PRNG (note that K_encr and K_aut stay the same).
新しいMSKとEMSKはPRNG（K_encrとK_autが同じとどまることに注意してください）を使用して導出されています。
MSK = 6263f614 973895e1 335f7e30 cff028ee
2176f519 002c9abe 732fe0ef 00cf167c
756d9e4c ed6d5ed6 40eb3fe3 8565ca07
6e7fb8a8 17cfe8d9 adbce441 d47c4f5e
EMSK = 3d8ff786 3a630b2b 06e2cf20 9684c13f
6b82f992 f2b06f1b 54bf51ef 237f2a40
1ef5e0d7 e098a34c 533eaebf 34578854
b7721526 20a777f0 e0340884 a294fb73
A.10. EAP-Response/SIM/Re-authentication
A.10。 EAP応答/ SIM /再認証
The client's response includes the counter as well. The following plaintext will be encrypted and stored in the AT_ENCR_DATA attribute:
クライアントの応答は、同様にカウンタを含みます。以下の平文は、AT_ENCR_DATA属性に暗号化して保存されます。
13 ; Attribute type: AT_COUNTER
01 ; Attribute length: 4 octets (1*4)
00 01 ; Counter value
06 ; Attribute type: AT_PADDING
03 ; Attribute length: 12 octets (3*4)
00 00 00 00
00 00 00 00
00 00
The EAP packet looks like this:
EAPパケットは次のようになります。
02 ; Code: Response 01 ; Identifier: 1 00 44 ; Length: 68 octets 12 ; Type: EAP-SIM 0d ; EAP-SIM subtype: Re-authentication 00 00 ; (reserved) 81 ; Attribute type: AT_IV 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) cd f7 ff a6 ; IV value 5d e0 4c 02 6b 56 c8 6b 76 b1 02 ea 82 ; Attribute type: AT_ENCR_DATA 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) b6 ed d3 82 79 e2 a1 42 3c 1a fc 5c 45 5c 7d 56
02;コード：レスポンス01;識別子：1 00 44。長さ：68個のオクテット12;タイプ：EAP-SIMの0D。 EAP-SIMサブタイプ：再認証00 00。 （予約）81。属性タイプ：AT_IV 05;長さ属性：20個のオクテット（5 * 4）00 00。 （予約）のCD F7のFFのA6。 IV値5D E0 4C 02 6B 56 C8 6B 76 B1 02 EA 82。属性タイプ：AT_ENCR_DATA 05;長さ属性：20個のオクテット（5 * 4）00 00。 （予約）B6 ED D3 82 79 E2 A1 42 3C 1aはFC 5C 45 5C 7D 56
0b ; Attribute type: AT_MAC 05 ; Attribute length: 20 octets (5*4) 00 00 ; (reserved) fa f7 6b 71 ; MAC value fb e2 d2 55 b9 6a 35 66 c9 15 c6 17
0B;属性タイプ：AT_MAC 05;長さ属性：20個のオクテット（5 * 4）00 00。 （予約）のFA F7 6B 71。 MAC値FB E2 D2 55 B9部6a 35 66 C9 15 C6 17
The MAC is calculated over the EAP packet above (with MAC value set to zero), followed by the NONCE_S value (a total of 84 bytes).
MACはNONCE_S値（84バイトの合計）、続いて、（ゼロに設定したMAC値）上記のEAPパケットに対して計算されます。
The next packet will be EAP-Success:
次のパケットは、EAP-成功になります。
03 ; Code: Success 01 ; Identifier: 1 00 04 ; Length: 4 octets
03;コード：成功01。識別子：1 00 04。長さ：4つのオクテット
Appendix B. Pseudo-Random Number Generator
付録B.疑似乱数ジェネレータ
The "|" character denotes concatenation, and "^" denotes exponentiation.
「|」文字は連結を意味し、「^」は、べき乗を表します。
Step 1: Choose a new, secret value for the seed-key, XKEY
ステップ1：シード・キーのための新しい、秘密の値を選択して、XKEY
Step 2: In hexadecimal notation let t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0 This is the initial value for H0|H1|H2|H3|H4 in the FIPS SHS [SHA-1]
ステップ2：| H1 | H2 | H3 | 16進表記では、tは67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0これはH0の初期値である=せFIPSのSHS [SHA-1]でH4
Step 3: For j = 0 to m - 1 do
3.1 XSEED_j = 0 /* no optional user input */
3.2 For i = 0 to 1 do
a. XVAL = (XKEY + XSEED_j) mod 2^b
b. w_i = G(t, XVAL)
c. XKEY = (1 + XKEY + w_i) mod 2^b
3.3 x_j = w_0|w_1
Authors' Addresses
著者のアドレス
Henry Haverinen (editor) Nokia Enterprise Solutions P.O. Box 12 FIN-40101 Jyvaskyla Finland
ヘンリーHaverinen（編集）、Nokiaのエンタープライズソリューション私書箱ボックス12 FIN-40101ユヴァスキュラフィンランド
EMail: henry.haverinen@nokia.com
メールアドレス：henry.haverinen@nokia.com
Joseph Salowey (editor) Cisco Systems 2901 Third Avenue Seattle, WA 98121 USA
ジョセフSalowey（編集者）、シスコシステムズ2901 Third Avenueのシアトル、WA 98121 USA
Phone: +1 206 256 3380 EMail: jsalowey@cisco.com
電話：+1 206 256 3380 Eメール：jsalowey@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。