Re: help with OTP

[Matt Zagrabelny via Kerberos]

Hi Ken!

Thanks for the reply and the comments.

On Fri, Jan 5, 2024 at 9:02 AM Ken Hornstein  wrote:

> >Krb5 devs,
>
> I'm not an official MIT krb5 developer, so I can't speak for them.  But
> in my experience things like this tend to be the most successful when they
> are submitted as pull requests.  That was my plan, eventually.
>
> >Any thoughts about extending kinit to natively perform the two step
> process
> >in the alias above? (And also have an option in /etc/krb5.conf so that it
> >is "on" by default?)
>
> I think this COULD be useful, but it would be more complicated.  Also,
> were you thinking of just changing the function of the kinit command
> or ANYTHING that does the same things as kinit?


The former. :)

No urgency from my side as the alias I use is sufficient.

Thank you (devs) for the software and support! As always, you are very
appreciated.

Cheers,

-m

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

Re: help with OTP

[Ken Hornstein via Kerberos]

>Krb5 devs,

I'm not an official MIT krb5 developer, so I can't speak for them.  But
in my experience things like this tend to be the most successful when they
are submitted as pull requests.  That was my plan, eventually.

>Any thoughts about extending kinit to natively perform the two step process
>in the alias above? (And also have an option in /etc/krb5.conf so that it
>is "on" by default?)

I think this COULD be useful, but it would be more complicated.  Also,
were you thinking of just changing the function of the kinit command
or ANYTHING that does the same things as kinit?  The latter is much
gnarlier.

--Ken

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

Re: help with OTP

[Matt Zagrabelny via Kerberos]

On Wed, Apr 26, 2023 at 11:41 AM Matt Zagrabelny  wrote:

> On Wed, Apr 26, 2023 at 11:29 AM Ken Hornstein 
> wrote:
>
>
> > It does occur to me a useful addition to kinit might be a flag that
> > means "authenticate using anonymous PKINIT and then use those
> > credentials as a FAST armour credential cache" so you wouldn't have
> > to muck around with juggling credential caches.
>
> That would be great and would eliminate an impending shell alias for me:
>
> alias kinit-otp='kinit -n -c /tmp/somecache; kinit -T /tmp/somecache'
>

Krb5 devs,

Any thoughts about extending kinit to natively perform the two step process
in the alias above? (And also have an option in /etc/krb5.conf so that it
is "on" by default?)

Maybe:

kinit --anonymous-cache-credentials

[libdefaults]
anonymous-cache-credentials = true

Thanks for the consideration!

-m

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

Re: help with OTP

[Ken Hornstein via Kerberos]

>Anonymous PKINIT works fine but requires certs to be distributed. Unless
>you're prepared to update every machine in the world every year, you
>pretty much have to use a cert that goes back to a commercial CA.

At least for us, we already did that hard work and have PKINIT already
working within the DoD PKI so anonymous PKINIT is trivial.  But even
with the kpServerAuth flag you still need an EKU that is not in "normal"
commercial certificates, at least in my limited experience.  The
frustrating thing for me is that in theory you can have the DOD PKI
issue a KDC certificate with the right extensions so you wouldn't even
need the pkinit_kdc_hostname lines but unfortunately the ASN.1 encoding
for that ends up being incorrect (I tried to get them to fix it but
sadly was unsuccessful).

>Furthermore, your applications have to be written for it. They can't use
>the normal krb5 API calls for getting a credential from a password. I
>actually wrote a LD_PRELOAD wrapper to make a normal application work.

Right, that was the OTHER piece I didn't quite understand at first
glance; it seems like the actual implementation was 70% complete in
terms of actual usability.  At least I didn't miss anything there!

--Ken

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

Re: help with OTP

[Russ Allbery]

Charles Hedrick  writes:

> Anonymous PKINIT works fine but requires certs to be distributed. Unless
> you're prepared to update every machine in the world every year, you
> pretty much have to use a cert that goes back to a commercial CA.

Because you have to distribute the certs to the client anyway, you can use
self-signed certificates and set whatever expiration you want.  There's
the standard tradeoff of long certificate lifetime, but so far as I know
there's no reason why you can't set your KDC public key certificate
lifetime to 50 years or whatever.

I agree with your other points, though.

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

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

Re: help with OTP

[Charles Hedrick via Kerberos]

Anonymous PKINIT works fine but requires certs to be distributed. Unless you're 
prepared to update every machine in the world every year, you pretty much have 
to use a cert that goes back to a commercial CA. But in that case you probably 
have to use the obscurely documented

  pkinit_eku_checking = kpServerAuth
  pkinit_kdc_hostname = kdc1.x.y
  pkinit_kdc_hostname = kdc2.x.y

I can understand that a newcomer would find OTP pretty much impossible to set 
up in practice.

Furthermore, your applications have to be written for it. They can't use the 
normal krb5 API calls for getting a credential from a password. I actually 
wrote a LD_PRELOAD wrapper to make a normal application work.


From: Kerberos  on behalf of Russ Allbery 

Sent: Wednesday, April 26, 2023 2:57 PM
To: Ken Hornstein via Kerberos 
Cc: Ken Hornstein 
Subject: Re: help with OTP

Ken Hornstein via Kerberos  writes:

> Well, dang, that's one for the toolbox!  I was able to confirm that
> works just fine (but note I already had an existing PKINIT
> infrastructure to leverage).  I will note that the existing
> documentation implies you could authenticate to WELLKNOWN/ANONYMOUS
> using your password, but maybe that isn't true?  I'm specifically
> referring to the documentation for the '-n' option for kinit, the
> "second form" of anonymous tickets.  There is a note that this isn't
> supported, but it mentions MIT Kerberos 1.8 so one could believe that
> note is out of date.

> This is kind of the giant mystery surrounding FAST.  If you're not
> familiar with the gory details of the FAST protocol you're kind of left
> stumbling around to figure out what exactly you need to do.  I realize
> this is probably because it's hard to write documentation for beginners
> (certainly I am guilty of this also); I'm only making this as a general
> observation.

I worked through a bunch of this for pam-krb5 back in the day and made it
support a set of reasonable things, including anonymous PKINIT to
establish the FAST armor.  People who are working in this area may find
its source code useful to look at, although I think there have been
improvements since then and what it does may no longer be best practice.

https://github.com/rra/pam-krb5/blob/main/module/fast.c

--
Russ Allbery (ea...@eyrie.org) <https://www.eyrie.org/~eagle/>

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: help with OTP

[Ken Hornstein via Kerberos]

>I worked through a bunch of this for pam-krb5 back in the day and made it
>support a set of reasonable things, including anonymous PKINIT to
>establish the FAST armor.  People who are working in this area may find
>its source code useful to look at, although I think there have been
>improvements since then and what it does may no longer be best practice.
>
>https://github.com/rra/pam-krb5/blob/main/module/fast.c

Thanks, Russ!  I will definitely use this as a starting point sometime
in the future.

--Ken

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

Re: help with OTP

[Russ Allbery]

Ken Hornstein via Kerberos  writes:

> Well, dang, that's one for the toolbox!  I was able to confirm that
> works just fine (but note I already had an existing PKINIT
> infrastructure to leverage).  I will note that the existing
> documentation implies you could authenticate to WELLKNOWN/ANONYMOUS
> using your password, but maybe that isn't true?  I'm specifically
> referring to the documentation for the '-n' option for kinit, the
> "second form" of anonymous tickets.  There is a note that this isn't
> supported, but it mentions MIT Kerberos 1.8 so one could believe that
> note is out of date.

> This is kind of the giant mystery surrounding FAST.  If you're not
> familiar with the gory details of the FAST protocol you're kind of left
> stumbling around to figure out what exactly you need to do.  I realize
> this is probably because it's hard to write documentation for beginners
> (certainly I am guilty of this also); I'm only making this as a general
> observation.

I worked through a bunch of this for pam-krb5 back in the day and made it
support a set of reasonable things, including anonymous PKINIT to
establish the FAST armor.  People who are working in this area may find
its source code useful to look at, although I think there have been
improvements since then and what it does may no longer be best practice.

https://github.com/rra/pam-krb5/blob/main/module/fast.c

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

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

Re: help with OTP

[Ken Hornstein via Kerberos]

>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

Re: help with OTP

[Matt Zagrabelny via Kerberos]

On Wed, Apr 26, 2023 at 11:29 AM Ken Hornstein  wrote:
>
> >Since I am currently only interested in anonymous auth, I thought I
> >could skip that directive. But alas:
>
> Right, so, here's where my limited knowledge of FAST comes into play.
>
> As I understand it, you need to be able to use a trusted key to
> authenticate with the KDC to to create the FAST channel.  Your options
> are using an already-existing key (such as a host key) or anonymous
> PKINIT.  But the "anonymous" part of anonymous PKINIT only refers to the
> CLIENT being anonymous; you still need the client to be able to verify
> the KDC's certificate (otherwise anyone could pretend to be your KDC and
> you could end up sending your OTP output to them, which would be bad).

Agreed.

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.

> That's the piece you were missing.  Once you have the FAST channel set
> up then you can use that to securely send the OTP response.
>
> I see in a later message you got it working; great!  Just FYI in case
> anyone else asks, the key line in that trace output was this:
>
> [1185088] 1682519355.427424: Processing preauth types: PA-PK-AS-REQ
> (16), PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147),
> PA-ENCRYPTED-CHALLENGE (138), PA_AS_FRESHNESS (150), PA-FX-COOKIE
> (133), PA-FX-ERROR (137)
>
> You're missing PA-OTP-REQUEST, which was because (as you discovered)
> that plugin wasn't installed.  But that requires a lot of Kerberos
> knowledge to get to that point :-/

Yup!

> It does occur to me a useful addition to kinit might be a flag that
> means "authenticate using anonymous PKINIT and then use those
> credentials as a FAST armour credential cache" so you wouldn't have
> to muck around with juggling credential caches.

That would be great and would eliminate an impending shell alias for me:

alias kinit-otp='kinit -n -c /tmp/somecache; kinit -T /tmp/somecache'

Thanks for all the help, Ken (and BuzzSaw and Greg). It is very appreciated!

-m


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

Re: help with OTP

[Ken Hornstein via Kerberos]

>Since I am currently only interested in anonymous auth, I thought I
>could skip that directive. But alas:

Right, so, here's where my limited knowledge of FAST comes into play.

As I understand it, you need to be able to use a trusted key to
authenticate with the KDC to to create the FAST channel.  Your options
are using an already-existing key (such as a host key) or anonymous
PKINIT.  But the "anonymous" part of anonymous PKINIT only refers to the
CLIENT being anonymous; you still need the client to be able to verify
the KDC's certificate (otherwise anyone could pretend to be your KDC and
you could end up sending your OTP output to them, which would be bad).
That's the piece you were missing.  Once you have the FAST channel set
up then you can use that to securely send the OTP response.

I see in a later message you got it working; great!  Just FYI in case
anyone else asks, the key line in that trace output was this:

[1185088] 1682519355.427424: Processing preauth types: PA-PK-AS-REQ
(16), PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147),
PA-ENCRYPTED-CHALLENGE (138), PA_AS_FRESHNESS (150), PA-FX-COOKIE
(133), PA-FX-ERROR (137)

You're missing PA-OTP-REQUEST, which was because (as you discovered)
that plugin wasn't installed.  But that requires a lot of Kerberos
knowledge to get to that point :-/

It does occur to me a useful addition to kinit might be a flag that
means "authenticate using anonymous PKINIT and then use those
credentials as a FAST armour credential cache" so you wouldn't have
to muck around with juggling credential caches.

--Ken

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

Re: help with OTP

[Matt Zagrabelny via Kerberos]

[Probably solved!]

On Wed, Apr 26, 2023 at 10:12 AM Matt Zagrabelny  wrote:
>
> Whoops. Looks like I need:
>
> sudo apt install krb5-pkinit

Fool me once shame on me, fool me twice shame on me!

I also neglected to add the krb5-otp package to the KDC server.

Now I get:

$ kdestroy
$ kinit -n -c /tmp/somecache
$ kinit -T /tmp/somecache
Enter OTP Token Value:
$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: b...@mydomain.com

Valid starting   Expires  Service principal
04/26/2023 10:26:41  04/26/2023 20:26:41  krbtgt/mydomain@mydomain.com
renew until 04/27/2023 10:26:29

This is all on my test system. Still need to try in production, but it
looks, and feels!, pretty good.

Thanks for all the help!

-m


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

Re: help with OTP

[Ken Hornstein via Kerberos]

>On 4/25/23 20:01, Ken Hornstein via Kerberos wrote:
>> First, there's about 500x ways for PKINIT to go wrong, and when it does
>> go wrong 99% of the time you fall back to a password so it's hard to
>> figure out exactly what failed.
>
>Assuming the kadmin client and KDC are running 1.12 or later, you can 
>create WELLKNOWN/ANONYMOUS with the -nokey option (instead of -randkey) 
>to disable the password fallback.  Or you can "kadmin.local purgekeys 
>-all WELLKNOWN/ANONYMOUS" to remove the principal's long-term keys once 
>it already exists.  If this is done you should get PKINIT error messages 
>from kinit -n if the KDC offered PKINIT and the client couldn't make it 
>work, like this:
>[...]

Well, dang, that's one for the toolbox!  I was able to confirm that
works just fine (but note I already had an existing PKINIT infrastructure
to leverage).  I will note that the existing documentation implies you
could authenticate to WELLKNOWN/ANONYMOUS using your password, but
maybe that isn't true?  I'm specifically referring to the documentation
for the '-n' option for kinit, the "second form" of anonymous tickets.
There is a note that this isn't supported, but it mentions MIT Kerberos
1.8 so one could believe that note is out of date.

This is kind of the giant mystery surrounding FAST.  If you're not
familiar with the gory details of the FAST protocol you're kind of left
stumbling around to figure out what exactly you need to do.  I realize
this is probably because it's hard to write documentation for beginners
(certainly I am guilty of this also); I'm only making this as a general
observation.

As a side note, it does occur to me that perhaps the simplest way to
integrate third-party OTP solutions into MIT Kerberos is to simply write
a bare-bones RADIUS server that does all of the magic you need to do
and point the existing OTP implementation at it; the RADIUS protocol is
relatively straightforward.  It looks like writing your own OTP plugin
is in practice very difficult due to the dependency on calling the ASN.1
routines to encode and decode the OTP preauth data.

--Ken

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

Re: help with OTP

[Matt Zagrabelny via Kerberos]

Hi Ken, Greg, and BuzzSaw,

On Tue, Apr 25, 2023 at 7:02 PM Ken Hornstein  wrote:
>
> >Making progress... but still need some pointers.
> >[...]
>
> Remember when I said setting up PKINIT is about as much fun as getting a
> punch in the face from John Cena?  Well, you're about to discover what
> I mean by that.

Ha. Yup. Isn't that all IT though?


> First, there's about 500x ways for PKINIT to go wrong, and when it does
> go wrong 99% of the time you fall back to a password so it's hard to
> figure out exactly what failed.  I work with a large PKINIT deployment
> that uses smartcards on the client side, so I feel I can speak with
> some authority here.  But, some pointers to get you going.
>
> - You can use the KRB5_TRACE environment variable (on both the client
>   and server) to figure out if PKINIT was even attempted.  Do something
>   like:
>
>   env KRB5_TRACE=/dev/stdout kinit [... kinit arguments ...]

Great hint. Thank you!

KRB5_TRACE=/dev/stdout kinit -n -c /tmp/somecache
[1180611] 1682514855.418738: Getting initial credentials for
WELLKNOWN/anonym...@mydomain.com
[1180611] 1682514855.418739: Error loading plugin module pkinit:
2/unable to load plugin
[/usr/lib/x86_64-linux-gnu/krb5/plugins/preauth/pkinit.so]:
/usr/lib/x86_64-linux-gnu/krb5/plugins/preauth/pkinit.so: cannot open
shared object file: No such file or directory

Whoops. Looks like I need:

sudo apt install krb5-pkinit

I installed that on both the client and KDC system.


>   That should at least tell you if PKINIT is attempted and if it is
>   being attempted why it failed (but it will produce a lot so it requires
>   some experience to determine the useful bit you need).
>
> - If you are generating the KDC certificate yourself and you do all of
>   the right magic (as specified in the MIT documentation) to put the
>   realm in the certificate you should not need this:
>
> >> YOURREALM = {
> >>   pkinit_kdc_hostname = yourkdc.fqdn
> >> }
>
> - Did you put the right stuff to trust the KDC certificate on the client?
>   I did not see that.  The PKINIT documentation does mention that you
>   need a pkinit_anchors entry on the client (at a minimum, you may need
>   others).

Again, great hint.

I read the docs from:

https://web.mit.edu/kerberos/www/krb5-latest/doc/admin/pkinit.html

It says:

--
If any clients will authenticate using regular (as opposed to
anonymous) PKINIT, the KDC must also have filesystem access to the CA
certificate (cacert.pem), and the following configuration (with the
appropriate pathname):

pkinit_anchors = FILE:/var/lib/krb5kdc/cacert.pem
--

Since I am currently only interested in anonymous auth, I thought I
could skip that directive. But alas:

KRB5_TRACE=/dev/stdout /usr/sbin/krb5kdc -n -P /var/run/krb5-kdc.pid
[362890] 1682516397.385786: Retrieving K/m...@mydomain.com from
FILE:/etc/krb5kdc/stash (vno 0, enctype 0) with result: 0/Success
[362890] 1682516397.385787: PKINIT server initializing realm MYDOMAIN.COM
[362890] 1682516397.385788: PKINIT server initialization failed for
realm MYDOMAIN.COM: 22/No pkinit_anchors supplied for realm
MYDOMAIN.COM
[362890] 1682516397.385791: Retrieving K/m...@mydomain.com from
FILE:/etc/krb5kdc/stash (vno 0, enctype 0) with result: 0/Success
krb5kdc: starting...

I added:

pkinit_anchors  = FILE:/etc/krb5kdc/cacert.pem

KRB5_TRACE=/dev/stdout /usr/sbin/krb5kdc -n -P /var/run/krb5-kdc.pid
[363318] 1682516577.731993: Retrieving K/m...@mydomain.com from
FILE:/etc/krb5kdc/stash (vno 0, enctype 0) with result: 0/Success
[363318] 1682516577.731994: PKINIT server initializing realm MYDOMAIN.COM
[363318] 1682516577.731995: PKINIT loading CA certs and CRLs from FILE
[363318] 1682516577.731998: Retrieving K/m...@mydomain.com from
FILE:/etc/krb5kdc/stash (vno 0, enctype 0) with result: 0/Success
krb5kdc: starting...

So, that looks good.

I'm able to anonymous auth:

$ kinit -n -c /tmp/somecache

but I still get a kerberos principal password as opposed to a RADIUS one...

$ kinit -T /tmp/somecache
Password for b...@mydomain.com:
[type in kerberos password]
$

Lots of debug stuff follows. I've read through it, but don't see
anything that jumps out as to why I'm not getting the OTP prompt:

kadmin.local:  get_principal bob
Principal: b...@mydomain.com
Expiration date: [never]
Last password change: Mon Dec 10 14:18:53 CST 2018
Password expiration date: [never]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Tue Apr 25 10:13:24 CDT 2023 (root/ad...@mydomain.com)
Last successful authentication: Wed Apr 26 08:55:41 CDT 2023
Last failed authentication: Wed Apr 26 08:55:16 CDT 2023
Failed password attempts: 0
Number of keys: 2
Key: vno 1, aes256-cts-hmac-sha1-96
Key: vno 1, aes128-cts-hmac-sha1-96
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH
Policy: [none]

kadmin.local:  get_strings bob
otp: [{type:MyRemoteTokenType ,username:bob}]

anonymous auth:

$ KRB5_TRACE=/dev/stdout kinit -n -c /tmp/somecache
[1185075] 1682519339.169989: Getting ini

Re: help with OTP

[Greg Hudson]

On 4/25/23 20:01, Ken Hornstein via Kerberos wrote:

First, there's about 500x ways for PKINIT to go wrong, and when it does
go wrong 99% of the time you fall back to a password so it's hard to
figure out exactly what failed.


Assuming the kadmin client and KDC are running 1.12 or later, you can 
create WELLKNOWN/ANONYMOUS with the -nokey option (instead of -randkey) 
to disable the password fallback.  Or you can "kadmin.local purgekeys 
-all WELLKNOWN/ANONYMOUS" to remove the principal's long-term keys once 
it already exists.  If this is done you should get PKINIT error messages 
from kinit -n if the KDC offered PKINIT and the client couldn't make it 
work, like this:


$ kinit -n
kinit: Pre-authentication failed: No pkinit_anchors supplied while 
getting initial credentials


(The PKINIT doc page still says to create WELLKNOWN/ANONYMOUS with 
-randkey, even though it talks about the -nokey option for client 
principals.  I will work on documentation updates based on this thread.)


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

Re: help with OTP

[Ken Hornstein via Kerberos]

>Making progress... but still need some pointers.
>[...]

Remember when I said setting up PKINIT is about as much fun as getting a
punch in the face from John Cena?  Well, you're about to discover what
I mean by that.

First, there's about 500x ways for PKINIT to go wrong, and when it does
go wrong 99% of the time you fall back to a password so it's hard to
figure out exactly what failed.  I work with a large PKINIT deployment
that uses smartcards on the client side, so I feel I can speak with
some authority here.  But, some pointers to get you going.

- You can use the KRB5_TRACE environment variable (on both the client
  and server) to figure out if PKINIT was even attempted.  Do something
  like:

  env KRB5_TRACE=/dev/stdout kinit [... kinit arguments ...]

  That should at least tell you if PKINIT is attempted and if it is
  being attempted why it failed (but it will produce a lot so it requires
  some experience to determine the useful bit you need).

- If you are generating the KDC certificate yourself and you do all of
  the right magic (as specified in the MIT documentation) to put the
  realm in the certificate you should not need this:

>> YOURREALM = {
>>   pkinit_kdc_hostname = yourkdc.fqdn
>> }

- Did you put the right stuff to trust the KDC certificate on the client?
  I did not see that.  The PKINIT documentation does mention that you
  need a pkinit_anchors entry on the client (at a minimum, you may need
  others).

--Ken

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

Re: help with OTP

[Matt Zagrabelny via Kerberos]

Making progress... but still need some pointers.

On Tue, Apr 25, 2023 at 4:01 PM BuzzSaw Code  wrote:
>
> You don't need or want to know the anonymous principal's password -
> you should use randkey.  Getting a password prompt for those creds
> means something is missing in the config.

OK. Agreed.

>
> You probably need to set some of the PKINIT parameters since they seem

This seems to be a missing point in my configuration. I just followed:

https://web.mit.edu/kerberos/www/krb5-latest/doc/admin/pkinit.html

to attempt to get pkinit working for anonymous credentials.

I generated the CA and the KDC cert/key and updated the config file
(/etc/krb5kdc/kdc.conf):

--
[kdcdefaults]
kdc_ports = 750,88
kdc_tcp_listen = 88

[realms]
MYDOMAIN.COM = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
default_principal_flags = +preauth
pkinit_identity = FILE:/etc/krb5kdc/kdc.pem,/etc/krb5kdc/kdckey.pem
}
--


> to be tied to FAST as well in your krb5.conf on your client:
>
> YOURREALM = {
>   pkinit_kdc_hostname = yourkdc.fqdn
> }
>

OK. Thanks! I added that to my /etc/krb5.conf.

$ kinit -n -c /tmp/somecache
Password for WELLKNOWN/anonym...@mydomain.com:

In the KDC logs I see:

Apr 25 16:56:05 auth-test krb5kdc[226122]: AS_REQ (8 etypes
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19),
DEPRECATED:des3-cbc-sha1(16), DEPRECATED:arcfour-hmac(23),
camellia128-cts-cmac(25), camellia256-cts-cmac(26)})
2607:ea00:200:60::13: NEEDED_PREAUTH: WELLKNOWN/anonym...@mydomain.com
for krbtgt/mydomain@mydomain.com, Additional pre-authentication
required
Apr 25 16:56:05 auth-test krb5kdc[226122]: closing down fd 14

I see the "additional pre-authentication required". I check the
anonymous principal:

kadmin.local:  get_principal WELLKNOWN/anonym...@mydomain.com
Principal: WELLKNOWN/anonym...@mydomain.com
Expiration date: [never]
Last password change: Tue Apr 25 16:04:45 CDT 2023
Password expiration date: [never]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Tue Apr 25 16:04:45 CDT 2023 (root/ad...@mydomain.com)
Last successful authentication: Tue Apr 25 15:06:53 CDT 2023
Last failed authentication: Tue Apr 25 15:04:26 CDT 2023
Failed password attempts: 0
Number of keys: 2
Key: vno 3, aes256-cts-hmac-sha1-96
Key: vno 3, aes128-cts-hmac-sha1-96
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH

So I remove the preauth requirement:

kadmin.local:  modprinc -requires_preauth WELLKNOWN/anonym...@mydomain.com
Principal "WELLKNOWN/anonym...@mydomain.com" modified.

However, when I try:

$ kinit -n -c /tmp/somecache
Password for WELLKNOWN/anonym...@mydomain.com:

I still get a password prompt and the KDC logs still say:

NEEDED_PREAUTH for the WELLKNOWN/anonym...@mydomain.com principal.

Any ideas what I am missing to get pkinit working with anonymous credentials?

Thanks for the help!

-m


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

Re: help with OTP

[Matt Zagrabelny via Kerberos]

Hi BuzzSaw,

Thanks for the reply!

On Tue, Apr 25, 2023 at 1:33 PM BuzzSaw Code  wrote:
>
> What we did:
> - in your kdc.conf:
>
> [otp]
>DEFAULT = {
> server = localhost6:1812
> secret = secrettfile
> strip_realm = true
>}
>
> This assumes your kdc runs a local RADIUS server that will answer up
> OTP requests.  Change as needed.


Got it.

>
>
> - create the file 'secretfile' with your shared RADIUS secret in the
> same directory as kdc.conf
>
> - kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS'


-randkey. Do I need to know what the passphrase is?

>
> - kadmin -q 'modprinc +requires_preauth user
> - kadmin -q 'setstr user otp []'
>
> Testing:
>
> Get an initial TGT with anonymous auth
> - kinit -n -c /tmp/somecache


I tried this, but it prompted me:

$ kinit -n -c /tmp/somecache
Password for WELLKNOWN/anonym...@mydomain.com:
kinit: Password incorrect while getting initial credentials

...so I went and changed the password for the WELLKNOWN/ANONYMOUS
principal. Then...

$ kinit -n -c /tmp/somecache
Password for WELLKNOWN/anonym...@mydomain.com:
kinit: Reply has wrong form of session key for anonymous request while
getting initial credentials

I've never requested anonymous credentials before.

Does anyone know how to correctly request them?

Thanks,

-m


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

Re: help with OTP

[BuzzSaw Code]

What we did:
- in your kdc.conf:

[otp]
   DEFAULT = {
server = localhost6:1812
secret = secrettfile
strip_realm = true
   }

This assumes your kdc runs a local RADIUS server that will answer up
OTP requests.  Change as needed.

- create the file 'secretfile' with your shared RADIUS secret in the
same directory as kdc.conf

- kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS'
- kadmin -q 'modprinc +requires_preauth user
- kadmin -q 'setstr user otp []'

Testing:

Get an initial TGT with anonymous auth
- kinit -n -c /tmp/somecache

Use that anonymous auth
- kinit -T /tmp/somecache  user

Should get prompted for OTP there if that is right.

For Linux things that support 'sssd' - look a the krb5_use_fast
setting - we set our to demand.

For macOS and other things we build Russ Allbery's pam_krb5 -
https://www.eyrie.org/~eagle/software/pam-krb5/pam-krb5.html
that supports FAST.  The Kerberos supplied with macOS sorta works but
is missing so much it has been easier just to push a build of MIT
Kerberos to it.

That's the off the top of my head notes for OTP.

HTH.


On Tue, Apr 25, 2023 at 12:44 PM Matt Zagrabelny via Kerberos
 wrote:
>
> Hi Ken!
>
> On Mon, Apr 24, 2023 at 5:25 PM Ken Hornstein  wrote:
> >
> > >make it look like you can put the secret directly into the
> > >configuration file. There seems to be a little bit of disconnect
> > >between those two parts of the docs. I just wanted to point it out if
> > >it is helpful.
> >
> > It looks like (according to the source code) it has to have that as
> > a filename.
>
> Thanks for source diving and confirming how to use that config directive.
>
> > >I've tried to configure my kdc.conf with the required otp stanzas:
> >
> > Well, it's a preauthentication mechanism, so FIRST you have to make sure
> > your principal is configured to require preauthentication.
>
> Sure. I just did that:
>
> kadmin.local:  modify_principal +requires_preauth b...@mydomain.com
> Principal "b...@mydomain.com" modified.
>
> I've searched the docs and didn't find anything, but... I don't
> suppose there is a config item for the KDC to require preauth for
> "user" principals?
>
>   And there
> > is a note at the bottom of that page that suggests you need to be using
> > FAST which implies you need to set up a FAST credential cache.
>
> I've done some searching and found:
>
> https://web.mit.edu/kerberos/krb5-1.12/doc/basic/ccache_def.html
>
> ...but no mention of FAST.
>
>
>   And
> > I will be the first person to confess that I've always been a little
> > hazy on how exactly that works!  (We do use an OTP preauthentication
> > mechanism but it predates the newer OTP mechanism you're using).  I am
> > not aware of any extant documentation that explains how you're supposed
> > to use FAST in practice, which I always found a bit odd.
>
> I haven't found any documentation about configuring the KDC to use FAST.
>
>   I wasn't
> > involved with Kerberos protocol development when FAST was designed but I
> > remember a lot of messages about it, but it seems like there's a giant
> > hole on how exactly you're supposed to use it when it comes down to the
> > nuts and bolts.  If there is some documentation about it, hey, I'd love
> > to read it!
>
> Ditto.
>
>   One of my long-term plans is to migrate our weird stuff to
> > something based on OTP which would involve FAST and I sure hope that's
> > actually possible in practice (I am aware that without an available
> > local keytab you'd have to do anonymous PKINIT and that wouldn't be too
> > bad for us since we already have all of the certificate stuff deployed
> > for PKINIT with Kerberos, but if you DIDN'T already have everything set
> > up for PKINIT it would be about as much fun as a punch in the face from
> > John Cena).
> >
> > My guess is you could use kinit -k to get a TGT based on a keytab on the
> > host and then give THAT credential cache you create to the kinit command
> > using the -T option.  Again, that's just a guess.
>
> Yeah... I'm unsure how this all plumbs together.
>
> Thanks for the reply. Maybe someone else, with FAST experience (?),
> will chime in.
>
> Cheers,
>
> -m
>
> 
> 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: help with OTP

[Matt Zagrabelny via Kerberos]

Hi Ken!

On Mon, Apr 24, 2023 at 5:25 PM Ken Hornstein  wrote:
>
> >make it look like you can put the secret directly into the
> >configuration file. There seems to be a little bit of disconnect
> >between those two parts of the docs. I just wanted to point it out if
> >it is helpful.
>
> It looks like (according to the source code) it has to have that as
> a filename.

Thanks for source diving and confirming how to use that config directive.

> >I've tried to configure my kdc.conf with the required otp stanzas:
>
> Well, it's a preauthentication mechanism, so FIRST you have to make sure
> your principal is configured to require preauthentication.

Sure. I just did that:

kadmin.local:  modify_principal +requires_preauth b...@mydomain.com
Principal "b...@mydomain.com" modified.

I've searched the docs and didn't find anything, but... I don't
suppose there is a config item for the KDC to require preauth for
"user" principals?

  And there
> is a note at the bottom of that page that suggests you need to be using
> FAST which implies you need to set up a FAST credential cache.

I've done some searching and found:

https://web.mit.edu/kerberos/krb5-1.12/doc/basic/ccache_def.html

...but no mention of FAST.


  And
> I will be the first person to confess that I've always been a little
> hazy on how exactly that works!  (We do use an OTP preauthentication
> mechanism but it predates the newer OTP mechanism you're using).  I am
> not aware of any extant documentation that explains how you're supposed
> to use FAST in practice, which I always found a bit odd.

I haven't found any documentation about configuring the KDC to use FAST.

  I wasn't
> involved with Kerberos protocol development when FAST was designed but I
> remember a lot of messages about it, but it seems like there's a giant
> hole on how exactly you're supposed to use it when it comes down to the
> nuts and bolts.  If there is some documentation about it, hey, I'd love
> to read it!

Ditto.

  One of my long-term plans is to migrate our weird stuff to
> something based on OTP which would involve FAST and I sure hope that's
> actually possible in practice (I am aware that without an available
> local keytab you'd have to do anonymous PKINIT and that wouldn't be too
> bad for us since we already have all of the certificate stuff deployed
> for PKINIT with Kerberos, but if you DIDN'T already have everything set
> up for PKINIT it would be about as much fun as a punch in the face from
> John Cena).
>
> My guess is you could use kinit -k to get a TGT based on a keytab on the
> host and then give THAT credential cache you create to the kinit command
> using the -T option.  Again, that's just a guess.

Yeah... I'm unsure how this all plumbs together.

Thanks for the reply. Maybe someone else, with FAST experience (?),
will chime in.

Cheers,

-m


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

Re: help with OTP

[Ken Hornstein via Kerberos]

>make it look like you can put the secret directly into the
>configuration file. There seems to be a little bit of disconnect
>between those two parts of the docs. I just wanted to point it out if
>it is helpful.

It looks like (according to the source code) it has to have that as
a filename.

>I've tried to configure my kdc.conf with the required otp stanzas:

Well, it's a preauthentication mechanism, so FIRST you have to make sure
your principal is configured to require preauthentication.  And there
is a note at the bottom of that page that suggests you need to be using
FAST which implies you need to set up a FAST credential cache.  And
I will be the first person to confess that I've always been a little
hazy on how exactly that works!  (We do use an OTP preauthentication
mechanism but it predates the newer OTP mechanism you're using).  I am
not aware of any extant documentation that explains how you're supposed
to use FAST in practice, which I always found a bit odd.  I wasn't
involved with Kerberos protocol development when FAST was designed but I
remember a lot of messages about it, but it seems like there's a giant
hole on how exactly you're supposed to use it when it comes down to the
nuts and bolts.  If there is some documentation about it, hey, I'd love
to read it!  One of my long-term plans is to migrate our weird stuff to
something based on OTP which would involve FAST and I sure hope that's
actually possible in practice (I am aware that without an available
local keytab you'd have to do anonymous PKINIT and that wouldn't be too
bad for us since we already have all of the certificate stuff deployed
for PKINIT with Kerberos, but if you DIDN'T already have everything set
up for PKINIT it would be about as much fun as a punch in the face from
John Cena).

My guess is you could use kinit -k to get a TGT based on a keytab on the
host and then give THAT credential cache you create to the kinit command
using the -T option.  Again, that's just a guess.

--Ken

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