Non-default Quality of Protection?

[Benjamin Kaduk]

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