Subject: [MSEC] MIKEY mapping of keys to steams -- possible vulnerability

From: Brian Weis <[email-masked]>
Date: Mon, 07 Jan 2002 12:04:04 -0800

I have a question on how MIKEY accurately maintains a mapping of keys to
audio/video streams in an SDP specification. I've given my understanding
of how this happens so you can check my assumptions, and then I suggest
a possibly vulnerability.

MIKEY specifies a new concept of "crypto session id" which it uses to
label media streams which are later defined in an SDP description The
crypto session id is a logical identity where the first media session
("m=") statement is associated with the first crypto session id, the
second media session statement is associated with the second crypto
session id, etc. (This seems clear from section 6. of MIKEY.)

The format of the crypto session id is specified in section A.1. The
concept of the MCS ID is defined to be an 80-bit random number which
doesn't describe the media session at all, and I can't tell how the CS
IDs are defined but I see nothing which is mappable to the actual media
streams.

MIKEY protects the "a=keymgmt-data" data such that tampering can be
detected within the key management data.

But MIKEY cannot detect if the "m=" statements in the SDP description
have been replaced or otherwise modified. To illustrate my point, here
is the example in the MIKEY document:

        |          a=keymgmt-prot:MIKEY
        |          a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD...
   MCS <   CS 1 <  m=audio 49000 RTP/SAVP 98
        |          a=rtpmap:98 AMR/8000
        |  CS 2 <  m=video 2232 RTP/SAVP 31

Suppose this was modified by a man-in-the-middle and the SDP was changed
to this:

        |          a=keymgmt-prot:MIKEY
        |          a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD...
   MCS <   CS 1 <  m=video 53172 RTP/SAVP 98
        |  CS 2 <  m=audio 49170 RTP/SAVP 31

The keys in keymgmt-data will be correctly transmitted in the MIKEY
description, but applied to the wrong media streams. 

This could be considered a DoS attack. In the case of a multicast group,
it's a more serious attack: if a dishonest group member (holding the
encryption keys) changes the SDP before other group members see it, he
can source different media streams which match the new SDP definition.
These will be authenticated in MIKEY and accepted as the valid streams,
when in fact they are not what the person who sent the MIKEY definition
intended.

I realize that MIKEY did not intend to protect the "m=" statements in
any way. But it seems to me that the implicit references to the rest of
the SDP definition affects the validity of MIKEY.

One way to solve this might be to include something in the CS ID so that
the media can be verified (e.g., a hash of the "m=" statement). But that
doesn't handle all of the dependencies on the SDP statements. MIKEY is
also dependent on the "c=" statement defining the actual multicast
address.

Another solution would be to require that MIKEY be used in conjunction
with a separate authentication system which authenticates the entire SDP
definition. (For example, SIP defines some authentication using PGP
although I've heard comments that on one actually uses it.) This seems
to me to be the safest approach, but it is too bad that MIKEY would be
dependent on other systems.

I'm anxious to hear your comments.

Thanks,
Brian
-- 
Brian Weis
Strategic Cryptographic Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

_______________________________________________
msec mailing list
[email-masked]
http://www.pairlist.net/mailman/listinfo/msec