The IESG has approved the following document: - 'A One-way Active Measurement Protocol (OWAMP) ' <draft-ietf-ippm-owdp-16.txt> as a Proposed Standard This document is the product of the IP Performance Metrics Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-owdp-16.txt 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). _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
