From Newsgroup: comp.protocols.kerberos

Hi there..

I've been working on a spec for GSSAPI on Go similar to RFC2744 and RFC2853
for C and Java. I have a working implementation of the described interface
and a provider that wraps the MIT & Heimdal C libraries. The idea is to provide an idomatic interface for Go developers that supports multiple providers (like the C provider or a pure Go provider at some point).

I would love some feedback before launching this on the world! It is
currently in beta, and the docs/code are at:

The interface spec: https://github.com/golang-auth/go-gssapi/wiki
.. and the code for the interface and provider register: https://github.com/golang-auth/go-gssapi

And the C provider: https://github.com/golang-auth/go-gssapi-c

I know the C folks probably won't be keen on the more OO approach - would
be interested to know how people think this compares with the Java
interface though and whether there have been any issues to be aware of with this approach.

Many thanks!

Jake
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On Thu, 2025-10-23 at 18:53 -0600, Jake Scott wrote:

Hi there..

I've been working on a spec for GSSAPI on Go similar to RFC2744 and RFC2853 for C and Java. I have a working implementation of the described interface and a provider that wraps the MIT & Heimdal C libraries. The idea is to provide an idomatic interface for Go developers that supports multiple providers (like the C provider or a pure Go provider at some point).

I would love some feedback before launching this on the world! It is currently in beta, and the docs/code are at:

The interface spec: https://github.com/golang-auth/go-gssapi/wiki
.. and the code for the interface and provider register: https://github.com/golang-auth/go-gssapi

And the C provider: https://github.com/golang-auth/go-gssapi-c

I know the C folks probably won't be keen on the more OO approach - would
be interested to know how people think this compares with the Java
interface though and whether there have been any issues to be aware of with this approach.

Many thanks!

Very nice work Jake,
if you haven't already looked at it I would carefully comb through https://github.com/pythongssapi/python-gssapi (and its documentation)
to see how we did split things between a higher level and a lower
level (raw) API.

This will push your users to avoid falling in some traps.

I would strongly suggest you implement the CredStore extension
(original project:
https://k5wiki.kerberos.org/wiki/Projects/Credential_Store_extensions-a
) as it makes some use case much easier to deal with than trying to
manually juggle credentials, with less side effects.

And as Michael mentioned, I would strongly suggest avoiding trying to
build a native implementation, it would be a huge time-sink with hard
to achieve maturity. It may seem fun initially bug both libkrb5 and
libgssapi have devilish details that you won't see when testing simple applications (including support for out of tree plugins like-ahttps://github.com/gssapi/gss-ntlmssp and support for cache types
that require exact semantic to interoperate correctly (and some of
those differ between C implementations already).

That said given this API allow users to easily switch between a naive/incomplete and a good implementation somewhat easily that is less
of a concern to me.

Finally I am not super-familiar with Go APIs so it would be easier to
judge the API if you had a code example of a full GSSAPI context
establishment loop on the client and on the server side separately.
Error handling and continuations being important to get right to be
usable in real scenario.

HTH,
Simo.
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On Fri, Oct 24, 2025 at 7:55rC>AM Simo Sorce <simo@redhat.com> wrote:
if you haven't already looked at it I would carefully comb through

https://github.com/pythongssapi/python-gssapi (and its documentation)
to see how we did split things between a higher level and a lower
level (raw) API.

Thanks - the python bindings were one of the things I looked at actually.
Do you find
users making use of the low level API much?.. I wondered what the
motivation there
was. I like the way the API deals with extensions and that influenced how
the Go bindings
do that also (not that they're all implemented yet)

I would strongly suggest you implement the CredStore extension
(original project:
https://k5wiki.kerberos.org/wiki/Projects/Credential_Store_extensions
) as it makes some use case much easier to deal with than trying to
manually juggle credentials, with less side effects.

Thanks I'll look into that!

And as Michael mentioned, I would strongly suggest avoiding trying to
build a native implementation, it would be a huge time-sink with hard
to achieve maturity.

I agree that a pure-Go implementation is likely never going to be
as complete or well tested as MIT or Heimdal. What drove me to do this
project in the first place is the disconnect between the desire of Go developers
in general for a pure-go solution vs the reality that the existing implementation
was no where near production ready. Having one standard we develop against allows us some flexibility for future developments though..
I would guess that the vast majority of applications making use of GSSAPI probably use a small subset of the functionality and probably a very large percentage of users still use a file based credential cache. So a cut-down less complete provider might be of benefit for those folks esp. those who
just won't use C bindings to anything. Honestly I think I would focus on
a decent SASL implemementation before thinking about any of that though. Finally I am not super-familiar with Go APIs so it would be easier to

judge the API if you had a code example of a full GSSAPI context establishment loop on the client and on the server side separately.
Error handling and continuations being important to get right to be
usable in real scenario.

Absolutely - take a look at https://github.com/golang-auth/gssapi-examples/tree/main/go
Thanks for the feedback!
Jake
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

Hi Michael thanks for your reply. Didn't receive it in email for reason;
found it on the mailing list archive..
On Thu, Oct 23, 2025 at 6:53rC>PM Osipov, Michael (IN IT IN) < michael.osipov@innomotics.com> wrote:

* Have you looked into py-gssapi? It is a very clean, yet convenient
wrapper your C GSS-API. I have been using it at low-level and high-level
with please without the need to resort to C?

I did - its a very nice to use API that I have made use of myself and influenced some of the Go API design.
I'm not sure of the reason for the low level part though - certianly in Go there are idiomatic ways to do things
and I don't know that exposing the GSS calls directly fits that bill. I am
no Python developer though - I assumed
the same would be true there so I'm certainly interested in why someone
might want to use the
lower level APIs from a high level language like that..
* The JGSS RFC is very dated and lacks a lot of features which have been

introduced in the C API in the past decade. There is now also an ExtendedJGSSContext you might want to check.
* You should write to security-dev at openjdk mailing list and ask Max (Weijun Wang). He is the lead guy for JGSS impl at Oracle. Feel free to mention my name.

Thanks that's useful info - I didn't know about the extended context and
will certainly chat to the Java
guys.
* Since you support Apple Kerberos, see

https://github.com/curl/curl/issues/19109. This might be interesting for
you.

That is interesting - why would you enable channel bindings by default. I
will do some more MacOS
testing..
* FreeBSD base Kerbros: The ancient Heimdal has been replaced with MIT

Kerberos 1.22.1 in the base system for 15. You might want to check that.

Great news and about to install a FBSD 15 system to test with, thanks!
Does it easily plug into Go's URL transport library, e.g.,

py-requests-gssapi to authenticate via SPENGO?

Yes I've already used it for that purpose. But I think its not a bad idea
to ship something
that makes this simple for developers - I would guess that Negotiate is probably
the primary usecase. Thanks fot the suggestion.
** Python uses OpenLDAP libs with Cyrus SASL where SASL GSSAPI mech

comes for free, I have seen that you provide LDAP examples as well, how trivial is it to make this happen in the Go impl too? This might get interesting for us as well (LDAP calls to Active Directory)?

So I wrote a very bare bones SASL library for Go a number of years ago that
I am not
very proud of (https://github.com/golang-auth/go-sasl if you're brave
enough). I intend
on moving on to actually making this something I'm happy to use 'next' and talking to
folks that have Go libraries that fudge SASL to integrate that instead (including
the nice people at https://github.com/go-ldap/ldap)
Java's ticket cache is pure memory which means pure crap. I need to

change and fiddle with the Subject between threads in a thread pool
executor while MIT Kerberos does this nicely either with a file-based or KCM-based cache. The Java approach leads to more code or a cache
per-thread which is slow to populate.

That is also the approach to the old pure-go Kerberos implemetation. I did write a patch
that used a file CCcache in a way that was compatible with MIT but just abandoned it
in favour of this project eventually.
You might be pleasantly surprised to hear that a colleage of mine is close
to submitting
a PR that will introduce KCM support for Java. We use KCM at my place of
work with
a custom KCM daemon (which I'm told we're also going to open source, just
don't hold
me to that).
Many thanks,
Jake
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On Sat, Oct 25, 2025 at 2:16rC>AM Jake Scott <jake@poptart.org> wrote:

I would guess that the vast majority of applications making use of
GSSAPI probably use a small subset of the functionality

Perhaps, but any heterogeneous site where Microsoft Active Directory
is used and is authoritative is going to leverage GSSAPI heavily.

and probably a very large percentage of users still use a file based credential cache. So a cut-down less complete provider might be of
benefit for those folks esp. those who just won't use C bindings to
anything. Honestly I think I would focus on a decent SASL
implemementation before thinking about any of that though.

While the FILE: ccache type is the oldest and simplest, both the KEYRING:persistent and (especially) the KCM: ccache types offer
significant advantages. So I wouldnrCOt necessarily assume that yourCOre
not going to commonly encounter other ccache types than FILE:.

(For example, KCM: has been the default ccache type in Fedora since at
least Fedora 41.)

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On Fri, Oct 24, 2025 at 4:15rC>AM Osipov, Michael (IN IT IN) via Kerberos < kerberos@mit.edu> wrote:

Java's ticket cache is pure memory which means pure crap. I need to
change and fiddle with the Subject between threads in a thread pool
executor while MIT Kerberos does this nicely either with a file-based or KCM-based cache. The Java approach leads to more code or a cache
per-thread which is slow to populate.

This is the biggest problem with security APIs in general and is not
specific to Java.
RFCs, drafts and implementations tend to focus on authentication and crypto
but what is equally important and almost completely overlooked is the management of secrets, accounts and trusts.
Ideally every device should have a virtualized program that manages secrets like plaintext, base keys, tickets, access tokens etc associated and
accounts (probably non-authoritative proxy account but could also be authoritative local) and trusts (which implicitly covers the concepts of
realms and domains).
Programs would connect to this program over a pipe or socket, get a session
id and then let it produce / consume tokens like GSS, bearer etc and leave
the specifics of "providers" and protection of secrets up to the host
device.
Of course I'm leaving a lot out like syncing data between devices (the
achilles heel of passkeys), role mapping, ...
Mike
--
Michael B Allen
Java AD DS Integration
https://www.ioplex.com/ <http://www.ioplex.com/>
--- Synchronet 3.21a-Linux NewsLink 1.2