>>>>> "RH" == Robbie Harwood <rharwood@xxxxxxxxxx> writes:
RH> I've spent a nontrivial amount of time working on improving that,
RH> but am always willing to process more bugs in the
RH> documentation/errors area.
I know, and I don't mean to denigrate any work that's been done in
making the MIT KRB stack better. It's certainly a whole lot better than
it used to be. I've been using it since, I don't know, sometime in the
previous century.
RH> My memory is that it complains about a bad enctype on K/M, but it's
RH> been a while. If you want, as part of this change I can make sure
RH> it generates a useful error message.
Certainly don't add a message on my account, but on the general
principle that if krb5kdc can't start at all then it would try to say
why.
>> Well certainly there isn't much you can do to fix old principals on
>> existing systems. But the current versions should be complaining
>> loudly when it has to issue a ticket for a principal that lacks a
>> modern enctype today, if not six months ago.
RH> Yes but also no. The problem is where to complain.
Maybe I wasn't clear, but I was saying that maybe the KDC should
complain when it has to issue a ticket with a key type that's
deprecated.
RH> For folks running KDCs, we do have existing logging.
Then I have to say that I'm not seeing it. For some background, here's
what I was recently working on.
I set up a test slave KDC with Fedora 29 and did some testing against
it. Trying to get a ticket using an old principal generated this bit of
log:
Dec 07 19:08:30 XXX krb5kdc[846](info): AS_REQ (7 etypes {18 17 16 23 1 3 2}) YYY: NEEDED_PREAUTH: ZZZ for krbtgt/QQQ, Additional pre-authentication required
Dec 07 19:08:30 XXX krb5kdc[846](info): DISPATCH: repeated (retransmitted?) request from YYY, resending previous response
The last line is repeated a number of times. There are no other logs
related to this principal.
The problem is that the principal in question hasn't been touched in
twelve years (which I guess you can see from the list of etypes.) That
coupled with the change (which I don't think was your doing) to
/etc/crypto-policies/back-ends/krb5.config to remove des3-cbc-sha1
caused the KDC to fail to issue those tickets.
So obviously I figured out what the problem was, but the logged info
wasn't remotely helpful in figuring that out.
Now, krb5kdc couldn't really know that F29 was going to drop something
from supported_enctypes, and there's no setting like
"deprecated_enctypes" which would have told it what to complain about
(though that doesn't sound like a terrible idea). But if the server had
said what the problem was, or there was something which bugged me about
principals having only deprecated etypes, then I wouldn't have had any
confusion at all.
RH> But as an admin, you know that I'm already logging every issuance -
RH> including their etypes.
Yes, but of course that doesn't help you if it doesn't issue anything.
I guess if you know the list of etypes by heart you could see the
problem from the logged info. And if it does issue something today but
will fail in F30 due to removal of some etypes, there's no complaint at
all.
RH> I don't think that putting more messages in here would be useful,
RH> but I could be persuaded otherwise.
Doesn't technically have to be more messages, even adding more
information to the existing message would help. Adding ", Only
deprecated etypes issued" to the end of the ISSUE lines would sort of be
in keeping with the existing format.
But really, whether it's in something that gets logged or some separate
tool I can run or something, it would just be nice to have some
established procedure to know that that you're going to be hit by
expiring crypto before you actually get hit by it.
>> Of course, if I'm reading that wrong and this is merely an effect of
>> moving to version 1.18 then.... the current devel documentation
>> doesn't seem to say much about deprecation of additional algorithms.
>> Which I know doesn't mean much, but given how kerberos development
>> progresses, I would have expected the complete removal of an
>> encryption type to be telegraphed years in advance.
RH> Arguably, we telegraphed single-DES removal in 2009 (and there have
RH> been two RFCs about this that I cited), but you're right that
RH> Kerberos has never been a "move fast and deprecate things" kind of
RH> situation.
Yes, single-DES removal has been yelled about loudly for a long time.
There's a section in every release announcement about it. But isn't the
current proposal about removing more than just 1DES?
RH> I don't want to go on too long about this, but the perception that
RH> Kerberos is somehow "maintenance mode" isn't quite right.
I certainly don't harbor the belief that MIT Kerberos is just in
maintenance mode. I was trying to say that it moves carefully and with
significant effort put into backwards compatibility.
- J<
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
