Subject: RE: GSS-API per msg prot negotiation

From: "Linn, John" <[email-masked]>
Date: Fri, 30 Jan 1998 15:53:19 -0500

John Wray wrote, excerpting: 

> Would the following restrictions do what you want:
> 
>     A) If a gssapi mechanism spec allows for optional support of
>        particular QOP values, then either:
> 
>        i) All implementations are required to be capable of
>           processing messages protected using any QOP value,
>           regardless of whether they can apply protection
>           corresponding to that QOP,
> 
>        or
> 
>        ii) The set of mutually-supported receiver QOP values
>            must be determined during context establishment,
>            and messages may be protected by either peer
>            using only QOP values from this mutually-supported
>            set.
> 
>        NOTE: (i) is just a special-case of (ii), where
>              implementations are required to support
>              all QOP values on receipt.
> 
This seems like a clarifying statement which would be useful to be able
to include within 2078bis, probably within the QOP section (1.2.4).  To
consider one mechanism, RFC-1964 would need some changes to align with
(i); of three QOP-selectable integrity algorithms, it states that one
may not be supported by all implementations and the section's text is
silent about support requirements for the other two.  What's the group
sentiment about including the statement and aligning mechanism specs
accordingly?

>     B) A failure of gss_getmic() or gss_wrap() due to an attempt
>        to use an unsupported QOP will not interfere with context
>        validity, nor shall such a failure impact the ability of the
>        application to subsequently invoke gss_getmic() or
>        gss_wrap() using a supported QOP; in particular, any
>        state information concerning sequencing of outgoing
>        messages shall be unchanged by an unsuccesful call
>        of gss_getmic() or gss_wrap().
> 
>        NOTE: should the last clause (after the semilcolon) be
>              true in general - shouldn't any failure of gss_getmic()
>              or gss_wrap() leave sequencing state alone?
> 
I think that discussion in this area would logically fall into 2078bis's
Sec. 1.2.8 (Implementation Robustness).  John's note seems right to me;
what's the group sentiment about including two separate statements: the
clause up to the semicolon, and a separate sentence beginning with the
words "any state information..."?

--jl

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 11 Feb 1998 16:13:37 -0500

From: "Linn, John" <[email-masked]>
   Date: Fri, 30 Jan 1998 15:53:19 -0500

Well, taking one mechanism's implementation in mind (the OpenVision/MIT
Krb5 GSSAPI), we currently meet condition A.i. for the two integrity
algorithms which were not called out as being optional in RFC 1964.  My
interpretation of 1964 was that if it was not called out as optional, it
was mandatory to be able to *receive* tokens sealed with those
algoritms.  However, we do not currently support sending tokens using
anything other than the default algorithm, which is
GSS_KRB5_INTEG_C_QOP_DES_MAC.  

In fact, passing in any QOP other than GSS_C_QOP_DEFAULT causes the
gss_seal() function to return GSS_S_FAILURE with a minor status code of
"unknown qop".  

Arguably this is not ideal, but it's what the current implementation
does.  It wouldn't be hard to improve our implementations QOP support,
though.

						- Ted