Subject: RE: simple secure update and signatory strength

From: "Stuart Kwan (Exchange)" <[email-masked]>
Date: Wed, 24 Nov 1999 11:55:40 -0800

I think a general name-based access control method would be better.  The
entries I can modify should be based on who I am, not on the strength of the
key I am holding.  I believe we will inevitably create such an access
control mechanism.

-----Original Message-----
From: Brian Wellington [mailto:[email-masked]]
Sent: Tuesday, November 23, 1999 12:55 PM
To: [email-masked]
Subject: simple secure update and signatory strength

Hi.  I mentioned at the DNSIND meeting in DC that I'd be opening a
discussion about the merits of the signatory strength field with respect
to simple secure update.  Here goes...

Basically, in the current draft, the 4 bits in the KEY record that
represent signatory strength are interpreted as a 4 bit unsigned integer.
When an update is performed that modifies existing RRsets in a secure
zone, the signatory value of the message must be greater than or equal to
that of the data for the update to occur.

As an example, assume we have a host.example TXT set, signed by a key with
signatory strength 10.  An update signed by a message key with strength
>=10 may update the set (assuming all other checks pass), while a key with
strength <10 may not update the set.

When a set is added/modified, it is signed by the strongest zone key
weaker than or equal to the message signing key.  In the above example, if
the zone keys were of strength 5, 10, and 15, and the message was signed
by a key of strength 12, the zone key of strength 10 would be used.

This allows, for example, a DHCP server to have a key with low strength
but access to all names in a zone, and individuals to have keys with
higher strength and restricted to specific names.  So, if there were no
records for foo.example, the DHCP server could add one, but if I used my
key to add records, the DHCP server could not change my set.  It could
change its own set, though.

The question is, is this useful?  To be of any use, it requires multiple
online zone keys, and the related problem where a signature by any of a
set of zone keys is sufficient to validate a set.  This also adds
complexity to the access control process and extra work for the
administrator when determining whether or not to sign keys if their
signatory strength is too high.

The other argument is that all of this can be done with name-based access
control (granting privileges based on identity), so strength is not
needed.  The DHCP example above could be done by granting permission to
'add' but not 'modify' or 'delete' based on identity, but this might be
more complicated.

I think the signatory field should be left as in ssu-01, but others
disagree and say that the field should remain undefined.

Brian

---

From: Brian Wellington <[email-masked]>
Date: Wed, 24 Nov 1999 15:01:08 -0500 (EST)

> key I am holding.  I believe we will inevitably create such an access

Key strength would be used as an adjunct to name-based access control, not
a replacement.  The advantage would be a case where multiple identities
can update a signle DNS name, but one has more authority than the other.
In most cases, name-based is enough.

It is good to know that similar access control will be implemented in a
non-BIND server :)

Brian