On May 1, 2007, at 1:16 AM, Magnus Hagander wrote:

Henry B. Hotz wrote:
OK, so posted.  ;-)


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.

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'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.

The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to