Technical Summary
With growing availability of good time sources to network nodes, it
becomes increasingly possible to measure one-way IP performance metrics
with high precision. To do so in an interoperable manner, a common
protocol for such measurements is required. The One-Way Active
Measurement Protocol (OWAMP) can measure one-way delay, as well as
other unidirectional characteristics, such as one-way loss. This document
is an implementation of the requirements draft (RFC 3763) published
earlier.
Working Group Summary
The working group extensively worked on requirements for this
protocol (which were approved by the IESG in 2004 and published
as RFC 3763), and in general, developed this protocol for
about three years, with a great deal of participation and
discussion from experience. The decision to advance had
strong working group support. There were no IETF Last Call
comments.
Protocol Quality
Three implementations of the protocol exist, a forth h site has indicated
that they will implement this. This protocol sits on top of IPPM metrics
(RFC2330, 2678-2681). The group of users of these metrics have all
expressed interest in this protocol.
The security section of RFC3763 took a long time to complete. In order
to make sure that this document met the security requirements set for
in that document, a security review has been done by Sam Weiler. His
comments have been incorporated. The Responsible Area Director also
reviewed the document against RFC 3763, and the shepherding Chair,
Henk Uijterwaal, reviewed the detailed security support.
There was extensive work with one of the Security Area Directors, Russ
Housley, to ensure that the security protocols were valid.
Henk Uitjerwaal has shepherded this specification.
Notes to the RFC Editor
[a final issue of the Security review]
Section 3.1, Connection Setup
OLD:
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
and a 16-octet Session-key, 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.)
NEW:
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 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.)
OLD:
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.
Session-key and Client-IV are generated randomly by the client.
Session-key MUST be generated with sufficient entropy not to reduce
the security of the underlying cipher [RFC4086].
NEW:
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.
The AES Session-key, HMAC Session-key and Client-IV are generated
randomly by the client. The AES Session-key and HMAC
Session-key MUST be generated with sufficient entropy not to reduce
the security of the underlying cipher [RFC4086].
-----------
Section 3.2, Integrity Protection (HMAC)
OLD:
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 same key
used for AES encryption is used for HMAC authentication. 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.
NEW:
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.
-----------
Section 3.4, OWAMP-Control Commands
OLD:
In authenticated or encrypted mode (which are identical as far as
OWAMP-Control is concerned, and only differ in OWAMP-Test) all
further communications are encrypted with the Session-key, using CBC
mode. The client encrypts everything it sends through the just-
established OWAMP-Control connection using stream encryption with
Client-IV as the IV. Correspondingly, the server encrypts its side
of the connection using Server-IV as the IV.
NEW:
In authenticated or encrypted mode (which are identical as far as
OWAMP-Control is concerned, and only differ in OWAMP-Test) all further
communications are encrypted with the AES Session-key (using CBC mode)
and authenticated with the HMAC Session-key. The client encrypts
encrypts everything it sends through the just-established
OWAMP-Control connection using stream encryption with Client-IV
as the IV. Correspondingly, the server encrypts its side of the
connection using Server-IV as the IV.
OLD:
The two streams (one going from the client to the server and one
going back) are encrypted independently, each with its own IV, but
using the same key (the session key).
NEW:
The two streams (one going from the client to the server and one
going back) are encrypted independently, each with its own IV, but
using the same key (the AES Session-key).
----------
Section 4.1.2, OWAMP-Test Packet Format and Content
OLD:
The key to use is obtained as follows: the 16-octet session identifier
(SID) is encrypted with the same session key as is used for the
corresponding OWAMP-Control session (where it is used in a different
chaining mode); this is a single-block ECB encryption; its result is
the key to use in encrypting (and decrypting) the packets of the
particular OWAMP-Test session.
NEW:
[Replace the one paragraph above with the following three new
paragraphs:]
Similarly to each OWAMP-Control session, each OWAMP-Test session has
two keys: an AES Session-key and an HMAC Session-key. There is a
difference in how the keys are obtained, however: in the case of
OWAMP-Control, the keys are generated by the client and communicated
(as part of the Token) during connection setup as part of
Set-Up-Response message; in the case of OWAMP-Test, described here,
the keys are derived from the OWAMP-Control keys and the SID.
The OWAMP-Test AES Session-key is obtained as follows: the
OWAMP-Control AES Session-key (the same AES Session-key as is used for
the corresponding OWAMP-Control session, where it is used in a
different chaining mode) is encrypted, using AES, with the 16-octet
session identifier (SID) as the key; this is a single-block ECB
encryption; its result is the OWAMP-Test AES Session-key to use in
encrypting (and decrypting) the packets of the particular OWAMP-Test
session. Note that all of OWAMP-Test AES Session-key, OWAMP-Control
AES Session-key, and the SID are comprised of 16 octets.
The OWAMP-Test HMAC Session-key is obtained as follows: the
OWAMP-Control HMAC Session-key (the same HMAC Session-key as is used
for the corresponding OWAMP-Control session) is encrypted, using AES,
with the 16-octet session identifier (SID) as the key; this is a
two-block CBC encryption, always performed with IV=0; its result is
the OWAMP-Test HMAC Session-key to use in authenticating the packets
of the particular OWAMP-Test session. Note that all of OWAMP-Test
HMAC Session-key and OWAMP-Control HMAC Session-key are comprised of
32 octets, while the SID is 16 octets.
OLD:
In encrypted mode, the first two blocks (32 octets) are encrypted
using AES CBC mode. The key to use is obtained in the same way as
NEW:
In encrypted mode, the first two blocks (32 octets) are encrypted
using AES CBC mode. The AES Session-key to use is obtained in the
same way as
OLD:
In OWAMP-Test HMAC is not encrypted (note that this is different from
OWAMP-Control, where encryption is stream mode is used, so everything
including the HMAC blocks ends up being encrypted). The key for HMAC
(authentication) is the same as the key for AES (encryption).
NEW:
In OWAMP-Test HMAC is not encrypted (note that this is different from
OWAMP-Control, where encryption in stream mode is used, so everything
including the HMAC blocks ends up being encrypted).