[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: heimdal and cybersafe compatibility




I used to work for the now-defunct company known as Cybersafe.

Regarding #3, this is a long-time bug where TGS reps get sent back with the
ASN.1 application tag of an AS rep (25 versus 26 I think).  I believe this was
a bug that cybersafe inherited from MIT, and never fixed in their KDC for
legacy reasons.  I believe Cybersafe clients were patched to accept either tag
however, as other KDCs like Microsoft were true to the RFC and had no legacy
baggage.

Dave


windeleb@wellsfargo.com wrote:

> I am trying to get a Kerberized version of OpenSSH working in the cygwin
> environment under Windows.  Our KDC is a CyberSAFE implementation.
>
> I have been able to build the heimdal source in the cygwin environment with
> a little tweaking and have gotten OpenSSH to build against the heimdal
> libraries with few modifications. I have been able to get a TGT using the
> kinit that comes with the heimdal release.  However, when I try to connect
> to a server using Kerberos authentication in ssh, I run into a few problems:
>
> 1) By default, the connection to the KDC tries to connect via UDP and fails.
> It appears that the connection happens, but no data is sent back from the
> KDC (length == 0).  I have modified the code to force a connetion over TCP
> and it seems to work fine (connection is created and data sent back, though
> I haven't peeked at it yet).  Is there a way to specify this via a runtime
> configuration option rather than hard coding it?  The option will need to be
> available to the library itself since it will be called from OpenSSH.
>
> 2) After forcing the TCP connection, the client seems to be unable to parse
> the reply correctly.  Doing a bit of debugging, I have found that the
> checksums of the data don't match (CRC32).  Does anyone know whether
> CyberSAFE and Heimdal compute checksums differently?  I would think that if
> I can get a TGT from the KDC, a session ticket should be fine, too.
>
> 3) If I try to force the verification to return without errors, I get an
> asn1 parsing error that I've tracked down to the decode_EncTGSRepPart and
> decode_EncASRepPart functions.  I'm under the assumption that the data isn't
> getting parsed correctly in the first place, which is perhaps why item 2) is
> happening.  Any ideas?
>
> Any help would be appreciated.  I'm new to the list so let me know if this
> has been discussed before.  I didn't see a mail archive for this list and I
> haven't been able to track down any useful information on the web or in
> newsgroups.
>
> Best Regards.
>
> -brahm