Subject: RE: RPCSEC_GSS interop wrt minor status codes

From: "wurzl, mario" <[email-masked]>
Date: Tue, 5 Nov 2002 09:07:58 -0500

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Monday, November 04, 2002 18:49
> To: [email-masked]
> Subject: RPCSEC_GSS interop wrt minor status codes
> 
> 
> While researching some GSS-API features/issues I ran into a problem
> with RPCSEC_GSS interoperability.
> 
> Facts:
> 
>  - RFC2203 (RPCSEC_GSS), section 5.2.3.1 says that when the server's
>    gss_accept_sec_context() returns an error then the server must
>    (lower-case) send a NULL handle *and* token in the response to the
>    client
> 
>  - The GSS-API RFCs imply, but do not explicitly state, that
>    gss_accept_sec_context() CAN produce an output token even if its
>    major status is an error
> 
>  - RFC1964 (the Kerberos GSS mechanism spec) explicitly allows for
>    KRB-ERROR as Kerberos mech GSS token
> 
>  - RFC1964 defines symbolic names for Kerberos mech GSS minor status
>    codes, but NOT integers (i.e., there no standard wire 
> representation
>    of Kerberos GSS mech minor status codes other than the error token
>    defined in RFC1964, a KRB-ERROR wrapped with a GSS header).
> 
>    Note that the error code in the KRB-ERROR is NOT the same as the
>    minor code produced by gss_accept_sec_context(), not in the case of
>    MIT krb5 and implementations derived from it.
> 
> Problem:
> 
>  - There is no interoperable way to communicate minor status 
> codes from
>    the Kerberos GSS mechanism in RPCSEC_GSS.
> 
>    There is one specific error condition that effectively cannot be
>    communicated interoperably: when the initiator refers to 
> the acceptor
>    by an incorrect name (e.g., host/foo instead of nfs/foo). 
> There is no
>    GSS major error for such a condition; there is a Kerberos 
> error code
>    for this (KRB_AP_ERR_NOT_US), but it can't be communicated
>    interoperably in the context of RPCSEC_GSS (see above).
> 
> 
> Solution 0: Do nothing. The client will know that there was 
> an error and
>             will know the major error code, but won't 
> reliably know the
> 	    minor code, so the user will have less info to go on, but
> 	    hey, they can live with this, right?
> 
> Solution 1: Modify RPCSEC_GSS to allow non-null GSS tokens in error
>             responses from the server's gss_accept_sec_context(). Does
> 	    not affect wire representation. Clients may or may not like
> 	    this but it doesn't matter as errors are final. It is
> 	    possible that some clients may leak memory (or even crash?)
> 	    if this is done.
> 
> Solution 2: Standardize integer values for the minor status code
>             symbolic names listed in RFC1964.
> 
> Solution (2) is a poor alternative to solution (1), though it may be
> independently desirable.
>
The numeric values for the minor code symbolic names are defined in MIT's
implementation
in files gssapi_err_generic.h and gssapi_err_krb5.h
Although there are other implementations of the Kerberos protocol, the MIT
implementation
is the "de facto" reference implementation.
> 
> It may be worth testing client behaviour w/ solution (1) at the
> Connectathon.
> 
> Cheers,
> 
> Nico
> -- 
>

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 5 Nov 2002 08:39:20 -0600

> is the "de facto" reference implementation.

Those header files are not exported (i.e., installed) by MIT krb5. Those
integer values are strictly internal to MIT's implementation. As such
they are conceivably subject to change.

Vendors with non-MIT-derived GSS/Kerberos code bases might not be happy
to go along.

Even standardizing numeric values for RFC1964 minor status values would
require an update to RFC2203 or a separate draft RFC - either way a
modification of RPCSEC_GSS is needed to address the problem. The
simplest RPCSEC_GSS mod is to allow the server to send back gss error
tokens.

In any case, RPCSEC_GSS implementors should make sure that their clients
don't leak or crash when the server includes a non-null gss_token in an
rpc_gss_init_res whose gss_major is not GSS_S_COMPLETE or
GSS_S_CONTINUE_NEEDED.

Cheers,

Nico
--

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 5 Nov 2002 09:44:00 -0500

> is the "de facto" reference implementation.

We ought to get these into some RFC somehow, even if it is only 
Informational.
Maybe this could reasonably be taken up within the Kerberos WG ?

Ran

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 5 Nov 2002 10:03:50 -0600

The KRB-WG would, indeed, be the appropriate WG to take up
standardization of Kerberos mechanism minor codes. BUT, expect
opposition at the KRB-WG; if nothing else its plate appears to be full
at this time.

RFC2203 violates the GSS-API abstraction by not allowing error gss
tokens and by sending GSS status codes on the wire.

Standardizing numeric mappings for RFC1964 minor numbers would not
change the fact that GSS-API abstractions are being violated by RFC2203.

The abstractions violated are:

 - GSS status codes are API concepts - they are not intended to be used
   on the wire. This abstraction cannot be easily changed without
   introducing a status code mapping API for what is an appropriate
   minor code on the acceptor side may not be an appropriate code on the
   initiator side. Introducing such a status code mapping API to GSS-API
   would necessarily require that RPCSEC_GSS be modified to specify its
   use.

   In GSS-API this mapping is done through the mech-specific error
   tokens, so that in an error condition there may be three different
   sets of error codes: the status codes produced on the acceptor side,
   mech-specific codes in the mech-speicifc error token and the status
   codes produced on the initiator side when processing error tokens.

 - GSS_Accept_sec_context() can produce output tokens even if there is a
   final error - the acceptor is expected to send such tokens in order
   to indicate the error condition to the initiator.

The former abstraction is violated as a result of violating the latter.

Consider the case where an RPCSEC_GSS client uses the wrong name for the
server: the status code on the acceptor side should indicate that the
wrong credential was used (the server may have multiple credentials -
think HA), but on the initiator side the status code should indicate
that the wrong acceptor target name was used. We cannot implement such
semantics merely by standardizing RFC1964 minor status codes; we have to
allow the server to send gss error tokens or we need GSS-API extensions.

Unless there is a significant negative impact to allowing RPCSEC_GSS
servers to return non-null gss error tokens (I believe there is not)
then we should fix RPCSEC_GSS to stop violating the GSS-API
abstractions.

Can this RPCSEC_GSS problem be fixed by separate RFC without requiring a
new RPCSEC_GSS RFC be drafted?

Cheers,

Nico
--