Hi Viktor, Thanks a lot for your response and sorry for delaying my response.
> On Thu, Dec 10, 2015 at 09:56:26PM +0100, Hosnieh Rafiee wrote: > > > > 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. > A requirements draft might be the right starting point, and "aaa" > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
