Jeffrey Hutzelman wrote:
On Wednesday, September 22, 2004 15:14:36 -0500 "Douglas E. Engert" <[EMAIL PROTECTED]> wrote:
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, so I looked at the CVS and see that rkgk has been in the source for 6 weeks. and the gssapi usage is still to be defined. From the README:
- GSS-API to rxgk authenticator RPCs
To be later specified.
But it looks like it is header in the right direction.
OK maybe I should. But let me ask you how much of a gss will you need in the kernel
None.
good. that will keep it simple and fast.
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.
Its not a third party. See below on the "lying" comments.
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.
GOOD. So this is what I have been looking for. Its the akog or gssklog of the future. What you called below "just-get-a-token-for-the-cache-manager". It does the inital authenticaiton, and gets back a token.
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.
Not nessesarialy, as it might not be able to be "done in advance by a separate user-mode process" without knowledge of what are all the servers.
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.
Sounds good to me. I have no problems with using this for more then AFS.
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.
Maybe that was the intent, but pratically when the capabilities are not provided by the two technoligies, one has to adapt.
Even in the rxgk README file it says:
171 exported auth name 172 173 all mech's need to have a rxgk name to krb4 name function 174 until pts is changed to support rxgk names.
This then goes along with how are gssapi names supported or mapped by the PTS.
We are working on different schedules here. I am talking today, you are talking future.
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.
We are talking the same thing here. I would consider the gssklogd for example to be part of AFS, under control of the AFS admin issuing tokens to be used by AFS. I would be glad to see it replaced with something more integrated that used rxgk and gssapi.
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.
Good. The rxgk looks very promising.
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.
I am living is a the real world of systems that don't understand global name spaces, like most unix systems. They still have uid and short names for local users. Mapping of identies is done all the time. Having the local UID nad username match the AFS UID and username is just another mapping to keep the user happy.
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.
Its not a question of "lying" That implies that that there is some some question of the trust relationship between the fileserver and the mapping server. All the mapping that has been done so far are under the control of the AFS cell admins, and is part of AFS. Maybe not from the AFS developer's point of view, but it is from the administrator's and user's view. For a trust relationship its not a third party.
You are arguing that the final server needs to do the mapping, I am arguing that it can be done before and put into the token. I believe that it is more of a implementation/performance issue then a security issue.
-- Jeff
--
Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
