[dane] Any comment? Bounding of authentication and authorization

[Hosnieh Rafiee <[e-mail]>]

Anybody had a chance to take a look on this? Any comment? 


> -----Original Message-----
> From: DNSOP [mailto:[e-mail]] On Behalf Of Hosnieh Rafiee
> Sent: 29 November, 2015 11:52 PM
> To: [e-mail]
> Cc: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop