On Apr 21,  7:43am, Dick Davies wrote:
} * John Nemeth <jnemeth@victoria.tc.ca> [1116 21:16]:
} > On Apr 17,  5:57pm, Dick Davies wrote:
} > } 
} > } on the users behalf to validate the passphrase?), since
} > } PAM is fundamentally user/pass based. 
} > 
} >      PAM is not fundamentally user/pass based.  It is in fact not based
} > on any particular authentication method.
} 
} No, but every PAM module I've seen relies on a 'username' and 'password'

     Just curious, have you read the PAM specification, or even just
the manpages documenting a particular implementation?

} if you think of 'password' as 'string of bytes used to authenticate user'.

     In the end, all passwords are strings of bytes.  It is just a
matter of how you interpret those bytes.  The bytes could represent
characters entered at the keyboard, a certificate read from a
smartcard, data coming from a biometric scanner, or even a ticket.

} This isn't a good fit to ticket-based authentication. 

     There is nothing stopping a PAM module from using a Kerberos
ticket.  The problem is how to get that ticket from the client
application.  See my previous note where I coined the term, CSPAM, for
client/server PAM.

} > } server identification (there are no tickets coming back from the 
} > } server to the client). You'd have to rely on SSL CRLs to 'untrust'
} > 
} >      If you use Kerberos, you would get the appropriate information
} > back.  You'd just have to have a secure way of storing the TGT so that
} > different applications could get to it.
} 
} In practice i believe each server ends up holding a TGT (or more sensibly 
} a service ticket) for each client that has authenticated to it with pam_krb5.
} The point i'm making is with this setup I have to give my principal and
} passphrase to a remote machine which I can't be sure is who it says it is.

     Yes, I see the problem.  CSPAM would have to provide for mutual
authentication, provided the underlying authentication protocol allows
for it.

} > } I gave up and went to ldap auth - it has its warts but load balancing
} > } works well, and it feels like a better match to pam, plus it does 
} > 
} >      PAM is fully modular and thus can use any protocol you want.
} 
} I'm not sure what your point is. i'm saying pam_krb5 is more of a hack than

     Yes, it seems that pam_krb5 doesn't actually follow the spirit of
Kerberos.  Maybe somebody needs to write a new one, or maybe we need to
invent CSPAM to solve the problem.

}-- End of excerpt from Dick Davies