Non-default Quality of Protection?

[Tomas Kuthan]

On 11/12/13 04:29 PM, Benjamin Kaduk wrote:
> On Tue, 12 Nov 2013, Tomas Kuthan wrote:
>
>> Hi all,
>>
>> I am confuzzled about usefulness of the QOP concept in GSS-API.
>>
>> RFC 2743 states, that using non-default QOP is a mechanism specific,
>> non-portable construct.
>> RFC 4121 says, that applications using different QOP than default are
>> not guaranteed portability and interoperability. It also says, that
>> encryption and checksum algorithms in per-message tokens are implicitly
>> defined by the algorithms associated with the session key or subkey and
>> that using different algorithm than the one for which the key is defined
>> may not be appropriate.
>>
>> This gives me the impression, that using non-default QOPs is discouraged
>> and that the whole Quality of Protection concept is somewhat obsolete.
>> Is that so?
>
> Yes, it is so.
>
>> Do you know of a use-case (real life or hypothetical) for non-default
>> QOP with Kerberos GSS-API mechanism?
>
> Not in the present day and age. RFC 1964 defined some non-default QOP
> values, but it is obsoleted by the the RFC 4121 you were looking at; the
> code that actually implemented such QOP was removed in the 2003-2006
> timeframe (depending on what implementation you are looking at).
>
>> Does any other GSS-API mechanism make use of non-default QOPs?
>
> I don't know of any, but neither am I a full expert on all GSS-API
> mechanisms out there.
>
>
> My sense is that the QOP concept is recognized as
> broken/not-very-useful, but there just hasn't been enough time to bump
> the GSS-API version and remove it entirely.
>
> -Ben Kaduk

Hi Ben,

thank you very much for your insight. This confirmation is a big help 
for me.

Folks,

if any of you knows about any modern-day usage of non-default QOP, 
please let me know. I'm still curious :-)

Thanks,
Tomas