Anyone managed to build a static gssd?

[Rick Macklem]

Benjamin Kaduk wrote:
>On Mon, Jan 08, 2018 at 01:52:48PM +0000, Rick Macklem wrote:
>> Garrett Wollman wrote:
>> [good stuff snipped]
>> > What would it take to get AES support?
>> Good question. Unfortunately I don't know the answer.
>> (I shouldn't have blamed RPCSEC_GSS Version 1, since it isn't this spec
>>  that is the problem, from what I know.)
>>
>> 1 - The kernel RPCSEC_GSS code does upcalls to the userland library for
>>    the initialization phase (ie. GSS_Init() calls using the tokens).
>>    --> So question #1 becomes "Does the Heimdal GSSAPI library know how
>>          to do better checksum/encryption than was specified in the original
>>          GSSAPI RFC?".
>
>Heavens; yes!  Per RFC 6649, you shouldn't be using single-DES for
>anything you actually care about the confidentiality of.
I wasn't asking if they should. I just didn't know if they had been updated
to do so.

Anyhow, I took a quick look at the code and it does appear that everything
is there to make newer encryption types up to aes256 work, assuming the
userland library does its part.
(In sys/kgssapi/krb5 there is krb5_mech.c and in it there are krb5_encrypt_new()
 as well as krb5_encrypt_old(). The one that ends in _new() appears to do the
 newer stuff like aes.)

>> 2 - The kernel RPCSEC_GSS code uses the session key from the GSS_Init()
>>   handling of the tokens to do checksums/encryption. (Basically in kernel
>>    versions of GSS_GetMIC(), GSS_VerifyMIC(), GSS_Wrap, GSS_Unwrap().)
>>    If the answer to #1 is yes, then it  might not be that much work?
>
>sys/kgssapi/krb5 has bits for aes/RC4/etc.
Yep, as I noted above. The RPCSEC_GSS code used the gss context which
hopefully gets set to the right thing.

>> 3 - I have never seen any definition of what the QOPs are for better encryption
>>   types in the GSSAPI. (Numbers that define the better checksum/encryption
>>   algorithms.)
>>   --> I have no idea if the NFS implementors have done anything about this.
>>         I haven't seen discussions of it on nfsv4 at ietf.org, but it may have happened.
>>         Without this, you'd end up with a FreeBSD specific hack that didn't
>>         interoperate with other NFS implementation.s
>>         In practice these days "If Linux supports it, others will too.".
>
>The GSS QOP should be considered deprecated as of GSS-API version2,
>and GSS_C_QOP_DEFAULT is the only thing I ever see used.
>The session key output by the GSS security context negotiation will
>be of an encryption type supported by both peers, so there "ought
>not" be any code changes needed to the GSS-API consumer code.
I looked and the RPCSEC_GSS kernel code only uses GSS_C_QOP_DEFAULT.

>> If you can answer all of the above, then you probably know the answer.
>> It could range from some fairly minor changes to the kernel RPCSEC_GSS
>> code to a whole lot of work.
>>
>> Maybe some Kerberos conversant folk can shed light on this?
>
>The above all adds up to a situation where the last time I tried to
>look at this (a few years ago), I had managed to convince myself
>that non-single-DES should "just work" as-is.  But I didn't actually
>spin up a test server to verify that.
Yep. I would agree with this. I could only get DES to work, but that was
quite a few years ago and I was just testing the NFS side, so I didn't care
if newer encryption worked.

Hopefully someone will test and find out if it works, rick
ps: And sorry for misleading you by saying only 64bit keys worked. That
      statement assumed that the krb5_encrypt_old() functions were the
      only ones available.