directory-kerby mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <>
Subject RE: AP-REP message
Date Mon, 04 Jan 2016 07:39:01 GMT
I know and agree with the point you made here. What I would say is that, our Kerberos implementation
codes are still lacking many things and to be evolved fast. We may see many classes, variables,
methods and codes are not referenced in the existing codes, it's normal because we have so
much to fill yet. Given you have reviewed quite a few of the codes, I guess you might understand
that why we define and write those classes or methods not used yet, because in many times
we follow a RFC spec, or a fixed pattern and make up many of them, either for completeness,
for the future we'll use them at all, or just for our customers they need the library to do

Decrypted result in Kerberos is surely to be passed elsewhere and handled in various procedures
or components, considering it often contains many information. We just can't do all the logics
in a single place because that would result in a very large function or class. I guess the
codes you noted are still very initial for now, which means we have many things to fill in
the places. Sorry I haven't checked the codes you mentioned, but I would if our Kerby codes
are going to be close to the final status with all the available functionalities existing
in MIT Kerberos already fine implemented. Obviously, we're not. Sadly, we won't in a fair
term future. Otherwise it's unfair, Kerberos has evolved past more than twenty years, we just
can't catch up with the mainstream simply in one or two years.

Please pardon if what I said is over too much. Thanks!


-----Original Message-----
From: Emmanuel Lécharny [] 
Sent: Monday, January 04, 2016 2:38 PM
Subject: Re: AP-REP message

Le 04/01/16 06:12, Zheng, Kai a écrit :
> It's good to look at the life cycle of these decrypted objects but I don't think it will
help a lot if we would do otherwise. Generally decrypting the part and using the decrypted
result are not the same place. 

Here is where the encrpted data is decrypetd and used, in KdcRequest :

     * Get the armor key.
     * @throws org.apache.kerby.kerberos.kerb.KrbException e
     * @param fastArmor krb fast armor
    private void armorApRequest(KrbFastArmor fastArmor) throws KrbException {
        if (fastArmor.getArmorType() == ArmorType.ARMOR_AP_REQUEST) {
            ApReq apReq = KrbCodec.decode(fastArmor.getArmorValue(),

            Authenticator authenticator = EncryptionUtil.unseal(apReq.getEncryptedAuthenticator(),
                    encKey, KeyUsage.AP_REQ_AUTH, Authenticator.class);

            EncryptionKey armorKey =
FastUtil.cf2(authenticator.getSubKey(), "subkeyarmor",
                    encKey, "ticketarmor");

or in TgsRequest :

    public void verifyAuthenticator(PaDataEntry paDataEntry) throws KrbException {
        ApReq apReq = KrbCodec.decode(paDataEntry.getPaDataValue(),


        Authenticator authenticator =
            encKey, KeyUsage.TGS_REQ_AUTH, Authenticator.class);

In both case, we get the encrypted data, we decypt it locally, put the result in a local variable,
which is immediately used and discarded. Its quite what I'm expecting to see, btw. At no point
in the whole kerby code we use the decrypted value, which is by the way not set in the encapsulating
data structure.

At this point, I can see why it has been added in the structure - in the spirit that it may
be used in a different place in the code than where it has been decrypted -. But actually,
this is not the case.

If you feel like it's better to keep those fields in the classes, so be it. I'm just afraid
we keep them for the sake of keeping them, not respecting the YAGNI principle

Your call !

View raw message