Subject: [netmod] RFC7952 annotation to identify leaf encryption/hashing format

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 22 May 2017 17:16:36 +0000

Hi all,

Does anyone see any reasons why RFC7952 annotations couldn't/shouldn't be used to identify the encryption/hashing format of an encrypted/hashed leaf ?

There are a number of approaches out there for encrypted/hashed leafs (e.g. RFC7317 crypt-hash which encodes the hash function by prepending $x$ to the password, using multiple leafs for the value/algorithm, etc).

These are leafs that can be typically written in cleartext or encrypted/hashed format, but return only an encrypted/hashed format when retrieved from a device.

I think RFC7952 annotation could also be used as an approach to this problem.

Annotation definition:

     md:annotation hash-format {
       type enumeration {
         enum md5l
         enum sha-256
         ...
       }
     }

An 'auth-key' leaf that is hashed:

    <auth-key hash-format="sha-256">
      QsdsEWfjKAowjjhQHHslJSHHll
    </auth-key>

Regards,
Jason

Note - I don't believe this statement in section 9 would point anyone away from using annotations for encryption/hashing information (since the encrypted leafs are data nodes):  "It is RECOMMENDED that security-sensitive or privacy-sensitive data be modeled as regular YANG data nodes rather than annotations."

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 22 May 2017 23:56:13 +0200

RFC 7952 says:

   4.  Annotations sent by a server should not break clients that don't
       support them.

If the client is expected to understand which hash function has been
used to generate a hash value, then I think the hash function should
be communicated as proper YANG data and not as metadata.

/js

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 22 May 2017 16:22:53 -0700

> be communicated as proper YANG data and not as metadata.
Agreed.

Also, the annotation extension cannot constrain the usage of the XML
attribute.
It is supposed to apply to any data node (clearly hash-function does not
apply to
every data node.) Since it is data-node specific, it is not metadata; just
more data.

> /js

Andy

> > Does anyone see any reasons why RFC7952 annotations couldn't/shouldn't
> be used to identify the encryption/hashing format of an encrypted/hashed
> leaf ?
> >
> > There are a number of approaches out there for encrypted/hashed leafs
> (e.g. RFC7317 crypt-hash which encodes the hash function by prepending $x$
> to the password, using multiple leafs for the value/algorithm, etc).
> >
> > These are leafs that can be typically written in cleartext or
> encrypted/hashed format, but return only an encrypted/hashed format when
> retrieved from a device.
> >
> > Note - I don't believe this statement in section 9 would point anyone
> away from using annotations for encryption/hashing information (since the
> encrypted leafs are data nodes):  "It is RECOMMENDED that
> security-sensitive or privacy-sensitive data be modeled as regular YANG
> data nodes rather than annotations."
> >
> >
> >
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 24 May 2017 15:04:49 +0200

> every data node.) Since it is data-node specific, it is not metadata; just

If hashing/encryption is only intended for specific nodes and envisioned
for them in advance, then by all means YANG leaves should be used for
specifying the algorithms and other data.

On the other hand, I believe 7952 annotations might be used provided
that encryption/hashing is applied only to string or binary leaf values
so that the data model constraints are not violated, just the client
that doesn't support RFC 7952 might not be able to decode the data. This is
no different from using NACM: a client that doesn't understand NACM has
to live with the fact that some data may be missing. Here the data would
be present but unusable.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67