interoperability of MIT Kerberos V5 1.0pl1 and Cybersafe Kerberos

interoperability of MIT Kerberos V5 1.0pl1 and Cybersafe Kerberos

Post by Don Rol » Sat, 30 May 1998 04:00:00



My apologies, I am sure this has been discussed before, but in a web
search I was unable to find a lead.

We are running a *safe Kerberos V5 server.  I am trying to prepare
a  client library for creating kerberized clients on arbitrary machines.

I have downloaded and successfully built the MIT Athean Kerberos V.5
distribution.  However, kinit will not work against the *safe server
- I receive a password incorrect message.  I know the *safe server
is working because I have a Kerberos V.4 client which is interoperating
with the *safe server successfully (with the same principal and
password).

Looking over the documentation, it appears the MIT Kerberos only
supports des-cbc-crc encryption.  Looking over the RFCs it appears that
the standard requires des-cbc-md5 as the default encryption.

My questions:

  1)  is the difficulty the use of des-cbc-crc encryption by MIT
Kerberos?

  2)  if not, any leads on what the difficulty might be?

  3)  any solution?

Thanks in advance, appreciate any hint anyone can give!
--

Regards.


 
 
 

interoperability of MIT Kerberos V5 1.0pl1 and Cybersafe Kerberos

Post by Ken Hornste » Sat, 30 May 1998 04:00:00


Quote:>I have downloaded and successfully built the MIT Athean Kerberos V.5
>distribution.  However, kinit will not work against the *safe server
>- I receive a password incorrect message.  I know the *safe server
>is working because I have a Kerberos V.4 client which is interoperating
>with the *safe server successfully (with the same principal and
>password).

Last time I talked with folks at *safe, their KDC could only
support one key per principal (If I'm wrong, please correct me, but
that's what I remember).  Maybe this is using the V4 salt algorithm,
and the *safe KDC isn't telling the MIT kinit about it?

Since *safe _is_ a commercial product, talking to their tech support
probably is in order.

--Ken

 
 
 

interoperability of MIT Kerberos V5 1.0pl1 and Cybersafe Kerberos

Post by Mike Friedm » Wed, 03 Jun 1998 04:00:00


: Last time I talked with folks at *safe, their KDC could only
: support one key per principal (If I'm wrong, please correct me, but
: that's what I remember).  Maybe this is using the V4 salt algorithm,
: and the *safe KDC isn't telling the MIT kinit about it?

I'm currently working with an evaluation copy of *Safe software.  They do
support a 'primary' and 'secondary' key, whose purpose is V4 compatibility.
I created a *Safe KDC database from my Cygnus V4 KDC (using *Safe's
conversion utilities) and, by default, each principal has a 'primary key'
which is V5-salted and a 'secondary' key which is V4-salted (ie, no salt).

I have been able to use a Cygnus V4 kinit to authenticate successfully against
the *Safe KDC.  Also, my Cygnus V4 telnet client could then use the V4
TGT to obtain a V4 service ticket which works with the Cygnus V4 telnetd.

Incidentally, the Cygnus kinit and telnet are old Windows (16-bit) versions!!

----------------------------------------------------------------------------

Communication & Network Services          +1-510-642-1410
University of California at Berkeley      http://www.veryComputer.com/~mikef
----------------------------------------------------------------------------

 
 
 

interoperability of MIT Kerberos V5 1.0pl1 and Cybersafe Kerberos

Post by Marc Horowit » Thu, 04 Jun 1998 04:00:00



>> I'm currently working with an evaluation copy of *Safe
>> software.  They do support a 'primary' and 'secondary' key, whose
>> purpose is V4 compatibility.  I created a *Safe KDC database
>> from my Cygnus V4 KDC (using *Safe's conversion utilities) and,
>> by default, each principal has a 'primary key' which is V5-salted
>> and a 'secondary' key which is V4-salted (ie, no salt).

It's not computationally feasible to turn a v4 key into a v5-salted
key.  If the *safe code claims to have done so, either they're
confused, or they've broken DES :-)

This may or may not help you debug things.

                Marc

 
 
 

interoperability of MIT Kerberos V5 1.0pl1 and Cybersafe Kerberos

Post by Wes Hardake » Fri, 05 Jun 1998 04:00:00


Marc> It's not computationally feasible to turn a v4 key into a v5-salted
Marc> key.  If the *safe code claims to have done so, either they're
Marc> confused, or they've broken DES :-)

I think they only do so for new keys generated in the kdc...  Their
kdc creates v4 and v5 keys for new password changes...  (Obviously
with a v5 password changer).

We use a *safe KDC and and MIT clients and servers, since many of
the MIT client telnets don't interact properly with the *safe
telnetd's and it creates problems for linux users and other
non-supported platforms for *safe.  The other problem is that they
are not cache-file compatibile with the latest MIT releases.  Their
code is essentially built off of pre-beta5 code, which causes all
sorts of other problems.

Um, I'd better stop before I really get started...

--
"Ninjas aren't dangerous.  They're more afraid of you than you are of them."

 
 
 

interoperability of MIT Kerberos V5 1.0pl1 and Cybersafe Kerberos

Post by Mike Friedm » Fri, 05 Jun 1998 04:00:00



: Marc> It's not computationally feasible to turn a v4 key into a v5-salted
: Marc> key.  If the *safe code claims to have done so, either they're
: Marc> confused, or they've broken DES :-)

: Wes>  I think they only do so for new keys generated in the kdc...  Their
: Wes>  kdc creates v4 and v5 keys for new password changes...  (Obviously
: Wes>  with a v5 password changer).

Oops, sorry, I misspoke!  The principals that I had moved from the V4 db to
*Safe's KDC had a primary and secondary key both in V4 format.  Only new
principals I added later, or else password changes I made to old principals,
resulted in V5-salted keys.

Anyway, my original point was that I was able to get downward compatibility
of the *Safe KDC with a V4 kinit.  This works even when the principal
has a primary key that's V5-salted, as long as the secondary key is V4.
(This was in response to someone who was having trouble with compatibility).

Sorry for any confusion I may have contributed to.

Mike

----------------------------------------------------------------------------

Communication & Network Services          +1-510-642-1410
University of California at Berkeley      http://www.veryComputer.com/~mikef
----------------------------------------------------------------------------

 
 
 

1. Cybersafe Kerberos V5 vs. Cygnus Kerbnet 1.2 Kerberos V5 and MIT Kerberos V5

I have been performing interoperabiltiy testing of Kerberos
implementations against a CyberSafe Kerberos V5 server in our company.

Status to date:

    TeleBit NetBlazer Kerberos V4                   works
    Cygnus Kerberos V4                              works
    MIT Athena Kerberos V5                          password invalid
    Cygnus Kerbnet 1.2 Kerberos V5 on DEC UNIX      password invalid
    Cygnus Kerbnet 1.2 Kerberos V5 on  Windos/NT 4  password invalid

Evidence indicates that the problem is with Preauth.

Can anyone assit me with:

   Explicit description of technical nature of problem
   Possible workarounds

It looks to me like the CyberSafe people blew something.

Thanks in advance!
--

Regards.


2. licensing from UK

3. Is Kerberos V5 supported by AFS, is Kerberos V5 preferred and stable?

4. Ultra1 64-Bit Solaris 7 Bug?

5. OpenVision vs CyberSafe commercial Kerberos V5?

6. Firecracker price fraud

7. OpenVision vs CyberSafe commercial Kerberos V5? (fwd)

8. Wanted: IDE controller and HD

9. Interoperability between MIT v5b5+ and CyberSAFE Challenger

10. Problems with interoperability among Kerberos MIT 5 and Win2K

11. Sun's SEAM, MIT Kerberos and Windows 2000 interoperability

12. Interoperability with windows 2003 KDC and MIT kerberos V

13. FALSE ALARM: SEVERE interoperability bug in Kerberos V5 beta 4