[要約] RFC 4763は、共有秘密認証と鍵の確立のための拡張認証プロトコル（EAP-SAKE）に関するものです。このRFCの目的は、EAP-SAKEを使用してセキュアな認証と鍵の交換を実現することです。
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)
共有秘密認証と主要な確立のための拡張可能な認証プロトコル法（EAPセイク）
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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は、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用のIETFレビューに基づいていないことに注意しています。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、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.
このドキュメントは、共有秘密認証と主要な確立（酒）のための拡張可能な認証プロトコル（EAP）メカニズムを指定します。このRFCは、RFC 3748ごとにベンダーのEAPメソッドのEAPタイプのIANA割り当てのドキュメントとして公開されています。この仕様は、この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は、スマートカード、Kerberos、公開キー、1回限りのパスワード、TLSなど、いくつかの認証スキームをサポートしています。このドキュメントは、EAPセイクと呼ばれる認証スキームを定義します。EAP-Sakeは、静的な事前に共有された秘密データに基づいて、相互認証とセッションキーの派生をサポートします。このRFCは、RFC 3748ごとにベンダーのEAPメソッドのEAPタイプのIANA割り当てのドキュメントとして公開されています。この仕様は、この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].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。これらの言葉はしばしば大文字になります。「必須」、「必要」、「必須」、「必須」、「必要」、「必要」、「は」、「そうではない」、「そうでない」、「推奨」、「5月」、「オプション」は、このドキュメントの「オプション」です。BCP 14 [キーワード]に記載されているとおりに解釈されます。
In addition to the terms used in [EAP], this document frequently uses the following terms and abbreviations:
[EAP]で使用されている用語に加えて、このドキュメントは頻繁に次の用語と略語を使用します。
MIC Message Integrity Check
マイクメッセージの整合性チェック
SMS SAKE Master Secret
SMS酒マスターシークレット
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セイクのスタンドアロンバージョンは定義されていません。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セイクは、ピアとサーバーにのみ知られている長期または事前に共有された秘密を想定しています。この恥ずかしさの秘密は、ルートシークレットと呼ばれます。ルートの秘密は、16バイトのパーツルートセクレットAと16バイトのパーツルートセクレット-Bで構成されています。root-secret-aの秘密は、EAPセイク方法、つまりEAPピアとEAPサーバーを相互に認証するためにローカルの使用のために予約されています。ルートセクレット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セイクの利点のいくつかは次のとおりです。
o It is based on well-established Bellare-Rogaway mutual authentication protocol.
o これは、確立されたBellare-Rogaway相互認証プロトコルに基づいています。
o It supports key derivation for local EAP method use and for export to other third parties to use them independently of EAP.
o ローカルEAPメソッドの使用と、EAPとは独立してそれらを使用するために他の第三者に輸出するための重要な派生をサポートします。
o It employs only two request/response exchanges.
o リクエスト/応答交換は2つしか使用していません。
o It relies on the (corrected) IEEE 802.11i function for key derivation and message integrity. This way a device implementing a lower-layer secure association protocol compliant with IEEE 802.11i standard will not need additional cryptographic code.
o キー派生とメッセージの整合性のために、（修正された）IEEE 802.11i関数に依存しています。このようにして、IEEE 802.11i標準に準拠した低層セキュアアソシエーションプロトコルを実装するデバイスは、追加の暗号コードを必要としません。
o Its encryption algorithm is securely negotiated (with no extra messages), yet encryption use is optional.
o 暗号化アルゴリズムは安全にネゴシエートされます（追加のメッセージはありません）が、暗号化の使用はオプションです。
o Keys used for authentication and those used for encryption are cryptographically separate.
o
o User identity anonymity can be optionally supported.
o ユーザーIDの匿名性はオプションでサポートできます。
o No synchronization (e.g., of counters) needed between server and peer.
o サーバーとピアの間では、同期（カウンターなど）は必要ありません。
o There is no one-time key pre-processing step.
o 1回限りのキー前処理ステップはありません。
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セイクは、2つのEAP要求/応答交換で構成される4つのメッセージを使用します。図に示されているEAP.SUCCESSおよびEAP.FAILUREメッセージは、EAPセイクメソッドの一部ではありません。慣習として、メソッド属性はat_xxという名前で、xxは属性値が設定されているパラメーターの名前です。
A successful EAP-SAKE authentication exchange is depicted in Figure 1. The following steps take place:
成功したEAPセイク認証交換を図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セイク認証手順（Ciphersuiteの交渉を伴う）
1. The EAP server sends the first message of the EAP-SAKE exchange. This message is an EAP.Request message of type SAKE and subtype Challenge. The EAP.Request/SAKE/Challenge message contains the attributes: AT_RAND_S, whose value is a nonce freshly generated 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セイク交換の最初のメッセージを送信します。このメッセージは、タイプ酒とサブタイプの課題のEAP.requestメッセージです。EAP.Request/Says/Challengeメッセージには、属性が含まれています。AT_RAND_Sの値は、サーバーによって新たに生成されたNONCEです。AT_SERVERIDは、サーバーの識別子（ユーザーNAI [NAI]の領域など、完全に適格なドメイン名）を搭載しています。AT_SERVERID属性はオプションですが、このメッセージに含める必要があります。AT_SERVERIDの目的は、このEAPフェーズで使用するために、ピアが正しいセキュリティ協会（つまり、ルートセクレット、ピーリド、および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/Say/Challengeメッセージには、AT_RAND_Pが含まれています。AT_RAND_Pには、ピアによって生成されたものが新たに生成されます。AT_PEERID、ピア識別子を運ぶ。AT_SPI_Pは、ピアによってサポートされている1つまたは複数の暗号のリストを掲載しています。メッセージの整合性チェックを含むAT_MIC_P。AT_SPI_PおよびAT_PEERID属性はオプションです。Multi-Homedホストのケースをカバーするために、AT_PeerID属性を含める必要があります。サポートされているCiphersuiteは、EAPセイクメソッドのローカル値、または「セキュリティパラメーターインデックス」の値で表されます。セクション3.2.8.3を参照してください。ピアは、ルートセクレットAキーとともに、両方のNoncesを使用して、Tek-AuthとTek-Cipherキーを含む酒のマスターシークレット（SMS）と一時的なEAPキー（TEK）を導き出します。MIC_P値は、nonces rand_sとrand_pの両方に基づいて計算され、キーtek-authを使用して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.
3. EAP.Response/Say/Challengeメッセージを受信すると、サーバーはnonces rand_sとrand_pの両方を使用して、ルートセクレットAキーを使用して、ピアが行ったのとまったく同じようにSMSとTEKを計算します。それに続いて、サーバーは、ピアが行ったのとまったく同じように、ピアのMIC_Pを計算します。サーバーは、計算されたMIC_Pをピアから受信したMIC_Pと比較します。それらが一致した場合、サーバーはピア認証のピアを考慮します。暗号化が必要な場合、サーバーは、ピアのCiphersuiteリストSPI_Pから最も強力な暗号化されたもの、またはピアにAT_SPI_P属性が含まれていない場合は適切なCipherSuiteを選択します。サーバーは、属性とサブタイプ確認のEAP.requestメッセージを送信します。これは、属性を含み、サーバーが選択したciphersuiteを運ぶ属性を含みます。暗号化されたデータを含むAT_ENCR_DATA;およびAT_MIC_S、メッセージの整合性チェックを実行します。AT_SPI_SおよびAT_ENCR_DATAは、機密性および/またはユーザーIDの匿名性が必要な場合に含まれるオプションの属性です。含まれる可能性のあるその他のオプションの属性は、at_next_tmpidとat_msk_lifeです。前と同様に、MIC_S値は、nonces rand_sとrand_pの両方を使用して計算され、EAPパケット全体がキーTek-authを使用して計算されます。
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/Says/CONDICEメッセージを受信した場合、ピアはサーバーと同じ方法でMIC_を計算します。ピアは、受信したMIC_Sを計算したMIC_Sと比較します。それらが一致する場合、ピアはサーバーを認証されたサーバーと見なし、タイプ酒とサブタイプ確認の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セイク交換が成功した後、サーバーは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セイクメッセージを受信すると、ピアとサーバーの両方がメッセージの形式をチェックして、適切に形成され、有効なセッション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とピア/サーバーペアの間には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.
AuthenticatorがサーバーからEAP.Failureメッセージを受信した場合、Authenticatorはすぐにピアとの接続を終了する必要があります。
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.
サーバーは、受け入れられると見なされるciphersuitesを宣伝していないピアの許可を拒否し（地域のシステムポリシーなど）、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
図2. EAPセイク認証手順、ピアは認証に失敗します
1. As in step 1 of Figure 1.
1. 図1のステップ1のように。
2. As in step 2 of Figure 1.
2. 図1のステップ2のように。
3. Upon receipt of the EAP.Response/SAKE/Challenge message, the Server uses both nonces RAND_S and RAND_P, along with the Root-Secret-A key, to compute the SMS and TEK in exactly the same way the Peer did. Following that, the Server computes the Peer's MIC in exactly the same way the Peer did. The Server then compares the computed MIC_P with the MIC_P it received from the Peer. Since they do not match, the Server considers the Peer to have failed authentication and sends an EAP.Failure message back to the Peer.
3. EAP.Response/Say/Challengeメッセージを受信すると、サーバーはnonces rand_sとrand_pの両方を使用して、ルートセクレットAキーを使用して、ピアが行ったのとまったく同じようにSMSとTEKを計算します。それに続いて、サーバーはピアが行ったのとまったく同じようにピアのマイクを計算します。サーバーは、計算された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属性に、前のメッセージにピアがリストしたSPI値のいずれかが含まれていない場合、またはピアがAT_SPI_P属性を含めていない場合、サーバーが選択したcipherSuiteを受け入れない場合、ピアはこのメッセージを静かに捨てるべきです。あるいは、ピアは、酒/承認メッセージをサーバーに送り返す場合があります。このメッセージに応じて、サーバーはピアに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値が一致しない場合、サーバーが認証に失敗したと見なします。この場合、ピアはサーバーにタイプ酒とサブタイプの認証拒否のREAP.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
図3. EAPセイク認証手順、サーバーは認証に失敗します
1. As in step 1 of Figure 1.
1. 図1のステップ1のように。
2. As in step 2 of Figure 1.
2. 図1のステップ2のように。
3. As in step 3 of Figure 1.
3. 図1のステップ3のように。
4. The Peer receives a EAP.Request/SAKE/Confirm message indicating successful authentication by the Server. The Peer computes the MIC_S in the same manner as the Server did. The Peer then compares the received MIC_S with the MIC_S it computed. Since they do not match, the Peer considers the Server to have failed authentication. In this case, the Peer responds with an EAP.Response message of type SAKE and subtype Auth-Reject, indicating authentication failure.
4. ピアは、サーバーによる認証が成功したことを示すEAP.Request/Says/Confismメッセージを受け取ります。ピアは、サーバーと同じ方法でMIC_を計算します。ピアは、受信した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.
5. EAP.Response/Say/Auth-Rejectメッセージを受信すると、サーバーは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).
ユーザーの匿名性が必要な場合、一時的な識別子（一時的な）をピアに割り当てることをお勧めします。一時的なものは、eap.request/sase/確認メッセージのピアに配信されます。Tempidは、Nai [Nai]の形式に従い、PeerとEAPセイク認証タスクに従事するEAPサーバーによって生成されます。EAPサーバーは、永続的なアイデンティティスペースと区別できる温度空間で構成可能である必要があります。たとえば、特定の領域を一時的に割り当てることができます（例：TMP.example.biz）。
A TempID is not assigned an explicit lifetime. The TempID is valid until the Server requests the permanent identifier, or the Peer triggers the start of a new EAP session by sending in its permanent identifier. A Peer MUST be able to trigger an EAP session at any time using its permanent identifier. A new TempID assigned during a successful EAP session MUST replace the existing TempID for future transactions between the Peer and the Server.
一時は明示的な寿命が割り当てられていません。Tempidは、サーバーが永続的な識別子を要求するまで有効であるか、またはピアが永続的な識別子を送信することにより新しいEAPセッションの開始をトリガーします。ピアは、永久識別子を使用していつでもEAPセッションをトリガーできる必要があります。成功したEAPセッション中に割り当てられた新しい一時的なものは、ピアとサーバーの間の将来のトランザクションのために既存の一時的なものを置き換える必要があります。
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.
一時的な配信は、サーバーがピア認証を検討していることを意味するものではないことに注意してください。サーバーは、eap.response/sase/確認メッセージのマイクをまだ確認する必要があります。EAPフェーズがEAP.Failureメッセージで終了した場合、サーバーとピアは、無効であると配信された和らげを考慮する必要があります。したがって、ピアは、次にサーバーで認証しようとするときにこの一時的なものを使用してはなりません。
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.
ピアが所有する可能性のあるアイデンティティの種類は、それぞれ許可された一時的なアイデンティティであり、それぞれ許可された一時的なアイデンティティです。許可は、ルートの秘密に関連するNAIであり、長寿命です。一時的なものは、EAPメソッドを介して生成された識別子であり、ピアはサーバーとのその後のEAPセッション中に自分自身を識別するために使用できることです。一時的な目的は、ユーザーの匿名のサポートを許可することです。温度の使用は、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:
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_ANY_ID_REQを使用して、タイプ酒およびサブタイプIDの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. ピアは、ピア識別子を含む属性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/sase/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:
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
図5.サーバーには、ピアアイデンティティとして温度が与えられます。サーバーには許可が必要です
1. The Peer (or the Authenticator on behalf of the Peer) sends an EAP.Request message of type Identity and includes the TempID.
1. ピア（またはピアに代わって認証者）は、タイプIDの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. サーバーは代わりに許可を必要とするため、属性AT_PERM_ID_REQおよびAT_SERVERIDを使用して、タイプ酒およびサブタイプIDの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. ピアは、ピア許可を運ぶ属性AT_PEERIDを含むタイプの酒およびサブタイプのアイデンティティのEAP.RESPONSEメッセージを送信します。
EAP-SAKE uses a three-level key hierarchy.
EAPセイクは、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には、ルートシークレットと呼ばれる事前に共有された秘密が含まれています。これは、ルートセクレットAパーツ（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には、The Case Master Secret（SMS）と呼ばれるキー派生キーが含まれています。SMS-Aは、root-secret-aキーと、EAPセイクキー駆除関数（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メソッドのみにローカルを使用するためのキーです。それらは、EAPセイクKDFを使用してSMS-AとNoncesから派生しています。それらは、MICの計算に使用される16バイトのTek-Authと、選択した属性を暗号化するために使用される16バイトのTek-Cipherに分割されます。SMSは新鮮であるため、派生したTeksもそうです。
+--------------------+ +--------------------+
| 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
図6. EAPセイク法の重要な階層
On another branch of level 3 of the key hierarchy are the MSK and EMSK, each mandated to be 64 bytes long. They are derived from the SMS-B and the nonces using the EAP-SAKE KDF. Again, since the SMS is fresh, so are the derived MSK/EMSK. The MSK is meant to be exported and relayed to other parties. The EMSK is reserved for future use, such as derivation of application-specific keys, and is not shared with other parties.
主要な階層のレベル3の別のブランチには、それぞれが64バイトの長さであることが義務付けられているMSKとEMSKがあります。それらは、EAPセイクKDFを使用してSMS-BとNoncesから派生しています。繰り返しますが、SMSは新鮮であるため、派生したMSK/EMSKもそうです。MSKは、他の関係者に輸出され、中継することを目的としています。EMSKは、アプリケーション固有のキーの導出など、将来の使用のために予約されており、他の当事者と共有されていません。
The EAP-SAKE key material is summarized in the table below.
EAPセイクキーマテリアルは、下の表にまとめられています。
===================================================================
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セイクは、高速な再認証をサポートしていないため、TEKの寿命は次のEAP相互認証までのみ延長することです。MSKの生涯は、次の相互認証がいつ行われるかを決定します。サーバーは、AT_MSK_LIFE属性のPEERにMSK Lifetimeをパイアに伝えることができます。EAPセイクは、重要な生涯交渉をサポートしていないことに注意してください。
The EAP-SAKE Method-Id is the contents of the RAND_S field from the AT_RAND_S attribute, followed by the contents of the RAND_P field in the AT_RAND_P attribute.
EAP-Sake Method-IDは、AT_RAND_S属性のRAND_Sフィールドの内容であり、AT_RAND_P属性のRAND_Pフィールドの内容が続きます。
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セイクキー駆付関数を示します。この関数は、[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つの文字列を使用します。キー、ラベル、およびMSGを使用し、次のように長さxバイトから文字列を出力します。
Out = KDF-X (Key, Label, Msg) 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.
out = kdf-x（key、label、msg）kdfは、キー「キー」を備えたキー付きハッシュ関数であり、入力「ラベル| msg」で動作します。ここで続く規則は、連結が|で示されることです、床は床関数を示し、[x ... y]はバイトxから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文字列です。これは、長さのバイトまたは末尾のnull文字なしで与えられた正確な形式に含まれています。
Below, "Length" denotes a single unsigned octet with values between 0 and 255 (bytes). The following functions are defined (see [HMAC], [SHA1]):
以下では、「長さ」は、0〜255（バイト）の値を持つ単一の符号なしのオクテットを示します。次の機能が定義されています（[hmac]、[sha1]を参照）：
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)
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)]
The Peer and Server derive the SMS and then the TEK as follows:
ピアとサーバーは、次のようにSMSを導き出し、次のようにテックを導き出します。
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（root-secret-a、 "dase 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]
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（root-secret-b、 "dase 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]
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.
ciphersuiteは、セキュリティパラメーターインデックス（SPI）と呼ばれる数値によって識別されます。SPIは、EAPセイクメソッドで使用されており、EAPデータ保護のみのためにピアとサーバーの間のciphersuiteを交渉するために使用しています。明らかに、このciphersuiteは、ピアとサーバーの両方によって合意された後、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メソッドはこのciphersuiteを使用する必要がある場合と必要な場合があります。たとえば、一時的な識別子をピアに配信し、暗号化する必要がある場合、このタスクには交渉されたCiphersuiteが使用されます。暗号化がピアに渡されるときに必要な属性がない場合、このciphersuiteは使用されません。
As with most other methods employing ciphersuite negotiation, the following exchange is employed: the Peer sends an ordered list of one or more supported ciphersuites, starting with the most preferred one, in a field SPI_P. The Server then sends back the one ciphersuite chosen in a field SPI_S. The Server SHOULD choose the strongest ciphersuite supported by both of them.
Ciphersuiteの交渉を採用している他のほとんどの方法と同様に、次の交換が採用されています。ピアは、フィールドSPI_Pで、最も好まれたものから始まる1つ以上のサポートされているシファースーツの順序付けられたリストを送信します。サーバーは、フィールドSPI_Sで選択した1つのciphersuiteを送り返します。サーバーは、両方でサポートされている最強のCiphersuiteを選択する必要があります。
Ciphersuite negotiation for data protection is achieved via SAKE Signaling as follows. In the EAP.Response/SAKE/Challenge, the Peer sends a list of supported ciphersuites, SPI_P, and protects that with a MIC. In the EAP.Request/SAKE/Confirm, the Server sends one selected ciphersuite, SPI_S, and signs that with a MIC. Finally, the Peer confirms the selected ciphersuite and readiness to use it in a signed EAP.Response/SAKE/Confirm message. The negotiation is secure because of the Message Integrity Checks that cover the entire EAP message.
データ保護のためのCiphersuite交渉は、次のように日本酒シグナリングを介して達成されます。EAP.Response/Say/Challengeでは、ピアはサポートされているCiphersuites、SPI_Pのリストを送信し、マイクで保護します。eap.request/sase/confismでは、サーバーは選択した1つのciphersuite、spi_sを送信し、マイクで標識を送信します。最後に、ピアは、選択したciphersuiteと準備が整っていることを確認し、署名されたeap.response/sase/confismメッセージで使用します。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.
このセクションでは、メッセージの整合性と属性暗号化に使用されるEAP/日本酒属性を指定します：at_mic_s、at_mic_p、at_iv、at_encr_data、およびat_paddingを指定します。AT_MIC_SとAT_MIC_Pのみが、EAPセイク交換中に使用することが必須です。
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は、nonces rand_sおよびrand_pを使用して導出されるため、at_mic_sおよびat_mic_p属性は、eap.response/say/cholangeメッセージとその後送信されるメッセージでのみ使用できます。
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セイクメッセージの整合性に使用されます。AT_MIC_S属性は、キーマテリアル（TEK）が導出されるたびにサーバーが送信するすべてのEAPセイクパケットに含める必要があります。つまり、AT_MIC_S属性はEAP.Request/Say/Confismメッセージに含める必要があります。AT_MIC_Sは、eap.request/sase/challengeメッセージ、またはeap.request/sase/itfenteメッセージに含めてはなりません。
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属性は、キーマテリアル（TEK）が導出されるたびにピアが送信するすべてのEAPセイクパケットに含める必要があります。つまり、AT_MIC_P属性は、EAP.Response/Says/ChallengeおよびEAP.Response/Sase/確認メッセージに含める必要があります。
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.
AT_MIC_P属性は、ピアがサーバーと同じTEKを持っていることを確認していないため、EAP.RESPONSE/SATY-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を計算するときにゼロに設定されます。サーバーとピアのNONCESおよび識別子を含めると、リプレイと中間の攻撃の検出に役立ちます。
The Peer computes its MIC as follows:
ピアは次のようにマイクを計算します：
MIC_P = KDF-16 (TEK-Auth, "Peer MIC", RAND_S | RAND_P | PEERID | 0x00 | SERVERID | 0x00 | <EAP-packet>),
mic_p = kdf-16（tek-auth、 "Peer Mic"、rand_s | rand_p | peerid | 0x00 | serverid | 0x00 | <eap-packet>）、
while the Server computes its MIC as
サーバーがマイクを計算します
MIC_S = KDF-16 (TEK-Auth, "Server MIC", RAND_P |RAND_S | SERVERID | 0x00 | PEERID | 0x00 | <EAP-packet>).
mic_s = kdf-16（tek-auth、 "server mic"、rand_p | rand_s | serverId | 0x00 | peerid | 0x00 | <eap-packet>）。
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-packet>は、バイトの文字列として使用されるEAPパケット全体、マイク値フィールドがゼロに設定されていることを示します。0x00は、ServerIDとPeerIDを区切るために使用される単一のオクテット値を示します。PeeridとserverIDは、それぞれ、日本酒/挑戦メッセージの対応する属性に携帯されているものです。
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/Request/日本酒/アイデンティティメッセージが先行する場合、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が酒/挑戦メッセージまたは日本酒/アイデンティティメッセージのいずれにも含まれていない場合、MIC_PとMIC_Sの計算で使用されるServerIDの値は空でなければなりません。AT_PEERIDが日本酒/チャレンジメッセージに含まれておらず、日本酒/チャレンジメッセージの前にResponse/日本酒/アイデンティティメッセージがなかった場合、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-Authの所有を検証できるようにします。ただし、AT_SERVERIDはサーバーによってマイクで明示的に署名されていないため、EAPセイクはチャネル結合を主張しません。
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の値フィールドには、使用された暗号化アルゴリズムで必要な場合、初期化ベクトル（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.
属性は、Ciphersuiteが合意された後にのみ暗号化できます。つまり、サーバーのEAP.Request/Sase/確認メッセージから始まるメッセージで。属性は、AT_SPI_S属性によって指定されたSPI値に対応するアルゴリズムを使用して暗号化する必要があります。属性は、セクション3.2.6.2で派生が指定されているTek-Cipherキーを使用して暗号化する必要があります。
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).
The value field of the AT_ENCR_DATA attribute consists of bytes encrypted using the ciphersuite specified in the AT_SPI_S attribute. The encryption key is the TEK-Cipher, and the plaintext consists of one or more concatenated EAP-SAKE attributes.
AT_ENCR_DATA属性の値フィールドは、AT_SPI_S属性で指定されたCipherSuiteを使用して暗号化されたバイトで構成されています。暗号化キーはTek-Cipherであり、平文は1つ以上の連結EAPセイク属性で構成されています。
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属性の長さには、属性タイプと属性の長さフィールドが含まれます。値フィールドの実際のパッドバイトは、送信時にゼロ（0x00）に設定されています。メッセージの受信者は、パッドバイトが復号化後にゼロであることを確認する必要があり、それ以外の場合はメッセージを静かに破棄する必要があります。
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.
The default encryption algorithm AES-CBC involves the AES block cipher [AES] in the Cipher-Block-Chaining (CBC) mode of operation [CBC].
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セイク方法のピアは、SPI_Pフィールドに最大4つのSPI値を送信できます。AT_SPI_PおよびAT_SPI_S属性の長さはそれぞれ2バイトの倍数でなければならないため、送信者は必要に応じてゼロバイトの値フィールドにパッドをパッドします（AT_PADDING属性はここでは使用されません）。たとえば、AT_SPI_Sの値フィールドには、選択したSPIの1つのバイトが含まれ、その後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セイク方法は、メッセージが過度に長くなっていないため、断片化を必要としません。つまり、EAPパケットは、他のレイヤー（リンク、ネットワーク）の最大送信ユニットの制限内にあります。唯一の変数フィールドは、NAIを運ぶもので、長さのフィールドによって256バイトに制限されています。
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セイクパケットを受信した場合、実装はこのパケットを静かに破棄し、状態を変更するのではなく、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を一致させないセッションIDフィールドを備えたEAPセイクパケットを受信した場合、そのエンティティはこのパケットを静かに破棄する必要があります（最初のメッセージには適用されませんEAPセイクセッション）。
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：サーバーは、日本酒/挑戦の前にEAP-SUCSESSメッセージを送信してはなりません。ピアがEAP.response/say/sampingパケットを介してサーバーを正常に認証する前に、ピアは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メッセージに一致する必要があるサーバーによって新たに生成される必要がある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セイクサブタイプ：酒/挑戦、酒/確認、日本酒/認証、酒/アイデンティティ。これらのサブタイプではないタイプ「EAPセイク」のすべてのメッセージは、静かに破棄する必要があります。
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バイト）のタイプ長価値形式に従います。長さのフィールドはオクテットにあり、タイプと長さのフィールドの長さが含まれます。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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
1-byte unsigned integer; see Table below.
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:
eap.request/sase/confismメッセージで使用されるAT_ENCR_DATA属性の例を以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_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/Say/Challengeパケットの形式を以下に示します。
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セイク
Version
バージョン
2
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.
この属性の値フィールドには、サーバーNonce RAND_Sパラメーターが含まれています。rand_s属性は、eap.request/sase/challengeに存在する必要があります。
AT_SERVERID
AT_SERVERID
The value field of this attribute contains the Server identifier (e.g., a non-null terminated string). The AT_SERVERID attribute SHOULD be present in EAP.Request/SAKE Challenge.
この属性の値フィールドには、サーバー識別子（例：非ヌル終端文字列）が含まれます。AT_SERVERID属性は、EAP.Request/Case Challengeに存在する必要があります。
The format of the EAP.Response/SAKE/Challenge packet is shown below.
EAP.Response/Say/Challengeパケットの形式を以下に示します。
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セイク
Version
2
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.
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が含まれています。ピアアイデンティティは、EAP.Response/ID、つまりNAI Realm部分を含む同じネットワークアクセス識別子形式に従います。アイデンティティは、永続的なアイデンティティ、または一時的なアイデンティティです。アイデンティティには、終了したnull文字が含まれません。AT_PEERID属性は、EAP.Response/Says/Challengeでオプションです。
AT_SPI_P
at_spi_p
The value field of this attribute contains the Peer's ciphersuite list SPI_P parameter. The AT_SPI_P attribute is optional in the EAP.Response/SAKE/Challenge.
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/sase/Challengeに存在する必要があります。
The format of the EAP.Request/SAKE/Confirm packet is shown below.
EAP.Request/Says/Confienパケットの形式を以下に示します。
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セイク
Version
バージョン
2
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.
この属性の値フィールドには、選択されたサーバーCiphersuite SPI_Sパラメーターが含まれています。AT_SPI_S属性は、eap.request/sase/confirmでオプションです。
AT_IV
AT_IV
This attribute is optional to use in this message. The value field of this attribute contains the Initialization Vector that is used with the encrypted data following.
この属性は、このメッセージで使用するためにオプションです。この属性の値フィールドには、暗号化されたデータフォローで使用される初期化ベクトルが含まれます。
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.
この属性の値フィールドには、サーバーMIC_Sパラメーターが含まれます。AT_MIC_S属性は、eap.request/sase/confirmに存在する必要があります。
The format of the EAP.Response/SAKE/Confirm packet is shown below.
EAP.response/sase/confienパケットの形式を以下に示します。
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セイク
Version
バージョン
2
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/sase/confirmに存在する必要があります。
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/Says/Auth-Rejectパケットの形式を以下に示します。
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セイク
Version
バージョン
2
2
Session ID
セッションID
A number matching all other EAP messages in this EAP session.
このEAPセッションの他のすべてのEAPメッセージと一致する数字。
Subtype
サブタイプ
3 for SAKE/Auth-Reject
The format of the EAP.Request/SAKE/Identity is shown below.
EAP.Request/Says/Identityの形式を以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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セイク
Version
バージョン
2
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属性はオプションであり、サーバーがパーアに永続的な識別子を与えることを要求する場合（つまり、許可されています）。AT_ANY_ID_REQ属性が含まれている場合、AT_PERM_ID_REQを含めてはなりません。値フィールドには、予約された2つのバイトのみが含まれており、送信時にゼロに設定され、受信で無視されます。
AT_ANY_ID_REQ
at_any_id_req
The AT_ANY_ID_REQ attribute is optional, to be included in cases where the Server requires the Peer to send any identifier (e.g., PermID, TempID). The AT_ANY_ID_REQ MUST NOT be included if AT_PERM_ID_REQ is included. The value field only contains two reserved bytes, which are set to zero on sending and ignored on reception. One of the AT_PERM_ID_REQ and AT_ANY_ID_REQ MUST be included.
AT_ANY_ID_REQ属性はオプションであり、サーバーが識別子を送信するためにピアが必要な場合（たとえば、許可、温度）。AT_PERM_ID_REQが含まれている場合、AT_ANY_ID_REQを含めてはなりません。値フィールドには、予約された2つのバイトのみが含まれており、送信時にゼロに設定され、受信で無視されます。AT_PERM_ID_REQおよびAT_ANY_ID_REQの1つを含める必要があります。
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/Say/Identityに含めることをお勧めします。
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セイク
Version
バージョン
2
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/sase/Identityに存在する必要があります。
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/IDとEAP.Response/IDパケットの形式は[EAP]で説明されています。このパケットには、ユーザーID（NAIなど）が存在する必要があります。
The format of the EAP-Success and EAP-Failure packet is also shown in [EAP].
EAP-SUCSESSおよびEAP-Failureパケットの形式は[EAP]にも表示されます。
IANA allocated a new EAP Type for EAP-SAKE.
IANAは、EAPセイク用の新しい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セイクメッセージには、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ビットタイプ番号を持つ属性で構成されています。範囲0〜127内で番号が付けられた属性は、非スキップ可能な属性と呼ばれ、128〜255の範囲内の属性はskippable属性と呼ばれます。EAPセイク属性タイプ番号は、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].
[IANA]で説明されている「必要な仕様」ポリシーに従って、このメモで説明されている2つの数値スペースからの価値割り当てのすべての要求が適切なドキュメントを必要とします。
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-Sakeはトンネリング方法ではないため、EAP.Response/Says/Auth-Reject、EAP.Success、およびEAP.Failureパケットは、完全性またはリプレイ保護されていません。これにより、攻撃者がそのようなメッセージを吹き飛ばすことができます。認証障害はサーバーとピアが共通のキーに同意しないことを示すため、EAP.Response/Says/Auth-Rejectは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セイクを使用した相互認証と主要な施設が妥協されます。
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セイクは、ルートシークレットがどのように生成またはサーバーとピアに分配されるかについては対処しません。根の秘密のエントロピーを最大化することをお勧めします。ルートの秘密は機械で生成する必要があります。
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セイクメッセージの数のログを維持する必要があります。これらの場合、ルートシークレットを安全に更新する手順が整っている必要があります。
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.
相互認証は、酒/挑戦と酒/確認メッセージによって達成されます。EAP.Request/Says/Challengeには、サーバーNonce RAND_Sが含まれています。EAP.Response/Says/Challengeには、ピアマイク（MIC_P）とともに、ピアノンセRAND_Pが含まれています。eap.request/sase/confirnには、サーバーマイク（MIC_S）が含まれています。両方のMICS（MIC_SとMIC_P）は、nonces rand_sとrand_pの両方を使用して計算され、ルートシークレットから派生した共有秘密であるtekによってキーが付けられています。サーバーは、コンピューターを計算するMIC_Pがピアが送信するものと一致する場合、ピアを認証したと見なします。同様に、ピアは、それが計算するMIC_Sがサーバーが送信するものと一致する場合、サーバーが認証されたサーバーを考慮します。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セイクメッセージの整合性保護は、メッセージ整合性チェック（MIC）を使用することで達成されます。これは、共通共有秘密（TEK）が利用可能になるとすぐに、つまりEAP.Request/日本酒/挑戦。敵は、受信者がマイク障害に遭遇することなく、マイクで保護されたメッセージを変更することはできません。整合性保護の程度は、MICの導出に使用されるKDFのセキュリティ、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/Say/Challengeメッセージの結果、ピアはEAP.Response/Chagence/Challengeメッセージを送信します。これは、Tek-Authキーの妥協に対する最小限のリスクをもたらします。この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セイク/チャレンジリクエストパケットに続いて各パケットに存在するマイクの計算に含まれるセッション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セッション内のリプレイ保護は、MICを介して達成されます。マイクは、EAPパケット全体（セッションIDを含む）だけでなく、nonces rand_sとrand_pもカバーしています。したがって、EAPメッセージの受信者は、受け取ったメッセージは、受信者のNONCEと他のピアNONCEの有効なマイクが含まれているため、リプレイではなく、他のピアから送信されたメッセージであることを保証できます。前と同様に、リプレイ保護の範囲は、MICの導出に使用されるKDFのセキュリティ、KDFが使用する共有秘密の長さとエントロピー、およびMICの長さに見合っています。
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 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使用のため）とマスターセッションキー、およびTeksなどの他の低レベルのキーを導き出します。一部の低レベルのキーの一部が使用される場合と使用されていない場合があります。これらすべてのキーの強度（エントロピー）は、せいぜい根の秘密の強さです。
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.
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セイクメソッドにマウントするのに不可能です。代わりに、ルートの秘密は機械で生成されます。これは必ずしもプロビジョニングの問題を引き起こすわけではありません。
Resistance to man-in-the-middle attacks is provided through the integrity protection that each EAP message carries (i.e., Message Integrity Check field) as soon as a common key for this EAP session has been derived through mutual authentication. As before, the extent of this resistance is commensurate with the strength of the MIC itself. Man-in-the-middle attacks associated with the use of any EAP method within a tunneling or sequencing protocol are beyond the scope of this document.
このEAPセッションの共通キーが相互認証を通じて導き出されるとすぐに、各EAPメッセージが伝える（つまり、メッセージの整合性チェックフィールド）が伝える（つまり、メッセージの整合性チェックフィールド）が、各EAPメッセージが伝達する整合性保護を通じて、中間攻撃に対する抵抗が提供されます。前と同様に、この抵抗の程度は、マイク自体の強度と見なされます。トンネリングまたはシーケンスプロトコル内のEAPメソッドの使用に関連する中間攻撃は、このドキュメントの範囲を超えています。
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セイクは、結果の表示、完全性保護、およびリプレイ保護を提供するという点で、結果の表示保護を提供します。サーバーは、EAP.Request/Say/Confismメッセージを送信することにより、ピアを正常に認証したことを示しています。ピアは、eap.response/sase/confismメッセージを送信することにより、サーバーを正常に認証したことを示します。
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.
TEKは、EAPセイクパケット（Tek-Auth、Tek-Cipher）、マスターセッションキー、および拡張マスターセッションキーを保護するために使用されていました。これらのキーに関する情報は、他のキーに関する情報につながるわけではありません。また、TEK、MSK、またはEMSKのいずれかまたはすべてからルートシークレットを計算することは実行不可能であることに注意してください。
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セイク交換のために新鮮な乱数（つまり、nonces）を生成する必要があります。いずれかのエンティティが前のセッションから乱数を再利用した場合、他の人が新たに生成された乱数を使用するという事実は、このセッション内で導出された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.
したがって、1つの交換での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で署名されます。したがって、盗聴者は、ピアが最初に（たとえば、パワーアップ時に）送信する元の許可をリンクすることはできません。
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.
サーバーとピアは、ピアパーマネントアイデンティティを使用する1つの初期EAPセイクフェーズの後に、一時的なアイデンティティのみが交換されるように構成される場合があります。この場合、最大のアイデンティティ保護を実現するには、温度をピアとサーバーの不揮発性メモリに保存する必要があります。したがって、このドキュメントへのコンプライアンスは、ピアの生涯にわたってピアアイデンティティ保護を排除または義務付けていません。
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.
サーバー識別子とピア識別子は、酒/挑戦メッセージで送信される場合があります。ただし、最初のメッセージの時点で確立された認証キーがないため、サーバー識別子はここで整合性で保護されていません。
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セイクフェーズ中に交換されるすべての後続のEAPセイクメッセージは、メッセージ整合性チェック（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.
This negotiation is secure because of the Message Integrity Checks (MICs) that cover the entire EAP messages used for ciphersuite negotiation (see Section 3.2.7.). The extent of the security of the negotiation is commensurate with the security of the KDF used to derive the MICs, the length and entropy of the shared secret used by the KDF, and the length of the MICs.
この交渉は、Ciphersuiteの交渉に使用されるEAPメッセージ全体をカバーするメッセージの整合性チェック（MIC）のために安全です（セクション3.2.7を参照）。交渉のセキュリティの程度は、MICS、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セイクは、32バイトのルートシークレットからのキー派生をサポートします。それから導出された他のすべてのキーのエントロピーは、キー付きハッシュ関数（KDFなど）を使用することにより多少削減されます。したがって、ルートシークレットの有効なキー強度が32バイトであると楽観的に仮定すると、導出されたキーの有効なキー強度は、最大16バイトのemskから得られるルートシークレット量の有効なキー強度です。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)
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-Makeは提供しません。
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/ drafts/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.、Blunk、L.、Vollbrecht、J.、Carlson、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.、Bellare、M。、およびR. Canetti、「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：メディアアクセス制御（Mac）セキュリティ強化」、2004年6月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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、「Secure Hash Standard」、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] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
Authors' Addresses
著者のアドレス
Michaela Vanderveen Qualcomm Flarion Technologies 135 Rte. 202/206 South Bedminster, NJ 07921 USA
Michaela Vanderveen Qualcomm Flarion Technologies 135 Rte。202/206サウスベッドミンスター、ニュージャージー州07921 USA
EMail: mvandervn@yahoo.com
Hesham Soliman Qualcomm Flarion Technologies 135 Rte. 202/206 South Bedminster, NJ 07921 USA
Hesham Soliman Qualcomm Flarion Technologies 135 Rte。202/206サウスベッドミンスター、ニュージャージー州07921 USA
EMail: solimanhs@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。