Re: [secdir] Secdir last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

[Rifaat Shekh-Yusef <[e-mail]>]

Hi Valery,

Thanks for engaging with me on this.
Your answers/suggestions below address all my comments and concerns.

Regards,
 Rifaat


On Mon, Apr 1, 2024 at 11:45 AM Valery Smyslov <[e-mail]> wrote:

> Hi Rifaat,
>
>
>
> I snipped parts where we are in agreement.
>
>
>
> Hi Valery,
>
>
>
> See my replies below.
>
>
>
> Regards,
>
>  Rifaat
>
>
>
>
>
> […]
>
>
>
> > * "Since the responder sends the SUPPORTED_AUTH_METHODS notification in
> > the IKE_SA_INIT exchange, it must take care that the size of the response
> > message wouldn't grow too much so that IP fragmentation takes place."
> >
> > Is this limited to the responder? or should the initiator too take that
> into
> > considerations?
>
> It is not limited to the responder in general, but in the context of this
> document
> it is the responder who is going to send a message that could be
> fragmented at IP level.
> Usually the response is smaller than the request. In this case it can be
> larger
> and thus the responder should take care of IP fragmentation.
>
>
>
> Got it.
>
> I am assuming that the fragmentation issue with the initiator request is
> captured in a different document.
>
> If that is the case, then I think it is reasonable to leave this text as
> is.
>
>
>
>          It is described in the IKE fragmentation document (RFC 7383).
>
>          I’ve added a reference to it in the -07 version.
>
>
>
>
>
> > # Section 5
> >
> > Second paragraph: I guess the potential for downgrade attack is not
> limited to the
> > NULL use case. If one of the supported methods is consider to be weaker
> than the
> > others, then an active attacker in the path could force the parties to
> use that
> > weaker method.
>
> This is not a "downgrade" in a common sense. Downgrade assumes that there
> is a negotiation between the peers and an attacker may influence this
> process forcing
> peers to use weaker option. In IKEv2 authentication methods are not
> negotiated.
> This specification doesn't provide negotiation too, since each party
> still chooses what it thinks is appropriate on its own. It only allows
> peers
> to select authentication method more consciously.
>
>
>
> Thanks for the clarification, as I am not an IKE expert.
>
> Having said that, I wonder why you are specifically calling out the NULL
> use case.
>
> Would not the NULL use case be also applicable to weaker authentication
> methods?
>
> Meaning that the attacker in the middle would be able to remove the
> stronger methods and leave the weaker ones?
>
>
>
>          Yes, it is possible. NULL authentication is just the easiest way
> for an attacker to do it.
>
>          I can add the following text in the Security Considerations
> (right after the NULL authentication discussion):
>
>
>
>    Similarly, if an attacker on the path can break some of the announced
>
>    authentication methods, then the attacker can encourage peers to use
>
>    one of these weaker methods by removing all other announcements, and
>
>     if this succeeds, then impersonate one of the peers.
>
>
>
>          Does this help?
>
>
>
>          Regards,
>
>          Valery.
>
>
>
>
>
> Regards,
>
>  Rifaat
>
>
>
>
>
> Regards,
> Valery.
>
>