[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Protocol Action: 'The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX' to Proposed Standard
The IESG has approved the following document:
- 'The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX '
<draft-ietf-pki4ipsec-ikecert-profile-12.txt> as a Proposed Standard
This document is the product of the Profiling Use of PKI in IPSEC Working
Group.
The IESG contact persons are Russ Housley and Sam Hartman.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pki4ipsec-ikecert-profile-12.txt
Technical Summary
This document specifies a profile for the use of Certificates for
identification in the IKEv1 and IKEv2 protocols. These protocols say
very little about the certificates, and a fair amount of industry
practice has built up around bake-offs and interop events over the
last 8 years. This profile captures the best of those practices. It
is targeted to two main audiences: implementors who are building
interoperable products, and deployers who need to know how to
configure the systems. The profile also provides guidance to the PKI
community about the needs of the IPsec VPN application.
Working Group Summary
The initial draft came from IPsec WG, and was completed in the
PKI4IPsec WG. An issue tracker was used to make sure that all issues
were addressed. The PKI4IPsec WG has strong consensus that this
document should be published as a Proposed Standard.
Protocol Quality
Every mid- to large-size IPsec implementation supports this profile,
and at least four PKI vendors support this profile.
This document was reviewed by Russ Housley for the IESG.
Note to RFC Editor
In section 3.1.1, please make the following change:
OLD:
In addition, implementations MUST be capable of verifying that the
address contained in the ID is the same as the peer source address,
contained in the outer most IP header.
NEW:
In addition, implementations MUST be capable of verifying that the
address contained in the ID is the same as the address
contained in the IP header. Implementations SHOULD be
able to check the address in either the outermost or
innermost IP header and MAY provide a cotf-announce-bounces at ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1HWIDs-0005sP-Ld; Tue, 27 Mar 2007 16:24:52 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43) id 1HWIDq-0005sA-CB
for ietf-announce at ietf.org; Tue, 27 Mar 2007 16:24:50 -0400
Received: from ns4.neustar.com ([156.154.24.139])
by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HWIDq-0001bI-1y
for ietf-announce at ietf.org; Tue, 27 Mar 2007 16:24:50 -0400
Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com
[10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id F00642AC2B;
Tue, 27 Mar 2007 20:24:19 +0000 (GMT)
Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43)
id 1HWIDL-00073R-NZ; Tue, 27 Mar 2007 16:24:19 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary at ietf.org>
To: IETF-Announce <ietf-announce at ietf.org>
Message-Id: <E1HWIDL-00073R-NZ at stiedprstage1.ietf.org>
Date: Tue, 27 Mar 2007 16:24:19 -0400
X-Spam-Score: -2.8 (--)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: pki4ipsec chair <pki4ipsec-chairs at tools.ietf.org>,
Internet Architecture Board <iab at iab.org>,
pki4ipsec mailing list <pki4ipsec at icsalabs.com>,
RFC Editor <rfc-editor at rfc-editor.org>
Subject: Protocol Action: 'The Internet IP Security PKI Profile
of IKEv1/ISAKMP, IKEv2, and PKIX' to Proposed Standard
X-BeenThere: ietf-announce at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
<mailto:ietf-announce-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce at ietf.org>
List-Help: <mailto:ietf-announce-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>,
<mailto:ietf-announce-request at ietf.org?subject=subscribe>
Errors-To: ietf-announce-bounces at ietf.org
The IESG has approved the following document:
- 'The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX '
<draft-ietf-pki4ipsec-ikecert-profile-12.txt> as a Proposed Standard
This document is the product of the Profiling Use of PKI in IPSEC Working
Group.
The IESG contact persons are Russ Housley and Sam Hartman.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pki4ipsec-ikecert-profile-12.txt
Technical Summary
This document specifies a profile for the use of Certificates for
identification in the IKEv1 and IKEv2 protocols. These protocols say
very little about the certificates, and a fair amount of industry
practice has built up around bake-offs and interop events over the
last 8 years. This profile captures the best of those practices. It
is targeted to two main audiences: implementors who are building
interoperable products, and deployers who need to know how to
configure the systems. The profile also provides guidance to the PKI
community about the needs of the IPsec VPN application.
Working Group Summary
The initial draft came from IPsec WG, and was completed in the
PKI4IPsec WG. An issue tracker was used to make sure that all issues
were addressed. The PKI4IPsec WG has strong consensus that this
document should be published as a Proposed Standard.
Protocol Quality
Every mid- to large-size IPsec implementation supports this profile,
and at least four PKI vendors support this profile.
This document was reviewed by Russ Housley for the IESG.
Note to RFC Editor
In section 3.1.1, please make the following change:
OLD:
In addition, implementations MUST be capable of verifying that the
address contained in the ID is the same as the peer source address,
contained in the outer most IP header.
NEW:
In addition, implementations MUST be capable of verifying that the
address contained in the ID is the same as the address
contained in the IP header. Implementations SHOULD be
able to check the address in either the outermost or
innermost IP header and MAY provide a configuration option
for specifying which is to be checked. If there is no
configuration option provided, an implementation SHOULD
check the peer source address contained in the outermost
header (as is the practice of most of today's implementations).
In section 5.1.3.12, please make the following change:
OLD:
A summary of the logic flow for peer certificate validation regarding
the EKU extension follows:
NEW:
Conforming IKE implementations are not required to support EKU.
If a critical EKU extension appears in a certificate and EKU is
not supported by the implementation, then RFC 3280 requires that
the certificate be rejected. Implementations that do support EKU
MUST support the following logic for certificate validation:
_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
nfiguration option
for specifying which is to be checked. If there is no
configuration option provided, an implementation SHOULD
check the peer source address contained in the outermost
header (as is the practice of most of today's implementations).
In section 5.1.3.12, please make the following change:
OLD:
A summary of the logic flow for peer certificate validation regarding
the EKU extension follows:
NEW:
Conforming IKE implementations are not required to support EKU.
If a critical EKU extension appears in a certificate and EKU is
not supported by the implementation, then RFC 3280 requires that
the certificate be rejected. Implementations that do support EKU
MUST support the following logic for certificate validation:
_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce