Subject: RE: [MSEC] MIKEY: additional change suggested

From: Euchner Martin <[email-masked]>
Date: Fri, 28 May 2004 10:01:02 +0200

I agree that the proposed enhancement (i.e. adding IDr) to the I_message improves the resistance to DoS attacks. We should take the proposed opportunity to fix the MIKEY protocols accordingly.

The reported enhancement is clearly beneficial for the MIKEY-DH protocol.

I believe that similar protocol enhancements would apply equally to the MIKEY-PublicKey-Sign and likely even to the MIKEY-preshared key management protocols. In all cases, the recipient would be able to quickly deduce if a received I_message is actually targeted for him or if it is a replay or mis-route.
Note: The ISO/IEC 9798-2,3,4 key management protocols all purposely include the ID of the responder for good security reasons!

Please note, that I made already some proposal to mandatory add IDr to the I_message in the DHHMAC key management variant (see most recent DHHMAC-06 Internet Draft). I also believe that the enhancement proves worthwhile for the MIKEY re-keying/key updating I_message.

I believe similar changes should be applied to the MIKEY-DH key management protocol. Since the MIKEY DH key management protocols are only point-to-point, multicast considerations would not apply. Thus, I assume that the initiator does know the target IDr of the responder when MIKEY operates in point-to-point fashion.

However, some caution appears worthwhile to make IDr mandatory for the MIKEY-PublicKey-Sign and for the MIKEY-preshared. This is because those two key management protocols could be deployed in multicast scenarios, where a single IDr would not make too much sense; IDr might even be unknown to the MIKEY initiator.

Thus, I see two approaches basically.

1) Make [IDr] optional in I_message for MIKEY-PublicKey-Sign and for MIKEY-preshared.
2) Include a list of all potential responder IDr in I_message. Something like [ID1], [ID2], ...[IDr]. This would allow any responder to check if his identity is within the list. If not, the responder could easily drop and discard the unsolicited I_message.

Anyway, for either approach some text should be added to the spec describing when to use IDr, in which scenarios and under which circumstances. The security section should equally address the issue.

Any feedback is highly appreciated.

With kind regards

Martin Euchner.
-----------------------------------------------------------------------
| Dipl.-Inf.                     Rapporteur Q.G/SG16
| Martin Euchner                 Phone: +49 89 722 55790
| Siemens AG.....................Fax  : +49 89 722 62366
| ICN M SR 3                     mailto:[email-masked]
|                                mailto:[email-masked]
| Hofmannstr. 51                 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/
| D-81359 Muenchen               Internet: http://www.siemens.de/
| __________________
| Germany     
-----------------------------------------------------------------------

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]]  On Behalf Of Mats Näslund
Sent:	Donnerstag, 27. Mai 2004 23:01
To:	MSEC
Cc:	Russ Housley
Subject:	[MSEC] MIKEY: additional change suggested 

Hi,

As it has been pointed out in the mailing list, there is a 
possibility of performing a type of DoS attack when MIKEY 
uses the Diffie-Hellman method, at least when the protocol 
is used standalone (see mails at the end in case you haven't 
followed the thread). The proposal to mitigate the attack is,
however, simple: add a payload in the Initiator message, carrying 
the identity of the Responder. 

Our proposal is to add this to MIKEY so that it is included in
the published RFC (which should now be quite nearby in time).
We have approached the MSEC chairmen, and also Russ Housley as
security AD, and they have confirmed that it seems a good idea
to try to fix this while we have a change.
 
Now, since MIKEY is in the Editor's queue, we need to follow
certain procedures to request changes at this stage. Specifically,
we have agreed with Russ and the chairmen to follow the same procedure
as when we made a minor update of the PRF a few months ago. 
Specifically:

- We ask the msec group to provide feedback if the solution
  seems agreeable, or at least to make objections against it, should
  such exist, until Thursday, June 3 2004, 23.59UTC (one week from now).

- We will answer any comments/questions received on the list asap. 

- We summarize the inputs received in a post to the msec list the
  following day (June 4).

- We would then proceed to ask the AD and IESG for this change, 
  assuming no issues were raised on which we could not agree in the 
  WG during the week.

Many thanks,

MIKEY authors  

----- background material ------

>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]On Behalf Of Elisabetta Carrara
>>(KI/EAB)
>>Sent: den 17 maj 2004 15:34
>>To: [email-masked]'
>>Cc: [email-masked]'; Mats Näslund (KI/EAB)
>>Subject: RE: [MSEC] MIKEY: Possible DoS by copying messages
>>
>>
>>
>>Hi Gerhard,
>>you have a good point.
>>
>>The attack you describe does apply for a general case
>>where MIKEY is used independent of a signaling protocol. 
>>In a scenario such as SIP, a large number of Invites 
>>within a short time-frame would very likely not be 
>>accepted by the application.
>>Still, the protocol should mitigate this type of attack,
>>and your suggestion (the use of IDr) seems a good and simple
>>way.
>> 
>>Many thanks for pointing it out.
>>
>>Cheers
>>/E
>>
>>
>  
>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]]On Behalf Of Gerhard Strangar
>>>> Sent: den 13 maj 2004 18:48
>>>> To: [email-masked]
>>>> Subject: [MSEC] MIKEY: Possible DoS by copying messages
>>>> 
>>    
>>
>>>>Hello,
>>    
>>
>>>>Mikey draft 8 says (Section 9.5):
>>    
>>
>>>>>> This protocol is resistant to Denial of Service attacks in the sense
>>>>>> that a Responder does not construct any state (at the key management
>>>>>> protocol level) before it has authenticated the Initiator.
>>>      
>>>
>>>>But I think - at least for the Diffie-Hellman method - authentication of
>>>>the sender is not sufficient. IMHO the Responder needs to verify if the
>>>>message was meant to be sent to him (e.g. by adding the Responder's ID
>>>>to the Initiator's message). Imagine an attacker who gains access to a
>>>>network with high traffic, let's assume 2 MIKEY message per second.
>>>>Let's further assume a timeout of 60 seconds after which MIKEY sessions
>>>>are closed.
>>>>If an attacker created a copy of all MIKEY messages and sent them to one
>>>>client, this client would either create 120 concurrent MIKEY sessions
>>>>(causing high CPU consumption) or reject to establish more than n
>>>>sessions.
>>>>In case of using pre-shared or public key transport, the client will not
>>>>run into the timeout, but detect an error immediately. However it might
>>>>already have wasted CPU cycles on doing an RSA decryption.
>>    
>>

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Mats Näslund <[email-masked]>
Date: Fri, 28 May 2004 15:59:54 +0200

Hi Martin,

Thanks for raising this issue. We now realize we were not 100% clear in the
earlier posting.

Yes, our suggestion is to add an ID_responder payload in all three cases.
While it was the DH case that brought up the issue, it seems clear that
at least the public key variant suffers similar potential DoS aspects,
and it seems a good thing generally to be able to discard messages that
are not obviously directed to you, before spending any amount of non-
trivial processing, sorry if this wasn't too clear.

Thus, this is the proposal that we would like the WG's feedback on.

You also raise the issue whether this ID payload(s) should be MANDATORY,
(STRONGLY) RECOMMENDED, or just OPTIONAL, motivated by multicast concerns.
It seems that a general way to cover both your suggestions would be to say
that one (or more) ID payload(s) are in general be OPTIONAL, but RECOMMENDED
whenever the set or responders is "manageable".

Comments?

Cheers and thanks again

MIKEY authors