Non-default Quality of Protection?
tomas.kuthan at oracle.com
Tue Nov 12 10:54:11 EST 2013
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
thank you very much for your insight. This confirmation is a big help
if any of you knows about any modern-day usage of non-default QOP,
please let me know. I'm still curious :-)
More information about the Kerberos