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: Using a stub krb5.conf with "include"

[Nico Williams]

On Mon, Dec 12, 2022 at 06:47:50PM -0500, Ken Hornstein via Kerberos wrote:
> >The profile library has the concept of marking a section or subsection
> >as "final", preventing further amendments to that section.  But that
> >concept does not apply to individual relations (although it was
> >erroneously documented as applying to them prior to 1.17.1).
> 
> When I looked at the finalization support, I found that it had two
> unexpected features:
> 
> 1) The finalization support only works across files; in other words, if
>you have KRB5_CONFIG=/etc/file1:/etc/file2, a finalized section in file1
>suppresses the same section in file2.  But it doesn't work if it's all
>within file1.
> 
> 2) An include statement in a krb5.conf file does NOT count as a new file for
>the purposes of finalization.
> 
> If I am wrong about these things, I'd sure love a correction.  Honestly,
> I can't see a reason why a finalized section in a file just doesn't
> suppress further sections, even within the same file.

Hmmm, this could be useful in Heimdal as well.  We should at the very
least not trip up over the finalizer token.

Can we get the semantics nailed down?

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