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

[Jeffrey Hutzelman]

--On Monday, January 04, 2010 04:22:49 PM -0500 Derrick Brashear 
<shadow@gmail.com> wrote:

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

That's a good question.  It's probably sufficient for now, but may not be 
forever.  On the other hand, this is the length limit on an opaque<>, which 
means we can increase it later, if we're careful about it.


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

I believe the intent was that the raw form not be displayed directly, 
because it is unlikely to be human-readable.  If a display form is not 
provided (i.e. is empty) but the implementation understands the auth type 
in question, then it should be fine to use an auth-type-specific conversion 
mechanism to produce something for display.  However, it is _not_ fine to 
do the reverse -- the display form should never be used to derive something 
used in making a security decision.



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

Yes, I think that's best.

-- Jeff