From nobody Tue Mar 21 08:54:29 2017 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; Tue, 21 Mar 2017 11:54:21 -0400 From: Greg Hudson To: kitten@ietf.org Date: Tue, 21 Mar 2017 11:54:20 -0400 Message-ID: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Tue Mar 21 13:16:39 2017 Return-Path: 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 B6692129516 for ; Tue, 21 Mar 2017 13:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 hOj77tEnmwKr for ; Tue, 21 Mar 2017 13:16:31 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BCB1129513 for ; Tue, 21 Mar 2017 13:16:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 299F3E1C8; Tue, 21 Mar 2017 16:16:30 -0400 (EDT) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t65K-zAumhBZ; Tue, 21 Mar 2017 16:16:28 -0400 (EDT) Received: from [192.168.3.129] (24-205-82-163.dhcp.psdn.ca.charter.com [24.205.82.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 5D999A10DE; Tue, 21 Mar 2017 16:16:28 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: Date: Tue, 21 Mar 2017 13:16:26 -0700 Cc: kitten@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3FD27BFF-5090-4505-852C-E8766BBAA93B@oxy.edu> References: To: Greg Hudson X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 20:16:33 -0000 > On Mar 21, 2017, at 8:54 AM, Greg Hudson wrote: >=20 > Section 7 (Kerberos Admin Service Discovery): >=20 > * 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. Mildly disagree.=20 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 =E2=80=9Cimplementation specific=E2=80=9D. Of course, having done that much, one wonders if we couldn=E2=80=99t = specify an interoperable subset of an admin protocol which implements = =E2=80=9Cenough of=E2=80=9D 6860. . . Experience with 6860 would = suggest there isn=E2=80=99t sufficient interest to support that effort = though. > This change would have an impact on section 9.2.1 (removing the > default admin service port) and 9.2.2. Personal email. hbhotz@oxy.edu From nobody Tue Mar 21 19:05:07 2017 Return-Path: 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 A4600130133 for ; Tue, 21 Mar 2017 19:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=secure-endpoints.com 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 RspxXhsLN8Y1 for ; Tue, 21 Mar 2017 19:04:41 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8213112942F for ; Tue, 21 Mar 2017 19:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1490148258; x=1490753058; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:From:Openpgp:Organization:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; bh=TAA32qkQo1UgWnRsgimklk TwW/zn2BOOKNbVNvDhQ50=; b=tNgvfR0UClC4n8+/VKQrsGBSb97GDUywsjI8hJ YqpIJ0982IfoQcneyFsyv5K+Hg1pBObC3zyiRKWGm1ISjT1MZ+x/7r5bawX11zFS Tffksc6Boz9C3ZjauJE6DZxbEPIc7qa5nFISP2AktZd48cU8JapCX8QHrC7RxJkN 6ldAE= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Tue, 21 Mar 2017 22:04:18 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Tue, 21 Mar 2017 22:04:18 -0400 Received: from [IPv6:2001:470:1f07:f77:71aa:981e:ca22:7768] by secure-endpoints.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v16.5.2) with ESMTPSA id md50001298125.msg for ; Tue, 21 Mar 2017 22:04:17 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDRemoteIP: 2001:470:1f07:f77:71aa:981e:ca22:7768 X-MDHelo: [IPv6:2001:470:1f07:f77:71aa:981e:ca22:7768] X-MDArrival-Date: Tue, 21 Mar 2017 22:04:17 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1254fc8628=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-CAV-Result: clean To: kitten@ietf.org References: <3FD27BFF-5090-4505-852C-E8766BBAA93B@oxy.edu> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=https://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: <80806829-87b9-5945-24ca-b96144947476@secure-endpoints.com> Date: Tue, 21 Mar 2017 22:04:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3FD27BFF-5090-4505-852C-E8766BBAA93B@oxy.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000106000106080601080301" Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 02:04:44 -0000 This is a cryptographically signed message in MIME format. --------------ms000106000106080601080301 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/21/2017 4:16 PM, Henry B (Hank) Hotz, CISSP wrote: >=20 >> On Mar 21, 2017, at 8:54 AM, Greg Hudson wrote: >> >> 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 n= o >> standard for what is being discovered. I think we want to leave this= >> as an implementation-specific aside. >=20 > Mildly disagree.=20 >=20 > 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 --------------ms000106000106080601080301 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DJswggYCMIIE6qADAgECAhBAAVgjEN7WFoCIXylZ1uvSMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE2MTEwMjAzMjQxOFoXDTE3MTEwMjAzMjQxOFowgZYxNTAzBgNVBAsMLFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMSswKQYJKoZIhvcNAQkBFhxq YWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMTAwLgYKCZImiZPyLGQBARMgN0YwMDAwMDEw MDAwMDE1ODIzMTBERUE3MDAwMDA3QjQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDPaPDUdwWkzLcNsJjjlDs5lo4ySDKmCgzQsuDt+VY3wP0IZBbu8f/LM3zWCH7zVRJ/XuY5 qN44jFEXwj5fGY71Esm5pKv5sUpys6Q3c6BKXiHv/IUusI3qTJ46QBEAiHu2lxB75UnIYgm+ ZbKmcAR48Z1Sl/Ku86e9GPuts9R51SeHW1pjq89LAi6C0ERuAUIK0rVZGDmKWtRNs9EykXzk mU2Z1ZLuPL0jIggFPeT8TyH6TH/XvapbC+7rHJrzuBY4NDqLgqDJUf0JidL9JeK9+IxxPCab EbVmOf5sBgO5mg92l4+f+Q4xefZcI4C7RPFdRTRWsQs7Z3DpE28BDbjDAgMBAAGjggKlMIIC oTAOBgNVHQ8BAf8EBAMCBaAwgYQGCCsGAQUFBwEBBHgwdjAwBggrBgEFBQcwAYYkaHR0cDov L2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUFBzAChjZodHRwOi8vdmFs aWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWExMi5wN2MwHwYDVR0jBBgw FoAUpHPa72k1inXMoBl7CDL4a4nkQuwwCQYDVR0TBAIwADCCASwGA1UdIASCASMwggEfMIIB GwYLYIZIAYb5LwAGCwEwggEKMEoGCCsGAQUFBwIBFj5odHRwczovL3NlY3VyZS5pZGVudHJ1 c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDCBuwYIKwYBBQUHAgIw ga4agatUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4gaXNzdWVkIGluIGFjY29y ZGFuY2Ugd2l0aCAKSWRlblRydXN0J3MgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91 bmQgYXQgaHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5 L3RzL2luZGV4Lmh0bWwwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3ZhbGlkYXRpb24uaWRl bnRydXN0LmNvbS9jcmwvdHJ1c3RpZGNhYTEyLmNybDAnBgNVHREEIDAegRxqYWx0bWFuQHNl Y3VyZS1lbmRwb2ludHMuY29tMB0GA1UdDgQWBBSP11Voh/Sg9hmecftn2BV5ZQd9OTAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAC9cnqRj+ViE efFsiYNMUC8tZf6PXcWDecOR5Pdv/Vd/O6y10mYyilPrcd0sJux1idTZIOzHAsh36BfBdNSt BFAuBZD66L649U3XqBnh9nbuzmCwNc3tWjOaY/Xe7R90lqrXaW0Dw0U++zwmNyCO2CRgBdrU 8cTqFpOtpe/gCAMhjajrUfb+m8Vcd5R0RVIvdljblqv2t9IXQIHwWSm8E7v302z7yW4o4iPH kegez5vq37ICikQjkkVyAJr0wtirJyQuFzMgpoWVpm0CKBiMwJPki2kiHlNiMHBr2ch4fC+H SjbMg4OzTZJCz1xhKvpyRDOM8JRb2BNSU8JjmrxZgFIwggaRMIIEeaADAgECAhEA+d5Wf8lN DHdw+WAbUtoVOzANBgkqhkiG9w0BAQsFADBKMQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRl blRydXN0MScwJQYDVQQDEx5JZGVuVHJ1c3QgQ29tbWVyY2lhbCBSb290IENBIDEwHhcNMTUw MjE4MjIyNTE5WhcNMjMwMjE4MjIyNTE5WjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRl blRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANGRTTzPCic0kq5L6ZrUJWt5LE/n6tbPXPhGt2Egv7plJMoEpvVJJDqGqDYy maAsd8Hn9ZMAuKUEFdlx5PgCkfu7jL5zgiMNnAFVD9PyrsuF+poqmlxhlQ06sFY2hbhQkVVQ 00KCNgUzKcBUIvjv04w+fhNPkwGW5M7Ae5K5OGFGwOoRck9GG6MUVKvTNkBw2/vNMOd29VGV TtR0tjH5PS5yDXss48Yl1P4hDStO2L4wTsW2P37QGD27//XGN8K6amWB6F2XOgff/PmlQjQO ORT95PmLkwwvma5nj0AS0CVp8kv0K2RHV7GonllKpFDMT0CkxMQKwoj+tWEWJTiDKSsCAwEA AaOCAoAwggJ8MIGJBggrBgEFBQcBAQR9MHswMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJj aWFsLm9jc3AuaWRlbnRydXN0LmNvbTBHBggrBgEFBQcwAoY7aHR0cDovL3ZhbGlkYXRpb24u aWRlbnRydXN0LmNvbS9yb290cy9jb21tZXJjaWFscm9vdGNhMS5wN2MwHwYDVR0jBBgwFoAU 7UQZwNPwBovupHu+QucmVMiONnYwDwYDVR0TAQH/BAUwAwEB/zCCASAGA1UdIASCARcwggET MIIBDwYEVR0gADCCAQUwggEBBggrBgEFBQcCAjCB9DBFFj5odHRwczovL3NlY3VyZS5pZGVu dHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDADAgEBGoGqVGhp cyBUcnVzdElEIENlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdp dGggSWRlblRydXN0J3MgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0 cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzL2luZGV4 Lmh0bWwwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNv bS9jcmwvY29tbWVyY2lhbHJvb3RjYTEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFKRz2u9pNYp1zKAZewgy+GuJ5ELsMA0G CSqGSIb3DQEBCwUAA4ICAQAN4YKu0vv062MZfg+xMSNUXYKvHwvZIk+6H1pUmivyDI4I6A3w Wzxlr83ZJm0oGIF6PBsbgKJ/fhyyIzb+vAYFJmyI8I/0mGlc+nIQNuV2XY8cypPoVJKgpnzp /7cECXkX8R4NyPtEn8KecbNdGBdEaG4a7AkZ3ujlJofZqYdHxN29tZPdDlZ8fR36/mAFeCEq 0wOtOOc0Eyhs29+9MIZYjyxaPoTS+l8xLcuYX3RWlirRyH6RPfeAi5kySOEhG1quNHe06QIw pigjyFT6v/vRqoIBr7WpDOSt1VzXPVbSj1PcWBgkwyGKHlQUOuSbHbHcjOD8w8wHSDbL+L2h e8hNN54doy1e1wJHKmnfb0uBAeISoxRbJnMMWvgAlH5FVrQWlgajeH/6NbYbBSRxALuEOqEQ epmJM6qz4oD2sxdq4GMN5adAdYEswkY/o0bRKyFXTD3mdqeRXce0jYQbWm7oapqSZBccFvUg YOrB78tB6c1bxIgaQKRShtWR1zMM0JfqUfD9u8Fg7G5SVO0IG/GcxkSvZeRjhYcbTfqF2eAg prpyzLWmdr0mou3bv1Sq4OuBhmTQCnqxAXr4yVTRYHkp5lCvRgeJAme1OTVpVPth/O7HJ7Vu EP9GOr6kCXCXmjB4P3UJ2oU0NqfoQdcSSSt9hliALnExTEjii20B2nSDojGCAxQwggMQAgEB ME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJ RCBDQSBBMTICEEABWCMQ3tYWgIhfKVnW69IwDQYJYIZIAWUDBAIBBQCgggGXMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDMyMjAyMDQxM1owLwYJKoZI hvcNAQkEMSIEIDDiO1O2rmiMKLBsVrdeHVDIT507udSK8jYvVs4aHND/MF0GCSsGAQQBgjcQ BDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1 c3RJRCBDQSBBMTICEEABWCMQ3tYWgIhfKVnW69IwXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy AhBAAVgjEN7WFoCIXylZ1uvSMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEArAolU3+fsHLP/cMWt9Je DBC6SrjlIOieEkLvn4HEZJZND3fgy5N7azOJkuqNsBBLcQKhbqaejXmBEsPTkRyNRJReqYh2 bgmHr0kCI4St46N/jy0RAKZa4/bjqNaqXFXSvxp32tYLqSHGUIOe48T2vyqIre0hy+cqoGuo RqqxF3QzZwpHoLelycFZKVBKY7hpQsH59YSVgBmINOJ9+cUdGNoc48CRKe6h8jn3ICvuP3W3 b6kfk0iPgnx2+Ly4MIOBhmB/8jx0hf9tsDKAOAMeT2AxBhnK48qGFBHCm9rkO3zMoQYn42UR Qsfl7nByAdCU6GvKkk2AFSNDi7VqCGynXQAAAAAAAA== --------------ms000106000106080601080301-- From nobody Wed Mar 22 15:57:57 2017 Return-Path: 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 A0D11129C25; Wed, 22 Mar 2017 15:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 AaiplDuVleW2; Wed, 22 Mar 2017 15:57:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D28EF129C1E; Wed, 22 Mar 2017 15:57:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7410DB80DA0; Wed, 22 Mar 2017 15:56:59 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, kitten@ietf.org Message-Id: <20170322225659.7410DB80DA0@rfc-editor.org> Date: Wed, 22 Mar 2017 15:56:59 -0700 (PDT) Archived-At: Subject: [kitten] RFC 8129 on Authentication Indicator in Kerberos Tickets X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 22:57:41 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8129 Title: Authentication Indicator in Kerberos Tickets Author: A. Jain, N. Kinder, N. McCallum Status: Standards Track Stream: IETF Date: March 2017 Mailbox: ajain323@gatech.edu, nkinder@redhat.com, npmccallum@redhat.com Pages: 6 Characters: 11296 Updates: RFC 4120 I-D Tag: draft-ietf-kitten-krb-auth-indicator-07.txt URL: https://www.rfc-editor.org/info/rfc8129 DOI: 10.17487/RFC8129 This document updates RFC 4120, as it specifies an extension in the Kerberos protocol. It defines a new authorization data type, AD-AUTHENTICATION-INDICATOR. The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in service tickets so that application services can use it as an input into policy decisions. This document is a product of the Common Authentication Technology Next Generation Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Mar 23 10:06:53 2017 Return-Path: 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 D00ED129A6C for ; Thu, 23 Mar 2017 10:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 1tLClcDpzkiq for ; Thu, 23 Mar 2017 10:06:51 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 62369129A04 for ; Thu, 23 Mar 2017 10:06:51 -0700 (PDT) X-AuditID: 12074422-903ff70000006fe7-63-58d400a998f1 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 80.D7.28647.9A004D85; Thu, 23 Mar 2017 13:06:50 -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 v2NH6m2w018319; Thu, 23 Mar 2017 13:06:49 -0400 Received: from [18.101.8.226] (vpn-18-101-8-226.mit.edu [18.101.8.226]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v2NH6kcW028061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Mar 2017 13:06:47 -0400 To: "Henry B (Hank) Hotz, CISSP" References: <3FD27BFF-5090-4505-852C-E8766BBAA93B@oxy.edu> Cc: kitten@ietf.org From: Greg Hudson Message-ID: Date: Thu, 23 Mar 2017 13:06:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <3FD27BFF-5090-4505-852C-E8766BBAA93B@oxy.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKIsWRmVeSWpSXmKPExsUixCmqrLuK4UqEwer74hYf7y1ksTi6eRWL A5PHkiU/mTy2Nv1lDmCK4rJJSc3JLEst0rdL4MqY+ewnW8FvtopDE58xNzCeYu1i5OSQEDCR OLnmAyOILSTQxiSxcr9RFyMXkL2RUaJ1wWM2iMRRJon7jRwgtrCAl8TjKUtZQGwRAUOJ6Ssn Ag3iAKpJknjeYAESZhYQlli+5ixYK5uAssT6/VvBynkFrCT+rj7MDGKzCKhK3OyfxATSKioQ IdFwOB2iRFDi5MwnYOWcAtYSj25OY4QYqS7xZ94lZghbXmL72znMExgFZiFpmYWkbBaSsgWM zKsYZVNyq3RzEzNzilOTdYuTE/PyUot0TfVyM0v0UlNKNzGCQpTdRWkH48R/XocYBTgYlXh4 I2suRQixJpYVV+YeYpTkYFIS5XXceTlCiC8pP6UyI7E4I76oNCe1+BCjBAezkgjv49dAOd6U xMqq1KJ8mJQ0B4uSOK+4RmOEkEB6YklqdmpqQWoRTFaGg0NJglcDGItCgkWp6akVaZk5JQhp Jg5OkOE8QMMlQWp4iwsSc4sz0yHypxh1OW4cP/CGSYglLz8vVUqcV+0/0AUCIEUZpXlwc8Cp JZXj0StGcaC3hHl3g1TxANMS3KRXQEuYgJaU7bkAsqQkESEl1cCouqNdUNc34sb1mdM7f1kx Kx68aCqoYJxmItHtPY3xZkDvkm/TS3nt3XPi3W7Y7bukziF0xjDIcMJM4bknTJYFrexr0j8v VGtY2dm8b8XdKzEtX8z5/32M8tzdXzfx8NP8k7unff9rzcFf0zQpNsf6pzPzNIE752JypHi/ lG+N/a5/O2X36a9KLMUZiYZazEXFiQBnf0GyCAMAAA== Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 17:06:53 -0000 On 03/21/2017 04:16 PM, Henry B (Hank) Hotz, CISSP wrote: > Mildly disagree. > > 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] -> Adding RFC 6860 into the mix just changes the picture to: [disc] -> -> [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 nobody Fri Mar 24 14:05:18 2017 Return-Path: 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 5368A128D2E for ; Fri, 24 Mar 2017 14:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=secure-endpoints.com 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 8BOP5IiXoeVv for ; Fri, 24 Mar 2017 14:05:15 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B772126BF6 for ; Fri, 24 Mar 2017 14:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1490389493; x=1490994293; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:From:Openpgp:Organization:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type; bh=XXknIUXNNcMsVrbKieadrd Z0XnZvtt0w7W5HK8R91NU=; b=NX5PHE4btWC31a08z6Q0jSY7Jq+8KXgdH+GFYS QWYGEte/PDcgPDdVrGjUOc4ORKQ2FneqhgcEylcWbBI+paDAH2m7v31gJj/LSWCM RlGkoer57XqhgEMXWk43kIJ456Y6UTwMEQhKjayfFcjh2D4KCZQZtQU+vaQ7HcIE BPzrE= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Fri, 24 Mar 2017 17:04:53 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Fri, 24 Mar 2017 17:04:52 -0400 Received: from [IPv6:2001:470:1f07:f77:71aa:981e:ca22:7768] by secure-endpoints.com (IPv6:2001:470:1f07:f77:28d9:68fb:855d:c2a5) (MDaemon PRO v17.0.0) with ESMTPSA id md50001300793.msg; Fri, 24 Mar 2017 17:04:52 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDRemoteIP: 2001:470:1f07:f77:71aa:981e:ca22:7768 X-MDHelo: [IPv6:2001:470:1f07:f77:71aa:981e:ca22:7768] X-MDArrival-Date: Fri, 24 Mar 2017 17:04:52 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1256a661a1=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org X-CAV-Result: clean To: kitten@ietf.org References: <3FD27BFF-5090-4505-852C-E8766BBAA93B@oxy.edu> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=https://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: <8a72a238-c062-71cd-137a-4273a90762be@secure-endpoints.com> Date: Fri, 24 Mar 2017 17:04:50 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030403010501090606000300" Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 21:05:17 -0000 This is a cryptographically signed message in MIME format. --------------ms030403010501090606000300 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 3/23/2017 1:06 PM, Greg Hudson wrote: > I believe that any DNS discovery protocol for > the implementation-specific admin service should also be considered > implementation-specific. I concur. Jeffrey Altman --------------ms030403010501090606000300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DJswggYCMIIE6qADAgECAhBAAVgjEN7WFoCIXylZ1uvSMA0GCSqGSIb3DQEBCwUAMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy MB4XDTE2MTEwMjAzMjQxOFoXDTE3MTEwMjAzMjQxOFowgZYxNTAzBgNVBAsMLFZlcmlmaWVk IEVtYWlsOiBqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMSswKQYJKoZIhvcNAQkBFhxq YWx0bWFuQHNlY3VyZS1lbmRwb2ludHMuY29tMTAwLgYKCZImiZPyLGQBARMgN0YwMDAwMDEw MDAwMDE1ODIzMTBERUE3MDAwMDA3QjQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDPaPDUdwWkzLcNsJjjlDs5lo4ySDKmCgzQsuDt+VY3wP0IZBbu8f/LM3zWCH7zVRJ/XuY5 qN44jFEXwj5fGY71Esm5pKv5sUpys6Q3c6BKXiHv/IUusI3qTJ46QBEAiHu2lxB75UnIYgm+ ZbKmcAR48Z1Sl/Ku86e9GPuts9R51SeHW1pjq89LAi6C0ERuAUIK0rVZGDmKWtRNs9EykXzk mU2Z1ZLuPL0jIggFPeT8TyH6TH/XvapbC+7rHJrzuBY4NDqLgqDJUf0JidL9JeK9+IxxPCab EbVmOf5sBgO5mg92l4+f+Q4xefZcI4C7RPFdRTRWsQs7Z3DpE28BDbjDAgMBAAGjggKlMIIC oTAOBgNVHQ8BAf8EBAMCBaAwgYQGCCsGAQUFBwEBBHgwdjAwBggrBgEFBQcwAYYkaHR0cDov L2NvbW1lcmNpYWwub2NzcC5pZGVudHJ1c3QuY29tMEIGCCsGAQUFBzAChjZodHRwOi8vdmFs aWRhdGlvbi5pZGVudHJ1c3QuY29tL2NlcnRzL3RydXN0aWRjYWExMi5wN2MwHwYDVR0jBBgw FoAUpHPa72k1inXMoBl7CDL4a4nkQuwwCQYDVR0TBAIwADCCASwGA1UdIASCASMwggEfMIIB GwYLYIZIAYb5LwAGCwEwggEKMEoGCCsGAQUFBwIBFj5odHRwczovL3NlY3VyZS5pZGVudHJ1 c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDCBuwYIKwYBBQUHAgIw ga4agatUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgaGFzIGJlZW4gaXNzdWVkIGluIGFjY29y ZGFuY2Ugd2l0aCAKSWRlblRydXN0J3MgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91 bmQgYXQgaHR0cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5 L3RzL2luZGV4Lmh0bWwwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3ZhbGlkYXRpb24uaWRl bnRydXN0LmNvbS9jcmwvdHJ1c3RpZGNhYTEyLmNybDAnBgNVHREEIDAegRxqYWx0bWFuQHNl Y3VyZS1lbmRwb2ludHMuY29tMB0GA1UdDgQWBBSP11Voh/Sg9hmecftn2BV5ZQd9OTAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQELBQADggEBAC9cnqRj+ViE efFsiYNMUC8tZf6PXcWDecOR5Pdv/Vd/O6y10mYyilPrcd0sJux1idTZIOzHAsh36BfBdNSt BFAuBZD66L649U3XqBnh9nbuzmCwNc3tWjOaY/Xe7R90lqrXaW0Dw0U++zwmNyCO2CRgBdrU 8cTqFpOtpe/gCAMhjajrUfb+m8Vcd5R0RVIvdljblqv2t9IXQIHwWSm8E7v302z7yW4o4iPH kegez5vq37ICikQjkkVyAJr0wtirJyQuFzMgpoWVpm0CKBiMwJPki2kiHlNiMHBr2ch4fC+H SjbMg4OzTZJCz1xhKvpyRDOM8JRb2BNSU8JjmrxZgFIwggaRMIIEeaADAgECAhEA+d5Wf8lN DHdw+WAbUtoVOzANBgkqhkiG9w0BAQsFADBKMQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRl blRydXN0MScwJQYDVQQDEx5JZGVuVHJ1c3QgQ29tbWVyY2lhbCBSb290IENBIDEwHhcNMTUw MjE4MjIyNTE5WhcNMjMwMjE4MjIyNTE5WjA6MQswCQYDVQQGEwJVUzESMBAGA1UEChMJSWRl blRydXN0MRcwFQYDVQQDEw5UcnVzdElEIENBIEExMjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBANGRTTzPCic0kq5L6ZrUJWt5LE/n6tbPXPhGt2Egv7plJMoEpvVJJDqGqDYy maAsd8Hn9ZMAuKUEFdlx5PgCkfu7jL5zgiMNnAFVD9PyrsuF+poqmlxhlQ06sFY2hbhQkVVQ 00KCNgUzKcBUIvjv04w+fhNPkwGW5M7Ae5K5OGFGwOoRck9GG6MUVKvTNkBw2/vNMOd29VGV TtR0tjH5PS5yDXss48Yl1P4hDStO2L4wTsW2P37QGD27//XGN8K6amWB6F2XOgff/PmlQjQO ORT95PmLkwwvma5nj0AS0CVp8kv0K2RHV7GonllKpFDMT0CkxMQKwoj+tWEWJTiDKSsCAwEA AaOCAoAwggJ8MIGJBggrBgEFBQcBAQR9MHswMAYIKwYBBQUHMAGGJGh0dHA6Ly9jb21tZXJj aWFsLm9jc3AuaWRlbnRydXN0LmNvbTBHBggrBgEFBQcwAoY7aHR0cDovL3ZhbGlkYXRpb24u aWRlbnRydXN0LmNvbS9yb290cy9jb21tZXJjaWFscm9vdGNhMS5wN2MwHwYDVR0jBBgwFoAU 7UQZwNPwBovupHu+QucmVMiONnYwDwYDVR0TAQH/BAUwAwEB/zCCASAGA1UdIASCARcwggET MIIBDwYEVR0gADCCAQUwggEBBggrBgEFBQcCAjCB9DBFFj5odHRwczovL3NlY3VyZS5pZGVu dHJ1c3QuY29tL2NlcnRpZmljYXRlcy9wb2xpY3kvdHMvaW5kZXguaHRtbDADAgEBGoGqVGhp cyBUcnVzdElEIENlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3VlZCBpbiBhY2NvcmRhbmNlIHdp dGggSWRlblRydXN0J3MgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBQb2xpY3kgZm91bmQgYXQgaHR0 cHM6Ly9zZWN1cmUuaWRlbnRydXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzL2luZGV4 Lmh0bWwwSgYDVR0fBEMwQTA/oD2gO4Y5aHR0cDovL3ZhbGlkYXRpb24uaWRlbnRydXN0LmNv bS9jcmwvY29tbWVyY2lhbHJvb3RjYTEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFKRz2u9pNYp1zKAZewgy+GuJ5ELsMA0G CSqGSIb3DQEBCwUAA4ICAQAN4YKu0vv062MZfg+xMSNUXYKvHwvZIk+6H1pUmivyDI4I6A3w Wzxlr83ZJm0oGIF6PBsbgKJ/fhyyIzb+vAYFJmyI8I/0mGlc+nIQNuV2XY8cypPoVJKgpnzp /7cECXkX8R4NyPtEn8KecbNdGBdEaG4a7AkZ3ujlJofZqYdHxN29tZPdDlZ8fR36/mAFeCEq 0wOtOOc0Eyhs29+9MIZYjyxaPoTS+l8xLcuYX3RWlirRyH6RPfeAi5kySOEhG1quNHe06QIw pigjyFT6v/vRqoIBr7WpDOSt1VzXPVbSj1PcWBgkwyGKHlQUOuSbHbHcjOD8w8wHSDbL+L2h e8hNN54doy1e1wJHKmnfb0uBAeISoxRbJnMMWvgAlH5FVrQWlgajeH/6NbYbBSRxALuEOqEQ epmJM6qz4oD2sxdq4GMN5adAdYEswkY/o0bRKyFXTD3mdqeRXce0jYQbWm7oapqSZBccFvUg YOrB78tB6c1bxIgaQKRShtWR1zMM0JfqUfD9u8Fg7G5SVO0IG/GcxkSvZeRjhYcbTfqF2eAg prpyzLWmdr0mou3bv1Sq4OuBhmTQCnqxAXr4yVTRYHkp5lCvRgeJAme1OTVpVPth/O7HJ7Vu EP9GOr6kCXCXmjB4P3UJ2oU0NqfoQdcSSSt9hliALnExTEjii20B2nSDojGCAxQwggMQAgEB ME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1c3RJ RCBDQSBBMTICEEABWCMQ3tYWgIhfKVnW69IwDQYJYIZIAWUDBAIBBQCgggGXMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MDMyNDIxMDQ1MFowLwYJKoZI hvcNAQkEMSIEINanpOZLtFMFJYNTmdPwPQVeL9kfB1qpeiEdKMsZRU+lMF0GCSsGAQQBgjcQ BDFQME4wOjELMAkGA1UEBhMCVVMxEjAQBgNVBAoTCUlkZW5UcnVzdDEXMBUGA1UEAxMOVHJ1 c3RJRCBDQSBBMTICEEABWCMQ3tYWgIhfKVnW69IwXwYLKoZIhvcNAQkQAgsxUKBOMDoxCzAJ BgNVBAYTAlVTMRIwEAYDVQQKEwlJZGVuVHJ1c3QxFzAVBgNVBAMTDlRydXN0SUQgQ0EgQTEy AhBAAVgjEN7WFoCIXylZ1uvSMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCG SAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEApUesi88QiN7WEvbKU8y0 iPn/y0Qfpr55syrInuBbbmfPiM/DFsPQ0IkLTixFc+fNwI6XWP4OUpoK9JxTdFJHWEnFIjRt EF+/A7fby7iNsGi4nqbF+zQ+zPHicDQY66O4MdLhQ/ADvN+Q7fYUKcITTtJ83b8/UQB7J+iG 5KlsV7TYpIdTFNIv74v2ToR10o0Ou+4eaO5/XmqQBAAo2g6OuEXsK2OKtHtGzN9GNfGe9IiA 95F4tUNSUJpjqd8CeQQPDzZF9Ssk6F0X+HT7LSSOiE6uPoJkxJYfNzd77P5RIE+/ZfnhO86G X6+kvnMuS6Zq/csnFYNYCfx5PBu0ROHyTAAAAAAAAA== --------------ms030403010501090606000300-- From nobody Fri Mar 24 14:23:03 2017 Return-Path: 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 7525D129504 for ; Fri, 24 Mar 2017 14:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 RnNQWHlflaJf for ; Fri, 24 Mar 2017 14:23:00 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DC4212998B for ; Fri, 24 Mar 2017 14:23:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id 341D7EA1A; Fri, 24 Mar 2017 17:22:59 -0400 (EDT) Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njyJfNr5xZoc; Fri, 24 Mar 2017 17:22:58 -0400 (EDT) Received: from [192.168.3.129] (24-205-82-163.dhcp.psdn.ca.charter.com [24.205.82.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 00F6FEA19; Fri, 24 Mar 2017 17:22:57 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: Date: Fri, 24 Mar 2017 14:22:56 -0700 Cc: kitten@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <008F4AF2-95A0-425F-979F-26CC394822E1@oxy.edu> References: <3FD27BFF-5090-4505-852C-E8766BBAA93B@oxy.edu> To: Greg Hudson X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 21:23:01 -0000 > On Mar 23, 2017, at 10:06 AM, Greg Hudson wrote: >=20 > On 03/21/2017 04:16 PM, Henry B (Hank) Hotz, CISSP wrote: >> Mildly disagree.=20 >>=20 >> Mainly because there is RFC 6860. >=20 > I think Hank meant RFC 6880 (KDC Information Model), to answer Jeffrey > Altman's question. Yes. (Copy-by-hand considered dangerous.) > 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: >=20 > [discovery] -> >=20 > Adding RFC 6860 into the mix just changes the picture to: >=20 > [disc] -> -> [info model] >=20 > 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. My opinion hasn=E2=80=99t 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. Personal email. hbhotz@oxy.edu From nobody Tue Mar 28 19:04:04 2017 Return-Path: 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 B8976127337; Tue, 28 Mar 2017 19:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 Szi1JkGThhjc; Tue, 28 Mar 2017 19:03:56 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 267061200F1; Tue, 28 Mar 2017 19:03:56 -0700 (PDT) X-AuditID: 12074422-4d3ff70000002527-8b-58db1609150a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 3D.AA.09511.9061BD85; Tue, 28 Mar 2017 22:03:55 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v2T23r9p009509; Tue, 28 Mar 2017 22:03:53 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v2T23nMa016911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Mar 2017 22:03:52 -0400 Date: Tue, 28 Mar 2017 21:03:49 -0500 From: Benjamin Kaduk To: saag@ietf.org Cc: kitten@ietf.org Message-ID: <20170329020348.GR30306@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJIsWRmVeSWpSXmKPExsUixG6nrsstdjvC4M5sfoujm1exWEzp72Ry YPJYsuQnUwBjFJdNSmpOZllqkb5dAlfGm/d3WAqesFZMnjCBsYHxKUsXIyeHhICJxNyj3cxd jFwcQgJtTBLn+3tYIJyNjBL9U66yQzhXmSS2LGsFa2ERUJW43vSMCcRmE1CRaOi+zAxiiwgI SjzomwRWwywgLLF8zVm2LkYODmEBTYk/2/JBwrxA21ZOOMQCYQtKnJz5BKpcS+LGv5dMIOXM AtISy/9xgIRFBZQlGmY8YJ7AyDcLSccsJB2zEDoWMDKvYpRNya3SzU3MzClOTdYtTk7My0st 0jXVy80s0UtNKd3ECA41F6UdjBP/eR1iFOBgVOLh3ZF3K0KINbGsuDL3EKMkB5OSKG/NAaAQ X1J+SmVGYnFGfFFpTmrxIUYJDmYlEd4VnLcjhHhTEiurUovyYVLSHCxK4rziGo0RQgLpiSWp 2ampBalFMFkZDg4lCV5xUaBGwaLU9NSKtMycEoQ0EwcnyHAeoOGnRECGFxck5hZnpkPkTzHq ctw4fuANkxBLXn5eqpQ4LztIkQBIUUZpHtwcUIqQyN5f84pRHOgtYd48kCoeYHqBm/QKaAkT 0BJxm1sgS0oSEVJSDYwKebFfu4Tzf//bmTe9Y/7+GaeVg3invN94hOX4Soti5ghF5bPCMlti D/F0/xd3rDq23deo1WDnhYwFP24ZX7k3OyZqrtHsXpnly5TC5GtVuxKjL3FLvTwWM03jf9TW oAWzZkuelX/Fv/3Qrre+uueavz+UX1J4PCzuxK20lxKXlvBYM7pnXp2mxFKckWioxVxUnAgA /p9/1ewCAAA= Archived-At: Subject: [kitten] kitten status report for IETF 98 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 02:03:58 -0000 kitten is not meeting in Chicago. Since Seoul, we have been pretty succesful in clearing some backlog; we published three RFCs (8062, 8070, and 8129), and have another draft waiting for shepherd writeup (draft-ietf-kitten-rfc5653bis). We've adopted a new document (draft-ietf-kitten-krb-service-discovery) to document a scheme already deployed by MIT/Red Hat for consolidating KDC discovery into a single URI query. This leaves us in a position to pick up some additional new work; likely candidates include a PAKE preauthentication scheme for Kerberos that can do integrated second factor (no proper password + second factor scheme is standardized yet), and deprecating the triple-DES and RC4 kerberos enctypes. -Ben From nobody Wed Mar 29 11:22:23 2017 Return-Path: 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 C90D6126DDF for ; Wed, 29 Mar 2017 11:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no 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 sT6VjTUDWosz for ; Wed, 29 Mar 2017 11:22:10 -0700 (PDT) Received: from mail-qt0-f174.google.com (mail-qt0-f174.google.com [209.85.216.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5EB1292F4 for ; Wed, 29 Mar 2017 11:22:09 -0700 (PDT) Received: by mail-qt0-f174.google.com with SMTP id x35so20066655qtc.2 for ; Wed, 29 Mar 2017 11:22:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aRVz4uiQUAPvjHD1FvzJEwQ1oZRhbR6kYM+7g9oqg08=; b=e4PEsGhYDqVgaxmUIEwZVL4RK1Gi4zVESI7LSmDLvlAWBjmwBzqzKXifxB9z0sh6Iy EfmTRpcJOSlmHk9cQ/OFkPTfj1WuC38oqADH56I4zqofUbexM3NVFBSvm/eXG4Il/sMf uItfyhbGZFELSF15ro4PCtlADoX5R2g5ffPaHk1/lbBD/ia7AyWBxHobZODTuStN2DRt t3eWMYJsblKblG6OF5OoTdptWoWDudRS1KhQ63Zoqq71fhWdz8DFe9DqU3S1WxKXZEjv UsZGDbVebrnT+ZcOBoMg81zWE1/UAcD/AbKy7aKDiwjRlNrP6pf/UKk9VY4eIvpUCn7N Hspw== X-Gm-Message-State: AFeK/H1+XnbX2G8i2JEwQFTZth7Id2YEPsWjqZX1hMW9mKBcGj1GwAJ7Yj/5iYIo7hoM7SBLoWG7OLUJbKblnPJ1 X-Received: by 10.237.53.143 with SMTP id c15mr1959822qte.49.1490811728853; Wed, 29 Mar 2017 11:22:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.175.181 with HTTP; Wed, 29 Mar 2017 11:21:38 -0700 (PDT) In-Reply-To: <20170329020348.GR30306@kduck.kaduk.org> References: <20170329020348.GR30306@kduck.kaduk.org> From: Matt Rogers Date: Wed, 29 Mar 2017 14:21:38 -0400 Message-ID: To: Benjamin Kaduk Cc: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [kitten] kitten status report for IETF 98 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 18:22:12 -0000 On Tue, Mar 28, 2017 at 10:03 PM, Benjamin Kaduk wrote: > kitten is not meeting in Chicago. > > Since Seoul, we have been pretty succesful in clearing some backlog; > we published three RFCs (8062, 8070, and 8129), and have another > draft waiting for shepherd writeup (draft-ietf-kitten-rfc5653bis). > I can pick up the shepherd duties for draft-ietf-kitten-rfc5653bis. Regards, Matt From nobody Thu Mar 30 11:38:03 2017 Return-Path: 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 A16D5129A22 for ; Thu, 30 Mar 2017 11:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 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] 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 Kag5JPJ8PTU1 for ; Thu, 30 Mar 2017 11:38:01 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 2808C129A1A for ; Thu, 30 Mar 2017 11:38:01 -0700 (PDT) X-AuditID: 12074425-abbff70000006f9e-7d-58dd5087fb7f Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 04.25.28574.7805DD85; Thu, 30 Mar 2017 14:37:59 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v2UIbwlX014087 for ; Thu, 30 Mar 2017 14:37:59 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v2UIbtYd009052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 30 Mar 2017 14:37:58 -0400 Date: Thu, 30 Mar 2017 13:37:55 -0500 From: Benjamin Kaduk To: kitten@ietf.org Message-ID: <20170330183754.GL30306@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGIsWRmVeSWpSXmKPExsUixG6notsecDfC4NUCAYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr49GOBYwFDxkrZn9ya2DcyNjFyMkhIWAisef7a6YuRi4OIYE2 JomnxzaxQDjHGSV23ljLAlIlJPCaSWLNES8Qm0VAVeJIyw0mEJtNQEWiofsyM4gtIiAssXvr OyCbg0MYKL7lJTtImBdowYWrZ5ghbEGJkzOfgI1kFtCSuPHvJRNIObOAtMTyfxwgYVEBZYmG GQ+YJzDyzkLSMQtJxyyEjgWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0LfRyM0v0UlNKNzGC g8hFdQfjnL9ehxgFOBiVeHh3CN6NEGJNLCuuzD3EKMnBpCTKW6EOFOJLyk+pzEgszogvKs1J LT7EKMHBrCTC22ENlONNSaysSi3Kh0lJc7AoifOKazRGCAmkJ5akZqemFqQWwWRlODiUJHhj /IEaBYtS01Mr0jJzShDSTBycIMN5gIYfBKnhLS5IzC3OTIfIn2LU5bhx/MAbJiGWvPy8VClx 3id+QEUCIEUZpXlwc0DRL5G9v+YVozjQW8K830BG8QATB9ykV0BLmICWiNvcAllSkoiQkmpg zAif5Xb+1Y+JgSt3/tka3MPr92299WvjvcpNLnKa62P/Txa0Dsqa2bMzqShk8wUuzqa/qq/L b37Ljz3/ZtOLY0wJeREqV3SjrCf0f+zaafpQo/Hax+DPj1SE+yP0rMr+GJvoO8Q4Wnm9NlTq 9ny21G0jn7Pf9Hv8DS2eauK7me5Vh4flbYlSYinOSDTUYi4qTgQAEwg4ENkCAAA= Archived-At: Subject: [kitten] impending draft submissions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 18:38:02 -0000 Hi all, Just a heads-up that I'll be posting some no-change version bumps of a few old WG documents soon. That's just to get them un-expired for convenience when looking at the WG dashboard on the datatracker. -Ben From nobody Thu Mar 30 11:52:13 2017 Return-Path: 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 431DE127698 for ; Thu, 30 Mar 2017 11:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 9VmPzmsXvvH0 for ; Thu, 30 Mar 2017 11:52:09 -0700 (PDT) Received: from mail-qt0-f181.google.com (mail-qt0-f181.google.com [209.85.216.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA8D129A20 for ; Thu, 30 Mar 2017 11:52:08 -0700 (PDT) Received: by mail-qt0-f181.google.com with SMTP id n21so47565955qta.1 for ; Thu, 30 Mar 2017 11:52:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DvOb4DF+ZaQoSVtnPjDA2NlBXnV9ObEzsKYXD9SwBXM=; b=F5KiSDUEEuNXTPrnislbf0NNTqSjas5TPDPidMthiSxloL7uyvIXMehrCu51c8mEJg rVbJ8MyQ/XEquOh+mIiIKIoTb5+KGltf1QPdtdwcFAN50KNWAPLCNvzuDzjGe018ojHV yht9Ne0hx5/dKbsg78E1+T1P0ImvL06GLrF1ocw68sAdx57NZHUJtgjVdj+qBxfwFeon ruhtCdu9m0mLYeHwhUzwcWaA6LqHbnfuVmCHeQBCHMHqVFchJPwdkFxTYIVsueEI7L3a H4xD8bPQIPuz6zRs1z9h2BzHJiKofcX0WdkjYv7SWZpAfYS0QR9CWWWHd8bDFg5EpLO9 Ho/w== X-Gm-Message-State: AFeK/H2RT4wx+lfgbDI2xQgZpzT7k2MvhGPCv0rbJmhxwft7cWu/VWUabwfsf+FNQpqi2QcFIcIIWnopA8kuUqli X-Received: by 10.200.39.97 with SMTP id h30mr1317325qth.18.1490899927077; Thu, 30 Mar 2017 11:52:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.175.181 with HTTP; Thu, 30 Mar 2017 11:51:36 -0700 (PDT) In-Reply-To: References: From: Matt Rogers Date: Thu, 30 Mar 2017 14:51:36 -0400 Message-ID: To: Greg Hudson Cc: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 18:52:12 -0000 On Tue, Mar 21, 2017 at 11:54 AM, Greg Hudson wrote: > 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. > 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. > * 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. > I'll make this 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. I think "formally specify" would be better. > > * 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. > Works for me. > Section 4.4 (Residual): > > * 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 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.) How about "..client MUST query the following URI DNS record, where REALM is a domain-style realm name." > > 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. > I'm OK with removing this part. > 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. > 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." > 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? > 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 From nobody Thu Mar 30 11:56:25 2017 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0621289B0; Thu, 30 Mar 2017 11:56:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149090018429.15436.3384793440991744607@ietfa.amsl.com> Date: Thu, 30 Mar 2017 11:56:24 -0700 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-channel-bound-flag-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 18:56:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation of the IETF. Title : Channel Binding Signalling for the Generic Security Services Application Programming Interface Author : Nicolas Williams Filename : draft-ietf-kitten-channel-bound-flag-01.txt Pages : 10 Date : 2017-03-30 Abstract: Channel binding is a technique that allows applications to use a secure channel at a lower layer without having to use authentication at that lower layer. The concept of channel binding comes from the Generic Security Services Application Programming Interface (GSS- API). It turns out that the semantics commonly implemented are different that those specified in the base GSS-API RFC (RFC2743), and that that specification has a serious bug. This document addresses both, the inconsistency as-implemented and the specification bug. This Internet-Draft proposes the addition of a "channel bound" return flag for the GSS_Init_sec_context() and GSS_Accept_sec_context() functions. Two behaviors are specified: a default, safe behavior reflecting existing implementation deployments, and a behavior that is only safe when the application specifically tells the GSS-API that it (the application) supports the new behavior. Additional API elements related to this are also added, including a new security context establishment API. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-channel-bound-flag/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-channel-bound-flag-01 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-channel-bound-flag-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-channel-bound-flag-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 30 11:58:22 2017 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C1C129A23; Thu, 30 Mar 2017 11:58:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149090030035.15599.903358505409249548@ietfa.amsl.com> Date: Thu, 30 Mar 2017 11:58:20 -0700 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-gssapi-extensions-iana-11.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 18:58:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation of the IETF. Title : Namespace Considerations and Registries for GSS-API Extensions Authors : Nicolas Williams Alexey Melnikov Filename : draft-ietf-kitten-gssapi-extensions-iana-11.txt Pages : 13 Date : 2017-03-30 Abstract: This document describes the ways in which the GSS-API may be extended and directs the creation of an IANA registry for various GSS-API namespaces. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-gssapi-extensions-iana/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-gssapi-extensions-iana-11 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-gssapi-extensions-iana-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-gssapi-extensions-iana-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 30 12:03:51 2017 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C235129A48; Thu, 30 Mar 2017 12:03:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149090061312.15466.7831290520857588741@ietfa.amsl.com> Date: Thu, 30 Mar 2017 12:03:33 -0700 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-pkinit-alg-agility-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 19:03:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation of the IETF. Title : PKINIT Algorithm Agility Authors : Love Hornquist Astrand Larry Zhu Margaret Wasserman Benjamin Kaduk Filename : draft-ietf-kitten-pkinit-alg-agility-01.txt Pages : 18 Date : 2017-03-30 Abstract: This document updates PKINIT, as defined in RFC 4556, to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable. These changes provide preemptive protection against vulnerabilities discovered in the future against any specific cryptographic algorithm, and allow incremental deployment of newer algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-alg-agility/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-pkinit-alg-agility-01 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-pkinit-alg-agility-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-alg-agility-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 30 12:16:10 2017 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8771293FC; Thu, 30 Mar 2017 12:16:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149090136320.15527.8612534804221555267@ietfa.amsl.com> Date: Thu, 30 Mar 2017 12:16:03 -0700 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-iakerb-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 19:16:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation of the IETF. Title : Initial and Pass Through Authentication Using Kerberos V5 and the GSS- API (IAKERB) Authors : Benjamin Kaduk Jim Schaad Larry Zhu Jeffery Altman Filename : draft-ietf-kitten-iakerb-03.txt Pages : 13 Date : 2017-03-30 Abstract: This document defines extensions to the Kerberos protocol and the GSS-API Kerberos mechanism that enable a GSS-API Kerberos client to exchange messages with the KDC by using the GSS-API acceptor as a proxy, encapsulating the Kerberos messages inside GSS-API tokens. With these extensions a client can obtain Kerberos tickets for services where the KDC is not accessible to the client, but is accessible to the application server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-iakerb/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-iakerb-03 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-iakerb-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-iakerb-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 30 13:16:38 2017 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C91D129469; Thu, 30 Mar 2017 13:16:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149090499714.8927.3296620885922090779@ietfa.amsl.com> Date: Thu, 30 Mar 2017 13:16:37 -0700 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-kerberos-iana-registries-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 20:16:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation of the IETF. Title : Move Kerberos protocol parameter registries to IANA Author : Tom Yu Filename : draft-ietf-kitten-kerberos-iana-registries-04.txt Pages : 9 Date : 2017-03-30 Abstract: The Keberos 5 network authentication protocol has several numeric protocol parameters. Most of these parameters are not currently under IANA maintenance. This document requests that IANA take over the maintenance of the remainder of these Kerberos parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-kerberos-iana-registries/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-kerberos-iana-registries-04 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-kerberos-iana-registries-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-kerberos-iana-registries-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/