Network Working Group M. Vanderveen
Request for Comments: 4763 H. Soliman
Category: Informational Qualcomm Flarion Technologies
November 2006
Extensible Authentication Protocol Method for
Shared-secret Authentication and Key Establishment (EAP-SAKE)
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).
著作権（C）IETFトラスト（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は、いかなる目的のためにと、公開する決定が展開されたプロトコルとセキュリティ、輻輳制御、または不適切な相互作用のようなもののためにIETFレビューに基づいていない特定のノートに、このRFCのフィットネスの知識を負いません。 RFC Editorはその裁量でこの文書を公開することを選択しました。このドキュメントの読者は実現と展開のためにその値を評価する際に警戒する必要があります。詳細については、RFC 3932を参照してください。
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.
この文書では、共有秘密認証と鍵確立（SAKE）のための拡張認証プロトコル（EAP）メカニズムを指定します。このRFCは仕様はこのIANAの戦力外通告専門家のレビューを経過したRFC 3748.あたりのベンダーのEAPメソッドのためのEAPタイプのIANAの割り当てのための文書として公開されています。
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
7. Acknowledgements ...............................................44
8. References .....................................................44
8.1. Normative References ......................................44
8.2. Informative References ....................................45
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]フレームワークを介してIEEE 802ネットワーク内で使用されています。
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は、スマートカード、ケルベロス、公開キー、ワンタイムパスワード、TLS、およびその他を含むいくつかの認証方式をサポートしています。この文書では、EAP-SAKEと呼ばれる認証方式を定義します。 EAP-SAKEは、静的な事前共有秘密データに基づいて、相互認証およびセッション鍵の導出をサポートしています。このRFCは仕様はこのIANAの戦力外通告専門家のレビューを経過したRFC 3748.あたりのベンダーのEAPメソッドのためのEAPタイプのIANAの割り当てのための文書として公開されています。
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"、 "MUST NOT"、 "REQUIRED"、 "MUST"、 "MUST NOT"、この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はありますBCP 14 [KEYWORDS]で説明されるように解釈されます。
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のSAKEマスターシークレット
NAI Network Access Identifier
NAIネットワークアクセス識別子
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-酒認証プロトコルは、ネイティブEAP認証方式です。それは、EAPの外にEAP-SAKEのスタンドアロンバージョンが定義されていない、です。 EAP-酒は、事前共有鍵と、周知の公開暗号アルゴリズムに基づいて、相互認証を可能にするように設計されています。この方法は、サブスクリプションベースの公衆アクセス・ネットワーク、例えば、セルラーネットワークのために理想的です。
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はピアおよびサーバに知られている長期または事前共有秘密を前提としています。この事前共有秘密は、rootの秘密と呼ばれています。ルート秘密は、16バイトの部分ルート秘密-A、および16バイトの部分ルート秘密-Bから成ります。ルート・シークレット・シークレットは、相互にEAPピアとEAPサーバを認証するために、即ち、EAP-SAKE方法にローカルでの使用のために予約されています。ルート・シークレット-Bの秘密は、そのようなマスターセッションキー（MSK）および拡張マスターセッションキー（EMSK）などの他の量を導出するために使用されます。ルート・シークレット-Bとルート・シークレット-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.
バックエンド認証サーバが使用される場合、サーバは、典型的には、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それは十分に確立さベラー-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ユーザー・アイデンティティの匿名性は、必要に応じてサポートすることができます。
o No synchronization (e.g., of counters) needed between server and peer.
Oいいえ同期（例えば、カウンタの）サーバとピアとの間で必要とされません。
o There is no one-time key pre-processing step.
Oなしのワンタイムキーの前処理ステップがありません。
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-酒は、二つのEAP要求/応答の交換からなる4つのメッセージを使用します。図に示さEAP.SuccessとEAP.FailureメッセージはEAP-酒方法の一部ではありません。慣例として、メソッドの属性がXXは、属性値に設定されたパラメータの名前ですAT_XX、命名されています。
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 |<---------------------------------------------------------|
| |
Figure 1. EAP-SAKE Authentication Procedure (with ciphersuite negotiation)
（暗号スイートネゴシエーション付き）図1 EAP-酒認証手順
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 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.
1. EAPサーバは、EAP-SAKE交換の最初のメッセージを送信します。このメッセージは、タイプSAKEとサブタイプのチャレンジのEAP.Requestメッセージです。 EAP.Request /酒/チャレンジメッセージは、属性が含まれます。その値が新たにサーバによって生成されたノンスであるAT_RAND_Sを、サーバ（例えば、ユーザNAI [NAI]の領域として完全修飾ドメイン名）の識別子を運び、AT_SERVERID、。 AT_SERVERID属性はオプションですが、このメッセージに含まれるべきです。 AT_SERVERIDの目的は、このEAPフェーズ中に使用するために適切なセキュリティアソシエーション（すなわち、ルート秘密、PEERID、及びSERVERID）を選択する際にピアを支援することです。
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.ピア型酒及びサブタイプチャレンジのEAP.Responseメッセージを送信することによって応答します。 EAP.Response /酒/チャレンジメッセージは、属性含ま：新たにピアによって生成されたノンスを運ぶAT_RAND_Pを、ピア識別子を運ぶAT_PEERID、。ピアによってサポートされる1つのまたは複数の暗号スイートのリストを運ぶAT_SPI_P、。そして、AT_MIC_Pは、メッセージの整合性チェックを含みます。 AT_SPI_PとAT_PEERID属性はオプションです。 AT_PEERID属性は、マルチホームホストの場合をカバーするために、含まれるべきです。サポートされる暗号スイートは、EAP-SAKEメソッドにローカル値、または「セキュリティパラメータインデックス」で表され、セクション3.2.8.3を参照してください。ピアはまた、TEK-authおよびTEK-暗号キーが含まれ、SAKEマスターシークレット（SMS）と一時的なEAPキー（のTEK）を導出するために、ルート・秘密鍵と一緒に、両方のナンスを使用しています。 MIC_P値がキーTEK-AUTHを使用して、両方のナンスRAND_SとRAND_P、全体のEAPパケットに基づいて計算され、セクション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.
EAP.Response / SAKE /チャレンジメッセージを受信すると3.は、サーバーは、ピアがした全く同じようにSMSとTEKを計算するために、ルート・秘密鍵と一緒に、ナンスのRAND_SとRAND_Pの両方を使用しています。それに続いて、サーバーは、ピアがやったと全く同じ方法で、ピアのMIC_Pを計算します。サーバーは、それがピアから受信したMIC_Pで計算されたMIC_Pを比較します。それらが一致した場合、サーバーは認証されたピアを考慮します。暗号化が必要とされている場合は、ピアがAT_SPI_P属性が含まれていなかった場合、サーバは、ピアの暗号スイートリストSPI_Pから最強の暗号スイート、または適切な暗号スイートを選択します。サーバーは、属性を含む、タイプ酒及びサブタイプ確認のEAP.Requestメッセージを送信する：AT_SPI_S、サーバーによって選択された暗号スイートを搬送します。 AT_ENCR_DATA、暗号化されたデータを含みます。そして、AT_MIC_Sは、メッセージの整合性チェックを運びます。 AT_SPI_SとAT_ENCR_DATAは、機密性および/またはユーザアイデンティティ匿名を希望する場合は、オプションの属性は、含まれています。含まれ得る他のオプションの属性はAT_NEXT_TMPID、およびAT_MSK_LIFEです。前述のように、MIC_S値がキーTEK-AUTHを使用して、両方のナンスRAND_SとRAND_P、全体のEAPパケットを用いて計算されます。
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.ピアがEAP.Request /酒/サーバによって認証成功を示すメッセージを確認して受信した場合、ピアは、サーバが行ったように同じ方法でMIC_Sを計算します。ピアは、それが計算MIC_Sで受信MIC_Sを比較します。それらが一致した場合、ピアは、認証サーバーを考慮し、それは前と同じように計算されたメッセージの整合性チェックを含む属性AT_MIC_Pを持つタイプのSAKEとサブタイプの確認のEAP.Responseメッセージを送信します。
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交換した後、サーバーをピアにEAP.Successメッセージを送信することにより、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-酒メッセージはEAP.Success又はEAP.Failureが送信されるまで、サーバーによって選択された最初のメッセージで送信され、そしてその後のメッセージに複製されたセッションIDを含みます。 EAP-SAKEメッセージを受信すると、ピアとサーバの両方が、それが整形式で、有効なセッション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.
それは一意にピアとサーバ間のセッションを識別するのに役立ちますように、セッションIDは、リプレイ保護の目的のために主に導入されることに注意してください。ほとんどの場合、セッションIDとピア/ Serverペア間の1対1の関係があります。
The parameters used by the EAP-SAKE method are summarized in the table below:
EAP-酒法で使用されるパラメータを以下の表にまとめます：
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)
If the Authenticator receives an EAP.Failure message from the Server, the Authenticator MUST terminate the connection with the Peer immediately.
オーセンティケータは、サーバーからEAP.Failureメッセージを受信した場合、認証はすぐにピアとの接続を終えなければなりません。
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に一致しない場合、ピアは、認証に失敗したと見なします。
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.
サーバは、（例えば、ローカルシステムポリシーによって）許容されると考えられている暗号スイートのいずれかをアドバタイズしないピアの認証を拒否し、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:
次の手順が行われ、図2のように、認証に失敗した場合、サーバーは、ピアにEAP.Failureメッセージを送らなければなりません。
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 |<---------------------------------------------------------|
Figure 2. EAP-SAKE Authentication Procedure, Peer Fails
Authentication
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.
EAP.Response / SAKE /チャレンジメッセージを受信すると3.は、サーバーは、ピアがした全く同じようにSMSとTEKを計算するために、ルート・秘密鍵と一緒に、ナンスのRAND_SとRAND_Pの両方を使用しています。それに続いて、サーバーは、ピアがやったと全く同じ方法で、ピアのMICを計算します。サーバーは、それがピアから受信したMIC_Pで計算されたMIC_Pを比較します。彼らは一致していないので、サーバーは、ピアが認証を失敗したと見なし、バックピアにEAP.Failureメッセージを送信します。
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.
AT_SPI_S属性は、ピアは、サーバが選択した暗号スイートを受け入れない前のメッセージに記載されている、またはピアがAT_SPI_Pが含まれていなかった場合は、まだ属性SPI値の1が含まれていない場合、ピアは静かにこのメッセージを破棄すべきです。また、ピアが戻ってサーバーにSAKE /認証拒否メッセージを送信することができます。このメッセージに応答して、サーバーをピアにEAP.Failureメッセージを送らなければなりません。
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属性が含まれなければなりません。サーバーは、暗号化は、それは通常、ピア（例えば、一時的なID、グループキーなど）を対象とし、いくつかのデータを保護する必要があるサーバーであるとして、使用するかどうかを知っています。ピアはAT_SPI_S属性を受け取るまだAT_ENCR_DATA属性が存在しない場合、ピアは、メッセージを処理し、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値が一致しない場合は、サーバーが認証を失敗したと見なします。この場合、ピアは、認証失敗を示す、サーバにEAP.Response型酒のメッセージおよびサブ認証拒否を送信しなければなりません。次の手順が行われ、図3のようにこの場合、サーバは、ピアにEAP.Failureメッセージを送らなければなりません。
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 |<---------------------------------------------------------|
| |
Figure 3. EAP-SAKE Authentication Procedure, Server Fails
Authentication
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.ピアは、サーバによって認証成功を示すメッセージを確認/ EAP.Request /酒を受け取ります。ピアは、サーバーがしたのと同じ方法でMIC_Sを計算します。ピアは、それが計算MIC_Sで受信MIC_Sを比較します。彼らは一致していないので、ピアは、サーバーが認証を失敗したと見なします。この場合、ピアは、認証失敗を示す、タイプ酒と認証が拒否サブタイプのEAP.Responseメッセージで応答します。
5. Upon receipt of a EAP.Response/SAKE/Auth-Reject message, the Server sends an EAP.Failure message back to the Peer.
EAP.Response /酒/ AUTH-Rejectメッセージを受信すると5は、サーバは、バックピアへEAP.Failureメッセージを送信します。
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）を割り当てることが望ましいことがあります。 TempIDはEAP.Request / SAKE /メッセージを確認してピアに配信されます。 TempIDは、任意のNAI [NAI]の形式に従うとピアとEAP-酒認証タスクに従事するEAPサーバによって生成されます。 EAPサーバは、永久的なアイデンティティスペースと区別することができるTempIDスペースで設定可能であるべきです。例えば、特定の領域（例えば、tmp.example.biz）TempIDsために割り当てることができます。
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は、明示的な寿命を割り当てられません。サーバが永久的な識別子を要求し、または同輩が永久的な識別子に送信することによって、新しいEAPセッションの開始をトリガするまでTempIDが有効です。ピアは、その永続的識別子を使用して、いつでもEAPセッションをトリガすることができなければなりません。成功したEAPセッション中に割り当てられた新しいTempIDはピアとサーバ間の将来の取引のための既存の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の配信はサーバが認証ピアを考慮することを意味するものではないことに注意してください。サーバーは、まだメッセージを確認/ EAP.Response / SAKEでMICをチェックする必要があります。場合EAPのフェーズがEAP.Failureメッセージで終了し、その後、サーバおよびピアは、ちょうど無効として配信されたTempIDを考慮する必要があります。したがって、ピアは、これは、それがサーバーで認証しようとすると、次の時間をTempID使用してはなりません。
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.
ピアが有することができる識別情報の種類は、それぞれPermIDとTempIDと呼ば、永久及び一時的なアイデンティティです。 PermIDは、rootの秘密に関連付けられているNAIこと、および長寿命であることができます。 TempIDはEAPメソッドを通ってピアがサーバとのその後のEAPセッション中に自分自身を識別するために使用できること生成された識別子です。 TempIDの目的は、利用者の匿名性のサポートを可能にすることです。 TempIDsの使用はEAP-酒方法において任意です。
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:
このケースは、例えば、サーバは、それが持っていないピアのEAP-酒セッションを開始したい場合などに起こることがあり、図4に示すように、サーバは、EAP.Request /酒/ Identityメッセージを介してピアIDを要求することができます以下のための加入者識別子。次の手順が実行されます。
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. |
+--------------------------------------------------------------+
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.サーバーは、任意のピア識別子の要求を示す、属性_どんなAT__ID REQと、タイプ酒及びサブタイプのアイデンティティのEAP.Requestメッセージを送信します。
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.ピアは、どのピア識別子（PermID又はTempID）を含有AT_PEER_ID属性と、タイプ酒及びサブタイプのアイデンティティのEAP.Responseメッセージを構築します。
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.
それはピア識別子の形式を認識しない場合はサーバがEAP.Response / SAKE / Identityメッセージで報告されたピアのアイデンティティを見つけ、またはことができない場合、サーバーは、ピアにEAP.Failureメッセージを送信することができます。
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でピアを検索することができない場合は、ポリシーがピアは現在、永久的なIDを使用する必要があることを指示した場合、次の手順が発生し、図5のように、または、[サーバーは具体的には、永久的な識別子を求めることができます。
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. |
+---------------------------------------------------------------+
Figure 5. Server Is Given a TempID as Peer Identity; Server
Requires a 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.ピア（又はピアに代わって認証）が型アイデンティティの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.サーバーではなくPermIDが必要ですので、属性AT_PERM_ID_REQとAT_SERVERIDで型SAKEとサブタイプのアイデンティティの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.ピアは、ピアPermIDを運ぶ属性AT_PEERIDを含むタイプ酒及びサブタイプのアイデンティティのEAP.Responseメッセージを送信します。
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の秘密と呼ばれる事前共有秘密が含まれています。これは、ルート秘密部分（16バイト）とルート秘密-B部（16バイト）に分割さ32バイト高エントロピーの文字列です。
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マスターシークレット（SMS）と呼ばれる鍵導出キーが含まれています。 SMS-Aは、ルート・秘密鍵およびEAP-SAKEキー導出関数（KDF）を使用してピアおよびサーバナンス、同様にSMS-Bのために由来しています。 SMSは、唯一のピアおよびサーバに知られており、他の当事者に知らされていません。
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は、このような過渡EAPキー（TEK）、マスターセッションキー（MSK）、および拡張MSK（EMSK）としてセッションキーが含まれています。 TEKは、唯一のEAPメソッドへのローカル使用のためのキーです。これらは、SMS-AおよびEAP-酒のKDFを用いてナンスから誘導されます。彼らは、MICをを計算するために使用される16バイトのTEK-AUTHに分割され、16バイトのTEK-暗号は、選択した属性を暗号化するために使用されます。 SMSが新鮮であるので、その派生のTEKです。
+--------------------+ +--------------------+
| 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 |
+--------------------+ +--------------------+
Figure 6. Key Hierarchy for the EAP-SAKE Method
EAP-SAKE方法について図6.キー階層
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-酒のKDFを用いてナンスから誘導されます。ここでも、SMS以来、新鮮なので、派生MSK / EMSKです。 MSKは、他の当事者に輸出して中継されることを意図しています。 EMSKは、アプリケーション固有キーの派生として、将来の使用のために予約されており、他の関係者と共有されません。
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
--------------------------------------------------------------------
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のこのバージョンは速い再認証をサポートしていないので、のTEKの寿命は次のEAP相互認証まで拡張することです。次の相互認証が行われる場合にMSKの寿命が決まります。サーバーはAT_MSK_LIFE属性にピアにMSKの寿命を伝えることができます。 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-酒法-IDはAT_RAND_P属性にRAND_Pフィールドの内容に続いて、AT_RAND_S属性からRAND_Sフィールドの内容です。
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キー派生関数を示しています。この関数は、[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つの文字列かかり：キー、ラベル、およびメッセージを、以下のように長さXバイトのうち、文字列を出力します。
Out = KDF-X (Key, Label, Msg)
アウト= KDF-X（キー、ラベル、メッセージ）
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はキー「キー」と入力「|メッセージラベル」上で動作して鍵付きハッシュ関数です。慣例は、本明細書に続いて、その連結がで示されている|、床は、床関数、および[X ... Y]表すバイト×Yを介してです。
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（キー、ラベル、メッセージ、長さ）：= HMAC-SHA1（キー、ラベル| Y |メッセージ|長）ここで、Y：= 0x00のKDF-16（キー、ラベル、メッセージ）：= KDF（キー、ラベル、メッセージ、16）KDF-32（キー、ラベル、MSG）：= KDF（キー、ラベル、メッセージ、32）KDF-128（キー、ラベル、MSG）：= 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：= [] ;; FLOORへ= 0（長さ/ 20）-1 Rん：私のためにnull文字列= Rを| H-SHA1（キー、ラベル、メッセージは、I）R [0 ...（長さ-1）]を返します
The Peer and Server derive the SMS and then the TEK as follows:
次のようにピアおよびサーバは、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（ルート・シークレット-A、 "SAKEマスターシークレットA"、RAND_P | RAND_S）TEK = KDF-32（SMS-A、 "一時EAPキー"、RAND_S | RAND_P）TEK-AUTH = TEK [0 ... 15] TEK暗号= TEK [16 ... 31]
The Peer and the Server derive the MSK/EMSK, as follows:
次のようにピアおよびサーバは、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]
SMS-B = KDF-16（ルート・シークレット-B、 "SAKEマスターシークレットB"、RAND_P | RAND_S）セッション・キー・ブロック= KDF-128（SMS-B、 "マスターセッションキー"、RAND_S | RAND_P）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の知識につながるん。
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.
暗号スイートは、セキュリティパラメータインデックス（SPI）と呼ばれる数値によって識別されます。 SPIは、ピアとのみEAPデータ保護のためのサーバー間の暗号スイートを交渉するために、EAP-SAKE方法で、ここで使用されています。それはピアとサーバの両方が合意された後に明らかに、この暗号スイートは、後半のEAPの会話の中で使用することができます。
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メソッドがまたは、この暗号スイートを使用する必要がない場合があります。一時的な識別子は、ピアに配信する必要があると、暗号化する必要がある場合たとえば、その後に交渉暗号スイートは、このタスクのために使用されます。彼らはピアに渡されると、暗号化を必要とする属性がない場合は、この暗号スイートは使用されることはありません。
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.
暗号スイートのネゴシエーションを使用するほとんどの他の方法と同様に、以下の交換が採用されている：ピアは、フィールドSPI_Pで、最も好ましいものから始めて、一つ以上のサポートされているCipherSuiteの順序付きリストを送信します。 Serverは、フィールドSPI_Sに選ばれた1つの暗号スイートを送り返します。サーバーは、それらの両方でサポートされている最強の暗号スイートを選択する必要があります。
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.
次のようなデータ保護のための暗号スイートネゴシエーションはSAKEシグナリングを介して達成されます。 EAP.Response / SAKE /チャレンジでは、ピアは、サポートされる暗号スイートのリストを送信するSPI_P、及びMICであることを保護します。 EAP.Request / SAKEで/ Serverは、MICと一つの選択された暗号スイート、SPI_S、および徴候それを送信し、確認してください。最後に、ピアは、選択された暗号スイートおよび署名さEAP.Response /酒/メッセージを確認し、それを使用するための準備を確認します。交渉があるため全体のEAPメッセージをカバーするメッセージ整合性チェックの安全です。
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.
AT_MIC_S、AT_MIC_P、AT_IV、AT_ENCR_DATA、およびAT_PADDING：このセクションでは、メッセージの整合性と属性の暗号化に使用するEAP / SAKE属性を指定します。 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.
属性の保護のためのメッセージ認証のために必要なのTEKは、ナンスのRAND_SとRAND_Pを使用して導出されているので、AT_MIC_SとAT_MIC_PはEAP.Response / SAKE /挑戦メッセージ、その後、送信されたメッセージで使用できる属性。
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メッセージの整合性のために使用されています。 AT_MIC_S属性は、キーマテリアル（TEK）が導出された時はいつでもサーバーが送信するすべてのEAP-SAKEパケットに含まれなければなりません。これは、AT_MIC_S属性がEAP.Request / SAKE /メッセージを確認しに含まれる必要があります。 AT_MIC_SはEAP.Request / SAKE /チャレンジメッセージ、またはEAP.Request / SAKE /アイデンティティメッセージに含まれてはいけません。
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.
AT_MIC_P属性は、すべてのEAP-SAKEに含まれなければならない重要な材料（TEK）が導出された時はいつでもピアが送信するパケット。これは、AT_MIC_P属性がEAP.Response / SAKE /チャレンジと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.
ピアは、それがサーバーと同じTEKを有していることが確認されていないので、AT_MIC_P属性がEAP.Response / SAKE / AUTH-Rejectメッセージに含まれてはいけません。
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は、サーバのナンスと識別子とピアナンスと識別子を先頭に付け、全体のEAPパケットに対して計算されます。 MICを計算するときMIC属性の値フィールドはゼロに設定されています。サーバおよびピアのナンスと識別子補助リプレイを検出すると、man-in-the-middle攻撃を含みます。
The Peer computes its MIC as follows:
次のようにピアがそのMICを計算します。
MIC_P = KDF-16 (TEK-Auth, "Peer MIC", RAND_S | RAND_P | PEERID | 0x00 | SERVERID | 0x00 | <EAP-packet>),
MIC_P = KDF-16（AUTH-TEK、 "ピアMIC"、RAND_S | RAND_P |ピア| $ 00 |サーバー| $ 00 | <EAP-パケット>）、
while the Server computes its MIC as
サーバーは、その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、 "サーバーMIC"、RAND_P | RAND_S | SERVERID | $ 00 | PEERID | $ 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パケットを、意味します。 0x00がSERVERIDとPEERIDを区切るために使用される単一のオクテット値です。 PEERIDとSERVERIDは、それぞれ、SAKE /チャレンジメッセージに対応する属性で運ばれたものです。
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の属性を含むEAP.Request /酒/ Identityメッセージに先行し、次いで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酒/チャレンジメッセージまたは酒/ Identityメッセージのいずれかに含まれていなかった場合、MIC_PとMIC_Sの計算に使用されるSERVERIDの値は空でなければなりません。 AT_PEERID酒/チャレンジメッセージに含まれていなかった、酒/チャレンジメッセージを先行ないEAP.Response /酒/ Identityメッセージがなかった場合、MIC_PとMIC_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.
ピアおよびサーバが互いの身元を確認し、共通の秘密の所持、TEK-認証できるように、サーバおよびピアのアイデンティティが署名した応答の計算に含まれています。 AT_SERVERIDが明示的にサーバーによってMICで署名されていないので、EAP-SAKEは、結合チャネルを主張しません。
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.
AT_IVとAT_ENCR_DATA属性は、サーバおよびピア間で暗号化された情報を送信するために使用することができます。 AT_IVの値フィールドは1を使用する暗号化アルゴリズムによって必要とされる場合、初期化ベクトル（IV）を含有します。 AT_ENCR_DATA属性があるたびAT_IV属性を含めることが必須ではありません。
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.
属性は、暗号スイートは、すなわち、任意のメッセージでメッセージを確認/ ServerのEAP.Request / SAKEで始まる、合意された後にのみ暗号化することができます。属性はAT_SPI_S属性で指定されたSPI値に対応するアルゴリズムを使用して暗号化されなければなりません。属性は、その導出節3.2.6.2に指定されているTEK-暗号キーを使用して暗号化されなければなりません。
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属性の新しい値を選択する必要があります。送信側は初期化ベクトル（ガイドラインについては[RFC4086]を参照）を生成するために、良好な乱数発生器を使用すべきです。
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属性で指定された暗号スイートを使用して暗号化されたバイトで構成されます。暗号化キーは、TEK-暗号で、平文は、一つ以上の連結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属性を含めるべきではありません。 AT_PADDING属性の長さは、属性タイプと属性の長さフィールドを含んでいます。値フィールドの実際のパッドバイトが送信にゼロ（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項に示されています。
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は、[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方式におけるピアは、そのSPI_Pフィールドに4つのSPI値まで送信することができます。 AT_SPI_PとAT_SPI_Sの長さがそれぞれ2バイトの倍数でなければならない属性があるため、必要なゼロバイトの送信元パッド値フィールド（AT_PADDING属性がここで使用されていない）場合。例えば、AT_SPI_Sの値フィールドは、ゼロの1バイトに続いて選択されたSPIと1つのバイトを含んでいます。
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バイトに、その長さフィールドによって制限されるのNAIを運ぶものです。
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.
不正な形式のメッセージ：ピアまたはサーバにエラーが含まれているEAP-SAKEパケットを受信した場合、原則として、実装は静かに、このパケットを破棄状態を変更しないと、相手にどんな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).
ピアまたはサーバは、このセッション中に前のパケットからのセッションIDと一致しないセッションIDフィールドを持つEAP-酒パケットを受信した場合、そのエンティティは、サイレントの最初のメッセージには適用されない（このパケットを破棄すべきである：セッションID不一致EAP-SAKEセッション）。
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.
認証の失敗をピア：ピアは、このような端末装置が盗まれたと報告されている場合などのサービスのために許可されていないことも可能です。その場合、サーバーはEAP.Failureのメッセージを送信する必要があります。
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.
予期しないEAP.Success：サーバーがラウンドを確認/ SAKE /チャレンジとSAKE前にEAP-Successメッセージを送ってはいけません。ピアはパケットを確認/ EAP.Response / SAKE経由でサーバーを正常に認証される前にピアが静かにどんなEAP.Successパケットを捨てなければなりません。
The Peer and Server SHOULD log all error cases.
ピアおよびサーバは、すべてのエラーケースがログインする必要があります。
A summary of the EAP packet format [EAP] is shown below for convenience. The fields are transmitted from left to right.
EAPパケットフォーマット[EAP]の要約は、便宜上、下に示されています。フィールドは左から右に送信されます。
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
コード
1 - Request
1 - 要求
2 - Response
2 - レスポンス
Identifier
識別
The identifier field is one octet and aids in matching responses with requests.
識別子フィールドは、リクエストとレスポンスのマッチングで1オクテットとエイズです。
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.
長さフィールドは、2つのオクテットであり、コード、識別子、長さ、タイプ、およびデータフィールドを含むEAPメッセージ内のオクテットの数を示します。
Type
タイプ
To be assigned.
割り当てられます。
Version
版
The EAP-SAKE method as described herein is version 2.
本明細書に記載されるようにEAP-酒法は、バージョン2です。
Session ID
セッション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.
セッションIDは、たて、特定のEAPの会話の中で、すべてのEAPメッセージと一致している必要がありServerによって生成されなければならない1バイトの乱数です。
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サブタイプ：SAKE /挑戦、SAKE /確認し、SAKE /認証拒否、およびSAKE /アイデンティティ。これらのサブタイプのものではないタイプ「EAP-SAKE」のすべてのメッセージは静かに捨てなければなりません。
Message Name Subtype Value (decimal)
=============================================
SAKE/Challenge 1
SAKE/Confirm 2
SAKE/Auth-Reject 3
SAKE/Identity 4
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:
EAP-酒パケットの一部であるEAP-酒属性は、1バイトのタイプ、1バイト長、可変長値（最大255バイト）を有するタイプレングス値の形式に従います。 Lengthフィールドは、オクテットにあり、タイプと長さフィールドの長さを含んでいます。次のようにEAP-SAKE属性の形式は次のとおりです。
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
タイプ
1-byte unsigned integer; see Table below.
1バイトの符号なし整数。下記の表を参照してください。
Length
長さ
The total number of octets in the attribute, including Type and Length.
タイプと長さなどの属性、のオクテットの総数。
Value
値
Attribute-specific.
属性固有。
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
AT_MSK_LIFE 6 Yes MSK Lifetime in seconds
-----------------------------------------------------------------
An example of the AT_ENCR_DATA attribute, as used in the EAP.Request/SAKE/Confirm message, is shown below:
AT_ENCR_DATA属性の例は、EAP.Request /酒に使用される/メッセージを確認し、以下に示します。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the EAP.Request/SAKE/Challenge packet is shown below.
EAP.Request /酒/チャレンジパケットのフォーマットは以下に示されています。
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:
フィールドの意味は以下の通りであります：
Code
コード
1 for Request
リクエストのための1
Identifier
識別
A random number. See [EAP].
乱数。 [EAP]を参照してください。
Length
長さ
The length of the entire EAP packet in octets.
オクテット内全体EAPパケットの長さ。
Type
タイプ
EAP-SAKE
EAP-SAKE
Version
版
2
２
Session ID
セッションID
A random number chosen by the server to identify this EAP-Session.
このEAP-セッションを識別するために、サーバによって選ばれた乱数。
Subtype
サブタイプ
1 for SAKE/Challenge
販売のための1 /チャレンジ
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.
この属性の値フィールドには、サーバのナンスのRAND_Sパラメータが含まれています。 RAND_S属性がEAP.Request / SAKE /チャレンジ中に存在しなければなりません。
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.
この属性の値フィールドは、サーバ識別子（例えば、非ヌル終端文字列）が含まれています。 AT_SERVERID属性がEAP.Request / SAKEチャレンジ中に存在すべきです。
The format of the EAP.Response/SAKE/Challenge packet is shown below.
EAP.Response /酒/チャレンジパケットのフォーマットは以下に示されています。
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:
フィールドの意味は以下の通りであります：
Code
コード
2 for Response
レスポンスのための2
Identifier
識別
A number that MUST match the Identifier field from the corresponding Request.
対応する要求の識別子フィールドに一致しなければならない数。
Length
長さ
The length of the entire EAP packet in octets.
オクテット内全体EAPパケットの長さ。
Type
タイプ
EAP-SAKE
EAP-SAKE
Version
版
2
２
Session ID
セッションID
A number matching all other EAP messages in this EAP session.
このEAPセッション内の他のすべてのEAPメッセージに一致する番号。
Subtype
サブタイプ
1 for SAKE/Challenge
販売のための1 /チャレンジ
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.
この属性の値フィールドは、ピア・ナンスRAND_Pパラメータが含まれています。 AT_RAND_P属性がEAP.Response / SAKE /チャレンジ中に存在しなければなりません。
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.
この属性の値フィールドは、ピアのNAIが含まれています。ピアのアイデンティティは、NAIのレルム部分を含むEAP.Response /アイデンティティに使用されているのと同じネットワークアクセス識別子のフォーマット、すなわち、以下。アイデンティティは、永久的なアイデンティティ、または一時的なアイデンティティです。アイデンティティは、任意の終端のnull文字が含まれていません。 AT_PEERID属性がEAP.Response / SAKE /チャレンジではオプションです。
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.
この属性の値フィールドは、ピアの暗号スイートリストSPI_Pパラメータが含まれています。 AT_SPI_P属性がEAP.Response / SAKE /チャレンジではオプションです。
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.
この属性の値フィールドは、ピアMIC_Pパラメータが含まれています。 AT_MIC_P属性がEAP.Response / SAKE /チャレンジ中に存在しなければなりません。
The format of the EAP.Request/SAKE/Confirm packet is shown below.
EAP.Request /酒/確認パケットのフォーマットを以下に示します。
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:
フィールドの意味は以下の通りであります：
Code
コード
1 for Request
リクエストのための1
Identifier
識別
A random number. See [EAP].
乱数。 [EAP]を参照してください。
Length
長さ
The length of the entire EAP packet in octets.
オクテット内全体EAPパケットの長さ。
Type
タイプ
EAP-SAKE
EAP-SAKE
Version
版
2
２
Session ID
セッションID
A number matching all other EAP messages in this EAP session.
このEAPセッション内の他のすべてのEAPメッセージに一致する番号。
Subtype
サブタイプ
2 for SAKE Confirm
特売確認のために2
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.
この属性の値フィールドは、サーバー選択した暗号スイートSPI_Sパラメータが含まれています。 AT_SPI_S属性がEAP.Request / SAKE /確認ではオプションです。
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.
この属性は、このメッセージに使用するオプションです。この属性の値フィールドは、暗号化されたデータは、次のように使われている初期化ベクトルが含まれています。
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.
この属性は、このメッセージに使用するオプションです。存在する場合、暗号化されたデータは、ピアは、次のEAP認証に使用する必要がありNAIを含む、属性AT_NEXT_TMPIDが含まれていてもよいです。
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.
この属性は、このメッセージに使用するオプションです。この属性の値フィールドは、秒単位でMSKの寿命が含まれています。
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.
この属性の値フィールドは、Server MIC_Sパラメータが含まれています。 AT_MIC_S属性がEAP.Request / SAKE /確認中に存在しなければなりません。
The format of the EAP.Response/SAKE/Confirm packet is shown below.
EAP.Response /酒/確認パケットのフォーマットを以下に示します。
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:
フィールドの意味は以下の通りであります：
Code
コード
2 for Response
レスポンスのための2
Identifier
識別
A number that MUST match the Identifier field from the corresponding Request.
対応する要求の識別子フィールドに一致しなければならない数。
Length
長さ
The length of the entire EAP packet in octets.
オクテット内全体EAPパケットの長さ。
Type
タイプ
EAP-SAKE
EAP-SAKE
Version
版
2
２
Session ID
セッションID
A number matching all other EAP messages in this EAP session.
このEAPセッション内の他のすべてのEAPメッセージに一致する番号。
Subtype
サブタイプ
2 for SAKE Confirm
特売確認のために2
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.
この属性の値フィールドは、ピアのMIC_Pパラメータが含まれています。 AT_MIC_P属性がEAP.Response / SAKE /確認中に存在しなければなりません。
AT_PADDING
AT_PADDING
The value field is set to zero. Added to achieve 32-bit alignment of the EAP-SAKE packet.
値フィールドはゼロに設定されています。 EAP-酒パケットの32ビット・アラインメントを達成するために添加しました。
The format of the EAP.Response/SAKE/Auth-Reject packet is shown below.
EAP.Response /酒/認証拒否パケットのフォーマットを以下に示します。
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:
フィールドの意味は以下の通りであります：
Code
コード
2 for Response
レスポンスのための2
Identifier
識別
A number that MUST match the Identifier field from the corresponding Request.
対応する要求の識別子フィールドに一致しなければならない数。
Length
長さ
The length of the entire EAP packet in octets.
オクテット内全体EAPパケットの長さ。
Type
タイプ
EAP-SAKE
EAP-SAKE
Version
版
2
２
Session ID
セッションID
A number matching all other EAP messages in this EAP session.
このEAPセッション内の他のすべてのEAPメッセージに一致する番号。
Subtype
サブタイプ
3 for SAKE/Auth-Reject
3販売用/認証拒否
The format of the EAP.Request/SAKE/Identity is shown below.
EAP.Request /酒/アイデンティティの形式を以下に示します。
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:
フィールドの意味は以下の通りであります：
Code
コード
1 for Request
リクエストのための1
Identifier
識別
A random number. See [EAP].
乱数。 [EAP]を参照してください。
Length
長さ
The length of the entire EAP packet in octets.
オクテット内全体EAPパケットの長さ。
Type
タイプ
EAP-SAKE
EAP-SAKE
Version
版
2
２
Session ID
セッションID
A number matching all other EAP messages in this EAP session.
このEAPセッション内の他のすべてのEAPメッセージに一致する番号。
Subtype
サブタイプ
4 for SAKE/Identity
販売のための4 /アイデンティティ
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.
AT_PERM_ID_REQ属性は、サーバーがその永続的識別子（すなわち、PermID）を得ピアを必要とする場合に含まれるように、任意です。 _どんなAT__ID REQ属性が含まれている場合AT_PERM_ID_REQを含んではいけません。値フィールドは、送信時にゼロに設定され、受信時には無視されている2つの予約バイトを含んでいます。
AT_ANY_ID_REQ
_どんなAT__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.
_どんなAT__ID REQ属性は、サーバが任意の識別子（例えば、PermID、TempID）を送信するピアを必要とする場合に含まれるように、任意です。 AT_PERM_ID_REQが含まれている場合は_どんなAT__ID REQを含んではいけません。値フィールドは、送信時にゼロに設定され、受信時には無視されている2つの予約バイトを含んでいます。 AT_PERM_ID_REQと_どんなAT__ID REQの一つを含まなければなりません。
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.
この属性の値フィールドは、サーバの識別子/レルムが含まれています。 AT_SERVERID属性はオプションですが、EAP.Request / SAKE /アイデンティティに含めることをお勧めします。
The format of the EAP.Response/SAKE/Identity is shown below:
EAP.Response /酒/アイデンティティの形式を以下に示します。
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:
フィールドの意味は以下の通りであります：
Code
コード
2 for Response
レスポンスのための2
Identifier
識別
A number that MUST match the Identifier field from the corresponding Request.
対応する要求の識別子フィールドに一致しなければならない数。
Length
長さ
The length of the entire EAP packet.
全体のEAPパケットの長さ。
Type
タイプ
EAP-SAKE
EAP-SAKE
Version
版
2
２
Session ID
セッションID
A number matching all other EAP messages in this EAP session.
このEAPセッション内の他のすべてのEAPメッセージに一致する番号。
Subtype
サブタイプ
4 for SAKE/Identity
販売のための4 /アイデンティティ
AT_PEERID
AT_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.
この属性の値フィールドは、ピアのNAIが含まれています。 AT_PEERID属性がEAP.Response / SAKE /アイデンティティ中に存在しなければなりません。
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）は、このパケットの中に存在すべきです。
The format of the EAP-Success and EAP-Failure packet is also shown in [EAP].
EAP-成功とEAP-Failureパケットのフォーマットは、[EAP]に示されています。
IANA allocated a new EAP Type for EAP-SAKE.
IANAはEAP-SAKEのための新しいEAPタイプを割り当てられます。
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ビットのサブタイプフィールドを含みます。サブタイプは、IANA管理が必要である新しい付番スペースです。次のサブタイプは、このメモで指定されています。
SAKE/Challenge.................1
SAKE/Confirm...................2
SAKE/Auth-Reject...............3
SAKE/Identity..................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:
サブタイプ特異的データは、8ビット・タイプ番号を持つ属性、から構成されています。 127までの範囲内で0番の属性がスキップ不可属性と呼ばれ、128〜255の範囲内の属性は、スキップ可能な属性と呼ばれます。 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
AT_ENCR_DATA..................................128
AT_IV.........................................129
AT_PADDING....................................130
AT_NEXT_TMPID.................................131
AT_MSK_LIFE...................................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コンセンサスが必要です。
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仕様[EAP]は、その方法に固有のセキュリティメカニズムを備えていないEAPのセキュリティの脆弱性を説明しています。このセクションでは、脆弱性とセキュリティの推奨とともに、EAP-酒法の記載セキュリティ性を論じています。
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-酒トンネリング方式ではないので、EAP.Response /酒/認証拒否、EAP.Success、及びEAP.Failureパケットが完全性又は再生保護されていません。これにより、攻撃者がこのようなメッセージを偽装できるようになります。なお、EAP.Response / SAKE /認証失敗がサーバおよびピアは、共通鍵に同意しないことを示しているので、MICで保護することができない認証が拒否。
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.
最も重要なのは、攻撃者は、ピアはサーバが相互認証が達成されたと考える指標としてEAP.Successパケットを受け入れさせることはできません。それはサーバーを認証している前に、またはそれはサーバーが認証を失敗したとみなされた後、ピアはEAP.Successパケットを受け付けないためです。
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.
ルートシークレットは、サーバーおよびピア以外の第三者に知られている場合、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の秘密が生成されるか、またはサーバおよびピアに配布する方法を扱っていません。 rootの秘密のエントロピーが最大化されることが推奨されます。ルート秘密は、機械で生成されるべきです。
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.
ルート秘密は、ヒト、選択したパスワード等の低エントロピー、推測量に由来する場合、EAP-酒鍵導出はオンラインおよびオフライン辞書攻撃を受けやすいです。そのようなパスワードが危険にさらされているかどうかを識別しやすくするために、実装は、無効なMICフィールドで受信EAP-SAKEメッセージの数のログを維持する必要があります。これらのケースでは、しっかりと根の秘密を更新する手順は、場所にする必要があります。
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 /チャレンジは、サーバのナンスのRAND_Sが含まれています。 EAP.Response /酒/チャレンジピアMIC（MIC_P）とともに、ピアノンスRAND_Pを含有します。そしてEAP.Request / SAKE /確認は、サーバーのMIC（MIC_S）が含まれています。両方のMIC（MIC_SとMIC_P）は、両方のナンスRAND_SとRAND_Pを使用して計算され、TEK、ルート秘密から誘導される共有秘密をキーとしています。それは計算MIC_Pは、ピアが送信したものと一致する場合、サーバーは認証されたピアを考慮します。同様に、ピアは、それが計算MIC_Sは、サーバーが送信したものと一致する場合、認証サーバを考えています。 MIC値が計算される方法は、攻撃者が共有の秘密の知識がなくても正しいMICを生成するための計算ハードそれを作る鍵付き一方向ハッシュ関数を含みます。
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メッセージの完全性保護はEAP.Request後、共通の共有秘密（TEK）はすなわち、利用可能になるとすぐに、すべてのメッセージの中に存在しているメッセージ整合性チェック（MIC）、を使用して任意のメッセージを達成しています/ SAKE /挑戦。敵はMICの障害が発生したために、受信者を招くことなく、MIC-保護されたメッセージのいずれかを変更することはできません。完全性保護の範囲は、KDFのセキュリティに見合ったMIC、KDFが使用する共有秘密鍵の長さとエントロピー、及びMICの長さを導出するために使用されます。
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-酒などのほとんどのセッション確立プロトコルの最初のメッセージは、再生の対象となります。再生EAP.Request /酒/チャレンジメッセージは、攻撃者の選択したnonceを使用して計算されたMICを含む、バックEAP.Response /酒/チャレンジメッセージを送信ピアになります。これは、TEK-認証キーの妥協に最小限のリスクをもたらす、とピアが無効なサーバーのMICを見つけるだろうとこのEAPセッションを正常に進めることができません。
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).
リプレイ保護は一緒にEAP-酒/チャレンジ要求パケットに後続する各パケット内に存在するMICの計算に含まれるセッションIDフィールドと、RAND_SとRAND_P値を介して達成されます。セッションIDは、各EAPセッションのためのサーバによって新たに生成されなければなりません。セッションIDもピアとサーバ間の可能な複数のEAPセッションの識別に役立てます。同一セッション内では、メッセージが攻撃者によって再生することができますが、ステートマシンは、これらのケースを処理できる必要があります。セッション内の再生（例えば、メッセージが最初に失われた後、再送信するので、受信者は、それが重複メッセージであると考えて）ネットワーク故障から受信者に区別できないことに留意されたいです。
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セッション内の再生保護は、（セッションIDを含む）全体のEAPパケットもナンスのRAND_SとRAND_Pないだけを覆ってMICを介して達成されます。このように、EAPメッセージの受信者は、それが受信者のナンスや他のピアナンスの有効なMICが含まれているので、それだけで受信したメッセージは、単に他のピアによって送信され1ないリプレイであることを保証することができます。前と同じように、リプレイ保護の範囲は、MIC、KDFが使用する共有秘密鍵の長さとエントロピー、及びMICの長さを導出するために使用KDFのセキュリティに見合っています。
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属性を使用してサポートされています。暗号スイートは、セキュアにネゴシエートされる（セクション3.2.7参照）、必要に応じて任意の属性を暗号化するために使用することができます。デフォルトの暗号スイートはAESに基づく強力な暗号が含まれています。
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-酒マスターセッションキー（EAP使用のための）マスターキー、並びにのTEKのような他の下位レベルの鍵を導出します。下位レベルのキーの一部を用いても用いなくてもよいです。すべてのこれらのキーの強さ（エントロピー）は、rootの秘密の最も強度です。
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.
サーバおよびピア128ビットのノンスは、良好な乱数発生器を使用して生成されていると仮定MSK及びEMSKのエントロピーは、ほとんどの256ビットです。
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法にマウントすることは不可能です。その代わり、ルート秘密は、機械生成です。これは、必ずしも問題のプロビジョニングをもたらすことはありません。
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.
man-in-the-middle攻撃に対する耐性は、各EAPメッセージを運ぶ完全性保護（すなわち、メッセージ完全性チェックフィールド）とすぐに相互認証によって導出されたこのEAPセッションのための共通鍵を介して提供されます。前と同じように、この抵抗の程度は、MIC自体の強度に見合いました。トンネリングまたは配列決定プロトコル内の任意のEAP方式の使用に関連したman-in-the-middle攻撃は、このドキュメントの範囲を超えています。
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は、それが結果指摘、完全性保護、および再生保護を提供することで、結果表示の保護を提供します。サーバーは、それが成功しEAP.Request / SAKE /整合性とリプレイ保護されたメッセージを、確認してを送信することによりピアを認証したことを示しています。ピアは、それがEAP.Response / SAKE /また、整合性とリプレイ保護されたメッセージを、確認してを送信することにより、サーバーを正常に認証していることを示しています。
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.
EAP-SAKEパケット（TEK-AUTH、TEK-暗号）、マスターセッションキー、および拡張マスターセッションキーを保護するために使用されるのTEKは、個別の暗号的です。これらのキーのいずれかについての情報は、他のどのキーに関する情報にはつながりません。我々はまた、のTEK、MSK、またはEMSKのいずれかまたは全てから、rootの秘密を計算することが実行不可能であることに注意してください。
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-酒セッション内で、新鮮な鍵材料が生成されます。以下に説明するように、2つの独立したEAP-酒セッションから、この方法によってエクスポート鍵材料は、別個の暗号です。
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 separate from the corresponding keys derived in the previous exchange.
サーバとEAP-酒交換のための新鮮な乱数を生成する必要がピア（すなわち、ナンス）の両方。どちらかのエンティティは、以前のセッションからの乱数を再使用する場合、他に新たに生成された乱数を使用しないという事実は、このセッション内由来のTEK、MSKおよびEMSKはで導出対応するキーから暗号分離されていることを意味します前回の交換。
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.
従って、一つの交換にMSK又はEMSKの妥協は、ピアとサーバとの間の前または後の交換のMSKおよびEMSKを損ないません。
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. から分かるように、サーバーは、ユーザーの匿名性を達成するために、ピアへの一時的なNAIを割り当てることができます。この識別子は、ピアによって、サーバとEAP-酒認証フェーズに係合次回を使用することができます。 TempIDはAT_ENCR_DATA属性の中に、暗号化され、それを送信することによって保護され、MICとサーバーによって署名されています。従って、盗聴者は、ピアが最初のサーバに平文で送信された後続の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.
サーバとピアが唯一TempIDアイデンティティはピア永久的なアイデンティティを使用していますつの初期EAP-SAKEフェーズの後に交換されるように構成してもよいです。この場合、最大のアイデンティティ保護を実現するために、TempIDはピアおよびサーバの不揮発性メモリに格納する必要があります。したがって、この文書の遵守は、ピアの生涯にわたるピアID保護を排除するか、強制しません。
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 /チャレンジメッセージで送信することができます。最初のメッセージの現時点では確立した認証キーが存在しないので、サーバー識別子は、完全性保護され、ここではありません。
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段階中に交換彼らはメッセージ完全性チェック（MIC）を含有するよう、整合性が保護されています。 MICは、EAPメッセージにわたって計算され、サーバおよびピアのアイデンティティを超えます。そのでは、両方のEAPエンドポイントは、相手の身元を確認することができます。
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の会話をするために使用される暗号スイートのネゴシエーションをサポートしていません。ただし、データ保護のための暗号スイートのネゴシエーションがサポートされています。この暗号スイートのネゴシエーションがダウン交渉やman-in-the-middle攻撃のリスクを最小限にするために、保護されています。
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.
この交渉は、理由の暗号群のネゴシエーションに使用全体のEAPメッセージをカバーするメッセージ整合性チェック（MIC）があるかの安全である（セクション3.2.7を参照してください。）。交渉のセキュリティの程度はMICは、KDFが使用する共有秘密鍵の長さとエントロピーを導出するために使用KDFのセキュリティ、およびMICは長さに見合ったです。
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バイトのルート秘密から鍵導出をサポートしています。それから誘導される他のすべてのキーのエントロピーは、鍵付きハッシュ関数（例えば、KDF）を使用することによって幾分減少します。したがって、ルート秘密の有効鍵強度は32バイトで、導出鍵の有効鍵強度は、それらが由来するルート秘密量の最も効果的な強みであると楽観的仮定：EMSK、最大16のバイトで。 MSK、ほとんどの16のバイトで。
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-酒対称事前共有秘密に基づいて、チャレンジ/レスポンス認証と鍵確立のメカニズムです。
[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)
サーバーからとピアからの認証が成功の保護された結果指示（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-酒256ビットの実効キー強度（セクション5.7）と主要な派生をサポート
[d] Description of key hierarchy: see Section 3.2.5.
[D]キー階層の説明：3.2.5項を参照してください。
[e] Indication of vulnerabilities: EAP-Make does not provide:
脆弱性の[E]表示：EAP-メイクが用意されていません。
Fast reconnect
高速再接続
Fragmentation
フラグメンテーション
Channel binding
結合チャンネル
Cryptographic binding
暗号化は、結合します
Thanks to R. Dynarski for his helpful comments.
彼の有益なコメントのためにR. Dynarskiに感謝します。
[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、のAdvanced Encryption Standard（AES）"、2001年11月http://csrc.nist.gov/publications/ FIPS / FIPS197 / fips- 197.pdf
[CBC] National Institute of Standards and Technology, NIST Special Publication 800-38A, "Recommendation for Block Cipher Modes of Operation - Methods and Techniques", December 2001. http://csrc.nist.gov/publications/ drafts/Draft-NIST_SP800-38D_Public_Comment.pdf
[CBC]アメリカ国立標準技術研究所、は、NIST Special Publication 800-38A、「操作のブロック暗号モードのための推薦 - の方法と技術」、2001年12月http://csrc.nist.gov/publications/ドラフト/ Draft- NIST_SP800-38D_Public_Comment.pdf
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[EAP] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、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問題部に書くためのガイドライン"、BCP 26、RFC 2434、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 / MAN特定要件 - パート11：無線媒体アクセス制御（MAC）及び物理層（PHY）仕様：修正6：媒体アクセス制御（Medium Access Control MAC）セキュリティ強化」、2004年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、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月「ハッシュ標準セキュア」。
[NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[NAI] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク、D.、3、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
Authors' Addresses
著者のアドレス
Michaela Vanderveen Qualcomm Flarion Technologies 135 Rte. 202/206 South Bedminster, NJ 07921 USA
ミカエラVANDERVEENクアルコムフラリオン・テクノロジーズ135のRTE。 206分の202南Bedminster、NJ 07921 USA
EMail: mvandervn@yahoo.com
メールアドレス：mvandervn@yahoo.com
Hesham Soliman Qualcomm Flarion Technologies 135 Rte. 202/206 South Bedminster, NJ 07921 USA
Heshamソリマンクアルコムフラリオン・テクノロジーズ135のRTE。 206分の202南Bedminster、NJ 07921 USA
EMail: solimanhs@gmail.com
メールアドレス：solimanhs@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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.
この文書では、BCP 78に及び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.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。