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

From: "Fredrik Lindholm (ERA)" <[email-masked]>
Date: Mon, 14 Jan 2002 11:43:14 +0100

Brian, Mark,

"Independence of the security of the underlying 
transport" means that no security mechanism of 
the underlying transport is used to protect the 
MIKEY message. However, the intention was not 
to let people think that MIKEY would solve all 
the problems that will come from using SIP, RTSP 
and SDP. I guess the formulation may be a bit 
misguiding, but I will put a clarification of 
this. 

More comments below.

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

Ok, put it like this. Some stuff that exists in 
SDP must be duplicated and put in MIKEY, e.g. IP 
address(es), and ports. This is a very common 
thing to put in a key management protocol, and 
are in general not treated as a layer violation. 
Then if you choose to hash it or not, that's 
another issue. 

The big issue resulting from this discussion as 
I see it (not only for MIKEY but to all key 
management protocols for secure groups) is, how 
do we treat NATs? If a NAT exists, you cannot 
bind IP addresses and ports in the key management 
scheme in a good way. In theory, I guess it would 
be possible to launch an attack (equal to Brian's 
where the SDP were changed), by fooling the NAT 
to map the incoming stream from a group wrong 
(assuming as Brian did that SOA is not used). 
This is an issue that we will look more into. I 
guess that NAT traversal may be a topic for a 
general MSEC discussion and a new thread.  

Some drafts on the NAT vs SDP/UDP topic from the 
mmusic group:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-natreq4udp-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-00.txt

Fredrik

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

---

From: Mark Baugher <[email-masked]>
Date: Mon, 14 Jan 2002 13:03:42 -0800

After exchanging some private notes and considering the
nature of an attack using the CS identifiers, I don't think
the issue that I raised about security dependencies
between MIKEY and SDP amounts to very much.

thanks, Mark

At 11:43 AM 1/14/2002 +0100, Fredrik Lindholm (ERA) wrote:

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