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

From: Martin Bjorklund <[email-masked]>
Date: Wed, 23 Oct 2019 10:18:44 +0200 (CEST)

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 <[email-masked]> 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 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.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Fri, 25 Oct 2019 18:03:51 +0000

> On Oct 23, 2019, at 4:18 AM, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

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?

> get a user name and the client can't be authenticated, and the session

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Oct 2019 10:22:16 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> 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.
> 

I'll check with my co-author and get back.

> Actually, I thought that this was on purpose, as SnmpTLSFingerprint in
> RFC 6353 (referenced by "typedef tls-fingerprint" says (note the 3rd
> paragraph):
> 

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

---

From: Kent Watsen <[email-masked]>
Date: Mon, 28 Oct 2019 15:47:58 +0000

Hi Martin,

> I'll check with my co-author and get back.

Thanks.

> this, since the protocls (NETCONF etc) can handle non-existing

In that case, there might be two issues:

	1) the description statement excluding CA certs (mentioned before)
	2) `mandatory true` should be `mandatory false` ?

Kent // contributor

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 28 Oct 2019 20:59:37 -0700

Hi -

On 10/28/2019 2:22 AM, Martin Bjorklund wrote:
...
> nodes (due to the way the protocol (SNMP) works).

This comes as a complete surprise to me.  References?

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 29 Oct 2019 10:51:45 +0100 (CET)

Hi,

> > I'll check with my co-author and get back.

I have now filed an errata for this issue.

However, I remember that we had a discussion on whether we should
accept erratas on YANG modules or not.  The YANG module exist in
various places outside of the RFC, such as the IANA site, and it won't
be corrected there.

> 	2) `mandatory true` should be `mandatory false` ?

I don't understand 2), can you elaborate?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 29 Oct 2019 10:53:49 +0100 (CET)

Randy Presuhn <[email-masked]> wrote:
> ....

I don't have any references at hand, so let me re-phrase:

  nodes.

(where "optional" means optional to set, not optional to implement)

/martin

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Tue, 29 Oct 2019 10:08:40 +0000

> (where "optional" means optional to set, not optional to implement)

The protocol handles non-existing values just fine. However, some
implementations did not handle non-existing values in the protocol
properly. MIB module authors sometimes use special values to indicate
the absence of a value in order to please those implementations.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 29 Oct 2019 15:35:19 +0000

Hi Martin,

> I have now filed an errata for this issue.

Ack.

> various places outside of the RFC, such as the IANA site, and it won't

Yes, two thoughts:
   - this erratum could marked as document update required.
   - we may want to publish a -biz soon

> I don't understand 2), can you elaborate?

First, let me demote (2) from a SHOULD to a MAY, since there is a workaround.

The thinking is that it may be common for deployments to use the same "cert-to-name" strategy everywhere (e.g., IDevID certificates), and hence there is no need to specify a "fingerprint" in order to lookup what strategy to use.  For these cases, it would be better to not specify a fingerprint at all.   If this remains "mandatory true", the best fallback would be to specify the fingerprint for the *root* CA certs spanning the end-entity certs connecting to that endpoint.

New issue.  Why isn't "list cert-to-name" order-by user as opposed to:
            
          "The id specifies the order in which the entries in the
           cert-to-name list are searched.  Entries with lower
           numbers are searched first.";

I suspect that this is for SNMP compatibility, but then your earlier response on this thread said regarding "mandatory true" and empty fingerprint values suggested that more appropriate YANG-isms should be used, in general.  "ordered-by user" vs "ordered by id" seems like such a case.

Kent // contributor

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Tue, 29 Oct 2019 15:48:45 +0000

>    - we may want to publish a -biz soon

I fail to see the argument. Standards-track RFCs typically lead to
some form of code somewhere so errata may always affect
implementations and I do not see why YANG is different just because
definitions are in a formal notation. Here we resolve a contradiction
contained in text of description clauses. If you implement this and
run into this contradiction, you likely check the RFC whether there
is already an errata.

/js

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 29 Oct 2019 09:24:50 -0700

Hi -

>> (where "optional" means optional to set, not optional to implement)

No, for set operations DEFVAL in SMIv2 governs "missing" objects.
(RFC 1442 7.9 or any of its successors.)

The decision to define sentinel values is entirely up to the MIB 
designer.  Zero-length
string is a possible choice only for stuff built with OCTET STRING as 
the underlying
type.  But it's still a value, and in no way makes something "optional."

*Any* object/instance might appear to be "missing" for retrieval due to 
the operation of
VACM or its proprietary predecessors.  It's been that way since, like, 
forever.
See for example RFC 1157 section 4.1.2 to get an idea how ancient this is.

Randy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 29 Oct 2019 21:13:56 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> The thinking is that it may be common for deployments to use the same
> "cert-to-name" strategy everywhere (e.g., IDevID certificates), and
> hence there is no need to specify a "fingerprint" in order to lookup
> what strategy to use.  For these cases, it would be better to not
> specify a fingerprint at all.  If this remains "mandatory true", the
> best fallback would be to specify the fingerprint for the *root* CA
> certs spanning the end-entity certs connecting to that endpoint.

Are we still talking about the usage of cert-to-name in
ietf-netconf-server?  If so we have (as one example):

  +--rw netconf-server
     +--rw listen! {ssh-listen or tls-listen}?
        ...
        +--rw endpoint* [name]
           ...
           +--rw (transport)
              ...
              +--:(tls) {tls-listen}?
                 +--rw tls
                    ...
                    +--rw netconf-server-parameters
                       +--rw client-identification
                          +--rw cert-maps
                             +--rw cert-to-name* [id]
                                +--rw id           uint32
                                +--rw fingerprint  x509c2n:tls-fingerprint
                                +--rw map-type     identityref
                                +--rw name         string

[we can discuss if this is the best structure, but that's another
thread]

What would a "cert-to-name" entry mean if the fingerprint isn't present?

> I suspect that this is for SNMP compatibility, but then your earlier
> response on this thread said regarding "mandatory true" and empty
> fingerprint values suggested that more appropriate YANG-isms should be
> used, in general.  "ordered-by user" vs "ordered by id" seems like
> such a case.

Yes I agree.  I don't recall but I also suspect the motivation was
simple mapping to the MIB.  (mapping a zero-length string to/from an
optional leaf is straightforward).

/martin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 30 Oct 2019 00:25:06 +0000

> ietf-netconf-server?  

...and ietf-restconf-server, yes.

> If so we have (as one example):
> 
>  +--rw netconf-server

Your snippet excludes "tis-server-perameters".   Here is a more complete view:

  +--rw restconf-server
     +--rw listen! {http-listen or https-listen}?
        +--rw endpoint* [name]
           +--rw name           string
           +--rw (transport)
              +--:(http)
              |  +--rw http
              |     ...
              +--:(https)
                 +--rw https
                    +--rw tcp-server-parameters
                    |  ...
                    +--rw tls-server-parameters
                    |  +--rw server-identity
                    |  |  ...
                    |  +--rw client-authentication!
                    |  |  +--rw (required-or-optional)
                    |  |  |  ...
                    |  |  +--rw (local-or-external)
                    |  |     +--:(local)
                    |  |     |  +--rw ca-certs!  
                    |  |     |  |  ...
                    |  |     |  +--rw client-certs!
                    |  |     |     ...
                    |  |     +--:(external)
                    |  |        ...
                    |  +--rw hello-params
                    |  |  ...
                    +--rw http-server-parameters
                    |  +--rw server-name?             string
                    |  +--rw protocol-versions
                    |  |  +--rw protocol-version*   enumeration
                    |  +--rw client-authentication!
                    |     ...
                    +--rw restconf-server-parameters
                       +--rw client-identification
                          +--rw cert-maps
                             +--rw cert-to-name* [id]
                                +--rw id             uint32
                                +--rw fingerprint
                                |       x509c2n:tls-fingerprint
                                +--rw map-type       identityref
                                +--rw name           string

The "tls-server-parameters" container defines the certificates used to authenticate the client's cert.   In many deployments, regardless how the client cert is authenticated, the "client-identification" section only needs to explain extract the "name" from the cert, a fingerprint isn't needed to identify either the client's end-entity or some intermediate cert.

> 
>> New issue.  Why isn't "list cert-to-name" order-by user given:
>> 

Is it too late to fix?   No reason to hold onto SNMP compatibility, given SNMP is now deprecated...

Kent // contributor

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 30 Oct 2019 06:57:39 +0000

> Is it too late to fix?   No reason to hold onto SNMP compatibility, given SNMP is now deprecated...

I think SNMP is still STD 62.

Doing merely cosmetic changes that break backwards compatibility is
something the IETF should consider very carefully. Creating variants
of existing definitions has costs - so there should be a strong
benefit justifying the costs of introducing variants.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Oct 2019 13:28:39 +0100 (CET)

Kent Watsen <[email-masked]> wrote:
> The "tls-server-parameters" container defines the certificates used to
> authenticate the client's cert.  In many deployments, regardless how
> the client cert is authenticated, the "client-identification" section
> only needs to explain extract the "name" from the cert, a fingerprint
> isn't needed to identify either the client's end-entity or some
> intermediate cert.

Ok.  To me this sounds like you need a more complex^wsophisticated
client identification mechansim than what a plain cert-to-name gives
you.  I don't think there is anything wrong with the current
cert-to-name grouping.  So let's continue this discussion in the
netconf ML, where this model is being developed.

/martin

---

From: Kent Watsen <[email-masked]>
Date: Wed, 30 Oct 2019 16:56:14 +0000

> you.

I wouldn't characterize it as such.   It's not complex.  It's a simple thing,
optimizing the trivial case for improved usability.  I'm unfamiliar with how
all other models might use cert-to-name, though one use is here [1], but
I imagine all uses that are associated with a TLS connection also wishing
for this optimization (this includes [1]).  For models that are not associated
with a TLS connection, the current cert-to-name 'mandatory true' is just
fine.

[1] https://tools.ietf.org/html/rfc7407#section-2.12 <https://tools.ietf.org/html/rfc7407#section-2.12>

> I don't think there is anything wrong with the current
> cert-to-name grouping.  

See above.

> So let's continue this discussion in the

I'll fork this part of the conversation there.

Kent // contributor