Anybody had a chance to take a look on this? Any comment?
> -----Original Message----- > From: DNSOP [mailto:[email protected]] On Behalf Of Hosnieh Rafiee > Sent: 29 November, 2015 11:52 PM > To: [email protected] > Cc: [email protected] > Subject: [DNSOP] a new draft?? Bounding of authentication and > authorization > > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
