Re: [netmod] x509c2n:cert-to-name problem
Martin Bjorklund <mbj@tail-f.com> Mon, 28 October 2019 09:22 UTC
Return-Path: <mbj@tail-f.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDCE1200DF for <netmod@ietfa.amsl.com>; Mon, 28 Oct 2019 02:22:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x55Y8x-33gTM for <netmod@ietfa.amsl.com>; Mon, 28 Oct 2019 02:22:48 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C659112003F for <netmod@ietf.org>; Mon, 28 Oct 2019 02:22:47 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id BACB11AE02BD; Mon, 28 Oct 2019 10:22:45 +0100 (CET)
Date: Mon, 28 Oct 2019 10:22:16 +0100
Message-Id: <20191028.102216.1541488608391720310.mbj@tail-f.com>
To: kent@watsen.net
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <0100016e0416c312-13b65019-1c32-4fc8-b8b2-f2b7cc591a00-000000@email.amazonses.com>
References: <netconf-wg/https-notif/issues/3/545072069@github.com> <20191023.101844.48270589337022568.mbj@tail-f.com> <0100016e0416c312-13b65019-1c32-4fc8-b8b2-f2b7cc591a00-000000@email.amazonses.com>
X-Mailer: Mew version 6.8 on Emacs 25.2
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/YlhmxK0i2jx9t-ABGJ9U-fWeC6s>
Subject: Re: [netmod] x509c2n:cert-to-name problem
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Oct 2019 09:22:49 -0000
Kent Watsen <kent@watsen.net> wrote: > > > > On Oct 23, 2019, at 4:18 AM, Martin Bjorklund <mbj@tail-f.com> wrote: > > > > Hi, > > > > Since this is a problem with ietf-x509-cert-to-name I reply to this > > question here, rather than buried in a reply to another issue for > > another document ;-) > > > > Kent Watsen <notifications@github.com> wrote: > >> Separately, I just noticed an issue with the > >> `ietf-[net/rest]conf-server` modules using x509c2n:cert-to-name. > >> > >> ``` > >> leaf fingerprint { > >> type x509c2n:tls-fingerprint; > >> mandatory true; > >> description > >> "Specifies a value with which the fingerprint of the > >> full certificate presented by the peer is compared. If > >> the fingerprint of the full certificate presented by the > >> peer does not match the fingerprint configured, then the > >> entry is skipped, and the search for a match continues."; > >> ``` > >> > >> This definition seems to exclude authenticating client certificates > >> via a trust anchor certificate as, if one can configure a fingerprint, > >> then one could also configure the whole certificate (e.g., > >> `tls-server-parameters/client-authentication/client-certs`), thus > >> obviating the need for > >> `tls-server-parameters/client-authentication/ca-certs`. > > > > [...] > > > >> A better definition (I think) would've been: > >> > >> ``` > >> OLD: full certificate presented by the peer > >> NEW: full certificate of the certificate used to authenticate the > >> certificate presented by the peer, which MAY be the peer's end-entity > >> certificate. > >> ``` > > > > Hmm, I think you found an inconsisteny in this module. Note that the > > description of the list itself has: > > > > The cert-to-name entry's fingerprint > > determines whether the list entry is a match: > > > > 1) If the cert-to-name list entry's fingerprint value > > matches that of the presented certificate, then consider > > the list entry a successful match. > > > > 2) If the cert-to-name list entry's fingerprint value > > matches that of a locally held copy of a trusted CA > > certificate, and that CA certificate was part of the CA > > certificate chain to the presented certificate, then > > consider the list entry a successful match. > > > > Also note: > > > > Security administrators are encouraged to make use of > > certificates with subjectAltName fields that can be mapped to > > names so that a single root CA certificate can allow all > > child certificates' subjectAltName fields to map directly to > > a name via a 1:1 transformation. > > > > So I think this is a bug in the description of "leaf fingerprint". > > I'd rather it be that than a bug in "list cert-to-name". Would an > erratum be appropriate here? While the fix effectively changes the > meaning of "fingerprint", it only would do so in order to resolve the > inconsistency, and thus seems necessary. > > Martin, if you agree, would to like to propose text or go straight to > submitting an erratum? I'll check with my co-author and get back. > >> I note that `fingerprint` may be 0 characters in length, which is what > >> netconf/restconf servers wanting to support authenticating clients via > >> a trust anchor will need to do in their configurations. I'll update > >> the examples in those drafts to include an empty `fingerprint` node. > > > > But 0-length fingerprint won't match anything, which means you won't > > get a user name and the client can't be authenticated, and the session > > dropped. > > Actually, I thought that this was on purpose, as SnmpTLSFingerprint in > RFC 6353 (referenced by "typedef tls-fingerprint" says (note the 3rd > paragraph): > > SnmpTLSFingerprint ::= TEXTUAL-CONVENTION > DISPLAY-HINT "1x:1x" > STATUS current > DESCRIPTION > "A fingerprint value that can be used to uniquely reference > other data of potentially arbitrary length. > > An SnmpTLSFingerprint value is composed of a 1-octet hashing > algorithm identifier followed by the fingerprint value. The > octet value encoded is taken from the IANA TLS HashAlgorithm > Registry (RFC 5246). The remaining octets are filled using the > results of the hashing algorithm. > > This TEXTUAL-CONVENTION allows for a zero-length (blank) > SnmpTLSFingerprint value for use in tables where the > fingerprint value may be optional. MIB definitions or > implementations may refuse to accept a zero-length value as > appropriate." > REFERENCE "RFC 5246: The Transport Layer > Security (TLS) Protocol Version 1.2 > http://www.iana.org/assignments/tls-parameters/ > " > SYNTAX OCTET STRING (SIZE (0..255)) > > Does it not have the same meaning? No, in many SMIv2 objects, a zero-length value is used for optional nodes (due to the way the protocol (SNMP) works). In YANG we don't do this, since the protocls (NETCONF etc) can handle non-existing optional leafs. /martin > > Kent // contributor > > > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod >
- [netmod] x509c2n:cert-to-name problem [WAS: [netc… Martin Bjorklund
- Re: [netmod] x509c2n:cert-to-name problem [WAS: [… Kent Watsen
- Re: [netmod] x509c2n:cert-to-name problem Martin Bjorklund
- Re: [netmod] x509c2n:cert-to-name problem Kent Watsen
- Re: [netmod] x509c2n:cert-to-name problem Randy Presuhn
- Re: [netmod] x509c2n:cert-to-name problem Martin Bjorklund
- Re: [netmod] x509c2n:cert-to-name problem Martin Bjorklund
- Re: [netmod] x509c2n:cert-to-name problem
- Re: [netmod] x509c2n:cert-to-name problem Kent Watsen
- Re: [netmod] x509c2n:cert-to-name problem
- Re: [netmod] x509c2n:cert-to-name problem Randy Presuhn
- Re: [netmod] x509c2n:cert-to-name problem Martin Bjorklund
- Re: [netmod] x509c2n:cert-to-name problem Kent Watsen
- Re: [netmod] x509c2n:cert-to-name problem
- Re: [netmod] x509c2n:cert-to-name problem Martin Bjorklund
- Re: [netmod] x509c2n:cert-to-name problem Kent Watsen