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

[Valery Smyslov <[e-mail]>]

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.