Subject: [kitten] Review of draft-ietf-kitten-krb-service-discovery-00

From: Greg Hudson <[email-masked]>
Date: Tue, 21 Mar 2017 11:54:20 -0400

In general:

* RFC 7553 is informational and this document is standards track, which
  is a down reference (see RFC 3967).  Also, RFC 7553 contains ambiguous
  guidance about URI records labels which some readers have interpreted
  as being incompatible with our use of labels.  I think at one point we
  received advice to reference the IANA registration of the URI record
  type instead of RFC; unfortunately I do not know the mechanics of that
  kind of reference.

* Similarly, MS-KKDCP is in the normative references section, and is not
  a standards-track IETF document.  It is only used as the reference in
  the initial contents of the transport registry, so perhaps it can just
  be an informative reference.

Abstract:

* I would rephrase or omit the fourth goal ("define a discovery
  procedure for Kerberos password services").  There is an
  interoperable, well-documented[1] de facto standard for discovering
  kpasswd services; it just isn't specified in an RFC.  It's debatable
  whether this is a serious enough deficit to mention in the abstract as
  a problem that we're solving; if it is, I would say "formally specify"
  rather than "define" to make it clear that the problem being remedied
  is the lack of a formal specification.

Section 4.2 (Flags):

* seperating -> separating

* eg. -> e.g. (two places; I think this is the accepted RFC style based
  on a very brief survey)

* Section 4.2.1 (Master Flag) is too focused on password changes, I
  think.  I suggest:

  The client SHOULD consider this server as one that might possess more
  up-to-date long-term key material, and use it as a fallback for errors
  that might result from out-of-date keys.

  (Although MIT krb5 currently only uses the master KDC for AS requests,
  Roland has pointed out that we really ought to use it for TGS requests
  as well due to krbtgt key rollovers.)

Section 4.4 (Residual):

* I suggest "where such are defined" -> "as defined"

Section 5 (Kerberos V5 KDC Service Discovery):

* "REALM indicates the translation of the Kerberos realm to a DNS
   domain" seems to invoke some kind of translation procedure without a
   reference.  RFC 4120 doesn't really define any such translation
   procedure; it just says in section 6.1 that a realm might be in
   domain style with some specifics on what that means, and in section
   7.2.3.2 that "The realm MUST be a domain-style realm name".

   (Section 6 has this same wording again.)

Section 7 (Kerberos Admin Service Discovery):

* There is no standard admin protocol, even a de facto one (well,
  Heimdal has some interoperability with MIT krb5).  It doesn't make a
  lot of sense to specify a standard discovery protocol when there is no
  standard for what is being discovered.  I think we want to leave this
  as an implementation-specific aside.

  This change would have an impact on section 9.2.1 (removing the
  default admin service port) and 9.2.2.

Section 8 (Relationship to Existing Mechanism):

* The wording here seems too general.  I think we want to specifically
  say that URI records should be preferred over SRV records.

Section 9.1.2 (Initial Registry Contents, for flags registry):

* The reference here is "TBD".  Is there a plan?  Is the reference
  supposed to be to this RFC once a number is assigned?

[1] https://technet.microsoft.com/en-us/library/cc961719.aspx
    http://web.mit.edu/kerberos/krb5-latest/doc/admin/realm_config.html#hostnames-for-kdcs
    http://www.h5l.org/manual/HEAD/info/heimdal/Setting-up-DNS.html#Setting-up-DNS

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Tue, 21 Mar 2017 13:16:26 -0700

> On Mar 21, 2017, at 8:54 AM, Greg Hudson <[email-masked]> wrote:
> 

Mildly disagree. 

Mainly because there is RFC 6860. As a weaker argument, I still think it makes sense to specify how to find the admin service, even if the details of that service are “implementation specific”.

Of course, having done that much, one wonders if we couldn’t specify an interoperable subset of an admin protocol which implements “enough of” 6860. . .  Experience with 6860 would suggest there isn’t sufficient interest to support that effort though.

>  default admin service port) and 9.2.2.

Personal email.  [email-masked]

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 21 Mar 2017 22:04:13 -0400

On 3/21/2017 4:16 PM, Henry B (Hank) Hotz, CISSP wrote:
> Mainly because there is RFC 6860.

Hi Hank,

I'm confused, what does RFC 6860 "Hiding Transit-Only Networks in OSPF"
have to do with this draft?  Is there a different RFC you are thinking
about?

Jeffrey Altman

---

From: Greg Hudson <[email-masked]>
Date: Thu, 23 Mar 2017 13:06:46 -0400

> Mainly because there is RFC 6860.

I think Hank meant RFC 6880 (KDC Information Model), to answer Jeffrey
Altman's question.

I will argue that in complexity, a discovery mechanism is small, an
information model is medium, and an administrative protocol is large.  I
argued that the URI discovery draft creates:

  [discovery] -> <empty void of no admin protocol>

Adding RFC 6860 into the mix just changes the picture to:

  [disc] -> <empty void of no admin protocol> -> [info model]

They don't connect up, and the missing piece is much larger than the
pieces on either side.  As there is no indication that a complete
picture is forthcoming, I believe that any DNS discovery protocol for
the implementation-specific admin service should also be considered
implementation-specific.

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 24 Mar 2017 17:04:50 -0400

On 3/23/2017 1:06 PM, Greg Hudson wrote:
> I believe that any DNS discovery protocol for

I concur.

Jeffrey Altman

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Fri, 24 Mar 2017 14:22:56 -0700

> On Mar 23, 2017, at 10:06 AM, Greg Hudson <[email-masked]> wrote:
> 

Yes. (Copy-by-hand considered dangerous.)

> the implementation-specific admin service should also be considered

My opinion hasn’t changed. I think the service discovery protocols for everything ought to be similar so they ought to be specified together.

I will note that failing to include something I wanted is not a reason to oppose the entire draft. I can live with being in the rough for this point.

---

From: Matt Rogers <[email-masked]>
Date: Thu, 30 Mar 2017 14:51:36 -0400

>   type instead of RFC; unfortunately I do not know the mechanics of that
The IANA registration entry refers to RFC 7553:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml
Perhaps it should just be an informative reference instead.

>   be an informative reference.
I'll make this an informative reference.

>   is the lack of a formal specification.

I think "formally specify" would be better.

>   that might result from out-of-date keys.
Works for me.

> * I suggest "where such are defined" -> "as defined"

This will be removed with the Residual section (based on past comments
to redefine the fields as
"krb5srv:[flags]:transport-type:transport-info")

>    (Section 6 has this same wording again.)

How about "..client MUST query the following URI DNS record, where
REALM is a domain-style realm name."

>   default admin service port) and 9.2.2.
I'm OK with removing this part.

>   say that URI records should be preferred over SRV records.

How about: "Clients that support service discovery through both URI
and SRV records SHOULD perform the URI discovery first. If no URI
record is found, the client MAY then attempt SRV discovery."

>   supposed to be to this RFC once a number is assigned?

It should be changed to the assigned number, yes. It was suggested
that instead of TBD we use [This Document], which I think is the
convention for this kind of reference.

I'd also like to get some thoughts on this text for a Security
Considerations section:
"The security implication of using DNS URI records is identical to
that of using DNS for any Kerberos service or host mapping; without
secure DNS the results can be forged.  The same precautions regarding
the use of insecure DNS with Kerberos outlined in RFC 4120 should be
followed."

Thanks,
Matt