Network Working Group M. Vanderveen
Request for Comments: 4763 H. Soliman
Category: Informational Qualcomm Flarion Technologies
November 2006
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-SAKE）
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
IESG Note
IESG注释
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
本RFC不适用于任何级别的互联网标准。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.
本文档指定了用于共享秘密身份验证和密钥建立（SAKE）的可扩展身份验证协议（EAP）机制。根据RFC 3748，本RFC作为供应商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
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
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、公钥、一次性密码、TLS等。本文档定义了一个身份验证方案，称为EAP-SAKE。EAP-SAKE支持基于静态预共享秘密数据的相互认证和会话密钥推导。根据RFC 3748，本RFC作为供应商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].
在本文件中，使用了几个词来表示规范的要求。这些词通常大写。本文件中的关键词“必须”、“不得”、“必需”、“必须”、“不得”、“应该”、“不应该”、“建议”、“可能”和“可选”应按照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
短信主密钥
NAI Network Access Identifier
网络访问标识符
The EAP-SAKE authentication protocol is a native EAP authentication method. That is, a stand-alone version of EAP-SAKE outside of EAP is not defined. EAP-SAKE is designed to enable mutual authentication, based on pre-shared keys and well-known public cryptographic algorithms. This method is ideal for subscription-based public access networks, e.g., cellular networks.
EAP-SAKE认证协议是一种本机EAP认证方法。也就是说，没有定义EAP之外的EAP-SAKE的独立版本。EAP-SAKE旨在基于预共享密钥和众所周知的公共密码算法实现相互认证。该方法非常适用于基于订阅的公共接入网络，例如蜂窝网络。
EAP-SAKE assumes a long-term or pre-shared secret known only to the Peer and the Server. This pre-shared secret is called the Root Secret. The Root Secret consists of a 16-byte part Root-Secret-A, and 16-byte part Root-Secret-B. The Root-Secret-A secret is reserved for use local to the EAP-SAKE method, i.e., to mutually authenticate the EAP Peer and EAP Server. The Root-Secret-B secret is used to derive other quantities such as the Master Session Key (MSK) and Extended Master Session Key (EMSK). Root-Secret-B and Root-Secret-A MUST be cryptographically separate.
EAP-SAKE假定只有对等方和服务器知道长期或预先共享的秘密。这个预先共享的秘密称为根秘密。根秘密由16字节部分的根秘密-a和16字节部分的根秘密-B组成。根秘密-a秘密保留用于EAP-SAKE方法的本地使用，即相互认证EAP对等方和EAP服务器。Root-Secret-B Secret用于导出其他量，例如主会话密钥（MSK）和扩展主会话密钥（EMSK）。Root-Secret-B和Root-Secret-A必须以加密方式分开。
When a Backend Authentication Server is used, the Server typically communicates with the Authenticator using an AAA protocol. The AAA communications are outside the scope of this document.
当使用后端身份验证服务器时，服务器通常使用AAA协议与身份验证程序通信。AAA通信不在本文件范围内。
Some of the advantages of EAP-SAKE are as follows:
EAP-SAKE的一些优点如下：
o It is based on well-established Bellare-Rogaway mutual authentication protocol.
o 它基于成熟的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 它只使用两个请求/响应交换。
o It relies on the (corrected) IEEE 802.11i function for key derivation and message integrity. This way a device implementing a lower-layer secure association protocol compliant with IEEE 802.11i standard will not need additional cryptographic code.
o 它依赖于（已更正的）IEEE 802.11i函数进行密钥派生和消息完整性。这样，实现符合IEEE 802.11i标准的低层安全关联协议的设备将不需要额外的密码。
o Its encryption algorithm is securely negotiated (with no extra messages), yet encryption use is optional.
o 它的加密算法是安全协商的（没有额外的消息），但加密使用是可选的。
o Keys used for authentication and those used for encryption are cryptographically separate.
o 用于身份验证的密钥和用于加密的密钥在加密方面是分开的。
o User identity anonymity can be optionally supported.
o 可以选择支持用户身份匿名。
o No synchronization (e.g., of counters) needed between server and peer.
o 服务器和对等机之间不需要同步（例如计数器）。
o There is no one-time key pre-processing step.
o 没有一次性按键预处理步骤。
EAP-SAKE uses four messages consisting of two EAP request/response exchanges. The EAP.Success and EAP.Failure messages shown in the figures are not part of the EAP-SAKE method. As a convention, method attributes are named AT_XX, where XX is the name of the parameter the attribute value is set to.
EAP-SAKE使用由两个EAP请求/响应交换组成的四条消息。图中显示的EAP.Success和EAP.Failure消息不是EAP-SAKE方法的一部分。按照惯例，方法属性在_XX处命名，其中XX是属性值设置为的参数的名称。
A successful EAP-SAKE authentication exchange is depicted in Figure 1. The following steps take place:
图1描述了一个成功的EAP-SAKE身份验证交换。执行以下步骤：
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 |<---------------------------------------------------------|
| |
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-SAKE认证程序（带密码套件协商）
1. The EAP server sends the first message of the EAP-SAKE exchange. This message is an EAP.Request message of type SAKE and subtype Challenge. The EAP.Request/SAKE/Challenge message contains the attributes: AT_RAND_S, whose value is a nonce freshly generated
1. EAP服务器发送EAP-SAKE交换的第一条消息。此消息是类型为SAKE和子类型为Challenge的EAP.Request消息。EAP.Request/SAKE/Challenge消息包含以下属性：AT_RAND_S，其值为新生成的nonce
by the Server; and AT_SERVERID, which carries an identifier of the Server (a fully qualified domain name, such as the realm of the user NAI [NAI]). The AT_SERVERID attribute is OPTIONAL but SHOULD be included in this message. The purpose of the AT_SERVERID is to aid the Peer in selecting the correct security association (i.e., Root-Secret, PEERID, and SERVERID) to use during this EAP phase.
通过服务器；以及AT_SERVERID，它携带服务器的标识符（完全限定的域名，如用户NAI[NAI]的领域）。AT_SERVERID属性是可选的，但应包含在此消息中。AT_SERVERID的目的是帮助对等方选择在EAP阶段使用的正确安全关联（即Root Secret、PEERID和SERVERID）。
2. The Peer responds by sending an EAP.Response message of type SAKE and subtype Challenge. The EAP.Response/SAKE/Challenge message contains the attributes: AT_RAND_P, which carries a nonce freshly generated by the Peer; AT_PEERID, which carries a Peer identifier; AT_SPI_P, which carries a list of one or more ciphersuites supported by the Peer; and AT_MIC_P, containing a message integrity check. The AT_SPI_P and AT_PEERID attributes are OPTIONAL. The AT_PEERID attribute SHOULD be included, in order to cover the case of multi-homed hosts. A supported ciphersuite is represented by a value local to the EAP-SAKE method, or "Security Parameter Index", see section 3.2.8.3. The Peer uses both nonces, along with the Root-Secret-A key, to derive a SAKE Master Secret (SMS) and Temporary EAP Keys (TEKs), which also include the TEK-Auth and TEK-Cipher keys. The MIC_P value is computed based on both nonces RAND_S and RAND_P, and the entire EAP packet, using the key TEK-Auth, see Section 3.2.6.
2. 对等方通过发送类型为SAKE和子类型Challenge的EAP.Response消息进行响应。EAP.Response/SAKE/Challenge消息包含以下属性：AT_RAND_P，它携带由对等方新生成的nonce；AT_PEERID，携带对等标识符；AT_SPI_P，其中包含对等方支持的一个或多个密码套件的列表；和AT_MIC_P，包含消息完整性检查。AT_SPI_P和AT_PEERID属性是可选的。应包括AT_PEERID属性，以涵盖多宿主主机的情况。受支持的密码套件由EAP-SAKE方法的本地值或“安全参数索引”表示，请参见第3.2.8.3节。对等方使用这两个nonce以及Root-Secret-A密钥来派生SAKE主密钥（SMS）和临时EAP密钥（TEK），其中还包括TEK Auth和TEK密码密钥。MIC_P值是基于随机数RAND_S和RAND_P以及整个EAP数据包，使用密钥TEK Auth计算的，见第3.2.6节。
3. Upon receipt of the EAP.Response/SAKE/Challenge message, the Server uses both nonces RAND_S and RAND_P, along with the Root-Secret-A key, to compute the SMS and TEK in exactly the same way the Peer did. Following that, the Server computes the Peer's MIC_P in exactly the same way the Peer did. The Server then compares the computed MIC_P with the MIC_P it received from the Peer. If they match, the Server considers the Peer authenticated. If encryption is needed, the Server selects the strongest ciphersuite from the Peer's ciphersuite list SPI_P, or a suitable ciphersuite if the Peer did not include the AT_SPI_P attribute. The Server sends an EAP.Request message of type SAKE and subtype Confirm, containing the attributes: AT_SPI_S, carrying the ciphersuite chosen by the Server; AT_ENCR_DATA, containing encrypted data; and AT_MIC_S, carrying a message integrity check. The AT_SPI_S and AT_ENCR_DATA are OPTIONAL attributes, included if confidentiality and/or user identity anonymity is desired. Other OPTIONAL attributes that MAY be included are AT_NEXT_TMPID, and AT_MSK_LIFE. As before, the MIC_S value is computed using both nonces RAND_S and RAND_P, and the entire EAP packet, using the key TEK-Auth.
3. 在收到EAP.Response/SAKE/Challenge消息后，服务器使用nonce RAND_S和RAND_P以及Root-Secret-A密钥，以与对等方完全相同的方式计算SMS和TEK。然后，服务器以与对等方完全相同的方式计算对等方的MIC_P。然后，服务器将计算出的MIC_P与从对等方接收到的MIC_P进行比较。如果它们匹配，服务器将认为对等方已通过身份验证。如果需要加密，服务器将从对等方的密码套件列表SPI_P中选择最强的密码套件，如果对等方未包含AT_SPI_P属性，则选择合适的密码套件。服务器发送类型为SAKE和子类型为Confirm的EAP.Request消息，其中包含以下属性：AT_SPI_S，携带服务器选择的密码套件；AT_ENCR_数据，包含加密数据；在MIC_S，携带信息完整性检查。AT_SPI_和AT_ENCR_数据是可选属性，如果需要保密性和/或用户身份匿名性，则包括这些属性。可能包括的其他可选属性包括AT_NEXT_TMPID和AT_MSK_LIFE。与前面一样，MIC_S值是使用nonce 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/SAKE/Confirm消息，指示服务器成功验证，则对等方将以与服务器相同的方式计算麦克风。然后，对等方将接收到的麦克风与其计算出的麦克风进行比较。如果它们匹配，对等方将认为服务器已通过身份验证，并发送类型为SAKE和子类型为Confirm的EAP.Response消息，其属性位于\u MIC\u P，包含消息完整性检查，计算方式与前面相同。
5. After a successful EAP-SAKE exchange, the Server concludes the EAP conversation by sending an EAP.Success message to the Peer.
5. EAP-SAKE交换成功后，服务器通过向对等方发送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-SAKE消息都包含会话ID，该ID由服务器选择，在第一条消息中发送，并在后续消息中复制，直到发送EAP.Success或EAP.Failure。收到EAP-SAKE消息后，对等方和服务器都必须检查消息的格式，以确保消息格式正确，并且包含有效的会话ID。
Note that the Session ID is introduced mainly for replay protection purposes, as it helps uniquely identify a session between a Peer and a Server. In most cases, there is a one-to-one relationship between the Session ID and the Peer/Server pair.
请注意，引入会话ID主要是为了重播保护目的，因为它有助于唯一标识对等方和服务器之间的会话。在大多数情况下，会话ID和对等/服务器对之间存在一对一的关系。
The parameters used by the EAP-SAKE method are summarized in the table below:
EAP-SAKE方法使用的参数汇总如下表所示：
Name Length (bytes) Description
---------+---------------+-------------
RAND_P 16 Peer nonce
RAND_S 16 Server nonce
MIC_P 16 Peer MIC
MIC_S 16 Server MIC
SPI_P variable Peer ciphersuite preference(s)
SPI_S variable Server chosen ciphersuite
PEERID variable Peer identifier
SERVERID variable Server identifier (FQDN)
Name Length (bytes) Description
---------+---------------+-------------
RAND_P 16 Peer nonce
RAND_S 16 Server nonce
MIC_P 16 Peer MIC
MIC_S 16 Server MIC
SPI_P variable Peer ciphersuite preference(s)
SPI_S variable Server chosen ciphersuite
PEERID variable Peer identifier
SERVERID variable Server identifier (FQDN)
If the Authenticator receives an EAP.Failure message from the Server, the Authenticator MUST terminate the connection with the Peer immediately.
如果验证器从服务器接收到EAP.Failure消息，则验证器必须立即终止与对等方的连接。
The Server considers the Peer to have failed authentication if either of the two received MIC_P values does not match the computed MIC_P.
如果接收到的两个MIC_P值中的任何一个与计算出的MIC_P不匹配，服务器将认为对等方身份验证失败。
The Server SHOULD deny authorization for a Peer that does not advertise any of the ciphersuites that are considered acceptable (e.g., by local system policy) and send an EAP.Failure message.
服务器应拒绝对未公布任何被认为可接受的密码套件（例如，通过本地系统策略）的对等方的授权，并发送EAP.失败消息。
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:
如果身份验证失败，服务器必须向对等方发送EAP.failure消息，如图2所示。执行以下步骤：
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 |<---------------------------------------------------------|
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-SAKE身份验证过程，对等方身份验证失败
1. As in step 1 of Figure 1.
1. 如图1的步骤1所示。
2. As in step 2 of Figure 1.
2. 如图1的步骤2所示。
3. Upon receipt of the EAP.Response/SAKE/Challenge message, the Server uses both nonces RAND_S and RAND_P, along with the Root-Secret-A key, to compute the SMS and TEK in exactly the same way the Peer did. Following that, the Server computes the Peer's MIC in exactly the same way the Peer did. The Server then compares the computed MIC_P with the MIC_P it received from the Peer. Since they do not match, the Server considers the Peer to have failed authentication and sends an EAP.Failure message back to the Peer.
3. 在收到EAP.Response/SAKE/Challenge消息后，服务器使用nonce RAND_S和RAND_P以及Root-Secret-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属性但不接受服务器选择的密码套件，则对等方应自动放弃此消息。或者，对等方可以将SAKE/Auth拒绝消息发送回服务器；为了响应此消息，服务器必须向对等方发送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_数据属性，则对等方应处理该消息并跳过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_值与计算出的MIC_值不匹配，则对等方认为服务器身份验证失败。在这种情况下，对等方必须向服务器发送类型为SAKE和子类型为Auth Reject的EAP.Response消息，指示身份验证失败。在这种情况下，服务器必须向对等方发送EAP.Failure消息，如图3所示。执行以下步骤：
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 |<---------------------------------------------------------|
| |
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-SAKE身份验证过程，服务器身份验证失败
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/SAKE/Confirm消息，指示服务器成功进行身份验证。对等方以与服务器相同的方式计算麦克风。然后，对等方将接收到的麦克风与其计算出的麦克风进行比较。由于它们不匹配，对等方认为服务器身份验证失败。在这种情况下，对等方使用类型为SAKE和子类型为Auth Reject的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/SAKE/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).
当需要用户匿名时，建议将临时标识符（TempID）分配给对等方。TempID在EAP.Request/SAKE/Confirm消息中传递给对等方。TempID遵循任何NAI[NAI]的格式，由参与对等方EAP-SAKE身份验证任务的EAP服务器生成。EAP服务器应可配置临时ID空间，以区别于永久标识空间。例如，可以为tempid分配一个特定的领域（例如，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.
没有为临时ID分配显式生存期。在服务器请求永久标识符，或者对等方通过发送其永久标识符触发新EAP会话的启动之前，临时ID是有效的。对等方必须能够随时使用其永久标识符触发EAP会话。在成功的EAP会话期间分配的新TempID必须替换现有TempID，以用于对等方和服务器之间的未来事务。
Note that the delivery of a TempID does not imply that the Server considers the Peer authenticated; the Server still has to check the MIC in the EAP.Response/SAKE/Confirm message. In case the EAP phase ends with an EAP.Failure message, then the Server and the Peer MUST consider the TempID that was just delivered as invalid. Hence, the Peer MUST NOT use this TempID the next time it tries to authenticate with the Server.
请注意，TempID的传递并不意味着服务器认为对等方已通过身份验证；服务器仍需检查EAP.Response/SAKE/Confirm消息中的麦克风。如果EAP阶段以EAP.失败消息结束，那么服务器和对等体必须考虑刚刚交付为无效的TempID。因此，对等方下次尝试向服务器进行身份验证时不得使用此临时ID。
The types of identities that a Peer may possess are permanent and temporary identities, referred to as PermID and TempID, respectively. A PermID can be an NAI associated with the Root Secret, and is long-lived. A TempID is an identifier generated through the EAP method and that the Peer can use to identify itself during subsequent EAP sessions with the Server. The purpose of the TempID is to allow for user anonymity support. The use of TempIDs is optional in the EAP-SAKE method.
对等方可能拥有的身份类型是永久身份和临时身份，分别称为PermID和TempID。PermID可以是与根秘密关联的NAI，并且是长期存在的。TempID是通过EAP方法生成的标识符，对等方可以在与服务器的后续EAP会话期间使用它来标识自己。TempID的目的是允许用户匿名性支持。在EAP-SAKE方法中，tempid的使用是可选的。
The Server MAY request the Peer ID via the EAP.Request/SAKE/Identity message, as shown in Figure 4. This case may happen if, for example, the Server wishes to initiate an EAP-SAKE session for a Peer it does not have a subscriber identifier for. The following steps take place:
服务器可以通过EAP.request/SAKE/Identity消息请求对等ID，如图4所示。例如，如果服务器希望为没有订户标识符的对等方启动EAP-SAKE会话，则可能发生这种情况。执行以下步骤：
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. |
+--------------------------------------------------------------+
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. 服务器发送一个EAP.Request消息，其类型为SAKE和子类型标识，属性为_ANY_ID_REQ，指示对任何对等标识符的请求。
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. 对等方构造类型为SAKE和子类型标识的EAP.Response消息，属性位于包含任何对等标识符（PermID或TempID）的\u Peer\u ID。
If the Server cannot find the Peer identity reported in the EAP.Response/SAKE/Identity message, or if it does not recognize the format of the Peer identifier, the Server MAY send an EAP.Failure message to the Peer.
如果服务器找不到EAP.Response/SAKE/identity消息中报告的对等标识，或者如果服务器无法识别对等标识的格式，则服务器可能会向对等方发送EAP.Failure消息。
If the Server is unable to look up a Peer by its TempID, or if policy dictates that the Peer should now use its permanent id, then the Server may specifically ask for the permanent identifier, as in Figure 5. The following steps occur:
如果服务器无法通过其临时id查找对等方，或者如果策略规定对等方现在应该使用其永久id，那么服务器可能会特别要求永久标识符，如图5所示。发生以下步骤：
Peer Server
| |
| +---------------------------------+
1 | | Server obtains TempID but |
| | requires PermID |
| +---------------------------------+
| |
| EAP.Request/SAKE/Identity |
| (AT_PERM_ID_REQ, AT_SERVERID) |
2 |<---------------------------------------------------------|
| |
| EAP.Response/SAKE/Identity |
| (AT_PEERID) |
3 |--------------------------------------------------------->|
| |
| +---------------------------------+
| | Server finds and uses |
| | Peer PermID to start a |
| | EAP-SAKE authentication phase |
| +---------------------------------+
|
+---------------------------------------------------------------+
| Normal EAP-SAKE authentication follows. |
+---------------------------------------------------------------+
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。给服务器一个TempID作为对等身份；服务器需要一个许可证
1. The Peer (or the Authenticator on behalf of the Peer) sends an EAP.Request message of type Identity and includes the TempID.
1. 对等方（或代表对等方的身份验证器）发送类型为Identity的EAP.Request消息，并包含TempID。
2. The Server requires a PermID instead, so it sends an EAP.Request message of type SAKE and subtype Identity with attributes AT_PERM_ID_REQ and AT_SERVERID.
2. 服务器需要一个PermID，因此它发送一个EAP.Request消息，类型为SAKE，子类型为Identity，属性为\u PERM\u ID\u REQ和\u SERVERID。
3. The Peer sends an EAP.Response message of type SAKE and subtype Identity containing the attribute AT_PEERID carrying the Peer PermID.
3. 对等方发送类型为SAKE和子类型标识的EAP.Response消息，其中包含带有对等方权限ID的\u PEERID属性。
EAP-SAKE uses a three-level key hierarchy.
EAP-SAKE使用三级密钥层次结构。
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包含名为根秘密的预共享秘密。这是一个32字节的高熵字符串，分为Root-Secret-a部分（16字节）和Root-Secret-B部分（16字节）。
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包含称为清酒主密钥（SMS）的密钥派生密钥。SMS-A是使用EAP-SAKE密钥派生函数（KDF）从根密钥A、对等方和服务器的nonce派生出来的，同样，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和nonce派生的。它们被划分为一个16字节的TEK认证（用于计算MIC）和一个16字节的TEK密码（用于加密选定的属性）。因为SMS是新的，所以派生的TEK也是新的。
+--------------------+ +--------------------+
| Root-Secret-A | | Root-Secret-B |
| (pre-shared secret)| | (pre-shared secret)|
+--------------------+ +--------------------+
| |
V V
+-------------------+ +--------------------+
| SAKE Master Secret|<---RAND_S------------->| SAKE Master Secret |
| (SMS-A) | | | (SMS-B) |
| |<-------]---RAND_P----->| |
+-------------------+ | | +--------------------+
| | | |
V | | V
+--------------------+ | | +--------------------+
| Transient EAP Keys |<------+-----+-------->| Session Keys: |
| TEK-Auth,TEK-Cipher|<------------+-------->| MSK, EMSK |
+--------------------+ +--------------------+
+--------------------+ +--------------------+
| 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-SAKE方法的密钥层次结构
On another branch of level 3 of the key hierarchy are the MSK and EMSK, each mandated to be 64 bytes long. They are derived from the SMS-B and the nonces using the EAP-SAKE KDF. Again, since the SMS is fresh, so are the derived MSK/EMSK. The MSK is meant to be exported and relayed to other parties. The EMSK is reserved for future use, such as derivation of application-specific keys, and is not shared with other parties.
在密钥层次结构的第3级的另一个分支上是MSK和EMSK，每个分支的长度都是64字节。它们是使用EAP-KDF从SMS-B和nonce派生的。同样，由于SMS是新的，因此派生的MSK/EMSK也是新的。MSK将被导出并转发给其他方。EMSK保留供将来使用，例如派生特定于应用程序的密钥，并且不与其他方共享。
The EAP-SAKE key material is summarized in the table below.
下表总结了EAP-SAKE关键材料。
===================================================================
Key Size Scope Lifetime Use
(bytes)
===================================================================
Root-Secret-A 16 Peer, Server Device Derive TEK
--------------------------------------------------------------------
Root-Secret-B 16 Peer, Server Device Derive MSK, EMSK
--------------------------------------------------------------------
TEK-Auth 16 Peer, Server MSK Life Compute MICs
--------------------------------------------------------------------
TEK-Cipher 16 Peer, Server MSK Life Encrypt attribute
--------------------------------------------------------------------
MSK 64 Peer, Server, MSK Life Derive keys for
Authenticator lower-layer use
--------------------------------------------------------------------
EMSK 64 Peer, Server MSK Life Reserved
--------------------------------------------------------------------
===================================================================
Key Size Scope Lifetime Use
(bytes)
===================================================================
Root-Secret-A 16 Peer, Server Device Derive TEK
--------------------------------------------------------------------
Root-Secret-B 16 Peer, Server Device Derive MSK, EMSK
--------------------------------------------------------------------
TEK-Auth 16 Peer, Server MSK Life Compute MICs
--------------------------------------------------------------------
TEK-Cipher 16 Peer, Server MSK Life Encrypt attribute
--------------------------------------------------------------------
MSK 64 Peer, Server, MSK Life Derive keys for
Authenticator lower-layer use
--------------------------------------------------------------------
EMSK 64 Peer, Server MSK Life Reserved
--------------------------------------------------------------------
A key name format is not provided in this version.
此版本中未提供密钥名格式。
Since this version of EAP-SAKE does not support fast re-authentication, the lifetime of the TEKs is to extend only until the next EAP mutual authentication. The MSK lifetime dictates when the next mutual authentication is to take place. The Server MAY convey the MSK lifetime to the Peer in the AT_MSK_LIFE attribute. Note that EAP-SAKE does not support key lifetime negotiation.
由于此版本的EAP-SAKE不支持快速重新身份验证，TEK的生存期将仅延长到下一个EAP相互身份验证。MSK生存期决定下一次相互身份验证的时间。服务器可以在AT_MSK_LIFE属性中将MSK生存期传递给对等方。请注意，EAP-SAKE不支持密钥生存期协商。
The EAP-SAKE Method-Id is the contents of the RAND_S field from the AT_RAND_S attribute, followed by the contents of the RAND_P field in the AT_RAND_P attribute.
EAP-SAKE方法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表示EAP-SAKE密钥派生函数，其输出为X字节。此函数是[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:
该函数获取任意长度的三个字节字符串：键、标签和消息，并输出长度为X字节的字符串，如下所示：
Out = KDF-X (Key, Label, Msg)
Out=KDF-X（键、标签、消息）
The KDF is a keyed hash function with key "Key" and operating on input "Label | Msg". The convention followed herein is that concatenation is denoted by |, FLOOR denotes the floor function, and [x...y] denotes bytes x through y.
KDF是一个键为“key”的哈希函数，对输入“Label | Msg”进行操作。本文遵循的约定是，级联由|表示，FLOOR表示FLOOR函数，[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字符串。它包含在给定的确切形式中，没有长度字节或尾随空字符。
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)
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)]
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，然后派生TEK，如下所示：
SMS-A = KDF-16 (Root-Secret-A, "SAKE Master Secret A", RAND_P|RAND_S) TEK = KDF-32 (SMS-A, "Transient EAP Key", RAND_S | RAND_P) TEK-Auth = TEK[0...15] TEK-Cipher = TEK[16...31]
SMS-A=KDF-16（Root-Secret-A，“SAKE Master Secret A”，RAND|P|RAND|S）TEK=KDF-32（SMS-A，“瞬态EAP密钥”，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，“SAKE Master Secret B”，RAND|P|RAND|S）会话密钥块=KDF-128（SMS-B，“Master Session Key”，RAND|S|RAND|P）MSK=会话密钥块[0…63]EMSK=会话密钥块[64…127]
The derivation above affords the required cryptographic separation between the MSK and EMSK. That is, knowledge of the EMSK does not immediately lead to knowledge of the MSK, nor does knowledge of the MSK immediately lead to knowledge of the EMSK.
上述推导提供了MSK和EMSK之间所需的加密分离。也就是说，对EMSK的了解不会立即导致对MSK的了解，对MSK的了解也不会立即导致对EMSK的了解。
A ciphersuite is identified by a numeric value called the Security Parameter Index (SPI). The SPI is used here in the EAP-SAKE method in order to negotiate a ciphersuite between the Peer and the Server for EAP data protection only. Obviously, this ciphersuite can only be used late in the EAP conversation, after it has been agreed upon by both the Peer and the Server.
密码套件由称为安全参数索引（SPI）的数值标识。此处，在EAP-SAKE方法中使用SPI，以便在对等方和服务器之间协商密码套件，仅用于EAP数据保护。显然，只有在对等方和服务器都同意后，此密码套件才能在EAP会话的后期使用。
The EAP method may or may not need to use this ciphersuite, since attribute encryption is optional. For example, if the temporary identifier needs to be delivered to the Peer and needs to be encrypted, then the negotiated ciphersuite will be used for this task. If there are no attributes that need encryption as they are passed to the Peer, then this ciphersuite is never used.
EAP方法可能需要也可能不需要使用此密码套件，因为属性加密是可选的。例如，如果临时标识符需要传递给对等方并需要加密，则协商的密码套件将用于此任务。如果在传递给对等方时没有需要加密的属性，则永远不会使用此密码套件。
As with most other methods employing ciphersuite negotiation, the following exchange is employed: the Peer sends an ordered list of one or more supported ciphersuites, starting with the most preferred one, in a field SPI_P. The Server then sends back the one ciphersuite chosen in a field SPI_S. The Server SHOULD choose the strongest ciphersuite supported by both of them.
与使用密码套件协商的大多数其他方法一样，使用以下交换：对等方发送一个或多个受支持密码套件的有序列表，从最首选的密码套件开始，在字段SPI\u P中。然后服务器发回在字段SPI\u S中选择的一个密码套件。服务器应选择两者支持的最强密码套件。
Ciphersuite negotiation for data protection is achieved via SAKE Signaling as follows. In the EAP.Response/SAKE/Challenge, the Peer sends a list of supported ciphersuites, SPI_P, and protects that with a MIC. In the EAP.Request/SAKE/Confirm, the Server sends one selected ciphersuite, SPI_S, and signs that with a MIC. Finally, the Peer confirms the selected ciphersuite and readiness to use it in a signed EAP.Response/SAKE/Confirm message. The negotiation is secure because of the Message Integrity Checks that cover the entire EAP message.
数据保护的Ciphersuite协商通过SAKE信令实现，如下所示。在EAP.Response/SAKE/Challenge中，对等方发送受支持的密码套件列表SPI_P，并用麦克风保护该列表。在EAP.Request/SAKE/Confirm中，服务器发送一个选定的密码套件SPI_，并用麦克风对此进行签名。最后，对等方确认所选密码套件，并准备在签名的EAP.Response/SAKE/Confirm消息中使用它。由于覆盖整个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/SAKE属性：AT_MIC_S、AT_MIC_P、AT_IV、AT_ENCR_DATA和AT_PADDING。在EAP-SAKE交换期间，只有AT_MIC_和AT_MIC_P是必须使用的。
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是使用nonce RAND_S和RAND_P导出的，因此AT_MIC_S和AT_MIC_P属性只能用于EAP.Response/SAKE/Challenge消息以及此后发送的任何消息。
The AT_MIC_S and AT_MIC_P attributes are used for EAP-SAKE message integrity. The AT_MIC_S attribute MUST be included in all EAP-SAKE packets that the Server sends whenever key material (TEK) has been derived. That is, the AT_MIC_S attribute MUST be included in the EAP.Request/SAKE/Confirm message. The AT_MIC_S MUST NOT be included in EAP.Request/SAKE/Challenge messages, or EAP.Request/SAKE/Identity messages.
AT_MIC_S和AT_MIC_P属性用于EAP-SAKE消息完整性。无论何时导出密钥材料（TEK），服务器发送的所有EAP-SAKE数据包中都必须包含AT_MIC_S属性。也就是说，AT_MIC_S属性必须包含在EAP.Request/SAKE/Confirm消息中。AT_麦克风不得包含在EAP.Request/SAKE/Challenge消息或EAP.Request/SAKE/Identity消息中。
The AT_MIC_P attribute MUST be included in all EAP-SAKE packets the Peer sends whenever key material (TEK) has been derived. That is, the AT_MIC_P attribute MUST be included in the EAP.Response/SAKE/Challenge and EAP.Response/SAKE/Confirm messages.
无论何时导出密钥材料（TEK），对等方发送的所有EAP-SAKE数据包中都必须包含AT_MIC_P属性。也就是说，AT_MIC_P属性必须包含在EAP.Response/SAKE/Challenge和EAP.Response/SAKE/Confirm消息中。
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.
EAP.Response/SAKE/Auth-Reject消息中不得包含AT_MIC_P属性，因为对等方尚未确认其具有与服务器相同的TEK。
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）。在整个EAP数据包上计算MIC，并在其前面加上服务器nonce和标识符以及对等方nonce和标识符。计算话筒时，话筒属性的值字段设置为零。包括服务器和对等节点的nonce和标识符有助于检测重播和中间人攻击。
The Peer computes its MIC as follows:
对等方按如下方式计算其MIC：
MIC_P = KDF-16 (TEK-Auth, "Peer MIC", RAND_S | RAND_P | PEERID | 0x00 | SERVERID | 0x00 | <EAP-packet>),
麦克风P=KDF-16（TEK认证，“对等麦克风”，RAND|S | RAND|U P | PEERID | 0x00 |<EAP数据包>），
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|U S=KDF-16（TEK认证，“服务器MIC”，RAND|U P|RAND|U S|SERVERID|0x00 | PEERID|0x00 |<EAP数据包>）。
Here, <EAP-packet> denotes the entire EAP packet, used as a string of bytes, the MIC value field set to zero. 0x00 denotes a single octet value used to delimit SERVERID and PEERID. The PEERID and SERVERID, respectively, are the ones carried in the corresponding attributes in the SAKE/Challenge messages.
此处，<EAP packet>表示整个EAP数据包，用作一个字节字符串，MIC值字段设置为零。0x00表示用于分隔SERVERID和PEERID的单个八位字节值。PEERID和SERVERID分别是SAKE/Challenge消息中相应属性中携带的。
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.
如果在SAKE/Challenge交换之前有包含AT_SERVERID属性的EAP.Request/SAKE/Identity消息，则必须将MIC_P和MIC_S计算中的SERVERID值设置为该属性的值。
If the AT_SERVERID was not included in either the SAKE/Challenge message or the SAKE/Identity message, then the value of the SERVERID used in the computation of MIC_P and MIC_S MUST be empty. If the AT_PEERID was not included in the SAKE/Challenge message, and there was no EAP.Response/SAKE/Identity message preceding the SAKE/Challenge messages, then the value of the PEERID used in the computation of MIC_P and MIC_S MUST be empty.
如果SAKE/Challenge消息或SAKE/Identity消息中未包含AT_SERVERID，则用于计算MIC_P和MIC_S的SERVERID的值必须为空。如果SAKE/Challenge消息中不包括AT_PEERID，并且在SAKE/Challenge消息之前没有EAP.Response/SAKE/Identity消息，则用于计算MIC_P和MIC_S的PEERID的值必须为空。
The Server and Peer identity are included in the computation of the signed responses so that the Peer and Server can verify each other's identities, and the possession of a common secret, the TEK-Auth. However, since the AT_SERVERID is not explicitly signed with a MIC by the Server, EAP-SAKE does not claim channel binding.
服务器和对等方身份包括在签名响应的计算中，以便对等方和服务器可以验证彼此的身份，以及是否拥有公共机密TEK Auth。但是，由于AT_SERVERID未由服务器与MIC显式签名，EAP-SAKE不声明通道绑定。
The AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted information between the Server and the Peer. The value field of AT_IV contains an initialization vector (IV) if one is required by the encryption algorithm used. It is not mandatory that the AT_IV attribute be included whenever the AT_ENCR_DATA attribute is.
AT_IV和AT_ENCR_数据属性可用于在服务器和对等方之间传输加密信息。如果使用的加密算法需要初始化向量，则AT_IV的值字段包含初始化向量（IV）。无论何时启用AT_ENCR_数据属性，都不强制包含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_数据，否则不得包含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.
只有在约定了密码套件后，才能对属性进行加密，即在以服务器的EAP.Request/SAKE/Confirm消息开头的任何消息中。必须使用与AT_SPI_S属性指定的SPI值对应的算法对属性进行加密。必须使用第3.2.6.2节规定的TEK密码密钥对属性进行加密。
If an IV is required by the encryption algorithm, then the sender of the AT_IV attribute MUST NOT reuse the IV value from previous EAP-SAKE packets. The sender MUST choose a new value for each AT_IV attribute. The sender SHOULD use a good random number generator to generate the initialization vector (see [RFC4086] for guidelines).
如果加密算法需要IV，则AT_IV属性的发送方不得重用先前EAP-SAKE数据包中的IV值。发送方必须为每个AT_IV属性选择一个新值。发送方应该使用一个好的随机数生成器来生成初始化向量（请参见[RFC4086]了解指导原则）。
The value field of the AT_ENCR_DATA attribute consists of bytes encrypted using the ciphersuite specified in the AT_SPI_S attribute. The encryption key is the TEK-Cipher, and the plaintext consists of one or more concatenated EAP-SAKE attributes.
AT_ENCR_数据属性的值字段由使用AT_SPI_属性中指定的密码套件加密的字节组成。加密密钥是TEK密码，明文由一个或多个串联的EAP-SAKE属性组成。
The default encryption algorithm, as described in Section 3.2.8.3, requires the length of the plaintext to be a multiple of 16 bytes. The sender MAY need to include the AT_PADDING attribute as the last attribute within the value field of the AT_ENCR_DATA attribute. The length of the padding is chosen so that the length of the value field of the AT_ENCR_DATA attribute becomes a multiple of 16 bytes. The AT_PADDING attribute SHOULD NOT be included if the total length of other attributes present within the AT_ENCR_DATA attribute is a multiple of 16 bytes. The length of the AT_PADDING attribute includes the Attribute Type and Attribute Length fields. The actual pad bytes in the value field are set to zero (0x00) on sending. The recipient of the message MUST verify that the pad bytes are zero after decryption and MUST silently discard the message otherwise.
如第3.2.8.3节所述，默认加密算法要求明文长度为16字节的倍数。发送方可能需要将AT_PADDING属性作为AT_ENCR_数据属性的值字段中的最后一个属性。选择填充的长度，以便AT_ENCR_数据属性的值字段的长度变为16字节的倍数。如果AT_ENCR_数据属性中存在的其他属性的总长度是16字节的倍数，则不应包括AT_PADDING属性。AT_PADDING属性的长度包括属性类型和属性长度字段。值字段中的实际pad字节在发送时设置为零（0x00）。消息的收件人必须验证解密后pad字节是否为零，否则必须以静默方式丢弃消息。
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_数据属性的示例如第3.3.3节所示。
An SPI value is a variable-length string identifying at least an encryption algorithm and possibly a "security association". EAP-SAKE does not mandate the format of the SPI; it only mandates that the default encryption algorithm be supported if encryption is supported. That is, if an implementation compliant with this document supports encryption, then it MUST support the AES-CBC cipher.
并且“可能的话，识别长度至少为SPI的加密算法”是一个字符串。EAP-SAKE不强制规定SPI的格式；它仅要求在支持加密的情况下支持默认加密算法。也就是说，如果符合本文档的实现支持加密，那么它必须支持AES-CBC密码。
The default encryption algorithm AES-CBC involves the AES block cipher [AES] in the Cipher-Block-Chaining (CBC) mode of operation [CBC].
默认加密算法AES-CBC涉及密码块链接（CBC）操作模式[CBC]中的AES分组密码[AES]。
The Peer in the EAP-SAKE method can send up to four SPI values in its SPI_P field. Because the length of the AT_SPI_P and AT_SPI_S attributes must each be a multiple of 2 bytes, the sender pads the value field with zero bytes when necessary (the AT_PADDING attribute is not used here). For example, the value field of the AT_SPI_S contains one byte with the chosen SPI, followed by one byte of zeros.
EAP-SAKE方法中的对等方最多可以在其SPI_P字段中发送四个SPI值。因为AT_SPI_P和AT_SPI_S属性的长度都必须是2字节的倍数，所以发送方在必要时用零字节填充值字段（此处不使用AT_PADDING属性）。例如，AT_SPI_S的值字段包含一个带有所选SPI的字节，后跟一个零字节。
The EAP-SAKE method does not require fragmentation, as the messages do not get excessively long. That is, EAP packets are well within the limit of the maximum transmission unit of other layers (link, network). The only variable fields are those carrying NAIs, which are limited by their length field to 256 bytes.
EAP-SAKE方法不需要分段，因为消息不会过长。也就是说，EAP分组在其他层（链路、网络）的最大传输单元的限制内。唯一的变量字段是那些携带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-SAKE数据包，则实现应该自动丢弃该数据包，而不是更改状态，并且不向另一方发送任何EAP消息。此类错误的示例包括缺少强制属性、此类型消息中不允许的属性以及无法识别的子类型或属性。
Non-matching Session Id: If a Peer or Server receives an EAP-SAKE packet with a Session Id field not matching the Session Id from the previous packet in this session, that entity SHOULD silently discard this packet (not applicable for the first message of an EAP-SAKE session).
非匹配会话Id：如果对等方或服务器接收到一个EAP-SAKE数据包，其会话Id字段与该会话中前一个数据包的会话Id不匹配，则该实体应自动丢弃该数据包（不适用于EAP-SAKE会话的第一条消息）。
Peer Authorization Failure: It may be possible that a Peer is not authorized for services, such as when the terminal device is reported stolen. In that case, the Server SHOULD send an EAP.Failure message.
对等授权失败：对等方可能未获得服务授权，例如当终端设备被报告被盗时。在这种情况下，服务器应该发送EAP.Failure消息。
Unexpected EAP.Success: A Server MUST NOT send an EAP-Success message before the SAKE/Challenge and SAKE/Confirm rounds. The Peer MUST silently discard any EAP.Success packets before the Peer has successfully authenticated the Server via the EAP.Response/SAKE/Confirm packet.
意外的EAP。成功：在清酒/挑战和清酒/确认回合之前，服务器不得发送EAP成功消息。在对等方通过EAP.Response/SAKE/Confirm数据包成功验证服务器之前，对等方必须以静默方式丢弃任何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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
标识符字段是一个八位字节，有助于将响应与请求匹配。
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.
长度字段是两个八位字节，表示EAP消息中的八位字节数，包括代码、标识符、长度、类型和数据字段。
Type
类型
To be assigned.
待分配。
Version
版本
The EAP-SAKE method as described herein is version 2.
本文所述的EAP-SAKE方法为版本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是一个1字节的随机数，必须由服务器新生成，并且必须匹配特定EAP会话中的所有EAP消息。
Subtype
亚型
EAP-SAKE subtype: SAKE/Challenge, SAKE/Confirm, SAKE/Auth-Reject, and SAKE/Identity. All messages of type "EAP-SAKE" that are not of these subtypes MUST silently discarded.
EAP-SAKE子类型：清酒/挑战、清酒/确认、清酒/认证拒绝和清酒/身份。所有不属于这些子类型的“EAP-SAKE”类型的消息都必须以静默方式丢弃。
Message Name Subtype Value (decimal)
=============================================
SAKE/Challenge 1
SAKE/Confirm 2
SAKE/Auth-Reject 3
SAKE/Identity 4
Message Name Subtype Value (decimal)
=============================================
SAKE/Challenge 1
SAKE/Confirm 2
SAKE/Auth-Reject 3
SAKE/Identity 4
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-SAKE数据包一部分的EAP-SAKE属性遵循类型长度值格式，具有1字节类型、1字节长度和可变长度值（最多255字节）。长度字段以八位字节为单位，包括类型的长度和长度字段。EAP-SAKE属性格式如下：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
1-byte unsigned integer; see Table below.
1字节无符号整数；见下表。
Length
长
The total number of octets in the attribute, including Type and Length.
属性中的八位字节总数，包括类型和长度。
Value
价值
Attribute-specific.
属性特定。
The following attribute types are allocated.
将分配以下属性类型。
-----------------------------------------------------------------
Attr. Name Length
(bytes) Skippable Description
-----------------------------------------------------------------
AT_RAND_S 18 No Server Nonce RAND_S
AT_RAND_P 18 No Peer Nonce RAND_P
AT_MIC_S 10 No Server MIC
AT_MIC_P 10 No Peer MIC
AT_SERVERID variable No Server FQDN
AT_PEERID variable No Peer NAI (tmp, perm)
AT_SPI_S variable No Server chosen SPI SPI_S
AT_SPI_P variable No Peer SPI list SPI_P
AT_ANY_ID_REQ 4 No Requires any Peer Id (tmp, perm)
AT_PERM_ID_REQ 4 No Requires Peer's permanent Id/NAI
AT_ENCR_DATA Variable Yes Contains encrypted attributes
AT_IV Variable Yes IV for encrypted attributes
AT_PADDING 2 to 18 Yes Padding for encrypted attributes
AT_NEXT_TMPID variable Yes TempID for next EAP-SAKE phase
-----------------------------------------------------------------
Attr. Name Length
(bytes) Skippable Description
-----------------------------------------------------------------
AT_RAND_S 18 No Server Nonce RAND_S
AT_RAND_P 18 No Peer Nonce RAND_P
AT_MIC_S 10 No Server MIC
AT_MIC_P 10 No Peer MIC
AT_SERVERID variable No Server FQDN
AT_PEERID variable No Peer NAI (tmp, perm)
AT_SPI_S variable No Server chosen SPI SPI_S
AT_SPI_P variable No Peer SPI list SPI_P
AT_ANY_ID_REQ 4 No Requires any Peer Id (tmp, perm)
AT_PERM_ID_REQ 4 No Requires Peer's permanent Id/NAI
AT_ENCR_DATA Variable Yes Contains encrypted attributes
AT_IV Variable Yes IV for encrypted attributes
AT_PADDING 2 to 18 Yes Padding for encrypted attributes
AT_NEXT_TMPID variable Yes TempID for next EAP-SAKE phase
AT_MSK_LIFE 6 Yes MSK Lifetime in seconds
-----------------------------------------------------------------
AT_MSK_LIFE 6 Yes MSK Lifetime in seconds
-----------------------------------------------------------------
An example of the AT_ENCR_DATA attribute, as used in the EAP.Request/SAKE/Confirm message, is shown below:
EAP.Request/SAKE/Confirm消息中使用的AT_ENCR_数据属性示例如下所示：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_IV | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Initialization Vector |
| |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |AT_ENCR_DATA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+}e
| AT_NEXT_TMPID | Length | |}n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |}c
| |}r
. Peer TempID |}y
. |}p
. |}t
| |}e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+}d
| AT_MIC_S | Length = 10 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MIC_S |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |AT_PADDING | Length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_IV | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Initialization Vector |
| |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |AT_ENCR_DATA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+}e
| AT_NEXT_TMPID | Length | |}n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |}c
| |}r
. Peer TempID |}y
. |}p
. |}t
| |}e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+}d
| AT_MIC_S | Length = 10 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MIC_S |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |AT_PADDING | Length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the EAP.Request/SAKE/Challenge packet is shown below.
下面显示的是数据包/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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=EAP-SAKE | Version=2 | Session ID | Subtype=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_RAND_S | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| RAND_S |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | AT_SERVERID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
| Server ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
字段的语义描述如下：
Code
密码
1 for Request
1请求
Identifier
标识符
A random number. See [EAP].
随机数。见[EAP]。
Length
长
The length of the entire EAP packet in octets.
整个EAP数据包的长度（以八位字节为单位）。
Type
类型
EAP-SAKE
EAP-SAKE
Version
版本
2
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
在兰德
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/SAKE/Challenge中。
AT_SERVERID
AT_服务器ID
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.
此属性的值字段包含服务器标识符（例如，以非null结尾的字符串）。AT_SERVERID属性应该出现在EAP.Request/SAKE Challenge中。
The format of the EAP.Response/SAKE/Challenge packet is shown below.
EAP.Response/SAKE/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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=EAP-SAKE | Version=2 | Session ID | Subtype=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_RAND_P | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| RAND_P |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | AT_PEERID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Peer NAI :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | AT_SPI_P | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPIP | AT_MIC_P | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MIC_P |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
字段的语义描述如下：
Code
密码
2 for Response
2.答复
Identifier
标识符
A number that MUST match the Identifier field from the corresponding Request.
必须与相应请求的标识符字段匹配的数字。
Length
长
The length of the entire EAP packet in octets.
整个EAP数据包的长度（以八位字节为单位）。
Type
类型
EAP-SAKE
EAP-SAKE
Version
版本
2
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.
此属性的值字段包含对等的nonce RAND\P参数。EAP.Response/SAKE/Challenge中必须存在AT_RAND_P属性。
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/identity中使用的相同网络访问标识符格式，即包括NAI领域部分。身份是永久性身份，或临时身份。空标识不包括任何终止字符。AT_PEERID属性在EAP.Response/SAKE/Challenge中是可选的。
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.
此属性的值字段包含对等方的ciphersuite列表SPI\P参数。AT_SPI_P属性在EAP.Response/SAKE/Challenge中是可选的。
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参数。EAP.Response/SAKE/Challenge中必须存在AT_MIC_P属性。
The format of the EAP.Request/SAKE/Confirm packet is shown below.
EAP.Request/SAKE/Confirm数据包的格式如下所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=EAP-SAKE | Version=2 | Session ID | Subtype=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_SPI_S | Length | SPI_S |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_IV | Length | Initialization Vector ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_ENCR_DATA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Data... |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_MSK_LIFE | Length=6 | MSK Lifetime... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_MIC_S | Length=18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MIC_S |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=EAP-SAKE | Version=2 | Session ID | Subtype=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_SPI_S | Length | SPI_S |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_IV | Length | Initialization Vector ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_ENCR_DATA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Data... |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_MSK_LIFE | Length=6 | MSK Lifetime... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_MIC_S | Length=18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MIC_S |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
字段的语义描述如下：
Code
密码
1 for Request
1请求
Identifier
标识符
A random number. See [EAP].
随机数。见[EAP]。
Length
长
The length of the entire EAP packet in octets.
整个EAP数据包的长度（以八位字节为单位）。
Type
类型
EAP-SAKE
EAP-SAKE
Version
版本
2
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
在斯皮斯
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参数。在EAP.Request/SAKE/Confirm中，AT_SPI_S属性是可选的。
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_数据
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.
此属性在此消息中使用是可选的。加密数据（如果存在）可能在_NEXT_TMPID处包含一个属性，该属性包含对等方应在下一个EAP身份验证中使用的NAI。
AT_MSK_LIFE
在MSK生活
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
至少
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.
此属性的值字段包含服务器麦克风参数。EAP.Request/SAKE/Confirm中必须存在AT_MIC_S属性。
The format of the EAP.Response/SAKE/Confirm packet is shown below.
EAP.Response/SAKE/Confirm数据包的格式如下所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=EAP-SAKE | Version=2 | Session ID | Subtype=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_MIC_P | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MIC_P |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_PADDING | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=EAP-SAKE | Version=2 | Session ID | Subtype=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_MIC_P | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MIC_P |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_PADDING | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
字段的语义描述如下：
Code
密码
2 for Response
2.答复
Identifier
标识符
A number that MUST match the Identifier field from the corresponding Request.
必须与相应请求的标识符字段匹配的数字。
Length
长
The length of the entire EAP packet in octets.
整个EAP数据包的长度（以八位字节为单位）。
Type
类型
EAP-SAKE
EAP-SAKE
Version
版本
2
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
至少
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参数。EAP.Response/SAKE/Confirm中必须存在AT_MIC_P属性。
AT_PADDING
AT_填料
The value field is set to zero. Added to achieve 32-bit alignment of the EAP-SAKE packet.
值字段设置为零。添加以实现EAP-SAKE数据包的32位对齐。
The format of the EAP.Response/SAKE/Auth-Reject packet is shown below.
EAP.Response/SAKE/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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=EAP-SAKE | Version=2 | Session ID | Subtype=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
字段的语义描述如下：
Code
密码
2 for Response
2.答复
Identifier
标识符
A number that MUST match the Identifier field from the corresponding Request.
必须与相应请求的标识符字段匹配的数字。
Length
长
The length of the entire EAP packet in octets.
整个EAP数据包的长度（以八位字节为单位）。
Type
类型
EAP-SAKE
EAP-SAKE
Version
版本
2
2.
Session ID
会话ID
A number matching all other EAP messages in this EAP session.
与此EAP会话中的所有其他EAP消息匹配的数字。
Subtype
亚型
3 for SAKE/Auth-Reject
3为方便/授权拒绝
The format of the EAP.Request/SAKE/Identity is shown below.
EAP.Request/SAKE/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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=EAP-SAKE | Version=2 | Session ID | Subtype=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_PERM_ID_REQ | Length = 4 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_ANY_ID_REQ | Length = 4 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_SERVERID | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| Server ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
字段的语义描述如下：
Code
密码
1 for Request
1请求
Identifier
标识符
A random number. See [EAP].
随机数。见[EAP]。
Length
长
The length of the entire EAP packet in octets.
整个EAP数据包的长度（以八位字节为单位）。
Type
类型
EAP-SAKE
EAP-SAKE
Version
版本
2
2.
Session ID
会话ID
A number matching all other EAP messages in this EAP session.
与此EAP会话中的所有其他EAP消息匹配的数字。
Subtype
亚型
4 for SAKE/Identity
4.为了安全/身份
AT_PERM_ID_REQ
AT_PERM_ID_REQ
The AT_PERM_ID_REQ attribute is optional, to be included in cases where the Server requires the Peer to give its permanent identifier (i.e., PermID). The AT_PERM_ID_REQ MUST NOT be included if the AT_ANY_ID_REQ attribute is included. The value field only contains two reserved bytes, which are set to zero on sending and ignored on reception.
AT_PERM_ID_REQ属性是可选的，在服务器要求对等方提供其永久标识符（即PermID）的情况下包括该属性。如果包含AT_ANY_ID_REQ属性，则不得包含AT_PERM_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属性是可选的，在服务器要求对等方发送任何标识符（例如PermID、TempID）的情况下包括该属性。如果包含AT_PERM_ID_请求，则不得包含AT_ANY_ID_请求。值字段仅包含两个保留字节，发送时设置为零，接收时忽略。必须包括AT_PERM_ID_REQ和AT_ANY_ID_REQ之一。
AT_SERVERID
AT_服务器ID
The value field of this attribute contains the identifier/realm of the Server. The AT_SERVERID attribute is optional but RECOMMENDED to include in the EAP.Request/SAKE/Identity.
此属性的值字段包含服务器的标识符/域。AT_SERVERID属性是可选的，但建议包含在EAP.Request/SAKE/Identity中。
The format of the EAP.Response/SAKE/Identity is shown below:
EAP.Response/SAKE/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_PEERID | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| Peer NAI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=EAP-SAKE | Version=2 | Session ID | Subtype=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_PEERID | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| Peer NAI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The semantics of the fields is described below:
字段的语义描述如下：
Code
密码
2 for Response
2.答复
Identifier
标识符
A number that MUST match the Identifier field from the corresponding Request.
必须与相应请求的标识符字段匹配的数字。
Length
长
The length of the entire EAP packet.
整个EAP数据包的长度。
Type
类型
EAP-SAKE
EAP-SAKE
Version
版本
2
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
阿图皮里德
The value field of this attribute contains the NAI of the Peer. The AT_PEERID attribute MUST be present in EAP.Response/SAKE/Identity.
此属性的值字段包含对等方的NAI。AT_PEERID属性必须存在于EAP.Response/SAKE/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]中描述了EAP.Request/Identity和EAP.Response/Identity数据包的格式。用户ID（如NAI）应存在于该数据包中。
The format of the EAP-Success and EAP-Failure packet is also shown in [EAP].
EAP成功和EAP失败数据包的格式也显示在[EAP]中。
IANA allocated a new EAP Type for EAP-SAKE.
IANA为EAP-SAKE分配了新的EAP类型。
EAP-SAKE messages include an 8-bit Subtype field. The Subtype is a new numbering space for which IANA administration is required. The following subtypes are specified in this memo:
EAP-SAKE消息包含一个8位子类型字段。子类型是一个新的编号空间，需要IANA管理。本备忘录中指定了以下子类型：
SAKE/Challenge.................1
SAKE/Confirm...................2
SAKE/Auth-Reject...............3
SAKE/Identity..................4
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范围内的属性称为可跳过属性。EAP-SAKE属性类型编号是一个新的编号空间，需要IANA管理。指定了以下属性类型：
AT_RAND_S.......................................1
AT_RAND_P.......................................2
AT_MIC_S........................................3
AT_MIC_P........................................4
AT_SERVERID.....................................5
AT_PEERID.......................................6
AT_SPI_S........................................7
AT_SPI_P........................................8
AT_ANY_ID_REQ...................................9
AT_PERM_ID_REQ.................................10
AT_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
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]中描述的“所需规范”政策，本备忘录中描述的两个数字空间的所有赋值请求都需要适当的文件。
All assignments of values from the two number spaces described in this memo require IETF consensus.
本备忘录中描述的两个数字空间的所有赋值都需要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-SAKE方法声称的安全属性，以及漏洞和安全建议。
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/SAKE/Auth-Reject、EAP.Success和EAP.Failure数据包不受完整性或重播保护。这使得攻击者可以伪造此类消息。请注意，EAP.Response/SAKE/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-SAKE的相互身份验证和密钥建立将受到损害。
EAP-SAKE does not address how the Root Secret is generated or distributed to the Server and Peer. It is RECOMMENDED that the entropy of the Root Secret be maximized. The Root Secret SHOULD be machine-generated.
EAP-SAKE不解决如何生成根密钥或将其分发给服务器和对等方的问题。建议最大化根秘密的熵。根密钥应该由计算机生成。
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-SAKE密钥派生会受到在线和离线字典攻击。为了帮助识别此类密码是否已被泄露，实施应记录接收到的带有无效MIC字段的EAP-SAKE消息的数量。在这些情况下，应该有一个安全更新根密钥的过程。
Mutual authentication is accomplished via the SAKE/Challenge and SAKE/Confirm messages. The EAP.Request/SAKE/Challenge contains the Server nonce RAND_S; the EAP.Response/SAKE/Challenge contains the Peer nonce RAND_P, along with the Peer MIC (MIC_P); and the EAP.Request/SAKE/Confirm contains the Server MIC (MIC_S). Both MICs (MIC_S and MIC_P) are computed using both nonces RAND_S and RAND_P and are keyed by the TEK, a shared secret derived from the Root Secret. The Server considers the Peer authenticated if the MIC_P it computes matches the one that the Peer sends. Similarly, the Peer considers the Server authenticated if the MIC_S it computes matches the one that the Server sends. The way the MICs are computed involves a keyed one-way hash function, which makes it computationally hard for an attacker to produce the correct MIC without knowledge of the shared secret.
相互身份验证通过SAKE/质询和SAKE/确认消息完成。EAP.Request/SAKE/Challenge包含服务器nonce RAND；EAP.Response/SAKE/Challenge包含对等的nonce RAND\u P以及对等的MIC（MIC\u P）；EAP.Request/SAKE/Confirm包含服务器麦克风（MIC_）。两个MIC（MIC_S和MIC_P）都使用随机数RAND_S和RAND_P计算，并由TEK键控，TEK是源于根秘密的共享秘密。如果服务器计算的MIC\P与对等方发送的MIC\P匹配，则服务器认为对等方已验证。类似地，如果对等方计算的MIC_与服务器发送的MIC_匹配，则对等方认为服务器已通过身份验证。MIC的计算方式涉及一个键控单向散列函数，这使得攻击者在不知道共享秘密的情况下很难生成正确的MIC。
Integrity protection of EAP-SAKE messages is accomplished through the use of the Message Integrity Checks (MIC), which are present in every message as soon as a common shared secret (TEK) is available, i.e., any message after the EAP.Request/SAKE/Challenge. An adversary cannot modify any of the MIC-protected messages without causing the recipient to encounter a MIC failure. The extent of the integrity protection is commensurate with the security of the KDF used to derive the MIC, the length and entropy of the shared secret used by the KDF, and the length of the MIC.
EAP-SAKE消息的完整性保护是通过使用消息完整性检查（MIC）来实现的，只要有公共共享机密（TEK），即EAP.Request/SAKE/Challenge之后的任何消息，MIC就会出现在每条消息中。对手无法修改任何受麦克风保护的邮件，而不会导致收件人遇到麦克风故障。完整性保护的程度与用于导出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-SAKE）的第一条消息都会被重播。重播的EAP.Request/SAKE/Challenge消息导致对等方发回EAP.Response/SAKE/Challenge消息，该消息包含使用攻击者选择的nonce计算的MIC。这对TEK身份验证密钥的泄露风险最小，并且该EAP会话无法成功进行，因为对等方将发现服务器的MIC无效。
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).
重播保护通过RAND_S和RAND_P值以及会话ID字段实现，会话ID字段包括在EAP-SAKE/质询请求数据包之后每个数据包中存在的MIC的计算中。服务器必须为每个EAP会话重新生成会话ID。会话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实现，MIC不仅覆盖整个EAP数据包（包括会话ID），还覆盖非随机数RAND_S和RAND_P。因此，EAP消息的接收者可以确信其刚刚收到的消息是另一对等方刚刚发送的消息，而不是重播，因为它包含接收者的nonce和另一对等方nonce的有效MIC。与之前一样，重播保护的范围与用于导出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.
通过使用AT_ENCR_数据和AT_IV属性支持EAP-SAKE属性的机密性。密码套件经过安全协商（见第3.2.7节），可用于根据需要加密任何属性。默认密码套件包含基于AES的强密码。
EAP-SAKE derives a Master Key (for EAP use) and Master Session Key, as well as other lower-level keys, such as TEKs. Some of the lower-level keys may or may not be used. The strength (entropy) of all these keys is at most the strength of the Root Secret.
EAP-SAKE派生主密钥（供EAP使用）和主会话密钥，以及其他较低级别的密钥，如TEK。一些较低级别的键可能会被使用，也可能不会被使用。所有这些密钥的强度（熵）最多是根密钥的强度。
The entropy of the MSK and of the EMSK, assuming that the Server and Peer 128-bit nonces are generated using good random number generators, is at most 256-bits.
假设使用良好的随机数生成器生成服务器和对等128位nonce，则MSK和EMSK的熵最多为256位。
Dictionary attacks are not feasible to mount on the EAP-SAKE method because passwords are not used. Instead, the Root Secret is machine-generated. This does not necessarily pose provisioning problems.
由于未使用密码，因此无法在EAP-SAKE方法上装载字典攻击。相反，根秘密是由机器生成的。这不一定会造成资源调配问题。
Resistance to man-in-the-middle attacks is provided through the integrity protection that each EAP message carries (i.e., Message Integrity Check field) as soon as a common key for this EAP session has been derived through mutual authentication. As before, the extent of this resistance is commensurate with the strength of the MIC itself. Man-in-the-middle attacks associated with the use of any EAP method within a tunneling or sequencing protocol are beyond the scope of this document.
通过每个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-SAKE提供结果指示保护，因为它提供结果指示、完整性保护和重播保护。服务器通过发送EAP.Request/SAKE/Confirm消息表示已成功对对等方进行身份验证，该消息受完整性和重播保护。对等方通过发送EAP.Response/SAKE/Confirm消息表示已成功对服务器进行身份验证，该消息也受完整性和重播保护。
The TEKs used to protect EAP-SAKE packets (TEK-Auth, TEK-Cipher), the Master Session Key, and the Extended Master Session Key are cryptographically separate. Information about any of these keys does not lead to information about any other keys. We also note that it is infeasible to calculate the Root Secret from any or all of the TEKs, the MSK, or the EMSK.
用于保护EAP-SAKE数据包（TEK认证、TEK密码）、主会话密钥和扩展主会话密钥的TEK在加密方面是分开的。关于这些钥匙中任何一个的信息不会导致关于任何其他钥匙的信息。我们还注意到，从任何或所有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-SAKE会话中，生成新的键控材料。通过此方法从两个独立的EAP-SAKE会话导出的键控材料在加密上是独立的，如下所述。
Both the Server and the Peer SHOULD generate fresh random numbers (i.e., nonces) for the EAP-SAKE exchange. If either entity re-uses a random number from a previous session, then the fact that the other does use a freshly generated random number implies that the TEKs, MSK, and EMSK derived within this session are cryptographically
服务器和对等方都应该为EAP-SAKE交换生成新的随机数（即nonce）。如果其中一个实体重新使用前一个会话中的随机数，那么另一个实体确实使用新生成的随机数这一事实意味着该会话中派生的TEK、MSK和EMSK是加密的
separate from the corresponding keys derived in the previous exchange.
与上一次交换中派生的相应密钥分开。
Therefore, compromise of MSK or EMSK on one exchange does not compromise the MSK and EMSK of previous or subsequent exchanges between a Peer and a Server.
因此，一个交换上的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-SAKE身份验证阶段时使用。TempID通过在AT_ENCR_数据属性内加密发送，并由服务器用麦克风签名来保护。因此，窃听者无法将对等方首先发送（例如，通电时）的原始PermID链接到以清除方式发送给服务器的任何后续TempID值。
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.
服务器和对等方可被配置为在使用对等方永久身份的一个初始EAP-SAKE阶段之后仅交换TempID身份。在这种情况下，为了实现最大的身份保护，TempID应该存储在对等机和服务器的非易失性内存中。因此，遵守本文件并不排除或强制要求在对等方的整个生命周期内保护对等方身份。
The Server identifier and Peer identifier MAY be sent in the SAKE/Challenge messages. However, since there is no established authentication key at the time of the first message, the Server identifier is not integrity-protected here.
服务器标识符和对等标识符可以在SAKE/质询消息中发送。但是，由于在发送第一条消息时没有建立身份验证密钥，因此服务器标识符在这里不受完整性保护。
All subsequent EAP-SAKE messages exchanged during a successful EAP-SAKE phase are integrity-protected, as they contain a Message Integrity Check (MIC). The MIC is computed over the EAP message and also over the Server and Peer identities. In that, both EAP endpoints can verify the identity of the other party.
在成功的EAP-SAKE阶段中交换的所有后续EAP-SAKE消息都受到完整性保护，因为它们包含消息完整性检查（MIC）。通过EAP消息以及服务器和对等身份计算MIC。这样，两个EAP端点都可以验证另一方的身份。
EAP-SAKE does not support negotiation of the ciphersuite used to integrity-protect the EAP conversation. However, negotiation of a ciphersuite for data protection is supported. This ciphersuite negotiation is protected in order to minimize the risk of down-negotiation or man-in-the-middle attacks.
EAP-SAKE不支持协商用于保护EAP会话完整性的密码套件。但是，支持协商用于数据保护的密码套件。此ciphersuite协商受到保护，以将向下协商或中间人攻击的风险降至最低。
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.
此协商是安全的，因为消息完整性检查（MIC）覆盖了用于密码套件协商的整个EAP消息（见第3.2.7节）。协商的安全程度与用于导出MICs的KDF的安全性、KDF使用的共享秘密的长度和熵以及MICs的长度相称。
EAP-SAKE supports key derivation from a 32-byte Root Secret. The entropy of all other keys derived from it is reduced somewhat through the use of keyed hash functions (e.g. KDF). Thus, assuming optimistically that the effective key strength of the Root Secret is 32 bytes, the effective key strengths of the derived keys is at most the effective key strength of the Root Secret quantities they are derived from: EMSK, at most 16 bytes; MSK, at most 16 bytes.
EAP-SAKE支持从32字节的根密钥派生密钥。通过使用键控散列函数（例如KDF），从中导出的所有其他键的熵都会有所降低。因此，乐观地假设根秘密的有效密钥强度为32字节，则导出密钥的有效密钥强度至多为其从中导出的根秘密量的有效密钥强度：EMSK，至多16字节；MSK，最多16个字节。
This section provides the security claims as required by [EAP].
本节提供[EAP]要求的担保索赔。
[a] Mechanism: EAP-SAKE is a challenge/response authentication and key establishment mechanism based on a symmetric pre-shared secret.
[a] 机制：EAP-SAKE是一种基于对称预共享秘密的质询/响应认证和密钥建立机制。
[b] Security claims. EAP-SAKE provides:
[b] 担保索赔。EAP-SAKE提供：
Mutual authentication (Section 5.3)
相互认证（第5.3节）
Integrity protection (Section 5.4)
完整性保护（第5.4节）
Replay protection (Section 5.5)
重播保护（第5.5节）
Confidentiality (optional, Section 5.6 and Section 5.13)
保密性（可选，第5.6节和第5.13节）
Key derivation (Section 5.7)
密钥推导（第5.7节）
Dictionary attack protection (Section 5.8)
字典攻击保护（第5.8节）
Protected result indication of successful authentication from Server and from Peer (Section 5.10)
服务器和对等方成功认证的受保护结果指示（第5.10节）
Session independence (Section 5.12)
会议独立性（第5.12节）
[c] Key strength. EAP-SAKE supports key derivation with 256-bit effective key strength (Section 5.7)
[c] 关键力量。EAP-SAKE支持256位有效密钥强度的密钥派生（第5.7节）
[d] Description of key hierarchy: see Section 3.2.5.
[d] 密钥层次结构描述：见第3.2.5节。
[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] 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
[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] 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
[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 37482004年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标准-局域网/城域网特定要求-第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，“安全哈希标准”，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.Erenen，“网络接入标识符”，RFC 42822005年12月。
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]伊斯特莱克，D.，3，席勒，J.和S.克罗克，“安全的随机性要求”，BCP 106，RFC 4086，2005年6月。
Authors' Addresses
作者地址
Michaela Vanderveen Qualcomm Flarion Technologies 135 Rte. 202/206 South Bedminster, NJ 07921 USA
Michaela Vanderveen高通Flarion Technologies 135 Rte。202/206美国新泽西州南贝德明斯特07921
EMail: mvandervn@yahoo.com
EMail: mvandervn@yahoo.com
Hesham Soliman Qualcomm Flarion Technologies 135 Rte. 202/206 South Bedminster, NJ 07921 USA
Hesham Soliman高通Flarion Technologies 135 Rte。202/206美国新泽西州南贝德明斯特07921
EMail: solimanhs@gmail.com
EMail: solimanhs@gmail.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org/copyright.html中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。