Projects/NAPTR - Revision history

TomYu: add early project template; bump heading levels

2015-03-17T20:20:37Z

add early project template; bump heading levels

Npmccallum: /* Definitions */

2015-02-24T15:32:09Z

‎Definitions

Npmccallum: /* Definitions */

2015-02-24T15:31:41Z

‎Definitions

Npmccallum: /* Definitions */

2015-02-24T01:38:50Z

‎Definitions

Npmccallum: /* The URI Record */

2015-02-24T01:29:18Z

‎The URI Record

Npmccallum at 01:28, 24 February 2015

2015-02-24T01:28:49Z

Npmccallum at 01:22, 24 February 2015

2015-02-24T01:22:32Z

Npmccallum: New page: = 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...

2015-02-23T23:33:04Z

New page: = 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...

New page

= 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 [https://tools.ietf.org/html/draft-faltstrom-uri-11 URI Record type] and its relation to [https://www.ietf.org/rfc/rfc2915.txt 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:

<code><nowiki>
_ms_kkdcp IN URI 10 1 "https://kdc.example.com/kdc"
</nowiki></code>

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, which in this case will be the principal (including the realm), and a domain (which is only the realm).

(More to come...)

@@ Line 1: / Line 1: @@
 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 [https://tools.ietf.org/html/draft-faltstrom-uri-11 URI Record type] and its relation to [https://www.ietf.org/rfc/rfc2915.txt NAPTR records], I think NAPTR provides improvements in other areas as well.
-= The URI Record =
+== The URI Record ==
 This is basically an equivalent for SRV records but for URIs. An example might be:
@@ Line 13: / Line 15: @@
 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 ==
 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).
@@ Line 48: / Line 50: @@
 In the above case, a second NAPTR lookup would be perormed, this time on foo.com. The realm itself, however, would remain unchanged.
-= Definitions =
+== Definitions ==
 Most of the NAPTR and URI protocols are already well defined. What kerberos would need to standardize is:

← Older revision		Revision as of 15:32, 24 February 2015
Line 65:		Line 65:
	# In the case of the U flag, MSKKDCP. Otherwise, UDP or TCP (at the client's discretion).		# 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 ~~thought~~.	+	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.

@@ Line 52: / Line 52: @@
 Most of the NAPTR and URI protocols are already well defined. What kerberos would need to standardize is:
 # Service name
 # Protocol names
@@ Line 57: / Line 58: @@
 # The behavior of the "P" flag (optional)
-For the first three, I propose:
+For the first four, I propose:
 # KRB5
 # UDP, TCP and MSKKDCP

@@ Line 61: / Line 61: @@
 # KRB5
 # UDP, TCP and MSKKDCP
-# UDP or TCP at the client's discretion
+# 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 thought.

@@ Line 19: / Line 19: @@
 First, we query NAPTR for the domain (a.k.a. realm). Here is what a response might look like:
-<code><nowiki>
+<code><pre>
 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.
-</nowiki></code>
+</pre></code>
@@ Line 30: / Line 30: @@
 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:
-<code><nowiki>
+<code><pre>
 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.
-</nowiki></code>
+</pre></code>
 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:
-<code><nowiki>
+<code><pre>
 example.com IN NAPTR 100 20 "A" "KRB5" "" kdc.example.com.
-</nowiki></code>
+</pre></code>
 On last thing should be mentioned that is not kerberos specific: NAPTR allows redirection. This is usually done by specifying no flag:
-<code><nowiki>
+<code><pre>
 example.com IN NAPTR 100 20 "" "KRB5" "" foo.com.
-</nowiki></code>
+</pre></code>
 In the above case, a second NAPTR lookup would be perormed, this time on foo.com. The realm itself, however, would remain unchanged.

← Older revision		Revision as of 01:22, 24 February 2015
Line 15:		Line 15:
	= The NAPTR Record =		= The NAPTR Record =

−	The NAPTR record type can alleviate this interaction problem. NAPTR records are evaluated with a string, ~~which~~ in ~~this~~ ~~case~~ ~~will~~ be ~~the~~ ~~principal~~ ~~(including~~ the realm~~), and a domain~~ (~~which~~ is ~~only~~ ~~the realm~~).	+	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).

−	(More to come...)
		+	First, we query NAPTR for the domain (a.k.a. realm). Here is what a response might look like:
		+
		+	<code><nowiki>
		+	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.
		+	</nowiki></code>
		+
		+
		+	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:
		+
		+	<code><nowiki>
		+	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.
		+	</nowiki></code>
		+
		+	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:
		+	<code><nowiki>
		+	example.com IN NAPTR 100 20 "A" "KRB5" "" kdc.example.com.
		+	</nowiki></code>
		+
		+	On last thing should be mentioned that is not kerberos specific: NAPTR allows redirection. This is usually done by specifying no flag:
		+	<code><nowiki>
		+	example.com IN NAPTR 100 20 "" "KRB5" "" foo.com.
		+	</nowiki></code>
		+
		+	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:
		+
		+	# Service name
		+	# Protocol names
		+	# The behavior of a service without a protocol
		+	# The behavior of the "P" flag (optional)
		+
		+	For the first three, I propose:
		+
		+	# KRB5
		+	# UDP, TCP and MSKKDCP
		+	# 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 thought.