> >> OK, but if those extra payloads are disguised as some notification
> >> (there is no payload actually called “info”), then responders do tend
> to ignore notifications they don’t recognize.
> >
> > True, but in this case the inputs to the hash function will be
> > different (you need to insert
> After second read it seems to me that there is one more obstacle to
> that attack in real world.
> It seems that attacker appends original initiator's SAi, KEi, Ni
> payloads to its message sent to responder (as info`). So, this message
> would contain two SA payloads, two KE payloads etc. I bel
OK, but if those extra payloads are disguised as some notification (there is no
payload actually called “info”),
then responders do tend to ignore notifications they don’t recognize.
True, but in this case the inputs to the hash function will be different (you
need to insert Notification
paylo
[HJ] according to this
figure(https://securityblog.redhat.com/wp-content/uploads/2016/01/sloth-ike-2.png):
The IKE_INIT request(m1') send to real responder contain infoi' at the end,
which equals=SAi|g^x|Ni|infoi,
so the actual m1'=HDR|C2|SAi'|g^x'|ni|SAi|g^x|ni|infoi; thus two SA, tw KE, two
N
> On 16 Jan 2016, at 7:17 AM, HU, Jun (Jun) wrote:
>
>
>
>> -Original Message-
>> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of EXT Yoav Nir
>> Sent: Friday, January 15, 2016 8:15 PM
>> To: Valery Smyslov
>> Cc: ipsec@ietf.org; Paul Wouters; Scott Fluhrer (sfluhrer)
>> Subje
