Re: [netmod] x509c2n:cert-to-name problem [WAS: [netconf-wg/https-notif] What is the user-id of the entity sending the notification? (#3)]

> 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 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?

Kent // contributor

> 
> 
> /martin
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod