HDTenEightyP/NetNews huggingface dataset:
From: glenz@ocsg.COM (Glen Zorn)
Subject: Re: Anyone Ported Kerberos To MS-Windows?
Organization: Internet-USENET Gateway at Stanford University
Date: Mon, 31 Aug 1992 22:34:59 GMT

In article <btv4x4.hip@wang.com>, erussell@wang.com writes:

	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.

What *exactly* are we talking about when we say "Kerberos client"?  Is it just
kinit, klist, and kdestroy?  If so, what good is it?  If not, what Kerberized
applications (rlogin, telnet, rcp...) must be included to make a real client?

~ Glen


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

Newsgroups: comp.protocols.kerberos
From: jis@MIT.EDU (Jeffrey I. Schiller)
Subject: Re: New User Accounts
Organization: Massachusetts Institute of Technology
Date: Thu, 3 Sep 1992 19:05:45 GMT

In article <199209021630.AA04209@magrathea.ksr.com> dean@ksr.com writes:

   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.  

You are assuming that each workstation has an /etc/srvtab file. In our
environment that simply isn't true. Furthermore *if* each workstation has
a /etc/srvtab file, it must be get confidential from the users of the
workstation (unless the workstation is only used by one person, i.e.,
it is in their office).

   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.

I would recommend changing this procedure do instead return the TGT
(and associated session key) via the already encrypted channel that
was used to supply the SecurID code (assuming that the code proved
valid). Leave the person's entry in the kerberos database with a random
value (or leave the DES key NULL). This is more secure then:

   The client would get initial kerberos tickets as usual using the  
   SecurID code as the password.

Many of the SecurID cards that I have seen only have a 5 or 6 digit
value on them. If I watch you login, given your proposal, I can obtain
your TGT and session key encrypted in a value which I *know* is a 5
or 6 digit purely numeric string. I can then do an offline search of
all valid 5 and 6 digit values (and with modern computers and fast DES
software, this can be done quite quickly, easily within the session
lifetime).

			-Jeff
Newsgroups: comp.protocols.kerberos
From: nassif@advtech.uswest.com (Rodolphe Nassif)
Subject: Request for ftp info for Kerberos software for SUN workstations
Originator: nassif@agni
Organization: U S WEST Advanced Technologies
Distribution: usa
Date: Wed, 26 Aug 1992 20:28:09 GMT

I need information on which network site and under which directories kerberos
software for SUN workstations is available to ftp. 
A side question: is Kerberos version 5 a superset of version 4? 
(the reason of my question is that the server side of my application would 
be running on MVS using IBM's Kerberos).

Thank you,

Rodolphe Nassif
U S WEST Advanced Technologies
Boulder, CO 80303
ph# (303) 541-6288
e-mail: nassif@uswest.com
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 18:57:05 GMT

Joe,

We have modified Kerberos to use the key version number to handle this.
All new accounts start with a key version number of zero.  Such an
account is considered to have an expired password.  The user must run
kpasswd to change his password before he can use the account.  We have
also modified some of the other utilities to allow the administrator to
zero the key version.

Hilary
Newsgroups: comp.protocols.kerberos
From: ddl@DAS.HARVARD.EDU (Dan Lanciani)
Subject: Re: Kerberos for DOS and OS/2
Organization: Internet-USENET Gateway at Stanford University
Date: Tue, 1 Sep 1992 23:41:05 GMT

|Is your krb for OS/2 process or thread reentrant?

	It is, by definition, process-reentrant.  I have no idea how
it would react to multi-threading as there many potential critical
sections.  Tracking them down will have to wait until I have an
application that can make real use of multi-threading (beyond being able
to call itself a multi-threaded application in PR releases :).

|i.e., is it in a
|DLL that can be shared by processes and threads?

	I never bothered building a DLL; however, FTP Software packages
the code as a DLL so it can certainly be done.

				Dan
Newsgroups: comp.protocols.kerberos
From: glenz@ocsg.COM (Glen Zorn)
Subject: Re: New User Accounts
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 3 Sep 1992 22:08:03 GMT

All of the schemes mentioned so far for adding SecureID card support to 
Kerberos v4 seem to negate what I see as one of the system's greatest 
strengths, that the user's password is not routinely shuttled across the 
network (OK, so it *is* transmitted during password-changing, but I can't 
think of anyother time).  It seems to me that any valid integration has got to 
include this feature.

~ Glen


Glen Zorn       Network Security Analyst
glenz@OCSG.COM  Open Computing Security Group
From: alan@curta.cc.columbia.edu (Alan Crosswell)
Newsgroups: comp.protocols.kerberos
Subject: Re: New User Accounts
Date: 2 Sep 92 16:20:20 GMT
Article-I.D.: news.1992Sep2.162020.14082
Organization: Columbia University

In article <9209020104.AA25528@windsail.nersc.gov> ramus@nersc.gov (Joe  
Ramus) writes:
> 
> 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

We preload our KDC with potential user's entries with an instance
ID of "foobar" and a pre-assigned password (which for us is a not
so-well known secret but good enough given the headache of administering
15,000 new accounts each September).  For new user's we have a special
program which they run and give their pre-assigned password to.  If
they succeed in authenticating with it, then this program (which
has a srvtab instance of frobitz.admin and appears in the admin_acl.add
file ONLY) then does a kadm_ank to add the user with a null instance
and a good password that the program enforces.

Our nightly kerberos log audit script then generates a form letter
for these people which is snail-mailed to them the next day as a
confirmation that it was really them who did it.  Not perfect, but
does the job for us.

MIT Athena's Moira Userreg server is pretty much the same thing.
/a
From: alan@curta.cc.columbia.edu (Alan Crosswell)
Newsgroups: comp.protocols.kerberos
Subject: Re: Encrypted rlogin/rlogind only?
Date: 31 Aug 92 18:34:59 GMT
Organization: Columbia University

In article <1992Aug31.171149.13924@ncar.ucar.edu> mark@deluge.mmm.ucar.edu  
(Mark Bradford) writes:
> 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."

You need the rest of Kerberos, none of which is an OS modification,
in order to use encrytped rlogin, since it is Kerberos that manages
the initial session key exchange for rlogin to encrypt with.
/a
Newsgroups: comp.protocols.kerberos
From: kaufman@kibitz.enet.dec.com (Charlie Kaufman)
Subject: Re: is kadmind exportable as a binary? if so, begging letter.
Organization: Internet-USENET Gateway at Stanford University
Date: Sat, 15 Aug 1992 01:47:25 GMT

Ted Ts'o writes:

>Just to set the record straight; it's not just the United States.  Any
>of the twenty or so countries who have signed the COCOM treaty will have
>such restrictions.  The COCOM treaty basically says that any
>cryptographic material will be treated as *munitions*, and you are not
>allowed to export munitions to another country --- even including
>to another country which has signed the COCOM treaty --- without an
>export license.

I've heard this story before; I've even told it.  Recently I've seen an
announcement from University College London making crypto code
available for use with OSI protocols.  It claims to be freely
exportable anywhere except the U.S. (where it would infringe on the RSA
patent rather than violate export laws).  I assume the U.K. is a COCOM
country, so this would appear to contradict the statement above (unless
UCL is ignorant of the law or has chosen to ignore it).

Does anyone have any idea how they get away with it?  I'd settle for
caveated theories.

	--Charlie
Newsgroups: comp.protocols.kerberos
From: westes@netcom.com (Will Estes)
Newsgroups: comp.protocols.kerberos
Subject: Some Alternative Strategies For Using Kerberos
Date: 28 Aug 92 05:53:44 GMT
Organization: Mail Group


I am curious how others who have installed Kerberos are using
it.  An initial reading of the overview articles suggests to me three
different ways of using the service:

1) To authenticate the client and server just at the time a client starts
to use a service, after which packets are exchanged without
using the Kerberos ticket.

2) To authenticate each and every packet exchanged between a client and
server using the ticket.

3) To both authenticate each packet using the ticket and also encrypt 
application data using the session key.

Approach 1), while not securing all the data that is exchanged between a
client and server, at least seems sufficient to stop an arbitrary client 
from using the server (unless of course he is going to start forging 
packets at the same time that the authorized client is using the server).  
For some environments and applications, that level of security might be 
sufficient.

Approaches 2) and 3) seem like they would be a lot of work, especially if you
are trying to retrofit some existing application to use Kerberos.
True/false? 

Have I missed some other common approaches for applying Kerberos?

-- 
Thanks,
Will Estes		Internet: westes@netcom.com
Newsgroups: comp.protocols.kerberos
From: dean@ksr.com
Subject: Re: New User Accounts
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 2 Sep 1992 22:02:34 GMT

Actually, I don't have to change the kerberos server (or kerberos  
libraries) at all.

I only need to add some code in the login program and the kinit  
program to talk to the kerberos-securID server before it attempts to  
get tickets for the principal.  (And of course implement the  
kerberos-securID server, but most of whats needed is in kadmind.)

As far as distinguishing between accounts which use securID and  
accounts which don't, this isn't a problem, since kerberos still  
works the same as it always did.  


It will send the password (securely) to the kerberos-SecurID server,  
which would not be able authenticate the password, and so wouldn't  
change the password (private key).  


Hence when the principal gets the initial tickets from the kerberos  
server, he would be able to decrypt them successfully using his  
password.  It would be a good idea to keep a list of those which do  
not use (or those which do use) SecurID to prevent false messages  
about authentication failures.

The problem of reauthentication is definitely a tough one, though it  
is mostly due to the fact that kerberized rlogin and telnet do not  
allow you to dynamically turn encryption on and off.  (It would go  
away if all rlogin/telnet sessions were encrypted, but this is  
unfortunately impractical).

Having a modem (or machine on the modem) which did kerberos is  
definitely a good idea, but it still suffers from reauthentication  
problem.

		--Dean

Dean Anderson
KSR Computing Facilities
Kendall Square Research
Newsgroups: comp.protocols.kerberos
From: 0003858921@MCIMAIL.COM ("Robert G. Moskowitz")
Subject: Re: New User Accounts
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 3 Sep 1992 10:39:00 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.

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


Robert Moskowitz
Chrysler Corp.
Newsgroups: comp.protocols.kerberos
From: sommerfeld@APOLLO.HP.COM
Subject: Re: New User Accounts
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 2 Sep 1992 18:27:20 GMT

   We preload our KDC with potential user's entries with an instance
   ID of "foobar" and a pre-assigned password (which for us is a not
   so-well known secret but good enough given the headache of administering
   15,000 new accounts each September).  For new user's we have a special
   program which they run and give their pre-assigned password to.  If
   they succeed in authenticating with it, then this program (which
   has a srvtab instance of frobitz.admin and appears in the admin_acl.add
   file ONLY) then does a kadm_ank to add the user with a null instance
   and a good password that the program enforces.

   Our nightly kerberos log audit script then generates a form letter
   for these people which is snail-mailed to them the next day as a
   confirmation that it was really them who did it.  Not perfect, but
   does the job for us.

   MIT Athena's Moira Userreg server is pretty much the same thing.
   /a

The Athena Moira system (which I helped implement when I worked there;
ask me some time about why icarus.mit.edu is a CNAME pointing to
kerberos.mit.edu...) effectively uses the student id number as the
initial password (since that was the only "shared secret" we had
available that had *any* degree of security).

Two things made life interesting: 

	1) Athena was not allowed access to the student id numbers at
the time (although things have changed since then); however, they
could get a one-way hash of the id numbers.

	2) Each incoming class typically has several sets of students
with the same {first name, last name} pair.

The solution is left as an exercise for the reader :-)

						- Bill















Newsgroups: comp.protocols.kerberos
From: sjogren@TGV.COM (Sam Sjogren)
Subject: VMS Kerberos (was: Re:  Kerberos on non-UNIX systems?)
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 2 Sep 1992 20:16:13 GMT

glenz@ocsg.COM (Glen Zorn) writes:
>>	   - Mini/Super-Mini

> TVG has a version of Kerberos (I've never actually seen it) that runs under
> VAX/VMS.

Our company's name is spelled "TGV", like the French super train (but
it's a different company).

It's a V4 Kerberos implementation, currently, btw.

-Sam
Newsgroups: comp.protocols.kerberos
From: dean@ksr.com
Subject: Re: New User Accounts
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 2 Sep 1992 16:30:16 GMT

For kerberos and non-kerberos systems, I assign users an initial  
password and tell them what it is.  They are told to change it (how  
to change it, etc).  


If they do not change it (ie, the old one can be used to change their  
passwd, their passwd is changed and they lose.

		--Dean

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
From: westes@netcom.com (Will Estes)
Newsgroups: comp.protocols.kerberos
Subject: Anyone Ported Kerberos To MS-Windows?
Date: 28 Aug 92 05:54:56 GMT
Organization: Mail Group

Is anyone aware of a port of Kerberos client software to MS-DOS
or MS-Windows?  Can someone tell me how much effort is involved in porting
the client code to a new OS?  (i.e, how much code is there, and is it
particularly difficult to port?)

-- 
Thanks,
Will Estes		Internet: westes@netcom.com
Newsgroups: comp.protocols.kerberos
From: bjaspan@ATHENA.MIT.EDU ("Barry Jaspan")
Subject: Re: how does kerberos handle su utility
Organization: Internet-USENET Gateway at Stanford University
Date: Fri, 4 Sep 1992 17:22:26 GMT


You can sort of achieve what you want using ksu in its current or a
modified form, but I don't think you want to.

In its distribution form, ksu requests a ticket-granting ticket for
<username>.root, checks whether that user is in root's .klogin file,
and if so creates a root shell just like su.  (If the machine has an
rcmd.<hostname> srvtab, ksu uses it to verify the response from
Kebreros; otherwise, the response can be spoofed and ksu becomes a
security hole.)

So, for your scenario, I think this is what you would like: (a) user
on host A gets kerberos tickets, (b) user logs in via kerberos rlogin
to host B, (c) user run ksu to become root on host B.  This assumes
that the user cannot or does not want to just rlogin to host B as root
in the first place, which would probably make more sense.

There are two problems with this scenario.  (1) Kerberos rlogin does
not propagate tickets, so in step (c) the user will not have tickets
for ksu to use; the user will have to type a password.  (2) In its
current form, ksu always gets a *new* ticket granting ticket for
username.root and therefore always prompts for a password, even if the
current KRBTKFILE contains a tgt for that user.  I consider this a
bug, but haven't thought about it enough to be really sure that it is
one.

Problem (2) can be fixed by modifying ksu or using an encrypted
rlogin.  Problem (1) can only be fixed by using Kerberos V5, which has
forwardable tickets, or by using a "remote kinit" system.  Neither
will be trivial.

I recommend logging in as root in the first place.  Kerberos is not
meant to perform local password validation.

Barry

Newsgroups: comp.protocols.kerberos
From: sriram@CS.UWP.EDU (Sriram Govindarajan)
Subject: unsubscribe me!
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 3 Sep 1992 17:52:54 GMT

Please remove me from the mailing list.
Thanks
Sriram
From: westes@netcom.com (Will Estes)
Newsgroups: comp.protocols.kerberos
Subject: Kerberos Programmer's Tutorial
Date: 28 Aug 92 05:48:14 GMT
Organization: Mail Group

I recently read of the following reference in a Kerberos article:

	W.J. Bryant, Kerberos Programmer's Tutorial, MIT
	Project Athena

Is this a book or an article?  If the latter, is it available anywhere
by FTP?

-- 
Thanks,
Will Estes		Internet: westes@netcom.com
Newsgroups: comp.protocols.kerberos
From: ddl@DAS.HARVARD.EDU (Dan Lanciani)
Subject: Kerberos for DOS and OS/2
Organization: Internet-USENET Gateway at Stanford University
Date: Mon, 31 Aug 1992 18:31:41 GMT

	There has been some interest in my version of Kerberos for
DOS and OS/2, thus, I am working on extracting a distribution from
my tcp/ip source tree.  We are looking into the possibility of anonymous
ftp distribution but the export restrictions might make this difficult.
Anyone interested in the meantime should make private arrangements with
me to pick up a copy.
	The expected build environment is Microsoft C 5.1 with the 6.0A
libraries installed for a default DOS link and OS/2 available via -Lp.
The latter is necessary because some executables are linked/run during
the build to create the DES tables.  These executables are bound so
the build can work under DOS or OS/2.  I will include my version of
make.exe and a copy of BYACC compiled for DOS & OS/2 to assist in
the build process.  You will, of course, need a good socket library.
	The utilities (kinit, etc.) have been tested under both DOS and
OS/2 but the Kerberos server and admin server may work only under OS/2
or a comparable multi-tasking environment.  I do not include DOS versions
of the various r-utilities since these are specific to the tcp/ip product
you use.

				Dan Lanciani
				ddl@harvard.*
Newsgroups: comp.protocols.kerberos
From: supy@strider.ucs.ualberta.ca (Allen Supynuk)
Subject: How do we get a licence to export kerberos to Canada?
Organization: University Of Alberta, Edmonton Canada
Distribution: comp.protocols.kerberos
Date: Thu, 3 Sep 1992 17:59:48 GMT


How do we go about getting Kerberos legally in Canada?
The kerberos README file starts out saying:

   Export of this software from the United States of America is
   assumed to require a specific license from the United States
   Government.  It is the responsibility of any person or
   organization contemplating export to obtain such a license
   before exporting.

I will summarize for the net. Thanks, eh?

[If, somehow, I posted this question several times, it's because nn kept
 reporting "article not posted." Please accept my apologies.]
Newsgroups: comp.protocols.kerberos
From: dean@ksr.com
Subject: Re: Is Kerberos V5 supported by AFS, is Kerberos V5 preferred and stable?
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 2 Sep 1992 22:09:20 GMT

3stable adj  sta7bler \-b(e-)ler\; sta7blest \-b(e-)lest\
[ME, fr. MF estable, fr. L stabilis, fr. stare to stand]
(14c)
1a: firmly established: FIXED, STEADFAST
b: not changing or fluctuating: UNVARYING
c: PERMANENT, ENDURING
2a: steady in purpose: firm in resolution
b: not subject to insecurity or emotional illness: SANE, RATIONAL aa  
stable personalityq
3a1 : placed so as to resist forces tending to cause motion or change  
of motion
 (2): designed so as to develop forces that restore the original  
condition when disturbed from a condition of equilibrium or steady  
motion
b (1): not readily altering in chemical makeup or physical state  
astable emulsionsq
 (2): not spontaneously radioactive
 syn see LASTING

Kerberos V5 is in beta.  Its been in beta for a year (there is a new  
beta version out Real Soon Now).  So I guess that can be called  
stable.  


OSF DCE is derived from Kerberos, but is substantially different from  
MIT kerberosV5.  You may have problems using this for general  
authentication purposes unless you have source code for your clients  
and their servers. (and are willing to change your clients and  
servers to use DCE RPC).

If your clients/servers use encryption, you may have some problems  
using the DCE server because the encryption subroutines (or  
krb_mk_priv, etc) are not available in the libraries unless you have  
DCE source (I'm not sure this is right, it doesn't matter for me,  
because I'm planning to run both.  MIT kerberos for authentication,  
and OSF DCE for itself).

		--Dean

Dean Anderson
KSR Computing Facilities
Kendall Square Research