On Wednesday, September 22, 2004 10:54:32 -0500 "Douglas E. Engert" <[EMAIL PROTECTED]> wrote:
You mentioned using an arbitrary gssapi with RX.
No; I mentioned using arbitrary GSS mechanisms to authenticate rxgk.
If you use this approach vs a mapping service, you will need to support the arbitrary gssapi in the client's kernel as well as all the services.
No.
An arbitrary gssapi may not give you access to the session keys, but require you to use gs_wrap/unwrap whihc might be more overhead then you want.
No.
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.
Only the initial token issuing mapping service need to be aware of the gssapi issues introduced with arbitrary GSSAPI.
You're still stuck in the old world, where you have to bash everything into something that has a single-DES key and a name that looks something like a krb4 principal.
We're trying to design the new world, in which you do native authentication and a service that administrators can actually manage (like the ptserver) maintains a set of arbitrary mappings between authentication identities and vice ID's. It doesn't have to be the ptserver; it could be a separate service, but it seems silly to have a double-mapping where you first start with an authentication-mechanism-specific service that maps things to a name, and then remap the name to the identity you actually care about. That's going backwards.
-- Jeff _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
