Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) X-RT-Original-Encoding: iso-8859-1 Content-Length: 18181 From ppomes@Qualcomm.com Mon Jan 6 14:24:29 1997 Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id OAA24839 for ; Mon, 6 Jan 1997 14:24:28 -0500 Received: from zelkova.qualcomm.com by MIT.EDU with SMTP id AA14745; Mon, 6 Jan 97 14:24:27 EST Received: (from ppomes@localhost) by zelkova.qualcomm.com (8.8.4/8.8.4) id LAA02260; Mon, 6 Jan 1997 11:24:14 -0800 (PST) Message-Id: <199701061924.LAA02260@zelkova.qualcomm.com> Date: Mon, 6 Jan 1997 11:24:14 -0800 (PST) From: Paul Pomes Reply-To: ppomes@Qualcomm.com To: krb5-bugs@MIT.EDU Subject: How are new /etc/srvtab files created X-Send-Pr-Version: 3.99 >Number: 333 >Category: krb5-admin >Synopsis: How are /etc/srvtab files created now? >Confidential: no >Severity: serious >Priority: high >Responsible: bjaspan >State: closed >Class: support >Submitter-Id: unknown >Arrival-Date: Mon Jan 06 14:25:01 EST 1997 >Last-Modified: Sat Jan 25 22:35:34 EST 1997 >Originator: Paul Pomes >Organization: QUALCOMM, Inc. 6455 Lusk Blvd San Diego, CA 92121-2779 >Release: 1.0 >Environment: Sparc 20/MP, Solaris 2.4, SparcWorks 3.01 System: SunOS zelkova 5.4 Generic_101945-27 sun4m sparc >Description: Since many Macs are still using NCSA telnet with kconfig it's important that we be able to create /etc/srvtab files so that telnetd can support v4 clients. How can kadmin be used to create /etc/srvtab files? >How-To-Repeat: By searching docs and code, there is no way to do a xst4 anymore. >Fix: Needed. >Audit-Trail: From: "Barry Jaspan" To: krb5-bugs@MIT.EDU, ppomes@Qualcomm.com Cc: Subject: Re: krb5-admin/333: How are new /etc/srvtab files created Date: Mon, 6 Jan 1997 14:43:37 -0500 Use kadmin to create a V5 srvtab, then use the ktutil program (kadmin/ktutil) to convert it to V4 format. Barry From: Paul Pomes To: Ken Hornstein Cc: krb5-bugs@MIT.EDU, bjaspan@MIT.EDU Subject: Re: krb5-admin/333: How are new /etc/srvtab files created Date: Mon, 06 Jan 1997 12:34:23 -0800 The compatibility code isn't used within telnet at least. If the /etc/srvtab file is absent then telnetd will not offer the KERBEROS_V4 option. kadmin/ktutil might work, however kadmin saves the key as a des-cbc-crc:normal enctype whereas /etc/srvtab needs des-cbc-crc:v4. I've tried reading in a v5srvtab and writing out a srvtab with ktutil, however that form won't work. Entries added in previous versions show the v4 enctype: Principal: rcmd/vega1@GLOBALSTAR.COM Expiration date: Wed Dec 30 16:00:00 PST 2037 Last password change: [never] Password expiration date: [none] Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Fri Mar 22 08:23:33 PST 1996 (K/M@GLOBALSTAR.COM) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 1 Key: vno 2, DES cbc mode with CRC-32, Version 4 Attributes: Policy: [none] New principals behave quite differently after any of randkey or xst is applied to the entry: kadmin: ank rcmd/zelkova@GLOBALSTAR.COM Enter password for principal "rcmd/zelkova@GLOBALSTAR.COM": Re-enter password for principal "rcmd/zelkova@GLOBALSTAR.COM": Principal "rcmd/zelkova@GLOBALSTAR.COM" created. kadmin: getprinc rcmd/zelkova@GLOBALSTAR.COM Principal: rcmd/zelkova@GLOBALSTAR.COM Expiration date: [never] Last password change: Mon Jan 06 12:19:19 PST 1997 Password expiration date: [none] Maximum ticket life: 0 days 10:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Mon Jan 06 12:19:19 PST 1997 (ppomes/admin@GLOBALSTAR.COM) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 5 Key: vno 1, DES cbc mode with CRC-32, no salt Key: vno 1, DES cbc mode with CRC-32, Version 4 Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3 Attributes: Policy: [none] Watch what happens after a "xst rcmd/zelkova@GLOBALSTAR.COM" is done: kadmin: xst -k /tmp/foo rcmd/zelkova@GLOBALSTAR.COM Entry for principal rcmd/zelkova@GLOBALSTAR.COM with kvno 2, encryption type DES-CBC-CRC added to keytab WRFILE:/tmp/foo. kadmin: getprinc rcmd/zelkova@GLOBALSTAR.COM Principal: rcmd/zelkova@GLOBALSTAR.COM Expiration date: [never] Last password change: Mon Jan 06 12:20:56 PST 1997 Password expiration date: [none] Maximum ticket life: 0 days 10:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Mon Jan 06 12:20:56 PST 1997 (ppomes/admin@GLOBALSTAR.COM) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 1 Key: vno 2, DES cbc mode with CRC-32, no salt Attributes: Policy: [none] After rcmd/zelkova@GLOBALSTAR.COM is deleted, "ank -randkey rcmd/zelkova@ GLOBALSTAR.COM" is seen to have similar results: kadmin: ank -randkey rcmd/zelkova@GLOBALSTAR.COM Principal "rcmd/zelkova@GLOBALSTAR.COM" created. kadmin: getprinc rcmd/zelkova@GLOBALSTAR.COM Principal: rcmd/zelkova@GLOBALSTAR.COM Expiration date: [never] Last password change: Mon Jan 06 12:23:42 PST 1997 Password expiration date: [none] Maximum ticket life: 0 days 10:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Mon Jan 06 12:23:42 PST 1997 (ppomes/admin@GLOBALSTAR.COM) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 1 Key: vno 2, DES cbc mode with CRC-32, no salt Attributes: Policy: [none] So far as I can tell, the new entries are not even available to V4 processes when all the keys are present. hydra1 is an old entry and findable, zelkova cannot: Jan 6 12:25:26 draco1 krb5kdc[9955]: PROCESS_V4:APPL Request ppomes.@GLOBALSTAR.COM on 129.46.148.32 for rcmd.hydra1 Jan 6 12:30:43 draco1 krb5kdc[9955]: PROCESS_V4:APPL Request ppomes.@GLOBALSTAR.COM on 129.46.148.32 for rcmd.zelkova Jan 6 12:30:43 draco1 krb5kdc[9955]: PROCESS_V4:UNKNOWN "rcmd" "zelkova" From: Marc Horowitz To: ppomes@Qualcomm.com Cc: krb5-bugs@MIT.EDU Subject: Re: krb5-admin/333: How are new /etc/srvtab files created Date: 06 Jan 1997 15:43:56 -0500 Paul Pomes writes: >> Since many Macs are still using NCSA telnet with kconfig it's >> important that we be able to create /etc/srvtab files so that >> telnetd can support v4 clients. How can kadmin be used to >> create /etc/srvtab files? You can use the ktutil command to convert a v5 keytab to a v4 srvtab. Marc From: Ken Hornstein To: Paul Pomes Cc: krb5-bugs@MIT.EDU, bjaspan@MIT.EDU Subject: Re: krb5-admin/333: How are new /etc/srvtab files created Date: Mon, 06 Jan 1997 15:50:02 -0500 >The compatibility code isn't used within telnet at least. If the >/etc/srvtab file is absent then telnetd will not offer the KERBEROS_V4 >option. Errr, Paul, I don't want to call you a liar, but the compatibility code is in read_service_key(), so assuming that you used the built-in V4 code, then it should just work. My V5 telnetds offer KERBEROS_V4 authentication and I definately don't have /etc/srvtab's. Now, I haven't actually _TESTED_ to see if it works or not, but it does offer it in the option negotiation :-) --Ken From: Paul Pomes To: Ken Hornstein Cc: krb5-bugs@MIT.EDU, bjaspan@MIT.EDU Subject: Re: krb5-admin/333: How are new /etc/srvtab files created Date: Tue, 07 Jan 1997 14:40:30 -0800 |Errr, Paul, I don't want to call you a liar, but the compatibility code |is in read_service_key(), so assuming that you used the built-in V4 code, |then it should just work. My V5 telnetds offer KERBEROS_V4 authentication |and I definately don't have /etc/srvtab's. I really don't see how that can be unless the location of the v4 srvtab file has been reset. In libtelnet/kerberos.c is the routine kerberos4_init(ap, server) Authenticator *ap; int server; { FILE *fp; if (server) { str_data[3] = TELQUAL_REPLY; if ((fp = fopen(KEYFILE, "r")) == NULL) return(0); fclose(fp); } else { str_data[3] = TELQUAL_IS; } return(1); } where KEYFILE is defined by the krb4_srvtab entry in krb5.conf or to /etc/srvtab by default. One place or another there has to be a srvtab file defined before telnetd will offer KERBEROS_V4 as an option. After some more work it's my feeling that rel 1.0 has a new problem that wasn't in b6 with the creation of v4-compatible principles. rcmd/foo entries created before rel 1.0 continue to work. rcmd/foo entries made afterwards do not. Here are the log entries and getprinc results for rcmd/andromeda (old entry) and rcmd/cetus1 (new entry). Note that the V4_PROCESS can't even locate the rcmd/cetus1 entry. Jan 7 14:24:31 draco1 krb5kdc[9955]: PROCESS_V4:APPL Request ppomes.@GLOBALSTAR.COM on 129.46.148.32 for rcmd.andromeda Jan 7 14:25:18 draco1 krb5kdc[9955]: PROCESS_V4:APPL Request ppomes.@GLOBALSTAR.COM on 129.46.148.32 for rcmd.cetus1 Jan 7 14:25:18 draco1 krb5kdc[9955]: PROCESS_V4:UNKNOWN "rcmd" "cetus1" Principal: rcmd/andromeda@GLOBALSTAR.COM Expiration date: Wed Dec 30 16:00:00 PST 2037 Last password change: [never] Password expiration date: [none] Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Fri Mar 22 08:23:33 PST 1996 (K/M@GLOBALSTAR.COM) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 1 Key: vno 2, DES cbc mode with CRC-32, Version 4 Attributes: Policy: [none] Principal: rcmd/cetus1@GLOBALSTAR.COM Expiration date: [never] Last password change: Tue Jan 07 08:40:04 PST 1997 Password expiration date: [none] Maximum ticket life: 0 days 10:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Tue Jan 07 08:40:04 PST 1997 (ppomes/admin@GLOBALSTAR.COM) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 5 Key: vno 1, DES cbc mode with CRC-32, no salt Key: vno 1, DES cbc mode with CRC-32, Version 4 Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - No Realm Key: vno 1, DES cbc mode with RSA-MD5, Version 5 - Realm Only Key: vno 1, DES cbc mode with RSA-MD5, AFS version 3 Attributes: Policy: [none] Again if I do either of xst or 'cpw -randkey' only the CRC-32, no salt version will be left. Here are the two entries from a dump run princ 38 29 1 1 0 rcmd/andromeda@GLOBALSTAR.COM 0 86400 604800 2145830400 0 0 0 0 2 23 05d452314b2f4d40474c4f42414c535441522e434f4d00 2 2 1 26 0800dd210e866151970982f441b9487dc95a535191e0adfbc977 1 0 -1 -1; rcmd/cetus1 after a 'cpw -randkey' princ 38 26 2 1 0 rcmd/cetus1@GLOBALSTAR.COM 0 36000 604800 0 0 0 0 0 2 32 a4cfd23270706f6d65732f61646d696e40474c4f42414c535441522e434f4d00 1 4 a4cfd232 1 2 1 26 080056729d1b7d4068bf1b0899f49495eb61577b059bb065a6ee -1; From: Ken Hornstein To: Paul Pomes Cc: krb5-bugs@MIT.EDU Subject: Re: krb5-admin/333: How are new /etc/srvtab files created Date: Tue, 07 Jan 1997 23:59:58 -0500 >|Errr, Paul, I don't want to call you a liar, but the compatibility code >|is in read_service_key(), so assuming that you used the built-in V4 code, >|then it should just work. My V5 telnetds offer KERBEROS_V4 authentication >|and I definately don't have /etc/srvtab's. > >I really don't see how that can be unless the location of the v4 srvtab file >has been reset. In libtelnet/kerberos.c is the routine >[...] >where KEYFILE is defined by the krb4_srvtab entry in krb5.conf or to >/etc/srvtab by default. One place or another there has to be a srvtab >file defined before telnetd will offer KERBEROS_V4 as an option. Sorry about that; I didn't see that bit of code! (But it would seem to me that you could get around that by just adding the appropriate entry to krb5.conf so that the srvtab just points to an existing file, since the v4 routines will apparantly look at the V5 keytab. But I don't want to put my foot in my mouth AGAIN, so I won't claim that this actually works :-) ). >Again if I do either of xst or 'cpw -randkey' only the CRC-32, no salt version >will be left. Do you have the "supported_enctypes" line in your kdc.conf? The OV admin server will only create new keys with those enctypes listed in that profile line. Mine says: supported_enctypes = des-cbc-crc:normal des:v4 --Ken From: Paul Pomes To: Ken Hornstein Cc: krb5-bugs@MIT.EDU Subject: Re: krb5-admin/333: How are new /etc/srvtab files created Date: Wed, 08 Jan 1997 06:33:10 -0800 The keys are created with multiple types as shown in the previous message. The three problems are that 1) -randkey argument to cpw or ank deletes the extra keys, 2) xst also deletes the extra keys, 3) new principals *with instances* created by kadmin are not visible to V4 requests. New principals with null instances work just fine with V4. Old principals with non-null instances created with kdb5_edit also work with V4. |(But it would seem to me that you could get around that by just adding |the appropriate entry to krb5.conf so that the srvtab just points to |an existing file, since the v4 routines will apparantly look at the V5 |keytab. But I don't want to put my foot in my mouth AGAIN, so I won't |claim that this actually works :-) ). I've tried pointing krb4_srvtab at /etc/krb5.srvtab with no joy. The client runs up against problem #3 above and fails to obtain the rcmd/ ticket from the KDC. That suggestion *does* work for hosts that had their rcmd/ entries created by kdb5_edit in previous releases. Doesn't this last bit imply that the key for rcmd/ must be the same as that for host/.? /pbp From: Ken Hornstein To: Paul Pomes Cc: krb5-bugs@MIT.EDU Subject: Re: krb5-admin/333: How are new /etc/srvtab files created Date: Wed, 08 Jan 1997 11:18:46 -0500 >The keys are created with multiple types as shown in the previous message. >The three problems are that 1) -randkey argument to cpw or ank deletes the >extra keys, 2) xst also deletes the extra keys, 3) new principals *with >instances* created by kadmin are not visible to V4 requests. New principals >with null instances work just fine with V4. Old principals with non-null >instances created with kdb5_edit also work with V4. Odd; I'm using the beta 7 OV admin server, but that definately isn't the behavior I'm seeing. Oh, wait, I just realized; the keys I _do_ use for V4 stuff have don't have V4 keys associated with them! Of course, now that I think about it, it really shouldn't matter; you aren't ever converting strings to keys, since the raw key is stored in the keytab, so it shouldn't really matter if there is a V4 salt for that key or not, right? >Doesn't this last bit imply that the key for rcmd/ must be the >same as that for host/.? I'm not sure; I am currently only using V4 for POP, and my instance is a FQDN. You know, it's my impression that the only thing you actually need a "host/" principal, and the V5 KDC will do the right translation magic needed. Certainly I remember seeing the translation code in either the KDC or the krb5 library ... --Ken From: Paul Pomes To: Ken Hornstein Cc: krb5-bugs@MIT.EDU Subject: Re: krb5-admin/333: How are new /etc/srvtab files created Date: Wed, 08 Jan 1997 10:20:11 -0800 At 11:18 EST on Wednesday, January 8, 1997, Ken Hornstein wrote: |>The keys are created with multiple types as shown in the previous message. |>The three problems are that 1) -randkey argument to cpw or ank deletes the |>extra keys, 2) xst also deletes the extra keys, 3) new principals *with |>instances* created by kadmin are not visible to V4 requests. New principals |>with null instances work just fine with V4. Old principals with non-null |>instances created with kdb5_edit also work with V4. I've determined the problem to be one that has bitten me before, incorrect principal conversion. The v4_instance_convert stanza had not been updated with the new machine cetus1.glab.globalstar.com for the realm GLOBALSTAR.COM. A v4 query for rcmd.cetus1 was being converted to host/cetus1.globalstar.com@GLOBALSTAR.COM instead of the correct form of host/cetus1.glab.globalstar.com@GLOBALSTAR.COM The new default_domain specification is most welcome now. What I would urge to make this translation clearer is to change the logging. What the KDC couldn't find wasn't the v4 'rcmd.cetus1@GLOBALSTAR.COM' principal, but the v5 'host/cetus1.globalstar.com@GLOBALSTAR.COM' principal. If the latter had been logged it would have a lot more obvious what was going on and what I needed to do to fix it. For the record my steps were On the KDC hosts I editted /etc/krb5.conf to replace the v4_instance_convert stanza with a "default_domain = GLAB.GLOBALSTAR.COM" entry. On the target machines, e.g., cetus1, I used kadmin with the command 'xst -k /etc/krb5.keytab host/cetus1.glab.globalstar.com ftp/cetus1.glab.globalstar.com' This was followed by ktutil: rkt /etc/krb5.keytab wst /etc/srvtab Thank you all for the help and feedback. /pbp State-Changed-From-To: open-closed State-Changed-By: tlyu State-Changed-When: Sat Jan 25 22:34:35 1997 State-Changed-Why: problem solved; user needed clarification >Unformatted: