HDTenEightyP/NetNews huggingface dataset:
From: backman@vaxeline.ftp.com  (Larry Backman)
Subject: Re: Kerberized NFS
Nntp-Software: PC/TCP NNTP
Organization: FTP Software, Inc., Wakefield, MA
Date: Mon, 05 Oct 1992 13:56:06

In article <1992Oct3.012831.12500@spdcc.com> dyer@spdcc.com (Steve Dyer) writes:

 >> I believe that Sun has implemented a Kerberos-based NFS authentication
 >> scheme which is dissimilar to this.  I don't know a whole lot about it.
 >> It might even be in Solaris 2.0.  Anyone know?

 I've been hammering at Sun to release their spec. for this for 
 a while without luck .  It is in fact in Solaris 2.0; as I understand
 it is simply another RPC Authentication type.


 Larry Backman
 FTP Software
From: dyer@spdcc.com (Steve Dyer)
Newsgroups: comp.protocols.kerberos
Subject: Re: Kerberos & X.509
Date: 1 Oct 92 05:43:40 GMT
Article-I.D.: spdcc.1992Oct1.054340.14436
Organization: S.P. Dyer Computer Consulting, Cambridge MA

In article <8emQBDi00WBwAkx=JW@andrew.cmu.edu> John Gardiner Myers <jgm+@CMU.EDU> writes:
>dyer@spdcc.com (Steve Dyer) writes:
>> AFS's V4 KDC doesn't resemble the MIT V4 server
>
>I'm not exactly sure what you mean by this, but the AFS V4 KDC
>does interoperate with most MIT V4 clients.

Exactly what I meant by that was that it's a different implementation
with different administrative commands and a different way of replicating
the database (UBIK).  This is a neutral observation.

The AFS V4 KDC does interoperate with most clients; jgm said "most"
because kinit/login-type programs which prompt for passwords run into
the annoying problem that the AFS KDC stores keys using a different
string-to-key algorithm than the MIT standard server.


-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
Newsgroups: comp.protocols.kerberos
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Subject: Re: Kerberized NFS
Organization: Internet-USENET Gateway at Stanford University
Date: Sat, 3 Oct 1992 06:19:07 GMT

   Date: 3 Oct 92 01:28:31 GMT
   From: dyer@spdcc.com (Steve Dyer)

   >Is anyone using MIT's Kerberized NFS in production?

   Customers of DEC's DECathena service are.

	[ An excellent description of MIT's Kerberized NFS has been
	omitted.]

I should point out that you do not need to be a Customer of DECathena to
obtain a copy of MIT's Kerberized NFS.  Indeed, MIT Project Athena is
using it in full production, and has been for a number of years.  

To get it, send mail with a subject of 'index krb-nfs' to
'archive-server@athena-dist.mit.edu' for more details.

Note that you will need access to Sun NFS sources and kernel sources in
order to compile the server-side (basically rpc.mountd and the kernel on
the server need to be modified).  However, neither Sun NFS code nor
kernel changes are required for the client-side changes.

							- Ted
From: dyer@spdcc.com (Steve Dyer)
Subject: Re: Kerberos & X.509
Organization: S.P. Dyer Computer Consulting, Cambridge MA
Date: Wed, 30 Sep 1992 01:34:56 GMT

In article <jnm-290992124706@baloo.ctd.ornl.gov> jnm@ornl.gov (Jamey Maze) writes:
>As far as Kerberos implementations, it seems that the OSF/DCE
>implementation would hold the most long term promise. I know many of you on
>this list will disagree, but at this site, the promise of a standard
>Kerberos implementation eventually being bundled with the operating system
>was enough to stifle any major investments in 3rd-party support of MIT
>Kerberos (either V4 or V5).

Well, you're going to have to BUY OSF/DCE, and I think it's going to be
a bundled (read: optional) product from OS vendors for a very long time.
(Just IMHO).  I'd expect that any 3rd party KRB5 product would have to
have a way of contacting a KDC through TCP or UDP, and not just DCE RPC,
and in such cases, you should be able to use the freely available MIT
server.  I'm excited about the DCE, too, but there's an irresistable
potency about a freely available standard which comes with a equally
freely available implementation which you seem eager to discount.

>AFS is being viewed as clear winner and with it
>being integrated into OSF/DCE, that's another point in its favor.

Huh?  AFS is viewed as clear winner to what?  It's not at all clear what
you're trying to say here.  Plus, what's going to end up in the DCE
file-system wise has some high-level similarities to AFS, but the areas
where it diverges are too many to list.  AFS's V4 KDC doesn't resemble
the MIT V4 server, but it doesn't resemble the DCE Registry/Security Server
either.

>Since
>Project Athena's funding in this area appears to have been redirected into
>OSF, it would appear that MIT will not necessarily be taking the lead role
>in on-going development in this area. I'd be interested in hearing
>thoughtful comments on this evaluation. (No flames please.)

How about a more thoughtful evaluation to begin with?

-- 
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
Newsgroups: comp.protocols.kerberos
From: glenz@ocsg.COM (Glen Zorn)
Subject: Re:  Kerberised ftp?
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 30 Sep 1992 18:09:14 GMT


In article <BvDwon.G1n@cck.coventry.ac.uk>, ccx009@cch.coventry.ac.uk (Adam 
Bentley) writes:


	Does anyone have a kerberised ftp/ftpd for 4.2 bsd?

Yes, a kerberized FTP (both server and client) is included in the Sandia 
version of Kerberos V5.  It is available for anonymous FTP from rutgers.rutgers.edu (128.6.21.9) in the file src/krb5-sandia_src.tar.Z.  I've never tried it, so caveat emptor.  Hope this helps.

~ Glen


Glen Zorn       Network Security Analyst
glenz@OCSG.COM  Open Computing Security Group
Newsgroups: comp.protocols.kerberos
From: cwm@BETA.LANL.GOV (Christina W Mercier)
Subject: Kerberized NFS
Organization: Internet-USENET Gateway at Stanford University
Date: Fri, 2 Oct 1992 14:38:36 GMT


KERBERIZED NFS

Is anyone using MIT's Kerberized NFS in production?
I am interested in finding out:
 What type of implementation, to support the Kerberized mount,
      is required for the NFS clients?
 Can a client do a Kerberized mount to one server and a regular      
      mount to another?

Does anyone know of any writeups on Kerberized NFS other than the 
      Appendix of the "Kerberos: An Authentication Service for Open
      Network Systems" paper by Steiner, Neuman, and Schiller?

Any discussion on whether folks think that a Kerberized mount is enough
  protection for an NFS server in these times would also be appreciated.

Thanks in advance.

Christina Mercier
cwm@lanl.gov
Los Alamos, New Mexico

Newsgroups: comp.protocols.kerberos
From: jnm@ornl.gov (Jamey Maze)
Subject: Kerberos & X.509
Followup-To: comp.protocols.kerberos
Organization: Oak Ridge National Lab
Date: Tue, 29 Sep 1992 17:17:38 GMT

I attended the Interop tutorial on Kerberos last year and the speakers
included a section on X.509 with a comparison of it to Kerberos. X.509 is
based on RSA public-key encryption and I believe the DEC SPX was based on
the X.509 draft standard. Since then I haven't heard anything else about
X.509 or SPX. Is there anything new on that horizon? I'm interested in that
I've been asked to provide input into the security chapter of my company's
5-year computing strategic plan and am looking for potential alternatives
to Kerberos. We will have to show that we've considered all the
alternatives.

It seems that a potential Achilles heel for Kerberos is public-key
encryption, but I remember there being some talk about Kerberos being
adapted for public-key. How serious is such an effort and who is doing it?

Also, what's the status on the development of a generic API for Kerberos
V4, V5, and OSF/DCE? How serious is that effort and who's doing it? Where
can I learn more?

As far as Kerberos implementations, it seems that the OSF/DCE
implementation would hold the most long term promise. I know many of you on
this list will disagree, but at this site, the promise of a standard
Kerberos implementation eventually being bundled with the operating system
was enough to stifle any major investments in 3rd-party support of MIT
Kerberos (either V4 or V5). AFS is being viewed as clear winner and with it
being integrated into OSF/DCE, that's another point in its favor. Since
Project Athena's funding in this area appears to have been redirected into
OSF, it would appear that MIT will not necessarily be taking the lead role
in on-going development in this area. I'd be interested in hearing
thoughtful comments on this evaluation. (No flames please.)

Thanks!

--
Jamey Maze, Oak Ridge National Lab     
Newsgroups: comp.protocols.kerberos
From: ccx009@cch.coventry.ac.uk (Adam Bentley)
Subject: Kerberised Telnet and Ftp
Followup-To: poster
Organization: Coventry University
Date: Tue, 29 Sep 1992 14:04:38 GMT


A simple question... has anyone got kerberised telnet or ftp which
they can make available (4.2 bsd preffered).

thanks.
-- 
						_
					       /-\dam

FLESH: Adam Bentley (Fraggle), Systems/Networking, Coventry University. UK
Newsgroups: comp.protocols.kerberos
From: hendrick@neptune.ctron.com (Jim Hendrick)
Subject: (none)
Organization: Internet-USENET Gateway at Stanford University
Date: Mon, 5 Oct 1992 22:46:27 GMT

Please add my name to the mailing list (if it still exists)

Jim
Newsgroups: comp.protocols.kerberos
From: hounsell@nmerh7.BNR.CA (Rob Hounsell)
Subject: Kerberos: Licensing, etc.
Reply-To: hounsell@BNR.CA
Organization: Northern Telecom Canada
Date: Thu, 01 Oct 92 19:17:56 GMT

Howdy!

  I have been asked by my manager to investigate exactly what Kerberos
is, and determine if it could be included into a product we are
developing (long-term).

Q1: Where can I find out more about it? I have read various articles regarding
    "what is wrong with it", but nothing about "what it is / can do".

Q2: I ftp'd to the ATHENA distribution site and got the README for the beta2
    version, but I see that there are export restrictions in place. Since I am
    working for a Canadian company, I assumed I couldn't get any more of the
    distribution. True? Do I have to get my corportate legal department
to contact
    someone (who?) in the US Government?

Q3: Provided we follow the disclaimer stated in the README regarding
redistributon
    (and assuming we get the correct export (import??) license), are there any 
    further restrictions regarding the selling of a product
incorporating Kerberos
    as a component?

Thanks for your help.

regards,
Rob
+-----------------------------------------------------------------------------+
| Rob Hounsell                           BNR WAN:  HOUNSELL@NMERH53           |
| NT Product Performance: OA/M           INTERNET: HOUNSELL@BNR.CA            |
|                                        PHONE: (613) 765-2904                |
|                                        ESN: 395-2904                        |
+-----------------------------------------------------------------------------+


Newsgroups: comp.protocols.kerberos
From: warlord@MIT.EDU (Derek Atkins)
Subject: Re: Ticket Forwarding
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 30 Sep 1992 20:55:42 GMT

There is a program called 'rkinit' which one can use to create an
initial ticket on a remote machine.  This requires you to have a
secure local connection, but you are already making that assumption.

You run rkinit and tell it the remote machine-name, a file-name,
principal, etc, and then it will connect to a special server (rkinitd,
which is run out of inetd) and will locally ask for your password, and
then it will encrypt the initial ticket (not your password) in the
session key and send it over.  Actually, there are TWO (2) initial
ticket requests: one from the client (rkint) and one from the server
(rkinitd).

The sources are publically available (although they are not with the
kerberos source tree as ftp-able from athena-dist).  I could put them
up for ftp if there is a need for it.

In other words, there is no need to re-invent the wheel?  Why go out
and re-code what has already been implemented....

-derek

         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: kaufman@kibitz.enet.dec.com (Charlie Kaufman)
Subject: Kerberos V5 ASN.1 question
Organization: Internet-USENET Gateway at Stanford University
Date: Mon, 28 Sep 1992 22:44:49 GMT

In looking at the ASN.1 for Kerberos V5, it appears that the data
structures could be made much more compact through liberal use of
IMPLICIT to get rid of extra tags.  Not being an ASN.1 expert, I'm
wondering whether IMPLICIT is the default given the tools you are using. (?)

	--Charlie
Newsgroups: comp.protocols.kerberos
From: dean@ksr.com
Subject: Re: X and Kerberos
Organization: Internet-USENET Gateway at Stanford University
Date: Mon, 28 Sep 1992 14:38:00 GMT

I am implementing kerberos and SecurID Cards at our site.  I planned  
to have xdm use kerberos for authentication.  Of course, I think the  
password is sent in the clear from the xterm to the host machine(s).   
I would also like to know more about the Duke implementation.

Dean Anderson		dean@ksr.com
KSR Computing Facilities
Kendall Square Research
From: jgm+@CMU.EDU (John Gardiner Myers)
Newsgroups: comp.protocols.kerberos
Subject: Re: Ticket Forwarding
Date: 30 Sep 92 07:07:21 GMT
Article-I.D.: andrew.UemQ_d600WBwEkx_QX
Organization: Systems Group 97, Carnegie Mellon, Pittsburgh, PA

Disable IP address checking on the Kerberos server.  Send your
ticket-granting credential to host B encrypted.

				_.John
From: john@iastate.edu (John Hascall)
Newsgroups: comp.protocols.kerberos
Subject: Re: Kerberized NFS
Date: 7 Oct 92 02:26:21 GMT
Organization: Iowa State University, Ames, IA

}   >Is anyone using MIT's Kerberized NFS in production?

}   From: dyer@spdcc.com (Steve Dyer)
}   Customers of DEC's DECathena service are.
}	[ An excellent description of MIT's Kerberized NFS has been
}	omitted.]

tytso@ATHENA.MIT.EDU (Theodore Ts'o) writes:
}I should point out that you do not need to be a Customer of DECathena to
}obtain a copy of MIT's Kerberized NFS.  Indeed, MIT Project Athena is
}using it in full production, and has been for a number of years.  

First, I should note we are running a hodge-podge of an *old* MITathena
which we have mangled mercilessly and DECathena parts.

Our major problem with KerbyNFS has to do with shutdown/startup.
In a normal NFS with hard mounts, you can shutdown the NFS server
and bring it backup with your clients none the wiser (other than
the time delay).  The KNFS mods add state to the NFS server (the
uid maps).  So if you have a server crash you lose this state.
If you have a planned outage you can do:

	nfsc dump uidmapfile.dmp

and have your /etc/rc* file do:

	[ -f uidmapfile.dmp ] && {
		mv uidmapfile.dmp uidmapfile.dmp~
		nfsc load uidmapfile.dmp~
	}

(or some such).   This, however, can take a very long time (both the
load and the dump).

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?

John
-- 
John Hascall                                       ``Live with it pink-boy!''
Project Vincent                                                              
Iowa State University Computation Center                     john@iastate.edu
Ames, IA  50011                                      515/294-9551 [fax -1717]
Newsgroups: comp.protocols.kerberos
From: smb@ulysses.att.com
Subject: Re: Kerberos V5 ASN.1 observation
Organization: Internet-USENET Gateway at Stanford University
Date: Fri, 2 Oct 1992 14:40:57 GMT

It's also worth noting that there are security advantages to using
at least some explicit typing.  Specifically, if fields aren't
typed, it's a lot easier to do cut-and-paste attacks.  Michael Merritt
and I discussed this at greater length in our critique of Kerberos.


		--Steve Bellovin
Newsgroups: comp.protocols.kerberos
From: glenz@ocsg.COM (Glen Zorn)
Subject: Re:  Kerberised Telnet and Ftp
Organization: Internet-USENET Gateway at Stanford University
Date: Wed, 30 Sep 1992 18:12:19 GMT

Adam ~

There is a Kerberized telnet in the Sandia distribution, as well.

~ Glen


Glen Zorn       Network Security Analyst
glenz@OCSG.COM  Open Computing Security Group
From: arnoff@vax.ftp.com (Michael S. Greenberg)
Newsgroups: comp.protocols.kerberos
Subject: KTelnet -- multiple authentication option negotiation?
Date: 28 Sep 92 20:30:12 GMT
Reply-To: arnoff
Organization: FTP Software, Inc., Wakefield, MA
Nntp-Software: PC/TCP NNTP

Here is a question:

	Once a telnet client has successfully authenticated itself to
a telnet server via kerberos can / will the server request
authentication option negotiation again at any time during the
session?  The RFC draft we are working from is not specific on this
point.

	Thanks in advance for any light you may shed,
		Mike
--
Michael Greenberg				      Internet: arnoff@ftp.com
From: laut@keego.gici.com
Newsgroups: comp.protocols.kerberos
Subject: Kerberos under VAX/VMS v5.4
Date: 7 Oct 92 03:42:38 GMT
Organization: Gull Island Consultants, Inc.


	I am interested in trying to build the Kerberos kit under the
VAX/VMS v5.4, using Wollongong TCP v5.2.  I noticed that kits are geared
for a UNIX environment.  Is there a conversion mechanism that anyone can
suggest for the MAKEFILEs, etc.?

	Seeing this is the month for Halloween, would you anticipate building
Kerberos under VAX/VMS to be relatively easy, or am I in for a treat? (:-)

-- 
Bill Laut			Internet:  laut@alien.gici.com
Gull Island Consultants, Inc.	Phone:     (616) 780-3321
P.O. Box 627
Muskegon, MI  49440		>> "Usual disclaimers, apply within" <<
Newsgroups: comp.protocols.kerberos
From: rminnich@SUPER.SUPER.ORG (Ronald G. Minnich)
Subject: Re: New User Question...
Organization: Internet-USENET Gateway at Stanford University
Date: Thu, 1 Oct 1992 17:06:05 GMT

OK, speaking as a potential user of kerberos, but probably not as a real 
user, i would like to comment on one aspect of kerberos that has 
put some people i know off the idea of using it. 

The problem with the distribution as stands is basically mechanical.
You get it, and then you have to go to many other places
to get other pieces, some of which are not there or are different
than the instructions say. In particular it seems to depend on 
certain versions of certain tools, which versions are not always
available or have been superseded. 

One major improvement that would help potential users would be to 
have a tar.Z that basically included all the pieces of code necessary
to build a given version of the system. 
In particular for things that are changing (ISODE)
a snapshot of relevant files with patches applied would help a lot. 
It seems you don't need all of ISODE for the right parts of kerberos; 
a subset would be fine for those of us who have no interest in 
running ISODE. 

I have hesitated to bring this up, but I just ran into another person
who had the same experiences, so am writing this note not 
in the spirit of complaining but in an attempt to provide a useful
suggestion. 

thanks,
ron
From: jgm+@CMU.EDU (John Gardiner Myers)
Newsgroups: comp.protocols.kerberos
Subject: Re: Kerberos & X.509
Date: 30 Sep 92 07:10:07 GMT
Article-I.D.: andrew.8emQBDi00WBwAkx=JW
	<1992Sep30.013456.16179@spdcc.com>
Organization: Systems Group 97, Carnegie Mellon, Pittsburgh, PA

dyer@spdcc.com (Steve Dyer) writes:
> AFS's V4 KDC doesn't resemble the MIT V4 server

I'm not exactly sure what you mean by this, but the AFS V4 KDC
does interoperate with most MIT V4 clients.

				_.John
Newsgroups: comp.protocols.kerberos
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
Subject: Re: Possible incorrect Pepsy flags?
Organization: Internet-USENET Gateway at Stanford University
Date: Sat, 3 Oct 1992 06:23:55 GMT

   From: bbh7rqj@socrates.MIT.EDU
   Date: Fri, 2 Oct 92 15:54:33 EDT

   I found that my version of pepsy doesn't like the -C option which
   Project.tmpl passes it.  

   I took it out, but am weary of something happening down the road...

   Is this flag really supposed to be there, or is it a mistake, or do 
   I need a newer version of pepsy?

Oops.  I forgot to mention this.  Yes, if you are using pepsy from ISODE
6.8, you will need to take out the -C flag.  The -C flag turns on
"backwards compatibility mode".  Basically, the pepsy in ISODE 7.0 and
ISODE 8.0 generates one .h file instead of the three .h files generated
by ISODE 6.8; the -C flag tells pepsy to use the ISODE 6.8 style of 3 .h
files.

So if you are using pepsy from ISODE 6.8, just take out the -C flag and
you shouldn't have any problems.  Remember that if you are using 6.8,
you do need to apply our bug-fixes to pepsy, though.  Those bugfixes
were finally accepted by the ISODE people in version 7.0, so
'pepsy-fixes' isn't need if you are running 7.0 or 8.0.

							- Ted
Newsgroups: comp.protocols.kerberos
From: schimpf@tuxedo.enet.dec.com (Brian Schimpf - DTN 226-5292  02-Oct-1992 0850)
Subject: RE: Kerberos & X.509
Organization: Internet-USENET Gateway at Stanford University
Date: Fri, 2 Oct 1992 12:57:38 GMT

Jamey,

>Also, what's the status on the development of a generic API for Kerberos
>V4, V5, and OSF/DCE? How serious is that effort and who's doing it? Where
>can I learn more?

	There is a definition of the Generic Security Service API (GSSAPI.)
There are IETF documents available that describe this work.  These are 
available via anonymous ftp from nnsc.nsf.net.  The base spec is 
draft-ietf-cat-genericsec-02.txt, while the C bindings are 
draft-ietf-cat-secservice-01.txt.  I can also say that OSF is considering
a proposal from us to include an extended GSSAPI in DCE V1.1 but that
decision has not been made yet.  Assuming that proposal is accepted we will
(or someone will) extend GSSAPI to accomodate the DCE authorization model.
These extensions would be a strict superset of the currently specified API
(i.e. programs written to the IETF version would run on DCE).  GSSAPI is
also included in the current release of Kerberos V5 from MIT unless I'm
mistaken.

	In the general area of public key I think it's safe to say that 
most of the involved players would agree that public key is the right long
term goal for DCE.  How DCE would evolve to public key and in what timeframe
are unanswered questions for now.  (These are my opinions and don't reflect
either official Digital policy nor am I attempting to speak for either
OSF or Hewlett-Packard, obviously.)

Thanks,

Brian Schimpf
Digital Equipment Corporation
Newsgroups: comp.protocols.kerberos