[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Challenge-based authentication (Was: Re: binary prompts and pam limited by some other protocol)



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.





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []