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

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Wed, 9 Jan 2002 13:12:13 +0100

Hi Brian,

and thanks for the comments. They are most valid. 

I see three ways of solving it (without making a too complex solution). 

1) Assume that SIP, RTSP, or SDP can transport the description in a secure and reliable way to its destination (e.g. we have the SIP security group that are working with this problem). This is mainly what we have done so far.

2) Begin using the extra keymgmt-auth attribute that we are introducing in SDP. We introduced an extra SDP attribute in order to be able to authenticate part of the SDP description if necessary (this is however still an undocumented feature in the current MIKEY draft). Your comments may give us a reason to pursue with that attribute and use it to "tie" the media description to the MIKEY data (in case it is not already provided by SIP/RTSP/SDP). 

A small example of how it could work:
        |          a=keymgmt-prot:MIKEY
        |          a=keymgmt-data:uiSDF9sdhs727gheWsnDSJD...
        |          a=keymgmt-auth:q9wuIs5du2ISD7
   MCS <   CS 1 <  m=audio 49000 RTP/SAVP 98
        |          a=rtpmap:98 AMR/8000
        |  CS 2 <  m=video 2232 RTP/SAVP 31

where the authentication field is computed over a well-defined subset of SDP (this could of course include the c= line). There is mainly one problem with this. If the user is behind a NAT, the SIP server (or another intermediate node) may need to change things like IP addresses and ports in the SDP, and thereby the authentication will fail (if it is computed over these fields). 

3) An idea, similar to the one you proposed. Instead of including the hash of some specific field, a hash over a well-defined subset or the entire SDP description could be provided (but not as input to any id), i.e. set q = hash(the sdp lines, except "a=keymgmt-data:..."). Let the signature/MAC in MIKEY include q. The hash could in this case be as just another payload in MIKEY. It would of course be authenticated and the result would be equal to that in 2). This will however have the same NAT problems as in 2). This approach will have the disadvantage that we might need to build in too much knowledge about SDP in MIKEY. 

Exactly what to aim at is something that needs to be discussed. In the future, we will probably be able to rely on 1) (and we need doing so unless we want to solve the same issues the security protocols for 1) will solve). 

Best Regards,
Fredrik

> -----Original Message-----
> From: Brian Weis [mailto:[email-masked]]
> Sent: den 7 januari 2002 21:04
> To: [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: MIKEY mapping of keys to steams -- possible vulnerability
> 
> 
> 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

---

From: Brian Weis <[email-masked]>
Date: Fri, 11 Jan 2002 17:53:26 -0800

Hi Fredrik,

Thanks for your response. I've got some more comments inline.

> 1) Assume that SIP, RTSP, or SDP can transport the description in a secure and reliable way to its destination (e.g. we have the SIP security group that are working with this problem). This is main…

Right, that would be work in terms of securing a system. But as Mark
pointed out, in terms of the protocol definition this approach means
that your statement in Section 2.2 of MIKEY may not be quite true

   * Independent of the security of the underlying transport.

if you think of the session establishment protocol being part of the
term "underlying transport".

> where the authentication field is computed over a well-defined subset of SDP (this could of course include the c= line). There is mainly one problem with this. If the user is behind a NAT, the SIP…

Thanks for pointing out the proposed keymgmt-auth attribute It does
begin to solve the authentication problem, but I don't think specifying
it will be so easy. 

The NAT problem is interesting. I didn't know that NAT boxes were SDP
(or SIP and RTSP) aware. But if the c= line isn't in the authenticated
subset of the SDP definition then it's questionable whether validating
the integrity of the rest of the SDP definition  is worthwhile -- an
attacker can still change the media streams to which the MIKEY keys will
be applied to (same ports, different machine).

> 3) An idea, similar to the one you proposed. Instead of including the hash of some specific field, a hash over a well-defined subset or the entire SDP description could be provided (but not as inpu…

Yes, I think that no matter what you choose to hash you'll either have
too much knowledge of SDP in MIKEY, or too much knowledge of MIKEY in
SDP. In the example above, who does the hash() on the local system? If
the SDP code does it then it has to know about creating a MIKEY-specific
hash. If the MIKEY code does it, then it has to be given access to the
entire SDP description and it has to know how to parse it.

This applies to both solutions 2) and 3). You can think of it as a
protocol layering violation problem.

I suggest that you  put some more thought into the a=keymgmt-auth
attribute defined in draft-ietf-mmusic-kmgmt-ext-00.txt draft. If you
can't come up with a way of addressing the layering problem you should
probably remove it from that draft and mention the integrity issue there
too.

> Exactly what to aim at is something that needs to be discussed. In the future, we will probably be able to rely on 1) (and we need doing so unless we want to solve the same issues the security prot…

Yes, 1) is your best bet for now. But you should add some text to the
MIKEY draft pointing out the problem and describe the dependency.

I have put some thought into a generic SDP authentication attribute
(which would not be part of any particular key management system, and
could be used by itself to authenticate any SDP description.) If that's
seen as appropriate I'll submit it mmusic.

Thanks,
Brian

> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Mark Baugher <[email-masked]>
Date: Fri, 11 Jan 2002 14:33:56 -0800

Hi Fredrik
     Doesn't this problem conflict with one of your stated design goals of
Section 2.2:  Independence of the security of the underlying transport?
All three of these solutions seem to me to violate that design goal.
It seems to me that you need to remove the dependency that you
have on the integrity of SDP messages in order to preserve your goals.

Mark

At 01:12 PM 1/9/2002 +0100, Fredrik Lindholm (ERA) wrote:

>1) Assume that SIP, RTSP, or SDP can transport the description in a secure 
>and reliable way to its destination (e.g. we have the SIP security group 
>that are working with this problem). This is mainly what we have done so far.
>
>2) Begin using the extra keymgmt-auth attribute that we are introducing in 
>SDP. We introduced an extra SDP attribute in order to be able to 
>authenticate part of the SDP description if necessary (this is however 
>still an undocumented feature in the current MIKEY draft). Your comments 
>may give us a reason to pursue with that attribute and use it to "tie" the 
>media description to the MIKEY data (in case it is not already provided by 
>SIP/RTSP/SDP).
>
>where the authentication field is computed over a well-defined subset of 
>SDP (this could of course include the c= line). There is mainly one 
>problem with this. If the user is behind a NAT, the SIP server (or another 
>intermediate node) may need to change things like IP addresses and ports 
>in the SDP, and thereby the authentication will fail (if it is computed 
>over these fields).
>
>3) An idea, similar to the one you proposed. Instead of including the hash 
>of some specific field, a hash over a well-defined subset or the entire 
>SDP description could be provided (but not as input to any id), i.e. set q 
>= hash(the sdp lines, except "a=keymgmt-data:..."). Let the signature/MAC 
>in MIKEY include q. The hash could in this case be as just another payload 
>in MIKEY. It would of course be authenticated and the result would be 
>equal to that in 2). This will however have the same NAT problems as in 
>2). This approach will have the disadvantage that we might need to build 
>in too much knowledge about SDP in MIKEY.
>
>Exactly what to aim at is something that needs to be discussed. In the 
>future, we will probably be able to rely on 1) (and we need doing so 
>unless we want to solve the same issues the security protocols for 1) will 
>solve).
>
>Best Regards,
>Fredrik
>
>