[39238] in Kerberos
Re: help with OTP
daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Wed Apr 26 13:13:03 2023
Message-ID: <202304261708.33QH8fKK018047@hedwig.cmf.nrl.navy.mil>
To: Matt Zagrabelny <mzagrabe@d.umn.edu>
cc: kerberos <kerberos@mit.edu>
In-Reply-To: <CAOLfK3XRaYoT+NgbjDCbEaKow36QpTjrFrjGO-jGW96=7z9u_A@mail.gmail.com>
MIME-Version: 1.0
Date: Wed, 26 Apr 2023 13:08:41 -0400
From: Ken Hornstein via Kerberos <kerberos@mit.edu>
Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>The docs that I referenced still made it seem that the anchor config
>was somewhat optional for anonymous auth.
>
>..but maybe I wasn't reading those lines with the proper mindset or context.
Looking at that, I can see why you would come to that conclusion. It
was obvious to ME that you needed to configure the client to trust the
KDC's certificate but I had the benefit of literal years of experience
with PKINIT. Unfortunately, there's kind of a "missing middle" in terms
of Kerberos documentation; there are some good high level overviews,
a LOT of stuff that is documented down the wire protocol and API level,
but in terms of practical integration it's kind of harsh to a newcomer
because it is written by people who already know all of this. I am not
faulting MIT for this, as this is true with the documentation for
a LOT of very technical things. It's a lot of effort to write the
sort of thing that would be useful for this kind of situation. The
information is all out there but it's kind of scattered in a bunch
of different places and it takes a lot of effort to put it all together.
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
