Kerberos & GSS-API native support on Solaris

Henry B. Hotz hotz at jpl.nasa.gov
Mon Apr 4 17:44:25 EDT 2005


I've heard that the previous Sun Kerberos stuff was based off of MIT  
1.2.1.

Did you guys re-import a later version for you Solaris 10 work?  (If  
so, which version?)

I've got to say I'm impressed with the Kerberos improvements in Solaris  
10.  You didn't just update the encryption types, but you got it all  
much better integrated with the rest of the system it appears.

On Apr 4, 2005, at 11:15:46 -0500, Nicolas Williams wrote:

> Date: Mon, 4 Apr 2005 11:15:46 -0500
> From: Nicolas Williams <Nicolas.Williams at sun.com>
> To: "Newman, Edward (IDS GNS)" <edward_newman at ml.com>
> Cc: krbdev at mit.edu
> Subject: Re: Kerberos & GSS-API native support on Solaris
> Message-ID: <20050404161546.GI16131 at binky.Central.Sun.COM>
> In-Reply-To:  
> <662111A076D927479A73552F31FBE5FF02F312EF at mllna201mb.emea.win.ml.com>
> References:  
> <662111A076D927479A73552F31FBE5FF02F312EF at mllna201mb.emea.win.ml.com>
> Content-Type: text/plain; charset=us-ascii
> MIME-Version: 1.0
> Precedence: list
> Message: 1
>
> On Mon, Apr 04, 2005 at 01:32:05PM +0100, Newman, Edward (IDS GNS)  
> wrote:
>> Can anyone provide a support matrix for Kerberos on Solaris using  
>> native
>> Sun libraries (rather than MIT or Heimdal). I have had particular
>> difficulty in getting a definitive answer on this. The following  
>> appears
>> to be the case:
>>
>> Solaris 8
>> Standard Global encryption versions of Kerberos and GSS-API (libgss)
>> only provide for DES based integrity. No support for even DES based
>> encryption or other stronger encryption algorithms (appears to show by
>> missing GSS_KRB5_CONF_C_QOP_DES in /etc/gss/qop file).
>>
>> Domestic encryption (possibly added via Solaris Encryption Kit)  
>> provides
>> enhanced DES support for Kerberos. Still no support for RC4-HMAC.
>
> Solaris 8's implementation of the Kerberos V mechanism supports the DES
> enctypes only.
>
> Its "Domestic" Kerberos V mechanism supports confidentiality and
> integrity protection.  Its "Global" Kerberos V mechanism supports only
> integrity protection.
>
>> Solaris 9
>> Global encryption libraries appear to support DES integrity and
>> encryption. No RC4 support.
>
> Solaris 9's implementation of the Kerberos V mechanism supports the DES
> enctypes only.
>
>> Solaris 10
>> Kerberos implementation supports many encryption variants through new
>> Solaris 10 encryption APIs. Includes RC4-HMAC.
>
> Solaris 10's implementation of the Kerberos V mechanism supports a
> number of enctypes:
>
>  - DES
>  - 3DES
>  - RC4-HMAC
>  - AES-128
>  - AES-256 (with the addition of the supplemental cryptographic
>    packages)
>
>> Clearly some of above could be resolved by installing MIT libraries  
>> and
>> recompiling against these rather than native implementations. Just
>> trying to understand what the existing native Solaris support consists
>> of.
>
> You can't replace the native Kerberos V implementation for Solaris
> native consumers of it (RPCSEC_GSS, pam_krb5, telnet/in.telnetd, ...).
>
> You can replace some, but not all, of the Solaris native consumers of
> mech_krb5.  Specifically you cannot replace the RPCSEC_GSS component
> (i.e., Secure NFS).
>
>> What combination of packages and patches would provide full DES
>> integrity and encryption on Solaris 8/9? Does someone maintain such an
>> interoperability matrix for Kerberos? Any chance that Active Directory
>> will move to AES?
>
> See above.  For Solaris 8 you need the Domestic version of mech_krb5,
> which comes with the Solaris Data Encryption Supplemental CD:
>
> http://www.sun.com/software/solaris/encryption/
>
> IIRC Solaris 9 ships only the domestic mech_krb5.
>
> Nico
>
------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu


------------------------------------------------------------------------ 
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu



More information about the krbdev mailing list