On Feb 10, 2015, at 3:35 PM, Sam Hartman <[log in to unmask]> wrote:
> 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.

 That makes sense.

> Thoughts on this approach?

  It’s reasonable.

> Alan, is error-cause the right thing to be using here?

  Yes.

> 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?

  Just populate Error-Cause directly.

  We should also update the Post-Auth-Type Reject filter to *not* remove Error-Cause…. done.  I’ve pushed a fix for Access-Reject and Accounting-Response.

  Hmm.. on  a quick scan of the RFCs, I don’t see an explicit statement that it’s allowed in Access-Reject.  RFC 3580 implies that, but doesn’t say that explicitly.

  Anyways… Error-Cause in an Access-Reject is OK by me.  It’s something to use carefully, to avoid information leakage.  But it’s a good idea for TR.