[IPsec] Populating ID_DER_ASN1_DN
David Wierbowski <wierbows@us.ibm.com> Thu, 17 September 2009 02:32 UTC
Return-Path: <wierbows@us.ibm.com>
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 0B2AF3A6A1E for <ipsec@core3.amsl.com>; Wed, 16 Sep 2009 19:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.692
X-Spam-Level:
X-Spam-Status: No, score=-5.692 tagged_above=-999 required=5 tests=[AWL=0.906, 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 2fsT9yCrStux for <ipsec@core3.amsl.com>; Wed, 16 Sep 2009 19:32:33 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.141]) by core3.amsl.com (Postfix) with ESMTP id 09B4F3A6900 for <ipsec@ietf.org>; Wed, 16 Sep 2009 19:32:32 -0700 (PDT)
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n8H2WVIY025143 for <ipsec@ietf.org>; Wed, 16 Sep 2009 22:32:31 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8H2XG0S214546 for <ipsec@ietf.org>; Wed, 16 Sep 2009 22:33:17 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8H2XGRc031475 for <ipsec@ietf.org>; Wed, 16 Sep 2009 22:33:16 -0400
Received: from d01ml084.pok.ibm.com (d01ml084.pok.ibm.com [9.63.10.23]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8H2XGcT031469 for <ipsec@ietf.org>; Wed, 16 Sep 2009 22:33:16 -0400
X-KeepSent: D4A5DB2F:BDD2E710-85257634:000AE8AB; type=4; name=$KeepSent
To: ipsec@ietf.org
X-Mailer: Lotus Notes Release 8.0.2FP1 SHF149 July 17, 2009
Message-ID: <OFD4A5DB2F.BDD2E710-ON85257634.000AE8AB-85257634.000E0809@us.ibm.com>
From: David Wierbowski <wierbows@us.ibm.com>
Date: Wed, 16 Sep 2009 22:33:14 -0400
X-MIMETrack: Serialize by Router on D01ML084/01/M/IBM(Release 8.0.2FP1|November 13, 2008) at 09/16/2009 22:33:16
MIME-Version: 1.0
Content-type: multipart/alternative; Boundary="0__=0ABBFCA7DF996E3B8f9e8a93df938690918c0ABBFCA7DF996E3B"
Content-Disposition: inline
Subject: [IPsec] Populating ID_DER_ASN1_DN
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, 17 Sep 2009 02:32:34 -0000
Section 3.1.5 of RFC 4945 states that when generating an ID type of ID_DER_ASN1_DN that "implementations MUST populate the contents of ID with the Subject field from the end-entity certificate, and MUST do so such that a binary comparison of the two will succeed." Section 3.1.5 is specific to IKEv1. There is no such requirement listed in Section 4 which is applicable to IKEv2. What is the purpose of this requirement and why is it only applicable to IKEv1? I believe in the past it has been said that the requirement exists because smaller devices may not be capable of performing DN matching. If that's the case it seems the issue would be applicable to IKEv2 as well. Section Section 3.1.5 also states, "Regarding SPD matching, implementations MUST be able to perform matching based on a bitwise comparison of the entire DN in ID to its entry in the SPD. However, operational experience has shown that using the entire DN in local configuration is difficult, especially in large-scale deployments. Therefore, implementations also MUST be able to perform SPD matches of any combination of one or more of the C, CN, O, OU attributes within Subject DN in the ID to the same in the SPD." What is the purpose of requiring the ability to match on a bitwise comparison of the entire DN if it is also acceptable to match any combination of one or more of the C, CN, O, OU attributes? It seems that only implementing the second MUST would be sufficient. If the ID matches a bitwise comparison of the entire DN it will also match a combination of one or more of the C, CN, O, OU attributes. Dave Wierbowski
- [IPsec] Populating ID_DER_ASN1_DN David Wierbowski
- Re: [IPsec] Populating ID_DER_ASN1_DN Raj Singh
- Re: [IPsec] Populating ID_DER_ASN1_DN Yoav Nir
- Re: [IPsec] Populating ID_DER_ASN1_DN David Wierbowski
- Re: [IPsec] Populating ID_DER_ASN1_DN Yoav Nir
- Re: [IPsec] Populating ID_DER_ASN1_DN Tero Kivinen