RFC4186 日本語訳
4186 Extensible Authentication Protocol Method for Global System forMobile Communications (GSM) Subscriber Identity Modules (EAP-SIM). H.Haverinen, Ed., J. Salowey, Ed.. January 2006. (Format: TXT=220807 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Haverinen, Ed.
Request for Comments: 4186 Nokia
Category: Informational J. Salowey, Ed.
Cisco Systems
January 2006
ワーキンググループH.Haverinen、エドをネットワークでつないでください。コメントのために以下を要求してください。 4186年のノキアカテゴリ: エド情報のJ.Salowey、シスコシステムズ2006年1月
Extensible Authentication Protocol Method for
Global System for Mobile Communications (GSM)
Subscriber Identity Modules (EAP-SIM)
汎欧州デジタルセルラーシステム(GSM)加入者アイデンティティモジュールのための拡張認証プロトコルメソッド(EAP-シム)
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).
Copyright(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は、EAP-SIMがEAPと互換性があることを確かめましたが、RFC3748で定義されるように他のレビューを全くしていません、セキュリティクレームの合法化を含んでいて。また、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認証と主要な協定に増進を指定します。 また、メカニズムはネットワーク認証、ユーザ匿名サポート、結果指摘、および速い再認証手順を含んでいます。
Haverinen & Salowey Informational [Page 1] RFC 4186 EAP-SIM Authentication January 2006
[1ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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
1. 序論…4 2. 用語…5 3. 概要…8 4. 操作…10 4.1. バージョン交渉…10 4.2. アイデンティティ管理…11 4.2.1. 同輩のアイデンティティの形式、世代、および用法…11 4.2.2. サーバへの同輩のアイデンティティを伝えます…17 4.2.3. EAP-応答/アイデンティティのためのアイデンティティの選択…19 4.2.4. 初めにEAP-SIM交換のサーバ操作…19 4.2.5. 同輩によるEAP-要求/SIM/始めの処理…20 4.2.6. アイデンティティプライバシーに対する攻撃…21 4.2.7. 処理する、_サーバによるアイデンティティで…22 4.3. メッセージ系列の例(有益な)…23 4.3.1. 完全な認証…24 4.3.2. 速い再認証…25 4.3.3. 完全な認証へ後ろへ下がってください…26 4.3.4. 永久的なアイデンティティ1を要求します…27 4.3.5. 永久的なアイデンティティ2を要求します…28 4.3.6. 3EAP-SIM/スタート往復旅行…28 5. 速い再認証…30 5.1. 一般…30 5.2. UMTS別名との比較…31 5.3. 速い再認証のアイデンティティ…31 5.4. 速い再認証手順…33 5.5. Counter Is Too Smallであることの速いRe-認証Procedure…36 6. EAP-SIM通知…37 6.1. 一般…37 6.2. 結果指摘…39 6.3. 誤り事件…40 6.3.1. 同輩操作…40 6.3.2. サーバ操作…41 6.3.3. EAP-失敗…42 6.3.4. EAP-成功…42 7. 重要世代…43 8. メッセージ・フォーマットとプロトコル伸展性…45 8.1. メッセージ形式…45 8.2. 伸展性について議定書の中で述べてください…47 9. メッセージ…48 9.1. EAP-Request/SIM/は始まります…48 9.2. EAP-Response/SIM/は始まります…49 9.3. EAP-Request/SIM/は挑戦します…49 9.4. EAP-Response/SIM/は挑戦します…50 9.5. 再EAP-要求/SIM/認証…51
Haverinen & Salowey Informational [Page 2] RFC 4186 EAP-SIM Authentication January 2006
[2ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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
9.6. 再EAP-応答/SIM/認証…51 9.7. クライアントEAP-応答/SIM/誤り…52 9.8. EAP-Request/SIM/、通知、…52 9.9. EAP-Response/SIM/、通知、…53 10. 属性…53 10.1. 属性のテーブル…53 10.2. _では、バージョン_は記載します…54 10.3. _選択された_バージョンで…55 10.4. _一回だけ_MTで…55 10.5. __永久的な_ID REQで…56 10.6. __どんな_ID REQでも…56 10.7. __FULLAUTH_ID REQで…57 10.8. _アイデンティティで…57 10.9. _底ならし革で…58 10.10. _次の_匿名で…59 10.11. _次の_REAUTH_IDで…59 10.12. _IVにおいて_ENCR_データにおいて_詰め物において…60 10.13. _結果_インディアン座で…62 10.14. _Macで…62 10.15. _では、反対してください…63 10.16. _では、__あまりに小さく反対してください…63 10.17. _一回だけ_Sで…64 10.18. _通知で…64 10.19. _クライアント_誤り_コードで…65 11. IANA問題…66 12. セキュリティ問題…66 12.1. A3とA8アルゴリズム…66 12.2. アイデンティティ保護…66 12.3. 互いの認証と三つ子の暴露…67 12.4. 認証センターをあふれさせます…69 12.5. キー派生…69 12.6. キーとセッション独立の暗号の分離…70 12.7. 辞書は攻撃されます…71 12.8. 資格証明書は…を再使用します…71 12.9. そして、保全、保護、および秘密性を再演してください…72 12.10. 交渉は攻撃されます…73 12.11. 結果指摘を保護します…73 12.12. 中央の男性は攻撃します…74 12.13. 乱数を生成します…74 13. セキュリティクレーム…74 14. 承認と貢献…75 14.1. 貢献者…75 14.2. 承認…75 14.2.1. 貢献者のアドレス…77 15. 参照…78 15.1. 標準の参照…78 15.2. 有益な参照…79
Haverinen & Salowey Informational [Page 3] RFC 4186 EAP-SIM Authentication January 2006
[3ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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
付録A.テストベクトル…81 A.1。 EAP-要求/アイデンティティ…81 A.2。 EAP-応答/アイデンティティ…81 A.3。 EAP-Request/SIM/は始まります…82 A.4。 EAP-Response/SIM/は始まります…82 A.5。 EAP-Request/SIM/は挑戦します…83 A.6。 EAP-Response/SIM/は挑戦します…86 A.7。 EAP-成功…86 A.8。 速い再認証…86 A.9。 再EAP-要求/SIM/認証…87 A.10。 再EAP-応答/SIM/認証…89 付録B.疑似乱数生成器…90
1. Introduction
1. 序論
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]は3番目の世代モバイルネットワークに使用されるAuthenticationとKey Agreement(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認証はチャレンジレスポンスメカニズムに基づいています。 挑戦として128ビットの乱数(RAND)をSIMの上で作業するA3/A8認証と主要な誘導アルゴリズムに与えることができます。 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
互いの認証の不足はGSM認証で弱点です。 より強くて、より長いキーが必要であるデータ網には、派生している64ビットの暗号キー(Kc)は十分強くはありません。 したがって、EAP-SIMでは、いくつかのRAND挑戦が、数個の64ビットのKcキーを生成するのに使用されます。(キーは、より強い合わせることの材料を構成するために結合されます)。 EAP-SIMでは、クライアントは、主要な派生に貢献して、前であるのからEAP-SIM要求の再生を防ぐためにネットワークへのNONCE_MTを乱数に発行します。
Haverinen & Salowey Informational [Page 4] RFC 4186 EAP-SIM Authentication January 2006
[4ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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.
交換。 ネットワークへのクライアントの挑戦として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.
基本的なGSMメカニズムEAP-SIMのセキュリティ所有地の上のEAP-SIM体格のセキュリティはこのドキュメントのセクション11に記録されます。 EAP-SIMのImplementersとユーザがセキュリティの特性が問題の環境で十分であるかどうか決定するために慎重にセクション11のセキュリティ問題を研究するようにアドバイスされます、特にKcキーの秘密保持がEAP-SIMのセキュリティに不可欠であるので。 要するに、GSMメカニズムより弱いどんな意味でもEAP-SIMがありません。いくつかの場合、EAP-SIMは基本的なGSMメカニズムより良いセキュリティ資産を提供します、特に、SIM資格証明書はEAP-SIMに使用されるだけであり、GSM/GPRSから再使用されないなら。 EAP-SIMのセキュリティ機能の多くがSIM三つ子でKc値の秘密保持を当てにされるので、これらの値を保護するのはEAP-SIMプロトコルのセキュリティに主要です。
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.
第3Generation Partnership Project(3GPP)は高められたAuthenticationとKey Agreement(AKA)アーキテクチャをUniversalのモバイルTelecommunications System(UMTS)に指定しました。 3番目の世代AKAメカニズムは、より長いセッションキーの互いの認証、反復操作による保護、および派生を含んでいます。 EAP-AKA[EAP-AKA]は3番目の世代AKAに基づいているEAPメソッドを指定します。 EAP-AKA(より安全なプロトコルである)はEAP-SIMの代わりに使用されるかもしれません、3番目の世代アイデンティティモジュールと3Gネットワークインフラが利用可能であるなら。
2. Terms
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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]で説明されるように解釈されることになっています。
Haverinen & Salowey Informational [Page 5] RFC 4186 EAP-SIM Authentication January 2006
[5ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
This document frequently uses the following terms and abbreviations:
このドキュメントは頻繁に以下の用語と略語を使用します:
AAA protocol
AAAプロトコル
Authentication, Authorization, and Accounting protocol
認証、Authorization、およびAccountingは議定書を作ります。
AuC
AuC
Authentication Centre. The GSM network element that provides
the authentication triplets for authenticating
the subscriber.
認証センター。 GSMは認証三つ子を加入者を認証するのに提供する要素をネットワークでつなぎます。
Authentication vector
認証ベクトル
GSM triplets can be alternatively called authentication
vectors.
代わりにGSM三つ子を認証ベクトルと呼ぶことができます。
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.
前の完全な認証交換のときに引き出されたキーに基づいているEAP-SIM認証交換。 GSM認証と主要な交換アルゴリズムは速い再認証手順で使用されません。
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.
分野が使用されている環境にNAI分野の部分を含む同輩の速い再認証のアイデンティティ。 速い再認証だけのときに、使用されています。
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.
EAP-SIM認証交換はアルゴリズムをGSM認証と主要な協定に基礎づけました。
GSM
GSM
Global System for Mobile communications.
モバイルコミュニケーションのためのグローバルなSystem。
Haverinen & Salowey Informational [Page 6] RFC 4186 EAP-SIM Authentication January 2006
[6ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
GSM Triplet
GSM三つ子
The tuple formed by the three GSM authentication values RAND,
Kc, and SRES.
tupleは3つのGSM認証値でRAND、Kc、およびSRESを形成しました。
IMSI
IMSI
International Mobile Subscriber Identifier, used in GSM to
identify subscribers.
加入者を特定するのにGSMで使用される国際モバイルSubscriber Identifier。
MAC
Mac
Message Authentication Code
メッセージ立証コード
NAI
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.
分野が使用されている環境にNAI分野の部分を含む同輩の永久的なアイデンティティ。 通常、永久的なアイデンティティはIMSIに基づいています。 完全な認証だけのときに、使用されています。
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.
分野が使用されている環境にNAI分野の部分を含む同輩の匿名のアイデンティティ。 完全な認証だけのときに、使用されています。
Haverinen & Salowey Informational [Page 7] RFC 4186 EAP-SIM Authentication January 2006
[7ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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.
加入者識別モジュール。 SIMは伝統的にGSMオペレータによって分配されたスマートカードです。
3. Overview
3. 概要
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 |
|<---------------------------------------------------------|
| |
同輩固有識別文字| EAP-要求/アイデンティティ| |<---------------------------------------------------------| | | | EAP-応答/アイデンティティ| |--------------------------------------------------------->| | | | EAP-要求/SIM/始め(_バージョン_リストの)| |<---------------------------------------------------------| | | | EAP-応答/SIM/始め(__一回だけ_MT、選択された_バージョンにおける)| |--------------------------------------------------------->| | | | EAP-要求/SIM/挑戦(__底ならし革、MACの)| |<---------------------------------------------------------| +-------------------------------------+ | | 同輩がGSMアルゴリズムを実行する、検証| | | AT_MAC、セッションキーを引き出します。| | +-------------------------------------+ | | EAP-応答/SIM/挑戦(_MACの)| |--------------------------------------------------------->| | | | EAP-成功| |<---------------------------------------------------------| | |
Figure 1: EAP-SIM full authentication procedure
図1: EAP-SIMの完全な認証手順
Haverinen & Salowey Informational [Page 8] RFC 4186 EAP-SIM Authentication January 2006
[8ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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 RequestはEAP-要求/アイデンティティです。 完全な認証のときに、アイデンティティプライバシーが有効であるなら、同輩の応答はユーザの移動加入者識別番号(IMSI)か一時的なアイデンティティ(匿名)のどちらかを含んでいます、セクション4.2で指定されるように。
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サーバからType18(SIM)のEAP Requestsを受け取って、対応するEAP Responsesを送ります。 また、Type SIMのものであるEAPパケットはSubtype分野を持っています。 完全な認証では、最初のEAP-要求/SIMパケットはSubtype10のもの(始まる)です。 EAP-SIMパケットはType、Length、Value形式でコード化された属性におけるパラメタをカプセル化します。 パケット・フォーマットと属性の使用はセクション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_バージョン_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).
同輩はEAP-応答/SIM/スタートパケットでEAP-要求/SIM/始めに応じます。(それは、同輩でNONCE_MTであって、選ばれた状態で乱数を含むAT_NONCE_MT属性を含んでいて、同輩で数が選択したバージョンを含むAT_SELECTED_バージョン属性を含んでいます)。 バージョン交渉は、合わせることの材料(セクション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.
EAP Response/SIM/始めを受けた後に、EAPサーバはnが2かnと等しいところで加入者を認証することにおける使用=3としてn GSM三つ子を得ます。 三つ子から、EAPサーバはセクション7で指定されるように合わせることの材料を誘導します。 Authentication Centre(AuC)にGSMネットワークへ連絡することによって、三つ子を得るかもしれません。 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 Serverが発行する次のEAP RequestはタイプSIMとsubtype Challenge(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
EAP-要求/SIM/挑戦メッセージを受け取り次第、同輩は、GSM認証アルゴリズムを実行して、メッセージ確認コードのコピーについて計算します。 そして、同輩は、計算されたMACが容認されたMACと等しいことを確かめます。 MACのものがマッチでない、その時に同輩をするなら
Haverinen & Salowey Informational [Page 9] RFC 4186 EAP-SIM Authentication January 2006
[9ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
sends the EAP-Response/SIM/Client-Error packet and the authentication exchange terminates.
クライアント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.
同輩に与えられたRANDsがメッセージ確認コード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.
すべてがチェックアウトされるなら、同輩はEAP-応答/SIM/挑戦で応じます、同輩のSRES応答値(セクション9.4)をカバーするAT_MAC属性を含んでいて。 EAPサーバは、MACが正しいことを確かめます。 保護された成功指摘がこの例で使用されないので、EAPサーバはEAP-成功パケットを送ります、認証がうまくいったのを示して。 (セクション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で説明されます。
4. Operation
4. 操作
4.1. Version Negotiation
4.1. バージョン交渉
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は、プロトコルにおける未来の発展を許容するためにバージョン交渉を含んでいます。 バージョン交渉は完全な認証に実行されます、そして、2つの属性を使用します、AT_バージョン_LIST、サーバが同輩が完全な認証におけるEAP-応答/SIM/始めに含んでいるEAP-要求/SIM/始め、およびAT_SELECTED_バージョンにいつも含んでいるどれ。
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
AT_バージョン_LISTはサーバによってサポートされたEAP-SIMバージョンを含めます。AT_バージョン_LISTが同輩によって実装されて、同輩の安全保障政策で許容されているバージョンを含んでいないなら、同輩はクライアントEAP-応答/SIM/誤りパケット(セクション9.7)をエラーコード「サポートされないバージョン」があるサーバに送らなければなりません。 aであるなら、適当なバージョンは含まれていて、次に、同輩はインクルードです。
Haverinen & Salowey Informational [Page 10] RFC 4186 EAP-SIM Authentication January 2006
[10ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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.
EAP-応答/SIM/スタートパケットに選択されたバージョンを含むAT_SELECTED_バージョン属性。 同輩は_AT_バージョンLISTに含まれているバージョンを示すだけでよいです。いくつかのバージョンが許容できるなら、同輩SHOULDは最初にバージョンリストに起こるバージョンを選びます。
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_バージョンLISTのバージョン数のリストとAT_SELECTED_バージョンの選択されたバージョンは主要な派生手順(セクション7)に含まれています。 攻撃者がこれらの属性のどちらかを変更するなら、同輩とサーバは異なった合わせることの材料を誘導します。 K_autキーが異なってサーバと同輩であるので、異なったAT_MAC値について計算してください。 したがって、同輩は、EAP-要求/SIM/挑戦に含まれていたそのAT_MACを検出して、不正確であり、クライアントEAP-応答/SIM/誤りパケットを送ります。 認証手順は終わります。
4.2. Identity Management
4.2. アイデンティティ管理
4.2.1. Format, Generation and Usage of Peer Identities
4.2.1. 同輩のアイデンティティの形式、世代、および用法
4.2.1.1. General
4.2.1.1. 一般
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認証では、通常、AuthenticatorかEAPサーバがEAP-要求/アイデンティティパケットを同輩に発行します。 同輩は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ケタモバイルのCountry Code(MCC)、2か3ケタモバイルのNetwork Code(MNC)、および10ケタ未満のモバイルSubscriber Identification Number(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プロトコルはNetwork Access Identifier(NAI)[RFC4282]とユーザを同一視します。 ローミング環境で使用されると、NAIは"@"( username@realm )で切り離されたユーザ名と分野で構成されます。 ユーザ名部分は分野の中で加入者を特定します。
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
このセクションはEAP-SIMで使用される同輩アイデンティティ形式を指定します。 本書では、「アイデンティティ」か「同輩のアイデンティティ」という用語は同輩を特定するのに使用される全体のアイデンティティストリングについて言及します。 同輩
Haverinen & Salowey Informational [Page 11] RFC 4186 EAP-SIM Authentication January 2006
[11ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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.
アイデンティティは分野の部分を含むかもしれません。 「ユーザ名」はユーザを特定する同輩のアイデンティティの部分を示します、すなわち、ユーザ名が分野の部分を含んでいません。
4.2.1.2. Identity Privacy Support
4.2.1.2. アイデンティティプライバシーサポート
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はcleartextの永久的なアイデンティティを隠して、その結果、加入者のEAP交換を立ち聞きする者にとって追跡不可能にするのに使用できる任意のアイデンティティプライバシー(匿名)サポートを含んでいます。 永久的なアイデンティティが決して変化しないので、それを明らかにするのは、観察者がユーザを追跡するのを助けるでしょう。 通常、永久的なアイデンティティはIMSIに基づいています、同じ識別子がまた、他の文脈で使用されるかもしれないので。(さらに、IMSIは追跡を助けるかもしれません)。 アイデンティティプライバシーはセルラー・ネットワークで使用されるTemporaryのモバイルSubscriber Identities(TMSI)から同等な、しかし、別々の一時的なアイデンティティ、または匿名に基づいています。 アイデンティティプライバシーに関するセキュリティ問題に関してセクション12.2を見てください。
4.2.1.3. Username Types in EAP-SIM identities
4.2.1.3. EAP-SIMのアイデンティティにおけるユーザ名Types
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は速い再認証ユーザ名です。 永久的なユーザ名と匿名ユーザ名と異なって、速い再認証ユーザ名は1回の識別子です。(その識別子はEAP交換の向こう側に再使用されません)。
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つのタイプのアイデンティティは単に速い再認証のときに完全な認証と最後のものだけで使用されます。 任意のアイデンティティプライバシーサポートが完全な認証のときに使用されていないとき、非匿名の永久的なアイデンティティは使用されます。 速い再認証交換はセクション5で指定されます。
4.2.1.4. Username Decoration
4.2.1.4. ユーザ名デコレーション
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
いくつかの環境で、同輩は、ひもでユーザ名をprependingするか、または追加することによってアイデンティティに飾り付けをする必要があるかもしれません、NAIに加えた補っているAAAルーティング情報を示すために
Haverinen & Salowey Informational [Page 12] RFC 4186 EAP-SIM Authentication January 2006
[12ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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分野の部分の用法はデコレーションであると考えられません。) このドキュメントの範囲の外にユーザ名デコレーションがあります。 しかしながら、ユーザ名デコレーションが、サーバが有効なユーザ名を認識するのを防ぐかもしれないことに注意されるべきです。 したがって、同輩は同輩がEAP-応答/アイデンティティに含んでいるアイデンティティにユーザ名デコレーションを使用するかもしれません、そして、EAPサーバはこのメッセージで飾り付けをされた同輩ユーザ名を受け入れるかもしれませんが、同輩かEAPサーバが様々なEAP-SIM属性に使用されるいかなる他の同輩のアイデンティティにも飾り付けをしてはいけません。 EAP-応答/アイデンティティに使用されるアイデンティティだけに飾り付けをしてもよいです。
4.2.1.5. NAI Realm Portion
4.2.1.5. NAI分野の部分
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分野はメソッド交渉の間に使用する最初の認証方法に関する役に立つヒントであるかもしれません。 同輩が永久的なユーザ名の代わりに匿名ユーザ名を使用しているとき、永久的なユーザ名を使用するとき、分野の部分を選択するとき、同輩は同様に部分という分野名を選択します。
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部分に由来しているかもしれません。 IMSIから分野3gppnetwork.orgを使用することで分野を得るRECOMMENDED方法は[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.
いくつかの古い実装が、分野名にIMSIに"mnc"、IMSIのMNCケタ、".mcc"、IMSIのMCCケタ、および".owlan.org"を連結することによって、由来しています。 例えば、IMSIが123456789098765であり、長い間MNCが3ケタであるなら、派生している分野名は"mnc456.mcc123.owlan.org"です。 owlan.orgで稼働するDNSサーバが全くなくて、手動で構成されたAAAルーティングでこれらの分野名を使用できるだけです。 新しい実装SHOULDは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
同輩は、IMSIが少しも明白な構造がなければ一連のケタであるので、MNC部分の長さを測定できないかもしれません。 同輩が、長い間、MNCが2ケタかそれとも3ケタであるかどうか決定できないなら、同輩は3ケタのMNCを使用するかもしれません。 MNCの適度の長さが2であるなら、MNCは包含という分野名にMSINの最初のケタを使用しました。 したがって、いつがAAAネットワークを構成するか。
Haverinen & Salowey Informational [Page 13] RFC 4186 EAP-SIM Authentication January 2006
[13ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
operators that have 2-digit MNCs, the network SHOULD also be prepared for realm names with incorrect, 3-digit MNCs.
また不正確で、3ケタのMNCsの分野名のためにそれで2ケタのMNCs、ネットワークSHOULDを準備するオペレータ。
4.2.1.6. Format of the Permanent Username
4.2.1.6. 永久的なユーザ名の形式
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).
非匿名の永久的なユーザ名SHOULD、IMSIから、派生してください。 この場合、永久的なユーザ名は「1インチ」形式のものであるに違いありません。| 「IMSI、どこ、キャラクタ、」|「連結を指示します。」 言い換えれば、ユーザ名の最初のキャラクタはIMSIによって続かれたもの(ASCIIは31 16進を評価する)のケタです。 IMSIは15以上の10進数字でないのから成るASCIIストリングとしてコード化されます(ASCIIは30〜39 16進を評価します)、IMSIケタあたり1つのキャラクタ、[GSM-03.03]で指定されたオーダーで。 例えば、IMSI295023820005424から得られた永久的なユーザ名はASCIIストリング「1295023820005424」(16進法におけるバイト値: 31 32 39 35 30 32 33 38 32 30 30 30 35 34 32 34)としてコード化されるでしょう。
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-シムを裁くヒントとしての1インチ、例えば、EAP/別名、」 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に基づいていない永久的なユーザ名を選ぶかもしれません。 この場合、このドキュメントの範囲の外にユーザ名、形式、およびその処理の選択があります。 この場合、同輩実装はユーザ名への少しの主人公もprependしてはいけません。
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サーバは実装依存する方法で匿名ユーザ名と速い再認証のアイデンティティを作り出します。 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サーバが別のサーバ缶の要求を出した、同輩は永久的なアイデンティティを送ります。
Haverinen & Salowey Informational [Page 14] RFC 4186 EAP-SIM Authentication January 2006
[14ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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.
速い再認証のアイデンティティを発行するとき、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.
再認証がアイデンティティであると速く生成するとき、サーバSHOULDは同じ完全な認証交換の後に使用された前のものと異なった新鮮で、新しい速い再認証のアイデンティティを選びます。 完全な認証交換と関連速い再認証交換は同じ「完全な認証関係」としてここと呼ばれます。 速い再認証のアイデンティティSHOULDは無作為のコンポーネントを含んでいます。 この無作為のコンポーネントは完全な認証文脈識別子として働いています。 速い再認証州の情報が同輩のものに合っている(言い換えれば、州の情報が同じ完全な認証交換から来ているか否かに関係なく)か否かに関係なく、アイデンティティが、サーバが検出するのを助けることができる文脈特有の速い再認証。 また、無作為のコンポーネントで速い再認証のアイデンティティが予測できるようにならないので、攻撃者はサーバのEAP-Request/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
一般に、それは、EAPサーバに関するタスクとユーザ名の十分な分離を確実にする管理者の方針です。 匿名ユーザ名と速い再認証ユーザ名は、EAPサーバによって作り出されて、使用されます。またはEAPサーバがNAIユーザ名がEAP-SIM匿名ユーザ名であるかどうか決定できるように匿名ユーザ名と速い再認証ユーザ名を構成しなければならない。
Haverinen & Salowey Informational [Page 15] RFC 4186 EAP-SIM Authentication January 2006
[15ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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-SIMの速い再認証ユーザ名。 例えば、IMSIからユーザ名を得たときサーバが匿名ユーザ名と速い再認証ユーザ名で異なった主人公を使用するかもしれない、(例えば匿名が先導で始まることができた、「3インチのキャラクタ)」 永久的なアイデンティティへの速い再認証のアイデンティティを写像するとき、サーバSHOULDは速い再認証のアイデンティティのユーザ名部分を調べるだけであり、アイデンティティの分野の部分を無視します。
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/挑戦で送られた匿名ユーザ名を保存しないで、例えば、誤動作するかもしれないので、SHOULDが少なくとも最も最近維持するEAPサーバは最も最近発行された匿名ユーザ名に加えた匿名ユーザ名を使用しました。 認証交換が首尾よく終了されていないなら、サーバSHOULD NOTは最新のうまくいっている認証交換の間に発行された匿名ユーザ名を上書きします。
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
同輩がEAP-要求/SIM/挑戦メッセージの新しい匿名ユーザ名を受け取らないなら、同輩は次の完全な認証に関する永久的なユーザ名の代わりに古い匿名ユーザ名を使用するかもしれません。 速い再認証のユーザ名部分
Haverinen & Salowey Informational [Page 16] RFC 4186 EAP-SIM Authentication January 2006
[16ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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.
アイデンティティは1回のユーザ名です。(同輩はそのユーザ名を再使用してはいけません)。 同輩がEAP交換に速い再認証のアイデンティティを使用すると、同輩は、速い再認証のアイデンティティを捨てて、別のEAP認証交換にそれを再使用してはいけません、認証交換が終了されなかったとしても。
4.2.1.9. Usage of the Pseudonym by the Peer
4.2.1.9. 同輩による匿名の用法
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_ネクストPSEUDONYMに受け取られた匿名ユーザ名を変更してはいけません。 しかしながら、上で議論するように、同輩は、補っているAAAルーティング情報を示すひもでユーザ名を追加するか、またはprependingすることによっていくつかの環境におけるユーザ名に飾り付けをする必要があるかもしれません。
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分野の選択について議論します。 永久的なユーザ名か匿名ユーザ名を使用するかどうかにかかわらず同輩は同様に分野の部分を選択できます。
4.2.1.10. Usage of the Fast Re-authentication Identity by the Peer
4.2.1.10. 同輩による速い再認証のアイデンティティの用法
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で受け取られた速い再認証のアイデンティティのユーザ名部分を変更してはいけません、ユーザ名デコレーションが必要であるときにケースを除いて。 これらの場合ではさえ、「根」速い再認証ユーザ名を変更してはいけませんが、別のひもでそれを追加するか、またはprependedするかもしれません。
4.2.2. Communicating the Peer Identity to the Server
4.2.2. サーバへの同輩のアイデンティティを伝えます。
4.2.2.1. General
4.2.2.1. 一般
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
同輩のアイデンティティはサーバにEAP-応答/アイデンティティメッセージと伝えられるかもしれません。 このメッセージは永久的なアイデンティティ、匿名のアイデンティティ、または速い再認証のアイデンティティを含むかもしれません。 同輩が永久的なアイデンティティか匿名のアイデンティティ(サーバは永久的なアイデンティティに写像できる)を使用するなら、認証はセクション3の概要で議論するように続きます。 同輩が速い再認証のアイデンティティを使用して、aが有効な状態で速い再認証のアイデンティティが合っているなら断食してくださいなら
Haverinen & Salowey Informational [Page 17] RFC 4186 EAP-SIM Authentication January 2006
[17ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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.
サーバとサーバが、速い再認証を使用するのに同意するかどうかによって維持された再認証のアイデンティティ、次に、速い再認証交換は実行されます、セクション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/開始メッセージにアイデンティティを要求する属性(__どんな_ID REQ、AT_FULLAUTH_AT_ID REQか_AT_PERMANENT_ID REQも)を含んでいます、そして、同輩はAT_IDENTITY属性を入れます、EAP-応答/SIM/開始メッセージで。(属性は同輩のアイデンティティを含みます)。 どんな_ID_REQも結果と考えるAT_は一般的なアイデンティティを要求する属性です。(同輩が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要素(可能なAAAプロキシサーバなどの)は、オリジナルのアイデンティティでEAP-応答/アイデンティティパケットから同輩について言及し続けるでしょう。
4.2.2.2. Relying on EAP-Response/Identity Discouraged
4.2.2.2. がっかりするEAP-応答/アイデンティティを当てにします。
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 Frameworkによって扱われるかもしれません。 これはEAP同輩とEAPサーバに追加層の処理を取り入れます。付加的な層の処理は、アイデンティティ応答をキャッシュするか、またはアイデンティティにデコレーションを加えるかもしれません。 EAP同輩とEAPサーバはアイデンティティ応答の変更で主要な派生に異なったアイデンティティを使用するでしょう。(それは、プロトコルに失敗されるでしょう)。
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でメソッド特有のアイデンティティ属性を使用するのが、RECOMMENDEDであり、サーバはEAP-応答/アイデンティティを当てにして、強くがっかりしています。
Haverinen & Salowey Informational [Page 18] RFC 4186 EAP-SIM Authentication January 2006
[18ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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でアイデンティティの変更されていなくて非飾り付けをされたコピーを送るよう要求するのにアイデンティティを要求する属性を使用しなければなりません。
4.2.3. Choice of Identity for the EAP-Response/Identity
4.2.3. EAP-応答/アイデンティティのためのアイデンティティの選択
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-要求/アイデンティティメッセージを受け取るのに始められるなら、同輩は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-応答/アイデンティティにおける永久的なアイデンティティを伝えます。
4.2.4. Server Operation in the Beginning of EAP-SIM Exchange
4.2.4. 初めにEAP-SIM交換のサーバ操作
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、サーバSHOULD NOTはEAP-応答/アイデンティティで受け取られたアイデンティティストリングを当てにします。 したがって、EAP-SIM交換を始めるRECOMMENDED方法はどんな容認されたアイデンティティストリングも無視することです。 サーバSHOULDは、サーバが、同輩が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-SIM要求を送るとき、EAPサーバがEAP-応答/アイデンティティパケットを受けましたが、内容が有効な永久的なアイデンティティ、匿名のアイデンティティまたは再認証のアイデンティティであるように見えないならEAPサーバが同輩からEAP-SIM同輩のアイデンティティ(永久的なアイデンティティ、匿名のアイデンティティ、または速い再認証のアイデンティティ)をまだ、受けていないなら、以下のメソッドの1つを使用して、サーバは同輩からアイデンティティを要求しなければなりません。
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
サーバは、サーバが、同輩がAT_IDENTITY属性で永久的なアイデンティティを入れる必要であるのを示すためにAT_PERMANENT_ID_REQ属性があるEAP-要求/SIM/開始メッセージを送ります。
Haverinen & Salowey Informational [Page 19] RFC 4186 EAP-SIM Authentication January 2006
[19ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
of the EAP-Response/SIM/Start message. This is done in the following cases:
EAP-応答/SIM/開始メッセージについて。 以下の場合でこれをします:
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 サーバは、容認されたアイデンティティを処理すると決めました、そして、サーバは、容認されたアイデンティティが匿名のアイデンティティであると認めますが、サーバは永久的なアイデンティティへの匿名のアイデンティティを写像できません。
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 サーバは、容認されたアイデンティティを処理すると決めました、そして、サーバは、容認されたアイデンティティが再認証のアイデンティティであると認めますが、サーバは永久的なアイデンティティへの再認証のアイデンティティを写像できません。
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/開始メッセージのAT_IDENTITY属性でアイデンティティを入れる必要であるのを示すためにATがあるEAP-要求/SIM/スタートパケットに_どんな_ID_REQ属性も発行します、そして、サーバはアイデンティティのための少しの都合のよいタイプも示しません。 他の場合でこれをします、サーバが容認されたEAP-応答/アイデンティティを無視するか、サーバには少しのアイデンティティもないか、またはサーバが容認されたアイデンティティの形式を認識しない時のように。
4.2.5. Processing of EAP-Request/SIM/Start by the Peer
4.2.5. 同輩によるEAP-要求/SIM/始めの処理
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/始めがアイデンティティ要求属性を含んでいないなら、同輩はEAP-応答/SIM/始めでAT_IDENTITYなしで応じます。 交換が完全な認証交換であるので、同輩は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/始めで応じて、永久的なアイデンティティを含まなければならないその時
Haverinen & Salowey Informational [Page 20] RFC 4186 EAP-SIM Authentication January 2006
[20ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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".
_アイデンティティで。 同輩に利用可能な匿名があるなら、同輩は、永久的なアイデンティティを送るのを拒否するかもしれません。 したがって、同輩は、この場合、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を含んで、同輩に利用可能な匿名があるなら、同輩SHOULDはEAP-応答/SIM/始めで応じて、AT_IDENTITYに匿名のアイデンティティを含んでいます。 このメッセージを受け取るとき同輩に匿名がないなら、同輩は、EAP-応答/SIM/始めで応じて、AT_IDENTITYで永久的なアイデンティティを入れなければなりません。 Peerは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属性に使用したアイデンティティを認識できなかったなら、サーバは第2EAP-要求/SIM/始めを発行するかもしれません。 高々、3EAP/SIM/スタートラウンドを使用できるので、同輩はEAP交換の中で3以上EAP-要求/SIM/開始メッセージに応じてはいけません。 同輩は、同輩が受けるEAP-要求/SIM/スタートパケットの系列が本書では定義される配列規則に応じることを確かめなければなりません。 最初のEAP-要求/SIM/始めでどんなすなわち、AT__ID_REQも使用できるだけです。 _どんな言い換えれば、AT__ID REQ MUST NOT、も2番目か第3EAP-要求/SIM/始めで使用されてください。 _AT_FULLAUTH_ID REQ MUST NOT、前のEAP-要求/SIM/始めが_AT_PERMANENT_ID REQを含んでいたなら、使用されてください。 予期していなかった属性か予期していなかったメッセージを受け取るときの場合では、同輩操作はセクション6.3.1で指定されます。
4.2.6. Attacks Against Identity Privacy
4.2.6. アイデンティティプライバシーに対する攻撃
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-Request/SIM/スタートパケットを同輩に伝えるかもしれないからです。 同輩が永久的なアイデンティティを明らかにしたくないなら、同輩は発信します。
Haverinen & Salowey Informational [Page 21] RFC 4186 EAP-SIM Authentication January 2006
[21ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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-応答/SIM/誤りでEAPパケットに応じます、同輩が、有効なネットワークが同輩の永久的なアイデンティティへの匿名のアイデンティティを写像できると信じているので。 (あるいはまた、保守的な同輩はある特定の状況では、例えば_AT_PERMANENT_ID REQを受け入れるかもしれません、昔に匿名を受け取ったなら。) この方針の利益は匿名に対する活発な攻撃に対して同輩を保護するということです。 他方では、「寛容な」同輩は、いつも_AT_PERMANENT_ID REQを受け入れて、永久的なアイデンティティで応じます。 この方針の利益は、有効なネットワークが時々匿名を失っても働いているということであり、永久的なアイデンティティにそれらを写像できません。
4.2.7. Processing of AT_IDENTITY by the Server
4.2.7. _アイデンティティでは、サーバで、処理します。
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.
サーバがAT_IDENTITY(属性を要求するサーバのアイデンティティに対応した)と共にEAP-応答/SIM/開始メッセージを受け取るとき、サーバは以下の通り作動しなければなりません。
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_IDENTITYが有効な永久的なアイデンティティを含んでいないならサーバが_AT_PERMANENT_ID REQを使用したなら、サーバは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/挑戦で完全な認証を続けます。
Haverinen & Salowey Informational [Page 22] RFC 4186 EAP-SIM Authentication January 2006
[22ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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/始めを送りましたが(再認証を示して)、サーバが永久的なアイデンティティへのアイデンティティを写像できないなら、サーバは_AT_FULLAUTH_ID REQとのEAP-要求/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-要求/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/始めを送ります。
4.3. Message Sequence Examples (Informative)
4.3. メッセージ系列の例(有益)です。
This section contains non-normative message sequence examples to illustrate how the peer identity can be communicated to the server.
このセクションはどう同輩のアイデンティティをサーバに伝えることができるかを例証する非標準のメッセージ系列の例を含みます。
Haverinen & Salowey Informational [Page 23] RFC 4186 EAP-SIM Authentication January 2006
[23ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
4.3.1. Full Authentication
4.3.1. 完全な認証
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) |
|------------------------------------------------------>|
| |
同輩固有識別文字| | | +------------------------------+ | | サーバには、aがありません。| | | 利用可能な加入者のアイデンティティ| | | EAP-SIMを始めます。| | +------------------------------+ | | | EAP-要求/SIM/始め| | (___どんな_ID REQ、バージョン_リストの) | |<------------------------------------------------------| | | | | | EAP-応答/SIM/始め| | (__アイデンティティ、一回だけ_MTで|、|、_の選択された_バージョン) | |------------------------------------------------------>| | |
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.
同輩が完全な認証のアイデンティティを使用して、AT_IDENTITY属性がEAPサーバが永久的なアイデンティティに写像できる有効な永久的なアイデンティティか有効な匿名のアイデンティティを含んでいるなら、完全な認証系列はいつものようにEAP-要求/SIM/挑戦メッセージを発行するEAP Serverを続けます。
Haverinen & Salowey Informational [Page 24] RFC 4186 EAP-SIM Authentication January 2006
[24ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
4.3.2. Fast Re-authentication
4.3.2. 速い再認証
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) |
|------------------------------------------------------>|
| |
同輩固有識別文字| | | +------------------------------+ | | サーバには、aがありません。| | | 利用可能な加入者のアイデンティティ| | | EAP-SIMを始めます。| | +------------------------------+ | | | EAP-要求/SIM/始め| | (___どんな_ID REQ、バージョン_リストの) | |<------------------------------------------------------| | | | | | EAP-応答/SIM/始め| | (a速い再authアイデンティティを含むAT_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-Request/SIM/再認証パケットを続かせます、セクション5で指定されるように。
Haverinen & Salowey Informational [Page 25] RFC 4186 EAP-SIM Authentication January 2006
[25ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
4.3.3. Fall Back to Full Authentication
4.3.3. 完全な認証へ後ろへ下がってください。
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で使用した速い再認証のアイデンティティを認識しない場合を例証して、第2EAP-要求/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) |
|------------------------------------------------------>|
| |
同輩固有識別文字| | | +------------------------------+ | | サーバには、aがありません。| | | 利用可能な加入者のアイデンティティ| | | EAP-SIMを始めます。| | +------------------------------+ | | | EAP-要求/SIM/始め| | (___どんな_ID REQ、バージョン_リストの) | |<------------------------------------------------------| | | | | | EAP-応答/SIM/始め| | (a速い再authアイデンティティを含むAT_IDENTITY) | |------------------------------------------------------>| | | | +------------------------------+ | | サーバは認識しません。| | | 速い再auth。 | | | アイデンティティ| | +------------------------------+ | | | EAP-要求/SIM/始め| | (___FULLAUTH_ID REQ、バージョン_リストの) | |<------------------------------------------------------| | | | | | EAP-応答/SIM/始め| | (aがあるAT_IDENTITYは-authに. アイデンティティ、AT_NONCE_MTを洗い張りします| | AT_SELECTED_バージョン) | |------------------------------------------------------>| | |
Figure 4: Fall back to full authentication
図4: 完全な認証へ後ろへ下がってください。
Haverinen & Salowey Informational [Page 26] RFC 4186 EAP-SIM Authentication January 2006
[26ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
4.3.4. Requesting the Permanent Identity 1
4.3.4. 永久的なアイデンティティ1を要求します。
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) |
|------------------------------------------------------>|
| |
同輩固有識別文字| | | EAP-要求/アイデンティティ| |<------------------------------------------------------| | | | EAP-応答/アイデンティティ| | (匿名を含んでいます) | |------------------------------------------------------>| | | | +------------------------------+ | | サーバは写像しません。| | | 永久的なイドへの匿名。 | | +------------------------------+ | EAP-要求/SIM/始め| | (___永久的な_ID REQ、バージョン_リストの) | |<------------------------------------------------------| | | | EAP-応答/SIM/始め| | (| | 永久的なアイデンティティがあるAT_IDENTITY、AT_NONCE_MT、AT_SELECTED_バージョン) | |------------------------------------------------------>| | |
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-要求/SIM/挑戦メッセージを発行するEAP Serverを続けます。
Haverinen & Salowey Informational [Page 27] RFC 4186 EAP-SIM Authentication January 2006
[27ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
4.3.5. Requesting the Permanent Identity 2
4.3.5. 永久的なアイデンティティ2を要求します。
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) |
|------------------------------------------------------>|
| |
同輩固有識別文字| | | +------------------------------+ | | サーバには、aがありません。| | | 利用可能な加入者のアイデンティティ| | | EAP-SIMを始めます。| | +------------------------------+ | EAP-要求/SIM/始め| | (___どんな_ID REQ、バージョン_リストの) | |<------------------------------------------------------| | | |EAP-応答/SIM/始め| |(| | 匿名のアイデンティティがあるAT_IDENTITY、AT_NONCE_MT、AT_SELECTED_バージョン) | |------------------------------------------------------>| | +-------------------------------+ | | サーバは写像しません。| | | 中の_アイデンティティにおける匿名| | | 有効な永久的なアイデンティティに| | +-------------------------------+ | | | EAP-要求/SIM/始め| | (___永久的な_ID REQ、バージョン_リストの) | |<------------------------------------------------------| | | | EAP-応答/SIM/始め| | (永久的なアイデンティティがあるAT_IDENTITY、| | AT_NONCE_MT、AT_SELECTED_バージョン) | |------------------------------------------------------>| | |
Figure 6: Requesting a permanent identity (two EAP-SIM Start rounds)
図6: 永久的なアイデンティティを要求します。(2EAP-SIM Startラウンド)
4.3.6. Three EAP-SIM/Start Roundtrips
4.3.6. 3EAP-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.
最悪の場合には、サーバが許容できるアイデンティティを得る前に旅行の周りに3EAP/SIM/始めがあります。 本件は図7で例証されます。
Haverinen & Salowey Informational [Page 28] RFC 4186 EAP-SIM Authentication January 2006
[28ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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
同輩固有識別文字| | | +------------------------------+ | | サーバには、aがありません。| | | 利用可能な加入者のアイデンティティ| | | EAP-SIMを始めます。| | +------------------------------+ | EAP-要求/SIM/始め| | (_どんな_にも、_バージョン_リストにID_REQを含んでいます) | |<------------------------------------------------------| | | | EAP-応答/SIM/始め| | (速い再authアイデンティティがあるAT_IDENTITY) | |------------------------------------------------------>| | | | +------------------------------+ | | サーバは受け入れません。| | | 速い再auth。 | | | アイデンティティ| | +------------------------------+ | EAP-要求/SIM/始め| | (___FULLAUTH_ID REQ、バージョン_リストの) | |<------------------------------------------------------| | | : : : : : : : : |EAP-応答/SIM/始め| |(| | 匿名のアイデンティティがあるAT_IDENTITY、AT_NONCE_MT、AT_SELECTED_バージョン) | |------------------------------------------------------>| | | | +-------------------------------+ | | サーバは写像しません。| | | 中の_アイデンティティにおける匿名| | | 有効な永久的なアイデンティティに| | +-------------------------------+ | EAP-要求/SIM/始め| | (___永久的な_ID REQ、バージョン_リストの) | |<------------------------------------------------------| | | | EAP-応答/SIM/始め| | (| | 永久的なアイデンティティがあるAT_IDENTITY、AT_NONCE_MT、AT_SELECTED_バージョン) | |------------------------------------------------------>| | | 図7: 3EAP-SIM Startラウンド
Haverinen & Salowey Informational [Page 29] RFC 4186 EAP-SIM Authentication January 2006
[29ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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 Serverが永久的なアイデンティティを認識して、続くことができるなら、サーバはEAP-要求/SIM/挑戦メッセージを発行します。
5. Fast Re-Authentication
5. 速い再認証
5.1. General
5.1. 一般
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アルゴリズムを利用して、したがって、Authentication Centreから2か3人の新鮮な三つ子を必要とするので、完全な認証手順はそれほど頻繁な使用によく合っていません。 したがって、EAP-SIMはSIM A3/A8アルゴリズムを利用しないで、またAuthentication Centreから新しい三つ子を必要としないより安価な速い再認証手順を含んでいます。 完全な認証より少ない往復旅行で再認証を実行できます。
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パケットと属性を保護するのに使用されます、そして、完全な認証からのオリジナルのMaster Keyは新鮮なMaster Session Keyを生成するのに使用されます、セクション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番目の速い再認証のときに、対価は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サーバによって送られたより値以下であることを確かめなければなりません。
Haverinen & Salowey Informational [Page 30] RFC 4186 EAP-SIM Authentication January 2006
[30ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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は新しいMaster Session Keyに貢献します。
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.
同輩とサーバSHOULDの両方で、完全な認証が、実行される必要がある前にその後の速い再認証の数のための上限を許容しています。 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サーバは、以下の値を保存する必要があります: Key、最新の対価、および次の速い再認証にアイデンティティをマスタリングしてください。 K_aut、K_encrを保存するか、または再びMKから得るかもしれません。 また、サーバは、ユーザの永久的なアイデンティティを保存する必要があるかもしれません。
5.2. Comparison to UMTS AKA
5.2. UMTS別名との比較
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 AuthenticationとKey Agreement(AKA)交換とそれを比べるのは役立っているかもしれません。(それは密接に交換に類似しています)。 カウンタはUMTS AKA一連番号に対応している、NONCE_SはRANDに対応している、再EAP-要求/SIM/認証におけるAT_MACはAUTNに対応している、再EAP-応答/SIM/認証におけるAT_MACはRESに対応しています、AT_COUNTERも。_SMALLはAUTSに対応しています、そして、カウンタを暗号化するのはAnonymity Keyの使用法に対応しています。 また、無作為の、または、新鮮な材料に関して、速い再認証におけるキー生成も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も_SMALLが結果と考える暗号化するのが速い再認証交換のセキュリティに重要でないことに注意されるべきです。
5.3. Fast Re-authentication Identity
5.3. 速い再認証のアイデンティティ
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.
速い再認証手順は別々の再認証ユーザアイデンティティを利用します。 匿名と永久的なアイデンティティは完全な認証だけのために予約されます。 再認証のアイデンティティが無くなって、ネットワークがそれを認識しないなら、EAPサーバは完全な認証のときに後ろへ下がることができます。
Haverinen & Salowey Informational [Page 31] RFC 4186 EAP-SIM Authentication January 2006
[31ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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)の暗号化されたデータにskippable AT_ネクスト_REAUTH_ID属性を含むかもしれません。 この属性は次の速い再認証のための新しい速い再認証のアイデンティティを含んでいます。 また、能力がそれに旗を揚げさせるとき、属性は働いています、サーバが速い再認証をサポートして、サーバが、現在の背景の中で速い再認証を使用し続けたがっているのを示して。 同輩はこの属性を無視するかもしれません、その場合、それが次回、完全な認証を使用しなければなりません。 同輩が再認証を使用したいと思うなら、それは次の認証のときにこの速い再認証のアイデンティティを使用します。 同輩に速い再認証のアイデンティティがあっても、同輩は、速い再認証のアイデンティティを捨てて、代わりに匿名か永久的なアイデンティティを使用するかもしれません、その場合、完全な認証を実行しなければなりません。 EAPサーバがEAP-要求/SIM/挑戦かEAP-Request/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形式に従って。 AAAインフラストラクチャにその後の速い再認証関連する要求を同じAAAサーバに発送させるように、EAP Serverは適切な分野の部分を選ぶことができます。例えば、分野の部分は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-応答/アイデンティティパケットで速い再認証のアイデンティティを使用するかもしれませんか、またはどんな_ID_REQも結果と考えるサーバのAT_に対応して同輩は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.
同輩が速い再認証のアイデンティティのユーザ名部分を変更してはいけませんが、同輩は、分野の部分を変更するか、またはそれをもう1つの分野の部分に取り替えるかもしれません。 同輩は、例えば、正しいサーバに達しているのを確実にするためにAAAルーティングに影響を及ぼすように分野を変更する必要があるかもしれません。 EAPサーバを変えるためにNAIの分野の部分を変えるのが望ましくなくて、いくつかのサーバの中で主要な同じ速い再認証を共有するのにおいてセキュリティリスクがあるかもしれないことに注意されるべきです。
Haverinen & Salowey Informational [Page 32] RFC 4186 EAP-SIM Authentication January 2006
[32ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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/スタートパケットを発行することによって、完全な認証手順を始めます。 それがどんな_ID_REQも結果と考えるAT_を含まないなら、このパケットはいつも完全な認証系列を始めます。 サーバが速い再認証のアイデンティティから同輩のアイデンティティを取り戻すことができなかったなら、サーバは_REQがこのEAP要求で結果と考えるAT_FULLAUTH_IDのREQかAT_PERMANENT_ID_を含んでいます。
5.4. Fast Re-authentication Procedure
5.4. 速い再認証手順
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.
エイト環は速い再認証手順を例証します。 この例では、任意の保護された成功指示は使用されていません。 暗号化された属性は'*'で指示されます。 同輩はEAP-応答/アイデンティティパケットで再認証のアイデンティティを使用します。 上で議論するように、サーバへの再認証のアイデンティティを伝える代替の方法は同輩がEAP-応答/SIM/開始メッセージでAT_IDENTITY属性を使用することです。 この後者のケースは以下の図で例証されません、そして、サーバが、同輩がEAP-要求/SIM/スタートパケットで_どんな_ID_REQ属性もATを含んでいるのによるアイデンティティに送るよう要求するときだけ、それは可能です。
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-Request/SIM/再認証パケットを同輩に送ります。 このパケットは暗号化されたAT_COUNTER属性を含まなければなりません、新鮮な対価、サーバによって選ばれた乱数を含む暗号化されたAT_NONCE_S属性、ENCR_DATAとAT_IV属性が暗号化に使用したAT_、およびパケットの上にメッセージ確認コードを含むAT_MAC属性で。 また、パケットは次の速い再認証のアイデンティティを含む暗号化された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.
速い再認証のアイデンティティは1回のアイデンティティです。 同輩が新しい速い再認証のアイデンティティを受けないなら、それは、次の認証のときに完全な認証を開始するのに永久的なアイデンティティか匿名のアイデンティティのどちらかを使用しなければなりません。
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,
同輩はAT_MACが正しく、対価が新鮮であることを(いずれも以前に値を使用したよりすばらしい)確かめます。 同輩は、次回の暗号化されたAT_ネクスト_REAUTH_IDから次の速い再認証がアイデンティティであると保存するかもしれません。 すべてのチェックがうまくいくなら、同輩は再EAP-応答/SIM/認証パケットで応じます。
Haverinen & Salowey Informational [Page 33] RFC 4186 EAP-SIM Authentication January 2006
[33ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
including the AT_COUNTER attribute with the same counter value and AT_MAC attribute.
同じ対価とMACが結果と考えるAT_があるAT_COUNTER属性を含んでいます。
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-Request/SIM/再認証パケットで使用した同じくらいであることを確かめます。 これらのチェックがうまくいくなら、再認証は成功しました、そして、サーバはEAP-成功パケットを同輩に送ります。
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-SIM通知でEAP-成功パケットはぐるりと先行されているでしょうに。
Haverinen & Salowey Informational [Page 34] RFC 4186 EAP-SIM Authentication January 2006
[34ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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 |
|<------------------------------------------------------|
| |
同輩固有識別文字| | | EAP-要求/アイデンティティ| |<------------------------------------------------------| | | | EAP-応答/アイデンティティ| | (速い再認証のアイデンティティを含んでいます) | |------------------------------------------------------>| | | | +--------------------------------+ | | サーバはアイデンティティを認識します。| | | 断食を使用するのに同意します。| | | 再認証| | +--------------------------------+ | | : : : : : : : : | 再EAP-要求/SIM/認証| | (_カウンタの*、| | _一回だけ_Sの*、__次の_REAUTH_ID、Macの__IV、ENCR_データにおいて*) | |<------------------------------------------------------| | | +-----------------------------------------------+ | | 同輩はAT_MACと新しさについて確かめます。| | | カウンタ。 同輩が速く新しさを保存するかもしれない、再| | | 次の再authのための認証のアイデンティティ。 | | +-----------------------------------------------+ | | | | 再EAP-応答/SIM/認証| | (| | AT_IV、AT_ENCR_DATA、同じ値がある*AT_COUNTER、AT_MAC) | |------------------------------------------------------>| | +--------------------------------+ | | そしてサーバがAT_MACについて確かめる。| | | カウンタ| | +--------------------------------+ | | | EAP-成功| |<------------------------------------------------------| | |
Figure 8: Fast Re-authentication
エイト環: 速い再認証
Haverinen & Salowey Informational [Page 35] RFC 4186 EAP-SIM Authentication January 2006
[35ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
5.5. Fast Re-authentication Procedure when Counter Is Too Small
5.5. Counter Is Too Smallであることの速いRe-認証Procedure
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-Request/SIM/再認証の対価を受け入れないなら、それは、暗号化されたAT_COUNTERも含んでいることによって、カウンタ同期問題を示します。_EAP-Response/SIM/再認証における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. |
+---------------------------------------------------------------+
| |
同輩固有識別文字| EAP-要求/SIM/始め| | (___どんな_ID REQ、バージョン_リストの) | |<------------------------------------------------------| | | | EAP-応答/SIM/始め| | (_アイデンティティにおける) | | (速い再認証のアイデンティティを含んでいます) | |------------------------------------------------------>| | | | 再EAP-要求/SIM/認証| | (_カウンタの*、| | _一回だけ_Sの*、__次の_REAUTH_ID、Macの__IV、ENCR_データにおいて*) | |<------------------------------------------------------| +-----------------------------------------------+ | | AT_MACは有効ですが、カウンタは新鮮ではありません。 | | +-----------------------------------------------+ | | | | 再EAP-応答/SIM/認証| | (| | __カウンタ、Macの_の*が_ENCR_データで__あまりに小さく打ち返す_IVの*) | |------------------------------------------------------>| | +----------------------------------------------+ | | サーバ、しかし、AT_MACが確かめる、検出| | | その同輩がAT_COUNTERも入れた、_SMALL| | +----------------------------------------------+ | | | EAP-要求/SIM/始め| | (_バージョン_リストの) | |<------------------------------------------------------| +---------------------------------------------------------------+ | 通常の完全な認証は続きます。 | +---------------------------------------------------------------+ | |
Figure 9: Fast Re-authentication, counter is not fresh
図9: 速いRe-認証、カウンタは新鮮ではありません。
Haverinen & Salowey Informational [Page 36] RFC 4186 EAP-SIM Authentication January 2006
[36ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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つのメッセージが基本的な速い再認証ケースと同様です。 同輩がそれを検出するとき、対価が新鮮でない、それはAT_COUNTERも含んでいます。_再EAP-応答/SIM/認証における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.
_SMALL、サーバは、AT_COUNTERもを受け取り次第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を見てください)。
6. EAP-SIM Notifications
6. EAP-SIM通知
6.1. General
6.1. 一般
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.
EAP-SIMは[RFC3748]の指定されるとしてのEAP Notificationsの使用を禁止しません。 いつでも、EAP-SIM交換にEAP Notificationsを使用できます。 EAP-SIMがEAP Notificationsを保護しないことに注意されるべきです。 また、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サーバに応じなければなりません、同輩が通知コードを認めなかったとしても。
Haverinen & Salowey Informational [Page 37] RFC 4186 EAP-SIM Authentication January 2006
[37ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
An EAP-SIM full authentication exchange or a fast re-authentication exchange MUST NOT include more than one EAP-SIM notification round.
EAP-SIMの完全な認証交換か速い再認証交換がぐるりと1つ以上の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ビットの数です。 最も重要なビットはSuccessビットと呼ばれます(Sに噛み付きました)。 Sビットは、通知が失敗を含意するかどうか指定します。 ゼロ(コードは0...32767を評価する)に設定されたSビットがあるコード値は失敗のケースの上で使用されます。 この範囲からの通知コードの領収書が失敗したEAP交換を含意するので、同輩は失敗指示として通知を使用できます。 これらの通知コードのためのEAP-応答/SIM/通知を受け取った後に、サーバはEAP-失敗パケットを送らなければなりません。
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.
1つ(32768...65536を評価する)に設定されたSビットがある通知コードの領収書は失敗を含意しません。 通知コード「成功」(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番目の最上位ビットはPhaseビットと呼ばれます(Pに噛み付きました)。 それは、EAP-SIM交換のどのフェーズに通知を使用できるかを指定します。 Pビットがゼロに設定されるなら、完全な認証で丸いうまくいっているEAP/SIM/挑戦か再認証で丸いうまくいっている再EAP/SIM/認証の後に通知を使用できるだけです。 同輩が首尾よくAT_MACとAT_COUNTER属性について確かめて、_また、AT_COUNTERを入れない場合にだけ、再認証ラウンドはうまくいくと考えられます。_再EAP-応答/SIM/認証における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通知を決して送らないと決めるかもしれません。
Haverinen & Salowey Informational [Page 38] RFC 4186 EAP-SIM Authentication January 2006
[38ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
6.2. Result Indications
6.2. 結果指摘
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/挑戦パケットか再EAP-応答/SIM/認証パケットを送る、(AT_COUNTER、も_SMALL)、同輩は、首尾よくサーバを認証して、同輩のローカルの方針が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)との成功指摘を使用できます。 同輩が対応する応答パケットでAT_RESULT_INDを入れなかったならサーバが再EAP-要求/SIM/挑戦かEAP-要求/SIM/認証パケットに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-成功を送らなければなりません。
Haverinen & Salowey Informational [Page 39] RFC 4186 EAP-SIM Authentication January 2006
[39ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
6.3. Error Cases
6.3. 誤り事件
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同輩とサーバを必要とします。 しかしながら、実装SHOULD NOTは同輩、固有識別文字、またはサーバの働きを報告する正しい誤りを当てにします。誤りと他のトランジットで失われるべきメッセージか悪意がある関係者にとって、エラーメッセージを発行しないことによってリソースを消費するのを試みるのは可能です。 同輩とEAPサーバSHOULDの両方には、状態に掃除するメカニズムがあります、エラーメッセージかEAP-成功がタイムアウト時間の後に受け取られないでも。
6.3.1. Peer Operation
6.3.1. 同輩操作
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-失敗パケットと交換が終える認証を発行しなければなりません。
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 認識されていなくて、非skippableな属性。
o unrecognized or unexpected EAP-SIM Subtype in the EAP request.
o EAP要求における認識されていないか予期していなかったEAP-SIM Subtype。
o A RAND challenge repeated in AT_RAND.
o RAND挑戦はAT_RANDで繰り返されました。
o invalid AT_MAC. The peer SHOULD log this event.
o 無効のAT_MAC。 同輩SHOULDはこのイベントを登録します。
o invalid pad bytes in AT_PADDING.
o AT_PADDINGの無効のパッドバイト。
Haverinen & Salowey Informational [Page 40] RFC 4186 EAP-SIM Authentication January 2006
[40ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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".
AT_バージョン_LIST属性(サーバによってサポートされたEAP-SIMバージョンを記載する)を処理するとき、セクション4.1で指定されるように、属性が同輩によって実装されて、同輩の安全保障政策で許容されているバージョンを含んでいないなら、同輩はエラーコード「サポートされないバージョン」があるクライアント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".
同輩が、AT_RANDに含まれていたRAND挑戦が新鮮でないと信じているなら、例えば、それが、或るものが以前にRANDsを使用したのを覚えていることができるので、同輩はエラーコードがあるクライアントEAP-応答/SIM/誤りパケットに「RANDsは新鮮でないこと」を送らなければなりません。
6.3.2. Server Operation
6.3.2. サーバ操作
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/通知パケットを発行しなければなりません。 デフォルトで、サーバは一般的な失敗コードの1つを使用します。(「認証の後の一般失敗」(0)、または「一般失敗」(16384))。 セクション6は、これらの2つのコードのこの選択がEAP-SIM交換のフェーズ次第であることを見ます。 サーバが失敗を含意するEAP要求/SIM/通知を発行するとき、誤り事件は以下を含んでいます:
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 サーバは奇形の属性、非認識された非skippable属性、または写し属性に遭遇します。
o a mandatory attribute is missing or an invalid attribute was
included
o 義務的な属性がなくなるか、または無効の属性は含まれていました。
o unrecognized or unexpected EAP-SIM Subtype in the EAP Response
o EAP Responseの認識されていないか予期していなかったEAP-SIM Subtype
o invalid AT_MAC. The server SHOULD log this event.
o 無効のAT_MAC。 サーバSHOULDはこのイベントを登録します。
o invalid AT_COUNTER
o 無効のAT_COUNTER
Haverinen & Salowey Informational [Page 41] RFC 4186 EAP-SIM Authentication January 2006
[41ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
6.3.3. EAP-Failure
6.3.3. EAP-失敗
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.
2) AT_NOTIFICATIONコードが失敗を含意するとき、ぐるりと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サーバがEAP-失敗を送らないでしょうが、AAAサーバや中間的AAAプロキシなどの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-失敗パケットを受け入れなければなりません。 同輩SHOULDは他の場合で静かにEAP-失敗パケットを捨てます。
6.3.4. EAP-Success
6.3.4. 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 Notificationを受けた後に、同輩は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/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 fast
同輩が、AT_RESULT_IND(セクション6.2で議論するように)がオンな状態で速く保護された成功指摘を使用したがっているのを示さなかったなら
Haverinen & Salowey Informational [Page 42] RFC 4186 EAP-SIM Authentication January 2006
[42ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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 Notificationを受けた後に、同輩は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-成功パケットを受け入れてはいけません、サーバ証明が首尾よく終了されたとしても。
7. Key Generation
7. キー生成
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の完全な認証のときに、以下の基本的なGSM認証値(Kcキー)、NONCE_MT、および他の関連文脈からMaster Key(MK)を得ます。
MK = SHA1(Identity|n*Kc| NONCE_MT| Version List| Selected Version)
MKはSHA1と等しいです。(アイデンティティ| n*Kc| 一回だけ_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.
「上の公式で」|「キャラクタは連結を指示します。」 「アイデンティティ」は少しも終端空文字なしで同輩アイデンティティストリングを指示します。 それはこの交換で同輩によって送られた最後のAT_IDENTITY属性からのアイデンティティであるかAT_IDENTITYが使用されなかったなら、それがEAP-応答/アイデンティティパケットからのアイデンティティです。 アイデンティティストリングは少しも変化なしでそのままで含まれています。 セクション4.2.2で.2について議論するとき、EAP-SIM同輩のアイデンティティを伝えるためにEAP-応答/アイデンティティを当てにするのはお勧めできないです、そして、サーバSHOULDは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は値が連結したn Kcを指示します。 RANDがRANDが結果と考えるAT_で挑戦するとき、Kcキーは同次に使用されます。 NONCE_MTはNONCE_MT値(AT_NONCE_MT属性ではなく、一回だけの値だけ)を指示します。 バージョンListは属性のように同次に_AT_バージョンLISTからのサポートされた2バイトバージョン番号を含んでいます。 SelectedバージョンはAT_SELECTED_バージョンからの2バイトの選択されたバージョンです。 ネットワークバイトオーダーはちょうど属性のように使用されています。 ハッシュ関数SHA-1は[SHA-1]で指定されます。 いくつかのEAP/SIM/スタート往復旅行がEAP-SIM交換に使用されるなら、最後のEAP/SIM/スタートラウンドからのNONCE_MT、バージョンList、およびSelectedバージョンは使用されています、そして、前のEAP/SIM/スタートラウンドは無視されます。
Haverinen & Salowey Informational [Page 43] RFC 4186 EAP-SIM Authentication January 2006
[43ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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パケットを保護するために、別々のTransient EAPキーズ(TEKs)を生成するPseudo-乱数Function(PRF)にMaster Keyを与えます、リンクレイヤセキュリティのためのMaster Session Key(MSK)、および他の目的のためのExtended Master Session Key(EMSK)と同様に。 速い再認証のときに、EAPパケットを保護するのに同じTEKsを使用しなければなりませんでしたが、オリジナルから派生しているMKと新しい値からの新しいMSKと新しいEMSK MUSTは速さで再認証を交換しました。
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はそれ自身の目的のために2TEKsを必要とします。 認証の主要な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の連邦政府の情報Processing Standards(FIPS)公表186-2[PRF]で指定された乱数発生に基づいています。 疑似乱数生成器は[PRF](アルゴリズム1)の変更通知1つ(2001年の10月5日)で指定されます。 Algorithm1が汎用疑似乱数生成器として使用されるとき、変更通知(74ページ)で指定されるように、ステップ3.3における「モッズq」用語は省略されます。 アルゴリズムで使用される機能GはSecure Hash Standardを通して構成されます、規格のAppendix3.3で指定されるように。 機能GがSHA-1と非常に同様であることに注意されるべきですが、メッセージ詰め物は異なっています。 一部始終について[PRF]を参照してください。 便利において、正しい変更がある乱数アルゴリズムはAppendix 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ビットのXKEYとXVAL値が使用されているので、bは160と等しいです。 それぞれの完全な認証のときに、Master Keyは初期の秘密の種子主要なXKEYとして使用されます。 ステップ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ビット)、Master Session Key(64バイト)、Extended Master Session Key(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:
速い再認証のときに、新しいMaster Session Keyと新しいExtended Master Session Keyを生成するのに同じ疑似乱数生成器を使用できます。 '種子価値のXKEY'は以下の通り計算されます:
XKEY' = SHA1(Identity|counter|NONCE_S| MK)
'XKEY'はSHA1と等しいです。(_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
公式では、または、上では、IdentityがEAP-応答/SIM/スタートパケットのAT_IDENTITY属性から少しも終端空文字なしで速い再認証のアイデンティティを指示します。
Haverinen & Salowey Informational [Page 44] RFC 4186 EAP-SIM Authentication January 2006
[44ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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は前の完全な認証のときに引き出されたMaster Keyです。
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, ...).
'速い再認証のときに、疑似乱数生成器は新しい種子値のXKEYと共に動かされ'て、結果として起こる320ビットの乱数(x_0、x_1、…、x_m-1)は、新しい64バイトのMaster Session Keyと新しい64バイトのExtended Master Session Keyとして連結されて、2つの64バイトの塊に仕切られて、使用されます。 K_encrとK_autが速い再認証のときに引き出されないのでMaster Session KeyとExtended Master Sessionキーが主要なストリームの始まりから入手されることに注意してください(x_0、x_1…)。
The first 32 bytes of the MSK can be used as the Pairwise Master Key (PMK) for IEEE 802.11i.
IEEE 802.11iにPairwise Master Key(PMK)としてMSKの最初の32バイトを使用できます。
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バイトはさん-MPPE-RECV-KEYとさん-MPPE-SEND-KEYへの2番目の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).
初期のMaster Keyを生成するとき、数個のセッションのときにキー(Kcのもの)を結合する混合機能が、GSM認証手順と乱数NONCEで_がMTであると単一のセッションキーに生成したので、ハッシュ関数は使用されています。 このいくつかの理由があります。 現在のGSMセッションキーが大部分に64ビットあるので、それらの2つ以上が、より長いキーを生成するのに必要です。 キーを結合するのに一方向関数を使用することによって、私たちは攻撃者が何とかEAP-SIMセッションキーの1つを学んだとしてもそれが、彼がオリジナルのGSM Kcのものを学ぶのを手伝わないと確信しています。 さらに、私たちが計算で乱数NONCE_MTを入れるので、同輩は、それがネットワークから受けるEAP-SIMパケットが新鮮であることを確かめることができて、再演しません(また、セクション11を見てください)。
8. Message Format and Protocol Extensibility
8. メッセージ・フォーマットとプロトコル伸展性
8.1. Message Format
8.1. メッセージ・フォーマット
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のメソッド特有のType-データがあとに続くCode、Identifiers、Length、およびType分野で始まります。 EAPヘッダーのCode分野はEAP要求のための1と、そして、EAP Responsesのための2に設定されます。 用法
Haverinen & Salowey Informational [Page 45] RFC 4186 EAP-SIM Authentication January 2006
[45ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
Length and Identifier fields in the EAP header are also specified in [RFC3748]. In EAP-SIM, the Type field is set to 18.
また、EAPヘッダーの長さとIdentifier分野は[RFC3748]で指定されます。 EAP-SIMでは、Type分野は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では、Type-データは1八重奏のSubtype分野と2八重奏の予約された分野から成るEAP-SIMヘッダーと共に始まります。 EAP-SIMで使用されるSubtype値は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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード| 識別子| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| Subtype| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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ヘッダーに続くType-データの残りはTypeでコード化される属性から成ります、Length、Value形式。 以下の図は属性のジェネリック書式を示しています。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 値… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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].
特定のタイプの属性を示します。 属性タイプ値はEAP-AKA仕様[EAP-AKA]のIANA問題部で記載されています。
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.
4バイトの倍数における、この属性の長さを示します。 属性の最大の長さは1024バイトです。 長さはAttribute TypeとLengthバイトを含んでいます。
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.
この属性に関連している特定のデータ。 この分野はいつも含まれています、そして、それは長さが2バイト以上であるかもしれません。 タイプと長さの分野は値の分野の形式と長さを測定します。
Haverinen & Salowey Informational [Page 46] RFC 4186 EAP-SIM Authentication January 2006
[46ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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.
範囲の中で0〜127に付番された属性は非skippable属性と呼ばれます。 EAP-SIM同輩が同輩が認めない非skippable属性に遭遇すると、同輩はクライアントEAP-応答/SIM/誤りパケットを送らなければなりません。(それは、認証交換を終えます)。 EAP-SIMサーバがサーバが認識しない非skippable属性に遭遇するなら、サーバは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の範囲の中の属性はskippable属性と呼ばれます。 skippable属性が遭遇して、認識されないとき、それは無視されます。 まだ属性とメッセージデータの残りを処理しなければなりません。 属性のLength分野は、次の属性を捜し求める際に属性値をスキップするのに使用されます。
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.
他の属性の中で属性をカプセル化することができます。 言い換えれば、他の属性を含むように属性タイプの値の分野を指定できます。
8.2. Protocol Extensibility
8.2. プロトコル伸展性
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を広げることができます。 skippable属性が使用されているなら、壊れている古い実装なしでプロトコルを広げるのは可能です。
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
しかしながら、どんな新しい属性も、パケットが保全によって保護されていないとEAP-要求/SIM/始めかEAP-応答/SIM/始めに言い足しました。 したがって、EAP-SIMの最新版でこれらのメッセージを広げてはいけません。 _AT_バージョンLISTのサポートしているEAP-SIMバージョンのリストが1以外のバージョンを含んでいないなら、サーバは本書ではEAP-要求/SIM/開始メッセージで指定されたもの以外の属性を含んではいけません。 このプロトコルの将来のバージョンがEAP-要求/SIM/始めに新しい属性を指定して、まだプロトコルのバージョン1をサポートしているかもしれないことに注意してください。 この場合、サーバは、新しい属性を含んでいるEAP-要求/SIM/開始メッセージを送るかもしれなくて、AT_バージョン_LIST属性におけるプロトコルバージョン1と他のバージョンのサポートを示します。 同輩がバージョン1を選択するなら、同輩は本書では指定されたもの以外のEAP-要求/SIM/始めに含まれていたいかなる他の属性も無視しなければなりません。 同輩のAT_SELECTED_バージョンにおける選択されたEAP-SIMバージョンであるなら、1、同輩が含んではいけないその時は他ですか?
Haverinen & Salowey Informational [Page 47] RFC 4186 EAP-SIM Authentication January 2006
[47ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
attributes aside from those specified in this document in the EAP-Response/SIM/Start message.
それらは別として属性は本書では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 SHOULD NOTへのどんな拡大も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がバージョン交渉をサポートするので、また、新しいバージョン番号を使用することによって、プロトコルの新しいバージョンを指定できます。
9. Messages
9. メッセージ
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で指定されます。
9.1. EAP-Request/SIM/Start
9.1. EAP-要求/SIM/始め
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 RequestはEAP-要求/SIM/始めです。 EAP/SIM/スタート往復旅行は2つの目的に使用されます。 完全な認証では、このパケットは、AT_NONCE_MT属性をサーバに送るよう同輩に要求するのに使用されます。さらに、Start周遊旅行は、同輩のアイデンティティを得るのにセクション4.2で指定されるようにサーバによって使用されるかもしれません。 セクション4.2で議論するように、いくつかのStartラウンドが有効な同輩のアイデンティティを得るのに必要であるかもしれません。
The server MUST always include the AT_VERSION_LIST attribute.
サーバはいつもAT_バージョン_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.
サーバは以下のアイデンティティを要求する属性の1つを含むかもしれません: __永久的な_ID REQにおいて、または、__FULLAUTH_ID REQにおいて、または、__どんな_ID REQでも。 これらの3つの属性が互いに唯一ので、サーバは属性の1つ以上を含んではいけません。
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/開始メッセージを発行したなら、それは新しい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/開始メッセージを発行したなら、それは、ATがある新しいEAP-要求/SIM/スタートパケットに__どんな_ID REQも発行するか、または_ID_REQ属性をAT_FULLAUTHに発行してはいけません。
Haverinen & Salowey Informational [Page 48] RFC 4186 EAP-SIM Authentication January 2006
[48ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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があるEAP-要求/SIM/開始メッセージに_どんな_ID_REQ属性も発行したなら、それはATがある新しいEAP-要求/SIM/スタートパケットに_どんな_ID_REQ属性も発行してはいけません。
This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.
このメッセージはAT_MAC、AT_IV、またはAT_ENCR_DATAを含んではいけません。
9.2. EAP-Response/SIM/Start
9.2. EAP-応答/SIM/始め
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/始めがアイデンティティを要求する属性の1つを含んでいる場合にだけ、同輩は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を含んではいけません。
9.3. EAP-Request/SIM/Challenge
9.3. EAP-要求/SIM/挑戦
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.
AT_NONCE_MTを含む有効なEAP-応答/SIM/始めと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パケット| 一回だけ_MT
Haverinen & Salowey Informational [Page 49] RFC 4186 EAP-SIM Authentication January 2006
[49ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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.
EAPパケットはセクション8.1で指定されるように表されます。 16バイトのNONCE_MT値は同輩のAT_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値の分野の平文は入れ子にされた属性から成ります。 入れ子にされた属性はAT_PADDINGを含むかもしれません(セクション10.12で指定されるように)。 サーバがアイデンティティがプライバシーであるとサポートして、次の完全な認証のために匿名を同輩に伝えたいなら、入れ子にされた暗号化された属性はAT_ネクスト_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で指定されます。
9.4. EAP-Response/SIM/Challenge
9.4. EAP-応答/SIM/挑戦
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.
EAPパケットはセクション8.1で指定されるように表されます。 上で記法n*SRESで連結されて、指示された2か3つのSRES値がすぐに、EAPパケットバイトのあとに続きます。 対応するRANDがサーバのAT_RAND属性で挑戦するとき、SRES値は同次に使用されます。
Haverinen & Salowey Informational [Page 50] RFC 4186 EAP-SIM Authentication January 2006
[50ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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の使用を暗号化された(skippable)属性を含むこのメッセージの属性にするかもしれません。 EAPサーバはサーバが、これらが任意の属性であると実装しなかったとしてもこれらの属性を含んでいるEAP-応答/SIM/挑戦メッセージを処理しなければなりません。
9.5. EAP-Request/SIM/Re-authentication
9.5. 再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-応答/アイデンティティかEAP-応答/SIM/始めで有効な速い再認証のアイデンティティを受けたなら、サーバは再EAP-要求/SIM/認証メッセージを送ります。
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属性を含まなければなりません。 平文は以下の入れ子にされた暗号化された属性から成ります:(属性を含まなければなりません)。 _カウンタにおいて_一回だけの_Sで。 さらに、入れ子にされた暗号化された属性は以下の属性を含むかもしれません: _次の_REAUTH_IDにおいて_詰め物において。
9.6. EAP-Response/SIM/Re-authentication
9.6. 再EAP-応答/SIM/認証
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パケット| 一回だけ_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.
EAPパケットはセクション8.1で指定されるように表されます。 16バイトのNONCE_S値はサーバのAT_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
AT_IVとAT_ENCR_DATA属性を含まなければなりません。 入れ子にされた暗号化された属性はAT_COUNTER属性を含まなければなりません。 AT_COUNTER_、_また、SMALL属性は入れ子にするところに含まれるかもしれません。
Haverinen & Salowey Informational [Page 51] RFC 4186 EAP-SIM Authentication January 2006
[51ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
encrypted attributes, and it is included in cases specified in Section 5. The AT_PADDING attribute MAY be included.
暗号化された属性、およびそれはそうです。ケースでは、セクション5で指定されて、含まれています。 AT_PADDING属性は含まれるかもしれません。
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なしでもこのパケットを送って、SMALLは、同輩が首尾よくサーバを認証して、EAP交換が同輩のローカルの方針で受け入れられるのを示します。 したがって、これらの条件が満たされないなら、同輩は再EAP-応答/SIM/認証を送ってはいけませんが、同輩はクライアントEAP-応答/SIM/誤りを送らなければなりません。
9.7. EAP-Response/SIM/Client-Error
9.7. クライアント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属性を使用してはいけません。
9.8. EAP-Request/SIM/Notification
9.8. EAP-要求/SIM/通知
The usage of this message is specified in Section 6. The AT_NOTIFICATION attribute MUST be included.
このメッセージの用法はセクション6で指定されます。 AT_NOTIFICATION属性を含まなければなりません。
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_MAC属性は、AT_NOTIFICATIONの通知コードのPビットがゼロに設定されるなら含まなければならなくて、Pビットが1つに設定されるとき、ケースに含まれてはいけません。 セクション6でPビットについて議論します。
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 MUSTに対価を含んでいて、同じ速い再認証交換のときに再EAP-要求/SIM/認証パケットと同じにしてください。
Haverinen & Salowey Informational [Page 52] RFC 4186 EAP-SIM Authentication January 2006
[52ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
9.9. EAP-Response/SIM/Notification
9.9. EAP-応答/SIM/通知
The usage of this message is specified in Section 6. This packet is an acknowledgement of EAP-Request/SIM/Notification.
このメッセージの用法はセクション6で指定されます。 このパケットはEAP-要求/SIM/通知の承認です。
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.
AT_MAC属性は、EAP-要求/SIM/通知のAT_NOTIFICATIONの通知コードのPビットがゼロに設定されるとき、ケースに含まなければならなくて、Pビットが1つに設定されるとき、ケースに含まれてはいけません。 セクション6でPビットについて議論します。
No message-specific data is included in the MAC calculation, see Section 10.14.
セクション10.14は、どんなメッセージ特有のデータもMAC計算に含まれていないのを見ます。
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 MUSTに対価を含んでいて、同じ速い再認証交換のときに再EAP-要求/SIM/認証パケットと同じにしてください。
10. Attributes
10. 属性
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問題部で指定されます。
10.1. Table of Attributes
10.1. 属性のテーブル
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の中に含まなければならない入れ子にされた属性であるかどうかを示します、そして、「スキップ」で指示されたコラムは属性がskippable属性であるかどうかを示します。
"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インチが、メッセージに属性を含まなければならないのを示す、「01インチ、表示、属性がメッセージに時々含まれている、「0*、」、表示、属性は、本書では指定されたケースの中のメッセージに含まれていませんが、プロトコルの将来のバージョンに含まれるかもしれません」
Haverinen & Salowey Informational [Page 53] RFC 4186 EAP-SIM Authentication January 2006
[53ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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
(8)(9)Encrが_で_バージョン_リスト1 0 0 0 0 0 0 0 0N Nでスキップする属性(1)(2)(3)(4)(5)(6)(7)は_次の_匿名0 0 0-1 0 0 0 0 0 0Y Yで_底ならし革0 0 1 0 0 0 0 0 0N Nで_アイデンティティ0 0-1 0 0 0 0 0 0 0N Nで__FULLAUTH_ID_REQ0-1 0 0 0 0 0 0 0 0N Nのどんな_ID_REQ0-1 0 0 0 0 0 0 0 0N Nでも_永久的な_ID_REQ0-1 0 0 0 0 0 0 0 0N Nで_一回だけ_MT0 0-1 0 0 0 0 0 0 0N Nで_次の_REAUTH_IDで_バージョン0 0-1 0 0 0 0 0 0 0N Nを選択しました; 0 0 0-1 0 0 0 0 0-1 0 ___の___また、___のカウンタ0 0 0 0 0-1 0-1 0 1 1Y NのMac0 0 1 1 0-1 0-1 0 1 1N Nのインディアン座0 0 0-1 0-1 0 0 0 0-1 0-1N Yが_クライアント_誤り_コード0 0 0 0 0 0 1 0 0N Nで_通知0 0 0 0 1 0 0 0 0N Nで_一回だけ_S0 0 0 0 0 0 0 1 0Y Nで_小さい0 0 0 0 0 0 0 0 0-1Y Nを打ち返すという結果で0 0 0-1 0 *0-1 0-1 0 0-1 0-1Y Nを水増しするENCR_データ0 0 0-1 0*0-1 0-1 0 1 1N YのIV0 0 0-1 0*0-1 0-1 0 1 1N YのY Y
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は互いに排他的です。 同時に、それらの1つしか含むことができません。 属性のAT_IVとAT_ENCR_DATAの1つが含まれているなら、属性の両方を含まなければなりません。
10.2. AT_VERSION_LIST
10.2. _バージョン_リストで
The format of the AT_VERSION_LIST attribute is shown below.
AT_バージョン_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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _バージョン_L.で。| 長さ| 実際のバージョンリストの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン1であるとサポートされます。| バージョン2であるとサポートされます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョンNであるとサポートされます。| 詰め物| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
この属性はセクション4.1で指定されるようにバージョン交渉に使用されます。 属性はEAP-SIMサーバによってサポートされたバージョン番号を含んでいます。サーバがバージョンを含むだけでよい、それ、それ
Haverinen & Salowey Informational [Page 54] RFC 4186 EAP-SIM Authentication January 2006
[54ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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).
道具とそれは安全保障政策で許容されています。 最も都合のよいバージョンが最初に記載されている状態で、サーバSHOULDはよく使われる順のバージョンを記載します。 少なくとも1つのバージョン番号を含まなければなりません。 本書では説明されたプロトコルのバージョン番号は1(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バイトのActualバージョンList Lengthと共に始まります、ActualバージョンList Length属性の長さを含んでいなくて。(List Lengthはバイトで表現されるバージョンListの長さを指定します)。 サーバによってサポートされたバージョンのリストはこの野原のあとに続いています。(それぞれ、バージョンには、2バイトの長さがあります)。 例えば、1つのサポートしているバージョンしかなければ、ActualバージョンList Lengthは2歳です。 属性の長さが4バイトの倍数であるに違いないので、必要であるときに、送付者はどんなバイトでも値の分野を水増ししません。
10.3. AT_SELECTED_VERSION
10.3. _選択された_バージョンで
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _では、選択されます…| 長さ=1| 選択されたバージョン| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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で指定されるようにバージョン交渉に使用されます。 この属性の値の分野は2バイトのバージョン番号を含んでいます。(それは、同輩が使用したがっているEAP-SIMバージョンを示します)。
10.4. AT_NONCE_MT
10.4. _一回だけ_MTで
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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |_一回だけ_MTで| 長さ=5| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 一回だけ_MT| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Haverinen & Salowey Informational [Page 55] RFC 4186 EAP-SIM Authentication January 2006
[55ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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/スタートラウンドを含んでいるなら、同輩SHOULDはすべてのEAP-応答/SIM/スタートパケットで同じNONCE_MT値を使用します。 同輩SHOULDは、NONCE_がMTであると生成するのに偶発性の良い源を使用します。セキュリティアプリケーションのために乱数を生成することに関する詳しい情報に関して[RFC4086]を見てください。
10.5. AT_PERMANENT_ID_REQ
10.5. __永久的な_ID REQで
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |_では、パーマをかけてください…_REQ| 長さ=1| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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バイトだけを含んでいます。(バイトは、発信のゼロに設定されて、レセプションで無視されます)。
10.6. AT_ANY_ID_REQ
10.6. __どんな_ID REQでも
The format of the AT_ANY_ID_REQ attribute is shown below.
どんな_ID_REQも結果と考えるAT_の書式は以下に示されます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |__どんな_ID REQでも| 長さ=1| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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バイトだけを含んでいます。(バイトは、発信のゼロに設定されて、レセプションで無視されます)。
Haverinen & Salowey Informational [Page 56] RFC 4186 EAP-SIM Authentication January 2006
[56ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
10.7. AT_FULLAUTH_ID_REQ
10.7. __FULLAUTH_ID REQで
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 |
+---------------+---------------+-------------------------------+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |_FULLAUTH_で…| 長さ=1| 予約されます。| +---------------+---------------+-------------------------------+
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バイトだけを含んでいます。(バイトは、発信のゼロに設定されて、レセプションで無視されます)。
10.8. AT_IDENTITY
10.8. _アイデンティティで
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) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _アイデンティティで| 長さ| 実際のアイデンティティの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . アイデンティティ(任意の)…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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で指定されます。 同じアイデンティティ形式はAT_IDENTITY属性とEAP-応答/アイデンティティパケットで使用されて、同輩がそうしてはいけない例外でそれがAT_IDENTITYに含むアイデンティティに飾り付けをしてください。 アイデンティティは少しの終端空文字も含んでいません。 属性の長さが4バイトの倍数であるに違いないので、必要であるときに、送付者はどんなバイトでもアイデンティティを水増ししません。
Haverinen & Salowey Informational [Page 57] RFC 4186 EAP-SIM Authentication January 2006
[57ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
10.9. AT_RAND
10.9. _底ならし革で
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _底ならし革で| 長さ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . n*ランド…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
この属性の値の分野は予約された2バイトを含んでいます、続いて、長い間、n GSM RANDs、各16バイトを含みます。 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値を使用しなければなりません。 言い換えれば、一度、AT_RANDにRAND値を含むことができるだけです。 AT_RAND属性を処理するとき、同輩は、RANDsが異なっているのをチェックしなければなりません。
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の完全な認証交換に新鮮なRANDsを入手しなければなりません。 サーバは有効なAT_MACと共にEAP-応答/SIM/挑戦パケットを受信するか、またはコードでクライアントEAP-応答/SIM/誤りを受信するなら、より明確に、サーバは、AT_RANDにそれを含んでいるRANDsが消費されると考えなければなりません。「不十分な数の挑戦」か「RANDsは新鮮ではありません」。 しかしながら、他の場合(サーバがEAP-要求/SIM/挑戦パケットへの応答を受けないか、またはサーバが上に記載されたケース以外の応答を受けるなら)では、サーバは、RANDsが消費されると考える必要はありません、そして、サーバは次の完全な認証試みのAT_RAND属性にRANDsを再使用するかもしれません。
Haverinen & Salowey Informational [Page 58] RFC 4186 EAP-SIM Authentication January 2006
[58ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
10.10. AT_NEXT_PSEUDONYM
10.10. _次の_匿名で
The format of the AT_NEXT_PSEUDONYM attribute is shown below.
AT_ネクスト_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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _次の_PSEUで。| 長さ| 実際の匿名の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . 次の匿名…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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バイトの実際の匿名の長さで始まります。(それは、バイトで表現される以下の匿名の長さを指定します)。 同輩が次の認証に使用できる匿名ユーザ名はこの野原のあとに続いています。 ユーザ名はどんな分野の部分も含んではいけません。 ユーザ名は少しの終端空文字も含んでいません。 属性の長さが4バイトの倍数であるに違いないので、必要であるときに、送付者はどんなバイトでも匿名を水増ししません。 ユーザ名コード化はUTF-8変換形式[RFC3629]に続かなければなりません。 AT_ENCR_DATA属性の中でそれをカプセル化することによって、この属性をいつも暗号化しなければなりません。
10.11. AT_NEXT_REAUTH_ID
10.11. _次の_REAUTH_IDで
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _次の_レオーで。| 長さ| 実際の再Authアイデンティティの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . 次の速い再認証ユーザ名…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
この属性の値の分野はバイトで表現される以下の速い再認証のアイデンティティの長さを指定する2バイトの実際の再認証アイデンティティの長さで始まります。 同輩が次の速い再認証に使用できる速い再認証のアイデンティティはこの野原のあとに続いています、セクション5で説明されるように。 分野の部分が必要である環境では、速い再認証のアイデンティティはユーザ名部分とaの両方を含んでいます。
Haverinen & Salowey Informational [Page 59] RFC 4186 EAP-SIM Authentication January 2006
[59ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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.
分野の名前部分。 速い再認証のアイデンティティは少しの終端空文字も含んでいません。 属性の長さが4バイトの倍数であるに違いないので、必要であるときに、送付者はどんなバイトでも速い再認証のアイデンティティを水増ししません。 アイデンティティコード化はUTF-8変換形式[RFC3629]に続かなければなりません。 AT_ENCR_DATA属性の中でそれをカプセル化することによって、この属性をいつも暗号化しなければなりません。
10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING
10.12. __ENCR_データにおける_詰め物におけるIVで
AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted information between the EAP-SIM peer and server.
EAP-SIM同輩とサーバの間に暗号化された情報を伝えるのにAT_IVとAT_ENCR_DATA属性を使用できます。
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の値の分野は予約された2バイトを含んでいます、続いて、AT_ENCR_DATA属性によって必要とされた16バイトの初期化ベクトルを含みます。 予約されたバイトは、発信するとき、ゼロに設定されて、レセプションで無視されます。 そして、AT_IV属性を含まなければならない、_AT_ENCRである場合にだけ、DATAは含まれています。 この条件を満たさないパケットが遭遇するなら、セクション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パケットから初期化ベクトル価値を再使用してはいけません。 送付者SHOULDは、初期化ベクトルを生成するのに偶発性の良い源を使用します。 セキュリティアプリケーションのために乱数を生成することに関する詳しい情報に関して[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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _IVで| 長さ=5| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 初期設定ベクトル| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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属性の値の分野はエー・イー・エス(AES)[AES]を使用することで暗号化された暗号テキストバイトがAT_IV属性から初期化ベクトルを使用しながら128ビットのCipher Block Chainingで主要な(CBC)運転モードであとに続いた予約された2バイトから成ります。 予約されたバイトは、発信するとき、ゼロに設定されて、レセプションで無視されます。 CBCモードの記述に関して[CBC]を見てください。 AT_ENCR_DATA属性の書式は以下に示されます。
Haverinen & Salowey Informational [Page 60] RFC 4186 EAP-SIM Authentication January 2006
[60ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _ENCR_データで| 長さ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . データを暗号化します…| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_PADDING属性はAT_ENCR_DATA属性の中の他の入れ子にされた属性の全長が16バイトの倍数であるなら含まれていません。 いつものように、Padding属性のLengthはAttribute TypeとAttribute Length分野を含んでいます。 Padding属性の長さは、4バイトか8バイトか12バイトです。 それが選ばれているので、AT_ENCR_DATA属性の値の分野の長さは16バイトの倍数になります。 値の分野の実際のパッドバイトが発信での(00 16進)のゼロに合うように設定されます。 メッセージの受取人は、パッドバイトがゼロに設定されることを確かめなければなりません。 この検証が同輩で失敗するなら、エラーコードが「パケットを処理できない」状態で、それは、認証交換を終えるためにクライアント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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _詰め物で| 長さ| そっと歩きます… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Haverinen & Salowey Informational [Page 61] RFC 4186 EAP-SIM Authentication January 2006
[61ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
10.13. AT_RESULT_IND
10.13. _結果_インディアン座で
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _結果_で…| 長さ=1| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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属性の中でそれをカプセル化してはいけません。
10.14. AT_MAC
10.14. _Macで
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属性の値の分野は予約された2バイトを含んでいます、続いて、合わせられたメッセージ確認コード(MAC)を含みます。 MACは全体のEAPパケットの上で計算されて、任意のメッセージ特有のデータで連結されます、MAC属性の値の分野がMACについて計算するときにはゼロに合わせるように設定される例外で。 EAPパケットはセクション8.1における指定されるとしてのCode分野、Subtype分野で始まる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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _Macで| 長さ=5| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Mac| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Haverinen & Salowey Informational [Page 62] RFC 4186 EAP-SIM Authentication January 2006
[62ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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]の合わせられたハッシュ値です。 20バイトのHMAC-SHA1値から最初の16バイトに出力に先端を切らせることによって、HMAC-SHA1-128値を得ます。したがって、MACの長さは16バイトです。(MACの計算に使用される認証キー(K_aut)の派生はセクション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メッセージに含まれているとき、いかなる他の属性も見る前に受取人はAT_MAC属性を処理しなければなりません、EAP-要求/SIM/挑戦を処理する時を除いて。 EAP-要求/SIM/挑戦の処理はセクション9.3で指定されます。 メッセージ確認コードが無効であるなら、受取人は、セクション6.3で指定されるようにメッセージの他のすべての属性を無視して、働かなければなりません。
10.15. AT_COUNTER
10.15. _カウンタで
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _カウンタで| 長さ=1| カウンタ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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属性の中でそれをカプセル化することによって、この属性をいつも暗号化しなければなりません。
10.16. AT_COUNTER_TOO_SMALL
10.16. _では、__あまりに小さく反対してください。
The format of the AT_COUNTER_TOO_SMALL attribute is shown below.
形式、AT_COUNTERではも、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _では、反対してください…| 長さ=1| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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属性の中でそれをカプセル化することによって、この属性をいつも暗号化しなければなりません。
Haverinen & Salowey Informational [Page 63] RFC 4186 EAP-SIM Authentication January 2006
[63ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
10.17. AT_NONCE_S
10.17. _一回だけ_Sで
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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _一回だけ_Sで| 長さ=5| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | 一回だけ_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属性の値の分野は予約された2バイトを含んでいます、続いて、このEAP-SIMの速い再認証のためにサーバによって新たに生成された乱数(16バイト)を含みます。 乱数は同輩のための挑戦として新しい合わせることの材料のための種子値としても使用されます。 予約されたバイトは、発信のゼロに設定されて、レセプションで無視されます。 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値を再使用してはいけません。 サーバSHOULDは、NONCEが_Sであると生成するのに偶発性の良い源を使用します。 セキュリティアプリケーションのために乱数を生成することに関する詳しい情報に関して[RFC4086]を見てください。
10.18. AT_NOTIFICATION
10.18. _通知で
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |_通知で| 長さ=1|S|P| 通知コード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
以下に記載された通知コード値は予約されました。 以下での記述は通知の意味論を例証します。
Haverinen & Salowey Informational [Page 64] RFC 4186 EAP-SIM Authentication January 2006
[64ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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--ユーザは要求されたサービスに加入していません。 (うまくいっている認証の後に使用された失敗を含意します。)
10.19. AT_CLIENT_ERROR_CODE
10.19. _クライアント_誤り_コードで
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |_では、クライアント_は間違えます。| 長さ=1| クライアントエラーコード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_バージョン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 「RANDsは新鮮ではありません」: 同輩は、AT_RANDに含まれていたRAND挑戦が新鮮でなかったと信じています。
Haverinen & Salowey Informational [Page 65] RFC 4186 EAP-SIM Authentication January 2006
[65ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
11. IANA Considerations
11. IANA問題
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は属性やメッセージSubtypesなどのプロトコルデザインの大部分をEAP-AKA[EAP-AKA]と共有します。 EAP-SIMプロトコル番号はEAP-AKAと同じIANA登録で管理されるべきです。 初期の値が両方のプロトコルのために[EAP-AKA]に記載されているので、このドキュメントは少しの新しい登録やパラメタ配分も必要としません。 一般的な登録がEAP-SIMとEAP-AKAに使用されるとき、両方のプロトコルのためのプロトコル番号配分方針は[EAP-AKA]で指定されます。
12. Security Considerations
12. セキュリティ問題
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-SIMの要求されたセキュリティの特性について論じます、脆弱性とセキュリティ推薦と同様に。EAP仕様[RFC3748]はEAPのセキュリティの脆弱性について説明します。(EAPはそれ自身のセキュリティー対策を含んでいません)。
12.1. A3 and A8 Algorithms
12.1. A3とA8アルゴリズム
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]はA3とA8アルゴリズムの一般的なGSM認証手順と外部のインタフェース(入出力する)を指定します。これらの機能の操作が個々のオペレータのドメインの完全中で転んで、したがって、機能は完全に標準化されるより各オペレータによってむしろ指定されます。 [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バージョン1のセキュリティについての議論に関して[GSMクローニング]を見てください。 COMP-128 A3/A8アルゴリズムのいくつかの改訂版がこれらの弱点の公表の後に考案されて、公的に指定されたGSM-MILENAGEアルゴリズムがどんな知られている攻撃にも被害を受け易くないことに注意してください。
12.2. Identity Protection
12.2. アイデンティティ保護
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
EAP-SIMは受け身の盗聴に対して加入者のアイデンティティのプライバシーを保護する任意のアイデンティティプライバシーサポートを含んでいます。 このドキュメントは、EAP-SIM交換の一部としてサーバから同輩まで匿名を提供するためにメカニズムを指定するだけです。 したがって、まだ少しのEAP-SIM交換も実行していない同輩は利用可能な匿名を通常持っていません。 しかし、同輩に利用可能な匿名がないなら、プライバシーメカニズムを使用できません。
Haverinen & Salowey Informational [Page 66] RFC 4186 EAP-SIM Authentication January 2006
[66ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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.
明確で永久的なアイデンティティを送らなければならないでしょう。 端末のSHOULDは、リブートの向こう側にそれを維持できるように非揮発性メモリーの匿名を保存します。 ネットワークをまねる活発な攻撃者は、加入者の永久的なアイデンティティを学ぶのを試みるのにAT_PERMANENT_ID_REQ属性を使用するかもしれません。 しかしながら、セクション4.2.2で議論するように、ネットワークが匿名を認識できるべきであるのが信じているなら、端末は、cleartextの永久的なアイデンティティを送るのを拒否できます。
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.
同輩とサーバが、匿名が確かに維持されて、アイデンティティプライバシーが必要であることを保証できないなら、対外安全保障メカニズム(Protected拡張認証プロトコル(PEAP)[PEAP]などの)からの追加保護は使用されるかもしれません。 対外安全保障メカニズムが使用中であるなら、EAP-SIMのアイデンティティプライバシー機能は役に立たないかもしれません。 EAP-SIMがある対外安全保障メカニズムを使用するセキュリティ問題はこのドキュメントの範囲を超えています。
12.3. Mutual Authentication and Triplet Exposure
12.3. 互いの認証と三つ子の暴露
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/挑戦パケットで正しい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.
三つ子を得る別の方法は同輩プラットホームでウイルスか他の悪意があるソフトウェア一本で攻撃を開始することです。 同輩SHOULD、悪意があるソフトウェアで攻撃について質問している三つ子に対して保護されてください。 彼らが同輩によって保存されるか、扱われる、または同輩のサブシステムの間に伝えられるとき、攻撃者のキーをKcに暴露しないように注意するべきです。 同輩の中で保護された環境の外がこれらの値の輸送、ストレージ、および取り扱いを制限するために方法を取るべきです。 しかしながら、このドキュメントの範囲の外に同輩のウイルスの防止と同輩のオペレーティングシステムのセキュリティ能力があります。
Haverinen & Salowey Informational [Page 67] RFC 4186 EAP-SIM Authentication January 2006
[67ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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サーバはホームLocation Register(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サーバは、連続した認証交換に新鮮な三つ子(RANDは挑戦します)を使用するためにセクション3で指定されるように強制されます。 EAP-SIMが同輩がRANDsが新鮮であるかどうかチェックするどんな手段も強制しないので、体系のセキュリティは三つ子の秘密保持にもたれます。 しかしながら、同輩はいくつかの以前中古のRANDsを覚えているのに実装特有のメカニズムを使うかもしれません、そして、同輩はサーバのRANDsの新しさをチェックするかもしれません。 同輩であるときに、場合における操作はそれを検出します。RANDsによる新鮮であるのが、指定されたコネセクション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.
認証ベクトルの再使用を防ぐのはUMTS AuthenticationとKey Agreement(AKA)のデザインで考慮に入れられました。(それは、EAP-AKA[EAP-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サーバでEAP-SIMの互いの認証をすることに注意してください。一般に、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メソッドに拡大のようなサポートを提供するかもしれません。
Haverinen & Salowey Informational [Page 68] RFC 4186 EAP-SIM Authentication January 2006
[68ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
12.4. Flooding the Authentication Centre
12.4. 認証センターをあふれさせます。
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サーバはAuthentication Centre(AuC)から認証ベクトルを通常得ます。 EAP-SIMはAuCのために新しい用法を導入します。 このドキュメントの範囲の外にEAP-SIMサーバとAuCの間のプロトコルがあります。 しかしながら、悪意があるEAP-SIM同輩が、多くのプロトコルがサービス不能攻撃を仕掛けるという要求であると生成するかもしれないことに注意されるべきです。 EAP-SIMサーバ実装SHOULDはこれを考慮に入れます、そして、SHOULDはそれがAuCに向かって生成するトラフィックを制限するために手を打ちます、AuCをあふれさせて、サービス不能攻撃を広げることからのEAP-SIMからAuCの他のユーザまでの攻撃者を防いで。
12.5. Key Derivation
12.5. 主要な派生
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は主要な派生をサポートします。 主要な階層構造はセクション7で指定されます。 EAP-SIMは、より強い合わせるのが材料であり、より強いATがMACが評価する_であると生成するために数人のGSM三つ子を結合します。 結果として起こるキーの実勢力を認証アルゴリズムを含むオペレータ特有のパラメタに特に依存します、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が使用されるのを許容する安全保障政策が3人の三つ子を必要とする将来の方針のセキュリティに感染するかもしれないことに注意されるべきです、敵が、より弱い方針が適用されているとき交換されたメッセージを利用できるかもしれないので。
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加入者をまねる活発な攻撃者はn*RANDとAT_MAC値をEAPサーバからどんな与えられた加入者のアイデンティティにも容易に入手できます。 しかしながら、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
EAP-SIMが個々のGSM Kcキーから計算された少しの値も暴露しないとき、EAP-SIMにKcキーについてブルートフォースアタックを1つだけに取り付けるのは可能ではありません。 したがって、EAP-SIMで暴露された値でブルートフォースアタックを考えるとき、EAP-SIMセッションキーの有効長は事実によって感染されません。
Haverinen & Salowey Informational [Page 69] RFC 4186 EAP-SIM Authentication January 2006
[69ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
combined from several shorter keys, i.e., the effective length of 128 bits may be achieved. For additional considerations, see Section 12.8.
数個のより短いキーから結合されていて、すなわち、128ビットの有効長は達成されるかもしれません。 追加問題に関しては、セクション12.8を見てください。
12.6. Cryptographic Separation of Keys and Session Independence
12.6. キーとセッション独立の暗号の分離
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-SIMパケット(K_はencrします、K_aut)を保護するのに使用されるEAP Transientキーズ、Master Session Key、およびExtended Master Session Keyは暗号でそうです。EAP-SIMでは、別々です。 攻撃者は他のキーに基づくこれらのキーのどれかの少しの重要な情報も引き出すことができません。 攻撃者もGSM Kcキーからプレ共有秘密キー(気)について計算できません、EAP-SIM K_encrから、Master Session Keyか、Extended Master Session KeyからのEAP-SIM K_autから。
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 Transientキーズ、Master Session Key、およびExtended Master Session Keyは異なって、前の完全な認証交換のときに引き出された換算値から暗号で分離するでしょう。
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)をMaster Session KeyとExtended Master Session Keyの新しさに提供します。 完全な認証交換に使用されたのと同じEAP Transientキーズ(K_encr、K_aut)は、EAP交渉を保護するのに使用されます。 しかしながら、同じEAP Transientキーズを使用するすべての速い再認証の向こう側の保護が交換する再生と保全に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]は「受け身の攻撃(EAPの会話の捕獲などの)か活発な攻撃(MSKかEMSKの感染を含んでいる)がその後の、または、先のMSKsかEMSKsの感染を可能にしないというデモンストレーション」とセッション独立を定義します。 MSKsと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キー値が異なった交換に使用されるのを保証できません。 サーバだけがその新鮮なRANDsを確実にすることができます、そして、したがって、新鮮なKcキーは使用されています。
Haverinen & Salowey Informational [Page 70] RFC 4186 EAP-SIM Authentication January 2006
[70ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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.
したがって、同輩は、EAP-SIMセッションが内部のKc値に関して独立しているのを保証できません。 しかしながら、EAP-SIMでは、Kcキーは秘密の中間結果であると考えられます。(中間結果はメソッドの外でエクスポートされません)。 RAND再使用に関する詳しい情報に関してセクション12.3を見てください。
12.7. Dictionary Attacks
12.7. 辞書攻撃
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カードに保存されたあらかじめ共有された左右対称の秘密はパスフレーズでなく、またそれはパスフレーズから得られません。)
12.8. Credentials Re-use
12.8. 資格証明書再使用
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暗号化アルゴリズムが[Barkan-2003]に記録されるように使用されているなら、40ビット未満、活発な攻撃者は同輩に使いならすことができる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.
EAP-SIMが個々のKcキーから計算された少しの値も暴露しないのでA5暗号化アルゴリズムがEAP-SIMで使用されないので、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
当時、このドキュメントは書かれました、(3GPP)がこれらのA5脆弱性へのフィックスに働かせ始めた第3Generation Partnership Project。 3GPPで議論したソリューション提案の1つは保全で保護されたA5バージョン交渉です。(その交渉は、端末の前でKcに関する知識が主要であると立証するために基地局を必要とするでしょう)。
Haverinen & Salowey Informational [Page 71] RFC 4186 EAP-SIM Authentication January 2006
[71ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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.
Kcからネットワークまで計算されたどんな値も送ります。 別の提案はいわゆる特別なRANDsです、GSMの許容A5アルゴリズムや三つ子がEAP-SIMのために意図するという事実のように。そこでは、RAND挑戦の数ビットが、暗号の分離に三つ子の許容使用を示すことによって、使用されるでしょう。 現在これは処理中の作業です、そして、メカニズムはまだ選択されていません。
12.9. Integrity and Replay Protection, and Confidentiality
12.9. 保全、反復操作による保護、および秘密性
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/スタート往復旅行の間、これらの属性を使用できません。 しかしながら、プロトコル値(ユーザアイデンティティストリング、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.
完全な認証のときに、RAND値で基本的なGSM認証体系とNONCE_MT価値の使用からEAP交換の反復操作による保護を提供します。 また、EAP-SIMメッセージの再生に対する保護はあるEAP-SIM Subtypeと、異なったK_autキーがそれぞれの完全な認証交換における計算のAT_MACに使用されるという事実の上で一度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
EAP-SIMがトンネリングメソッドでないので、EAP-要求/通知、EAP-応答/通知、EAP-成功、またはEAP-失敗パケットが、秘密でなく、また保全で保護されない、またEAP-SIMに再生によって保護されていません。 物理的に不安定なネットワークでは、これは可能にされるかもしれません。
Haverinen & Salowey Informational [Page 72] RFC 4186 EAP-SIM Authentication January 2006
[72ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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.
誤った通知を同輩に送って、サービスの否定を仕掛ける攻撃者は、これらのパケットを偽造することによって、攻撃します。 セクション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 Notificationパケットで秘密情報を伝えてはいけません。
12.10. Negotiation Attacks
12.10. 交渉攻撃
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メソッドを使用するなら。
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は、ciphersuiteが交渉であるとサポートしません。
12.11. Protected Result Indications
12.11. 保護された結果指摘
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
頼り無い媒体の上でEAP-SIMを使用するとき、EAP-失敗パケットが無くなっても、EAP-SIM失敗指摘は、同輩とEAPサーバが相手の認証決定を知るのを確実にするのを助けるでしょう。 また、保護された成功指摘が使用されていると、Successパケットの損失は承認、保全、および再生で保護されたEAP-SIM成功指示で扱われるでしょう。 任意の成功指摘が使用されていないなら、同輩は、結局サーバが認証を引き継いだと信じるかもしれません、実際に失敗したとき。 アクセスがそうにならないので
Haverinen & Salowey Informational [Page 73] RFC 4186 EAP-SIM Authentication January 2006
[73ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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.
この場合与えて、クライアントが、時間の長期間の間それにはアクセスがないとわかることができるなら、保護された結果指摘は必要ではありません。
12.12. Man-in-the-Middle Attacks
12.12. 介入者攻撃
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.
介入者攻撃とセッションハイジャックを避けるために、利用者データSHOULDは物理的に不安定なネットワークに保全によって保護されています。 EAP-SIM Master Session Key、またはそれから得られたキーが保全保護キーとして使用されるかもしれませんか、または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メソッドの使用にも関連している介入者攻撃があります。 例えば、PEAP[PEAP-02]の早めのバージョンはこの攻撃に被害を受け易かったです。 この仕様はこれらの攻撃を扱いません。 EAP-SIMがトンネリングプロトコルと共に使用されるなら、凶暴な固有識別文字を通した介入者攻撃が一方通行の認証されたトンネルをセットアップできるのを防ぐためにプロトコルとEAP-SIMの間に提供された暗号の結合があるべきです。 例えば、PEAPの、より新しいバージョンはそのような暗号の結合を含んでいます。 EAP-SIM Master Session Keyは、暗号の結合を提供するのに使用されるかもしれません。 しかしながら、結合が提供されるメカニズムは、トンネリングプロトコルによって、このドキュメントの範囲を超えています。
12.13. Generating Random Numbers
12.13. 乱数を生成します。
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.
SHOULDが乱数を生成するのに偶発性の良い源を使用するEAP-SIM実装がプロトコルで必要です。 セキュリティアプリケーションのために乱数を生成する詳しい情報に関して[RFC4086]を見てください。
13. Security Claims
13. セキュリティクレーム
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.
Authメカニズム: EAP-SIMはGSM SIMメカニズムに基づいています。(それは、左右対称の128ビットのプレ共有秘密キーに基づく挑戦/応答認証と主要な協定メカニズムです)。 また、EAP-SIMは互いの認証を提供する同輩挑戦を利用します。
Ciphersuite negotiation: No
Ciphersuite交渉: いいえ
Mutual authentication: Yes (Section 12.3)
互いの認証: はい(セクション12.3)
Integrity protection: Yes (Section 12.9)
保全保護: はい(セクション12.9)
Haverinen & Salowey Informational [Page 74] RFC 4186 EAP-SIM Authentication January 2006
[74ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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)で主要な派生をサポートします。 しかしながら、セクション11で議論するように、同じ資格証明書がGSM/GPRSとEAP-SIMで使用されるなら、主要な強さは同じレベルにGSM、GSM/GPRSの上の上がっている攻撃で基本的にかなり引き下げられるかもしれません。 例えば、誤ったGSM/GPRS基地局を使用する活発な攻撃は有効な主要な強さをおよそゼロまで減少させます。
Description of key hierarchy: Please see Section 7.
主要な階層構造の記述: セクション7を見てください。
Dictionary attack protection: N/A (Section 12.7)
辞書攻撃保護: なし(セクション12.7)
Fast reconnect: Yes
速く再接続してください: はい
Cryptographic binding: 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で脆弱性について議論します。
14. Acknowledgements and Contributions
14. 承認と貢献
14.1. Contributors
14.1. 貢献者
In addition to the editors, Nora Dabbous, Jose Puthenkulam, and Prasanna Satarasinghe were significant contributors to this document.
エディタに加えて、ノラDabbous、ホセPuthenkulam、およびPrasanna Satarasingheはこのドキュメントへの重要な寄稿者でした。
Pasi Eronen and Jukka-Pekka Honkanen contributed Appendix A.
パシEronenとユッカ-ペッカHonkanenはAppendix Aを寄付しました。
14.2. Acknowledgements
14.2. 承認
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.Asokan、1月-エリック・エクバーグ、パトリクFlykt、ユッカ-ペッカHonkanen、Antti Kuikka、ユッカLatva、ラシ・レーティネン、Jyri Rinnemaa、ティモTakamaki、およびライモVuonnalaは多くの着想と概念をこのプロトコルに寄付しました。
Haverinen & Salowey Informational [Page 75] RFC 4186 EAP-SIM Authentication January 2006
[75ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
N. Asokan, Pasi Eronen, and Jukka-Pekka Honkanen contributed and helped in innumerable ways during the development of the protocol.
N.Asokan、パシEronen、およびユッカ-ペッカHonkanenは貢献して、プロトコルの開発の間、無数の方法で助けました。
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 NiemiとKaisaニーベルグは、実質的に主要な派生のデザインと速い再認証手順に貢献して、また、このプロトコルに関連する多くの議論にそれらの暗号の専門的技術を提供しました。
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.
バージョン12で非常に役に立つコメントをこの仕様[S3-020125]の早めのバージョンへの彼の非常に貴重なコメントと、見直して、グレッグ・ローズに提供してくださってありがとうございます。
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、フローラン・ベルサニ、ジャック・キャロン、ゴパルDommety、オーガスティンFarrugia、マーク・グレーソン、マックス・deグルート、プラカシュ・アイヤル、西・カント、ビクタのロルツ、Jouni Malinen、シャールバールパテル、トム・ポーチャー、マイケル・リチャードソン、ステファン・シュローダー、Umaシャンカル、ジェシー・ウォーカー、およびトーマス・ウィーランドをありがとうございます。 MAC計算に改良を提案するためのマックスのおかげで、特別です。
Thanks to Glen Zorn for reviewing this document and for providing very useful comments on the protocol.
このドキュメントを再検討して、プロトコルで非常に役に立つコメントをGlenゾルンに提供してくださってありがとうございます。
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.
おかげに、これを見直すためのバーナードAbobaはRFC3748のためにコンプライアンスを記録します。
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から多くの考えを取り入れます。
Haverinen & Salowey Informational [Page 76] RFC 4186 EAP-SIM Authentication January 2006
[76ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
14.2.1. Contributors' Addresses
14.2.1. 貢献者のアドレス
Nora Dabbous Gemplus 34 rue Guynemer 92447 Issy les Moulineaux France
ノラDabbous Gemplus34悔悟Guynemer92447Issy les Moulineauxフランス
Phone: +33 1 4648 2000 EMail: nora.dabbous@gemplus.com
以下に電話をしてください。 +33 1 4648 2000はメールされます: nora.dabbous@gemplus.com
Jose Puthenkulam Intel Corporation 2111 NE 25th Avenue, JF2-58 Hillsboro, OR 97124 USA
ホセPuthenkulamインテル社2111NE第25アベニュー、JF2-58ヒースボロー、または97124米国
Phone: +1 503 264 6121 EMail: jose.p.puthenkulam@intel.com
以下に電話をしてください。 +1 6121年の503 264メール: jose.p.puthenkulam@intel.com
Prasanna Satarasinghe Transat Technologies 180 State Street, Suite 240 Southlake, TX 76092 USA
Prasanna Satarasinghe Transat技術180ステイト・ストリート、240Southlake、スイートテキサス76092米国
Phone: + 1 817 4814412 EMail: prasannas@transat-tech.com
以下に電話をしてください。 + 1つの817 4814412メール: prasannas@transat-tech.com
Haverinen & Salowey Informational [Page 77] RFC 4186 EAP-SIM Authentication January 2006
[77ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
15. References
15. 参照
15.1. Normative References
15.1. 引用規格
[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仕様書GSM03.20(ETS300 534):」 「デジタルセル通信システム(フェーズ2)」。 「セキュリティはネットワーク機能を関係づけた」、」、8月1997日
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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仕様書GSM03.03(ETS300 523):」 「デジタルセル通信システム(フェーズ2)」。 「付番、アドレシング、および識別」、」、4月1997日
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC
2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen,
"The Network Access Identifier", RFC 4282,
December 2005.
2005年12月の[RFC4282]AbobaとB.と用務員とM.とArkko、J.とP.Eronen、「ネットワークアクセス識別子」RFC4282。
[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)」」11月2001日の 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の特別な公表800-38A、「ブロックのための推薦は運転モードを解きます--メソッドとテクニック」」、12月2001日の 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.
商務省、米国の「180-1 「細切れ肉料理規格を保証してください」という連邦情報処理基準(FIPS)公表」1995年4月の[SHA-1]米国商務省標準技術局。
Haverinen & Salowey Informational [Page 78] RFC 4186 EAP-SIM Authentication January 2006
[78ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
[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]米国商務省標準技術局、「連邦政府の情報Processing Standards(FIPS)公表186-2(変更通知がある)」。 2000年1月の「デジタル署名基準(DSS)。」 利用可能である、以下のオンライン http://csrc.nist.gov/publications/ 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、ISO10646の変化形式」STD63、RFC3629、11月2003日
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J.,
and H. Levkowetz, "Extensible Authentication
Protocol (EAP)", RFC 3748, June 2004.
[RFC3748]Aboba、B.、Blunk、L.、Vollbrecht、J.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、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-別名]のArkko、J.、およびH.Haverinen、「広げることができる認証は第3世代認証のための方法と主要な協定(EAP-別名)について議定書の中で述べます」、RFC4187、2006年1月。
15.2. Informative References
15.2. 有益な参照
[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 t23.003] 第3世代パートナーシッププロジェクト、「3GPP仕様書3GPP t23.003V6.8.0:」 「第3世代Parnershipは突出しています」。 仕様書グループコアネットワーク。 「付番、アドレシング、および識別(リリース6)」、」、12月2005日
[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 t55.205] 第3世代パートナーシッププロジェクト、「3GPP仕様書3GPP t55.205V6.0.0:」 「第3世代パートナーシッププロジェクト」。 仕様書グループサービスとシステム局面。 GSM-MILENAGEアルゴリズムの仕様: 「例のアルゴリズムはKey Generation機能のGSM Authentication、A3、およびA8(リリース6)のためにセットした」、」、12月2002日
[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.、S.とゾルンとG.とサイモン、D.とA.Palekar、「保護されたEAPプロトコル(PEAP)」というJosefssonは進行中(2002年2月)で働いています。
Haverinen & Salowey Informational [Page 79] RFC 4186 EAP-SIM Authentication January 2006
[79ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
[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.
B.、サイモン、D.、Arkko、J.、Eronen、P.、およびH.Levkowetz、「拡張認証プロトコル(EAP)Key Management枠組み」という[EAPを合わせます]のAbobaは進行中(2005年10月)で働いています。
[Service-Identity] Arkko, J. and P. Eronen, "Authenticated Service
Information for the Extensible Authentication
Protocol (EAP)", Work in Progress, October 2004.
「拡張認証プロトコル(EAP)のための認証されたサービス情報」という[サービスアイデンティティ]のArkko、J.、およびP.Eronenは進歩、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.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
[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、第3Generation Partnership Projectドキュメント3GPP TSG SA WG3 Security S3#22のコメント、S3-020125」2002年2月。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC
3344, August 2002.
[RFC3344] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS
Attributes ", RFC 2548, March 1999.
[RFC2548] ゾルン、G.、「マイクロソフトの業者特有の半径属性」、RFC2548、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脆弱性に関するウェブページ
[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メーリングリスト5月29日、2003 2003http://mail.frascone.com/pipermail/公衆/eap/5月/001267.htmlに掲示されます。
Haverinen & Salowey Informational [Page 80] RFC 4186 EAP-SIM Authentication January 2006
[80ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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 FIPS186-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:
最初のパケットは明瞭な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:
クライアントのアイデンティティが" 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 2e66 6f 6f
Haverinen & Salowey Informational [Page 81] RFC 4186 EAP-SIM Authentication January 2006
[81ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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-SIM0a。 EAP-SIM「副-タイプ」: 始め00 00。 (予約される)です。 0f。 タイプを結果と考えてください: _バージョン_リスト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:
クライアントは、一回だけを選択して、以下のパケットで応じます:
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-SIM0a。 EAP-SIM「副-タイプ」: 始め00 00。 (予約される)です。 07 ; タイプを結果と考えてください: _一回だけ_MT05で。 長さを結果と考えてください: 20の八重奏(5*4)00 00。 (予約される)です。 01 23 45 67 ; NONCE_MT値の89腹筋cd ef fe dc Ba98 76 54 32 10 10。 タイプを結果と考えてください: _選択された_バージョン01で。 長さを結果と考えてください: 4つの八重奏(1*4)00 01。 バージョン: 1
Haverinen & Salowey Informational [Page 82] RFC 4186 EAP-SIM Authentication January 2006
[82ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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)
(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
39d45aea f4e30601 983e972b 6cfd46d1 c3637733 65690d09cd44976b 525f47d3 a60a985e 955c53b0 90b2e4b7 3719196a40254296K_encr=536e5ebc 4465582a a6a8ec99 86ebb620K_aut=25af1942 efcbf4bc 72b39434 21f2a974 MSK=8fd14a88 8f46b9a7 886e4488 EMSKは5949eab0 fff69d52 315c6c63 4fd14a7f 0d52023d 56f79698 fa6596ab eed4f93f bb48eb53 4d985414 ceed0d9a8ed33c38 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).
次に、サーバは匿名と速い再認証のアイデンティティ(それぞれこの場合「w8w49PexCazWJ&xCIARmxuMKht5S1sxR DqXSEFBEg3DcZP9cIxTe5J4OyIwNGVzxeJOU1G」と「Y24fNSrz8BP274jOJaF17WfxI8YO7QX0 0pMXk9XMMVOw7broaNhTczuFq53aEpOkk3L0dm@eapsim.foo 」)を選択します。
Haverinen & Salowey Informational [Page 83] RFC 4186 EAP-SIM Authentication January 2006
[83ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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
84 ; タイプを結果と考えてください: _次の_匿名13で。 長さを結果と考えてください: 76の八重奏(19*4)00 46。 実際の匿名の長さ: 70の八重奏77 38 77 34 39 50 65 78 43 61 7a57 4a26 78 43 49 41 52 6d78 75 4d 4b68 74 35 53 31 73 78 52 44 71 58 53 45 46 42 45 67 33 44 63 5a50 39 63 49 78 54 65 35 4a34 4f79 49 77 4e47 56 7a78 65 4a 4f55 31 47 00 00。 (属性詰め物) 85 ; タイプを結果と考えてください: _次の_REAUTH_ID16で。 長さを結果と考えてください: 88の八重奏(22*4)00 51。 実際の再authアイデンティティの長さ: 81の八重奏59 32 34 66 4e53 72 7a38 42 50 32 37 34 6a 4f 4a61 46 31 37 57 66 78 49 38 59 4f37 51 58 30 30 70 4d58 6b39 58 4d 4d56 4f77 37 62 72 6f61 4e68 54 63 7a75 46 71 35 33 61 45 70 4f 6b 6b33 4c30 64 6d40 65 61 70 73 69 6d 2e66 6f 6f00 00 00。 (属性詰め物) 06 ; タイプを結果と考えてください: _詰め物03で。 長さを結果と考えてください: 12の八重奏(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-SIM0b。 EAP-SIM「副-タイプ」: 挑戦00 00。 (予約される)です。 01 ; タイプを結果と考えてください: _底ならし革0dで。 長さを結果と考えてください: 52の八重奏(13*4)00 00。 (予約される)です。 10 11 12 13 ; 最初に、RAND14 15 16 17 18 19 1a 1b 1c 1d 1e 1f20 21 22 23。 2番目のRAND24 25 26 27 28 29 2a 2b 2c 2d 2e 2f
Haverinen & Salowey Informational [Page 84] RFC 4186 EAP-SIM Authentication January 2006
[84ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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 ; 3番目のRAND34 35 36 37 38 39 3a 3b 3c 3d 3e 3f81。 タイプを結果と考えてください: _IV05で。 長さを結果と考えてください: 20の八重奏(5*4)00 00。 (予約される)です。 9e18b0 c2。 IV値の9a65 22 63c0 6e fb54dd00a8 95 82。 タイプを結果と考えてください: _ENCR_データ2dで。 長さを結果と考えてください: 180の八重奏(45*4)00 00。 (予約される)です。 55、f2 93 9b bd b1 b1 9e a1 b4 7f c0 b3 e0、4c腹筋2c f7 37 2d98e3 02 3c 6b b9 24 15 72 3d58Ba d6 6c e0 84e1 01b6 0f53 58 35 4b d4 21 82 78ae a7 bf 2c Ba Ce33 10 6a教育dc62 5b 0c 1d 5a a6 7a41 73 9a e5 b5 79 50 97 3f c7ff83 01 07 3c 6f95 31 50fc30 3eになってください; a1 52d1 e1 0a 2d 1f 4f52 26da a1 ee90 05 47 22 52bd b3 b7 1d 6f 0c 3a34 90 31 6c46 92 98 71は71 79 90がd2 5f 6d d7 f2 b7 b3 20bf 4d 5a99 2e88 03 31d7 29 94 5a ec75ae 5d43c8教育a5 fe62 33fc ac49 4e e6 7a 0d50 4d 0bであったなら45cd fd bc a6 11 2f07f8をbdします。 タイプを結果と考えてください: _Mac05で。 長さを結果と考えてください: 20の八重奏(5*4)00 00。 (予約される)です。 fe f3 24ac。 MAC価値39 62のb5 9f 3b d7 82 53ae 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は上(ゼロに設定されたMAC値がある)のEAPパケットの上で計算されます、NONCE_MT値(合計296バイト)があとに続いていて。
Haverinen & Salowey Informational [Page 85] RFC 4186 EAP-SIM Authentication January 2006
[85ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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-SIM0b。 EAP-SIM「副-タイプ」: 挑戦00 00。 (予約される)です。 0b。 タイプを結果と考えてください: _Mac05で。 長さを結果と考えてください: 20の八重奏(5*4)00 00。 (予約される)です。 f5 6d64 33。 MAC値のe6 8e d2 97 6a c1 19 37fc 3d11 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は上(ゼロに設定されたMAC値がある)のEAPパケットの上で計算されます、SRES値(合計40バイト)があとに続いていて。
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-要求/アイデンティティパケットはいつものように同じです。 EAP-応答/アイデンティティは速い再認証のアイデンティティ(DATAが上で結果と考えるAT_ENCR_からの)を含んでいます:
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 4e53 72 7a38 42 50 32 37 34 6a 4f 4a61 46 31 37 57 66 78 49 38 59 4f37 51 58 30 30 70 4d58 6b39 58 4d 4d56 4f77 37 62 72 6f61 4e68 54 63 7a75 46 71 35 33 61 45 70 4f 6b 6b33 4c30 64 6d40 65 61 70 73 69 6d 2e66 6f 6f
Haverinen & Salowey Informational [Page 86] RFC 4186 EAP-SIM Authentication January 2006
[86ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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/認証で応じるでしょう。 それは、関連対価を検索して、一回だけを発生させて、新しい再認証のアイデンティティ(この場合「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)
13 ; タイプを結果と考えてください: _では、01を打ち返してください。 長さを結果と考えてください: 4つの八重奏(1*4)00 01。 対価15。 タイプを結果と考えてください: _一回だけ_S05で。 長さを結果と考えてください: 20の八重奏(5*4)00 00。 (予約される)です。 01 23 45 67 ; NONCE_S値の89腹筋cd ef fe dc Ba98 76 54 32 10 85。 タイプを結果と考えてください: _次の_REAUTH_ID16で。 長さを結果と考えてください: 88の八重奏(22*4)00 51。 実際の再authアイデンティティの長さ: 81の八重奏75 74 61 30 4d30 69 79 49 73 4d77 57 70 35 54 54 64 53 64 6e 4f 4c76 67 32 58 44 56 66 32 31 4f59 74 31 76 6e66 69 4d63 73 35 64 6e49 44 48 4f49 46 56 61 76 49 52 7a 4d52 79 7a57 36 76 46 7a64 48 57 40 65 61 70 73 69 6d 2e66 6f 6f00 00 00。 (属性詰め物)
Haverinen & Salowey Informational [Page 87] RFC 4186 EAP-SIM Authentication January 2006
[87ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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 00a4。 長さ: 164の八重奏12。 以下をタイプしてください。 EAP-SIM0d。 EAP-SIM「副-タイプ」: 再認証00 00。 (予約される)です。 81 ; タイプを結果と考えてください: _IV05で。 長さを結果と考えてください: 20の八重奏(5*4)00 00。 (予約される)です。 d5 85ac77。 IV値の86b9 03 36 65 7c77b4 65 75b9 c4 82。 タイプを結果と考えてください: _ENCR_データ1dで。 長さを結果と考えてください: 116の八重奏(29*4)00 00。 (予約される)です。 68 62 91a9 d2腹筋c5 8c aa32 94b6 e8 5b44 84 6c44e5 dc b2 de 8b 9e80d6 9d49 85 8a 5d b8 4c dc 1c 9b c9 5c01b9 6b 6e ca31 34 74ae a6 d3 14 16e1 9d aa 9d f7 0f05 00 88 41ca80 14 96 4d 3b30a4 9b Cf43e4 d3 f1 8e86 29 5a 4a 2b38d9 6c97 05c2 bb b0 5c 4a ac e9 7d 5e af f5 64 04 6c 8b d3 0b c3 9b e5 e1 7a Ce2b10a6 0b。 タイプを結果と考えてください: _Mac05で。 長さを結果と考えてください: 20の八重奏(5*4)00 00。 (予約される)です。 48 3a17 99。 MAC値のb8 3d 7c d3 d0 a1 e4 01d9 ee47 70
The MAC is calculated over the EAP packet above (with MAC value set to zero; a total of 164 bytes).
MACは上(合計ゼロ;164バイトに設定されたMAC値がある)のEAPパケットの上で計算されます。
Finally, the server derives new keys. The XKEY' is calculated as described in Section 7*:
最終的に、サーバは新しいキーを引き出します。 'XKEY'はセクション7*で説明されるように計算されます:
XKEY' = 863dc120 32e08343 c1a2308d b48377f6 801f58d4
'XKEY'は863dc120 32e08343 c1a2308d b48377f6 801f58d4と等しいです。
Haverinen & Salowey Informational [Page 88] RFC 4186 EAP-SIM Authentication January 2006
[88ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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
6263f614 973895e1 335f7e30 cff028ee 2176f519 002c9abe 732fe0ef 00cf167c756d9e4c ed6d5ed6 40eb3fe3MSK=8565ca07 6e7fb8a8 17cfe8d9 adbce441 d47c4f5e EMSKは3d8ff786 3a630b2b 06e2cf20 9684c13f 6b82f992 f2b06f1b54bf51ef 237f2a40 1ef5e0d7 e098a34c 533eaebf34578854b7721526 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
13 ; タイプを結果と考えてください: _では、01を打ち返してください。 長さを結果と考えてください: 4つの八重奏(1*4)00 01。 対価06。 タイプを結果と考えてください: _詰め物03で。 長さを結果と考えてください: 12の八重奏(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-SIM0d。 EAP-SIM「副-タイプ」: 再認証00 00。 (予約される)です。 81 ; タイプを結果と考えてください: _IV05で。 長さを結果と考えてください: 20の八重奏(5*4)00 00。 (予約される)です。 cd f7ff a6。 IV値の5d e0 4c02 6b56c8 6b76b1 02ea82。 タイプを結果と考えてください: _ENCR_データ05で。 長さを結果と考えてください: 20の八重奏(5*4)00 00。 (予約される)です。 b6教育d3 82 79e2 a1 42 3c 1a fc 5c45 5c 7d56
Haverinen & Salowey Informational [Page 89] RFC 4186 EAP-SIM Authentication January 2006
[89ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
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。 タイプを結果と考えてください: _Mac05で。 長さを結果と考えてください: 20の八重奏(5*4)00 00。 (予約される)です。 ファf7 6b71。 MAC値のfb e2 d2 55b9 6a35 66c9 15c6 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は上(ゼロに設定されたMAC値がある)のEAPパケットの上で計算されます、NONCE_S値(合計84バイト)があとに続いていて。
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.
「The」|「キャラクタは連結を指示します、そして、"^"は羃法を指示します。」
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: 貸された16進法では、t=67452301EFCDAB89 98BADCFE10325476C3D2E1F0 ThisはH0のための初期の値です。|H1|H2|H3|FIPS SHSのH4[SHA-1]
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
ステップ3: 3.1をしてください。mへのj=0--1 0〜XSEED_j=0/*いいえ任意のユーザ入力*/3.2For i=1はaをします。 XVALはモッズ2^b b.w_i=G(t、XVAL)cと等しいです(XKEY+XSEED_j)。 XKEYはモッズ2^b3.3x_j=w_0と等しいです(1+XKEY+w_i)。|w_1
Haverinen & Salowey Informational [Page 90] RFC 4186 EAP-SIM Authentication January 2006
[90ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
Authors' Addresses
作者のアドレス
Henry Haverinen (editor) Nokia Enterprise Solutions P.O. Box 12 FIN-40101 Jyvaskyla Finland
ヘンリーHaverinen(エディタ)ノキアエンタープライズソリューション私書箱12フィン-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ワシントン98121シアトル(米国)
Phone: +1 206 256 3380 EMail: jsalowey@cisco.com
以下に電話をしてください。 +1 3380年の206 256メール: jsalowey@cisco.com
Haverinen & Salowey Informational [Page 91] RFC 4186 EAP-SIM Authentication January 2006
[91ページ]RFC4186EAP-SIM認証2006年1月の情報のHaverinen&Salowey
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Haverinen & Salowey Informational [Page 92]
Haverinen&Salowey情報です。[92ページ]
一覧
スポンサーリンク
