From nobody Mon May 16 07:48:50 2016 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 8A73C12D18C; Mon, 16 May 2016 07:48:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160516144847.16796.56722.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2016 07:48:47 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-krb-auth-indicator-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 14:48:47 -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 : Authentication Indicator in Kerberos Tickets Authors : Anupam Jain Nathan Kinder Nathaniel McCallum Filename : draft-ietf-kitten-krb-auth-indicator-01.txt Pages : 5 Date : 2016-05-16 Abstract: This document proposes an extension in the Kerberos protocol [RFC4120]. 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 the service tickets so that the application services can use it as an input into policy decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-auth-indicator/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-krb-auth-indicator-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-krb-auth-indicator-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 Mon May 16 09:17:10 2016 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 726A612D584; Mon, 16 May 2016 09:17:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160516161709.16705.29515.idtracker@ietfa.amsl.com> Date: Mon, 16 May 2016 09:17:09 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-krb-auth-indicator-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 16:17:09 -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 : Authentication Indicator in Kerberos Tickets Authors : Anupam Jain Nathan Kinder Nathaniel McCallum Filename : draft-ietf-kitten-krb-auth-indicator-02.txt Pages : 5 Date : 2016-05-16 Abstract: This document specifies an extension in the Kerberos protocol [RFC4120]. 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 the service tickets so that application services can use it as an input into policy decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-auth-indicator/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-krb-auth-indicator-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-krb-auth-indicator-02 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 Mon May 16 09:41:25 2016 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 C572012D1DB for ; Mon, 16 May 2016 09:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 SDMkMQqAaED4 for ; Mon, 16 May 2016 09:41:21 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAFA112D102 for ; Mon, 16 May 2016 09:41:20 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6F11A6331B for ; Mon, 16 May 2016 16:41:20 +0000 (UTC) Received: from vpn-56-169.rdu2.redhat.com (vpn-56-169.rdu2.redhat.com [10.10.56.169]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4GGfJnW030904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 16 May 2016 12:41:20 -0400 Message-ID: <1463416879.2542.15.camel@redhat.com> From: Nathaniel McCallum To: kitten@ietf.org Date: Mon, 16 May 2016 12:41:19 -0400 In-Reply-To: <20160516161709.16705.29515.idtracker@ietfa.amsl.com> References: <20160516161709.16705.29515.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 16 May 2016 16:41:20 +0000 (UTC) Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-krb-auth-indicator-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 16:41:24 -0000 With this revision, I believe that we are in the home stretch on this draft. Unless anyone has any objections, I'd like to request that the chairs begin WGLC. On Mon, 2016-05-16 at 09:17 -0700, internet-drafts@ietf.org wrote: > 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           : Authentication Indicator in Kerberos > Tickets >         Authors         : Anupam Jain >                           Nathan Kinder >                           Nathaniel McCallum > Filename        : draft-ietf-kitten-krb-auth-indicator-02.txt > Pages           : 5 > Date            : 2016-05-16 > > Abstract: >    This document specifies an extension in the Kerberos protocol >    [RFC4120].  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 the service tickets so that application services >    can use it as an input into policy decisions. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-auth-indicator > / > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-kitten-krb-auth-indicator-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-krb-auth-indicato > r-02 > > > 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/ > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Tue May 17 08:49:27 2016 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 7006B12D9EB for ; Tue, 17 May 2016 08:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 hF4Bac-c8jfm for ; Tue, 17 May 2016 08:49:25 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E0412D9EA for ; Tue, 17 May 2016 08:49:24 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 89C99CD65D for ; Tue, 17 May 2016 15:49:24 +0000 (UTC) Received: from vpn-55-135.rdu2.redhat.com (vpn-55-135.rdu2.redhat.com [10.10.55.135]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4HFnNUW027317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 17 May 2016 11:49:24 -0400 Message-ID: <1463500163.2432.9.camel@redhat.com> From: Nathaniel McCallum To: kitten@ietf.org Date: Tue, 17 May 2016 11:49:23 -0400 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 17 May 2016 15:49:24 +0000 (UTC) Archived-At: Subject: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 15:49:26 -0000 https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery -02 I'd like to propose adoption of this draft: 1. It is in the scope of the WG. This is an extension to the discovery methods already defined in RFC 4120. 2. It is beneficial. It provides both speed improvments and additional functionality (discovery of MS-KKDCP proxies). 3. It is small. It avoids defining new: DNS names, DNS semantics, URIs, or transport semantics. It simply combines the existing tools in a fairly obvious way. Thoughts? From nobody Tue May 17 09:25:41 2016 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 D699412D707 for ; Tue, 17 May 2016 09:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" 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 KoxzLiZ8rlj7 for ; Tue, 17 May 2016 09:25:38 -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 1C35B12D6FC for ; Tue, 17 May 2016 09:25:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1463502315; x=1464107115; 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=pltK8rt4hNfGd4msidAWgn rX9Osoe6ueU+lb9sCRgaI=; b=a6NFE3+ZaRClxTP01fTwmo2SCkeRuokp3sOFH0 p7il53i7PGGz15p0OeDC3dKBJWX4+6E3h/rBrClPO33d4T78ePW9u42JEfs7dGAY M4lvMaT8Mn8Z9NrSDeSOoLLrGb+AfST7uMTDb6QYt1OWBVFqlKjKxVsVXcFJntq2 5gWJ0= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Tue, 17 May 2016 12:25:15 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Tue, 17 May 2016 12:25:15 -0400 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v16.0.2) with ESMTPSA id md50001089424.msg for ; Tue, 17 May 2016 12:25:14 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDRemoteIP: 208.125.0.246 X-MDArrival-Date: Tue, 17 May 2016 12:25:14 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1945b5244a=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org To: kitten@ietf.org References: <1463500163.2432.9.camel@redhat.com> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> Date: Tue, 17 May 2016 12:25:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <1463500163.2432.9.camel@redhat.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030508040400040104020901" Archived-At: Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 16:25:40 -0000 This is a cryptographically signed message in MIME format. --------------ms030508040400040104020901 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/17/2016 11:49 AM, Nathaniel McCallum wrote: > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery= > -02 >=20 > I'd like to propose adoption of this draft: >=20 > 1. It is in the scope of the WG. This is an extension to the discovery > methods already defined in RFC 4120. >=20 > 2. It is beneficial. It provides both speed improvments and additional > functionality (discovery of MS-KKDCP proxies). >=20 > 3. It is small. It avoids defining new: DNS names, DNS semantics, URIs,= > or transport semantics. It simply combines the existing tools in a > fairly obvious way. >=20 > Thoughts? >=20 Having read the draft I am totally unclear how it is implemented. _kerberos.REALM is not a valid DNS URI record name. To translate the URI https://host[:port][path] to an URI record requires _kerberos._https.host not _kerberos.host DNS URI records according to RFC 7553 work just like DNS SRV records in that they require both a service name and a protocol name. Switching to URI records does not solve the problem of multiple DNS queries. To find a KDC that supports https, use the DNS SRV record _kerberos._https.REALM registering additional service types such as "kpasswd" can be done but the fact is implementations such as Heimdal already perform SRV lookups f= or _kpasswd,_tcp.REALM and _kpasswd._udp.REALM Can you make a case for something that DNS URI records provides that DNS SRV records do not? The introduction of DNS URI records will only mean that in practice that Kerberos client libraries will need to issue the DNS URI queries in addition to the existing DNS SRV records. Jeffrey Altman --------------ms030508040400040104020901 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 DFkwggYVMIIE/aADAgECAhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBCwUAMIGmMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5 bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3 MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH NTAeFw0xNTEyMjAwMDAwMDBaFw0xNjEyMjAyMzU5NTlaMIGvMS4wLAYDVQQDDCVQZXJzb25h IE5vdCBWYWxpZGF0ZWQgLSAxNDUwNTc0MTU1Njc5MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFu QHNlY3VyZS1lbmRwb2ludHMuY29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNv bmEgTm90IFZhbGlkYXRlZDEfMB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM0X8uixbo9Tu+sKS20bZeCbN9brFQbtkQ5x /6MrkGsQNTzQ/2WZFJzH89ZoC8auZRFQdA6/yh4wXdCNQ6hBO8Lom26t0LHGhoWtzdkP7MWu YeLMZiuOsC6N6ejHEbtt0KLjphNIUvBVFx5JQzgAwJ1I08LSZg/bIGAVF3SfLOVFu2Iiq5kj psHOv/ECV13fGSvYwBXJN1C1To6wxDgn4pl3m6fFfe4xiVEpc3t6GbKcI+4blK9w76fDaVXw U2uJQAG1UYxbChwocBmb3ka1MlUb2ug3oYBpnufD9zk8u3UqaFlfYyr6/2cr6fqiz1U4+xcb Q3otvVWwzRecpmPEiIcCAwEAAaOCAjIwggIuMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQD AgWgMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU2Pc1OxE6 W8hcBZ5L2346cucbFa8wJwYDVR0RBCAwHoEcamFsdG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNv bTBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20v cnBhMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzU3 ZGU3YTIzOGQ0NWQ4ZDRmYzcxZjhhNWM2YjgxYzkzL0xhdGVzdENSTC5jcmwwTgYIKwYBBQUH AQEEQjBAMD4GCCsGAQUFBzAChjJodHRwOi8vY2FjZXIuc3ltYXV0aC5jb20vbXBraS9zeW1j YzFpbmRzdWJjYWc1LmNydDAfBgNVHSMEGDAWgBRnGbY9pXm7M2DYLVPTjAk9B6wYcDArBgpg hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGt7pITFgUxMDkyMjA5BgpghkgBhvhFARAF BCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3 DQEBCwUAA4IBAQBvO/+L6Tms91Ed1ZJzgT0y9jBK/Armb6Y/EnR1swCDMqRfBzGSGtzOCuN7 PteBvlaB5vmnwEwiZR/FtsDhhORd8Xy5wdmCunhwPbf0ClnBqichI+4UZNS5fCQTciIqHFxq 7EKuHOQm4/ssEH2Xr8yIpCd+Dx9oPEG7MqUno6oxcIDdur4iNKxOBtjWNiXM7rn733qtuFlw 1jIX3eFIsrBALikTU1UbY2KwfewXbiVaFWY0ysl5uOgfWdmj2xBk7aft/L/fnuyWyeeM9IBg 6vdUjPhmJwtFdEdefgP5cRRdYgG8zgJf8Rq84slkea0bwis8PvKVksJ/k2scaDHzKTe2MIIG PDCCBSSgAwIBAgIQBwKiGoW4S2WeGApu5vWjZTANBgkqhkiG9w0BAQsFADCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMTUxMDAxMDAwMDAwWhcNMjUw OTMwMjM1OTU5WjCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0 aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW+w0x SSLADLrvTi0XuLQw5TTSrAnuyYkAXfSuExGzE45VzyIYqCAGpv0ly2iUtKCCkA5ulpJE7hW5 tOz6z3k9adScH9wgmg4o1Q21xp468dRlGcCEM02O2orx1ie5A6DR+iicgpNs9w2FfVvpTpli /pNC0u4+s3FXhpdGy98N4caEWrMNj/X0EIoFXZ9oRuwIsFhCgva+LRBGpiQLJ/6YFFODk4Lb 6sA/T6JYYbVLcmkSXzNZ9vmzTABkzoXFhpIMbhzrKM9xqZCpdJl0JOtI4Q5daBKoAWbo7pqy L/g9zbd4JM6lYHzoFj1J8Qe6M74yK8JnoxbHb8DSWpQEwmtFAgMBAAGjggI+MIICOjA3Bggr BgEFBQcBAQQrMCkwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTAS BgNVHRMBAf8ECDAGAQH/AgEAMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEF BQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDov L3d3dy5zeW1hdXRoLmNvbS9ycGEwLwYDVR0fBCgwJjAkoCKgIIYeaHR0cDovL3Muc3ltY2Iu Y29tL3BjYTEtZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRU3ltYW50ZWNQS0ktMi0yMTcwHQYDVR0OBBYEFGcZtj2lebszYNgtU9OMCT0HrBhwMIHx BgNVHSMEgekwgeahgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5 OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQsFAAOCAQEARhnkJ3U7vq/i 2qIUYI8eRJCBaStjSTWN6Xa6n5iPE4HXy/xlG/gOY96UKHT742/YySp6DlSmg64pSvYrUf09 OBK73WNF+2TMPlSGf05CbSO3HQv9+swNjpM1yuVF+c8vf3k9YxjHRyNK9qkUAK1+WVUaiSfb lKCROMb+QJWjYPZduMjFFu2cZmkURhBKynAqb9FQ4CYa01K0R3KLRdK9A7ml3NkI85CrdHCr yqBO8MBO5OC+T5ARYCcMKxzf52zKdbQl55FIqpK0UXVfKZtHFxy9yerPda11I8/yxd9aq7dr yru4XqvVo3DUaPMXepsLoBQ8++iBVmjoz118c7guvDGCBGIwggReAgEBMIG7MIGmMQswCQYD VQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNQIQ cBGDX/fzAS3ijWWeve3D7zANBglghkgBZQMEAgEFAKCCAncwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNTE3MTYyNTEwWjAvBgkqhkiG9w0BCQQxIgQg IOpK3IrMLIhB5Ld6rZqykTvfNfeoZi2TbvdJjLkQsS0wbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7 MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHNQIQcBGDX/fzAS3ijWWeve3D7zCBzgYLKoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3lt YW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1 AhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBAQUABIIBACAWS7NGWdR0OzFOefD53JDq 3spHLFqNzdj93h/084Fr56BI6BzOH3rBXUJ9BSf5vlWkFsxM3HNWMya0ZN9pUCebRq1H956D WofPYgdGvnND9cBF7mjF2Nt+qpECWvsDLl6y45S+xGH/pHIiFGO6J53rhHr3Vu9ArZSjXVny BZqlWHIP430LQ7APghdqFKkUNCOxcXAA0mP1sjp9IozNEV+6FXJnb9Stz9hH9vCxpWCeGx7W C1F0j6B6EnD+MSY1elIDE2a0KlNssCfukTdgP6K5JZ08ExJIGMn3yhf69xtA0kibU6glCbeb nEmND6qyCz3M9nI9DmIbZ1FiLoBIWXoAAAAAAAA= --------------ms030508040400040104020901-- From nobody Tue May 17 13:26:31 2016 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 2EB0812D9C0 for ; Tue, 17 May 2016 13:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 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, 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 F9MQYD8wTZnl for ; Tue, 17 May 2016 13:26:28 -0700 (PDT) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C1812D9C2 for ; Tue, 17 May 2016 13:26:27 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id vYSQ1s00N10HQrX01YSRd8; Tue, 17 May 2016 22:26:25 +0200 Message-ID: <573B7E6E.1010900@openfortress.nl> Date: Tue, 17 May 2016 22:26:22 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Jeffrey Altman , Nathaniel McCallum References: <1463500163.2432.9.camel@redhat.com> <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> In-Reply-To: <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 20:26:30 -0000 Hi, I agree mostly with Jeffrey, but have some additional remarks / thoughts. > _kerberos.REALM > > is not a valid DNS URI record name. To translate the URI > Yes, the RFC wants it to be of the form _server._transport, however > https://host[:port][path] > > to an URI record requires > > _kerberos._https.host where is _https defined as a transport? RFC 7553 gives examples with _http._tcp -- I've always wondered to deal with _https and especially how to add semantics on top of it, so I certainly like the scheme, but is this format defined anywhere? For SRV, I though transports were limited to TCP, UDP, SCTP -- so not even TLS, let alone HTTPS? Nathaniel, I think what you are actually trying to do is to describe HTTPS as a tunneling technique, right? Since this type of tunnel is designed to participate in the rope-pulling contest between application desires and (perhaps misguided) firewall configurations, it might be expected that new tunnels would be topped on as time passes. Clients would need to keep up, but keep the older solutions working as well. So instead, I would rather have some sort of a redirection to a somewhat general tunnel descriptor as a general discovery outcome when looking for a "direct" service description. This would service many applications in the same manner. > registering additional service types such as "kpasswd" can be done but > the fact is implementations such as Heimdal already perform SRV > lookups for > > _kpasswd,_tcp.REALM and _kpasswd._udp.REALM > > Can you make a case for something that DNS URI records provides that DNS > SRV records do not? > It should outweigh having to do both forever and ever, indeed. And needing to add even more when other tunneling techniques arrive. I hope this helps! Cheers, -Rick From nobody Tue May 17 13:43:26 2016 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 77A9712DDDA for ; Tue, 17 May 2016 13:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 P-YTWCYlgxmA for ; Tue, 17 May 2016 13:43:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB49C12DDDD for ; Tue, 17 May 2016 13:43:22 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 44F717F6B0; Tue, 17 May 2016 20:43:22 +0000 (UTC) Received: from vpn-55-135.rdu2.redhat.com (vpn-55-135.rdu2.redhat.com [10.10.55.135]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4HKhL3i026952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 May 2016 16:43:21 -0400 Message-ID: <1463517801.2432.24.camel@redhat.com> From: Nathaniel McCallum To: Jeffrey Altman , kitten@ietf.org Date: Tue, 17 May 2016 16:43:21 -0400 In-Reply-To: <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> References: <1463500163.2432.9.camel@redhat.com> <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 17 May 2016 20:43:22 +0000 (UTC) Archived-At: Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 20:43:24 -0000 On Tue, 2016-05-17 at 12:25 -0400, Jeffrey Altman wrote: > On 5/17/2016 11:49 AM, Nathaniel McCallum wrote: > > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-disco > > very > > -02 > > > > I'd like to propose adoption of this draft: > > > > 1. It is in the scope of the WG. This is an extension to the > > discovery > > methods already defined in RFC 4120. > > > > 2. It is beneficial. It provides both speed improvments and > > additional > > functionality (discovery of MS-KKDCP proxies). > > > > 3. It is small. It avoids defining new: DNS names, DNS semantics, > > URIs, > > or transport semantics. It simply combines the existing tools in a > > fairly obvious way. > > > > Thoughts? > > > > Having read the draft I am totally unclear how it is implemented. > >   _kerberos.REALM > > is not a valid DNS URI record name.  To translate the URI > >   https://host[:port][path] > > to an URI record requires > >  _kerberos._https.host > > not > >  _kerberos.host It doesn't actually require this. It just gives examples. > DNS URI records according to RFC 7553 work just like DNS SRV records > in > that they require both a service name and a protocol name.  Switching > to > URI records does not solve the problem of multiple DNS queries. > > To find a KDC that supports https, use the DNS SRV record > >   _kerberos._https.REALM _https isn't a thing. You'd have to do something like: _http._tls._tcp. > registering additional service types such as "kpasswd" can be done > but > the fact is implementations such as Heimdal already perform SRV > lookups for > >  _kpasswd,_tcp.REALM and _kpasswd._udp.REALM At the cost of one DNS query per transport. Further, administrators have no control over the weights or priorties between transports. My draft provides this. > Can you make a case for something that DNS URI records provides that > DNS > SRV records do not? Yes. MS-KKDCP requires a path. SRV records cannot provide a path. > The introduction of DNS URI records will only mean that in practice > that > Kerberos client libraries will need to issue the DNS URI queries in > addition to the existing DNS SRV records. We will need to add at least one more DNS query to support MS-KKDCP (two if we have to treat http and https as separate queries). This is unavoidable. While it is true that this will result in a 50% increase in DNS queries, using my URI scheme means that a simple administrator configuration can turn this 50% increase into a 50% decrease in queries over the existing implementations. This is a win. From nobody Tue May 17 13:53:31 2016 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 D738112D5D2 for ; Tue, 17 May 2016 13:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 VbfZnApchAae for ; Tue, 17 May 2016 13:53:24 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E999312DA16 for ; Tue, 17 May 2016 13:53:23 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6094663305; Tue, 17 May 2016 20:53:23 +0000 (UTC) Received: from vpn-55-135.rdu2.redhat.com (vpn-55-135.rdu2.redhat.com [10.10.55.135]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4HKrJIU001137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 May 2016 16:53:22 -0400 Message-ID: <1463518399.2432.33.camel@redhat.com> From: Nathaniel McCallum To: Rick van Rein , Jeffrey Altman Date: Tue, 17 May 2016 16:53:19 -0400 In-Reply-To: <573B7E6E.1010900@openfortress.nl> References: <1463500163.2432.9.camel@redhat.com> <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> <573B7E6E.1010900@openfortress.nl> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 17 May 2016 20:53:23 +0000 (UTC) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 20:53:30 -0000 On Tue, 2016-05-17 at 22:26 +0200, Rick van Rein wrote: > Hi, > > I agree mostly with Jeffrey, but have some additional remarks / > thoughts. > > > _kerberos.REALM > > > > is not a valid DNS URI record name. To translate the URI > > > Yes, the RFC wants it to be of the form _server._transport, however > > > https://host[:port][path] > > > > to an URI record requires > > > > _kerberos._https.host > > where is _https defined as a transport?  RFC 7553 gives examples with > _http._tcp -- I've always wondered to deal with _https and especially > how to add semantics on top of it, so I certainly like the scheme, > but > is this format defined anywhere?  For SRV, I though transports were > limited to TCP, UDP, SCTP -- so not even TLS, let alone HTTPS? > > Nathaniel, I think what you are actually trying to do is to describe > HTTPS as a tunneling technique, right?  Since this type of tunnel is > designed to participate in the rope-pulling contest between > application > desires and (perhaps misguided) firewall configurations, it might be > expected that new tunnels would be topped on as time passes. Yes, this is possible: new tunnels may appear over time. > Clients > would need to keep up, but keep the older solutions working as > well.  So > instead, I would rather have some sort of a redirection to a somewhat > general tunnel descriptor as a general discovery outcome when looking > for a "direct" service description.  This would service many > applications in the same manner. How does the "general tunnel descriptor" help in the case of Kerberos tunnelling where the tunnel protocols are Kerberos-specific? The desire for abstraction here just adds complexity without any benefit of reusability. OTOH, new Kerberos tunnelling protocols can just get new URIs. In fact, this is already explicitly allowable in the existing draft. So the system, as defined is perfectly flexible to new situations in the future. One advantage to the URI approach is that weights and priorities can be used to appropriately transition between transports; something that is not currently possible. From nobody Tue May 17 14:09:04 2016 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 3CB8612D615 for ; Tue, 17 May 2016 14:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" 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 1RJT-3RqONbX for ; Tue, 17 May 2016 14:09:02 -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 C9B3E12D1DF for ; Tue, 17 May 2016 14:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1463519319; x=1464124119; 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=rV5RtfKaSRER1sbm8TJ2F5 xF1LqP7lEyRyAtVFHx+bA=; b=dnFx9seqAuu9nsk2pAItwsrorOGhym7sqRM1ZJ nrOWbLI4m5VT/fI37ydx6Wdh4Upfl1XGw/QkGaqabsEBBb4+8JYjChhlFo3ar7qI xSI+5EygJ9GUwrZXIWcuqgLDv8d+gtvuOSjYfUdmeq1SIykF18XKELY+IGvjo9ju L2C9w= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Tue, 17 May 2016 17:08:39 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Tue, 17 May 2016 17:08:39 -0400 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v16.0.2) with ESMTPSA id md50001089594.msg for ; Tue, 17 May 2016 17:08:39 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDArrival-Date: Tue, 17 May 2016 17:08:39 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1945b5244a=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org To: Nathaniel McCallum , kitten@ietf.org References: <1463500163.2432.9.camel@redhat.com> <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> <1463517801.2432.24.camel@redhat.com> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: <490bd7aa-81ca-9199-6687-222bb65caddf@secure-endpoints.com> Date: Tue, 17 May 2016 17:08:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <1463517801.2432.24.camel@redhat.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070801070004010306000700" Archived-At: Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 21:09:03 -0000 This is a cryptographically signed message in MIME format. --------------ms070801070004010306000700 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/17/2016 4:43 PM, Nathaniel McCallum wrote: > We will need to add at least one more DNS query to support MS-KKDCP > (two if we have to treat http and https as separate queries). This is > unavoidable. While it is true that this will result in a 50% increase > in DNS queries, using my URI scheme means that a simple administrator > configuration can turn this 50% increase into a 50% decrease in queries= > over the existing implementations. This is a win. As an implementer I can tell you that it would be more than a decade before I would ever be able to remove existing lookup methods and possibly even longer than that. As a deployer of a realm I can tell you that I have no control over updates of Kerberos libraries in the clients. Clients are deployed long after the 10 year lifetimes of the operating systems and new features such as this are not backported into prior OS distributions. As such I would be unable to rely upon URI as a replacement for SRV for more than 10 years. I would be required to publish both URI and and SRV lookup records forever. You have described a reason why URI lookups are necessary for MS-KKDCP. Please restrict your draft to that case. Sincerely, Jeffrey Altman --------------ms070801070004010306000700 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 DFkwggYVMIIE/aADAgECAhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBCwUAMIGmMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5 bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3 MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH NTAeFw0xNTEyMjAwMDAwMDBaFw0xNjEyMjAyMzU5NTlaMIGvMS4wLAYDVQQDDCVQZXJzb25h IE5vdCBWYWxpZGF0ZWQgLSAxNDUwNTc0MTU1Njc5MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFu QHNlY3VyZS1lbmRwb2ludHMuY29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNv bmEgTm90IFZhbGlkYXRlZDEfMB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM0X8uixbo9Tu+sKS20bZeCbN9brFQbtkQ5x /6MrkGsQNTzQ/2WZFJzH89ZoC8auZRFQdA6/yh4wXdCNQ6hBO8Lom26t0LHGhoWtzdkP7MWu YeLMZiuOsC6N6ejHEbtt0KLjphNIUvBVFx5JQzgAwJ1I08LSZg/bIGAVF3SfLOVFu2Iiq5kj psHOv/ECV13fGSvYwBXJN1C1To6wxDgn4pl3m6fFfe4xiVEpc3t6GbKcI+4blK9w76fDaVXw U2uJQAG1UYxbChwocBmb3ka1MlUb2ug3oYBpnufD9zk8u3UqaFlfYyr6/2cr6fqiz1U4+xcb Q3otvVWwzRecpmPEiIcCAwEAAaOCAjIwggIuMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQD AgWgMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU2Pc1OxE6 W8hcBZ5L2346cucbFa8wJwYDVR0RBCAwHoEcamFsdG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNv bTBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20v cnBhMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzU3 ZGU3YTIzOGQ0NWQ4ZDRmYzcxZjhhNWM2YjgxYzkzL0xhdGVzdENSTC5jcmwwTgYIKwYBBQUH AQEEQjBAMD4GCCsGAQUFBzAChjJodHRwOi8vY2FjZXIuc3ltYXV0aC5jb20vbXBraS9zeW1j YzFpbmRzdWJjYWc1LmNydDAfBgNVHSMEGDAWgBRnGbY9pXm7M2DYLVPTjAk9B6wYcDArBgpg hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGt7pITFgUxMDkyMjA5BgpghkgBhvhFARAF BCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3 DQEBCwUAA4IBAQBvO/+L6Tms91Ed1ZJzgT0y9jBK/Armb6Y/EnR1swCDMqRfBzGSGtzOCuN7 PteBvlaB5vmnwEwiZR/FtsDhhORd8Xy5wdmCunhwPbf0ClnBqichI+4UZNS5fCQTciIqHFxq 7EKuHOQm4/ssEH2Xr8yIpCd+Dx9oPEG7MqUno6oxcIDdur4iNKxOBtjWNiXM7rn733qtuFlw 1jIX3eFIsrBALikTU1UbY2KwfewXbiVaFWY0ysl5uOgfWdmj2xBk7aft/L/fnuyWyeeM9IBg 6vdUjPhmJwtFdEdefgP5cRRdYgG8zgJf8Rq84slkea0bwis8PvKVksJ/k2scaDHzKTe2MIIG PDCCBSSgAwIBAgIQBwKiGoW4S2WeGApu5vWjZTANBgkqhkiG9w0BAQsFADCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMTUxMDAxMDAwMDAwWhcNMjUw OTMwMjM1OTU5WjCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0 aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW+w0x SSLADLrvTi0XuLQw5TTSrAnuyYkAXfSuExGzE45VzyIYqCAGpv0ly2iUtKCCkA5ulpJE7hW5 tOz6z3k9adScH9wgmg4o1Q21xp468dRlGcCEM02O2orx1ie5A6DR+iicgpNs9w2FfVvpTpli /pNC0u4+s3FXhpdGy98N4caEWrMNj/X0EIoFXZ9oRuwIsFhCgva+LRBGpiQLJ/6YFFODk4Lb 6sA/T6JYYbVLcmkSXzNZ9vmzTABkzoXFhpIMbhzrKM9xqZCpdJl0JOtI4Q5daBKoAWbo7pqy L/g9zbd4JM6lYHzoFj1J8Qe6M74yK8JnoxbHb8DSWpQEwmtFAgMBAAGjggI+MIICOjA3Bggr BgEFBQcBAQQrMCkwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTAS BgNVHRMBAf8ECDAGAQH/AgEAMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEF BQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDov L3d3dy5zeW1hdXRoLmNvbS9ycGEwLwYDVR0fBCgwJjAkoCKgIIYeaHR0cDovL3Muc3ltY2Iu Y29tL3BjYTEtZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRU3ltYW50ZWNQS0ktMi0yMTcwHQYDVR0OBBYEFGcZtj2lebszYNgtU9OMCT0HrBhwMIHx BgNVHSMEgekwgeahgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5 OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQsFAAOCAQEARhnkJ3U7vq/i 2qIUYI8eRJCBaStjSTWN6Xa6n5iPE4HXy/xlG/gOY96UKHT742/YySp6DlSmg64pSvYrUf09 OBK73WNF+2TMPlSGf05CbSO3HQv9+swNjpM1yuVF+c8vf3k9YxjHRyNK9qkUAK1+WVUaiSfb lKCROMb+QJWjYPZduMjFFu2cZmkURhBKynAqb9FQ4CYa01K0R3KLRdK9A7ml3NkI85CrdHCr yqBO8MBO5OC+T5ARYCcMKxzf52zKdbQl55FIqpK0UXVfKZtHFxy9yerPda11I8/yxd9aq7dr yru4XqvVo3DUaPMXepsLoBQ8++iBVmjoz118c7guvDGCBGIwggReAgEBMIG7MIGmMQswCQYD VQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNQIQ cBGDX/fzAS3ijWWeve3D7zANBglghkgBZQMEAgEFAKCCAncwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNTE3MjEwODMyWjAvBgkqhkiG9w0BCQQxIgQg b7Y72TVk1IvT1muYRgv64uGlNdfKPI3Hm4GnLb0lxskwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7 MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHNQIQcBGDX/fzAS3ijWWeve3D7zCBzgYLKoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3lt YW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1 AhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBAQUABIIBAJEvn54UjfRYaFFY+Z5/fkNj ULY+PemnpiR7D3o/W/NDVbL7NxpOv30p6kUnlrfk0NYZVxg1AA+TyaACSr49vRoTvdaa4OT4 AkxK8Ptl565XJfpJ+GkmAH6hW2oFN+/TToe+8JIIGyMkLoeLq99XZZgBrzVM4N0cjJQxZ0FC qeOPxQIlqEaoB8StvlyVeIdE1MRnHCZ/Z5T3VIIvSsUrnmH/AHJ1xhxa2SqkvhLje/3bNb+8 EPm2+/fxfMapgLzbx9DbESkd6X/cInoy+HTxUTlAb+oFYQN3B5GH39C8EHOiysl4DSLhOfDE zo6N1IUdYnqwBDrlT2EVExOv/S75ofQAAAAAAAA= --------------ms070801070004010306000700-- From nobody Tue May 17 14:26:10 2016 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 A83CC12D0BE for ; Tue, 17 May 2016 14:26:06 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 09 hex): References: ...2432.9.camel@redhat.com>\n\t\n <54c900f2-399[...] X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 sMXXPsRUuh09 for ; Tue, 17 May 2016 14:26:01 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C844112DA0F for ; Tue, 17 May 2016 14:26:01 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 89A5781129; Tue, 17 May 2016 21:26:01 +0000 (UTC) Received: from vpn-55-135.rdu2.redhat.com (vpn-55-135.rdu2.redhat.com [10.10.55.135]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4HLQ0v9029025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 17 May 2016 17:26:01 -0400 Message-ID: <1463520360.2432.46.camel@redhat.com> From: Nathaniel McCallum To: Jeffrey Altman , kitten@ietf.org Date: Tue, 17 May 2016 17:26:00 -0400 In-Reply-To: <490bd7aa-81ca-9199-6687-222bb65caddf@secure-endpoints.com> References: <1463500163.2432.9.camel@redhat.com> <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> <1463517801.2432.24.camel@redhat.com> <490bd7aa-81ca-9199-6687-222bb65caddf@secure-endpoints.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Tue, 17 May 2016 21:26:01 +0000 (UTC) Archived-At: Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 21:26:07 -0000 On Tue, 2016-05-17 at 17:08 -0400, Jeffrey Altman wrote: > On 5/17/2016 4:43 PM, Nathaniel McCallum wrote: > > We will need to add at least one more DNS query to support MS-KKDCP > > (two if we have to treat http and https as separate queries). This > > is > > unavoidable. While it is true that this will result in a 50% > > increase > > in DNS queries, using my URI scheme means that a simple > > administrator > > configuration can turn this 50% increase into a 50% decrease in > > queries > > over the existing implementations. This is a win. > > As an implementer I can tell you that it would be more than a decade > before I would ever be able to remove existing lookup methods and > possibly even longer than that. I'm also an implementer. And I can tell you that when you remove the code doesn't matter. All that matters is what happens at runtime. And if we offer admins a way to cut their Kerberos DNS requests in half, they'll take it. > As a deployer of a realm I can tell you that I have no control over > updates of Kerberos libraries in the clients.  Clients are deployed > long > after the 10 year lifetimes of the operating systems and new features > such as this are not backported into prior OS distributions. > As such I would be unable to rely upon URI as a replacement for SRV > for > more than 10 years.  I would be required to publish both URI and and > SRV > lookup records forever. Agreed. But who cares? Clients that support the new method get increased speed and functionality. Clients that don't, get the same behavior they always had. The only cost for this on the DNS-side of the equasion is an additional record -- one which we need anyway. > You have described a reason why URI lookups are necessary for MS- > KKDCP. > Please restrict your draft to that case. I've described a reason why a URI record lookup is requied for MS- KKDCP. However, I've also described a system which presents a 50% reduction in DNS lookups. I don't see any reason to neglect this second feature. From nobody Tue May 17 17:36:36 2016 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 8428412D54A for ; Tue, 17 May 2016 17:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" 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 DklOKlRJ3qhR for ; Tue, 17 May 2016 17:36:33 -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 0F4BA12D543 for ; Tue, 17 May 2016 17:36:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1463531770; x=1464136570; 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=MIICBqaYoRzA6Qv6xvQJVK UFtpx/vXIBbOWQ5TXYsDg=; b=FI8PheDJBpm7MKibCfdRX/HlDpwiJKxaQb5zVJ JHY491brPD004RNdOBvKH4E+Gqb3a08F0/kxZD6ahtJRXVmHBpiehR+ws4Vhv0oD gPu3F0feRd9fQVdyzLd4DDtHk0jxGKINXTzAUu57AQ4wdp3RHXxoGOzP+8AAmEio Akgzo= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Tue, 17 May 2016 20:36:10 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Tue, 17 May 2016 20:36:10 -0400 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v16.0.2) with ESMTPSA id md50001089700.msg for ; Tue, 17 May 2016 20:36:07 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDArrival-Date: Tue, 17 May 2016 20:36:07 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=194665a7e1=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org To: Nathaniel McCallum , kitten@ietf.org References: <1463500163.2432.9.camel@redhat.com> <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> <1463517801.2432.24.camel@redhat.com> <490bd7aa-81ca-9199-6687-222bb65caddf@secure-endpoints.com> <1463520360.2432.46.camel@redhat.com> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: <3911bb56-b9a1-a5e5-cc6c-c742f779536c@secure-endpoints.com> Date: Tue, 17 May 2016 20:36:04 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <1463520360.2432.46.camel@redhat.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090702010905040801050806" Archived-At: Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 00:36:34 -0000 This is a cryptographically signed message in MIME format. --------------ms090702010905040801050806 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/17/2016 5:26 PM, Nathaniel McCallum wrote: > > I've described a reason why a URI record lookup is requied for MS- > KKDCP. However, I've also described a system which presents a 50% > reduction in DNS lookups. I don't see any reason to neglect this second= > feature. And when the DNS URI record is not published or cannot be queried the Kerberos library will have a 50% increase in the number of DNS lookups. Not only does the library have to query for DNS URI but it still must query for the DNS SRV records. I will also point out that a large number of the DNS hosting providers do not support URI records and many of the DNS proxy servers do not support them either. As a result there is no ability for DNS URI records to be published and the queries are will be blocked. Sincerely, Jeffrey Altman --------------ms090702010905040801050806 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 DFkwggYVMIIE/aADAgECAhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBCwUAMIGmMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5 bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3 MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH NTAeFw0xNTEyMjAwMDAwMDBaFw0xNjEyMjAyMzU5NTlaMIGvMS4wLAYDVQQDDCVQZXJzb25h IE5vdCBWYWxpZGF0ZWQgLSAxNDUwNTc0MTU1Njc5MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFu QHNlY3VyZS1lbmRwb2ludHMuY29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNv bmEgTm90IFZhbGlkYXRlZDEfMB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM0X8uixbo9Tu+sKS20bZeCbN9brFQbtkQ5x /6MrkGsQNTzQ/2WZFJzH89ZoC8auZRFQdA6/yh4wXdCNQ6hBO8Lom26t0LHGhoWtzdkP7MWu YeLMZiuOsC6N6ejHEbtt0KLjphNIUvBVFx5JQzgAwJ1I08LSZg/bIGAVF3SfLOVFu2Iiq5kj psHOv/ECV13fGSvYwBXJN1C1To6wxDgn4pl3m6fFfe4xiVEpc3t6GbKcI+4blK9w76fDaVXw U2uJQAG1UYxbChwocBmb3ka1MlUb2ug3oYBpnufD9zk8u3UqaFlfYyr6/2cr6fqiz1U4+xcb Q3otvVWwzRecpmPEiIcCAwEAAaOCAjIwggIuMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQD AgWgMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU2Pc1OxE6 W8hcBZ5L2346cucbFa8wJwYDVR0RBCAwHoEcamFsdG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNv bTBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20v cnBhMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzU3 ZGU3YTIzOGQ0NWQ4ZDRmYzcxZjhhNWM2YjgxYzkzL0xhdGVzdENSTC5jcmwwTgYIKwYBBQUH AQEEQjBAMD4GCCsGAQUFBzAChjJodHRwOi8vY2FjZXIuc3ltYXV0aC5jb20vbXBraS9zeW1j YzFpbmRzdWJjYWc1LmNydDAfBgNVHSMEGDAWgBRnGbY9pXm7M2DYLVPTjAk9B6wYcDArBgpg hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGt7pITFgUxMDkyMjA5BgpghkgBhvhFARAF BCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3 DQEBCwUAA4IBAQBvO/+L6Tms91Ed1ZJzgT0y9jBK/Armb6Y/EnR1swCDMqRfBzGSGtzOCuN7 PteBvlaB5vmnwEwiZR/FtsDhhORd8Xy5wdmCunhwPbf0ClnBqichI+4UZNS5fCQTciIqHFxq 7EKuHOQm4/ssEH2Xr8yIpCd+Dx9oPEG7MqUno6oxcIDdur4iNKxOBtjWNiXM7rn733qtuFlw 1jIX3eFIsrBALikTU1UbY2KwfewXbiVaFWY0ysl5uOgfWdmj2xBk7aft/L/fnuyWyeeM9IBg 6vdUjPhmJwtFdEdefgP5cRRdYgG8zgJf8Rq84slkea0bwis8PvKVksJ/k2scaDHzKTe2MIIG PDCCBSSgAwIBAgIQBwKiGoW4S2WeGApu5vWjZTANBgkqhkiG9w0BAQsFADCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMTUxMDAxMDAwMDAwWhcNMjUw OTMwMjM1OTU5WjCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0 aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW+w0x SSLADLrvTi0XuLQw5TTSrAnuyYkAXfSuExGzE45VzyIYqCAGpv0ly2iUtKCCkA5ulpJE7hW5 tOz6z3k9adScH9wgmg4o1Q21xp468dRlGcCEM02O2orx1ie5A6DR+iicgpNs9w2FfVvpTpli /pNC0u4+s3FXhpdGy98N4caEWrMNj/X0EIoFXZ9oRuwIsFhCgva+LRBGpiQLJ/6YFFODk4Lb 6sA/T6JYYbVLcmkSXzNZ9vmzTABkzoXFhpIMbhzrKM9xqZCpdJl0JOtI4Q5daBKoAWbo7pqy L/g9zbd4JM6lYHzoFj1J8Qe6M74yK8JnoxbHb8DSWpQEwmtFAgMBAAGjggI+MIICOjA3Bggr BgEFBQcBAQQrMCkwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTAS BgNVHRMBAf8ECDAGAQH/AgEAMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEF BQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDov L3d3dy5zeW1hdXRoLmNvbS9ycGEwLwYDVR0fBCgwJjAkoCKgIIYeaHR0cDovL3Muc3ltY2Iu Y29tL3BjYTEtZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRU3ltYW50ZWNQS0ktMi0yMTcwHQYDVR0OBBYEFGcZtj2lebszYNgtU9OMCT0HrBhwMIHx BgNVHSMEgekwgeahgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5 OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQsFAAOCAQEARhnkJ3U7vq/i 2qIUYI8eRJCBaStjSTWN6Xa6n5iPE4HXy/xlG/gOY96UKHT742/YySp6DlSmg64pSvYrUf09 OBK73WNF+2TMPlSGf05CbSO3HQv9+swNjpM1yuVF+c8vf3k9YxjHRyNK9qkUAK1+WVUaiSfb lKCROMb+QJWjYPZduMjFFu2cZmkURhBKynAqb9FQ4CYa01K0R3KLRdK9A7ml3NkI85CrdHCr yqBO8MBO5OC+T5ARYCcMKxzf52zKdbQl55FIqpK0UXVfKZtHFxy9yerPda11I8/yxd9aq7dr yru4XqvVo3DUaPMXepsLoBQ8++iBVmjoz118c7guvDGCBGIwggReAgEBMIG7MIGmMQswCQYD VQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNQIQ cBGDX/fzAS3ijWWeve3D7zANBglghkgBZQMEAgEFAKCCAncwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNTE4MDAzNjA0WjAvBgkqhkiG9w0BCQQxIgQg runhOGm+qyt5KMANA0RR3S/mXkxWbx3dl9LjHhwMzGswbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7 MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHNQIQcBGDX/fzAS3ijWWeve3D7zCBzgYLKoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3lt YW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1 AhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBAQUABIIBAHrwYaDDLZIg1OCSiNEuG0K5 cVpGwjm1tgMOSI1dMnyK453MzWFlPWTljnVWjG8bD7thaOUUoxQkvSp5BNHL4pcFHfEGsCbc lNtg78i0oZh81Rld/gc9V0ukJP3sE0XOqeX4w0UGoE6qHVTpdoouiHqSI61A8jvCWK4UY5Jx bafuO5ZPKeXAWpoDjnqMRLyFKw71nSHir5VsaId71kgW+fpmMU4o++UPlDHcMHq9rFV20avi QF+GOzwO/o0ze5I9kRX7bOrDC1LlG1g9cciBNb8opmpw65BnmPiVjXRXHNS7xW/bOEfFS5no HnN4q5LPmsyvPMtcjLr0WxymMUxFSLAAAAAAAAA= --------------ms090702010905040801050806-- From nobody Tue May 17 22:10:17 2016 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 98A4312D9A3 for ; Tue, 17 May 2016 22:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 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=-1.426, 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 RrojVLtALozZ for ; Tue, 17 May 2016 22:10:14 -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 0E49A12B00F for ; Tue, 17 May 2016 22:10:12 -0700 (PDT) X-AuditID: 12074424-34fff70000005c1f-0d-573bf933fa15 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 44.12.23583.339FB375; Wed, 18 May 2016 01:10:11 -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 u4I5AAVl004326; Wed, 18 May 2016 01:10:11 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u4I5A7Si030271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 May 2016 01:10:10 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u4I5A6lC023729; Wed, 18 May 2016 01:10:06 -0400 (EDT) Date: Wed, 18 May 2016 01:10:06 -0400 (EDT) From: Benjamin Kaduk To: Nathaniel McCallum In-Reply-To: <1463500163.2432.9.camel@redhat.com> Message-ID: References: <1463500163.2432.9.camel@redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixG6nomv80zrcoLtL3uLo5lUsFnO/zmJ1 YPJYsuQnk8f7fVfZApiiuGxSUnMyy1KL9O0SuDI27njLUvCLveLjy3aWBsajbF2MnBwSAiYS P7d/Y+5i5OIQEmhjkvh9cyMjhLORUeJx/yso5xCTxIaze1ghnAagzNUrjCD9LALaEg9Wb2MF sdkEVCRmvtkINldEQE9i2b4JYDXMAsIS68/NANrBwSEsECDxeKoaSJhTwFBi3+lWJhCbV8BR YtPkTSwgtpCAgcSRW0vA4qICOhKr909hgagRlDg58wkLxEgtieXTt7FMYBSYhSQ1C0lqASPT KkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1zvdzMEr3UlNJNjOCQdFHZwdjd432IUYCDUYmHd0O/ dbgQa2JZcWXuIUZJDiYlUd4LJkAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrxNX4FyvCmJlVWp RfkwKWkOFiVxXkYGBgYhgfTEktTs1NSC1CKYrAwHh5IEr/8PoEbBotT01Iq0zJwShDQTByfI cB6g4X++gwwvLkjMLc5Mh8ifYlSUEuddD9IsAJLIKM2D6wWnjN1Mqq8YxYFeEeY1AaniAaYb uO5XQIOZgAZPMLMAGVySiJCSamCctYXlj3X2sfdfL8x69SzJ7ZLu8tAJM/R7OZ+9dtC+lpOy cT2HcmVbnot9yZ+dYp9seHNFSvtmui6Q+T/fQ9qGXWb6HKEj549uP/XmwZtIqRNZ99YduTx7 2wLFcBG/v0vdD8w4nlgQq1ZxYIqCqYDgj4OfxA40e2ReT70uJMDueeJmrN716MNhSizFGYmG WsxFxYkAiDpuCPQCAAA= Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 05:10:15 -0000 On Tue, 17 May 2016, Nathaniel McCallum wrote: > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery > -02 > > I'd like to propose adoption of this draft: The chairs are tracking this document and expect it to eventually become a working group document. However, as I implied in our previous discussion (off-list), there are a lot of existing WG documents that are not moving very fast, and it seems unhealthy to keep a lot of documents around in such a state. It would be better to finish off (or formally abandon) some existing documents before we start trying to take on new work. I also noted that "adding [Kerberos] bits to the DNS always seems harder than one expects", which seems borne out by the discussion triggered by your message. -Ben P.S. If someone wanted to help clear out the pile of existing WG documents, draft-ietf-kitten-gssapi-extensions-iana, draft-ietf-kitten-rfc5653bis, or draft-ietf-kitten-krb-auth-indicator would be fine places to start. From nobody Wed May 18 03:10:43 2016 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 F2BBF12B078 for ; Wed, 18 May 2016 03:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 F7ofcZo0lavJ for ; Wed, 18 May 2016 03:10:39 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0795.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::795]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6B112B007 for ; Wed, 18 May 2016 03:10:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9ELvV+T1U635D1T5F6g2DIkFZ6TcvpFgL5k5NiG4gdA=; b=V4EcG8El9oEcPMxjGR2xFUy+T/vZ72egxhBxo+CplqIN5m4ZXy6Ylz+kPWjO0rg0kXoKgyzghdVlxC3hBpsTDEQmcfyNJ+C62HMrNgyAO19bxsgnWEleBZo2UVL4xi5vD2W5TOMAsXhiD0V08X5Ta5xZ/jAU0dJaMgWJx9KZWAY= Authentication-Results: MIT.EDU; dkim=none (message not signed) header.d=none;MIT.EDU; dmarc=none action=none header.from=btconnect.com; Received: from pc6 (109.145.193.232) by VI1PR07MB1567.eurprd07.prod.outlook.com (10.165.239.13) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 18 May 2016 10:10:22 +0000 Message-ID: <016801d1b0ec$f4c0c6e0$4001a8c0@gateway.2wire.net> From: tom p. To: Benjamin Kaduk References: <1463500163.2432.9.camel@redhat.com> Date: Wed, 18 May 2016 09:26:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [109.145.193.232] X-ClientProxiedBy: DB3PR08CA0003.eurprd08.prod.outlook.com (10.161.51.141) To VI1PR07MB1567.eurprd07.prod.outlook.com (10.165.239.13) X-MS-Office365-Filtering-Correlation-Id: d9f84979-72c2-4f98-2243-08d37f049faf X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1567; 2:Cr+OPCcaOhbK16WaEFOX2y5TVB58ENtFvYL6HrSkoKT3YM7bCp7Ab2RfG2nLGpyUatvBDUrYxmj4h2N5d4l6kig7I77Oxf42O1vUgCSccQm6ofSV2T4bwtJRwuaAUM94hsQ9vS289iTsI/ExpnDk+dutKBuJ45vZdKqsXSUcEo0N+dSFE/G5QX1ffcr3Ua4C; 3:yhLQ99JiqL15yA6fMAmVf/uIYo51Xf/xbvwyA1OK+j37zncvhs5wwDzKPo05wB9QRW3HFYFHf+eB+SNvqOWbQTcSu2iktnqVDudq2EZim/qTxAsm4nna9lAJJdmK/7RV; 25:/JAnbgfLG7TeA1SvDE0ZYGTXtp/9QrQfH31t7D0oFcBi/d42qMwRiVmNKzUhYCwbqJPUAgf7Wxue1AxfM4guIXwygnqmNUuHMEm7G8T96KJbeTigPKxFL1KK1AhyDjXv4nBROVyXftp80hev1l9E+I3TaHtUO205dkgjdiVw7/Uv3ofO5cQcpG0Odsbrom1HDHTfDYAYDp2qz4BG9iq6TIbUXBCuKReyMiN9K7Vfq3WdOgKbKMLJZiIoxiUAkJPJk5ZUHEqay9juSZejI3l0GbjrvBU838wtKcgtDaRmRjJPhW6CTJ8I4hR2xd8yJDnm1+vpI3RYapJw4PAjVxlL/migekStIulpeJfSv142oW6F7ebYXJY6Fz3ggM0N1QQKkOEtYyWTjzQ3Gc4973QSv7AFqe51IxraicL40BPpKdI= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR07MB1567; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:VI1PR07MB1567; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1567; X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1567; 4:aGdalTOAf2HHVlUU+p0KJy5pWDjY/K3OwTq1R5hVTkLBaLjLpJ1bfhMsw1gLiv80a3lc909o4wYODszVAp+u7HS8zn6uklwzcFV6/0IcBFVzkL8KotSGWrcEvqKHIlikedrcIunRYICOimo4366TaPDNXKBXsVNil8tqia14IfKJuwlFKRzrDtFwz/RWaddFB6IZd4gLDTWSSJ5KvUDdD+LW3pDOLedXJal/A2frv3ZiV52ViYxZNdLevSnS317iTrr+owq0jnIjYyiip1f3gB5gB0bBSRl6jxdpxi1E/YQp3sqzjJb1PRlbl6a6h4l/eExWNLDbHLpjR6dJezP5FXr3vcd5rMgvyCnMMe0Q5QJ7NkbZj8VHOCBEaUr7UCQ9 X-Forefront-PRVS: 0946DC87A1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(24454002)(377454003)(586003)(81166006)(66066001)(77096005)(14496001)(81686999)(61296003)(47776003)(86362001)(8676002)(230700001)(5008740100001)(81816999)(230783001)(6116002)(44716002)(1456003)(92566002)(62236002)(3846002)(15975445007)(23756003)(189998001)(2906002)(5004730100002)(110136002)(2171001)(42186005)(9686002)(33646002)(50226002)(19580395003)(19580405001)(84392002)(76176999)(50466002)(50986999)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1567; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR07MB1567; 23:IzWWomnLkYJH2Ojcb4zQ6w6YXzCPXFrbUJzY2+A?= =?iso-8859-1?Q?ztue8Ak4v7K7ldPKApqTrKXIXx2g66WswFH0LrBaqdwr/Ore97kwtjJBPR?= =?iso-8859-1?Q?GvW+tQ9/IvzvoFgilnAoNR2yC2RW7/7wPFz5UmRSITCZHpu82ShkcT6zeT?= =?iso-8859-1?Q?tfMMyyb0UPLnGhfZkkz+L3SJj3iyM9rZAvAk6mRsSf/Q7hf5EBXCHLlQ2Z?= =?iso-8859-1?Q?1gk+8Z6tUqMWpUyrrDORgGrIhLtruCi6UdBgwPfYkBm6xdlNtHW+u/H5as?= =?iso-8859-1?Q?QGzxf18emNjUOlkothAk5cQVhHb426QUCTgAL+uf/mw/T4UGTqC4nsjO+3?= =?iso-8859-1?Q?iiv/IQ0JFS/fuw8UpUTQmytmmYqLlRSekB8PgV7RnFU2/UmnPGgyJkcJ+S?= =?iso-8859-1?Q?GTNxaOLOqkxxxouwP3qkOZfMwizBcB563wLBXS15ZAF2OuOVHvn6/5xlVh?= =?iso-8859-1?Q?hvTAZuSL+pLQ29K0BtIfktSPbZQfS13x91u91ASL8tm+G420dMTNddtam0?= =?iso-8859-1?Q?Ha98CHkgje+XQMZYJJ9dodL+/BbS6C2yeEcr875c93Y74FUYBjCLHKbdjo?= =?iso-8859-1?Q?4OcLFQvMwCo5/Z4m/oPrajXF34JB5w29BtU17dVU2J5+69kgF1veRy4isq?= =?iso-8859-1?Q?MsBOdXOtQzrIyOhjhnTDJN9/yawXEhFr2Bdm8hLw2gNtwxvaIHLFlZy6LN?= =?iso-8859-1?Q?4mxxEbDuJX6Cx4v6jNc86X9VDeXXsCWIGcrkGUHDM15jjh2sSt/iAXsXQd?= =?iso-8859-1?Q?nfvpnK2CGyS9JxKbj3CG9mr1WJIkoklN3CNr7cNybz+PoPc2Wz2rdPjyqg?= =?iso-8859-1?Q?Mre/bHT5FR/BqBoehXkHAAKQpunjSYjwbUVhidsnDK6vgrENBLXjLZzMxL?= =?iso-8859-1?Q?O9Zk45qDWMf0ro7XTQkWLqap9dJHcTQdZP/K2gzLee7qZEjkeB+2Eh1yWD?= =?iso-8859-1?Q?hDvNK1ZJz0wlk2omPpzkgSoydI4ByejxVRf4Qzn4J1QzGejRJhoEq20AAC?= =?iso-8859-1?Q?YAt1LanDdVW0B11YVzKuJdOVgy9OztRPrwJ0b5mhPudm03kDbApQy0h8LR?= =?iso-8859-1?Q?Nep08iZw4Tsm/kV3kCFotzSRGAkJVo7hv/EBLBbOcmReaf2PRoL7/FuFdj?= =?iso-8859-1?Q?P1HcKUGx5wCpa00xin+dFCMZdV6SNNLlGFtPvq59smgtqjv0=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR07MB1567; 5:mIQInbHCDOD8eDMxe2NlT0LETmw4G5h8MmjtRh1NX5+BbwlWsJDwuXUD7HnMlFWgXRxPM8Fv0geVcMbOoJnpucEhjIcuG0uKKMMQmH78PbmPjEJxgkx1AzypQWLYvzz+/4Rjo4pjw6Y6zqHBTtd/NA==; 24:lKnKYd2M7Azpd9NJ87iEGdFlF3EkO6qlo2swTFT0EeKZoGACcW9KIDciLJ9PBSJ7/klBsblQP0JmDl9Vpkknq/6TfJ33K8biuX1oYA6BsFM=; 7:opyOwNrxw7hh1Id04zZlZnK8/web7aWW0+bVFTDe/Pdf0lef860azBly52+VlsT15BMlPhqZMNp+igarKjsA/W7Z5vXGRiBZFb/Cnb8VDPX4oXIPkggBL+gbEjbMw1G78/bd6TyXopeQW9S5pYd9ETmpxDsko9Z/3snHECaLxFUsMj8mqVHKqXChdcBK/oQm SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2016 10:10:22.2052 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1567 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption ofdraft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 10:10:41 -0000 ----- Original Message ----- From: "Benjamin Kaduk" To: "Nathaniel McCallum" Cc: Sent: Wednesday, May 18, 2016 6:10 AM > On Tue, 17 May 2016, Nathaniel McCallum wrote: > > > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery > > -02 > > > > I'd like to propose adoption of this draft: > > The chairs are tracking this document and expect it to eventually become a > working group document. However, as I implied in our previous discussion > (off-list), there are a lot of existing WG documents that are not moving > very fast, and it seems unhealthy to keep a lot of documents around in > such a state. It would be better to finish off (or formally abandon) some > existing documents before we start trying to take on new work. > > I also noted that "adding [Kerberos] bits to the DNS always seems harder > than one expects", which seems borne out by the discussion triggered by > your message. > > -Ben > > P.S. If someone wanted to help clear out the pile of existing WG > documents, draft-ietf-kitten-gssapi-extensions-iana, > draft-ietf-kitten-rfc5653bis, or draft-ietf-kitten-krb-auth-indicator > would be fine places to start. P.P.S. Perhaps you should operate a one-in one-out policy. If an author has an I-D gathering dust in the expired pile, then they should resolve that - advance it, bin it - before an adoption call is made for another I-D by them Authors with a track record of producing RFC might be given a bigger pile of tokens for their leaky bucket. Just a thought. Tom Petch > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Wed May 18 09:34:53 2016 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 DE66012D558 for ; Wed, 18 May 2016 09:34:50 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 09 hex): References: ...2432.9.camel@redhat.com>\n\t\n <54c900f2-399[...] X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 jUGzJajM1EqK for ; Wed, 18 May 2016 09:34:49 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68A8C12D5D6 for ; Wed, 18 May 2016 09:34:49 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E0519C05B1D8; Wed, 18 May 2016 16:34:48 +0000 (UTC) Received: from vpn-57-37.rdu2.redhat.com (vpn-57-37.rdu2.redhat.com [10.10.57.37]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4IGYlxK009712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 May 2016 12:34:48 -0400 Message-ID: <1463589287.2481.34.camel@redhat.com> From: Nathaniel McCallum To: Jeffrey Altman , kitten@ietf.org Date: Wed, 18 May 2016 12:34:47 -0400 In-Reply-To: <3911bb56-b9a1-a5e5-cc6c-c742f779536c@secure-endpoints.com> References: <1463500163.2432.9.camel@redhat.com> <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> <1463517801.2432.24.camel@redhat.com> <490bd7aa-81ca-9199-6687-222bb65caddf@secure-endpoints.com> <1463520360.2432.46.camel@redhat.com> <3911bb56-b9a1-a5e5-cc6c-c742f779536c@secure-endpoints.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 18 May 2016 16:34:49 +0000 (UTC) Archived-At: Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:34:51 -0000 On Tue, 2016-05-17 at 20:36 -0400, Jeffrey Altman wrote: > On 5/17/2016 5:26 PM, Nathaniel McCallum wrote: > > > > I've described a reason why a URI record lookup is requied for MS- > > KKDCP. However, I've also described a system which presents a 50% > > reduction in DNS lookups. I don't see any reason to neglect this > > second > > feature. > > And when the DNS URI record is not published or cannot be queried the > Kerberos library will have a 50% increase in the number of DNS > lookups. > Not only does the library have to query for DNS URI but it still must > query for the DNS SRV records. This is, indeed, the trade-off to a longer-term improvement. As I said before, the property that makes this trade-off acceptable (IMHO) is that the DNS administrator can solve this problem. This performance trade-off creates an incentive for administrators to move to the new system. I'm very open to alternative designs. But we've been having this conversation for more than a year now and, while lots of alternatives have been proposed, all of them were abandoned by their proposers after due consideration. Here is a basic summary of the ideas proposed (please remind me if I've missed any): 1. A new, Kerberos-specific RR type. 2. (Ab)using TXT; same semantics as the current draft. 3. (Ab)using TXT; same semantics as RFC4120 - KKDCP only. 4. Using SRV with a default path. #1 was dismissed as generally having the effect of ghettoizing the discovery mechanism. Servers wouldn't implement it. Neither would administrative interfaces. It also has all the same drawbacks as the current draft. #2 is the exact same proposal as the existing draft, just using TXT records. Its main advantage over the current draft is that we don't need to depend on the URI record type. However, using the TXT record like this is controversial (to say the least). #3 is the simplist solution: just define a TXT record for KKDCP only. This record would work in parallel to the existing SRV records and would only indicate the location of the KKDCP proxy. The downside is that this adds an additional query just for KKDCP. Future tunnels may add more queries. Also, it doesn't allow for weights/priorities between protocols. #4 proposes to define an SRV record for KKDCP. This would carry the understanding that the default path (/KdcProxy) would always be used. This is basically a hack and is extremely inflexible. It would mean, in many cases, that the KKDCP proxy couldn't be integrated directly into existing infrastructure. Notice that in all of the options we require an additional DNS query. This is unavoidable. #3 and #4 do not provide any opportunity for speedup. This means that KKDCP users will have to wait for two DNS timeouts in order to get connectivity. I find this property unacceptable. #1 and #2 have the potential for speedups, with exactly the same semantics as the current draft. But they each have significant drawbacks as well. The current draft seems to me the best balance of all the options. 1. It uses a standard RR type. While the use of URI may be somewhat controversial, it seems to me less problematic than either of the alternatives (a custom RR type or TXT). 2. It does add an additional DNS query; but this can be avoided if DNS configuration is updated. This is the best case scenario considering an extra query will be required in all options. 3. It provides the ability to use weights/priorities between protocols. > I will also point out that a large number of the DNS hosting > providers > do not support URI records and many of the DNS proxy servers do not > support them either.   As a result there is no ability for DNS URI > records to be published and the queries are will be blocked. On the MIT krb5 call this week, I argued this very point against #1 (above). What I argued is that it will be easier to get hosting providers to add support for URI than for some Kerberos-specific type. If hosting providers were the only consideration, then TXT would be a no-brainer here. However, there are also standardization considerations. If the general consensus is that standardizing on TXT won't present any difficulty, I would be more than happy to switch to this option. If you have any alternative, more creative, solutions, I'm all ears. If, after this explanation, you agree that our solution is the best balance of all the concerns, I am also open to suggestions for improvements in the implementation. It is my hope that we can agree upon the contours of the problem and devise a solution that is acceptable to everyone. Nathaniel From nobody Wed May 18 09:59:41 2016 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 BCE1712D1AA for ; Wed, 18 May 2016 09:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 rRgaIEr0fAnt for ; Wed, 18 May 2016 09:59:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C74212D194 for ; Wed, 18 May 2016 09:59:38 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 04FEA80F7B; Wed, 18 May 2016 16:59:38 +0000 (UTC) Received: from vpn-57-37.rdu2.redhat.com (vpn-57-37.rdu2.redhat.com [10.10.57.37]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4IGxa0s009150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 May 2016 12:59:37 -0400 Message-ID: <1463590776.2481.40.camel@redhat.com> From: Nathaniel McCallum To: Benjamin Kaduk Date: Wed, 18 May 2016 12:59:36 -0400 In-Reply-To: References: <1463500163.2432.9.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 18 May 2016 16:59:38 +0000 (UTC) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 16:59:40 -0000 On Wed, 2016-05-18 at 01:10 -0400, Benjamin Kaduk wrote: > On Tue, 17 May 2016, Nathaniel McCallum wrote: > > > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-disco > very > > -02 > > > > I'd like to propose adoption of this draft: > > The chairs are tracking this document and expect it to eventually > become a > working group document.  However, as I implied in our previous > discussion > (off-list), there are a lot of existing WG documents that are not > moving > very fast, and it seems unhealthy to keep a lot of documents around > in > such a state.  It would be better to finish off (or formally abandon) > some > existing documents before we start trying to take on new work. Understandable. However, a timeline would also be helpful. This draft is already more than a year old and has only seen minor changes. > I also noted that "adding [Kerberos] bits to the DNS always seems > harder > than one expects", which seems borne out by the discussion triggered > by > your message. Well, I take this discussion as just a rehash of the conversations that happened last year; just with new interlocutors. None of the input variables have changed and we are, I think, ending up with exactly the same conclusions. > P.S. If someone wanted to help clear out the pile of existing WG > documents, draft-ietf-kitten-gssapi-extensions-iana, > draft-ietf-kitten-rfc5653bis, or draft-ietf-kitten-krb-auth-indicator > would be fine places to start. I have requested WGLC for draft-ietf-kitten-krb-auth-indicator. From nobody Wed May 18 10:02:31 2016 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 A9AF012D5A8 for ; Wed, 18 May 2016 10:02:30 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 09 hex): References: ...2432.9.camel@redhat.com>\n\t\n ; Wed, 18 May 2016 10:02:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A9E12D567 for ; Wed, 18 May 2016 10:02:26 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A79E56540F; Wed, 18 May 2016 17:02:25 +0000 (UTC) Received: from vpn-57-37.rdu2.redhat.com (vpn-57-37.rdu2.redhat.com [10.10.57.37]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4IH2LDd019568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 May 2016 13:02:25 -0400 Message-ID: <1463590940.2481.43.camel@redhat.com> From: Nathaniel McCallum To: "tom p." , Benjamin Kaduk Date: Wed, 18 May 2016 13:02:20 -0400 In-Reply-To: <016801d1b0ec$f4c0c6e0$4001a8c0@gateway.2wire.net> References: <1463500163.2432.9.camel@redhat.com> <016801d1b0ec$f4c0c6e0$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Wed, 18 May 2016 17:02:25 +0000 (UTC) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption ofdraft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 17:02:31 -0000 On Wed, 2016-05-18 at 09:26 +0100, tom p. wrote: > ----- Original Message ----- > From: "Benjamin Kaduk" > To: "Nathaniel McCallum" > Cc: > Sent: Wednesday, May 18, 2016 6:10 AM > > On Tue, 17 May 2016, Nathaniel McCallum wrote: > > > > > > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discove > ry > > > -02 > > > > > > I'd like to propose adoption of this draft: > > > > The chairs are tracking this document and expect it to eventually > become a > > working group document.  However, as I implied in our previous > discussion > > (off-list), there are a lot of existing WG documents that are not > moving > > very fast, and it seems unhealthy to keep a lot of documents around > > in > > such a state.  It would be better to finish off (or formally > > abandon) > some > > existing documents before we start trying to take on new work. > > > > I also noted that "adding [Kerberos] bits to the DNS always seems > harder > > than one expects", which seems borne out by the discussion > > triggered > by > > your message. > > > > -Ben > > > > P.S. If someone wanted to help clear out the pile of existing WG > > documents, draft-ietf-kitten-gssapi-extensions-iana, > > draft-ietf-kitten-rfc5653bis, or draft-ietf-kitten-krb-auth- > > indicator > > would be fine places to start. > > P.P.S. > > Perhaps you should operate a one-in one-out policy.  If an author has > an > I-D gathering dust in the expired pile, then they should resolve that > - > advance it, bin it - before an adoption call is made for another I-D > by > them  Authors with a track record of producing RFC might be given a > bigger pile of tokens for their leaky bucket. I'm fine with this so long as the author gets to choose the priority. For instance, I have three drafts. Two of them are small (auth-ind, service-discovery) and one of them is large (spake-preauth). This order is also my priority. However, I'd hate to have spake-preauth be pulled in first and have it block the smaller drafts for years. Nathaniel From nobody Thu May 19 09:10:47 2016 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 A428312D177 for ; Thu, 19 May 2016 09:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 7z-P7a02mN1D for ; Thu, 19 May 2016 09:10:44 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C3A12D16F for ; Thu, 19 May 2016 09:10:43 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id D2728400EE530; Thu, 19 May 2016 09:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=yXXD3pbM7owkRt 3fS2fwvuUFT/g=; b=bpsEawCugAp7MbGTgsHcv+zZqXncraw/XKTttXTPEvKA+U p0CC0PPfeGRjNmxgz5cUcsu+aKFFJHhJ+S5YoAAdps0OT4V2bNBIC7GdoFaL4Os7 0n53rH+KR2ovJBebswtaGvIUJ6TC2iiIv7JXlsTAs9J/Z6d4mhFwRUj5kjjSQ= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id 77FA3400F8A33; Thu, 19 May 2016 09:10:36 -0700 (PDT) Date: Thu, 19 May 2016 11:10:06 -0500 From: Nico Williams To: Jeffrey Altman Message-ID: <20160519161004.GA19530@localhost> References: <1463500163.2432.9.camel@redhat.com> <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 16:10:45 -0000 On Tue, May 17, 2016 at 12:25:10PM -0400, Jeffrey Altman wrote: > On 5/17/2016 11:49 AM, Nathaniel McCallum wrote: > > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery > > -02 > > > > I'd like to propose adoption of this draft: > > > > 1. It is in the scope of the WG. This is an extension to the discovery > > methods already defined in RFC 4120. > > > > 2. It is beneficial. It provides both speed improvments and additional > > functionality (discovery of MS-KKDCP proxies). > > > > 3. It is small. It avoids defining new: DNS names, DNS semantics, URIs, > > or transport semantics. It simply combines the existing tools in a > > fairly obvious way. > > > > Thoughts? > > > > Having read the draft I am totally unclear how it is implemented. > > _kerberos.REALM > > is not a valid DNS URI record name. To translate the URI RFC7553 is Informational. Clearly it's the most authoritative when describing the URI RR type's RDATA and their semantics. But as for the RRset names, I think it's mistaken, and anyways, it's Informational (though it once aimed for Proposed Standard; we might want to find out why it ended up being Informational). > https://host[:port][path] > > to an URI record requires > > _kerberos._https.host > > [...] Problems with this: a) if we're going to be pedantic, _https is not the sort of protocol intended to go there (protocols running over IP are, so _tcp, _udp, _sctp, ...); b) plus we have *two* HTTP-based protocols, so how would we indicate which protocol to use? c) every additional transport for the KDC exchanges adds a (serial, as implemented) DNS lookup for the clients -- this is a performance disaster. (c) is fatal. We really need _kerberos.. as the QName and, therefore, the RRset name. One question, one answer set. And if we're going to use URI, then we'll need a 'krbtgt' URI scheme by which to express the four protocols we have (raw over TCP, raw over UDP, HTTP MSFT-style, and HTTP Heimdal-style: krbtgt:[:]#proto=tcp krbtgt:[:]#proto=udp krbtgt:http[s]://[:port][/path]#style=POST krbtgt:http[s]://[:port][/path]#style=GET Or any variant of that that you might like, such as: krbtgttcp:[:] krbtgtudp:[:] krbtgtpost:http[s]://[:port][/path] krbtgtget:http[s]://[:port][/path] > Can you make a case for something that DNS URI records provides that DNS > SRV records do not? Yes. See above. > The introduction of DNS URI records will only mean that in practice that > Kerberos client libraries will need to issue the DNS URI queries in > addition to the existing DNS SRV records. Yes, but they should try URI queries first so as to create an incentive to publish those (because that will be faster, because it will be just one query instead of three or four). Nico -- From nobody Thu May 19 09:25:53 2016 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 4F2D912D5E0 for ; Thu, 19 May 2016 09:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 xeptOJgEBh0z for ; Thu, 19 May 2016 09:25:49 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC69012D5B9 for ; Thu, 19 May 2016 09:25:49 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id 71B2440130600; Thu, 19 May 2016 09:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=xb3G7P8B8yP8rt DGG83j9u+J4s4=; b=RNOCXuSi1ibNm7NwWpi6/rYPV7tcNbW3N77c1+4bIyjH6U R2Ku8vmR5AsYDUvcBEJgBz+vYFQHy0h1Q6Oj9efHbHGYAo4+hZutOghWilaRdnUu Yr65UUjpIBIgT9zMOV4PQt6rVqGdadlPaCoYjhYoQXlNUGvtvssMtiWkl6BPM= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id C3D464012E6FE; Thu, 19 May 2016 09:25:47 -0700 (PDT) Date: Thu, 19 May 2016 11:25:46 -0500 From: Nico Williams To: Nathaniel McCallum Message-ID: <20160519162545.GB19530@localhost> References: <1463500163.2432.9.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1463500163.2432.9.camel@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 16:25:51 -0000 On Tue, May 17, 2016 at 11:49:23AM -0400, Nathaniel McCallum wrote: > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery > -02 > > I'd like to propose adoption of this draft: > > 1. It is in the scope of the WG. This is an extension to the discovery > methods already defined in RFC 4120. > > 2. It is beneficial. It provides both speed improvments and additional > functionality (discovery of MS-KKDCP proxies). > > 3. It is small. It avoids defining new: DNS names, DNS semantics, URIs, > or transport semantics. It simply combines the existing tools in a > fairly obvious way. > > Thoughts? - If we use the URI RR type (and maybe even if we don't), we'll need a krbtgt URI scheme, as we have four different options to express, including two over HTTP: raw over TCP, raw over UDP, HTTP w/ POST, HTTP w/ GET. - We should find out why RFC7553 ended up being Informational. There may be some important lessons in that. - Perhaps we should have our own RR type. In principle it's easy to add them, but: - You've mentioned that many DNS hosters don't have UIs or support for URI RRs. This needs more research. If adding support for new RR types is impossible because of this, then the DNS community at the IETF should be asked to address this, and we might need to use TXT RRs instead. Using TXT RRs is frowned upon, and we'd never get an RFC on the Standards track using them today, but if the DNS community confirms that adding new RR types is much harder than previously thought, then TXT RRs will have to become the DNS extension mechanism to use instead of new RR types. Ideally we could get the DNS hosters to support arbitrary RR types. Yes, there is also a UI issue (see below), but it's manageable. - If new RR types are the answer, then the DNS community needs to do something about UIs. For example, there could be an XML schema defining RR types' RDATA contents and UI elements. Then implementors could automatically translate those to code to implement UIs for new RR types. - Can you research whether the DNS community at the IETF has addressed these issues before? If they have not, then we'll have to bring this up to them. If they have, what was the outcome? Have conditions in the market changed? Should the IETF review these issues again? - Can you ask some DNS hosters to inveigh as to whether they would be willing to add arbitrary new RR types? (Presumably with a UI that requires the user to paste base64-/hex-encoded RDATA.) I think this research will be very valuable in reviewing this document, and perhaps using alternative designs (e.g., defining a new RR type, or using TXT, or updating RFC7553 and perhaps promoting it to Proposed Standard). - You might want to seek several ADs' input on this early. The DNS issues here seem very real, and dealing with them may require help from the ADs. The WG chairs might help with this. Nico -- From nobody Thu May 19 09:28:18 2016 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 0A58112DA34 for ; Thu, 19 May 2016 09:28:17 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 09 hex): References: ...2432.9.camel@redhat.com>\n\t\n <54c900f2-399[...] X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 gC-Td6yy7fJw for ; Thu, 19 May 2016 09:28:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C87C912D97D for ; Thu, 19 May 2016 09:28:14 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7373478222; Thu, 19 May 2016 16:28:14 +0000 (UTC) Received: from dhcp137-207.rdu.redhat.com (dhcp137-207.rdu.redhat.com [10.13.137.207]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4JGSDff025884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 May 2016 12:28:14 -0400 Message-ID: <1463675293.31173.25.camel@redhat.com> From: Nathaniel McCallum To: Nico Williams , Jeffrey Altman Date: Thu, 19 May 2016 12:28:13 -0400 In-Reply-To: <20160519161004.GA19530@localhost> References: <1463500163.2432.9.camel@redhat.com> <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> <20160519161004.GA19530@localhost> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 19 May 2016 16:28:14 +0000 (UTC) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 16:28:17 -0000 On Thu, 2016-05-19 at 11:10 -0500, Nico Williams wrote: > On Tue, May 17, 2016 at 12:25:10PM -0400, Jeffrey Altman wrote: > > On 5/17/2016 11:49 AM, Nathaniel McCallum wrote: > > > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-dis > > > covery > > > -02 > > > > > > I'd like to propose adoption of this draft: > > > > > > 1. It is in the scope of the WG. This is an extension to the > > > discovery > > > methods already defined in RFC 4120. > > > > > > 2. It is beneficial. It provides both speed improvments and > > > additional > > > functionality (discovery of MS-KKDCP proxies). > > > > > > 3. It is small. It avoids defining new: DNS names, DNS semantics, > > > URIs, > > > or transport semantics. It simply combines the existing tools in > > > a > > > fairly obvious way. > > > > > > Thoughts? > > > > > > > Having read the draft I am totally unclear how it is implemented. > > > >   _kerberos.REALM > > > > is not a valid DNS URI record name.  To translate the URI > > RFC7553 is Informational.  Clearly it's the most authoritative when > describing the URI RR type's RDATA and their semantics.  But as for > the > RRset names, I think it's mistaken, and anyways, it's Informational > (though it once aimed for Proposed Standard; we might want to find > out > why it ended up being Informational). I have already inquired. I was informed that the change was made simply for the reason that all DNS RR type definitions are informational. To avoid a downreference, I was advised to reference IANA instead of the RFC: http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml > >   https://host[:port][path] > > > > to an URI record requires > > > >  _kerberos._https.host > > > > [...] > > Problems with this: > > a) if we're going to be pedantic, _https is not the sort of protocol >    intended to go there (protocols running over IP are, so _tcp, > _udp, >    _sctp, ...); > > b) plus we have *two* HTTP-based protocols, so how would we indicate >    which protocol to use? > > c) every additional transport for the KDC exchanges adds a (serial, > as >    implemented) DNS lookup for the clients -- this is a performance >    disaster. > > (c) is fatal.  We really need _kerberos.. as the > QName and, therefore, the RRset name.  One question, one answer set. > > And if we're going to use URI, then we'll need a 'krbtgt' URI scheme > by > which to express the four protocols we have (raw over TCP, raw over > UDP, > HTTP MSFT-style, and HTTP Heimdal-style: > >   krbtgt:[:]#proto=tcp >   krbtgt:[:]#proto=udp >   krbtgt:http[s]://[:port][/path]#style=POST >   krbtgt:http[s]://[:port][/path]#style=GET > > Or any variant of that that you might like, such as: > >   krbtgttcp:[:] >   krbtgtudp:[:] >   krbtgtpost:http[s]://[:port][/path] >   krbtgtget:http[s]://[:port][/path] One reason to avoid "krbtgt" is that we are actually defining transport mechanisms for multiple protocols: kerberos and kpasswd, at a minimum. I suspect implementors will extract this to additional protocols. But in general, I don't care what the actual URIs look like. As you may have hinted, it may be worth considering implementing a URI for Heimdal's proxy. I left it off the current draft since there is no protocol definition; just some code. From nobody Thu May 19 09:46:00 2016 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 D591E12D614 for ; Thu, 19 May 2016 09:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 bpwo5o-wadVC for ; Thu, 19 May 2016 09:45:57 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96CBD12DA98 for ; Thu, 19 May 2016 09:45:44 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 03FB82005E804; Thu, 19 May 2016 09:45:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=zJm2qODasuAg+f 0ScVT0QvkDmug=; b=bBsynTp9v/ZyXU0MSwviiLuPhCoqzdpZXAcqiXd3O+y3F7 ef6rC0JqmXOw5HUL/+xb5et8n/XnzelJsHdGj0qXPokTpAS5sDUvym9fCPT16X8r vrwxkbTSY65CGthhaWrDT8O6ryB97sCyWBu5LGdPdM+J/dOPY8qixXmlkyl/g= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id 4FE2B2005E808; Thu, 19 May 2016 09:45:43 -0700 (PDT) Date: Thu, 19 May 2016 11:45:40 -0500 From: Nico Williams To: Nathaniel McCallum Message-ID: <20160519164540.GC19530@localhost> References: <1463500163.2432.9.camel@redhat.com> <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> <20160519161004.GA19530@localhost> <1463675293.31173.25.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1463675293.31173.25.camel@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 16:45:59 -0000 On Thu, May 19, 2016 at 12:28:13PM -0400, Nathaniel McCallum wrote: > > (though it once aimed for Proposed Standard; we might want to find > > out why it ended up being Informational). > > I have already inquired. I was informed that the change was made simply > for the reason that all DNS RR type definitions are informational. To > avoid a downreference, I was advised to reference IANA instead of the > RFC: > http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml Thanks. > > And if we're going to use URI, then we'll need a 'krbtgt' URI scheme > > by which to express the four protocols we have (raw over TCP, raw > > over UDP, HTTP MSFT-style, and HTTP Heimdal-style: > > One reason to avoid "krbtgt" is that we are actually defining transport > mechanisms for multiple protocols: kerberos and kpasswd, at a minimum. > I suspect implementors will extract this to additional protocols. On the contrary, that's all the more reason to want URI schemes for Kerberos: we can then add additional URI schemes for the related protocols (kpasswd, kadmin Heimdal flavor, kadmin MIT flavor, kadmin Solaris flavor, admin via LDAP, and whatever else comes up). > But in general, I don't care what the actual URIs look like. Me either, as long as they can express the options we have to be able to express. > As you may have hinted, it may be worth considering implementing a URI > for Heimdal's proxy. I left it off the current draft since there is no > protocol definition; just some code. Sure, but we can document it if need be. The point is that we have more than just three options to express, and if you include kpasswd and such, we have more than four. It's critical to be able to get at least the KDCs with one DNS question (perhaps using EDNS0 or falling back on DNS over TCP if the answers don't fit in a DNS UDP response). Nico -- From nobody Thu May 19 09:47:27 2016 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 44B5312D19D for ; Thu, 19 May 2016 09:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.326 X-Spam-Level: X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 9HnlnMQoubwr for ; Thu, 19 May 2016 09:47:23 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1062F12D5B2 for ; Thu, 19 May 2016 09:47:19 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CBDFE486A0; Thu, 19 May 2016 16:47:18 +0000 (UTC) Received: from dhcp137-207.rdu.redhat.com (dhcp137-207.rdu.redhat.com [10.13.137.207]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4JGlHLQ003714 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 May 2016 12:47:18 -0400 Message-ID: <1463676437.31173.36.camel@redhat.com> From: Nathaniel McCallum To: Nico Williams Date: Thu, 19 May 2016 12:47:17 -0400 In-Reply-To: <20160519162545.GB19530@localhost> References: <1463500163.2432.9.camel@redhat.com> <20160519162545.GB19530@localhost> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 19 May 2016 16:47:18 +0000 (UTC) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 16:47:25 -0000 On Thu, 2016-05-19 at 11:25 -0500, Nico Williams wrote: > On Tue, May 17, 2016 at 11:49:23AM -0400, Nathaniel McCallum wrote: > > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-disco > > very > > -02 > > > > I'd like to propose adoption of this draft: > > > > 1. It is in the scope of the WG. This is an extension to the > > discovery > > methods already defined in RFC 4120. > > > > 2. It is beneficial. It provides both speed improvments and > > additional > > functionality (discovery of MS-KKDCP proxies). > > > > 3. It is small. It avoids defining new: DNS names, DNS semantics, > > URIs, > > or transport semantics. It simply combines the existing tools in a > > fairly obvious way. > > > > Thoughts? > >  - If we use the URI RR type (and maybe even if we don't), we'll need > a >    krbtgt URI scheme, as we have four different options to express, >    including two over HTTP: raw over TCP, raw over UDP, HTTP w/ POST, >    HTTP w/ GET. Agreed to a URI scheme. However, HTTP w/ GET is undefined and only exists in one codebase. It also has some real idempotency and space limitation drawbacks. In contrast, MS-KKDCP (HTTP w/ POST) has a protocol definition and is implemented by multiple vendors without the above drawbacks. >  - We should find out why RFC7553 ended up being > Informational.  There >    may be some important lessons in that. The authors of RFC 7553 told me that informational should be considered normal for RR type definitions. The authoritative record is IANA and should be referenced instead of the informational RFC. >  - Perhaps we should have our own RR type.  In principle it's easy to >    add them, but: > >  - You've mentioned that many DNS hosters don't have UIs or support > for >    URI RRs.  This needs more research.  If adding support for new RR >    types is impossible because of this, then the DNS community at the >    IETF should be asked to address this, and we might need to use TXT >    RRs instead. > >    Using TXT RRs is frowned upon, and we'd never get an RFC on the >    Standards track using them today, but if the DNS community > confirms >    that adding new RR types is much harder than previously thought, > then >    TXT RRs will have to become the DNS extension mechanism to use >    instead of new RR types. > >    Ideally we could get the DNS hosters to support arbitrary RR > types. >    Yes, there is also a UI issue (see below), but it's manageable. > >  - If new RR types are the answer, then the DNS community needs to do >    something about UIs.  For example, there could be an XML schema >    defining RR types' RDATA contents and UI elements.  Then > implementors >    could automatically translate those to code to implement UIs for > new >    RR types. > >  - Can you research whether the DNS community at the IETF has > addressed >    these issues before? > >    If they have not, then we'll have to bring this up to them. > >    If they have, what was the outcome?  Have conditions in the market >    changed?  Should the IETF review these issues again? Yes. I'm working on this now. However, I'm less sure that UX designers will be keen to back a "generic record" interface. I do think it will be possible to get buy-in for URI records. >  - Can you ask some DNS hosters to inveigh as to whether they would > be >    willing to add arbitrary new RR types?  (Presumably with a UI that >    requires the user to paste base64-/hex-encoded RDATA.) > >    I think this research will be very valuable in reviewing this >    document, and perhaps using alternative designs (e.g., defining a > new >    RR type, or using TXT, or updating RFC7553 and perhaps promoting > it >    to Proposed Standard). I plan to ask some of the providers I know. >  - You might want to seek several ADs' input on this early.  The DNS >    issues here seem very real, and dealing with them may require help >    from the ADs.  The WG chairs might help with this. +1 From nobody Thu May 19 09:59:26 2016 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 1338212DAE0 for ; Thu, 19 May 2016 09:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 IU2motGAzsaQ for ; Thu, 19 May 2016 09:59:23 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3EEB12DADA for ; Thu, 19 May 2016 09:59:23 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 1B2B1584083; Thu, 19 May 2016 09:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=WPQ2PifJdtsj52 4spQOi/dg89TQ=; b=aRyVIEjvvu7xCIuZPZyEy+tAjJ24Fzh8ah6N8DucB0OAiH hDX8rQ2sdGm0pzEIXYsI0n5gYeCbNeUDAeEijutmpiQ1/ECs6mVm+SqzUeDhilTf yLHTXuddFsUtih6xObrOQsswy3YVdyF617fu4luotdo2V/5daAFZTp228ze3s= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id 44290584074; Thu, 19 May 2016 09:59:19 -0700 (PDT) Date: Thu, 19 May 2016 11:59:14 -0500 From: Nico Williams To: Nathaniel McCallum Message-ID: <20160519165913.GD19530@localhost> References: <1463500163.2432.9.camel@redhat.com> <20160519162545.GB19530@localhost> <1463676437.31173.36.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1463676437.31173.36.camel@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 16:59:25 -0000 On Thu, May 19, 2016 at 12:47:17PM -0400, Nathaniel McCallum wrote: > Agreed to a URI scheme. > > However, HTTP w/ GET is undefined and only exists in one codebase. It > also has some real idempotency and space limitation drawbacks. Idempotency is not an issue (the KDC exchanges are idempotent, with the sole exception of account lockout on N incorrect passwords, which is and always has been a very bad idea and which will not be relevant in any way once we have PAKE), but the URI size limitations are real. But this is a distraction. The point is that we have enough options to express, and that's why we need a URI scheme. > > - Can you research whether the DNS community at the IETF has > > addressed these issues before? > > > > If they have not, then we'll have to bring this up to them. > > > > If they have, what was the outcome? Have conditions in the market > > changed? Should the IETF review these issues again? > > Yes. I'm working on this now. However, I'm less sure that UX designers > will be keen to back a "generic record" interface. I do think it will > be possible to get buy-in for URI records. That seems probable, yes. > > - Can you ask some DNS hosters to inveigh as to whether they would > > be willing to add arbitrary new RR types? (Presumably with a UI > > that requires the user to paste base64-/hex-encoded RDATA.) > > > > I think this research will be very valuable in reviewing this > > document, and perhaps using alternative designs (e.g., defining a > > new RR type, or using TXT, or updating RFC7553 and perhaps > > promoting it to Proposed Standard). > > I plan to ask some of the providers I know. Thanks, Nico -- From nobody Thu May 19 10:37:07 2016 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 2C4D512DB2A for ; Thu, 19 May 2016 10:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 LYcoiofdpiqc for ; Thu, 19 May 2016 10:37:05 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ADAF12DAFE for ; Thu, 19 May 2016 10:37:05 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id E0F222005D105; Thu, 19 May 2016 10:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=mo+iEBxlTPn/65 GyL9nfSrAOcJM=; b=Ucxc454L6Y0UPlSclN8WLxuN93mpeVpYQGsgEV16RW3U1w S6rXfJc6m/oSyGRxuWLm/53XpqhezmsAQvSj4tZMt8IP5wFVOID+kHnF0t6T74wq OW7tc1iTpfz4HNHOiC/pu/WLk6KzWNh+NOqU3Zx952L66mlkJwejVDs3GLp40= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 363B720058D3E; Thu, 19 May 2016 10:36:56 -0700 (PDT) Date: Thu, 19 May 2016 12:36:43 -0500 From: Nico Williams To: Jeffrey Altman Message-ID: <20160519173642.GE19530@localhost> References: <1463500163.2432.9.camel@redhat.com> <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> <1463517801.2432.24.camel@redhat.com> <490bd7aa-81ca-9199-6687-222bb65caddf@secure-endpoints.com> <1463520360.2432.46.camel@redhat.com> <3911bb56-b9a1-a5e5-cc6c-c742f779536c@secure-endpoints.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3911bb56-b9a1-a5e5-cc6c-c742f779536c@secure-endpoints.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 17:37:06 -0000 On Tue, May 17, 2016 at 08:36:04PM -0400, Jeffrey Altman wrote: > And when the DNS URI record is not published or cannot be queried the > Kerberos library will have a 50% increase in the number of DNS lookups. That's a feature: the feature that will drive adoption :) Of course, some clients might have an option to not do this, but still, if you want fast, zero-conf discovery, you'll want to publish the URI RRs. Nico -- From nobody Fri May 20 00:26:48 2016 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 95D9C12D6C8 for ; Fri, 20 May 2016 00:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.328 X-Spam-Level: X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 sF1LMBFbhb1j for ; Fri, 20 May 2016 00:26:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEEF912D6BD for ; Fri, 20 May 2016 00:26:44 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7EB6581F07 for ; Fri, 20 May 2016 07:26:44 +0000 (UTC) Received: from pspacek.brq.redhat.com (vpn1-6-212.ams2.redhat.com [10.36.6.212]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4K7QgDS005576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 May 2016 03:26:43 -0400 To: kitten@ietf.org References: <1463500163.2432.9.camel@redhat.com> <20160519162545.GB19530@localhost> <1463676437.31173.36.camel@redhat.com> From: Petr Spacek Organization: Red Hat Message-ID: <9533fb26-6513-caca-efbc-158ebf6ca408@redhat.com> Date: Fri, 20 May 2016 09:26:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <1463676437.31173.36.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 20 May 2016 07:26:44 +0000 (UTC) Archived-At: Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 07:26:46 -0000 On 19.5.2016 18:47, Nathaniel McCallum wrote: > On Thu, 2016-05-19 at 11:25 -0500, Nico Williams wrote: >> On Tue, May 17, 2016 at 11:49:23AM -0400, Nathaniel McCallum wrote: >>> https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-disco >>> very >>> -02 >>> >>> I'd like to propose adoption of this draft: >>> >>> 1. It is in the scope of the WG. This is an extension to the >>> discovery >>> methods already defined in RFC 4120. >>> >>> 2. It is beneficial. It provides both speed improvments and >>> additional >>> functionality (discovery of MS-KKDCP proxies). >>> >>> 3. It is small. It avoids defining new: DNS names, DNS semantics, >>> URIs, >>> or transport semantics. It simply combines the existing tools in a >>> fairly obvious way. >>> >>> Thoughts? >> >> - If we use the URI RR type (and maybe even if we don't), we'll need >> a >> krbtgt URI scheme, as we have four different options to express, >> including two over HTTP: raw over TCP, raw over UDP, HTTP w/ POST, >> HTTP w/ GET. > > Agreed to a URI scheme. > > However, HTTP w/ GET is undefined and only exists in one codebase. It > also has some real idempotency and space limitation drawbacks. > > In contrast, MS-KKDCP (HTTP w/ POST) has a protocol definition and is > implemented by multiple vendors without the above drawbacks. > >> - We should find out why RFC7553 ended up being >> Informational. There >> may be some important lessons in that. > > The authors of RFC 7553 told me that informational should be considered > normal for RR type definitions. The authoritative record is IANA and > should be referenced instead of the informational RFC. > >> - Perhaps we should have our own RR type. In principle it's easy to >> add them, but: Any new RR type will be in worse position than URI because of reasons you stated below. >> - You've mentioned that many DNS hosters don't have UIs or support >> for >> URI RRs. This needs more research. If adding support for new RR >> types is impossible because of this, then the DNS community at the >> IETF should be asked to address this, and we might need to use TXT >> RRs instead. >> >> Using TXT RRs is frowned upon, and we'd never get an RFC on the >> Standards track using them today, but if the DNS community >> confirms >> that adding new RR types is much harder than previously thought, >> then >> TXT RRs will have to become the DNS extension mechanism to use >> instead of new RR types. >> >> Ideally we could get the DNS hosters to support arbitrary RR >> types. >> Yes, there is also a UI issue (see below), but it's manageable. >> >> - If new RR types are the answer, then the DNS community needs to do >> something about UIs. For example, there could be an XML schema >> defining RR types' RDATA contents and UI elements. Then >> implementors >> could automatically translate those to code to implement UIs for >> new >> RR types. Oh yes, this is my plan for some time already but it always gets lower priority than something else ... I would not wait for it :-) More importantly, there was literally no usage & demand for the URI record up to now. Adding new RR types to UI is trivial as soon as you have justification for the management, so the demand could simply solve the UI problem for the URI RR type. >> - Can you research whether the DNS community at the IETF has >> addressed >> these issues before? >> >> If they have not, then we'll have to bring this up to them. >> >> If they have, what was the outcome? Have conditions in the market >> changed? Should the IETF review these issues again? > > Yes. I'm working on this now. However, I'm less sure that UX designers > will be keen to back a "generic record" interface. I do think it will > be possible to get buy-in for URI records. > >> - Can you ask some DNS hosters to inveigh as to whether they would >> be >> willing to add arbitrary new RR types? (Presumably with a UI that >> requires the user to paste base64-/hex-encoded RDATA.) We have a standard for Handling of Unknown DNS RR Types: https://tools.ietf.org/html/rfc3597 It says that RDATA for unknown types should be typed in using hexadecimal notation: https://tools.ietf.org/html/rfc3597#section-5 Also, some servers/services simply lack UI (e.g. Windows Server 2003) but allow adding the record using standard DNS UPDATE protocol RFC 2136, which is also behavior mandated by RFC 3597. Petr Spacek @ Red Hat >> I think this research will be very valuable in reviewing this >> document, and perhaps using alternative designs (e.g., defining a >> new >> RR type, or using TXT, or updating RFC7553 and perhaps promoting >> it >> to Proposed Standard). > > I plan to ask some of the providers I know. > >> - You might want to seek several ADs' input on this early. The DNS >> issues here seem very real, and dealing with them may require help >> from the ADs. The WG chairs might help with this. > > +1 From nobody Fri May 20 00:37:41 2016 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 81A0B12D6CF for ; Fri, 20 May 2016 00:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.328 X-Spam-Level: X-Spam-Status: No, score=-8.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, 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 qjBdWj1e2Rc1 for ; Fri, 20 May 2016 00:37:38 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5E6712D6BD for ; Fri, 20 May 2016 00:37:38 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9AADF552D3 for ; Fri, 20 May 2016 07:37:38 +0000 (UTC) Received: from pspacek.brq.redhat.com (vpn1-6-212.ams2.redhat.com [10.36.6.212]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u4K7bbEm032603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 May 2016 03:37:38 -0400 To: kitten@ietf.org References: <1463500163.2432.9.camel@redhat.com> <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> <1463517801.2432.24.camel@redhat.com> From: Petr Spacek Organization: Red Hat Message-ID: <75ef03a4-fe85-2397-ae32-73487f913a14@redhat.com> Date: Fri, 20 May 2016 09:37:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <1463517801.2432.24.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 20 May 2016 07:37:38 +0000 (UTC) Archived-At: Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 07:37:40 -0000 On 17.5.2016 22:43, Nathaniel McCallum wrote: > On Tue, 2016-05-17 at 12:25 -0400, Jeffrey Altman wrote: >> On 5/17/2016 11:49 AM, Nathaniel McCallum wrote: >>> https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-disco >>> very >>> -02 >>> >>> I'd like to propose adoption of this draft: >>> >>> 1. It is in the scope of the WG. This is an extension to the >>> discovery >>> methods already defined in RFC 4120. >>> >>> 2. It is beneficial. It provides both speed improvments and >>> additional >>> functionality (discovery of MS-KKDCP proxies). >>> >>> 3. It is small. It avoids defining new: DNS names, DNS semantics, >>> URIs, >>> or transport semantics. It simply combines the existing tools in a >>> fairly obvious way. >>> >>> Thoughts? >>> >> >> Having read the draft I am totally unclear how it is implemented. >> >> _kerberos.REALM >> >> is not a valid DNS URI record name. To translate the URI >> >> https://host[:port][path] >> >> to an URI record requires >> >> _kerberos._https.host >> >> not >> >> _kerberos.host > > It doesn't actually require this. It just gives examples. More importantly, SRV records did not have any way to specify protocol so _proto label was only way to convey the information. In contrary, URI can convey information about protocol/scheme and thus artificial requirement for _proto label does not make sense. Also, RFC 2782's Applicability Statement clearly states that SRV records should be used only for applications which have own RFC describing its semantics. Considering URI vs. SRV properties mentioned above and the requirement for separate RFC, I think that Nathaniel's usage of URI records is justified and legal. Petr^2 Spacek >> DNS URI records according to RFC 7553 work just like DNS SRV records >> in >> that they require both a service name and a protocol name. Switching >> to >> URI records does not solve the problem of multiple DNS queries. >> >> To find a KDC that supports https, use the DNS SRV record >> >> _kerberos._https.REALM > > _https isn't a thing. You'd have to do something like: _http._tls._tcp. > >> registering additional service types such as "kpasswd" can be done >> but >> the fact is implementations such as Heimdal already perform SRV >> lookups for >> >> _kpasswd,_tcp.REALM and _kpasswd._udp.REALM > > At the cost of one DNS query per transport. Further, administrators > have no control over the weights or priorties between transports. My > draft provides this. > >> Can you make a case for something that DNS URI records provides that >> DNS >> SRV records do not? > > Yes. MS-KKDCP requires a path. SRV records cannot provide a path. > >> The introduction of DNS URI records will only mean that in practice >> that >> Kerberos client libraries will need to issue the DNS URI queries in >> addition to the existing DNS SRV records. > > We will need to add at least one more DNS query to support MS-KKDCP > (two if we have to treat http and https as separate queries). This is > unavoidable. While it is true that this will result in a 50% increase > in DNS queries, using my URI scheme means that a simple administrator > configuration can turn this 50% increase into a 50% decrease in queries > over the existing implementations. This is a win. From nobody Fri May 20 02:58:45 2016 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 8270612DBD0 for ; Fri, 20 May 2016 02:58:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160520095844.8857.29611.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2016 02:58:44 -0700 Archived-At: Subject: [kitten] Confirm email address for Colin Wong X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 09:58:44 -0000 Hello, We have received a request to add the email address 'kitten@ietf.org' to the user account 'ttobelgoog@gmail.com' at 'datatracker.ietf.org'. If you requested this change, please confirm that this is your email address by clicking on following link: https://datatracker.ietf.org/accounts/add_email/confirm/ttobelgoog%40gmail.com/20160520/kitten%40ietf.org/9771da3b6f3eb6d1902c09ba9e347800/ This link will expire in 3 days. If you did not request this change, you may safely ignore this email, as no actions have been taken. Best regards, The datatracker login manager service (for the IETF Secretariat) From nobody Fri May 20 08:06:36 2016 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 94DA912D0B3 for ; Fri, 20 May 2016 08:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 C0msqeB0MB-7 for ; Fri, 20 May 2016 08:06:34 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA54512B018 for ; Fri, 20 May 2016 08:06:33 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 93176200D570A; Fri, 20 May 2016 08:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ZrpzzKYQ2xFtTU KHPot54l5pwEU=; b=yG+G1gnNSjomj4rZm8VhcHNf4n0b1gTCOI86OobDJ0Wo13 +rmY0aBqE3raQBbIu23iu5FCsjFnmEyLExnGGGiJh4Db6HYfHKuucpuljQ76tvV7 8n7KF3bsYCYd78OIoHdJ/IgkC+4HDnmWdkn/S1QwS+l8Y7ieDeV3CykQQG7jg= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 3CAC4200D5708; Fri, 20 May 2016 08:06:32 -0700 (PDT) Date: Fri, 20 May 2016 10:06:31 -0500 From: Nico Williams To: Petr Spacek Message-ID: <20160520150629.GH19530@localhost> References: <1463500163.2432.9.camel@redhat.com> <20160519162545.GB19530@localhost> <1463676437.31173.36.camel@redhat.com> <9533fb26-6513-caca-efbc-158ebf6ca408@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9533fb26-6513-caca-efbc-158ebf6ca408@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 15:06:35 -0000 On Fri, May 20, 2016 at 09:26:42AM +0200, Petr Spacek wrote: > On 19.5.2016 18:47, Nathaniel McCallum wrote: > > On Thu, 2016-05-19 at 11:25 -0500, Nico Williams wrote: > >> - Perhaps we should have our own RR type. In principle it's easy to > >> add them, but: > > Any new RR type will be in worse position than URI because of reasons you > stated below. Exactly. > >> - If new RR types are the answer, then the DNS community needs to do > >> something about UIs. For example, there could be an XML schema > >> defining RR types' RDATA contents and UI elements. Then > >> implementors could automatically translate those to code to > >> implement UIs for new RR types. > > Oh yes, this is my plan for some time already but it always gets lower > priority than something else ... I would not wait for it :-) Er, OK, how do we help you implement it? :) > More importantly, there was literally no usage & demand for the URI > record up to now. Adding new RR types to UI is trivial as soon as you > have justification for the management, so the demand could simply > solve the UI problem for the URI RR type. Well, I hope so! The UI for URI is going to be very similar to the UI for SRV. A machine-readable description of what the UI should be for each RR type would have made this problem a non-problem, and might yet. > >> - Can you ask some DNS hosters to inveigh as to whether they would > >> be willing to add arbitrary new RR types? (Presumably with a UI > >> that requires the user to paste base64-/hex-encoded RDATA.) > > We have a standard for Handling of Unknown DNS RR Types: > https://tools.ietf.org/html/rfc3597 > > It says that RDATA for unknown types should be typed in using hexadecimal > notation: > https://tools.ietf.org/html/rfc3597#section-5 Thanks. > Also, some servers/services simply lack UI (e.g. Windows Server 2003) > but allow adding the record using standard DNS UPDATE protocol RFC > 2136, which is also behavior mandated by RFC 3597. That's nice, but the services that Nathaniel is concerned about probably don't support DNS UPDATEs. That's another thing. Implementations that support DNS UPDATE often don't have useful authorization models, leading enterprises often to having to write proxies [that invariably do not themselves speak DNS UPDATE]. I'm not sure that a standard can help there, but I think it might. One idea would be to associate authorization attributes to each RR type and RRset name pattern so that the DNS server could evaluate the DNS UPDATE client's authorization to perform a given operation. E.g., the owner(s) of a given domainname (should ownership and/or ACLs be expressible within DNS?) might get to manage associated SRV RRsets, and maybe (subject to site-local policy) add/delete CNAMEs pointing to that name, but maybe not modify the A/AAAA RRsets -- the "associated" bit would be nice if it were expressed in a standard, while which operations are allowed should be locally expressible based on simple labels for each association, say. Nico -- From nobody Fri May 20 08:14:12 2016 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 565A412D9CB for ; Fri, 20 May 2016 08:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 7LYq2aFqb-5O for ; Fri, 20 May 2016 08:14:10 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CF1A12D9C9 for ; Fri, 20 May 2016 08:14:10 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id C55766B0083; Fri, 20 May 2016 08:14:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=tO7uNy0h2pUVqT BUpuccm+veypI=; b=UrTxZkUL9Wstc6jhXf0wh/yKTcTRALOoY7rssuBCQ6V7i6 Mf1t5JJ0LOb1yugtwixRe/7WvQ2VoX656zAWWQX4WD7x506hJVpyIY7qboufNs3B D8tqgyrr4lkiAumytHGdcqmFVwvb8dWrGOEfJm5JVzzPyG4kzpPJ1LQjBHx0Q= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 67E216B0070; Fri, 20 May 2016 08:14:04 -0700 (PDT) Date: Fri, 20 May 2016 10:14:02 -0500 From: Nico Williams To: Petr Spacek Message-ID: <20160520151402.GI19530@localhost> References: <1463500163.2432.9.camel@redhat.com> <54c900f2-399c-0ff0-c292-91baba495a21@secure-endpoints.com> <1463517801.2432.24.camel@redhat.com> <75ef03a4-fe85-2397-ae32-73487f913a14@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <75ef03a4-fe85-2397-ae32-73487f913a14@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 15:14:11 -0000 On Fri, May 20, 2016 at 09:37:36AM +0200, Petr Spacek wrote: > On 17.5.2016 22:43, Nathaniel McCallum wrote: > > On Tue, 2016-05-17 at 12:25 -0400, Jeffrey Altman wrote: > >> On 5/17/2016 11:49 AM, Nathaniel McCallum wrote: > >> Having read the draft I am totally unclear how it is implemented. > >> > >> _kerberos.REALM > >> > >> is not a valid DNS URI record name. To translate the URI > >> > >> https://host[:port][path] > >> > >> to an URI record requires > >> > >> _kerberos._https.host > > > > It doesn't actually require this. It just gives examples. It doesn't have any normative language about it, so I agree. But worryingly, section 4.1 says that "[t]he URI owner name is subject to special conventions." I wouldn't want to be told late in the game that this made this section normative! (It can't, since normative language is used elsewhere, its non-use here seems clearly definitive to me.) > More importantly, SRV records did not have any way to specify protocol so > _proto label was only way to convey the information. > > In contrary, URI can convey information about protocol/scheme and thus > artificial requirement for _proto label does not make sense. Yes, this should seem obvious to all. So why did section 4 even mention protocols?? > Also, RFC 2782's Applicability Statement clearly states that SRV > records should be used only for applications which have own RFC > describing its semantics. > > Considering URI vs. SRV properties mentioned above and the requirement > for separate RFC, I think that Nathaniel's usage of URI records is > justified and legal. Thanks. I'm in favor of adopting this document and the use of the URI RR type, with one URI RRset per-realm, not one per-{realm, protocol}, and with a URI scheme or two by which to express all those things that we need to. Nico -- From nobody Fri May 20 09:05:16 2016 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 B90D412DD5F for ; Fri, 20 May 2016 09:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" 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 kaRafE16wD7x for ; Fri, 20 May 2016 09:05:13 -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 530E312DD6D for ; Fri, 20 May 2016 09:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1463760234; x=1464365034; 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=xpqQvFfW0PMOk2jbhJK9UG pE1O1Hb4jned3MS46uMCw=; b=lRgh45F6QZ89dZkeDceYbEUIQacK90zrm7xlLM B+Vvz04R2f2bzaZY0F9I9BnCnUHlxvR6Drdhv5foO0UAppw/A7dIeXoVIuxvxLi9 K5K7wefVygEuh5lJHrF6gFDjf6UDe5bG+K3AhA/peL30SlFRjujI3guyI714lyry 5fhYg= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Fri, 20 May 2016 12:03:54 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Fri, 20 May 2016 12:03:53 -0400 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v16.0.2) with ESMTPSA id md50001091360.msg for ; Fri, 20 May 2016 12:03:52 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDArrival-Date: Fri, 20 May 2016 12:03:52 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1948c7937e=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org To: kitten@ietf.org References: <20160520095844.8857.29611.idtracker@ietfa.amsl.com> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: Date: Fri, 20 May 2016 12:03:52 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160520095844.8857.29611.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050506030900000402080208" Archived-At: Subject: Re: [kitten] Confirm email address for Colin Wong X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2016 16:05:14 -0000 This is a cryptographically signed message in MIME format. --------------ms050506030900000402080208 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The ietf-secretary has been notified and has removed kitten@ietf.org from the user's Data Tracker account. Jeffrey Altman On 5/20/2016 5:58 AM, IETF Secretariat wrote: >=20 > Hello, >=20 > We have received a request to add the email address 'kitten@ietf.org' > to the user account 'ttobelgoog@gmail.com' at 'datatracker.ietf.org'.=20 > If you requested this change, please confirm that this is your email > address by clicking on following link: >=20 > https://datatracker.ietf.org/accounts/add_email/confirm/ttobelgoog%4= 0gmail.com/20160520/kitten%40ietf.org/9771da3b6f3eb6d1902c09ba9e347800/ >=20 > This link will expire in 3 days. >=20 > If you did not request this change, you may safely ignore this email, > as no actions have been taken. >=20 > Best regards, >=20 > The datatracker login manager service > (for the IETF Secretariat) >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 >=20 >=20 --------------ms050506030900000402080208 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 DFkwggYVMIIE/aADAgECAhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBCwUAMIGmMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5 bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3 MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH NTAeFw0xNTEyMjAwMDAwMDBaFw0xNjEyMjAyMzU5NTlaMIGvMS4wLAYDVQQDDCVQZXJzb25h IE5vdCBWYWxpZGF0ZWQgLSAxNDUwNTc0MTU1Njc5MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFu QHNlY3VyZS1lbmRwb2ludHMuY29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNv bmEgTm90IFZhbGlkYXRlZDEfMB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM0X8uixbo9Tu+sKS20bZeCbN9brFQbtkQ5x /6MrkGsQNTzQ/2WZFJzH89ZoC8auZRFQdA6/yh4wXdCNQ6hBO8Lom26t0LHGhoWtzdkP7MWu YeLMZiuOsC6N6ejHEbtt0KLjphNIUvBVFx5JQzgAwJ1I08LSZg/bIGAVF3SfLOVFu2Iiq5kj psHOv/ECV13fGSvYwBXJN1C1To6wxDgn4pl3m6fFfe4xiVEpc3t6GbKcI+4blK9w76fDaVXw U2uJQAG1UYxbChwocBmb3ka1MlUb2ug3oYBpnufD9zk8u3UqaFlfYyr6/2cr6fqiz1U4+xcb Q3otvVWwzRecpmPEiIcCAwEAAaOCAjIwggIuMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQD AgWgMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU2Pc1OxE6 W8hcBZ5L2346cucbFa8wJwYDVR0RBCAwHoEcamFsdG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNv bTBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20v cnBhMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzU3 ZGU3YTIzOGQ0NWQ4ZDRmYzcxZjhhNWM2YjgxYzkzL0xhdGVzdENSTC5jcmwwTgYIKwYBBQUH AQEEQjBAMD4GCCsGAQUFBzAChjJodHRwOi8vY2FjZXIuc3ltYXV0aC5jb20vbXBraS9zeW1j YzFpbmRzdWJjYWc1LmNydDAfBgNVHSMEGDAWgBRnGbY9pXm7M2DYLVPTjAk9B6wYcDArBgpg hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGt7pITFgUxMDkyMjA5BgpghkgBhvhFARAF BCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3 DQEBCwUAA4IBAQBvO/+L6Tms91Ed1ZJzgT0y9jBK/Armb6Y/EnR1swCDMqRfBzGSGtzOCuN7 PteBvlaB5vmnwEwiZR/FtsDhhORd8Xy5wdmCunhwPbf0ClnBqichI+4UZNS5fCQTciIqHFxq 7EKuHOQm4/ssEH2Xr8yIpCd+Dx9oPEG7MqUno6oxcIDdur4iNKxOBtjWNiXM7rn733qtuFlw 1jIX3eFIsrBALikTU1UbY2KwfewXbiVaFWY0ysl5uOgfWdmj2xBk7aft/L/fnuyWyeeM9IBg 6vdUjPhmJwtFdEdefgP5cRRdYgG8zgJf8Rq84slkea0bwis8PvKVksJ/k2scaDHzKTe2MIIG PDCCBSSgAwIBAgIQBwKiGoW4S2WeGApu5vWjZTANBgkqhkiG9w0BAQsFADCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMTUxMDAxMDAwMDAwWhcNMjUw OTMwMjM1OTU5WjCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0 aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW+w0x SSLADLrvTi0XuLQw5TTSrAnuyYkAXfSuExGzE45VzyIYqCAGpv0ly2iUtKCCkA5ulpJE7hW5 tOz6z3k9adScH9wgmg4o1Q21xp468dRlGcCEM02O2orx1ie5A6DR+iicgpNs9w2FfVvpTpli /pNC0u4+s3FXhpdGy98N4caEWrMNj/X0EIoFXZ9oRuwIsFhCgva+LRBGpiQLJ/6YFFODk4Lb 6sA/T6JYYbVLcmkSXzNZ9vmzTABkzoXFhpIMbhzrKM9xqZCpdJl0JOtI4Q5daBKoAWbo7pqy L/g9zbd4JM6lYHzoFj1J8Qe6M74yK8JnoxbHb8DSWpQEwmtFAgMBAAGjggI+MIICOjA3Bggr BgEFBQcBAQQrMCkwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTAS BgNVHRMBAf8ECDAGAQH/AgEAMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEF BQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDov L3d3dy5zeW1hdXRoLmNvbS9ycGEwLwYDVR0fBCgwJjAkoCKgIIYeaHR0cDovL3Muc3ltY2Iu Y29tL3BjYTEtZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRU3ltYW50ZWNQS0ktMi0yMTcwHQYDVR0OBBYEFGcZtj2lebszYNgtU9OMCT0HrBhwMIHx BgNVHSMEgekwgeahgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5 OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQsFAAOCAQEARhnkJ3U7vq/i 2qIUYI8eRJCBaStjSTWN6Xa6n5iPE4HXy/xlG/gOY96UKHT742/YySp6DlSmg64pSvYrUf09 OBK73WNF+2TMPlSGf05CbSO3HQv9+swNjpM1yuVF+c8vf3k9YxjHRyNK9qkUAK1+WVUaiSfb lKCROMb+QJWjYPZduMjFFu2cZmkURhBKynAqb9FQ4CYa01K0R3KLRdK9A7ml3NkI85CrdHCr yqBO8MBO5OC+T5ARYCcMKxzf52zKdbQl55FIqpK0UXVfKZtHFxy9yerPda11I8/yxd9aq7dr yru4XqvVo3DUaPMXepsLoBQ8++iBVmjoz118c7guvDGCBGIwggReAgEBMIG7MIGmMQswCQYD VQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNQIQ cBGDX/fzAS3ijWWeve3D7zANBglghkgBZQMEAgEFAKCCAncwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNTIwMTYwMzUyWjAvBgkqhkiG9w0BCQQxIgQg sy5M+VT0bASQT2jaa1NNl4VG3YLIafWdkUUdoH8BKTMwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7 MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHNQIQcBGDX/fzAS3ijWWeve3D7zCBzgYLKoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3lt YW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1 AhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBAQUABIIBAFgwhnctyST7YbvPNA7Y1B2m QQx9ReHbdS8zuhlkhhguNw5ByyypbfFeLa2A2LQhCjm1bR3vO3TjxJCi0/65KNDUillAOEiP GXN4wbeFZVvUqDg2+6wtJCgAXr7buvecRZxgdsutqnZDycmD6LMJGH3S8eFfU7Kbu9//ydxS up6nA5utpoObGuJcRBaDgwrmcbESEP1pjpj/GC+hZUpKVIkHbnzKn5ZrbERPt9oPfa4APHpS b7NsCn0hmQNGib1GYeWsZiVHVPAP4TlVras+OqxKmudQMiw43ck3Mi5FalDrYPC30xE9Koyn /+sGPq8S4WXeOfMaWCMBpjhLNthoNiQAAAAAAAA= --------------ms050506030900000402080208-- From nobody Mon May 23 14:50:25 2016 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 5F01912D5A6; Mon, 23 May 2016 14:50:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160523215024.20285.52976.idtracker@ietfa.amsl.com> Date: Mon, 23 May 2016 14:50:24 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 21:50: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 : Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) Freshness Extension Authors : Michiko Short Seth Moore Paul Miller Filename : draft-ietf-kitten-pkinit-freshness-07.txt Pages : 8 Date : 2016-05-23 Abstract: This document describes how to further extend the Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) extension [RFC4556] to exchange an opaque data blob that a KDC can validate to ensure that the client is currently in possession of the private key during a PKINIT AS exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-freshness/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-pkinit-freshness-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-freshness-07 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 Mon May 23 14:50:44 2016 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 2BD3212D177 for ; Mon, 23 May 2016 14:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 V6vZll4J78TO for ; Mon, 23 May 2016 14:50:31 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0773.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:773]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF59712D5B6 for ; Mon, 23 May 2016 14:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WCQQwZqCeUOVinyaQMr3by+WmcY1bbwtsCrm98oYKUg=; b=QvJDO5OkNw8KGcJ2T/uM3f3Gv1O4kMzHfB9w4xu05gk0Zel5bjgiTEw6NV8yflUCrIt6MkCXaE+c58p4ni3fb+Pocq3zcK6n0FRWJn9DxnUdS2NCIQ2ZtzhIL5BWrMjqmz39TrXGaUrnnIm1upEJ8KPq6iGgbAI3uAyVDHthH1o= Received: from BY1PR03MB1417.namprd03.prod.outlook.com (10.162.127.147) by BY1PR03MB1419.namprd03.prod.outlook.com (10.162.127.149) with Microsoft SMTP Server (TLS) id 15.1.497.12; Mon, 23 May 2016 21:50:06 +0000 Received: from BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) by BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) with mapi id 15.01.0497.019; Mon, 23 May 2016 21:50:06 +0000 From: Michiko Short To: Greg Hudson , Benjamin Kaduk Thread-Topic: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-06 Thread-Index: AQHRmzbcnmT+dbhq5EmhPXXI/KiBHJ/HH3iA Date: Mon, 23 May 2016 21:50:06 +0000 Message-ID: References: <5717A72A.6060406@mit.edu> In-Reply-To: <5717A72A.6060406@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:4::75d] x-ms-office365-filtering-correlation-id: 98a54605-b0f7-4d97-10f8-08d38354342a x-microsoft-exchange-diagnostics: 1; BY1PR03MB1419; 5:cJe9tcSQ/0JTN/y0deHWJs/79JC3LWX5gDO0gA3SBlZ1KdYnRswHpQdkrkbGXJaL1REbSWusgs2dSDxe7V40tq82sai0hv1yfVCQRSZZx0mCoXhTpVbL0BkckLoprxlky8bUaVpaQUJgOMcqrz/MDw==; 24:qzWKMa3W/3iadlO6rm9HIw+aL14LM00d5YdPLZ7mx74rbcpyxTsPt5upa4y2/c2Xru0MuYVVkrKu8RRFvbqd7ot3uQ+po7bicf6XrjrLNzQ=; 7:tD7Fqop6yXbnBCAFBPHggLWQlM/yOSCAQvbieT4XBPSIAZVyo2o/hXlnX4CRB7h7OJtSivqlwwxuoNVMWJgpNa6NaURAlzxY/5GLV4fhs1YCevzNg8Vq+4Z7TLfYxZ49WX4f/vUoeTxPnsa+rOb5D/H3500J+bubkdSIzYS0PjzFLWvC0tWPqMk3SRBTbhhLUQWq93oxplmgw6jUtqE5qg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR03MB1419; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BY1PR03MB1419; BCL:0; PCL:0; RULEID:; SRVR:BY1PR03MB1419; x-forefront-prvs: 0951AB0A30 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(13464003)(54356999)(10290500002)(586003)(5005710100001)(6116002)(19580405001)(1220700001)(102836003)(106116001)(92566002)(19580395003)(10400500002)(5002640100001)(86612001)(4326007)(3280700002)(50986999)(81166006)(76576001)(8676002)(76176999)(33656002)(122556002)(8936002)(99286002)(5003600100002)(2900100001)(2950100001)(5008740100001)(230783001)(189998001)(77096005)(11100500001)(87936001)(2171001)(10090500001)(74316001)(2906002)(5004730100002)(86362001)(5001770100001)(9686002)(3660700001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR03MB1419; H:BY1PR03MB1417.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2016 21:50:06.4410 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB1419 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 21:50:42 -0000 Publishing version 7 of the draft which includes the IANA number assigned 1) In section 2, step 1 should say "Section 2.9.3 of [RFC4120]" as in the o= ther references; currently it is missing "of". Searched and fixed Section references with missing "of" 2) Section 2.3 should make a forward reference to section 4. Added 3) In section 8 paragraph 1, "KDC provided" should be "KDC-provided". Fixed 4) In section 8 paragraph 2, there should be a comma between "KDCs" and "de= pending." I would also remove the quotes around "freshness". Fixed 5) In section 8 paragraph 3, the construction "allowing both X as well as Y= " is not grammatical. It should either be "allowing both X and Y" or "allo= wing X as well as Y". Also, there should be a "the" before "existing risks= ". Fixed 6) Numeric Google search results suggest "implementor" over "implementer," = but I don't know what the RFC editor's preference is. Looks like "er" is American English and "or" is British. Since the doc is w= ritten in American English I left as is. If the editor prefers British then= they can fix all the American spellings. Honestly, being American and havi= ng studied English in American schools, I don't what they all would be and = I prefer to be consistent.=20 -----Original Message----- From: Greg Hudson [mailto:ghudson@mit.edu]=20 Sent: Wednesday, April 20, 2016 8:59 AM To: Benjamin Kaduk Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-pkinit-freshness-06 On 04/14/2016 11:12 PM, Benjamin Kaduk wrote: > This message begins the second Working Group Last Call (WGLC) of=20 > "Public Key Cryptography for Initial Authentication in Kerberos=20 > (PKINIT) Freshness Extension". I re-read this draft and found only minor editorial issues: * In section 2, step 1 should say "Section 2.9.3 of [RFC4120]" as in the ot= her references; currently it is missing "of". * Section 2.3 should make a forward reference to section 4. * In section 8 paragraph 1, "KDC provided" should be "KDC-provided". * In section 8 paragraph 2, there should be a comma between "KDCs" and "dep= ending." I would also remove the quotes around "freshness". * In section 8 paragraph 3, the construction "allowing both X as well as Y"= is not grammatical. It should either be "allowing both X and Y" or "allow= ing X as well as Y". Also, there should be a "the" before "existing risks"= . * Numeric Google search results suggest "implementor" over "implementer," b= ut I don't know what the RFC editor's preference is. "implementer" is used twice in the draft.