You should read about how rxgk actually works. Yes, you can do Kerberos and just use the session key. But in the long term the intended usage is to use GSS to sign a key exchange.
OK maybe I should. But let me ask you how much of a gss will you need in the kernel
None.
or are you proposing some helper process that does the gssapi for the kernel.
No.
How often will you haqve to use that gssapi, I would propose only when getting a token. Hopefully not for any other AFS transactions.
rxgk is not GSSAPI. rxgk is an Rx security class, which provides encryption and integrity protection for Rx connections. This is accomplished through the use of Kerberos enctypes (note this is a non-Kerberos use of the crypto draft, and in fact is one of the reasons that there is a strong modular boundary between kcrypto and Kerberos itself). There is a per-connection key which is negotiated between the client and server, with the negotiation being protected by a longer-term key which serves a similar role to a Kerberos session key (note this is _not_ the same role served by the key in an rxkad token -- _that_ key is used to protect the connection directly, and is reused for every connection made with that token).
The rxgk "token" is the result of an authenticated key exchange between the client and server. This exchange is done using a special rx service which is provided by every server which implements rxgk (it's actually in the library). So, every rx service (not just AFS, dammit!) which supports rxgk contains everything needed for a client to authenticate to it. And the application server gets to know the client's real authentication name, not the result of some mapping performed by a third party.
The authentication exchange can be done by the client when a connection is established, but the resulting token can be reused for additional connections with the same server. This reusability means the exchange can also be done in advance by a separate user-mode process, and the resulting token handed to the kernel - just as is done today.
In the case of AFS, it is expected that initially the same token will be usable with all servers in a cell, as is the case today. I hope that someday we will be able to move to a model where fileservers can have individual keys, but that issue is separate from and orthogonal to the current discussion.
In case I haven't made it clear -- AFS cells are not the only Rx services. I dislike any approach that requires me to design, implement, and run a magic "mapping server" for each and every Rx-based service. A large part of the point of rxgk was to introduce support for decent encryption and advanced features, allowing rx to be authenticated using any mechanism without requiring magic separate tools.
The purpose of aklog is not and never EVER EVER has been to "translate" tickets into a form that rxkad can use. User-mode applications can AND SHOULD use Kerberos tickets or other authentication mechanisms directly. IMHO it is important that this continue to be the case, not only for the cache manager but also for user-mode AFS tools and for non-AFS services like adm, stage, and others.
This requires that every client be able to perform all steps of the exchange, rather than retrieving a "token" someone else has prepared for them. It requires that clients be able to determine who to talk to to conduct the exchange, which is simplest when it is the same as the server you are trying to authenticate to. And it requires that rx application servers get to find out the client's actual identity, rather than relying on an external "mapping service" which hides the identity from them. If the server wants to map the client's authentication identity onto something else, then the server can perform that mapping or contact a service that does so. It should not be done beforehand by a client that has to guess what the server wants and which mapping service to talk to, and it should not be done in a fashion that changes the client's identity in his authentication credentials.
The pratical approach was to map ahead, as it required no change to AFS.
It was fine for a quick hack for your AFS cell. It confuses clients who have to figure out what mapping service to talk to. It conflates authentication and authorization, which is usually a bad idea. And it doesn't do anything for non-AFS services, where the client doesn't know about your funny mapping service.
But maybe we are getting somewhere here. A single service could be fine but what do you do with x509 names as identies?
You give them to the rx application service and let it decide what to do with them. You tag them with an appropriate type, of course.
What is an AFS token? It has been a kerberos ticket, as it was small and had every thing you needed.
Well, if by everything you mean "except for a name that is not a Kerberos principal name, or a non-DES session key".
What if the authentication method is not Kerberos but some other gssapi? Do you generate a token that looks like a Kerberos ticket?
No. You never generate a token that looks like a Kerberos ticket. You generate a token that looks like an rxgk token.
How far into AFS do you go with using the authetication methods gssapi?
No further than the rxgk library, and whatever tool you use to do just-get-a-token-for-the-cache-manager.
That means that anything can use rxgk, not just AFS.
But some other issues include what does ls -l show for a file owner? the current AFS user and uid is nice, but what if the authenticaiton name was a X509 certificate? What do you show for cross realm/foreign users? Do you start using UUIDs and UUIDs for a user's realm?
You are living in a strange alternate universe.
Unless you are using a specially-modified ls, you get the AFS uid and whatever username that maps to in /etc/passwd or whatever nss mech you are using. You would, of course, continue to get that.
In response to your real question, AFS users continue to have names by which users and administrators refer to them. These are the names of PTS entries, but they are not the names used for authentication. The _fileserver_ knows a user by his vice ID, which it gets by asking the ptserver to look up the authentication ID -- just like today, except you stop lying to the fileserver about the user's authentication ID, because it stops being necessary to do so.
-- Jeff _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
