Re: [netmod] x509c2n:cert-to-name problem

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
> 