Subject: [MSEC] RE: MIKEY DH-payload question

From: "Fredrik Lindholm (EAB)" <[email-masked]>
Date: Fri, 2 May 2003 16:22:20 +0200

> From: Euchner Martin ICN M SR 3 [mailto:[email-masked]]
> Sent: den 2 maj 2003 14:47
> 
> Fredrick,
> 
> many thanks for the fast response. I fully agree with your 
> answers, and I
> will add some clarifications into my ID.
> 
> 
> However, I just came across another issue in the MIKEY DH 
> key-update method
> (see section 4.5):
> 
> The DH-method allows [DHi] and [DHi, DHr] being optional.
> 
> I assume that [X, Y] means either X and Y present or both absent 

Correct assumption.

> (in contrast to using [X], [Y] for the other cases) ?
> 
> 
> Still, there are some combinations of options that are not 
> entirely clear to
> me: Possible reasons are that a DH payload may be a new one 
> or a previous
> one; 
> 
> 
> 1.) Initiator sends DHi, Responder sends no DH half key(s)
> 2.) Initiator doesn't any DHi, Responder sends DHi & DHr: The 
> responder can
> just reuse the existing DHi but certainly SHOULD generate a new DHr ?

I would not recommended this. If you like to reuse previous value, 
you should still send it. One reason to send it is because you 
may map the value to a lifetime or an MKI. It would be very confusing 
to guess what DH value to use if there would have existed more than 
one during a MIKEY session.

> 
> Case 1) would thus compute a new TGK based upon the new DHi and the
> old/currently active DHr?
> Case 2) would compute a new TGK based upon the new DHr and 
> currently active
> DHi?
> 
> Thus case 1) and case 2) could be seen as a partial key 
> update; a feature
> that certainly may have its value!

I agree that partial update might be a nice feature, but as stated 
above, I do think one always should send the value (even if it is 
not a "fresh" one) just to avoid confusion. 

The reason that you could leave the DH values out was to be able 
to update other parameters without the need to update the key.

This might be something we need to clarify in the draft. 

> Generally, I see some necessity that the notion of optional 
> be clarified. My
> understanding of the [X] payloads is that such fields SHOULD 
> be present as
> much as possible, but MAY be left out in certain 
> circumstances. Is that
> true?

Yes

> 
> Since those "certain circumstances" and their impact on the (reduced)
> security is not entirely obvious from the text, I fear that some
> implementers may simply discard any optional fields from 
> implementation for
> the sake of simplicity. Thus, some warning statements should 
> be considered
> when an option is not taken...

Sounds like a good idea.

Thanks,
Fredrik

> 
> 
> 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://intranet.icn.siemens.de/marketing/cs27/topics/security/
> | D-81359 Muenchen               Internet: http://www.siemens.de/
> | __________________
> | Germany     
> --------------------------------------------------------------
> ---------
> 
>  -----Original Message-----
> From: 	Fredrik Lindholm (EAB) 
> [mailto:[email-masked]] 
> Sent:	Friday, May 02, 2003 12:40 PM
> To:	Euchner Martin  ICN M SR 3
> Cc:	Elisabetta Carrara (EAB); [email-masked];
> [email-masked]'
> Subject:	RE: MIKEY Identity payload question
> 
> 
> Hi Martin,
> 
> > -----Original Message-----
> > From: Euchner Martin ICN M SR 3 [mailto:[email-masked]]
> > Sent: den 2 maj 2003 11:49
> > To: [email-masked]; Euchner Martin ICN M SR 3
> > Cc: Elisabetta Carrara (EAB); [email-masked]'
> > Subject: MIKEY Identity payload question
> > 
> > 
> > Quick question regarding the IDi, IDr payloads in the MIKEY 
> protocols:
> > 
> > While IDr is optional in the MIKEY-preshared and public-key 
> > protocols, the
> > Diffie-Hellman variant is lightly different in that the 
> additional IDi
> > reflected by the sender is not optional.
> > 
> > Is IDi in MIKEY-DHSIGN R_message really a mandatory field 
> even if the
> > initiator did not provide any explicit identity information? 
> 
> Yes
> 
> > This sounds
> > like the responder would have to defer the initiator's ID 
> > through some other
> > means.
> 
> Correct (the assumption is basically, if you know how to verify the 
> signature, then you also know the ID).
>  
> > My naive assumption of understanding would be that the IDi at the
> > responder's side is understood as an optional field. The 
> > responder should
> > provide IDi payload at least if an IDi payload was received. 
> > Otherwise, if
> > no IDi payload had been received, IDi payload would not be 
> > responded. Is
> > this the intention?
> 
> No
> 
> The reason for mandating the IDi was mainly to avoid that the 
> following attack could take place:
> 
> Alice (IDi)       Carol (IDi')       Bob (IDr)
> 
>  ---I-mesasge -->
>                  Change ID and 
>                  add own signature 
>                     --- I'-message --->
>                                  <--- R-message ---
>       <--- R-message ---
> 
> <-------------  communication ------------->
> I'm talking to Bob!                  I'm talking to Carol!
> 
> 
> (You could see this as: Alice should submit her homework to her 
> teacher Bob. Carol didn't do her homework but knows that Alice 
> is a very good student. Therefore, she would like to send in 
> Alice's homework as her own...)
> 
> Even though Carol will not be able to eavesdrop on the 
> communication, it is still a problem that Bob cannot know
> for sure who he is actually talking to. So this was the reason 
> why we mandated the IDi in the response of the DH-mode.
> 
>  
> > I further assuming that making the ID payloads optional has 
> > nothing to do
> > with identity protection?
> 
> Correct
> 
> Best Regards,
> Fredrik
> 
> > 
> > 
> > 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://intranet.icn.siemens.de/marketing/cs27/topics/security/
> > | D-81359 Muenchen               Internet: http://www.siemens.de/
> > | __________________
> > | Germany     
> > --------------------------------------------------------------
> > ---------
> > 
> 

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