We're working on improving Moonshot's error handling and debugability.
Today, all you typically get at the client is authentication rejected,
and at the server is access reject.

We've had some discussion on-list in the last week of the errors we'd
like to distinguish.

I'd like to discuss our mechanisms for doing that.

On the server, we return an error using gss_display_status.  A few years
ago Kerberos introduced the convention that the message you get back
from gss_display_status can be dynamic.  You pass in a major and minor
code, but the resulting message, especially for minor codes is not
constant.  It may depend on the circumstances of the most recent error.
There are facilities in mech_eap for manipulating this.

We already do a reasonably good job of mapping libradsec errors into
moonshot errors and recovering the libradsec error message.

So, on the server, we can return a fairly dynamic error message.

I'm proposing that we first look to see if an access-reject has an
error-cause attribute.  That was defined in the COA spec, but based on
some of the registered values, its usage seems to be more common.

The main value from Error-Cause I want to retrieve are values related to
proxy failures, particularly including the proxy routing failure code.  

If Error-cause is not present, or perhaps possibly even if it is, we
look for reply-message.  If there's EAP, that won't be present, but if
things have failed so hard that the EAP was not processed, we can get a
reply-message.

Between the client and acceptor we have a more limited interface.  The
ABFAB error token contains a major status and a minor status as an
unsigned 32-bit integer limited to the values 0-255 (see section 5.3 and
7.6 of RFC 7055)

We will not be able to communicate out reply-message, but we will be
able to parse out error cause codes and turn these into meaningful
GSS-EAP errors.

Then, we propose to write and send patches to FreeRADIUS to update the
trust router code and ABFAB policy.  We propose to populate reply
message with trust router errors where appropriate and to generate
error-cause from the more interesting trust router errors.  In
particular we'll generate a proxy routing error when we fail to find a
trust path.

We also want to generate an error-cause when the IDP rejects for
authorization reasons.

Thoughts on this approach?
Alan, is error-cause the right thing to be using here?
Typically the TR code returns noop or notfound rather than reject
directly when a mapping isn't found.  Should we define another internal
attribute and populate error-cause when we turn that into a reject in
unlang, or should we populate error-cause from the TR code directly?

--Sam