using keytab with preauth and ldap alias canonicalization

[Greg Hudson]

On 10/4/21 11:38 PM, Chris Hecker wrote:
> The first time the player starts the game and wants to go online, what 
> happens depends on how they launched the game.  Sometimes I get a 
> username/password, and then create a key from that and save it in the 
> keytab.  Other times I get a keyblock from a server process that talks 
> to kadmind and I save that to a keytab.  Then we fall through to the 
> next case...
> 
> If there is an existing keytab, I load the key from that, and then send 
> it to the KDC to get a TGT.
> 
> So, currently, all paths go through the existing key path eventually, 
> which is where I'm running into trouble.

Well, you're running into trouble when you have the wrong key in the
keytab, which happens in the username/password case when you don't use
the right salt (because you're using the default salt for an alias).

> I assume given a key created for checkersp, there is no way to change it 
> into a key for checker, so I'd need to reprompt or get a new keyblock 
> for the canonical name?

checkersp and checker have the same key.  If you're computing it from a
password you must use the correct salt, either by fetching it from the
KDC or by knowing the canonical principal name (assuming the principal's
keys use the default salt, which is likely).

If you created a key from the password using the default salt for
checkersp, it's not valid for anything, and you won't be able to go back
to the inputs.

> Is there a way to validate that the checkersp 
> key is at least correct, or is that info not available because the KDC 
> only has the key with the canonical salt and stuff?

Right, it only knows the long-term key as computed with the canonical salt.

> I guess I haven't 
> tested the case of adding an alias that becomes the canonical princ.  Is 
> the existing password key in the KDC invalid then...in other words, 
> assuming I just use LDAP to add another princ and set it canonical 
> without touching other LDAP fields, is the key data invalid at that 
> point because the salt is wrong?

Generally yes.  In the normal case, the salt isn't stored in the key
data, and the KDC computes it from the canonical principal name and
sends that to the client.  So if you change the canonical principal name
without changing the key set or storing the old canonical salt, the KDC
will start sending the wrong salt to clients and clients will compute
the wrong keys.

>  I'll have to handle that case I 
> think...will I have to force a password update on that account, assuming 
> again there's no way to rekey from one princ salt to another?

kadmin's rename operation computes the old salt value and stores it in
the key data as an explicit salt, so that the KDC continues sending the
correct salt the client.  See krb5_dbe_specialize_salt() if you're curious.

> I'm also going to have to handle the case where the canonical alias is 
> created after a player already has a keytab saved, so I'm going to have 
> to deal with the error of the key login path failing regardless.  Hmm.

Not sure this follows.  Obviously if there was a password change, the
keytab is out of date.  If there was no key change and the keytab wasn't
incorrectly created, the keytab should still work.

[From another message:]
> Is there any reason ktutil is under the kadmin tree instead of buildable 
> in the clients tree with kinit and klist and whatnot?  It uses the ss 
> library so it's a bit less portable I guess, but it doesn't use and kadm 
> functions and seems generally useful on clients too?  It's installed 
> alongside those client tools on centos at least.

It's been that way since 1.0.  kadmin is also a client, as is
gss-sample, so it's never been the case that all clients were under
clients.  I don't believe we build ss on Windows, so that would be the
primary obstacle to adding ktutil to the Windows build.