[7560] in Kerberos
Re: krb4 application compatibility
daemon@ATHENA.MIT.EDU (Sam Hartman)
Mon Jul 1 14:42:15 1996
To: Dave McGuire <mcguire@rocinante.digex.net>
Cc: Sam Hartman <hartmans@MIT.EDU>, kerberos@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 01 Jul 1996 14:22:38 -0400
In-Reply-To: Dave McGuire's message of Sat, 29 Jun 1996 15:10:11 -0400
>>>>> "Dave" == Dave McGuire <mcguire@rocinante.digex.net> writes:
>> On the other hand, you should have no problems if you continue
>> to have a krb4 application. The KDC and krb524d should handle
>> most of the issues involving assumptions that have changed
>> between krb5 and krb4. Your application maintains
>> compatability with past versions. Future versions of the
>> application may even choose to maintain compatability with the
>> past versions of the application in a manner similar to the BSD
>> utilities, although you should probably drop krb4 support some
>> day.
Dave> Point well taken...and I agree...but the application in
Dave> question doesn't even come close to working against a krb5
Dave> kdc. I've been working on it all day, to no avail. It gets
Dave> tickets from its stashed file, but mutual authentication
Dave> blows up. I'm still looking into why.
The following assumes that you are using the libkrb4.a,
libdes425 and libcrypto.a that come with krb5. If you are using pure
Kerberos IV libraries, then your application doesn't even know that
krb5 is involved.
Dave> Perhaps my problem is one of configuration. I haven't
Dave> been able to determine a few things...when using the krb4
Dave> interoperability features in krb5 beta6:
Dave> Do I need an appropriately configured v4-style
Dave> /etc/krb.conf, or will the library code use information it
Dave> found in /etc/krb5.conf?
You need a krb.conf and if appropriate a krb.realms. They
don't always live in /etc; their location is specified in krb5.conf:
(From the MIT krb5.conf:)
[libdefaults]
ticket_lifetime = 600
default_realm = ATHENA.MIT.EDU
krb4_config = /etc/athena/krb.conf
krb4_realms = /etc/athena/krb.realms
Dave> Do I need to create a v4-style /etc/srvtab for
Dave> applications which use v4 mutual authentication, or will the
Dave> library code use /etc/v5srvtab?
I think you are misusing the term mutual authentication. A
srvtab is required for one way authentication from client to server as
well as for mutual authentication. In most cases (excluding telnetd
among others), the library will work without a /etc/srvtab. However,
you can use the ktutil program to convert /etc/v5srvtab to /etc/srvtab
without a problem. You should try this if you are having problems.
Dave> Is converting a v4 realm to v5b6 a way around the
Dave> infuriating "no dots in principal names" problem in v4, or
Dave> will I need to continue to inflate our nameservers by
Dave> duplicating hostnames that happen to be in subdomains with
Dave> dashes replacing the dots?
You actually can have dots in krb4 principals, but it doesn't
work the way you think it will, so it doesn't help you with this
problem. You can use the krb.realms file to overide what realm a
client and server think a machine is in. For example,
lithium.lcs.mit.edu is really in the ATHENA.MIT.EDU realm (with
rcmd.lithium@ATHENA.MIT.EDU as its principal). Thus, we have the
following line in our krb.realms file:
lithium.lcs.mit.edu ATHENA.MIT.EDU
Dave> If you could clear these things up for me, I might be able
Dave> to get a bit farther. Of course, I'd *really* like to see
Dave> this package converted to use gssapi, but I've nowhere near
Dave> the knowledge of gssapi required to do that, and
Dave> documentation is somewhat lacking. I will spend a few hours
Dave> this afternoon studying the gss-sample code...If I can
Dave> figure out how that works, I might take a stab at converting
Dave> this application to use gssapi.
Dave> Is there somewhere I might find a brief description of the
Dave> "flow" of a gss application, in terms of the functions and
Dave> data structures used?
Dave> -Dave McGuire
Dave> mcguire@digex.net
