Subject: [DNSOP] new Resource record?

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 9 Dec 2015 21:25:18 +0100

Hi,

Since DNS is a very important service on the internet, for several security
processes, it can be used as a powerful system. So far, some resource
records were proposed for certificates, keys and other values.

I would like to suggest the following format (this is the rough version and
it is not exact but only giving you an idea that what is the purpose) for a
new resource record to store the reference information of bounding of
authentication and authorization where authentication can be based on public
keys or certificates.
This means each reference no represents an actual policy template in other
security system or other services. This means if a certificates bound to
more than one references, then more than one of this section is added to
RDATA section of the DNS query. This also should be updatable by the DDNS
protocol.
BTW, I skipped the header and other parts of RR and this part is only the
RDATA section.  

-----------------------
|flag| reference no   |
-----------------------
| some human readable |
|       text          |
-----------------------

The processes are also simple, when a node query the certificates, DNS
server also includes this RR if it exists on the DNS server so that when the
querier retrieves this information, it can query other services for the
given value to authorize the other host on the network. 

Is DNSOP a right place for that? I asked DANE and they said it Is not in
their charter. If not, please tell me where is the right place. If yes,
please tell me what do you think about that and whether or not you support
it to draft it.

Thank you,
Best,
Hosnieh

---

From: Jared Mauch <[email-masked]>
Date: Wed, 9 Dec 2015 15:29:51 -0500

> On Dec 9, 2015, at 3:25 PM, Hosnieh Rafiee <[email-masked]> wrote:
> 
> Hi,
> 

People have done things similar to this over the years.  I remember software
once distributed UNENCODED over sequenced DNS TXT records.

It seems something like TXT would be the best way to do this, eg:

dig txt 1.255.42.204.in-addr.arpa.

Nothing really stops you from putting a “Seq-01-Base64-Blob” out there.

You might be able to use HINFO for that as well since it’s designed for two
fields already.

- Jared

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 9 Dec 2015 22:00:05 +0100

Hi Jared,

Thanks a lot for your quick response.
> dig txt 1.255.42.204.in-addr.arpa.

I might not be aware of that but since you suggested the use of the existing TXT record, Do you think the following conditions for processing this TXT RRs are also supported: 
Assumption: the admin of the DNS server is different from the admin of different zones in the DNS server
1- If a user is the owner of the domain example.com, it must not be able to add a new txt RR with different reference value if and if this reference value is not already assigned to this domain on the DNS server  (prevention of a user to access unauthorized resources)
But this user should be able to add this reference txt RR with one of the already existing value to its subdomains.
2- if a user is the owner of only a sub domain such as xx.example.com then it cannot change this RR but it can again assign it to its sub-subdomain such as yy.xx.example.com

In other word, the owner of the DNS server can update this txt RR (reference number) but the domain owners (any zones) on this DNS server should not be able to change it but they can assign (update), the already existing assigned reference numbers to domains and subdomains inside their zones. Similar to this, the subdomain owner cannot change this assigned value but can assign 1 or all of these reference Numbers to its sub-subdomain. 
Just like a tree that each root node have the possibility to use what is available to it and assign it to its leaves and this can continue until the end of the tree..
This is a kind of delegation of access control to the child leaves.  

If this is already existence in the DNS server, I think I no longer need to suggest such RR or the process to handle such cases. But if this process is not existence, then perhaps it is an advantage to have it.

> Nothing really stops you from putting a “Seq-01-Base64-Blob” out there.

Right but just my concern is the process behind this that needs to be a kind of tree based authorization.

> You might be able to use HINFO for that as well since it’s designed for two

I will look at them.
Thanks,
Best,
Hosnieh

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 10 Dec 2015 09:46:43 +0100

On 9 Dec 2015, at 21:25, Hosnieh Rafiee wrote:

> I would like to suggest the following format (this is the rough version and it is not exact but only giving you an idea that what is the purpose) for a new resource record to store the reference information of bounding of authentication and authorization where authentication can be based on public keys or certificates.
> This means each reference no represents an actual policy template in other security system or other services. This means if a certificates bound to more than one references, then more than one of this section is added to RDATA section of the DNS query. This also should be updatable by the DDNS protocol.
> BTW, I skipped the header and other parts of RR and this part is only the RDATA section.
>
> -----------------------
> |flag| reference no   |
> -----------------------
> | some human readable |
> |       text          |
> -----------------------
>
> The processes are also simple, when a node query the certificates, DNS server also includes this RR if it exists on the DNS server so that when the querier retrieves this information, it can query other services for the given value to authorize the other host on the network.

A few things:

1. Do not use TXT RR. We have already too much use of TXT, and you should define a new RRType

2. There are multiple reasons why you should not use TXT record or even the structure of the TXT RR, most notably the length of the "some human readable text" portion. I suggest you have, just like in the URI RRType, the length of the "some human readable text" be set by the length of the RR as a whole minus the flag, reference no, header etc. That way the length can be longer than what you otherwise can (in a TXT for example). You also do not end up having trouble defining how to handle multiple strings in the RR, like you have if you try to stuff things into a TXT.

3. Think about (as you did in a later message) the owner as well as the RData. The right prefix might be key to the usage pattern.

   Patrik

---

From: Edward Lewis <[email-masked]>
Date: Thu, 10 Dec 2015 13:47:26 +0000

On Dec 9, 2015, at 3:25 PM, Hosnieh Rafiee <[email-masked]> wrote:
HR> I would like to suggest the following format (this is the rough version
HR> and it is not exact but only giving you an idea that what is the
HR> purpose) for a new resource record to store the reference information
HR> of bounding of authentication and authorization where authentication
HR> can be based on public keys or certificates.

First, read "Domain Name System (DNS) IANA Considerations", RFC 6895.
(http://tools.ietf.org/html/rfc6895) That lays out the process of getting
a new Resource Record assigned.

Second, from the quick description, I don't quite understand what you want
to solve.  Not complaining, but in preparing to ask for a new type, the
use case might need to be clearer.

HR> Is DNSOP a right place for that? I asked DANE and they said it
HR> is not in their charter.

I don't know what you asked the DANE WG.  But if it was to add a new DNS
RR type, they certainly would not be the best place.  DNSOP WG doesn't
make decisions on new types (see the RFC for that), but you might get
useful advice on this list.

HR> If not, please tell me where is the right place. If yes,please
HR> tell me what do you think about that and whether or not you
HR> support it to draft it.

I don't understand it.  But don't reuse TXT or HINFO or anything just
because it would seem convenient.  Consult the RFC for the process.

On 12/9/15, 15:29, "DNSOP on behalf of 'Jared Mauch'"
<[email-masked] on behalf of [email-masked]> wrote:

JM> You might be able to use HINFO for that as well since it’s
JM> designed for two fields already.

Jared,

You've just made the naughty list for 2015.

Santa

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 10 Dec 2015 21:47:59 +0100

Hi Patrik,

Thanks for your message and your suggestion.

> 1. Do not use TXT RR. We have already too much use of TXT, and you should

Ok , I think this is also Edward's opinion.

> 2. There are multiple reasons why you should not use TXT record or even
the
> structure of the TXT RR, most notably the length of the "some human
readable
> text" portion. I suggest you have, just like in the URI RRType, the length
of the
> "some human readable text" be set by the length of the RR as a whole minus
> the flag, reference no, header etc. That way the length can be longer than
> what you otherwise can (in a TXT for example). You also do not end up
having
> trouble defining how to handle multiple strings in the RR, like you have
if you
> try to stuff things into a TXT.

> 3. Think about (as you did in a later message) the owner as well as the
RData.
> The right prefix might be key to the usage pattern.

Right, sounds reasonable.

Thank you,
Best,
Hosnieh

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 10 Dec 2015 21:56:26 +0100

Hi Edward,
Thanks for your message.

> a new Resource Record assigned.

Ok

> use case might need to be clearer.

Authentication and authorization in multi-tenancy environment where it is based on certificates and TLS and not giving direct access to resource policy that belongs to the owner of infrastructure while at the same time giving flexibility to each tenant to delegate all or a part of its resources to third party.

> useful advice on this list.

I actually asked in the mailinglist whether their charter is open to having the bounding of authentication and authorization there since the purpose would be also use DANE. But what I heard (in private message exchanges) that they do not want to recharter to consider this.
If I misunderstood, then perhaps the chair of DANE can speak out and correct me.

> because it would seem convenient.  Consult the RFC for the process.

Ok you are the second person that you do not recommend to use TXT. I think also according to processes Ineed for DDNS, there need to be a bit more restriction. For quering I think it will address the needs but for processes during updating that , there need to be new processes defined which means it is better, as you and other suggested, to think about other RR.

I need to first take a look on the RFC you have submitted to see what I can do and how to introduce it. I think, I again bug the WG for more advise :)

 Thanks again,
Best,
Hosnieh

---

From: Jared Mauch <[email-masked]>
Date: Thu, 10 Dec 2015 16:09:09 -0500

> On Dec 10, 2015, at 8:47 AM, Edward Lewis <[email-masked]> wrote:
> 
> Jared,
> 

I know I’m permanently on that list since I was given coal as
a kid.

- Jared

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 11 Dec 2015 19:57:51 +0000

On Thu, Dec 10, 2015 at 09:56:26PM +0100, Hosnieh Rafiee wrote:

> Authentication and authorization in multi-tenancy environment where it is
> based on certificates and TLS and not giving direct access to resource
> policy that belongs to the owner of infrastructure while at the same time
> giving flexibility to each tenant to delegate all or a part of its resources
> to third party.

This is still much too vague.  Is the goal here to turn DNS into
something akin to "Active Directory"?  Perhaps a better design is
to use DNS primarily for cross-organizational key management (solving
the "introduction" problem), and to leave more fine-grained security
policy storage to dedicated services such as Kerberos, ...  There've
been mutterings of facilitating cross-realm Kerberos via DANE, thus
avoiding the need for manual pairwise shared keys.

> I actually asked in the mailinglist whether their charter is open to having
> the bounding of authentication and authorization there since the purpose
> would be also use DANE. But what I heard (in private message exchanges)
> that they do not want to recharter to consider this.

I was one of the off-list responders.  I still think the scope was
much too broad (not well defined), and that a more narrow definition
would likely suffice, probably just use DANE TLSA to secure the
transport, and do everything else at higher layers (above the DNS).

A requirements draft might be the right starting point, and "aaa"
is much more of a topic for "kitten" than for DANE or DNSOP.

-- 
	Viktor.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Fri, 18 Dec 2015 17:44:49 +0100

Hi Viktor,

Thanks a lot for your response and sorry for delaying my response. 

> > > Second, from the quick description, I don't quite understand what
> > > you want to solve.  Not complaining, but in preparing to ask for a
> > > new type, the use case might need to be clearer.
> >
> > Authentication and authorization in multi-tenancy environment where it
> > is based on certificates and TLS and not giving direct access to
> > resource policy that belongs to the owner of infrastructure while at
> > the same time giving flexibility to each tenant to delegate all or a
> > part of its resources to third party.
> 
> This is still much too vague.  Is the goal here to turn DNS into something
akin to
> "Active Directory"?  Perhaps a better design is to use DNS primarily for
cross-
> organizational key management (solving the "introduction" problem), and to
> leave more fine-grained security policy storage to dedicated services such
as
> Kerberos, ...  There've been mutterings of facilitating cross-realm
Kerberos via
> DANE, thus avoiding the need for manual pairwise shared keys.
> 

The purpose is to reduce dependency to other services such as Active
directory, etc. Since DNS is widely used in most infrastructure for
providing the mapping of name to ip address for many devices, it is
beneficial to re-use the same service for also authentication and
authorization. So, to abit clearer, we are talking about the system that
uses TLS based authentication, that is the certificates is also the identity
of the device. There is usually less problem with first trust in first
contact because usually there is agreement that during this agreement, this
trust can be established. So, there is not so much worry about that.
Therefore, automation for this is not the purpose but rather, mapping of
authentication and authorization is the focus. Since authentication can be
already achieved by DANE, we only need this mapping that can be also
achieved by the introduction of a small resource record. 

I looked at Kitten charter, it does not cover the aspects, we are looking
for and it covers something else which is out of scope of the work we want
to do.  

> > I actually asked in the mailinglist whether their charter is open to
> > having the bounding of authentication and authorization there since
> > the purpose would be also use DANE. But what I heard (in private
> > message exchanges) that they do not want to recharter to consider this.
> 
> I was one of the off-list responders.  I still think the scope was much
too broad
> (not well defined), and that a more narrow definition would likely
suffice,
> probably just use DANE TLSA to secure the transport, and do everything
else
> at higher layers (above the DNS).
>
I looked at Kitten charter, it does not cover the aspects, we are looking
for and it covers something else which is out of scope of the work we want
to do.  
So, if DNSOP is not a place to introduce a new resource record, then where
is the place? That is the question.

> is much more of a topic for "kitten" than for DANE or DNSOP.

Ok, I will draft it as a requirement and submit it. thanks 

Best,
Hosnieh