[ippm] Protocol Action: 'A One-way Active Measurement Protocol (OWAMP)' to Proposed Standard

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).

_______________________________________________
ippm mailing list
ippm@ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm