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

From: "Steffen Fries" <[email-masked]>
Date: Wed, 02 Jun 2004 15:46:13 +0200

Hi,

I think that the introduction of the IDr payload in is very 
useful, as it counters some DoS attacks on one hand as also 
reflection attacks, which may be targeted to the initiator of a 
MIKEY session. 

As Martin mentioned, there are other protocols, were the same 
approach has been taken to counter those attacks.

Regarding the definition of mandatory or optional support of the 
IDr payload I go along with your proposal to have it OPTIONAL 
but (STRONGLY) RECOMMENDED. Sometimes it may be hard to know to 
IDr in advance.

Regarding multicast and the pre-shared secret MIKEY variant, one 
may use a group identifier in the IDr payload instead of a peer 
identifier. Since in this case a group already shares a secret 
key, the identifier may not be peer specific.

Regards
	Steffen 

Date sent:      	Fri, 28 May 2004 15:59:54 +0200
From:           	Mats Näslund <[email-masked]>
To:             	Euchner Martin <[email-masked]>
Subject:        	Re: [MSEC] MIKEY: additional change suggested
Copies to:      	Russ Housley <[email-masked]>, MSEC <[email-masked]>

> 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
> 
> Euchner Martin wrote:
> 
> >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.
> >
> 
> 
> _______________________________________________
> 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: Wed, 02 Jun 2004 16:16:26 +0200

Hi

Thanks for the feedback and additional suggestions. We agree.

Best,

/Mats