[OpenAFS] afs authentication

[Douglas E. Engert]

"Christopher A. Petro" wrote:
> 
> I recall being pretty impressed with AFS authentication back in 1993.  It
> doesn't seem quite as spiffy anymore, though.  The last few messages about
> a 3DES key breaking it and my own recent hassles have got me thinking about
> it quite a bit.  Now that I have AFS up and running on my machines (except
> for XP where the client just flat out refuses to start, though it can
> authenticate just fine), I'm thinking about doing something about it.

I sort of agree with you, but by 1993, Kerberos V5 looked much better and
looks much better today. We use AFS for a file service but not for authentication.
We use Kerberos V5 for authentication, and treat AFS as a service. We are 
using the KRB524 and AKLOG to convert the K5 tickets to the K4 AFS token. We 
are also working in the GSSKLOG to replace the KRB524 and AKLOG do the 
authentication via GSSAPI, which will allow us to use Kerberos or some other
GSSAPI for authentication.  

So this helps your problem in the two areas below, The authentication can use 
3DES, and K5 has preauthenticaion to address the password issues. ut see below
for more comments. 

But it does not address the fact that the AFS token is still using single des,
as it is essentially a K4 ticket.    

> 
> I see two real problems with the current authentication:
> 
>  * It's DES.  I can capture any two packets in a row from the client/AS
>    handshake and brute-force the password hash in no time.  That's all
>    I would need to get in using a modified klog, and getting the actual
>    password from it wouldn't be difficult either.  I love the following
>    bit from the Authentication Server Spec: "It is implicitly assumed
>    that anyone prepared to do a serious cryptographic attack on DES
>    encrypted data in this system can have whatever he or she can get.
>    Any data so sensitive that this might be a problem should be subject
>    to additonal safety measures.  No such data should be stored in the
>    Andrew File System."  I don't know about you, but I think my _spam_
>    deserves more protection than DES. :)
> 
>  * It's password-based.  A lot boredom.org users log on from untrusted
>    machines such as .edu lab machines, public clusters, etc. where they
>    have to assume that there's a keysniffer running.  In the past we have
>    always solved this using S/KEY.  For now some of these people are using
>    S/KEY to auth to one of the client machines and then having their
>    login script klog them into AFS using a plaintext password stored
>    on the local file system.  Clearly suboptimal.

If you come up with a GSSAPI using S/Key, you could use the GSSKLOG.  
If you use the Globus GSI, you can use X509 certificates. 

> 
> The beauty of access being controlled by opaque tickets is that it
> should be very, very easy to replace the initial authentication without
> having to make modifications to parts of the code not related to
> authentication.  Assuming the code related to verifying tickets is nicely
> tucked away in a library and the tickets are handled opaquely everywhere
> else, strengthening the protection on tickets should also be relatively
> trivial.
> 

Sounds a lot like GSSAPI, the authentication is tucked away in 
a library, and the authentication is handled opaquely. 

> Obviously I'm making a lot of assumptions about the code without having
> really read it.  Before I start a project like this, is anyone else working
> on improving the authentication in the system?  Am I incorrect in assuming
> that the authentication code is well segregated and modular?  The original
> AFS documentation all makes it sound like the system was designed to be
> fairly agnostic about how this all worked internally, going as far to say
> that any secret key-based encryption would be fine to use, so I don't
> foresee any changes to authentication violating any fundamental design
> principals.
> 
> Clearly the changes should be backwards-compatible.  If a cell doesn't
> allow particular users to authenticate using DES, attempts to log in
> using and old client making the original RPC calls should fail auth
> gracefully.  What other concerns might there be?
> 

Check out the GSSKLOG at ftp://achilles.ctd.anl.gov/pub/DEE/gssklog-0.5.tar


> Comments and thoughts are greatly appreciated.
> 
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

-- 

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