[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.
- [IPsec] Resolving Roadmap Issue #114 Frankel, Sheila E.
- [IPsec] Resolving Roadmap Issue #114 Tero Kivinen
- Re: [IPsec] Resolving Roadmap Issue #114 Paul Hoffman