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

[Ladislav Lhotka <[e-mail]>]

Andy Bierman <[e-mail]> writes:

> On Mon, May 22, 2017 at 2:56 PM, Juergen Schoenwaelder <
> [e-mail]> wrote:
>
>> 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.
>>
>>
> 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.

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

>
>
>
>> /js
>>
>
> Andy
>
>
>>
>> On Mon, May 22, 2017 at 05:16:36PM +0000, Sterne, Jason (Nokia -
>> CA/Ottawa) wrote:
>> > 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."
>> >
>> >
>> >
>>
>> > _______________________________________________
>> > netmod mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   [phone]         <http://www.jacobs-university.de/>
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

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