Subject: Encrypted logins, configuration, The Chooser, etc.

From: "Bruce A. Burdick, Jr." <[email-masked]>
Date: Tue, 06 Feb 2001 02:47:05 -0600

I've perused the archives, but have mostly seen quick jots and morsels, all
assuming quite a bit of pre-existing context. Let's assemble the full story
on encrypted logins and netatalk. I'd like to see a robust how-to that
leaves nothing unsaid. How about you?

What are the various methods for encrypted logins supported by netatalk? In
which versions? What are the advantages/disadvantages of these? Which of
them are older/newer technologies? Which are weak/fading? Which are robust?

What are the various methods for encrypted logins supported by The Chooser?
In which versions?

How does netatalk need to be compiled to support the various methods? How
does this differ among the versions?

How does netatalk need to be configured to support the various methods? How
does this differ among the versions?

Do any end-to-end secure solutions exist? (i.e. no clear text passwords
stored or transmitted) What are they? How (in detail) are they installed and
configured?

What is netatalk 1.5 promising in this regard? What remains to be
implemented or fixed? What is not slated for development before the next
version? (1.6?)

Any other questions I missed?

I know some of the answers to these. But perhaps you know and can explain
them better. Or perhaps you have additional insights.

My reason for asking all this: I want to be able to login (with full
encryption, of course) from a Macintosh to a netatalk server over TCP/IP.
I'm running netatalk-1.4b2+asun2.1.3-8 on LinuxPPC 2000 (2.2.15pre3) and
netatalk-1.4b2+asun2.1.3-7 on LinuxPPC 2000 Q4 (2.2.18), and the shipping
version on OpenBSD 2.8 i386 (netatalk-990130.tgz). I've tried a few times to
get encrypted logins working, all to no avail. I'm not looking for a quick
fix. I'd really like to get a solid picture of the options and issues in my
head. I think a set of the best answers to the above questions will make my
life a lot easier, and probably many of yours as well. Anyone want to take a
crack at these?

Lastly, to you fellas who've picked up the netatalk ball and put it back
into development: thank you!

-B...

---

From: "Bruce A. Burdick, Jr." <[email-masked]>
Date: Sat, 10 Mar 2001 12:25:50 -0600

I'm reposting this. It got zero response on the list last month when traffic
was lower. But the participants who have increased the list traffic this
month have demonstrated an ability to answer some difficult questions. So my
hopes are up for some good answers this time around. And in the intervening
month I've managed to verify that if there is a third-party UAM for the Mac,
it's languishing in obscurity somewhere where Google and the other major
engines can't see it.

Don't be daunted by the size and scope of this list of questions. Break off
whatever you can manage.

-B...

___________________________________________________
From: Bruce A. Burdick, Jr. <[email-masked]>
Date: Tue, 06 Feb 2001 02:47:05 -0600

-B...

---

From: jeff <[email-masked]>
Date: Mon, 12 Mar 2001 05:04:03 -0500

> Don't be daunted by the size and scope of this list of questions. Break off

Randnum and DHX are the two ones that are supported by netatalk which
are supported by stock AppleShare clients.

Randnum (2-way encryption) is a little better security wise, but the
tradeoff is that you have to keep a seperate afppasswd file, which can
be a pain for a large number of users.

> What are the various methods for encrypted logins supported by The Chooser?

Apple has a page up at
http://til.info.apple.com/techinfo.nsf/artnum/n60792?OpenDocument&software
which explains the latest recommended versions of AppleShare Client for
each version of Mac OS. The latest versions all support DHX and randnum.
 
> does this differ among the versions?

It compiles the uams by default in the 1.5 series, if you have SSL
support, which it tries to detect if you haven't specified a path for
it.
 
> does this differ among the versions?

In your configuration directory (normally set in the build process,
usually /etc/atalk or /usr/local/atalk/etc or something similar), there
is a file called netatalk.conf which allows you to set the UAMS that the
sysv scripts ask for. Add the UAMs you want to the list in that file,
and you should be ready to go.
 
> implemented or fixed? What is not slated for development before the next

The biggest thing that has to be done before 1.6 is a DID database.
Other than that, we only have to worry about fixing small bugs in the
code.
 
> life a lot easier, and probably many of yours as well. Anyone want to take a

As far as I know, the 1.5pre5 release should work with encrypted
passwords on OpenBSD and LinuxPPC 2000. If you use the pam modules
(--enable-pam on the ./configure line) you can even use a single LDAP or
NIS authentication server for passwords across all the boxen.

Make sure to update your AppleShare Clients, though. Many old ones don't
support DHX.

jeff

---

From: Leland Wallace <[email-masked]>
Date: Mon, 12 Mar 2001 11:54:19 -0800

> leaves nothing unsaid. How about you?
<SNIP>

> What are the various methods for encrypted logins supported by The 
Authentication methods supported by the AppleShare Client:
No User Authent  --  aka guest

Cleartext passwd  -- the lowest common denominator (just as bad as it 
sounds)

Randnum Exchange -- only 8-byte random numbers are sent over the wire.
   vulnerable to offline dictionary attack, only the client is 
authenticated. Requires
   a cleartext password on the server. Limited to 8 byte passwords. Uses 
DES.

2-Way Randnum Exchange -- same as above, but the server is authenticated 
as well,
   making it strong against Man in the Middle attacks. This has been the 
mainstay of the
   Apple AFP services.

DHCast128 -- aka DHX, a 128 bit key is generated by Diffie-Hellman key 
agreement,
   a 64 byte password is sent encrypted by the above key using CAST-128.  
Weak
   against Man in the Middle attacks. This one is gaining popularity and 
is supported in
   Mac OS X.

Third Party UAMs that I know of:
MicrosoftUAM
Netware UAM
There are at least 2 kerberos UAMs kicking around.

Clients up to 3.8.3, have the first 4, 3.8.3 shipped with DHX as a UAM 
plug in. 3.8.4 and later
have DHX built in.

UAMs Id like to write if I had the time:
B-SPEKE - a robust alg, provably secure, does not use cleartext anywhere 
except on the client
(as input).  <http://world.std.com/~dpj>

SRP - very similar to B-SPEKE. <http://www-cs-
students.stanford.edu/~tjw/srp/>

RADIUS - don't know very much abt this one, but it looks like it would 
be useful.

<SNIP>
> stored or transmitted) What are they? How (in detail) are they 
By your definition DHX seems to fit the bill. I'd look at B-SPEKE and 
SRP as well.

<SNIP>

> into development: thank you!
ditto.

I'm the lead engineer on the AppleShare Client at Apple.

Hope this helps
Leland

+-----------------------------------------------------------------------------------
Leland Wallace           Working in            AppleShare Engineering
[email-masked]    but not speaking for      Apple Computer Inc.
http://www2.inow.com/~randall
+-----------------------------------------------------------------------------------

---

From: "Michael Clark" <[email-masked]>
Date: Tue, 13 Mar 2001 07:16:45 +0800

<SNIP>
>    against Man in the Middle attacks. This one is gaining popularity and

Okay, so i guess DHX has no need for clear text passwords stored on the server
(as is required with the 'network-secure' UAMs such as 2-way randnum) - can I
use PAM right?

I guess you can then use LDAP indirectly through PAM - anybody tried this?

Michael Clark.

---

From: Leland Wallace <[email-masked]>
Date: Mon, 12 Mar 2001 15:26:14 -0800

> (as is required with the 'network-secure' UAMs such as 2-way randnum) - 
AFAIK yes, and I think that's what the current DHX implementations 
allow. Once the
password is decrypted on the server side, you can do anything you want 
with it.

Hope this helps
Leland

---

From: Marc Miller <[email-masked]>
Date: Mon, 12 Mar 2001 16:41:02 -0800 (PST)

A friend recently informed me that Linux Magazine also said to create the
netatalk passwords in a clear-text file for one of those other encryption
techniques.  Dangerous.

DHX does work with PAM; I'm doing that right now on my system.

> I guess you can then use LDAP indirectly through PAM - anybody tried this?

============================================================
	/\/\arc ._|. /\/\iller ([email-masked])
	Computer Room Consultant
	Information Technology/Lab Management
============================================================
I can be contacted through the Communication Center link from
http://www.mother.com/~mjmiller/