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

[Derrick Brashear]

On Mon, Jan 4, 2010 at 4:10 PM, Simon Wilkinson <simon@sxw.org.uk> 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 GSS=
API
> names before making calls. I think there are a number of issues with this
> design
> =A0*) It builds in specific Kerberos 5 knowledge to generic GSSAPI client=
s. It
> is my hope that rxgk clients will be able to be completely generic, so th=
eir
> mechanism support can be changed by altering the GSSAPI libraries at link
> time. I would really rather not embed any mechanism specific knowledge in=
to
> these clients
> =A0*) 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 y=
ou
> know it there's a huge tangled web of mappings that every client has to b=
e
> aware of

Only if it wishes to manipulate them.

> =A0*) Client based knowledge is hugely difficult to upgrade. If this mapp=
ing
> must be performed, then doing it on the servers hugely simplifies the tas=
k
> of maintaining it.
> =A0*) 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, t=
o
> simply require those sites to add both rxk5 and rxgk names to their pts
> database, than force every available client to have hardcoded mapping rul=
es.

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 GSSAP=
I
> 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 map=
ping
>> 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 clar=
ify
> on what the use cases for this are? I wonder if it might be cleaner to ha=
ve
> 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.
>



--=20
Derrick