Projects/NAPTR

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.

Background

The original driver of this proposal is the desire to enable automatic detection of MS-KKDCP compliant proxies. However, after researching the new proposed standard for the URI Record type and its relation to NAPTR records, I think NAPTR provides improvements in other areas as well.

The URI Record

This is basically an equivalent for SRV records but for URIs. An example might be:

_mskkdcp IN URI 10 1 "https://kdc.example.com/kdc"

A URI record on its own might suffice. However, getting the interaction right between this and the two SRV records may be challenging. Notice that the URI record type provides priority and weight fields. While this gives us an indication of how to prioritize traffic across multiple proxy URIs, it does not explain how to do the same between MS-KKDCP and TCP/UDP.

The NAPTR Record

The NAPTR record type can alleviate this interaction problem. NAPTR records are evaluated with a string and a domain. For kerberos, both of these are the realm (in this case, example.com).

First, we query NAPTR for the domain (a.k.a. realm). Here is what a response might look like:

example.com IN NAPTR 100 10 "D" "KRB5+MSKKDCP" "" _mskkdcp.example.com.
example.com IN NAPTR 100 20 "S" "KRB5+UDP" "" _kerberos._udp.example.com.
example.com IN NAPTR 100 20 "S" "KRB5+TCP" "" _kerberos._tcp.example.com.

In this example, the client is instructed to try the MS-KKDCP proxy first. If this fails, it can fall back to TCP or UDP. These lookups will be performed in two stages. First, the NAPTR record will be fetched. From this the method is chosen. Second, the chosen method is queried. For MS-KKDCP, a URI record is queried via the "D" flag. For the others, an SRV record is queried from the "S" flag.

For DNS servers which do not support the URI records, NAPTRs can be used to generate URIs themselves via the "U" flag. In this case, no secondary lookup is performed. Secondary queries can be avoided for TCP/UDP as well using the "A" flag. Here are examples of both:

example.com IN NAPTR 100 10 "U" "KRB5+MSKKDCP" "!^.*$!https://kdc.example.com/kdc!" .
example.com IN NAPTR 100 20 "A" "KRB5+UDP" "" kdc.example.com.
example.com IN NAPTR 100 20 "A" "KRB5+TCP" "" kdc.example.com.

If the administrator does not wish to control TCP or UDP, the protocol portion of the field can be ignored. For instance, this case supports either UDP or TCP:

example.com IN NAPTR 100 20 "A" "KRB5" "" kdc.example.com.

On last thing should be mentioned that is not kerberos specific: NAPTR allows redirection. This is usually done by specifying no flag:

example.com IN NAPTR 100 20 "" "KRB5" "" foo.com.

In the above case, a second NAPTR lookup would be perormed, this time on foo.com. The realm itself, however, would remain unchanged.

Definitions

Most of the NAPTR and URI protocols are already well defined. What kerberos would need to standardize is:

1. URI record prefix name
2. Service name
3. Protocol names
4. The behavior of a service without a protocol
5. The behavior of the "P" flag (optional)

For the first four, I propose:

1. _mskkdcp
2. KRB5
3. UDP, TCP and MSKKDCP
4. In the case of the U flag, MSKKDCP. Otherwise, UDP or TCP (at the client's discretion).

The "P" flag is essentially a standardized way to add protocol specific behavior given the evaluation of the regular expression. One possible thought is the use of this flag for realm moves. However, I have not thought through the ramifications of this.