e.g., new more secure ciphers if they are needed).
Should a cipher with a different key size (say, a 256-bit key) become
needed, a new key derivation function for OWAMP-Test keys would also
be needed. The semantics of change in the cipher SHOULD then in the
future be tied to the semantics of change in the key derivation
function (KDF). One KDF that might be considered for the purpose
might be a pseudo-random function (PRF) with appropriately sized
output, such as 256 bits (perhaps HMAC-SHA256, if it is then still
considered a secure PRF), which could then be used to derive the
OWAMP-Test session keys from the OWAMP-Control session key by using
the OWAMP-Control session key as the HMAC key and the SID as HMAC
message.
Note that the replacement scheme outlined above is trivially
susceptible to downgrade attacks: a malicious party in the middle can
flip modes bits as the mode is negotiated so that the oldest and
weakest mode supported by the two parties is used. If this is deemed
problematic at the time of cryptographic primitive replacement, the
scheme might be augmented with a measure to prevent such an attack
(by perhaps exchanging the modes again once a secure communications
channel is established, comparing the two sets of mode words, and
dropping the connection should they not match).
6.8. Long-term Manually Managed Keys
OWAMP-Control uses long-term keys with manual management. These keys
are used to automatically negotiate session keys for each OWAMP-
Control session running in authenticated or encrypted mode. The
number of these keys managed by a server scales linearly with (and,
in fact, is equal to) the number of administratively different users
(perhaps particular humans, roles, or robots representing sites) that
need to connect to this server. Similarly, the number of different
manual keys managed by each client is the number of different servers
that the client needs to connect to. This use of manual long-term
keys is compliant with [BCP107].
6.9. (Not) Using Time as Salt
A natural idea is to use the current time as salt when deriving
session keys. Unfortunately, this appears to be too limiting.
Although OWAMP is often run on hosts with well-synchronized clocks,
it is also possible to run it on hosts with clocks completely
untrained. The delays obtained thus are, of course, not directly
usable; however, some metrics, such as unidirectional loss,
reordering, measures of congestion such as the median delay minus
minimum, and many others are usable directly and immediately (and
improve upon the information that would have been provided by a
round-trip measurement). Further, even delay information can be
useful with appropriate post-processing. Indeed, one can even argue
that running the clocks free and post-processing the results of a
mesh of measurements will result in better accuracy, as more
information is available a posteriori and correlation of data from
different hosts is possible in post-processing, but not with online
clock training.
Given this, time is not used as salt in key derivation.
6.10. The Use of AES-CBC and HMAC
OWAMP relies on AES-CBC for confidentiality and on HMAC-SHA1
truncated to 128 bits for message authentication. Random IV choice
is important for prevention of a codebook attack on the first block
(it should also be noted that, with its 128-bit block size, AES is
more resistant to codebook attacks than are ciphers with shorter
blocks; we use random IV anyway).
HMAC MUST verify. It is crucial to check for this before using the
message; otherwise, existential forgery becomes possible. The
complete message for which HMAC verification fails MUST be discarded
(both for short messages consisting of a few blocks and potentially
for long messages, such as a response to the Fetch-Session command).
If such a message is part of OWAMP-Control, the connection MUST be
dropped.
Since OWAMP messages can have different numbers of blocks, the
existential forgery attack described in example 9.62 of [MENEZES]
becomes a concern. To prevent it (and to simplify implementation),
the length of any message becomes known after decrypting its first
block.
A special case is the first (fixed-length) message sent by the
client. There, the token is a concatenation of the 128-bit challenge
(transmitted by the server in the clear), a 128-bit AES Session-key
(generated randomly by the client, encrypted with AES-CBC with IV=0),
and a 256-bit HMAC-SHA1 Session-key used for authentication. Since
IV=0, the challenge (a single cipher block) is simply encrypted with
the secret key. Therefore, we rely on resistance of AES to chosen
plaintext attacks (as the challenge could be substituted by an
attacker). It should be noted that the number of blocks of chosen
plaintext an attacker can have encrypted with the secret key is
limited by the number of sessions the client wants to initiate. An
attacker who knows the encryption of a server’s challenge can produce
an existential forgery of the session key and thus disrupt the
session; however, any attacker can disrupt a session by corrupting
the protocol messages in an arbitrary fashion. Therefore, no new
threat is created here; nevertheless, we require that the server
never issues the same challenge twice. (If challenges are generated
randomly, a repetition would occur, on average, after 2^64 sessions;
we deem this satisfactory as this is enough even for an implausibly
busy server that participates in 1,000,000 sessions per second to go
without repetitions for more than 500 centuries.) With respect to
the second part of the token, an attacker can produce an existential
forgery of the session key by modifying the second half of the
client’s token while leaving the first part intact. This forgery,
however, would be immediately discovered by the client when the HMAC
on the server’s next message (acceptance or rejection of the
connection) does not verify.
7. Acknowledgements
We would like to thank Guy Almes, Mark Allman, Jari Arkko, Hamid
Asgari, Steven Van den Berghe, Eric Boyd, Robert Cole, Joan
Cucchiara, Stephen Donnelly, Susan Evett, Sam Hartman, Kaynam
Hedayat, Petri Helenius, Scott Hollenbeck, Russ Housley, Kitamura
Yasuichi, Daniel H. T. R. Lawson, Will E. Leland, Bruce A. Mah,
Allison Mankin, Al Morton, Attila Pasztor, Randy Presuhn, Matthew
Roughan, Andy Scherrer, Henk Uijterwaal, and Sam Weiler for their
comments, suggestions, reviews, helpful discussion and proof-reading.
8. IANA Considerations
IANA has allocated a well-known TCP port number (861) for the OWAMP-
Control part of the OWAMP protocol.
9. Internationalization Considerations
The protocol does not carry any information in a natural language,
with the possible exception of the KeyID in OWAMP-Control, which is
encoded in UTF-8.
10. References
10.1. Normative References
[AES] Advanced Encryption Standard (AES),
http://csrc.nist.gov/encryption/aes/
[BCP107] Bellovin, S. and R. Housley, "Guidelines for
Cryptographic Key Management", BCP 107, RFC 4107,
June 2005.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
"Framework for IP Performance Metrics", RFC 2330, May
1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-
way Delay Metric for IPPM", RFC 2679, September 1999.
[RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-
way Packet Loss Metric for IPPM", RFC 2680, September
1999.
[RFC2836] Brim, S., Carpenter, B., and F. Le Faucheur, "Per Hop
Behavior Identification Codes", RFC 2836, May 2000.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000.
10.2. Informative References
[APAN] Z. Shu and K. Kobayashi, "HOTS: An OWAMP-Compliant
Hardware Packet Timestamper", In Proceedings of PAM
2005, http://www.springerlink.com/index/
W4GBD39YWC11GQTN.pdf
[BRIX] Brix Networks, http://www.brixnet.com/
[ZIGG] J. H. Ahrens, U. Dieter, "Computer methods for
sampling from the exponential and normal
distributions", Communications of ACM, volume 15,
issue 10, 873-882, 1972.
http://doi.acm.org/10.1145/355604.361593
[MENEZES] A. J. Menezes, P. C. van Oorschot, and S. A.
Vanstone, Handbook of Applied Cryptography, CRC
Press, revised reprint with updates, 1997.
[KNUTH] D. Knuth, The Art of Computer Programming, vol.2, 3rd
edition, 1998.
[Abilene] One-way Latency Measurement (OWAMP),
http://e2epi.internet2.edu/owamp/
[RIJN] Reference ANSI C Implementation of Rijndael,
http://www.esat.kuleuven.ac.be/~rijmen/
rijndael/rijndaelref.zip
[RIPE] RIPE NCC Test-Traffic Measurements home,
http://www.ripe.net/test-traffic/.
[SURVEYOR] Surveyor Home Page,
http://www.advanced.org/surveyor/.
[SURVEYOR-INET] S. Kalidindi and M. Zekauskas, "Surveyor: An
Infrastructure for Network Performance Measurements",
Proceedings of INET’99, June 1999.
http://www.isoc.org/inet99/proceedings/4h/4h_2.htm
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC
1305, March 1992.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D.,
Mikkelsen, J., and T. Wright, "Transport Layer
Security (TLS) Extensions", RFC 3546, June 2003.
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
Appendix A: Sample C Code for Exponential Deviates
The values in array Q[] are the exact values that MUST be used by all
implementations (see Sections 5.1 and 5.2). This appendix only
serves for illustrative purposes.
/*
** Example usage: generate a stream of exponential (mean 1)
** random quantities (ignoring error checking during initialization).
** If a variate with some mean mu other than 1 is desired, the output
** of this algorithm can be multiplied by mu according to the rules
** of arithmetic we described.
** Assume that a 16-octet ’seed’ has been initialized
** (as the shared secret in OWAMP, for example)
** unsigned char seed[16];
** OWPrand_context next;
** (initialize state)
** OWPrand_context_init(&next, seed);
** (generate a sequence of exponential variates)
** while (1) {
** u_int64_t num = OWPexp_rand64(&next);
<do something with num here>
...
** }
*/
#include <stdlib.h>
typedef u_int64_t u_int64_t;
/* (K - 1) is the first k such that Q[k] > 1 - 1/(2^32). */
#define K 12
#define BIT31 0x80000000UL /* See if first bit in the lower
32 bits is zero. */
#define MASK32(n) ((n) & 0xFFFFFFFFUL)
#define EXP2POW32 0x100000000ULL
typedef struct OWPrand_context {
unsigned char counter[16];/* Counter (network byte order).*/
keyInstance key; /* Key to encrypt the counter.*/
unsigned char out[16]; /* The encrypted block.*/
} OWPrand_context;
/*
** The array has been computed according to the formula:
**
** Q[k] = (ln2)/(1!) + (ln2)^2/(2!) + ... + (ln2)^k/(k!)
**
** as described in algorithm S. (The values below have been
** multiplied by 2^32 and rounded to the nearest integer.)
** These exact values MUST be used so that different implementation
** produce the same sequences.
*/
static u_int64_t Q[K] = {
0, /* Placeholder - so array indices start from 1. */
0xB17217F8,
0xEEF193F7,
0xFD271862,
0xFF9D6DD0,
0xFFF4CFD0,
0xFFFEE819,
0xFFFFE7FF,
0xFFFFFE2B,
0xFFFFFFE0,
0xFFFFFFFE,
0xFFFFFFFF
};
/* this element represents ln2 */
#define LN2 Q[1]
/*
** Convert an unsigned 32-bit integer into a u_int64_t number.
*/
u_int64_t
OWPulong2num64(u_int32_t a)
{
return ((u_int64_t)1 << 32) * a;
}
/*
** Arithmetic functions on u_int64_t numbers.
*/
/*
** Addition.
*/
u_int64_t
OWPnum64_add(u_int64_t x, u_int64_t y)
{
return x + y;
}
/*
** Multiplication. Allows overflow. Straightforward implementation
** of Algorithm 4.3.1.M (p.268) from [KNUTH].
*/
u_int64_t
OWPnum64_mul(u_int64_t x, u_int64_t y)
{
unsigned long w[4];
u_int64_t xdec[2];
u_int64_t ydec[2];
int i, j;
u_int64_t k, t, ret;
xdec[0] = MASK32(x);
xdec[1] = MASK32(x>>32);
ydec[0] = MASK32(y);
ydec[1] = MASK32(y>>32);
for (j = 0; j < 4; j++)
w[j] = 0;
for (j = 0; j < 2; j++) {
k = 0;
for (i = 0; ; ) {
t = k + (xdec[i]*ydec[j]) + w[i + j];
w[i + j] = t%EXP2POW32;
k = t/EXP2POW32;
if (++i < 2)
continue;
else {
w[j + 2] = k;
break;
}
}
}
ret = w[2];
ret <<= 32;
return w[1] + ret;
}
/*
** Seed the random number generator using a 16-byte quantity ’seed’
** (== the session ID in OWAMP). This function implements step U1
** of algorithm Unif.
*/
void
OWPrand_context_init(OWPrand_context *next, unsigned char *seed)
{
int i;
/* Initialize the key */
rijndaelKeyInit(next->key, seed);
/* Initialize the counter with zeros */
memset(next->out, 0, 16);
for (i = 0; i < 16; i++)
next->counter[i] = 0UL;
}
/*
** Random number generating functions.
*/
/*
** Generate and return a 32-bit uniform random value (saved in the
**less significant half of the u_int64_t). This function implements
**steps U2-U4 of the algorithm Unif.
*/
u_int64_t
OWPunif_rand64(OWPrand_context *next)
{
int j;
u_int8_t *buf;
u_int64_t ret = 0;
/* step U2 */
u_int8_t i = next->counter[15] & (u_int8_t)3;
if (!i)
rijndaelEncrypt(next->key, next->counter, next->out);
/* Step U3. Increment next.counter as a 16-octet single
quantity in network byte order for AES counter mode. */
for (j = 15; j >= 0; j--)
if (++next->counter[j])
break;
/* Step U4. Do output. The last 4 bytes of ret now contain
the random integer in network byte order */
buf = &next->out[4*i];
for (j=0; j<4; j++) {
ret <<= 8;
ret += *buf++;
}
return ret;
}
/*
** Generate an exponential deviate with mean 1.
*/
u_int64_t
OWPexp_rand64(OWPrand_context *next)
{
unsigned long i, k;
u_int32_t j = 0;
u_int64_t U, V, J, tmp;
/* Step S1. Get U and shift */
U = OWPunif_rand64(next);
while ((U & BIT31) && (j < 32)) { /* Shift until first 0. */
U <<= 1;
j++;
}
/* Remove the 0 itself. */
U <<= 1;
U = MASK32(U); /* Keep only the fractional part. */
J = OWPulong2num64(j);
/* Step S2. Immediate acceptance? */
if (U < LN2) /* return (j*ln2 + U) */
return OWPnum64_add(OWPnum64_mul(J, LN2), U);
/* Step S3. Minimize. */
for (k = 2; k < K; k++)
if (U < Q[k])
break;
V = OWPunif_rand64(next);
for (i = 2; i <= k; i++) {
tmp = OWPunif_rand64(next);
if (tmp < V)
V = tmp;
}
/* Step S4. Return (j+V)*ln2 */
return OWPnum64_mul(OWPnum64_add(J, V), LN2);
}
Appendix B: Test Vectors for Exponential Deviates
It is important that the test schedules generated by different
implementations from identical inputs be identical. The non-trivial
part is the generation of pseudo-random exponentially distributed
deviates. To aid implementors in verifying interoperability, several
test vectors are provided. For each of the four given 128-bit values
of SID represented as hexadecimal numbers, 1,000,000 exponentially
distributed 64-bit deviates are generated as described above. As
they are generated, they are all added to each other. The sum of all
1,000,000 deviates is given as a hexadecimal number for each SID. An
implementation MUST produce exactly these hexadecimal numbers. To
aid in the verification of the conversion of these numbers to values
of delay in seconds, approximate values are given (assuming
lambda=1). An implementation SHOULD produce delay values in seconds
that are close to the ones given below.
SID = 0x2872979303ab47eeac028dab3829dab2
SUM[1000000] = 0x000f4479bd317381 (1000569.739036 seconds)
SID = 0x0102030405060708090a0b0c0d0e0f00
SUM[1000000] = 0x000f433686466a62 (1000246.524512 seconds)
SID = 0xdeadbeefdeadbeefdeadbeefdeadbeef
SUM[1000000] = 0x000f416c8884d2d3 (999788.533277 seconds)
SID = 0xfeed0feed1feed2feed3feed4feed5ab
SUM[1000000] = 0x000f3f0b4b416ec8 (999179.293967 seconds)
Authors’ Addresses
Stanislav Shalunov
Internet2
1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48104
EMail: shalunov@internet2.edu
WWW: http://www.internet2.edu/~shalunov/
Benjamin Teitelbaum
Internet2
1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48104
EMail: ben@internet2.edu
WWW: http://people.internet2.edu/~ben/
Anatoly Karp
Computer Sciences Department
University of Wisconsin-Madison
Madison, WI 53706
EMail: akarp@cs.wisc.edu
Jeff W. Boote
Internet2
1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48104
EMail: boote@internet2.edu
Matthew J. Zekauskas
Internet2
1000 Oakbrook Drive, Suite 300
Ann Arbor, MI 48104
EMail: matt@internet2.edu
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
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 AND THE INTERNET