[OpenAFS] home on afs woes

[Jeffrey Hutzelman]

On Wednesday, January 04, 2006 05:31:15 PM -0600 "Douglas E. Engert" 
<deengert@anl.gov> wrote:

> Exactly where in the PAM stack do you want
>> to obtain (and, if need be, discard) this extra token? pam_open_session()
>
> I am not sure. It has to be after the GSSAPI or pam_authenticate has a TGT
> (which could have been via keyboard interactive or at the console) but
> before
> the krb5_kuserok is called.

You don't want to use the forwarded ticket for this, or one that was 
obtained by pam_authenticate.  Those are tickets for which the client 
(read: attacker) knows the session key, and thus can spoof the server and 
give you back a false .klogin file.

Access to the klogin file must in some way be protected by a key which the 
potential attacker does not and cannot know.


In AFS, the intended mechanism for this is a feature of rxgk that will 
allow the cache manager to combine users' credentials with its own in such 
a way that traffic is protected by a key which is tied to the user's 
identity but is known only to the cache manager.  One side effect of the 
technique used to achieve this is that the cache manager will be able to 
protect _all_ communication with the fileserver, even when done on behalf 
of unauthenticated users.

Another is that, if we choose to implement the feature, the fileserver will 
be able to make access control decisions based on the client host's 
identity as well as that of the user.  The effect would be similar to the 
behavior of IP-address ACL's today, except that it would behave reasonably 
consistently and would actually be secure.

With these features, it is possible to access and trust a .klogin file 
without requiring the user's credentials, if users and/or administrators 
are willing to set permissive enough ACL's.  Personally, I fall into that 
camp -- I don't mind if .k5login contents are world-readable.


Another feature I'd like to see added to the ptserver is the ability to map 
a large set of Kerberos principals (either enumerated or based on a 
pattern) to a single PTS entry.  I've been thinking about this for a long 
time, though, and haven't yet come up with a way to represent it that 
doesn't make the lookups grossly inefficient (something we cannot afford; 
this is an operation the fileserver uses a lot, and its performance is a 
real issue).

If we can ever find a way to provide that capability, it should allow the 
camp that wants to keep klogin files secret a way to do so without creating 
a pts entry for every host.


-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA