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

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

Mats,

Once again many thanks for your good answers that indeed clarify a lot of the misunderstandings.

To quickly summarize: I believe that we are already very close in our views; I don't see any real disagreement.

However, I see some further related issues on how the answerer has implemented its system. Originally, I had the "insecure implementation" in mind, yet it was not immediately apparent to me that this is the main cause of the problem. I would at least ask for your confirmation, if that is correct; see the longer added statements with the counter example in the middle of the email.

Cherio

Martin.

> MEU:> Ok this confirms that kmtext "negotiates" a key management
 >protocol family, but does not actually negotiate any particular key
 >management capability. I intentionally put negotiate in quotes, since

Well, we would e.g. assume that if a shared key is known, that method
would in general be preferred (even if you by chance also know a public
key), and the need to negotiate in that "dimension" would be small.

Still, we think also that sort of negotiation *could* be done
with a security that is not lower than if just single offers were
allowed, see below.

MEU: ok.

> My only concern in the context of a bidding-down attack is, that the 
 >bidding-down attack could be accomplished within a spurious hop

What do you mean by "spurious hop" ?

MEU:> sorry for not having explained the attack scenario. It is exactly the case that you showed in 1. and in 2, where an evil Eve who is not trusted by the offerer nor the answerer runs a modification/substitution attack on at least one SDP a-line.

 >somewhere between the originating and terminating end systems, such
 >that the attacker replaces a stronger offer by a weaker one of the same
 >protocol family. For the bidding-down attack success, the strength of

Neglecting that we don't understand "spurious hop", we still think
that the attack you describe is of the following form:

1. The Initiator makes an offer containing m > 1 MIKEY
    alternatives/lines.

2. Somehow, along the path, at least one of the m MIKEY offers
    get replaced by another (weaker) MIKEY offer that was not in
    the original offer.

Correct?

MEU:> yes exactly.

If so, let's call the weak MIKEY variant "MIKEY-X", be it password
based or otherwise.

Now we need to ask, how could it be that the inserted MIKEY-X offer gets
accepted as authentic by the Responder?

As we see it, that would only be possible if either:

A) the MIKEY-X offer is a replay of an old offer (which would normally
   be taken care of by MIKEY-X replay protection), or,

MEU: actually I had in mind just this case as I did not assume case B to happen (so my assumption is also along the lines that MIKEY-X still provides some meaningful security level, yet it is possibly lower in security level than any of the current MIKEY protocol variants.)

B) The MIKEY-X option is so weak in itself that it is possible
   to fake MIKEY-X messages without even resorting on replay.

MEU:> You are right that this case would also exist.

But if either of these would be possible, there would be
a flaw in that specific MIKEY-X variant, and it really doesn't
matter that there were more than one offer in the original
message: the attacker could fake MIKEY-X offers according to that
(single) MIKEY-X version at any point in time, right? The real
Initiator doesn't even need to be on-line. Thus, you *could* say that
you have a bidding down attack, but that is not *the* real problem.
The problem is more fundamental than that.

MEU: I tend to agree with that given that Eve somehow must have substituted actually a replayed MIKEY protocol run. I really cannot think of any much different attack right now.
Now if Eve had done so, then the answerer could detect this attack, by verification that the integrity of >each< offered MIKEY protocol holds valid. For the replayed option, the verification would fail (e.g. re-used nonce or expired timestamp etc).
So I agree with you that the answerer has a real chance to detect a bidding-down attack. This is good and removes my original concern.

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?

I cannot fully believe this to be true right now, as this questions the choice of making certain MIKEY protocols optional altogether.

Why is it so?

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:

Assume that the offerer provides 3 alternatives: A1, A2, A3 where A1 < A2 < A3 and "<" means security level is lower than. Assume further that Eve substitutes B1 against A1 somewhere between the offerer and the answerer and that B1 < A1. 
Now assume further the security policy of the answerer is such that the answerer picks the medium offered option; i.e. discarding the highest and the lowest offered option; so in the case without attack, the decision taken is A2. (Please don't ask me if such a security policy is any realistic or why such a policy would make sense).

In the case where Eve attacks with a substitute B1 for A3, and the answerer does not verify the security validity first of A1, B1, and A2, the policy decision would pick A1 now. The answerer would not detect the successful bidding-down attack just by verifying A1 which is of course correct. The offerer is also not able to detect the occurred bidding-down attack even with a verification message response.

Unfortunately, the insecure variant is so much more compelling from the performance and implementation point of view that incorrect implementations could be tricked at least in certain cases depending on the security policy.

Unless I'm badly missing the point here (perhaps it's too late already?), I believe the correct behaviour of the answerer is not immediately obvious to everyone; and thus, it may be more than worth to document the correct behaviour in the security consideration section.

BTW: I also forgot to clarify in my previous email, what I understand as a successful bidding-down attack: This is an outcome of a negotiation procedure where the offerer and answerer (with the "help" of some attacker) agree on a security option that yields a less security level than without the attacker. The successful bidding-down attack does not imply that any security protocol has been broken nor that the reduced security option would actually be subject to a (feasible) attack.

Also, in addition (as we seem to agree), the bidding-down variant of the 
attack can be discovered using the verification option. (However, the
more basic "faked-offer" is not mitigated by the V-message.)

 > the substituted MIKEY protocol matters only as much as its security is
 >(somewhat) less than the original protocols. If the reduced security >
 >level is sufficient to break MIKEY in any reasonable time, is a
 >completely different issue.

We think (see above) that it isn't enough if the substituted offers
are only "somewhat" less secure, they would need to be quite badly
insecure, otherwise the substitution as such would be impossible.

MEU: I agree with you, except the issue explained above.

 > The protected protocol list would not indicate the particular 
 >substitution attack.

Correct. But even single offers containing only one MIKEY line
could be faked.

MEU:> Yes ok, yet such cases could be detected with the V-message.

 >
 > However, I admit that there are two mechanisms in place that allow the
 >offerer to detect such an attack:
 > a) The offerer would receive a SDP response from the answerer that
 >holds a "foreign", non-offered kmgt option.
 > b) MIKEY luckily provides the verification message, unless the MIKEY
 >key management protocol isn't already two-way.
 >
 > Mechanism a) or b) are the only way for the offerer to detect any
 >occurred bidding-down attack; the responder has no chance to detect
 >such an attack just by inspecting the incoming offer.

Yes. But even so, attacks remain possible by just faking *single* offers
based on the weak variant.

MEU:> ok.

 >
 > For myself this fact is now clear. So my conclusion is that in fact
 >the MIKEY verification message has a very strong value in protecting
 >the offerer against bidding-down attacks. I simply cannot remember
 >right now, if this has been adequately explained in MIKEY RFC or in the
 >kmext draft and if that is apparent to the reader.

Maybe not...but this was clearly one reason for adding it as an option.

MEU: ok. 

 >  >
 >  > 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.
 >
 > MEU:> hmm, I'm not certain if I understand this fully.
 > Except for the problem that you correctly describe in the following
 >paragraph, I believe that my proposed solution could at least provide
 >some value for the answerer to get protection against bidding down
 >attacks on the MIKEY protocol level, yet clearly not on any
 >transform/alg level below.

It is not clear it helps, if there is even a single very insecure
variant. Also, if a single, otherwise secure, variant contains
insecure "sub-options" you have an issue. We are therefore sceptic
to what it adds.

MEU:> Yes I understand your hesitations now.

 >
 > This would challenge us to answer the question: Is the proposed yet
 >non-perfect approach (i.e. allocating several KMIDs) worth the effort?
 >
 > Maybe...when we don't want the entire security protection to depend
 >just on the offerer, but give the answerer a certain chance at least to
 >recover on its own.
 >
 > I put this aspect for further discussion among the security experts.
 >

We are listening to other possible feedback. We hope we have
clarified why *we* think the suggested approach protects against
"relevant" attacks.

MEU:> I appreciate any further views.
 >
 > 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).
 > MEU:> Yes I completely agree to this point. Taken to the most extreme
 >case this would mean that the entire offering of security parameters
 >would need to be secured. I clearly think that this is beyond what we 
 >want to achieve.

Ok.

 >
 > 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.
 >
 > MEU:> not quite. Please see my explanations on the spurious hop, >above.

We don't see how that could happen, or, to be precise, if it
*could* happen, even simpler, non-bidding-down attacks would
occur.

MEU:> yes, possibly. I've not analyzed the situation what all could go wrong, if Eve actually attacks the SDP but I believe it could get pretty nasty from the security point of view.

 >
 > 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.
 >
 > MEU:> Yes full agreement. Clearly the verification mechanism is a very
 >powerful tool to protect the offerer from a bidding down attack.
 >However, the answerer fully depends on the correct reaction and
 >implementation of the offerer. The answerer has no means to detect an
 >occurred bidding-down attack on its own.
 >

Fully agree.

MEU> Excellent!

Cheers

/Mats and MIKEY gang

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

---

From: Mats Näslund <[email-masked]>
Date: Thu, 21 Oct 2004 17:08:12 +0200

Hi again Martin,

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

Euchner Martin wrote:

 > To quickly summarize: I believe that we are already very close in our
 > views; I don't see any real disagreement.
 >
 > However, I see some further related issues on how the answerer has
 > implemented its system. Originally, I had the "insecure implementation"
 > in mind, yet it was not immediately apparent to me that this is the main
 > cause of the problem. I would at least ask for your confirmation, if
 > that is correct; see the longer added statements with the counter
 > example in the middle of the email.
 >
 > Cherio
 >
 > Martin.
 >
 > MEU:> sorry for not having explained the attack scenario. It is exactly
 > the case that you showed in 1. and in 2, where an evil Eve who is not
 > trusted by the offerer nor the answerer runs a modification/substitution
 > attack on at least one SDP a-line.
 >
 > Now we need to ask, how could it be that the inserted MIKEY-X offer
 > gets accepted as authentic by the Responder?
 >
 >
 >MEU: actually I had in mind just this case as I did not assume case B
 >to happen (so my assumption is also along the lines that MIKEY-X still
 >provides some meaningful security level, yet it is possibly lower in
 >security level than any of the current MIKEY protocol variants.)
 >
 > MEU: I tend to agree with that given that Eve somehow must have
 >substituted actually a replayed MIKEY protocol run. I really cannot
 >think of any much different attack right now.

OK.

 >
 > Now if Eve had done so, then the answerer could detect this attack, by
 >verification that the integrity of >each< offered MIKEY protocol holds
 >valid. For the replayed option, the verification would fail (e.g.
 >re-used nonce or expired timestamp etc).
 >
 > So I agree with you that the answerer has a real chance to detect a
 >bidding-down attack. This is good and removes my original concern.

OK.

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

 >
 > I cannot fully believe this to be true right now, as this questions 
the choice of making certain MIKEY protocols optional altogether.
 > Why is it so?

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?

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

[snip]

We took the liberty of deleting your example of the above, we generally
agree with you.

Best,

/Mats and MIKEY team