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 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
