[IPsec] Resolving Roadmap Issue #114

"Frankel, Sheila E." <sheila.frankel@nist.gov> Thu, 03 December 2009 17:43 UTC

Return-Path: <sheila.frankel@nist.gov>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE02F28C192 for <ipsec@core3.amsl.com>; Thu, 3 Dec 2009 09:43:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6vXwXXGB+2S for <ipsec@core3.amsl.com>; Thu, 3 Dec 2009 09:43:04 -0800 (PST)
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 802E928C190 for <ipsec@ietf.org>; Thu, 3 Dec 2009 09:43:04 -0800 (PST)
Received: from WSXGHUB1.xchange.nist.gov (wsxghub1.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id nB3HgfgJ030707; Thu, 3 Dec 2009 12:42:41 -0500
Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([2002:8106:1260::8106:1260]) with mapi; Thu, 3 Dec 2009 12:42:41 -0500
From: "Frankel, Sheila E." <sheila.frankel@nist.gov>
To: "ipsec@ietf.org" <ipsec@ietf.org>
Date: Thu, 03 Dec 2009 12:42:40 -0500
Thread-Topic: Resolving Roadmap Issue #114
Thread-Index: Acp0QAJgtTl41raORXSDtOUqzOycVw==
Message-ID: <D7A0423E5E193F40BE6E94126930C493078C303072@MBCLUSTER.xchange.nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_D7A0423E5E193F40BE6E94126930C493078C303072MBCLUSTERxcha_"
MIME-Version: 1.0
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: sheila.frankel@nist.gov
Cc: "suresh.krishnan@ericsson.com" <suresh.krishnan@ericsson.com>, Paul Hoffman <paul.hoffman@vpnc.org>, Tero Kivinen <kivinen@iki.fi>
Subject: [IPsec] Resolving Roadmap Issue #114
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Dec 2009 17:43:05 -0000

Issue #114: Expired drafts, especially BEET

==> Tero and Yaron suggested wording changes. The 2nd paragraph below contains those changes.

#114: Expired drafts, especially BEET

Proposed changes to Roadmap doc:

Add text to the introductory section for IKEv1, Section 4.1.1:

Additional text (revised since last email):

   IKE is the preferred key management protocol for IPsec. It is used for
   peer authentication; to negotiate, modify and delete SAs;  and to
   negotiate authenticated keying material for use within those SAs.  The
   standard peer authentication methods used by IKEv1 (pre-shared secret
   keys and digital certificates) had several shortcomings related to use
   of IKEv1 to enable remote user authentication to a corporate VPN: it
   could not leverage the use of legacy authentication systems (e.g. RADIUS
   databases) to authenticate a remote user to a security gateway; and it
   could not be used to configure remote users with network addresses or
   other information needed in order to access the internal network.

   Several Internet Drafts were written to address these problems:
   Extended Authentication withn IKE (XAUTH) (draft-beaulieu-ike-xauth and
   its predecessor draft-ietf-ipsra-isakmp-xauth) and The ISAKMP Configuration
   Method (draft-dukes-ike-mode-cfg and its predecessor draft-ietf-ipsec-isakmp-
   mode-cfg).  These drafts did not progress to RFC status due to security
   flaws and other problems related to these solutions. However, many current
   IKEv1 implementations incorporate aspects of these solutions to facilitate
   remote user access to corporate VPNs. These solutions were not standardized,
   and different implementations implemented different versions. Thus, there
   is no assurance that the implementations adhere fully to the suggested
   solutions, or that one implementation can interoperate with others that
   claim to incorporate the same features. Furthermore, these solutions have
   known security issues. Thus, use of these solutions is not recommended.