GSS-API per msg prot negotiation

[Martin Rex <[e-mail]>]

I'm worried about potential side effects when implementing "political"
solutions, specifically in the availability of per-message protection
services.  "Political" requirements are currently inflicted on a significant
fraction of implementors, so explicit statements may be necessary in
some areas to maintain interoperability.


Scenario:
Two components of an application use gssapi to authenticate and
secure their communication and successfully establish a security
context (i.e. both sides get to see GSS_S_COMPLETE from context
establishment).  If one side gets back the availability flag
for confidentiality protection, the other side must get it as well
and the application(s) must be able to use gss_wrap WITH confidentiality
protection to talk to their peer, independent of the combination of
"compliant" but independent implemenations of the same gssapi mechanism. 

The same requirement applies to integrity protection and gss_getmic(),
gss_verifymic().  I think that each of the INTEGRITY, CONFIDENTIALITY,
MUTUAL_AUTH and ANON flags must be consistently returned by both
sides: gss_init_sec_context() and gss_accept_sec_context() in case
of success (GSS_S_COMPLETE).  I'm wondering if that applies also to
REPLAY and SEQUENCE.


Besides being a significant application portability issue for us,  ;-)
I assume it is a severe interoperability issue and as such needs to be
resolved before GSS-API may eventually advance to Draft Standard on the
Internet Standards track.  


More or less obvious mechanism spec and/or implementation issues:

- If a gssapi mechanism spec doesn't mandate confidentiality,
  it must provide a handshake during context establishment so
  that independent implemenations may figure out availability
  of a common confidentiality mechanism.

- If a gssapi mechanism spec doesn't mandate confidentiality,
  a one-way authentication with confidentiality can not meet
  the interoperability requirement.

- If a gssapi mechanism spec mandates confidentiality,
  a one-way authentication with confidentiality would be limited to
  the mandated confidentiality algorithm(s).


On top of that, I think such requirements have to be extended
to QOP values:

- If a gssapi mechanism spec allows optional confidentiality
  or integrity mechanisms to be selected by the application
  by using an explicit QOP parameter, the context establishment
  must provide for negotiation of common QOP values.

- When using an optional QOP value that is known to the local
  gssapi implementation but not by the peer and therefore not
  available for the established security context, the failure
  of the gss_getmic() or gss_wrap() must not interfere with
  the context validity, sequence protection or replay protection
  as provided by the gssapi mechanism.

Talking of QOP values: gss_wrap_size_limit() takes a qop for
input and may return GSS_S_BAD_QOP.  Could we add the statement
that a QOP value accepted by gss_wrap_size_limit() doesn't mean
that this QOP is acutally valid and would be accepted by gss_wrap()?
(I have a layered GSS-API mechanism with a qop-independent wrap_size
 increase where validating the QOP value would be extremely awkward
 due to the layering.)


What is the optional/mandatory status for the Kerberos 5 gssapi mechanism
RFC-1964, mech-OID
     iso(1) member-body(2) United States(840)
                            mit(113554) infosys(1) gssapi(2) krb5(2)

Is per-message integrity protection mandatory-to-implement?
Is per-message confidentiality protection mandatory-to-implement?


I haven't seen any specific requirements concerning these interoperability
issues in both of the GSS-API documents rfc2078bis, C-bindings,
and neither the Kerberos 5 GSS-API mechanism spec rfc1964.


I'm especially interested in implementation practice -- especially
where political solutions are already technical problems today.

-Martin