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

[Jeffrey Hutzelman]

--On Thursday, August 26, 2010 04:14:31 PM +0100 Simon Wilkinson 
<simon@sxw.org.uk> wrote:

>
> On 25 Aug 2010, at 03:38, Derrick Brashear wrote:
>
>> On Tue, Aug 24, 2010 at 3:33 PM, Jeffrey Hutzelman <jhutz@cmu.edu> wrote:
>>>
>>>
>>> since in practice Kerberos V5 is the _only_ mechanism currently
>>> supported
>
> I believe that at approximately the point that OpenAFS deploys
> authentication name mapping, we'll also be supporting X509 and SCRAM in
> addition to Kerberos. I suspect we'll see a requirement for supporting
> Moonshot names pretty soon too, providing that gets off the ground. Any
> solution that assumes that we're primarily dealing with Kerberos v5 names
> is inherently flawed, in my book.

You are quoting me out of context.  I was not proposing a solution that 
makes any such assumption.  Rather, I was saying that a model in which the 
ptserver stores a single alias and presents it to users and administrators 
as both raw-krb5 and gss-krb5 is likely to be confusing in deployments 
where krb5 is the only mechanism in use, and result in unnecessary and 
misleading bug reports.  This is because deleting the raw-krb5 alias will 
result in also deleting the gss-krb5 alias (or vice versa), and in 
deployments where krb5 is the only mechanism, that will be 
indistinguishable to users from "BUG: deleting one alias makes them all go 
away".

Using krb5 as the only mechanism is likely to be the most common deployment 
for a long time.  Any solution that ignores that and creates additional 
pain for that most-common case is _also_ fatally flawed.

That said, this is really a side discussion; the issue at hand is not how 
the ptserver should simulaneously manage and represent raw-krb5 and 
gss-krb5 names, but whether it should do so at all.



>>> As it stands, the onus to convert is on implementations of
>>> authentication mechanisms using GSS-krb5.  Would it make people happier
>>> if we were to eliminate the Kerberos V5 name type and require Kerberos
>>> V5 names to always be represented as GSS export tokens?  That would
>>> place the onus of conversion on things (rxkad, not mech-independent
>>> server code) that accept raw Kerberos V5 authentication.
>>
>> I can't speak for the objector. I believe that doing so would be
>> entirely reasonable.
>
> I am not convinced. It sounds to me like you are moving the onus for
> conversion from the ptserver to requiring every fileserver (or every
> client) to perform the conversion steps when using rxk5 or rxkad
> identities. It seems so much cleaner to keep this knowledge in one place
> - and the ptserver is the obvious location for this to exist.

The onus for conversion has _never_ been in the ptserver.  I prefer to 
concentrate mechanism-specific knowledge in as few places and as little 
code as possible.  Servers which accept authentication using a given 
mechanism _must_ have mechanism-specific knowledge, because they are 
implementing the mechanism.  The ptserver is in the same boat; it needs 
mechanism-specific knowledge of the mechanisms it accepts for 
authentication of the PR service.  In both cases, this mechanism-specific 
knowledge can and should be confined to the rx security class which 
implements it, and, for GSS-API mechanisms, to the GSS-API mechanism 
implementation.


I'm agreeing with you here that requiring rxgk to do something special with 
the Kerberos V5 name type that it does not do with other GSS-API mechanisms 
is an abstraction violation that puts GSS-mechanism-specific knowledge into 
code that should be GSS-mechanism-independent.  However, putting that 
knowledge into the implementation of the PR service RPC's is _also_ an 
abstraction violation, and worse, it breaks the modularity of the 
distributed system, requiring me to upgrade my ptservers to recognize a new 
name type before I can use those names _anywhere_ in the system.  I am 
reminded of Kerberos client implementations which refuse to use a ticket 
encrypted with a service key whose enctype they do not recognize.

What I offer as an alternative is that mechanism-specific knowledge about 
the format of raw-krb5 be confined to the implementations of those rx 
security classes which use it; namely, rxkad and rxk5.  These will already 
require changes to support what I hope will end up being a common, 
class-independent API to allow server application code to obtain the 
client's authentication name, to be used in place of rxkad_GetServerInfo. 
At least rxkad will already require code changes to report a krb5 principal 
name as a single string, rather than performing the lossy krb5-to-krb4 name 
conversion it does today.  All I propose is that instead of merely 
returning a string, it return an opaque name in the same form as would be 
used by gss-krb5.

Specifically, I propose deleting the Kerberos V5 name type entirely, and 
instead requiring that mechanisms based on Kerberos V5 (currently, rxkad 
and rxk5) represent names as for the GSSAPI name type with the Kerberos V5 
mechanism.  We can describe how to do this; it's really quite simple:

- Prepare a string in the syntax we were going to use anyway, which is
  that described in RFC1964 2.1.1 with the constraints from 2.1.3.
- Use that name directly for the display name
- For the canonical/opaque name, prefix the string with the following
  sequence of octets:
  04 01 00 0B 06 09 2A 86 48 86 F7 12 01 02 02 hx xx xx xl
  where 'hx xx xx xl' is the length of the string, in octets,
  represented as a network-order 32-bit integer.

Yes, this means the conversion is done in every server that accepts those 
mechanisms.  But it is done in the mechanism, as part of producing the 
generic name token, and it is always done in the same way.  The important 
thing here is that we're not doing a subjective, lossy "translation" as is 
currently done in rxkad to convert krb5 names into krb4 names; we're merely 
making a minor and completely reversible change in the representation of 
the name.

-- Jeff