[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