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

Greg Hudson <ghudson@mit.edu> Tue, 21 March 2017 15:54 UTC

Return-Path: <ghudson@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21821297CD for <kitten@ietfa.amsl.com>; Tue, 21 Mar 2017 08:54:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtLRPThNt5j9 for <kitten@ietfa.amsl.com>; Tue, 21 Mar 2017 08:54:26 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF81129A71 for <kitten@ietf.org>; Tue, 21 Mar 2017 08:54:24 -0700 (PDT)
X-AuditID: 12074424-67fff70000004baa-93-58d14cae3617
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id E2.56.19370.EAC41D85; Tue, 21 Mar 2017 11:54:23 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v2LFsLRf012129 for <kitten@ietf.org>; Tue, 21 Mar 2017 11:54:22 -0400
Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v2LFsKRJ011898 for <kitten@ietf.org>; Tue, 21 Mar 2017 11:54:21 -0400
From: Greg Hudson <ghudson@mit.edu>
To: kitten@ietf.org
Date: Tue, 21 Mar 2017 11:54:20 -0400
Message-ID: <x7dzige39sj.fsf@equal-rites.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUixCmqrLve52KEwYqbQhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrJtT5kK5slUfJ11h62BcYNYFyMnh4SAiUTTgn/MXYxcHEIC bUwSiyc9Z4RwjjNKHH7/iAXC6WCS+HP0AgtIC5uAssT6/VvBbBEBYYndW98xg9jCArYSs2bd ZQWxWQRUJb4/2sAEYvMKGEq8e3mSEcIWlDg58wlYL7OAhMTBFy+YJzByz0KSmoUktYCRaRWj bEpulW5uYmZOcWqybnFyYl5eapGuuV5uZoleakrpJkZQGLC7qOxg7O7xPsQowMGoxMOrIH8x Qog1say4MvcQoyQHk5Io75pLFyKE+JLyUyozEosz4otKc1KLDzFKcDArifBaOgKV86YkVlal FuXDpKQ5WJTEecU1GiOEBNITS1KzU1MLUotgsjIcHEoSvMIOQI2CRanpqRVpmTklCGkmDk6Q 4TxAwxfYgQwvLkjMLc5Mh8ifYlSUEuddaA+UEABJZJTmwfWC41SI0foVozjQK8K8f22BqniA MQ7X/QpoMBPQ4LI9F0AGlyQipKQaGNfKVlz0bNmeJhQddXDToYj8g+wc7V+Mb97b05vRknTw 2GuXR4Uyrw7uX/Bm3xK1CXZ8Ym69JQt8tl6bvmAJ90ZZlqnb7qjdvJB+9Ojpyugde1+yeB/o O/BI5O7Z4j9cr97Oz5x7tSxR6ZJ82CwT/S0FLh9drk/gjg6fmZj7ql7GkFvBbvnxublKLMUZ iYZazEXFiQDTfuQZrgIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/nd7_8JIKefEjiy7WXVxVsm5os7g>
Subject: [kitten] Review of draft-ietf-kitten-krb-service-discovery-00
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Mar 2017 15:54:28 -0000

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