cURL / Mailing Lists / curl-library / Single Mail



From: Michael Osipov <>
Date: Sun, 16 Nov 2014 11:03:30 +0100

Hi Steve,

Am 2014-11-16 um 00:23 schrieb Steve Holme:
> On Sat, 15 Nov 2014, Michael Osipov wrote: [...]
>> If you take another close look, you'll see that gss_seal is used
>> and this is exactly the same as a SASL QOP which I told you about
>> recently.
> Reading the above RFC it did seem like there was a bit of overlap
> between what the PROT command is trying to do and auth-int and
> auth-conf from SASL's QOP values.

Yes, exactly.

>> So that option was/is not used with Kerberos 4 but can be used
>> with Kerberos 5 too.
> Would you ever want to use it with Kerberos 5 or would you only use
> the encryption part of Kerberos 5 rather than the authentication part
> here? Am I right in thinking that you could authenticate FTP with
> clear text, but then use a protocol protection of PRIVATE and let
> Kerberos 5 do that encryption for you?

Well, I am not skilled with FTP but theoretically yes, that should be
stated in the RFC. You would require a valid GSS context anyway.

Though it wouldn't make any sense to me to use cleartext auth and
encrypt with Kerberos.

>> At best, we need someone who uses that stuff in the real world. In
>> my opinion, stuff has been contributed and never been reviewed
>> again. :-(
> Yep. I wouldn't mind learning more about FTP and updating its
> authentication. For example I added Kerberos 5 support via SSPI to
> the TODO list, add other mechanisms if FTP supports them, and try and
> remove some of the "Blocking" code in the process - but at the
> moment, as you know, I'm busy with other things in curl at the
> moment.

Have you read the source review?

Ultimately, you have found a bug because --krb (KRBLEVEL) can be/is used
with Kerberos 5. That should be checked (AND) with HAVE_GSSAPI, idealy
with USE_KERBEROS but those calls aren't ifdefed yet.

The level/QOP things boils down to the same code with GSS-API: gss_wrap
with flags. It is perfectly fine use the naming of the high level
API/protocol, e.g., FTP PROT's enum with distinct options and SASL QOP
but the backend should map it to one code block only. It does not matter
whether you wrap for SASL or FTP.

List admin:
Received on 2014-11-16