HDTenEightyP/NetNews huggingface dataset:
From: smb@ulysses.att.com
Subject: Re: New User Accounts
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 2 Sep 1992 01:25:46 GMT

Put a ``passwd'' command in the initial .profile, and arrange for the
real default .profile (or .login if your religion runs that way) to
be installed by the initial version.
Newsgroups: comp.protocols.kerberos
From: glenz@ocsg.COM (Glen Zorn)
Subject: Re:  Papers by W. J Bryant
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 3 Sep 1992 17:02:49 GMT

In article <1992Sep2.091510.23147@news.uit.no>, orjanr@staff.cs.uit.no	(Orjan 
W. Robertsen) writes:


	In the papaer "Living with Your Three-Headed Dog" by Tai Jin there
	are references to two papers (or maybe books) by W. J. Bryant.

	The papers (books) are:
		W. J. Bryant, Kerberos Programmers's Tutorial
		W. J. Bryant, Kerberos Administrators Manual

	As of March 1988 theese should be "in preparation".

	DOES ANYONE KNOW WHERE TO GET THEESE, OR IF THEY EXIST AT ALL ??


Does anyone know how to get the paper "Living with Your Three-Headed Dog" by 
Tai Jin?  Thanks in advance.

~ Glen


Glen Zorn       Network Security Analyst
glenz@OCSG.COM  Open Computing Security Group


Newsgroups: comp.protocols.kerberos
From: S.Aujla@axion.bt.co.uk
Subject: Please add me to mailing list
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 3 Sep 1992 12:42:31 GMT


email: saujla@axion.bt.co.uk

Many thanks

Sukhvinder Aujla
Newsgroups: comp.protocols.kerberos
From: warlord@ATHENA.MIT.EDU (Derek Atkins)
Subject: Re: New User Accounts
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 2 Sep 1992 18:01:55 GMT

> P.S.  Has anyone had any experience using SecurID cards with Kerberos  
> IV or V?
> 
> I think one can use a service key to get a ticket and session key for  
> a mutually authenticated private session with a "kerberos-SecurID"  
> server, which is on the same machine as the kerberos server.  
> 
> The SecurID code would be sent to this server, and if authenticated  
> by the SecurID software, the kerberos passwd would be changed to the  
> securID code, and then changed to something random 30 seconds later.
> 
> The client would get initial kerberos tickets as usual using the  
> SecurID code as the password.
> 
> Any comments are appreciated

I was looking into this possibility this summer.  One way of doing
this would be to have the kerberos server know the SecurID algorithm
and send you an initial ticket in encrypted in the SecurID number.
Another possibility would be to send a couple of initial tickets for
the next five minutes of validity, each with the SecurID number of
that time, and then have the client try all of them until it gets a
good one.

Sending the SecurID number to the kerberos server then means you need
some way to securely get the kerberos ticket back onto your
workstation.  What would you encrypt it in?  If you are using SecurID
in the first place, that means you CAN'T use your kerberos password,
as that would defeat the purpose.

There is a large problem in this -- its a "two network problem."  You
need one secret, SecurID, to get into the system, and then you need
another secret to authenticate to kerberos.  The cure is to somehow
combine both secrets into one request/challenge/response sequence.

-derek

PS (Shameful plug) My thesis is going to involve something like this!

         Derek Atkins -- MIT '93 -- Electrical Engineering
--warlord@MIT.EDU | ..!mit-eddie!mit-athena!warlord | s20069@mitvma.bitnet
      Chairman, MIT Student Information Processing Board (SIPB)
           MIT Media Laboratory, Speech Research Group

Newsgroups: comp.protocols.kerberos
From: warlord@MIT.EDU (Derek Atkins)
Subject: Re: New User Accounts
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 2 Sep 1992 19:49:40 GMT

The point of using SecurID is so that you don't HAVE to type your
password in the clear over the net.  Granted, this might allow one to
obtain a tgt using SecurID as the password (instead of the normal
login password), however this doesnt solve the problem of
re-authentication.

Once you are logged in, if you want to reauthenticate, someone can
watch as you type your password.  Since the SecurID password is
changed every minute, and is only good once, that isn't a problem,
however to use your SecurID code as the password would require major
hacking of the kerberos server and would probably make it incompatible
with the current system.  (I.e., how does the server know whether or
not to expect a SecurID password or not).

The solution here is not a simple one, so suggestions are open!

(The real solution is to throw away SecurID as a method of
login-password-authentication and extend kerberos all the way across
the modem to the terminal.)

-derek


Newsgroups: comp.protocols.kerberos
From: orjanr@diplom0.cs.uit.no (Orjan Robertsen)
Subject: Papers by W. J Bryant
Organization: University of Tromsoe
Date: Wed, 2 Sep 1992 09:15:10 GMT


In the papaer "Living with Your Three-Headed Dog" by Tai Jin there
are references to two papers (or maybe books) by W. J. Bryant.

The papers (books) are:
	W. J. Bryant, Kerberos Programmers's Tutorial
	W. J. Bryant, Kerberos Administrators Manual

As of March 1988 theese should be "in preparation".

DOES ANYONE KNOW WHERE TO GET THEESE, OR IF THEY EXIST AT ALL ??

Thanks

-- 
////      Orjan W. Robertsen            |e-mail   : orjanr@staff.cs.uit.no////
///Dept. of Computer Science, University|Home     : +47-83-82897          ///
// of Tromsoe, N-9000 TROMSO, NORWAY   |Phone/Fax: +47-83-44053/44580    //
Newsgroups: comp.protocols.kerberos
From: ggm@brolga.cc.uq.oz.au (George Michaelson)
Subject: Re: New User Accounts
Organization: Prentice Centre, University of Queensland
Date: Wed, 2 Sep 1992 04:16:55 GMT

smb@ulysses.att.com writes:

>Put a ``passwd'' command in the initial .profile, and arrange for the
>real default .profile (or .login if your religion runs that way) to
>be installed by the initial version.


We were hacked from an account created but never legally used within
the non-expiry period. The initial password was admittedly insecure.

Yes... the first command traced on the hacked account was to change the
password. 

I now believe that in some circumstances you need to actually stand over
the customer and MAKE them initialize the password to a secure value.

	-George
--
                         George Michaelson
G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
                         University of Queensland | hippos in Philadelphia
Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht
Newsgroups: comp.protocols.kerberos
From: trier@odin.ins.cwru.edu (Stephen C. Trier)
Subject: Re:  Anyone Ported Kerberos To MS-Windows?
Organization: Case Western Reserve University, Cleveland, OH (USA)
Date: Sat, 29 Aug 92 04:41:13 GMT

In article <9208282333.AA02728@endor.harvard.edu> ddl@DAS.HARVARD.EDU (Dan Lanciani) writes:
>Well, I ported it to DOS and OS/2.

Is your port the one on athena-dist, or is it part of your commercial
TCP suite?

-- 
"Beware of programmers who     Stephen Trier
 carry screwdrivers."          Network Services Engineering, IRIS/INS/Telecom
       Leonard Brandwein       Case Western Reserve University
                               trier@ins.cwru.edu
Newsgroups: comp.protocols.kerberos
From: ddl@DAS.HARVARD.EDU (Dan Lanciani)
Subject: Re:  Anyone Ported Kerberos To MS-Windows?
Organization: Internet-USENET Gateway at Stanford University
Date: Fri, 28 Aug 1992 23:33:46 GMT

	Well, I ported it to DOS and OS/2.  The main problems were
sizeof(int) == 32 and related simple (but sometimes hard-to-find)
bugs.  The DES library and the error code system were the main offenders.

				Dan
Newsgroups: comp.protocols.kerberos
From: restock@ns.pacbell.com (Bob Stockwell)
Subject: Porting application server side only
Organization: Pacific * Bell
X-Newsreader: Tin 1.1 PL5
Date: Thu, 3 Sep 1992 21:58:29 GMT

We are investigating the viability of porting the application server
portion of Kerberos.  In looking at the sources from MIT it is
difficult to determine how much effort this would take.  Of all of the
source files provided how many are needed to just do the application
server portion only.  I assume that most of the code is for the
TGS with a little less for the client side.  The application server
side should be much smaller.  Am I wrong?  Has anybody done this?  To
a Tandem Guardian platform?

--
Thanks,
Bob


Bob Stockwell
Pacific Bell
510/901-9702
restock@pacbell.com
Newsgroups: comp.protocols.kerberos
From: lwvanels@athena.mit.edu (Lucien W. Van Elsen)
Subject: Re: kerberized login under aix
Reply-To: lwvanels@MIT.EDU
Organization: Massachusetts Institute of Technology
Date: Tue, 25 Aug 1992 17:27:26 GMT

pulverg@CPSEC.CPMC.COLUMBIA.EDU (Gerald E Pulver) writes:
>   Has anyone out there had experience kerberizing login on an aix machine?
>   If so: did you just use login.krb as a direct drop-in replacement for 
>   /bin/login or did you establish kerberos as an alternate authentication
>   method in login.cfg, to be referred to on a case-by-case basis in the
>   Primary Authenication field of SMIT?

I managed to get login.krb somewhat working under AIX with a moderate amount
work; the security routines and methods for starting up a new session are
fairly different.  The "somewhat working" is due to the fact that while the
login would work for network access (replacing /bin/login), I could not
manage to get it to work on the console, apparently due to some HFT magic
that I was missing.  Since we also desired to add some features to the login
program, establishing an alternate authentication method wasn't sufficient.
We eventually ended up using a modified version Transarc's (proprietary)
login.

However, if you don't need to add any additional features, adding an
alternate authentication method is what I'd recommend; the interface is
fairly flexible, though somewhat poorly documented.

	-Lucien

----------------------------------------------------------------------------
Lucien Van Elsen               | lwvanels@mit.edu
			       | The secret to a long life is knowing when
			       | it's time to go..
Newsgroups: comp.protocols.kerberos
From: henry@ADS.COM (Henry Mensch)
Subject: Papers by W. J Bryant
Reply-To: henry@ads.com
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 2 Sep 1992 17:51:27 GMT

   Date: Wed, 2 Sep 1992 09:15:10 GMT
   From: orjanr@diplom0.cs.uit.no (Orjan Robertsen)

   In the papaer "Living with Your Three-Headed Dog" by Tai Jin there
   are references to two papers (or maybe books) by W. J. Bryant.

   The papers (books) are:
	   W. J. Bryant, Kerberos Programmers's Tutorial
	   W. J. Bryant, Kerberos Administrators Manual

   As of March 1988 theese should be "in preparation".

   DOES ANYONE KNOW WHERE TO GET THEESE, OR IF THEY EXIST AT ALL ??

can you please:

a) not shout; it won't make things happen faster ...

b) ask info-athena@mit.edu for copies of these papers.

# henry mensch / booz, allen & hamilton, inc.  / <henry@ads.com>
Newsgroups: comp.protocols.kerberos
From: erussell@wang.com (Edward A. Russell)
Subject: Re: Anyone Ported Kerberos To MS-Windows?
Organization: Wang Labs, Lowell MA, USA
Date: Mon, 31 Aug 92 19:31:51 GMT


I missed the original post.  I have ported Kerberos client to
MS-Windows.
I had to change some int variables to unsigned int or long.  I
generated the DES C code (which gets automatically generated as part
of the make) on an AIX so I would not have to port the make
files/Imakefiles.  I then just wrote my own simple make files to
compile just the files needed for kerberos client libraries.  I then
put it all in a DLL.

--
   
   *   *         ==================================================
     ^           #    erussell@wang.com     "Just a happy guy"    #
   \___/         ==================================================
Newsgroups: comp.protocols.kerberos
From: glenz@ocsg.COM (Glen Zorn)
Subject: Looking for good cryptographic psuedo-random number generator
Organization: Internet-USENET Gateway at Stanford University
Date: Tue, 1 Sep 1992 17:19:52 GMT

Folks ~

I'm searching for a good, solid cryptographic psuedo-random number generator.
Pointers toward source code would be most appreciated, sources for algorithms
also gratefully accepted.

~ Glen


Glen Zorn       Network Security Analyst
glenz@OCSG.COM  Open Computing Security Group
Newsgroups: comp.protocols.kerberos
From: ramus@nersc.gov (Joe Ramus)
Subject: New User Accounts
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 2 Sep 1992 01:04:54 GMT


I do not see a good way to handle new user accounts in MIT Kerberos 4.

On some of our systems now, we have the concept of an expired password.
When we add a new user, the assigned password is expired and can only
be used to get a new password.  We then use some off-line method to inform
the new user of the assigned password.  The user must then get a new
password which is known only to that user.

Kerberos 4 has the concept of an expiration date for a principal.
When that date is reached, the principal is no longer able to get a
ticket and cannot change the password.

How do other sites manage new accounts and assigned passwords?

  Joe Ramus  NERSC Livermore  (510) 423-8917   ramus@nersc.gov
Newsgroups: comp.protocols.kerberos
From: smb@ulysses.att.com
Subject: Re: New User Accounts
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 3 Sep 1992 15:16:09 GMT

	 Dictionary attacks can eb stopped using the protocls developed
	 by li Gong et al, and by Bellovin & Merrit. Note that the
	 latter necessitates the use of public-key, and both have
	 (probably acceptable) an overhead.

Both protocols require public key cryptosystems.  One significant difference
is that the Lomas/Gong/Needham/Saltzer protocol requires a known public
key for the server, and the Bellovin/Merritt one does not.  Both require
high-quality random numbers.  Bellovin/Merritt imposes some possibly-tricky
constraints on what a public key can look like.


		--Steve Bellovin
Xref: sparky comp.protocols.kerberos:662 comp.sys.next.misc:19255 comp.sys.sequent:527 comp.sys.dec:4835 alt.security:4245
From: ccx009@cch.coventry.ac.uk (Adam Bentley)
Newsgroups: comp.protocols.kerberos,comp.sys.next.misc,comp.sys.sequent,comp.sys.dec,comp.security,alt.security
Subject: Kerberos V4 slave testing
Date: 3 Sep 92 16:54:34 GMT
Followup-To: comp.protocols.kerberos
Organization: Coventry University


The documentation for Kerberos V4 is a bit patchy. Does anyone have 
anything more up to date than the stuff at athena-dist.mit.edu?

More notes on testing slave servers, network services etc. would be useful.

In fact, any additional documents at all! Postscript would be nice


thanks for any help...

(cross posted to various comp.sys groups as these are the platforms I'm
currently building/testing on. Follow-ups to comp.protocols.kerberos
and via email if possible please!)

-- 
						_
					       /-\dam

FLESH: Adam Bentley (Fraggle), Systems/Networking, Coventry University. UK
Newsgroups: comp.protocols.kerberos
From: dean@ksr.com
Subject: Re: New User Accounts
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 3 Sep 1992 20:54:10 GMT

Yes, the scheme would require an /etc/srvtab.  I don't see how to  
avoid this, unless the kerberos server knows the securID algorithm.   
This is difficult for us, as we would need to buy source to the  
securID server software.  


This definitely suffers from the problem of a compromised  
workstation.  I don't think it changes the situation however, because  
if a workstation is compromised, the login program can be changed to  
steal the users password, or the tickets can be stolen after they are  
obtained.

The securID code is a combination of a user chosen PIN, and a 6 or 8  
digit changing code, combining to form a minimum of a 10 or 12 digit  
number.  I think this is unreasonable to crack by force in a short (8  
hour max for V4) time period.  Though perhaps it is not.  If the PIN  
is known, the user can definitely be cracked.

Even so, a TGT or a new random key could be sent back over the  
existing secure channel.  By sending a key rather than a TGT, I can  
easily configure accounts with passwords and accounts with SecurID  
cards, without having the client software aware of which is actually  
used.  Also, the kerberos server and libraries don't need to be  
modified.

Also, SecurID code replay can be avoided by keeping a cache of  
recently used SecurID codes, and insuring that they are only used  
once.  Now, one only needs to worry about the users tickets being  
stolen should the workstation be compromised.  


			--Dean

Dean Anderson
KSR Computing Facilities
Kendall Square Research
Newsgroups: comp.protocols.kerberos
From: hilary@SNLL-ARPAGW.LLNL.GOV (Hilary Jones)
Subject: Re: New User Accounts
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 2 Sep 1992 19:01:59 GMT

Dean,

We have modified Kerberos V5 to allow the use of the SecurID card.  The
mods for this should be available on the internet (I forget the location) 
and perhaps will find their way into the final release of V5.

Hilary
Newsgroups: comp.protocols.kerberos
From: bagate!socrates!bf4grjc (Ganesan)
Subject: Re: New User Accounts
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 2 Sep 1992 21:42:08 GMT

ravi@socrates.bell-atl.com
X-Mailer: ELM [version 2.3 PL8]

> 
> The solution here is not a simple one, so suggestions are open!
> 
Here at Bell Atlantic we have a major V.5 deployemnet planned, 
concurrent with a major token authenticator deployement. And in 
looking at this problem agree that it is hardly simple.

> (The real solution is to throw away SecurID as a method of
> login-password-authentication and extend kerberos all the way across
> the modem to the terminal.)
> 
However, throwing away SecureID is NOT any solution at all. 
Lets assume, that by some majic Kerberos gets deployed on every 
terminal in every location (e.g. its already availble for PCs to 
some extent, X-Terminals have it, so this is not very far fetched..).

What problem do you solve? 
Type 1. Cleartext passwords over supposedly insecure channels.

What problem does it NOT solve? 
Type 2. Password weakness problems:
 - password guessing 
 - dictionary attacks
 - intentional password sharing
 - unintentional password sharing /* That little Post-It note.... */
 - enforcing accountability /* i.e. you can never prove intentional password 
   sharing; a guilty user can always claim someone guessed his password */

Analysis of security break-ins across many corporations (and I bet its 
the same for the University world) shows that the major source of threats 
are Type 2 problems. 

Most academic work on cryptographic protocol security has focussed on 
Type 1 problems. Probably because it is the more interesting and tractable 
problem. Kerberos is a good example of the tremendous steps taken towards 
solving Type 1 problems.

Meanwhile in the real world, where Type 2 problems cost companies millions 
of dollars, solutions such as SecureID, which take strong steps towards 
solving Type 2 problems, ARE EXTREMELY IMPORTANT.

Please note: This is not meant to trivialize the Kerberos work; it is 
also very important, and the smarter your average hacker gets, the more 
important Type-1 problems will get. But it must be realized that methods 
of solving Type-2 problems (e.g. the recent Kerberos work to protect against 
dictionary attacks using public-key, Secure ID type systems, etc.) are
vital to closing the doors most often used by hackers.


-Ravi

*****************************************************************************
Ravi Ganesan				e-mail: ravi.ganesan@bell-atl.com
IS SAS Corporate Network Planning	v-mail: (301) 595-8439
Bell Atlantic				fax:	(301) 595-1341
*****************************************************************************
Newsgroups: comp.protocols.kerberos
From: nessett@OCFMAIL.OCF.LLNL.GOV (Danny Nessett)
Subject: how does kerberos handle su utility
Organization: Internet-USENET Gateway at Stanford University
Date: Fri, 4 Sep 1992 16:08:35 GMT


During discussions on another topic, the question arose how remote execution
mechanisms handle on-machine utilities that require authentication. In the
context of Kerberos this question is formulated as follows. If a machine
runs a Kerberized version of rlogin and rexec, is it possible to do away
with user passwords altogether. In particular, once a user has been
authenticated by Kerberos to, let's say, rlogin, how does he then use
the su utility. Since it expects a password when changing the process
effective uid to a different user, this seems to suggest that the user
must also have a password on the machine. Furthermore, this password will
travel in the clear from the machine to which the user's terminal is
attached to the machine running rlogin.

We tried to come up with a scenario whereby the su utility is kerberized, but
kept running into the problem that su expects input to come from a
terminal. Are we missing something obvious here?

Dan Nessett
Newsgroups: comp.protocols.kerberos
From: bagate!socrates!bf4grjc (Ravi Ganesan (301) 595-8439)
Subject: Re: New User Accounts
Reply-To: socrates!socrates.bell-atl.com!ravi
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 3 Sep 1992 14:09:06 GMT

> 
> Ganesan writes:
> 
> >What problem does it NOT solve? 
> >Type 2. Password weakness problems:
> > - password guessing 
> > - dictionary attacks
> 
> >From the Kerberos class that I took at spring INTEROP, it would seem that the
> dictionary in v5 will pretty much stop these two.
>
Observe that there is a trade off situation in using difficult passwords, 
especiailly when they change often due to password aging, and when a user 
has accounts on several systems which as yet cannot share authentication. 
i.e. the harder the password, the more likely the user is to write it down.

Dictionary attacks can eb stopped using the protocls developed by li Gong et 
al, and by Bellovin & Merrit. Note that the latter necessitates the use 
of public-key, and both have (probably acceptable) an overhead.

> 
> Nothing will stop intentional password sharing.  Even with a SecureID.  It is
> just more limited with SecureID.
> 

With a token authenticator, a physical device needs to change hands for 
password sharing can take place, which in general would require the complicity
of the person doing the sharing, which can be audited. 

While I'm sure sharing can/will still occur, it is FAR MORE limited. Nothing 
works like the detterrent of being resonsible for your actions! 

Ravi
-- 


*******************************************************************************

Ravi Ganesan                            e-mail: ravi@socrates.bell-atl.com
IS SAS Corporate Network Planning       v-mail: (301) 595-8439
Bell Atlantic                           Fax:    (301) 595-1341

Note: If your e-mail reply to me bounces, try sending it explicitly to 
ravi@socrates.bell-atl.com instead of using the 'reply' feature.
******************************************************************************
Newsgroups: comp.protocols.kerberos
From: mark@deluge.mmm.ucar.edu (Mark Bradford)
Subject: Encrypted rlogin/rlogind only?
Reply-To: bradfrd2@ncar.ucar.edu (Mark Bradford)
Organization: STORM Project Office, NCAR, Boulder
Date: Mon, 31 Aug 1992 17:11:49 GMT

Has anybody extracted just the encrypted rlogin/rlogind from the Kerberos
package?  We interact with a site that is paranoid about plaintext
passwords being typed over the network, but is also paranoid about major
modifications to the operating system (read, "doesn't want to install
Kerberos").  The encrypted rlogin would help mollify them; has anybody
isolated it from the rest of Kerberos, or should I start hacking myself?
Thanks!

-- 
-- Mark Bradford (bradfrd2@ncar.ucar.edu) <> To err is human, to moo bovine.
                  "It's an ill wind that gathers no moss."
Newsgroups: comp.protocols.kerberos