help with OTP

[Matt Zagrabelny]

Greetings Kerberos folks,

I am attempting to understand a bit more of the OTP support in MIT's
Kerberos implementation.

I'm running Debian stable:

ii krb5-kdc 1.18.3-6+deb11u3

I'm looking at the docs at:

https://web.mit.edu/kerberos/krb5-1.13/doc/admin/conf_files/kdc_conf.html#otp

The docs say about the "secret":

---<cut>---
This tag indicates a filename (which may be relative to
LOCALSTATEDIR/krb5kdc) containing the secret used to encrypt the
RADIUS packets. The secret should appear in the first line of the file
by itself; leading and trailing whitespace on the line will be
removed. If the value of server is a Unix domain socket address, this
tag is optional, and an empty secret will be used if it is not
specified. Otherwise, this tag is required.
---<cut>---

which seems to indicate that the secret should be a path to a file.

The example:

---<cut>---
[otp]
MyRemoteTokenType = {
server = radius.mydomain.com:1812
secret = SEmfiajf42$
timeout = 15
retries = 5
strip_realm = true
}
---<cut>---

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.

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

[otp]
MyRemoteTokenType = {
server = radius.mydomain.com
secret = super_secret_with_radiusd
timeout = 15
retries = 5
strip_realm = true
}

and I've set the otp string for my principal:

kadmin.local: set_string b...@MYDOMAIN.COM otp
[{"type":"MyRemoteTokenType ","username":"bob"}]
Attribute set for principal "b...@MYDOMAIN.COM".

When I kinit, I don't see any traffic go to the radius server (neither
in the kdc logs, nor in the radiusd logs) and type my password for
kerberos, which is different than my radius password, and I get the
TGT:

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: b...@MYDOMAIN.COM

Valid starting Expires Service principal
04/24/2023 16:17:02 04/25/2023 02:17:02 krbtgt/MYDOMA...@MYDOMAIN.COM
renew until 04/25/2023 16:16:50

Any ideas what I am missing, or what steps I could take to debug this further?

Thanks for the help!

-m

[Ken Hornstein]

>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

[Matt Zagrabelny]

Hi Ken!

On Mon, Apr 24, 2023 at 5:25 PM Ken Hornstein <ke...@cmf.nrl.navy.mil> 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

[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.

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

[Matt Zagrabelny]

Hi BuzzSaw,

Thanks for the reply!

On Tue, Apr 25, 2023 at 1:33 PM BuzzSaw Code <buzzsa...@gmail.com> 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/ANON...@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/ANON...@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

[Matt Zagrabelny]

Making progress... but still need some pointers.

On Tue, Apr 25, 2023 at 4:01 PM BuzzSaw Code <buzzsa...@gmail.com> 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):

---<cut>---
[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
}
---<cut>---


> 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/ANON...@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/ANON...@MYDOMAIN.COM
for krbtgt/MYDOMA...@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/ANON...@MYDOMAIN.COM
Principal: WELLKNOWN/ANON...@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/ANON...@MYDOMAIN.COM
Principal "WELLKNOWN/ANON...@MYDOMAIN.COM" modified.

However, when I try:

$ kinit -n -c /tmp/somecache
Password for WELLKNOWN/ANON...@MYDOMAIN.COM:

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

NEEDED_PREAUTH for the WELLKNOWN/ANON...@MYDOMAIN.COM principal.

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

[Ken Hornstein]

>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

[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.)

[Matt Zagrabelny]

Hi Ken, Greg, and BuzzSaw,

On Tue, Apr 25, 2023 at 7:02 PM Ken Hornstein <ke...@cmf.nrl.navy.mil> 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/ANON...@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:

---<cut>---
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
---<cut>---

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 initial credentials for
WELLKNOWN/ANON...@MYDOMAIN.COM
[1185075] 1682519339.169991: Sending unauthenticated request
[1185075] 1682519339.169992: Sending request (194 bytes) to MYDOMAIN.COM
[1185075] 1682519339.169993: Resolving hostname auth-test.mydomain.com
[1185075] 1682519339.169994: Sending initial UDP request to dgram fc00::1:88
[1185075] 1682519339.169995: Received answer (323 bytes) from dgram fc00::1:88
[1185075] 1682519339.169996: Sending DNS URI query for _kerberos.MYDOMAIN.COM.
[1185075] 1682519339.169997: No URI records found
[1185075] 1682519339.169998: Sending DNS SRV query for
_kerberos-master._udp.MYDOMAIN.COM.
[1185075] 1682519339.169999: Sending DNS SRV query for
_kerberos-master._tcp.MYDOMAIN.COM.
[1185075] 1682519339.170000: No SRV records found
[1185075] 1682519339.170001: Response was not from primary KDC
[1185075] 1682519339.170002: Received error from KDC:
-1765328359/Additional pre-authentication required
[1185075] 1682519339.170005: Preauthenticating using KDC method data
[1185075] 1682519339.170006: Processing preauth types: PA-PK-AS-REQ
(16), PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147),
PA-ENC-TIMESTAMP (2), PA_AS_FRESHNESS (150), PA-FX-COOKIE (133)
[1185075] 1682519339.170007: Selected etype info: etype aes256-cts,
salt "MYDOMAIN.COMWELLKNOWNANONYMOUS", params ""
[1185075] 1682519339.170008: Received cookie: MIT
[1185075] 1682519339.170009: Preauth module pkinit (147) (info)
returned: 0/Success
[1185075] 1682519339.170010: PKINIT client received freshness token from KDC
[1185075] 1682519339.170011: Preauth module pkinit (150) (info)
returned: 0/Success
[1185075] 1682519339.170012: PKINIT loading CA certs and CRLs from
FILE /etc/krb5/cacert.pem
[1185075] 1682519339.170013: PKINIT client computed kdc-req-body
checksum 14/0CF6EE90E51246F7626115CA71D38D89C16D42AB
[1185075] 1682519339.170015: PKINIT client making DH request
[1185075] 1682519339.170016: Preauth module pkinit (16) (real)
returned: 0/Success
[1185075] 1682519339.170017: Produced preauth for next request:
PA-FX-COOKIE (133), PA-PK-AS-REQ (16)
[1185075] 1682519339.170018: Sending request (1680 bytes) to MYDOMAIN.COM
[1185075] 1682519339.170019: Resolving hostname auth-test.mydomain.com
[1185075] 1682519339.170020: Initiating TCP connection to stream fc00::1:88
[1185075] 1682519339.170021: Sending TCP request to stream fc00::1:88
[1185075] 1682519339.170022: Received answer (2955 bytes) from stream fc00::1:88
[1185075] 1682519339.170023: Terminating TCP connection to stream fc00::1:88
[1185075] 1682519339.170024: Sending DNS URI query for _kerberos.MYDOMAIN.COM.
[1185075] 1682519339.170025: No URI records found
[1185075] 1682519339.170026: Sending DNS SRV query for
_kerberos-master._udp.MYDOMAIN.COM.
[1185075] 1682519339.170027: Sending DNS SRV query for
_kerberos-master._tcp.MYDOMAIN.COM.
[1185075] 1682519339.170028: No SRV records found
[1185075] 1682519339.170029: Response was not from primary KDC
[1185075] 1682519339.170030: Processing preauth types: PA-PK-AS-REP
(17), PA-PKINIT-KX (147)
[1185075] 1682519339.170031: Preauth module pkinit (147) (info)
returned: 0/Success
[1185075] 1682519339.170032: PKINIT client verified DH reply
[1185075] 1682519339.170033: PKINIT client config accepts KDC dNSName
SAN auth-test.mydomain.com
[1185075] 1682519339.170034: PKINIT client found 1 SANs (1 princs, 0
UPNs, 0 DNS names) in certificate
/C=US/ST=State/L=Location/O=Organization/OU=Unit/CN=auth-test.mydomain.com
[1185075] 1682519339.170035: PKINIT client found id-pkinit-san in KDC
cert: krbtgt/MYDOMA...@MYDOMAIN.COM
[1185075] 1682519339.170036: PKINIT client matched KDC principal
krbtgt/MYDOMA...@MYDOMAIN.COM against id-pkinit-san; no EKU check
required
[1185075] 1682519339.170037: PKINIT client used KDF 2B06010502030602
to compute reply key aes256-cts/71E2
[1185075] 1682519339.170038: Preauth module pkinit (17) (real)
returned: 0/Success
[1185075] 1682519339.170039: Produced preauth for next request: (empty)
[1185075] 1682519339.170040: AS key determined by preauth: aes256-cts/71E2
[1185075] 1682519339.170041: Decrypted AS reply; session key is: aes256-cts/0D0B
[1185075] 1682519339.170042: FAST negotiation: available
[1185075] 1682519339.170043: Resolving unique ccache of type MEMORY
[1185075] 1682519339.170044: Initializing MEMORY:IfWp4iF with default
princ WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS
[1185075] 1682519339.170045: Storing config in MEMORY:IfWp4iF for
krbtgt/MYDOMA...@MYDOMAIN.COM: fast_avail: yes
[1185075] 1682519339.170046: Storing
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM\@MYDOMAIN.COM@X-CACHECONF:
in MEMORY:IfWp4iF
[1185075] 1682519339.170047: Storing config in MEMORY:IfWp4iF for
krbtgt/MYDOMA...@MYDOMAIN.COM: pa_type: 16
[1185075] 1682519339.170048: Storing
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krb5_ccache_conf_data/pa_type/krbtgt\/MYDOMAIN.COM\@MYDOMAIN.COM@X-CACHECONF:
in MEMORY:IfWp4iF
[1185075] 1682519339.170049: Storing config in MEMORY:IfWp4iF for :
start_realm: MYDOMAIN.COM
[1185075] 1682519339.170050: Storing
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krb5_ccache_conf_data/start_realm@X-CACHECONF: in MEMORY:IfWp4iF
[1185075] 1682519339.170051: Storing
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krbtgt/MYDOMA...@MYDOMAIN.COM in MEMORY:IfWp4iF
[1185075] 1682519339.170052: Moving ccache MEMORY:IfWp4iF to FILE:/tmp/somecache
[1185075] 1682519339.170053: Destroying ccache MEMORY:IfWp4iF


and the attempt to auth via OTP:

$ KRB5_TRACE=/dev/stdout kinit -T /tmp/somecache
[1185088] 1682519355.427393: Getting initial credentials for b...@MYDOMAIN.COM
[1185088] 1682519355.427394: FAST armor ccache: /tmp/somecache
[1185088] 1682519355.427395: Retrieving
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM\@MYDOMAIN.COM@X-CACHECONF:
from FILE:/tmp/somecache with result: 0/Success
[1185088] 1682519355.427396: Read config in FILE:/tmp/somecache for
krbtgt/MYDOMA...@MYDOMAIN.COM: fast_avail: yes
[1185088] 1682519355.427397: Using FAST due to armor ccache negotiation result
[1185088] 1682519355.427398: Getting credentials
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krbtgt/MYDOMA...@MYDOMAIN.COM using ccache FILE:/tmp/somecache
[1185088] 1682519355.427399: Retrieving
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krb5_ccache_conf_data/start_realm@X-CACHECONF: from
FILE:/tmp/somecache with result: 0/Success
[1185088] 1682519355.427400: Read config in FILE:/tmp/somecache for :
start_realm: MYDOMAIN.COM
[1185088] 1682519355.427401: Retrieving
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krbtgt/MYDOMA...@MYDOMAIN.COM from FILE:/tmp/somecache with result:
0/Success
[1185088] 1682519355.427402: Armor ccache sesion key: aes256-cts/0D0B
[1185088] 1682519355.427403: Creating authenticator for
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krbtgt/MYDOMA...@MYDOMAIN.COM, seqnum 0, subkey aes256-cts/E842,
session key aes256-cts/0D0B
[1185088] 1682519355.427405: FAST armor key: aes256-cts/B8EF
[1185088] 1682519355.427407: Sending unauthenticated request
[1185088] 1682519355.427408: Encoding request body and padata into FAST request
[1185088] 1682519355.427409: Sending request (968 bytes) to MYDOMAIN.COM
[1185088] 1682519355.427410: Resolving hostname auth-test.mydomain.com
[1185088] 1682519355.427411: Sending initial UDP request to dgram fc00::1:88
[1185088] 1682519355.427412: Received answer (551 bytes) from dgram fc00::1:88
[1185088] 1682519355.427413: Sending DNS URI query for _kerberos.MYDOMAIN.COM.
[1185088] 1682519355.427414: No URI records found
[1185088] 1682519355.427415: Sending DNS SRV query for
_kerberos-master._udp.MYDOMAIN.COM.
[1185088] 1682519355.427416: Sending DNS SRV query for
_kerberos-master._tcp.MYDOMAIN.COM.
[1185088] 1682519355.427417: No SRV records found
[1185088] 1682519355.427418: Response was not from primary KDC
[1185088] 1682519355.427419: Received error from KDC:
-1765328359/Additional pre-authentication required
[1185088] 1682519355.427420: Decoding FAST response
[1185088] 1682519355.427423: Preauthenticating using KDC method data
[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)
[1185088] 1682519355.427425: Selected etype info: etype aes256-cts,
salt "MYDOMAIN.COMbob", params ""
[1185088] 1682519355.427426: Received cookie: MIT
[1185088] 1682519355.427427: PKINIT client has no configured identity; giving up
[1185088] 1682519355.427428: Preauth module pkinit (147) (info)
returned: 0/Success
[1185088] 1682519355.427429: PKINIT client received freshness token from KDC
[1185088] 1682519355.427430: Preauth module pkinit (150) (info)
returned: 0/Success
[1185088] 1682519355.427431: PKINIT client has no configured identity; giving up
[1185088] 1682519355.427432: Preauth module pkinit (16) (real)
returned: 22/Invalid argument
Password for b...@MYDOMAIN.COM:
[1185088] 1682519365.538171: Preauth module encrypted_challenge (138)
(real) returned: 0/Success
[1185088] 1682519365.538172: Produced preauth for next request:
PA-FX-COOKIE (133), PA-ENCRYPTED-CHALLENGE (138)
[1185088] 1682519365.538173: Encoding request body and padata into FAST request
[1185088] 1682519365.538174: Sending request (1067 bytes) to MYDOMAIN.COM
[1185088] 1682519365.538175: Resolving hostname auth-test.mydomain.com
[1185088] 1682519365.538176: Sending initial UDP request to dgram fc00::1:88
[1185088] 1682519365.538177: Received answer (1051 bytes) from dgram fc00::1:88
[1185088] 1682519365.538178: Sending DNS URI query for _kerberos.MYDOMAIN.COM.
[1185088] 1682519365.538179: No URI records found
[1185088] 1682519365.538180: Sending DNS SRV query for
_kerberos-master._udp.MYDOMAIN.COM.
[1185088] 1682519365.538181: Sending DNS SRV query for
_kerberos-master._tcp.MYDOMAIN.COM.
[1185088] 1682519365.538182: No SRV records found
[1185088] 1682519365.538183: Response was not from primary KDC
[1185088] 1682519365.538184: Decoding FAST response
[1185088] 1682519365.538185: Processing preauth types:
PA-ENCRYPTED-CHALLENGE (138), PA-ETYPE-INFO2 (19)
[1185088] 1682519365.538186: Selected etype info: etype aes256-cts,
salt "MYDOMAIN.COMbob", params ""
[1185088] 1682519365.538187: Preauth module encrypted_challenge (138)
(real) returned: 0/Success
[1185088] 1682519365.538188: Produced preauth for next request: (empty)
[1185088] 1682519365.538189: AS key determined by preauth: aes256-cts/2CFC
[1185088] 1682519365.538190: FAST reply key: aes256-cts/DA2D
[1185088] 1682519365.538191: Decrypted AS reply; session key is: aes256-cts/E0C1
[1185088] 1682519365.538192: FAST negotiation: available
[1185088] 1682519365.538193: Resolving unique ccache of type MEMORY
[1185088] 1682519365.538194: Initializing MEMORY:jh1396e with default
princ b...@MYDOMAIN.COM
[1185088] 1682519365.538195: Storing config in MEMORY:jh1396e for
krbtgt/MYDOMA...@MYDOMAIN.COM: fast_avail: yes
[1185088] 1682519365.538196: Storing b...@MYDOMAIN.COM ->
krb5_ccache_conf_data/fast_avail/krbtgt\/MYDOMAIN.COM\@MYDOMAIN.COM@X-CACHECONF:
in MEMORY:jh1396e
[1185088] 1682519365.538197: Storing config in MEMORY:jh1396e for
krbtgt/MYDOMA...@MYDOMAIN.COM: pa_type: 138
[1185088] 1682519365.538198: Storing b...@MYDOMAIN.COM ->
krb5_ccache_conf_data/pa_type/krbtgt\/MYDOMAIN.COM\@MYDOMAIN.COM@X-CACHECONF:
in MEMORY:jh1396e
[1185088] 1682519365.538199: Storing b...@MYDOMAIN.COM ->
krbtgt/MYDOMA...@MYDOMAIN.COM in MEMORY:jh1396e
[1185088] 1682519365.538200: Moving ccache MEMORY:jh1396e to
FILE:/tmp/krb5cc_1000
[1185088] 1682519365.538201: Destroying ccache MEMORY:jh1396e


Thanks for any additional help. I appreciate it!

-m

[Ken Hornstein]

>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

[Matt Zagrabelny]

[Probably solved!]

On Wed, Apr 26, 2023 at 10:12 AM Matt Zagrabelny <mzag...@d.umn.edu> 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/MYDOMA...@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

[Ken Hornstein]

>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

[Matt Zagrabelny]

On Wed, Apr 26, 2023 at 11:29 AM Ken Hornstein <ke...@cmf.nrl.navy.mil> 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

[Ken Hornstein]

>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

[Russ Allbery]

Ken Hornstein via Kerberos <kerb...@mit.edu> 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/>

[Ken Hornstein]

>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

[Charles Hedrick]

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 <kerberos...@mit.edu> on behalf of Russ Allbery <ea...@eyrie.org>
Sent: Wednesday, April 26, 2023 2:57 PM
To: Ken Hornstein via Kerberos <kerb...@mit.edu>
Cc: Ken Hornstein <ke...@cmf.nrl.navy.mil>
Subject: Re: help with OTP

Ken Hornstein via Kerberos <kerb...@mit.edu> 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/>

[Russ Allbery]

Charles Hedrick <hed...@rutgers.edu> 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.

[Ken Hornstein]

>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

[Matt Zagrabelny]

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

[Ken Hornstein]

>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

[Matt Zagrabelny]

Hi Ken!

Thanks for the reply and the comments.

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