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.
> 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).
A requirements draft might be the right starting point, and "aaa"
is much more of a topic for "kitten" than for DANE or DNSOP.
--
Viktor.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
