On Tue, Jul 03, 2001 at 11:38:31AM +0200, Mark Murray wrote: > > I had wanted to design a generic wrapper API for all those systems atop > > PAM w/ binary prompts. But that has gone nowhere. Although, the one > > example of binary prompts included in Linux-PAM is, in fact, a wrapper > > around a home-grown network authentication system based on shared > > secrets, so a bare-bones proof of concept exists. > > I have been racking my brains for a solution to a similar problem, and > I am coming to the conclusion that PAM needs to be extended. In effect this is what libpamc + libpam binary prompts are: an extension to PAM to allow [non-initial] authentication over a network connections. It's just that this extension needs to be more generic still for my needs. What I want is a very simple API for apps to be able to handle both, initial authentication, and network authentication. But network authentication protocols tend to be somewhat complex, and usually involve negotiating a session key for session encryption/ protection use, *after* authentication -- and *this* is the bit that PAM can't handle now, since, once you're done authenticating with PAM you're also done with PAM. A simple extension to correct for this might be to add an API for extracting module-specific context structures by name; that wouldn't make PAM the simple API I'm looking for, but it would make it possible to write a simple layer atop PAM that is the simple API I'm looking for. Another problem is that Andrew Morgan's binary prompts are a bit too opaque: apps need to know which sort of tokens they are being asked to exchange with the client so they can do any further packaging that their protocol may require. It's important not to force changes to existing protocols in order to use an API such as what we're talking about. > At the risk of being somewhat long-winded, let me illustrate the problem > with ftpd and a challenge-based authenticator like OPIE or S/Key. [...] > I have not thought about this for very long, so there are doubtless > fundamental flaws in the idea. Your example is very specific to one form of authentication -- it would look very different if you were using GSS instead. Any PAM extension for handling this problem should be generic enough to cover most existing network authentication schemes. > Comments? I could hack up a proof-of-concept of this in short order. Look back through the archives of this list, there may be some interesting discussions on this topic. A proof of concept already exists in the form of the sample client app / server module that use binary prompts included in Linux-PAM. > M > -- > Mark Murray Nico -- . -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
