HDTenEightyP/NetNews huggingface dataset:
From: dleung@sulu.ucr.edu (chi-wai leung)
Newsgroups: comp.protocols.kerberos
Subject: NEED SAMPLE ON KERBERIZING!
Date: 12 Oct 92 05:49:09 GMT
Organization: University of California, Riverside

I am doing a project for a distributed operating systems class. 
I would like to Kerberize a unix command such as "tar" or "mail".
Where can I find some already Kerberized programs so I can take a look and
write my own Kerberized "tar" and "mail"?

	Any help would be greatly appreciated, including locations
of sample source, algorithms, etc...
						Thank you!!!!

From Dominica Leung
dleung@ucrengr.ucr.edu
From: hendrick@ctron.com (Jim Hendrick)
Newsgroups: comp.protocols.kerberos
Subject: Re: Replys to Kerb. on a Sun
Date: 6 Oct 92 14:23:57 GMT
Distribution: comp
Organization: Cabletron Systems Inc.

First,
	Thanks to all who replied to my query on compiling the big K
on a sun. I ended up going to 4.1.2 (I was going to anyway, this was just
the last impetus needed).

Second: Any pitfalls, tips on operating K as a secure domain within
a primarily NIS environment? Among the platforms necessary before I can
implement this are: Sun SPARC (I can put 4.1.2 on the secure machines, but
clients may be running 4.1.x, any problems?), DEC 5000/2**, 3100 and a 2100
running ULTRIX 4.2.*, IBM RS/6000 running AIX 3.2.x, SGI Indigo running
IRIX (various OS revs also) and (here it comes . . .) Sun SPARCs running
Solaris 2.x.

Thanks for any replies. Respond via e-mail and I'll summarize or reply here
and I wont have to!

Jim

--
###########################################################################
### Jim Hendrick (hendrick@ctron.com)   ###                             ###
### Cabletron Systems Inc.              ###   " My opinions, etc are    ###
### P. O. Box 5005                      ### exclusively the property    ###
### Rochester, NH 03867-5005            ### of nobody in particular."   ###
### (603) 332-9400 x1457                ###                             ###
### fax:(603)332-1019                   ###                             ###
###########################################################################
Newsgroups: comp.protocols.kerberos
From: dean@ksr.com
Subject: Re: Question on Kerberos & X-terminals
Organization: Internet-USENET Gateway at Stanford University
Date: Mon, 12 Oct 1992 15:37:57 GMT

There are 10BaseT ether switches which switch packets instead of  
rebroadcasting them.  I haven't had any direct experience with them,  
but they should make xterms as secure as the physical wiring.

		--Dean

Dean Anderson		dean@ksr.com
KSR Computing Facilities
Kendall Square Research
Newsgroups: comp.protocols.kerberos
From: hendrick@neptune.ctron.com (Jim Hendrick)
Subject: Question on Kerberos & X-terminals
Organization: Internet-USENET Gateway at Stanford University
Date: Sun, 11 Oct 1992 03:02:34 GMT

Hi,
	I am looking for information on the security problems with
using Xterminals to access "realtively secure" machines. By this I
mean machines that act as access points to a database containing
critical resources. These access machines have been physically
"secured" in a minimal sense, locked cabinets, no terminals
considered secure in the /etc/ttytab file including the console. As
part of the duties of several administrators, they are required to log
into these "trusted" machines and occasionally su to root or other
more priviliged accounts. My question relates to the ability (or
inability) to safely use Xterminals to access these "trusted"
machines. Specifically, does anyone know of a way to secure the
transmissions from these Xterminals such that a network "snooper"
could not obtain the cleartext passwords as they fly by? I am moving
towards using Kerberos as the authentication service for these
machines so that one could (from a workstation running K.) use the
encrypted mode of transmission for sensitive login sessions and to
generally keep cleartext passwords off the wire but now I have been
asked to set up Xterminals for the administrative staff to use and
think that this might pose a problem. {whew, how's that for a sentence :-}

I hope this is an appropriate forum for such a question (being new to
this mailing list).

Thanks

Jim
Newsgroups: comp.protocols.kerberos
From: "a1: :sadler"@mrgate.office.office.decnet.lockheed.com
Subject: Questions regarding Kerberos
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 14 Oct 1992 21:50:36 GMT

From:	NAME: Connie J. Sadler              
	FUNC: 48-10                           
	TEL: (408)756-1577                    <SADLER AT A1 AT OFFICE>
To:	"kerberos@athena.mit.edu"@eagle@mrgate


    
    Hello.
    
    I'm from LMSC (Lockheed Missiles and Space Company), and we have a 
    small team working to test Kerberos software on various platforms and 
    want to begin an implementation plan if it looks like Kerberos will 
    give us what we want. We are using MIT's code, TGV's software for 
    VAX/VMS and are testing some software from OCSG and CYGNUS and FTP, 
    Inc.
    
    Problem areas which you may be able to help with:
    
    	We're having trouble getting client for DOS and the MAC with VT100 
    	terminal emulation - anyone know of a source?
    
    	Will X.509 compete with Kerberos - how are they related?
    
    	Are other companies pressing vendors to build products which 
    	interoperate? Particularly IBM?
    
    I'd appreciate any comments. I am new on the mailing list and am 
    getting some good information. Thank you.
    
    
    					C. J. Sadler
    
    P.S.  We'd also like to know what ports are available.
From: mamros@athena.lkg.dec.com (Shawn Mamros)
Newsgroups: comp.protocols.kerberos
Subject: Re: Kerberized NFS
Date: 7 Oct 92 14:01:39 GMT
Reply-To: mamros@athena.lkg.dec.com (Shawn Mamros)
Organization: Digital Equipment Corporation


john@iastate.edu (John Hascall) writes:
>What would be nice is if the maps where stored in a file as well as
>in the kernel when created (so you don't loose state over a crash)
>and some way to make "load" a lot faster (seems like it takes
>about a half second per uid-map -- and we have many hundreds at
>any given time).  Someday, perhaps we will get time to look at
>this ourselves, but maybe someone else already has?

Half a second for each map sounds excessive, but then again it does have
to make one nfsmapctl(2) syscall per map.  Maybe somebody should take a
closer look at how the mapping table is structured, and see if it can be
made more efficient...

As far as having the maps stored in a file as well as the kernel, it sounds
like you want to make nfsmapctl(2)'s operation more analogous to what
quotactl(2) or quota(2) (depending on your flavor of OS) does.  That might
not be a bad idea... adding NFSMC_ON (which you would need to sync up the
kernel's copy with what's in the file at boot time) and NFSMC_OFF would
clean up parts of nfsc nicely (where, for "enable" and "disable" to work,
you have to write to kernel memory... ick).  Of course, nfsmapctl(2) is
used much more frequently than quotactl(2), so it's not clear whether this
will help performance more than it hurts (quicker startup/load time, perhaps,
but possibly slower map/unmap operations if you have to sync the file).

This is all off the top of my head - I haven't really looked too closely
at any of this, but would be interested in anybody else's comments/suggestions.
Maybe I'll get a chance to do a closer look sometime soon...

-Shawn Mamros
DECathena engineering
E-mail to: mamros@athena.lkg.dec.com
Newsgroups: comp.protocols.kerberos
From: jfc@ATHENA.MIT.EDU (John Carr)
Subject: Re: Question on Kerberos & X-terminals
Organization: Internet-USENET Gateway at Stanford University
Date: Sun, 11 Oct 1992 19:34:32 GMT


There is no standard for encrypted or Kerberos authenticated X.  Check with
your X terminal vendor.

Some X terminals have a serial connector on the back which you could use to
connect the terminal to a secure system, bypassing an insecure ethernet (I
know the DEC X terminals support this; I assume there are others).
From: looi@qut.edu.au (Mark Looi)
Newsgroups: comp.protocols.kerberos
Subject: Summary: Kerberos/PK and SecurID
Date: 12 Oct 92 09:13:59 EST
Organization: Queensland University of Technology

Thanks to all who responded.  As requested by some, here is a summary of
responses.

SecurID / Kerberos
------------------
Work is being done by Sandia and Security Dynamics.  At present, re-synching
with beta2 is in progress.  

Contact:
	Bill Rahe		whrahe@somnet.sandia.gov
	Glenn Machin		gmachin@somnet.sandia.gov


The Open Computing Security Group has also started coding SecurID support,
contact:
	Bob Gassen		bobg@ocsg.com


Kerberos Public Key
-------------------

Again, the OCSG is working on RSA Public Key support, this is at design
stage.  Same contact as above.


Charlie Kaufman has also posted some info to the net a few days ago, that
info is not included in this summary.


The area I'm looking into specifically is management of the principal's keys
(in particular, for 'human-user' principals) using smart cards (with in-built 
DES or RSA facilities) to work in the OSF/DCE environment.

Anyone else out there doing any work in this area?

Mark

----------------------------------------------------------------------------
Mark Looi                                                  m.looi@qut.edu.au
Information Security Research Centre                mlooi@fitmail.qut.edu.au
Queensland University of Technology
Brisbane QLD 4001 Australia
From: hendrick@ctron.com (Jim Hendrick)
Newsgroups: comp.protocols.kerberos
Subject: Re: Possible problem with rsh
Date: 8 Oct 92 15:49:18 GMT
Organization: Cabletron Systems Inc.

In response to my question, it seems that Sun allows:

rsh -n $host "blah blah blah"

while the bsd standard (as in the man pages . . .)

is:

rsh $host -n "blah blah blah"

so Kerberos's rsh passws the -n in as the hostname.


So much for standards.


Thanks for all who responded !!! (I'll try to think up some tougher ones ;-)



Jim
--
###########################################################################
### Jim Hendrick (hendrick@ctron.com)   ###                             ###
### Cabletron Systems Inc.              ###   " My opinions, etc are    ###
### P. O. Box 5005                      ### exclusively the property    ###
### Rochester, NH 03867-5005            ### of nobody in particular."   ###
### (603) 332-9400 x1457                ###                             ###
### fax:(603)332-1019                   ###                             ###
###########################################################################
Newsgroups: comp.protocols.kerberos
From: root@SNOWHITE.CIS.UOGUELPH.CA (gopher I)
Subject: Re: Kerberized NFS
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 8 Oct 1992 23:40:14 GMT

  On the other hand, it is certainly true that it wouldn't be that hard to
  make the same changes to a public-domain Unix NFS implementation ---
  say, the NFS implementation found in BSD 4.4, for example.  To my
  knowledge, no one has done it yet, but I can't imagine that it would be
  difficult.

In fact, the 4.4 nfssvc() syscall (which has options for pushing
uid --> cred mappings into the kernel) should be close to sufficient, so
about all that would be required would be the changes to mount_nfs/mountd.
Newsgroups: comp.protocols.kerberos
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Subject: Re: Kerberized NFS in 4.4BSD
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 8 Oct 1992 19:02:08 GMT

   Date: 8 Oct 92 05:14:38 GMT
   From: dyer@spdcc.com (Steve Dyer)

   >- The specification of the MIT mechanism is not public either. My
   >  understanding is that MIT logs all requests for the info. for Sun and that
   >  this suggests that Sun considers some of the provided code/info proprietary.

   This comes as a surprise to me; Ted, comments?  Aren't diffs available?

MIT does log all the people who askes for the MIT mechanism, but what is
distributed is context diffs to source code which can only be licensed
through Sun.  So in effect, you do need a Sun NFS source license if you
want to use the context diffs directly.

On the other hand, it is certainly true that it wouldn't be that hard to
make the same changes to a public-domain Unix NFS implementation ---
say, the NFS implementation found in BSD 4.4, for example.  To my
knowledge, no one has done it yet, but I can't imagine that it would be
difficult.

							- Ted
Newsgroups: comp.protocols.kerberos
From: looi@qut.edu.au (Mark Looi)
Newsgroups: comp.protocols.kerberos
Subject: Kerberos 4 on 386BSD and AT&T Unix 5.4
Date: 12 Oct 92 09:18:14 EST
Organization: Queensland University of Technology

I'm thinking about installing Kerberos 4 (actually, the Bones package with DES
re-inserted) on 386BSD 0.1 and/or AT&T Unix 5.4.0 (with BSD compatibility
package).

Has anyone tried {successfully/unsuccessfully} ?

Any hints, tricks, advice ?

Mark
---------------------------------------------------------------------------
Mark Looi                                                 m.looi@qut.edu.au
Information Security Research Centre               mlooi@fitmail.qut.edu.au
Queensland University of Technology
Brisbane QLD 4001  Australia

Newsgroups: comp.protocols.kerberos
From: alan@curta.cc.columbia.edu (Alan Crosswell)
Subject: Re: Kerberos DES <> MD5
Organization: Columbia University
Date: Wed, 7 Oct 1992 18:26:45 GMT

I've been straightened out by Chuck McManis at Sun that MD5 is public domain.
What is restricted is the use of RSA to encrypt a message digest to do a
public key signature.  Or something like that!
Newsgroups: comp.protocols.kerberos
From: schoultz@admin.kth.se (Rickard Schoultz)
Subject: Summary: klogin clients for PCs, Macs and terminal servers
Organization: Royal Institute of Technology, Sweden
Date: Sat, 10 Oct 1992 19:49:15 GMT

 Two weeks ago, I asked for pointers to kinit/login clients for
the mac, pc:s and terminal servers. Many thanks to those who responded!  
I got one answer about a mac product, one about terminal server support 
and one about OS/2. 
 I am a bit surprised to see that the only answers I got referred to
commercial products, surely there must be more implementations than
these. 
 Anyway, here's the summary:

/Rickard

----------------------------------------------------------------------
1. 
   PC/TCP 2.1 for MS-dos (and OS/2?) comes with kerberos support.
   
----------------------------------------------------------------------
2.
   From:    Rob MacKinnon <robmack@bsc.no>
   IBM's OS/2 comes with kerberos v4 support built in to the TCP/IP 
   portion of the product..

----------------------------------------------------------------------
3.
   From:    ekcaulfield@mkt.xyplex.com (Ed Caulfield)
   Subject: Terminal server support of Kerberos
   
   The Xyplex terminal server product supports Kerberos V4.

----------------------------------------------------------------------
4.
   From:    bobg@ocsg.COM (Bob Gassen)
   Subject: Kerberos information

   Yes, we offer commercialized kerberos software klogin clients for the 
   Mac and PC's, along with clients and servers for many other platforms.
   Our PC products work with FTP's TCP/IP and Wollongong's as well.  Our 
   Mac product os built on MACTCP.  

   Bob Gassen
   Open Computing Security Group
   (206) 883-8721
   2451 152nd Ave NE
   Redmond, WA 98052
----------------------------------------------------------------------
-- 
Rickard Schoultz			schoultz@admin.kth.se
Royal inst. of Technology - TS/Data	+46-8-790 90 88   (voice)
S-100 44 Stockholm (SWEDEN)	    	+46-8-10 25 10    (fax)
Newsgroups: comp.protocols.kerberos
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Subject: Re: Clarifying preauthentication
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 8 Oct 1992 18:46:09 GMT

   Date: Thu, 8 Oct 92 11:45:10 EDT
   From: John Linn. <linn@albeit.enet.dec.com>

   As I understand the scheme, it doesn't directly prevent off-line password
   attacks.  Rather, its real value (and it is real value) is indirect,
   making it harder for an attacker to actively acquire the necessary
   basis against which to attempt such attacks.  

John,
	Oops!  You're absolutely right; I wasn't sufficiently careful
when I was typing up the text of my announcement.  I was being far too
loose there --- thank you for calling me on it.  

	The correct statement is that it makes off-line password attacks
much more difficult, since the attacker must eavesdrop on the network
for a ticket exchange of the user who is under attack, instead of merely
asking the KDC for a ticket with which to mount the off-line password
attack.

	One way to absolutely prevent off-line attacks would be to
create a new preauthentication type which requests that the encryption
portion of the KRB_AS_REP also be encrypted in a service key found in
/etc/srvtab, as well as in the user's secret key.  But of course, that
only works if the machine on which you are logging in has an /etc/srvtab
file to which the login or kinit program has access.

	The other method, which you mentioned, is that with certain
types of hand-held authenticators, it might be possible to use the value
sent back from the authenticator as part of the key encrypting the
KRB_AS_REP message.  This assumes that you do not send that value back
to the KDC (so it is not exposed to the network), and that the value
displayed by the hand-held authenticator is long enough to be used
either exclusively or supplementarily as keying information.

	Again, my apologies for my mis-statement in my announcement; I
really should have been more careful.

					- Ted
Newsgroups: comp.protocols.kerberos
From: bbh7rqj@SOCRATES.MIT.EDU (Davies)
Subject: Error in .../kdc/policy.c
Organization: Internet-USENET Gateway at Stanford University
Date: Tue, 13 Oct 1992 13:26:05 GMT

Just in case someone hasn't caught this yet, I found a mistake in 
.../kdc/policy.c, line 61.  It said:

#ifdef 0  

when I think it should have been:
 
#if 0



Chris.
-- 

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

Chris Davies	                        e-mail: cdavies@socrates.bell-atl.com
Bell Atlantic                            Voice: (301) 989-4111
                                           Fax: (301) 595-1341


Note: If your e-mail reply to me bounces, try sending it explicitly to 
cdavies@socrates.bell-atl.com instead of using the 'reply' feature.
******************************************************************************
From: dyer@spdcc.com (Steve Dyer)
Newsgroups: comp.protocols.kerberos
Subject: any ports to 64-bit machines of KRB4?
Date: 15 Oct 92 06:48:50 GMT
Article-I.D.: spdcc.1992Oct15.064850.16891
Organization: S.P. Dyer Computer Consulting, Cambridge MA

Any words of warning or advice?  Gotchas, especially in the DES code?
Didn't Cray do a port not long ago?  Anyone else?  (Convex?)

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
From: haynes@cats.ucsc.edu (Jim Haynes)
Newsgroups: comp.protocols.kerberos
Subject: Re: Kerberized NFS in 4.4BSD
Date: 8 Oct 1992 18:01:43 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: hobbes.ucsc.edu


Steve asked about diffs between Sun NFS and Kerberized NFS.  As I recall the
MIT implementation of NFS was done to some source code that is quite
different from what you get from Sun; at any rate when we did the 
nfs_server.c module for SunOS 4.0 and 4.1 and 4.1.1 it was a matter of
looking at the MIT sources and figuring out how to apply them to the
Sun sources, rather than merely patching the latter.

On another branch of this topic, I don't suppose MIT is very interested in
messing with NFS now that AFS is so popular there.  I've been thinking of
looking at Sun's own Kerberized NFS implementation, which I presume is
incompatible with the MIT implementation we are now running.  Is this
in Solaris 2.0, does anyone know?  I spoze using it is a matter of
creating yet another file system type and hacking the attach program to
support it.
-- 
haynes@cats.ucsc.edu
haynes@cats.bitnet

"Any clod can have the facts, but having opinions is an Art."
        Charles McCabe, San Francisco Chronicle

Newsgroups: comp.protocols.kerberos
From: kaufman@kibitz.enet.dec.com (Charlie Kaufman)
Subject: Re: Kerberos DES <> MD5
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 7 Oct 1992 18:42:01 GMT

>I believe that MD5 is patented by RSADSI in the US of A.  It may be used
>only under license from RSADSI in this country.

MD5 may or may not be patented, but in any case RSADSI has made it
freely useable without payment of royalties (unlike the RSA algorithm
itself).  The notice in the model code in RFC 1321 includes the following text:

-----
Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991.  All rights
reserved.

License to copy and use this software is granted provided that it
is identified as the "RSA Data Security, Inc. MD5 Message-Digest
Algorithm" in all material mentioning or referencing this software
or this function.

License is also granted to make and use derivative works provided
that such works are identified as "derived from the RSA Data
Security, Inc. MD5 Message-Digest Algorithm" in all material
mentioning or referencing the derived work.
-----

>Besides, any crypto technology is  
>restricted from export.  So, an export license would be necessary for RSA
>just as it is for DES and a Captain Midnite Decoder Ring.

Sadly, this part of the message is correct.  There is a misconception
that encryption based on MD5 would be easier to export than encryption
based on DES.  This is *probably* not true (never make any absolute
statement about export).
Encryption used for data integrity protection (either via DES or MD5)
is easier to license for export than encryption used for data privacy. 
But if you use MD5 for data privacy (which is possible but
cryptographically unproven), you're in the same soup.

It is possible to remove encryption for privacy from Kerberos and get a
fairly general export license.  Digital has done so with Kerberos V4. 
Unfortunately, that is not the same as freely distributable and - at
least in our case - part of the price was not distributing source code.
 It did not require removal of DES.

	--Charlie

-------------------------------------------------
Email: kaufman@dsmail.enet.dec.com  Paper: Charles Kaufman
Phone: 1-508-486-7329                      Digital Equipment Corporation
FAX:   1-508-486-5279                      550 King Street, LKG1-2/A19
                                           Littleton, MA 01460
Newsgroups: comp.protocols.kerberos