On Mon, Jan 4, 2010 at 4:10 PM, Simon Wilkinson <[email protected]> wrote: > > 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
Only if it wishes to manipulate them. > *) 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 flipside is doing it this way allows a server to manage mappings it has no way to itself generate, as opposed to requiring upgrades later for new mappings. I'd like to hear other thoughts on this. > 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? Again, if anyone knows otherwise, speak up. >> 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. It does disallow it, the issue is what happens for cases where there is no defined single canonicalization? I it reasonable to disallow this only in those cases? >> 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" That'd be my suggestion >> 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? Yes. I can fix this phrasing. >> 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? fallback assumes implicit mappings where no explicit mappings exist for old-style (current rxkad) principals. The goal would be for the fileserver to fall back, thus not needing to switch to a different call if the first returns a no mapping error. This could be split into 2 RPCs. > Cheers, > Simon. > -- Derrick _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
