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

From: "Charlie Kaufman" <[email-masked]>
Date: Fri, 3 Sep 2004 10:40:51 -0700

I disagree.

IKEv2 was specifically designed so that it would maintain most of its
security properties even if its encryption algorithm were broken (or
NULL). Yes, identities and traffic selectors would be exposed. But the
key derivation and authentication would still be secure. It would be
entirely appropriate to use ENCR_NULL in IKE if AH was being negotiated
or ENCR_NULL were being negotiated in the underlying ESP.

Similarly, if IKE negotiated NONE as its integrity protection algorithm,
the subsequently negotiated ESP and AH SAs would still be secure (though
the protocol would be exposed to some "downgrade" attacks if the
endpoints were not both properly configured.

So I don't believe these should be ruled out in the IKEv2 specification
itself.

In Jeff's algorithms document, ENCR_NULL is listed as *MAY* implement,
which I believe is appropriate. NONE for integrity is not labeled.
Perhaps it should be labeled MUST NOT. (I think it's OK as is, but I
understand your concern).

	--Charlie

-----Original Message-----
From: Dondeti, Lakshminath [mailto:[email-masked]] 
Sent: Friday, September 03, 2004 5:58 AM
To: Tero Kivinen
Cc: [email-masked]; [email-masked]; [email-masked]; Charlie
Kaufman; [email-masked]; [email-masked]
Subject: Re: [Ipsec] Another IKEv2 issue IKE SA with NONE INTEG and/or
ENCR_NULL as ENCR.

Tero Kivinen wrote:

>I just noticed that we do not forbid of using encrption algorithm
>ENCR_NULL and integrity algorithm NONE for the IKE SA. Or at least I
>didn't find text about it.
>
>I think we should explicitly say that integrity algorithm cannot be
>NONE in IKE SA (it will completely break the authentication I think),
>and perhaps same thing about encryption algorithm ENCR_NULL (it will
>break the identity protection).
>
>So add a paragraph to section 3.3.3 saying:
>
>"For the IKE SA integrity algoritm MUST NOT be NONE, and encryption
>algorithm MUST NOT be ENCR_NULL."
>  
>
This probably was a side-effect of separating algorithms out of the 
spec.  This text should go into the security considerations, I would
think.

regards,
Lakshminath

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

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Fri, 03 Sep 2004 14:24:26 -0400

Agreed that IKEv2 will provide secure key establishment with the NULL 
algorithms, but as you note, other security properties (e.g., no ID 
protection, the TS payloads are exposed, and worse can be modified - and 
that would be a problem if TS's are used to dynamically update SPDs as 
described in Section 2.9 of ikev2-15 -  if AUTH_NULL were to be allowed) 
of the protocol do not hold.  

 I hope this can be documented in the security considerations section of 
the ikev2- algorithms I-D.  There is discussion there about the MUST and 
SHOULD algorithms, but none about the MAY algorithms (ENCR_NONE; and if 
possible a note about the MD5 algorithms would also be a welcome 
addition).   Thanks.

I am not sure about the implications of NULL algorithms in case of EAP 
(Section 2.16);  there is a note in Section 5 of ikev2-15, that 
non-key-generating methods SHOULD use a protected tunnel, which is 
good.  Is it ok to use ENCR_NULL with any key-generating method of EAP?

regards,
Lakshminath

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 6 Sep 2004 11:59:19 +0300

> or ENCR_NULL were being negotiated in the underlying ESP.

I think the security considerations section do assume we use
encryption: "While this protocol is designed to minimize disclosure of
configuration information to unauthenticated peers...".

> endpoints were not both properly configured.

Hmmm... at least we need strong comments to the security
considerations section. Also even when IKEv2 base SKEYSEED is
protected even when there is no encryption or authentication on the
IKEv2, it does not mean that all extensions done later are safe. For
example you easily cause denial of service, by just sending one Delete
notification to the other end killing the IKE_SA etc, or you can
create new IPsec SAs at will (you do not know the key, but you can
cause resource exchaustion on the other end etc). 

> So I don't believe these should be ruled out in the IKEv2 specification

I think we should rule them out. It will be much simplier for
everybody if we say that there will be encryption and authentication
on the packets. I do not see any reason why we should allow such thing
in the base IKEv2 spec. 
-- 
[email-masked]