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

[Ipsec] IKEv2 security considerations draft



I am soliciting interest in an IKEv2 "attack" or "security properties"
draft. Does the WG think such a draft is needed ? Does anyone want to own
this ? 

Some history. In May I offered comments on IKEv2 certificate exposure by the
active adversary which are still pending on the IKEv2 issues list. While I
think that particular issue is important to resolve in IKEv2 prior to
proposed standard, there are other usage issues and by-design security
properties in IKEv2 to explain. So I suggested a full treatment of such
security considerations be done as a separate "IKEv2 attack" draft. To
start, I would offer my own experience of risks to implementers of using
certain options and attribute values in certain scenarios, such as
information leakage provided to an active Internet adversary from CERTREQ in
IKEv1 implementations. IKEv2 doesn't have that CERTREQ problem, but other
issues may be present. The purpose of the draft would be to educate new
IKEv2 implementers on the full range of security considerations for
implementation. To achieve the cryptographic properties discussion similar
to RFC3218, the draft would certainly need a few cryptographers to assist.
My guess is that the cryptographic strengths and weaknesses of the current
IKEv2 design are not documented in one place yet.

While I have interest in an "IKEv2 attack" draft, there are IPsec IPv4/IPv6
deployment issues I'm immersed in that I want to bring to the WG attention
in November. So I'd be happy to contribute to an IKEv2 attack draft, but
don't want to pursue as primary author. 

-Wm

> -----Original Message-----
> From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On 
> Behalf Of Russ Housley
> Sent: Monday, May 24, 2004 9:57 AM
> To: William Dixon
> Cc: charliek@microsoft.com; ipsec@ietf.org
> Subject: RE: [Ipsec] Proposed Last Call based revisions to IKEv2
> 
> William:
> 
> I encourage you to work on the proposed document.  However, I 
> do not want to delay IKEv2 while it it written.  There are 
> other cases in the IETF where similar documents have been 
> written after the base document.  RFC
> 3218 is one example.
> 
> Russ
> 


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec