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.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
