--On Thursday, August 26, 2010 04:14:31 PM +0100 Simon Wilkinson
<[email protected]> wrote:
On 25 Aug 2010, at 03:38, Derrick Brashear wrote:
On Tue, Aug 24, 2010 at 3:33 PM, Jeffrey Hutzelman <[email protected]> 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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
