Subject: [MMUSIC] Re: draft-ietf-mmusic-kmgmt-ext-11.txt: KMID? IANA considerations section

From: Steffen Fries <[email-masked]>
Date: Wed, 03 Nov 2004 09:49:20 +0100

Hi,

I was just reading over the discussion regarding the bidding 
down attacks with respect to draft-ietf-mmusic-kmgmt-ext-11.txt 
and the DHHMAC draft (extension to MIKEY).

I understand the argumentation that just checking the the SDP 
part may not help. I have a scenario in mind which I don't see 
covered by the current discussion:
Let's assume somebody includes two MIKEY offers in an INVITE, 
one for PW based encryption and one for public key encryption. 
The SDP payload for this would look like 

   a=key-mgmt:mikey dhsoKkdOokdo7eWsnDSJDuiSDF9sdhs727ghsd/..
   a=key-mgmt:mikey uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD..

were the first line is bound to the password based encryption 
method and the second to the public key encryption method. Now, 
the protocol list, which goes to MIKEY to be protected would be 
"mikey;mikey". 

Assuming that an attacker may have gotten my password (the 
assumption is not a weak MIKEY method), he might be interested 
in replacing the second line by the first line. The integrity 
protection of "mikey;mikey" is still vaild, but the responder 
doesn't really have a choice since both offers are equeal. I'm 
not sure if this example is somewhat constructed, but I think 
the responder wouldn't even notice that a MITM changed the offer 
(unless protected by other means like TLS or S/MIME). Taking the 
approach from Martin would at least enable the receiver that 
something changed, even if he may not be able 
to process the other MIKEY method.

How does the current draft deal with such a situation?

Regards
	Steffen

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