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

From: "Steffen Fries" <[email-masked]>
Date: Wed, 03 Nov 2004 11:14:58 +0100

Hi Mats,

i put my comments also inline:

> Hi Steffen,

> Thanks for the additional comments. Our reply is inline.

> Steffen Fries wrote:

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

> Well, let's make another construction. Suppose we do introduce

> Martin's suggestion and that all else is as you assume above.

> The initiator sends something like

>      a=key-mgmt:mikey dhsoKkdOokdo7eWsnDSJDuiSDF9sdhs727ghsd/..

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

I actually thought here on something like

a=key-mgmt:mikeyPW dhsoKkdOokdo7eWsnDSJDuiSDF9sdhs727ghsd/..

a=key-mgmt:mikeyPS uiSDF9sdhs727ghsd/dhsoKkdOokdo7eWsnDSJD..

which would enable an easier processing as Matin suggested.

> where the both lines use the protocol list "mikeyPK; mikeyPW".

> Since the attacker knows the password, he could just as easily

> delete the first offer altogether and fake the (single) offer

>      a=key-mgmt:mikey <something>

> which is a mikeyPW offer using the protocol list "mikeyPW"

> (Guess this is equivalent to your attack but with a different

> "flavor"). This would also be a bidding down attack, but

> the extended list format does not help against this.

Agreed

> In fact, if the Initiator is not even on line, the fact

> that the attacker knows the password enables him to generate

> arbitrary (single) mikeyPW offers at any time, regardless

> of the format of the protocol list.

> > the responder wouldn't even notice that a MITM changed the offer

> > (unless protected by other means like TLS or S/MIME). Taking the

> Same in our example.

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

> Our view is that to demonstrate the need for the extended identifiers

> you need to make the assumption of an existing serious security hole

> (a VERY weak MIKEY version, the knowledge of a key/password, etc). But

> in that case there are much worse things to worry about than the

> bidding-down issue. And, even *with* the extended identifiers the

> bidding down problem remains in that case as we hope we showed above.

Okay, I got your point. Just for my curiosity, with this
argument, what is the point to protect the KMGT IDs by the key
management protocol at all? If some property like the password
is known, a MITM may replace the complete key management offer
with something else (like in your example). If a weak protocol
is used than you have the chance that the attacker is not able
to break it in the normal call setup time. Is that the goal?

regards

Steffen

> We thus do not believe the "real" security issue is solved

> by the extension of the protocol IDs. Why would an attacker wait

> to see "real" offers flying by and then change them, when he

> can attack himself at any time?

> > How does the current draft deal with such a situation?

> > Regards

> >         Steffen

> It is not addressed specifically.

> Regardless of the above, we again emphasize that the negotiation

> mechanism of key management protocols is intended for different

> protocols, not negotiating different types of the same protocol.

> Best,

> /Mats and MIKEY team

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

---

From: Mats Näslund <[email-masked]>
Date: Wed, 03 Nov 2004 13:13:21 +0100

Hi again Steffen,

 > which would enable an easier processing as Matin suggested.

Oh, sure, this was a typo by me. Nevertheless the issues remain
as we seem to agree (and just "seeing" mikeyX at this point doesn't
mean you can trust it until after the line has been parsed and
authenticated.)

 > Okay, I got your point. Just for my curiosity, with this argument, what
 > is the point to protect the KMGT IDs by the key management protocol at
 > all? If some property like the password is known, a MITM may replace the
 > complete key management offer with something else (like in your
 > example). If a weak protocol is used than you have the chance that the
 > attacker is not able to break it in the normal call setup time. Is that
 > the goal?

The inclusion of the (authenticated) protocol list is mainly to protect
against somebody *deleting* an entire a-line which (had it been
received) would have been the Responder's preferred choice.

For example, say I offer you
one a-line based on MIKEY and one based on ProtocolZ (maybe because
I have your public key, but I am not sure which protocol support).
Now suppose the MITM just deletes the MIKEY line but lets ProtocolZ
pass. Assuming you support ProtcolZ, you will probably accept that,
but you  might actually have preferred MIKEY (for security or other
reasons). The protocol list gives a way for you to check that
*something* was lost along the way.

Similarly, if I offer you three MIKEY options (though we do not see
that as realistic) the Responder can detect if one or two were
deleted by an attacker. He cannot detect *what* the other offers were,
but he does detect the attack.

Hope this clarifies the rationale.

/Mats and MIKEY team

---

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

Hi Mats,

I've a question to your last point:
 
> that as realistic) the Responder can detect if one or two were deleted
> by an attacker. He cannot detect *what* the other offers were, but he
> does detect the attack.

Given the example we used before:

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". By replacing line 2 with line 1 you force the 
receipient to go with MIKEY PW, even he would have preferred 
MIKEY PK. And the integrity check here should be fine.

Is it worth to mention this attack somewere in the security 
considerations?

Regards
	Steffen

-----------------------------------------------------------
    Steffen Fries,     Siemens AG, CT IC 3	
    Otto-Hahn-Ring 6,  D-81730 Munich, Germany 
    Phone:  (+49) 89 / 636-53403,    
    Fax  :  (+49) 89 / 636-48000
    Email:  [email-masked]
-----------------------------------------------------------

---

From: Mats Näslund <[email-masked]>
Date: Wed, 03 Nov 2004 16:08:44 +0100

Ciao Steffen,

> MIKEY PK. And the integrity check here should be fine.

Yes, this is possible if you (still contrary to intent) negotiate
within the same protocol. The duplication is still in principle
detectable though (by pure semantics), since it makes no sense to
offer *exactly* the same twice.

In fact, even technically, how could the Responder choose between
two apparently identical offers without parsing them? According
to MIKEY RFC, any MIKEY message that has come in and been authenticated
should be in the replay cache. Thus, a compliant MIKEY implementation
should in fact automatically catch the second line as a replay.

> Is it worth to mention this attack somewere in the security

Not sure, but with reference to this (long) discussion leading
(in our opinion) to the conclusion that not even misuse of the
functionality has any real security implication, we believe that
perhaps it is the intended use of multi-offer that should be
elaborated?

Best,

/Mats and MIKEY team

---

From: "Steffen Fries" <[email-masked]>
Date: Wed, 03 Nov 2004 17:22:31 +0100

Hi Mats,
> offer *exactly* the same twice.
correct, it makes not sense, it was just a constructed scenario

> 
> In fact, even technically, how could the Responder choose between two
> apparently identical offers without parsing them? According to MIKEY
> RFC, any MIKEY message that has come in and been authenticated should
> be in the replay cache. Thus, a compliant MIKEY implementation should
> in fact automatically catch the second line as a replay.
good point, I did not think on the replay cache as both offers 
are transmitted in the same message. But that would be detected.
> perhaps it is the intended use of multi-offer that should be
yes, I think it would be worth to provide more infos here. Maybe 
once in a while people having the same thoughts I had, then it 
is good to reflect the result of the discussion within the 
draft.

Regards
	Steffen---------------------------------------------------
--------

---

From: "Steffen Fries" <[email-masked]>
Date: Thu, 04 Nov 2004 08:31:41 +0100

Hi Mats,

yes, I will talk with Elisabetta in Washington. Anyway, I think 
we cleared the points mostly and I think whats left is only the 
reflection of the result in the draft in a way that everybody 
understands it.

Regards
	Steffen

Date sent:      	Wed, 03 Nov 2004 19:08:03 +0100
From:           	Mats Näslund <[email-masked]>
To:             	[email-masked],
       	"Elisabetta Carrara (KI/EAB)" <[email-masked]>
Subject:        	Re: draft-ietf-mmusic-kmgmt-ext-11.txt: KMID? IANA considerations
	section

> 
> Hi again Steffen,
> 
> I saw no reason to go "public" with this:
> 
> Steffen Fries wrote:
> 
> > once in a while people having the same thoughts I had, then it is
> > good to reflect the result of the discussion within the draft.
> 
> It was very good that you (and Martin) brought this up. One would
> indeed wish that this whole email exchange could be included in the
> RFC so as to settle it once and for all and so that future worries of
> this sort could avoided. However, that would make a rather long RFC so
> if we do anything about it, it needs to be rather compact text.
> 
> As I understood, you and Elisabetta would probably meet in Washington,
> where it may be more efficient with a f2f discussion.
> 
> Thanks,
> 
> /Mats
>