[OpenAFS] Some questions about the future of OpenAFS

[Douglas E. Engert]

Derek Atkins wrote:
> 
> Doug,
> 
> "Douglas E. Engert" <deengert@anl.gov> writes:
> 
> > So look at the separation of the authentication from the token
> > generation as a way to give you, the OpenAFS developer, more
> > flexibility in designing the next generation of the AFS
> > token. Tokens don't have to continue to be Kerberos tickets, as they
> > are used internally only by AFS.
> >
> > This also allows the AFS cell to accept authentication by multiple
> > means. The current klog and kaserver, the krb524d route, the K5
> > GSSAPI and the GSI. Other could also be added too. Thus the AFS cell
> > can be thought of separately from a Kerberos realm. The cell then
> > represents the common set of servers which use the same
> > authorization data base.
> 
> I don't particularly like this view.  The reason I don't like it is
> that it views an AFS Cell as a coherent unit. I don't agree with that
> view -- I see an AFS Cell as a collection of different servers that
> collaborate to provide a file system.  What I'd like to see is the
> client authenticate to _each server_ independently.

This is sounding like DFS, where you needed a ticket for each 
file server. We tried DCE and DFS, when Transarc said DFS would replace AFS.
but it never really worked well.
   
The beauty of AFS is its simplicity. I like the coherent unit concept, it 
keeps it simple. You could always have multiple cells. The question is then
what do you gain by having to authenticte to different servers in the same 
cell? If you are going to try and base some authorization decision on this,
i.e. some users can only authenticte to some servers, the complexity goes
up very fast. (Another way to maybe achieve this is multiple cells.)

> 
> The problem with this view is that it makes an assumption about the
> AFS token -- in particular, it assumes that the AFS client token can
> be used to obtain individual tokens for each AFS server.  In other
> words, your client token is effectively a TGT that is used to obtain
> service tickets for each AFS server you contact.
>

Thats still OK. As AFS will be handling this internally. I just want to get
the initial token using other authentiction methods.   
 
> Unfortunately this means that the AFS Token is even _more_ tightly
> bound into Kerberos, as opposed to less-tightly bound as you are
> proposing.

What's in the token is up to you, the AFS developer. If it is a k5 ticket,
we will still use it. But try not to equate an AFS cell with a Kerberos 
realm. 

The Kerberos realm is for authentication. The AFS cell is for access to a common
file system and includes authorization information as well. They don't have 
to match. You should be able to have multiple cells accept authentication 
from multiple realms, and authentication for other sources too. 

The first approach we used to authenticating to AFS using GSI was via SSLK5, which
used a modified K5 KDC which understood SSL and the X509 certificates to return
a K5 TGT. This was then used like any other K5 TGT to get the K4 ticket via
krb524 and ak5log. The SSLK5 is functionally equivalent to PKINIT, i.e. Use X509
certificate for preauthenticiton. But this then required a K5 realm
be setup. (It worked with DCE/DFS too. 

As I pointed out in one of these notes, people have Globus at some sites which
have AFS but they are not willing to put up Kerberos 5. If the Kerberos was built
into the AFS they would most likely convert, but would still want to use GSI 
authentication. We would then use PKINIT or the SSLK5. 
 
> 
> -derek
> 
> --
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord@MIT.EDU                        PGP key available

-- 

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