*DNSSEC is protecting evermore of the Internet, and DANE expands it with facilities for in-promptu certificate validation. This combination opens new windows of opportunity for initial trust across operational realms.
The role of DNSSEC and DANE
Thanks to DNSSEC, it is possible to trace the validity of DNS data all the way to the DNS root, where a "widely known" key is used to sign the root DNS records that define the Internet. Anyone who uses a validating resolver can be certain that the DNS content for DNSSEC-signed sites is unmodified by rogue intermediates between them and the authoritative DNS server.
DANE exploits the newly found reliability of DNS data by storing in it certificates, or hashes of certificates. Where a certificate is a long-lasting statement of trust in an identity by a supposedly trustworthy third party, the addition of DANE is short-lived assurance of that same information, in a way controlled by the domain owner.
DANE for Cross-Realm Kerberos
Kerberos is a single-signon protocol that is widely used for internal authentication and encryption of network connections. It is old, but far from expired -- it is actively developed and widely deployed thanks to various infrastructural products centered around it -- Windows for Workgroups and Active Directory, Samba4, and FreeIPA are a few well-known examples.
The point where Kerberos is barely usable, is for Realm Crossover which is only possible with manual configuration by administrators. That is a sad fact, because once it is configured, it affects the entire internal network. Ideally, trust (in identities) could be established automatically.
This is where the DANE idea enters the game. The Kerberos protocol can already use X.509 certificates of a particular format to pre-authenticate to a Key Distribution Center; the KDC uses another X.509 certificate to establish its own server rights. There is no reason why one KDC could not contact another KDC, using a server certificate on both ends, to pre-authenticate and then obtain a fresh, temporary exchange key for the use of the second realm's services by the first realm's clients. To this end, proof of certificate validity could be confirmed through DNSSEC and DANE.
The assignment handed out here has two parts:
Check out the most recent stable MIT krb5, and modify the KDC code to support this scheme, both as a requesting and offering server.
Setup two KDCs, including DNSSEC/DANE, and demonstrate that the clients in one can access the services in the other (by fetching a
krbtgtticket-granting ticket). Demonstrate variations with unidirectional and bidirectional trust.
Report which security precautions are required to make this a safe success; this may be investigated in interaction with OpenFortress cryptographer and network expert.