[DNSOP] a new draft?? Bounding of authentication and authorization

["Hosnieh Rafiee" <[e-mail]>]

Dear All,

Before writing a draft (since I have had some unused drafts so far and ...
do not want to repeat the same mistake...), I would like to know the opinion
of WG on the overview of an idea for the extension of DANE  so that it can
be used for other use cases beyond Email and web, especially for
certificates based authentication (known as TLS based authentication) of
single devices in the network where we have DANE as a complete option in
place of PKI model and  the first A of AAA model.  In other word, the
extension focuses on not only giving the TLSA record back to the verifier
node but also the references of policy templates in resource policy storage.


Let me give you an example to be clearer ( I did not use the real example so
that it can be simpler to avoid the use of network related concept)
In Alice's enterprise, instead of AAA method, we assume that it is TLS based
authentication where authentication is based on the devices' certificates
and not the username and password. Therefore, DANE is in use as a way to
authenticate the Alice's laptop.  Alice need to access business server C and
B in her enterprise network after her laptop is being authenticated. For
authentication, Alice can herself generates a public/private key and
self-sign it. then it goes to the administrator of her enterprise network
called Bob to generate the TLSA record of her certificate and store it in
the DNS server so that later on business server C can verify Alice by query
the DNS server. Further, Bob also creates two new templates in resource
policy server and call them template AliceB and AliceC. Then in AliceB it
includes the authorization access to business server B and in AliceC it
defines Business server C. 

 To provide the binding of the Alice template with the authentication
information (certificates), Bob stores the template reference number of
Alice policy in a new resource record so called Parent policy Indices (PP
RR) on DNS server (This is the extension to DNS  to bound the authentication
and authorization).
Now, Alice tries to access business server C, the business server C asks the
certificates of Alice to establish a secure TLS channel. Alice's laptop
submits its certificates to business server C. Business server C needs to
verify this certificates, it queries the DNS server and asks for TLSA record
of Alice. DNS server checks Alice's laptop FQDN that includes in the query
of Business server C and retrieves Alice's laptop TLSA record. Further it
needs to retrieve the authorization information of Alice's laptop. 

The extension is that business server C also retrieves the reference numbers
that Bob stored it before in PP RR from DNS server along with TLSA record.
Then it can query the resource policy storage based on this reference number
that is the reference to the Alice template in resource policy and retrieves
the ALiCE's authorization information to make sure Alice is authorized to
use business server C. 

With this simple resource record, we added this bounding of authentication
and authorization. There might be some questions here such as:

1- Why not to store the whole authorization information on DNS server
instead of only storing the reference number
Answer: because at the moment in most network infrastructure, there are
already resource policy servers that stored the authorization information
and it is so costly to restore them all again in a new place otherwise there
is easy way of conversion.
Further, since DNS is usually publicly available to its local network or
global network, therefore, for security reason, not all nodes should be able
to know the content of the authorization information. It might leak some
critical information about the infrastructure and resources in the network
which might be both security and privacy issue. This is why, only reference
number and a small readable human text is enough for that.


2- Why not to store the TLSA record also in the resource policy so that the
business server C (as in my example) query the resource policy based on the
TLSA record.
By doing that, we limit the DANE use case and it can no longer be used for
some other use cases that we have in our mind for multi-tenancy where each
tenants can create subdomain on its own zone and re-assign these policies to
its sub-domain.
This is because a resource policy usually cannot be shared with the tenant
but DNS power allows a tenant to only access its own zone and update its own
resources. Therefore, this tenant can also create a sub domain on its own
zone and assign a part of its resources to third parties. In my example,
Alice can allow  David, her employee to access business server B but not
business server C by updating DNS server with the TLSA record of David's
laptop's certificate and in PP RR adding the template of business server B
(AliceB).  Therefore, Alice, without the need to ask Bob again, could
authorize someone else to only access a part of its authorized resources in
the network.

The concept can be to some extend similar to OAuth, but the difference is
that we want also to reduce CapEx in the network by eliminating the use of
PKI infrastructure and any other extra servers or services and the idea is
to use the existing resources that is supported by almost all networks for
both authentication and authorization purposes. 

As I said the use case is for network infrastructure but it might have
several other use cases that might come to your mind according to my simple
example. It would be good to hear some other use cases and ideas. 

Therefore, the proposed extension is this PP record and the processes of
this new resource record so that, TLSA and PP are able to be updated via the
DDNS but only by authorized owner, further, PP RR is also given to the
verifier node when a node query the TLSA record in case for instance, it
sets a flag. 

I would love to hear your opinion about this and if you think this  worth to
write it as a draft , I would appreciate any volunteers for that. 

Thank you,
Best,
Hosnieh