From sacadmin Mon Dec 11 10:41:27 2006 Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBBIfQvw018991 for ; Mon, 11 Dec 2006 10:41:26 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id kBBIjbVx011258; Mon, 11 Dec 2006 10:45:37 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id kBBIjaum011257; Mon, 11 Dec 2006 10:45:36 -0800 (PST) Date: Mon, 11 Dec 2006 10:45:36 -0800 (PST) From: Gary Winiger Message-Id: <200612111845.kBBIjaum011257@marduk.eng.sun.com> To: psarc@sac.sfbay.sun.com Subject: PSARC/2006/690 Kerberos client configuration improvements Cc: Mark.Phalan@sun.com, krb5-core@sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 4879 I'm sponsoring this fast track for Mark Phalan and the Kerberos project team. The goal of the proposal is to remove the need for explicit client configuration by changing default values to do explicit DNS lookup for the KDC, improving Kerberos realm lookup logic and removing the install time Kerberos configuration questions (sysidkrb5). The Kerberos client configuration is kept in krb5.conf(4) which is documented as Evolving (Committed). This project does not make any incompatible syntax changes. The documented interface taxonomy does not define the default values of the administrative interface. The proposal describes the rationale for each of the proposed changes. krb5.conf interface taxonomy remains Committed, the project requests a patch release binding. A current kclient(1M) man page and a diff marked krb5.conf(4) man pages are in the case directory. Sysidkrb5 appears undocumented and therefore an implementation artifact. The timer is set for 18 Dec, 2006. Gary.. ++++++++++++++ Proposal: ========= 1. Changing the code default for "dns_lookup_kdc" configuration parameter from "false" to "true". "dns_lookup_kdc" which can be specified in krb5.conf(4) indicates whether DNS should be queried for the location of the default Key Distribution Center (KDC). Kerberos is dependent on DNS; enabling this option does not introduce any extra security risks. This will have no effect on existing Kerberos configurations where the KDC has been listed. MIT and Apple both default to "dns_lookup_kdc" being "true". 2. Adding better Kerberos realm lookup logic to the Kerberos mech rather than enabling "dns_lookup_realm." If the realm cannot be determined then fall-back logic is invoked which walks through the domain name components and if a KDC can be located for a realm constructed from that part of the domain name then that realm will be returned. The project does NOT propose to enable "dns_lookup_realm" by default. Enabling "dns_lookup_realm" - an existing configuration parameter which indicates whether DNS should be queried for the realm is another means for determining the realm. "dns_lookup_realm" introduces a security risk: in a cross-realm scenario it could be possible to divert someone into accessing a service on a compromised system. Both the lookup of the default realm and the realm part of a service principal are affected. 3. Removing the install-time Kerberos configuration panel (sysidkrb5) The current Kerberos configuration tool invoked at install-time (sysidkrb5) does not do a good job of fully configuring Kerberos on a system. For e.g. it does not check or deal with the DNS nameservice configuration on which Kerberos is dependent. With the changes for 1 and 2 no explicit configuration is required in a suitably configured network environment. If configuration is required a more advanced and complete tool is available for system administrators: kclient(1M). krb5.conf(4): [libdefaults] The [libdefaults] section can contain any of the following relations: dns_lookup_kdc Indicates whether DNS SRV records need to be used to locate the KDCs and the other servers for a realm, if they have not already been listed in the [realms] sec- - tion. Enabling this option does make the machine vulner- - able to a certain type of DoS attack if somone spoofs + tion. This option makes the machine vulnerable to + a certain type of DoS attack if someone spoofs the DNS records and does a redirect to another server. This is, however, no worse than a DoS, since the bogus KDC is unable to decode anything sent (excepting the initial ticket request, which has no encrypted data). Also, anything the fake KDC sends out isl not trusted without verification (the local machine is unaware of the secret key to be used). If dns_lookup_kdc is not specified but dns_fallback is, then that value is used instead. In either case, values (if present) in the [realms] section override DNS. + dns_lookup_kdb is enabled by default. dns_lookup_realm Indicates whether DNS TXT records need to be used to determine the Kerberos realm information and/or the host/domain name-to-realm mapping of a host, if this information is not already present in the krb5.conf file. Enabling this option might make the host vulner- able to a redirection attack, wherein spoofed DNS replies persuade a client to authenticate to the wrong realm. In a realm with no cross-realm trusts, this a DoS attack. If dns_lookup_realm is not specified but dns_fallback is, then that value is used instead. In either case, values (if present) in the [libdefaults] and [domain_realm] sections override DNS. From sacadmin Tue Dec 12 06:16:08 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBCEG8W3023966 for ; Tue, 12 Dec 2006 06:16:08 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id kBCEG7X2005908 for ; Tue, 12 Dec 2006 06:16:08 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kBCEG1m0013267 for ; Tue, 12 Dec 2006 14:16:02 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JA500L01ZLCGV00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 12 Dec 2006 14:16:01 +0000 (GMT) Received: from [192.168.73.101] (nessieroo.force9.co.uk [81.174.224.49]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JA5000TMZMN1N30@d1-emea-09.sun.com>; Tue, 12 Dec 2006 14:16:00 +0000 (GMT) Date: Tue, 12 Dec 2006 14:15:59 +0000 From: Darren J Moffat Subject: Re: PSARC/2006/690 Kerberos client configuration improvements In-reply-to: <200612111845.kBBIjaum011257@marduk.eng.sun.com> Sender: Darren.Moffat@Sun.COM To: Gary Winiger Cc: psarc@sac.sfbay.sun.com, Mark.Phalan@Sun.COM, krb5-core@Sun.COM Message-id: <457EB99F.6090401@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200612111845.kBBIjaum011257@marduk.eng.sun.com> User-Agent: Thunderbird 1.5.0.8 (X11/20061127) Status: RO Content-Length: 1780 Yeah!!!!! Especially the removal of sysikrb5. In PSARC/2002/411 which introduced the DNS lookup capability we had this text in the proposal: > 3. Risks & Assumptions > > Using DNS for lookups may allow additional types of denial of > service attacks, via spoofing of DNS records. Although an > attacker can redirect a Kerberos client to a KDC controlled > by the attacker, the Kerberos protocol prevents the > attacker's KDC from aquiring the client's secret key and thus > cannot issue a Kerberos ticket that the client will accept. > > Also when using DNS to lookup the realm information, a redirection > attack is a possibility, where spoofed DNS replies persuade a > Kerberos client to authenticate to the wrong realm. Depending on > how the client software manages hostnames, it may already be > vulnerable to such attacks. > > Pls refer the "Security considerations" section in the Internet draft > draft-ietf-krb-wg-krb-dns-locate-03.txt for more details. As I understand section 2 of this proposal that still stands and this case provides a more secure alternative that is protected by the description in para one of that set of risks outlined in 2002/411. Just so I understand the new algorithm properly it means we will do something like this: if the domain is: lab.sfbay.sun.com Look first for KDC for realm LAB.SFBAY.SUN.COM then look for KDC for realm SFBAY.SUN.COM then finally look for SUN.COM What domain name are we talking about here and how does this case determine what it is ? The reason I ask is because I believe that kclient(1M) currently gets this wrong because it parses /etc/resolv.conf looking for the domain entry. -- Darren J Moffat From sacadmin Tue Dec 12 13:57:44 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBCLviM3010521 for ; Tue, 12 Dec 2006 13:57:44 -0800 (PST) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id kBCLvinF028563 for ; Tue, 12 Dec 2006 13:57:44 -0800 (PST) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kBCLviO1015585 for ; Tue, 12 Dec 2006 14:57:44 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JA600801K6F0L00@mail-amer.sun.com> (original mail from Shawn.Emery@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 12 Dec 2006 14:57:44 -0700 (MST) Received: from [129.150.48.133] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JA600C4VL058VB2@mail-amer.sun.com>; Tue, 12 Dec 2006 14:57:43 -0700 (MST) Date: Tue, 12 Dec 2006 14:56:29 -0700 From: Shawn M Emery Subject: Re: PSARC/2006/690 Kerberos client configuration improvements In-reply-to: <457EB99F.6090401@Sun.COM> Sender: Shawn.Emery@Sun.COM To: Darren J Moffat Cc: Gary Winiger , psarc@sac.sfbay.sun.com, Mark.Phalan@Sun.COM, krb5-core@Sun.COM Message-id: <457F258D.3090207@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200612111845.kBBIjaum011257@marduk.eng.sun.com> <457EB99F.6090401@Sun.COM> User-Agent: Thunderbird 1.5.0.8 (X11/20061110) Status: RO Content-Length: 2107 Darren J Moffat wrote: > Yeah!!!!! Especially the removal of sysikrb5. > > In PSARC/2002/411 which introduced the DNS lookup capability we had > this text in the proposal: > >> 3. Risks & Assumptions >> >> Using DNS for lookups may allow additional types of denial of >> service attacks, via spoofing of DNS records. Although an >> attacker can redirect a Kerberos client to a KDC controlled >> by the attacker, the Kerberos protocol prevents the >> attacker's KDC from aquiring the client's secret key and thus >> cannot issue a Kerberos ticket that the client will accept. >> >> Also when using DNS to lookup the realm information, a >> redirection >> attack is a possibility, where spoofed DNS replies persuade a >> Kerberos client to authenticate to the wrong realm. Depending on >> how the client software manages hostnames, it may already be >> vulnerable to such attacks. >> Pls refer the "Security considerations" section in the Internet >> draft >> draft-ietf-krb-wg-krb-dns-locate-03.txt for more details. > > > As I understand section 2 of this proposal that still stands and this > case provides a more secure alternative that is protected by the > description in para one of that set of risks outlined in 2002/411. > > Just so I understand the new algorithm properly it means we will do > something like this: > > if the domain is: lab.sfbay.sun.com > > Look first for KDC for realm LAB.SFBAY.SUN.COM > then look for KDC for realm SFBAY.SUN.COM > then finally look for SUN.COM > > What domain name are we talking about here and how does this case > determine what it is ? > > The reason I ask is because I believe that kclient(1M) currently gets > this wrong because it parses /etc/resolv.conf looking for the domain > entry. Yes, this easily breaks if only the search directive is defined. A couple of possible solutions for this: 1. call sysinfo with the SI_SRPC_DOMAIN command. 2. try to resolve the local host name through DNS to derive the domain name. Shawn. -- From sacadmin Tue Dec 12 14:10:57 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBCMAvpo011448 for ; Tue, 12 Dec 2006 14:10:57 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kBCMAqol009126; Tue, 12 Dec 2006 16:10:52 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kBCMAml1009125; Tue, 12 Dec 2006 16:10:48 -0600 (CST) Date: Tue, 12 Dec 2006 16:10:48 -0600 From: Nicolas Williams To: Shawn M Emery Cc: Darren J Moffat , Gary Winiger , psarc@sac.sfbay.sun.com, Mark.Phalan@sun.com, krb5-core@sun.com Subject: Re: PSARC/2006/690 Kerberos client configuration improvements Message-ID: <20061212221048.GZ26175@binky.Central.Sun.COM> Mail-Followup-To: Shawn M Emery , Darren J Moffat , Gary Winiger , psarc@sac.sfbay.sun.com, Mark.Phalan@Sun.COM, krb5-core@sun.com References: <200612111845.kBBIjaum011257@marduk.eng.sun.com> <457EB99F.6090401@Sun.COM> <457F258D.3090207@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <457F258D.3090207@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2781 On Tue, Dec 12, 2006 at 02:56:29PM -0700, Shawn M Emery wrote: > Darren J Moffat wrote: > >In PSARC/2002/411 which introduced the DNS lookup capability we had > >this text in the proposal: > > > >>3. Risks & Assumptions > >> > >> Using DNS for lookups may allow additional types of denial of > >> service attacks, via spoofing of DNS records. Although an > >> attacker can redirect a Kerberos client to a KDC controlled > >> by the attacker, the Kerberos protocol prevents the > >> attacker's KDC from aquiring the client's secret key and thus > >> cannot issue a Kerberos ticket that the client will accept. This case does not help with the attack described in the above quoted paragraph. But it does help with this: > >> Also when using DNS to lookup the realm information, a > >>redirection > >> attack is a possibility, where spoofed DNS replies persuade a > >> Kerberos client to authenticate to the wrong realm. Depending on > >> how the client software manages hostnames, it may already be > >> vulnerable to such attacks. Item (2) in this case provides a method for host2realm mapping that is sufficiently secure to be on by default and which differs from: > >> Pls refer the "Security considerations" section in the Internet > >>draft > >> draft-ietf-krb-wg-krb-dns-locate-03.txt for more details. > >As I understand section 2 of this proposal that still stands and this > >case provides a more secure alternative that is protected by the > >description in para one of that set of risks outlined in 2002/411. Yes. > >Just so I understand the new algorithm properly it means we will do > >something like this: > > > >if the domain is: lab.sfbay.sun.com > > > > Look first for KDC for realm LAB.SFBAY.SUN.COM > > then look for KDC for realm SFBAY.SUN.COM > > then finally look for SUN.COM > > > >What domain name are we talking about here and how does this case > >determine what it is ? > > > >The reason I ask is because I believe that kclient(1M) currently gets > >this wrong because it parses /etc/resolv.conf looking for the domain > >entry. > > Yes, this easily breaks if only the search directive is defined. A > couple of possible solutions for this: > > 1. call sysinfo with the SI_SRPC_DOMAIN command. > 2. try to resolve the local host name through DNS to derive the domain name. The reverse sounds better to me. We're essentially saying that to have zero-conf Kerberos you need to have REALM names that correspond to DNS domainnames, and so the host's FQDN as resolved through DNS should be sufficient. Whereas the SI_SRPC_DOMAIN can be a NIS domain whose name needn't match the DNS domain nor realm name, so it seems inappropriate. Nico -- From sacadmin Tue Dec 12 16:04:18 2006 Received: from dm-holland-01.uk.sun.com (dm-holland-01.UK.Sun.COM [129.156.101.192]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBD04HgM015549 for ; Tue, 12 Dec 2006 16:04:17 -0800 (PST) Received: from vaticaan.holland.sun.com (vaticaan.Holland.Sun.COM [129.159.213.1]) by dm-holland-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kBD04DYn018249; Wed, 13 Dec 2006 00:04:13 GMT Received: from holland (room101 [129.159.201.52]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kBD04Ct0028792; Wed, 13 Dec 2006 01:04:12 +0100 (MET) Message-Id: <200612130004.kBD04Ct0028792@vaticaan.holland.sun.com> From: Casper.Dik@sun.com To: Shawn M Emery cc: Darren J Moffat , Gary Winiger , psarc@sac.sfbay.sun.com, Mark.Phalan@sun.com, krb5-core@sun.com Subject: Re: PSARC/2006/690 Kerberos client configuration improvements In-Reply-To: <457F258D.3090207@sun.com> References: <200612111845.kBBIjaum011257@marduk.eng.sun.com> <457EB99F.6090401@Sun.COM> <457F258D.3090207@sun.com> Date: Wed, 13 Dec 2006 01:04:10 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 266 >Yes, this easily breaks if only the search directive is defined. A >couple of possible solutions for this: > >1. call sysinfo with the SI_SRPC_DOMAIN command. No, that's the RPC domain; please do not confuse it further with any type of internet domain. Casper From sacadmin Wed Dec 13 06:36:50 2006 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBDEaohW001605 for ; Wed, 13 Dec 2006 06:36:50 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kBDEamCx009067 for ; Wed, 13 Dec 2006 06:36:49 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kBDEafHx008167 for ; Wed, 13 Dec 2006 14:36:43 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JA700901V8S0300@d1-emea-09.sun.com> (original mail from Mark.Phalan@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 13 Dec 2006 14:36:41 +0000 (GMT) Received: from [129.157.18.58] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JA700ME4V940N0O@d1-emea-09.sun.com>; Wed, 13 Dec 2006 14:36:40 +0000 (GMT) Date: Wed, 13 Dec 2006 15:35:05 +0100 From: Mark Phalan Subject: Re: PSARC/2006/690 Kerberos client configuration improvements In-reply-to: <20061212221048.GZ26175@binky.Central.Sun.COM> Sender: Mark.Phalan@Sun.COM To: Nicolas Williams Cc: Shawn M Emery , Darren J Moffat , Gary Winiger , psarc@sac.sfbay.sun.com, krb5-core@Sun.COM Message-id: <1166020505.90.25.camel@phalan> MIME-version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-type: text/plain Content-transfer-encoding: 7BIT References: <200612111845.kBBIjaum011257@marduk.eng.sun.com> <457EB99F.6090401@Sun.COM> <457F258D.3090207@sun.com> <20061212221048.GZ26175@binky.Central.Sun.COM> Status: RO Content-Length: 3141 On Tue, 2006-12-12 at 16:10 -0600, Nicolas Williams wrote: > On Tue, Dec 12, 2006 at 02:56:29PM -0700, Shawn M Emery wrote: > > Darren J Moffat wrote: > > >In PSARC/2002/411 which introduced the DNS lookup capability we had > > >this text in the proposal: > > > > > >>3. Risks & Assumptions > > >> > > >> Using DNS for lookups may allow additional types of denial of > > >> service attacks, via spoofing of DNS records. Although an > > >> attacker can redirect a Kerberos client to a KDC controlled > > >> by the attacker, the Kerberos protocol prevents the > > >> attacker's KDC from aquiring the client's secret key and thus > > >> cannot issue a Kerberos ticket that the client will accept. > > This case does not help with the attack described in the above quoted > paragraph. > > But it does help with this: > > > >> Also when using DNS to lookup the realm information, a > > >>redirection > > >> attack is a possibility, where spoofed DNS replies persuade a > > >> Kerberos client to authenticate to the wrong realm. Depending on > > >> how the client software manages hostnames, it may already be > > >> vulnerable to such attacks. > > Item (2) in this case provides a method for host2realm mapping that is > sufficiently secure to be on by default and which differs from: > > > >> Pls refer the "Security considerations" section in the Internet > > >>draft > > >> draft-ietf-krb-wg-krb-dns-locate-03.txt for more details. > > > >As I understand section 2 of this proposal that still stands and this > > >case provides a more secure alternative that is protected by the > > >description in para one of that set of risks outlined in 2002/411. > > Yes. > > > >Just so I understand the new algorithm properly it means we will do > > >something like this: > > > > > >if the domain is: lab.sfbay.sun.com > > > > > > Look first for KDC for realm LAB.SFBAY.SUN.COM > > > then look for KDC for realm SFBAY.SUN.COM > > > then finally look for SUN.COM > > > > > >What domain name are we talking about here and how does this case > > >determine what it is ? > > > > > >The reason I ask is because I believe that kclient(1M) currently gets > > >this wrong because it parses /etc/resolv.conf looking for the domain > > >entry. > > > > Yes, this easily breaks if only the search directive is defined. A > > couple of possible solutions for this: > > > > 1. call sysinfo with the SI_SRPC_DOMAIN command. > > 2. try to resolve the local host name through DNS to derive the domain name. > > The reverse sounds better to me. > > We're essentially saying that to have zero-conf Kerberos you need to > have REALM names that correspond to DNS domainnames, and so the host's > FQDN as resolved through DNS should be sufficient. > Doesn't the relience on a DNS server to determine the FQDN negate any benefits of using the "domainname -> realm name mapping" over "dns_lookup_realm"? -Mark > Whereas the SI_SRPC_DOMAIN can be a NIS domain whose name needn't match > the DNS domain nor realm name, so it seems inappropriate. > > Nico From sacadmin Wed Dec 13 06:54:31 2006 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBDEsU80002328 for ; Wed, 13 Dec 2006 06:54:31 -0800 (PST) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id kBDEsTl1026609 for ; Wed, 13 Dec 2006 06:54:30 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id kBDEsOlr011207 for ; Wed, 13 Dec 2006 14:54:24 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JA700L01VUQMY00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc@sac.sfbay.sun.com; Wed, 13 Dec 2006 14:54:24 +0000 (GMT) Received: from [129.156.173.21] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JA7008WHW2N9O30@d1-emea-09.sun.com>; Wed, 13 Dec 2006 14:54:24 +0000 (GMT) Date: Wed, 13 Dec 2006 14:54:23 +0000 From: Darren J Moffat Subject: Re: PSARC/2006/690 Kerberos client configuration improvements In-reply-to: <1166020505.90.25.camel@phalan> Sender: Darren.Moffat@Sun.COM To: Mark Phalan Cc: Nicolas Williams , Shawn M Emery , Gary Winiger , psarc@sac.sfbay.sun.com, krb5-core@Sun.COM Message-id: <4580141F.2090405@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200612111845.kBBIjaum011257@marduk.eng.sun.com> <457EB99F.6090401@Sun.COM> <457F258D.3090207@sun.com> <20061212221048.GZ26175@binky.Central.Sun.COM> <1166020505.90.25.camel@phalan> User-Agent: Thunderbird 1.5.0.8 (X11/20061113) Status: RO Content-Length: 413 Mark Phalan wrote: > Doesn't the relience on a DNS server to determine the FQDN negate any > benefits of using the "domainname -> realm name mapping" over > "dns_lookup_realm"? I think this case needs to specify how it determines the DNS domainame of the host, and the answer is NOT parsing /etc/resolv.conf because the domain entry doesn't need to exist (and in fact very often doesn't). -- Darren J Moffat From sacadmin Wed Dec 13 07:35:07 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBDFZ7Jh002714 for ; Wed, 13 Dec 2006 07:35:07 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kBDFZ2ek010088; Wed, 13 Dec 2006 09:35:02 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kBDFZ1Xj010087; Wed, 13 Dec 2006 09:35:01 -0600 (CST) Date: Wed, 13 Dec 2006 09:35:01 -0600 From: Nicolas Williams To: Mark Phalan Cc: Shawn M Emery , Darren J Moffat , Gary Winiger , psarc@sac.sfbay.sun.com, krb5-core@sun.com Subject: Re: PSARC/2006/690 Kerberos client configuration improvements Message-ID: <20061213153501.GK26175@binky.Central.Sun.COM> Mail-Followup-To: Mark Phalan , Shawn M Emery , Darren J Moffat , Gary Winiger , psarc@sac.sfbay.sun.com, krb5-core@sun.com References: <200612111845.kBBIjaum011257@marduk.eng.sun.com> <457EB99F.6090401@Sun.COM> <457F258D.3090207@sun.com> <20061212221048.GZ26175@binky.Central.Sun.COM> <1166020505.90.25.camel@phalan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1166020505.90.25.camel@phalan> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 574 On Wed, Dec 13, 2006 at 03:35:05PM +0100, Mark Phalan wrote: > On Tue, 2006-12-12 at 16:10 -0600, Nicolas Williams wrote: > Doesn't the relience on a DNS server to determine the FQDN negate any > benefits of using the "domainname -> realm name mapping" over > "dns_lookup_realm"? No -- that's a separate problem that we have _today_. The functionality that this case adds is independent of the hostname canonicalization problem and does not make it worse (the hostname canon thing could be fixed later without having to come back and fix host2realm resolution). Nico -- From sacadmin Wed Dec 13 07:40:45 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBDFejIA003039 for ; Wed, 13 Dec 2006 07:40:45 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kBDFeecW010095; Wed, 13 Dec 2006 09:40:40 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kBDFeexO010094; Wed, 13 Dec 2006 09:40:40 -0600 (CST) Date: Wed, 13 Dec 2006 09:40:39 -0600 From: Nicolas Williams To: Darren J Moffat Cc: Mark Phalan , Shawn M Emery , Gary Winiger , psarc@sac.sfbay.sun.com, krb5-core@sun.com Subject: Re: PSARC/2006/690 Kerberos client configuration improvements Message-ID: <20061213154039.GL26175@binky.Central.Sun.COM> Mail-Followup-To: Darren J Moffat , Mark Phalan , Shawn M Emery , Gary Winiger , psarc@sac.sfbay.sun.com, krb5-core@sun.com References: <200612111845.kBBIjaum011257@marduk.eng.sun.com> <457EB99F.6090401@Sun.COM> <457F258D.3090207@sun.com> <20061212221048.GZ26175@binky.Central.Sun.COM> <1166020505.90.25.camel@phalan> <4580141F.2090405@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4580141F.2090405@Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1024 On Wed, Dec 13, 2006 at 02:54:23PM +0000, Darren J Moffat wrote: > Mark Phalan wrote: > >Doesn't the relience on a DNS server to determine the FQDN negate any > >benefits of using the "domainname -> realm name mapping" over > >"dns_lookup_realm"? > > I think this case needs to specify how it determines the DNS domainame > of the host, and the answer is NOT parsing /etc/resolv.conf because the > domain entry doesn't need to exist (and in fact very often doesn't). Reverse lookup (PTR RR lookup). Note that such lookups are subject to DNS attacks, but: a) the traditional KDC lookup is subject to them as well (unless one uses IP addresses or files before DNS and one has /etc/inet/hosts entries for the KDC names, b) the most an attacker can do that can pull off this attack is obtain PA-ENC-TIMESTAMP ciphertext for subsequent off-line password dictionary/brute force attacks. Any on-path passive attacker can do this; with DNS in the mixture off-path active attackers can do it too. Nico -- From sacadmin Wed Dec 13 08:00:18 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBDG0IPC003821 for ; Wed, 13 Dec 2006 08:00:18 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id kBDG0DdX010139; Wed, 13 Dec 2006 10:00:13 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.6+Sun/8.13.6/Submit) id kBDG0DkY010138; Wed, 13 Dec 2006 10:00:13 -0600 (CST) Date: Wed, 13 Dec 2006 10:00:13 -0600 From: Nicolas Williams To: Mark Phalan , Shawn M Emery , Darren J Moffat , Gary Winiger , psarc@sac.sfbay.sun.com, krb5-core@sun.com Subject: Re: PSARC/2006/690 Kerberos client configuration improvements Message-ID: <20061213160012.GM26175@binky.Central.Sun.COM> Mail-Followup-To: Mark Phalan , Shawn M Emery , Darren J Moffat , Gary Winiger , psarc@sac.sfbay.sun.com, krb5-core@Sun.COM References: <200612111845.kBBIjaum011257@marduk.eng.sun.com> <457EB99F.6090401@Sun.COM> <457F258D.3090207@sun.com> <20061212221048.GZ26175@binky.Central.Sun.COM> <1166020505.90.25.camel@phalan> <20061213153501.GK26175@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061213153501.GK26175@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2349 On Wed, Dec 13, 2006 at 09:35:01AM -0600, Nicolas Williams wrote: > On Wed, Dec 13, 2006 at 03:35:05PM +0100, Mark Phalan wrote: > > On Tue, 2006-12-12 at 16:10 -0600, Nicolas Williams wrote: > > Doesn't the relience on a DNS server to determine the FQDN negate any > > benefits of using the "domainname -> realm name mapping" over > > "dns_lookup_realm"? > > No -- that's a separate problem that we have _today_. The functionality > that this case adds is independent of the hostname canonicalization > problem and does not make it worse (the hostname canon thing could be > fixed later without having to come back and fix host2realm resolution). There is one sense in which this case adds a vulnerability, but I think it's quite minor: IF prior to deploying zero-conf krb5 one had incomplete or no [domain_realm] relations, then this case can increase the number of hosts for which a realm can be resolved, and thus increase the set of hosts to which a victim could be redirected through DNS attacks on hostname canonicalization. E.g., sun.com has SUN.COM as its realm, but it lacks corresponding realms for its sub-domains, so given a host foo.central.sun.com then: - prior to this case the realm of services on foo.central.sun.com could not be resolved and therefore krb5 authentication with/of that host's principals would fail - after this case the realm of services on foo.central.sun.com would be resolved to SUN.COM If an attacker could subvert foo.central.sun.com and could mount a DNS attack on hostname canonicalization on some victim to redirect them to foo.central.sun.com and fool the victim into thinking that foo.central.sun.com is the host actually intende by the victim. In practice this is not a problem because people do mean to deploy a single realm for one DNS domainname and several of its sub-domains and intend for host2realm resolution to function properly: so they distribute domain_realm relations. Cross-realm relationships only make this worse if they are hierarchical (until we add Kerberos V referral support to the client). The upshot is that ultimately we have to fix the hostname canonicalization problem in our krb5 client, but I don't think that has to be done as part of this case, as long as the krb5 team commits to solving it. Nico -- From sacadmin Wed Dec 13 11:46:09 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBDJk9wP018043 for ; Wed, 13 Dec 2006 11:46:09 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kBDJk8YU018024; Wed, 13 Dec 2006 11:46:08 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id kBDJoLPM007967; Wed, 13 Dec 2006 11:50:21 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id kBDJoLfu007966; Wed, 13 Dec 2006 11:50:21 -0800 (PST) Date: Wed, 13 Dec 2006 11:50:21 -0800 (PST) From: Gary Winiger Message-Id: <200612131950.kBDJoLfu007966@marduk.eng.sun.com> To: gww@eng.sun.com, psarc@sac.sfbay.sun.com Cc: Mark.Phalan@sun.com, krb5-core@sun.com Subject: Re: PSARC/2006/690 Kerberos client configuration improvements Status: RO Content-Length: 264 This case was approved at today's PSARC meeting. A spec update was requested. I'm temporarily marking it waiting need spec so it won't appear on the fast track list. I'll post the spec and close out then case when the project team supplies the update. Gary.. From sacadmin Sun Dec 17 12:33:57 2006 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kBHKXve2024690 for ; Sun, 17 Dec 2006 12:33:57 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id kBHKXtJu025553; Sun, 17 Dec 2006 12:33:55 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id kBHKcFXK012095; Sun, 17 Dec 2006 12:38:15 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id kBHKcF9w012094; Sun, 17 Dec 2006 12:38:15 -0800 (PST) Date: Sun, 17 Dec 2006 12:38:15 -0800 (PST) From: Gary Winiger Message-Id: <200612172038.kBHKcF9w012094@marduk.eng.sun.com> To: gww@eng.sun.com, psarc@sac.sfbay.sun.com Cc: Mark.Phalan@sun.com, krb5-core@sun.com Subject: Re: PSARC/2006/690 Kerberos client configuration improvements Status: RO Content-Length: 130 I've placed the updated spec in the case directory as final.spec and updated the case to show it as approved 13 Dec 2006. Gary.. From sacadmin Fri Jun 29 05:45:18 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5TCjIJf009712 for ; Fri, 29 Jun 2007 05:45:18 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l5TChVp7014061 for ; Fri, 29 Jun 2007 05:43:32 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5TChQ58020009 for ; Fri, 29 Jun 2007 12:43:26 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JKE00801DWZ2500@d1-emea-09.sun.com> (original mail from Mark.Phalan@Sun.COM) for psarc@sac.sfbay.sun.com; Fri, 29 Jun 2007 13:43:26 +0100 (BST) Received: from [129.157.18.58] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JKE003P2E0CB2IG@d1-emea-09.sun.com>; Fri, 29 Jun 2007 13:43:25 +0100 (BST) Date: Fri, 29 Jun 2007 14:40:42 +0200 From: Mark Phalan Subject: Comment on PSARC/2006/690 Kerberos client configuration improvements Sender: Mark.Phalan@Sun.COM To: psarc@sac.sfbay.sun.com Cc: Gary Winiger Message-id: <1183120842.9048.278.camel@phalan> MIME-version: 1.0 X-Mailer: Evolution 2.10.1 Content-type: text/plain Content-transfer-encoding: 7BIT Status: RO Content-Length: 516 It is the intention of the product team to do a phased putback for this project. The first putback will be the ON changes as specified. The changes to the install-gate (removal of sysidkrb5) will be done at a later time. There are no dependencies per-se between the removal of sysidkrb5 and the ON changes. The changes to the install-gate simply remove the install time Kerberos configuration panel. The changes to ON stand on their own - removing sysidkrb5 is just part of the larger picture. Regards, -Mark