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

From: "Charlie Kaufman" <[email-masked]>
Date: Tue, 7 Sep 2004 11:00:48 -0700

Working group last call completed over a year ago. I don't believe any
clarification is needed, though I agree that some words on this in the
security considerations section wouldn't hurt. Even with continued
revisions, the document will never be perfect; but it will eventually be
irrelevant.

It would appear that there will be one more revision to the spec
concerning minimum UDP message size support. Hopefully, that will be
this week. If you want this change, I would ask that you post proposed
wording to the list and get the chairs to declare consensus. Both very
quickly.

	--Charlie

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

Charlie Kaufman writes:
> 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.

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...".

> 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.

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
> itself.

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]

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