Subject: GSS-API per msg prot negotiation

From: Martin Rex <[email-masked]>
Date: Thu, 15 Jan 1998 17:04:32 +0100 (MEZ)

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

---

From: [email-masked]
Date: Tue, 20 Jan 1998 11:02:00 -0500

Martin writes (regarding requiring that both ends of a

>  the mandated confidentiality algorithm(s).

The latter two issues aren't quite correct - one-way authentication
is a service, and is what you get when you don't set the MUTUAL_REQ
bit to GSS_INIT_SEC_CONTEXT; it doesn't necessarily map to a single
message, but can be implemented as a series of messages between
initiator and acceptor.  So the above should read something like:

- If a gssapi mechanism spec doesn't mandate confidentiality,
  a single-message context establishment can not provide
  interoperable confidentiality.

- If a gssapi mechanism spec mandates confidentiality,
  a single-message context establishment exchange would be limited to
  the mandated confidentiality algorithm(s).

>  as provided by the gssapi mechanism.

I think I understand the above, but the wording is confusing (for
a start, "confidentiality/integrity mechanisms" haven't been defined,
and I can't think of a clear concise definition that captures what I
think you're after). 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.

    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?

John (note my new E-mail address)