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

[Douglas E. Engert]

Let me make this clear. I am trying to be practical here. Jeff's
original note was questioning people on did they really need mapping.
and so far some sites have spoke up. So I brought up the gssklog  which
was a practical solution to using another authentication system with AFS
without having to modify AFS. It required mapping X509 subject names
which did not sit well with the PTS.


Jeffrey Hutzelman wrote:

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

OK maybe I should. But let me ask you how much of a gss will you need in
the kernel, or are you proposing some helper process that does the
gssapi for the kernel.  How often will you haqve to use that gssapi,
I would propose only when getting a token. Hopefully not for any
other AFS transactions.

> 
> 
>> 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.
>

I did not say that. It does not have to be single des and does not have to be
a krb5 principal. You may be to hung up on how simple a concept the
gssklog was. Today it does generate a k4 ticket, with a des key, as that
was all AFS supported when I first wrote it, but there is no reason it could
not generate a k5 ticket instead with whatever key types the AFS servers can use.


> 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.

The pratical approach was to map ahead, as it required no change to AFS.

But maybe we are getting somewhere here. A single service could be fine
but what do you do with x509 names as identies?

What is an AFS token? It has been a kerberos ticket, as it was small
and had every thing you needed. What if the authentication method is
not Kerberos but some other gssapi? Do you generate a token that looks
like a Kerberos ticket? How far into AFS do you go with using the
authetication methods gssapi?

I am proposing that the authentication be done up front, and a token
issued for use with the AFS protocols. If some of the PTS mappings could
be moved to it that  would be OK. There is nothing to say the seperate
service could not use the PTS database or some single database.

But what does this mean for using a K5 ticket directly from some KDC
as a token without any additional mappings? THis was the original notes
problem, that it was assuming it was easy to do.

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?

> 
> -- Jeff
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444