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 (CET)
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
>