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

From: Euchner Martin <[email-masked]>
Date: Thu, 21 Oct 2004 20:58:06 +0200

Hello Mats and MIKEY gang,

Thanks once more for the helpful responses. I've added inline below my comments to the exchange before. I believe we are getting very close now.

So to summarize the discussion and where we stand:
1) There is nothing wrong with MIKEY; all known MIKEY protocol variants provide sufficient and good security to protect against manipulation attacks on the SDP key management phase.
2) I don't see kmgtext-11 protocol being flawed either.
3) I'm a bit concerned that the overall security very much depends on a correct implementation of the responder, in particular the right processing order of the steps. My concern is fostered by the feeling that while for security experts, the correct and secure processing order is obvious, I'm not so certain, if it is also that obvious for non-security experts; especially, since I could not find any advice/or caution anywhere in the kmgtext document.

So I would like to ask the WG:
Do you see a need to add some advice or caution (possibly in the security consideration section) that explains what to do on the responder side?

I would highly appreciate to see such a text as some generally useful non-obvious but important detail.

4) We clarified that the KMID is on the key management protocol level, the current KMID scheme does not reflect the MIKEY protocol variant level.
5) We are in agreement that the bidding-down attack can be mitigated at the responder as long as the responder implements all possible MIKEY protocol options, even those that are not of interest to the responder, and of course that the responder verifies each received option to detect if it is an injection/replacement/replay etc.
6) We are also in agreement that we are concerned about bidding-down attacks on the protocol level, but not on the algorithm/parameter level; the latter would assume a very insecure MIKEY protocol anyhow; we can de-scope this easily from our discussion.
7) I believe that we are further in agreement that the current mechanism operating on a key management protocol level and the procedures are secure but come at a high price (number of implemented options, performance).

I am clearly concerned about the consequences, namely that the existing mechanism is very costly. Do we really want this?? Or can we try to improve?

8) Where could we improve it? Which bidding-down attacks are worth it? This is a requirements question:

I would like to see
a) better (i.e. cheaper) yet equally secure protection mechanism in place that quickly detects a maliciously injected/substituted MIKEY protocol option that the responder has not implemented and/or doesn't want to support.
b) Possibility for the responder to quickly decide without full verification of all offers not to consider further a particular offer.

c) The responder being able to quickly sort out attacks from a bidding-down attempt.

So in essence I believe I'm requiring that the MIKEY protocol identifier becomes an authenticated one.

Imagine an example with a PKI enabled environment where MIKEY-DHSIGN or MIKEY-PK are possible but MIKEY-PS is also available and implemented and where the security policy of the responder would always prefer a PKI option unless such one is not offered. 

In this example, the responder upon reception of (DHSIGN, PK, PS) offer would just decide which of both DHSIGN or PK to take, and then verify the offered and chosen MIKEY protocol string. The responder does not need to verify the other offered MIKEY strings. So there is only one MIKEY instantiation instead of three. Wouldn't that be worth it?
In the example above where the responder receives an attacked offer of (DHSIGN, PK; PW) and PW is not supported or implemented, the PW option can instantly be sorted out and would not be processed any further. This would even improve resistance against certain DoS attacks, but that's a different issue not of my concern here.

9) I wouldn't have argued so long, without offering a solution that (hopefully) would work roughly as follows:

- each offered MIKEY protocol option is identified by a specific KMID. One for MIKEY-PS, a different KMID for MIKEY-DH etc
- we take advantage of the fact that MIKEY strongly integrity protects the list of protocol IDs end-to-end; so the KMIDs are indeed authenticated.
- The responder can detect
a) an injected additional KMID offer or
b) an offer that is replaced by new KMID (and string) which is not supported
simply as the KMID doesn't show up within the protected protocol list.

Thus, the responder does not require implementation of all options to thwart bidding-down attacks. The responder can reject offers that he/she hasn't implemented or for some policy reason, doesn't want to support.

10) Isn't it obvious that allocation of a few KMIDs basically and a few checks upon them by the responder is a much cheaper mechanism to satisfy above requirement than brute-force verification of each and every received option by the receiver?

I put this proposal forward to discussion.

Cheers

Martin.

Hi again Martin,

Yes, we think we are almost in complete agreement
now. Final(?) thoughts below:

MEU:> yes I think so too, nearly. So let's clear up the remaining issue.

 >
 > New concern: Unfortunately, this comes at a high price; namely the
 >answerer MUST implement all MIKEY protocol variants even those that
 >MIKEY calls just optional to implement such as MIKEY-DHSIGN,  in order
 >to be able to protect against bidding-down attacks. Right?

No. The bidding down attack will only be *detected* if the Responder
supports the variant that was inserted (MIKEY-X in the above case).
MEU> yes under the condition that the responder has implemented the inserted option and first checks validity of the offer, before deciding further. On the latter we have clearly agreement that not doing so would be highly insecure.

If the Responder does not even support MIKEY-X, the *substitution* will
not be detected, but OTHO you cannot then even talk of "bidding down" in
this case, since it's simply not possible to fool the Responder into
using something he doesn't even support.

In summary, you are right in the sense that the modification cannot be
*detected* unless all variants are supported, but OTOH, you cannot
"bid down" to something that is not implemented. For instance, if you
don't support MIKEY-DH, how can I fool you into using it?

MEU:>ok, as above. However, bad implementation of the processing order in the responder could indeed lead to a successful bidding-down attack, where the attacker forces the responder to choose an implemented option of lower security level (than without attack), where the responder actually hasn't implemented even the injected option.

 >
 > So the answerer MUST first verify all received MIKEY protocol offers,
 >and just after that actually would decide which option to choose
 >(authenticate first then policy decide).
 >
 > In fact, doing it the other way round (i.e. 1st make protocol choice 
then verify that the choice is authentic) would be insecure, even if the 
choice is not the replayed protocol offer! See counter example:

This is in very true: you can in general not make secure decisions based 
on (possibly) faked information, agreed.

MEU: ok we are in agreement.

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

---

From: Mats Näslund <[email-masked]>
Date: Wed, 27 Oct 2004 09:51:02 +0200

Hello Martin,

Euchner Martin wrote:

 > Thanks once more for the helpful responses. I've added inline below my
 > comments to the exchange before. I believe we are getting very close now.

Yes it seems that on almost all *detail* we do agree, but we draw
different conclusions in the end from these details. You argue
there is a bidding-down attack that can/should be mitigated, we
argue that is really a side-effect of something else that cannot
be solved in the way you propose.

In this mail, we will argue again that there is no bidding-down
attack issue (the issue is on another level), and furthermore,
the countermeasure you suggest is not protecting against it.

 > 1) There is nothing wrong with MIKEY; all known MIKEY protocol variants
 > provide sufficient and good security to protect against manipulation
 > attacks on the SDP key management phase.
 >
 > 3) I'm a bit concerned that the overall security very much depends on a
 > correct implementation of the responder, in particular the right
 > processing order of the steps. My concern is fostered by the feeling
 > that while for security experts, the correct and secure processing order
 > is obvious, I'm not so certain, if it is also that obvious for
 > non-security experts; especially, since I could not find any advice/or
 > caution anywhere in the kmgtext document.
 >
 > Do you see a need to add some advice or caution (possibly in the
 > security consideration section) that explains what to do on the
 > responder side?
 >
 > 4) We clarified that the KMID is on the key management protocol level,
 > the current KMID scheme does not reflect the MIKEY protocol variant 
level.
 >
 > 5) We are in agreement that the bidding-down attack can be mitigated at
 > the responder as long as the responder implements all possible MIKEY
 > protocol options, even those that are not of interest to the responder,
 > and of course that the responder verifies each received option to detect
 > if it is an injection/replacement/replay etc.

Here, it is important to be precise. The bidding down can be
*detected* if all variants are implmented, but there cannot even be
a bidding down to something that is not supported. In either
case, it's a non-issue in our opinion.

Also, this seems to contradict your concern about the security
relying on implementation errors at the Responder:
suppose there *is* a really weak variant, which is used to launch
the (bidding down) attack. Wouldn't it be better NOT to implement
that variant, completely avoiding bidding-down attacks, rather
than implementing it just for the sake of *detecting* an attack, and
at the same time opening up for an implementation error that
by accident actually *accepts* the weak offer?

(We argue more below why you cannot detect the attack without
implementing all variants.)

 >
 > 6) We are also in agreement that we are concerned about bidding-down
 > attacks on the protocol level, but not on the algorithm/parameter level;
 > the latter would assume a very insecure MIKEY protocol anyhow; we can
 > de-scope this easily from our discussion.

OK, but why then the concern in 5, which is based on this insecure
MIKEY option?

 >
 > 7) I believe that we are further in agreement that the current mechanism
 > operating on a key management protocol level and the procedures are
 > secure but come at a high price (number of implemented options,
 > performance).
 >
 > I am clearly concerned about the consequences, namely that the existing
 > mechanism is very costly. Do we really want this?? Or can we try to 
improve?

Why costly? We have made *provisions* for offering multiple key mgmt
protocol, but you don't need to implement more than MIKEY (or some
other, single, protocol). We do not mandate multiple protocols, not
even all MIKEY variants are mandatory.

The mechanism is to be used for those (exceptional) cases
where

1. the Initator support more than one protocol, but,
2. has no clue which the Responder supports.

 > a) better (i.e. cheaper) yet equally secure protection mechanism in
 > place that quickly detects a maliciously injected/substituted MIKEY
 > protocol option that the responder has not implemented and/or doesn't
 > want to support.

Why is it considered a "malicious" act to inject something that
the reponder doesn't want to use or perhaps doesn't even support?
This is DoS, and could be achieved much simpler, e.g. deleting all
key mgt offers, or just garbling them.

Given that

- we want to open up the possibility for more than one offer,
- only the Responder can detect a substitution, and,
- he can only verify those options which he/she "understands",

we do not see how it can be made simpler, yet still secure
(more on that below).

 >
 > b) Possibility for the responder to quickly decide without full
 > verification of all offers not to consider further a particular offer.

This is impossible if the arguments above are correct. We have
just concluded (or at least we think we can convince you, see below)
that to *detect* the attack, you may in the worst case
need to implement all variants/offered protocols. From this (if it is
correct) it seems to follow that you cannot omit the
verification of any single offer, or?

 > becomes an authenticated one.

We still argue it doesn't solve the real issue (should such exist).

 >
 > Imagine an example with a PKI enabled environment where MIKEY-DHSIGN or
 > MIKEY-PK are possible but MIKEY-PS is also available and implemented and
 > where the security policy of the responder would always prefer a PKI
 > option unless such one is not offered.
 >
 > In this example, the responder upon reception of (DHSIGN, PK, PS) offer
 > would just decide which of both DHSIGN or PK to take, and then verify
 > the offered and chosen MIKEY protocol string. The responder does not
 > need to verify the other offered MIKEY strings. So there is only one
 > MIKEY instantiation instead of three. Wouldn't that be worth it?
 >
 > In the example above where the responder receives an attacked offer of
 > (DHSIGN, PK; PW) and PW is not supported or implemented, the PW option
 > can instantly be sorted out and would not be processed any further.

 > Imagine an example with a PKI enabled environment where MIKEY-DHSIGN
or MIKEY-PK are possible but MIKEY-PS is also available and implemented
and where the security policy of the responder would always prefer a PKI
option unless such one is not offered.
 >
 > In this example, the responder upon reception of (DHSIGN, PK, PS)
offer would just decide which of both DHSIGN or PK to take, and then
verify the offered and chosen MIKEY protocol string. The responder does
not need to verify the other offered MIKEY strings. So there is only one
MIKEY instantiation instead of three. Wouldn't that be worth it?
 >
 > In the example above where the responder receives an attacked offer
of (DHSIGN, PK; PW) and PW is not supported or implemented, the PW
option can instantly be sorted out and would not be processed any
further. This

Yes, it can also be sorted out by the simple fact that it's not
implemented. You seem to suggest a method that can detect certain
bidding down attacks in the case when there is a bid-down to something
that would anyway never have been chosen by the Responder, becuase he
does not support it. We do not consider this an attack.

This argument can be turned around, and in doing so, it serves as
a counterexample, showing that extending the authenticated info
to also include teh "variant" does not help:

Suppose the Responder only supports only PW or only PK and that a
(PK, PS) offer is replaced (by an attacker) into (PK, PW). Also
assume that PK is very strong but PW is weak. The
original authenticator in the PK-line would say "MIKEY-PK MIKEY-PS".
Now, considering that the attacker managed
to fake the PW line, it is likely that it can be made to say
"MIKEY-PK MIKEY-PW". Now, a Responder that implements only MIKEY-PK,
will detect: "aha, the PS offer has been replaced by a PW offer". But,
consider now an attack towards a Responder who only supports PW.
In addition to faking the authenticator of the PW part (to say
"MIKEY-PK MIKEY-PW", as would be expected), the attacker modifies
the PK offer's authenticator to say "MIKEY-PK MIKEY-PW" too. Now,
he can't fake the strong signature on this, but he doesn't care
since he (correctly) hopes the Responder will not support PK.
When the Respoder receives this offer, he will think all is fine.
Had he implemented (and used) also the PK variant he would have seen
the attack on the PK line, since teh signature wouild be wrong,
but now it goes by unnoticed.

In summary, to *detect* this attack, the Responder needs to
implement (and use) at least one of the "secure" variants. In
the worst case, this could be *all* variants (if we are really
paranoid). Therefore, adding
the the "type" of MIKEY-offer to the authenticated info does not
remove the need to verify (possibly) all offers. Note though that
(again) we argue that the real issue is an insecure MIKEY
variant (PW) that could be used on it's own to cause harm, and
therefore these bidding-down attacks are purely artificial
examples that do not show the real problem.

 > would even improve resistance against certain DoS attacks, but that's a
 > different issue not of my concern here.
 >
 > 9) I wouldn't have argued so long, without offering a solution that
 > (hopefully) would work roughly as follows:
 >
 > - each offered MIKEY protocol option is identified by a specific KMID.
 > One for MIKEY-PS, a different KMID for MIKEY-DH etc
 >
 > - we take advantage of the fact that MIKEY strongly integrity protects
 > the list of protocol IDs end-to-end; so the KMIDs are indeed 
authenticated.
 > Thus, the responder does not require implementation of all options to
 > thwart bidding-down attacks. The responder can reject offers that he/she
 > hasn't implemented or for some policy reason, doesn't want to support.
 >
 > 10) Isn't it obvious that allocation of a few KMIDs basically and a few
 > checks upon them by the responder is a much cheaper mechanism to satisfy
 > above requirement than brute-force verification of each and every
 > received option by the receiver?
 >

In summary, your main concern seem to boil down into the scenario
where you try to negotiate different MIKEY types (DH, PK, PS) at
the same time. The key management negotiation was intended for
negotiation of different key management protocols and not
negotiation of one and the same protocol. This is a position we
still hold. Therefore, we do not see the need for a specific KMID
indicating key management protocol's specific offer types.

Best,

/Mats and MIKEY team