rxgk GSSNegotiate errorcode field (was Re: [AFS3-std] Re: afs3-rxgk-updates for 03)

[Benjamin Kaduk]

On Mon, 29 Oct 2012, Jeffrey Hutzelman wrote:

> On Mon, 2012-10-29 at 16:57 -0500, Andrew Deason wrote:
>
>>> commit c23fc51c268fefc460b224a12b63cd9a9672b538
>>> Author: Ben Kaduk <kaduk@mit.edu>
>>> Date:   Wed Oct 24 23:21:29 2012 -0400
>>>
>>>     Describe the GSSNegotiate errorcode field
>>
>> I wasn't quite sure on what kind of errors are expected here. If they
>> are what you wrote in this commit, then I think it makes sense to make
>> this application-specific, and in rxgk-afs we specify a registry to
>> specify values (or if we want to keep it implementation-private or
>> something, that's an option, too).
>>
>> But if this is intended to contain GSS error codes... aren't those
>> standard? (and don't we need more than one 4-byte int for that?)
>
> GSS-API major status codes are standardized at the abstract API layer as
> integers, but without specific values.  The actual integer values used
> depend on the language bindings; for C they are specified in RFC2744,
> but for other programming languages the values might be different.
>
> GSS-API minor status codes are not standardized; they are specific to
> the mechanism and implementation.
>
> So, you can't depend on doing anything programmatic with GSS-API status
> codes you receive from a peer.  However, it turns out that in practice,
> the status codes (or better yet, the set of status strings returned by
> GSS_Display_status) can be very useful in troubleshooting.

This field is explicitly *not* a GSS error code, if I understand 
correctly.  It is embedded within te RXGK_ClientInfo struct, which is 
returned to the client in the rxgk_info (out) parameter of GSSNegotiate(). 
The value of the rxgk_info field is undefined if the gss_major_status 
(out) parameter of GSSNegotiate() is not equal to GSS_S_COMPLETE.
So, the GSS error codes would all be in gss_major_status and 
gss_minor_status -- the errrorcode field of RXGK_ClientInfo is for policy 
errors.  It was remarked (I don't remember by whom offhand) that we should 
give some guidance for what values might be seen in this field; my 
interpretation of it as policy errors is that the policy is 
application-specific.  Even so, it seems appropriate to give some sense 
for what conditions applications might consider to be policy errors.

I am not strongly tied to this text, or even to having the errorcode field 
be defined to hold application-specific values.  If someone wants to 
advocate having a registry for these values established in this document, 
we can talk about that, but policy does feel application-specific to me.

-Ben