Wanted: (Discussion about) Interesting authentication protocols/ideas.

Wanted: (Discussion about) Interesting authentication protocols/ideas.

Post by Robb Shect » Sat, 15 Feb 1997 04:00:00



Hello,

We have a fairly hard user authentication problem that we're working on.  
We've come up with a solution or two, but nothing that's totally
satisfactory.  If anyone has had to do something like this, it'd be great
to hear about:  We have a very unique situation, so I'm not sure if
anyone has had to deal with this.  Here's a description of the problem,
along with a potential solution.

GOAL:  Authenticate student use of online computer labs.

SHORT DESCRIPTION:  We have 80 computer all across Europe.  They each have
a Linux server (serving files via NFS), and we're working on configuring
them to go online, via IP masquerading.  Some are VERY far away (from
Iceland to Saudi Arabia), and it's very expensive to service them.  We
have field representatives who deal with students, but who have no tech.
knowledge.  These labs are unmonitored.  The network we'll be using (the
milnet) is unreliable and insecure.  Some labs will be connecting via
Ethernet, some via PPP to a military terminal server.  We expect that
we'll have a good percentage down at one time for some reason or another.

RESTRICTIONS:
   * No net/comm between the field staff and lab.
   * No reliable net/comm between the lab and 'Headquarters' (in Heidelberg,
     Germany)
   * No reliable net/comm between the field staff and Headquarters.
   * No "secrets" can be stored on the lab servers: Anyone with a Linux boot
     disk can reboot and get root privs.
   * Various user timeouts/levels desired (weekend pass / one-semester pass,
     etc...)
   * No executable can be stored on the fieldstaff's computer system: They're
     very old, and crammed full of necessary software.
   * We also need 'instant' access to a lab:  If a student has enrolled
     in a course, they must be able to use the lab right away.
   * If a student is valid, they should be able to use ANY of our labs.

MY ONE, ALMOST GREAT AUTHENTICATION SOLUTION:

  The would work wonderfully, if we could put software on the field
staff's systems:

1) We install PGP on the field staff systems, along with a Public/Private
key pair.

2) We install PGP on the lab servers along with the field staff public
key. (No secrets here.)

2) When a student enrolls for a class, we clear-sign a certificate that
looks like this:

     Name: Bucky Jones
     Dates: 1/5/96 - 1/5/97
     Privs: http, ftp, telnet

3) We extract 5 or 6 characters from the sig block, and give that to the
student as their "password".

4) The student gets the signed certificate (minus password) on a floppy disk.

5) When a student first goes to a lab, they insert the floppy into a
client PC.  A login program request the password, combines it back with
the signature block, and sends it via TCP/IP to the server.

6) The server validates the sig block and date with the public key.  

7) The user, password, priviledges and dates are added to a database which
automatically deletes its entries at the end of the approved usage
dates.  Until then, the user can come back to that particular lab and
just enter their password to gain access.

So,  Any comments or conversation about this would be really appreciated.

- Robb
--
-
Robb Shecter                                               PGP Fingerprint:
University of Maryland, European Division              5F 70 B1 A7 B9 F9 42 67
Information Systems and Administrative Computing       11 27 47 EE 35 80 04 AA

 
 
 

Wanted: (Discussion about) Interesting authentication protocols/ideas.

Post by Paddy Holah » Sun, 16 Feb 1997 04:00:00



>We have a fairly hard user authentication problem that we're working on.  
>We've come up with a solution or two, but nothing that's totally
>satisfactory.  If anyone has had to do something like this, it'd be great
>to hear about:  We have a very unique situation, so I'm not sure if
>anyone has had to deal with this.  Here's a description of the problem,
>along with a potential solution.

Take a look at <www.baltimore.ie/srlogin.htm> for a solution for
remote login to unix.

 
 
 

Wanted: (Discussion about) Interesting authentication protocols/ideas.

Post by Vin McLella » Mon, 17 Feb 1997 04:00:00



> Hello,

> We have a fairly hard user authentication problem that we're working on.
> We've come up with a solution or two, but nothing that's totally
> satisfactory.  If anyone has had to do something like this, it'd be great
> to hear about:  We have a very unique situation, so I'm not sure if
> anyone has had to deal with this.  Here's a description of the problem,
> along with a potential solution.

> GOAL:  Authenticate student use of online computer labs.

> SHORT DESCRIPTION:  We have 80 computer all across Europe.  They each have
> a Linux server (serving files via NFS), and we're working on configuring
> them to go online, via IP masquerading.  Some are VERY far away (from
> Iceland to Saudi Arabia), and it's very expensive to service them.  We
> have field representatives who deal with students, but who have no tech.
> knowledge.  These labs are unmonitored.  The network we'll be using (the
> milnet) is unreliable and insecure.  Some labs will be connecting via
> Ethernet, some via PPP to a military terminal server.  We expect that
> we'll have a good percentage down at one time for some reason or another.

> RESTRICTIONS:
>    * No net/comm between the field staff and lab.
>    * No reliable net/comm between the lab and 'Headquarters' (in Heidelberg,
>      Germany)
>    * No reliable net/comm between the field staff and Headquarters.
>    * No "secrets" can be stored on the lab servers: Anyone with a Linux boot
>      disk can reboot and get root privs.
>    * Various user timeouts/levels desired (weekend pass / one-semester pass,
>      etc...)
>    * No executable can be stored on the fieldstaff's computer system: They're
>      very old, and crammed full of necessary software.
>    * We also need 'instant' access to a lab:  If a student has enrolled
>      in a course, they must be able to use the lab right away.
>    * If a student is valid, they should be able to use ANY of our labs.

> MY ONE, ALMOST GREAT AUTHENTICATION SOLUTION:

>   The would work wonderfully, if we could put software on the field
> staff's systems:

> 1) We install PGP on the field staff systems, along with a Public/Private
> key pair.

> 2) We install PGP on the lab servers along with the field staff public
> key. (No secrets here.)

> 2) When a student enrolls for a class, we clear-sign a certificate that
> looks like this:

>      Name: Bucky Jones
>      Dates: 1/5/96 - 1/5/97
>      Privs: http, ftp, telnet

> 3) We extract 5 or 6 characters from the sig block, and give that to the
> student as their "password".

> 4) The student gets the signed certificate (minus password) on a floppy disk.

> 5) When a student first goes to a lab, they insert the floppy into a
> client PC.  A login program request the password, combines it back with
> the signature block, and sends it via TCP/IP to the server.

> 6) The server validates the sig block and date with the public key.

> 7) The user, password, priviledges and dates are added to a database which
> automatically deletes its entries at the end of the approved usage
> dates.  Until then, the user can come back to that particular lab and
> just enter their password to gain access.

> So,  Any comments or conversation about this would be really appreciated.

> - Robb
> --
> -
> Robb Shecter                                               PGP Fingerprint:
> University of Maryland, European Division              5F 70 B1 A7 B9 F9 42 67
> Information Systems and Administrative Computing       11 27 47 EE 35 80 04 AA

--

      53 Nichols St., Chelsea, Ma. 02150 USA Tel: (617) 884-5548
                         <*><*><*><*><*><*><*><*><*>
 
 
 

Wanted: (Discussion about) Interesting authentication protocols/ideas.

Post by Ian Stirlin » Thu, 20 Feb 1997 04:00:00


: Hello,

:    * No "secrets" can be stored on the lab servers: Anyone with a Linux boot
:      disk can reboot and get root privs.

It could be difficult to reboot the server, if it was in a secure, locked
enclosure. While not perfect, Far fewer hackers would be willing to take
a grinder/powersaw in, which for a semi-decent case would be required to
open it in a semi-reasonable amount of time.
Also, if you have cameras, it's going to be Very obvious who did the deed.
If you make the secret machine specific, then in the worst case, onlt
that machine is comprimised.

Ideally you'd like a hardware R/O drive, for booting off, to eliminate
( or reduce) the problem of someone hacking the server.
quite a few SCSI disks I've seen have a read-only jumper.
Perhaps booting off an internal SCSI CD-ROM? (you'd need a burner tho)

--
Ian Stirling.                     Currently designing a new PDA, see homepage.
Homepage:                         http://www.mauve.demon.co.uk/
Great are those who suffer fasting's hardships,
But they are surpassed by those who suffer hard words spoken.
Malaclypse the younger.