Solaris 9, stock sshd, pam_krb5, MIT 1.4.3 KDC

[Nicolas Williams]

On Tue, May 16, 2006 at 05:32:45PM -0400, Jeff Blaine wrote:
> Nicolas Williams wrote:
> > What does kadmin -q "getprinc host/noodle.foo.com at JBTEST" say?
> > 
> > I bet the des3-hmac-sha1 key comes before the des-cbc-crc key.
> 
> Yes, it does.

Well, that's it then.  Switch to des-cbc-crc.

Yes, the krb5 team at Sun greatly upgraded enctype support in Solaris
10.  No, this can't be easily backported to Solaris 9.

> > That means that when the stock pam_krb5/mech_krb5 do a TGS-REQ to get a
> > service ticket [for the PAM_USER with host/noodle.foo.com at JBTEST as the
> > service principal name] with which to validate the user's TGT the ticket
> > will come back encrypted in host/noodle.foo.com at JBTEST's 3DES key
> > (because the KDC will select that long-term key because it's first in
> > the KDB entry), which, sadly, the Solaris 9 mech_krb5 doesn't support.
> 
> I guess this is what I want:
> 
> http://www.ietf.org/internet-drafts/draft-zhu-kerb-enctype-nego-04.txt

No, this is not applicable to your situation.

> This helped just now though.  What a mess.
> 
>      http://learningsolaris.com/docs/krb_enctypes_so10.pdf
> 
> Looks like I'll redo my existing stuff to only ever allow
> 1DES enctype (boggles my mind) via 'supported_enctypes' in
> kdc.conf.

Hmmm, OK, this is complicated, and I'd rather not go into all these
details, but:

 - the Solaris 10 kadmind has a heuristic to detect Solaris 8 and 9
   kadmin clients so that changing a service principal's keys results in
   getting only 1DES keys,

 - while for changing user passwords results in all supported_enctypes
   being allowed for the user.

 - at the same time, the Solaris 10 kadmin client's ktadd sub-command
   acts as though the -e <all permitted_enctypes> option had been given,
   if it wasn't.

So that if you have a Solaris 10 KDC and Solaris 8, 9 and 10 systems
deployed you should not normally notice this 1DES vs. other enctypes
issue.

Perhaps we need to get this behaviour into MIT krb5, since you're using
it alongside Solaris' krb5 support.  I assume you're using MIT's KDC
software.

MIT?

> That seems a real shame -- "Use 1DES in any homogenous
> environment or you may really hurt yourself."
> 
> Sadly, it also doesn't appear one can remove just *one* enctype
> instance of a key (the 3DES one in my case).

You could ktadd again, with -e des-cbc-crc:normal,...  but though this
is better than not having 3DES keys at all, it doesn't really buy you
much security.

> I'm glad I am finding all of this out now on a testbed
> machine :O
> 
> > You could upgrade to Solaris 10 and get support for AES (in addition to
> > 3DES and HMAC-RC4)...
> 
> Not an option.

:(

> Thanks for your help, Nico and Doug.

NP.

Nico
--