Subject: [Ipsec] Another IKEv2 issue IKE SA with NONE INTEG and/or ENCR_NULL as ENCR.

From: Tero Kivinen <[email-masked]>
Date: Wed, 8 Sep 2004 12:06:48 +0300

Dondeti, Lakshminath writes:
> First, glad you caught this.  While I understand that key exchange will 
> work without encryption, I always assumed confidentiality and integrity 
> protection for IKEv2 messages beyond the INIT messages (2 or 4).  My 
> guess would be that most implementations work with similar assumptions.  
> However, it is important that spec be complete to avoid any future 
> compliance and interop hassles.

I had also the same assumption... My assumption was so strong, that I
had never even checked this, and I just noticed it now because I was
looking something completely different thing, and started wondering
where does it say they are mandatory, and noticed that the text was
not there.

I never assumed that this was intentional, I assumed this was serious
bug in the document...

> So, here is an attempt at the additional text to the security 
> considerations section, assuming you are still interested in this topic.

Sure. 

> While the basic IKEv2 AKE or the SIGMA protocol would work without 
> confidentiality and integrity protection of messages, the same cannot be 
> said for several additional features such as identity protection, 
> protection of traffic selectors etc.  Without integrity protection, an 
> adversary can modify the TS payloads to trick negotiating peers to 
> narrow the range of address prefixes or ports from the scope of an IPsec 
> SA.  Similarly, NULL encryption of IKEv2 messages leaves the identities 
> and traffic selectors (which may contain private addresses), and other 
> configuration information readily available to eavesdroppers.  Several 
> DoS attacks are also possible: <list one or two high-impact ones>.

There is also some EAP methods which might also require encrypted
tunnel, don't know. The DoS attacks include ability to send IKEv2 SA
delete message, which will cause the IKE SA and all IPsec SAs to be
deleted, this can be send from anywhere in the world (i.e. from random
IP address), as long as the attacker knows the IKEv2 SPIs and can
guess the message ID.

Attacker can also make new IPsec SAs at will causing resource shortage
on the other end and so on.  

> If this sounds good, please revise and post to the list.   Or, you might 
> want to just write your own :-).

This sounds good, I have included new modified version in this mail,
and CC'd it to the list.

The final MUST NOT could also be SHOULD NOT (but I would prefer MUST).
Do we really see any use for running IKEv2 without integrity and
encryption? 

Text to be adde dto the security consideartions section:
----------------------------------------------------------------------
    While the basic IKEv2 AKE or the SIGMA protocol would work without
    confidentiality and integrity protection of messages, the same
    cannot be said for several additional features such as identity
    protection, protection of traffic selectors etc. Without integrity
    protection, an adversary can modify the TS payloads to trick
    negotiating peers to narrow the range of address prefixes or ports
    from the scope of an IPsec SA. Attackers can also cause all kind
    of DoS attacks, like deleting all IKE and IPsec SAs at will
    (delete notifications, initial contact notifications), and those
    attacks can be mounted from any IP address, by just knowing the
    IKE SA SPIs and guessing the message ID. Attacker can also create
    (unusable) IPsec SAs at will, and may be causing resource shortage
    on the any of the hosts.

    Similarly, NULL encryption of IKEv2 messages leaves the identities
    and traffic selectors (which may contain private addresses), and
    other configuration information readily available to
    eavesdroppers. This also reveals EAP packets to the passive
    attacker, and attackers could use them to replay some EAP
    authentications to another EAP server. The configuration payloads
    contains internal network configuration information which is also
    revealed to the attackers. Also future expansions might require
    authenticated and encrypted channel to work properly.

    Because of this integrity algorithm NONE and encryption algorithm
    ENCR_NULL for IKE SA MUST NOT be used.
-- 
[email-masked]

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Paul Koning <[email-masked]>
Date: Wed, 8 Sep 2004 09:38:41 -0400

>>>>> "Tero" == Tero Kivinen <[email-masked]> writes:

 Tero> Dondeti, Lakshminath writes:
 >> First, glad you caught this.  While I understand that key exchange
 >> will work without encryption, I always assumed confidentiality and
 >> integrity protection for IKEv2 messages beyond the INIT messages
 >> (2 or 4).  My guess would be that most implementations work with
 >> similar assumptions.  However, it is important that spec be
 >> complete to avoid any future compliance and interop hassles.

 Tero> I had also the same assumption... My assumption was so strong,
 Tero> that I had never even checked this, and I just noticed it now
 Tero> because I was looking something completely different thing, and
 Tero> started wondering where does it say they are mandatory, and
 Tero> noticed that the text was not there.

 Tero> I never assumed that this was intentional, I assumed this was
 Tero> serious bug in the document...

Agreed.

I can see no good reason to permit this, and very good reasons to
forbid it.

Null encryption exists in ESP to work around crypto law issues, but I
don't see how those are relevant to IKE.

      paul

---

From: Stephen Kent <[email-masked]>
Date: Wed, 8 Sep 2004 16:56:42 -0400

>don't see how those are relevant to IKE.

Paul,

NULL encryption exists in ESP not to work around export control 
issues (we have AH for that) but to allow efficient, integrity-only 
processing where is it needed and where confidentiality is not 
required (and might cause technical problems, add undesirable 
overhead, etc.)

Steve