Linux Authentication Architecture Question:

Howdy,

I am writing a UDP server daemon in perl, and I would like to back-end
its authentication into whatever the Linux box happens to be using for
user authentication at the moment.

In consideration of PAM, LDAP, and the legacy password authentication
system, what is the most forward compatible, and installation tolerant
way of doing this? I want to be able to distribute the daemon and
have it compile and work with various distros without a myriad of
grabastic dependencies.

The data is not sensitive to snooping, but it does need to be
authenticated. So CHAP over UDP should be sufficient. Is there a way
to pipe to "login" on the backend or something?

Thanks in advance!

[email]shrike@cyberspace.org[/email] wrote:[color=blue]
> Howdy,
>
> I am writing a UDP server daemon in perl, and I would like to back-end
> its authentication into whatever the Linux box happens to be using for
> user authentication at the moment.[/color]

*WHY*? There are so many already existing, why can't you simply use the
existing LDAP or similar infrastructures?
[color=blue]
> In consideration of PAM, LDAP, and the legacy password authentication
> system, what is the most forward compatible, and installation tolerant
> way of doing this? I want to be able to distribute the daemon and
> have it compile and work with various distros without a myriad of
> grabastic dependencies.[/color]

Depends on what you want. PAM isn't a protocol, it's a manager for other
protocols. LDAP is extremely powerful, but too powerful and too potentially
mis-configurable or many setups.

[color=blue]
> The data is not sensitive to snooping, but it does need to be
> authenticated. So CHAP over UDP should be sufficient. Is there a way
> to pipe to "login" on the backend or something?
>
> Thanks in advance![/color]

If all you need is authentication, why not simply use Kerberos? Are you
married to the use of UDP in this project?

In article <21bc80f1-87ea-4a90-a27c-a6c646c81895@d1g2000hsg.googlegroups.com>,
"shrike@cyberspace.org" <shrike@cyberspace.org> writes:[color=blue]
>Howdy,
>
>I am writing a UDP server daemon in perl, and I would like to back-end
>its authentication into whatever the Linux box happens to be using for
>user authentication at the moment.
>
>In consideration of PAM, LDAP, and the legacy password authentication
>system, what is the most forward compatible, and installation tolerant
>way of doing this? I want to be able to distribute the daemon and
>have it compile and work with various distros without a myriad of
>grabastic dependencies.
>
>The data is not sensitive to snooping, but it does need to be
>authenticated. So CHAP over UDP should be sufficient. Is there a way
>to pipe to "login" on the backend or something?[/color]

That sounds like either a lot of work or bad security.

If you don't want to send the password in the clear, you have
to have some sort of encryption which probably requires something
like a connection.

Why do you want to use UDP? Why not ssh or ssl/web?


--
These are my opinions, not necessarily my employer's. I hate spam.

On 15.09.2008, Nico Kadel-Garcia <nkadel@gmail.com> wrote:[color=blue][color=green]
>> The data is not sensitive to snooping, but it does need to be
>> authenticated. So CHAP over UDP should be sufficient. Is there a way
>> to pipe to "login" on the backend or something?
>>
>> Thanks in advance![/color]
>
> If all you need is authentication, why not simply use Kerberos?[/color]

Maybe because Kerberos is the only protocol having in Linux just one
kosher implementation, which is buggy from time to time and has way, way
to complicated API?
[color=blue]
> Are you
> married to the use of UDP in this project?[/color]

--
Secunia non olet.
Stanislaw Klekot

Hal Murray wrote:[color=blue]
> In article <21bc80f1-87ea-4a90-a27c-a6c646c81895@d1g2000hsg.googlegroups.com>,
> "shrike@cyberspace.org" <shrike@cyberspace.org> writes:[color=green]
>> Howdy,
>>
>> I am writing a UDP server daemon in perl, and I would like to back-end
>> its authentication into whatever the Linux box happens to be using for
>> user authentication at the moment.
>>
>> In consideration of PAM, LDAP, and the legacy password authentication
>> system, what is the most forward compatible, and installation tolerant
>> way of doing this? I want to be able to distribute the daemon and
>> have it compile and work with various distros without a myriad of
>> grabastic dependencies.
>>
>> The data is not sensitive to snooping, but it does need to be
>> authenticated. So CHAP over UDP should be sufficient. Is there a way
>> to pipe to "login" on the backend or something?[/color]
>
> That sounds like either a lot of work or bad security.
>
> If you don't want to send the password in the clear, you have
> to have some sort of encryption which probably requires something
> like a connection.
>
> Why do you want to use UDP? Why not ssh or ssl/web?[/color]

I think folks are missing the OP's question.

He's writing a service. It doesn't matter what kind.
He wants to authenticate access to it.

With no additional work or extra configuration required for his custom
service, he wants to use whatever the server OS uses for interactive
sessions. If it uses /etc/passwd, his service would use /etc/passwd.
If it uses LDAP or NIS or whatever, his service would plug into the
authentication architecture the same way that interactive logins do,
transparently, no extra config required at installation.

I suspect it's a matter of configuring pam correctly by writing a pam
module for the service, sticking a reference to it in a custom config
file, and dropping the config file into /etc/pam.d when you install the
service. That's a guess on my part. I haven't had a reason to drink of
the pam nectar deeply yet. I just poke at it from time to time for
stuff other people write.

Stachu 'Dozzie' K. wrote:[color=blue]
> On 15.09.2008, Nico Kadel-Garcia <nkadel@gmail.com> wrote:[color=green][color=darkred]
>>> The data is not sensitive to snooping, but it does need to be
>>> authenticated. So CHAP over UDP should be sufficient. Is there a way
>>> to pipe to "login" on the backend or something?
>>>
>>> Thanks in advance![/color]
>> If all you need is authentication, why not simply use Kerberos?[/color]
>
> Maybe because Kerberos is the only protocol having in Linux just one
> kosher implementation, which is buggy from time to time and has way, way
> to complicated API?
>[color=green]
>> Are you
>> married to the use of UDP in this project?[/color]
>[/color]

It's gotten pretty stable, and many if not most LDAP setups run on top of it
for authentication handling. And the utilities and libraries to use it have
gotten pretty integral to contemporary versions of Linux, so little new
implementation work is needed.

On Sep 15, 3:25*pm, Nico Kadel-Garcia <nka...@gmail.com> wrote:[color=blue]
> shr...@cyberspace.org wrote:[color=green]
> > Howdy,[/color]
>[color=green]
> > I am writing a UDP server daemon in perl, and I would like to back-end
> > its authentication into whatever the Linux box happens to be using for
> > user authentication at the moment.[/color]
>
> *WHY*? There are so many already existing, why can't you simply use the
> existing LDAP or similar infrastructures?[/color]

The data transmitted isn't security sensitive, only the authentication
process is. From that standpoint, all I want to do is pass credentials
and let the OS handle the rest. CHAP is fine for that IMHO since it's
dirt simple and reliable. Writing a CHAP implementation over UDP will
pay dividends in not having to support LDAP, Kerberos, etc. etc. If I
use whatever AAA system the user already has, my phone bill stays low
because I don't have to support other peoples AAA software.
[color=blue]
>[color=green]
> > In consideration of PAM, LDAP, and the legacy password authentication
> > system, what is the most forward compatible, and installation tolerant
> > way of doing this? *I want to be able to distribute the daemon and
> > have it compile and work with various distros without a myriad of
> > grabastic dependencies.[/color]
>
> Depends on what you want. PAM isn't a protocol, it's a manager for other
> protocols. LDAP is extremely powerful, but too powerful and too potentially
> mis-configurable or many setups.
>[/color]

PAM is still not that broadly distributed. At least the last time I
checked, Slackware didn't have it, and recompiling the dependent
libraries to get it is not for the faint of heart. I want a
monolithic daemon, that installs and uses whatever AAA system is
there. I will leave supporting AAA to the people who are good at
it.
[color=blue][color=green]
> > The data is not sensitive to snooping, but it does need to be
> > authenticated. So CHAP over UDP should be sufficient. *Is there a way
> > to pipe to "login" on the backend or something?[/color]
>[color=green]
> > Thanks in advance![/color]
>
> If all you need is authentication, why not simply use Kerberos? Are you
> married to the use of UDP in this project?[/color]

Yes. I am actually tunneling within a UDP based session layer
protocol. So UDP comes with the territory.

Thanks in advance!

On Sep 15, 6:31*pm, hal-use...@ip-64-139-1-69.sjc.megapath.net (Hal
Murray) wrote:[color=blue]
> In article <21bc80f1-87ea-4a90-a27c-a6c646c81...@d1g2000hsg.googlegroups.com>,
>
>
>
> *"shr...@cyberspace.org" <shr...@cyberspace.org> writes:[color=green]
> >Howdy,[/color]
>[color=green]
> >I am writing a UDP server daemon in perl, and I would like to back-end
> >its authentication into whatever the Linux box happens to be using for
> >user authentication at the moment.[/color]
>[color=green]
> >In consideration of PAM, LDAP, and the legacy password authentication
> >system, what is the most forward compatible, and installation tolerant
> >way of doing this? *I want to be able to distribute the daemon and
> >have it compile and work with various distros without a myriad of
> >grabastic dependencies.[/color]
>[color=green]
> >The data is not sensitive to snooping, but it does need to be
> >authenticated. So CHAP over UDP should be sufficient. *Is there a way
> >to pipe to "login" on the backend or something?[/color]
>
> That sounds like either a lot of work or bad security.
>
> If you don't want to send the password in the clear, you have
> to have some sort of encryption which probably requires something
> like a connection.
>[/color]

That is partially correct. CHAP uses hash algorithms and a shared
random value to authenticate. Passwords are never sent, and
consequently no encryption, shared or public key is required.
[color=blue]
>
> Why do you want to use UDP? *Why not ssh or ssl/web?
>[/color]

SSH is WAY to heavy. The data is not security sensitive, so why should
I burn cycles encrypting it? Second, why should I support users who
hose up their SSH or httpd installations?
[color=blue]
> --
> These are my opinions, not necessarily my employer's. *I hate spam.[/color]

On Sep 15, 10:08*pm, Allen Kistler <ackist...@oohay.moc> wrote:[color=blue]
> Hal Murray wrote:[color=green]
> > In article <21bc80f1-87ea-4a90-a27c-a6c646c81...@d1g2000hsg.googlegroups.com>,
> > *"shr...@cyberspace.org" <shr...@cyberspace.org> writes:[color=darkred]
> >> Howdy,[/color][/color]
>[color=green][color=darkred]
> >> I am writing a UDP server daemon in perl, and I would like to back-end
> >> its authentication into whatever the Linux box happens to be using for
> >> user authentication at the moment.[/color][/color]
>[color=green][color=darkred]
> >> In consideration of PAM, LDAP, and the legacy password authentication
> >> system, what is the most forward compatible, and installation tolerant
> >> way of doing this? *I want to be able to distribute the daemon and
> >> have it compile and work with various distros without a myriad of
> >> grabastic dependencies.[/color][/color]
>[color=green][color=darkred]
> >> The data is not sensitive to snooping, but it does need to be
> >> authenticated. So CHAP over UDP should be sufficient. *Is there a way
> >> to pipe to "login" on the backend or something?[/color][/color]
>[color=green]
> > That sounds like either a lot of work or bad security.[/color]
>[color=green]
> > If you don't want to send the password in the clear, you have
> > to have some sort of encryption which probably requires something
> > like a connection.[/color]
>[color=green]
> > Why do you want to use UDP? *Why not ssh or ssl/web?[/color]
>
> I think folks are missing the OP's question.
>
> He's writing a service. *It doesn't matter what kind.
> He wants to authenticate access to it.
>
> With no additional work or extra configuration required for his custom
> service, he wants to use whatever the server OS uses for interactive
> sessions. *If it uses /etc/passwd, his service would use /etc/passwd.
> If it uses LDAP or NIS or whatever, his service would plug into the
> authentication architecture the same way that interactive logins do,
> transparently, no extra config required at installation.
>
> I suspect it's a matter of configuring pam correctly by writing a pam
> module for the service, sticking a reference to it in a custom config
> file, and dropping the config file into /etc/pam.d when you install the
> service. *That's a guess on my part. *I haven't had a reason to drinkof
> the pam nectar deeply yet. *I just poke at it from time to time for
> stuff other people write.[/color]

That's it in a nutshell. I am starting to think I will need to go
through the source to telnetd, dig out the respective bits and make a
perl extension. But I _really_ would rather work with an API or
something instead of sticking my fingers in some positively ancient
code. I would think somebody would have some documentation for the
relative functions in glibc, or wherever the auth functions are in the
shared libraries. This really shouldn't be too hard.

[email]shrike@cyberspace.org[/email] <shrike@cyberspace.org> wrote:[color=blue]
> I am writing a UDP server daemon in perl, and I would like to back-end
> its authentication into whatever the Linux box happens to be using for
> user authentication at the moment.[/color]

I would use PAM for the authentication. That way you don't have to care
about the actual authentication backend in use. PAM has modules for LDAP,
kerberos, passwd and many more backends.

Toni
--
---------------------------------------------------------------------------
e9427514 (at) student.tuwien.ac.at

Antonio Batovanja wrote:[color=blue]
> [email]shrike@cyberspace.org[/email] <shrike@cyberspace.org> wrote:[color=green]
>> I am writing a UDP server daemon in perl, and I would like to back-end
>> its authentication into whatever the Linux box happens to be using for
>> user authentication at the moment.[/color]
>
> I would use PAM for the authentication. That way you don't have to care
> about the actual authentication backend in use. PAM has modules for LDAP,
> kerberos, passwd and many more backends.
>
> Toni[/color]

Not if it's not *ENCRYPTED*, and not if it keeps passwords in clear text on
the client. The number of people who just slap in authentication technologies
and don't think about this is... actually most of the Subversion using community.

Nico Kadel-Garcia <nkadel@gmail.com> wrote:[color=blue]
> Antonio Batovanja wrote:[color=green]
>> [email]shrike@cyberspace.org[/email] <shrike@cyberspace.org> wrote:[color=darkred]
>>> I am writing a UDP server daemon in perl, and I would like to back-end
>>> its authentication into whatever the Linux box happens to be using for
>>> user authentication at the moment.[/color]
>>
>> I would use PAM for the authentication. That way you don't have to care
>> about the actual authentication backend in use. PAM has modules for LDAP,
>> kerberos, passwd and many more backends.
>>
>> Toni[/color][/color]
[color=blue]
> Not if it's not *ENCRYPTED*, and not if it keeps passwords in clear text on
> the client. The number of people who just slap in authentication technologies
> and don't think about this is... actually most of the Subversion using community.[/color]

Please clarify that for me.
What does *transport encryption* from the client to the server have to do
with the server process authenticating the user *on the server locally*
using PAM?

Sure, the transport channel *should* be encrypted, but that's a different
problem.

Toni
--
---------------------------------------------------------------------------
e9427514 (at) student.tuwien.ac.at

Antonio Batovanja wrote:[color=blue]
> Nico Kadel-Garcia <nkadel@gmail.com> wrote:[color=green]
>> Antonio Batovanja wrote:[color=darkred]
>>> [email]shrike@cyberspace.org[/email] <shrike@cyberspace.org> wrote:
>>>> I am writing a UDP server daemon in perl, and I would like to back-end
>>>> its authentication into whatever the Linux box happens to be using for
>>>> user authentication at the moment.
>>> I would use PAM for the authentication. That way you don't have to care
>>> about the actual authentication backend in use. PAM has modules for LDAP,
>>> kerberos, passwd and many more backends.
>>>
>>> Toni[/color][/color]
>[color=green]
>> Not if it's not *ENCRYPTED*, and not if it keeps passwords in clear text on
>> the client. The number of people who just slap in authentication technologies
>> and don't think about this is... actually most of the Subversion using community.[/color]
>
> Please clarify that for me.
> What does *transport encryption* from the client to the server have to do
> with the server process authenticating the user *on the server locally*
> using PAM?
>
> Sure, the transport channel *should* be encrypted, but that's a different
> problem.
>
> Toni[/color]

Some clients, like Jabber's default setup, store passwords in cleartext on the
server. Some clients, such as Subversions's built-in HTTP and HTTPS tools,
store it in cleartext on the client. The latter is the worst, because it will
store your PAM passwords locally, in cleartext.

The lack of encryption from client to server for this usage means that the
passwords go over the wire in the clear, even if the authentication is done
locally on the server.