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

From: Euchner Martin <[email-masked]>
Date: Tue, 19 Oct 2004 20:19:10 +0200

Mats,

Many thanks to you and the entire MIKEY crew for answering my question.

On one hand, I understand your response (see my acknowledgement below), one the other hand put some further comments for discussion and yet in some other areas I believe that there may be just a resolvable misunderstanding.

I'm addressing the issues inline below.

Cheers

Martin

 -----Original Message-----
From: 	Mats Näslund [mailto:[email-masked]] 
Sent:	Montag, 18. Oktober 2004 11:39
To:	Euchner Martin
Cc:	[email-masked]; Jari Arkko (JO/LMF); Elisabetta Carrara (KI/EAB); Fredrik Lindholm (KI/EAB); Karl Norrman (KI/EAB)
Subject:	Re: draft-ietf-mmusic-kmgmt-ext-11.txt: KMID? IANA considerations section

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

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.

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 this SDP-based negotiation is operating just on the family - level of the key management protocol but certainly not on protocol capabilities (such as a particular choice like MIKEY-PK, or even more fine grained on a crypto algorithm level). So in order to "negotiate" any deeper than the family-level, kmgtext offers the desired MIKEY protocol variants in parallel. Unfortunately, this increases the processing time of the offerer considerably; namely 3 times to instantiate and to compile 3 different MIKEY key management protocol messages. For the answerer, the work load is not as high as on the offerer, but still the base64 decoding requires some more effort than just a quick inspection of a specific KMID would cost; so this latter point is really a minor issue.

I should clearly say, that I don't see any better alternative for a full 2-way handshake negotiation process yet a 4-way handshake would not face the parallel explosion property.

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

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

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

MEU:> Here I sense a minor misunderstanding. I'm clearly not questioning the security of any MIKEY protocol nor am I saying that any MIKEY protocol is any close to being weak that it could be broken.

My only concern in the context of a bidding-down attack is, that the bidding-down attack could be accomplished within a spurious hop 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 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.
The protected protocol list would not indicate the particular substitution attack.

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.

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.

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

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.

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.

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.

Best,

/Mats and MIKEY gang

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

---

From: Mats Näslund <[email-masked]>
Date: Wed, 20 Oct 2004 18:24:11 +0200

Hi again Martin,

Thanks for your additional thoughts. Indeed, I think we
are getting closer, but as you write, there may still be some
mutual misunderstandings before we "meet". Hopefully, some more
elaboration below brings us even closer...

Euchner Martin wrote:

 > On one hand, I understand your response (see my acknowledgement
 >below), one the other hand put some further comments for discussion and
 >yet in some other areas I believe that there may be just a resolvable 
 >misunderstanding.
 >
 > Cc:     [email-masked]; Jari Arkko (JO/LMF); Elisabetta Carrara 
(KI/EAB); Fredrik Lindholm (KI/EAB); Karl Norrman (KI/EAB)
 > 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.

 > this SDP-based negotiation is operating just on the family - level of 
 >the key management protocol but certainly not on protocol capabilities
 >(such as a particular choice like MIKEY-PK, or even more fine grained
 >on a crypto algorithm level). So in order to "negotiate" any deeper
 >than the family-level, kmgtext offers the desired MIKEY protocol
 >variants in parallel. Unfortunately, this increases the processing time
 >of the offerer considerably; namely 3 times to instantiate and to
 >compile 3 different MIKEY key management protocol messages. For the 
 >answerer, the work load is not as high as on the offerer, but still the
 >base64 decoding requires some more effort than just a quick inspection
 >of a specific KMID would cost; so this latter point is really a minor 
 >issue.

Yes, if you really don't have any clue
what the responder supports/prefers, you *could* trade the number of
single messages for the amount of processing involved in a producing a
single, but larger multi-offer.

 >
 > I should clearly say, that I don't see any better alternative for a
 >full 2-way handshake negotiation process yet a 4-way handshake would
 >not face the parallel explosion property.
 >
 >
 > MEU:> Here I sense a minor misunderstanding. I'm clearly not
 >questioning the security of any MIKEY protocol nor am I saying that any
 >MIKEY protocol is any close to being weak that it could be broken.
 >
 > 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" ?

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

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,

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

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.

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.

 > The protected protocol list would not indicate the particular 

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

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

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

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

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

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

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

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

Cheers

/Mats and MIKEY gang