[OpenAFS-devel] Anyone supporting multiple realms in a "all realms are equal" type of setup?

[Jeffrey Hutzelman]

On Wednesday, September 22, 2004 15:14:36 -0500 "Douglas E. Engert" 
<deengert@anl.gov> 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 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