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:
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.
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 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.
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!
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.
Hi Ken!
On Mon, Apr 24, 2023 at 5:25rC>PM Ken Hornstein <kenh@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 bob@MYDOMAIN.COM
Principal "bob@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
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
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.
You probably need to set some of the PKINIT parameters since they seem
to be tied to FAST as well in your krb5.conf on your client:
YOURREALM = {
pkinit_kdc_hostname = yourkdc.fqdn
}
Making progress... but still need some pointers.
[...]
YOURREALM = {
pkinit_kdc_hostname = yourkdc.fqdn
}
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.
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:
[...]
Whoops. Looks like I need:
sudo apt install krb5-pkinit
Since I am currently only interested in anonymous auth, I thought I
could skip that directive. But alas:
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.
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.
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
Well, dang, that's one for the toolbox! I was able to confirm thatI 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
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.
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.
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.
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.
On Wed, Apr 26, 2023 at 11:29rC>AM Ken Hornstein <kenh@cmf.nrl.navy.mil> 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?)
The former. :)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 stepprocess
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?
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 64 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 492944:06:07 |
| Calls: | 842 |
| Files: | 1,304 |
| D/L today: |
8 files (19,649K bytes) |
| Messages: | 261,765 |