[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
- Re: [kitten] Review of draft-ietf-kitten-krb-serv… Matt Rogers
- Re: [kitten] Review of draft-ietf-kitten-krb-serv… Benjamin Kaduk
- [kitten] Review of draft-ietf-kitten-krb-service-… Greg Hudson
- Re: [kitten] Review of draft-ietf-kitten-krb-serv… Henry B (Hank) Hotz, CISSP
- Re: [kitten] Review of draft-ietf-kitten-krb-serv… Jeffrey Altman
- Re: [kitten] Review of draft-ietf-kitten-krb-serv… Greg Hudson
- Re: [kitten] Review of draft-ietf-kitten-krb-serv… Jeffrey Altman
- Re: [kitten] Review of draft-ietf-kitten-krb-serv… Henry B (Hank) Hotz, CISSP
- Re: [kitten] Review of draft-ietf-kitten-krb-serv… Matt Rogers
- Re: [kitten] Review of draft-ietf-kitten-krb-serv… Greg Hudson