Re: Fwd: [PATCHES] Preliminary GSSAPI Patches

Henry B. Hotz wrote:
>
> On May 1, 2007, at 1:16 AM, Magnus Hagander wrote:
>
>> Henry B. Hotz wrote:
>>
>>>>> Would you like a new version of the patch with the incomplete
>>>>> functionality commented out (or otherwise removed)?
>>
>> Yes please :-) I was going to try to do one of those myself, but since
>> you already know your way around the code, please do it. And please go
>> for removing it alltogether instead of just commenting it out - it's in
>> the list archives and can be referred to there if/when we want to add it
>> back in.
>
> I can do that.

Thanks!

> Could I ask you, or someone else, to look at what needs to happen to
> configure? The way you capture `krb5-config --libs gssapi` into a
> variable is completely different in BSD and GNU make, and I don't know
> how to deal with that. (The configure logic for mod_auth_kerb suffers
> from that problem, too.) The README.GSSAPI file in the patch has
> reasonable notes, and it should be pretty simple otherwise.

I'll leave the autoconf-fu to someone else if possible, but I can look
at it later if nobody does (will look at the rest too).

The docs need to be moved from README into the proper docs as well, but
I can take care of that once the code is settled.

>> I'd also vote for changing the name of the "non encrypted" version to
>> just "gss" instead of "gss-np".
>
> I happen to disagree on this point. There are a whole class of attacks
> that become possible if the encryption from the original authentication
> exchange isn't used for the on-going channel encryption/integrity. They
> may be impossible in practice, but how many cans of worms do you want to
> deal with when you recommend a "secure" configuration to an average
> admin? I would rather not hide the distinction by changing the name
> that way.
>
> Also, if I *do* get the buffering disentangled and create a working
> "gss" mechanism, what would I call it if the name is already taken? At
> that point it would become the recommended mechanism unless high-volume
> performance made it impractical.

I would call them "gss" and "gss-sec". Or possibly "gss-enc". I think
that's a lot more clear than "gss-np" (something ending with -sec is a
giveaway)

But I won't fight for it, it's not that important to me :-)

(And whether it's recommended or not depends on the environment - there
are a cases where it's just unnecessary to add it. Say if you're
employing ipsec across your network, adding a second layer of encryption
will just make things slower for no gain - and it makes things more
complex. Even if you're not talking high volume.)

//Magnus