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

From: Euchner Martin <[email-masked]>
Date: Thu, 14 Oct 2004 13:05:01 +0200

IANA Consideration section 8 of the draft allocates key management IDs (KMID) for the key management protocols. One KMID (not yet allocated by IANA) will be for MIKEY.

Now here is my question:

Assuming an example where the offerer advertises just 3 MIKEY protocols; e.g. MIKEY-preshared, MIKEY-DHsign and MIKEY-PK,
Then the SDP would hold something like
a=key-mgmt:mikey   a1234a54...
a=key-mgmt:mikey   b454646ca54...
a=key-mgmt:mikey   c95785656ef3....

and the generated protocol list would be "mikey;mikey;mikey", where 'mikey' represents the allocated KMID value for the MIKEY protocol family.

Q1) In the context of bidding-down protection, what kind of security does this list actually provide?

I believe that an attacker could easily substitute another, weak 4th mikey key management protocol ("mikey-password") against one of the other three offered ones; yet the (MIKEY) protected protocol list would remain the same and the answer would not be able to detect the attack.

My conclusion (needs confirmation) is that the design flaw is that the KMID is on a key management protocol family but it should rather be on the key management protocol option/varient.

For MIKEY, the fix should be straightforward: Allocate a KMID for each of the MIKEY protocol variants; i.e.
One for MIKEY-preshared, one for MIKEY-DHsign and one for MIKEY-PK.

Cheers 

Martin.

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

---

From: Mats Näslund <[email-masked]>
Date: Mon, 18 Oct 2004 11:38:34 +0200

Hi Martin,

Thanks for raising this issue. It is known to us and was discussed 
internally when deciding for the current protection mechanism. Perhaps
we should have motivated why we did not consider this a threat to
be taken care of, but now that you raise the issue, let's see if we
can settle it.

Euchner Martin wrote:

 > IANA Consideration section 8 of the draft allocates key management 
IDs (KMID) for the key management protocols. One KMID (not yet allocated 
by IANA) will be for MIKEY.
 >
 > Now here is my question:
 >
 > Assuming an example where the offerer advertises just 3 MIKEY 
protocols; e.g. MIKEY-preshared, MIKEY-DHsign and MIKEY-PK,
 > a=key-mgmt:mikey   c95785656ef3....

First of all, why would this be something that ever occurs?
The reason we allow several options is to let the parties
agree on a particular prefered *protocol*, but choosing options
within one and the same protocol is not intended to be done
at this level.

(Anyway, let's assume it can happen...)

 >
 > and the generated protocol list would be "mikey;mikey;mikey", where 
'mikey' represents the allocated KMID value for the MIKEY protocol family.

Right.

 > I believe that an attacker could easily substitute another, weak 4th 
mikey key management protocol ("mikey-password") against one of the 
other three offered ones; yet the (MIKEY) protected protocol list would 
remain the same and the answer would not be able to detect the attack.

Okay, let's assume he can. To accomplish this, the "mikey-password"
variant needs to be so weak that he can fake the authentiction data of
the a-line where this is inserted. That is, the authentication mechanism
of the password variant is completely insecure. But if this is so, the
attacker does not even need the "real" Initiator to be on-line: he can
at any  point in time impersonate the real Initiator, faking MIKEY
messages using the password variant. Therefore...

 >
 > My conclusion (needs confirmation) is that the design flaw is that 
the KMID is on a key management protocol family but it should rather be 
on the key management protocol option/varient.
 >
 > For MIKEY, the fix should be straightforward: Allocate a KMID for 
each of the MIKEY protocol variants; i.e.
 > One for MIKEY-preshared, one for MIKEY-DHsign and one for MIKEY-PK.

...this protection mechanism is totally inadequate for the case
you describe, the "real" security hole remains open even if
we were to add this feature.

Another scenario in which the suggested protection is not enough
is as follows: suppose preshared-MIKEY is extended by a cipher/MAC
combination which has poor security. It may then not be enough to
authenticate the fact MIKEY-preshared was offered, but rather the
exact options at the transform level (which *is* done in each a-line
individually, but not across a-lines). However, we would exclude this
as a threat for the same reason as above: if faked MIKEY lines can
be inserted by an attacker, the problem is not of bidding-down nature,
it is really a fundamental security flaw of the protocol as such.

Finally, if one is still concerned by this, we would suggest that
the Initiator uses MIKEY's option of requesting a verification message
back from the Responder. If an attacker modifies the offer to contain
something the Initiator actually didn't offer, the response back will
be generated by an incorrect method/key, and the Initiator will
detect this when checking the response.

Best,

/Mats and MIKEY gang