[OpenAFS] Re: 'afs/' principal rekeying instructions may be incomplete

[Andrew Deason]

On Thu, 23 Jan 2014 18:35:40 +0000
pg@afs.list.sabi.co.UK (Peter Grandi) wrote:

> Is there any _technical_ risk in using the "avoid the loss of
> the old keys" procedure?

You apparently get a keytab that contains DES keys in it, and apparently
the DES entries have the wrong kvno. That can cause problems. That's the
only actual problem I can think of, besides just being confusing.

If the KDC does actually use that old key for issuing a new ticket, then
that could also be a problem. But I'm not aware of any case in which it
does, which also means keeping it around is pointless.

There's also no way to get rid of it unless you are running a new enough
MIT KDC. I don't remember what version lets you fix that, but istr older
ones have no way of removing older keys besides hex-editing the database
or something crazy like that.

> Thus my aim was to keep both the single-DES key and 'Keyfile' for a
> while (I am well aware that as long as they exist there is no extra
> authentication security from the other keys and keytab) check the KDC
> logs to see whether any new single-DES tickets for 'afs/cell' are
> generated in the next week

I don't think that's possible. Someone more familiar with the MIT KDC
codebase can confirm/deny, but old kvnos should be ignored for the
purposes of issuing new tickets; I don't know of any situation where
that's not true.

What you would really want to look for is incoming requests to the AFS
servers that are using single-DES keys. But I don't think we have a way
of tracking that beyond sniffing the wire traffic.

>   "On OpenAFS 1.6.5, this is best achieved by renaming the
>   KeyFile out of the way, but retaining it so that it can be
>   reinstated if one of the previous steps was incomplete."
> 
> Keeping around the 'KeyFile' so it can be restored does not make
> sense unless the matching key is preserved too. Unless the above
> strictly refers to keeping it aorund for the sake of already
> existing tokens.

Oh, we just like to be cautious. I hear Kerberos and OpenAFS have a
large number of corner cases ;)

But yes, it's helpful to keep around in case someone is still using
those credentials. This can be already-issued tokens, or it can be any
machine that has a copy of the KeyFile, and is using it for outgoing or
incoming connection authentication.

> For example I know that several run under 'k5start', and I don't know
> which enctypes are in those keytabs. I am fairly sure they include
> non-DES enctypes, but then I would have to check each of them.
> 
> But then I am not sure what 'k5start' when it renews a ticket.
> If it keeps using the same single-DES key then renewal will fail.

It doesn't. It just runs aklog to get tokens, which will take your TGT,
and acquire an afs/ service ticket with it. The keys in such a keytab
are only for obtaining a TGT (in this situation), and the TGT is used
for obtaining other service tickets.

Also, I'm not sure if this is clear, but the encryption type of the
service key is supposed to be invisible to the client; the client just
passes an encrypted blob to the server. The keys in your keytab for a
k5start'ified service have no relation to the keys for the afs/ service
principal. (Unless you are trying to authenticate _as_ the afs/
principal, which is weird and you're on your own.)

It also should be pointed out that this general rekeying procedure isn't
really an AFS thing. It was just provided for the rxkad-k5/kdf
transition, since it was my opinion that many sites have never performed
a rekeying procedure and wouldn't know what to do. The "basic" procedure
we described is the same as rekeying any kerberized service, and matches
the procedures recommended by the MIT link you provided (for kerberized
application services, not the TGS). So if you want to change what the
recommended procedure for rekeying services is, I think you'll need to
convince the general Kerberos community and not us.

There are some specifics with the KeyFile and rxkad.keytab and all that,
but the how-to-rekey.txt document itself I believe is largely agnostic
of the underlying service. We talk about the afs/ service principal and
fileservers and such so we can be more direct and less confusing, but
the actualy procedures are not AFS-specific.

> > In particular, that means that when receiving a token that's
> > encrypted in a single-DES key, the AFS server will look in the
> > KeyFile for that decryption key. If the key is only in
> > rxkad.keytab, it will fail. [ ... ]
> 
> So if I keep the 'KeyFile' until all possible single-DES tickets
> have fully expired this is not an issue :-).

Yes, and doing this is what is recommended.

-- 
Andrew Deason
adeason@sinenomine.net