RFC4763 日本語訳
4763 Extensible Authentication Protocol Method for Shared-secretAuthentication and Key Establishment (EAP-SAKE). M. Vanderveen, H.Soliman. November 2006. (Format: TXT=96027 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Vanderveen
Request for Comments: 4763 H. Soliman
Category: Informational Qualcomm Flarion Technologies
November 2006
コメントを求めるワーキンググループM.バンダビーンの要求をネットワークでつないでください: 4763時間ソリマンCategory: 情報のクアルコムFlarion技術2006年11月
Extensible Authentication Protocol Method for
Shared-secret Authentication and Key Establishment (EAP-SAKE)
共有秘密キー認証と主要な設立のための拡張認証プロトコルメソッド(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 IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
IESG Note
IESG注意
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCはインターネットStandardのどんなレベルの候補ではありません。 IETFは配布しているプロトコルとのセキュリティのようなもの、輻輳制御、または不適当な相互作用のために、どんな目的のためのこのRFCのフィットネスに関するどんな知識と発行するという決定がIETFレビューに基づいていないという特に注も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このドキュメントの読者は実装と展開のために値を評価する際に警戒するべきです。 詳しい情報に関してRFC3932を見てください。
Abstract
要約
This document specifies an Extensible Authentication Protocol (EAP) mechanism for Shared-secret Authentication and Key Establishment (SAKE). This RFC is published as documentation for the IANA assignment of an EAP Type for a vendor's EAP method per RFC 3748. The specification has passed Designated Expert review for this IANA assignment.
このドキュメントはShared秘密のAuthenticationとKey特権階級(SAKE)に拡張認証プロトコル(EAP)メカニズムを指定します。 このRFCはベンダーのRFC3748あたりのEAPメソッドのためにEAP TypeのIANA課題のためのドキュメンテーションとして発行されます。 仕様はこのIANA課題のためにレビューにDesignated Expertに合格しました。
Vanderveen & Soliman Informational [Page 1] RFC 4763 EAP-SAKE November 2006
[1ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Protocol Description ............................................4
3.1. Overview and Motivation of EAP-SAKE ........................4
3.2. Protocol Operation .........................................5
3.2.1. Successful Exchange .................................5
3.2.2. Authentication Failure ..............................7
3.2.3. Identity Management ................................11
3.2.4. Obtaining Peer Identity ............................11
3.2.5. Key Hierarchy ......................................13
3.2.6. Key Derivation .....................................15
3.2.7. Ciphersuite Negotiation ............................17
3.2.8. Message Integrity and Encryption ...................17
3.2.9. Fragmentation ......................................21
3.2.10. Error Cases .......................................21
3.3. Message Formats ...........................................22
3.3.1. Message Format Summary .............................22
3.3.2. Attribute Format ...................................23
3.3.3. Use of AT_ENCR_DATA Attribute ......................25
3.3.4. EAP.Request/SAKE/Challenge Format ..................26
3.3.5. EAP.Response/SAKE/Challenge Format .................28
3.3.6. EAP.Request/SAKE/Confirm Format ....................30
3.3.7. EAP.Response/SAKE/Confirm Format ...................32
3.3.8. EAP.Response/SAKE/Auth-Reject Format ...............33
3.3.9. EAP.Request/SAKE/Identity Format ...................34
3.3.10. EAP.Response/SAKE/Identity Format .................36
3.3.11. Other EAP Messages Formats ........................37
4. IANA Considerations ............................................37
5. Security Considerations ........................................38
5.1. Denial-of-Service Attacks .................................38
5.2. Root Secret Considerations ................................38
5.3. Mutual Authentication .....................................39
5.4. Integrity Protection ......................................39
5.5. Replay Protection .........................................39
5.6. Confidentiality ...........................................40
5.7. Key Derivation, Strength ..................................40
5.8. Dictionary Attacks ........................................41
5.9. Man-in-the-Middle Attacks .................................41
5.10. Result Indication Protection .............................41
5.11. Cryptographic Separation of Keys .........................41
5.12. Session Independence .....................................41
5.13. Identity Protection ......................................42
5.14. Channel Binding ..........................................42
5.15. Ciphersuite Negotiation ..................................42
5.16. Random Number Generation .................................43
6. Security Claims ................................................43
1. 序論…3 2. 用語…3 3. 記述について議定書の中で述べてください…4 3.1. EAP-酒の概要と動機…4 3.2. 操作について議定書の中で述べてください…5 3.2.1. うまくいっている交換…5 3.2.2. 認証失敗…7 3.2.3. アイデンティティ管理…11 3.2.4. 同輩のアイデンティティを得ます…11 3.2.5. キー階層構造…13 3.2.6. キー派生…15 3.2.7. Ciphersuite交渉…17 3.2.8. メッセージの保全と暗号化…17 3.2.9. 断片化…21 3.2.10. 誤り事件…21 3.3. メッセージ形式…22 3.3.1. メッセージ・フォーマット概要…22 3.3.2. 形式を結果と考えてください…23 3.3.3. 使用、_ENCR_データ属性で…25 3.3.4. EAP.Request/酒/挑戦形式…26 3.3.5. EAP.Response/酒/挑戦形式…28 3.3.6. EAP.Request/酒/は形式を確認します…30 3.3.7. EAP.Response/酒/は形式を確認します…32 3.3.8. Auth EAP.Response/酒/廃棄物形式…33 3.3.9. EAP.Request/酒/アイデンティティ形式…34 3.3.10. EAP.Response/酒/アイデンティティ形式…36 3.3.11. 他のEAPメッセージ形式…37 4. IANA問題…37 5. セキュリティ問題…38 5.1. サービス不能攻撃…38 5.2. 秘密の問題を根づかせてください…38 5.3. 互いの認証…39 5.4. 保全保護…39 5.5. 保護を再演してください…39 5.6. 秘密性…40 5.7. 主要な派生、強さ…40 5.8. 辞書は攻撃されます…41 5.9. 中央の男性は攻撃します…41 5.10. 結果指示保護…41 5.11. キーの暗号の分離…41 5.12. セッション独立…41 5.13. アイデンティティ保護…42 5.14. 拘束力があった状態で、精神を集中してください…42 5.15. Ciphersuite交渉…42 5.16. 乱数発生…43 6. セキュリティクレーム…43
Vanderveen & Soliman Informational [Page 2] RFC 4763 EAP-SAKE November 2006
[2ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
7. Acknowledgements ...............................................44
8. References .....................................................44
8.1. Normative References ......................................44
8.2. Informative References ....................................45
7. 承認…44 8. 参照…44 8.1. 標準の参照…44 8.2. 有益な参照…45
1. Introduction
1. 序論
The Extensible Authentication Protocol (EAP), described in [EAP], provides a standard mechanism for support of multiple authentication methods. EAP is also used within IEEE 802 networks through the IEEE 802.11i [IEEE802.11i] framework.
[EAP]で説明された拡張認証プロトコル(EAP)は複数の認証方法のサポートに標準のメカニズムを提供します。 また、EAPはIEEE 802.11i[IEEE802.11i]フレームワークを通してIEEE802ネットワークの中で使用されます。
EAP supports several authentication schemes, including smart cards, Kerberos, Public Key, One Time Passwords, TLS, and others. This document defines an authentication scheme, called the EAP-SAKE. EAP-SAKE supports mutual authentication and session key derivation, based on a static pre-shared secret data. This RFC is published as documentation for the IANA assignment of an EAP Type for a vendor's EAP method per RFC 3748. The specification has passed Designated Expert review for this IANA assignment.
EAPはスマートカード、ケルベロス、Public Key、One Time Passwords、TLS、および他のものを含むいくつかの認証体系をサポートします。 EAP-SAKEは、このドキュメントが認証体系を定義すると呼びました。 EAP-SAKEは互いの認証とセッションの主要な派生、ベースの静電気の上で秘密をあらかじめ共有しているデータをサポートします。 このRFCはベンダーのRFC3748あたりのEAPメソッドのためにEAP TypeのIANA課題のためのドキュメンテーションとして発行されます。 仕様はこのIANA課題のためにレビューにDesignated Expertに合格しました。
2. Terminology
2. 用語
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [KEYWORDS].
本書では、いくつかの単語が、仕様の要件を意味するのに使用されます。 これらの単語はしばしば大文字で書かれます。 “MUST"、「必須NOT」が「必須NOT」というキーワード“MUST"が、「必要でした」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14[キーワード]で説明されるように本書では解釈されることであるべきですか?
In addition to the terms used in [EAP], this document frequently uses the following terms and abbreviations:
[EAP]で使用される用語に加えて、このドキュメントは頻繁に以下の用語と略語を使用します:
MIC Message Integrity Check
MICメッセージの保全チェック
SMS SAKE Master Secret
SMS酒のマスター秘密
NAI Network Access Identifier
NAIネットワークアクセス識別子
Vanderveen & Soliman Informational [Page 3] RFC 4763 EAP-SAKE November 2006
[3ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
3. Protocol Description
3. プロトコル記述
3.1. Overview and Motivation of EAP-SAKE
3.1. EAP-酒の概要と動機
The EAP-SAKE authentication protocol is a native EAP authentication method. That is, a stand-alone version of EAP-SAKE outside of EAP is not defined. EAP-SAKE is designed to enable mutual authentication, based on pre-shared keys and well-known public cryptographic algorithms. This method is ideal for subscription-based public access networks, e.g., cellular networks.
EAP-SAKE認証プロトコルは固有のEAP認証方法です。 すなわち、EAPにおける外のEAP-SAKEのスタンドアロンのバージョンは定義されません。 EAP-SAKEは互いの認証を可能にするように設計されています、あらかじめ共有されたキーとよく知られる公共の暗号アルゴリズムに基づいて。予約購読に基づくパブリックアクセスネットワークに、このメソッドは理想的です、例えば、セルラー・ネットワーク。
EAP-SAKE assumes a long-term or pre-shared secret known only to the Peer and the Server. This pre-shared secret is called the Root Secret. The Root Secret consists of a 16-byte part Root-Secret-A, and 16-byte part Root-Secret-B. The Root-Secret-A secret is reserved for use local to the EAP-SAKE method, i.e., to mutually authenticate the EAP Peer and EAP Server. The Root-Secret-B secret is used to derive other quantities such as the Master Session Key (MSK) and Extended Master Session Key (EMSK). Root-Secret-B and Root-Secret-A MUST be cryptographically separate.
EAP-SAKEはPeerとServerだけにおいて知られている長期かプレ共有秘密キーを仮定します。このプレ共有秘密キーはRoot Secretと呼ばれます。 Root Secretは16バイトの部分Root秘密A、および16バイトの部分Root秘密Bから成ります。 Root秘密A秘密はEAP-SAKEメソッドへの地方の使用のために予約されます、すなわち、互いにEAP Server EAP PeerとRoot秘密B秘密を認証するのはMaster Session Key(MSK)やExtended Master Session Key(EMSK)などの他の量を引き出すのにおいて使用されています。 根の秘密BとRoot秘密Aは暗号で分離することであるに違いありません。
When a Backend Authentication Server is used, the Server typically communicates with the Authenticator using an AAA protocol. The AAA communications are outside the scope of this document.
Backend Authentication Serverが使用されているとき、Serverは、AuthenticatorとAAAプロトコルを使用することで通常コミュニケートします。 このドキュメントの範囲の外にAAAコミュニケーションがあります。
Some of the advantages of EAP-SAKE are as follows:
EAP-SAKEの利点のいくつかは以下の通りです:
o It is based on well-established Bellare-Rogaway mutual
authentication protocol.
o それは安定しているBellare-Rogaway互いの認証プロトコルに基づいています。
o It supports key derivation for local EAP method use and for export
to other third parties to use them independently of EAP.
o それは、EAPの如何にかかわらず彼らを使用するために地方のEAPメソッド使用と輸出のための主要な派生を他の第三者にサポートします。
o It employs only two request/response exchanges.
o それは2回の要求/応答交換だけを使います。
o It relies on the (corrected) IEEE 802.11i function for key
derivation and message integrity. This way a device implementing a
lower-layer secure association protocol compliant with IEEE 802.11i
standard will not need additional cryptographic code.
o それは主要な派生とメッセージの保全のために(直る)のIEEE 802.11i機能を当てにします。 このように、IEEE 802.11i規格による対応することの下層安全な協会プロトコルを実装するデバイスは追加暗号のコードを必要としないでしょう。
o Its encryption algorithm is securely negotiated (with no extra
messages), yet encryption use is optional.
o 暗号化アルゴリズムはしっかりと交渉されます(付加的なメッセージなしで)、しかし、暗号化使用は任意です。
o Keys used for authentication and those used for encryption are
cryptographically separate.
o 暗号化に使用される認証とものがあるので、使用されるキーは暗号で分離します。
o User identity anonymity can be optionally supported.
o 任意にユーザアイデンティティ匿名をサポートすることができます。
Vanderveen & Soliman Informational [Page 4] RFC 4763 EAP-SAKE November 2006
[4ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
o No synchronization (e.g., of counters) needed between server and
peer.
o 同期はサーバと同輩の間で必要ではありません(例えば、カウンタの)。
o There is no one-time key pre-processing step.
o どんな1回の主要な前処理ステップもありません。
3.2. Protocol Operation
3.2. プロトコル操作
EAP-SAKE uses four messages consisting of two EAP request/response exchanges. The EAP.Success and EAP.Failure messages shown in the figures are not part of the EAP-SAKE method. As a convention, method attributes are named AT_XX, where XX is the name of the parameter the attribute value is set to.
EAP-SAKEは2回のEAP要求/応答交換から成る4つのメッセージを使用します。 数字に示されたEAP.SuccessとEAP.FailureメッセージはEAP-SAKEメソッドの一部ではありません。 コンベンションとして、メソッド属性はAT_XXと命名されて、属性値はXXがパラメタの名前であるところに設定されます。
3.2.1. Successful Exchange
3.2.1. うまくいっている交換
A successful EAP-SAKE authentication exchange is depicted in Figure 1. The following steps take place:
うまくいっているEAP-SAKE認証交換は図1に表現されます。 以下のステップは行われます:
Peer Server
| |
| EAP.Request/SAKE/Challenge |
| (AT_RAND_S, AT_SERVERID) |
1 |<---------------------------------------------------------|
| |
| EAP.Response/SAKE/Challenge |
| (AT_RAND_P, AT_PEERID, AT_SPI_P, AT_MIC_P) |
2 |--------------------------------------------------------->|
| |
| EAP.Request/SAKE/Confirm |
| (AT_SPI_S, AT_ENCR_DATA, AT_MIC_S)|
3 |<---------------------------------------------------------|
| |
| EAP.Response/SAKE/Confirm |
| (AT_MIC_P) |
4 |--------------------------------------------------------->|
| |
| |
| EAP-Success |
5 |<---------------------------------------------------------|
| |
同輩サーバ| | | EAP.Request/酒/挑戦| | (__底ならし革_S、SERVERIDの) | 1 |<---------------------------------------------------------| | | | EAP.Response/酒/挑戦| | (__底ならし革_P、_PEERID、_SPI_P、ミック_Pの) | 2 |--------------------------------------------------------->| | | | /が確認するEAP.Request/日本酒| | (__SPI_S、_ENCR_データ、ミック_Sの)| 3 |<---------------------------------------------------------| | | | /が確認するEAP.Response/日本酒| | (_ミック_Pの) | 4 |--------------------------------------------------------->| | | | | | EAP-成功| 5 |<---------------------------------------------------------| | |
Figure 1. EAP-SAKE Authentication Procedure (with ciphersuite
negotiation)
図1。 EAP-酒の認証手順(ciphersuite交渉がある)
1. The EAP server sends the first message of the EAP-SAKE exchange.
This message is an EAP.Request message of type SAKE and subtype
Challenge. The EAP.Request/SAKE/Challenge message contains the
attributes: AT_RAND_S, whose value is a nonce freshly generated
1. EAPサーバはEAP-SAKE交換の最初のメッセージを送ります。 このメッセージはタイプSAKEとsubtype Challengeに関するEAP.Requestメッセージです。 EAP.Request/SAKE/挑戦メッセージは属性を含んでいます: AT_RAND_S。その値は新たに生成された一回だけです。
Vanderveen & Soliman Informational [Page 5] RFC 4763 EAP-SAKE November 2006
[5ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
by the Server; and AT_SERVERID, which carries an identifier of
the Server (a fully qualified domain name, such as the realm of
the user NAI [NAI]). The AT_SERVERID attribute is OPTIONAL but
SHOULD be included in this message. The purpose of the
AT_SERVERID is to aid the Peer in selecting the correct security
association (i.e., Root-Secret, PEERID, and SERVERID) to use
during this EAP phase.
サーバで。 そして、AT_SERVERID。(そのSERVERIDはServer(ユーザNAI[NAI]の分野などの完全修飾ドメイン名)に関する識別子を運びます)。 含まれていて、AT_SERVERID属性は、このメッセージのOPTIONALにもかかわらず、SHOULDです。 このEAP段階の間、使用する_SERVERIDが正しいセキュリティ協会(すなわち、Root-秘密、PEERID、およびSERVERID)を選択することにおけるPeerを支援することになっているATの目的。
2. The Peer responds by sending an EAP.Response message of type SAKE
and subtype Challenge. The EAP.Response/SAKE/Challenge message
contains the attributes: AT_RAND_P, which carries a nonce freshly
generated by the Peer; AT_PEERID, which carries a Peer
identifier; AT_SPI_P, which carries a list of one or more
ciphersuites supported by the Peer; and AT_MIC_P, containing a
message integrity check. The AT_SPI_P and AT_PEERID attributes
are OPTIONAL. The AT_PEERID attribute SHOULD be included, in
order to cover the case of multi-homed hosts. A supported
ciphersuite is represented by a value local to the EAP-SAKE
method, or "Security Parameter Index", see section 3.2.8.3. The
Peer uses both nonces, along with the Root-Secret-A key, to
derive a SAKE Master Secret (SMS) and Temporary EAP Keys (TEKs),
which also include the TEK-Auth and TEK-Cipher keys. The MIC_P
value is computed based on both nonces RAND_S and RAND_P, and the
entire EAP packet, using the key TEK-Auth, see Section 3.2.6.
2. Peerは、タイプSAKEとsubtype Challengeに関するEAP.Responseメッセージを送ることによって、応じます。 EAP.Response/SAKE/挑戦メッセージは属性を含んでいます: AT_RAND_P(_はPeerによって新たに生成された一回だけを運びます)。 AT_PEERID、どれがPeer識別子を運ぶか。 AT_SPI_P(_はPeerによってサポートされた1ciphersuitesのリストを運びます)。 AT_MIC_P、そして、メッセージの保全を含んで、チェックしてください。 AT_SPI_PとAT_PEERID属性はOPTIONALです。 含まれていて、AT_PEERIDがケースをカバーするためにSHOULDを結果と考える、マルチ、家へ帰り、ホスト。 サポートしているciphersuiteがEAP-SAKEメソッドへの地方の値によって表されるか、またはセクション3.2.8は、「セキュリティパラメタインデックス」と.3に見ます。 Peerは、SAKE Master Secret(SMS)とTemporary EAPキーズ(TEKs)を引き出すのにRoot秘密Aキーに伴う両方の一回だけを使用します。(また、キーズは、TEK-AuthとTEK-暗号キーを含んでいます)。 MIC_P値は一回だけのRAND_SとRAND_Pと全体のEAPパケットの両方に基づいて計算されます、主要なTEK-Authを使用します、とセクション3.2.6は見ます。
3. Upon receipt of the EAP.Response/SAKE/Challenge message, the
Server uses both nonces RAND_S and RAND_P, along with the Root-
Secret-A key, to compute the SMS and TEK in exactly the same way
the Peer did. Following that, the Server computes the Peer's
MIC_P in exactly the same way the Peer did. The Server then
compares the computed MIC_P with the MIC_P it received from the
Peer. If they match, the Server considers the Peer
authenticated. If encryption is needed, the Server selects the
strongest ciphersuite from the Peer's ciphersuite list SPI_P, or
a suitable ciphersuite if the Peer did not include the AT_SPI_P
attribute. The Server sends an EAP.Request message of type SAKE
and subtype Confirm, containing the attributes: AT_SPI_S,
carrying the ciphersuite chosen by the Server; AT_ENCR_DATA,
containing encrypted data; and AT_MIC_S, carrying a message
integrity check. The AT_SPI_S and AT_ENCR_DATA are OPTIONAL
attributes, included if confidentiality and/or user identity
anonymity is desired. Other OPTIONAL attributes that MAY be
included are AT_NEXT_TMPID, and AT_MSK_LIFE. As before, the
MIC_S value is computed using both nonces RAND_S and RAND_P, and
the entire EAP packet, using the key TEK-Auth.
3. EAP.Response/SAKE/挑戦メッセージを受け取り次第、Serverは、Peerがしたまさに同じようにSMSとTEKを計算するのにRoot秘密のAキーと共に一回だけRAND_SとRAND_Pの両方を使用します。 それに続いて、ServerはPeerがしたまさに同じようにPeerのMIC_Pを計算します。 そして、ServerはそれがPeerから受けたMIC_Pと計算されたMIC_Pを比べます。 彼らが合っているなら、Serverは、Peerが認証されていると考えます。 暗号化が必要であるなら、ServerがPeerのciphersuiteリストSPI_Pから最も強いciphersuiteを選択するか、または適当なciphersuiteはPeerであるならAT_SPI_P属性を含んでいませんでした。 属性を含んでいて、ServerはタイプSAKEとsubtype Confirmに関するEAP.Requestメッセージを送ります: Serverによって選ばれたciphersuiteを運ぶAT_SPI_S。 AT_ENCR_DATA、含有はデータを暗号化しました。 AT_MIC_S、そして、メッセージの保全を運んで、チェックしてください。 AT_SPI_SとAT_ENCR_DATAは秘密性、そして/または、ユーザアイデンティティ匿名が望まれているなら含まれていたOPTIONAL属性です。 含まれるかもしれない他のOPTIONAL属性は、_AT_ネクストTMPIDと、AT_MSK_LIFEです。 従来と同様、MIC_S値は一回だけのRAND_SとRAND_Pと全体のEAPパケットの両方を使用することで計算されます、主要なTEK-Authを使用して。
Vanderveen & Soliman Informational [Page 6] RFC 4763 EAP-SAKE November 2006
[6ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
4. If the Peer receives the EAP.Request/SAKE/Confirm message
indicating successful authentication by the Server, the Peer
computes the MIC_S in the same manner as the Server did. The
Peer then compares the received MIC_S with the MIC_S it computed.
If they match, the Peer considers the Server authenticated, and
it sends an EAP.Response message of type SAKE and subtype
Confirm, with the attribute AT_MIC_P containing a message
integrity check, computed in the same manner as before.
4. PeerがEAP.Request/SAKE/を受けるなら、Serverによるうまくいっている認証を示すメッセージを確認してください、そして、PeerはServerと同じ方法による_SがしたMICを計算します。 そして、Peerはそれが計算したMIC_Sと容認されたMIC_Sを比べます。 彼らが合っているなら、Peerは、Serverが認証されていると考えます、そして、タイプSAKEとsubtype Confirmに関するEAP.Responseメッセージを送ります、属性AT_MIC_Pが従来と同様同じ方法で計算されたメッセージの保全チェックを含んでいて。
5. After a successful EAP-SAKE exchange, the Server concludes the
EAP conversation by sending an EAP.Success message to the Peer.
5. うまくいっているEAP-SAKE交換の後に、Serverは、EAP.SuccessメッセージをPeerに送ることによって、EAPの会話を結論づけます。
All EAP-SAKE messages contain a Session ID, which is chosen by the Server, sent in the first message, and replicated in subsequent messages until an EAP.Success or EAP.Failure is sent. Upon receipt of an EAP-SAKE message, both Peer and Server MUST check the format of the message to ensure that it is well-formed and contains a valid Session ID.
すべてのEAP-SAKEメッセージが、最初のメッセージで送られたServerによって選ばれているSession IDを含んで、その後のメッセージでEAP.Successまで模写されたか、またはEAP.Failureを送ります。 EAP-SAKEメッセージを受け取り次第、PeerとServerの両方が整形式であり、有効なSession IDを含むのを保証するメッセージの形式をチェックしなければなりません。
Note that the Session ID is introduced mainly for replay protection purposes, as it helps uniquely identify a session between a Peer and a Server. In most cases, there is a one-to-one relationship between the Session ID and the Peer/Server pair.
Session IDが主に反復操作による保護目的のために導入されることに注意してください、PeerとServerとのセッションを特定するのを唯一助けるとき。多くの場合、Session IDとPeer/サーバ組との1〜1つの関係があります。
The parameters used by the EAP-SAKE method are summarized in the table below:
EAP-SAKEメソッドで使用されるパラメタは以下のテーブルにまとめられます:
Name Length (bytes) Description
---------+---------------+-------------
RAND_P 16 Peer nonce
RAND_S 16 Server nonce
MIC_P 16 Peer MIC
MIC_S 16 Server MIC
SPI_P variable Peer ciphersuite preference(s)
SPI_S variable Server chosen ciphersuite
PEERID variable Peer identifier
SERVERID variable Server identifier (FQDN)
名前の長さ(バイト)の記述---------+---------------+------------- 可変可変ciphersuite PEERIDのPeer識別子SERVERID可変Server識別子が選ばれた一回だけのRAND_P16一回だけのMIC_P16Peer MIC MIC_S16Server MIC SPI_P可変Peer ciphersuite Peer RAND_S16Server好みSPI_SのServer(FQDN)
3.2.2. Authentication Failure
3.2.2. 認証失敗
If the Authenticator receives an EAP.Failure message from the Server, the Authenticator MUST terminate the connection with the Peer immediately.
AuthenticatorがServerからEAP.Failureメッセージを受け取るなら、Authenticatorはすぐに、Peerとの接続を終えなければなりません。
The Server considers the Peer to have failed authentication if either of the two received MIC_P values does not match the computed MIC_P.
どちらの2つの容認されたMIC_P値も計算されたMIC_Pに合っていないなら、Serverは、Peerが認証に失敗したと考えます。
Vanderveen & Soliman Informational [Page 7] RFC 4763 EAP-SAKE November 2006
[7ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
The Server SHOULD deny authorization for a Peer that does not advertise any of the ciphersuites that are considered acceptable (e.g., by local system policy) and send an EAP.Failure message.
Server SHOULDは許容できると(例えば、ローカルシステム方針による)考えられるciphersuitesのいずれも広告を出さないPeerのために承認を否定して、EAP.Failureメッセージを送ります。
In case of authentication failure, the Server MUST send an EAP.Failure message to the Peer as in Figure 2. The following steps take place:
認証失敗の場合には、Serverは図2のようにEAP.FailureメッセージをPeerに送らなければなりません。 以下のステップは行われます:
Peer Server
| |
| EAP.Request/SAKE/Challenge |
| (AT_RAND_S, AT_SERVERID) |
1 |<---------------------------------------------------------|
| |
| EAP.Response/SAKE/Challenge |
| (AT_RAND_P, AT_PEERID, AT_SPI_P, AT_MIC_P) |
2 |--------------------------------------------------------->|
| |
| +-------------------------------------------+
| | Server finds MIC_P invalid. |
| +-------------------------------------------+
| |
| EAP-Failure |
3 |<---------------------------------------------------------|
同輩サーバ| | | EAP.Request/酒/挑戦| | (__底ならし革_S、SERVERIDの) | 1 |<---------------------------------------------------------| | | | EAP.Response/酒/挑戦| | (__底ならし革_P、_PEERID、_SPI_P、ミック_Pの) | 2 |--------------------------------------------------------->| | | | +-------------------------------------------+ | | サーバは、MIC_Pが無効であることがわかります。 | | +-------------------------------------------+ | | | EAP-失敗| 3 |<---------------------------------------------------------|
Figure 2. EAP-SAKE Authentication Procedure, Peer Fails
Authentication
図2。 EAP-酒の認証手順、同輩は認証に失敗します。
1. As in step 1 of Figure 1.
1. 図1のステップ1のように。
2. As in step 2 of Figure 1.
2. 図1のステップ2のように。
3. Upon receipt of the EAP.Response/SAKE/Challenge message, the
Server uses both nonces RAND_S and RAND_P, along with the Root-
Secret-A key, to compute the SMS and TEK in exactly the same way
the Peer did. Following that, the Server computes the Peer's MIC
in exactly the same way the Peer did. The Server then compares
the computed MIC_P with the MIC_P it received from the Peer.
Since they do not match, the Server considers the Peer to have
failed authentication and sends an EAP.Failure message back to
the Peer.
3. EAP.Response/SAKE/挑戦メッセージを受け取り次第、Serverは、Peerがしたまさに同じようにSMSとTEKを計算するのにRoot秘密のAキーと共に一回だけRAND_SとRAND_Pの両方を使用します。 それに続いて、ServerはPeerがしたまさに同じようにPeerのMICを計算します。 そして、ServerはそれがPeerから受けたMIC_Pと計算されたMIC_Pを比べます。 彼らが合っていないので、ServerはPeerが認証に失敗したと考えて、EAP.FailureメッセージをPeerに送り返します。
Vanderveen & Soliman Informational [Page 8] RFC 4763 EAP-SAKE November 2006
[8ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
If the AT_SPI_S attribute does not contain one of the SPI values that the Peer listed in the previous message, or if the Peer did not include an AT_SPI_P attribute yet does not accept the ciphersuite the Server has chosen, then the Peer SHOULD silently discard this message. Alternatively, the Peer MAY send a SAKE/Auth-Reject message back to the Server; in response to this message, the Server MUST send an EAP.Failure message to the Peer.
PeerがAT_SPI_P属性を含んでいませんでしたが、Serverが選んだciphersuiteを受け入れないならAT_SPI_S属性がPeerが前のメッセージに記載したSPI値の1つを含んでいないなら、Peer SHOULDは静かにこのメッセージを捨てます。 あるいはまた、PeerはSAKE/Auth-廃棄物メッセージをServerに送り返すかもしれません。 このメッセージに対応して、ServerはEAP.FailureメッセージをPeerに送らなければなりません。
The AT_SPI_S attribute MUST be included if encryption is to be used. The Server knows whether or not encryption is to be used, as it is usually the Server that needs to protect some data intended for the Peer (e.g., temporary ID, group keys, etc). If the Peer receives an AT_SPI_S attribute yet there is no AT_ENCR_DATA attribute, the Peer SHOULD process the message and skip the AT_SPI_S attribute.
暗号化が使用されていることであるならAT_SPI_S属性を含まなければなりません。 Serverは、暗号化が使用されているかどうかことであることを知っています、それが通常Peerのために意図するいくつかのデータを保護する必要があるServerであるので(例えば、一時的なID、グループキーなど)。 PeerがまだAT_SPI_S属性を受けているならAT_ENCR_DATA属性が全くなくて、Peer SHOULDはメッセージを処理して、AT_SPI_S属性をスキップします。
The Peer considers the Server to have failed authentication if the received and the computed MIC_S values do not match. In this case, the Peer MUST send to the Server an EAP.Response message of type SAKE and subtype Auth-Reject, indicating an authentication failure. In this case, the Server MUST send an EAP.Failure message to the Peer as in Figure 3. The following steps take place:
受け取られていている値と計算されたMIC_S値が合っていないなら、Peerは、Serverが認証に失敗したと考えます。 この場合、PeerはタイプSAKEとsubtype Auth-廃棄物に関するEAP.ResponseメッセージをServerに送らなければなりません、認証失敗を示して。 この場合、Serverは図3のようにEAP.FailureメッセージをPeerに送らなければなりません。 以下のステップは行われます:
Vanderveen & Soliman Informational [Page 9] RFC 4763 EAP-SAKE November 2006
[9ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
Peer Server
| |
| EAP.Request/SAKE/Challenge |
| (AT_RAND_S, AT_SERVERID) |
1 |<---------------------------------------------------------|
| |
| EAP.Response/SAKE/Challenge |
| (AT_RAND_P, AT_PEERID, AT_SPI_P, AT_MIC_P) |
2 |--------------------------------------------------------->|
| |
| EAP.Request/SAKE/Confirm |
| (AT_SPI_S, AT_ENCR_DATA, AT_MIC_S)|
3 |<---------------------------------------------------------|
| |
+-----------------------------------------------+ |
| Peer finds MIC_S invalid. | |
+-----------------------------------------------+ |
| |
| EAP.Response/SAKE/Auth-Reject |
4 |--------------------------------------------------------->|
| |
| EAP-Failure |
5 |<---------------------------------------------------------|
| |
同輩サーバ| | | EAP.Request/酒/挑戦| | (__底ならし革_S、SERVERIDの) | 1 |<---------------------------------------------------------| | | | EAP.Response/酒/挑戦| | (__底ならし革_P、_PEERID、_SPI_P、ミック_Pの) | 2 |--------------------------------------------------------->| | | | /が確認するEAP.Request/日本酒| | (__SPI_S、_ENCR_データ、ミック_Sの)| 3 |<---------------------------------------------------------| | | +-----------------------------------------------+ | | 同輩は、MIC_Sが無効であることがわかります。 | | +-----------------------------------------------+ | | | | Auth EAP.Response/酒/廃棄物| 4 |--------------------------------------------------------->| | | | EAP-失敗| 5 |<---------------------------------------------------------| | |
Figure 3. EAP-SAKE Authentication Procedure, Server Fails
Authentication
図3。 EAP-酒の認証手順、サーバは認証に失敗します。
1. As in step 1 of Figure 1.
1. 図1のステップ1のように。
2. As in step 2 of Figure 1.
2. 図1のステップ2のように。
3. As in step 3 of Figure 1.
3. 図1のステップ3のように。
4. The Peer receives a EAP.Request/SAKE/Confirm message indicating
successful authentication by the Server. The Peer computes the
MIC_S in the same manner as the Server did. The Peer then
compares the received MIC_S with the MIC_S it computed. Since
they do not match, the Peer considers the Server to have failed
authentication. In this case, the Peer responds with an
EAP.Response message of type SAKE and subtype Auth-Reject,
indicating authentication failure.
4. PeerはEAP.Requestを受けます。/SAKE/はServerによるうまくいっている認証を示すメッセージを確認します。PeerはServerと同じ方法による_SがしたMICを計算します。 そして、Peerはそれが計算したMIC_Sと容認されたMIC_Sを比べます。 彼らが合っていないので、Peerは、Serverが認証に失敗したと考えます。 この場合、認証失敗を示して、PeerはタイプSAKEとsubtype Auth-廃棄物に関するEAP.Responseメッセージで応じます。
5. Upon receipt of a EAP.Response/SAKE/Auth-Reject message, the
Server sends an EAP.Failure message back to the Peer.
5. Auth EAP.Response/SAKE/廃棄物メッセージを受け取り次第、ServerはEAP.FailureメッセージをPeerに送り返します。
Vanderveen & Soliman Informational [Page 10] RFC 4763 EAP-SAKE November 2006
[10ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
3.2.3. Identity Management
3.2.3. アイデンティティ管理
It may be advisable to assign a temporary identifier (TempID) to a Peer when user anonymity is desired. The TempID is delivered to the Peer in the EAP.Request/SAKE/Confirm message. The TempID follows the format of any NAI [NAI] and is generated by the EAP Server that engages in the EAP-SAKE authentication task with the Peer. EAP servers SHOULD be configurable with TempID spaces that can be distinguished from the permanent identity space. For instance, a specific realm could be assigned for TempIDs (e.g., tmp.example.biz).
ユーザ匿名が望まれているとき、一時的な識別子(TempID)をPeerに割り当てるのは賢明であるかもしれません。 TempIDはメッセージをEAP.Request/SAKEのPeerに提供されるか、または確認することです。 TempIDはどんなNAI[NAI]の形式にも続いて、Peerと共にEAP-SAKE認証タスクに従事しているEAP Serverによって生成されます。 EAPサーバSHOULD、永久的なアイデンティティスペースと区別できるTempID空間で、構成可能であってください。 例えば、TempIDs(例えば、tmp.example.biz)のために特定の分野を割り当てることができました。
A TempID is not assigned an explicit lifetime. The TempID is valid until the Server requests the permanent identifier, or the Peer triggers the start of a new EAP session by sending in its permanent identifier. A Peer MUST be able to trigger an EAP session at any time using its permanent identifier. A new TempID assigned during a successful EAP session MUST replace the existing TempID for future transactions between the Peer and the Server.
明白な寿命はTempIDに割り当てられません。 Serverが永久的な識別子を要求するまで、TempIDが有効であるか、またはPeerは、永久的な識別子を送ることによって、新しいEAPセッションの始まりの引き金となります。 Peerは、いつでも、永久的な識別子を使用することでEAPセッションの引き金となることができなければなりません。 うまくいっているEAPセッションの間に割り当てられた新しいTempIDは清算取引のためにPeerとServerの間で既存のTempIDを取り替えなければなりません。
Note that the delivery of a TempID does not imply that the Server considers the Peer authenticated; the Server still has to check the MIC in the EAP.Response/SAKE/Confirm message. In case the EAP phase ends with an EAP.Failure message, then the Server and the Peer MUST consider the TempID that was just delivered as invalid. Hence, the Peer MUST NOT use this TempID the next time it tries to authenticate with the Server.
TempIDの配送が、Serverが、Peerが認証されていると考えるのを含意しないことに注意してください。 ServerはEAP.ResponseでまだMICをチェックしなければなりません。/SAKE/はメッセージを確認します。 EAPフェーズがEAP.Failureメッセージで終わるといけないので、そして、ServerとPeerは、ただ提供されたTempIDが無効であるとみなさなければなりません。 したがって、PeerはこのTempIDを使用してはいけません。それがServerと共に認証しようとする次回。
3.2.4. Obtaining Peer Identity
3.2.4. 同輩のアイデンティティを得ます。
The types of identities that a Peer may possess are permanent and temporary identities, referred to as PermID and TempID, respectively. A PermID can be an NAI associated with the Root Secret, and is long- lived. A TempID is an identifier generated through the EAP method and that the Peer can use to identify itself during subsequent EAP sessions with the Server. The purpose of the TempID is to allow for user anonymity support. The use of TempIDs is optional in the EAP- SAKE method.
Peerが持っているかもしれないアイデンティティのタイプはそれぞれPermIDとTempIDと呼ばれた永久的で一時的なアイデンティティです。 PermIDはRoot Secretに関連しているNAIであることができ、長い間、送られます。 識別子がEAPメソッドで生成されて、Peerがその後のEAPセッションの間. TempIDの目的をそれ自体でServerと共に特定するのに使用できるTempIDはユーザ匿名サポートを考慮することになっています。 TempIDsの使用はEAP- SAKEメソッドで任意です。
The Server MAY request the Peer ID via the EAP.Request/SAKE/Identity message, as shown in Figure 4. This case may happen if, for example, the Server wishes to initiate an EAP-SAKE session for a Peer it does not have a subscriber identifier for. The following steps take place:
Serverは図4に示されるようにEAP.Request/SAKE/アイデンティティメッセージでPeer IDを要求するかもしれません。 例えば、ServerがPeerのためのそれが加入者識別子を持っていないEAP-SAKEセッションを開始したいと思うなら、本件は起こるかもしれません。 以下のステップは行われます:
Vanderveen & Soliman Informational [Page 11] RFC 4763 EAP-SAKE November 2006
[11ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
Peer Server
| |
| +---------------------------------+
| | Server wishes to initiate |
| | an EAP-SAKE session |
| | |
| +---------------------------------+
| |
| EAP.Request/SAKE/Identity |
| (AT_ANY_ID_REQ, AT_SERVERID) |
1 |<---------------------------------------------------------|
| |
| EAP.Response/SAKE/Identity |
| (AT_PEERID) |
2 |--------------------------------------------------------->|
| |
+--------------------------------------------------------------+
| If identity found, normal EAP-SAKE authentication follows. |
+--------------------------------------------------------------+
同輩サーバ| | | +---------------------------------+ | | 開始するサーバ願望| | | EAP-SAKEセッション| | | | | +---------------------------------+ | | | EAP.Request/酒/アイデンティティ| | (___どんな_ID REQ、SERVERIDの) | 1 |<---------------------------------------------------------| | | | EAP.Response/酒/アイデンティティ| | (_PEERIDの) | 2 |--------------------------------------------------------->| | | +--------------------------------------------------------------+ | 通常のEAP-SAKE認証が続くのがアイデンティティによってわかったなら。 | +--------------------------------------------------------------+
Figure 4. Server Requests Peer Identity
図4。 サーバは同輩のアイデンティティを要求します。
1. The Server sends an EAP.Request message of type SAKE and subtype
Identity, with the attribute AT_ANY_ID_REQ, indicating a request
for any Peer identifier.
1. ServerはタイプSAKEに関するEAP.Requestメッセージと属性ATとsubtype Identityに__どんな_ID REQも送ります、どんなPeer識別子に関する要求も示して。
2. The Peer constructs an EAP.Response message of type SAKE and
subtype Identity, with the attribute AT_PEER_ID containing any
Peer identifier (PermID or TempID).
2. PeerはタイプSAKEとsubtype Identityに関するEAP.Responseメッセージを構成します、属性AT_PEER_IDがどんなPeer識別子(PermIDかTempID)も含んでいて。
If the Server cannot find the Peer identity reported in the EAP.Response/SAKE/Identity message, or if it does not recognize the format of the Peer identifier, the Server MAY send an EAP.Failure message to the Peer.
Serverが、PeerがPeer識別子の形式を認識しないならEAP.Response/SAKE/アイデンティティメッセージで報告されたアイデンティティであることを見つけることができないなら、ServerはEAP.FailureメッセージをPeerに送るかもしれません。
If the Server is unable to look up a Peer by its TempID, or if policy dictates that the Peer should now use its permanent id, then the Server may specifically ask for the permanent identifier, as in Figure 5. The following steps occur:
ServerがTempIDでPeerを見上げることができないか、または方針が、Peerが現在永久的なイドを使用するはずであると決めるなら、Serverは明確に永久的な識別子を求めるかもしれません、図5のように。 以下のステップは起こります:
Vanderveen & Soliman Informational [Page 12] RFC 4763 EAP-SAKE November 2006
[12ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
Peer Server
| |
| +---------------------------------+
1 | | Server obtains TempID but |
| | requires PermID |
| +---------------------------------+
| |
| EAP.Request/SAKE/Identity |
| (AT_PERM_ID_REQ, AT_SERVERID) |
2 |<---------------------------------------------------------|
| |
| EAP.Response/SAKE/Identity |
| (AT_PEERID) |
3 |--------------------------------------------------------->|
| |
| +---------------------------------+
| | Server finds and uses |
| | Peer PermID to start a |
| | EAP-SAKE authentication phase |
| +---------------------------------+
|
+---------------------------------------------------------------+
| Normal EAP-SAKE authentication follows. |
+---------------------------------------------------------------+
同輩サーバ| | | +---------------------------------+ 1 | | しかしサーバがTempIDを入手する。| | | PermIDを必要とします。| | +---------------------------------+ | | | EAP.Request/酒/アイデンティティ| | (___パーマ_ID REQ、SERVERIDの) | 2 |<---------------------------------------------------------| | | | EAP.Response/酒/アイデンティティ| | (_PEERIDの) | 3 |--------------------------------------------------------->| | | | +---------------------------------+ | | サーバ掘り出し物と用途| | | aを始める同輩PermID| | | EAP-SAKE認証フェーズ| | +---------------------------------+ | +---------------------------------------------------------------+ | 通常のEAP-SAKE認証は続きます。 | +---------------------------------------------------------------+
Figure 5. Server Is Given a TempID as Peer Identity; Server
Requires a PermID
図5。 同輩のアイデンティティとしてTempIDをサーバに与えます。 サーバはPermIDを必要とします。
1. The Peer (or the Authenticator on behalf of the Peer) sends an
EAP.Request message of type Identity and includes the TempID.
1. Peer(または、Peerを代表したAuthenticator)はタイプIdentityに関するEAP.Requestメッセージを送って、TempIDを含んでいます。
2. The Server requires a PermID instead, so it sends an EAP.Request
message of type SAKE and subtype Identity with attributes
AT_PERM_ID_REQ and AT_SERVERID.
2. Serverが代わりにPermIDを必要とするので、それは_属性AT_PERM_IDのREQとAT_SERVERIDとタイプSAKEとsubtype Identityに関するEAP.Requestメッセージを送ります。
3. The Peer sends an EAP.Response message of type SAKE and subtype
Identity containing the attribute AT_PEERID carrying the Peer
PermID.
3. Peerは属性AT_PEERIDを含むタイプSAKEとsubtype Identityに関するEAP.ResponseメッセージにPeer PermIDを運ばせます。
3.2.5. Key Hierarchy
3.2.5. 主要な階層構造
EAP-SAKE uses a three-level key hierarchy.
EAP-SAKEは主要な3レベルの階層構造を使用します。
Level 1 contains the pre-shared secret called Root Secret. This is a 32-byte high-entropy string partitioned into the Root-Secret-A part (16 bytes) and the Root-Secret-B part (16 bytes).
レベル1はRoot Secretと呼ばれるプレ共有秘密キーを含んでいます。 これはRoot秘密A部分(16バイト)とRoot秘密B部分(16バイト)に仕切られた32バイトの高エントロピーストリングです。
Vanderveen & Soliman Informational [Page 13] RFC 4763 EAP-SAKE November 2006
[13ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
Level 2 contains the key derivation key called the SAKE Master Secret (SMS). SMS-A is derived from the Root-Secret-A key and the Peer and Server nonces using the EAP-SAKE Key-Derivation Function (KDF), and similarly for SMS-B. The SMS is known only to the Peer and Server and is not made known to other parties.
レベル2はSAKE Master Secret(SMS)と呼ばれる主要な派生キーを含んでいます。 SMS-BのためにRoot秘密Aキー、Peer、およびServer一回だけから同様に、EAP-SAKE Key-派生Function(KDF)を使用することでSMS-Aを得ます。 SMSはPeerとServerだけにおいて知られていて、相手に明らかにされません。
Level 3 contains session keys, such as Transient EAP Keys (TEK), Master Session Key (MSK), and Extended MSK (EMSK). TEKs are keys for use local to the EAP method only. They are derived from the SMS-A and the nonces using the EAP-SAKE KDF. They are partitioned into a 16-byte TEK-Auth, used to compute the MICs, and a 16-byte TEK-Cipher, used to encrypt selected attributes. Since the SMS is fresh, so are the derived TEKs.
レベル3はTransient EAPキーズなどのセッションキー(TEK)、Master Session Key(MSK)、およびExtended MSK(EMSK)を含んでいます。 TEKsはEAPメソッドだけへの地方の使用のためのキーです。 SMS-Aと一回だけからEAP-SAKE KDFを使用することでそれらを得ます。 それらは16バイトのTEK-Authに仕切られます、MICs、および16バイトのTEK-暗号を計算するのにおいて使用されています、選択された属性を暗号化するのにおいて、使用されています。 派生しているTEKsもSMSが新鮮であるからです。
+--------------------+ +--------------------+
| Root-Secret-A | | Root-Secret-B |
| (pre-shared secret)| | (pre-shared secret)|
+--------------------+ +--------------------+
| |
V V
+-------------------+ +--------------------+
| SAKE Master Secret|<---RAND_S------------->| SAKE Master Secret |
| (SMS-A) | | | (SMS-B) |
| |<-------]---RAND_P----->| |
+-------------------+ | | +--------------------+
| | | |
V | | V
+--------------------+ | | +--------------------+
| Transient EAP Keys |<------+-----+-------->| Session Keys: |
| TEK-Auth,TEK-Cipher|<------------+-------->| MSK, EMSK |
+--------------------+ +--------------------+
+--------------------+ +--------------------+ | 根の秘密A| | 根の秘密B| | (プレ共有秘密キー)| | (プレ共有秘密キー)| +--------------------+ +--------------------+ | | +に対するV-------------------+ +--------------------+ | 酒のマスター秘密| <、-、--底ならし革_S------------->| 酒のマスター秘密| | (SMS-a) | | | (SMS-B) | | | <、-、-、-、-、-、--]---底ならし革_P----->|、| +-------------------+ | | +--------------------+ | | | | V| | +に対して--------------------+ | | +--------------------+ | 一時的なEAPキー| <、-、-、-、-、--+-----+-------->| セッションキー: | | TEK-Auth、TEK-暗号| <、-、-、-、-、-、-、-、-、-、-、--+-------->| MSK、EMSK| +--------------------+ +--------------------+
Figure 6. Key Hierarchy for the EAP-SAKE Method
図6。 EAP-酒のメソッドのための主要な階層構造
On another branch of level 3 of the key hierarchy are the MSK and EMSK, each mandated to be 64 bytes long. They are derived from the SMS-B and the nonces using the EAP-SAKE KDF. Again, since the SMS is fresh, so are the derived MSK/EMSK. The MSK is meant to be exported and relayed to other parties. The EMSK is reserved for future use, such as derivation of application-specific keys, and is not shared with other parties.
主要な階層構造のレベル3の別の支店に、MSKとEMSKがあります、とそれぞれが64バイト長になるように強制しました。 SMS-Bと一回だけからEAP-SAKE KDFを使用することでそれらを得ます。 派生しているMSK/EMSKもSMSが再び新鮮であるからです。 相手にエクスポートされて、MSKはリレーされることになっています。 EMSKはアプリケーション特有のキーの派生などの今後の使用のために予約されて、相手と共有されません。
Vanderveen & Soliman Informational [Page 14] RFC 4763 EAP-SAKE November 2006
[14ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
The EAP-SAKE key material is summarized in the table below.
EAP-SAKEの主要な材料は以下のテーブルにまとめられます。
===================================================================
Key Size Scope Lifetime Use
(bytes)
===================================================================
Root-Secret-A 16 Peer, Server Device Derive TEK
--------------------------------------------------------------------
Root-Secret-B 16 Peer, Server Device Derive MSK, EMSK
--------------------------------------------------------------------
TEK-Auth 16 Peer, Server MSK Life Compute MICs
--------------------------------------------------------------------
TEK-Cipher 16 Peer, Server MSK Life Encrypt attribute
--------------------------------------------------------------------
MSK 64 Peer, Server, MSK Life Derive keys for
Authenticator lower-layer use
--------------------------------------------------------------------
EMSK 64 Peer, Server MSK Life Reserved
--------------------------------------------------------------------
=================================================================== 主要なサイズ範囲生涯使用(バイト)=================================================================== 根の秘密A16同輩、サーバデバイスはTEKを引き出します。-------------------------------------------------------------------- 根の秘密B16はじっと見て、サーバデバイスはMSK、EMSKを引き出します。-------------------------------------------------------------------- TEK-Auth16同輩、サーバMSKの寿命はMICsを計算します。-------------------------------------------------------------------- TEK-暗号16Peer、Server MSK Life Encrypt属性-------------------------------------------------------------------- MSK64Peer、Server、Authenticator下層使用のためのMSK Life Deriveキー-------------------------------------------------------------------- EMSK64同輩、MSKの寿命が予約したサーバ--------------------------------------------------------------------
A key name format is not provided in this version.
主要な名前形式はこのバージョンに提供されません。
Since this version of EAP-SAKE does not support fast re- authentication, the lifetime of the TEKs is to extend only until the next EAP mutual authentication. The MSK lifetime dictates when the next mutual authentication is to take place. The Server MAY convey the MSK lifetime to the Peer in the AT_MSK_LIFE attribute. Note that EAP-SAKE does not support key lifetime negotiation.
EAP-SAKEのこのバージョンが速い再認証をサポートしないので、TEKsの寿命は次のEAPの互いの認証までしか広がることになっていません。 MSK寿命は、次の互いの認証がいつ行われることになっているかを決めます。 ServerはAT_MSK_LIFE属性でMSK生涯をPeerに伝えるかもしれません。 EAP-SAKEが主要な生涯交渉をサポートしないことに注意してください。
The EAP-SAKE Method-Id is the contents of the RAND_S field from the AT_RAND_S attribute, followed by the contents of the RAND_P field in the AT_RAND_P attribute.
EAP-SAKE Method-イドはAT_RAND_P属性におけるRAND_P分野のコンテンツがあとに続いたAT_RAND_S属性からのRAND_S分野のコンテンツです。
3.2.6. Key Derivation
3.2.6. 主要な派生
3.2.6.1. Key-Derivation Function
3.2.6.1. 主要な派生機能
For the rest of this document, KDF-X denotes the EAP-SAKE Key- Derivation Function whose output is X bytes. This function is the pseudo-random function of [IEEE802.11i].
このドキュメントの残りのために、KDF-Xは出力がXバイトであるEAP-SAKE Key派生Functionを指示します。 この機能は[IEEE802.11i]の擬似ランダム機能です。
The function takes three strings of bytes of arbitrary lengths: a Key, a Label, and a Msg, and outputs a string Out of length X bytes as follows:
機能はバイトの任意の長さの3個のストリングを取ります: Key、Label、エムエスジー、および出力aは以下の長さのXバイトのOutを結びます:
Out = KDF-X (Key, Label, Msg)
出ている=KDF-X(キー、ラベル、エムエスジー)
Vanderveen & Soliman Informational [Page 15] RFC 4763 EAP-SAKE November 2006
[15ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
The KDF is a keyed hash function with key "Key" and operating on input "Label | Msg". The convention followed herein is that concatenation is denoted by |, FLOOR denotes the floor function, and [x...y] denotes bytes x through y.
KDFは主要な「キー」がある合わせられたハッシュ関数と「ラベル」という入力を作動することにさせます。| 「エムエスジー。」 連結が指示されるここに続かれるコンベンションがあります。|, FLOORは床の機能を指示します、そして、[x...y]はyを通してバイトxを指示します。
The label is an ASCII character string. It is included in the exact form it is given without a length byte or trailing null character.
ラベルはASCII文字列です。 それは長さのバイトも引きずっているヌル文字なしで与えられている正確なフォームに含まれています。
Below, "Length" denotes a single unsigned octet with values between 0 and 255 (bytes). The following functions are defined (see [HMAC], [SHA1]):
以下では、値が0と255(バイト)の間ある状態で、「長さ」がただ一つの未署名の八重奏を指示します。 以下の機能は定義されます([SHA1]、[HMAC]を見てください):
H-SHA1(Key, Label, Msg, Length) := HMAC-SHA1(Key, Label|Y|Msg|Length) where Y := 0x00 KDF-16(Key, Label, Msg) := KDF(Key, Label, Msg, 16) KDF-32(Key, Label, Msg) := KDF(Key, Label, Msg, 32) KDF-128(Key, Label, Msg) := KDF(Key, Label, Msg, 128)
H-SHA1(キー、Label、エムエスジー、Length):=HMAC-SHA1、(主要なLabel|Y|エムエスジー| 長さ)どこY:=0×00KDF-16(キー、Label、エムエスジー):=KDF(キー、Label、エムエスジー、16)KDF-32(キー、Label、エムエスジー):=KDF(キー、Label、エムエスジー、32)KDF-128(キー、Label、エムエスジー):=KDF(キー、ラベル、エムエスジー、128)
KDF(Key, Label, Msg, Length) R := [] ;; null string for i := 0 to FLOOR(Length/20)-1 do R := R | H-SHA1(Key, Label, Msg, i) return R[0...(Length-1)]
KDF(キー、ラベル、エムエスジー、長さ)R:=[]。 -1がR:=Rをするi:=0からFLOOR(長さ/20)のためのヌルストリング| H-SHA1(キー、Label、エムエスジー、i)リターンR[0(長さ-1)…]
3.2.6.2. Transient EAP Keys Derivation
3.2.6.2. 一時的なEAPキー派生
The Peer and Server derive the SMS and then the TEK as follows:
PeerとServerはSMSを引き出して、次に、以下のTEKを引き出します:
SMS-A = KDF-16 (Root-Secret-A, "SAKE Master Secret A", RAND_P|RAND_S) TEK = KDF-32 (SMS-A, "Transient EAP Key", RAND_S | RAND_P) TEK-Auth = TEK[0...15] TEK-Cipher = TEK[16...31]
SMS-A=KDF-16(底ならし革_P| 根の秘密A、「酒のマスター秘密A」、底ならし革_S)TEK=KDF-32(底ならし革_S| SMS-A、「一時的なEAPキー」、底ならし革_P)TEK-AuthはTEK[0...15] TEK-暗号=TEKと等しいです。[16...31]
3.2.6.3. Extended/Master Session Key Derivation
3.2.6.3. 拡張/マスターセッション主要な派生
The Peer and the Server derive the MSK/EMSK, as follows:
PeerとServerは以下の通りMSK/EMSKを引き出します:
SMS-B = KDF-16 (Root-Secret-B, "SAKE Master Secret B", RAND_P|RAND_S) Session-Key-Block=KDF-128(SMS-B, "Master Session Key", RAND_S|RAND_P) MSK = Session-Key-Block[0...63] EMSK = Session-Key-Block[64...127]
KDF-128(底ならし革_S| SMS-B、「マスターセッションキー」、底ならし革_P)SMS-B=KDF-16(底ならし革_P| 根の秘密B、「酒のマスター秘密B」、底ならし革_S)セッションキー・ブロック=MSKはセッションセッションキー・ブロック[0...63]EMSK=キー・ブロックと等しいです。[64...127]
The derivation above affords the required cryptographic separation between the MSK and EMSK. That is, knowledge of the EMSK does not immediately lead to knowledge of the MSK, nor does knowledge of the MSK immediately lead to knowledge of the EMSK.
上の派生は必要な暗号の分離をMSKとEMSKの間に提供します。 すなわち、EMSKに関する知識はすぐにMSKに関する知識につながりません、そして、MSKに関する知識はすぐに、EMSKに関する知識につながりません。
Vanderveen & Soliman Informational [Page 16] RFC 4763 EAP-SAKE November 2006
[16ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
3.2.7. Ciphersuite Negotiation
3.2.7. Ciphersuite交渉
A ciphersuite is identified by a numeric value called the Security Parameter Index (SPI). The SPI is used here in the EAP-SAKE method in order to negotiate a ciphersuite between the Peer and the Server for EAP data protection only. Obviously, this ciphersuite can only be used late in the EAP conversation, after it has been agreed upon by both the Peer and the Server.
ciphersuiteはSecurity Parameter Index(SPI)と呼ばれる数値によって特定されます。 SPIは、EAPデータ保護だけのためにPeerとServerの間のciphersuiteを交渉するのにここ、EAP-SAKEメソッドで使用されます。 明らかに、遅くEAPの会話にこのciphersuiteを使用できるだけです、それがPeerとServerの両方によって同意された後に。
The EAP method may or may not need to use this ciphersuite, since attribute encryption is optional. For example, if the temporary identifier needs to be delivered to the Peer and needs to be encrypted, then the negotiated ciphersuite will be used for this task. If there are no attributes that need encryption as they are passed to the Peer, then this ciphersuite is never used.
属性暗号化が任意であるので、EAPメソッドは、このciphersuiteを使用する必要があるかもしれません。 例えば、一時的な識別子が、Peerに提供されるのが必要であり、暗号化される必要があると、交渉されたciphersuiteはこのタスクに使用されるでしょう。 それらがPeerに通過されるとき暗号化を必要とする属性が全くなければ、このciphersuiteは決して使用されません。
As with most other methods employing ciphersuite negotiation, the following exchange is employed: the Peer sends an ordered list of one or more supported ciphersuites, starting with the most preferred one, in a field SPI_P. The Server then sends back the one ciphersuite chosen in a field SPI_S. The Server SHOULD choose the strongest ciphersuite supported by both of them.
他のほとんどのメソッドのように、ciphersuite交渉を使う以下の交換採用しています: Peerはciphersuitesであるとサポートされた1以上の規則正しいリストを送ります、最も都合のよい1つから始めて、分野SPI_Pで。 そして、Serverは分野SPI_Sで選ばれた1ciphersuiteを返送します。 Server SHOULDはそれらの両方によってサポートされる中で最も強いciphersuiteを選びます。
Ciphersuite negotiation for data protection is achieved via SAKE Signaling as follows. In the EAP.Response/SAKE/Challenge, the Peer sends a list of supported ciphersuites, SPI_P, and protects that with a MIC. In the EAP.Request/SAKE/Confirm, the Server sends one selected ciphersuite, SPI_S, and signs that with a MIC. Finally, the Peer confirms the selected ciphersuite and readiness to use it in a signed EAP.Response/SAKE/Confirm message. The negotiation is secure because of the Message Integrity Checks that cover the entire EAP message.
データ保護のためのCiphersuite交渉は以下のSAKE Signalingを通して達成されます。 EAP.Response/SAKE/挑戦では、Peerはサポートしているciphersuitesのリスト、SPI_Pを送って、MICと共にそれを保護します。 EAP.Request/SAKE/では、Serverが1選択されたciphersuite、SPI_Sを送って、MICをそれと契約すると確認してください。 最終的に、Peerは、選択されたciphersuiteと署名しているEAP.Response/SAKE/でそれを使用する準備がメッセージを確認すると確認します。 交渉は全体のEAPメッセージをカバーするMessage Integrity Checksのために安全です。
3.2.8. Message Integrity and Encryption
3.2.8. メッセージの保全と暗号化
This section specifies the EAP/SAKE attributes used for message integrity and attribute encryption: AT_MIC_S, AT_MIC_P, AT_IV, AT_ENCR_DATA, and AT_PADDING. Only the AT_MIC_S and AT_MIC_P are mandatory to use during the EAP-SAKE exchange.
このセクションはメッセージの保全と属性暗号化に使用されるEAP/SAKE属性を指定します: _ミック_Sにおいて_ミック_Pにおいて_IVにおいて_ENCR_データにおいて_詰め物において。 AT_MIC_SとAT_MIC_Pだけが、EAP-SAKE交換の間、使用するために義務的です。
Because the TEKs necessary for protection of the attributes and for message authentication are derived using the nonces RAND_S and RAND_P, the AT_MIC_S and AT_MIC_P attributes can only be used in the EAP.Response/SAKE/Challenge message and any messages sent thereafter.
属性の保護と通報認証に必要なTEKsが一回だけのRAND_SとRAND_Pを使用することで引き出されるので、EAP.Response/SAKE/挑戦メッセージとその後送られたどんなメッセージでもAT_MIC_SとAT_MIC_P属性を使用できるだけです。
Vanderveen & Soliman Informational [Page 17] RFC 4763 EAP-SAKE November 2006
[17ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
3.2.8.1. The AT_MIC_S and AT_MIC_P Attributes
3.2.8.1. _MIC_Sと_MIC_P属性
The AT_MIC_S and AT_MIC_P attributes are used for EAP-SAKE message integrity. The AT_MIC_S attribute MUST be included in all EAP-SAKE packets that the Server sends whenever key material (TEK) has been derived. That is, the AT_MIC_S attribute MUST be included in the EAP.Request/SAKE/Confirm message. The AT_MIC_S MUST NOT be included in EAP.Request/SAKE/Challenge messages, or EAP.Request/SAKE/Identity messages.
AT_MIC_SとAT_MIC_P属性はEAP-SAKEメッセージの保全に使用されます。 主要な材料(TEK)が誘導されたときはいつも、Serverが送るすべてのEAP-SAKEパケットにAT_MIC_S属性を含まなければなりません。 すなわち、AT_MIC_S属性はメッセージをEAP.Request/SAKEに含まれているか、または確認することであるに違いありません。 EAP.Request/SAKE/挑戦メッセージ、またはEAP.Request/SAKE/アイデンティティメッセージにAT_ミック_Sを含んではいけません。
The AT_MIC_P attribute MUST be included in all EAP-SAKE packets the Peer sends whenever key material (TEK) has been derived. That is, the AT_MIC_P attribute MUST be included in the EAP.Response/SAKE/Challenge and EAP.Response/SAKE/Confirm messages.
主要な材料(TEK)が誘導されたときはいつも、Peerが送るすべてのEAP-SAKEパケットにAT_MIC_P属性を含まなければなりません。 EAP.Response/SAKE/挑戦にすなわち、AT_MIC_P属性を含まなければなりません、そして、EAP.Response/SAKE/はメッセージを確認します。
The AT_MIC_P attribute MUST NOT be included in the EAP.Response/SAKE/Auth-Reject message since the Peer has not confirmed that it has the same TEK as the Server.
Peerが、Serverと同じTEKを持っていると確認していないので、Auth EAP.Response/SAKE/廃棄物メッセージにAT_MIC_P属性を含んではいけません。
Messages that do not meet the conditions specified above MUST be silently discarded upon reception.
レセプションで静かに上で指定された条件を満たさないメッセージを捨てなければなりません。
The value field of the AT_MIC_S and AT_MIC_P attributes contain a message integrity check (MIC). The MIC is calculated over the entire EAP packet, prepended with the Server nonce and identifier and the Peer nonce and identifier. The value field of the MIC attribute is set to zero when calculating the MIC. Including the Server and Peer nonces and identifiers aids in detecting replay and man-in-the-middle attacks.
AT_MIC_Sの値の分野とAT_MIC_P属性はメッセージの保全チェック(MIC)を含んでいます。 MICはServer一回だけと識別子でprependedされた、全体のEAPパケット、Peer一回だけ、および識別子に関して計算されます。 MICについて計算するとき、MIC属性の値の分野はゼロに設定されます。 再生と中央の男性攻撃を検出する際にServer、Peer一回だけ、および識別子援助を含んでいます。
The Peer computes its MIC as follows:
Peerは以下のMICを計算します:
MIC_P = KDF-16 (TEK-Auth, "Peer MIC", RAND_S | RAND_P | PEERID | 0x00 | SERVERID | 0x00 | <EAP-packet>),
MIC_PはKDF-16と等しいです(TEK-Auth、「同輩ミック」底ならし革_S| 底ならし革_P| PEERID|0×00|SERVERID|0×00|<EAP-パケット>)。
while the Server computes its MIC as
ServerはMICを計算します。
MIC_S = KDF-16 (TEK-Auth, "Server MIC", RAND_P |RAND_S | SERVERID | 0x00 | PEERID | 0x00 | <EAP-packet>).
MIC_SはKDF-16と等しいです(TEK-Auth、「Serverミック」底ならし革_P| 底ならし革_S| SERVERID|0×00|PEERID|0×00|<EAP-パケット>)。
Here, <EAP-packet> denotes the entire EAP packet, used as a string of bytes, the MIC value field set to zero. 0x00 denotes a single octet value used to delimit SERVERID and PEERID. The PEERID and SERVERID, respectively, are the ones carried in the corresponding attributes in the SAKE/Challenge messages.
ここで、<EAP-パケット>はMIC値の分野がゼロに一連のバイトセットしたので使用される全体のEAPパケットを指示します。 0×00 SERVERIDとPEERIDを区切るのに使用されるただ一つの八重奏値を指示します。 PEERIDとSERVERIDはそれぞれSAKE/挑戦メッセージの対応する属性で運ばれたものです。
Vanderveen & Soliman Informational [Page 18] RFC 4763 EAP-SAKE November 2006
[18ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
In case the SAKE/Challenge exchange was preceded by an EAP.Request/SAKE/Identity message containing the AT_SERVERID Attribute, then the SERVERID value in the MIC_P and MIC_S computation MUST be set to the value of this attribute.
AT_SERVERID Attributeを含むEAP.Request/SAKE/アイデンティティメッセージがSAKE/挑戦交換に先行するといけなかったので、そして、MIC_PとMIC_S計算におけるSERVERID値をこの属性の値に設定しなければなりません。
If the AT_SERVERID was not included in either the SAKE/Challenge message or the SAKE/Identity message, then the value of the SERVERID used in the computation of MIC_P and MIC_S MUST be empty. If the AT_PEERID was not included in the SAKE/Challenge message, and there was no EAP.Response/SAKE/Identity message preceding the SAKE/Challenge messages, then the value of the PEERID used in the computation of MIC_P and MIC_S MUST be empty.
AT_SERVERIDがSAKE/挑戦メッセージかSAKE/アイデンティティメッセージのどちらかに含まれていなかったなら、MIC_Pとミック_Sの計算に使用されるSERVERIDの値は空であるに違いありません。 AT_PEERIDがSAKE/挑戦メッセージに含まれないで、またSAKE/挑戦メッセージに先行するEAP.Response/SAKE/アイデンティティメッセージが全くなかったなら、MIC_Pとミック_Sの計算に使用されるPEERIDの値は空であるに違いありません。
The Server and Peer identity are included in the computation of the signed responses so that the Peer and Server can verify each other's identities, and the possession of a common secret, the TEK-Auth. However, since the AT_SERVERID is not explicitly signed with a MIC by the Server, EAP-SAKE does not claim channel binding.
ServerとPeerのアイデンティティは、PeerとServerが互いのアイデンティティ、および一般的な秘密(TEK-Auth)の所有物について確かめることができるように、署名している応答の計算に含まれています。 しかしながら、AT_SERVERIDがServerによって明らかにMICを契約されないので、EAP-SAKEはチャンネル結合を要求しません。
3.2.8.2. The AT_IV, AT_ENCR_DATA, and AT_PADDING Attributes
3.2.8.2. 属性を水増しする__IVにおいて_ENCR_データにおいて
The AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted information between the Server and the Peer. The value field of AT_IV contains an initialization vector (IV) if one is required by the encryption algorithm used. It is not mandatory that the AT_IV attribute be included whenever the AT_ENCR_DATA attribute is.
ServerとPeerの間に暗号化された情報を伝えるのにAT_IVとAT_ENCR_DATA属性を使用できます。 1が使用される暗号化アルゴリズムによって必要とされるなら、AT_IVの値の分野は初期化ベクトル(IV)を含んでいます。 AT_IV属性がAT_ENCR_DATA属性がそうであるときはいつも、含まれているのは、義務的ではありません。
However, the AT_IV attribute MUST NOT be included unless the AT_ENCR_DATA is included. Messages that do not meet this condition MUST be silently discarded.
しかしながら、AT_ENCR_DATAが含まれていない場合、AT_IV属性を含んではいけません。 静かにこの条件を満たさないメッセージを捨てなければなりません。
Attributes can be encrypted only after a ciphersuite has been agreed on, i.e., in any message starting with the Server's EAP.Request/SAKE/Confirm message. The attributes MUST be encrypted using algorithms corresponding to the SPI value specified by the AT_SPI_S attribute. The attributes MUST be encrypted using the TEK- Cipher key, whose derivation is specified in Section 3.2.6.2.
ciphersuiteがメッセージをすなわち、ServerのEAP.Request/SAKEから始まるどんなメッセージでも同意されるか、または確認するためにことになった後にだけ属性を暗号化できます。 AT_SPI_S属性によって指定されたSPI値に対応するアルゴリズムを使用して、属性を暗号化しなければなりません。 TEK暗号キー(派生はセクション3.2.6で.2に指定される)を使用して、属性を暗号化しなければなりません。
If an IV is required by the encryption algorithm, then the sender of the AT_IV attribute MUST NOT reuse the IV value from previous EAP- SAKE packets. The sender MUST choose a new value for each AT_IV attribute. The sender SHOULD use a good random number generator to generate the initialization vector (see [RFC4086] for guidelines).
IVがそうなら、暗号化アルゴリズムが必要であることで、そして、AT_IV属性の送付者は前のEAP- SAKEパケットからIV値を再利用してはいけません。 送付者はそれぞれのAT_IV属性のための新しい値を選ばなければなりません。 送付者SHOULDは、初期化ベクトルを生成するのに良い乱数発生器を使用します(ガイドラインに関して[RFC4086]を見てください)。
Vanderveen & Soliman Informational [Page 19] RFC 4763 EAP-SAKE November 2006
[19ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
The value field of the AT_ENCR_DATA attribute consists of bytes encrypted using the ciphersuite specified in the AT_SPI_S attribute. The encryption key is the TEK-Cipher, and the plaintext consists of one or more concatenated EAP-SAKE attributes.
AT_ENCR_DATA属性の値の分野はAT_SPI_S属性で指定されたciphersuiteを使用することで暗号化されたバイトから成ります。 暗号化キーはTEK-暗号です、そして、平文は1かさらに連結されたEAP-SAKE属性から成ります。
The default encryption algorithm, as described in Section 3.2.8.3, 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 the value field of the AT_ENCR_DATA attribute. The length of the padding is chosen so that the length of the value field of the AT_ENCR_DATA attribute becomes a multiple of 16 bytes. The AT_PADDING attribute SHOULD NOT be included if the total length of other attributes present within the AT_ENCR_DATA attribute is a multiple of 16 bytes. The length of the AT_PADDING attribute includes the Attribute Type and Attribute Length fields. The actual pad bytes in the value field are set to zero (0x00) on sending. The recipient of the message MUST verify that the pad bytes are zero after decryption and MUST silently discard the message otherwise.
デフォルト暗号化アルゴリズムは、セクション3.2.8で.3について説明するので、平文の長さが16バイトの倍数であることを必要とします。 送付者は、最後の属性としてAT_ENCR_DATA属性の値の分野の中にAT_PADDING属性を含む必要があるかもしれません。 詰め物の長さが選ばれているので、AT_ENCR_DATA属性の値の分野の長さは16バイトの倍数になります。 AT_ENCR_DATA属性の中の現在の他の属性の全長が16バイトの倍数であるなら含まれていて、AT_PADDINGはSHOULD NOTを結果と考えます。 AT_PADDING属性の長さはAttribute TypeとAttribute Length分野を含んでいます。 値の分野の実際のパッドバイトが発信での(0×00)のゼロに合うように設定されます。 メッセージの受取人は、パッドバイトが復号化の後のゼロであり、そうでなければ、静かにメッセージを捨てなければならないことを確かめなければなりません。
The MIC computed on the entire EAP message can be used to obviate the need for special integrity protection or message authentication of the encrypted attributes.
暗号化された属性の特別な保全保護か通報認証の必要性を取り除くのに全体のEAPメッセージで計算されたMICは使用できます。
An example of the AT_ENCR_DATA attribute is shown in Section 3.3.3.
AT_ENCR_DATA属性に関する例はセクション3.3.3で示されます。
3.2.8.3. Security Parameter Index (SPI) Considerations
3.2.8.3. セキュリティパラメタインデックス(SPI)問題
An SPI value is a variable-length string identifying at least an encryption algorithm and possibly a "security association". EAP-SAKE does not mandate the format of the SPI; it only mandates that the default encryption algorithm be supported if encryption is supported. That is, if an implementation compliant with this document supports encryption, then it MUST support the AES-CBC cipher.
SPI値は少なくとも暗号化アルゴリズムとことによると「セキュリティ協会」を特定する可変長文字列です。 EAP-SAKEはSPIの形式を強制しません。 それは、暗号化がサポートされるならデフォルト暗号化アルゴリズムがサポートされるのを強制するだけです。 すなわち、このドキュメントによる対応することの実装が暗号化をサポートするなら、それは、AES-CBCが暗号であるとサポートしなければなりません。
The default encryption algorithm AES-CBC involves the AES block cipher [AES] in the Cipher-Block-Chaining (CBC) mode of operation [CBC].
デフォルト暗号化アルゴリズムAES-CBCはCipherブロック推論(CBC)運転モード[CBC]にAESブロック暗号[AES]にかかわります。
The Peer in the EAP-SAKE method can send up to four SPI values in its SPI_P field. Because the length of the AT_SPI_P and AT_SPI_S attributes must each be a multiple of 2 bytes, the sender pads the value field with zero bytes when necessary (the AT_PADDING attribute is not used here). For example, the value field of the AT_SPI_S contains one byte with the chosen SPI, followed by one byte of zeros.
EAP-SAKEメソッドによるPeerはSPI_P分野で最大4つのSPI値を送ることができます。 AT_SPI_PとAT_SPI_S属性の長さがそれぞれ2バイトの倍数であるに違いないので、必要であるときに、送付者はどんなバイトでも値の分野を水増ししません(AT_PADDING属性はここで使用されません)。 例えば、AT_SPI_Sの値の分野は1バイトのゼロがあとに続いた選ばれたSPIがある1バイトを含んでいます。
Vanderveen & Soliman Informational [Page 20] RFC 4763 EAP-SAKE November 2006
[20ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
3.2.9. Fragmentation
3.2.9. 断片化
The EAP-SAKE method does not require fragmentation, as the messages do not get excessively long. That is, EAP packets are well within the limit of the maximum transmission unit of other layers (link, network). The only variable fields are those carrying NAIs, which are limited by their length field to 256 bytes.
メッセージが過度に長くならないとき、EAP-SAKEメソッドは断片化を必要としません。 すなわち、EAPパケットは他の層(リンク、ネットワーク)のマキシマム・トランスミッション・ユニットの枠内に良いです。 唯一の変数フィールドが彼らの長さの分野によって256バイトに制限されるNAIsを運ぶものです。
3.2.10. Error Cases
3.2.10. 誤り事件
Malformed messages: As a general rule, if a Peer or Server receives an EAP-SAKE packet that contains an error, the implementation SHOULD silently discard this packet, not change state, and not send any EAP messages to the other party. Examples of such errors include a missing mandatory attribute, an attribute that is not allowed in this type of message, and unrecognized subtypes or attributes.
奇形のメッセージ: 概して、PeerかServerが誤りを含むEAP-SAKEパケットを受けるなら、実装SHOULDは状態を変えるのではなく、静かにこのパケットを捨てて、どんなEAPメッセージも相手に送りません。 そのような誤りに関する例はなくなった義務的な属性か、このタイプに関するメッセージに許容されていない属性と、認識されていない血液型亜型か属性を含んでいます。
Non-matching Session Id: If a Peer or Server receives an EAP-SAKE packet with a Session Id field not matching the Session Id from the previous packet in this session, that entity SHOULD silently discard this packet (not applicable for the first message of an EAP-SAKE session).
Non-matching Session Id: If a Peer or Server receives an EAP-SAKE packet with a Session Id field not matching the Session Id from the previous packet in this session, that entity SHOULD silently discard this packet (not applicable for the first message of an EAP-SAKE session).
Peer Authorization Failure: It may be possible that a Peer is not authorized for services, such as when the terminal device is reported stolen. In that case, the Server SHOULD send an EAP.Failure message.
Peer Authorization Failure: It may be possible that a Peer is not authorized for services, such as when the terminal device is reported stolen. In that case, the Server SHOULD send an EAP.Failure message.
Unexpected EAP.Success: A Server MUST NOT send an EAP-Success message before the SAKE/Challenge and SAKE/Confirm rounds. The Peer MUST silently discard any EAP.Success packets before the Peer has successfully authenticated the Server via the EAP.Response/SAKE/Confirm packet.
Unexpected EAP.Success: A Server MUST NOT send an EAP-Success message before the SAKE/Challenge and SAKE/Confirm rounds. The Peer MUST silently discard any EAP.Success packets before the Peer has successfully authenticated the Server via the EAP.Response/SAKE/Confirm packet.
The Peer and Server SHOULD log all error cases.
The Peer and Server SHOULD log all error cases.
Vanderveen & Soliman Informational [Page 21] RFC 4763 EAP-SAKE November 2006
Vanderveen & Soliman Informational [Page 21] RFC 4763 EAP-SAKE November 2006
3.3. Message Formats
3.3. Message Formats
3.3.1. Message Format Summary
3.3.1. Message Format Summary
A summary of the EAP packet format [EAP] is shown below for convenience. The fields are transmitted from left to right.
A summary of the EAP packet format [EAP] is shown below for convenience. The fields are transmitted from left to right.
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=EAP-SAKE | Version=2 | Session ID | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=EAP-SAKE | Version=2 | Session ID | Subtype | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
Code
1 - Request
1 - Request
2 - Response
2 - Response
Identifier
Identifier
The identifier field is one octet and aids in matching responses
with requests.
The identifier field is one octet and aids in matching responses with requests.
Length
Length
The Length field is two octets and indicates the number of octets
in an EAP message including the Code, Identifier, Length, Type,
and Data fields.
The Length field is two octets and indicates the number of octets in an EAP message including the Code, Identifier, Length, Type, and Data fields.
Type
Type
To be assigned.
To be assigned.
Version
Version
The EAP-SAKE method as described herein is version 2.
The EAP-SAKE method as described herein is version 2.
Session ID
Session ID
The Session ID is a 1-byte random number that MUST be freshly
generated by the Server that must match all EAP messages in a
particular EAP conversation.
The Session ID is a 1-byte random number that MUST be freshly generated by the Server that must match all EAP messages in a particular EAP conversation.
Vanderveen & Soliman Informational [Page 22] RFC 4763 EAP-SAKE November 2006
Vanderveen & Soliman Informational [Page 22] RFC 4763 EAP-SAKE November 2006
Subtype
Subtype
EAP-SAKE subtype: SAKE/Challenge, SAKE/Confirm, SAKE/Auth-Reject,
and SAKE/Identity. All messages of type "EAP-SAKE" that are not
of these subtypes MUST silently discarded.
EAP-SAKE subtype: SAKE/Challenge, SAKE/Confirm, SAKE/Auth-Reject, and SAKE/Identity. All messages of type "EAP-SAKE" that are not of these subtypes MUST silently discarded.
Message Name Subtype Value (decimal)
=============================================
SAKE/Challenge 1
SAKE/Confirm 2
SAKE/Auth-Reject 3
SAKE/Identity 4
Message Name Subtype Value (decimal) ============================================= SAKE/Challenge 1 SAKE/Confirm 2 SAKE/Auth-Reject 3 SAKE/Identity 4
3.3.2. Attribute Format
3.3.2. Attribute Format
The EAP-SAKE attributes that are part of the EAP-SAKE packet follow the Type-Length-Value format with 1-byte Type, 1-byte Length, and variable-length Value (up to 255 bytes). The Length field is in octets and includes the length of the Type and Length fields. The EAP-SAKE attribute format is as follows:
The EAP-SAKE attributes that are part of the EAP-SAKE packet follow the Type-Length-Value format with 1-byte Type, 1-byte Length, and variable-length Value (up to 255 bytes). The Length field is in octets and includes the length of the Type and Length fields. The EAP-SAKE attribute format is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
Type
1-byte unsigned integer; see Table below.
1-byte unsigned integer; see Table below.
Length
Length
The total number of octets in the attribute, including Type and
Length.
The total number of octets in the attribute, including Type and Length.
Value
Value
Attribute-specific.
Attribute-specific.
Vanderveen & Soliman Informational [Page 23] RFC 4763 EAP-SAKE November 2006
Vanderveen & Soliman Informational [Page 23] RFC 4763 EAP-SAKE November 2006
The following attribute types are allocated.
The following attribute types are allocated.
-----------------------------------------------------------------
Attr. Name Length
(bytes) Skippable Description
-----------------------------------------------------------------
AT_RAND_S 18 No Server Nonce RAND_S
AT_RAND_P 18 No Peer Nonce RAND_P
AT_MIC_S 10 No Server MIC
AT_MIC_P 10 No Peer MIC
AT_SERVERID variable No Server FQDN
AT_PEERID variable No Peer NAI (tmp, perm)
AT_SPI_S variable No Server chosen SPI SPI_S
AT_SPI_P variable No Peer SPI list SPI_P
AT_ANY_ID_REQ 4 No Requires any Peer Id (tmp, perm)
AT_PERM_ID_REQ 4 No Requires Peer's permanent Id/NAI
AT_ENCR_DATA Variable Yes Contains encrypted attributes
AT_IV Variable Yes IV for encrypted attributes
AT_PADDING 2 to 18 Yes Padding for encrypted attributes
AT_NEXT_TMPID variable Yes TempID for next EAP-SAKE phase
----------------------------------------------------------------- Attr. Name Length (bytes) Skippable Description ----------------------------------------------------------------- AT_RAND_S 18 No Server Nonce RAND_S AT_RAND_P 18 No Peer Nonce RAND_P AT_MIC_S 10 No Server MIC AT_MIC_P 10 No Peer MIC AT_SERVERID variable No Server FQDN AT_PEERID variable No Peer NAI (tmp, perm) AT_SPI_S variable No Server chosen SPI SPI_S AT_SPI_P variable No Peer SPI list SPI_P AT_ANY_ID_REQ 4 No Requires any Peer Id (tmp, perm) AT_PERM_ID_REQ 4 No Requires Peer's permanent Id/NAI AT_ENCR_DATA Variable Yes Contains encrypted attributes AT_IV Variable Yes IV for encrypted attributes AT_PADDING 2 to 18 Yes Padding for encrypted attributes AT_NEXT_TMPID variable Yes TempID for next EAP-SAKE phase
AT_MSK_LIFE 6 Yes MSK Lifetime in seconds -----------------------------------------------------------------
AT_MSK_LIFE 6 Yes MSK Lifetime in seconds -----------------------------------------------------------------
Vanderveen & Soliman Informational [Page 24] RFC 4763 EAP-SAKE November 2006
Vanderveen & Soliman Informational [Page 24] RFC 4763 EAP-SAKE November 2006
3.3.3. Use of AT_ENCR_DATA Attribute
3.3.3. Use of AT_ENCR_DATA Attribute
An example of the AT_ENCR_DATA attribute, as used in the EAP.Request/SAKE/Confirm message, is shown below:
An example of the AT_ENCR_DATA attribute, as used in the EAP.Request/SAKE/Confirm message, is shown below:
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 = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Initialization Vector |
| |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |AT_ENCR_DATA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+}e
| AT_NEXT_TMPID | Length | |}n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |}c
| |}r
. Peer TempID |}y
. |}p
. |}t
| |}e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+}d
| AT_MIC_S | Length = 10 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MIC_S |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |AT_PADDING | Length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 18 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | Initialization Vector | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |AT_ENCR_DATA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+}e | AT_NEXT_TMPID | Length | |}n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |}c | |}r . Peer TempID |}y . |}p . |}t | |}e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+}d | AT_MIC_S | Length = 10 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | MIC_S | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | |AT_PADDING | Length=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vanderveen & Soliman Informational [Page 25] RFC 4763 EAP-SAKE November 2006
Vanderveen & Soliman Informational [Page 25] RFC 4763 EAP-SAKE November 2006
3.3.4. EAP.Request/SAKE/Challenge Format
3.3.4. EAP.Request/SAKE/Challenge Format
The format of the EAP.Request/SAKE/Challenge packet is shown below.
The format of the EAP.Request/SAKE/Challenge packet is shown below.
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=EAP-SAKE | Version=2 | Session ID | Subtype=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_RAND_S | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| RAND_S |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | AT_SERVERID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
| Server 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=EAP-SAKE | Version=2 | Session ID | Subtype=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_RAND_S | Length = 18 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | RAND_S | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | AT_SERVERID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : : | Server ID | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
The semantics of the fields is described below:
Code
Code
1 for Request
1 for Request
Identifier
Identifier
A random number. See [EAP].
A random number. See [EAP].
Length
Length
The length of the entire EAP packet in octets.
The length of the entire EAP packet in octets.
Type
Type
EAP-SAKE
EAP-SAKE
Version
Version
2
2
Vanderveen & Soliman Informational [Page 26] RFC 4763 EAP-SAKE November 2006
Vanderveen & Soliman Informational [Page 26] RFC 4763 EAP-SAKE November 2006
Session ID
Session ID
A random number chosen by the server to identify this EAP-Session.
A random number chosen by the server to identify this EAP-Session.
Subtype
Subtype
1 for SAKE/Challenge
1 for SAKE/Challenge
AT_RAND_S
AT_RAND_S
The value field of this attribute contains the Server nonce RAND_S
parameter. The RAND_S attribute MUST be present in
EAP.Request/SAKE/Challenge.
The value field of this attribute contains the Server nonce RAND_S parameter. The RAND_S attribute MUST be present in EAP.Request/SAKE/Challenge.
AT_SERVERID
AT_SERVERID
The value field of this attribute contains the Server identifier
(e.g., a non-null terminated string). The AT_SERVERID attribute
SHOULD be present in EAP.Request/SAKE Challenge.
The value field of this attribute contains the Server identifier (e.g., a non-null terminated string). The AT_SERVERID attribute SHOULD be present in EAP.Request/SAKE Challenge.
Vanderveen & Soliman Informational [Page 27] RFC 4763 EAP-SAKE November 2006
Vanderveen & Soliman Informational [Page 27] RFC 4763 EAP-SAKE November 2006
3.3.5. EAP.Response/SAKE/Challenge Format
3.3.5. EAP.Response/SAKE/Challenge Format
The format of the EAP.Response/SAKE/Challenge packet is shown below.
The format of the EAP.Response/SAKE/Challenge packet is shown below.
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=EAP-SAKE | Version=2 | Session ID | Subtype=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_RAND_P | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| RAND_P |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | AT_PEERID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Peer NAI :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | AT_SPI_P | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPIP | AT_MIC_P | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MIC_P |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=EAP-SAKE | Version=2 | Session ID | Subtype=1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_RAND_P | Length = 18 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | RAND_P | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | AT_PEERID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : Peer NAI : | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | AT_SPI_P | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPIP | AT_MIC_P | Length = 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MIC_P | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
The semantics of the fields is described below:
Code
Code
2 for Response
2 for Response
Identifier
Identifier
A number that MUST match the Identifier field from the
corresponding Request.
A number that MUST match the Identifier field from the corresponding Request.
Length
Length
The length of the entire EAP packet in octets.
The length of the entire EAP packet in octets.
Vanderveen & Soliman Informational [Page 28] RFC 4763 EAP-SAKE November 2006
Vanderveen & Soliman Informational [Page 28] RFC 4763 EAP-SAKE November 2006
Type
Type
EAP-SAKE
EAP-SAKE
Version
Version
2
2
Session ID
Session ID
A number matching all other EAP messages in this EAP session.
A number matching all other EAP messages in this EAP session.
Subtype
Subtype
1 for SAKE/Challenge
1 for SAKE/Challenge
AT_RAND_P
AT_RAND_P
The value field of this attribute contains the Peer nonce RAND_P
parameter. The AT_RAND_P attribute MUST be present in the
EAP.Response/SAKE/Challenge.
The value field of this attribute contains the Peer nonce RAND_P parameter. The AT_RAND_P attribute MUST be present in the EAP.Response/SAKE/Challenge.
AT_PEERID
AT_PEERID
The value field of this attribute contains the NAI of the Peer.
The Peer identity follows the same Network Access Identifier
format that is used in EAP.Response/Identity, i.e., including the
NAI realm portion. The identity is the permanent identity, or a
temporary identity. The identity does not include any terminating
null characters. The AT_PEERID attribute is optional in the
EAP.Response/SAKE/Challenge.
The value field of this attribute contains the NAI of the Peer. The Peer identity follows the same Network Access Identifier format that is used in EAP.Response/Identity, i.e., including the NAI realm portion. The identity is the permanent identity, or a temporary identity. The identity does not include any terminating null characters. The AT_PEERID attribute is optional in the EAP.Response/SAKE/Challenge.
AT_SPI_P
AT_SPI_P
The value field of this attribute contains the Peer's ciphersuite
list SPI_P parameter. The AT_SPI_P attribute is optional in the
EAP.Response/SAKE/Challenge.
The value field of this attribute contains the Peer's ciphersuite list SPI_P parameter. The AT_SPI_P attribute is optional in the EAP.Response/SAKE/Challenge.
AT_MIC_P
AT_MIC_P
The value field of this attribute contains the Peer MIC_P
parameter. The AT_MIC_P attribute MUST be present in the
EAP.Response/SAKE/Challenge.
The value field of this attribute contains the Peer MIC_P parameter. The AT_MIC_P attribute MUST be present in the EAP.Response/SAKE/Challenge.
Vanderveen & Soliman Informational [Page 29] RFC 4763 EAP-SAKE November 2006
Vanderveen & Soliman Informational [Page 29] RFC 4763 EAP-SAKE November 2006
3.3.6. EAP.Request/SAKE/Confirm Format
3.3.6. EAP.Request/SAKE/Confirm Format
The format of the EAP.Request/SAKE/Confirm packet is shown below.
The format of the EAP.Request/SAKE/Confirm packet is shown below.
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=EAP-SAKE | Version=2 | Session ID | Subtype=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_SPI_S | Length | SPI_S |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_IV | Length | Initialization Vector ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_ENCR_DATA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Data... |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_MSK_LIFE | Length=6 | MSK Lifetime... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_MIC_S | Length=18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MIC_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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=EAP-SAKE | Version=2 | Session ID | Subtype=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_SPI_S | Length | SPI_S | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_IV | Length | Initialization Vector ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | AT_ENCR_DATA | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encrypted Data... | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_MSK_LIFE | Length=6 | MSK Lifetime... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | AT_MIC_S | Length=18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MIC_S | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
The semantics of the fields is described below:
Code
Code
1 for Request
1 for Request
Identifier
Identifier
A random number. See [EAP].
A random number. See [EAP].
Length
Length
The length of the entire EAP packet in octets.
The length of the entire EAP packet in octets.
Vanderveen & Soliman Informational [Page 30] RFC 4763 EAP-SAKE November 2006
Vanderveen & Soliman Informational [Page 30] RFC 4763 EAP-SAKE November 2006
Type
Type
EAP-SAKE
EAP-SAKE
Version
Version
2
2
Session ID
Session ID
A number matching all other EAP messages in this EAP session.
A number matching all other EAP messages in this EAP session.
Subtype
Subtype
2 for SAKE Confirm
2 for SAKE Confirm
AT_SPI_S
AT_SPI_S
The value field of this attribute contains the Server chosen
ciphersuite SPI_S parameter. The AT_SPI_S attribute is optional
in the EAP.Request/SAKE/Confirm.
The value field of this attribute contains the Server chosen ciphersuite SPI_S parameter. The AT_SPI_S attribute is optional in the EAP.Request/SAKE/Confirm.
AT_IV
AT_IV
This attribute is optional to use in this message. The value
field of this attribute contains the Initialization Vector that is
used with the encrypted data following.
This attribute is optional to use in this message. The value field of this attribute contains the Initialization Vector that is used with the encrypted data following.
AT_ENCR_DATA
AT_ENCR_DATA
This attribute is optional to use in this message. The encrypted
data, if present, may contain an attribute AT_NEXT_TMPID,
containing the NAI the Peer should use in the next EAP
authentication.
This attribute is optional to use in this message. The encrypted data, if present, may contain an attribute AT_NEXT_TMPID, containing the NAI the Peer should use in the next EAP authentication.
AT_MSK_LIFE
AT_MSK_LIFE
This attribute is optional to use in this message. The value
field of this attribute contains the MSK Lifetime in seconds.
This attribute is optional to use in this message. The value field of this attribute contains the MSK Lifetime in seconds.
AT_MIC_S
AT_MIC_S
The value field of this attribute contains the Server MIC_S
parameter. The AT_MIC_S attribute MUST be present in the
EAP.Request/SAKE/Confirm.
The value field of this attribute contains the Server MIC_S parameter. The AT_MIC_S attribute MUST be present in the EAP.Request/SAKE/Confirm.
Vanderveen & Soliman Informational [Page 31] RFC 4763 EAP-SAKE November 2006
Vanderveen & Soliman Informational [Page 31] RFC 4763 EAP-SAKE November 2006
3.3.7. EAP.Response/SAKE/Confirm Format
3.3.7. EAP.Response/SAKE/Confirm Format
The format of the EAP.Response/SAKE/Confirm packet is shown below.
The format of the EAP.Response/SAKE/Confirm packet is shown below.
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=EAP-SAKE | Version=2 | Session ID | Subtype=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_MIC_P | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MIC_P |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_PADDING | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=EAP-SAKE | Version=2 | Session ID | Subtype=2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_MIC_P | Length = 18 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | MIC_P | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | AT_PADDING | Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
The semantics of the fields is described below:
Code
Code
2 for Response
2 for Response
Identifier
Identifier
A number that MUST match the Identifier field from the
corresponding Request.
A number that MUST match the Identifier field from the corresponding Request.
Length
Length
The length of the entire EAP packet in octets.
The length of the entire EAP packet in octets.
Type
Type
EAP-SAKE
EAP-SAKE
Version
Version
2
2
Session ID
Session ID
A number matching all other EAP messages in this EAP session.
A number matching all other EAP messages in this EAP session.
Vanderveen & Soliman Informational [Page 32] RFC 4763 EAP-SAKE November 2006
Vanderveen & Soliman Informational [Page 32] RFC 4763 EAP-SAKE November 2006
Subtype
Subtype
2 for SAKE Confirm
2 for SAKE Confirm
AT_MIC_P
AT_MIC_P
The value field of this attribute contains the Peer's MIC_P
parameter. The AT_MIC_P attribute MUST be present in the
EAP.Response/SAKE/Confirm.
The value field of this attribute contains the Peer's MIC_P parameter. The AT_MIC_P attribute MUST be present in the EAP.Response/SAKE/Confirm.
AT_PADDING
AT_PADDING
The value field is set to zero. Added to achieve 32-bit alignment
of the EAP-SAKE packet.
The value field is set to zero. Added to achieve 32-bit alignment of the EAP-SAKE packet.
3.3.8. EAP.Response/SAKE/Auth-Reject Format
3.3.8. EAP.Response/SAKE/Auth-Reject Format
The format of the EAP.Response/SAKE/Auth-Reject packet is shown below.
The format of the EAP.Response/SAKE/Auth-Reject packet is shown below.
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=EAP-SAKE | Version=2 | Session ID | Subtype=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=EAP-SAKE | Version=2 | Session ID | Subtype=3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
The semantics of the fields is described below:
Code
Code
2 for Response
2 for Response
Identifier
Identifier
A number that MUST match the Identifier field from the
corresponding Request.
A number that MUST match the Identifier field from the corresponding Request.
Length
Length
The length of the entire EAP packet in octets.
The length of the entire EAP packet in octets.
Type
Type
EAP-SAKE
EAP-SAKE
Vanderveen & Soliman Informational [Page 33] RFC 4763 EAP-SAKE November 2006
Vanderveen & Soliman Informational [Page 33] RFC 4763 EAP-SAKE November 2006
Version
Version
2
2
Session ID
Session ID
A number matching all other EAP messages in this EAP session.
A number matching all other EAP messages in this EAP session.
Subtype
Subtype
3 for SAKE/Auth-Reject
3 for SAKE/Auth-Reject
3.3.9. EAP.Request/SAKE/Identity Format
3.3.9. EAP.Request/SAKE/Identity Format
The format of the EAP.Request/SAKE/Identity is shown below.
The format of the EAP.Request/SAKE/Identity is shown below.
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=EAP-SAKE | Version=2 | Session ID | Subtype=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_PERM_ID_REQ | Length = 4 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_ANY_ID_REQ | Length = 4 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_SERVERID | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| Server 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type=EAP-SAKE | Version=2 | Session ID | Subtype=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT_PERM_ID_REQ | Length = 4 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT_ANY_ID_REQ | Length = 4 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |AT_SERVERID | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | Server ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
The semantics of the fields is described below:
Code
Code
1 for Request
1 for Request
Identifier
Identifier
A random number. See [EAP].
A random number. See [EAP].
Length
Length
The length of the entire EAP packet in octets.
The length of the entire EAP packet in octets.
Vanderveen & Soliman Informational [Page 34] RFC 4763 EAP-SAKE November 2006
Vanderveen & Soliman Informational [Page 34] RFC 4763 EAP-SAKE November 2006
Type
Type
EAP-SAKE
EAP-SAKE
Version
Version
2
2
Session ID
Session ID
A number matching all other EAP messages in this EAP session.
A number matching all other EAP messages in this EAP session.
Subtype
Subtype
4 for SAKE/Identity
4 for SAKE/Identity
AT_PERM_ID_REQ
AT_PERM_ID_REQ
The AT_PERM_ID_REQ attribute is optional, to be included in cases
where the Server requires the Peer to give its permanent
identifier (i.e., PermID). The AT_PERM_ID_REQ MUST NOT be
included if the AT_ANY_ID_REQ attribute is included. The value
field only contains two reserved bytes, which are set to zero on
sending and ignored on reception.
The AT_PERM_ID_REQ attribute is optional, to be included in cases where the Server requires the Peer to give its permanent identifier (i.e., PermID). The AT_PERM_ID_REQ MUST NOT be included if the AT_ANY_ID_REQ attribute is included. The value field only contains two reserved bytes, which are set to zero on sending and ignored on reception.
AT_ANY_ID_REQ
AT_ANY_ID_REQ
The AT_ANY_ID_REQ attribute is optional, to be included in cases
where the Server requires the Peer to send any identifier (e.g.,
PermID, TempID). The AT_ANY_ID_REQ MUST NOT be included if
AT_PERM_ID_REQ is included. The value field only contains two
reserved bytes, which are set to zero on sending and ignored on
reception. One of the AT_PERM_ID_REQ and AT_ANY_ID_REQ MUST be
included.
The AT_ANY_ID_REQ attribute is optional, to be included in cases where the Server requires the Peer to send any identifier (e.g., PermID, TempID). The AT_ANY_ID_REQ MUST NOT be included if AT_PERM_ID_REQ is included. The value field only contains two reserved bytes, which are set to zero on sending and ignored on reception. One of the AT_PERM_ID_REQ and AT_ANY_ID_REQ MUST be included.
AT_SERVERID
AT_SERVERID
The value field of this attribute contains the identifier/realm of
the Server. The AT_SERVERID attribute is optional but RECOMMENDED
to include in the EAP.Request/SAKE/Identity.
The value field of this attribute contains the identifier/realm of the Server. The AT_SERVERID attribute is optional but RECOMMENDED to include in the EAP.Request/SAKE/Identity.
Vanderveen & Soliman Informational [Page 35] RFC 4763 EAP-SAKE November 2006
Vanderveen & Soliman Informational [Page 35] RFC 4763 EAP-SAKE November 2006
3.3.10. EAP.Response/SAKE/Identity Format
3.3.10. EAP.Response/SAKE/Identity Format
The format of the EAP.Response/SAKE/Identity is shown below:
The format of the EAP.Response/SAKE/Identity is shown below:
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=EAP-SAKE | Version=2 | Session ID | Subtype=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_PEERID | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| Peer NAI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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=EAP-SAKE | Version=2 | Session ID | Subtype=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_PEERID | Length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | Peer NAI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
The semantics of the fields is described below:
Code
Code
2 for Response
2 for Response
Identifier
Identifier
A number that MUST match the Identifier field from the
corresponding Request.
A number that MUST match the Identifier field from the corresponding Request.
Length
Length
The length of the entire EAP packet.
The length of the entire EAP packet.
Type
Type
EAP-SAKE
EAP-SAKE
Version
Version
2
2
Session ID
Session ID
A number matching all other EAP messages in this EAP session.
A number matching all other EAP messages in this EAP session.
Subtype
Subtype
4 for SAKE/Identity
4 for SAKE/Identity
Vanderveen & Soliman Informational [Page 36] RFC 4763 EAP-SAKE November 2006
[36ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
AT_PEERID
_PEERIDで
The value field of this attribute contains the NAI of the Peer.
The AT_PEERID attribute MUST be present in
EAP.Response/SAKE/Identity.
この属性の値の分野はPeerのNAIを含んでいます。 AT_PEERID属性はEAP.Response/SAKE/アイデンティティで存在していなければなりません。
3.3.11. Other EAP Messages Formats
3.3.11. 他のEAPメッセージ形式
The format of the EAP.Request/Identity and EAP.Response/Identity packets is described in [EAP]. The user ID (e.g., NAI) SHOULD be present in this packet.
EAP.Request/アイデンティティとEAP.Response/アイデンティティパケットの形式は[EAP]で説明されます。 ユーザID(例えば、NAI)SHOULD、このパケットに存在してください。
The format of the EAP-Success and EAP-Failure packet is also shown in [EAP].
また、EAP-成功とEAP-失敗パケットの書式は[EAP]に示されます。
4. IANA Considerations
4. IANA問題
IANA allocated a new EAP Type for EAP-SAKE.
IANAはEAP-SAKEのために新しいEAP Typeを割り当てました。
EAP-SAKE messages include an 8-bit Subtype field. The Subtype is a new numbering space for which IANA administration is required. The following subtypes are specified in this memo:
EAP-SAKEメッセージは8ビットのSubtype分野を含んでいます。 SubtypeはIANA管理が必要である新しい付番スペースです。 以下の血液型亜型はこのメモで指定されます:
SAKE/Challenge.................1 SAKE/Confirm...................2 SAKE/Auth-Reject...............3 SAKE/Identity..................4
酒/挑戦…/が確認する1個の日本酒…2Auth酒/廃棄物…3の酒/アイデンティティ…4
The Subtype-specific data is composed of attributes, which have an 8-bit type number. 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- SAKE attribute type number is a new numbering space for which IANA administration is required. The following attribute types are specified:
Subtype特有のデータは属性で構成されます。(属性に、8ビットのタイプ番号があります)。 範囲の中で0〜127に付番された属性は非skippable属性と呼ばれます、そして、128〜255の範囲の中の属性はskippable属性と呼ばれます。 EAP- SAKE属性形式数はIANA管理が必要である新しい付番スペースです。 以下の属性タイプは指定されます:
AT_RAND_S.......................................1 AT_RAND_P.......................................2 AT_MIC_S........................................3 AT_MIC_P........................................4 AT_SERVERID.....................................5 AT_PEERID.......................................6 AT_SPI_S........................................7 AT_SPI_P........................................8 AT_ANY_ID_REQ...................................9 AT_PERM_ID_REQ.................................10
_底ならし革_S.で…大西洋標準時1_底ならし革_P.…大西洋標準時2_ミック_S.…大西洋標準時3_ミック_P.…_大西洋標準時4SERVERID…_大西洋標準時5PEERID…大西洋標準時6_SPI_S.…大西洋標準時7_SPI_P.…__どんな8 AT_ID REQも…大西洋標準時9_は_ID_REQにパーマをかけます…10
Vanderveen & Soliman Informational [Page 37] RFC 4763 EAP-SAKE November 2006
[37ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
AT_ENCR_DATA..................................128 AT_IV.........................................129 AT_PADDING....................................130 AT_NEXT_TMPID.................................131 AT_MSK_LIFE...................................132
_ENCR_データで…大西洋標準時128_IV…大西洋標準時129_詰め物…_次の大西洋標準時130_TMPID…大西洋標準時131_MSK_の寿命…132
All requests for value assignment from the two number spaces described in this memo require proper documentation, according to the "Specification Required" policy described in [IANA].
このメモで説明された2つの数の空間からの値の課題を求めるすべての要求が適切なドキュメンテーションを必要とします、「仕様が必要である」という[IANA]で説明された方針によると。
All assignments of values from the two number spaces described in this memo require IETF consensus.
このメモで説明された2つの数の空間からの値のすべての課題がIETFコンセンサスを必要とします。
5. Security Considerations
5. セキュリティ問題
The EAP specification [EAP] describes the security vulnerabilities of EAP, which does not include its method-specific security mechanisms. This section discusses the claimed security properties of the EAP- SAKE method, along with vulnerabilities and security recommendations.
このセクションはEAP- SAKEメソッドの要求されたセキュリティの特性について論じます、脆弱性とセキュリティ推薦と共に。EAP仕様[EAP]はEAPのセキュリティの脆弱性について説明します。(EAPはメソッド特有のセキュリティー対策を含んでいません)。
5.1. Denial-of-Service Attacks
5.1. サービス不能攻撃
Since EAP-SAKE is not a tunneling method, the EAP.Response/SAKE/Auth-Reject, EAP.Success, and EAP.Failure packets are not integrity or replay protected. This makes it possible for an attacker to spoof such messages. Note that EAP.Response/SAKE/Auth- Reject cannot be protected with a MIC since an authentication failure indicates that the Server and Peer do not agree on a common key.
EAP-SAKEがトンネリングメソッドでないことで、Auth EAP.Response/SAKE/廃棄物、EAP.Success、およびEAP.Failureパケットは保全ではありません再生が保護されました。 これで、攻撃者がそのようなメッセージを偽造するのが可能になります。 認証失敗が、ServerとPeerが一般的なキーに同意しないのを示すので、MICと共にEAP.Response/SAKE/Authが拒絶する注意を保護できません。
Most importantly, an attacker cannot cause a Peer to accept an EAP.Success packet as indication that the Server considers the mutual authentication to have been achieved. This is because a Peer does not accept EAP.Success packets before it has authenticated the Server or after it has considered the Server to have failed authentication.
最も重要に、攻撃者はPeerにServerが、互いの認証が達成されたと考えるという指示としてEAP.Successパケットを認めさせることができません。 これはServerを認証する前にPeerがEAP.Successパケットを受け入れないか、またはそれが、Serverが認証に失敗したと考えた後です。
5.2. Root Secret Considerations
5.2. 秘密の問題を根づかせてください。
If the Root Secret is known to any party other than the Server and Peer, then the mutual authentication and key establishment using EAP-SAKE is compromised.
Root SecretがServerとPeer以外のどんなパーティーにおいても知られているなら、EAP-SAKEを使用する互いの認証と主要な設立は感染されます。
EAP-SAKE does not address how the Root Secret is generated or distributed to the Server and Peer. It is RECOMMENDED that the entropy of the Root Secret be maximized. The Root Secret SHOULD be machine-generated.
EAP-SAKEはRoot SecretがServerとPeerに生成されるか、またはどう分配されるかを扱いません。 Root Secretのエントロピーが最大にされるのは、RECOMMENDEDです。 Root Secret SHOULD、マシンで、発生してください。
Vanderveen & Soliman Informational [Page 38] RFC 4763 EAP-SAKE November 2006
[38ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
If the Root Secret is derived from a low-entropy, guessable quantity such as a human-selected password, then the EAP-SAKE key derivation is subject to on-line and off-line dictionary attacks. To help identify whether such a password has been compromised, implementations SHOULD keep a log of the number of EAP-SAKE messages received with invalid MIC fields. In these cases, a procedure for updating the Root Secret securely SHOULD be in place.
人間によって選択されたパスワードなどの低エントロピーの、そして、推測可能な量からRoot Secretを得るなら、EAP-SAKEの主要な派生はオンラインの、そして、オフラインの辞書攻撃を受けることがあります。 そのようなパスワードが感染されたかどうか特定するのを助けるために、実装SHOULDは、無効のMIC分野でEAP-SAKEメッセージの数に関するログを受け取り続けます。 これらのケース、しっかりとRoot Secretをアップデートするための手順、SHOULD、適所にいてください。
5.3. Mutual Authentication
5.3. 互いの認証
Mutual authentication is accomplished via the SAKE/Challenge and SAKE/Confirm messages. The EAP.Request/SAKE/Challenge contains the Server nonce RAND_S; the EAP.Response/SAKE/Challenge contains the Peer nonce RAND_P, along with the Peer MIC (MIC_P); and the EAP.Request/SAKE/Confirm contains the Server MIC (MIC_S). Both MICs (MIC_S and MIC_P) are computed using both nonces RAND_S and RAND_P and are keyed by the TEK, a shared secret derived from the Root Secret. The Server considers the Peer authenticated if the MIC_P it computes matches the one that the Peer sends. Similarly, the Peer considers the Server authenticated if the MIC_S it computes matches the one that the Server sends. The way the MICs are computed involves a keyed one-way hash function, which makes it computationally hard for an attacker to produce the correct MIC without knowledge of the shared secret.
互いの認証はSAKE/挑戦で実行されます、そして、SAKE/はメッセージを確認します。 EAP.Request/SAKE/挑戦はServer一回だけRAND_Sを含んでいます。 EAP.Response/SAKE/挑戦はPeer MIC(MIC_P)と共にPeer一回だけRAND_Pを含んでいます。 そして、/が確認するEAP.Request/SAKEはServer MIC(MIC_S)を含んでいます。 両方のMICs(MIC_SとMIC_P)は一回だけRAND_SとRAND_Pの両方を使用することで計算されて、TEK(Root Secretから得られた共有秘密キー)によって合わせられます。 Serverはそれが計算するMIC_PがPeerが送るものに合っているなら認証されたPeerを考えます。 同様に、Peerはそれが計算するMIC_SがServerが送るものに合っているなら認証されたServerを考えます。 MICsが計算される方法は合わせられた一方向ハッシュ関数を伴います。(それは、攻撃者が共有秘密キーに関する知識なしで正しいMICを生産するのを計算上困難にします)。
5.4. Integrity Protection
5.4. 保全保護
Integrity protection of EAP-SAKE messages is accomplished through the use of the Message Integrity Checks (MIC), which are present in every message as soon as a common shared secret (TEK) is available, i.e., any message after the EAP.Request/SAKE/Challenge. An adversary cannot modify any of the MIC-protected messages without causing the recipient to encounter a MIC failure. The extent of the integrity protection is commensurate with the security of the KDF used to derive the MIC, the length and entropy of the shared secret used by the KDF, and the length of the MIC.
EAP-SAKEメッセージの保全保護は一般的な共有秘密キー(TEK)が利用可能であるとすぐに、あらゆるメッセージに存在しているMessage Integrity Checks(MIC)の使用で実行されます、EAP.Request/SAKE/挑戦の後のすなわちどんなメッセージ。 受取人がMICの故障に遭遇することを引き起こさない、敵はMICによって保護されたメッセージのいずれも変更できません。 保全保護の範囲はMICを引き出すのに使用されるKDFのセキュリティ、長さ、KDFによって使用された共有秘密キーのエントロピー、およびMICの長さについて等しいです。
5.5. Replay Protection
5.5. 反復操作による保護
The first message of most session establishment protocols, such as EAP-SAKE, is subject to replay. A replayed EAP.Request/SAKE/Challenge message results in the Peer sending an EAP.Response/SAKE/Challenge message back, which contains a MIC that was computed using the attacker's chosen nonce. This poses a minimal risk to the compromise of the TEK-Auth key, and this EAP Session cannot proceed successfully as the Peer will find the Server's MIC invalid.
EAP-SAKEなどのほとんどのセッション設立プロトコルの最初のメッセージは再生を受けることがあります。 再演されたEAP.Request/SAKE/挑戦メッセージはEAP.Response/SAKE/挑戦メッセージを送って戻すPeerをもたらします。(Peerは攻撃者の選ばれた一回だけを使用することで計算されたMICを含みます)。 これはTEK-Authキーの感染に最小量の危険を引き起こします、そして、Peerが、ServerのMICが無効であることがわかるとき、このEAP Sessionは首尾よく続くことができません。
Vanderveen & Soliman Informational [Page 39] RFC 4763 EAP-SAKE November 2006
[39ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
Replay protection is achieved via the RAND_S and RAND_P values, together with the Session ID field, which are included in the calculation of the MIC present in each packet subsequent to the EAP- SAKE/Challenge request packet. The Session ID MUST be generated anew by the Server for each EAP session. Session Ids also aid in identification of possible multiple EAP sessions between a Peer and a Server. Within the same session, messages can be replayed by an attacker, but the state machine SHOULD be able to handle these cases. Note that a replay within a session is indistinguishable to a recipient from a network malfunction (e.g., message was first lost and then re-transmitted, so the recipient thinks it is a duplicate message).
反復操作による保護はSession ID分野に伴うRAND_SとRAND_P値で達成されます。(値はEAP- SAKE/挑戦リクエスト・パケットへのその後のそれぞれのパケットの現在のMICの計算に含まれています)。 ServerはそれぞれのEAPセッションのために新たにSession IDを生成しなければなりません。 また、セッションIdsはPeerとServerの間で複数のEAPセッションに可能の識別で支援します。同じセッション、攻撃者が再演できますが、州がSHOULDを機械加工するというメッセージの中では、これらのケースを扱うことができてください。 ネットワーク不調からの受取人にとって、セッション以内の再生が区別がつかないことに注意してください(例えばメッセージが最初に、失われて、次に、再送されたので、受取人は、それが写しメッセージであると考えます)。
Replay protection between EAP sessions and within an EAP session is also accomplished via the MIC, which covers not only the entire EAP packet (including the Session ID) but also the nonces RAND_S and RAND_P. Thus, the recipient of an EAP message can be assured that the message it just received is the one just sent by the other Peer and not a replay, since it contains a valid MIC of the recipient's nonce and the other Peer nonce. As before, the extent of replay protection is commensurate with the security of the KDF used to derive the MIC, the length and entropy of the shared secret used by the KDF, and the length of the MIC.
また、EAPセッションとEAPセッション以内の反復操作による保護はMICを通して実行されます。MICは全体のEAPパケット(Session IDを含んでいる)だけではなく、一回だけのRAND_SとRAND_Pもカバーします。 したがって、EAPメッセージの受取人はそれがただ受け取ったメッセージが再生ではなく、もう片方のPeerによってただ送られたものであると確信できます、受取人の一回だけと他のPeer一回だけの有効なMICを含んでいるので。 従来と同様、反復操作による保護の範囲はMICを引き出すのに使用されるKDFのセキュリティ、長さ、KDFによって使用された共有秘密キーのエントロピー、およびMICの長さについて等しいです。
5.6. Confidentiality
5.6. 秘密性
Confidentiality of EAP-SAKE attributes is supported through the use of the AT_ENCR_DATA and AT_IV attributes. A ciphersuite is negotiated securely (see Section 3.2.7) and can be used to encrypt any attributes as needed. The default ciphersuite contains a strong cipher based on AES.
EAP-SAKE属性の秘密性はAT_ENCR_DATAとAT_IV属性の使用でサポートされます。 しっかりとciphersuiteを交渉します、そして、(セクション3.2.7を見てください)必要に応じてどんな属性も暗号化するのに使用できます。 デフォルトciphersuiteはAESに基づく強い暗号を含んでいます。
5.7. Key Derivation, Strength
5.7. 主要な派生、強さ
EAP-SAKE derives a Master Key (for EAP use) and Master Session Key, as well as other lower-level keys, such as TEKs. Some of the lower- level keys may or may not be used. The strength (entropy) of all these keys is at most the strength of the Root Secret.
EAP-SAKEはMaster Key(EAP使用のための)とMaster Session Keyを引き出します、他の低レベルキーと同様に、TEKsなどのように。 いくつかの下側の平らなキーが使用されるかもしれません。 これらのすべてのキーの強さ(エントロピー)は高々Root Secretの強さです。
The entropy of the MSK and of the EMSK, assuming that the Server and Peer 128-bit nonces are generated using good random number generators, is at most 256-bits.
良い乱数発生器を使用するのがServerとPeerの128ビットの一回だけに生成されると仮定して、高々MSKとEMSKのエントロピーは256ビットです。
Vanderveen & Soliman Informational [Page 40] RFC 4763 EAP-SAKE November 2006
[40ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
5.8. Dictionary Attacks
5.8. 辞書攻撃
Dictionary attacks are not feasible to mount on the EAP-SAKE method because passwords are not used. Instead, the Root Secret is machine-generated. This does not necessarily pose provisioning problems.
辞書攻撃はパスワードが使用されていないのでEAP-SAKEメソッドを上がるのにおいて可能ではありません。 代わりに、Root Secretはマシンで発生しています。 これは、必ず問題に食糧を供給しながら、ポーズをとるというわけではありません。
5.9. Man-in-the-Middle Attacks
5.9. 介入者攻撃
Resistance to man-in-the-middle attacks is provided through the integrity protection that each EAP message carries (i.e., Message Integrity Check field) as soon as a common key for this EAP session has been derived through mutual authentication. As before, the extent of this resistance is commensurate with the strength of the MIC itself. Man-in-the-middle attacks associated with the use of any EAP method within a tunneling or sequencing protocol are beyond the scope of this document.
このEAPセッションのための一般的なキーが互いの認証で引き出されるとすぐに、それぞれのEAPメッセージが運ぶ保全保護(すなわち、Message Integrity Check分野)で介入者攻撃への抵抗を提供します。 従来と同様、この抵抗の範囲はMIC自身の強さについて等しいです。 トンネリングか配列プロトコルの中でどんなEAPメソッドの使用にも関連している介入者攻撃はこのドキュメントの範囲を超えています。
5.10. Result Indication Protection
5.10. 結果指示保護
EAP-SAKE provides result indication protection in that it provides result indications, integrity protection, and replay protection. The Server indicates that it has successfully authenticated the Peer by sending the EAP.Request/SAKE/Confirm message, which is integrity and replay protected. The Peer indicates that it has successfully authenticated the Server by sending the EAP.Response/SAKE/Confirm message, which is also integrity and replay protected.
結果指摘、保全保護、および反復操作による保護を提供するので、EAP-SAKEは結果指示保護を提供します。 Serverは、首尾よく、発信するのによるEAP.Request/SAKE/が、メッセージ、どれが保全であるか、そして、および再生が保護したと確認するPeerを認証したのを示します。 Peerは、首尾よく、発信するのによるEAP.Response/SAKE/が、メッセージ、また、どれが保全であるか、そして、および再生が保護したと確認するServerを認証したのを示します。
5.11. Cryptographic Separation of Keys
5.11. キーの暗号の分離
The TEKs used to protect EAP-SAKE packets (TEK-Auth, TEK-Cipher), the Master Session Key, and the Extended Master Session Key are cryptographically separate. Information about any of these keys does not lead to information about any other keys. We also note that it is infeasible to calculate the Root Secret from any or all of the TEKs, the MSK, or the EMSK.
TEKsは以前は、よくEAP-SAKEパケット(TEK-Auth、TEK-暗号)を保護していました、Master Session Key、Extended Master Session Keyは暗号でMaster Session Keyです。別々。 これらのキーのどれかに関する情報はいかなる他のキーの情報にもつながりません。 また、私たちは、TEKs、MSK、またはEMSKのいずれかすべてからRoot Secretについて計算するのが実行不可能であることに注意します。
5.12. Session Independence
5.12. セッション独立
Within each EAP-SAKE session, fresh keying material is generated. The keying material exported by this method from two independent EAP-SAKE sessions is cryptographically separate, as explained below.
それぞれのEAP-SAKEセッション以内に、生々しく、材料を合わせるのは発生しています。 2つの独立しているEAP-SAKEセッションからこのメソッドでエクスポートされた合わせることの材料は以下で説明されるように暗号で分離することです。
Both the Server and the Peer SHOULD generate fresh random numbers (i.e., nonces) for the EAP-SAKE exchange. If either entity re-uses a random number from a previous session, then the fact that the other does use a freshly generated random number implies that the TEKs, MSK, and EMSK derived within this session are cryptographically
ServerとPeer SHOULDの両方が、EAP-SAKE交換のために新鮮な乱数が(すなわち、一回だけ)であると生成します。 どちらの実体も前のセッションから乱数を再使用するなら、もう片方が新たに生成している乱数を使用するという事実は、このセッション中に引き出されたTEKs、MSK、およびEMSKが暗号でそうであることを含意します。
Vanderveen & Soliman Informational [Page 41] RFC 4763 EAP-SAKE November 2006
[41ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
separate from the corresponding keys derived in the previous exchange.
前の交換で引き出された対応するキーから、分離してください。
Therefore, compromise of MSK or EMSK on one exchange does not compromise the MSK and EMSK of previous or subsequent exchanges between a Peer and a Server.
したがって、1回の交換でのMSKかEMSKの感染はPeerとServerの間の前の、または、その後の交換のMSKとEMSKに感染しません。
5.13. Identity Protection
5.13. アイデンティティ保護
As seen from Section 3.2.3., the Server may assign a temporary NAI to a Peer in order to achieve user anonymity. This identifier may be used by the Peer the next time it engages in an EAP-SAKE authentication phase with the Server. The TempID is protected by sending it encrypted, within an AT_ENCR_DATA attribute, and signed by the Server with a MIC. Thus, an eavesdropper cannot link the original PermID that the Peer first sends (e.g., on power-up) to any subsequent TempID values sent in the clear to the Server.
セクション3.2から.3に見られるように、Serverはユーザ匿名を達成するために一時的なNAIをPeerに割り当てるかもしれません。 この識別子はそれがServerとのEAP-SAKE認証フェーズに従事している次の時にPeerによって使用されるかもしれません。TempIDはそれを送ることによってAT_ENCR_DATA属性の中で暗号化されていた状態で保護されて、MICと共にServerによって署名されます。 したがって、立ち聞きする者はPeerが最初にServerへの明確で送られたどんなその後のTempID値にも送る(例えば、パワーアップするのに関して)オリジナルのPermIDをリンクできません。
The Server and Peer MAY be configured such that only TempID identities are exchanged after one initial EAP-SAKE phase that uses the Peer permanent identity. In this case, in order to achieve maximum identity protection, the TempID SHOULD be stored in non- volatile memory in the Peer and Server. Thus, compliance with this document does not preclude or mandate Peer identity protection across the lifetime of the Peer.
ServerとPeerが構成されるかもしれないので、Peerの永久的なアイデンティティを使用する1つの初期のEAP-SAKEフェーズの後にTempIDのアイデンティティだけを交換します。 この場合、最大のアイデンティティ保護を達成するために、TempID SHOULDはServer Peerの非揮発性メモリーとその結果、このドキュメントへの承諾が排除しない保存されたコネであるかPeerの生涯の向こう側にPeerアイデンティティ保護を強制します。
5.14. Channel Binding
5.14. チャンネル結合
The Server identifier and Peer identifier MAY be sent in the SAKE/Challenge messages. However, since there is no established authentication key at the time of the first message, the Server identifier is not integrity-protected here.
SAKE/挑戦メッセージでServer識別子とPeer識別子を送るかもしれません。 しかしながら、最初のメッセージ時点で主要な認証が確立されないので、Server識別子はここに保全によって保護されていません。
All subsequent EAP-SAKE messages exchanged during a successful EAP- SAKE phase are integrity-protected, as they contain a Message Integrity Check (MIC). The MIC is computed over the EAP message and also over the Server and Peer identities. In that, both EAP endpoints can verify the identity of the other party.
うまくいっているEAP- SAKE段階の間に交換されたすべてのその後のEAP-SAKEメッセージが保全によって保護されています、Message Integrity Check(MIC)を含むとき。 MICはEAPメッセージの上と、そして、ServerとPeerのアイデンティティの上に関しても計算されます。 それでは、両方のEAP終点が相手のアイデンティティについて確かめることができます。
5.15. Ciphersuite Negotiation
5.15. Ciphersuite交渉
EAP-SAKE does not support negotiation of the ciphersuite used to integrity-protect the EAP conversation. However, negotiation of a ciphersuite for data protection is supported. This ciphersuite negotiation is protected in order to minimize the risk of down- negotiation or man-in-the-middle attacks.
EAP-SAKEはEAPの会話を保全して保護するのに使用されるciphersuiteの交渉をサポートしません。 しかしながら、データ保護のためのciphersuiteの交渉はサポートされます。 このciphersuite交渉は、下に交渉か介入者攻撃の危険を最小にするために保護されます。
Vanderveen & Soliman Informational [Page 42] RFC 4763 EAP-SAKE November 2006
[42ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
This negotiation is secure because of the Message Integrity Checks (MICs) that cover the entire EAP messages used for ciphersuite negotiation (see Section 3.2.7.). The extent of the security of the negotiation is commensurate with the security of the KDF used to derive the MICs, the length and entropy of the shared secret used by the KDF, and the length of the MICs.
この交渉はciphersuite交渉に使用される全体のEAPメッセージをカバーするMessage Integrity Checks(MICs)のために安全です(.7にセクション3.2を見てください)。 交渉のセキュリティの範囲はMICsを引き出すのに使用されるKDFのセキュリティ、長さ、KDFによって使用された共有秘密キーのエントロピー、およびMICsの長さについて等しいです。
5.16. Random Number Generation
5.16. 乱数発生
EAP-SAKE supports key derivation from a 32-byte Root Secret. The entropy of all other keys derived from it is reduced somewhat through the use of keyed hash functions (e.g. KDF). Thus, assuming optimistically that the effective key strength of the Root Secret is 32 bytes, the effective key strengths of the derived keys is at most the effective key strength of the Root Secret quantities they are derived from: EMSK, at most 16 bytes; MSK, at most 16 bytes.
EAP-SAKEは32バイトのRoot Secretから主要な派生をサポートします。 それから得られた他のすべてのキーのエントロピーはいくらか合わせられたハッシュ関数(例えば、KDF)の使用で減少します。 派生しているキーの有効な主要な強さは高々それらが得られるRoot Secret量の有効な強さであってしたがって、Root Secretの有効な主要な強さが32バイトであると楽観的に仮定する主要な: EMSK、高々16バイト。 ほとんどの16バイトにおけるMSK。
6. Security Claims
6. セキュリティクレーム
This section provides the security claims as required by [EAP].
このセクションは必要に応じて[EAP]でセキュリティクレームを提供します。
[a] Mechanism: EAP-SAKE is a challenge/response authentication and
key establishment mechanism based on a symmetric pre-shared
secret.
[a]メカニズム: EAP-SAKEは左右対称のプレ共有秘密キーに基づく挑戦/応答認証と主要な設立メカニズムです。
[b] Security claims. EAP-SAKE provides:
[b]セキュリティクレームEAP-SAKEは提供します:
Mutual authentication (Section 5.3)
互いの認証(セクション5.3)
Integrity protection (Section 5.4)
保全保護(セクション5.4)
Replay protection (Section 5.5)
反復操作による保護(セクション5.5)
Confidentiality (optional, Section 5.6 and Section 5.13)
秘密性(任意であることで、5.6とセクション5.13を区分してください)
Key derivation (Section 5.7)
主要な派生(セクション5.7)
Dictionary attack protection (Section 5.8)
辞書攻撃保護(セクション5.8)
Protected result indication of successful authentication from
Server and from Peer (Section 5.10)
ServerとPeerからのうまくいっている認証の保護された結果しるし(セクション5.10)
Session independence (Section 5.12)
セッション独立(セクション5.12)
[c] Key strength. EAP-SAKE supports key derivation with 256-bit
effective key strength (Section 5.7)
[c] 主要な強さ。 EAP-SAKEは256ビットの有効な主要な強さで主要な派生をサポートします。(セクション5.7)
[d] Description of key hierarchy: see Section 3.2.5.
[d] 主要な階層構造の記述: セクション3.2.5を見てください。
Vanderveen & Soliman Informational [Page 43] RFC 4763 EAP-SAKE November 2006
[43ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
[e] Indication of vulnerabilities: EAP-Make does not provide:
[e] 脆弱性のしるし: EAP-造は提供されません:
Fast reconnect
速く再接続してください。
Fragmentation
断片化
Channel binding
チャンネル結合
Cryptographic binding
暗号の結合
7. Acknowledgements
7. 承認
Thanks to R. Dynarski for his helpful comments.
彼の役に立つコメントをR.Dynarskiをありがとうございます。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[AES] National Institute of Standards and Technology,
"Federal Information Processing Standards (FIPS)
Publication 197, Advanced Encryption Standard (AES)",
November 2001. http://csrc.nist.gov/publications/
fips/fips197/fips-197.pdf
[AES]米国商務省標準技術局、「連邦政府の情報処理規格(FIPS)公表197、エー・イー・エス(AES)」11月2001日の http://csrc.nist.gov/publications/ fips/fips197/fips-197.pdf
[CBC] National Institute of Standards and Technology, NIST
Special Publication 800-38A, "Recommendation for Block
Cipher Modes of Operation - Methods and Techniques",
December 2001. http://csrc.nist.gov/publications/
drafts/Draft-NIST_SP800-38D_Public_Comment.pdf
[CBC]米国商務省標準技術局、NISTの特別な公表800-38A、「ブロックのための推薦は運転モードを解きます--メソッドとテクニック」、NIST_SP800-38D_公衆_Comment.pdfを12月2001日 http://csrc.nist.gov/publications/ 草稿/作成します。
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
H. Levkowetz, "Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[EAP]Aboba、B.、Blunk、L.、Vollbrecht、J.、カールソン、J.とH.Levkowetz、「拡張認証プロトコル(EAP)」RFC3748、2004年6月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[HMAC] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[IANA]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[IEEE802.11i] "IEEE Standard for Information Technology-
Telecommunications and Information Exchange between
Systems - LAN/MAN Specific Requirements - Part 11:
Wireless Medium Access Control (MAC) and physical
layer (PHY) specifications: Amendment 6: Medium Access
Control (MAC) Security Enhancements", June 2004.
[IEEE802.11i] 「情報技術テレコミュニケーションのIEEE規格とシステム(LAN/男性決められた一定の要求)の間の情報交換は11を分けます」。 ワイヤレスのMedium Access Control(MAC)と物理的な層(PHY)の仕様: 修正6: 2004年6月の「媒体アクセス制御(MAC)セキュリティ増進。」
Vanderveen & Soliman Informational [Page 44] RFC 4763 EAP-SAKE November 2006
[44ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[SHA1] National Institute of Standards and Technology, U.S.
Department of Commerce, Federal Information Processing
Standard (FIPS) Publication 180-1, "Secure Hash
Standard", April 1995.
[SHA1]米国商務省標準技術局、米国商務省、連邦情報処理基準(FIPS)公表180-1は「ハッシュ規格を保証します」、1995年4月。
8.2. Informative References
8.2. 有益な参照
[NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
2005年12月の[NAI]AbobaとB.と用務員とM.とArkko、J.とP.Eronen、「ネットワークアクセス識別子」RFC4282。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
[RFC4086]イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
Authors' Addresses
作者のアドレス
Michaela Vanderveen Qualcomm Flarion Technologies 135 Rte. 202/206 South Bedminster, NJ 07921 USA
ミカエラバンダビーンクアルコムFlarion Technologies135Rte。 202/206の南Bedminster、ニュージャージー07921米国
EMail: mvandervn@yahoo.com
メール: mvandervn@yahoo.com
Hesham Soliman Qualcomm Flarion Technologies 135 Rte. 202/206 South Bedminster, NJ 07921 USA
HeshamソリマンクアルコムFlarion Technologies135Rte。 202/206の南Bedminster、ニュージャージー07921米国
EMail: solimanhs@gmail.com
メール: solimanhs@gmail.com
Vanderveen & Soliman Informational [Page 45] RFC 4763 EAP-SAKE November 2006
[45ページ]RFC4763EAP-酒の2006年11月の情報のバンダビーンとソリマン
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2006).
IETFが信じる著作権(C)(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78とwww.rfc-editor.org/copyright.htmlに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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, THE IETF TRUST, 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信頼、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Vanderveen & Soliman Informational [Page 46]
バンダビーンとソリマンInformationalです。[46ページ]
一覧
スポンサーリンク
