logo_kerberos.gif

Difference between revisions of "Projects/Trust KDC-local name resolution"

From K5Wiki
Jump to: navigation, search
Line 1: Line 1:
 
{{project-early}}
 
{{project-early}}
{{project-target|1.12}}
+
{{project-target|1.13}}
 
This project will alter the KDC so that local name service on the KDC host is trusted to produce information for service principal aliases and realm referrals. As a result, administrators will not need to explicitly construct principal aliases for host-based service principal names. The KDC is assumed to have the ability to look up realm-specific hostnames in a trusted resource, such as an <code>/etc/hosts</code> file, a local master nameserver, or a DNSSEC name service.
 
This project will alter the KDC so that local name service on the KDC host is trusted to produce information for service principal aliases and realm referrals. As a result, administrators will not need to explicitly construct principal aliases for host-based service principal names. The KDC is assumed to have the ability to look up realm-specific hostnames in a trusted resource, such as an <code>/etc/hosts</code> file, a local master nameserver, or a DNSSEC name service.
   

Revision as of 14:13, 11 October 2013

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.


This project is targeted at release 1.13.

This project will alter the KDC so that local name service on the KDC host is trusted to produce information for service principal aliases and realm referrals. As a result, administrators will not need to explicitly construct principal aliases for host-based service principal names. The KDC is assumed to have the ability to look up realm-specific hostnames in a trusted resource, such as an /etc/hosts file, a local master nameserver, or a DNSSEC name service.

Users often like to type aliases or unqualified names for hosts they are attempting to access. In the past, when the krb5 client library constructs the principal name for a host-based service, it does a reverse lookup on the IP address of the desired hostname. This is vulnerable to spoofing attacks and can cause problems in deployments where the administrators do not fully control the reverse lookup information for the IP addresses of their hosts. The forward lookup is also vulnerable but less of an operational problem.

Open questions:

  • What existing OS capabilities do we use? things like gethostbyname() and getaddrinfo()?
  • Do we replicate some of the domain search logic that exists in BIND?
  • If not, how do we know whether to trust a forward lookup that uses the domain search list?