RFC4187 日本語訳
4187 Extensible Authentication Protocol Method for 3rd GenerationAuthentication and Key Agreement (EAP-AKA). J. Arkko, H. Haverinen. January 2006. (Format: TXT=194958 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Arkko
Request for Comments: 4187 Ericsson
Category: Informational H. Haverinen
Nokia
January 2006
Arkkoがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4187年のエリクソンカテゴリ: 情報のH.Haverinenノキア2006年1月
Extensible Authentication Protocol Method for 3rd Generation
Authentication and Key Agreement (EAP-AKA)
第3世代認証と主要な協定のための拡張認証プロトコルメソッド(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-AKA protocol was developed by 3GPP. The documentation of EAP-AKA is provided as information to the Internet community. While the EAP WG has verified that EAP-AKA 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 underlying UMTS AKA algorithms.
EAP-AKAプロトコルは3GPPによって開発されました。 情報としてEAP-AKAのドキュメンテーションをインターネットコミュニティに提供します。 EAP WGは、EAP-AKAがRFC3748で定義されるようにEAPと互換性があることを確かめましたが、他のレビューを全くしていません、セキュリティクレームの合法化を含んでいて。また、IETFは基本的なUMTS AKAアルゴリズムのセキュリティを見直していません。
Abstract
要約
This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card.
このドキュメントは認証とAuthenticationとKey Agreement(AKA)メカニズムを使用するセッションの主要な分配に拡張認証プロトコル(EAP)メカニズムを指定します。 AKAは3番目の世代モバイルネットワークのUniversalのモバイルTelecommunications System(UMTS)とCDMA2000に使用されます。 AKAは対称鍵に基づいていて、UMTS加入者識別モジュール、USIM、または(移動可能)のユーザIdentity Moduleである加入者識別モジュールへ通常駆け込みます、(R)UIM、スマートカードと同様です。
EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure.
EAP-AKAは任意のアイデンティティプライバシーサポート、任意の結果指摘、および任意の速い再認証手順を含んでいます。
Arkko & Haverinen Informational [Page 1] RFC 4187 EAP-AKA Authentication January 2006
[1ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
Table of Contents
目次
1. Introduction and Motivation .....................................4
2. Terms and Conventions Used in This Document .....................5
3. Protocol Overview ...............................................9
4. Operation ......................................................15
4.1. Identity Management .......................................15
4.1.1. Format, Generation, and Usage of Peer Identities ...15
4.1.2. Communicating the Peer Identity to the Server ......21
4.1.3. Choice of Identity for the EAP-Response/Identity ...23
4.1.4. Server Operation in the Beginning of
EAP-AKA Exchange ...................................23
4.1.5. Processing of EAP-Request/AKA-Identity by
the Peer ...........................................24
4.1.6. Attacks against Identity Privacy ...................25
4.1.7. Processing of AT_IDENTITY by the Server ............26
4.2. Message Sequence Examples (Informative) ...................27
4.2.1. Usage of AT_ANY_ID_REQ .............................27
4.2.2. Fall Back on Full Authentication ...................28
4.2.3. Requesting the Permanent Identity 1 ................29
4.2.4. Requesting the Permanent Identity 2 ................30
4.2.5. Three EAP/AKA-Identity Round Trips .................30
5. Fast Re-Authentication .........................................32
5.1. General ...................................................32
5.2. Comparison to AKA .........................................33
5.3. Fast Re-Authentication Identity ...........................33
5.4. Fast Re-Authentication Procedure ..........................35
5.5. Fast Re-Authentication Procedure when Counter is
Too Small .................................................37
6. EAP-AKA Notifications ..........................................38
6.1. General ...................................................38
6.2. Result Indications ........................................39
6.3. Error Cases ...............................................40
6.3.1. Peer Operation .....................................41
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/AKA-Identity ..................................48
9.2. EAP-Response/AKA-Identity .................................48
9.3. EAP-Request/AKA-Challenge .................................49
9.4. EAP-Response/AKA-Challenge ................................49
9.5. EAP-Response/AKA-Authentication-Reject ....................50
9.6. EAP-Response/AKA-Synchronization-Failure ..................50
1. 序論と動機…4 2. このドキュメントで中古の期間、コンベンション…5 3. 概要について議定書の中で述べてください…9 4. 操作…15 4.1. アイデンティティ管理…15 4.1.1. 同輩のアイデンティティの形式、世代、および用法…15 4.1.2. サーバへの同輩のアイデンティティを伝えます…21 4.1.3. EAP-応答/アイデンティティのためのアイデンティティの選択…23 4.1.4. 初めにEAP-別名交換のサーバ操作…23 4.1.5. 同輩による別名EAP-要求/アイデンティティの処理…24 4.1.6. アイデンティティプライバシーに対する攻撃…25 4.1.7. 処理する、_サーバによるアイデンティティで…26 4.2. メッセージ系列の例(有益な)…27 4.2.1. __のどんな_ID REQの使用法も…27 4.2.2. 完全な認証のときに、後ろへ下がってください…28 4.2.3. 永久的なアイデンティティ1を要求します…29 4.2.4. 永久的なアイデンティティ2を要求します…30 4.2.5. 3つの別名EAP/アイデンティティ周遊旅行…30 5. 速い再認証…32 5.1. 一般…32 5.2. 別名との比較…33 5.3. 速い再認証のアイデンティティ…33 5.4. 速い再認証手順…35 5.5. Counterであるときに、速く、Re-認証ProcedureはToo Smallです…37 6. EAP-別名通知…38 6.1. 一般…38 6.2. 結果指摘…39 6.3. 誤り事件…40 6.3.1. 同輩操作…41 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-要求/アイデンティティ…48 9.2. 別名EAP-応答/アイデンティティ…48 9.3. 別名EAP-要求/挑戦…49 9.4. 別名EAP-応答/挑戦…49 9.5. 別名認証EAP-応答/廃棄物…50 9.6. 別名同期EAP-応答/失敗…50
Arkko & Haverinen Informational [Page 2] RFC 4187 EAP-AKA Authentication January 2006
[2ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
9.7. EAP-Request/AKA-Reauthentication ..........................50
9.8. EAP-Response/AKA-Reauthentication .........................51
9.9. EAP-Response/AKA-Client-Error .............................52
9.10. EAP-Request/AKA-Notification .............................52
9.11. EAP-Response/AKA-Notification ............................52
10. Attributes ....................................................53
10.1. Table of Attributes ......................................53
10.2. AT_PERMANENT_ID_REQ ......................................54
10.3. AT_ANY_ID_REQ ............................................54
10.4. AT_FULLAUTH_ID_REQ .......................................54
10.5. AT_IDENTITY ..............................................55
10.6. AT_RAND ..................................................55
10.7. AT_AUTN ..................................................56
10.8. AT_RES ...................................................56
10.9. AT_AUTS ..................................................57
10.10. AT_NEXT_PSEUDONYM .......................................57
10.11. AT_NEXT_REAUTH_ID .......................................58
10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING .....................58
10.13. AT_CHECKCODE ............................................60
10.14. AT_RESULT_IND ...........................................62
10.15. AT_MAC ..................................................63
10.16. AT_COUNTER ..............................................64
10.17. AT_COUNTER_TOO_SMALL ....................................64
10.18. AT_NONCE_S ..............................................65
10.19. AT_NOTIFICATION .........................................65
10.20. AT_CLIENT_ERROR_CODE ....................................66
11. IANA and Protocol Numbering Considerations ....................66
12. Security Considerations .......................................68
12.1. Identity Protection ......................................69
12.2. Mutual Authentication ....................................69
12.3. Flooding the Authentication Centre .......................69
12.4. Key Derivation ...........................................70
12.5. Brute-Force and Dictionary Attacks .......................70
12.6. Protection, Replay Protection, and Confidentiality .......70
12.7. Negotiation Attacks ......................................71
12.8. Protected Result Indications .............................72
12.9. Man-in-the-Middle Attacks ................................72
12.10. Generating Random Numbers ...............................73
13. Security Claims ...............................................73
14. Acknowledgements and Contributions ............................74
15. References ....................................................74
15.1. Normative References .....................................74
15.2. Informative References ...................................76
Appendix A. Pseudo-Random Number Generator .......................77
9.7. 別名EAP-要求/Reauthentication…50 9.8. 別名EAP-応答/Reauthentication…51 9.9. 別名クライアントEAP-応答/誤り…52 9.10. 別名EAP-要求/通知…52 9.11. 別名EAP-応答/通知…52 10. 属性…53 10.1. 属性のテーブル…53 10.2. __永久的な_ID REQで…54 10.3. __どんな_ID REQでも…54 10.4. __FULLAUTH_ID REQで…54 10.5. _アイデンティティで…55 10.6. _底ならし革で…55 10.7. _AUTNで…56 10.8. _RESで…56 10.9. _AUTSで…57 10.10. _次の_匿名で…57 10.11. _次の_REAUTH_IDで…58 10.12. _IVにおいて_ENCR_データにおいて_詰め物において…58 10.13. _CHECKCODEで…60 10.14. _結果_インディアン座で…62 10.15. _Macで…63 10.16. _では、反対してください…64 10.17. _では、__あまりに小さく反対してください…64 10.18. _一回だけ_Sで…65 10.19. _通知で…65 10.20. _クライアント_誤り_コードで…66 11. 問題に付番するIANAとプロトコル…66 12. セキュリティ問題…68 12.1. アイデンティティ保護…69 12.2. 互いの認証…69 12.3. 認証センターをあふれさせます…69 12.4. キー派生…70 12.5. ブルートフォースと辞書攻撃…70 12.6. 保護、反復操作による保護、および秘密性…70 12.7. 交渉は攻撃されます…71 12.8. 結果指摘を保護します…72 12.9. 中央の男性は攻撃します…72 12.10. 乱数を生成します…73 13. セキュリティクレーム…73 14. 承認と貢献…74 15. 参照…74 15.1. 標準の参照…74 15.2. 有益な参照…76 付録A.疑似乱数生成器…77
Arkko & Haverinen Informational [Page 3] RFC 4187 EAP-AKA Authentication January 2006
[3ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
1. Introduction and Motivation
1. 序論と動機
This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the 3rd generation Authentication and Key Agreement mechanism, specified for Universal Mobile Telecommunications System (UMTS) in [TS33.102] and for CDMA2000 in [S.S0055-A]. UMTS and CDMA2000 are global 3rd generation mobile network standards that use the same AKA mechanism.
このドキュメントは認証と[TS33.102]のUniversalのモバイルTelecommunications System(UMTS)と[S. S0055-A]のCDMA2000に指定された3番目の世代AuthenticationとKey Agreementメカニズムを使用するセッションの主要な分配に拡張認証プロトコル(EAP)メカニズムを指定します。 UMTSとCDMA2000は同じAKAメカニズムを使用する3番目のグローバルな世代モバイルネットワーク規格です。
2nd generation mobile networks and 3rd generation mobile networks use different authentication and key agreement mechanisms. The Global System for Mobile communications (GSM) is a 2nd generation mobile network standard, and EAP-SIM [EAP-SIM] specifies an EAP mechanism that is based on the GSM authentication and key agreement primitives.
モバイルネットワークと3番目の世代の2番目の世代モバイルネットワークは異なった認証と主要な協定メカニズムを使用します。モバイルコミュニケーション(GSM)のためのGlobal Systemは2番目の世代モバイルネットワーク規格です、そして、EAP-SIM[EAP-SIM]はGSM認証と主要な協定基関数に基づいているEAPメカニズムを指定します。
AKA is based on challenge-response mechanisms and symmetric cryptography. AKA typically runs in a UMTS Subscriber Identity Module (USIM) or a CDMA2000 (Removable) User Identity Module ((R)UIM). In this document, both modules are referred to as identity modules. Compared to the 2nd generation mechanisms such as GSM AKA, the 3rd generation AKA provides substantially longer key lengths and mutual authentication.
AKAはチャレンジレスポンスメカニズムと左右対称の暗号に基づいています。 AKA、通常UMTS加入者識別モジュール(USIM)かCDMA2000の(移動可能)のユーザIdentity Module((R)UIMでの走行) 本書では、両方のモジュールはアイデンティティモジュールと呼ばれます。 GSM AKAなどの2番目の世代メカニズムと比べて、3番目の世代AKAは実質的により長いキー長と互いの認証を提供します。
The introduction of AKA inside EAP allows several new applications. These include the following:
EAPの中のAKAの導入はいくつかの新しいアプリケーションを許容します。 これらは以下を含んでいます:
o The use of the AKA also as a secure PPP authentication method in
devices that already contain an identity module.
o The use of the 3rd generation mobile network authentication
infrastructure in the context of wireless LANs
o Relying on AKA and the existing infrastructure in a seamless way
with any other technology that can use EAP.
o aとしてもAKAの使用は、既にアイデンティティモジュールを含むデバイスにPPPが認証方法であることを固定します。○ AKAにおけるワイヤレスのLAN o Relyingの文脈における3番目の世代モバイルネットワーク認証インフラストラクチャの使用とシームレスのいかなる他の技術があるそうすることができる方法で既存のインフラストラクチャもEAPを使用します。
AKA works in the following manner:
AKAは以下の方法で働いています:
o The identity module and the home environment have agreed on a
secret key beforehand. (The "home environment" refers to the home
operator's authentication network infrastructure.)
o The actual authentication process starts by having the home
environment produce an authentication vector, based on the secret
key and a sequence number. The authentication vector contains a
random part RAND, an authenticator part AUTN used for
authenticating the network to the identity module, an expected
result part XRES, a 128-bit session key for integrity check IK,
and a 128-bit session key for encryption CK.
o アイデンティティモジュールと家庭環境はあらかじめ、秘密鍵に同意しました。 (「家庭環境」はホームのオペレータの認証ネットワークインフラを示します。) o 家庭環境に認証ベクトルを生産させることによって、実際の認証過程は始まります、秘密鍵と一連番号に基づいて。 認証ベクトルは無作為のパートRAND(AUTNがアイデンティティモジュール、予想された結果パートXRES、保全チェックIKに、主要な128ビットのセッション、および暗号化CKに、主要な128ビットのセッションまでネットワークを認証するのに使用した固有識別文字一部)を含んでいます。
Arkko & Haverinen Informational [Page 4] RFC 4187 EAP-AKA Authentication January 2006
[4ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
o The RAND and the AUTN are delivered to the identity module.
o The identity module verifies the AUTN, again based on the secret
key and the sequence number. If this process is successful (the
AUTN is valid and the sequence number used to generate AUTN is
within the correct range), the identity module produces an
authentication result RES and sends it to the home environment.
o The home environment verifies the correct result from the identity
module. If the result is correct, IK and CK can be used to
protect further communications between the identity module and the
home environment.
o RANDとAUTNはアイデンティティモジュールに提供されます。○ アイデンティティモジュールはAUTNについて確かめます、再び秘密鍵と一連番号に基づいて。 このプロセスがうまくいくなら(AUTNは有効です、そして、正しい範囲の中にAUTNを生成するのに使用される一連番号があります)、アイデンティティモジュールは、認証結果RESを生産して、それを家庭環境に送ります。○ 家庭環境はアイデンティティモジュールから正しい結果について確かめます。 結果が正しいなら、アイデンティティモジュールと家庭環境とのさらなるコミュニケーションを保護するのにIKとCKを使用できます。
When verifying AUTN, the identity module may detect that the sequence number the network uses is not within the correct range. In this case, the identity module calculates a sequence number synchronization parameter AUTS and sends it to the network. AKA authentication may then be retried with a new authentication vector generated using the synchronized sequence number.
AUTNについて確かめるアイデンティティモジュールがそれを検出するとき、正しい範囲の中にネットワークが使用する一連番号がありません。 この場合、アイデンティティモジュールは、一連番号同期パラメタAUTSについて計算して、それをネットワークに送ります。 そして、新しい認証ベクトルが生成されている状態で、AKA認証は、連動している一連番号を使用することで再試行されるかもしれません。
For a specification of the AKA mechanisms and how the cryptographic values AUTN, RES, IK, CK and AUTS are calculated, see [TS33.102] for UMTS and [S.S0055-A] for CDMA2000.
AKAメカニズムと暗号の値のAUTN、RES、IK、CK、およびAUTSがどう計算されるかに関する仕様に関しては、UMTSと[S. S0055-A]に関してCDMA2000に関して[TS33.102]を見てください。
In EAP-AKA, the EAP server node obtains the authentication vectors, compares RES and XRES, and uses CK and IK in key derivation.
EAP-AKAでは、EAPサーバノードは、認証ベクトルを得て、RESとXRESを比較して、主要な派生にCKとIKを使用します。
In the 3rd generation mobile networks, AKA is used for both radio network authentication and IP multimedia service authentication purposes. Different user identities and formats are used for these; the radio network uses the International Mobile Subscriber Identifier (IMSI), whereas the IP multimedia service uses the Network Access Identifier (NAI) [RFC4282].
3番目の世代モバイルネットワークでは、AKAはラジオ放送網認証とIPマルチメディアサービス認証目的の両方に使用されます。 異なったユーザアイデンティティと形式はこれらに使用されます。 ラジオ放送網は国際モバイルSubscriber Identifier(IMSI)を使用しますが、IPマルチメディアサービスはNetwork Access Identifier(NAI)[RFC4282]を使用します。
2. Terms and Conventions Used in This Document
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]で説明されるように解釈されることになっています。
This document frequently uses the following terms and abbreviations. The AKA parameters are specified in detail in [TS33.102] for UMTS and [S.S0055-A] for CDMA2000.
このドキュメントは頻繁に以下の用語と略語を使用します。 AKAパラメタはCDMA2000として[TS33.102]で詳細にUMTSと[S. S0055-A]に指定されます。
Arkko & Haverinen Informational [Page 5] RFC 4187 EAP-AKA Authentication January 2006
[5ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
AAA protocol
AAAプロトコル
Authentication, Authorization and Accounting protocol
認証、Authorization、およびAccountingは議定書を作ります。
AKA
別名
Authentication and Key Agreement
認証と主要な協定
AuC
AuC
Authentication Centre. The mobile network element that can
authenticate subscribers in the mobile networks.
認証センター。 モバイルネットワークで加入者を認証できるモバイルネットワーク要素。
AUTN
AUTN
AKA parameter. AUTN is an authentication value generated by
the AuC, which, together with the RAND, authenticates the
server to the peer, 128 bits.
AKAパラメタ。 AUTNはRANDと共に同輩(128ビット)にサーバを認証するAuCによって生成された認証値です。
AUTS
AUTS
AKA parameter. A value generated by the peer upon
experiencing a synchronization failure, 112 bits.
AKAパラメタ。 同期失敗を経験するときの112ビットの同輩によって生成された値。
EAP
EAP
Extensible Authentication Protocol [RFC3748]
拡張認証プロトコル[RFC3748]
Fast Re-Authentication
速い再認証
An EAP-AKA authentication exchange that is based on keys
derived upon a preceding full authentication exchange. The
3rd Generation AKA is not used in the fast re-authentication
procedure.
前の完全な認証交換のときに引き出されたキーに基づいているEAP-AKA認証交換。 第3Generation AKAは速い再認証手順で使用されません。
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 re-authentication only.
分野が使用されている環境にNAI分野の部分を含む同輩の速い再認証のアイデンティティ。 再認証だけのときに、使用されています。
Fast Re-Authentication Username
速い再認証ユーザ名
The username portion of fast re-authentication identity,
i.e., not including any realm portions.
速い再認証のアイデンティティのユーザ名部分、すなわち、どんな分野の部分も含んでいないこと。
Arkko & Haverinen Informational [Page 6] RFC 4187 EAP-AKA Authentication January 2006
[6ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
Full Authentication
完全な認証
An EAP-AKA authentication exchange that is based on the
3rd Generation AKA procedure.
3番目のGeneration AKA手順に基づいているEAP-AKA認証交換。
GSM
GSM
Global System for Mobile communications.
モバイルコミュニケーションのためのグローバルなSystem。
NAI
NAI
Network Access Identifier [RFC4282]
ネットワークアクセス識別子[RFC4282]
Identity Module
アイデンティティモジュール
Identity module is used in this document to refer to the
part of the mobile device that contains authentication and
key agreement primitives. The identity module may be an
integral part of the mobile device or it may be an application
on a smart card distributed by a mobile operator. USIM and
(R)UIM are identity modules.
アイデンティティモジュールは、認証と主要な協定基関数を含むモバイル機器の部分について言及するのに本書では使用されます。 アイデンティティモジュールはモバイル機器の不可欠の部分であるかもしれませんかそれが携帯電話会社によって分配されたスマートカードにおけるアプリケーションであるかもしれません。 USIMと(R)UIMはアイデンティティモジュールです。
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). Because 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.
永久的なアイデンティティのユーザ名部分、すなわち、どんな分野の部分も含んでいないこと。
Arkko & Haverinen Informational [Page 7] RFC 4187 EAP-AKA Authentication January 2006
[7ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
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分野の部分を含む同輩の匿名のアイデンティティ。 完全な認証だけのときに、使用されています。
Pseudonym Username
匿名ユーザ名
The username portion of pseudonym identity, i.e., not including
any realm portions.
匿名のアイデンティティのユーザ名部分、すなわち、どんな分野の部分も含んでいないこと。
RAND
底ならし革
An AKA parameter. Random number generated by the AuC,
128 bits.
AKAパラメタ。 AuCによって生成された乱数、128ビット。
RES
RES
Authentication result from the peer, which, together with
the RAND, authenticates the peer to the server,
128 bits.
同輩からの認証結果。(その同輩は、RANDと共に128ビットのサーバへの同輩を認証します)。
(R)UIM
(R) UIM
CDMA2000 (Removable) User Identity Module. (R)UIM is an
application that is resident on devices such as smart cards,
which may be fixed in the terminal or distributed by CDMA2000
operators (when removable).
CDMA2000の(移動可能)の加入者情報モジュール。 (R)UIMは端末で修理されているか、またはCDMA2000オペレータによって分配されるかもしれないスマートカードなどのデバイスで居住しているアプリケーション(移動可能であるときに)です。
SQN
SQN
An AKA parameter. Sequence number used in the authentication
process, 48 bits.
AKAパラメタ。 一連番号は認証過程、48にビットを使用しました。
SIM
SIM
Subscriber Identity Module. The SIM is traditionally a smart
card distributed by a GSM operator.
加入者識別モジュール。 SIMは伝統的にGSMオペレータによって分配されたスマートカードです。
SRES
SRES
The authentication result parameter in GSM, corresponds to
the RES parameter in 3G AKA, 32 bits.
GSMの認証結果パラメタ、3G AKA、32ビットのRESパラメタに対応しています。
Arkko & Haverinen Informational [Page 8] RFC 4187 EAP-AKA Authentication January 2006
[8ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
UAK
UAK
UIM Authentication Key, used in CDMA2000 AKA. Both the
identity module and the network can optionally generate the UAK
during the AKA computation in CDMA2000. UAK is not used in
this version of EAP-AKA.
CDMA2000 AKAで使用されるUIM Authentication Key。 アイデンティティモジュールとネットワークの両方がAKA計算の間、CDMA2000で任意にUAKを生成することができます。 UAKはEAP-AKAのこのバージョンで使用されません。
UIM
UIM
Please see (R)UIM.
(R) UIMを見てください。
USIM
USIM
UMTS Subscriber Identity Module. USIM is an application that
is resident on devices such as smart cards distributed by UMTS
operators.
UMTS加入者識別モジュール。 USIMはUMTSオペレータによって分配されたスマートカードなどのデバイスで居住しているアプリケーションです。
3. Protocol Overview
3. プロトコル概要
Figure 1 shows the basic, successful full authentication exchange in EAP-AKA, when optional result 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. At the minimum, EAP-AKA uses two roundtrips to authenticate and authorize the peer and generate session keys. As in other EAP schemes, an identity request/response message pair is usually exchanged first. On full authentication, the peer's identity 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.1. (As specified in [RFC3748], the initial identity request is not required, and MAY be bypassed in cases where the network can presume the identity, such as when using leased lines, dedicated dial-ups, etc. Please see Section 4.1.2 for specification of how to obtain the identity via EAP AKA messages.)
任意の結果指摘が使用されていないとき、図1はEAP-AKAの基本的で、うまくいっている完全な認証交換を示しています。 固有識別文字はバックエンド認証サーバにAAAプロトコルを使用することで位置しているEAPサーバと通常コミュニケートします。 図に示された固有識別文字は単にしばしばしかし、サーバとEAPサーバからのEAPメッセージ、これらをリレーすることですバックエンドAAAコミュニケーションが示されない。 最小限では、EAP-AKAは、同輩を認証して、権限を与えて、セッションキーを生成するのに2つの往復旅行を使用します。 他のEAP体系のように、通常、最初に、アイデンティティ要求/応答メッセージ組を交換します。 完全な認証のときに、アイデンティティプライバシーが有効であるなら、同輩のアイデンティティ応答はユーザの移動加入者識別番号(IMSI)か一時的なアイデンティティ(匿名)のどちらかを含んでいます、セクション4.1で指定されるように。 ([RFC3748]で指定されていて、初期のアイデンティティ要求が必要でなく、ネットワークが専用線、ひたむきなダイヤルアップなどを使用することでいつなどのアイデンティティを推定できる場合で迂回するとき EAP AKAメッセージでどうアイデンティティを得るかに関する仕様に関してセクション4.1.2を見てください。)
After obtaining the subscriber identity, the EAP server obtains an authentication vector (RAND, AUTN, RES, CK, IK) for use in authenticating the subscriber. From the vector, the EAP server derives the keying material, as specified in Section 6.4. The vector may be obtained by contacting an Authentication Centre (AuC) on the mobile network; for example, per UMTS specifications, several vectors may be obtained at a time. Vectors may be stored in the EAP server for use at a later time, but they may not be reused.
加入者のアイデンティティを得た後に、EAPサーバは認証ベクトル(RAND、AUTN、RES、CK、IK)を加入者を認証することにおける使用として得ます。 ベクトルから、EAPサーバはセクション6.4で指定されるように合わせることの材料を誘導します。 Authentication Centre(AuC)にモバイルネットワークへ連絡することによって、ベクトルを得るかもしれません。 例えば、UMTS仕様に従って、一度に、いくつかのベクトルを得るかもしれません。 後で、ベクトルは使用のためのEAPサーバで保存されるかもしれませんが、それらは再利用されないかもしれません。
Arkko & Haverinen Informational [Page 9] RFC 4187 EAP-AKA Authentication January 2006
[9ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
In CDMA2000, the vector may include a sixth value called the User Identity Module Authentication Key (UAK). This key is not used in EAP-AKA.
CDMA2000では、ベクトルはUser Identity Module Authentication Key(UAK)と呼ばれる6番目の値を含むかもしれません。 このキーはEAP-AKAで使用されません。
Next, the EAP server starts the actual AKA protocol by sending an EAP-Request/AKA-Challenge message. EAP-AKA 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. The EAP-Request/AKA-Challenge message contains a RAND random number (AT_RAND), a network authentication token (AT_AUTN), and a message authentication code (AT_MAC). The EAP-Request/ AKA-Challenge message MAY optionally contain encrypted data, which is used for identity privacy and fast re-authentication support, as described in Section 4.1. The AT_MAC attribute contains a message authentication code covering the EAP packet. The encrypted data is not shown in the figures of this section.
次に、EAPサーバは、AKA EAP-要求/挑戦メッセージを送ることによって、実際のAKAプロトコルを始めます。 EAP-AKAパケットはType、Length、Value形式でコード化された属性におけるパラメタをカプセル化します。 パケット・フォーマットと属性の使用はセクション8で指定されます。 AKA EAP-要求/挑戦メッセージはRANDを含んでいます。乱数(AT_RAND)、ネットワーク認証トークン(AT_AUTN)、および通報認証は(AT_MAC)をコード化します。 AKA EAP-要求/挑戦メッセージは任意に、暗号化されたデータを含むかもしれません、セクション4.1で説明されるように。(データはアイデンティティプライバシーと速い再認証サポートに使用されます)。 AT_MAC属性はEAPパケットをカバーするメッセージ確認コードを含んでいます。 暗号化されたデータはこのセクションの数字に示されません。
The peer runs the AKA algorithm (typically using an identity module) and verifies the AUTN. If this is successful, the peer is talking to a legitimate EAP server and proceeds to send the EAP-Response/ AKA-Challenge. This message contains a result parameter that allows the EAP server, in turn, to authenticate the peer, and the AT_MAC attribute to integrity protect the EAP message.
同輩は、AKAアルゴリズム(アイデンティティモジュールを通常使用する)を実行して、AUTNについて確かめます。 これがうまくいくなら、同輩は、正統のEAPサーバと話していて、AKA EAP-応答/挑戦を送りかけます。 このメッセージは同輩を認証するために順番にEAPサーバを許容する結果パラメタを含んでいます、そして、_MACが保全の結果と考えるATはEAPメッセージを保護します。
The EAP server verifies that the RES and the MAC in the EAP-Response/ AKA-Challenge packet are 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サーバは、AKA EAP-応答/挑戦パケットのRESとMACが正しいことを確かめます。 保護された成功指摘がこの例で使用されないので、EAPサーバはEAP-成功パケットを送ります、認証がうまくいったのを示して。 (セクション6.2で保護された成功指摘について議論します。) また、EAPサーバはそれが固有識別文字に送るメッセージに誘導合わせることの材料を含むかもしれません。 同輩が材料を合わせながら同じくらい引き出したので、固有識別文字はEAP-成功に伴う同輩に合わせることの材料を送りません。
Arkko & Haverinen Informational [Page 10] RFC 4187 EAP-AKA Authentication January 2006
[10ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
Peer Authenticator
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes user's NAI) |
|------------------------------------------------------>|
| +------------------------------+
| | Server runs AKA algorithms, |
| | generates RAND and AUTN. |
| +------------------------------+
| EAP-Request/AKA-Challenge |
| (AT_RAND, AT_AUTN, AT_MAC) |
|<------------------------------------------------------|
+-------------------------------------+ |
| Peer runs AKA algorithms, | |
| verifies AUTN and MAC, derives RES | |
| and session key | |
+-------------------------------------+ |
| EAP-Response/AKA-Challenge |
| (AT_RES, AT_MAC) |
|------------------------------------------------------>|
| +--------------------------------+
| | Server checks the given RES, |
| | and MAC and finds them correct.|
| +--------------------------------+
| EAP-Success |
|<------------------------------------------------------|
同輩固有識別文字| EAP-要求/アイデンティティ| |<------------------------------------------------------| | | | EAP-応答/アイデンティティ| | (ユーザのNAIを含んでいます) | |------------------------------------------------------>| | +------------------------------+ | | サーバはAKAアルゴリズムを実行します。| | | RANDとAUTNを生成します。 | | +------------------------------+ | 別名EAP-要求/挑戦| | (__底ならし革、_AUTN、Macの) | |<------------------------------------------------------| +-------------------------------------+ | | 同輩はAKAアルゴリズムを実行します。| | | AUTNとMACについて確かめて、RESを引き出します。| | | そして、セッションキー| | +-------------------------------------+ | | 別名EAP-応答/挑戦| | (__RES、Macの) | |------------------------------------------------------>| | +--------------------------------+ | | サーバは与えられたRESをチェックします。| | | そして、MAC、それらが正しいのがわかる、|| +--------------------------------+ | EAP-成功| |<------------------------------------------------------|
Figure 1: EAP-AKA full authentication procedure
図1: EAP-AKAの完全な認証手順
Arkko & Haverinen Informational [Page 11] RFC 4187 EAP-AKA Authentication January 2006
[11ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
Figure 2 shows how the EAP server rejects the Peer due to a failed authentication.
図2はEAPサーバが失敗した認証のためどうPeerを拒絶するかを示しています。
Peer Authenticator
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes user's NAI) |
|------------------------------------------------------>|
| +------------------------------+
| | Server runs AKA algorithms, |
| | generates RAND and AUTN. |
| +------------------------------+
| EAP-Request/AKA-Challenge |
| (AT_RAND, AT_AUTN, AT_MAC) |
|<------------------------------------------------------|
+-------------------------------------+ |
| Peer runs AKA algorithms, | |
| possibly verifies AUTN, and sends an| |
| invalid response | |
+-------------------------------------+ |
| EAP-Response/AKA-Challenge |
| (AT_RES, AT_MAC) |
|------------------------------------------------------>|
| +------------------------------------------+
| | Server checks the given RES and the MAC, |
| | and finds one of them incorrect. |
| +------------------------------------------+
| EAP-Request/AKA-Notification |
|<------------------------------------------------------|
| EAP-Response/AKA-Notification |
|------------------------------------------------------>|
| EAP-Failure |
|<------------------------------------------------------|
同輩固有識別文字| EAP-要求/アイデンティティ| |<------------------------------------------------------| | | | EAP-応答/アイデンティティ| | (ユーザのNAIを含んでいます) | |------------------------------------------------------>| | +------------------------------+ | | サーバはAKAアルゴリズムを実行します。| | | RANDとAUTNを生成します。 | | +------------------------------+ | 別名EAP-要求/挑戦| | (__底ならし革、_AUTN、Macの) | |<------------------------------------------------------| +-------------------------------------+ | | 同輩はAKAアルゴリズムを実行します。| | | ことによるとAUTNについて確かめて、発信します。| | | 無効回答| | +-------------------------------------+ | | 別名EAP-応答/挑戦| | (__RES、Macの) | |------------------------------------------------------>| | +------------------------------------------+ | | サーバは与えられたRESとMACをチェックします。| | | そして、それらの1つが不正確である掘り出し物。 | | +------------------------------------------+ | 別名EAP-要求/通知| |<------------------------------------------------------| | 別名EAP-応答/通知| |------------------------------------------------------>| | EAP-失敗| |<------------------------------------------------------|
Figure 2: Peer authentication fails
図2: 同輩認証は失敗します。
Arkko & Haverinen Informational [Page 12] RFC 4187 EAP-AKA Authentication January 2006
[12ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
Figure 3 shows the peer rejecting the AUTN of the EAP server.
図3は、同輩がEAPサーバのAUTNを拒絶するのを示します。
The peer sends an explicit error message (EAP-Response/ AKA-Authentication-Reject) to the EAP server, as usual in AKA when AUTN is incorrect. This allows the EAP server to produce the same error statistics that AKA generally produces in UMTS or CDMA2000.
同輩は明白なエラーメッセージ(AKA認証EAP-応答/廃棄物)をEAPサーバに送ります、AKAでは、AUTNが不正確であると、通常通りです。 これで、EAPサーバは一般に、AKAがUMTSかCDMA2000で作成するのと同じ誤り統計を作成できます。
Peer Authenticator
| EAP-Request/Identity |
|<------------------------------------------------------|
| EAP-Response/Identity |
| (Includes user's NAI) |
|------------------------------------------------------>|
| +------------------------------+
| | Server runs AKA algorithms, |
| | generates RAND and a bad AUTN|
| +------------------------------+
| EAP-Request/AKA-Challenge |
| (AT_RAND, AT_AUTN, AT_MAC) |
|<------------------------------------------------------|
+-------------------------------------+ |
| Peer runs AKA algorithms | |
| and discovers AUTN that can not be | |
| verified | |
+-------------------------------------+ |
| EAP-Response/AKA-Authentication-Reject |
|------------------------------------------------------>|
| EAP-Failure |
|<------------------------------------------------------|
同輩固有識別文字| EAP-要求/アイデンティティ| |<------------------------------------------------------| | EAP-応答/アイデンティティ| | (ユーザのNAIを含んでいます) | |------------------------------------------------------>| | +------------------------------+ | | サーバはAKAアルゴリズムを実行します。| | | RANDと悪いAUTNを生成します。| | +------------------------------+ | 別名EAP-要求/挑戦| | (__底ならし革、_AUTN、Macの) | |<------------------------------------------------------| +-------------------------------------+ | | 同輩はAKAアルゴリズムを実行します。| | | そうすることができないAUTNを発見します。| | | 確かめられます。| | +-------------------------------------+ | | 別名認証EAP-応答/廃棄物| |------------------------------------------------------>| | EAP-失敗| |<------------------------------------------------------|
Figure 3: Network authentication fails
図3: ネットワーク認証は失敗します。
The AKA uses shared secrets between the Peer and the Peer's home operator, together with a sequence number, to actually perform an authentication. In certain circumstances, shown in Figure 4, it is possible for the sequence numbers to get out of sequence.
AKAは、実際に認証を実行するのに一連番号と共にPeerとPeerのホームのオペレータの間の共有秘密キーを使用します。 図4のある事情では、一連番号が系列を出るのは、可能です。
Arkko & Haverinen Informational [Page 13] RFC 4187 EAP-AKA Authentication January 2006
[13ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
Peer Authenticator
| EAP-Request/Identity |
|<------------------------------------------------------|
| EAP-Response/Identity |
| (Includes user's NAI) |
|------------------------------------------------------>|
| +------------------------------+
| | Server runs AKA algorithms, |
| | generates RAND and AUTN. |
| +------------------------------+
| EAP-Request/AKA-Challenge |
| (AT_RAND, AT_AUTN, AT_MAC) |
|<------------------------------------------------------|
+-------------------------------------+ |
| Peer runs AKA algorithms | |
| and discovers AUTN that contains an | |
| inappropriate sequence number | |
+-------------------------------------+ |
| EAP-Response/AKA-Synchronization-Failure |
| (AT_AUTS) |
|------------------------------------------------------>|
| +---------------------------+
| | Perform resynchronization |
| | Using AUTS and |
| | the sent RAND |
| +---------------------------+
| |
同輩固有識別文字| EAP-要求/アイデンティティ| |<------------------------------------------------------| | EAP-応答/アイデンティティ| | (ユーザのNAIを含んでいます) | |------------------------------------------------------>| | +------------------------------+ | | サーバはAKAアルゴリズムを実行します。| | | RANDとAUTNを生成します。 | | +------------------------------+ | 別名EAP-要求/挑戦| | (__底ならし革、_AUTN、Macの) | |<------------------------------------------------------| +-------------------------------------+ | | 同輩はAKAアルゴリズムを実行します。| | | AUTNを発見する、それは含んでいます。| | | 不適当な一連番号| | +-------------------------------------+ | | 別名同期EAP-応答/失敗| | (_AUTSの) | |------------------------------------------------------>| | +---------------------------+ | | 再同期を実行してください。| | | そしてAUTSを使用する。| | | 送られたRAND| | +---------------------------+ | |
Figure 4: Sequence number synchronization
図4: 一連番号同期
After the resynchronization process has taken place in the server and AAA side, the process continues by the server side sending a new EAP-Request/AKA-Challenge message.
再同期プロセスがサーバとAAA側で行われた後に、プロセスはAKA新しいEAP-要求/挑戦メッセージを送るサーバ側のそばで持続します。
In addition to the full authentication scenarios described above, EAP-AKA includes a fast re-authentication procedure, which is specified in Section 5. Fast re-authentication is based on keys derived on full authentication. If the peer has maintained state information for 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.
上で説明された完全な認証シナリオに加えて、EAP-AKAは速い再認証手順を含んでいます。(それは、セクション5で指定されます)。 速い再認証は完全な認証のときに引き出されたキーに基づいています。 同輩が再認証のための州の情報を保守して、速い再認証を使用したいと思うなら、同輩は、永久的なアイデンティティか匿名のアイデンティティの代わりに特定の速い再認証のアイデンティティを使用することによって、これを示します。
Arkko & Haverinen Informational [Page 14] RFC 4187 EAP-AKA Authentication January 2006
[14ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
4. Operation
4. 操作
4.1. Identity Management
4.1. アイデンティティ管理
4.1.1. Format, Generation, and Usage of Peer Identities
4.1.1. 同輩のアイデンティティの形式、世代、および用法
4.1.1.1. General
4.1.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 EAP-Response/Identity, which contains the user's identity. The formats of these packets are specified in [RFC3748].
初めに、EAP認証では、通常、AuthenticatorかEAPサーバがEAP-要求/アイデンティティパケットを同輩に発行します。 同輩はEAP-応答/アイデンティティで応じます。(それは、ユーザのアイデンティティを含みます)。 これらのパケットの形式は[RFC3748]で指定されます。
Subscribers of mobile networks are identified with the International Mobile Subscriber Identity (IMSI) [TS23.003]. The IMSI is a string of not more than 15 digits. It is composed of a Mobile Country Code (MCC) of 3 digits, a Mobile Network Code (MNC) of 2 or 3 digits, and a Mobile Subscriber Identification Number (MSIN) of not 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.
モバイルネットワークの加入者は移動加入者識別番号(IMSI)[TS23.003]と同一視されています。 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-AKA. In this document, the term identity or peer identity refers to the whole identity string that is used to identify the peer. The peer identity may include a realm portion. "Username" refers to the portion of the peer identity that identifies the user, i.e., the username does not include the realm portion.
このセクションはEAP-AKAで使用される同輩アイデンティティ形式を指定します。 本書では、用語のアイデンティティか同輩のアイデンティティが同輩を特定するのに使用される全体のアイデンティティストリングについて言及します。 同輩のアイデンティティは分野の部分を含むかもしれません。 「ユーザ名」はユーザを特定する同輩のアイデンティティの部分を示します、すなわち、ユーザ名が分野の部分を含んでいません。
4.1.1.2. Identity Privacy Support
4.1.1.2. アイデンティティプライバシーサポート
EAP-AKA 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
EAP-AKAはcleartextの永久的なアイデンティティを隠して、その結果、加入者のEAP交換を立ち聞きする者にとって追跡不可能にするのに使用できる任意のアイデンティティプライバシー(匿名)サポートを含んでいます。 永久的なアイデンティティが決して変化しないので、それを明らかにするのは、観察者がユーザを追跡するのを助けるでしょう。 通常、永久的なアイデンティティはIMSIに基づいています、同じ識別子がまた、他の文脈で使用されるかもしれないので。(さらに、IMSIは追跡を助けるかもしれません)。 アイデンティティプライバシーは同等な一時的なアイデンティティ、または匿名に基づいています。
Arkko & Haverinen Informational [Page 15] RFC 4187 EAP-AKA Authentication January 2006
[15ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
to but separate from the Temporary Mobile Subscriber Identities (TMSI) that are used on cellular networks. Please see Section 12.1 for security considerations regarding identity privacy.
しかし、セルラー・ネットワークで使用されるTemporaryのモバイルSubscriber Identities(TMSI)から、別々です。 アイデンティティプライバシーに関するセキュリティ問題に関してセクション12.1を見てください。
4.1.1.3. Username Types in EAP-AKA Identities
4.1.1.3. EAP-別名のアイデンティティにおけるユーザ名タイプ
There are three types of usernames in EAP-AKA peer identities:
EAP-AKA同輩のアイデンティティには3つのタイプに関するユーザ名があります:
(1) Permanent usernames. For example, 0123456789098765@myoperator.com might be a valid permanent identity. In this example, 0123456789098765 is the permanent username.
(1) 永久的なユーザ名。 例えば、 0123456789098765@myoperator.com は有効な永久的なアイデンティティであるかもしれません。 この例では、0123456789098765は永久的なユーザ名です。
(2) Pseudonym usernames. For example, 2s7ah6n9q@myoperator.com might be a valid pseudonym identity. In this example, 2s7ah6n9q is the pseudonym username.
(2) 匿名ユーザ名。 例えば、 2s7ah6n9q@myoperator.com は有効な匿名のアイデンティティであるかもしれません。 この例では、2s7ah6n9qは匿名ユーザ名です。
(3) Fast re-authentication usernames. For example, 43953754@myoperator.com might be a valid fast re-authentication identity. In this case, 43953754 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) 速い再認証ユーザ名。 例えば、 43953754@myoperator.com は有効な速い再認証のアイデンティティであるかもしれません。 この場合、43953754は速い再認証ユーザ名です。 永久的なユーザ名と匿名ユーザ名と異なって、速い再認証ユーザ名は1回の識別子です。(その識別子はEAP交換の向こう側に再使用されません)。
The first two types of identities are used only on full authentication, and the last type 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.1.1.4. Username Decoration
4.1.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 realm. (The usage of an NAI realm portion is not considered to be 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-AKA attributes. Only the identity used in EAP-Response/Identity may be decorated.
いくつかの環境で、同輩は、ひもでユーザ名をprependingするか、または追加することによってアイデンティティに飾り付けをする必要があるかもしれません、NAI分野に加えて補っているAAAルーティング情報を示すために。 (NAI分野の部分の用法はデコレーションであると考えられません。) このドキュメントの範囲の外にユーザ名デコレーションがあります。 しかしながら、ユーザ名デコレーションが、サーバが有効なユーザ名を認識するのを防ぐかもしれないことに注意されるべきです。 したがって、同輩は同輩がEAP-応答/アイデンティティに含んでいるアイデンティティにユーザ名デコレーションを使用するかもしれません、そして、EAPサーバはこのメッセージで飾り付けをされた同輩ユーザ名を受け入れるかもしれませんが、同輩かEAPサーバが様々なEAP-AKA属性に使用されるいかなる他の同輩のアイデンティティにも飾り付けをしてはいけません。 EAP-応答/アイデンティティに使用されるアイデンティティだけに飾り付けをしてもよいです。
Arkko & Haverinen Informational [Page 16] RFC 4187 EAP-AKA Authentication January 2006
[16ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
4.1.1.5. NAI Realm Portion
4.1.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-AKA 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-AKA users. This convention makes it easy to recognize that the NAI identifies an AKA subscriber. Such a reserved NAI realm may be useful as a hint of 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 to how it selects the realm portion when using the permanent username.
分野が使用されているなら、分野は加入者のホームのオペレータによって選ばれるかもしれません、そして、それはEAP-AKA同輩実装で構成可能なパラメタであるかもしれません。 この場合、同輩はホームのオペレータのNAI分野によって通常構成されます。 オペレータはEAP-AKAユーザのために特定の分野名を予約するかもしれません。 このコンベンションはNAIがAKA加入者を特定すると認めるのを簡単にします。 そのような予約された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, will be specified in [TS23.003].
どんな構成された分野名も利用可能でないなら、同輩が分野名にIMSIのMCCとMNC部分に由来しているかもしれません。 分野3gppnetwork.orgを使用して、IMSIから分野を得るRECOMMENDED方法は[TS23.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 [TS23.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の代わりに[TS23.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 MSIN. Hence, when configuring AAA networks for operators that have 2-digit MNC's, the network SHOULD also be prepared for realm names with incorrect 3-digit MNC's.
同輩は、IMSIが少しも明白な構造がなければ一連のケタであるので、MNC部分の長さを測定できないかもしれません。 同輩が、長い間、MNCが2ケタかそれとも3ケタであるかどうか決定できないなら、同輩は3ケタのMNCを使用するかもしれません。 MNCの適度の長さが2であるなら、MNCは包含という分野名にMSINの最初のケタを使用しました。 したがって、また、2ケタのMNCのもの、ネットワークSHOULDを持っているオペレータのためにAAAネットワークを構成するのが、いつかが不正確なMNCの3ケタのものの分野名の用意をしました。
4.1.1.6. Format of the Permanent Username
4.1.1.6. 永久的なユーザ名の形式
The non-pseudonym permanent username SHOULD be derived from the IMSI. In this case, the permanent username MUST be of the format "0" | IMSI, where the character "|" denotes concatenation. In other words, the first character of the username is the digit zero (ASCII value 30 hexadecimal), followed by the IMSI. The IMSI is an ASCII string that consists of not more than 15 decimal digits (ASCII values between 30
非匿名の永久的なユーザ名SHOULD、IMSIから、派生してください。 この場合、永久的なユーザ名は「0インチ」形式のものであるに違いありません。| 「IMSI、どこ、キャラクタ、」|「連結を指示します。」 言い換えれば、ユーザ名の最初のキャラクタはケタゼロです(ASCIIは30 16進を評価します)、IMSIによって続かれて。 IMSIが15以上の10進数字でないのから成るASCIIストリングである、(ASCIIは間に30を評価します。
Arkko & Haverinen Informational [Page 17] RFC 4187 EAP-AKA Authentication January 2006
[17ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
and 39 hexadecimal), one character per IMSI digit, in the order as specified in [TS23.003]. For example, a permanent username derived from the IMSI 295023820005424 would be encoded as the ASCII string "0295023820005424" (byte values in hexadecimal notation: 30 32 39 35 30 32 33 38 32 30 30 30 35 34 32 34)
39 16進)、[TS23.003]の指定されるとしてのオーダーにおけるIMSIケタあたり1つのキャラクタ。 例えば、IMSI295023820005424から得られた永久的なユーザ名はASCIIストリング「0295023820005424」としてコード化されるでしょう。(16進法: 30 32 39 35 30 32 33 38 32 30 30 30 35 34 32 34におけるバイト値)
The EAP server MAY use the leading "0" as a hint to try EAP-AKA as the first authentication method during method negotiation, rather than using, for example, EAP-SIM. The EAP-AKA server MAY propose EAP-AKA even if the leading character was not "0".
EAPサーバは主な「メソッド交渉の間に例えばEAP-シムを使用するより最初の認証方法としてむしろEAP-別名を試みるヒントとしての0インチ」を使用するかもしれません。 EAP-AKAサーバは主人公が「0インチ」でなかったとしても、EAP-AKAを提案するかもしれません。
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.1.1.7. Generating Pseudonyms and Fast Re-Authentication Identities by
the Server
4.1.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-AKA 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 peer to send the permanent identity.
EAP-AKAは、匿名ユーザ名が認証交換のときに使用されているとき、匿名ユーザ名を生成したのと同じEAPサーバが使用されるのを保証するために条項を全く含んでいません。 サーバがホームのオペレータのすべてのEAPサーバが他によって生成された匿名を写像するのを許容するために何らかの集結されたメカニズムを実装するEAPが永久的なアイデンティティに切れるのは、お勧めです。 そのような何かメカニズムが利用可能でないなら、別のサーバによって発行された匿名を理解していなくて、EAPサーバは、永久的なアイデンティティを送るよう同輩に要求できます。
When issuing a fast re-authentication identity, the EAP server may include a realm name in the identity that will cause the fast re-authentication request to 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. The random component
再認証がアイデンティティであると速く生成するとき、サーバSHOULDは同じ完全な認証交換の後に使用された前のものと異なった新鮮で、新しい速い再認証のアイデンティティを選びます。 完全な認証交換と関連速い再認証交換は同じ「完全な認証関係」としてここと呼ばれます。 速い再認証のアイデンティティSHOULDは無作為のコンポーネントを含んでいます。 無作為のコンポーネント
Arkko & Haverinen Informational [Page 18] RFC 4187 EAP-AKA Authentication January 2006
[18ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
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 the peer's fast re-authentication state information (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/AKA-Reauthentication packet.
完全な認証文脈識別子としての作品。 速い再認証州の情報が同輩の速い再認証州の情報に合っている(言い換えれば、州の情報が同じ完全な認証交換から来ているか否かに関係なく)か否かに関係なく、アイデンティティが、サーバが検出するのを助けることができる文脈の特定の速い再認証。 また、無作為のコンポーネントで速い再認証のアイデンティティが予測できるようにならないので、攻撃者はサーバのEAP-要求/AKA-Reauthenticationパケットを得るために速い再認証交換を起こすことができません。
Transmitting pseudonyms and fast re-authentication identities from the server to the peer is discussed in Section 4.1.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 in order to allow the server to include a server-specific realm.
セクション4.1.1で.8にサーバから同輩まで匿名と速い再認証のアイデンティティを伝えるのと議論します。 匿名はユーザ名としてNAI分野なしで伝えられます、そして、速い再認証のアイデンティティは完全なNAIとして伝えられます、分野が必要であるなら分野の部分を含んでいて。 分野は、サーバがサーバ特有の分野を含んでいるのを許容するために速い再認証のアイデンティティに含まれています。
Regardless of construction method, the pseudonym username MUST conform to the grammar specified for the username portion of an NAI. Also, the fast re-authentication identity 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 that 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 usernames be recognizable from each other as an aid to the server when deciding which method to offer.
どのような場合でも、永久的なユーザ名、匿名ユーザ名、および速い再認証ユーザ名が互いから別々であって、認識可能であることが必要です。 また、どのメソッドを提供したらよいかを決めるとき、EAP-SIMと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 recognize if an NAI username is an EAP-AKA pseudonym username or an EAP-AKA 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 "2" character). When mapping a fast re-authentication identity to a permanent identity, the server SHOULD only examine the username portion of the fast re-authentication identity and ignore the realm portion of the identity.
一般に、それは、EAPサーバに関するタスクとユーザ名の十分な分離を確実にする管理者の方針です。 匿名ユーザ名と速い再認証ユーザ名は、EAPサーバによって作り出されて、使用されます。EAPサーバは、NAIユーザ名がEAP-AKA匿名ユーザ名であるか、そして、EAP-AKAの速い再認証ユーザ名を認識できるように、匿名ユーザ名と速い再認証ユーザ名を構成しなければなりません。 例えば、IMSIからユーザ名を得たときサーバが匿名ユーザ名と速い再認証ユーザ名で異なった主人公を使用するかもしれない、(例えば匿名が先導で始まることができた、「2インチのキャラクタ)」 永久的なアイデンティティへの速い再認証のアイデンティティを写像するとき、サーバSHOULDは速い再認証のアイデンティティのユーザ名部分を調べるだけであり、アイデンティティの分野の部分を無視します。
Arkko & Haverinen Informational [Page 19] RFC 4187 EAP-AKA Authentication January 2006
[19ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
Because the peer may fail to save a pseudonym username that was sent in an EAP-Request/AKA-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.
同輩がAKA EAP-要求/挑戦(例えば不調のため)で送られた匿名ユーザ名を保存しないかもしれないので、SHOULDが最も最近少なくとも維持するEAPサーバは最も最近発行された匿名ユーザ名に加えた匿名ユーザ名を使用しました。 認証交換が首尾よく終了されていないなら、サーバSHOULD NOTは最新のうまくいっている認証交換の間に発行された匿名ユーザ名を上書きします。
4.1.1.8. Transmitting Pseudonyms and Fast Re-Authentication Identities
to the Peer
4.1.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/AKA-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 to implement, 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/AKA-Reauthentication message.
AKA EAP-要求/挑戦メッセージはAT_ENCR_DATA属性の値の分野に暗号化された匿名ユーザ名、そして/または、暗号化された速い再認証のアイデンティティを含むかもしれません。 アイデンティティプライバシーサポートと速い再認証が実装するために任意であるので、同輩は、AT_ENCR_DATA属性を無視して、いつも永久的なアイデンティティを使用するかもしれません。 速い再認証(セクション5では、議論する)のときに、サーバはEAP-要求/AKA-Reauthenticationメッセージに新しくて、暗号化された速い再認証のアイデンティティを含むかもしれません。
On receipt of the EAP-Request/AKA-Challenge, the peer MAY decrypt the encrypted data in AT_ENCR_DATA; and if a pseudonym username is included, 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.
AKA EAP-要求/挑戦を受け取り次第、同輩はAT_ENCR_DATAの暗号化されたデータを解読するかもしれません。 そして、匿名ユーザ名が含まれているなら、同輩は次の完全な認証に関する得られた匿名ユーザ名を使用するかもしれません。 速い再認証のアイデンティティが含まれているなら、同輩は他の速い再認証州の情報と共にそれを保存するかもしれません、セクション5で議論するように、次の速い再認証のために。
If the peer does not receive a new pseudonym username in the EAP-Request/AKA-Challenge message, the peer MAY use an old pseudonym username instead of the permanent username on next full authentication. The username portions of fast re-authentication identities are one-time usernames, which the peer MUST NOT re-use. When the peer uses a fast re-authentication identity in an EAP exchange, the peer MUST discard the fast re-authentication identity and not re-use it in another EAP authentication exchange, even if the authentication exchange was not completed.
同輩がAKA EAP-要求/挑戦メッセージの新しい匿名ユーザ名を受け取らないなら、同輩は次の完全な認証に関する永久的なユーザ名の代わりに古い匿名ユーザ名を使用するかもしれません。 速い再認証のアイデンティティのユーザ名部分は1回のユーザ名です。(同輩はそのユーザ名を再使用してはいけません)。 同輩がEAP交換に速い再認証のアイデンティティを使用すると、同輩は、速い再認証のアイデンティティを捨てて、別のEAP認証交換にそれを再使用してはいけません、認証交換が終了されなかったとしても。
4.1.1.9. Usage of the Pseudonym by the Peer
4.1.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
任意のアイデンティティプライバシーサポートが完全な認証のときに使用されるとき、同輩はユーザ名として前の完全な認証系列の一部として受け取られた匿名ユーザ名を使用するかもしれません。
Arkko & Haverinen Informational [Page 20] RFC 4187 EAP-AKA Authentication January 2006
[20ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
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.1.1.10. Usage of the Fast Re-Authentication Identity by the Peer
4.1.1.10. 同輩による速い再認証のアイデンティティの用法
On fast re-authentication, the peer uses the fast re-authentication identity received as part of the previous authentication sequence. A new fast 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.1.2. Communicating the Peer Identity to the Server
4.1.2. サーバへの同輩のアイデンティティを伝えます。
4.1.2.1. General
4.1.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 re-authentication identity maintained by the server, then a fast re-authentication exchange is performed, as described in Section 5.
同輩のアイデンティティはサーバにEAP-応答/アイデンティティメッセージと伝えられるかもしれません。 このメッセージは永久的なアイデンティティ、匿名のアイデンティティ、または速い再認証のアイデンティティを含むかもしれません。 同輩が永久的なアイデンティティか匿名のアイデンティティ(サーバは永久的なアイデンティティに写像できる)を使用するなら、認証はセクション3の概要で議論するように続きます。 同輩が速い再認証のアイデンティティを使用して、速い再認証のアイデンティティがサーバによって維持された有効な速い再認証のアイデンティティに合わせるなら、速い再認証交換は実行されます、セクション5で説明されるように。
The peer identity can also be transmitted from the peer to the server using EAP-AKA messages instead of 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/AKA-Identity message; and the peer includes the AT_IDENTITY attribute, which contains the peer's identity, in the EAP-Response/AKA-Identity message. The AT_ANY_ID_REQ attribute is a general identity requesting attribute, which the server uses if it
また、EAP-応答/アイデンティティの代わりにEAP-AKAメッセージを使用することで同輩からサーバまで同輩のアイデンティティを伝えることができます。 この場合、サーバはAKA EAP-要求/アイデンティティメッセージに属性(__どんな_ID REQ、AT_FULLAUTH_AT_ID REQか_AT_PERMANENT_ID REQも)を要求するアイデンティティを含んでいます。 そして、同輩はAKA EAP-応答/アイデンティティメッセージでAT_IDENTITY属性を入れます。(それは、同輩のアイデンティティを含みます)。 どんな_ID_REQも結果と考えるAT_はサーバがそれであるなら使用する属性を要求する一般的なアイデンティティです。
Arkko & Haverinen Informational [Page 21] RFC 4187 EAP-AKA Authentication January 2006
[21ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
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. The EAP-Request/AKA-Challenge, EAP-Response/AKA-Challenge, or the packets used on fast re- authentication may optionally include the AT_CHECKCODE attribute, which enables the protocol peers to ensure the integrity of the AKA-Identity packets. AT_CHECKCODE is specified in Section 10.13.
同輩がAT_IDENTITYでアイデンティティのどの種類を返すべきであるかを指定しません。 サーバは、永久的なアイデンティティか匿名のアイデンティティのどちらかを要求するのにAT_FULLAUTH_ID_REQ属性を使用します。 サーバは、同輩が永久的なアイデンティティを送るよう要求するのにAT_PERMANENT_ID_REQ属性を使用します。 AKA EAP-要求/挑戦、AKA EAP-応答/挑戦、または速い再認証のときに使用されたパケットが任意にAT_CHECKCODE属性を含むかもしれません。(それは、プロトコル同輩がAKA-アイデンティティパケットの保全を保証するのを可能にします)。 AT_CHECKCODEはセクション10.13で指定されます。
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 only the EAP-AKA peer and the EAP-AKA server process the AT_IDENTITY attribute and entities that 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-AKA同輩とEAP-AKAサーバだけが通り抜けるAT_IDENTITY属性と実体を処理します。 EAPパケットはこの属性を処理しません。 したがって、AT_IDENTITY属性で認証されたアイデンティティがAAAプロトコルの中で別の方法的に彼らに伝えられないと、固有識別文字と他の中間的AAA要素(可能なAAAプロキシサーバなどの)は、オリジナルのアイデンティティでEAP-応答/アイデンティティパケットから同輩について言及し続けるでしょう。
4.1.2.2. Relying on EAP-Response/Identity Discouraged
4.1.2.2. がっかりするEAP-応答/アイデンティティを当てにします。
The EAP-Response/Identity packet is not method specific; therefore, 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-AKA, and the server is strongly discouraged from relying upon the EAP-Response/Identity.
この理由で、EAP同輩とサーバがEAP-AKAでメソッド特有のアイデンティティ属性を使用するのが、RECOMMENDEDであり、サーバはEAP-応答/アイデンティティを当てにして、強くがっかりしています。
In particular, if the EAP server receives a decorated identity in EAP-Response/Identity, then the EAP server MUST use the identity-requesting attributes to request the peer to send an unmodified and undecorated copy of the identity in AT_IDENTITY.
EAPサーバがEAP-応答/アイデンティティにおける飾り付けをされたアイデンティティを受けるなら、特に、EAPサーバは、AT_IDENTITYでアイデンティティの変更されていなくて非飾り付けをされたコピーを送るよう同輩に要求するのにアイデンティティを要求する属性を使用しなければなりません。
Arkko & Haverinen Informational [Page 22] RFC 4187 EAP-AKA Authentication January 2006
[22ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
4.1.3. Choice of Identity for the EAP-Response/Identity
4.1.3. EAP-応答/アイデンティティのためのアイデンティティの選択
If EAP-AKA peer is started upon receiving an EAP-Request/Identity message, then the peer MAY use an EAP-AKA identity in the EAP- Response/Identity packet. In this case, the peer performs the following steps.
EAP-AKA同輩がEAP-要求/アイデンティティメッセージを受け取るのに始められるなら、同輩はEAPの応答/アイデンティティパケットでEAP-AKAのアイデンティティを使用するかもしれません。 この場合、同輩は以下のステップを実行します。
If the peer has maintained fast re-authentication state information and if the peer 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.1.4. Server Operation in the Beginning of EAP-AKA Exchange
4.1.4. 初めにEAP-別名交換のサーバ操作
As discussed in Section 4.1.2.2, the server SHOULD NOT rely on an identity string received in EAP-Response/Identity. Therefore, the RECOMMENDED way to start an EAP-AKA exchange is to ignore any received identity strings. The server SHOULD begin the EAP-AKA exchange by issuing the EAP-Request/AKA-Identity 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/AKA-Identity message. Three methods to request an identity from the peer are discussed below.
セクション4.1.2で議論するように、.2、サーバSHOULD NOTはEAP-応答/アイデンティティで受け取られたアイデンティティストリングを当てにします。 したがって、EAP-AKA交換を始めるRECOMMENDED方法はどんな容認されたアイデンティティストリングも無視することです。 サーバSHOULDは、サーバが、同輩がEAP AKA応答/アイデンティティメッセージのAT_IDENTITY属性でアイデンティティを入れる必要であるのを示すためにアイデンティティを要求する属性でAKA EAP-要求/アイデンティティパケットを発行することによって、EAP-AKA交換を始めます。 以下で同輩からアイデンティティを要求する3つのメソッドについて議論します。
If the server chooses to not ignore the contents of EAP-Response/Identity, then the server may already receive an EAP-AKA identity in this packet. However, if the EAP server has not received any EAP-AKA peer identity (permanent identity, pseudonym identity, or fast re-authentication identity) from the peer when sending the first EAP-AKA 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-AKAのアイデンティティを受けるかもしれません。 しかしながら、EAP-AKAが要求する1番目を送るとき、EAPサーバがEAP-応答/アイデンティティパケットを受けましたが、内容が有効な永久的なアイデンティティ、匿名のアイデンティティ、または再認証のアイデンティティであるように見えないならEAPサーバが同輩からEAP-AKA同輩のアイデンティティ(永久的なアイデンティティ、匿名のアイデンティティ、または速い再認証のアイデンティティ)をまだ、受けていないなら、以下のメソッドの1つを使用して、サーバは同輩からアイデンティティを要求しなければなりません。
The server sends the EAP-Request/AKA-Identity message with the AT_PERMANENT_ID_REQ attribute to indicate that the server wants the peer to include the permanent identity in the AT_IDENTITY attribute of the EAP-Response/AKA-Identity message. This is done in the following cases:
サーバは、サーバが、同輩がAKA EAP-応答/アイデンティティメッセージのAT_IDENTITY属性で永久的なアイデンティティを入れる必要であるのを示すためにAT_PERMANENT_ID_REQ属性があるAKA EAP-要求/アイデンティティメッセージを送ります。 以下の場合でこれをします:
Arkko & Haverinen Informational [Page 23] RFC 4187 EAP-AKA Authentication January 2006
[23ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
o The server does not support fast re-authentication or identity
privacy.
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/AKA-Identity 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/AKA-Identity message. This is done in the following cases:
サーバは、サーバが、同輩がAKA EAP-応答/アイデンティティメッセージのAT_IDENTITY属性で完全な認証のアイデンティティ(匿名のアイデンティティか永久的なアイデンティティ)を入れる必要であるのを示すためにAT_FULLAUTH_ID_REQ属性でAKA EAP-要求/アイデンティティパケットを発行します。 以下の場合でこれをします:
o The server does not support fast re-authentication and the server
supports identity privacy
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 サーバは速い再認証をサポートしません、そして、サーバはサーバが処理すると決めたアイデンティティプライバシーoに容認されたアイデンティティをサポートします、そして、サーバは、容認されたアイデンティティが再認証のアイデンティティであると認めますが、サーバは永久的なアイデンティティへの再認証のアイデンティティを写像できません。
The server issues the EAP-Request/AKA-Identity 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/AKA-Identity 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, when the server does not have any identity, or when the server does not recognize the format of a received identity.
サーバはサーバが、同輩がAKA EAP-応答/アイデンティティメッセージのAT_IDENTITY属性でアイデンティティを入れる必要であるのを示すためにATがあるAKA EAP-要求/アイデンティティパケットに_どんな_ID_REQ属性も発行します、そして、サーバはアイデンティティのための少しの都合のよいタイプも示しません。 他の場合でこれをします、サーバがいつ容認されたEAP-応答/アイデンティティを無視するか、そして、いつ、サーバにはアイデンティティが少しのないか、そして、またはサーバがいつ容認されたアイデンティティの形式を認識しないのなどように。
4.1.5. Processing of EAP-Request/AKA-Identity by the Peer
4.1.5. 同輩による別名EAP-要求/アイデンティティの処理
Upon receipt of an EAP-Request/AKA-Identity message, the peer MUST perform the following steps.
AKA EAP-要求/アイデンティティメッセージを受け取り次第、同輩は以下のステップを実行しなければなりません。
If the EAP-Request/AKA-Identity includes AT_PERMANENT_ID_REQ, and if the peer does not have a pseudonym available, then the peer MUST respond with EAP-Response/AKA-Identity and include the permanent identity in 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/AKA-Identity and include the permanent identity in AT_IDENTITY or respond with EAP-Response/AKA-Client-Error packet with code "unable to process packet".
同輩に利用可能な匿名がないならAKA EAP-要求/アイデンティティが_AT_PERMANENT_ID REQを含んでいるなら、同輩は、AKA EAP-応答/アイデンティティで応じて、AT_IDENTITYで永久的なアイデンティティを入れなければなりません。 同輩に利用可能な匿名があるなら、同輩は、永久的なアイデンティティを送るのを拒否するかもしれません。 したがって、同輩は、この場合、AKA EAP-応答/アイデンティティで応じて、AT_IDENTITYで永久的なアイデンティティを入れなければならないか、またはコードが「パケットを処理できない」状態で、AKAクライアントEAP-応答/誤りパケットで応じなければなりません。
If the EAP-Request/AKA-Identity includes AT_FULL_AUTH_ID_REQ, and if the peer has a pseudonym available, then the peer SHOULD respond with EAP-Response/AKA-Identity and include the pseudonym identity in
AKA EAP-要求/アイデンティティが、_AT_FULL_AUTH_ID REQと同輩が利用可能な匿名、次にSHOULDがAKA EAP-応答/アイデンティティで応じて、匿名のアイデンティティを含む同輩がいるかどうかを含んでいるなら
Arkko & Haverinen Informational [Page 24] RFC 4187 EAP-AKA Authentication January 2006
[24ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
AT_IDENTITY. If the peer does not have a pseudonym when it receives this message, then the peer MUST respond with EAP-Response/ AKA-Identity and include the permanent identity in AT_IDENTITY. The Peer MUST NOT use a fast re-authentication identity in the AT_IDENTITY attribute.
_アイデンティティで。 このメッセージを受け取るとき同輩に匿名がないなら、同輩は、AKA EAP-応答/アイデンティティで応じて、AT_IDENTITYで永久的なアイデンティティを入れなければなりません。 PeerはAT_IDENTITY属性に速い再認証のアイデンティティを使用してはいけません。
If the EAP-Request/AKA-Identity includes AT_ANY_ID_REQ, and if the peer has maintained fast re-authentication state information and wants to use fast re-authentication, then the peer responds with EAP-Response/AKA-Identity 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/AKA-Identity and includes the pseudonym identity in AT_IDENTITY. Else, the peer responds with EAP-Response/AKA-Identity and includes the permanent identity in AT_IDENTITY.
同輩がAKA EAP-要求/アイデンティティが_どんなAT__ID REQも含んで、速い再認証州の情報を保守して、速い再認証を使用したいと思うなら、同輩は、AKA EAP-応答/アイデンティティで応じて、AT_IDENTITYで速い再認証のアイデンティティを入れます。 ほかに、同輩に利用可能な匿名のアイデンティティがあるなら、同輩は、AKA EAP-応答/アイデンティティで応じて、AT_IDENTITYで匿名のアイデンティティを入れます。 ほかに、同輩は、AKA EAP-応答/アイデンティティで応じて、AT_IDENTITYで永久的なアイデンティティを入れます。
An EAP-AKA exchange may include several EAP/AKA-Identity rounds. The server may issue a second EAP-Request/AKA-Identity, if it was not able to recognize the identity the peer used in the previous AT_IDENTITY attribute. At most three EAP/AKA-Identity rounds can be used, so the peer MUST NOT respond to more than three EAP-Request/AKA-Identity messages within an EAP exchange. The peer MUST verify that the sequence of EAP-Request/AKA-Identity packets 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/AKA-Identity; in other words, AT_ANY_ID_REQ MUST NOT be used in the second or third EAP-Request/AKA-Identity. AT_FULLAUTH_ID_REQ MUST NOT be used if the previous EAP-Request/AKA-Identity 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-AKA交換はいくつかのEAP/AKA-アイデンティティラウンドを含むかもしれません。 サーバはAKA第2EAP-要求/アイデンティティを発行するかもしれません、同輩が前のAT_IDENTITY属性に使用したアイデンティティを認識できなかったなら。 ほとんどの3EAP/AKA-アイデンティティラウンドのときに使用できるので、同輩はEAP交換の中でAKA3以上EAP-要求/アイデンティティメッセージに応じてはいけません。 同輩は、同輩が受けるAKA EAP-要求/アイデンティティパケットの系列が本書では定義される配列規則に応じることを確かめなければなりません。 AKA最初のEAP-要求/アイデンティティにどんなすなわち、AT__ID_REQも使用できるだけです。 _どんな言い換えれば、AT__ID REQ MUST NOT、もAKA2番目か第3EAP-要求/アイデンティティでは、使用されてください。 _AT_FULLAUTH_ID REQ MUST NOT、AKA前のEAP-要求/アイデンティティが_AT_PERMANENT_ID REQを含んでいたなら、使用されてください。 予期していなかった属性か予期していなかったメッセージを受け取るときの場合では、同輩操作はセクション6.3.1で指定されます。
4.1.6. Attacks against Identity Privacy
4.1.6. アイデンティティプライバシーに対する攻撃
The section above specifies two possible ways the peer can operate upon receipt of AT_PERMANENT_ID_REQ because a received AT_PERMANENT_ID_REQ does not necessarily originate from the valid network. However, an active attacker may transmit an EAP-Request/AKA-Identity 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 EAP-Response/AKA-Client-Error packet with the error code "unable to process packet", and the authentication exchange terminates.
上のセクションは容認された_AT_PERMANENT ID_REQが必ず有効なネットワークから発するというわけではないので同輩が_AT_PERMANENT_ID REQを受け取り次第働くことができる2つの可能な方法を指定します。 しかしながら、活発な攻撃者は、ユーザの本当のアイデンティティを見つけるためにAT_PERMANENT_ID_REQ属性で取り組みでAKA EAP-要求/アイデンティティパケットを同輩に伝えるかもしれません。 同輩が永久的なアイデンティティを明らかにしたくないなら、エラーコードが「パケットを処理できない」状態で、同輩はAKAクライアントEAP-応答/誤りパケットを送ります、そして、認証交換は終わります。
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,
基本的に、同輩が_AT_PERMANENT_ID REQに関して使うことができる2つの異なった方針があります。 「保守的な人」同輩は、ネットワークが匿名を強壮に維持できると仮定します。 したがって
Arkko & Haverinen Informational [Page 25] RFC 4187 EAP-AKA Authentication January 2006
[25ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
if a conservative peer has a pseudonym username, the peer responds with EAP-Response/AKA-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と共にAKAクライアントEAP-応答/誤りでEAPパケットに応じます、同輩が、有効なネットワークが同輩の永久的なアイデンティティへの匿名のアイデンティティを写像できると信じているので。 (あるいはまた、保守的な同輩はある特定の状況では_AT_PERMANENT_ID REQを受け入れるかもしれません、例えば、昔に匿名を受け取ったなら。) この方針の利益は匿名に対する活発な攻撃に対して同輩を保護するということです。 他方では、「寛容な」同輩は、いつも_AT_PERMANENT_ID REQを受け入れて、永久的なアイデンティティで応じます。 この方針の利益は、有効なネットワークが時々匿名を失っても働いているということであり、永久的なアイデンティティにそれらを写像できません。
4.1.7. Processing of AT_IDENTITY by the Server
4.1.7. _アイデンティティでは、サーバで、処理します。
When the server receives an EAP-Response/AKA-Identity message with the AT_IDENTITY (in response to the server's identity requesting attribute), the server MUST operate as follows.
サーバがAT_IDENTITY(属性を要求するサーバのアイデンティティに対応した)と共にAKA EAP-応答/アイデンティティメッセージを受け取るとき、サーバは以下の通り作動しなければなりません。
If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does not contain a valid permanent identity, then the server sends an EAP-Request/AKA-Notification packet with AT_NOTIFICATION code "General failure" (16384) to terminate the EAP exchange. If the server recognizes the permanent identity and is able to continue, then the server proceeds with full authentication by sending EAP-Request/AKA-Challenge.
AT_IDENTITYが有効な永久的なアイデンティティを含んでいないならサーバが_AT_PERMANENT_ID REQを使用したなら、サーバは、EAP交換を終えるためにAT_NOTIFICATIONコード「一般失敗」(16384)があるAKA EAP-要求/通知パケットを送ります。 サーバが永久的なアイデンティティを認識して、続くことができるなら、サーバはAKA送付EAP-要求/挑戦で完全な認証を続けます。
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/AKA-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/ AKA-Identity with AT_PERMANENT_ID_REQ.
サーバが_AT_FULLAUTH_ID REQを使用して、AT_IDENTITYがサーバが有効な永久的なアイデンティティに写像できる有効な永久的なアイデンティティか匿名のアイデンティティを含んでいるなら、サーバはAKA送付EAP-要求/挑戦で完全な認証を続けます。 AT_IDENTITYがサーバが認識できませんし、分類できないサーバが有効な永久的なアイデンティティに写像できない匿名のアイデンティティ、またはアイデンティティを含んでいるなら、サーバは_AT_PERMANENT_ID REQがあるAKA EAP-要求/アイデンティティを送ります。
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/ AKA-Challenge.
サーバが_どんなAT__ID REQも使用して、AT_IDENTITYがサーバが有効な永久的なアイデンティティに写像できる有効な永久的なアイデンティティか匿名のアイデンティティを含んでいるなら、サーバはAKA送付EAP-要求/挑戦で完全な認証を続けます。
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/AKA-Reauthentication (Section 5).
サーバが_どんなAT__ID REQも使用して、AT_IDENTITYが有効な速い再認証のアイデンティティを含んでいて、サーバが、再認証を使用するのに同意するなら、サーバは、EAP-要求/AKA-Reauthentication(セクション5)を送ることによって、速い再認証を続けます。
Arkko & Haverinen Informational [Page 26] RFC 4187 EAP-AKA Authentication January 2006
[26ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
If the server used AT_ANY_ID_REQ, and if the peer sent an EAP- Response/AKA-Identity with AT_IDENTITY that contains an identity that the server recognizes as a fast re-authentication identity, but the server is not able to map the identity to a permanent identity, then the server sends EAP-Request/AKA-Identity with AT_FULLAUTH_ID_REQ.
サーバが_どんなAT__ID REQも使用して、同輩がサーバが速い再認証のアイデンティティとして認識するアイデンティティを含むAT_IDENTITYがあるEAP AKA応答/アイデンティティを送りましたが、サーバが永久的なアイデンティティへのアイデンティティを写像できないなら、サーバは_AT_FULLAUTH_ID REQがあるAKA EAP-要求/アイデンティティを送ります。
If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid fast re-authentication identity, which 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 proceeds with full authentication by sending EAP-Request/AKA-Challenge.
サーバが_どんなAT__ID REQも使用して、サーバが速い再認証を使用したいと思わないならAT_IDENTITYが有効な速い再認証のアイデンティティ(サーバは永久的なアイデンティティに写像できる)を含んでいるなら、サーバはAKA送付EAP-要求/挑戦で完全な認証を続けます。
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/AKA-Identity with AT_PERMANENT_ID_REQ.
サーバが_どんなAT__ID REQも使用して、匿名のアイデンティティにもかかわらず、サーバが永久的なアイデンティティへの匿名のアイデンティティを写像できないときAT_IDENTITYがサーバが認識するアイデンティティを含んでいるなら、サーバは_AT_PERMANENT_ID REQがあるAKA EAP-要求/アイデンティティを送ります。
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/AKA-Identity with AT_FULLAUTH_ID_REQ.
サーバが_どんなAT__ID REQも使用して、AT_IDENTITYがサーバが認識できませんし、分類できないアイデンティティを含んでいるなら、サーバは_AT_FULLAUTH_ID REQがあるAKA EAP-要求/アイデンティティを送ります。
4.2. Message Sequence Examples (Informative)
4.2. メッセージ系列の例(有益)です。
This section contains non-normative message sequence examples to illustrate how the peer identity can be communicated to the server.
このセクションはどう同輩のアイデンティティをサーバに伝えることができるかを例証する非標準のメッセージ系列の例を含みます。
4.2.1. Usage of AT_ANY_ID_REQ
4.2.1. __のどんな_ID REQの使用法
Obtaining the peer identity with EAP-AKA attributes is illustrated in Figure 5 below.
EAP-AKA属性で同輩のアイデンティティを得るのは以下の図5で例証されます。
Peer Authenticator
| |
| +------------------------------+
| | Server does not have any |
| | Subscriber identity available|
| | When starting EAP-AKA |
| +------------------------------+
| EAP-Request/AKA-Identity |
| (AT_ANY_ID_REQ) |
|<------------------------------------------------------|
| |
| EAP-Response/AKA-Identity |
| (AT_IDENTITY) |
|------------------------------------------------------>|
| |
Figure 5: Usage of AT_ANY_ID_REQ
同輩固有識別文字| | | +------------------------------+ | | サーバには、いずれもありません。| | | 利用可能な加入者のアイデンティティ| | | いつの始めのEAP-AKA| | +------------------------------+ | 別名EAP-要求/アイデンティティ| | (__どんな_ID REQのも) | |<------------------------------------------------------| | | | 別名EAP-応答/アイデンティティ| | (_アイデンティティにおける) | |------------------------------------------------------>| | | 図5: __のどんな_ID REQの使用法
Arkko & Haverinen Informational [Page 27] RFC 4187 EAP-AKA Authentication January 2006
[27ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
4.2.2. Fall Back on Full Authentication
4.2.2. 完全な認証のときに、後ろへ下がってください。
Figure 6 illustrates the case when the server does not recognize the fast re-authentication identity the peer used in AT_IDENTITY.
サーバが同輩がAT_IDENTITYで使用した速い再認証のアイデンティティを認識しないとき、図6はケースを例証します。
Peer Authenticator
| |
| +------------------------------+
| | Server does not have any |
| | Subscriber identity available|
| | When starting EAP-AKA |
| +------------------------------+
| EAP-Request/AKA-Identity |
| (AT_ANY_ID_REQ) |
|<------------------------------------------------------|
| |
| EAP-Response/AKA-Identity |
| (AT_IDENTITY containing a fast re-auth. identity) |
|------------------------------------------------------>|
| +------------------------------+
| | Server does not recognize |
| | The fast re-auth. |
| | Identity |
| +------------------------------+
| EAP-Request/AKA-Identity |
| (AT_FULLAUTH_ID_REQ) |
|<------------------------------------------------------|
| EAP-Response/AKA-Identity |
| (AT_IDENTITY with a full-auth. Identity) |
|------------------------------------------------------>|
| |
同輩固有識別文字| | | +------------------------------+ | | サーバには、いずれもありません。| | | 利用可能な加入者のアイデンティティ| | | いつの始めのEAP-AKA| | +------------------------------+ | 別名EAP-要求/アイデンティティ| | (__どんな_ID REQのも) | |<------------------------------------------------------| | | | 別名EAP-応答/アイデンティティ| | (a速い再authアイデンティティを含むAT_IDENTITY) | |------------------------------------------------------>| | +------------------------------+ | | サーバは認識しません。| | | 速い再auth。 | | | アイデンティティ| | +------------------------------+ | 別名EAP-要求/アイデンティティ| | (__FULLAUTH_ID REQの) | |<------------------------------------------------------| | 別名EAP-応答/アイデンティティ| | (完全なauthとAT_IDENTITY。 アイデンティティ) | |------------------------------------------------------>| | |
Figure 6: Fall back on full authentication
図6: 完全な認証のときに、後ろへ下がってください。
If the server recognizes the fast re-authentication identity, but still wants to fall back on full authentication, the server may issue the EAP-Request/AKA-Challenge packet. In this case, the full authentication procedure proceeds as usual.
サーバが速い再認証のアイデンティティを認識しますが、完全な認証のときにまだ後ろへ下がっていたいなら、サーバはAKA EAP-要求/挑戦パケットを発行するかもしれません。 この場合、完全な認証手順はいつものように続きます。
Arkko & Haverinen Informational [Page 28] RFC 4187 EAP-AKA Authentication January 2006
[28ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
4.2.3. Requesting the Permanent Identity 1
4.2.3. 永久的なアイデンティティ1を要求します。
Figure 7 illustrates the case when the EAP server fails to decode a pseudonym identity included in the EAP-Response/Identity packet.
EAP-応答/アイデンティティパケットに匿名のアイデンティティを含んでいて、EAPサーバが解読しないと、図7はケースを例証します。
Peer Authenticator
| EAP-Request/Identity |
|<------------------------------------------------------|
| EAP-Response/Identity |
| (Includes a pseudonym) |
|------------------------------------------------------>|
| +------------------------------+
| | Server fails to decode the |
| | Pseudonym. |
| +------------------------------+
| EAP-Request/AKA-Identity |
| (AT_PERMANENT_ID_REQ) |
|<------------------------------------------------------|
| |
| EAP-Response/AKA-Identity |
| (AT_IDENTITY with permanent identity) |
|------------------------------------------------------>|
| |
同輩固有識別文字| EAP-要求/アイデンティティ| |<------------------------------------------------------| | EAP-応答/アイデンティティ| | (匿名を含んでいます) | |------------------------------------------------------>| | +------------------------------+ | | サーバは解読しません。| | | 匿名。 | | +------------------------------+ | 別名EAP-要求/アイデンティティ| | (__永久的な_ID REQの) | |<------------------------------------------------------| | | | 別名EAP-応答/アイデンティティ| | (永久的なアイデンティティがあるAT_IDENTITY) | |------------------------------------------------------>| | |
Figure 7: Requesting the permanent identity 1
図7: 永久的なアイデンティティ1を要求します。
If the server recognizes the permanent identity, then the authentication sequence proceeds as usual with the EAP Server issuing the EAP-Request/AKA-Challenge message.
サーバが永久的なアイデンティティを認識するなら、認証系列はいつものようにAKA EAP-要求/挑戦メッセージを発行するEAP Serverを続けます。
Arkko & Haverinen Informational [Page 29] RFC 4187 EAP-AKA Authentication January 2006
[29ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
4.2.4. Requesting the Permanent Identity 2
4.2.4. 永久的なアイデンティティ2を要求します。
Figure 8 illustrates the case when the EAP server fails to decode the pseudonym included in the AT_IDENTITY attribute.
AT_IDENTITY属性に匿名を含んでいて、EAPサーバが解読しないと、エイト環はケースを例証します。
Peer Authenticator
| |
| +------------------------------+
| | Server does not have any |
| | Subscriber identity available|
| | When starting EAP-AKA |
| +------------------------------+
| EAP-Request/AKA-Identity |
| (AT_ANY_ID_REQ) |
|<------------------------------------------------------|
| |
|EAP-Response/AKA-Identity |
|(AT_IDENTITY with a pseudonym identity) |
|------------------------------------------------------>|
| +------------------------------+
| | Server fails to decode the |
| | Pseudonym in AT_IDENTITY |
| +------------------------------+
| EAP-Request/AKA-Identity |
| (AT_PERMANENT_ID_REQ) |
|<------------------------------------------------------|
| EAP-Response/AKA-Identity |
| (AT_IDENTITY with permanent identity) |
|------------------------------------------------------>|
| |
同輩固有識別文字| | | +------------------------------+ | | サーバには、いずれもありません。| | | 利用可能な加入者のアイデンティティ| | | いつの始めのEAP-AKA| | +------------------------------+ | 別名EAP-要求/アイデンティティ| | (__どんな_ID REQのも) | |<------------------------------------------------------| | | |別名EAP-応答/アイデンティティ| |(匿名のアイデンティティがあるAT_IDENTITY) | |------------------------------------------------------>| | +------------------------------+ | | サーバは解読しません。| | | 中の_アイデンティティにおける匿名| | +------------------------------+ | 別名EAP-要求/アイデンティティ| | (__永久的な_ID REQの) | |<------------------------------------------------------| | 別名EAP-応答/アイデンティティ| | (永久的なアイデンティティがあるAT_IDENTITY) | |------------------------------------------------------>| | |
Figure 8: Requesting the permanent identity 2
エイト環: 永久的なアイデンティティ2を要求します。
4.2.5. Three EAP/AKA-Identity Round Trips
4.2.5. 3つの別名EAP/アイデンティティ周遊旅行
Figure 9 illustrates the case with three EAP/AKA-Identity round trips.
図9は3つのEAP/AKA-アイデンティティ周遊旅行をケースに入れます。
Arkko & Haverinen Informational [Page 30] RFC 4187 EAP-AKA Authentication January 2006
[30ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
Peer Authenticator
| |
| +------------------------------+
| | Server does not have any |
| | Subscriber identity available|
| | When starting EAP-AKA |
| +------------------------------+
| EAP-Request/AKA-Identity |
| (AT_ANY_ID_REQ) |
|<------------------------------------------------------|
| |
| EAP-Response/AKA-Identity |
| (AT_IDENTITY with fast re-auth. identity) |
|------------------------------------------------------>|
| +------------------------------+
| | Server does not accept |
| | The fast re-authentication |
| | Identity |
| +------------------------------+
| |
: :
: :
同輩固有識別文字| | | +------------------------------+ | | サーバには、いずれもありません。| | | 利用可能な加入者のアイデンティティ| | | いつの始めのEAP-AKA| | +------------------------------+ | 別名EAP-要求/アイデンティティ| | (__どんな_ID REQのも) | |<------------------------------------------------------| | | | 別名EAP-応答/アイデンティティ| | (速い再authアイデンティティがあるAT_IDENTITY) | |------------------------------------------------------>| | +------------------------------+ | | サーバは受け入れません。| | | 速い再認証| | | アイデンティティ| | +------------------------------+ | | : : : :
: :
: :
| EAP-Request/AKA-Identity |
| (AT_FULLAUTH_ID_REQ) |
|<------------------------------------------------------|
|EAP-Response/AKA-Identity |
|(AT_IDENTITY with a pseudonym identity) |
|------------------------------------------------------>|
| +------------------------------+
| | Server fails to decode the |
| | Pseudonym in AT_IDENTITY |
| +------------------------------+
| EAP-Request/AKA-Identity |
| (AT_PERMANENT_ID_REQ) |
|<------------------------------------------------------|
| EAP-Response/AKA-Identity |
| (AT_IDENTITY with permanent identity) |
|------------------------------------------------------>|
| |
: : : : | 別名EAP-要求/アイデンティティ| | (__FULLAUTH_ID REQの) | |<------------------------------------------------------| |別名EAP-応答/アイデンティティ| |(匿名のアイデンティティがあるAT_IDENTITY) | |------------------------------------------------------>| | +------------------------------+ | | サーバは解読しません。| | | 中の_アイデンティティにおける匿名| | +------------------------------+ | 別名EAP-要求/アイデンティティ| | (__永久的な_ID REQの) | |<------------------------------------------------------| | 別名EAP-応答/アイデンティティ| | (永久的なアイデンティティがあるAT_IDENTITY) | |------------------------------------------------------>| | |
Figure 9: Three EAP-AKA Start rounds
図9: 3EAP-AKA Startラウンド
After the last EAP-Response/AKA-Identity message, the full authentication sequence proceeds as usual.
AKA最後のEAP-応答/アイデンティティメッセージの後に、完全な認証系列はいつものように続きます。
Arkko & Haverinen Informational [Page 31] RFC 4187 EAP-AKA Authentication January 2006
[31ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
5. Fast Re-Authentication
5. 速い再認証
5.1. General
5.1. 一般
In some environments, EAP authentication may be performed frequently. Because the EAP-AKA full authentication procedure uses the AKA algorithms, and therefore requires fresh authentication vectors from the Authentication Centre, the full authentication procedure may result in many network operations when used very frequently. Therefore, EAP-AKA includes a more inexpensive fast re-authentication procedure that does not make use of the AKA algorithms and does not need new vectors from the Authentication Centre.
いくつかの環境で、EAP認証は頻繁に実行されるかもしれません。 EAP-AKAの完全な認証手順がAKAアルゴリズムを使用して、したがって、Authentication Centreから新鮮な認証ベクトルを必要とするので、非常に頻繁に使用されると、完全な認証手順は多くのネットワーク操作をもたらすかもしれません。 したがって、EAP-AKAはAKAアルゴリズムを利用しないで、またAuthentication Centreから新しいベクトルを必要としないより安価な速い再認証手順を含んでいます。
Fast re-authentication is optional to implement for both the EAP-AKA server and peer. On each EAP authentication, either one of the entities may fall back on full authentication if is does not want to use fast re-authentication.
速い再認証は、両方のためにEAP-AKAサーバと同輩を実装するために任意です。 実体のどちらかが完全な認証のときにそれぞれのEAP認証のときに後ろへ下がる、速い再認証を使用して欲ししないでください。
Fast re-authentication is based on the keys derived on the preceding full authentication. The same K_aut and K_encr keys used in full authentication are used to protect EAP-AKA 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-AKAパケットと属性を保護するのに使用されます、そして、完全な認証からのオリジナルの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 fast re-authentications. For example, on the second fast re-authentication, counter value is two or greater, etc. 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サーバによって送られたより値以下であることを確かめなければなりません。
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に貢献します。
Arkko & Haverinen Informational [Page 32] RFC 4187 EAP-AKA Authentication January 2006
[32ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
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. 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 and K_encr may either be stored or derived again from MK. The server may also need to store the permanent identity of the user.
同輩とサーバSHOULDの両方で、完全な認証が、実行される必要がある前にその後の速い再認証の数のための上限を許容しています。 16ビットのカウンタが速い再認証に使用されるので、対価がFFFFに達するとき、理論上の最大数の再認証に達しています。16進。 速い再認証を使用するために、同輩とEAPサーバは、以下の値を保存する必要があります: Key、最新の対価、および次の速い再認証にアイデンティティをマスタリングしてください。 K_autとK_encrを保存するか、または再びMKから得るかもしれません。 また、サーバは、ユーザの永久的なアイデンティティを保存する必要があるかもしれません。
5.2. Comparison to AKA
5.2. 別名との比較
When analyzing the fast re-authentication exchange, it may be helpful to compare it with the 3rd generation Authentication and Key Agreement (AKA) exchange used on full authentication. The counter corresponds to the AKA sequence number, NONCE_S corresponds to RAND, the AT_MAC in EAP-Request/AKA-Reauthentication corresponds to AUTN, the AT_MAC in EAP-Response/AKA-Reauthentication 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 AKA -- the server generates the NONCE_S and counter values, and the peer only verifies that the counter value is fresh.
速い再認証交換を分析するとき、完全な認証のときに使用された3番目の世代AuthenticationとKey Agreement(AKA)交換とそれを比べるのは役立っているかもしれません。 カウンタはAKA一連番号に対応している、NONCE_SはRANDに対応している、EAP-要求/AKA-ReauthenticationのAT_MACはAUTNに対応している、EAP-応答/AKA-ReauthenticationのAT_MACはRESに対応しています、AT_COUNTERも。_SMALLはAUTSに対応しています、そして、カウンタを暗号化するのはAnonymity Keyの使用法に対応しています。 また、無作為の、または、新鮮な材料に関して、速い再認証におけるキー生成も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 fast re-authentication identity is lost and the network does not recognize it, the EAP server can fall back on full authentication. 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/- AKA-Challenge message. This attribute contains a new re-authentication identity for the next fast re-authentication. The attribute also works as a capability flag that indicates 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 will use full authentication next time. If the peer wants to use fast re-authentication, it uses this fast re-authentication identity on next authentication. Even if the peer has a fast re-authentication
速い再認証手順は別々の再認証ユーザアイデンティティを利用します。 匿名と永久的なアイデンティティは完全な認証だけのために予約されます。 速い再認証のアイデンティティが無くなって、ネットワークがそれを認識しないなら、EAPサーバは完全な認証のときに後ろへ下がることができます。 EAPサーバが速い再認証をサポートするなら、それはEAP要求/AKA-挑戦メッセージの暗号化されたデータにskippable AT_ネクスト_REAUTH_ID属性を含むかもしれません。 この属性は次の速い再認証のための新しい再認証のアイデンティティを含んでいます。 また、サーバが、再認証とそれがサーバであると速くサポートするのを示す能力旗が、現在の背景の中で速い再認証を使用し続けたがっているとき、属性は働いています。 同輩はこの属性を無視するかもしれません、その場合、それが次回、完全な認証を使用するでしょう。 同輩が速い再認証を使用したいと思うなら、それは次の認証のときにこの速い再認証のアイデンティティを使用します。 同輩に速い再認証がある場合
Arkko & Haverinen Informational [Page 33] RFC 4187 EAP-AKA Authentication January 2006
[33ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
identity, the peer MAY discard the 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/AKA-Challenge or EAP-Request/AKA-Reauthentication, then the peer MUST discard its current fast re-authentication state information and perform a full authentication next time.
アイデンティティ、同輩は再認証のアイデンティティを捨てて、代わりに匿名か永久的なアイデンティティを使用するかもしれません、その場合、完全な認証を実行しなければなりません。 EAPサーバがAKA EAP-要求/挑戦かEAP-要求/AKA-Reauthenticationの暗号化されたデータに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/ AKA-Identity packet.
同輩がEAP-応答/アイデンティティパケットで速い再認証のアイデンティティを使用するかもしれませんか、またはどんな_ID_REQも結果と考えるサーバのAT_に対応して同輩はAKA EAP-応答/アイデンティティパケットの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の分野の部分を変えるのが望ましくなくて、いくつかのサーバの中で主要な同じ速い再認証を共有するのにおいてセキュリティリスクがあるかもしれないことに注意されるべきです。
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. If the server was able to decode the fast re-authentication identity to the permanent identity, the server issues the EAP-Request/AKA-Challenge packet to initiate full authentication. If the server was not able to recover the peer's identity from the fast re-authentication identity, the server starts the full authentication procedure by issuing an EAP-Request/AKA-Identity packet. This packet always starts a full authentication sequence if it does not include the AT_ANY_ID_REQ attribute.
同輩が速い再認証のアイデンティティを使用しても、例えば、サーバが速い再認証のアイデンティティを認めなくしたくはありませんし、速い再認証を使用したがっていないので、サーバは完全な認証のときに後ろへ下がりたがっているかもしれません。 サーバが永久的なアイデンティティへの速い再認証のアイデンティティを解読できたなら、サーバは、完全な認証を開始するためにAKA EAP-要求/挑戦パケットを発行します。 サーバが速い再認証のアイデンティティから同輩のアイデンティティを取り戻すことができなかったなら、サーバは、AKA EAP-要求/アイデンティティパケットを発行することによって、完全な認証手順を始めます。 それがどんな_ID_REQも結果と考えるAT_を含まないなら、このパケットはいつも完全な認証系列を始めます。
Arkko & Haverinen Informational [Page 34] RFC 4187 EAP-AKA Authentication January 2006
[34ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
5.4. Fast Re-Authentication Procedure
5.4. 速い再認証手順
Figure 10 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 fast re-authentication identity in the EAP-Response/Identity packet. As discussed above, an alternative way to communicate the fast re-authentication identity to the server is for the peer to use the AT_IDENTITY attribute in the EAP-Response/AKA-Identity 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/AKA-Identity packet.
図10は速い再認証手順を例証します。 この例では、任意の保護された成功指示は使用されていません。 暗号化された属性は'*'で指示されます。 同輩はEAP-応答/アイデンティティパケットで速い再認証のアイデンティティを使用します。 上で議論するように、サーバへの速い再認証のアイデンティティを伝える代替の方法は同輩がAKA EAP-応答/アイデンティティメッセージでAT_IDENTITY属性を使用することです。 この後者のケースは以下の図で例証されません、そして、サーバが、同輩がAKA EAP-要求/アイデンティティパケットで_どんな_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/AKA- Reauthentication 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要求/AKA- Reauthenticationパケットを同輩に送ります。 このパケットは暗号化された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/AKA-Reauthentication packet, including the AT_COUNTER attribute with the same counter value and the AT_MAC attribute.
同輩はAT_MACが正しく、対価が新鮮であることを(いずれも以前に値を使用したよりすばらしい)確かめます。 同輩は、次回の暗号化されたAT_ネクスト_REAUTH_IDから次の速い再認証がアイデンティティであると保存するかもしれません。 すべてのチェックがうまくいくなら、同輩はEAP-応答/AKA-Reauthenticationパケットで応じます、同じ対価があるAT_COUNTER属性とAT_MAC属性を含んでいて。
The server verifies the AT_MAC attribute and also verifies that the counter value is the same that it used in the EAP-Request/AKA-Reauthentication packet. If these checks are successful, the fast re-authentication has succeeded and the server sends the EAP-Success packet to the peer.
サーバは、AT_MAC属性について確かめて、また、対価がそれがEAP-要求/AKA-Reauthenticationパケットで使用した同じくらいであることを確かめます。 これらのチェックがうまくいくなら、速い再認証は成功しました、そして、サーバはEAP-成功パケットを同輩に送ります。
If protected success indications (Section 6.2) were used, the EAP-Success packet would be preceded by an EAP-AKA notification round.
保護された成功指摘(セクション6.2)が使用されるなら、EAP-AKA通知でEAP-成功パケットはぐるりと先行されているでしょうに。
Arkko & Haverinen Informational [Page 35] RFC 4187 EAP-AKA Authentication January 2006
[35ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
Peer Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes a fast re-authentication identity) |
|------------------------------------------------------>|
| +--------------------------------+
| | Server recognizes the identity |
| | and agrees on using fast |
| | re-authentication |
| +--------------------------------+
| EAP-Request/AKA-Reauthentication |
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER, |
| *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) |
|<------------------------------------------------------|
| |
: :
: :
同輩固有識別文字| | | EAP-要求/アイデンティティ| |<------------------------------------------------------| | | | EAP-応答/アイデンティティ| | (速い再認証のアイデンティティを含んでいます) | |------------------------------------------------------>| | +--------------------------------+ | | サーバはアイデンティティを認識します。| | | 速く使用するときの同意| | | 再認証| | +--------------------------------+ | 別名EAP-要求/Reauthentication| | (_カウンタの*、| | _一回だけ_Sの*、__次の_REAUTH_ID、Macの__IV、ENCR_データにおいて*) | |<------------------------------------------------------| | | : : : :
: :
: :
| |
+-----------------------------------------------+ |
| Peer verifies AT_MAC and the freshness of | |
| the counter. Peer MAY store the new re- | |
| authentication identity for next re-auth. | |
+-----------------------------------------------+ |
| |
| EAP-Response/AKA-Reauthentication |
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, |
| AT_MAC) |
|------------------------------------------------------>|
| +--------------------------------+
| | Server verifies AT_MAC and |
| | the counter |
| +--------------------------------+
| EAP-Success |
|<------------------------------------------------------|
| |
: : : : | | +-----------------------------------------------+ | | 同輩はAT_MACと新しさについて確かめます。| | | カウンタ。 同輩が新しさを保存するかもしれない、再| | | 次の再authのための認証のアイデンティティ。 | | +-----------------------------------------------+ | | | | 別名EAP-応答/Reauthentication| | (| | AT_IV、AT_ENCR_DATA、同じ値がある*AT_COUNTER、AT_MAC) | |------------------------------------------------------>| | +--------------------------------+ | | そしてサーバがAT_MACについて確かめる。| | | カウンタ| | +--------------------------------+ | EAP-成功| |<------------------------------------------------------| | |
Figure 10: Reauthentication
図10: Reauthentication
Arkko & Haverinen Informational [Page 36] RFC 4187 EAP-AKA Authentication January 2006
[36ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
5.5. Fast Re-Authentication Procedure when Counter is Too Small
5.5. CounterがToo Smallであることの速いRe-認証Procedure
If the peer does not accept the counter value of EAP-Request/ AKA-Reauthentication, it indicates the counter synchronization problem by including the encrypted AT_COUNTER_TOO_SMALL in EAP-Response/AKA-Reauthentication. The server responds with EAP-Request/AKA-Challenge to initiate a normal full authentication procedure. This is illustrated in Figure 11. Encrypted attributes are denoted with '*'.
同輩がEAP-要求/AKA-Reauthenticationの対価を受け入れないなら、それは、暗号化されたAT_COUNTERも含んでいることによって、カウンタ同期問題を示します。_EAP-応答/AKA-ReauthenticationのSMALL。 サーバは正常な完全な認証手順に着手するAKA EAP-要求/挑戦で反応します。 これは図11で例証されます。 暗号化された属性は'*'で指示されます。
Peer Authenticator
| EAP-Request/AKA-Identity |
| (AT_ANY_ID_REQ) |
|<------------------------------------------------------|
| |
| EAP-Response/AKA-Identity |
| (AT_IDENTITY) |
| (Includes a fast re-authentication identity) |
|------------------------------------------------------>|
| |
| EAP-Request/AKA-Reauthentication |
| (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/AKA-Reauthentication |
| (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/AKA-Challenge |
|<------------------------------------------------------|
+---------------------------------------------------------------+
| Normal full authentication follows. |
+---------------------------------------------------------------+
| |
同輩固有識別文字| 別名EAP-要求/アイデンティティ| | (__どんな_ID REQのも) | |<------------------------------------------------------| | | | 別名EAP-応答/アイデンティティ| | (_アイデンティティにおける) | | (速い再認証のアイデンティティを含んでいます) | |------------------------------------------------------>| | | | 別名EAP-要求/Reauthentication| | (_カウンタの*、| | _一回だけ_Sの*、__次の_REAUTH_ID、Macの__IV、ENCR_データにおいて*) | |<------------------------------------------------------| +-----------------------------------------------+ | | AT_MACは有効ですが、カウンタは新鮮ではありません。 | | +-----------------------------------------------+ | | 別名EAP-応答/Reauthentication| | (| | __カウンタ、Macの_の*が_ENCR_データで__あまりに小さく打ち返す_IVの*) | |------------------------------------------------------>| | +----------------------------------------------+ | | サーバ、しかし、AT_MACが確かめる、検出| | | その同輩がAT_COUNTERも入れた、_SMALL| | +----------------------------------------------+ | 別名EAP-要求/挑戦| |<------------------------------------------------------| +---------------------------------------------------------------+ | 通常の完全な認証は続きます。 | +---------------------------------------------------------------+ | |
Figure 11: Fast re-authentication counter too small
図11: 速い再認証はあまりに小さく反対します。
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/AKA-Reauthentication. This attribute
図では、上では、最初の3つのメッセージが基本的な速い再認証ケースと同様です。 同輩がそれを検出するとき、対価が新鮮でない、それはAT_COUNTERも含んでいます。_EAP-応答/AKA-ReauthenticationのSMALL属性。 この属性
Arkko & Haverinen Informational [Page 37] RFC 4187 EAP-AKA Authentication January 2006
[37ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
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.
あらゆるデータを含みなさい、ただし、それはサーバが完全な認証を開始するという要求です。 この場合、同輩はサーバの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/AKA-Reauthentication packet. If not, the server terminates the authentication exchange by sending the EAP-Request/AKA-Notification packet with AT_NOTIFICATION code "General failure" (16384). If all checks on the packet are successful, the server transmits an EAP-Request/AKA-Challenge packet and the full authentication procedure is performed as usual. Because the server already knows the subscriber identity, it MUST NOT use the EAP-Request/AKA-Identity packet to request the identity.
_SMALL、サーバは、AT_COUNTERもを受け取り次第AT_MACについて確かめて、そのAT_COUNTERについて確かめます。EAP-要求/AKA-Reauthenticationパケットに同じ対価を含んでいます。 そうでなければ、サーバは、AT_NOTIFICATIONコード「一般失敗」(16384)でAKA EAP-要求/通知パケットを送ることによって、認証交換を終えます。 パケットのすべてのチェックがうまくいくなら、サーバはAKA EAP-要求/挑戦パケットを伝えます、そして、完全な認証手順はいつものように実行されます。 サーバが既に加入者のアイデンティティを知るので、それはアイデンティティを要求するのにAKA EAP-要求/アイデンティティパケットを使用してはいけません。
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-AKA Notifications
6. EAP-別名通知
6.1. General
6.1. 一般
EAP-AKA does not prohibit the use of the EAP Notifications as specified in [RFC3748]. EAP Notifications can be used at any time in the EAP-AKA exchange. It should be noted that EAP-AKA does not protect EAP Notifications. EAP-AKA also specifies method-specific EAP-AKA notifications, which are protected in some cases.
EAP-AKAは[RFC3748]の指定されるとしてのEAP Notificationsの使用を禁止しません。 いつでも、EAP-AKA交換にEAP Notificationsを使用できます。 EAP-AKAがEAP Notificationsを保護しないことに注意されるべきです。 また、EAP-AKAはメソッド特有のEAP-AKA通知を指定します。(いくつかの場合、通知は保護されます)。
The EAP server can use EAP-AKA notifications to convey notifications and result indications (Section 6.2) to the peer.
EAPサーバは、通知と結果指摘(セクション6.2)を同輩に伝えるのにEAP-AKA通知を使用できます。
The server MUST use notifications in cases discussed in Section 6.3.2. When the EAP server issues an EAP-Request/AKA-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/AKA-Notification packet, even if the peer did not recognize the notification code.
サーバはセクション6.3.2で議論した場合における通知を使用しなければなりません。 EAPサーバがAKA EAP-要求/通知パケットを同輩に発行するとき、同輩は通知パケットを処理しなければなりません。 同輩は通知メッセージをユーザに示しているかもしれません、そして、同輩はAKA EAP-応答/通知パケットでEAPサーバに応じなければなりません、同輩が通知コードを認めなかったとしても。
An EAP-AKA full authentication exchange or a fast re-authentication exchange MUST NOT include more than one EAP-AKA notification round.
EAP-AKAの完全な認証交換か速い再認証交換がぐるりと1つ以上のEAP-AKA通知を含んではいけません。
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
通知コードは16ビットの数です。 最も重要なビットはSuccessビットと呼ばれます(Sに噛み付きました)。 Sビットは、通知が失敗を含意するかどうか指定します。 ゼロ(コードは0...32767を評価する)に設定されたSビットがあるコード値は失敗のケースの上で使用されます。 The
Arkko & Haverinen Informational [Page 38] RFC 4187 EAP-AKA Authentication January 2006
[38ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
receipt of a notification code from this range implies failed EAP exchange, so the peer can use the notification as a failure indication. After receiving the EAP-Response/AKA-Notification for these notification codes, the server MUST send the EAP-Failure packet.
この範囲からの通知コードの領収書が失敗したEAP交換を含意するので、同輩は失敗指示として通知を使用できます。 これらの通知コードのためのAKA EAP-応答/通知を受け取った後に、サーバは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-AKA exchange the notification can be used. If the P bit is set to zero, the notification can only be used after a successful EAP/AKA- Challenge round in full authentication or a successful EAP/AKA- Reauthentication round in re-authentication. 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/AKA-Reauthentication.
通知コードの2番目の最上位ビットはPhaseビットと呼ばれます(Pに噛み付きました)。 それは、EAP-AKA交換のどのフェーズに通知を使用できるかを指定します。 Pビットがゼロに設定されるなら、うまくいっているEAP/AKA挑戦の後に再認証で丸い完全な認証かうまくいっているEAP/AKA- Reauthenticationでぐるりと通知を使用できるだけです。 同輩が首尾よくAT_MACとAT_COUNTER属性について確かめて、_また、AT_COUNTERを入れない場合にだけ、再認証ラウンドはうまくいくと考えられます。_EAP-応答/AKA-ReauthenticationのSMALL属性。
If the P bit is set to one, the notification can only by used before the EAP/AKA-Challenge round in full authentication or before the EAP/AKA-Reauthentication 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/AKA-挑戦かEAP/AKA-Reauthenticationが再認証を引っ込める前に使用されるだけである通知缶です。 様々な失敗事件を示すのにこれらの通知を使用できるだけです。 言い換えれば、Pビットが1つに設定されるなら、Sビットをゼロに設定しなければなりません。
Section 9.10 and Section 9.11 specify what other attributes must be included in the notification packets.
セクション9.10とセクション9.11は、通知パケットにどんな他の属性を含まなければならないかを指定します。
Some of the notification codes are authorization related and hence not usually considered as part of the responsibility of an EAP method. However, they are included as part of EAP-AKA 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-AKA server implementation may decide never to send these EAP-AKA notifications.
通知コードのいくつかが話されて、したがって通常、EAPメソッドの責任の一端であることはみなされなかった承認です。 しかしながら、現在、ローカライズ可能道、および情報のユーザにこの情報を伝える他の方法が全くないのでEAP-AKAの部分が潜在的にユーザの役に立つので、それらは含まれています。 EAP-AKAサーバ実装は、これらのEAP-AKA通知を決して送らないと決めるかもしれません。
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-AKA notification to indicate failure to the peer. In this case, the result indication is integrity and replay protected.
セクション6.3で議論するように、サーバと同輩はすべての誤り事件の明白なエラーメッセージを使用します。 サーバがうまくいっている認証の後に誤りを検出するなら、サーバは、失敗を同輩に示すのにEAP-AKA通知を使用します。 この場合、結果指示は保全です、そして、再生は保護されました。
Arkko & Haverinen Informational [Page 39] RFC 4187 EAP-AKA Authentication January 2006
[39ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
By sending an EAP-Response/AKA-Challenge packet or an EAP-Response/AKA-Reauthentication 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.
AKA EAP-応答/挑戦パケットかEAP-応答/AKA-Reauthenticationパケットを送る、(AT_COUNTER、も_SMALL)、同輩は、首尾よくサーバを認証して、同輩のローカルの方針がEAP交換を受け入れるのを示します。 言い換えれば、同輩からサーバまでこれらのパケットは暗黙の成功指摘です。
EAP-AKA 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/AKA-Challenge or the EAP-Request/AKA-Reauthentication 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/AKA-Challenge or EAP-Response/AKA-Reauthentication. 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-AKA notification round will follow. The following EAP-AKA notification may indicate either failure or success.
また、EAP-AKAは、サーバから同輩まで任意の保護された成功が指摘であるとサポートします。 EAPサーバが保護された成功指摘を使用したいと思うなら、それはAKA EAP-要求/挑戦かEAP-要求/AKA-ReauthenticationパケットにAT_RESULT_IND属性を含んでいます。 この属性は、EAPサーバがうまくいっていて失敗の両方の場合に結果指摘を使用したがっているのを示します。 また、同輩がこれが欲しいなら、同輩はAKA EAP-応答/挑戦かEAP-応答/AKA-ReauthenticationでAT_RESULT_INDを入れます。 サーバからAT_RESULT_INDを受けなかったなら、同輩はAT_RESULT_INDを入れてはいけません。同輩とサーバの両方がAT_RESULT_INDを使用したなら、EAP交換はまだ完全ではありませんが、EAP-AKA通知ラウンドは続くでしょう。 以下のEAP-AKA通知は失敗か成功のどちらかを示すかもしれません。
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/AKA-Challenge or EAP-Request/AKA-Reauthentication 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を入れなかったならサーバがAKA EAP-要求/挑戦かEAP-要求/AKA-Reauthenticationパケットに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-AKA response to this notification. Hence, the server MUST ignore the contents of the EAP-AKA response it receives to the EAP-Request/AKA-Notification with this code. Regardless of the contents of the EAP-AKA response, the server MUST send EAP-Success as the next packet.
サーバが示すEAP交換が首尾よく完成したAT_NOTIFICATIONコード「成功」(32768)を使用するので、サーバがこの通知へのEAP-AKA応答を処理するとき、EAP交換は失敗できません。 したがって、サーバはそれがこのコードでAKA EAP-要求/通知に受けるEAP-AKA応答のコンテンツを無視しなければなりません。 EAP-AKA応答のコンテンツにかかわらず、サーバは次のパケットとしてEAP-成功を送らなければなりません。
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-AKA peer and server to send an error packet (EAP-Response/AKA-Client-Error, EAP-Response/AKA-Authentication-Reject or EAP-Response/AKA-Synchronization-Failure from the peer and EAP-Request/AKA-Notification from the server) in error cases. However, implementations SHOULD NOT rely upon the correct error reporting behavior of the peer, authenticator, or server. It is possible for error messages and other messages to be lost in transit,
このセクションは同輩の操作とサーバの間違ったケースを指定します。 以下の小区分は、誤りパケット(同輩からのAKA同期のAKAクライアントEAP-応答/誤り、AKA認証EAP-応答/廃棄物またはEAP-応答/故障とサーバからのAKA EAP-要求/通知)に間違ったケースを送るためにEAP-AKA同輩とサーバを必要とします。 しかしながら、実装SHOULD NOTはエラーメッセージと他のトランジットで失われるべきメッセージに、サーバ同輩、固有識別文字、またはそれの動きが可能であると報告する正しい誤りを当てにします。
Arkko & Haverinen Informational [Page 40] RFC 4187 EAP-AKA Authentication January 2006
[40ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
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サーバSHOULDの両方には、エラーメッセージかEAP-成功がタイムアウト時間の後に受け取られないでも、状態に掃除するメカニズムがあります。
6.3.1. Peer Operation
6.3.1. 同輩操作
Two special error messages have been specified for error cases that are related to the processing of the AKA AUTN parameter, as described in Section 3: (1) if the peer does not accept AUTN, the peer responds with EAP-Response/AKA-Authentication-Reject (Section 9.5), and the server issues EAP-Failure, and (2) if the peer detects that the sequence number in AUTN is not correct, the peer responds with EAP-Response/AKA-Synchronization-Failure (Section 9.6), and the server proceeds with a new EAP-Request/AKA-Challenge.
2つの特別なエラーメッセージがAKA AUTNパラメタの処理に関連する誤り事件に指定されました、セクション3で説明されるように: (1) 同輩がAUTNを受け入れないで、また同輩がAKA認証EAP-応答/廃棄物(セクション9.5)で応じて、サーバがEAP-失敗を発行して、(2) 同輩がそれを検出するならAUTNの一連番号が適度でないなら、同輩はAKA同期のEAP-応答/故障(セクション9.6)で応じます、そして、サーバはAKA新しいEAP-要求/挑戦を続けます。
In other error cases, when an EAP-AKA peer detects an error in a received EAP-AKA packet, the EAP-AKA peer responds with the EAP-Response/AKA-Client-Error packet. In response to the EAP-Response/AKA-Client-Error, the EAP server MUST issue the EAP-Failure packet, and the authentication exchange terminates.
EAP-AKA同輩が容認されたEAP-AKAパケットに誤りを検出するときの他の誤り事件では、EAP-AKA同輩はAKAクライアントEAP-応答/誤りパケットで応じます。 AKAクライアントEAP-応答/誤りに対応して、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 The peer is not able to parse the EAP request, i.e., the EAP
request is malformed.
o The peer encountered a malformed attribute.
o Wrong attribute types or duplicate attributes have been included
in the EAP request.
o A mandatory attribute is missing.
o Unrecognized non-skippable attribute.
o Unrecognized or unexpected EAP-AKA Subtype in the EAP request.
o Invalid AT_MAC. The peer SHOULD log this event.
o Invalid AT_CHECKCODE. The peer SHOULD log this event.
o Invalid pad bytes in AT_PADDING.
o The peer does not want to process AT_PERMANENT_ID_REQ.
o 同輩のローカルの方針によると、EAP交換は許容できません。○ 同輩がEAP要求を分析できない、すなわち、EAP要求は奇形です。○ 同輩は奇形の属性に遭遇しました。o Wrong属性タイプか写し属性がEAP要求に含まれています。o A義務的な属性は、取り逃がすo Unrecognized非skippable属性o UnrecognizedかEAP要求. o Invalid AT_MACで予期していなかったEAP-AKA Subtypeです。 同輩SHOULDはこのイベント. o Invalid AT_CHECKCODEを登録します。 同輩SHOULDはこのイベントを登録します。AT_PADDING○ 同輩のo Invalidパッドバイトは_AT_PERMANENT_ID REQを処理したがっていません。
6.3.2. Server Operation
6.3.2. サーバ操作
If an EAP-AKA server detects an error in a received EAP-AKA response,
the server MUST issue the EAP-Request/AKA-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
EAP-AKAサーバが容認されたEAP-AKA応答における誤りを検出するなら、サーバは失敗を含意するAT_NOTIFICATIONコードでAKA EAP-要求/通知パケットを発行しなければなりません。 デフォルトで、サーバは一般的な失敗コードの1つを使用します。(「認証の後の一般失敗」(0)か「一般失敗」(16384))。 選択
Arkko & Haverinen Informational [Page 41] RFC 4187 EAP-AKA Authentication January 2006
[41ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
between these two codes depends on the phase of the EAP-AKA exchange, see Section 6. The error cases when the server issues an EAP-Request/AKA-Notification that implies failure include the following:
セクション6は、これらの2つのコードの間では、交換をEAP-AKAのフェーズに依存しているのを見ます。 サーバが失敗を含意するAKA EAP-要求/通知を発行するとき、誤り事件は以下を含んでいます:
o The server is not able to parse the peer's EAP response.
o The server encounters a malformed attribute, a non-recognized
non-skippable attribute, or a duplicate attribute.
o A mandatory attribute is missing or an invalid attribute was
included.
o Unrecognized or unexpected EAP-AKA Subtype in the EAP Response.
o Invalid AT_MAC. The server SHOULD log this event.
o Invalid AT_CHECKCODE. The server SHOULD log this event.
o Invalid AT_COUNTER.
o サーバは同輩のEAP応答を分析できません。○ サーバは奇形の属性、非認識された非skippable属性、または写し属性に出会います。属性がなくなるのが義務的なo Aか無効の属性がEAP Responseの含まれている. o Unrecognizedの、または、予期していなかったEAP-AKA Subtypeでした。. o Invalid AT_MAC。 サーバSHOULDはこのイベント. o Invalid AT_CHECKCODEを登録します。 サーバSHOULDはこのイベント. o Invalid AT_COUNTERを登録します。
6.3.3. EAP-Failure
6.3.3. EAP-失敗
The EAP-AKA server sends EAP-Failure in three cases:
EAP-AKAサーバは3つの場合におけるEAP-失敗を送ります:
1. In response to an EAP-Response/AKA-Client-Error packet the server
has received from the peer, or
1. またはAKAクライアントEAP-応答/誤りパケットに対応してサーバが同輩から受信された。
2. In response to an EAP-Response/AKA-Authentication-Reject packet
the server has received from the peer, or
2. またはAKA認証EAP-応答/廃棄物パケットに対応してサーバが同輩から受信された。
3. Following an EAP-AKA notification round, when the AT_NOTIFICATION
code implies failure.
3. AT_NOTIFICATIONコードが失敗を含意するとき、ぐるりとEAP-AKA通知に続きます。
The EAP-AKA server MUST NOT send EAP-Failure in other cases than these three. However, it should be noted that even though the EAP-AKA server would not send an EAP-Failure, an authorization decision that happens outside EAP-AKA, such as in the AAA server or in an intermediate AAA proxy, may result in a failed exchange.
EAP-AKAサーバはこれらの3以外の場合におけるEAP-失敗を送ってはいけません。 しかしながら、EAP-AKAサーバがEAP-失敗を送らないでしょうが、AAAサーバや中間的AAAプロキシなどのEAP-AKAの外で起こる承認決定が失敗した交換をもたらすかもしれないことに注意されるべきです。
The peer MUST accept the EAP-Failure packet in case 1), case 2), and case 3) above. The peer SHOULD silently discard the EAP-Failure packet in other cases.
同輩は、場合1)、場合2)、および場合3)における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/AKA-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/AKA-Challenge packet.
完全な認証のときに、サーバはEAP/AKA-挑戦の後にぐるりとEAP-成功を送ることができるだけです。 同輩が首尾よくサーバを認証する前に受け取って、AKA EAP-応答/挑戦パケットを送るなら、同輩は静かにどんなEAP-成功パケットも捨てなければなりません。
Arkko & Haverinen Informational [Page 42] RFC 4187 EAP-AKA Authentication January 2006
[42ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
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/AKA-Challenge round.
同輩が、完全な認証のときにAT_RESULT_INDとの保護された成功指摘(セクション6.2で議論するように)を使用したがっているのを示さなかったなら、同輩は、うまくいっているEAP/AKA-挑戦の後の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/ AKA-Challenge round. In this case, the peer MUST only accept EAP-Success after receiving an EAP-AKA Notification with the AT_NOTIFICATION code "Success" (32768).
同輩が、AT_RESULT_INDとの保護された成功指摘を使用したがっているのを示したなら(セクション6.2で議論するように)、同輩は、うまくいっているEAP/ AKA-挑戦の後のEAP-成功が丸いと受け入れてはいけません。 この場合、AT_NOTIFICATIONコード「成功」(32768)でEAP-AKA Notificationを受けた後に、同輩はEAP-成功を受け入れるだけでよいです。
On fast re-authentication, EAP-Success can only be sent after the EAP/AKA-Reauthentication 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/AKA-Reauthentication packet.
速い再認証のときに、EAP/AKA-Reauthenticationの後にぐるりとEAP-成功を送ることができるだけです。 同輩が首尾よくサーバを認証する前に受け取って、EAP-応答/AKA-Reauthenticationパケットを送るなら、同輩は静かにどんな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 re-authentication, then the peer MUST accept EAP-Success after a successful EAP/AKA-Reauthentication round.
同輩が、速い再認証のときにAT_RESULT_INDとの保護された成功指摘(セクション6.2で議論するように)を使用したがっているのを示さなかったなら、同輩は、うまくいっているEAP/AKA-Reauthenticationの後の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/AKA- Reauthentication round. In this case, the peer MUST only accept EAP-Success after receiving an EAP-AKA Notification with the AT_NOTIFICATION code "Success" (32768).
同輩が、AT_RESULT_INDとの保護された成功指摘を使用したがっているのを示したなら(セクション6.2で議論するように)、同輩は、うまくいっているEAP/AKA- Reauthenticationの後のEAP-成功が丸いと受け入れてはいけません。 この場合、AT_NOTIFICATIONコード「成功」(32768)でEAP-AKA Notificationを受けた後に、同輩はEAP-成功を受け入れるだけでよいです。
If the peer receives an EAP-AKA 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-AKA通知(セクション6)を受け取るなら、同輩はもうEAP-成功パケットを受け入れてはいけません、サーバ証明が首尾よく終了されたとしても。
7. Key Generation
7. キー生成
This section specifies how keying material is generated.
このセクションは材料を合わせるのがどう発生しているかを指定します。
On EAP-AKA full authentication, a Master Key (MK) is derived from the underlying AKA values (CK and IK keys), and the identity, as follows.
EAP-AKAの完全な認証のときに、基本的なAKA値(CKとIKキー)、およびアイデンティティからMaster Key(MK)を得ます、以下の通りです。
MK = SHA1(Identity|IK|CK)
MKはSHA1と等しいです。(アイデンティティ|IK|CK)
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
「上の公式で」|「キャラクタは連結を指示します。」 アイデンティティは少しも終端空文字なしで同輩アイデンティティストリングを指示します。 AT_IDENTITYがアイデンティティであったなら、それはまたは同輩がこの交換で送られた最後のAT_IDENTITY属性からのアイデンティティです。
Arkko & Haverinen Informational [Page 43] RFC 4187 EAP-AKA Authentication January 2006
[43ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
not used, the identity from the EAP-Response/Identity packet. The identity string is included as-is, without any changes. As discussed in Section 4.1.2.2, relying on EAP-Response/Identity for conveying the EAP-AKA peer identity is discouraged, and the server SHOULD use the EAP-AKA method-specific identity attributes. The hash function SHA-1 is specified in [SHA-1].
使用されない、EAP-応答/アイデンティティパケットからのアイデンティティ。 アイデンティティストリングは少しも変化なしでそのままで含まれています。 セクション4.1.2で議論して、.2、信用がEAP-AKAを運ぶためのEAP-応答/アイデンティティをじっと見るとき、アイデンティティはがっかりしています、そして、サーバSHOULDはEAP-AKAのメソッド特有のアイデンティティ属性を使用します。 ハッシュ関数SHA-1は[SHA-1]で指定されます。
The Master Key is fed into a Pseudo-Random number Function (PRF), which generates separate Transient EAP Keys (TEKs) for protecting EAP-AKA 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.
Pseudo-乱数Function(PRF)にMaster Keyを与えます、リンクレイヤセキュリティのためのMaster Session Key(MSK)と他の目的のためのExtended Master Session Key(EMSK)と同様に。(Functionは、EAP-AKAパケットを保護するために、別々のTransient EAPキーズ(TEKs)を生成します)。 速い再認証のときに、EAPパケットを保護するのに同じTEKsを使用しなければなりませんでしたが、オリジナルから派生しているMKと新しい値からの新しいMSKと新しいEMSK MUSTは速さで再認証を交換しました。
EAP-AKA requires two TEKs for its own purposes: the authentication key K_aut, to be used with the AT_MAC attribute, and the encryption key K_encr, 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-AKAはそれ自身の目的のために2TEKsを必要とします: 認証の主要なK_は、AT_ENCR_DATA属性と共に使用されるのにAT_MAC属性、および暗号化の主要なK_encrと共に使用されるためにautします。 同じ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 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 Annex A.
主要な派生はNISTの連邦政府の情報Processing Standards(FIPS)公表186-2[PRF]で指定された乱数発生に基づいています。 疑似乱数生成器は[PRF](アルゴリズム1)の変更通知1つ(2001年の10月5日)で指定されます。 Algorithm1が汎用疑似乱数生成器として使用されるとき、変更通知(74ページ)で指定されるように、ステップ3.3における「モッズq」用語は省略されます。 アルゴリズムで使用される機能Gは規格のAppendix3.3の指定されるとしてのSecure Hash Standardを通して構成されます。 機能GがSHA-1と非常に同様であることに注意されるべきですが、メッセージ詰め物は異なっています。 一部始終について[PRF]を参照してください。 便利において、正しい変更がある乱数アルゴリズムはAnnex Aで引用されます。
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ビットの無作為のNo.x_0、x_1に関して…, x_m-1は連結されて、適当サイズの塊に仕切られて、キーとして以下のオーダーで使用されます: K_encr(128ビット)、K_aut(128ビット)、Master Session Key(64バイト)、Extended Master Session Key(64バイト)。
Arkko & Haverinen Informational [Page 44] RFC 4187 EAP-AKA Authentication January 2006
[44ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
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/AKA-Identity packet, or, if EAP-Response/AKA-Identity 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/AKA-Reauthentication packet. The counter is used in network byte order. NONCE_S denotes the 16-byte random NONCE_S value from the AT_NONCE_S attribute used in the EAP-Request/AKA-Reauthentication packet. The MK is the Master Key derived on the preceding full authentication.
上では、Identityが指示する公式では、AKA EAP-応答/アイデンティティパケットのAT_IDENTITY属性からの少しも終端空文字がいなければ速い再認証のアイデンティティであり、AKA EAP-応答/アイデンティティが速い再認証のときに使用されなかったなら、それがEAP-応答/アイデンティティパケットからアイデンティティストリングを指示します。 カウンタはEAP-応答/AKA-Reauthenticationパケットで使用されるAT_COUNTER属性から対価を指示します。 カウンタはネットワークバイトオーダーに使用されます。 NONCE_SはEAP-要求/AKA-Reauthenticationパケットで使用される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 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ビットの無作為のNo.x_0、x_1…, x_m-1は新しい64バイトのMaster Session Keyと新しい64バイトのExtended Master Session Keyとして連結されて、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バイトの合わせるだけが使用されています。
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 Length and Identifier fields in the EAP header is also specified in [RFC3748]. In EAP-AKA, the Type field is set to 23.
[RFC3748]で指定されるように、EAPパケットはEAPメソッド詳細Type-データがあとに続くCode、Identifiers、Length、およびType分野で始まります。 EAPヘッダーのCode分野はEAP要求のための1と、そして、EAP Responsesのための2に設定されます。 また、EAPヘッダーのLengthとIdentifier分野の用法は[RFC3748]で指定されます。 EAP-AKAでは、Type分野は23に設定されます。
Arkko & Haverinen Informational [Page 45] RFC 4187 EAP-AKA Authentication January 2006
[45ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
In EAP-AKA, the Type-Data begins with an EAP-AKA header that consists of a 1-octet Subtype field, and a 2-octet reserved field. The Subtype values used in EAP-AKA are defined in Section 11. The formats of the EAP header and the EAP-AKA header are shown below.
EAP-AKAでは、Type-データは1八重奏のSubtype分野、および2八重奏の予約された分野から成るEAP-AKAヘッダーと共に始まります。 EAP-AKAで使用されるSubtype値はセクション11で定義されます。 EAPヘッダーとEAP-AKAヘッダーの書式は以下に示されます。
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, immediately following the EAP-AKA header, consists of attributes that are encoded in Type, Length, Value format. The figure below shows the generic format of an attribute.
すぐにEAP-AKAヘッダーに続いて、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Attribute 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 Section 11.
特定のタイプの属性を示します。 属性タイプ値はセクション11に記載されています。
Length
長さ
Indicates the length of this attribute in multiples of 4 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 is two or more bytes in length. The
type and length fields determine the format and length of the
value field.
この属性に関連している特定のデータ。 この分野はいつも含まれています、そして、それは長さが2バイト以上です。 タイプと長さの分野は値の分野の形式と長さを測定します。
Attributes numbered within the range 0 through 127 are called non-skippable attributes. When an EAP-AKA peer encounters a non-skippable attribute type that the peer does not recognize, the peer MUST send the EAP-Response/AKA-Client-Error packet, and the authentication exchange terminates. If an EAP-AKA server encounters a non-skippable attribute that the server does not recognize, then the server sends EAP-Request/AKA-Notification packet with an
範囲の中で0〜127に付番された属性は非skippable属性と呼ばれます。 EAP-AKA同輩が同輩が認めない非skippable属性タイプに遭遇すると、同輩はAKAクライアントEAP-応答/誤りパケットを送らなければなりません、そして、認証交換は終わります。 EAP-AKAサーバは次にサーバが、サーバがAKA EAP-要求/通知パケットを送ると認めない非skippable属性に遭遇します。
Arkko & Haverinen Informational [Page 46] RFC 4187 EAP-AKA Authentication January 2006
[46ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
AT_NOTIFICATION code that implies general failure ("General failure
after authentication" (0), or "General failure" (16384), depending on
the phase of the exchange), and the authentication exchange
terminates.
一般的な失敗(「認証の後の一般失敗」(0)、または交換のフェーズに依存する「一般失敗」(16384))を含意するAT_NOTIFICATIONコード、および交換が終える認証。
When an attribute numbered in the range 128 through 255 is encountered but not recognized, that particular attribute is ignored, but 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 when searching for the next attribute. These attributes are called skippable attributes.
範囲で128〜255に付番された属性が遭遇しますが、認識されないとき、その特定の属性は無視されますが、まだ属性とメッセージデータの残りを処理しなければなりません。 属性のLength分野は、次の属性を捜し求めるとき、属性値をスキップするのに使用されます。 これらの属性はskippable属性と呼ばれます。
Unless otherwise specified, the order of the attributes in an EAP-AKA message is insignificant, and an EAP-AKA implementation should not assume a certain order will be used.
別の方法で指定されない場合、EAP-AKAメッセージにおける、属性の注文は意味をなしません、そして、EAP-AKA実装はあるオーダーが使用されると仮定するべきではありません。
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-AKA can be extended by specifying new attribute types. If skippable attributes are used, it is possible to extend the protocol without breaking old implementations. As specified in Section 10.13, if new attributes are specified for EAP-Request/AKA-Identity or EAP-Response/AKA-Identity, then the AT_CHECKCODE MUST be used to integrity protect the new attributes.
新しい属性タイプを指定することによって、EAP-AKAを広げることができます。 skippable属性が使用されているなら、壊れている古い実装なしでプロトコルを広げるのは可能です。 使用されて、保全に、新しい属性が保護されているという指定されるようにセクション10.13 次に、AT_CHECKCODE MUSTでは、新しい属性がAKA EAP-要求/アイデンティティかAKA EAP-応答/アイデンティティに指定されるならことになってください。
When specifying new attributes, it should be noted that EAP-AKA 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-AKA SHOULD NOT exceed the EAP MTU of 1020 bytes.
新しい属性を指定するとき、EAP-AKAがメッセージ断片化をサポートしないことに注意されるべきです。 したがって、新しい拡大のサイズを制限しなければならないので、基本的な下層の最大の移動単位数(MTU)は超えられていません。 [RFC3748]に応じて下層が1020バイト以上のEAP MTUを提供しなければならないので、EAP-AKA SHOULD NOTへのどんな拡大も1020バイトのEAP MTUを超えています。
EAP-AKA packets do not include a version field. However, should there be a reason to revise this protocol in the future, new non-skippable or skippable attributes could be specified in order to implement revised EAP-AKA versions in a backward-compatible manner. It is possible to introduce version negotiation in the EAP-Request/AKA-Identity and EAP-Response/AKA-Identity messages by specifying new skippable attributes.
EAP-AKAパケットはバージョン分野を含んでいません。 しかしながら、将来このプロトコルを改訂する理由があれば、新しい非skippableであるかskippableな属性は、後方コンパチブル方法で改訂されたEAP-AKAバージョンを実装するために指定されるかもしれません。 新しいskippable属性を指定することによってAKA EAP-要求/アイデンティティとAKA EAP-応答/アイデンティティメッセージにおけるバージョン交渉を導入するのは可能です。
Arkko & Haverinen Informational [Page 47] RFC 4187 EAP-AKA Authentication January 2006
[47ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
9. Messages
9. メッセージ
This section specifies the messages used in EAP-AKA. It specifies when a message may be transmitted or accepted, which attributes are allowed in a message, which attributes are required in a message, and other message-specific details. Message format is specified in Section 8.1.
このセクションはEAP-AKAで使用されるメッセージを指定します。 それはいつメッセージを送るか、または受け入れるかもしれないか、そして、どの属性がメッセージに許容されているか、そして、どの属性がメッセージで必要であるか、そして、他のメッセージ特有の詳細を指定します。 メッセージ・フォーマットはセクション8.1で指定されます。
9.1. EAP-Request/AKA-Identity
9.1. 別名EAP-要求/アイデンティティ
The EAP/AKA-Identity roundtrip MAY be used for obtaining the peer identity from the server. As discussed in Section 4.1, several AKA-Identity rounds may be required in order to obtain a valid peer identity.
EAP/AKA-アイデンティティ往復旅行は、サーバから同輩のアイデンティティを得るのに使用されるかもしれません。セクション4.1で議論するように、いくつかのAKA-アイデンティティラウンドが有効な同輩のアイデンティティを得るのに必要であるかもしれません。
The server MUST include one of the following identity requesting attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, 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 previously issued an EAP-Request/AKA-Identity message with the AT_PERMANENT_ID_REQ attribute, and if the server has received a response from the peer, then the server MUST NOT issue a new EAP-Request/AKA-Identity packet.
サーバが以前にAT_PERMANENT_ID_REQ属性でAKA EAP-要求/アイデンティティメッセージを発行して、サーバが同輩から応答を受けたなら、サーバはAKA新しいEAP-要求/アイデンティティパケットを発行してはいけません。
If the server has previously issued an EAP-Request/AKA-Identity message with the AT_FULLAUTH_ID_REQ attribute, and if the server has received a response from the peer, then the server MUST NOT issue a new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ or AT_FULLAUTH_ID_REQ attributes.
サーバが以前にAT_FULLAUTH_ID_REQ属性でAKA EAP-要求/アイデンティティメッセージを発行して、サーバが同輩から応答を受けたなら、サーバは、ATがあるAKA新しいEAP-要求/アイデンティティパケットに__どんな_ID REQも発行するか、または_ID_REQ属性をAT_FULLAUTHに発行してはいけません。
If the server has previously issued an EAP-Request/AKA-Identity message with the AT_ANY_ID_REQ attribute, and if the server has received a response from the peer, then the server MUST NOT issue a new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ.
サーバが以前にATがあるAKA EAP-要求/アイデンティティメッセージに_どんな_ID_REQ属性も発行して、サーバが同輩から応答を受けたなら、サーバはATがあるAKA新しいEAP-要求/アイデンティティパケットに__どんな_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/AKA-Identity
9.2. 別名EAP-応答/アイデンティティ
The peer sends EAP-Response/AKA-Identity in response to a valid EAP-Request/AKA-Identity from the server.
同輩はサーバからのAKA有効なEAP-要求/アイデンティティに対応してAKA EAP-応答/アイデンティティを送ります。
The peer MUST include the AT_IDENTITY attribute. The usage of AT_IDENTITY is defined in Section 4.1.
同輩はAT_IDENTITY属性を入れなければなりません。 AT_IDENTITYの使用法はセクション4.1で定義されます。
This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA.
このメッセージはAT_MAC、AT_IV、またはAT_ENCR_DATAを含んではいけません。
Arkko & Haverinen Informational [Page 48] RFC 4187 EAP-AKA Authentication January 2006
[48ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
9.3. EAP-Request/AKA-Challenge
9.3. 別名EAP-要求/挑戦
The server sends the EAP-Request/AKA-Challenge on full authentication after successfully obtaining the subscriber identity.
首尾よく加入者のアイデンティティを得た後に、サーバはAKA EAP-要求/挑戦を完全な認証に送ります。
The AT_RAND attribute MUST be included.
AT_RAND属性を含まなければなりません。
AT_MAC MUST be included. In EAP-Request/AKA-Challenge, there is no message-specific data covered by the MAC, see Section 10.15.
AT_Macを含まなければなりません。 セクション10.15は、AKA EAP-要求/挑戦には、MACでカバーされたどんなメッセージ特有のデータもないのを見ます。
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_CHECKCODE attribute MAY be included, and in certain cases specified in Section 10.13, it MUST be included.
AT_CHECKCODE属性は含まれるかもしれません、そして、セクション10.13で指定されたある場合では、それを含まなければなりません。
The EAP-Request/AKA-Challenge packet MAY include encrypted attributes for identity privacy and for communicating the next re-authentication identity. In this case, the AT_IV and AT_ENCR_DATA attributes are included (Section 10.12).
AKA EAP-要求/挑戦パケットはアイデンティティプライバシーと次の再認証のアイデンティティを伝えるための暗号化された属性を含むかもしれません。 この場合、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. Later versions of this protocol MAY specify additional attributes to be included within the encrypted data.
AT_ENCR_DATA値の分野の平文は入れ子にされた属性から成ります。 入れ子にされた属性はAT_PADDINGを含むかもしれません(セクション10.12で指定されるように)。 サーバがアイデンティティがプライバシーであるとサポートして、次の完全な認証のために匿名を同輩に伝えたいなら、入れ子にされた暗号化された属性はAT_ネクスト_PSEUDONYM属性を含んでいます。 サーバが再認証をサポートして、同輩への速い再認証のアイデンティティを伝えたいなら、入れ子にされた暗号化された属性はAT_ネクスト_REAUTH_ID属性を含んでいます。 このプロトコルの後のバージョンは、暗号化されたデータの中に含まれるように追加属性を指定するかもしれません。
When processing this message, the peer MUST process AT_RAND and AT_AUTN before processing other attributes. Only if these attributes are 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_AUTNを処理しなければなりません。 これらの属性が有効になるように確かめられる場合にだけ、同輩は、キーを引き出して、AT_MACについて確かめます。 誤りが発生するといけないので、操作はセクション6.3.1で指定されます。
9.4. EAP-Response/AKA-Challenge
9.4. 別名EAP-応答/挑戦
The peer sends EAP-Response/AKA-Challenge in response to a valid EAP-Request/AKA-Challenge.
同輩はAKA有効なEAP-要求/挑戦に対応してAKA EAP-応答/挑戦を送ります。
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/AKA-Challenge, but the peer MUST send EAP-Response/AKA-Client-Error.
このパケットを送るのは、同輩が首尾よくサーバを認証して、EAP交換が同輩のローカルの方針で受け入れられるのを示します。 したがって、これらの条件が満たされないなら、同輩はAKA EAP-応答/挑戦を送ってはいけませんが、同輩はAKAクライアントEAP-応答/誤りを送らなければなりません。
Arkko & Haverinen Informational [Page 49] RFC 4187 EAP-AKA Authentication January 2006
[49ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
The AT_MAC attribute MUST be included. In EAP-Response/AKA-Challenge, there is no message-specific data covered by the MAC, see Section 10.15.
AT_MAC属性を含まなければなりません。 セクション10.15は、AKA EAP-応答/挑戦には、MACでカバーされたどんなメッセージ特有のデータもないのを見ます。
The AT_RES attribute MUST be included.
AT_RES属性を含まなければなりません。
The AT_CHECKCODE attribute MAY be included, and in certain cases specified in Section 10.13, it MUST be included.
AT_CHECKCODE属性は含まれるかもしれません、そして、セクション10.13で指定されたある場合では、それを含まなければなりません。
The AT_RESULT_IND attribute MAY be included, if it was included in EAP-Request/AKA-Challenge. The usage of this attribute is discussed in Section 6.2.
それがAKA EAP-要求/挑戦に含まれていたなら、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/AKA-Challenge messages that include these attributes even if the server did not implement these optional attributes.
このプロトコルの後のバージョンはAT_ENCR_DATAとAT_IVの使用を暗号化された(skippable)属性を含むこのメッセージの属性にするかもしれません。 EAPサーバはサーバが、これらが任意の属性であると実装しなかったとしてもこれらの属性を含んでいるAKA EAP-応答/挑戦メッセージを処理しなければなりません。
9.5. EAP-Response/AKA-Authentication-Reject
9.5. 別名認証EAP-応答/廃棄物
The peer sends the EAP-Response/AKA-Authentication-Reject packet if it does not accept the AUTN parameter. This version of the protocol does not specify any attributes for this message. Future versions of the protocol MAY specify attributes for this message.
それがAUTNパラメタを受け入れないなら、同輩はAKA認証EAP-応答/廃棄物パケットを送ります。 プロトコルのこのバージョンはこのメッセージにどんな属性も指定しません。 プロトコルの将来のバージョンはこのメッセージに属性を指定するかもしれません。
The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in this message.
このメッセージでAT_Mac、AT_ENCR_DATA、またはAT_IV属性を使用してはいけません。
9.6. EAP-Response/AKA-Synchronization-Failure
9.6. 別名同期EAP-応答/失敗
The peer sends the EAP-Response/AKA-Synchronization-Failure, when the sequence number in the AUTN parameter is incorrect.
AUTNパラメタの一連番号が不正確であるときに、同輩はAKA同期のEAP-応答/故障を送ります。
The peer MUST include the AT_AUTS attribute. Future versions of the protocol MAY specify other additional attributes for this message.
同輩はAT_AUTS属性を入れなければなりません。 プロトコルの将来のバージョンは他の追加属性をこのメッセージに指定するかもしれません。
The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in this message.
このメッセージでAT_Mac、AT_ENCR_DATA、またはAT_IV属性を使用してはいけません。
9.7. EAP-Request/AKA-Reauthentication
9.7. 別名EAP-要求/Reauthentication
The server sends the EAP-Request/AKA-Reauthentication 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/AKA-Identity.
速い再認証を使用したがっていて、EAP-応答/アイデンティティかAKA EAP-応答/アイデンティティにおける有効な速い再認証のアイデンティティを受けたなら、サーバはEAP-要求/AKA-Reauthenticationメッセージを送ります。
Arkko & Haverinen Informational [Page 50] RFC 4187 EAP-AKA Authentication January 2006
[50ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
The AT_MAC attribute MUST be included. No message-specific data is included in the MAC calculation, see Section 10.15.
AT_MAC属性を含まなければなりません。 セクション10.15は、どんなメッセージ特有のデータもMAC計算に含まれていないのを見ます。
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_CHECKCODE attribute MAY be included, and in certain cases specified in Section 10.13, it MUST be included.
AT_CHECKCODE属性は含まれるかもしれません、そして、セクション10.13で指定されたある場合では、それを含まなければなりません。
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.8. EAP-Response/AKA-Reauthentication
9.8. 別名EAP-応答/Reauthentication
The client sends the EAP-Response/AKA-Reauthentication packet in response to a valid EAP-Request/AKA-Reauthentication.
クライアントは有効なEAP-要求/AKA-Reauthenticationに対応してEAP-応答/AKA-Reauthenticationパケットを送ります。
The AT_MAC attribute MUST be included. For EAP-Response/AKA-Reauthentication, the MAC code is calculated over the following data: EAP packet| NONCE_S. The EAP packet is represented as specified in Section 8.1. It is followed by the 16-byte NONCE_S value from the server's AT_NONCE_S attribute.
AT_MAC属性を含まなければなりません。 EAP-応答/AKA-Reauthenticationに関しては、以下のデータに関してMACコードは計算されます: EAPパケット| 一回だけ_S。 EAPパケットはセクション8.1で指定されるように表されます。 16バイトのNONCE_S値はサーバのAT_NONCE_S属性からそれのあとに続いています。
The AT_CHECKCODE attribute MAY be included, and in certain cases specified in Section 10.13, it MUST be included.
AT_CHECKCODE属性は含まれるかもしれません、そして、セクション10.13で指定されたある場合では、それを含まなければなりません。
The AT_IV and AT_ENCR_DATA attributes MUST be included. The nested encrypted attributes MUST include the AT_COUNTER attribute. The AT_COUNTER_TOO_SMALL attribute MAY be included in the nested encrypted attributes, and it is included in cases specified in Section 5. The AT_PADDING attribute MAY be included.
AT_IVとAT_ENCR_DATA属性を含まなければなりません。 入れ子にされた暗号化された属性はAT_COUNTER属性を含まなければなりません。 AT_COUNTER、もSMALLが結果と考える_は入れ子にされた暗号化された属性に含まれるかもしれなくて、それはセクション5で指定されたケースに含まれています。 AT_PADDING属性は含まれるかもしれません。
The AT_RESULT_IND attribute MAY be included, if it was included in EAP-Request/AKA-Reauthentication. The usage of this attribute is discussed in Section 6.2.
それがEAP-要求/AKA-Reauthenticationに含まれていたなら、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/AKA-Reauthentication, but the peer MUST send EAP-Response/ AKA-Client-Error.
_AT_COUNTERなしでもこのパケットを送って、SMALLは、同輩が首尾よくサーバを認証して、EAP交換が同輩のローカルの方針で受け入れられるのを示します。 したがって、これらの条件が満たされないなら、同輩はEAP-応答/AKA-Reauthenticationを送ってはいけませんが、同輩はAKAクライアントEAP-応答/誤りを送らなければなりません。
Arkko & Haverinen Informational [Page 51] RFC 4187 EAP-AKA Authentication January 2006
[51ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
9.9. EAP-Response/AKA-Client-Error
9.9. 別名クライアントEAP-応答/誤り
The peer sends EAP-Response/AKA-Client-Error in error cases, as specified in Section 6.3.1.
同輩はセクション6.3.1で指定されるようにAKAクライアントEAP-応答/誤りの間違った事件を送ります。
The AT_CLIENT_ERROR_CODE attribute MUST be included. The AT_MAC, AT_IV, or AT_ENCR_DATA attributes MUST NOT be used with this packet.
AT_CLIENT_ERROR_CODE属性を含まなければなりません。 このパケットと共にAT_MAC、AT_IV、またはAT_ENCR_DATA属性を使用してはいけません。
9.10. EAP-Request/AKA-Notification
9.10. 別名EAP-要求/通知
The usage of this message is specified in Section 6.
このメッセージの用法はセクション6で指定されます。
The AT_NOTIFICATION attribute MUST be included.
AT_NOTIFICATION属性を含まなければなりません。
The AT_MAC attribute MUST be included if the P bit of the AT_NOTIFICATION code is set to zero, and MUST NOT be included if 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.15.
どんなメッセージ特有のデータもMAC計算に含まれていません。 セクション10.15を見てください。
If EAP-Request/AKA-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/AKA-Reauthentication packet on the same fast re-authentication exchange.
AKA EAP-要求/通知が速い再認証交換のときに使用されて、AT_NOTIFICATIONのPビットがゼロに設定されるなら、AT_COUNTERは反復操作による保護に使用されます。 この場合、AT_ENCR_DATAとAT_IV属性を含まなければなりません、そして、カプセル化された平文属性はAT_COUNTER属性を含まなければなりません。 AT_COUNTER MUSTに対価を含んでいて、同じ速い再認証交換のときにEAP-要求/AKA-Reauthenticationパケットと同じにしてください。
9.11. EAP-Response/AKA-Notification
9.11. 別名EAP-応答/通知
The usage of this message is specified in Section 6. This packet is an acknowledgement of EAP-Request/AKA-Notification.
このメッセージの用法はセクション6で指定されます。 このパケットはAKA EAP-要求/通知の承認です。
The AT_MAC attribute MUST be included in cases when the P bit of the notification code in AT_NOTIFICATION of EAP-Request/AKA-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属性は、AKA EAP-要求/通知のAT_NOTIFICATIONの通知コードのPビットがゼロに設定されるとき、ケースに含まなければならなくて、Pビットが1つに設定されるとき、ケースに含まれてはいけません。 セクション6でPビットについて議論します。
If EAP-Request/AKA-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/AKA-Reauthentication packet on the same fast re-authentication exchange.
AKA EAP-要求/通知が速い再認証交換のときに使用されて、AT_NOTIFICATIONのPビットがゼロに設定されるなら、AT_COUNTERは反復操作による保護に使用されます。 この場合、AT_ENCR_DATAとAT_IV属性を含まなければなりません、そして、カプセル化された平文属性はAT_COUNTER属性を含まなければなりません。 AT_COUNTER MUSTに対価を含んでいて、同じ速い再認証交換のときにEAP-要求/AKA-Reauthenticationパケットと同じにしてください。
Arkko & Haverinen Informational [Page 52] RFC 4187 EAP-AKA Authentication January 2006
[52ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
10. Attributes
10. 属性
This section specifies the format of message attributes. The attribute type numbers are specified in Section 11.
このセクションはメッセージ属性の形式を指定します。 属性形式数はセクション11で指定されます。
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/ AKA-Identity, (2) EAP-Response/AKA-Identity, (3) EAP-Request/ AKA-Challenge, (4) EAP-Response/AKA-Challenge, (5) EAP-Request/ AKA-Notification, (6) EAP-Response/AKA-Notification, (7) EAP- Response/AKA-Client-Error (8) EAP-Request/AKA-Reauthentication, (9) EAP-Response/AKA-Reauthentication, (10) EAP-Response/AKA- Authentication-Reject, and (11) EAP-Response/AKA-Synchronization- Failure. The column denoted with "E" indicates whether the attribute is a nested attribute that MUST be included within AT_ENCR_DATA.
以下のテーブルは属性がどの種類に関するメッセージ、およびどんな量に見つけられるかもしれないガイドを提供します。 数が以下の括弧にある状態で、メッセージは指示されます: (1) 別名EAP-要求/アイデンティティ((2)別名EAP-応答/アイデンティティ、(3)別名EAP-要求/挑戦、(4)別名EAP-応答/挑戦、(5)別名EAP-要求/通知、(6)別名EAP-応答/通知、別名(7)EAP別名クライアント応答/誤り(8)EAP-要求/Reauthentication、別名(9)EAP-応答/Reauthentication、別名認証(10)EAP-応答/廃棄物、および(11)EAP-応答/別名同期失敗)。 「E」と共に指示されたコラムは、属性が_ENCR_データでそれを含まなければならない入れ子にされた属性であるかどうかを示します。
"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 the future versions of the protocol.
そして、「0インチが、メッセージに属性を含んではいけないのを示す、「1インチが、メッセージに属性を含まなければならないのを示す、「01インチ、表示、属性がメッセージに時々含まれている、「0*、」、表示、属性は、本書では指定されたケースの中のメッセージに含まれていませんが、プロトコルの将来のバージョンに含まれるかもしれません」
Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) (10)(11) E
AT_PERMANENT_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N
AT_ANY_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N
AT_FULLAUTH_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N
AT_IDENTITY 0 0-1 0 0 0 0 0 0 0 0 0 N
AT_RAND 0 0 1 0 0 0 0 0 0 0 0 N
AT_AUTN 0 0 1 0 0 0 0 0 0 0 0 N
AT_RES 0 0 0 1 0 0 0 0 0 0 0 N
AT_AUTS 0 0 0 0 0 0 0 0 0 0 1 N
AT_NEXT_PSEUDONYM 0 0 0-1 0 0 0 0 0 0 0 0 Y
AT_NEXT_REAUTH_ID 0 0 0-1 0 0 0 0 0-1 0 0 0 Y
AT_IV 0 0 0-1 0* 0-1 0-1 0 1 1 0 0 N
AT_ENCR_DATA 0 0 0-1 0* 0-1 0-1 0 1 1 0 0 N
AT_PADDING 0 0 0-1 0* 0-1 0-1 0 0-1 0-1 0 0 Y
AT_CHECKCODE 0 0 0-1 0-1 0 0 0 0-1 0-1 0 0 N
AT_RESULT_IND 0 0 0-1 0-1 0 0 0 0-1 0-1 0 0 N
AT_MAC 0 0 1 1 0-1 0-1 0 1 1 0 0 N
AT_COUNTER 0 0 0 0 0-1 0-1 0 1 1 0 0 Y
AT_COUNTER_TOO_SMALL 0 0 0 0 0 0 0 0 0-1 0 0 Y
AT_NONCE_S 0 0 0 0 0 0 0 1 0 0 0 Y
AT_NOTIFICATION 0 0 0 0 1 0 0 0 0 0 0 N
AT_CLIENT_ERROR_CODE 0 0 0 0 0 0 1 0 0 0 0 N
________IV0の_次の_REAUTH_ID0 0 0-1 0 0 0 0 0-1 0 0 0Yの次の_匿名0 0 0-1 0 0 0 0 0 0 0 0YのAUTS0 0 0 0 0 0 0 0 0 0 1NのRES0 0 0 1 0 0 0 0 0 0 0NのAUTN0 0 1 0 0 0 0 0 0 0 0Nの底ならし革0 0 1 0 0 0 0 0 0 0 0Nのアイデンティティ0 0-1 0 0 0 0 0 0 0 0 0NのFULLAUTH_ID_REQ0-1 0 0 0 0 0 0 0 0 0 0Nの_どんな_ID_REQ0-1 0 0 0 0 0 0 0 0 0 0Nの_永久的な_ID_REQ0-1 0 0 0 0 0 0 0 0 0 0Nの属性(1)(2)(3)(4)(5)(6)(7)(8)(9)(10)(11)E; 0 0-1 0*0-1 0-1 0 1 1 0 0N _また、__の_で_カウンタ0 0 0 0 0-1 0-1 0 1 1 0 0Yで_Mac0 0 1 1 0-1 0-1 0 1 1 0 0Nで_結果_インディアン座0 0 0-1 0-1 0 0 0 0-1 0-1 0 0Nで_CHECKCODE0 0 0-1 0-1 0 0 0 0-1 0-1 0 0Nで0 0 0-1 0*0-1 0-1 0 0-1 0-1 0 0Yを水増しするENCR_データ0 0 0-1 0*0-1 0-1 0 1 1 0 0Nでは、_クライアント_誤り_コード0 0 0 0 0 0 1 0 0 0 0Nで_一回だけ_S0 0 0 0 0 0 0 1 0 0 0Yで_通知0 0 0 0 1 0 0 0 0 0 0Nで_小さい0 0 0 0 0 0 0 0 0-1 0 0Yを打ち返してください。
Arkko & Haverinen Informational [Page 53] RFC 4187 EAP-AKA Authentication January 2006
[53ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
It should be noted that attributes AT_PERMANENT_ID_REQ, AT_ANY_ID_REQ, and AT_FULLAUTH_ID_REQ are mutually exclusive, so that only one of them can be included at the same time. If one of the attributes AT_IV or 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_PERMANENT_ID_REQ
10.2. __永久的な_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.1. The value field only contains two reserved bytes, which are set to zero on sending and ignored on reception.
_AT_PERMANENT_ID REQの使用はセクション4.1で定義されます。 値の分野は予約された2バイトしか含んでいません。(バイトは、発信のゼロに設定されて、レセプションで無視されます)。
10.3. AT_ANY_ID_REQ
10.3. __どんな_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.1. The value field only contains two reserved bytes, which are set to zero on sending and ignored on reception.
_どんなAT__ID REQの使用もセクション4.1で定義されます。 値の分野は予約された2バイトしか含んでいません。(バイトは、発信のゼロに設定されて、レセプションで無視されます)。
10.4. AT_FULLAUTH_ID_REQ
10.4. __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.1. The value field only contains two reserved bytes, which are set to zero on sending and ignored on reception.
_AT_FULLAUTH_ID REQの使用はセクション4.1で定義されます。 値の分野は予約された2バイトしか含んでいません。(バイトは、発信のゼロに設定されて、レセプションで無視されます)。
Arkko & Haverinen Informational [Page 54] RFC 4187 EAP-AKA Authentication January 2006
[54ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
10.5. AT_IDENTITY
10.5. _アイデンティティで
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.1. The value field of this attribute begins with 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.1.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.1で定義されます。 この属性の値の分野は2バイトの実際のアイデンティティの長さで始まります。(それは、バイトで表現されるアイデンティティの長さを指定します)。 示された実際の長さの加入者のアイデンティティはこの野原のあとに続いています。 アイデンティティは、永久的なアイデンティティ、匿名のアイデンティティまたは速い再認証のアイデンティティです。 アイデンティティ形式はセクション4.1.1で指定されます。 同じアイデンティティ形式はAT_IDENTITY属性とEAP-応答/アイデンティティパケットで使用されて、同輩がそうしてはいけない例外でそれがAT_IDENTITYに含むアイデンティティに飾り付けをしてください。 アイデンティティは少しの終端空文字も含んでいません。 属性の長さが4バイトの倍数であるに違いないので、必要であるときに、送付者はどんなバイトでもアイデンティティを水増ししません。
10.6. AT_RAND
10.6. _底ならし革で
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 = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _底ならし革で| 長さ=5| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 底ならし革| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute contains two reserved bytes followed by the AKA RAND parameter, 16 bytes (128 bits). The reserved bytes are set to zero when sending and ignored on reception.
この属性の値の分野はAKA RANDパラメタがあとに続いた予約された2バイト、16バイト(128ビット)を含んでいます。 予約されたバイトは、発信するとき、ゼロに設定されて、レセプションで無視されます。
Arkko & Haverinen Informational [Page 55] RFC 4187 EAP-AKA Authentication January 2006
[55ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
10.7. AT_AUTN
10.7. _AUTNで
The format of the AT_AUTN attribute is shown below.
AT_AUTN属性の書式は以下に示されます。
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_AUTN | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| AUTN |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _AUTNで| 長さ=5| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | AUTN| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute contains two reserved bytes followed by the AKA AUTN parameter, 16 bytes (128 bits). The reserved bytes are set to zero when sending and ignored on reception.
この属性の値の分野はAKA AUTNパラメタがあとに続いた予約された2バイト、16バイト(128ビット)を含んでいます。 予約されたバイトは、発信するとき、ゼロに設定されて、レセプションで無視されます。
10.8. AT_RES
10.8. _RESで
The format of the AT_RES attribute is shown below.
AT_RES属性の書式は以下に示されます。
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_RES | Length | RES Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
| RES |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _RESで| 長さ| RESの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | RES| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute begins with the 2-byte RES Length, which identifies the exact length of the RES in bits. The RES length is followed by the AKA RES parameter. According to [TS33.105], the length of the AKA RES can vary between 32 and 128 bits. Because the length of the AT_RES attribute must be a multiple of 4 bytes, the sender pads the RES with zero bits where necessary.
この属性の値の分野は2バイトのRES Lengthと共に始まります。(RES LengthはビットのRESの正確な長さを特定します)。 AKA RESパラメタはRESの長さのあとに続いています。 [TS33.105]に従って、AKA RESの長さは32〜128ビット異なることができます。 AT_RES属性の長さが4バイトの倍数であるに違いないので、送付者は必要であるところでゼロ・ビットでRESを水増しします。
Arkko & Haverinen Informational [Page 56] RFC 4187 EAP-AKA Authentication January 2006
[56ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
10.9. AT_AUTS
10.9. _AUTSで
The format of the AT_AUTS attribute is shown below.
AT_AUTS属性の書式は以下に示されます。
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_AUTS | Length = 4 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| AUTS |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| | _AUTSで| 長さ=4| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | AUTS| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of this attribute contains the AKA AUTS parameter, 112 bits (14 bytes).
この属性の値の分野はAKA AUTSをパラメタ、112ビット(14バイト)含んでいます。
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 a 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属性の中でそれをカプセル化することによって、この属性をいつも暗号化しなければなりません。
Arkko & Haverinen Informational [Page 57] RFC 4187 EAP-AKA Authentication January 2006
[57ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
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 a 2-byte actual re-authentication identity length which specifies the length of the following fast re-authentication identity in bytes. This field is followed by a fast re-authentication identity that the peer can use in the next fast re-authentication, as described in Section 5. In environments where a realm portion is required, the fast re-authentication identity includes both a username portion and a realm name portion. The fast re-authentication identity does not include any terminating null characters. Because the length of the attribute must be a multiple of 4 bytes, the sender pads the fast re-authentication identity with zero bytes when necessary. The identity encoding MUST follow the UTF-8 transformation format [RFC3629]. This attribute MUST always be encrypted by encapsulating it within the AT_ENCR_DATA attribute.
この属性の値の分野はバイトで表現される以下の速い再認証のアイデンティティの長さを指定する2バイトの実際の再認証アイデンティティの長さで始まります。 同輩が次の速い再認証に使用できる速い再認証のアイデンティティはこの野原のあとに続いています、セクション5で説明されるように。 分野の部分が必要である環境では、速い再認証のアイデンティティはユーザ名部分と分野の名前部分の両方を含んでいます。 速い再認証のアイデンティティは少しの終端空文字も含んでいません。 属性の長さが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-AKA peer and server.
EAP-AKA同輩とサーバの間に暗号化された情報を伝えるのに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 reuse the initialization vector value from previous EAP-AKA 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-AKAパケットから初期化ベクトル価値を再利用してはいけません。 送付者SHOULDは、初期化ベクトルを生成するのに偶発性の良い源を使用します。 セキュリティアプリケーションのために乱数を生成することに関する詳しい情報に関して[RFC4086]を見てください。 AT_IVの書式は以下に示されます。
Arkko & Haverinen Informational [Page 58] RFC 4187 EAP-AKA Authentication January 2006
[58ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
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. The cipher text bytes are encrypted using the Advanced Encryption Standard (AES) [AES] with a 128-bit key in the Cipher Block Chaining (CBC) mode of operation, which uses 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属性の値の分野は暗号テキストバイトがあとに続いた予約された2バイトから成ります。 暗号テキストバイトは、AT_IV属性から初期化ベクトルを使用する128ビットのCipher Block Chainingで主要な(CBC)運転モードがあるエー・イー・エス(AES)[AES]を使用することで暗号化されています。 予約されたバイトは、発信するとき、ゼロに設定されて、レセプションで無視されます。 CBCモードの記述に関して[CBC]を見てください。 AT_ENCR_DATA属性の書式は以下に示されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_ENCR_DATA | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Encrypted Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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-AKA attributes.
平文は入れ子にされたEAP-AKA属性から成ります。
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
暗号化アルゴリズムは、平文の長さが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進)のゼロに合うように設定されます。 メッセージの受取人は、パッドバイトがゼロに設定されることを確かめなければなりません。 これです。
Arkko & Haverinen Informational [Page 59] RFC 4187 EAP-AKA Authentication January 2006
[59ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
verification fails on the peer, then it MUST send the EAP-Response/AKA-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 EAP-Response/AKA-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.
検証は同輩で失敗して、次に、エラーコードが「パケットを処理できない」状態で、それは、認証交換を終えるためにAKAクライアントEAP-応答/誤りパケットを送らなければなりません。 この検証がサーバで失敗するなら、サーバは認証交換を終えないことを含意するAT_NOTIFICATIONコードがあるAKA EAP-応答/通知パケットを送ります。 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _詰め物で| 長さ| そっと歩きます… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10.13. AT_CHECKCODE
10.13. _CHECKCODEで
The AT_MAC attribute is not used in the very first EAP-AKA messages during the AKA-Identity round, because keying material has not been derived yet. The peer and the server may exchange one or more pairs of EAP-AKA messages of the Subtype AKA-Identity before keys are derived and before the AT_MAC attribute can be applied. The EAP/- AKA-Identity messages may also be used upon fast re-authentication.
AT_MAC属性はAKA-アイデンティティの間、まさしくその最初のEAP-AKAメッセージでぐるりと使用されません、材料を合わせるのがまだ引き出されていないので。 キーが引き出される前とAT_MAC属性を適用できる前に同輩とサーバは1組以上のSubtype AKA-アイデンティティに関するEAP-AKAメッセージを交換するかもしれません。 また、EAP/AKA-アイデンティティメッセージは速い再認証のときに使用されるかもしれません。
The AT_CHECKCODE attribute MAY be used to protect the EAP/ AKA-Identity messages. In full authentication, the server MAY include the AT_CHECKCODE in EAP-Request/AKA-Challenge, and the peer MAY include AT_CHECKCODE in EAP-Response/AKA-Challenge. In fast re-authentication, the server MAY include AT_CHECKCODE in EAP-Request/ AKA-Reauthentication, and the peer MAY include AT_CHECKCODE in EAP-Response/AKA-Reauthentication. The fact that the peer receives an EAP-Request with AT_CHECKCODE does not imply that the peer would have to include AT_CHECKCODE in the corresponding response. The peer MAY include AT_CHECKCODE even if the server did not include AT_CHECKCODE in the EAP request. Because the AT_MAC attribute is used in these messages, AT_CHECKCODE will be integrity protected with AT_MAC. The format of the AT_CHECKCODE attribute is shown below.
AT_CHECKCODE属性は、EAP/ AKA-アイデンティティメッセージを保護するのに使用されるかもしれません。 完全な認証では、サーバはAKA EAP-要求/挑戦にAT_CHECKCODEを含むかもしれません、そして、同輩はAKA EAP-応答/挑戦でAT_CHECKCODEを入れるかもしれません。 速い再認証では、サーバはEAP-要求/AKA-ReauthenticationにAT_CHECKCODEを含むかもしれません、そして、同輩はEAP-応答/AKA-ReauthenticationでAT_CHECKCODEを入れるかもしれません。 同輩がAT_CHECKCODEとのEAP-要求を受け取るという事実は、同輩が対応する応答でAT_CHECKCODEを入れなければならないのを含意しません。 サーバがEAP要求にAT_CHECKCODEを含まなかったとしても、同輩はAT_CHECKCODEを入れるかもしれません。 AT_MAC属性がこれらのメッセージで使用されるので、AT_CHECKCODEはAT_MACと共に保護された保全になるでしょう。 AT_CHECKCODE属性の書式は以下に示されます。
Arkko & Haverinen Informational [Page 60] RFC 4187 EAP-AKA Authentication January 2006
[60ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
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_CHECKCODE | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Checkcode (0 or 20 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | _CHECKCODEで| 長さ| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Checkcode(0バイトか20バイト)| | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value field of AT_CHECKCODE begins with two reserved bytes, which may be followed by a 20-byte checkcode. If the checkcode is not included in AT_CHECKCODE, then the attribute indicates that no EAP/- AKA-Identity messages were exchanged. This may occur in both full authentication and fast re-authentication. The reserved bytes are set to zero when sending and ignored on reception.
AT_CHECKCODEの値の分野は予約された2バイトで始まります。(バイトは20バイトのcheckcodeによって続かれるかもしれません)。 checkcodeがAT_CHECKCODEに含まれていないなら、属性は、EAP/AKA-アイデンティティメッセージが全く交換されなかったのを示します。 これは完全な認証と速い再認証の両方に起こるかもしれません。 予約されたバイトは、発信するとき、ゼロに設定されて、レセプションで無視されます。
The checkcode is a hash value, calculated with SHA1 [SHA-1], over all EAP-Request/AKA-Identity and EAP-Response/AKA-Identity packets exchanged in this authentication exchange. The packets are included in the order that they were transmitted, that is, starting with the first EAP-Request/AKA-Identity message, followed by the corresponding EAP-Response/AKA-Identity, followed by the second EAP-Request/AKA-Identity (if used), etc.
checkcodeはこの認証交換で交換されたすべてのAKA EAP-要求/アイデンティティとAKA EAP-応答/アイデンティティパケットの上のSHA1[SHA-1]と共に計算されたハッシュ値です。 パケットはそれらが伝えられて、それがそうであるオーダーに含まれています、AKA対応するEAP-応答/アイデンティティがあとに続いたAKA第2EAP-要求/アイデンティティ(使用されるなら)などがあとに続いた最初のAKA EAP-要求/アイデンティティメッセージから始まって
EAP packets are included in the hash calculation "as-is" (as they were transmitted or received). All reserved bytes, padding bytes, etc., that are specified for various attributes are included as such, and the receiver must not reset them to zero. No delimiter bytes, padding, or any other framing are included between the EAP packets when calculating the checkcode.
EAPパケットはハッシュ計算に「そのままで」含まれています(それらを伝えたか、または受け取ったように)。 すべての予約されたバイト、様々な属性に指定される詰め物バイトなどはそういうものとして含められています、そして、受信機はゼロにそれらをリセットしてはいけません。 checkcodeについて計算するとき、どんなデリミタバイトも、詰め物、またはいかなる他の縁どりもEAPパケットの間に含まれていません。
Messages are included in request/response pairs; in other words, only full "round trips" are included. Packets that are silently discarded are not included, and retransmitted packets (that have the same Identifier value) are only included once. (The base EAP protocol [RFC3748] ensures that requests and responses "match".) The EAP server must only include an EAP-Request/AKA-Identity in the calculation after it has received a corresponding response with the same Identifier value.
メッセージは要求/応答組で含まれています。 言い換えれば、完全な「周遊旅行」だけ、が含まれています。 静かに捨てられるパケットは含まれていません、そして、再送されたパケット(それには、同じIdentifier値がある)が一度、含まれているだけです。 (ベースEAPプロトコル[RFC3748]は、要求と応答が「合っていること」を確実にします。) 同じIdentifier値で対応する応答を受けた後にEAPサーバは計算にAKA EAP-要求/アイデンティティを含むだけでよいです。
The peer must include the EAP-Request/AKA-Identity and the corresponding response in the calculation only if the peer receives a subsequent EAP-Request/AKA-Challenge or a follow-up EAP-Request/ AKA-Identity with a different Identifier value than in the first EAP-Request/AKA-Identity.
同輩がAKA最初のEAP-要求/アイデンティティと異なったIdentifier値でその後のAKA EAP-要求/挑戦か追跡しているAKA EAP-要求/アイデンティティを受ける場合にだけ、同輩はAKA EAP-要求/アイデンティティと計算における対応する応答を入れなければなりません。
Arkko & Haverinen Informational [Page 61] RFC 4187 EAP-AKA Authentication January 2006
[61ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
The AT_CHECKCODE attribute is optional to implement. It is specified in order to allow protection of the EAP/AKA-Identity messages and any future extensions to them. The implementation of AT_CHECKCODE is RECOMMENDED.
AT_CHECKCODE属性は、実装するために任意です。 それは、EAP/AKA-アイデンティティメッセージとどんな今後の拡大の保護もそれらに許すために指定されます。 AT_CHECKCODEの実装はRECOMMENDEDです。
If the receiver of AT_CHECKCODE implements this attribute, then the receiver MUST check that the checkcode is correct. If the checkcode is invalid, the receiver must operate as specified in Section 6.3.
AT_CHECKCODEの受信機がこの属性を実装するなら、受信機は、checkcodeが正しいのをチェックしなければなりません。 checkcodeが無効であるなら、受信機はセクション6.3で指定されるように動作しなければなりません。
If the EAP/AKA-Identity messages are extended with new attributes, then AT_CHECKCODE MUST be implemented and used. More specifically, if the server includes any attributes other than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ in the EAP-Request/AKA-Identity packet, then the server MUST include AT_CHECKCODE in EAP-Request/ AKA-Challenge or EAP-Request/AKA-Reauthentication. If the peer includes any attributes other than AT_IDENTITY in the EAP-Response/ AKA-Identity message, then the peer MUST include AT_CHECKCODE in EAP-Response/AKA-Challenge or EAP-Response/AKA-Reauthentication.
EAP/AKA-アイデンティティメッセージが新しい属性で広げられるなら、そして、実装されて、使用されるAT_CHECKCODE MUSTです。 より明確に、サーバがAKA EAP-要求/アイデンティティパケットに何か_AT_PERMANENT_ID REQ、_AT_FULLAUTH_ID REQ、または_どんなAT__ID REQ以外の属性を含んでいるなら、サーバはAKA EAP-要求/挑戦かEAP-要求/AKA-ReauthenticationにAT_CHECKCODEを含まなければなりません。 同輩が何かAKA EAP-応答/アイデンティティメッセージのAT_IDENTITY以外の属性を入れるなら、同輩はAKA EAP-応答/挑戦かEAP-応答/AKA-ReauthenticationでAT_CHECKCODEを入れなければなりません。
If the server implements the processing of any other attribute than AT_IDENTITY for the EAP-Response/AKA-Identity message, then the server MUST implement AT_CHECKCODE. In this case, if the server receives any attribute other than AT_IDENTITY in the EAP-Response/AKA-Identity message, then the server MUST check that AT_CHECKCODE is present in EAP-Response/AKA-Challenge or EAP-Response/ AKA-Reauthentication. The operation when a mandatory attribute is missing is specified in Section 6.3.
サーバがAKA EAP-応答/アイデンティティメッセージのためにAT_IDENTITYよりいかなる他の属性の処理も実装するなら、サーバは、AT_がCHECKCODEであると実装しなければなりません。 この場合、サーバが何かAKA EAP-応答/アイデンティティメッセージのAT_IDENTITY以外の属性を受けるなら、サーバは、AT_CHECKCODEがAKA EAP-応答/挑戦かEAP-応答/AKA-Reauthenticationに存在しているのをチェックしなければなりません。 義務的な属性がなくなるとき、操作はセクション6.3で指定されます。
Similarly, if the peer implements the processing of any attribute other than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ for the EAP-Request/AKA-Identity packet, then the peer MUST implement AT_CHECKCODE. In this case, if the peer receives any attribute other than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ in the EAP-Request/AKA-Identity packet, then the peer MUST check that AT_CHECKCODE is present in EAP-Request/AKA-Challenge or EAP-Request/AKA-Reauthentication. The operation when a mandatory attribute is missing is specified in Section 6.3.
同様に、同輩がAKA EAP-要求/アイデンティティパケットのために__AT_PERMANENT_ID REQ、AT_FULLAUTH_ID REQ以外の属性をいずれかの処理に実装するか、または__どんな_ID REQもATに実装するなら、同輩は、AT_がCHECKCODEであると実装しなければなりません。 この場合、同輩がAKA EAP-要求/アイデンティティパケットで何か_AT_PERMANENT_ID REQ、_AT_FULLAUTH_ID REQ、または_どんなAT__ID REQ以外の属性を受けるなら、同輩は、AT_CHECKCODEがAKA EAP-要求/挑戦かEAP-要求/AKA-Reauthenticationに存在しているのをチェックしなければなりません。 義務的な属性がなくなるとき、操作はセクション6.3で指定されます。
10.14. AT_RESULT_IND
10.14. _結果_インディアン座で
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| 予約されます。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Arkko & Haverinen Informational [Page 62] RFC 4187 EAP-AKA Authentication January 2006
[62ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
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.15. AT_MAC
10.15. _Macで
The AT_MAC attribute is used for EAP-AKA message authentication. Section 9 specifies in which messages AT_MAC MUST be included.
AT_MAC属性はEAP-AKA通報認証に使用されます。 セクション9は、_どのメッセージ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-AKA 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-AKA message in Section 9.
AT_MAC属性の値の分野は予約された2バイトを含んでいます、続いて、合わせられたメッセージ確認コード(MAC)を含みます。 MACは全体のEAPパケットの上で計算されて、任意のメッセージ特有のデータで連結されます、MAC属性の値の分野がMACについて計算するときにはゼロに合わせるように設定される例外で。 EAPパケットはセクション8.1における指定されるとしてのCode分野、Subtype分野で始まるEAP-AKAヘッダー、およびすべての属性で始まるEAPヘッダーを含んでいます。 AT_MACの予約されたバイトは、発信するとき、ゼロに設定されて、レセプションで無視されます。 MAC計算に含まれるかもしれないメッセージ特有のデータのコンテンツは別々にセクション9のそれぞれのEAP-AKAメッセージに指定されています。
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| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MAC algorithm is 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 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-AKA message, the recipient MUST process the AT_MAC attribute before looking at any other attributes, except when processing EAP-Request/AKA-Challenge. The processing of EAP-Request/AKA-Challenge is specified in
AT_MAC属性がEAP-AKAメッセージに含まれているとき、いかなる他の属性も見る前に受取人はAT_MAC属性を処理しなければなりません、AKA EAP-要求/挑戦を処理する時を除いて。 AKA EAP-要求/挑戦の処理では、指定されます。
Arkko & Haverinen Informational [Page 63] RFC 4187 EAP-AKA Authentication January 2006
[63ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
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.
セクション9.3。 メッセージ確認コードが無効であるなら、受取人は、セクション6.3で指定されるようにメッセージの他のすべての属性を無視して、働かなければなりません。
10.16. AT_COUNTER
10.16. _カウンタで
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.17. AT_COUNTER_TOO_SMALL
10.17. _では、__あまりに小さく反対してください。
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属性の中でそれをカプセル化することによって、この属性をいつも暗号化しなければなりません。
Arkko & Haverinen Informational [Page 64] RFC 4187 EAP-AKA Authentication January 2006
[64ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
10.18. AT_NONCE_S
10.18. _一回だけ_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 (16 bytes) that is freshly generated by the server for this EAP-AKA fast re-authentication. The random number is used as 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-AKAの速い再認証のためのサーバによって新たに生成される乱数(16バイト)を含みます。 乱数は同輩のための挑戦として新しい合わせることの材料のための種子値としても使用されます。 予約されたバイトは、発信のゼロに設定されて、レセプションで無視されます。 AT_ENCR_DATA属性の中でそれをカプセル化することによって、この属性をいつも暗号化しなければなりません。
The server MUST NOT reuse the NONCE_S value from a previous EAP-AKA 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-AKAの速い再認証交換からNONCE_S値を再利用してはいけません。 サーバSHOULDは、NONCEが_Sであると生成するのに偶発性の良い源を使用します。 セキュリティアプリケーションのために乱数を生成することに関する詳しい情報に関して[RFC4086]を見てください。
10.19. AT_NOTIFICATION
10.19. _通知で
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で説明されるように解釈されます。
Arkko & Haverinen Informational [Page 65] RFC 4187 EAP-AKA Authentication January 2006
[65ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
The notification code values listed below have been reserved. The descriptions below illustrate the semantics of the notifications. The peer implementation MAY use different wordings when presenting the notifications to the user. The "requested service" depends on the environment where EAP-AKA is applied.
以下に記載された通知コード値は予約されました。 以下での記述は通知の意味論を例証します。 ユーザに通知を提示するとき、同輩実装は異なった言葉遣いを使用するかもしれません。 「要求されたサービス」はEAP-AKAが適用されている環境に依存します。
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.20. AT_CLIENT_ERROR_CODE
10.20. _クライアント_誤り_コードで
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 「パケットを処理できません」: 一般的なエラーコード
11. IANA and Protocol Numbering Considerations
11. 問題に付番するIANAとプロトコル
IANA has assigned the EAP type number 23 for EAP-AKA authentication.
IANAはEAP-AKA認証のEAP形式数23を割り当てました。
EAP-AKA shares most of the protocol design, such as attributes and message Subtypes, with EAP-SIM [EAP-SIM]. EAP-AKA protocol numbers should be administered in the same IANA registry with EAP-SIM. This document establishes the registries and lists the initial protocol numbers for both protocols.
EAP-AKAはEAP-SIM[EAP-SIM]と属性やメッセージSubtypesなどのプロトコルデザインの大部分を共有します。 EAP-AKAプロトコル番号は同じIANA登録でEAP-SIMで管理されるべきです。 このドキュメントは、登録を確立して、両方のプロトコルの初期のプロトコル番号を記載します。
Arkko & Haverinen Informational [Page 66] RFC 4187 EAP-AKA Authentication January 2006
[66ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
EAP-AKA and EAP-SIM messages include a Subtype field. The Subtype is a new numbering space for which IANA administration is required. The Subtype is an 8-bit integer. The following Subtypes are specified in this document and in [EAP-SIM]:
EAP-AKAとEAP-SIMメッセージはSubtype分野を含んでいます。 SubtypeはIANA管理が必要である新しい付番スペースです。 Subtypeは8ビットの整数です。 以下のSubtypesはこのドキュメントと[EAP-SIM]で指定されます:
AKA-Challenge...................................1
AKA-Authentication-Reject.......................2
AKA-Synchronization-Failure.....................4
AKA-Identity....................................5
SIM-Start......................................10
SIM-Challenge..................................11
AKA-Notification and SIM-Notification..........12
AKA-Reauthentication and SIM-Reauthentication..13
AKA-Client-Error and SIM-Client-Error..........14
別名挑戦…1個の別名認証廃棄物…2 別名同期失敗…4別名アイデンティティ…5 SIMで始まってください…10 SIM挑戦…11の別名通知とSIM通知…12 別名-ReauthenticationとSIM-Reauthentication。13 別名クライアント誤りとSIMクライアント誤り…14
The messages are composed of attributes, which have 8-bit attribute type numbers. Attributes numbered within the range 0 through 127 are called non-skippable attributes, and attributes within the range of 128 through 255 are called skippable attributes. The EAP-AKA and EAP-SIM attribute type number is a new numbering space for which IANA administration is required. The following attribute types are specified in this document in [EAP-SIM]:
メッセージは属性で構成されます。(属性に、8ビットの属性形式数があります)。 範囲の中で0〜127に付番された属性は非skippable属性と呼ばれます、そして、128〜255の範囲の中の属性はskippable属性と呼ばれます。 EAP-AKAとEAP-SIM属性形式数はIANA管理が必要である新しい付番スペースです。 以下の属性タイプは本書では[EAP-SIM]で指定されます:
AT_RAND.........................................1
AT_AUTN.........................................2
AT_RES..........................................3
AT_AUTS.........................................4
AT_PADDING......................................6
AT_NONCE_MT.....................................7
AT_PERMANENT_ID_REQ............................10
AT_MAC.........................................11
AT_NOTIFICATION................................12
AT_ANY_ID_REQ..................................13
AT_IDENTITY....................................14
AT_VERSION_LIST................................15
AT_SELECTED_VERSION............................16
AT_FULLAUTH_ID_REQ.............................17
AT_COUNTER.....................................19
AT_COUNTER_TOO_SMALL...........................20
AT_NONCE_S.....................................21
AT_CLIENT_ERROR_CODE...........................22
AT_IV.........................................129
AT_ENCR_DATA..................................130
AT_NEXT_PSEUDONYM.............................132
AT_NEXT_REAUTH_ID.............................133
AT_CHECKCODE..................................134
AT_RESULT_IND.................................135
_底ならし革で…_大西洋標準時1AUTN…_大西洋標準時2RES…_大西洋標準時3AUTS…大西洋標準時4_詰め物…大西洋標準時6_一回だけ_山…_大西洋標準時7の_の永久的な_ID REQ…大西洋標準時10の_Mac…大西洋標準時11の_通知…__どんな12 AT_ID REQも…大西洋標準時13の_のアイデンティティ…大西洋標準時14_バージョン_は記載します…大西洋標準時15_は_バージョンを選択しました…_大西洋標準時16_FULLAUTH_ID REQ…大西洋標準時17_は反対します…大西洋標準時19_は__あまりに小さく反対します…大西洋標準時20_一回だけ_S.…大西洋標準時21_クライアント_誤り_コード…大西洋標準時22_IV…大西洋標準時129_ENCR_データ…大西洋標準時130の_ネクスト_匿名…_次の132 AT_REAUTH_アイダホ州…_大西洋標準時133CHECKCODE…_大西洋標準時134_RESULTインディアナ州…135
Arkko & Haverinen Informational [Page 67] RFC 4187 EAP-AKA Authentication January 2006
[67ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
The AT_NOTIFICATION attribute contains a 16-bit notification code value. The most significant bit of the notification code is called the S bit (success) and the second most significant bit is called the P bit (phase). If the S bit is set to zero, then the notification code indicates failure; notification codes with the S bit set to one do not indicate failure. If the P bit is set to zero, then the notification code can only be used before authentication has occurred. If the P bit is set to one, then the notification code can only be used after authentication. The notification code is a new numbering space for which IANA administration is required. The following values have been specified in this document and in [EAP-SIM].
AT_NOTIFICATION属性は16ビットの通知コード値を含んでいます。 通知コードの最も重要なビットはSビット(成功)と呼ばれます、そして、2番目の最上位ビットはPビット(フェーズ)と呼ばれます。 Sビットがゼロに設定されるなら、通知コードは失敗を示します。 1つに設定されたSビットがある通知コードは失敗を示しません。 Pビットがゼロに設定されるなら、認証が起こる前に通知コードを使用できるだけです。 Pビットが1つに設定されるなら、認証の後に通知コードを使用できるだけです。 通知コードはIANA管理が必要である新しい付番スペースです。 以下の値はこのドキュメントと[EAP-SIM]で指定されました。
General failure after authentication......................0
User has been temporarily denied access................1026
User has not subscribed to the requested service.......1031
General failure.......................................16384
Success...............................................32768
認証の後の一般失敗…アクセサリーは一時0ユーザに対して否定されました…1026年のユーザは要求されたサービスに加入していません…1031年の一般失敗…16384成功…32768
The AT_VERSION_LIST and AT_SELECTED_VERSION attributes, specified in [EAP-SIM], contain 16-bit EAP method version numbers. The EAP method version number is a new numbering space for which IANA administration is required. Value 1 for "EAP-SIM Version 1" has been specified in [EAP-SIM]. Version numbers are not currently used in EAP-AKA.
[EAP-SIM]で指定されたAT_バージョン_LISTと_バージョンAT_SELECTED属性は16ビットのEAPメソッドバージョン番号を含んでいます。 EAPメソッドバージョン番号はIANA管理が必要である新しい付番スペースです。 「EAP-SIMバージョン1インチは[EAP-SIM]で指定された」ために1を評価してください。 バージョン番号は現在、EAP-AKAで使用されません。
The AT_CLIENT_ERROR_CODE attribute contains a 16-bit client error code. The client error code is a new numbering space for which IANA administration is required. Values 0, 1, 2, and 3 have been specified in this document and in [EAP-SIM].
AT_CLIENT_ERROR_CODE属性は16ビットのクライアントエラーコードを含んでいます。 クライアントエラーコードはIANA管理が必要である新しい付番スペースです。 値0、1、2、および3はこのドキュメントと[EAP-SIM]で指定されました。
All requests for value assignment from the various number spaces described in this document require proper documentation, according to the "Specification Required" policy described in [RFC2434]. Requests must be specified in sufficient detail so that interoperability between independent implementations is possible. Possible forms of documentation include, but are not limited to, RFCs, the products of another standards body (e.g., 3GPP), or permanently and readily available vendor design notes.
本書では説明された様々な数の空間からの値の課題を求めるすべての要求が適切なドキュメンテーションを必要とします、「仕様が必要である」という[RFC2434]で説明された方針によると。 詳細に十分な要求を指定しなければならないので、独立している実装の間の相互運用性は可能です。 ドキュメンテーションの可能なフォームが含んでいる、有限であることで、RFCs、別の標準化団体(例えば、3GPP)、または永久に、そして、容易に利用可能なベンダーの製品が注意を設計するということではありません。
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-AKA as well as vulnerabilities and security recommendations.
EAP仕様[RFC3748]はEAPのセキュリティの脆弱性について説明します。(EAPはそれ自身のセキュリティー対策を含んでいません)。このセクションは脆弱性とセキュリティ推薦と同様にEAP-AKAの要求されたセキュリティの特性について論じます。
Arkko & Haverinen Informational [Page 68] RFC 4187 EAP-AKA Authentication January 2006
[68ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
12.1. Identity Protection
12.1. アイデンティティ保護
EAP-AKA 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-AKA exchange. Hence, a peer that has not yet performed any EAP-AKA exchanges does not typically have a pseudonym available. If the peer does not have a pseudonym available, then the privacy mechanism cannot be used, and the permanent identity will have to be sent in the clear. The terminal SHOULD store the pseudonym in 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 (Section 4.1.2) to learn the subscriber's IMSI. However, as discussed in Section 4.1.2, the terminal can refuse to send the cleartext IMSI if it believes that the network should be able to recognize the pseudonym.
EAP-AKAは受け身の盗聴に対して加入者のアイデンティティのプライバシーを保護する任意のIdentityプライバシーサポートを含んでいます。 このドキュメントは、EAP-AKA交換の一部としてサーバから同輩まで匿名を提供するためにメカニズムを指定するだけです。 したがって、まだ少しのEAP-AKA交換も実行していない同輩は利用可能な匿名を通常持っていません。 同輩に利用可能な匿名がないなら、プライバシーメカニズムを使用できません、そして、明確で永久的なアイデンティティを送らなければならないでしょう。 端末のSHOULDは、リブートの向こう側にそれを維持できるように非揮発性メモリーの匿名を保存します。 ネットワークをまねる活発な攻撃者は、加入者のIMSIを学ぶのに、AT_PERMANENT_ID_REQ属性(セクション4.1.2)を使用するかもしれません。 しかしながら、セクション4.1.2で議論するように、ネットワークが匿名を認識できるべきであるのが信じているなら、端末は、cleartext IMSIを送るのを拒否できます。
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. The benefits and the security considerations of using an external security mechanism with EAP-AKA are beyond the scope of this document.
同輩とサーバが、匿名が確かに維持されて、Identityプライバシーが必要であることを保証できないなら、対外安全保障メカニズム(Protected拡張認証プロトコル(PEAP)[PEAP]などの)からの追加保護は使用されるかもしれません。 EAP-AKAがある対外安全保障メカニズムを使用する利益とセキュリティ問題はこのドキュメントの範囲を超えています。
12.2. Mutual Authentication
12.2. 互いの認証
EAP-AKA provides mutual authentication via the 3rd generation AKA mechanisms [TS33.102] and [S.S0055-A].
EAP-AKAは3番目の世代AKAメカニズム[TS33.102]と[S. S0055-A]を通して互いの認証を提供します。
Note that this mutual authentication is 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], [EAPKeying], [ServiceIdentity].
この互いの認証がEAPサーバであることに注意してください。一般に、EAPメソッドは結合資産をいわゆるチャンネルに供給しないならEAP固有識別文字(EAPサーバと異なるなら)によって提供されたアイデンティティかサービスを認証しません。 [RFC3748]、[EAPKeying][ServiceIdentity]でこれに関連する脆弱性について議論しました。
EAP-AKA does not provide the channel bindings property, so it only authenticates the EAP server. However, ongoing work such as [ServiceIdentity] may provide such support as an extension to popular EAP methods such as EAP-TLS, EAP-SIM, or EAP-AKA.
EAP-AKAがチャンネル結合資産を提供しないので、それはEAPサーバを認証するだけです。しかしながら、[ServiceIdentity]などの進行中の仕事はEAP-TLS、EAP-SIM、またはEAP-AKAなどのポピュラーなEAPメソッドに拡大のようなサポートを提供するかもしれません。
12.3. Flooding the Authentication Centre
12.3. 認証センターをあふれさせます。
The EAP-AKA server typically obtains authentication vectors from the Authentication Centre (AuC). EAP-AKA introduces a new usage for the AuC. The protocols between the EAP-AKA server and the AuC are out of the scope of this document. However, it should be noted that a
EAP-AKAサーバはAuthentication Centre(AuC)から認証ベクトルを通常得ます。 EAP-AKAはAuCのために新しい用法を導入します。 このドキュメントの範囲の外にEAP-AKAサーバとAuCの間のプロトコルがあります。 しかしながら、それが注意されるべきである、そのa
Arkko & Haverinen Informational [Page 69] RFC 4187 EAP-AKA Authentication January 2006
[69ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
malicious EAP-AKA peer may generate a lot of protocol requests to mount a denial-of-service attack. The EAP-AKA 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-AKA to other users of the AuC.
悪意があるEAP-AKA同輩は、多くのプロトコルがサービス不能攻撃を仕掛けるという要求であると生成するかもしれません。 EAP-AKAサーバ実装SHOULDはこれを考慮に入れます、そして、SHOULDはそれがAuCに向かって生成するトラフィックを制限するために手を打ちます、AuCをあふれさせて、サービス不能攻撃を広げることからのEAP-AKAからAuCの他のユーザまでの攻撃者を防いで。
12.4. Key Derivation
12.4. 主要な派生
EAP-AKA supports key derivation with 128-bit effective key strength. The key hierarchy is specified in Section 7.
EAP-AKAは128ビットの有効な主要な強さで主要な派生をサポートします。 主要な階層構造はセクション7で指定されます。
The Transient EAP Keys used to protect EAP-AKA packets (K_encr, K_aut), the Master Session Keys, and the Extended Master Session Keys are cryptographically separate. 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 from AKA IK, AKA CK, EAP-AKA K_encr, EAP-AKA K_aut, the Master Session Key, or the Extended Master Session Key.
EAP-AKAパケット(K_はencrします、K_aut)を保護するのに使用されるTransient EAPキーズ、Master Sessionキーズ、およびExtended Master Sessionキーズは暗号でそうです。別々。 攻撃者は他のキーに基づくこれらのキーのどれかの少しの重要な情報も引き出すことができません。 攻撃者もAKA IK、AKA CK、EAP-AKA K_encr、EAP-AKA K_aut、Master Session Key、またはExtended Master Session Keyからプレ共有秘密キーについて計算できません。
12.5. Brute-Force and Dictionary Attacks
12.5. ブルートフォースと辞書攻撃
The effective strength of EAP-AKA values is 128 bits, and there are no known, computationally feasible brute-force attacks. Because AKA is not a password protocol (the pre-shared secret is not a passphrase, or derived from a passphrase), EAP-AKA is not vulnerable to dictionary attacks.
EAP-AKA値の有効な強さは128ビットです、そして、どんな知られていて、計算上可能な全数探索法もありません。 AKAがパスワードプロトコル(プレ共有秘密キーは、パスフレーズでない、またパスフレーズから派生されていない)でないので、EAP-AKAは辞書攻撃に被害を受け易くはありません。
12.6. Protection, Replay Protection, and Confidentiality
12.6. 保護、反復操作による保護、および秘密性
AT_MAC, AT_IV, AT_ENCR_DATA, and AT_COUNTER attributes are used to provide integrity, replay, and confidentiality protection for EAP-AKA Requests and Responses. Integrity protection with AT_MAC includes the EAP header. 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_IV、AT_ENCR_DATA、およびAT_COUNTER属性は、保全、再生、および秘密性保護をEAP-AKA RequestsとResponsesに供給するのに使用されます。 AT_MACとの保全保護はEAPヘッダーを含んでいます。 保全保護(AT_MAC)は合わせられたメッセージ確認コードに基づいています。 秘密性(AT_ENCR_DATAとAT_IV)はブロック暗号に基づいています。
Because keys are not available in the beginning of the EAP methods, the AT_MAC attribute cannot be used for protecting EAP/AKA-Identity messages. However, the AT_CHECKCODE attribute can optionally be used to protect the integrity of the EAP/AKA-Identity roundtrip.
キーが初めにEAPメソッドで利用可能でないので、EAP/AKA-アイデンティティメッセージを保護するのにAT_MAC属性を使用できません。 しかしながら、EAP/AKA-アイデンティティ往復旅行の保全を保護するのに任意にAT_CHECKCODE属性を使用できます。
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.1.
秘密性保護はプロトコル分野の一部だけに適用されます。 10.1がまとめるそれの分野が秘密性であるセクションにおける属性のテーブルは保護されました。 誤りと通知が属性AT_CLIENT_ERROR_CODEをコード化すると述べられるべきであり、AT_NOTIFICATIONは秘密ではありませんが、それらは明確で伝えられます。 セクション12.1でアイデンティティ保護について議論します。
Arkko & Haverinen Informational [Page 70] RFC 4187 EAP-AKA Authentication January 2006
[70ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
On full authentication, replay protection of the EAP exchange is provided by RAND and AUTN values from the underlying AKA scheme. Protection against replays of EAP-AKA messages is also based on the fact that messages that can include AT_MAC can only be sent once with a certain EAP-AKA Subtype, and on the fact that a different K_aut key will be used for calculating AT_MAC in each full authentication exchange.
完全な認証のときに、RANDとAUTN値で基本的なAKA体系からEAP交換の反復操作による保護を提供します。 また、EAP-AKAメッセージの再生に対する保護はあるEAP-AKA 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-AKA notifications, if they are used after successful authentication in order to provide replay protection between re-authentication exchanges.
速い再認証のときに、AT_COUNTERとサーバの無作為の一回だけにカウンタを含んでいるのは、反復操作による保護を提供するのに使用されます。 また、AT_COUNTER属性はEAP-AKA通知に含まれています、それらがうまくいっている認証の後に再認証交換の間に反復操作による保護を提供するのに使用されるなら。
The contents of the user identity string are implicitly integrity protected by including them in key derivation.
ユーザアイデンティティストリングの内容はそれとなく、保全に主要な派生にそれらを含んでいることによって保護されたということです。
Because EAP-AKA 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. On physically insecure networks, this may enable an attacker 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 before the peer successfully authenticates the server or after the peer failed to authenticate the server.
EAP-AKAがトンネリングメソッドでないので、EAP-要求/通知、EAP-応答/通知、EAP-成功、またはEAP-失敗パケットが秘密でない、保全が保護されたか、または再生は保護されました。 物理的に不安定なネットワークでは、これは、攻撃者がこれらのパケットを偽造することによってサービス不能攻撃を仕掛けるのを可能にするかもしれません。 セクション6.3で議論するように、首尾よくサーバを認証した後に同輩はEAP-成功を受け入れるだけでしょう。したがって、攻撃者は同輩に同輩が首尾よくサーバを認証する前か同輩がサーバを認証しなかった後にうまくいっている互いの認証が起こったと強制的に信じさせることができません。
The security considerations of EAP-AKA result indications are covered in Section 12.8
EAP-AKA結果指摘のセキュリティ問題はセクション12.8でカバーされています。
An eavesdropper will see the EAP Notification, EAP_Success and EAP-Failure packets sent in the clear. With EAP-AKA, confidential information MUST NOT be transmitted in EAP Notification packets.
立ち聞きする者は、EAP Notification、EAP_Success、およびEAP-失敗パケットが明確で送られるのを見るでしょう。 EAP-AKAと共に、EAP Notificationパケットで秘密情報を伝えてはいけません。
12.7. Negotiation Attacks
12.7. 交渉攻撃
EAP-AKA does not protect the EAP-Response/Nak packet. Because EAP-AKA does not protect the EAP method negotiation, EAP method downgrading attacks may be possible, especially if the user uses the same identity with EAP-AKA and other EAP methods.
EAP-AKAはEAP-応答/Nakパケットを保護しません。 EAP-AKAがEAPメソッド交渉を保護しないので、EAPメソッド格下げ攻撃は可能であるかもしれません、特にユーザがEAP-AKAがある同じアイデンティティと他のEAPメソッドを使用するなら。
As described in Section 8, EAP-AKA allows the protocol to be extended by defining new attribute types. When defining such attributes, it should be noted that any extra attributes included in EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are not
セクション8で説明されるように、EAP-AKAは、プロトコルが新しい属性タイプを定義することによって広げられるのを許容します。 そのような属性を定義するとき、AKA EAP-要求/アイデンティティかAKA EAP-応答/アイデンティティパケットに含まれていたどんな付加的な属性もそうでないことに注意するべきではありません。
Arkko & Haverinen Informational [Page 71] RFC 4187 EAP-AKA Authentication January 2006
[71ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
included in the MACs later on, and thus some other precautions must be taken to avoid modifications to them.
後でMACsにこのようにして含まれていて、それらへの変更を避けるためにある他の注意を払わなければなりません。
EAP-AKA does not support ciphersuite negotiation or EAP-AKA protocol version negotiation.
EAP-AKAは、ciphersuiteが交渉かEAP-AKAプロトコルバージョン交渉であるとサポートしません。
12.8. Protected Result Indications
12.8. 保護された結果指摘
EAP-AKA supports optional protected success indications, and acknowledged failure indications. If a failure occurs after successful authentication, then the EAP-AKA failure indication is integrity and replay protected.
EAP-AKAは、任意の保護された成功指摘、および承認された失敗が指摘であるとサポートします。 失敗がうまくいっている認証の後に起こるなら、EAP-AKA失敗指示は保全です、そして、再生は保護されました。
Even if an EAP-Failure packet is lost when using EAP-AKA over an unreliable medium, then the EAP-AKA 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-AKA success indication. If the optional success indications are not used, then the peer may end up believing the server completed successful authentication, when actually it failed. Because access will not be granted in this case, protected result indications are not needed unless the client is not able to realize it does not have access for an extended period of time.
頼り無い媒体の上でEAP-AKAを使用するとき、EAP-失敗パケットが無くなっても、EAP-AKA失敗指摘は、同輩とEAPサーバが相手の認証決定を知るのを確実にするのを助けるでしょう。 また、保護された成功指摘が使用されていると、Successパケットの損失は承認によって、扱われるでしょう、保全、そして、再生がEAP-AKA成功指示を保護しました。 任意の成功指摘が使用されていないなら、同輩は、結局サーバがうまくいっている認証を終了したと信じるかもしれません、実際にが失敗したとき。 アクセスがこの場合承諾されないので、クライアントが、時間の長期間の間それにはアクセスがないとわかることができるなら、保護された結果指摘は必要ではありません。
12.9. Man-in-the-Middle Attacks
12.9. 介入者攻撃
In order to avoid man-in-the-middle attacks and session hijacking, user data SHOULD be integrity protected on physically insecure networks. The EAP-AKA 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-AKA 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-AKA is used with a tunneling protocol, there should be cryptographic binding provided between the protocol and EAP-AKA 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-AKA Master Session Key MAY be used to provide the cryptographic binding. However, the mechanism that provides the binding depends on the tunneling protocol and is beyond the scope of this document.
トンネルを堀られたプロトコルの中でどんなEAPメソッドの使用にも関連している介入者攻撃があります。 例えば、PEAP[PEAP-02]の早めのバージョンはこの攻撃に被害を受け易かったです。 この仕様はこれらの攻撃を扱いません。 EAP-AKAがトンネリングプロトコルと共に使用されるなら、凶暴な固有識別文字を通した介入者攻撃が一方通行の認証されたトンネルをセットアップできるのを防ぐためにプロトコルとEAP-AKAの間に提供された暗号の結合があるべきです。 例えば、PEAPの、より新しいバージョンはそのような暗号の結合を含んでいます。 EAP-AKA Master Session Keyは、暗号の結合を提供するのに使用されるかもしれません。 しかしながら、結合を提供するメカニズムは、トンネリングプロトコルによって、このドキュメントの範囲を超えています。
Arkko & Haverinen Informational [Page 72] RFC 4187 EAP-AKA Authentication January 2006
[72ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
12.10. Generating Random Numbers
12.10. 乱数を生成します。
An EAP-AKA 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-AKA実装がプロトコルで必要です。 セキュリティアプリケーションのために乱数を生成する詳しい情報に関して[RFC4086]を見てください。
13. Security Claims
13. セキュリティクレーム
This section provides the security claims required by [RFC3748].
このセクションは[RFC3748]によって必要とされたセキュリティクレームを提供します。
Auth. Mechanism: EAP-AKA is based on the AKA mechanism, which is an authentication and key agreement mechanism based on a symmetric 128-bit pre-shared secret.
Auth。 メカニズム: EAP-AKAはAKAメカニズムに基づいています。(それは、左右対称の128ビットのプレ共有秘密キーに基づく認証と主要な協定メカニズムです)。
Ciphersuite negotiation: No
Ciphersuite交渉: いいえ
Mutual authentication: Yes (Section 12.2)
互いの認証: はい(セクション12.2)
Integrity protection: Yes (Section 12.6)
保全保護: はい(セクション12.6)
Replay protection: Yes (Section 12.6)
保護を再演してください: はい(セクション12.6)
Confidentiality: Yes, except method-specific success and failure indications (Section 12.1, Section 12.6)
秘密性: メソッド特有の成功と失敗指摘以外のはい(セクション12.1、セクション12.6)
Key derivation: Yes
キー派生: はい
Key strength: EAP-AKA supports key derivation with 128-bit effective key strength.
主要な強さ: EAP-AKAは128ビットの有効な主要な強さで主要な派生をサポートします。
Description of key hierarchy: Please see Section 7.
主要な階層構造の記述: セクション7を見てください。
Dictionary attack protection: N/A (Section 12.5)
辞書攻撃保護: なし(セクション12.5)
Fast reconnect: Yes
速く再接続してください: はい
Cryptographic binding: N/A
暗号の結合: なし
Session independence: Yes (Section 12.4)
セッション独立: はい(セクション12.4)
Fragmentation: No
断片化: いいえ
Channel binding: No
チャンネル結合: いいえ
Indication of vulnerabilities. Vulnerabilities are discussed in Section 12.
脆弱性のしるし。 セクション12で脆弱性について議論します。
Arkko & Haverinen Informational [Page 73] RFC 4187 EAP-AKA Authentication January 2006
[73ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
14. Acknowledgements and Contributions
14. 承認と貢献
The authors wish to thank Rolf Blom of Ericsson, Bernard Aboba of Microsoft, Arne Norefors of Ericsson, N.Asokan of Nokia, Valtteri Niemi of Nokia, Kaisa Nyberg of Nokia, Jukka-Pekka Honkanen of Nokia, Pasi Eronen of Nokia, Olivier Paridaens of Alcatel, and Ilkka Uusitalo of Ericsson for interesting discussions in this problem space.
作者はこの問題スペースでの興味深い議論についてエリクソンのロルフ・ブロム、マイクロソフトのバーナードAboba、エリクソンのアーンNorefors、ノキアのN.Asokan、ノキアのValtteri Niemi、ノキアのKaisaニーベルグ、ノキアのユッカ-ペッカHonkanen、ノキアのパシEronen、アルカテルのオリビエParidaens、およびエリクソンのIlkka Uusitaloに感謝したがっています。
Many thanks to Yoshihiro Ohba for reviewing the document.
芳広オオバにドキュメントを再検討してくださいといってくださってありがとうございますこと。
This protocol has been partly developed in parallel with EAP-SIM [EAP-SIM], and hence this specification incorporates many ideas from EAP-SIM, and many contributions from the reviewer's of EAP-SIM.
EAP-SIM[EAP-SIM]と平行してこのプロトコルを一部開発してあります、そして、したがって、この仕様はEAP-SIM、および多くの貢献から評論家のEAP-SIMのものから多くの考えを取り入れます。
The attribute format is based on the extension format of Mobile IPv4 [RFC3344].
属性形式はモバイルIPv4[RFC3344]の拡大形式に基づいています。
15. References
15. 参照
15.1. Normative References
15.1. 引用規格
[TS33.102] 3rd Generation Partnership Project, "3GPP Technical
Specification 3GPP TS 33.102 V5.1.0: "Technical
Specification Group Services and System Aspects; 3G
Security; Security Architecture (Release 5)"",
December 2002.
[TS33.102]第3世代パートナーシッププロジェクト、「3GPP仕様書3GPP t33.102V5.1.0:」 「仕様書グループサービスとシステム局面」。 3Gセキュリティ。 「セキュリティー体系(リリース5)」、」、12月2002日
[S.S0055-A] 3rd Generation Partnership Project 2, "3GPP2
Enhanced Cryptographic Algorithms", September 2003.
[S.S0055-A] 第3世代パートナーシッププロジェクト2、「3GPP2は暗号アルゴリズムを高めた」2003年9月。
[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。
[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月。
[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月。
[TS23.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.
[TS23.003]第3世代パートナーシッププロジェクト、「3GPP仕様書3GPP t23.003V6.8.0:」 「第3世代Parnershipは突出しています」。 仕様書グループコアネットワーク。 「付番、アドレシング、および識別(リリース6)」、」、12月2005日
Arkko & Haverinen Informational [Page 74] RFC 4187 EAP-AKA Authentication January 2006
[74ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
[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月。
[AES] National Institute of Standards and Technology,
"Federal Information Processing Standards (FIPS)
Publication 197, "Advanced Encryption Standard
(AES)"", November 2001,
http://csrc.nist.gov/publications/fips/fips197/
fips-197.pdf.
[AES]米国商務省標準技術局、「連邦政府の情報処理規格(FIPS)公表197、「暗号化標準で(AES)進め」にされました」、2001年11月、 http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf。
[CBC] National Institute of Standards and Technology,
"NIST Special Publication 800-38A, "Recommendation
for Block Cipher Modes of Operation - Methods and
Techniques"", December 2001,
http://csrc.nist.gov/publications/
nistpubs/800-38a/sp800-38a.pdf.
[CBC]米国商務省標準技術局、「NISTの特別な公表800-38A、「ブロックのための推薦は運転モードを解きます--メソッドとテクニック」」、2001年12月、 http://csrc.nist.gov/publications/ nistpubs/800-38a/sp800-38a. pdf。
[SHA-1] National Institute of Standards and Technology,
U.S. Department of Commerce, "Federal Information
Processing Standard (FIPS) Publication 180-1,
"Secure Hash Standard"", April 1995.
商務省、米国の「180-1 「ハッシュ規格を保証してください」という連邦情報処理基準(FIPS)公表」1995年4月の[SHA-1]米国商務省標準技術局。
[PRF] National Institute of Standards and Technology,
"Federal Information Processing Standards (FIPS)
Publication 186-2 (with change notice); Digital
Signature Standard (DSS)", January 2000,
http://csrc.nist.gov/publications/
fips/fips186-2/fips186-2-change1.pdf.
[PRF]米国商務省標準技術局、「連邦政府の情報Processing Standards(FIPS)公表186-2(変更通知がある)」。 「デジタル署名基準(DSS)」、2000年1月、 http://csrc.nist.gov/publications/ fips/fips186-2/fips186-2-change1.pdf。
[TS33.105] 3rd Generation Partnership Project, "3GPP Technical
Specification 3GPP TS 33.105 4.1.0: "Technical
Specification Group Services and System Aspects; 3G
Security; Cryptographic Algorithm Requirements
(Release 4)"", June 2001.
[TS33.105]第3世代パートナーシッププロジェクト、「3GPPの技術的な仕様3GPP t33.105 4.1.0:」 「仕様書グループサービスとシステム局面」。 3Gセキュリティ。 「暗号アルゴリズム要件(リリース4)」、」、6月2001日
[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日
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
Arkko & Haverinen Informational [Page 75] RFC 4187 EAP-AKA Authentication January 2006
[75ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
15.2. Informative References
15.2. 有益な参照
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS
Attributes", RFC 2548, March 1999.
[RFC2548] ゾルン、G.、「マイクロソフトのベンダー特有の半径属性」、RFC2548、1999年3月。
[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月)で働いています。
[EAPKeying] 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フレームワーク」という[EAPKeying]Abobaは進行中(2005年10月)で働いています。
[ServiceIdentity] Arkko, J. and P. Eronen, "Authenticated Service
Information for the Extensible Authentication
Protocol (EAP)", Work in Progress, October 2004.
[ServiceIdentity] 「拡張認証プロトコル(EAP)のための認証されたサービス情報」というArkko、J.、およびP.Eronenは進歩、2004年10月に働いています。
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106,
RFC 4086, June 2005.
[RFC4086]イーストレークとD.とシラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
[RFC3344] Perkins, C., "IP Mobility Support for IPv4",
RFC 3344, August 2002.
[RFC3344] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」
[EAP-SIM] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible
Authentication Protocol Method for Global System
for Mobile Communications (GSM) Subscriber Identity
Modules (EAP-SIM)", RFC 4186, January 2006.
エド[EAP-SIM]Haverinen、H.、J.Salowey、エド、「汎欧州デジタルセルラーシステム(GSM)加入者アイデンティティモジュール(EAP-SIM)のための拡張認証プロトコルメソッド」、RFC4186(2006年1月)
Arkko & Haverinen Informational [Page 76] RFC 4187 EAP-AKA Authentication January 2006
[76ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
Appendix A. Pseudo-Random Number Generator
付録A.疑似乱数生成器
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: mへのj=0--1 3.1に。 どんな任意のユーザも*/3.2に入力しなかったXSEED_j=0/*。 0〜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
Arkko & Haverinen Informational [Page 77] RFC 4187 EAP-AKA Authentication January 2006
[77ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
Authors' Addresses
作者のアドレス
Jari Arkko Ericsson FIN-02420 Jorvas Finland
ヤリ・Arkkoエリクソンフィン-02420Jorvasフィンランド
EMail: jari.Arkko@ericsson.com
メール: jari.Arkko@ericsson.com
Henry Haverinen Nokia Enterprise Solutions P.O. Box 12 FIN-40101 Jyvaskyla Finland
ヘンリーHaverinenノキアエンタープライズソリューション私書箱12フィン-40101ユベスキュレフィンランド
EMail: henry.haverinen@nokia.com
メール: henry.haverinen@nokia.com
Arkko & Haverinen Informational [Page 78] RFC 4187 EAP-AKA Authentication January 2006
[78ページ]RFC4187EAP-別名認証2006年1月の情報のArkko&Haverinen
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)によって提供されます。
Arkko & Haverinen Informational [Page 79]
Arkko&Haverinen情報です。[79ページ]
一覧
スポンサーリンク
