Re: appl/simple/client/sim_client.c uses internal APIs

[Florian Weimer]

Thank you for your help regarding this matter.  In the end, I could not
fix the Authen::Krb5 Perl module because there are some fundamental
reference counting problems in it.  The code sort-of works today because
it papers over these issues by using internal libkrb5 APIs, which I
suspect happen to work mostly by accident (that, or the code is actually
dead because the reference counts never go to zero for some reason).
This is a Perl XS issue, unrelated to Kerberos.  It's fairly clear how
to fix it in princple, but I haven't done any serious Perl programming
in over a decade, and the upstream maintainer has archived the Git
repository recently anyway.

Thanks,
Florian


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Greg Hudson]

On 2/24/23 06:15, Florian Weimer wrote:

I need to fix Authen::Krb5 (a Perl wrapper) not rely on this krb5
internals.  Obviously, this is going to stay a krb5 wrapper, and won't
switch to GSSAPI.  So I'd really appreciate if someone would fix the
appl/simple/client/sim_client.c example not to rely on , so
that I can apply the parallel changes to the Perl port of this example
code.


Done:

https://github.com/krb5/krb5/commit/9139a60c94c24e41109574e84e7cda9c2dc3fb38

If possible, the Perl client code should be changed to use 
AP_OPTS_USE_SUBKEY, in addition to removing the replay cache calls.


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Russ Allbery]

Simo Sorce  writes:
> On Fri, 2023-02-24 at 16:27 -0800, Russ Allbery wrote:

>> Essentially everything that I don't like about GSSAPI is a direct
>> consequence of the fact that it's a generic authentication protocol
>> that in theory (although essentially never in practice outside of toys
>> and science experiments) could negotiate a mechanism other than
>> Kerberos.  Supporting that generality forces the addition of
>> irreducible complexity to the API.

> Sorry Russ,
> I do not know about toys or science experiments, but I have been using
> GSSAPI in real HTTP applications to do either NTLM or Krb5 just fine.
> And before that in SMB applications (although Samba is more complicated
> because of its history).

Argh, sorry, I got this backwards, and I think this is the same mistake
that I have made before.  For some reason it is stuck in my head that
SPNEGO is used to negotiate GSSAPI when it's the other way around: SPNEGO
is a GSSAPI mechanism.

Thank you all for the interesting feedback on this thread.  I think my
original statement had a few things wrong, and I appreciate all the
corrections.

My basic point is that I understand the need to first negotiate a security
mechanism and then use that security mechanism, but I don't like the
layering of multiple negotiation mechanisms, so I'm not a big fan of SASL
and GSSAPI/SPNEGO being separate and HTTP using yet another negotiation
protocol via WWW-Authenticate headers, although I understand why this
happened.

Ideally, I'd like to have three concepts: a negotiation protocol, a
security protocol for Kerberos, and an encoding layer for both of those
protocols into the application protocol (HTTP, IMAP, whatever) that deals
with problems like how to put this into valid HTTP requests.  I feel like
we've collectively taken multiple shots at this over the years and we keep
getting closer, but we keep ending up with the divisions between the
layers being murky and having multiple negotiation layers, and that in
turn makes the code more complicated.  And this is probably a pipe dream
at this point, since all this stuff is very baked into long-standing
protocols that are unlikely to change significantly.

More actionably, for a lot of applications I think there's some merit in
dispensing with the negitiation layer and having one single supported
security mechanism and that's it.  This was the idea behind Wireguard, and
I think it's an interesting model.  This isn't suitable for IMAP or HTTP
or whatnot for obvious reasons, but it adds a lot of simplicity when one
knows what security mechanism is in play because the (often private)
protocol only supports a single one and can just use it directly.  And
this is what becomes impossible when GSSAPI is the only recommended way of
using Kerberos, because then you can't get rid of the generic layer of the
API even if you don't need it, so you're stuck with having multiple
identity concepts, etc.  (I do understand all of the other problems with
the raw Kerberos API, though, and I'm not saying it should be used
instead.  The API that I actually want doesn't exist, I think.)

-- 
Russ Allbery (ea...@eyrie.org) 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Simo Sorce]

On Fri, 2023-02-24 at 16:27 -0800, Russ Allbery wrote:
> Essentially everything that I don't like about GSSAPI is a direct
> consequence of the fact that it's a generic authentication protocol that
> in theory (although essentially never in practice outside of toys and
> science experiments) could negotiate a mechanism other than Kerberos.
> Supporting that generality forces the addition of irreducible complexity
> to the API.

Sorry Russ,
I do not know about toys or science experiments, but I have been using
GSSAPI in real HTTP applications to do either NTLM or Krb5 just fine.
And before that in SMB applications (although Samba is more complicated
because of its history).

It is true that is very easy to make applications that work only with
one mechanism, but that's not because it is hard to make application
work with multiple ones. It is mostly due to the fact that application
writers tend to use only one mechanism, and as soon as they can make it
work with their application they call it done and ship it.

Classically the 1 roundtrip vs multiple roundtrips makes all multiple
rountrips mechanism break when the developer used only krb5 as the
mechanism for their application. I think that is fine, the beauty of
code is that it can be changed and fixed as needed.

Incidentally if the GSSAPI had not been too picky about security (I
know ... I know) and had provide a one roundtrip, password based
mechanism, that could establish a secure channel, we would probably
have had a lot more success with GSSAPI, but I digress..

This comes back to the fact GSSAPI tends to be a "better" API than krb5
APIs, not a simpler one. The lack of documentation on *how* to use
GSSAPI and well explained examples is part of the problem, as well as
the older GSSAPI (before the extensions) basically not being complete
on the client side.

In any case my problem with krb5 APIs is that people get that stuff
even more wrong than with GSSAPI.

The way I see it krb5 is a simple sharp edge of an API while GSSAPI is
like the blob, you never quite get the best shape but it has no sharp
edges either and tends to slowly absorb mechanisms if you let it :)

I choose the latter because it ends up being safer than the former, and
at least in the Open Source world, there are a lot more coding hands
than krb5 experts... and I suspect that is true in any other world, so
perhaps that should be the default choice regardless.

The truth is that non-security-savvy developers (the majority) would
just like a generic API, that always work, is simple, is always secure,
and stay out of the way (and has no dependencies, and can be easily
open coded, and...).

Until that holy grail is found I assume we'll always have arguments
about what is better or simpler or ..., and nobody will ever win one,
because what is better depends on the situation and the protocol and
the ecosystem, and the use case and the point of view...

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc





Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Nico Williams]

On Fri, Feb 24, 2023 at 04:27:28PM -0800, Russ Allbery wrote:
> Primarily what I'd want in a new mechanism is for it to be a protocol for
> Kerberos authentication.  (Or some other underlying authentication system
> that we all use instead, although that would be off-topic for this group.)

I'd settle for a new mechanism that can handle Kerberos naming.  I don't
care if there's a KDC or a CA or both or whatever other kind of trusted
third party, and if it has a non-trusted-third-party mode, etc.  Just
the naming is enough for me because that's what I've to be compatible
with.  Specifically: a) user@REALM style naming (user@domain might do,
with case insensitive domains so upcasing is safe), b)
service/hostname[@REALM] style service naming.

Certainly an API for such a mechanism only could be simpler than both,
krb5 and GSS.

If you want an example of what I object to in the krb5 API: everything
to do with krb5_cred and everything to do with krb5_auth_context --
those APIs are rather complicated and require developer understanding of
a myriad options that shouldn't be.

> In other words, not generic.  I understand why GSSAPI was made generic,
> but that's not what I want, and I think the security world is starting to
> realize that being able to negotiate every security property and mechanism
> is more of a bug than a feature.

At $WORK we've built bridging of all the auth methods for this sort of
reason.  Getting every app to use ${preferred_mechanism} turns out to be
impossible.  Bridging all the authentication infrastructures, OTOH, is
possible.

> Right now, it is possible to get into the truly absurd situation where to
> authenticate a client to a server you use:
> 
> * HTTP authentication, to negotiate
> * SPNEGO, to negotiate
> * GSASPI, to negotiate
> * Kerberos, to do the actual authentication

For HTTP you can just use Negotiate w/o SPNEGO.  Just because it's
called Negotiate doesn't mean you must use SPNEGO.  Negotiate is a
misnomer.

> Something similar happens with SASL.  This is three layers of negotiation
> too many.  [...]
> 
> I understand the need for *a* negotiation layer.  I think the error was in
> accepting additional negotiation layers below that, as opposed to getting
> out of the generic mode as quickly as possible and start working directly
> with the true protocol.

We've recognized that multi-layer negotiation is broken since at least
2004 or earlier, and we've studiously avoided it.  SASL/GS1 and SASL/GS2
specifically forbid use of SPNEGO, and so does SSHv2, for this reason.

I'm not aware of any Internet protocol, or even any proprietary
application, that can end up doing multiple layers of negotiation.

(I'm not counting algorithm negotiation within a mechanism as a distinct
negotiation layer, mind you, because the topic is negotiation of
mechanisms, not of mechanism-specific details.)

> Essentially everything that I don't like about GSSAPI is a direct
> consequence of the fact that it's a generic authentication protocol that
> in theory (although essentially never in practice outside of toys and
> science experiments) could negotiate a mechanism other than Kerberos.
> Supporting that generality forces the addition of irreducible complexity
> to the API.

The Solaris/Illumos mech glue and SPNEGO implementation was in fact
truly generic.  I got ssh/sshd to work with both, mech_krb5 and mech_dh
w/ zero mechanism-specific code in ssh/sshd, and that was more than 15
years ago.  Granted, mech_dh was practically obsolete, but we could have
tried to revive it, and I still think that a variation on mech_dh would
be a good foundation for a replacement for Kerberos.

Specifically my idea is to take JWT, enrich it with a standard
fetch-a-rock protocol for it (like the TGS protocol is for Kerberos),
enrich JWT tokens with client ECDH public keys, enrich the system with a
lookup service for service ECDH public keys (either in the fetch-a-rock
protocol or using DNS a la DANE), enrich JWT w/ Kerberos-style [public]
authz data, and enrich JWT tokens with Kerberos style naming support.

The result should be a) compatible with JWT, b) mech_dh-like in
mechanics, c) compatible with Kerberos style naming and authz data, but
it wouldn't be Kerberos as it is today.  Part of the idea is to make it
much easier to implement.

> (There is the other problem that all of the effort, hardware support, and
> optimization work is going into TLS now, and it feels like a huge waste of
> energy to try to compete with TLS in the secure transport business.  But
> that's a whole different can of worms since TLS is very wedded to X.509
> certificates and there are a bunch of very good reasons to not want to use
> X.509 certificates for client authentication in a lot of situations.)

The only problem I have with x.509 is x.500 naming and the paucity of
support for SAN-based authorization of _clients_.  Otherwise I just
don't mind the use of x.509.  But I might be biased because the biggest
problem many people have w

Re: appl/simple/client/sim_client.c uses internal APIs

[Benjamin Kaduk]

On Fri, Feb 24, 2023 at 04:27:28PM -0800, Russ Allbery wrote:
> 
> (There is the other problem that all of the effort, hardware support, and
> optimization work is going into TLS now, and it feels like a huge waste of
> energy to try to compete with TLS in the secure transport business.  But
> that's a whole different can of worms since TLS is very wedded to X.509
> certificates and there are a bunch of very good reasons to not want to use
> X.509 certificates for client authentication in a lot of situations.)

In case you haven't been following, OpenSSL is set to grow TLS raw public
key support soon, probably in 3.1 or so:
https://github.com/openssl/openssl/pull/18185
I've seen a number of places picking up on TLS with raw public key as an
option for secure transport when they don't want to be wedded to X.509
certificates (whether for client or for server).  You do have to supply
your own authorization layer, then, of course, but you may already have
one.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Sam Hartman]

> "Ken" == Ken Hornstein via Kerberos  writes:

Ken> I can't argue your preference, and I'll be the first to admit
Ken> that "simpler" can be subjective (although I would argue one
Ken> metric, "lines of code", the krb5 API would win).  But let me
Ken> point out a few things:

Ken> - I alluded to this on the kitten list (and I know you replied
Ken> there but I didn't get to reply to it yet), but the issue of
Ken> multiple round trips is a concern.  You point out that even
Ken> with SPNEGO you should have a single round trip most of the
Ken> time and that's a fair point, but this puts you in a tough spot
Ken> with the usage of GSS; you have to assume your GSS mechanism is
Ken> a single-trip and violate the API OR complicate your protocol
Ken> and implementation design and presume an unspecified number of
Ken> round trips.  At least with the krb5 API you can definitively
Ken> design the protocol (and implementation) for a single round
Ken> trip.

As an alternative to the krb5 api, stick in the krb5 mechanism oid.
You can definitively design your protocol and implementation for a
single round trip by doing that.
You can have more code in common with applications that do support
multi-round-trip negotiations, while still getting your half or one
round trip.

--Sam

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Russ Allbery]

Nico Williams  writes:

> Which is why, for a new mechanism, I would much prefer that it support
> Kerberos naming.  Certainly I don't ever want to see a mechanism use
> x.500 style naming again.

Primarily what I'd want in a new mechanism is for it to be a protocol for
Kerberos authentication.  (Or some other underlying authentication system
that we all use instead, although that would be off-topic for this group.)
In other words, not generic.  I understand why GSSAPI was made generic,
but that's not what I want, and I think the security world is starting to
realize that being able to negotiate every security property and mechanism
is more of a bug than a feature.

Right now, it is possible to get into the truly absurd situation where to
authenticate a client to a server you use:

* HTTP authentication, to negotiate
* SPNEGO, to negotiate
* GSASPI, to negotiate
* Kerberos, to do the actual authentication

Something similar happens with SASL.  This is three layers of negotiation
too many.  Even if you can hide or eliminate all of the round trips,
you're introducing a lot of conceptual complexity, and while the developer
doesn't need to know about any of it if all goes well, all often doesn't
go well in the real world and then you have to figure out at what layer
everything broke.

I understand the need for *a* negotiation layer.  I think the error was in
accepting additional negotiation layers below that, as opposed to getting
out of the generic mode as quickly as possible and start working directly
with the true protocol.

Essentially everything that I don't like about GSSAPI is a direct
consequence of the fact that it's a generic authentication protocol that
in theory (although essentially never in practice outside of toys and
science experiments) could negotiate a mechanism other than Kerberos.
Supporting that generality forces the addition of irreducible complexity
to the API.

(There is the other problem that all of the effort, hardware support, and
optimization work is going into TLS now, and it feels like a huge waste of
energy to try to compete with TLS in the secure transport business.  But
that's a whole different can of worms since TLS is very wedded to X.509
certificates and there are a bunch of very good reasons to not want to use
X.509 certificates for client authentication in a lot of situations.)

-- 
Russ Allbery (ea...@eyrie.org) 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Ken Hornstein via Kerberos]

>As an alternative to the krb5 api, stick in the krb5 mechanism oid.
>You can definitively design your protocol and implementation for a
>single round trip by doing that.
>You can have more code in common with applications that do support
>multi-round-trip negotiations, while still getting your half or one
>round trip.

I mean, fair point; that certainly would work.  But if I was doing it
for something internal and I didn't care about portability it wouldn't
alleviate all of the other negatives to the GSSAPI that Russ has
pointed out more eloquently than I.

--Ken

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Nico Williams]

On Fri, Feb 24, 2023 at 05:57:22PM -0500, Ken Hornstein via Kerberos wrote:
> I can't argue your preference, and I'll be the first to admit that
> "simpler" can be subjective (although I would argue one metric, "lines
> of code", the krb5 API would win).  But let me point out a few things:

Of course.  Preferences are personal.

> - I alluded to this on the kitten list (and I know you replied there
>   but I didn't get to reply to it yet), but the issue of multiple round
>   trips is a concern.  You point out that even with SPNEGO you should
>   have a single round trip most of the time and that's a fair point,
>   but this puts you in a tough spot with the usage of GSS; you have to
>   assume your GSS mechanism is a single-trip and violate the API OR
>   complicate your protocol and implementation design and presume an
>   unspecified number of round trips.  At least with the krb5 API you can
>   definitively design the protocol (and implementation) for a single
>   round trip.

If you have a mechanism that could use 3 round trips, GSS can't take
fewer.

SPNEGO (which isn't GSS itself) could have been designed so that the
initiator tries N mechanisms in parallel rather than in sequence.  I
suppose we could probably find a way to shoehorn that in.

> - I don't want to crap over the work Ben did on RFC 7546, but I couldn't
>   help noticing that he skipped over the vital work of extracting out
>   a useful error message out of the GSSAPI; that code alone is always
>   a mess but you'd need it anything you'd use in production.

I grant that gss_display_status() is a terrible API.  It's easy to
cargo-cult a wrapper around it though (and we should standardize one).

> >GSS does have some ugly things, mainly OIDs, but also not having
> >something like a krb5_context.  Regarding not having a krb5_context,
> >I've played with a couple of ways to fix that in Heimdal: either a)
> >enhancing the `OM_uint32 *minor_status` to be a more complex, opaque
> >object, or b) adding configuration key/value parameters to the
> >`cred_store` used in `gss_acquire_cred_from()`.
> 
> I was under the impression the "context_handle" served that purpose,
> although I realize not everything takes that as an argument.  If it
> doesn't serve that purpose then I understand the GSSAPI even less than I
> thought :-/

gss_ctx_id_t is the equivalent of krb5_auth_context, not of
krb5_context.  The word "context" here serves to confuse :(

> I recognize that the issue of krb5 API vs GSS is something that we're
> just never going to agree on.

If ever we do replace Kerberos then you might have no choice but to deal
with GSS or make krb5 APIs support the new thing.  But part of the point
of a new thing is to be simpler for implementors, while implementing a
new and old thing with the same API generally isn't simpler for them.

Nico
-- 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Russ Allbery]

Nico Williams  writes:

> RFC 7546 exists.

Yes, I am well aware that this exists.  If you can read this and come away
thinking that the API that it describes is simpler than the krb5 API, I
really don't know what to say.  Perhaps GSSAPI reflects the way that you
think more closely, so it seems simpler to you.

I use GSSAPI for new code because it is a *better* API (or, more
precisely, a better *protocol*) that fixes various underlying issues and
has better defaults.  But it is not *simpler*; quite the opposite, it's
more tedious and annoying and weird, harder to debug because of the
imposition of the generic layer that has a tendency to get in the way of
understanding what's going on, and requires you think about both Kerberos
and GSS concepts at the same time when implementing a non-trivial
application instead of focusing only on Kerberos.

Just to take another example, GSSAPI introduces yet another identity
format and now you have to be aware of both the Kerberos identity and the
GSS identity, which are sort of the same but not always.

> I've written a fair amount of app code using krb5 and GSS APIs, and I
> strongly prefer GSS code.

Well, I have written some of that code myself, and I don't agree.

> It does pay a price, but if all you need is encrypted sessions, then
> it's simple.

I think we have very different definitions of simple.

-- 
Russ Allbery (ea...@eyrie.org) 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Ken Hornstein via Kerberos]

>If you're using SPNEGO then you don't have to concern yourself with
>negotiation.  If you're implementing SSHv2 or SASL it's another story,
>though not much more complicated because you're doing negotiation at a
>layer that already does it and all you have to do is maybe pick a GSS
>mechanism.
>
>RFC 7546 exists.
>
>I've written a fair amount of app code using krb5 and GSS APIs, and I
>strongly prefer GSS code.

I can't argue your preference, and I'll be the first to admit that
"simpler" can be subjective (although I would argue one metric, "lines
of code", the krb5 API would win).  But let me point out a few things:

- I alluded to this on the kitten list (and I know you replied there
  but I didn't get to reply to it yet), but the issue of multiple round
  trips is a concern.  You point out that even with SPNEGO you should
  have a single round trip most of the time and that's a fair point,
  but this puts you in a tough spot with the usage of GSS; you have to
  assume your GSS mechanism is a single-trip and violate the API OR
  complicate your protocol and implementation design and presume an
  unspecified number of round trips.  At least with the krb5 API you can
  definitively design the protocol (and implementation) for a single
  round trip.

- I don't want to crap over the work Ben did on RFC 7546, but I couldn't
  help noticing that he skipped over the vital work of extracting out
  a useful error message out of the GSSAPI; that code alone is always
  a mess but you'd need it anything you'd use in production.

>GSS does have some ugly things, mainly OIDs, but also not having
>something like a krb5_context.  Regarding not having a krb5_context,
>I've played with a couple of ways to fix that in Heimdal: either a)
>enhancing the `OM_uint32 *minor_status` to be a more complex, opaque
>object, or b) adding configuration key/value parameters to the
>`cred_store` used in `gss_acquire_cred_from()`.

I was under the impression the "context_handle" served that purpose,
although I realize not everything takes that as an argument.  If it
doesn't serve that purpose then I understand the GSSAPI even less than I
thought :-/

I recognize that the issue of krb5 API vs GSS is something that we're
just never going to agree on.

--Ken

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Benjamin Kaduk]

On Fri, Feb 24, 2023 at 02:50:35PM -0600, Nico Williams wrote:
> On Fri, Feb 24, 2023 at 12:19:53PM -0800, Russ Allbery wrote:
> > Nico Williams  writes:
> > > If you're just trying to set up a GSS context between a client and a
> > > server, then GSS is really simple, and much simpler than the krb5 API.
> > 
> > I'm very dubious about this statement.  The requirement to handle
> > negotiation and potential multiple round trips and all the complexity with
> > major and minor status codes makes the equivalent GSS code complicated and
> > annoying.
> 
[...]
> 
> RFC 7546 exists.

And https://github.com/kaduk/gssdoc/blob/master/gss-sample.c has the
un-processed version of the sample code from the RFC; I did compile and run
it during development of the RFC.

-Ben

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Nico Williams]

On Fri, Feb 24, 2023 at 12:19:53PM -0800, Russ Allbery wrote:
> Nico Williams  writes:
> > If you're just trying to set up a GSS context between a client and a
> > server, then GSS is really simple, and much simpler than the krb5 API.
> 
> I'm very dubious about this statement.  The requirement to handle
> negotiation and potential multiple round trips and all the complexity with
> major and minor status codes makes the equivalent GSS code complicated and
> annoying.

If you're using SPNEGO then you don't have to concern yourself with
negotiation.  If you're implementing SSHv2 or SASL it's another story,
though not much more complicated because you're doing negotiation at a
layer that already does it and all you have to do is maybe pick a GSS
mechanism.

RFC 7546 exists.

I've written a fair amount of app code using krb5 and GSS APIs, and I
strongly prefer GSS code.

> GSS pays a significant price for being a generic mechanism with a
> negotiation method, and the API does not hide that price from the
> programmer.

It does pay a price, but if all you need is encrypted sessions, then
it's simple.

GSS does have some ugly things, mainly OIDs, but also not having
something like a krb5_context.  Regarding not having a krb5_context,
I've played with a couple of ways to fix that in Heimdal: either a)
enhancing the `OM_uint32 *minor_status` to be a more complex, opaque
object, or b) adding configuration key/value parameters to the
`cred_store` used in `gss_acquire_cred_from()`.

Nico
-- 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Chris Hecker]

It has been a long time since I made this evaluation so I don’t remember
the details, but I definitely do all sorts of stuff with ccaches and
keytabs and profiles and threads and static linking and controlling memory
allocations and controlling sockets and file usage and whatnot, it seemed
like GSSAPI would have been a nightmare.  Also, the design of krb5 is
pretty clear, it is lowlevel, but everything is right there, it doesn’t try
to hide much, which I value.

Anyway, if others prefer GSSAPI that’s fine with me, I just wanted speak up
and say there are some of us who like calling krb5 and kadm.

Chris


On Fri, Feb 24, 2023 at 12:43 Nico Williams  wrote:

> On Fri, Feb 24, 2023 at 01:50:58PM -0500, Ken Hornstein via Kerberos wrote:
> > >I have said this before on the list and it’s not a very popular thing to
> > >say, but I program to the krb5 public API, and it is a nice and clean
> and
> > >performant and simple and portable and flexible API, and GSSAPI looks
> like
> > >none of those things, it looks like a mess to use (just from looking at
> it
> > >for my needs, I have never programmed with it).  So, I hope there isn’t
> > >some movement to deprecate the lowlevel public krb5 API, because it is
> very
> > >useful for me at least.
>
> If you're just trying to set up a GSS context between a client and a
> server, then GSS is really simple, and much simpler than the krb5 API.
>
> If you have to deal with where credentials are (what ccaches, etc.) or
> acquiring them, then historically you couldn't really do that with GSS,
> bit now with the new gss_acquire_cred_from() and gss_store_cred_into()
> functions you can.
>
> > Dude, you are NOT the only one who feels that way, and I can't even
> > BELIEVE people argue otherwise!  Yes, the GSSAPI is a mess; there is
> > no getting around it.  The krb5 API is about 100x simpler (there are
> > more functions, true, but most of the time you only need a handful
> > of them).  I've used both; there's just no comparison.  I understand
> > why the GSSAPI was created and the point of it and I use it when I
> > feel it is appropriate; I understand why it is specified in protocol
> > standards.  But in the service of making it "generic" it ended up being
> > very complicated.  And if you want to have your protocol only require a
> > single round trip, you're stuck either calling the krb5 API directly OR
> > assuming that your GSSAPI mechanism will complete in a single round trip
> > (the latter is what Microsoft chose for their GSSAPI HTTP protocol),
> > which in my mind kind of negates the "g" in GSSAPI.
>
> The krb5 API is a mess too.  And API compatibility between Heimdal and
> MIT isn't complete.
>
> With GSS though, with the new gss_acquire_cred_from() and
> gss_store_cred_into(), I find there's very little need for krb5 APIs.
>
> For example, in a PR to Heimdal I've a GSS-based equivalent of kinit
> that has practically the same functionality as the Heimdal kinit
> command.  The only thing it doesn't have is the ability to let the KDC
> drive prompting, though I think I could do something about that too by
> encoding the necessary information into minor status codes.
>
> > However, one thing is worth mentioning: in my experience the GSSAPI
> > is portable.  The details of the krb5 API are basically tied to the
> > particular Kerberos implementation you're using, and that means you're
> > stuck either with a lot of compatibility code OR you have to compile
> > your preferred Kerberos implementation for your target platform, which
> > presents it's own issues.  If I want a truly portable application then I
> > do use the GSSAPI.
>
> Basically.
>
> Nico
> --
>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Russ Allbery]

Nico Williams  writes:

> If you're just trying to set up a GSS context between a client and a
> server, then GSS is really simple, and much simpler than the krb5 API.

I'm very dubious about this statement.  The requirement to handle
negotiation and potential multiple round trips and all the complexity with
major and minor status codes makes the equivalent GSS code complicated and
annoying.

GSS pays a significant price for being a generic mechanism with a
negotiation method, and the API does not hide that price from the
programmer.

-- 
Russ Allbery (ea...@eyrie.org) 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Sam Hartman]

> "Florian" == Florian Weimer  writes:

Florian> The Perl translation is here:

Florian> 


Florian> It's not an exact tranlation of the C because it creates a
Florian> replay cache:

Yeah, but it doesn't look like it *does* anything with the replay cache.
It looks like rdata_out mis passed as NULL in the call to krb5_mk_priv
from Krb5.xs's mk_priv all the time.

I don't think that a replay cache will ever be used on the client by
that code.
So I think you can simply remove the calls to the APIs that are
internal; they may create an empty replay cache file, but I do not think
that they add anything to the security of the code.

On the server side, you do need a replay cache, and if you call rd_priv
on the client without sequence number support you need a replay cache.
But I'm fairly sure rd_req will do that for you generally.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Nico Williams]

On Fri, Feb 24, 2023 at 01:50:58PM -0500, Ken Hornstein via Kerberos wrote:
> >I have said this before on the list and it’s not a very popular thing to
> >say, but I program to the krb5 public API, and it is a nice and clean and
> >performant and simple and portable and flexible API, and GSSAPI looks like
> >none of those things, it looks like a mess to use (just from looking at it
> >for my needs, I have never programmed with it).  So, I hope there isn’t
> >some movement to deprecate the lowlevel public krb5 API, because it is very
> >useful for me at least.

If you're just trying to set up a GSS context between a client and a
server, then GSS is really simple, and much simpler than the krb5 API.

If you have to deal with where credentials are (what ccaches, etc.) or
acquiring them, then historically you couldn't really do that with GSS,
bit now with the new gss_acquire_cred_from() and gss_store_cred_into()
functions you can.

> Dude, you are NOT the only one who feels that way, and I can't even
> BELIEVE people argue otherwise!  Yes, the GSSAPI is a mess; there is
> no getting around it.  The krb5 API is about 100x simpler (there are
> more functions, true, but most of the time you only need a handful
> of them).  I've used both; there's just no comparison.  I understand
> why the GSSAPI was created and the point of it and I use it when I
> feel it is appropriate; I understand why it is specified in protocol
> standards.  But in the service of making it "generic" it ended up being
> very complicated.  And if you want to have your protocol only require a
> single round trip, you're stuck either calling the krb5 API directly OR
> assuming that your GSSAPI mechanism will complete in a single round trip
> (the latter is what Microsoft chose for their GSSAPI HTTP protocol),
> which in my mind kind of negates the "g" in GSSAPI.

The krb5 API is a mess too.  And API compatibility between Heimdal and
MIT isn't complete.

With GSS though, with the new gss_acquire_cred_from() and
gss_store_cred_into(), I find there's very little need for krb5 APIs.

For example, in a PR to Heimdal I've a GSS-based equivalent of kinit
that has practically the same functionality as the Heimdal kinit
command.  The only thing it doesn't have is the ability to let the KDC
drive prompting, though I think I could do something about that too by
encoding the necessary information into minor status codes.

> However, one thing is worth mentioning: in my experience the GSSAPI
> is portable.  The details of the krb5 API are basically tied to the
> particular Kerberos implementation you're using, and that means you're
> stuck either with a lot of compatibility code OR you have to compile
> your preferred Kerberos implementation for your target platform, which
> presents it's own issues.  If I want a truly portable application then I
> do use the GSSAPI.

Basically.

Nico
-- 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Chris Hecker]

Sure, I agree with that rough breakdown, I just think the samples should
show a hierarchy of techniques and show the flexibility, and be named
appropriately.  I mean, if a developer is thoughtless when using a crypto
api then having messages be encrypted is not going to save them, so we need
to assume some level of competence on their part, and comment appropriately.

Chris


On Fri, Feb 24, 2023 at 12:25 Ken Hornstein  wrote:

> >I guess if I’m on a tear saying forbidden things, sometimes identity is
> all
> >you need, you don’t want all the samples to encrypt everything, because
> >that makes it look like you have to, which you don’t?  It is use-case
> >dependent, and krb5 is great because it is granular enough to let
> >developers choose what they do for their own use-cases.
>
> I'd like to push back on THIS a bit.
>
> While I agree that you don't ALWAYS need to encrypt everything, I would
> argue that in 2023 you should to encrypt everything 99% of the time, and
> the 1% you don't you should think about very carefully.  And having the
> samples encrypt stuff would be helpful as examples (and to take later
> further point, the breakdown between sample/simple always confuses me as
> well).
>
> --Ken
>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Sam Hartman]

> "Chris" == Chris Hecker  writes:

Chris> I guess if I’m on a tear saying forbidden things, sometimes
Chris> identity is all you need, you don’t want all the samples to
Chris> encrypt everything, because that makes it look like you have
Chris> to, which you don’t?  It is use-case dependent, and krb5 is
Chris> great because it is granular enough to let developers choose
Chris> what they do for their own use-cases.


My suspicion is that people are still really bad at figuring out whether
they need integrity.
I think a sample that does not either use TLS or use integrity
protection does a disservice to the community.
Because basically I don't think there are a lot of cases where identity
is all you need (other than when running over TLS), and I think people
are far more likely to believe they can get away with just identity than
is actually the case.

--Sam


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Florian Weimer]

* Sam Hartman:

>> "Florian" == Florian Weimer  writes:
>
> Florian> * Sam Hartman:
> >>> "Simo" == Simo Sorce  writes:
> >> 
> Simo> Wherever possible you should recommend people use GSSAPI and
> Simo> not krb5 APIs directly, unless they are building tools
> Simo> specifically to manage aspects of krb5 (acquiring tickets,
> Simo> managing ccaches, etc.)
> >> 
> >> I agree with the above.  I also think that the simple client
> >> referred to in the subject has a bunch of anti-patterns.  As an
> >> example, I don't think it integrity protects or encrypts its
> >> exchanges; I think it's too simple to actually be useful in
> >> today's world.
> >> 
> >> That said, it looks like krb5_auth_con_genaddrs is probably the
> >> API you want to use instead of krb5_gen_portaddr.  It takes an
> >> auth context and a socet FD and extracts addresses from the
> >> socket FD.
> >> 
> >> I suspect that the auth context machinery will generate the
> >> replay cache name for you, and again, you don't need that API
> >> either.  But please use GSS-API instead:-)
>
> Florian> I need to fix Authen::Krb5 (a Perl wrapper) not rely on
> Florian> this krb5 internals.  Obviously, this is going to stay a
> Florian> krb5 wrapper, and won't switch to GSSAPI.  So I'd really
> Florian> appreciate if someone would fix the
> Florian> appl/simple/client/sim_client.c example not to rely on
> Florian> , so that I can apply the parallel changes to the
> Florian> Perl port of this example code.
>
> That code is not maintained, and I'd probably fix it with git rm.
> If you'll point me at upstreams sources for authen::krb5 I'll take a
> look and figure out a recommendation for whether delete or some sort of
> repair is best in that case.

The Perl translation is here:



It's not an exact tranlation of the C because it creates a replay cache:

  # create the replay cache
  ($l,$r) = $ac->getaddrs();
  $lap = Authen::Krb5::gen_portaddr($l,$s->sockport());
  $rcn = Authen::Krb5::gen_replay_name($lap,"foobar");
  $rc = Authen::Krb5::get_server_rcache($rcn);
  $ac->setrcache($rc);

The setrcache part is missing in the C version, it seems.

If the Perl example is still broken, we should of course remove it.

Thanks,
Florian


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Ken Hornstein via Kerberos]

>I guess if I’m on a tear saying forbidden things, sometimes identity is all
>you need, you don’t want all the samples to encrypt everything, because
>that makes it look like you have to, which you don’t?  It is use-case
>dependent, and krb5 is great because it is granular enough to let
>developers choose what they do for their own use-cases.

I'd like to push back on THIS a bit.

While I agree that you don't ALWAYS need to encrypt everything, I would
argue that in 2023 you should to encrypt everything 99% of the time, and
the 1% you don't you should think about very carefully.  And having the
samples encrypt stuff would be helpful as examples (and to take later
further point, the breakdown between sample/simple always confuses me as
well).

--Ken

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Chris Hecker]

I guess if I’m on a tear saying forbidden things, sometimes identity is all
you need, you don’t want all the samples to encrypt everything, because
that makes it look like you have to, which you don’t?  It is use-case
dependent, and krb5 is great because it is granular enough to let
developers choose what they do for their own use-cases.

In my opinion, the problem with the samples is they are in multiple places
if I recall, and they aren’t super obviously named so it’s not clear what
simple va sample means, etc.  But I used them all (including the u2u one)
in learning and they were useful, they could just use a little love and
organization and documentation.

If they’re calling internal stuff that should be fixed too obvs, but they
don’t need to be gutted.

Chris


On Fri, Feb 24, 2023 at 11:59 Chris Hecker  wrote:

>
> Yeah, by portable I meant I just compile the parts of krb5 client code I
> need when necessary.  The krb5 client is very portable and fairly small.  I
> strip out some stuff I don’t use,  but not too much.
>
> Chris
>
>
> On Fri, Feb 24, 2023 at 11:51 Ken Hornstein  wrote:
>
>> >I have said this before on the list and it’s not a very popular thing to
>> >say, but I program to the krb5 public API, and it is a nice and clean and
>> >performant and simple and portable and flexible API, and GSSAPI looks
>> like
>> >none of those things, it looks like a mess to use (just from looking at
>> it
>> >for my needs, I have never programmed with it).  So, I hope there isn’t
>> >some movement to deprecate the lowlevel public krb5 API, because it is
>> very
>> >useful for me at least.
>>
>> Dude, you are NOT the only one who feels that way, and I can't even
>> BELIEVE people argue otherwise!  Yes, the GSSAPI is a mess; there is
>> no getting around it.  The krb5 API is about 100x simpler (there are
>> more functions, true, but most of the time you only need a handful
>> of them).  I've used both; there's just no comparison.  I understand
>> why the GSSAPI was created and the point of it and I use it when I
>> feel it is appropriate; I understand why it is specified in protocol
>> standards.  But in the service of making it "generic" it ended up being
>> very complicated.  And if you want to have your protocol only require a
>> single round trip, you're stuck either calling the krb5 API directly OR
>> assuming that your GSSAPI mechanism will complete in a single round trip
>> (the latter is what Microsoft chose for their GSSAPI HTTP protocol),
>> which in my mind kind of negates the "g" in GSSAPI.
>>
>> However, one thing is worth mentioning: in my experience the GSSAPI
>> is portable.  The details of the krb5 API are basically tied to the
>> particular Kerberos implementation you're using, and that means you're
>> stuck either with a lot of compatibility code OR you have to compile
>> your preferred Kerberos implementation for your target platform, which
>> presents it's own issues.  If I want a truly portable application then I
>> do use the GSSAPI.
>>
>> --Ken
>>
>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Greg Hudson]

On 2/23/23 12:34, Sam Hartman wrote:

I also think that the simple client referred to in the subject has a
bunch of anti-patterns.
As an example, I don't think it integrity protects or encrypts its
exchanges


I think appl/simple actually does protect messages but appl/sample does not.

It looks like the uses of krb5_gen_portaddr() and krb5_gen_replay_name() 
in sim_client.c don't do anything after commit 
dcb853ac32779b173f39e19c0f24b0087de85771 so they can be removed (I just 
didn't realize it at the time).


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Chris Hecker]

Yeah, by portable I meant I just compile the parts of krb5 client code I
need when necessary.  The krb5 client is very portable and fairly small.  I
strip out some stuff I don’t use,  but not too much.

Chris


On Fri, Feb 24, 2023 at 11:51 Ken Hornstein  wrote:

> >I have said this before on the list and it’s not a very popular thing to
> >say, but I program to the krb5 public API, and it is a nice and clean and
> >performant and simple and portable and flexible API, and GSSAPI looks like
> >none of those things, it looks like a mess to use (just from looking at it
> >for my needs, I have never programmed with it).  So, I hope there isn’t
> >some movement to deprecate the lowlevel public krb5 API, because it is
> very
> >useful for me at least.
>
> Dude, you are NOT the only one who feels that way, and I can't even
> BELIEVE people argue otherwise!  Yes, the GSSAPI is a mess; there is
> no getting around it.  The krb5 API is about 100x simpler (there are
> more functions, true, but most of the time you only need a handful
> of them).  I've used both; there's just no comparison.  I understand
> why the GSSAPI was created and the point of it and I use it when I
> feel it is appropriate; I understand why it is specified in protocol
> standards.  But in the service of making it "generic" it ended up being
> very complicated.  And if you want to have your protocol only require a
> single round trip, you're stuck either calling the krb5 API directly OR
> assuming that your GSSAPI mechanism will complete in a single round trip
> (the latter is what Microsoft chose for their GSSAPI HTTP protocol),
> which in my mind kind of negates the "g" in GSSAPI.
>
> However, one thing is worth mentioning: in my experience the GSSAPI
> is portable.  The details of the krb5 API are basically tied to the
> particular Kerberos implementation you're using, and that means you're
> stuck either with a lot of compatibility code OR you have to compile
> your preferred Kerberos implementation for your target platform, which
> presents it's own issues.  If I want a truly portable application then I
> do use the GSSAPI.
>
> --Ken
>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Ken Hornstein via Kerberos]

>I have said this before on the list and it’s not a very popular thing to
>say, but I program to the krb5 public API, and it is a nice and clean and
>performant and simple and portable and flexible API, and GSSAPI looks like
>none of those things, it looks like a mess to use (just from looking at it
>for my needs, I have never programmed with it).  So, I hope there isn’t
>some movement to deprecate the lowlevel public krb5 API, because it is very
>useful for me at least.

Dude, you are NOT the only one who feels that way, and I can't even
BELIEVE people argue otherwise!  Yes, the GSSAPI is a mess; there is
no getting around it.  The krb5 API is about 100x simpler (there are
more functions, true, but most of the time you only need a handful
of them).  I've used both; there's just no comparison.  I understand
why the GSSAPI was created and the point of it and I use it when I
feel it is appropriate; I understand why it is specified in protocol
standards.  But in the service of making it "generic" it ended up being
very complicated.  And if you want to have your protocol only require a
single round trip, you're stuck either calling the krb5 API directly OR
assuming that your GSSAPI mechanism will complete in a single round trip
(the latter is what Microsoft chose for their GSSAPI HTTP protocol),
which in my mind kind of negates the "g" in GSSAPI.

However, one thing is worth mentioning: in my experience the GSSAPI
is portable.  The details of the krb5 API are basically tied to the
particular Kerberos implementation you're using, and that means you're
stuck either with a lot of compatibility code OR you have to compile
your preferred Kerberos implementation for your target platform, which
presents it's own issues.  If I want a truly portable application then I
do use the GSSAPI.

--Ken

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Chris Hecker]

I have versions of both perl packages (krb5 and admin) that I work on
locally and have assumed I’d contribute back at some point.  It would be a
shame to delete them from cpan, they work well after some fixes.  I use my
versions in production.

I have said this before on the list and it’s not a very popular thing to
say, but I program to the krb5 public API, and it is a nice and clean and
performant and simple and portable and flexible API, and GSSAPI looks like
none of those things, it looks like a mess to use (just from looking at it
for my needs, I have never programmed with it).  So, I hope there isn’t
some movement to deprecate the lowlevel public krb5 API, because it is very
useful for me at least.

Chris


On Fri, Feb 24, 2023 at 08:55 Sam Hartman  wrote:

> > "Florian" == Florian Weimer  writes:
>
> Florian> * Sam Hartman:
> >>> "Simo" == Simo Sorce  writes:
> >>
> Simo> Wherever possible you should recommend people use GSSAPI and
> Simo> not krb5 APIs directly, unless they are building tools
> Simo> specifically to manage aspects of krb5 (acquiring tickets,
> Simo> managing ccaches, etc.)
> >>
> >> I agree with the above.  I also think that the simple client
> >> referred to in the subject has a bunch of anti-patterns.  As an
> >> example, I don't think it integrity protects or encrypts its
> >> exchanges; I think it's too simple to actually be useful in
> >> today's world.
> >>
> >> That said, it looks like krb5_auth_con_genaddrs is probably the
> >> API you want to use instead of krb5_gen_portaddr.  It takes an
> >> auth context and a socet FD and extracts addresses from the
> >> socket FD.
> >>
> >> I suspect that the auth context machinery will generate the
> >> replay cache name for you, and again, you don't need that API
> >> either.  But please use GSS-API instead:-)
>
> Florian> I need to fix Authen::Krb5 (a Perl wrapper) not rely on
> Florian> this krb5 internals.  Obviously, this is going to stay a
> Florian> krb5 wrapper, and won't switch to GSSAPI.  So I'd really
> Florian> appreciate if someone would fix the
> Florian> appl/simple/client/sim_client.c example not to rely on
> Florian> , so that I can apply the parallel changes to the
> Florian> Perl port of this example code.
>
> That code is not maintained, and I'd probably fix it with git rm.
> If you'll point me at upstreams sources for authen::krb5 I'll take a
> look and figure out a recommendation for whether delete or some sort of
> repair is best in that case.
> If the code actually provides integrity and confidentiality protection
> it is salvagable.  Otherwise it is probably worth deleting.
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Sam Hartman]

> "Florian" == Florian Weimer  writes:

Florian> * Sam Hartman:
>>> "Simo" == Simo Sorce  writes:
>> 
Simo> Wherever possible you should recommend people use GSSAPI and
Simo> not krb5 APIs directly, unless they are building tools
Simo> specifically to manage aspects of krb5 (acquiring tickets,
Simo> managing ccaches, etc.)
>> 
>> I agree with the above.  I also think that the simple client
>> referred to in the subject has a bunch of anti-patterns.  As an
>> example, I don't think it integrity protects or encrypts its
>> exchanges; I think it's too simple to actually be useful in
>> today's world.
>> 
>> That said, it looks like krb5_auth_con_genaddrs is probably the
>> API you want to use instead of krb5_gen_portaddr.  It takes an
>> auth context and a socet FD and extracts addresses from the
>> socket FD.
>> 
>> I suspect that the auth context machinery will generate the
>> replay cache name for you, and again, you don't need that API
>> either.  But please use GSS-API instead:-)

Florian> I need to fix Authen::Krb5 (a Perl wrapper) not rely on
Florian> this krb5 internals.  Obviously, this is going to stay a
Florian> krb5 wrapper, and won't switch to GSSAPI.  So I'd really
Florian> appreciate if someone would fix the
Florian> appl/simple/client/sim_client.c example not to rely on
Florian> , so that I can apply the parallel changes to the
Florian> Perl port of this example code.

That code is not maintained, and I'd probably fix it with git rm.
If you'll point me at upstreams sources for authen::krb5 I'll take a
look and figure out a recommendation for whether delete or some sort of
repair is best in that case.
If the code actually provides integrity and confidentiality protection
it is salvagable.  Otherwise it is probably worth deleting.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Florian Weimer]

* Sam Hartman:

>> "Simo" == Simo Sorce  writes:
>
> Simo> Wherever possible you should recommend people use GSSAPI and
> Simo> not krb5 APIs directly, unless they are building tools
> Simo> specifically to manage aspects of krb5 (acquiring tickets,
> Simo> managing ccaches, etc.)
>
> I agree with the above.
> I also think that the simple client referred to in the subject has a
> bunch of anti-patterns.
> As an example, I don't think it integrity protects or encrypts its
> exchanges; I think it's too simple to actually be useful in today's
> world.
>
> That said,  it looks like krb5_auth_con_genaddrs is probably the API you
> want to use instead of krb5_gen_portaddr.  It takes an auth context and
> a socet FD and extracts addresses from the socket FD.
>
> I suspect that the auth context machinery will generate the replay cache
> name for you, and again,  you don't need that API either.
> But please use GSS-API instead:-)

I need to fix Authen::Krb5 (a Perl wrapper) not rely on this krb5
internals.  Obviously, this is going to stay a krb5 wrapper, and won't
switch to GSSAPI.  So I'd really appreciate if someone would fix the
appl/simple/client/sim_client.c example not to rely on , so
that I can apply the parallel changes to the Perl port of this example
code.

The alternative would be to delete all this code from Authen::Krb5.
(The wrappers for non-public krb5 functions have to go either way.)

Thanks,
Florian


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Sam Hartman]

> "Simo" == Simo Sorce  writes:

Simo> Wherever possible you should recommend people use GSSAPI and
Simo> not krb5 APIs directly, unless they are building tools
Simo> specifically to manage aspects of krb5 (acquiring tickets,
Simo> managing ccaches, etc.)

I agree with the above.
I also think that the simple client referred to in the subject has a
bunch of anti-patterns.
As an example, I don't think it integrity protects or encrypts its
exchanges; I think it's too simple to actually be useful in today's
world.

That said,  it looks like krb5_auth_con_genaddrs is probably the API you
want to use instead of krb5_gen_portaddr.  It takes an auth context and
a socet FD and extracts addresses from the socket FD.

I suspect that the auth context machinery will generate the replay cache
name for you, and again,  you don't need that API either.
But please use GSS-API instead:-)

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: appl/simple/client/sim_client.c uses internal APIs

[Simo Sorce]

On Thu, 2023-02-23 at 10:20 +0100, Florian Weimer wrote:
> The example program uses internal APIs not present in the public header
> file (krb5_gen_portaddr, krb5_gen_replay_name; the THIS IS UGLY part).
> Are there alternatives part of the public API?
> 
> The issue here is that the example code has leaked outside of krb5 to
> other projects, and it only builds there because current compilers still
> support implicit function declarations.  I would like to give guidance
> to the external users, but unfortunately I don't know anything about
> Kerberos.

Wherever possible you should recommend people use GSSAPI and not krb5
APIs directly, unless they are building tools specifically to manage
aspects of krb5 (acquiring tickets, managing ccaches, etc.)

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc





Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos