[ippm] draft-ietf-ippm-owdp-11.txt security

[stanislav shalunov <[e-mail]>]

Sam,

Thank you very much for the in-person security review of the OWAMP
specification on Friday at the last IETF meeting in Washington.

During the security review, two potential problem areas were
identified: user authentication in OWAMP-Control and packet
authentication in authenticated mode in OWAMP-Test.  Before making any
changes to the protocol, I would like to write down my understanding
of the potential weaknesses and make sure this understanding is
shared.

In re user authentication in OWAMP-Control: in the current
specification, user authentication consists of (i) session key
establishment; (ii) using the session key subsequently to make
requests.  Let us talk about the two separately.

(i) Session key establishment consists of the server issuing a
challenge and the client encrypting the challenge with the master key
(the shared secret) along with a session key.  I believe this to be
the technique of protocol 2 (key transport with challenge-response) in
section 12.3.1(i) of the Handbook of Applied Cryptography (HAC) by
Menezes et al.  This protocol is described as follows:

        A <- B: n_B                     (1)
        A -> B: E_K(r_A, n_B, B*)       (2)

where the star next to B in step 2 denotes an optional parameter.  The
optional parameter (the addressee of the message) is not used in the
specification.  The optional field may be used to prevent reflection
attack described as attack 2 in section 12.9.1 of the HAC.  The
reflection attack does not appear to be applicable to the OWAMP
specification, as it requires the client to run a server that would
authenticate the (original) server using the same master key.  In
other words, the defence against the reflection attack is, in the
terms of HAC, ``using distinct keys K and K' for encryptions from A to
B and B to A, respectively.''

(ii) Using the session key to make requests does not appear to be
vulnerable, even though no redundancy is inherent in the initial
exchange as the necessary redundancy is contained in the protocol
messages.

It thus appear to me that no change to the user authentication part of
OWAMP is warranted.  Do you agree?

In re packet authentication in authenticated mode of OWAMP-Test: the
authentication token of each packet is its sequence number encrypted
with redundancy using the same session key as that used in the
OWAMP-Control session that spawned the OWAMP-Test session.

The threat model is as follows: both the client and the server wish to
cooperate to produce trustworthy measurement results.  The attacker,
who does not know the master key associated with the pair <server,
client's user name>, can observe traffic, modify it, hold it, replay
it, initiate sessions (both OWAMP-Control and OWAMP-Test) with the
same server using a different user name, and, of course, initiate
sessions with different servers (which would have unrelated user name
namespace and unrelated secrets).  The attacker is to be positively
prevented from initiating sessions with the server using the client's
credentials.  In authenticated mode, the timestamp is in the clear
with no protection, so the attacker can modify that at will; he can
also delay packets or replay them.

The potential problem is related to the fact that the key used to
encrypt the sequence number with redundancy is the same for all
OWAMP-Test sessions spawned by the same OWAMP-Control session.  Thus,
an attacker observing packets from different sessions might be able to
switch the authenticators and inject extra traffic.  Since an attacker
is already able to replay packets after observing them (possibly with
different timestamps, at attacker's option), even if the packets are
lost subsequently to the observation, he can perform the following
attack: by observing packets from one OWAMP-Test session (and guessing
the sequence numbers, which might be easier if the stream is periodic
than if it is, e.g., Poisson) and using the authenticators from these
packets in the packets that belong to a different OWAMP-Test session
spawned by the same OWAMP-Control session, the attacker can make
packets arrive sooner than they otherwise would (loss, for the
purposes of this attack, is a special case of very long delay).  For
example, an attacker might sit very close to, e.g., the client and
have the ability to observe and modify traffic; the client and the
server might start two periodic sessions, one in each directions; the
attacker would then be able to use packets from the session where the
client is the sender to completely generate packets from the session
where the server is the sender, and have them delivered at any time
the attacker chooses with timestamps that the attacker chooses.

Note: while during the security review this weakness was mentioned
only in the context of authenticated mode, encrypted mode is similarly
vulnerable, with the obvious change in attacker's abilities (namely,
the attacker can, under the same circumstances as in the case of the
authenticated mode, make packets arrive earlier than they otherwise
would, but he, differing from the case of authenticated mode, cannot
change the original timestamps in the packets from the different
session; while this limits the utility of the attack, the attack is
still there).

With respect to the second problem, I propose the following
resolution: replace the use of the OWAMP-Control session key K in
OWAMP-Test (both encrypted and authenticate mode) with a key that is
unique to the particular OWAMP-Test session, AES_K(SID) (the 16-octet
session identifier encrypted with AES in ECB mode using the session
key from the OWAMP-Control session spawning the OWAMP-Test session).
Do you see any problems with this?

Thank you again for the review and your involvement with OWAMP,

-- 
Stanislav Shalunov		http://www.internet2.edu/~shalunov/

Sex is the mathematics urge sublimated.                 -- M. C. Reed.

_______________________________________________
ippm mailing list
[e-mail] 
https://www1.ietf.org/mailman/listinfo/ippm