因工作需要，所以拿来翻译，就当作仔细阅读RFC和锻炼翻译能力的一种过程。
如果有幸你也要用到此篇RFC的内容，希望能给你带来帮助。
同时在看过之后，若有我翻译不准或者你有更准的翻译，希望能留言。谢谢~
先摘取了中间重要的几节拿来翻译，后续还会慢慢补上所有的内容。
3. OWAMP-Control
The type of each OWAMP-Control message can be found after reading the
first 16 octets. The length of each OWAMP-Control message can be
computed upon reading its fixed-size part. No message is shorter
than 16 octets.
通过读取每一个OWAMP-Control消息的前16个字节可以识别出其类型。还可以通过读取
每个OWAMP-Control消息的固定大小部分计算出其消息长度。OWAMP-Control消息体
的长度必须是大于或等于16个字节。
An implementation SHOULD expunge unused state to prevent denial-of-
service attacks, or unbounded memory usage, on the server. For
example, if the full control message is not received within some
number of minutes after it is expected, the TCP connection associated
with the OWAMP-Control session SHOULD be dropped. In absence of
other considerations, 30 minutes seems like a reasonable upper bound.
在实现过程中服务器应当丢弃未使用的状态，以免遭受DOS攻击或者内存越界访问。
比如，在超过预期时间点的几分钟之内服务器没有收到完整的控制消息，那么与该
OWAMP-Control会话关联的TCP连接应当丢弃。通常考虑，30分钟是一个合理的上限。
3.1. Connection Setup
Before either a Control-Client or a Fetch-Client can issue commands
to a Server, it has to establish a connection to the server.
在Control-Client或者Fetch-Client给服务器发送命令前，它们之间必须先建立连接。
First, a client opens a TCP connection to the server on a well-known
port 861. The server responds with a server greeting:
首先，Client用默认的861端口打开一个TCP连接到服务器。接着服务器会对此连接进行
回应(greeting)。回应的消息如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Unused (12 octets) |
| |
|+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Modes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Challenge (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Salt (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (12 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following Mode values are meaningful: 1 for unauthenticated, 2
for authenticated, and 4 for encrypted. The value of the Modes field
sent by the server is the bit-wise OR of the mode values that it is
willing to support during this session. Thus, the last three bits of
the Modes 32-bit value are used. The first 29 bits MUST be zero. A
client MUST ignore the values in the first 29 bits of the Modes
value. (This way, the bits are available for future protocol
extensions. This is the only intended extension mechanism.)
模式字段支持的有：1.不鉴权，2.鉴权，3.加密。在服务器响应(greeting)的消息
中，模式字段(Modes)的内容是只在本次会话(session)期间模式所支持的那些内
容的按位或(or)的结果。因此，表示模式字段内容的32位值的最后3位是被使用上
的。前29位必须是零。那么对于Client，模式值的前29位必须被其忽略。（这样，
这些比特位被用在未来协议的扩展上。这也是唯一的扩展机制。）
Challenge is a random sequence of octets generated by the server; it
is used subsequently by the client to prove possession of a shared
secret in a manner prescribed below.
Challenge字段内容是由服务器产生的随机序列的字节；接下来Client会用其按照如
下描述的方式展现持有共有密钥的行为。
Salt and Count are parameters used in deriving a key from a shared
secret as described below.
通过Shared secret可以派生一个关键值，Salt和Count就是用于派生该关键值的参数。
Salt MUST be generated pseudo-randomly (independently of anything
else in this document).
Salt必须是一个伪随机数（独立于本文档中任何其它）
Count MUST be a power of 2. Count MUST be at least 1024. Count
SHOULD be increased as more computing power becomes common.
Count必须是某个数的2次方。Count值必须至少是1024。Count值的 增大越来
越平常，随着计算能力的越来越强。
If the Modes value is zero, the server does not wish to communicate
with the client and MAY close the connection immediately. The client
SHOULD close the connection if it receives a greeting with Modes
equal to zero. The client MAY close the connection if the client's
desired mode is unavailable.
如果Modes的值是零，那么就表示Server不希望与Client通信，并且 可能会立即
关闭与Client的连接。如果Client在收到的greeting消息中 的Modes的值是零，
那么就应该由Client关闭与Server的连接。如果 Client所需的Mode是无效的，那
么Client可能会关闭与Server的连接 。
Otherwise, the client MUST respond with the following Set-Up-Response
message:
反之，Client必须按照下述的步骤设置回应消息：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+
| Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+
| |
. .
. KeyID (80 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+
| |
. .
. Token (64 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+
| |
. .
. Client-IV (16 octets) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+
Here Mode is the mode that the client chooses to use during this
OWAMP-Control session. It will also be used for all OWAMP-Test
sessions started under control of this OWAMP-Control session. In
Mode, one or zero bits MUST be set within last three bits. If it is
one bit that is set within the last three bits, this bit MUST
indicate a mode that the server agreed to use (i.e., the same bit
MUST have been set by the server in the server greeting). The first
29 bits of Mode MUST be zero. A server MUST ignore the values of the
first 29 bits. If zero Mode bits are set by the client, the client
indicates that it will not continue with the session; in this case,
the client and the server SHOULD close the TCP connection associated
with the OWAMP-Control session.
在Client回应的消息中，Mode的内容是Client在同一次OWAMP- Control会话期间
所选用的模式。对于同一个OWAMP-Control会话控制下开始的所有的OWAMP-Test
会话用的也是这个Mode值。设置Mode时，最后3位中1或者0位必须被设置。如果在
最后3位中1位被设置，那么该位必须标明Server所支持的Mode（即，在Server的
greeting回应消息中Server必须同样在该位设置）。Mode的前29位必须设置为零。
做为Server必须忽略掉前29位的内容。如果Client设置的是0位，那么就表示Client
将结束此次会话；在这种情况下意味着，Client和Server应当关闭本次OWAMP-Control
会话的TCP连接。
In unauthenticated mode, KeyID, Token, and Client-IV are unused.
Otherwise, KeyID is a UTF-8 string, up to 80 octets in length (if the
string is shorter, it is padded with zero octets), that tells the
server which shared secret the client wishes to use to authenticate
or encrypt, while Token is the concatenation of a 16-octet challenge,
a 16-octet AES Session-key used for encryption, and a 32-octet HMAC-
SHA1 Session-key used for authentication. The token itself is
encrypted using the AES (Advanced Encryption Standard) [AES] in
Cipher Block Chaining (CBC). Encryption MUST be performed using an
Initialization Vector (IV) of zero and a key derived from the shared
secret associated with KeyID. (Both the server and the client use
the same mappings from KeyIDs to shared secrets. The server, being
prepared to conduct sessions with more than one client, uses KeyIDs
to choose the appropriate secret key; a client would typically have
different secret keys for different servers. The situation is
analogous to that with passwords.)
在不鉴权模式中， KeyID 、 Token 和 Client-IV 字段是不用到的。如果用到了就表明
Client告诉Server期望是鉴权模式，Client通过使用Shared secret进行鉴权或者加密。
KeyID字段是UTF-8编码的字符串，最大支持80个字节的长度（如果KeyID的内容不足80
字节，剩余就用零填充），Token字段是以下几个内容的串接：16字节的Challenge，用
于加密的16字节的AES Session-key以及用于鉴权的32位的HMAC-SHA1 Session-key。
Token内容本身，即上述的3种串接的密码块（Cipher Block Chaining）是用AES
(Advanced Encryption Standard)加密过的。加密时要用到2样参数，一个是全是零的
初始化向量（Initialization Vector）和一个Key，key是从与KeyID关联的shared secret
派生来的。（Server和Client用的是同一个从KeyIDs到shared secrets的映射。Server
为准备执行与多个Client之间的会话，通过用KeyIDs来选择合适对应的Secret key。一个
Client通常为不同的Server持有不同的Secret key。此情形与用密码的相似）。
The shared secret is a passphrase; it MUST not contain newlines. The
secret key is derived from the passphrase using a password-based key
derivation function PBKDF2 (PKCS #5) [RFC2898]. The PBKDF2 function
requires several parameters: the PRF is HMAC-SHA1 [RFC2104]; the salt
and count are as transmitted by the server.
可以把Shared secret看成一种口令，口令中一定不能包含换行符。Secret key是用
一种通过基于密钥的派生算法（PBKDF2——PKCS #5 [RFC2898]）产生的。PBKDF2
算法需要这样一些参数：the PRF is HMAC-SHA1 [RFC2104]; 以及从Server端传递的salt和count。
AES Session-key, HMAC Session-key and Client-IV are generated
randomly by the client. AES Session-key and HMAC Session-key MUST be
generated with sufficient entropy not to reduce the security of the
underlying cipher [RFC4086]. Client-IV merely needs to be unique
(i.e., it MUST never be repeated for different sessions using the
same secret key; a simple way to achieve that without the use of
cumbersome state is to generate the Client-IV values using a
cryptographically secure pseudo-random number source: if this is
done, the first repetition is unlikely to occur before 2^64 sessions
with the same secret key are conducted).
AES Session-key, HMAC Session-key and Client-IV的值是Client随机产生的。
AES Session-key and HMAC Session-key的产生是通过充分无序排列来避免降
低相关密码的安全性[RFC4086]。Client-IV必须是唯一的。（即，对于使用同一个
Secret key的不同的会话中，Client-IV一定不能重复；若想省去上述繁琐的步骤达到
同样的目的，一个简单的做法是通过使用一个加密过的伪随机数生成Client-IV的值：
这样做，对于同一个Secret key在执行完2^64个会话之前是不会发生出现重复的Client-IV）
The server MUST respond with the following Server-Start message:
Server必须按照以下的格式做为服务启动消息来回应：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MBZ (15 octets) |
| |
| +-+-+-+-+-+-+-+-+
| | Accept |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Server-IV (16 octets) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start-Time (Timestamp) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MBZ (8 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The MBZ parts MUST be zero. The client MUST ignore their value. MBZ
(MUST be zero) fields here and after have the same semantics: the
party that sends the message MUST set the field so that all bits are
equal to zero; the party that interprets the message MUST ignore the
value. (This way, the field could be used for future extensions.)
MBZ部分必须是零。Client必须忽略这些值。这里说的MBZ字段和之后提到的是同
一个含义：发送回应消息时这部分的内容必须设置，所以将其全部设置成零；这就是
说这部分的值必须忽略掉。（这样，该字段用作扩展功能在将来。）
Server-IV is generated randomly by the server. In unauthenticated
mode, Server-IV is unused.
Server-IV是由Server随机产生的。在不鉴权模式下，Server-IV是不用到的。
The Accept field indicates the server's willingness to continue
communication. A zero value in the Accept field means that the
server accepts the authentication and is willing to conduct further
transactions. Non-zero values indicate that the server does not
accept the authentication or, for some other reason, is not willing
to conduct further transactions in this OWAMP-Control session. The
full list of available Accept values is described in Section 3.3,
"Values of the Accept Field".
Accept字段用来表示Server是否愿意继续通讯。如果Accept的内容是0表明
Server接受鉴权并希望有进一步的消息通讯。Accept如果是非0,表示Server
不接受鉴权，或者因为其它原因，总之Server不希望在本次OWAMP-Control
会话中有进一步的通讯。查看完整的Accept值列表在3.3部分描述。
If a negative (non-zero) response is sent, the server MAY (and the
client SHOULD) close the connection after this message.
如果Accept是负值，表明Server可能（Client应该）在发送完该消息后，会关闭此连接。
Start-Time is a timestamp representing the time when the current
instantiation of the server started operating. (For example, in a
multi-user general purpose operating system, it could be the time
when the server process was started.) If Accept is non-zero, Start-
Time SHOULD be set so that all of its bits are zeros. In
authenticated and encrypted modes, Start-Time is encrypted as
described in Section 3.4, "OWAMP-Control Commands", unless Accept is
non-zero. (Authenticated and encrypted mode cannot be entered unless
the control connection can be initialized.)
Start-Time是表示当前Server开始运作的时间戳。（比如，在多用户操作系统中，
该时间戳就表示Server进程的开始的时间。）如果Accept是非0的，Start-Time所有
位应该都设置成0。在鉴权和加密模式中，Start-Time字段会被按照3.4部分
“OWAMP-Control Commands”所描述的方式加密，除非Accept字段是非0。
（鉴权和加密模式不会继续，除非控制连接能被初始化。）
Timestamp format is described in Section 4.1.2. The same
instantiation of the server SHOULD report the same exact Start-Time
value to each client in each session.
Start-Time格式请参考4.1.2部分的内容。同一个Server实例应该在每个会话中对
每个Client回报同样的准确的时间戳值。
The previous transactions constitute connection setup.
上述的步骤就是连接过程。
3.2. Integrity Protection (HMAC)
Authentication of each message (also referred to as a command in this
document) in OWAMP-Control is accomplished by adding an HMAC to it.
The HMAC that OWAMP uses is HMAC-SHA1 truncated to 128 bits. Thus,
all HMAC fields are 16 octets. An HMAC needs a key. The HMAC
Session-key is communicated along with the AES Session-key during
OWAMP-Control connection setup. The HMAC Session-key SHOULD be
derived independently of the AES Session-key (an implementation, of
course, MAY use the same mechanism to generate the random bits for
both keys). Each HMAC sent covers everything sent in a given
direction between the previous HMAC (but not including it) and up to
the beginning of the new HMAC. This way, once encryption is set up,
each bit of the OWAMP-Control connection is authenticated by an HMAC
exactly once.
在OWAMP-Control中每一个消息（可以做为命令参考本文档）是通过添加HMAC鉴权的。
OWAMP用的HMAC是HMAC-SHA1的128位的缩短版。因此，所有的HMAC字段都是16个字节。
在OWAMP-Control连接设置期间，HMAC Session-key与AES Session-key有关联。
HMAC Session-key的派生应该独立于AES Session-key。（实现过程可能会用同样的机制为
上述2种keys分别产生随机的值。）在前一个HMAC（但不包括）与一开始的新的HMAC之间这样
一个给定的路径上，每次发送的HMAC都覆盖了该给定路径上的每一个的发送。这样，一旦加了密，
OWAMP-Control连接的每一位都是通过HMAC精确的鉴权的。
When encrypting, authentication happens before encryption, so HMAC
blocks are encrypted along with the rest of the stream. When
decrypting, the order, of course, is reversed: first one decrypts,
then one checks the HMAC, then one proceeds to use the data.
当加密时，在加密之前会先进行鉴权的，所以HMAC块是与剩余流一起加密的。
在加密的时候，顺序的相反的：先解密，接着检查HMAC，然后处理数据。
The HMAC MUST be checked as early as possible to avoid using and
propagating corrupt data.
必须尽可能早的检查HMAC，避免使用和被别处引用了坏数据。
In open mode, the HMAC fields are unused and have the same semantics
as MBZ fields.
在Open Mode下，HMAC字段与MBZ字段一样都设置成零，且不用到的。
本文详细介绍了OWAMP-Control连接的建立过程，包括服务器的问候消息、客户端的回应消息及服务器启动消息等关键步骤，并阐述了消息的鉴权方式。
扫一扫
1065
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
