[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-ietf-ipsec-ikev2-00.txt

shane@amante.org (Shane Amante) writes:
> 2.6 Cookies
> My observation is that Paragraph 6 ("It may be convenient for the
> IKE-SA identifier ...") seems to be adding more complexity, rather
> than promoting the stated goal of reducing it.  Is it too onerous to
> get rid of the feature described in Paragraph 6?

Actually the feature that allows the responder to change the cookie
also fixes one denial of service attack for the active attacker, which
can listen all packets, and can send packets, but cannot remove
packets in transit.

The attack is as following (ci = initiators cookie, cr = responders
cookie, ca = attackers cookie):

   Initiator		Attacker		Responder

1. HDR(0,ci), SA, KE, Ni  -->

(attacker sees that and sends fake packet init-reject
 packet to request cookie from the Initiator)

2.    <-- HDR(ci,ca), N(IKE-SA-INIT-REJECT)

(the original packet is received by the responder, it replies to it)

3.				 <-- HDR(ci,cr), SA, KE, Nr

(Initiator replies to the attackers packet)

4. HDR(ca,ci), SA, KE, Ni -->

(Responder will ignore this packet as the cookie ca does not match).
(When the initiator sees the responders reply packet, it notices that
the responder has received its 2nd packet and seems to have changed
his cookie, thus it sends next packet)

5. HDR*(cr,ci), ID, AUTH -->

(and the exchange continues).

Of course the attacker could also always send other error
notifications instead, but they are hopefully ignored by the initiator
when he sees the real reply packet from the responder (i.e the
if IKE end receives error notification without any protection it
should wait for a while for real packet to arrive before acting based
on the unauthenticated notification).

Also if the initiator receives a valid 2nd packet with cookies, and
then another packet with another cookie, it should reply to both
packets with same data (i.e retransmit packet but change the recipient
cookie). This will fix the attack where the attacker sends valid reply
packets but with wrong cookie, thus causing the initiator to use wrong
cookie, and exchange to fail.

The second attack is like this:

   Initiator		Attacker		Responder
1. HDR(0,ci), SA, KE, Ni  -->
2.    <-- HDR(ci,ca), SA, KE, Nr
3. HDR*(ca,ci), ID, AUTH
4.				 <-- HDR(ci,cr), SA, KE, Nr

After that the exchange fails, as the initiator has wrong responder
cookie.

The fixed exchange is like this:

   Initiator		Attacker		Responder
1. HDR(0,ci), SA, KE, Ni  -->
2.    <-- HDR(ci,ca), SA, KE, Nr
3. HDR*(ca,ci), ID, AUTH
4.				 <-- HDR(ci,cr), SA, KE, Nr
5. HDR*(cr,ci), ID, AUTH
6.				 <-- HDR*(ci,cr), ID, AUTH

Perhaps the cookies should be renamed to addresses and their usage
changed to so that source address, is ignored when packet is received,
and when reply is sent to packet it is sent to the source address of
the incoming packet to which this is reply (i.e the source and
destination address (was cookies) are simply always swapped). The
other end can change its address at any time.

> Also, in what real-world deployment scenarios would the 'Critical' bit
> be used in IKEv2?  In particular, this section says the 'Critical' bit
> is 0 for all payloads defined in this document [IKEv2] and if it's 0
> then the sender doesn't mind if the receiver skips this payload.

I assume the the critical bit for IKEv2 defined payloads is 0 because
they are not extensions they are part of the base protocol. It also
keeps the most of the payload bit-by-bit compatible with IKEv1
payloads... 

> 7.7 Certificate Request Payload
> 
> Last sentence in this section: "If no certificates exist then no
> further processing is performed-- this is not an error condition of
> the protocol."  I recommend that this be considered an error in
> IKEv2, otherwise how is the sender of the CERTREQ going to know
> what was the specific problem with it's request?  I recommend the
> following language:
>    If no certificates exist, no further processing is performed.  A
>    NOTIFY MUST be sent to the sender of the CERTREQ informing them of
>    this fact using an appropriate error code, (defined below in the 
>    "error codes" section of IKEv2 memo).

I hope that you mean that the negotiation still continues as normally,
we just include that notification payload to the reply packet, but do
not consider it as an error condition of the protocol. I think it must
be warning condition only not error condition. There are quite a lot
of cases where the other end cannot fullfill the certificate requests
the other end sent, but the authentication can still succeed as the
other end can use some other means to fetch the certificate. 



> 7.10.1 Notify Message Types
> 
> Is it recommended that multiple NOTIFY payloads be packed into a
> single Informational exchange?  Or, should multiple NOTIFY payloads be
> put in their own, separate IKE messages?
> 
> Here are a few more suggestions, which are probably going to be quite
> controversial since they go against the grain of re-using as much
> of IKEv1 as possible:

I think we should use the format described in the
draft-ietf-ipsec-notifymsg-04.txt (which seems to have expired). 
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
References: