Subject: Re: Centralized User and Password Management
To: Dick Davies <email@example.com>
From: John Nemeth <firstname.lastname@example.org>
Date: 12/09/2004 01:47:50
On Apr 21, 7:43am, Dick Davies wrote:
} * John Nemeth <email@example.com> [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
} > } 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
} > } 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