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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
