Subject: RE: [MSEC] MIKEY: additional change suggested --summary of change s

From: "Elisabetta Carrara (KI/EAB)" <[email-masked]>
Date: Fri, 4 Jun 2004 13:11:51 +0200

Hi,
as planned, after the feedback received on the mailing list, 
we send the summary of the changes that we will submit for 
IESG consideration:

- add an optional ID payload carrying the Responder's identifier
(in all three modes)
- add security considerations that recommend the use of such 
payload.

Thanks,
MIKEY authors  

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Mats Näslund
> (KI/EAB)
> Sent: den 27 maj 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: "Steffen Fries" <[email-masked]>
Date: Fri, 04 Jun 2004 15:08:54 +0200

Hi Elisabetta,

I've got two further questions to MIKEY:
1. In MIKEY the key validity period may be signaled either via
   the MKI or via the key lifetime directly (MIKEY Section
   6.13). This may be done by setting the KV to either 1 or 2.
   SRTP allows also the simultaneous use of MKI and lifetime
   values. (section 8.1, last paragraph).
   How is this signaled in MIKEY?
2. Using the key lifetime as described in MIKEY section 6.14, 
   the sender may include a "Sequence number, index, timestamp,
   or other start value that the security protocol uses to
   identify the start position of the key usage". How does the
   MIKEY initiator signale how the validity data is to be
   interpreted? Is this done somehow out of band or belongs to a
   policy?

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