On Fri, Jan 04, 2008 at 03:54:06PM -0700, Shawn M Emery wrote:
> Nicolas Williams wrote:
> > On Fri, Jan 04, 2008 at 03:11:30PM -0700, Shawn M Emery wrote:
> >> The supported enc types are documented in krb5.conf and is disjoint from
> >> the default set with the arcfour-hmac-md5-exp and des-cbc-crc elements.
> >>
> >
> > I don't follow this.
> >
>
> Supported encryption types also include arcfour-hmac-md5-exp and
> des-cbc-crc.
supported_enctypes' default is all enctypes.
> >>> Does the list of default enctypes include all the supported enctypes? If
> >>>
> >>>
> >> No, the supported set is found only in krb5.conf by design.
> >>
> >
> > Hmmm, no, supported_enctypes lives in kdc.conf. IIRC MIT wants to merge
> > kdc.conf into krb5.conf (yay).
> >
>
> The distinction is supported_enctypes and supported encryption types by
> the Kerberos mechanism.
The supported_enctypes parameter is misnamed. Its name makes all talk
of what is supported or not very confusing.
The supported_enctypes merely provides a default when the -e option is
not used with certain kadmin sub-commands.
In all other case when we speak of what enctypes are supported we really
might mean:
- what can I set permitted_enctypes to?
- what is permitted_enctypes set to?
So, three possible meanings altogheter when we talk about supported
enctypes.
Mark asked very specifically about the supported_enctypes parameter.
The answer is in kdc.conf(4), and it's incorrect -- the real answer is
in the code and it's "all enctypes".
> > Note that Solaris Kerberos differs from MIT Kerberos with regard to
> > supported_enctypes as follows:
> >
> > - kadmin(1M)'s ktadd sub-command, on Solaris 10 and up, when called
> > without a -e option always takes the local permitted_enctypes list
> > and uses that as the list for -e, as if it had been given
> >
>
> Yes.
>
> > - kadmind(1M) does NOT use supported_enctypes when clients call the
> > randkey RPC that doesn't have the enctype list; instead it defaults
> > to des-cbc-crc:normal only. That means: Solaris 8 and 9 kadmin ktadd
> > clients and MIT kadmin ktadd clients used without -e.
^
,
> s9- and s10+ call different functions in order to create keys with the
> correct encryption types:
> s9-: chrand_principal_1_svc()
> s10+: chrand_principal3_1_svc()
That's exactly what I said :) (But I missed adding a comma.)
S9- never had support for the *3 functions, and, correspondingly, their
kadmin sub-commands never had -e options.
The difference in S10+ and MIT behaviour of ktadd w/o -e is worth
pointing out as folks might wonder why they only get 1DES keys that way.
Nico
--
