[23437] in Kerberos
Re: afs to k5 conversion keytypes
daemon@ATHENA.MIT.EDU (Jeffrey Hutzelman)
Tue Feb 22 16:13:58 2005
Date: Tue, 22 Feb 2005 16:12:34 -0500
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>, kerberos@mit.edu
Message-ID: <33A69BFB780B0FDE2E543A2D@sirius.fac.cs.cmu.edu>
In-Reply-To: <200502222045.j1MKjA8N001656@ginger.cmf.nrl.navy.mil>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Errors-To: kerberos-bounces@mit.edu
On Tuesday, February 22, 2005 03:45:10 PM -0500 Ken Hornstein
<kenh@cmf.nrl.navy.mil> wrote:
>> krb5_change_password is not any worse to use than the init_creds API.
>> You can avoid the kadm5 API.
>
> Oh, sure ... but I'm not sure that's sufficient. What you probably
> want to do is query the database to see what enctypes your principal
> record has (so you're not doing a whole lot of password changes) and
> _that_ requires the kadm5 API. I guess you could do a password change
> for every login, but that sure would suck. Assuming you support something
> stronger than single-DES, you could get away with checking the enctype
> of the TGT session key, and you could avoid the kadm5 API that way.
I've been thinking about this recently, and I think what you want to do
(though there is no clear API for this) is check the enctype of the
long-term key that was actually used in getting the TGT.
If you believe you support AES, and the KDC supports AES, then you're going
to get an AES session key even if you don't have an AES long-term key.
OTOH, if you claimed to support AES and the long-term key the KDC actually
used was DES, then you should do the password change. Assuming, of course,
that the feature is enabled and that local configuration says you want to
have AES keys.
-- Jeff
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
