Subject: [kitten] Kerberos Service Discovery using DNS

From: Nathaniel McCallum <[email-masked]>
Date: Thu, 05 Mar 2015 12:57:51 -0500

I have uploaded a new draft: 
http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/

If you'd like to discuss it, reply to this message. :)

Nathaniel

---

From: Greg Hudson <[email-masked]>
Date: Fri, 06 Mar 2015 16:43:25 -0500

> http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/

I'm on board with this in general.  Some specific issues to be hashed out:

1. URL formats for basic RFC 4120 over UDP/TCP

The draft uses udp://hostname[:port] and tcp://hostname[:port] for
these.  The IANA registry notes some application-specific precedent for
the use of a "udp" scheme but there is no formal spec for it, and there
is no registration for "tcp" at all.  Obviously these URI schemes are
very context-dependent; a generic application such as a web browser
would have no idea what to do with a TCP or UDP URL.  On the other hand,
we are also proposing a very context-specific use of HTTP for MS-KKDCP,
and there is a ton of precedent for that (basically any kind of RPC over
HTTP).

2. UDP/TCP preference

Some implementation guidance may be necessary on this.  Implementations
are currently used to having their own preference of UDP versus TCP,
perhaps based on the packet size.

The current draft does allow the URI records to express no preference of
UDP versus TCP; one can simply give them the same priority and don't use
weights.  But if the URI records express a preference, should a client
always honor that preference, or can it ignore it--say, if the packet is
large?

3. Precedence of URI versus SRV

Discussion elsewhere suggested that the URI records, if present, should
have precedence over SRV records; if a client finds URI records, it
shouldn't do SRV lookups.  The draft should probably say that explicitly.

4. Security considerations

MS-KKDCP can offer security benefits for Kerberos traffic because it
uses TLS.  These added protections are mostly lost if unsecured URI
records are used to discover the proxy URL.  This is not a deal-breaker
as there are other reasons to use a proxy, but we should explicitly
state this in the security considerations.

---

From: Nathaniel McCallum <[email-masked]>
Date: Fri, 06 Mar 2015 16:58:16 -0500

On Fri, 2015-03-06 at 16:43 -0500, Greg Hudson wrote:
> these.  The IANA registry notes some application-specific precedent 
> for the use of a "udp" scheme but there is no formal spec for it, 
> and there is no registration for "tcp" at all.  Obviously these URI 
> schemes are very context-dependent; a generic application such as a 
> web browser would have no idea what to do with a TCP or UDP URL.  On 
> the other hand, we are also proposing a very context-specific use of 
> HTTP for MS-KKDCP, and there is a ton of precedent for that 
> (basically any kind of RPC over HTTP).

I think this is a very fair assessment of the situation. Assuming 
context-dependent usage permits us a certain succinctness. If needed, a
prefix for all of these could remove this necessary context. However, 
we would likely need a different prefix for the KDC and kpasswd cases.

> 2. UDP/TCP preference
> 
> Some implementation guidance may be necessary on this.  
> Implementations are currently used to having their own preference of 
> UDP versus TCP, perhaps based on the packet size.
> 
> The current draft does allow the URI records to express no 
> preference of UDP versus TCP; one can simply give them the same 
> priority and don't use weights.  But if the URI records express a 
> preference, should a client always honor that preference, or can it 
> ignore it--say, if the packet is large?

I would say that the client must never ignore the DNS preference. 
Large packets are not usually generated on the fly by clients but are 
either server responses to clients or are the result of server-
configured preauth mechs. This means that the server in question has 
been configured to cause these large packet sizes. Because of this, 
the DNS preferences should match the server's configuration. Anything 
other than this is a misconfiguration.

I'd be happy to add a statement to this effect in the draft.

> Discussion elsewhere suggested that the URI records, if present, 
> should have precedence over SRV records; if a client finds URI 
> records, it shouldn't do SRV lookups.  The draft should probably say 
> that explicitly.

I think this is somewhat implied by section 8. However, I can make an 
explicit statement to this effect.

> records are used to discover the proxy URL.  This is not a deal-
> breaker as there are other reasons to use a proxy, but we should 
> explicitly state this in the security considerations.

+1

---

From: Simo Sorce <[email-masked]>
Date: Fri, 06 Mar 2015 17:58:49 -0500

On Fri, 2015-03-06 at 16:43 -0500, Greg Hudson wrote:
> I'm on board with this in general. 

I like it too.

>  Some specific issues to be hashed out:
> 

I think the client SHOULD use the URI order in preference, but MAY
override it if it knows that the packet size will make it impossible to
use the URI preferred method. (Ie if the URI makes UDP preferred but the
client knows the size for the specific exchange is going to be too large
for UDP, it may decide to do straight TCP/MS-KKDCP instead).

+1

> state this in the security considerations.

True, but DNSSEC may help in this case, so it is not that weak, should
be pointed out anyway.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: Nico Williams <[email-masked]>
Date: Tue, 10 Mar 2015 13:29:28 -0500

I am in favor of adopting this proposal, or any proposal like it.

Using SRV RRs turns out to be somewhat problematic.  As we add
transports, we add DNS lookups.  It'd be nicer to do one lookup, and
get all the information.  URI RRs allow this, though I'm not sure that
URIs are really what we need here (but that's a detail we can discuss
after we adopt).

Nico
--

---

From: Rick van Rein <[email-masked]>
Date: Tue, 10 Mar 2015 22:27:03 +0100

Hello Nathaniel,

> http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/

Please consider deprecating the SRV-based procedure; without deprecation, implementatations are pretty much convicted to implementing both mechanisms forevermore, which is silly from both KISS and security viewpoints.

Please specify the implications for naming in certificates, such as for PKINIT.

Please do not overlool SCTP; it has the reliability and size-scalability of TCP but the speed and ordering advantages of UDP.  Even when Kerberos does not currently use SCTP, it may need to in future updates, possibly to handle large key sizes during PKINIT.

I hope this is helpful.

Cheers,
 -Rick

---

From: Nathaniel McCallum <[email-masked]>
Date: Tue, 10 Mar 2015 18:05:43 -0400

On Tue, 2015-03-10 at 22:27 +0100, Rick van Rein wrote:
> Please consider deprecating the SRV-based procedure; without 
> deprecation, implementatations are pretty much convicted to 
> implementing both mechanisms forevermore, which is silly from both 
> KISS and security viewpoints.

Is there specific IETF language I need to use for this?

Section 8 in the current document does imply that this method replaces 
the previous SRV lookup. I will definitely be making this more 
explicit.

> Please specify the implications for naming in certificates, such as 

I'm not sure how this relates. PKINIT is not a transport. Are you 
suggesting that we need to document the security considerations of 
using MS-KKDCP? If so, I don't think that's our job since:
1. We are not defining transports, just discovery of transports.
2. MS-KKDCP is not an IETF protocol.

> Please do not overlool SCTP; it has the reliability and size-
> scalability of TCP but the speed and ordering advantages of UDP.  
> Even when Kerberos does not currently use SCTP, it may need to in 
> future updates, possibly to handle large key sizes during PKINIT.

Since there is not currently an SCTP protocol defined, we cannot write 
a method for discovering it. Feel free to work on one. :)

Nathaniel

---

From: Rick van Rein <[email-masked]>
Date: Wed, 11 Mar 2015 10:25:47 +0100

Hi Nathaniel,

> Is there specific IETF language I need to use for this?

I don’t know of any, but the word “deprecated” seems to me to make a
big difference.  Formally, it’s still true of course that clients choose
whether to adopt any new standard into their code, but practically it
means that clients could get away with only implementing the new
approach.  For DNS admins, it would mean that they had to create
both descriptors because old clients won’t upgrade, but that hardly
sounds like a problem to me — except from the design ideal that
all knowledge should be concentrated in one place.

> I'm not sure how this relates.

I’m not sure if there is a problem, but it seems to be worthwhile to
consider.

SRV records point to a hostname, not an IP address.  This hostname
is then acceptable for certificates in many protocols — but I’m not
sure if that applies to the KDC’s certificates for PKINIT as well.
Note that an alternative is also possible, that is to require the domain
name to be used as a certificate name.  The fact that you define a
URI means that new habits / choices may follow, and especially if
the URI contains IP addresses instead of host names.

> Are you 
> using MS-KKDCP?

No.

> a method for discovering it. Feel free to work on one. :)

Hmm, yes this chicken-and-egg problem is everywhere where new
protocols are introduced, and it is generally considered valid reasoning.
I won’t press this hard, but think it leads to an impasse, which is why
I mentioned it; you are very specific about UDP and TCP and so you
are explicitly passing by SCTP.

-Rick

---

From: Greg Hudson <[email-masked]>
Date: Wed, 11 Mar 2015 10:39:42 -0400

> sure if that applies to the KDC’s certificates for PKINIT as well.

RFC 4556 requires that the KDC certificate contain a SAN of type
id-pkinit-san whose value is the TGT principal name for the realm, and
also an extended key usage value of id-pkinit-KPKdc.

The above applies "unless the client knows by some other means that the
KDC certificate is intended for a Kerberos KDC," and generally client
implementations do provide a way to use a standard SSL server cert for
the KDC with appropriate configuration.  In MIT krb5, the client must
have the valid PKINIT cert hostnames for the realm explicitly configured
in krb5.conf for this option; we do not pay any attention to the
hostname from the transport lookup.

I wouldn't object to security considerations language to make it
explicit that an unauthenticated transport hostname MUST NOT be used to
validate a PKINIT certificate (and maybe that a DNSSEC-authenticated
transport hostname SHOULD NOT be used), but I don't know that it is
necessary.

---

From: Rick van Rein <[email-masked]>
Date: Wed, 11 Mar 2015 15:57:37 +0100

Hi,

> also an extended key usage value of id-pkinit-KPKdc.

That takes my concern away.

-Rick

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Mar 2015 15:09:40 +0000

> transport hostname SHOULD NOT be used), but I don't know that it is

For PKINIT, where the user is expected to have some sort of
pre-existing trust relationship with the realm, adding DNSSEC as
a trusted "introducer" indeed may be unwise as a default.

In other contexts, where DNS is already an "introducer" of a remote
realm to the clients or KDC of a local realm one might employ
DNSSEC-validated results in security-relevant decisions.

Nico and I discussed some time back an idea for building cross-realm
keys between two "stranger" realms "on the fly", based on DANE.

There is certainly room for using DNSSEC-validated information with
automated unattended bootstrapping of secure channels to new realms
(if this is something that the local KDC is configured to do).

However, PKINIT should generally rely on "more local" trust anchors.
I deploy a single private root CA cert for PKINIT.

-- 
	Viktor.

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 11 Mar 2015 11:26:16 -0400

On Wed, 2015-03-11 at 10:25 +0100, Rick van Rein wrote:
> > >   Even when Kerberos does not currently use SCTP, it may need to 
> > > in  future updates, possibly to handle large key sizes during 
> > > PKINIT.
> > 
> > Since there is not currently an SCTP protocol defined, we cannot 
> > write  a method for discovering it. Feel free to work on one. :)
> 
> I won’t press this hard, but think it leads to an impasse, which is 
> why I mentioned it; you are very specific about UDP and TCP and so 
> you are explicitly passing by SCTP.

This isn't a chicken-and-egg problem. There is a dependency, but it is 
not circular.

Future transports and services will define new URI formats and 
prefixes, respectively, in their own RFCs. The scope of this draft is 
to define:
1. an extensible discovery protocol
2. prefixes for pre-existing services
3. URI formats for pre-existing transports

In short, don't feel like we have to cram SCTP into this draft. As I 
mentioned before, please feel free to write up an SCTP draft. It can 
define a URI format and reference this draft as a normative reference.

Nathaniel

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 11 Mar 2015 12:01:31 -0400 (EDT)

> other than this is a misconfiguration.

The client can always supply arbitrary authdata and request its inclusion
in the ticket.  The KDC need not know in advance when this might happen or
what it might include.

> I'd be happy to add a statement to this effect in the draft.

I would prefer Simo's approach.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 11 Mar 2015 12:05:26 -0400 (EDT)

> If you'd like to discuss it, reply to this message. :)

I'm generally in favor of something like this.

A few things that came to mind while reading it that have not already been
raised:

You cover kerberos and kpasswd, but not kadmin.  Any reason why?  (MIT's
code does not currently support using DNS to locate an admin server, but
that's not a reason to reject adding it to a discovery protocol in its own
right.)

I'm uncertain that section 3 is necessary.  Section 7.2.3.1 of RFC 4120
seems to just be saying "you can't make two kerberos realms that differ
only in case"; whatever case is used for the DNS query, the response will
be the same.

Section 5.1 calls out that the default path differs from that in
[MS-KKDCP].  It seems like some justification for this deviation should be
offered, or the gratuitous difference removed.

-Ben

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 11 Mar 2015 12:30:51 -0400

On Wed, 2015-03-11 at 12:05 -0400, Benjamin Kaduk wrote:
> You cover kerberos and kpasswd, but not kadmin.  Any reason why?  
> (MIT's code does not currently support using DNS to locate an admin 
> server, but that's not a reason to reject adding it to a discovery 
> protocol in its own
> right.)

My understanding is that kadmin is a proprietary protocol and has not 
been standardized. If that is incorrect, I can certainly add it. Does 
it already have a standardized discovery protocol?

> I'm uncertain that section 3 is necessary.  Section 7.2.3.1 of RFC 
> 4120 seems to just be saying "you can't make two kerberos realms 
> that differ only in case"; whatever case is used for the DNS query, 
> the response will
> be the same.

Do I understand you correctly to suggest that I simply remove section 3
altogether and say nothing about realm-to-domain translation?

> Section 5.1 calls out that the default path differs from that in [MS-
> KKDCP].  It seems like some justification for this deviation should 
> be

Good point. My justification is simply that the default provided by MS-
KKDCP will confuse DNS admins.

They will see a URI that looks like this:
  https://kdc.foo.com

They will expect this behavior from past experience:
  https://kdc.foo.com/

But they will actually get this behavior:
  https://kdc.foo.com/KdcProxy

Even if we were to use a different URI scheme, I think this behavior 
expectation mismatch will be pronounced.

I suspect the use of /KdcProxy is really just an implementation 
detail. Its only appearance is in Section 2.1 and its meaning is 
rather vague. I would like some clarification from MS regarding this 
question.

Nathaniel

---

From: Greg Hudson <[email-masked]>
Date: Wed, 11 Mar 2015 12:35:21 -0400

> offered, or the gratuitous difference removed.

Section 2.1 of [MS-KKDCP] states, "The URI uses the virtual directory
/KdcProxy unless otherwise configured."  I don't know what this actually
means.  I doubt it means that software should convert a URI like
http://hostname to http://hostname/KdcProxy.

In a similar vein it seems weird for this document to say anything about
a default path.  A URI always has a path component; it may be empty.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 11 Mar 2015 12:44:07 -0400 (EDT)

> it already have a standardized discovery protocol?

There are at least two different proprietary kadmin protocols.
SRV records for _kerberos-adm._tcp.[realm] are documented by both
MIT and Heimdal, and exist at many sites.  It looks like Heimdal doesn't
actually implement client support for them, either, though, judging by git
grep.  (The corresponding draft-ietf-cat-krb-dns-locate seems to have
withered and died.)

> altogether and say nothing about realm-to-domain translation?

That's my suggestion.  I am not 100% confident that it is correct, though.

> rather vague. I would like some clarification from MS regarding this

I guess I am satisfied by Greg's response on this point.

-Ben

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 11 Mar 2015 12:54:34 -0400

On Wed, 2015-03-11 at 12:35 -0400, Greg Hudson wrote:
> Section 2.1 of [MS-KKDCP] states, "The URI uses the virtual 
> directory /KdcProxy unless otherwise configured."  I don't know what 
> this actually means.  I doubt it means that software should convert a
> URI like  http://hostnameto http://hostname/KdcProxy.
> 
> In a similar vein it seems weird for this document to say anything 
> about a default path.  A URI always has a path component; it may be 
> empty.

Perhaps it would be better to say that the path may be empty and that 
the client MUST NOT try to replace an empty path with a default value?

Nathaniel

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 11 Mar 2015 12:56:35 -0400

On Wed, 2015-03-11 at 12:44 -0400, Benjamin Kaduk wrote:
> > > A few things that came to mind while reading it that have not > >
> already been
> > > raised:
> > >
> > > (MIT's code does not currently support using DNS to locate an 
> admin > > server, but that's not a reason to reject adding it to a 
> discovery > > protocol in its own
> > > right.)
> >
> > My understanding is that kadmin is a proprietary protocol and has 
> not > been standardized. If that is incorrect, I can certainly add 
> it. Does > it already have a standardized discovery protocol?
> 
> There are at least two different proprietary kadmin protocols. SRV 
> records for _kerberos-adm._tcp.[realm] are documented by both MIT 
> and Heimdal, and exist at many sites.  It looks like Heimdal doesn't 
> grep.  (The corresponding draft-ietf-cat-krb-dns-locate seems to 
> have withered and died.)

I am hesitant to attempt to define a discovery method for an 
unstandardized service. I would rather the service be standardized and 
define its own prefix at that time.

Nathaniel

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 11 Mar 2015 14:30:33 -0400

> There are at least two different proprietary kadmin protocols.

And this is why SRV records for kadmin is not standardized.

> grep. 

Using the same SRV record for both MIT and Heimdal is in my opinion a
bad mistake since each kadmin service implementation is incompatible
with the other.

_mit-kerberos-adm._tcp.[realm]
_heimdal-kerberos-adm._tcp.[realm]

would have been much better.

> (The corresponding draft-ietf-cat-krb-dns-locate seems to have
> withered and died.)

No.  The part of this I-D that were acceptable to the working group were
incorporated in RFC 4120.

Jeffrey Altman

---

From: Petr Spacek <[email-masked]>
Date: Tue, 24 Mar 2015 09:35:58 +0100

> http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/

Hello,

I'm late to the party so I will only one thing:
It seems like a good idea to standardize _kerberos-master URI record too (with
semantics equal to the one described on
http://web.mit.edu/Kerberos/krb5-1.12/doc/admin/realm_config.html).

Have a nice day!

-- 
Petr Spacek  @  Red Hat

---

From: Nathaniel McCallum <[email-masked]>
Date: Tue, 24 Mar 2015 08:36:27 -0400

> http://web.mit.edu/Kerberos/krb5-1.12/doc/admin/realm_config.html).

I *think* this might be MIT specific. Maybe Greg can answer that?

Nathaniel

---

From: Greg Hudson <[email-masked]>
Date: Tue, 24 Mar 2015 10:20:01 -0400

> I *think* this might be MIT specific. Maybe Greg can answer that?

It does look like only MIT krb5 implements it.

The semantics of _kerberos-master are "these addresses represent KDCs
(usually just one) which are more up to date than the other KDCs in the
realm, so retry with one of these if your first try fails for most
reasons."  In some realms the master KDC isn't one of the regular KDCs,
in order to shed the majority of the load from the KDC which is also
running kadmind.

These semantics are not generally needed for a realm with fast
replication (iprop with low polling delay, LDAP, etc.), but there are
enough realms with slow replication that we're not about to discard
those semantics.

It might be good if master KDC entries could be obtained in the same DNS
lookup as regular KDC entries, but none of the ways I can think of to do
it are particularly elegant.  We would need to be able to annotate each
URI with "this is also a master KDC" or "this is only a master KDC".
Shoving that tri-state into each URI scheme wouldn't be very elegant;
designating magic priority values for the URI record would be a layering
violation.  It's not really a big deal if a second DNS lookup is needed
for the fallback.

I have no strong opinion on whether the discovery standard needs to talk
about this.  MIT krb5 can always continue to implement it as a
non-standardized feature, using the same lookup behavior as the
_kerberos URI record but with the label changed to _kerberos-master.