[AFS3-std] Re: PTS authentication name mapping draft, second call for review

[Simon Wilkinson]

On 4 Jan 2010, at 15:25, Derrick Brashear wrote:

> Third call for review; I'm gonna ask for a last call later in the
> month as so far all review comment has been incorporated, unless
> something comes up.

Firstly, apologies for not finding the time to review this before now.  
I'm primarily going through this with my rxgk hat on...

I think generally the document is fine. I have one major issue, and  
some minor niggles:

The major issue is with section 11.4, Authentication Name Type  
rewriting. I really don't like the idea of requiring clients to  
rewrite particular GSSAPI names before making calls. I think there are  
a number of issues with this design
   *) It builds in specific Kerberos 5 knowledge to generic GSSAPI  
clients. It is my hope that rxgk clients will be able to be completely  
generic, so their mechanism support can be changed by altering the  
GSSAPI libraries at link time. I would really rather not embed any  
mechanism specific knowledge into these clients
   *) It isn't particularly extensible, because we have no change  
control over GSSAPI. What happens if (unlikely) a Kerberos 4 GSSAPI  
mechanism is standardised? What happens if we add an explicit X509  
mechanism? Before you know it there's a huge tangled web of mappings  
that every client has to be aware of
   *) Client based knowledge is hugely difficult to upgrade. If this  
mapping must be performed, then doing it on the servers hugely  
simplifies the task of maintaining it.
   *) It adds specific mappings to a very rare situation. The  
likelihood of sites running both Kerberos v5 and GSSAPI authentication  
mechanisms concurrently is very small. It would seem far better, in  
the long term, to simply require those sites to add both rxk5 and rxgk  
names to their pts database, than force every available client to have  
hardcoded mapping rules.

The minor niggles are:

 > 8.1. New Data Types
 > #define AUTHDATAMAX 1024

Are we happy that all raw authentication names will be less than 1k in  
length?
 > If a display portion is not provided, the data portion MUST NOT be  
used for user display purposes.
It would seem acceptable for a GSSAPI caller, with knowledge of the  
GSSAPI mechanism, to import the name contained in data, and generate  
its own display name from this. I think the language here disallows  
that though, so it should perhaps be modified.
 > 8.3. GetCapabilities RPC
 > It is proposed that the first 32 bits be allocated to capabilities  
flags, while the remainder be reserved for future standardisation.
I'm a little nervous about what happens to the remaining 195 bytes  
here - in particular if they end up being used for adhoc marshalled  
structures. But I guess that's a point that can be argued during  
"future standardisation"
 > 8.4. Authentication name mapping RPCs
 > In addition to the general-purpose RPC needed to represent this  
extended functionality, a complying server will include RPCs to  
represent the mapping of extended names to AFS IDs.
It's not clear to me what you mean by this paragraph. Is the "general- 
purpose RPC" the GetCapabilities one?
 > 8.4.1. AuthNameToID
The "fallback" parameter to this RPC seems rather inelegant. Can you  
clarify on what the use cases for this are? I wonder if it might be  
cleaner to have different RPCs for the different modes?
Cheers,
Simon.